If you've been following any of the recent PCI (Payment Card Industry) breaches, you'll see two trends coming from the breached organization. One one hand, they'll say that the PCI standard is flawed since it they were compliant and still got hacked. On the other hand, they'll say the problem was their QSA (Qualified Security Assessor) messed up. Although both the standard could be better and a QSA can be more thorough, it's time for organizations to stop passing the buck and admit that they screwed up.
Now I understand that there are certainly differences of quality in each QSA. I've seen everything from rubberstamped reports that make you wonder if the QSA can spell 'PCI' to a tinfoil hat QSA who uses the standard to create new, crazy requirements. But in the end, I sometimes wonder if the organizations understand truly what makes a good QSA and what their role is. Ultimately, the QSA is supposed to be an auditor (yes, I know technically we are 'assessors'). That means the QSA is trying to make sure the processes the organization established are working properly. In order to do that, the QSA needs to typically sample the controls and do some digging around. This should allow the QSA to determine that the control is generally operating correctly. However, the QSA is NOT the master of the organization's destiny for security. Heck, the audit is only once a year and cannot turn over every stone. The organization owns and is responsible for the processes, the controls, monitoring, and reacting. If they break down, that is the organization's problem.
Now as far as the standard goes, I hear a lot of people (generally non-QSA) stating that the PCI DSS is flawed. First of all, let's just understand that this was written to push compliance, not security, to a certain level since it was severely lacking in most organizations. Just to be clear, compliance is just a hurdle and not a ceiling. What I don't understand is then what other framework or compliance is better than PCI? For example, ISO 27001 is still too general and based on business decisions. The standard is still the most thorough, prescriptive, and layered one out there. This is not only for the controls within it but also the testing. For example, testing applies both externally and internally and escalates from scans, to pentests, and even web app reviews. For all the naysayers out there, I'd love to see a better version from them. Remember, PCI was the first and still the onyl one out there that has pushed hard for web application security such as the OWASP Top 10. Now for those who think the standard isn't detailed enough, give me a break. It isn't going to tell you exactly how to do X with product Y in a Z architecture. There are just too many variables.
So let's look at the latest details on the big breaches (http://www.wired.com/threatlevel/2009/08/tjx-hacker-charged-with-heartland/ ). Now we are finally starting to get enough details to understand what happened. Let's go with the assumption that the downfall to Heartland/Hannaford was SQL injection and see where the problem hypothetically is. Well the standard clearly states that it needs to be properly coded in requirements 6.5.2. Keep in mind that a QSA will not and may not even be able to review all your code. Oh yeah, that is the organization's requirement in 6.3.7. This also needs further tested through a web application review (possible third party problem) or prevented through a web application firewall (organization's problem) in 6.6. Not to mention that this would or should be detected during the vulnerability scanning (ASV problem) and penetration testing (probably third party problem) from requirements 11.2 and 11.3. So how exactly did the standard fail here when there are at so many layers of controls and testing designed to stop this?
This brings me back to yet another ranting point. It is unbelievable the number of organizations who are constantly trying to find the absolute cheapest vendor for any of the stuff we just discussed including the QSA, the ASV, and other testing. There is little going into understanding the quality or qualifications of the vendors being selected by the organization. This absolutely leads to 'getting what you pay' for quite a bit. But just remember, that is a choice of the organization to pick a deficient vendor.
We also need to realize that even if SQL injection had worked, there were still plenty of other controls within PCI that could have stopped the breach. First of all, there is a anti-malware requirement. Yes, I know that only recently was it clearly required for all platforms, not just those 'commonly affected'. But we have seen Linux malware and it's supported by all commercial anti-virus vendors and even free ones. So did the organization just not do it because it wasn't clearly dictated as a hurdle within the standard? I guess so. There is also a requirement to restrict firewall traffic both inbound AND outbound. So why was the malware allowed to talk to the internet from payment systems? There is no good business reason there. So the standard certainly isn't as flawed as people want to assert, though there it could be improved.
In the end, we certainly can conclude a few things. First of all, despite the fact that these organizations had been assessed as compliant, the organizations clearly were not compliant. Though it is possible that a QSA missed something, that is still the organization's problem. Also, the standard cannot be perfect but it is very well built and, if followed, would have stopped these. In security, like any process, it may only take one flaw for a breach to occur - even if that was the standard or the QSA. But that's why security has to be layered and has to be based on quality, not compliance. Regardless, the whole security process is owned by the organization and they need to take responsibility when it breaks. Passing the buck doesn't undo the breach, but does make for some interesting blamestorming to watch.
Read more!
Showing posts with label heartland. Show all posts
Showing posts with label heartland. Show all posts
Monday, August 17, 2009
Wednesday, March 25, 2009
Let's Get Ready to PCI Rumble!
I know this is going to sound kind of sad, but I am really excited to see what's going to happen with some of the latest PCI breaches and the organization's response. In the two the biggest, latest ones we see both Hannaford and Heartland stating their case that they were both PCI compliant. To the average person, the initial response is going to be something like, "Then the PCI DSS sucks!". However, a recent statement from a VISA exec was more along the lines of "We have yet to see a company that was breached that was compliant." So how do we judge this wrestling match?
First and foremost, we need to make a clear distinction about what it means to be PCI compliant. The position being taken by the the organizations above needs clarified. What they mean is that they had successfully completed their compliance validation activities. More specifically, that means they had their audit performed and submitted it along with the ASV scans. They met their due diligence obligation.
But now we need to reconcile that with the execs position. What he was talking about is more akin to PCI Safe Harbor. That states a company is 'safe' if they are fully compliant to the PCI DSS at the time of the breach and can be demonstrated during an audit with forensics. That, my friend, ain't easy. Compliance is something you will ultimately have to defend and is not the plaque or certificate on the wall for you did once a year.
So now we need to actually do some sort of prognostication here so you get my point. I don't have all the details for either breach, so I will make some assumptions. Let's assume both of them were breached due to malware on a system. I'll also assume they had anti-malware in place. What isn't an assumption is if it's possible to bypass malware. So I am going to assume is it did get bypassed. I am not sure if we'll know how the malware got there. Did that portion of PCI fail? Not at all. It's a good requirement and they did meet it. But PCI has many layers to it as all security programs should.
If I had to guess what will the final outcome is, it will be something like this. From what we know the big problem is that the data was breached i.e. it left their network. So just how did the data get into the hands of the the evildoers? I think that's the real question. Exactly what kind of firewall rules were in place that allowed the malware sniffers in place to send the traffic out of their network? Did the processor or the registers have direct access to the internet? I sure as heck hope not. If the attackers had some live connection into those systems, that's one thing. But I would suspect there is a lack of good egress filtering and not that the malware did some crazy cool method to bounce traffic out of their network. This kind of excessive egress would likely be caused by a lack of good process to reign in the poor rules adopted through "business justification". Personally, I think the business card trumps way too often as I have seen time and time again at clients.
So who is to blame here? I think an easy, but not necessarily correct, choice is the assessor. An auditor's job is to assure formalized, good processes and perform some testing as well. It may not be possible to audit every rule of every firewall. Even so, the auditor has to be pretty strong to push back when "business justification" has been established. It means possible rumbling with their client and their bank. But yes, the auditor may not have been thorough and some rubber stamping occurred here.
Well, only time will tell if I should quit security and become a psychic. Speaking of, my money is on the VISA exec to win the match. Even if I am wrong, there is some lessons learned here. In reality, there needs to be a strong, collaborative relationship between the auditor and the organization to both agree on a defensible position in gray or soft areas of the PCI DSS. I often say you need to imagine standing at the podium and feeling confident as you describe that position to reporters and the world. And never forget, compliance does not equal security. Business justification is not a loophole. Or if it is, a lot more can slip through that hole like malware and fines.
Read more!
First and foremost, we need to make a clear distinction about what it means to be PCI compliant. The position being taken by the the organizations above needs clarified. What they mean is that they had successfully completed their compliance validation activities. More specifically, that means they had their audit performed and submitted it along with the ASV scans. They met their due diligence obligation.
But now we need to reconcile that with the execs position. What he was talking about is more akin to PCI Safe Harbor. That states a company is 'safe' if they are fully compliant to the PCI DSS at the time of the breach and can be demonstrated during an audit with forensics. That, my friend, ain't easy. Compliance is something you will ultimately have to defend and is not the plaque or certificate on the wall for you did once a year.
So now we need to actually do some sort of prognostication here so you get my point. I don't have all the details for either breach, so I will make some assumptions. Let's assume both of them were breached due to malware on a system. I'll also assume they had anti-malware in place. What isn't an assumption is if it's possible to bypass malware. So I am going to assume is it did get bypassed. I am not sure if we'll know how the malware got there. Did that portion of PCI fail? Not at all. It's a good requirement and they did meet it. But PCI has many layers to it as all security programs should.
If I had to guess what will the final outcome is, it will be something like this. From what we know the big problem is that the data was breached i.e. it left their network. So just how did the data get into the hands of the the evildoers? I think that's the real question. Exactly what kind of firewall rules were in place that allowed the malware sniffers in place to send the traffic out of their network? Did the processor or the registers have direct access to the internet? I sure as heck hope not. If the attackers had some live connection into those systems, that's one thing. But I would suspect there is a lack of good egress filtering and not that the malware did some crazy cool method to bounce traffic out of their network. This kind of excessive egress would likely be caused by a lack of good process to reign in the poor rules adopted through "business justification". Personally, I think the business card trumps way too often as I have seen time and time again at clients.
So who is to blame here? I think an easy, but not necessarily correct, choice is the assessor. An auditor's job is to assure formalized, good processes and perform some testing as well. It may not be possible to audit every rule of every firewall. Even so, the auditor has to be pretty strong to push back when "business justification" has been established. It means possible rumbling with their client and their bank. But yes, the auditor may not have been thorough and some rubber stamping occurred here.
Well, only time will tell if I should quit security and become a psychic. Speaking of, my money is on the VISA exec to win the match. Even if I am wrong, there is some lessons learned here. In reality, there needs to be a strong, collaborative relationship between the auditor and the organization to both agree on a defensible position in gray or soft areas of the PCI DSS. I often say you need to imagine standing at the podium and feeling confident as you describe that position to reporters and the world. And never forget, compliance does not equal security. Business justification is not a loophole. Or if it is, a lot more can slip through that hole like malware and fines.
Read more!
Subscribe to:
Posts (Atom)
Posts
