As a former auditor, I understand the value a control has for an organization, a process or an application. But, I’ll be honest I used to think a control was one dimensional. It didn’t really matter what the control protected, if the control wasn’t functioning properly or configured exactly to a ‘T’, it was failing. I was never really looking at the control holistically – the nature of the control or the relationship among controls, or how to measure/estimate the effectiveness of controls within a risk analysis.
Chapter 7, "Interpreting Results", in Measuring and Managing Information Risk, the FAIR book, was the light at the end of the tunnel I needed to change my mindset and help me steer clients in the right direction. (If you're new to FAIR or need a refresher, check out What Is FAIR?or The FAIR Model Explained in 90 Seconds.)
3 Ways to Work with Controls in FAIR Risk Modeling
When running an analysis for a client or in a training, usually the most debated conversations are over how to model controls. It can differ for each client and each control – which is what makes the FAIR model so fun! When thinking through a control or process you want to implement, and you’re working to determine how to make the change accurately within your risk analysis, it’s key to think through what the purpose of the control is. There are three ways to look at it within the model:
1. Threat Event Prevention
What controls do you have that could cause you to have less loss events? Is your threat actor coming into contact less with your asset because of this new control enhancement? That would affect your contact frequency. Do you foresee there will be less action taken by the threat actor given the new control? Your probability of actionwill be reduced. Overall this would reduce your threat event frequencyand potentially your overall loss event frequency will be reduced.
2. Vulnerability Management
3. Detection & Response
Anything that could change the potential losses you experience would be modeled here.
Again, the beauty of modeling is that it can be worked and altered based on your IT environment or the functionality of a control or system. This is the more subjective piece of the model, but wherever you choose to model this control, just make sure you have used your critical thinking and you have your FAIR hat on to properly defend this change in the model. Encryption is an example of where the modeling could be different for certain organizations – it's one we encounter quite a bit.
Controls Modeling Case Study: Encryption
Some organizations look at this scenario, "Loss associated with a breach of confidential information in System X due to an attack from a cyber criminal", and think this is just going to be a smash and grab. If that’s the case I would probably model the implementation of encryption at your Secondary Loss Event Frequency – because you still may have some internal response, but your secondary response will significantly be reduced because the data is encrypted.
Now if we are looking at the same scenario, "Loss associated with a breach of confidential information in System X due to an attack from a cyber criminal", but imagine that the organization anticipates that the cyber criminal will sit on the network in search of data that is in plain-text and most likely skip over the encrypted database. This could in turn could be modeled at "Threat Event Frequency" – because the likelihood that the cyber criminal will take action against the encrypted database will be reduced.
Same control – encryption – modeled two different ways. Put on that FAIR hat and put your modeling to work!
