Compliance: Measuring Risk Under PCI 3.0 (Part IIIa)
After working on this series of articles for a while now, I've decided that my original part III is simply too lengthy for a single post. It provides a lot more in terms of details - background explanations, etc. With that in mind, I am breaking each step of the process out into its own separate post.
If you've missed the first two parts, you can find them here:
Part I - Overview
Part II - Tools and Techniques
Step 1. Get your priorities in order.
As you’ll see below, you really can’t just dive into this process head first, without any planning, and hope for a miracle. PCI covers an awful lot of ground – and you’re going to need to prioritize. While there IS a ‘Prioritized Approach’ resource available from the PCI website, it has a few limitations. For one, it doesn’t really take your organizational context or program maturity into account. More importantly though, it represents a perception-based approach to prioritization, instead of a data-driven one. Guesses aren’t what we need here – we need to understand what the real data in the real world is telling us.
Enter the annual Verizon DBIR. Every year, for the past several years, we’ve been handed a well-documented, thoroughly explained analysis of ‘what the data tells us’. It doesn’t look at security and compliance through a muddy or rose-colored lens, it tells us what we NEED to know. And it does so in a way that can be EXTREMELY useful if you’re willing to consider it. I’ll offer up some additional ways the DBIR (and other data sources) can be of use later – for now though, let’s talk about using the DBIR as a prioritization tool.
If you dive right into the 2013 version of the report (which covers what happened in 2012), you’ll see a lot of quick statistics thrown into the executive summary that should catch your eye - one of the key ones being “how do breaches occur?”
Right off the bat you can see that 76% of network intrusions exploited weak of stolen credentials. So how does that translate into useful PCI-relevant assessment prioritization information? Well, requirements 7 and 8 are directly tied to the age old subjects of authentication and authorization (or as we like to say now-a-days, identity and access management). This ranks as #4 on the PCI Prioritized approach list. Sure, #1 on the PCI list is getting rid of data that you don’t need - that’s a given… It doesn’t really help us mature our risk calculations though.
If you start to dig deeper – and you get into the ‘top 20 threat actions’ then you can get a REALLY good perspective on where the ‘holes’ are. You can even account for things like organizational size (and more if you pull the data and go through it all). This may not be data that’s an EXACT fit for your organization, but if you don’t think it’s valuable information to have on hand then I have to ask. What are you using today?
If you read the report, you’ll note that ‘tampering’ (#1) is actually a bit of an anomaly – an important one (and entirely relevant to PCI), but Malware is the real topper here for most organizations (addressed under PCI requirement 5). You’ll need to slice and dice this data in whatever way suits your individual needs. The data is there though – and it’s an EXTREMELY useful resource… especially when trying to prioritize your potential risks.
The point is – you have to be PCI compliant. It doesn’t matter the size of your organization, or what ‘level’ merchant you are. You have to deal with every part of the PCI standard. However, when it comes to measuring risk, you need to understand threats – and that’s what this data is pointing to. What are the most common threat actions that lead to data breaches? What are the most common threat actions that place cardholder data at RISK???
What exactly are we prioritizing here? Well, I'll cover that in part IIIb.
'Till next time...
