This is page 2 of:
Can Validating PCI Compliance Increase Your Vulnerability To A Breach?
Pages: 1 2
January 25th, 2010
PCI Columnist Walter Conway argues that it may sound like heresy coming from a QSA, but he sees some merchants over-emphasizing their PCI annual assessment. The main event for them is a clean Report on Compliance (ROC) for Level 1 (and soon Level 2) merchants or a Self-Assessment Questionnaire (SAQ) for everybody else. They believe that once the ROC is signed, they can relax until the next year.
But PCI is not like that. PCI has requirements that demand regular attention if merchants are to remain compliant the other 364 days in a year. CIOs and merchants who focus only on their annual PCI validation may actually find that they unintentionally make themselves more vulnerable to a costly data breach. They also make their PCI revalidation the following year more difficult, and possibly more expensive, than it has to be.
This Story Is Only Available For Premium Subscribers. Click Or Login In Below To Read The Rest Of This Story.
Already a Subscriber? Login Here
Pages: 1 2
One Comment | Read Can Validating PCI Compliance Increase Your Vulnerability To A Breach?
Leave a Reply
Readers, specifically those who want to comment on a story:
Our Comment SPAM system is getting very aggressive these days and has been blocking legitimate comments. If you post a comment and don't see it appear within 2 hours or so, can you please send a heads-up to customer-service@storefrontbacktalk.com? Ideally, please include the time you posted the comment. That will allow us to try and hunt for it. Thanks! P.S. We're working on fixing the system, but we don't want to lose any valuable comments in the meantime.
Our Comment SPAM system is getting very aggressive these days and has been blocking legitimate comments. If you post a comment and don't see it appear within 2 hours or so, can you please send a heads-up to customer-service@storefrontbacktalk.com? Ideally, please include the time you posted the comment. That will allow us to try and hunt for it. Thanks! P.S. We're working on fixing the system, but we don't want to lose any valuable comments in the meantime.
-Christine
January 29th, 2010 at 3:02 pm
Nice Article and well said!
IMHO one of the major root causes here is the perception that Security is borne of Compliance, when in fact the reverse is true. There are a couple of old sayings regarding ‘luck” – it is when preparation meets opportunity, and it is the residue of design – that can be applied here. Let’s replace “luck” with “security”, and see what we get, shall we?
Security is the residue of design
Security doesn’t just happen. It’s policies, procedures, awareness, attitude, culture, decisions, and a thousand other things that add up to your security posture.
If your CEO is meeting with Security and Audit quarterly, if security has a top-down focus and is baked into everything you do by policy, process, and procedure, and if security is something EVERYONE is responsible for, your security posture could be as ramrod-straight as you get outside a classified environment.
If security is something the Info Sec team is responsible for, if security is something you do when it’s easy but not when it’s hard, if security is something you do once a year so you can complete some paperwork, then your security posture is likely similar to that of the late Mr. Loopner (you remember him, right? Lisa’s dad? invetor of the slinky? And most important in this context: born without a spine!)
Security is what happens when preparation meets opportunity
Every year yields another “opportunity” to be secure. It’s PCI now. Before that it was HIPAA, before that, Sarbanes-Oxley, before that Graham-Leach-Bliley. You can’t survive in an environment like this by dealing with each of these challenges tactically. You’ll wind up trapped in a career-killing vicious circle of react and spend, react and spend.
The only way to deal with the never-ending barrage of new requirements is to have a comprehensive, standards-based information security program. When new “opportunities” arise, you will be able to quickly identify and report to management the 90% of the requirements already being met. By extension you can then either (a) identify the resources you need to implement, (b) propose compensating controls to address in lieu of resources, or (c) accurately describe the potential costs associated with accepting the risk.
In closing – I believe the Council and the brands stick pretty close to “to our knowlege, no organization to date has been found PCI DSS compliant at the time of compromise” to avoid potentially impugning PCI DSS compliance in the context of merhcant compromise.