Thursday, March 26, 2009

Thoughts After RMISC 2009 PCI Panel

Today I participated in a very interesting PCI panel at ISSA Denver RMISC 2009 conference in Denver.  In fact, even our pre-panel discussion was quite fun: we planned to hit such subjects as checklist mentality vs risk mentality, prescriptive compliance versus outcome-based compliance, PCI for various sizes of organizations and even PCI compliance in virtualized environments.

To start off, it was calming to note that most of the audience agreed that PCI was helpful for their organizations in cases where they wanted to jumpstart their security program, but were not sure how.  Most people also agreed that PCI helped them get executive attention and much-needed budget to implement the security controls they knew they needed to have. No surprises here.

However, at some point in the discussion I started to realize that the desire of some organizations to do “compliance first” and to treat PCI as a “blind” checklist as well as their desire to just focus on achieving compliance and not at all on security was due to the fact that the pressure on them “to be secure” was much weaker compared to the pressure “to be PCI compliant.”
In other words, those organizations who embark on a journey to “we just need to get the auditor/assessor off our backs” fear their auditors more than they fear the hackers (uhu, Russian, Chinese and Romanian combined :-)); at least, their decision-makers seem to. Those same decision makes also likely think that it is much simpler to measure when they are PCI compliant (=when the QSA leaves with a ‘PCI OK’ report) compared to when they are “secure enough” (=when nothing bad happens for a long time DURING WHICH they are not asleep at the wheel…); thus, in their minds,  compliance seems like a “cheap substitute” for security.

So we asked the audience:  “Why do you think some people fear an auditor more than a hacker?”

Results were interesting and somewhat surprising.  Some people suggested that their bosses still (despite all the evidence to the contrary!) share the “it won’t happen to us” mentality.  At this point, I asked “But what about all those scary media stories?”  The audience response was “Well, maybe they don't follow such media…”

When this discussion started, many of the audience members pointed out that PCI compliance projects were initiated by the finance departments or even directly by the CFO.  At the same time, most of the security projects at their organizations were initiated by the IT departments (or their IT security sub-departments).  It goes without saying that CFO has much more of a CEOs ear, compared to some unnamed security manager down in the trenches.

It was also added that senior management and decision makers do not perceive information security personally: no fines on them, no jail time, no clear (to them) chance of losing money or even their whole business.  However, they do perceive various compliance issues as affecting them directly and personally (especially with CFOs reminding them about it).

In light of this, it turns out that the biggest, best driver for implementing security measures and reducing risk to information was still a good old data breach or successful compromise! (BTW, read Rich’s paper on that [PDF]) Sometimes, as one audience member noted, a competitor suffering from such intrusion “helped” as well.  In other words, intrusions, compromises and other “0wnage” drives security, while regulatory mandates sometimes drive only “empty” compliance and none of the security (especially when a security department is either missing or inept at harnessing “compliance power surge” to further the actual risk reduction agenda).

While I was listening to the discussion, I realized that PCI has  no “superpowers” to magically make “security-ignorant” organization secure despite itself: if you are hellbent on ignoring security, PCI will not make you security conscious. If you want to help yourself and you organization to become more secure,  PCI DSS guidance is of service. Herein lies one of the more interesting “limitations” (better called “perceived limitations”) of PCI and, in fact, of any detailed, prescriptive security guidance: one can choose to use the “checklist”  to be followed blindly with no real advancement of security…

To conclude, it goes without saying that PCI is very helpful start for security for those who want to start; the rest can still choose to screw it up, no matter what level of detail is given in the prescriptive compliance mandate. PCI won’t stop you if you insist on ignoring security; it can only make it a bit harder.

Possibly related posts:

Dr Anton Chuvakin