This is page 2 of:
Can Validating PCI Compliance Increase Your Vulnerability To A Breach?
Let me offer a few examples. PCI Requirement 1.1.6 says you need to review your firewall and router rule sets at least every six months. Requirement 11.2 says you need internal and external vulnerability scans quarterly. Requirement 11.5 tells you to run integrity checking on critical data files weekly. And Requirement 10.6 says you need to review system component logs daily. If you focus only on your annual assessment (i.e., validation), you will not stay compliant for long in the face of these semi-annual, quarterly, monthly and even daily requirements.
Failing to maintain your compliance increases the risk that you will be breached. The PCI Council found that 95 percent of breached merchants were not compliant with Requirement 10 (logging), 86 percent were not compliant with Requirement 11 (vulnerability scanning) and 70 percent were not compliant with Requirement 1 (firewalls). Combined with the opportunistic and relatively unsophisticated nature of most attacks, the clear message is that failing to maintain PCI compliance continuously places you and your company at increased risk.
There is another problem with obsessing over your annual assessment: It may make the next year’s assessment harder rather than easier. Merchants expect that once they have completed a ROC the first time, it will be easier the following year. When the same staff members are assigned, documentation is maintained and there are no major system or network changes, that may be the case. But it will not be the case if merchants focus too much on their ROCs and fail during the course of the intervening year to run their quarterly vulnerability scans, review firewall configurations or check their logs. It may be pretty difficult going back and filling in those gaps. As a result, merchants can fail their subsequent annual assessments, which is painful. When processors make the mistake, they risk falling off the list of approved service providers–a virtual death sentence.
I recommend appointing a PCI owner. It may not be a full-time job, but that person’s role is to make sure your company stays compliant all the time–not just one day a year. The PCI owner schedules all your scans at the start of the year and then monitors the results. That person doesn’t have to check the firewall rules or the logs personally, but he makes sure someone does and records the results. The PCI owner goes to PCI training, so he knows what documentation the QSA will expect. In my ideal world, the CIO stops by the PCI owner’s office periodically and asks to see the latest scan results and other compliance documentation. With this approach, the CIO can be confident of being PCI compliant all the time.
I sometimes ask a question at PCI training or a client kickoff meeting: “What is the difference between PCI and true love?” After a moment, I tell attendees, “PCI is forever.” My point is that PCI is not going away and that compliance is a continuous process. You should not ignore compliance for 11 months and then scramble madly to complete your annual validation in time.
Do you have a PCI owner in your organization, and is that approach working? As a CIO, how do you ensure your company stays PCI compliant 24/7? Do you disagree with me that PCI validation does not equal PCI compliance? I’d like to hear your thoughts, whether we agree or disagree. Leave a comment below or E-mail me at wconway@403labs.com.
-Marc
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.