Who’s to Blame When PCI Security Fails?
By Ed Rarick, PCI Evangelist at Tripwire
In a recent article — In Legal First, Data-Breach Suit Targets Auditor — Kim Zetter reported that PCI auditor Savvis Inc is being sued because it had certified CardSystems Solutions as being PCI compliant just 3 months before 263,000 card numbers were stolen from their system, and nearly 40 million numbers were compromised.
Is Savvis to blame?
Does CardSystems Solutions have some responsibility to maintain a PCI compliant state “after the audit”?
These are tough questions that, in my view, belong in the Boardroom rather than the Courtroom. PCI DSS is very prescriptive for best practice IT security.
Auditors definitely need to be more exacting and tougher when evaluating a company’s adherence to the specification. But an audit is a point-in-time event that says “as of today” your security level and change and control processes are at an acceptable state.
If Savvis did a poor job of auditing CardSystems and issued a PCI certificate when that company was not really compliant, Savvis is at fault for issuing the certificate.
But what about the many companies who are compliant with PCI DSS with a point-in-time audit only to be breached a month later?
The auditor is not at fault in these cases, the company is. The stated intent of PCI DSS is to “maintain” a compliant state and not just “achieve” a compliant state.
Maintaining a PCI compliant state is not easy, but it is doable and it is worth it.
It is, in large part, an attitude of being committed to maintaining ongoing security best practices. Doing so delivers continuous compliance as a free byproduct.
Making best practice security a daily rigor needs to be elevated to the Boardroom.
Far too many company are putting all their eggs in “passing the audit” project rather than improving their daily security posture.
More tone-at-the-top is needed to provide the oversight, funding and support to allow security, compliance and operations teams to get it done and get it done right.
Tripwire provides a continuous compliance solution for the 80 configuration control requirements of PCI DSS.
Rather than just detecting when critical, high-risk files change, or rather than periodically assessing the compliance status of high-risk files, Tripwire monitors them in real-time and, if they ever change, for any reason, Tripwire immediately and automatically retests them to determine if they are still in a compliant state, according to PCI requirements and according to specific customer security policy.
Alerts are immediately issues when any high-risk file drifts from a secure state and full remediation instructions are provided to allow the file to quickly be restored to a secure state.
That is a long-winded way of saying that Tripwire automatically alerts on every high-risk change as it happens and where it happens, and provides the information needed to correct the problem.
Bad change happens most often in an hour or less. It is no longer acceptable to be alerted days, weeks or, as often happens, months later.
Tripwire alerts on bad change at the speed of change.
Ed Rarick is PCI Evangelist at Tripwire, Inc. With decades of industry experience working hand in hand with retailers, payment card processors, hoteliers and restaurateurs, Ed has an enterprise-wide understanding of the issues facing businesses that must comply with the PCI standard.
Learn More About Tripwire Here
Tripwire helps over 6,500 enterprises worldwide reduce security risk, attain compliance and increase operational efficiency across virtual and physical environments. With its industry leading configuration assessment and change auditing software solutions, IT organizations achieve and maintain configuration control. Tripwire is headquartered in Portland, Ore. with offices worldwide.
* * *
Stay Informed With ISR News Feeds and Email Alerts Here:
The Publisher gives permission to link, post, distribute, or reference this article for any lawful purpose, provided attribution is made to the author and to Information-Security-Resources.com
Filed under: Breach, Class Action Lawsuit, D&O Liability, FEATURE ARTICLE, Financial, Government, Insider Threat, PCI, PCI Security Standards Council, Sarbanes-Oxley, Tripwire, Uncategorized, due diligence, hackers, identity-theft, malware, national security, privacy
Comments
2 Comments on Who’s to Blame When PCI Security Fails?
-
Matt Harrigan on
Wed, 15th Jul 2009 9:07 am
-
Owain Powell-Jones on
Wed, 15th Jul 2009 1:51 pm
Hi Ed ,
In regards to Savvis’ responsibilities, you state:
“If Savvis did a poor job of auditing CardSystems and issued a PCI certificate when that company was not really compliant, Savvis is at fault for issuing the certificate.”
Actually, if Savvis did a poor job of auditing the right components of the environment as a direct result of those components not being identified by CardSystems, then its CardSystems who is at fault. You can’t hold assessors liable for things that are hidden from them. Cardsystems had the ability to identify the development databases to Savvis, and chose not to. The best an auditor can do in that environment is ask “once again, are there any other resources which store, process or transmit cardholder data?” If the answer is “no,” then its a “he said she said” situation.
What’s the next industry event you’ll be at? I’ll wager a coffee, beer, or beverage of your choosing and a good conversation that Savvis walks away from this case.
You also say “It is, in large part, an attitude of being committed to maintaining ongoing security best practices. Doing so delivers continuous compliance as a free byproduct.”
I agree whole-heartedly that security largely consists of an attitude and approach to the problems. The word “continuous” though… You might find it interesting to know that the SSC keeps with their moniker as of late that “no compromised merchant has ever been found to be compliant……at the time of compromise.” Of course not…compromised compliant merchants don’t make for an unregulated industry 
All that said… I will add that Tripwire is a great product, which… in the right hands, can be used to avert danger, get useful information, and effectively address some compliance issues.
Cheers,
MH
PS - Serious about that beer. 
Totally agree - to take a UK analogy - if your car is more than three years old you have, every year, to pass an MoT test for which you get a certificate, now, if you have an MoT certificate but don’t maintain your brakes afterwards you are clearly at fault in an accident if you could not brake in time, it is no good suing the garage that did the MoT because all they did was test and certify that your car passed on that day the standardised test ….
Whilst I fully accept that Tripwire is a good product the danger currently is that there are a lot of single function products that focus on only one element of PCI compliance (another example is LogLogic looking only at log/event management) - the analogy is only maintaining your brakes but not checking the oil or tyres or lights, etc. - if you go out and buy a single specialist product you are again not getting full PCI coverage …
Enterprises and government need to look at solutions (of which there are not many yet) that perform the full ITGRC function set (IT Governance Risk and Compliance) including: event management (including log management, SIM and SIEM), anomoly detection, configuration management, vulnerabiilty scanning, performance management, etc. - the only one that I know of at the moment (capable of enterprise scale and with blue chip references) is SecureVue by eIQnetworks
I believe the next phase of PCI will address some of the issues around QSAs and the quality of their work, however it is the organisation’s responsiblity to be secure and one needs to remember that PCI is only a standard/test to indicate that they are doing that, which is, after all, a requirement of any well run business handling sensitive data …
Tell me what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!
