« March 2009 | Main | May 2009 »
What are you doing at 2pm eastern today? If you have that annoying budget meeting, or maybe one of those late lunches with the group of folks that bug you, how about joining me for a webcast on PCI?
Click here to register, and I'll be on Twitter during the event if you guys want to interact!
PCI is still a hotly debated topic nearly four and a half years after its initial release on December 15, 2004. You didn't have to visit too many after hours parties or exhibitors at RSA to see that.
Most of the criticism of PCI comes from people who really don't understand it, or understand how to use it to their advantage. And those people fall into two categories themselves; those who are green to PCI and are overwhelmed, and those who love their soap box.
Those in the former bucket just need time to get up to speed. PCI, like Rome, was not built overnight, and it requires weeks of study to fully grasp how it will affect your environment. There is training available from a couple of industry sources, though my personal preference is that any training on payment security should not stop at PCI. I have a solution for the card companies to address the latter group directly, but more importantly, address the industry at large to demonstrate that you really do focus on information security.
I propose that the founding members of the council (Visa, MasterCard, Amex, Discover, and JCB) consider two ways to demonstrate PCI Compliance. The first of which is to complete the PCI DSS just like they would do today. Nothing new there.
Here's the twist.
The second method should be met by demonstrating a mature ISO 27000 security program, potentially certified under BSI America. That serves two purposes. The first purpose is to accomplish the intent of PCI DSS, protecting the data. The second is to combat the nay-sayers who say things like "I can't wait until this PCI crap is over so I can get back to security1." In reality, those nay-sayers were doing a poor job at security before by only focusing on problems that interested them, not ones that were in the best interest of the customers, shareholders, and employees of the company.
If the card brands gave merchants and service providers the option, I think you would see the majority choosing PCI DSS, and only the most savvy choosing the ISO route. The best thing is that the card brands could fight the fires on two fronts. They can continue to coddle the laggards, and improve corporate information security for those that wish it. Most security professional agree (four out of five dentists?) that PCI is not the scariest thing out there, by FAR. But if you use what you learn from PCI and improve upon its required baseline, you can use the ankle-biting nature of PCI to also subdue his bigger, more ornery cousins PII and the State Data Breach Laws2.
_______________________________
1 This is an ACTUAL QUOTE from one of my retail contacts!
2 Sounds like a great name for a band!
Well, I finally made it back home yesterday after a week in San Francisco. It was great to put some faces to names, and thanks to all of you who stopped by the VeriSign ESS booth and said "Hi!"
On Wednesday, the blogger meetup DID happen, and neither Tim Callan nor I won any of the awards; though we did cheer loudly for our fellow bloggers! And then, who woulda thunk it, but little ol me won a Seagate Black Armor 420 NAS drive! SWEET! Thank you to Seagate for that!
The tweeps were tweeting all over the place!
Now, one last thing before I check out of the blogosphere for the week, I had to pass along this freaking awesome Twitter feed. The very county in Texas that I live in (Denton) now has a Twitter feed. What are they tweeting, you might ask?
Wait for it....
Mugshots! Yep, the next time I get caught for stealing my neighbor's paper might get me posted over there! Interested to know what kinds of offenders we have? Follow @DentonPolice on Twitter. The picture up as I am typing this is a 27 year old androgynous hipster with an attitude that got picked up for an outstanding warrant. This picture says facebook profile pic all over it.
Now if you read a little further, you will find that this is not an official, county sponsored feed. A photography student named Brian Baugh stumbled upon the online county jail report while studying new media. Quite an interesting little project Brian! Congrats!
See part 1 here, part 2 here, part 3 here, part 4 here, part 5 here.
Go Forth and Compensate!
What a pretty mural we have painted over the last several pages! Good compensating controls are the result of a marriage between art and science. We've discussed what compensating controls are, what they are not, some funny examples of how to go wrong, and three solid scenarios from which we created good controls.
Compensating controls are not the golden parachute of compliance initiatives. They require work to build effective ones that will pass the scrutiny of both a QSA and an Acquiring Bank (or card brand). Rarely do they yield lower cost and effort than simply meeting the original requirement. PCI DSS is based on many good (not best) standards of practice for security, and should be viewed as a baseline by which to operate, not a high water mark by which you aspire to be one day. Compensating controls may help you lower the bar of compliance in the short term, but remember, only you can prevent a security breach.
I hope you enjoyed this article on Compensating Controls! Look for links to download the entire articles in the next few days!
See part 1 here, part 2 here, part 3 here, part 4 here.
How to Create a Good Compensating Control
We've spent quite a bit of time setting this section up. We talked about what Compensating Controls are, what they are not, and some of the best mis-guided attempts to create them. Before we discuss the examples, please remember that these examples should be used for illustrative purposes only. I have over simplified the scenarios for brevity, and things are rarely as simple in the corporate world. Ultimately, compensating controls must be approved first by a QSA, or barring that, your Acquiring Bank. I know I don't like it when someone slaps some random article about PCI on me during an assessment, so please don't do that with this one. Now let's walk through a couple of examples of how one might create a good compensating control.
Here's a common compensating control that my team defines and implements at a customer. A Level 1 brick and mortar retailer with 2,500 stores has some systems in their stores that do not process cardholder data. These systems are a high risk to this customer's cardholder environment because they may access both the internet through a local firewall and the corporate intranet and webmail system, and users log-in to that machine with the default administrator account. Store managers and retail operations claim that the systems are required for day-to-day business because each store is empowered to customize their operations to better fit the local market. The corporation believes this drives innovation and helps them maintain a competitive edge over their peers.
What do you do? Do you crush the retailers aspirations to innovate by telling them they must deploy active directory to these machines, lock them down Department of Defense tight, and staff a call center? I suppose you could. But, if you made that recommendation you missed something important--understanding the business and limiting the impact that your compliance recommendations make. Instead, consider this compensating control.
Any number of network components could be used to create some segmentation in this environment. Let's say that we have a VLAN aware switch at the location that can have access lists (ACLs) tied to it. Why not create a new VLAN for just the POS network? Then create some ACLs around it to make it look like it is segmented behind a firewall. Now the threat of the in-store PC is effectively mitigated provided that the ACLs are appropriately secure.
Wait a second, ACLs? Those are not supposed to be used for compliance with PCI! They most certainly can be used for compliance. Requirement 1.3.6 only refers to external connections, not internal connections. Using ACLs internally is perfectly acceptable. If you want an extra boost in security, use a reflexive access list (RACL) which will basically look and feel like a stateful inspection firewall.
"But Branden," you say, "my store networks are different in every store! I can't just slap something in there like that and expect it to work globally!" If this is the case, I bet your store support group is overloaded with break-fix calls. Maybe this could be an opportunity to shore this up and get consistent footprints in each store?
Barring that, how about this twist?
Let's say that you are running a Windows XP variant as the operating system powering your POS. You are already required to put some kind of Anti-Virus and malware removal tools on there. Most of those come with software-based firewalls that could be administered remotely. Deploying firewall capabilities to the POS itself could be viewed as appropriate segmentation depending on the policy attached to that firewall. It is neither a transparent solution, nor is it very pretty, but it works.
The first solution above is really less of a compensating control and more of a way to reduce the scope of PCI. The best thing you can do for your company is reduce the scope of PCI (or any compliance initiative) to the bare minimum required, and then manage that subset of your infrastructure. The second truly is a compensating control. It meets the original intent and rigor of the original PCI requirements and provides a similar level of defense as the original requirements (reduce the vulnerability to payment systems), goes above and beyond the base requirements of PCI (firewalls are not required on devices that do not leave the premises), and it is most definitely commensurate with the additional risk imposed by not meeting the original requirement.
Take a closer look at those two suggestions. The first may be "free" to your company depending on what is already in place! You will need to adjust business process and prepare your IT community to deal with the change, but you may not need to spend any hard dollars rolling this solution out (unless your equipment cannot do this in the first place). The second suggestion, which is actually the compensating control, requires capital outlay for software licensing and training or consulting to build out the environment. Upon rollout, things will break that will result in potential losses to the business. I've seen retailers push changes like this to large environments, and every single one results in some kind of error.
Are you starting to get the hang of this thing? How about another example?
A Service Provider has a large mid-tier UNIX installation that runs critical areas of the payment process, including long-term data storage. For various reasons, encrypting the data is not an option on these machines. How do we make this service provider compliant with PCI Requirement 3.4?
This is a real world example that comes up frequently. Encryption implementations have come a long way since early in this decade. The words "my platform does not have a solution for encryption" is no longer valid for platforms that can comply with PCI. When I present the following control to customers, it is shocking how fast they find a way to encrypt their data.
Most mid-tier UNIX operating systems have the ability to switch from Discretionary Access Control (DAC) to Mandatory Access Control (MAC). MAC will cause that mid-tier UNIX machine to act like a mainframe using RACF/ACF2, and managing those controls is now a massive chore for whomever is charged with it. Converting the appropriate systems to MAC, and potentially adding some segmentation could effectively render cardholder data unreadable and meet PCI Requirement 3.4.
Things are never that easy. Security professionals inside companies love the idea of converting to MAC as it allows us to have more granular control over the systems and their data. Practical ones know that converting an existing system requires so much effort that the costs outweigh the benefits. This is a perfect example of how a compensating control might look good on paper (it's only three words when you use the acronym! 'Convert to MAC!'), but in reality would be much easier to just meet the implied requirement to encrypt that data.
One more example, and then it's time for you to get creative!
A medium sized retailer with less than 500 stores is struggling with requirement 10.2.1 to log 'all individual accesses to cardholder data.' All of their data is stored in a large DB2 database that runs on a mainframe. They run massive batch processes at regular intervals, and their space constraints prevent logging every single access to a row. Do you tell them to go back to their board for a CapEx request to buy lots and lots of drive space to store logs?
Before we proceed, consider the intent of the requirement. Reliable logs are valuable in investigating a breach quickly. Without them, it may take forensic examiners days, or even weeks, to determine the source of a breach. Once the source has been identified and analyzed, forensic companies must attempt to determine how many card numbers may have been exposed. If there are no logs, the assumption is that everything could be exposed, meaning that fines will add up pretty quickly.
The idea is not necessarily to make a log record that includes every single card number that is accessed, but to be able to identify which cards are accessed through the data contained in the logs. If we were to log the actual query performed against the database during a batch process, with knowledge of the date and time that the query was run and exactly what that query will do, we should then be able to determine, with reasonable certainty, which cards were accessed. Common batch processes run on a daily basis, usually using the data from the previous day to produce its output. If we must determine what could have been exposed from January 1 to January 8, we could look at the data that would have been accessed by that batch process during those days.
Logging the query, and all the other elements required by 10.3 about that action, would generate a reasonably accurate list of records that would use a fraction of the drive space required by creating an entry that has every single record exposed.
Look for the conclusion, part 6, on Wednesday!
I hope to see you there! I arrive on Monday and will be at the welcome reception about halfway through, and am leaving at lunchtime on Thursday. You can find me at the VeriSign ESS Booth (not the big one up front) at Booth #1454. It's in the back, so you have to look for it!
I will be manning the Retail Security area of our booth on Wednesday from 11:00 to 2:30. Come by and see me! Also, if you have not done so already, follow me on Twitter (http://twitter.com/BrandenWilliams/), I'll be tweeting from the conference and the booth! Who knows, maybe we'll end up at the same crowded bar filled with people arguing the merits of DLP!
I've been writing Herding Cats for over a year now, and with all this talk about DLP, I wanted to dust off my FIRST EVER Herding Cats.
Have you ever wanted to see if sensitive data your company protects exists outside of designated areas? Maybe you are looking for Personally Identifiable Information (PII), intellectual property, or cardholder data that might be sitting around in flat files. I suggest turning to Grep1, a GNU searching tool that is included on most Unix-based operating systems (and there are MS ports)!
Grep can use the power of regular expressions to quickly search for patterns in files. The results obtained will help you triage data leakage that may occur through the normal course of business.
I was recently working with a customer who found additional consumer information in batch files received from a financial institution. I am not talking about the consumer's hair color or meal preference. I am talking about their social security numbers. Our customer had no idea they were receiving this information, and yet they would likely be liable for its disclosure if a breach occurred.
The method described below is not foolproof; however, it will find the majority of files containing sensitive data.
It will not reliably (without additional tweaking) find information encoded inside binaries or database files, but you can use it to look through compressed files2 and flat files.
Let's say you wanted to take a cursory look at data that could contain social security numbers. Your grep command would look like3:
grep -rl "[[:digit:]]\{3\}[-,[: space:]]\?[[:digit:]]\{2\}[-,[: space:]]\?[[:digit:]]\{4\}" / > files-to-triage
In this command, we are recursively (-r) looking for any file that has nine digits in a row, with or without delimiters, and listing those filenames (-l) into a file called files-to-triage. After doing some test runs with this, I discovered that this will match quite a few files that do not have any of this data, but I think I could filter those out pretty quickly.
What if you wanted to look for stray cardholder data? To find most variations of valid cardholder data (apologies if I missed any) that would occur in a solid string of numbers or blocks of four separated by dashes or spaces, you would type:
grep -rl "\(\(4[[: digit:]]\{3\}\)\|\(5[1-5][[: digit:]]\{2\}\)\|\(6011\)\)[-,[: space:]]\?[[:digit:]]\{4\}[-,[: space:]]\?[[:digit:]]\{4\}[-,[: space:]]\?[[:digit:]]\{4\}\|3[4,7][[: digit:]]\{13\}\|3[0,6,8][[: digit:]]\{12\}" / | mail -s "Sensitive Data Report for `uname -a`" sensitive_data_reporting@company.com
This is what it looks like to write a regular expression that will search for most known types of credit card data. Regular expressions look like a work of art when viewed by the trained eye, but like hieroglyphics for the rest of us.
But what is that new fancy piece on the end? Say you wanted to run this regularly and email it to a report gathering mailbox. Provided your server has the mail program installed and its communication with a mail server is not blocked by firewall rules, this may be possible.
The automation can get pretty sophisticated from here. You could enhance the regular expression more or further parse the output to remove false positives, have the information dropped into a database or aggregate report on a daily basis with scripts, or simply just run it on a schedule from cron.
Now keep in mind, this is not a foolproof approach, nor the most efficient way to search for these types of data. There are several commercial packages on the market today to choose from that will do what you see above, and much more. But if you are looking for a starting point to see if you have a problem, using open source tools like Grep can be a cost-efficient way to see how deep the hole really goes.
____________________________________________________
1 http://www.gnu.org/software/grep
2 To do this, you need to use 'zgrep'.
3 You may have slight syntax differences in your regular expressions. Non-maintained versions of operating systems need not apply.
See part 1 here, part 2 here, part 3 here.
The Funniest Controls that You Didn't Design
Some of my most cherished stories and experiences come from customers and vendors that had the right intentions, but never seemed to follow the basic doctrines listed above on how good compensating controls are made9.
During my career I did some IT auditing for a bank that was owned by my employer. I know the drill of responding to auditor findings. They usually start with a meeting bringing all the key stakeholders together, a spreadsheet listing all the findings, and lots of grumbling about how picky "those damn auditors" are. Once the findings are separated out in the legitimate and ridiculous piles10, the ridiculous ones are assigned to experts to push back on the auditors. "We don't need that control because of a control over here," or "This gap does not apply to our environment," are common phrases uttered in the next round of meetings with said auditors. After all of that, a happy (potentially unhappy) medium is established, and we close out the audit.
The same process is often applied to PCI, and the compensating control Cha Cha commences.
Before I poke fun at the following examples, please understand that I am only illustrating a point. At no time were these suggestions made by people who didn't understand both the requirement, and the capabilities of the technology in question. These people were professionals; and based on their credentials and experience, they should have known better.
Encryption has always been a hotly debated topic from the early "Just Do It"® message that was pounded into our heads, to the cooler-headed "Slow down, it's a mainframe" axiom that we live by today. My favorite failed compensating control for Requirement 3.4 comes from a vendor who missed the last ferry off Gola Island. I received a call from this vendor late one afternoon and listened to their product team try to convince me that RAID-5 was essentially an equivalent to encryption. Their argument was that because you could not take any one drive and reconstruct useful data that could be considered compromise worthy, their product should be considered valid to sell to companies as encryption.
Right.
So if one drive (probably damaged) falls off of a truck during transport, the technology does prevent someone from reconstructing all the data that was on that system. If the system was large enough, chances are that the data on the drive may not provide any use to nefarious individuals either. But that's not really the goal of the requirement, is it? Physical theft prevention is covered in other areas of the standard. The point of the requirement is to render the data unreadable anywhere that it is stored. RAID may render the data unreadable on one physical drive, but it does not render it unreadable in any other circumstance. A simple compromise of one area of the system could lead to the access and theft of massive amounts of unencrypted data.
Speaking of encryption, disk only encryption inside data centers is not very useful either, unless additional user credentials are tied to the decryption process. Another favorite was a vendor that offered PCI compliance through an encryption appliance that was completely transparent to the operating system. So basically, you were only protecting the data as it sat on disk, in a secured facility, with gates, cameras, and Buck, the not-so-friendly security guard that looks like a hiring manager gave a night shift and a taser to the ex-bouncer of a strip club. If applications sat on disk drives housed in the unlocked part of a post office, then I could see the value here. Until then, the solution only focuses on the physical media and nothing else.
Encryption is really not the big problem with Requirement 3, key management is. Once companies figure out that encryption technologies are available for their platforms, they realize that key generation and management is a whole different problem. One vendor who apparently thought I had already checked out for the weekend make a case for using the COBOL Random Number Generator (RNG) to spit out sixteen digits (technically 128 bits of data) to use as an encryption key.
Yes, you are trying to be random and you will end up with a 128-bit key. But seriously, anyone with a basic knowledge of encryption will quickly find the problem with that approach. Not that COBOL's RNG is less than R, but that you have eliminated a giant section of possible key space! A 128-bit key generated in that manner is the equivalent of (approx.) 53 bits of encryption, thus making it computationally feasible to brute force that key11.
Look for Part 5 on Monday!
_______________________________________
9 By the way, if you read this and think, 'Hey! He is talking about ME!?', I'm not. I promise.
10 As defined by the assembled gallery of legumes. It's OK, I was one of the nuttiest in my time.
11 50 computers could do it in less than one year.
I'll admit, I'm not the insomniac whose brain refuses to shut down because of something like a skimmer. They do scare me. Less from a personal liability perspective and more from a corporate liability perspective.
Have you ever seen a real-life example of an ATM that has been doctored with a skimmer? Today is your lucky day! One Gizmodo reader submitted his pictures and story.
Maybe I'm crazy, and maybe it's just not that big of a deal anymore. The bad guys are getting very crafty now, and able to fit skimmers to specific ATM models. It used to be that if you used an ATM regularly, it would be very easy to tell if someone had tampered with it. Stray wires, duct tape (NOT DUCK TAPE), odd cameras or mirrors, all of which should be red flags to any user of that magical machine that makes you feel like you win every time you play with it!
Remember those old "fake ATMs" that were essentially just big skimming devices? I think many of us became wary of the generic ATM machine in a parking lot after that. But we're not talking about that here. We're talking about the ATM near your house that you visit every week, and you may not even be able to detect it!
At a minimum I would suggest that you disable the ability to withdraw funds from anything but a checking account from an ATM. Hopefully that should at least minimize the amount of money you would be out if you fell victim to such an attack. Any more suggestions than what is above might stray into the personal finance realm, and I'll let those guys blog about that!
See part 1 here, part 2 here.
What a Compensating Control Is Not
Compensating controls are not a short cut to compliance. In reality, most compensating controls are actually harder to do and cost more money in the long run than actually fixing or addressing the original issue or vulnerability.
Imagine walking into a meeting with a customer that has an open, flat network, with no encryption anywhere to be found (including on their wireless network which is not segmented either)7. Now imagine someone in internal audit telling you not to worry because they would just get some compensating controls. Finally, imagine they tell you this in the same voice and tone as if they were going down to the local drug store to pick up a case of compensating controls on aisle five. I don't have to make this stuff up, I get paid to listen to it!
Compensating controls were never meant to be a permanent solution for a compliance gap. Encryption requirements on large systems were made unreasonable early in this decade. Not only was there limited availability of commercial off-the-shelf software, but it was prohibitively expensive to implement. For Requirement 3.4 (Render PAN, at minimum, unreadable anywhere it is stored), card brands (largely Visa at the time) were quick to point out that compensating controls could be implemented for this requirement; one of those being strong access controls on large systems.
For mainframes, assessors would typically do a cursory walk through the controls and continue to recommend an encryption solution at some point for those systems. At one point, compensating controls were deemed to have a lifespan; meaning that the lack of encryption on a mainframe would only be accepted for a certain period of time. After that, companies would need to put encryption strategies in place.
Compensating control life spans never materialized. Compensating controls can be used for nearly every single requirement in the DSS--the most notable exception being permissible storage of sensitive authentication data after authorization. There are many requirements that commonly show up on compensating control worksheets; Requirement 3.4 being one of them.
Even with no defined life span, compensating controls are not an eternal free pass. Part of the process during every annual assessment is to review all compensating controls to ensure that they meet the four requirements as currently defined by the PCI Security Standards Council8, the original business or technological constraint still exists, and it proves to be effective in the current security threat landscape. If certain types of attacks are on the rise and a certain compensating control is not effective in resisting those attacks, it may not be considered OK on your next assessment.
To further cloud the situation, it is up to the QSA performing the assessment to decide to accept the control initially, but the Acquiring Bank (for merchants) has the final say. Substantial documentation and an open channel of communication to your acquirer is essential to ensure money is not wasted putting together controls that ultimately do not pass muster.
Don't get discouraged, though! Compensating controls are still a viable path to compliance even considering the list of reasons why you may not want to use them.
I would not be a true security professional if I didn't have a fun story or two based on my experiences coaching companies or individuals to better security. No names will be used, and I'm going to change enough details to protect those who were most likely being forced to try the old "Push Back on the Auditor" routine. I hope you enjoy reading them as much as I enjoyed listening to them.
Look for Part 4 on Wednesday!
_______________________________________
7 While it is not a requirement to segment your network, it does make compliance easier. Usually in this situation, I find a legacy system that cannot be patched or upgraded, but now becomes in scope. Then the conversation about compensating controls starts.
8 Remember, the requirements can change between versions of the standard.
My link seems to have disappeared from the right, so I'll just add it here! Follow me on Twitter at http://www.twitter.com/BrandenWilliams! I'll be tweeting from RSA in two weeks!
Did you miss the super-duper, fantsmoriffic webinar that we did with Forrester? If you were not one of the more than 300 attendees, don't worry! The webcast was recorded, and can now be viewed online!
Check it out at http://www.iian.ibeam.com/events/nrfe001/30288/!
Have you seen it? OWASP recently released their Code Review Guide to the general public for download! I'm very happy to say that one of our own consultants was a contributing author, Jenelle (Chapman) Davis!
This book goes through the basics of preparing for a review, understanding how threats may present themselves, to the more advanced topics of reviewing code for technical controls, to even giving suggestions for common languages or platforms on where to start. If you are interested in code review, you should understand the concepts in this book at a minimum. Slowly, but surely, we're starting to see more and more information be made available on this topic, and hopefully this will begin to spread around the desire for this type of service.
See part 1 here.
What a Compensating Control Is
In the early years of PCI DSS (and even my experience under the CISP program), the term compensating control was used to describe everything from a legitimate work-around for a security challenge to something that Michael Phelps may have dreamed up while expanding his mind at approximately twenty minutes after four in the afternoon4.
If you are considering a compensating control, you must perform a risk analysis and have a legitimate technological or documented business constraint before you even go to the next step. We will see more of the documented business constraints coming our way for review based on the current economic situation. Just remember the word legitimate and the phrase perform a risk analysis before proceeding to the next step. 'Bob' being on vacation is not a legitimate constraint, and an armchair review of the gap and potential control is not a risk analysis. Qualified Security Assessors (QSAs) should ask for documentation during a compliance review, and having it ready to go will make sure you are efficiently using their time. If they do not, you can bet that your assessment is not thorough.
Every compensating control must meet four criteria before it can be considered for validity. The four items that every compensating control must do are: meet the intent and rigor of the original PCI DSS requirement, provide a similar level of defense as the original PCI DSS requirement, be "above and beyond" other PCI DSS requirements, and be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement5. If you think compensating controls are easy, please re-read the above statement.
The compensating control polygon has four specific points that must be met. For a compensating control to be valid, it must:An example of a valid control might be using extra logs for the su command in UNIX to track actions executed under a shared root password. In rare cases, a system may not be able to use something like sudo to prevent shared administrator passwords from being used6.For an example of a completed compensating control, review the Appendix C of PCI Version 1.2.
- Meet the intent and rigor of the original PCI DSS requirement;
- Provide a similar level of defense as the original PCI DSS requirement;
- Be "above and beyond" other PCI DSS requirements (not simply in compliance with other PCI DSS requirements); and
- Be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement.
Look for Part 3 on Monday!
_______________________________________
4 Aww... too soon?
5 As described in the PCI Security Standards Glossary: https://www.pcisecuritystandards.org/pdfs/pci_dss_glossary.pdf.
6 If you are reading this and saying, "HEY! We CAN just use shared passwords!" please grow up. Nearly every system has the ability to use something like sudo which is free, or a commercial variant.
Kotaku recently reported that a cache of Xbox 360s and PlayStation 3s offloaded to Circuit City has tons of fun data on them. Smaller merchants are buying these things for pennies on the dollar in hopes to resell them for a profit in their stores. I've heard that these things are everywhere!
Folks, don't forget, that every one of these devices that you plug into the wall or has a battery is basically a computer. Sure, it may not be the one that you are reading this post on, but it is a scaled down version of the same technology.
You know that VOIP phone sitting on your desk? Yep, a computer. Aside from the data security issues associated with outdated or known vulnerable software, there is data on that thing. How long it lives, or what it stores depends on the device. Sure, my Wii only has my family's Miis on it and the code to my wireless network. But not the REAL wireless network, a DMZ one that I let all my security unconscious family and friends use. There is nothing in the 242 or so data units on the device that I would not be ashamed of posting here in this blog.
Can you say the same for your computing devices?
If not, then BE SURE to destroy all of the data on the device before handing it over. For appliances or self contained units such as TiVos or PS3s, you will void the warranty by sanitizing the drive, but if you are disposing of it, you probably were out of warranty anyway.
Regardless, hard drives are cheap right now, so using the super destructo method of a big magnet or a commercial shredder certainly becomes a more reasonable solution!
Few payment security professionals can find a hotter topic than compensating controls. They always look like this mythical accelerator to compliance used to push PCI Compliance initiatives through completion at a minimal cost to your company with little or no effort.
Sound familiar?
I wish I had a tape recorder at every meeting where I heard the phrase, "Don't worry, we'll just write up a compensating control for this." It may not be as great as the twenty-seven minute long video floating around of every single expletive uttered during The Soprano's legendary run on HBO1, but I bet I could fill a few podcasts with the audio.
Compensating controls are challenging. They often require a risk-based approach that can vary greatly from one Qualified Security Assessor (QSA) to another2. There is no guarantee a compensating control that works today will work one year from now, and the evolution of the standard itself could render a previous control invalid.
My goal for this article is to paint a compensating control mural. After reading this article, you should know how to create a compensating control, what situations may or may not be appropriate for compensating controls, and what land mines you must avoid as you lean on these controls to achieve compliance with the Payment Card Industry Data Security Standard (PCI DSS)3.
Look for Part 2 on Wednesday!
_______________________________________
1 How impressive is twenty-seven minutes? Seriously!
2 Why? Because we are not provided a common risk model to use.
3 Please visit http://www.pcisecuritystandards.org/.
It's been a few days now, and the dust is still settling as they say. Anton Chuvakin posted some great thoughts on the hearing, including one that I TOTALLY missed.
In Mr. Jones's1 defense, the site that has the XSS error in it MAY NOT be in scope for PCI depending on where code base lies, but regardless, the vulnerability is inexcusable from a guy talking to Congress about this stuff.
I fired the info around to some of our consultants and had a couple of responses of note.
James, a Consulting Manager in our group says (I am paraphrasing some of this):
The contention that PCI forces retailers to stray from their core competency of retail seems to be misleading. Small Level 4 merchants certainly do not have IT security backgrounds, let alone resources, but they also usually have small to nonexistent systems to protect. The core target of PCI, large Level 1 brick and mortars and prominent e-commerce portals, rely on IT excellence for operational efficiency and have long disenfranchised security efforts to the detriment of the consumer. The competency at maintaining systems securely should grow with the corporation and can be achieved without disrupting the "core competency.
James makes a good point here... From a sheer numbers game, level 4 retailers outpace any other group in the number of compromises. Of course, it's not hard when you have seven million counterparts in your group. But when you look at the number of records compromised, the big retailers are the ones that have exposed the most... probably! I just did a little quick math and that assumption requires big ticket breaches to continue to happen.
Regardless, James points out that security should exist as a partnership between technology, human resources, and the business to allow the enterprise to grow securely.
James also points out that "Mr. Lungren seems to have a lot of bad luck when paying for meals. Make sure you bring an extra credit card if dining with him."
One final thing that we in the industry deal with every day. James says:
I think Ms. Clarke may be jumping on the "PCI does not equal secure" bandwagon a tad bit late. We've all been in enough conference rooms where the "above and beyond the PCI standard" does not exist.
Frank, a Sr. Consulting Manager in our group says:
Main point: PCI is a baseline that prevents most breaches, and in all cases to-date, no compliant entity has ever been breached. Counterpoint: ambiguity in the standard and/or interpretation by a QSA leads to differing opinions on applying the standard. Folks, SQL injection vulnerability on an external website is a no-no, and should have been found at multiple checkpoints of the DSS, no matter what shade of rose is on your glasses.
shaZAM! Of course he's absolutely right. Setting the standard aside, vulnerabilities like that should be found and fixed using standard security practices.
He concludes his thoughts with this nugget:
End-end encryption is NOT a silver bullet. If hackers have full access to the internal PCI network, then they have the opportunity to attack the encryption methods as well. We all know that merchants extract information from the authorization process, and would need de-encryption mid-stream to maintain their data warehouse appetites.
As a marketing guy by training, I can tell you that there is value in certain types of data that might fly through the various flows that merchants use. What is going to happen if retailers adopt end-to-end encryption? Will the marketing guys get creative and find a way around the control? Maybe the newest reincarnation of the write-my-complex-password-down-on-a-postie-and-stick-it-under-my-desk-because-no-one-will-look-there workaround?
Time will tell!
Anyway, I hope you all enjoyed the briefing as much as I did!
OH! And we had a small "holiday" this week, April Fools Day! Here's a GREAT roundup of the most popular pranks. The Opera face gestures is exceptionally hilarious, and I can see lots of HR incidents getting started over innocently opening a speed dial.
__________________________________________
1 CMS 7.18. Look it up.
It's April, and what does that mean? It's time for ISSA's 2009 PCI issue! The feature article for that issue, is The Art of the Compensating Control. You can download this version from the website, even if you are not a member, at http://www.issa.org/Members/Journal.html for the rest of the month. If you are reading this after April 2009 and want a copy, let me know.
You readers of the blog are going to get a special treat! The original article was much more casual and entertaining than what we ended up publishing in the Journal. Thom reviewed the first final draft of the article and said that it was much too casual. He was absolutely right. I can't tell you what a joy it is to have a fantastic editor working on your behalf to make sure the best possible quality product is published.
Wait, something's missing. I said you are in for a special treat and all I did was gush over my editor... hrm... what was that treat....
OH YES! I will be posting the original, un-cut, un-censored article RIGHT HERE on the blog over the next few weeks! The original article will be broken into six individual posts that will be put on this blog every Monday and Wednesday for the next three weeks starting on April 6. By the end, I'll have a link to both versions of the article for your downloading pleasure!
I hope you enjoy reading it as much as I enjoyed writing it!
I got a few comments yesterday that made me think that some of you have the wrong idea. OK, I admit, the EDI/CIO comment I made yesterday morning was over the top, and as an act of contrition, I will tell you that yesterday I was told not to wear a shiny shirt, suit, or shoes to a particular customer because their CIO didn't like shiny consultants. My shirt was quite shiny. Something that would have been helpful to know before I packed. DOH.
Before I go any further, I do realize this is April Fools Day. What you are about to read is NOT an April Fools joke. To help illustrate that point, you won't see any backhanded complements here, just the front hand kind!
I love Dave Hogan, CIO of the National Retail Federation. Sure, I pick on him, and have published rants on several occasions here in this blog--dating back to my first reaction to the NRF's CIO from a 60 Minutes broadcast in November of 2007. It's not exactly like the playground love I felt when pushing down Lisa Duffy at recess. More like your beer buddy that only gives you a hard time when you spend all day complaining about guys that buy fast cars, drive them with the top down during winter just because they can, and then I go buy one and do the same thing, and James calls me on it while visiting a local watering hole in February. It's that kind of love. Beer buddy love? I may be on to something.
Let me clarify that I've never met Mr. Hogan. I once sat in a room with him in Brussels, but after the session ended, both of us had folks around us that wanted to chat and I lost him in the crowd. I wanted to meet him face to face, but didn't get the opportunity.
So why do I love Dave? Well for one, he has the testicular fortitude to stand up and voice his opinion against what many believe is a conspiracy against merchants. There are not too many others, including the competing retail organization, that take the same stance that he does in such a public fashion. The guy has cojones, and he should be celebrated for it.
I love Dave because he gives me something to write about. Agree or disagree, he plants a flag out in the PCI pasture and it's up you to to decide to run toward it, or plow over it. In a world of people who refuse to accept accountability for their actions, litigate their way out of trouble, play the blame game cause NOTHING is EVER their fault, and are publicly moderates even though they are privately extremists, how great is it that you know EXACTLY how Dave feels about the issues he talks about? If nothing else, he's consistent. The same message that prompted me to write that blog post late one Sunday evening after watching football was conveyed in the congressional hearing on PCI yesterday. Regardless if you agree with the points, he lays them out and lets you do with them what you will.
Finally, I love Dave because deep down, he really is looking out for the little guy. I've been a part of small companies. My first experience being the little guy was a two man company back in 1996. We were competing against the big guys--and winning. But as we grew, we quickly realized that the big guys had much more ability to react to us than we had to react to them. So we gracefully exited and sold two years later. So from one little guy to another, it is great to have someone standing up for you and trying to make things better.
Dave has good intentions. He is trying to make things better and he doesn't mind ruffling a few feathers in the process. One of these days, should we be in the same city, I would LOVE to chat about our differing viewpoints and offer as much help as I can to him and his constituents. After all, I'm not too unlike Dave in that I like to help people win, especially the little guy!
How about a round of applause for Dave!
