I was directing all to Anton’s site here where he has done the most thorough analysis of what’s been posted on the Net about this breach. It’s worth having a look at his site. After TJX, I thought I was all talked out about these topics – for a while at least…..okay, it’s big but it’s all now becoming quite common and things like this will continue to happen due to poor on-going security practices, inherently insecure software etc etc. So is there more to say on that front that I haven’t talked/preached about in this blog for a number of years?
PCI DSS has copped quite a bit of criticism from many “experts” on the Net over the events at Heartland. I do understand why. There have been many against the standard from the outset and any breach/security issue in an organisation that is using PCI DSS as the framework for their security practices is going to have these people questioning the purpose and overall benefits of the standard. Read on…..
My view; PCI DSS has introduced good practice to many organisations that previously did little in regards to IT security and/or did IT security poorly. Anything that introduces better practices can only be a good thing! But nothing is perfect and nothing is totally secure. PCI DSS is a starting point but unless an organisation is committed to an ongoing focus on the protection of their data and information systems, they’re always going to be at greater risk. It’s all about that old saying; “minimising risk”. Had PCI DSS not been part of Heartland security practice, could things have been worse? (Can it be worse?). Did they minimise their risk? More than likely BUT….they just minimised their risk – they did not and could not eliminate the risk(s). Looking at this from a higher management level; The 7 Reasons why Business are Insecure. There’s more to it than just reliance on a standard – a standard is just one part of an overall Strategic Security Management Framework. (SSMF is my framework that we use with many organisations that we work with).
Did the QSA in Heartland’s case do enough? I don’t know. I do though know that many QSAs are not thorough and we see the results of their work regularly. We’ve seen so many organisations that are “PCI Compliant” and wonder how the hell they were passed. Only recently we talked with a large multi-national (on a somewhat related topic) about certain security testing (that just happens to be core to PCI DSS compliance and validation). They had not done this testing…..had never done it on some major core systems. In our opinion, these systems were within scope for PCI DSS compliance. Yet, they had been certified as compliant by their QSA for the last 2 years!
I’m not saying that any of our clients will never be breached, but we’ve hopefully helped them minimise the risk of them being breached through the work we’ve done with them. We don’t pass anyone as being PCI DSS compliant unless we’re confident that they are, and not just compliant, but secure. We check things, we test things and we don’t just ask questions, accept the answers and then tick the box.
About 18 months ago, I had a chat with a QSA from a large well know “security” company. He told me he never touched anyone’s systems during a PCI DSS onsite audit. When I asked him how he could possibly then know whether those systems were secure (not using the term compliant), he responded that he based his assessment upon documentation and what the relevant IT staff told him. WTF?! He was surprised to learn that we get down and dirty on the systems hardcore! – “How do you get the time to do that?”, was his response. “Well we try to scope the job right and it’s probably one of the reasons we don’t get some jobs because you guys scope the job for half the time and the client will generally go for the cheaper option”. (To their longer term detriment).
There’s nothing new in this post. I’ve talked about the scary, weird, bad and good things about PCI DSS for a while. I can’t be accused of being a PCI DSS fanboy but I am a supporter of anything that is making steps (even small ones) to a more secure world:
http://beastorbuddha.com/category/pci/
For every bad story about PCI DSS reported, there’s probably hundreds of good stories that never get any press/blog attention. Lets balance it out fairly and then make a call on whether PCI DSS has been a good thing or not. Keen on your thoughts.
—————————————————————————————————————————————————————————–
Securus Global is a PCI DSS QSA, amongst other things. We have been delivering PCI DSS consulting, security and compliance services to may of Australia’s, the region’s and the world’s largest brands for a number of years.
“About 18 months ago, I had a chat with a QSA from a large well know “security” company. He told me he never touched anyone’s systems during a PCI DSS onsite audit.”
hmmm. someone is going against written directions in the PCI-DSS for testing procedures. They should be stripped of their QSA status and not refunded their $US10K per annum fee for bringing the profession into dis-repute.
The ones that often generate config checking involve:
“1.2 Examine firewall and router configurations to verify
that connections are restricted between untrusted networks
and system components in the cardholder data
environment, as follows:”
“2.2.3.c For a sample of system components, verify that
common security parameters are set appropriately.”
“2.3 For a sample of system components, verify that nonconsole
administrative access is encrypted by:
-observing an administrator log on to each system
to verify that a strong encryption method is invoked
before the administrator’s password is requested;
-Reviewing services and parameter files on systems
to determine that Telnet and other remote log-in
commands are not available for use internally; and
-Verifying that administrator access to the webbased
management interfaces is encrypted with
strong cryptography.”
etc etc.
@Matthew agreed….yeah….etc etc – even where it’s not specifically stated, it should be done to a level where the auditor is confident that the “spirit” of the point is met.
“Spirit” of the point should mean “security” not just “compliance” – something that the Net bloggers have been talking a good deal about; “compliance” vs “security”. When addressed this way (as a security standard and approached as a security standard), that argument should be moot. Easier said than done it seems in reality in many cases.
For the PCI SSC, I suppose they had to find some balance – build a sufficient base of Auditors to at least get the program off the ground and then fine-tune/fix issues later.
Almost anyone will pass the QSA exam with a little preparation time. It’s not a hard exam. Would I personally use any certified QSA to perform work for us for a client? Not a hope in hell! I’ve met many but would only rate a few. That’s being honest.
The breadth of knowledge required and to a level of detail I would be confident in is something that only a small percentage of the industry would have. Separating areas of the audit between team members against their areas of speciality is probably the approach most good QSAs would use – at least having strong technical expertise to support the main QSA is vital to ensure little to no gaps.
Many QSAs just don’t have enough basic technical expertise to be able to perform a full audit on their own to a level that the PCI SSC and industry overall would expect.
Many clients unfortunately are not in a position to be able to compare one QSA from the next and in many cases, the choice of auditor just comes down to who is the cheapest. You get what you pay for I suppose and as I mentioned, the short term savings could turn into longer term pain – all for the sake of a few thousand or more dollars.
I believe that the PCS SSC is going to start to audit the auditors and that is potentially a good thing.
I should add that should something come up during an audit that may not be covered specifically by the PCI DSS, but that we deem a security risk to the CC environment, it is raised with the client and/or somehow included within the audit under the “spirit” of one point or another.
I know its wrong, but I can’t help but laugh.
Having recently had the same lengthy discussion and kind of keeping my ear to the blogosphere I would have to argue against auditors measuring what you call ’spirit’… This is where the subject becomes subjective and you can’t expect/don’t want auditors to carry out risk assessments on the control weakness to get an idea if the ‘spirit’ is upheld. What I mean by this is the onus is on the target organisation to identify its own security (operational) risks and the controls which mitigate them. These may align with controls that are expected by (insert your compliance regime here) or may not.
The controls mentioned are a product of two types of risk in this case.
1. Regulatory Risk
At the most basic (think utopia) you are either compliant or not. The risk is that the regulator chops off your balls and you go crying to mumma.
2. Operational Risk
Think, something that goes wrong in your operating environment. This is what I consider the discussions mean by compliance /= security. I can tell you I don’t want a PCI auditor telling me if I am achieving acceptable operational risk.
I know and understand my organisations operational risk profile, so does the internal audit team because we have identified what that are risks to the organisation, division etc. and have a set of controls to mitigate the risk to an acceptable level.
Internal audit should also liaise with the organisational regulatory expert, and can tell the risk of said regulator doing the ol’ chop chop.
Sure you expect auditors to actually gather evidence of compliance to controls (isn’t this auditing 101?) otherwise if they are just asking questions and ticking boxes it is no more than a self assessment with someone else being the (expensive) scribe.
Maybe I have a low expectation of auditors, maybe they are supposed to assess the risk of missing or failing controls and do it well, but I so infrequently see this rare breed of auditors, I think they may be a myth.
@ Draz I agree that should something glaring be found in an audit that has nothing to do with whether there is compliance, you could argue there is a duty of care to call it out to the client. Otherwise in this litigious climate there is a distinct possibility that the auditors could be held liable if the vulnerability were to be exploited.
To sum up, these are two separate issues and should be kept as such. Compliance or non-compliance is one set of risks and has its own set of consequences and so is security (or the outcome of having security related operational risks). A better security posture may be the by-product of compliance but it is not the objective.
Just got the latest PCI SSC Assessor Newsletter and by coincidence, first page, big focus on QSA quality. One section:
“For the quality assurance program, assessors should expect to see the Council taking a closer look at the business requirements and professional conduct detailed in the Validation Requirements documents. This includes reviewing internal quality assurance programs of the assessors, their laboratories, insurance requirements and ethical behavior during an assessment or scan.”
Sounds simple enough. No rocket science. What is the problem and why are people making it complicated like here?:
http://pcianswers.com/2009/01/21/what-pci-compliance-really-means/
Looks like a situation of if you are not directly involved, you are not really seeing it. Confused how experts in our field just don’t get the basics of this. eg; Jeremiah’s comments to Mike.