PCI DSS overhaul necessary

First, I have to admit this post should have been submitted to the PCI Security Standards Council as part of the feedback phase for the DSS that has just closed, but my concerns are related to the core structure and format of the standard. I believe it wouldn’t make any difference to submit them as the last changes to PCI DSS have been more of an incremental aspect. Anyway, that’s my mea culpa for delivering criticism without contributing on improving the standard.

 I’ve been working exclusively with PCI during the past year. Being involved in remediation activities and not in assessments allows us to have a direct view of the challenges to have the standard fully implemented, even considering it a “bare minimum” in terms of security.

 In short, PCI DSS must be more effective: It has to shift from a simple list of controls to an outcome based system.

 All PCI requirements have the same weight to organizations trying to achieve compliance. There was an initiative from the Council called “the prioritized approach”, but it’s more a roadmap to an organization towards compliance than a risk based model. It says that “The roadmap helps to prioritize efforts to achieve compliance, establish milestones, lower the risk of cardholder data breaches sooner in the compliance process”. It tells you what should be tackled first, but at no point it means that you don’t need to work or put effort on the items on the end of the list. So, when full compliance is the end goal, having clear roles and responsibilities expressed in the security policy is as important as ensuring that Internet facing web applications are not vulnerable.

 I won’t argue about the importance of specific controls in the standard, but clearly some key deficiencies are directly related to a big chunk of the breaches, so the standard should be tuned to put more emphasis on those controls while allowing organizations to deal with the other items according to their own internal prioritization, planning and even culture. An organization with strong yet informal controls, for example, can only consider those controls in place for PCI after formalizing them, driving resources away from other areas that carry more risk and that might need improvement.

 PCI DSS also stifles innovation by forcing organizations to apply a set of “best practices” that otherwise could be replaced by more modern practices. Imagine a scenario where you are working to improve your controls over data traversing your network perimeter. A lot of interesting approaches and technologies are currently evolving and being discussed in our field, such as application aware Next Generation Firewalls, DLP systems, network behavior analysis tools and having an active security monitoring group who can understand what should and what should not be there. However, if PCI compliance is one of your priorities you better put all those things aside and start putting together extensive documentation about ports, protocols and rules in your environment (and keeping that updated!). The DSS seems to be written for low complexity networks, with just a few entry points and a very small number of services available and ongoing connections. You need to have all of them documented and keep that documentation up to date. No wonder the card issuers (i.e. Banks), who have far more complex networks than the average merchant, are still trying to keep a healthy distance from PCI.

Validation also needs to be reviewed. As the reporting instructions are public, organizations are tailoring their compliance efforts to what the QSA will look for, not to meet the requirements intents. A lot of documents are created as empty shells and placeholders, just because some process and procedures have to be documented. The QSA has limited time to go through all those documents in a very short time engagement with limited resources (lots of QSA competition reduce their ability to charge decently for those assessments), reducing the time available to check things that really matter. Can’t the assessment be changed from a control checklist to something more outcome based? Integrate the ASV scanning and pentest requirements into a single continuous assessment framework that would check the outcome of security processes the organizations choose to put in place to keep some key defined metrics under control?

 That’s a lot of food for thought. I’m not holding my breath for any exciting changes from the current review cycle. In fact, I’m expecting more from the same, additional layers of controls to keep the compliance wheel of pain running fast. Here we go for another lap.

 (I know about compensating controls, scope reduction and other things that can be done to make PCI DSS compliance more “manageable”. Although I agree they are useful tools I don’t think they are enough nor well defined and understood within the QSA community. Today it’s easy for an organization to just hop from one QSA to the other looking for someone that “likes” their approach on those items. There are so many different opinions out there that you can always find a QSA that will agree with anything you want to do)