The PCI Security Standards Council announced today a new set of guidelines for risk assessments, as output from one of the major Special Interest Groups selected by the Participating Organizations in 2011. This topic is one I have written about before, and in fact it was one of the SIGs that I voted for. I’ve been through the output and I must say, I don’t see it as any different from any other risk guidance out there. It’s fairly comprehensive when it comes to listing common risk methodologies, it gives some sample frameworks and processes, and aims to give some clarity to the larger 12.1.2 subrequirement of PCI DSS. As with most risk-related topics, you will have people hailing its greatness as well as an equal number tearing it apart.

Risk, by Fayjo

Requirement 12.1.2 has caused trouble in general for those subject to PCI DSS ever since the first iteration of the requirement. Small businesses don’t do this because they typically don’t go through formalized risk assessments anyway. Large retailers (notice the industry delineation) will do risk assessments, but they rarely covered information or cardholder security and QSAs/ISAs alike struggled with reviewing this requirement. Since its inception, PCI DSS forced retailers to change how they address cardholder security, so in some cases these risk assessments are broadening to cover those areas. But is the announcement of this guidance to an empty auditorium, or are companies going to implement better risk assessment programs with this document?

Time will tell on that one. But let’s take a deep dive into some of the highlights of the document.

The biggest missing piece I found was the same issue that has been a theme in many of my discussions recently—we’re forgetting to focus on the threat actor and his intentions. We generalize threats and hope we can cover them without actually profiling the individual or group. It’s hard to do that profiling, but you get a better view into the motivations of these attackers, thus improving your ability to defend your environment. This document seems to combine actors and threats into one glob, which doesn’t really represent the view of the world.

I loved the piece on continuous risk assessment, but feel like the SIG fell short and didn’t describe what that is, what it means from an ops perspective, and what value an organization can get from continuous feedback. This document follows one of the biggest flaws in PCI DSS (which I suppose makes sense), the problems with the snapshot view of compliance or risk. Both risk and compliance change continually, thus, to get an accurate view companies should be automating significant portions of their risk and compliance process to get a continuous view of where they are.

Table 1.0 (page 12) is a good start, but companies should avoid copying this directly and modify it heavily. There is a lot of generalization here (combining of threat and actor; unclear linkage between threat, vulnerability, and outcomes; and an overreaching business impact that does not correlate with each threat, vulnerability, or outcome) that is problematic. Every threat, vulnerability, or outcome doesn’t automatically mean that one or all of those five impacts are going to happen.

This document has a heavy tie in with the business side of the house, which is great! Just remember, this is a PCI DSS focused guidance document and this should augment, not replace, any existing risk assessment process your company does. Don’t confuse things like system downtime with a specific PCI DSS requirement.

Finally, there is a bit of discussion around quantitative and qualitative methods for assessing risk. This might be one of the more hotly debated areas in the information risk management space right now, and this document gives readers a taste of the theories behind each method. One thing that should have been added is references to further reading which is included in some of the methodologies listed earlier in the document just to reinforce that this is a high level overview.

Go download the guideline and give it a read. Leave comments below!

This post originally appeared on