The risk register: A manifesto for rallying your organization, pointing it in the right direction, and marching everybody toward effective risk management. Anyway, that’s the idea.
But, as Jack Jones, creator of the FAIR model for information risk analysis, recently wrote in the FAIR Institute blog…
“Too often, risk registers become a due diligence dumping ground for everything that turns up from audits, self-examinations, policy exceptions, etc.”
In this (4-minute) video, RiskLens VP and veteran FAIR analyst Chad Weinman gives a crash course in how to take some dumping ground risk register items, apply the FAIR model, and quickly shape them into well-formed risk scenarios that can be quantified and measured.
TRANSCRIPT: Steps to Quantification for Risk Register Items
A common question we often get is: “How do we take our scrambled up mess of a risk register and take those items and turn them into more well-formed risk scenarios for us to then go ahead and quantify and measure?” That’s what we’re going to take a look at today.
I’ve pulled three items from a sample risk register. This is a real register from one of the organizations we’ve worked with in the past 5 years, and I thought we’d walk through this.
Risk Register Item #1: Weak Password Policy
The first one is an unauthorized access due to weak password lockout policy.
The first step in turning this into a well-formed risk scenario is to identify the Loss Event. So here we’re talking about a data disclosure.
What is the asset we’re worried about? Obviously, it’s customer data, PII in this case, on System X or whatever system we are worried about with those weak password settings.
The Threat is a malicious internal or external actor.
And, of course, the Loss is “C” for confidentiality.
If we go ahead to the FAIR ontology, let’s quickly take a glance at where we would focus modeling this, given that weak password setting. It’s obviously on the Loss Event Frequency side. It’s also going to impact how Vulnerable a given system may be. And we’ll be working at the Resistance Strength Level.
Risk Register Item #2: Business Continuity "Risk"
So this one is my favorite of the bunch here, business continuity – quote-unquote a “risk” in the risk register. This is probably a control at best.
But, once again, by focusing on the Loss Event, an extended disruption due to lack of planning on business continuity, that’s the event we’re worried about.
So the assets here are any of the business processes that would be affected. And probably since we’re within IT or information security, the key IT systems that support those.
The Threat here would be environmental.
And once again, for the C-I-A, the effect would be availability.
Going a step further to help you through the analysis part here, when we look at the FAIR ontology, we’re not necessarily changing the likelihood or the frequency of a given environmental event happening but it would impact the magnitude or impact to the organization.
Risk Register Item #3: Limited Database Activity Monitoring
Number 3 is limited logging and monitoring to detect database security events.
So turning this more into an Event driven scenario, we’re looking at unauthorized access to sensitive data stored within internal databases because we’re assuming this is a problem across a population of databases.
The asset could be anything from financial, customer, IP data.
The threat is once again a malicious internal or external actor. And from an effect C-I-A, we’re definitely worried about confidentiality.
Shifting to the FAIR taxonomy, we see that when we look at the left or the right side, we’re going to focus more on modeling this on the impact side, the Loss Magnitude. The logic there is, because we have bad visibility and poor detection and monitoring, from an impact perspective, what that does is move our most likely and worst case toward the high end, so it would increase the impact of a given event.
Bottom Line on Risk Register Analysis
Once again to recap, a lot of the things that we see in risk registers are concerns or control deficiencies or other problems and we need to take those and translate them into Loss Events. Once we have the Loss Event defined, then we can further identify the assets, the Threat and the effects, and then we’re ready to start analyzing them using the FAIR ontology.
I hope you found this useful. If you have any questions, let us know.