Compliance: Measuring Risk Under PCI 3.0 (Part IIIb)
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 few parts, you can find them here:
Part I - Overview
Part II - Tools and Techniques
Part IIIa - Getting Your Priorities in Order
Step 2. Define the Threat Scenario You Want to Analyze.
The BRA process is a functional lightweight risk measurement tool that can be very useful under the right circumstances. However, its greatest limiting factor is that you MUST work with a singular well-defined threat scenario. You can’t use it to assess your entire enterprise, but you can use it to decide the level of risk associate with a particular action-asset pairing.
NIST 800-30 uses the concept of ‘framing’ to describe this phase. It talks about the need to gather threat data (see step 1 above) and the importance of defining the purpose and scope of your assessment. Here, we’re trying to fast-track things a little bit. Since we already know that we’re going to funnel all of our data points through the BRA process, we can keep this part pretty simple. There’s no need for complicated framing techniques. We just need a starting point.
Now we can leverage the VERIS taxonomy. As a quick note, I want to point out that VERIS is actually the breach reporting model that’s used by Verizon when they build the annual DBIR. This is a nice value-add since our threat data can tie nicely into our taxonomy. The real purpose of VERIS (in this instance) though is to use a common lexicon of threat actions and information assets. You can learn more about VERIS at http://www.veriscommunity.net. But what I want to zero in on is the existing schema that it uses.
I LOVE LOVE LOVE the fact that VERIS offers me a ready-built mechanism for identifying actions and assets, putting them into categories. This allows us to keep track of them as clearly defined data points. Just check out the ‘Schema Enumerations’ page of the site and scroll on down to the ‘Action Enumerations’ and the ‘Asset Enumerations’. You can get way down in the weeds if you want to, or you can roll everything back up into more manageable categories, but you get the idea.
So now let’s define the threat scenario that we’re going to be analyzing. Here’s a sample thought process that can be applied:
- Let’s go back to the idea that Malware is a big ticket item from a breach perspective. Spyware ranked at the top of the malware list. Our spyware action enumerator would be action.malware.variety.spyware.
- PCI requirement 5.1 says to: Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers).
- We know from our data (and a little common sense) that database servers are (traditionally) where most breaches actually occur (over 50% of them). Our asset enumerator would be asset.variety.s-database.
So now we’ve paired up the #1 threat action that leads to a breach to the #1 asset that gets breached. Sounds like a really good starting point when you’re trying to stay focused. We’re still missing the ‘how’ though. So we need to return to the action enumerators and look at the action vectors for malware.
- Again, our data tells us that direct installation ranks #1 as the vector used to get malware on a system so, let’s use that as our link (action.malware.vector.directinstall).
Note: At this point I should state that some combinations of action-->asset-->vector are going to make more sense to pair up than others. Some may not apply at all. You need to use some critical thinking here.
Finally, we come to our threat scenario, which may read something like:
‘What is the risk of spyware being directly installed on a database server?’.
If you want to get totally geeky (or if you wanted to build a tool for this stuff) you could write this as:
action.malware.variety.spyware > action.malware.vector.directinstall > asset.variety.s-database
I’ll describe WHY this process is necessary (and valuable) when I touch on the BRA process itself a little later on. Suffice it to say that you’re probably going to be building a pretty significant relational structure between potential combinations of actions, assets, and vectors. It’s probably going to be a fairly long list to – when you consider all of the possible permutations. Not to worry though – use your prioritization scheme to single out the things that you should be most concerned about. You may even want to set a limit – like perhaps only the top 10 or 20 actions, top 10 or 20 assets, and top 10 or 20 vectors – but that’s entirely up to you.
Hint: Plug all of this into a database instead of a spreadsheet, and it gets even easier.
Now that we know what question we're asking (which includes our 'well-defined threat scenario'), it's time to consider the controls that are in place to limit our overall risk. Stay tuned for part IIIc where I'll introduce a VERIS-based taxonomy for control statements using the SANS Top 20 Critical Controls for Effective Cyber Defense. This is where things start to get interesting ;-)
'Till next time.
