Over the last few years, card brand executives have implied that the PCI standards are the ‘Holy Grail’ and that only by following these standards can cardholder data be protected. To add insult to injury, the House of Representatives’ Subcommittee on Emerging Threats, Cybersecurity, and Science and Technology held hearings on the PCI DSS and its ineffectiveness in stopping terrorism funding. In the end, all of this bluster just added fuel to the fire around security and in particular cardholder data security.
What all of these people have missed is that regardless of whatever security standard you follow, sensitive data, cardholder or otherwise, is always at risk. There will always be a market for private information and there will always be someone willing to take the risk to obtain that information, regardless of the barriers put in their way. If they want you, they will get you.
Do not believe this to be true? Over a week ago, it was announced that HBGary Federal, an obscure subsidiary of Internet security firm HBGary, was attacked by “Anonymous” and their internal emails and other documents were posted on the Internet. To add insult to injury, Twitter and LinkedIn accounts were also compromised and postings were made under those compromised accounts. But the most embarrassing thing about this was that the documents posted showed that HBGary Federal is in the business of corporate espionage and discrediting corporate rivals.
What the HBGary incident highlights is how different a dedicated attacker is from your everyday, annoying attacker. Dedicated attackers are hunters. They research their prey conducting detail reconnaissance of their target. They know about the defenses of their target and they develop plans to defeat those defenses or at least keep them at bay. These are people skilled in their craft. These are people that take a job as part of the night cleaning staff at the building where their prey is located. They use this as an opportunity to scope out their quarry and determine where the weaknesses are located. If they need other expertise, they will go and acquire that expertise either through training or by teaming with someone that has that expertise. In the end, if they want you, they will get you.
And that is where the ‘Holy Grail’ status falls apart. Security relies on human beings either to configure, manage or monitor the process. Unfortunately, humans make mistakes either deliberately or accidentally. It is those mistakes that more times than not create the problems the result in breaches. Decisions are made to short cut a process to save time. Alerts or warning messages are ignored because they always are generated. Commands are mis-keyed resulting in an unforeseen configuration change that opens a hole. Whatever it is, mistakes occur and sometimes organizations pay the price.
The late David Taylor at PCI Knowledge Base was quoted as saying, “It’s easy to find somebody to be in noncompliance if that is the primary goal.” What Mr. Taylor is pointing out is that ‘witch-hunts’ are always successful given enough resources. No matter how well you think your organization is run, there are always enough ‘rocks’ that can be turned over to reveal a less compliant side of the organization. Forensic examinations are looking at the underside of all of those ‘rocks’ to determine which ones resulted in the breach.
Unfortunately, for most organizations, the forensic process becomes a witch-hunt because the media and public demand it. Why? Because thanks to the card brands and the PCI SSC holding out the PCI DSS as the ‘Holy Grail’, the public’s expectation is that a breach should never happened. That is not the message that should be being delivered.
What the card brands need to do is explain to the public the actual realities of the PCI standards. Particularly the fact that even if the PCI standards are followed, breaches are still going to occur. Now those breaches that occur should be much smaller and less costly, but they are still going to occur. That is the stark reality of security because, as I know some of you are tired of hearing, security is not perfect.
UPDATE: After the comments I have received, I want to clarify this point. I am not suggesting that security is a worthless endeavor because it is not and cannot be made perfect. Security is a necessary activity that all organizations need to participate in at some level. What people need to realize is that security is not perfect, it will stop the great majority of incidents if properly implemented and managed, but it will not stop everything. The problem is that there are sales and marketing types, as well as security “experts” that imply that their solutions or ideas will result in a “perfect” solution. It is these things that concern me because the unknowing believe that they are absolutely protected and then are dumbfounded when an incident occurs and then blame the security industry for misleading them.
PCI Guru 
There’s a valuable point in there, in essence that being 100% breach proof is an unattainable goal. Still, I’m not comfortable with the oversimplification that “if they want to get in, they will”. It is a true statement, but with qualifiers. Who is ‘they’, have you developed a security architecture where the only ‘they’ that will get in is an advanced attacker or team of attackers who will expend significant resources (time) to break in? Will every step of the penetration be a pain for them? Will the incident response (which you mention as forensics) be effective?
If the answers are yes, then you’ve probably done your job. If you throw your hands up and say “anyone will get in, there’s nothing I can do”, then the ‘they’ becomes anyone at any technical sophistication level with time on their hands.
I don’t know that the HB Gary example proves the point, they used a third party programmed CMS that was not a common platform, was hosted where penetration led to further access to sensitive systems, and the attack was a straightforward SQL injection (then again, that was what worked against Heartland, PCI’s most famous case).
Regardless, as I said, I think you’re making a valuable point, especially in the face of others who have stated things to the effect of “a PCI compliant firm has never been hacked”. PCI has its place and value, making you bulletproof isn’t part of the equation.
On an unrelated note, it is trivially simple to determine who you are, so having the blog be anonymous may not be worthwhile in the long run.
“On an unrelated note, it is trivially simple to determine who you are, …” If you read the “about” page, that is the whole point of the Stanley Bing reference. Stanley Bing’s real identity is also an open secret. When this started out, my employer was not supportive of blogging. As a result, I decided it might be in my best interest to shield my identity, but not be totally secretive. As time has gone on, my Firm’s attitude on blogging has changed and they now even have blogs on their Web site. However, since I have developed a following here, I am keeping my blog under the PCI Guru moniker until they ask me to move it to the corporate Web site.
I call it the 98-2 rule, patterned after the 80-20 rule. As I define it, security standards and “best practices” are going to stop 98% of attacks. However, there are 2% of the attackers that are going to do whatever it takes to get around your security measures. It is that 2% that are going to have the potential of creating a breach and it just doesn’t matter how good or robust your security is, they will be successful because they intend on being successful. The good news about that 2% is that, based on security statistics from Trustwave, Verizon, CSI, etc., they typically come around to an organization only once in about every two to three years. The bad news is that when they do happen, they cause real chaos and problems. Hence why you need an good, tried and true incident response plan so that you minimize their impact.
What are your recommendations on the control execution and testing frequency? As we all know, some of the companies get PCIDSS certificate and once the QSA is gone, PCIDSS falls apart. So what’s the best way of ensuring that all controls are executed according to standards all the time and how often should they be tested. The goal is not only to test once just before QSA is coming onsite. Should we assign control execution and testing frequency to each control?
There is no rule of thumb for this sort of thing. It is up to each organization to determine what actions they need to take to ensure that controls remain effective. Some need to have controls overseen and reviewed daily and other controls can be reviewed weekly, monthly or even quarterly. A lot depends on how often exceptions occur. We recommend that baselines be developed and based on how often exceptions are seen, review processes are set accordingly. So, if daily exceptions are regularly seen, I would say you would want to review that control no less than weekly and possibly daily (if it is frequently out of compliance) so that it does not get out of compliance too often.
Hope this helps.
Yes it did help. Building the program from ground up, so wanted to know if there are any best practices. So this really helps. The goal is to build something that can be maintained at all times and yields consistent evidence…
I would agree that usually there’s always a weak point – that’s why a layered approach is necessary. And yes, many times there is an weak link in it all – people… we make mistakes. Now a layered approach should help with this – but if only new holes are added and the old ones are enver fixed – sooner or later it will be one gigantic openning for the bad guys.
As I understand it – the HBGary thing resulted from bad passwords, poor encryption, and social engineering. If anything – I think it shows the weakness in humans and how even though we know what will create stronger/better security – we don’t always practice what we preach. When comparing it to the PCI DSS – I think it should show us that just going through with a checkbox mentality is going to hurt us in the long run. It shows the importance of security policies and enforcing them. It shows the importance of employee education and being sure to have a layered defense to help protect you should one area fail. Yes – a breach is always possible… but some are MUCH harder to pull off than others. That’s how the PCI DSS helps – it doesn’t prevent the possibility of a breach, it lessens the odds. The more someone has to work at it – the more likely they are to go looking for an easier target if all they’re looking for is a profit… now if it’s personal (like the HBGary incident), then odds are they’ll keep trying – which is why we need to be more proactive than reactive so that we can stop them from taking anything valuable when they do get past our main gates. Again – I believe that’s where the PCI SSC wants us to be. No, it’s not perfect – but if people used it for a base line instead of their maximum, we’d all be much better off.
But that is exactly the problem. There are very few people explaining the fact that breaches will still occur. There is this mistaken belief that breaches will stop and that is just not the case. The card brands and the PCI SSC are doing a disservice by not explaining to merchants and the public that the PCI standards only minimize the risk of a breach, not get rid of it entirely.
In regards to the HBGary episode, it doesn’t matter the ease, it was that “Anonymous” went to the necessary measures to make that breach happen. We will likely never know the extent of the research “Anonymous” went to get HBGary Federal. However, once you have a key, you usually can get the other keys relatively easy.
The PCI SSC says, “PCI DSS provides a baseline of technical and operational requirements
cardholder data… PCI DSS comprises a minimum set of requirements for protecting cardholder data, and may be enhanced by additional controls and practices to further mitigate risks… Secure payment applications, when implemented in a PCI DSS-compliant environment, will minimize the potential for security breaches…Compliance with the Payment Card Industry (PCI) Data Security Standard (DSS) helps to alleviate these
vulnerabilities and protect cardholder data…You’ll need to continuously assess your operations…”
I haven’t seen anywhere that the PCI SSC has said that the DSS protects you from a breach 100% – they say it is a miniminum of requirements that help, that it minimizes the risk, and helps alleviate the vulnerabilities, etc. They also say that it’s a continual thing, yet many people think it’s only a once a yr assessment. If they flat out say that the requirements get rid of the risk entirely, I’d love to know where that is.
I believe that thought process comes from the merchants and other’s who see the DSS as not the baseline, but all that they have to do – they’re max. Add that opinion to the fact that it’s required, and well you want to justify why it’s required don’t you? It’s pretty easy to take words out of context and believe what you want to.
It is not documented anywhere in the PCI DSS, it is implied in the statements made by card brand executives and representatives of some service providers’ executives to Congress and media outlets. As a result, merchants and the like get the impression that the PCI standards will stop breaches.