Create a Forward-Looking Risk Register to Anticipate Supply Chain Attacks - Part 2 of  'Modeling the Vulnerability du Jour'

With supply-chain attacks very much in the news – see the Apache Log4j vulnerability or the 3CX VoIP software compromise – we’re bringing back into view this post by FAIR thought leader Tony Martin-Vegue on how to leverage a risk register to prepare for emerging risks. 

Strange, unusual, media-worthy vulnerabilities and cyberattacks… they seem to pop up every few months or so and send us risk managers into a fire drill. The inevitable questions follow: Can what happened to them happen to us? Are we at risk of this type of vuln? And, my personal favorite, Is this on our risk register?

This post is the second of a two-part series on how to frame, scope, and model unusual or emerging risks in your company's risk register. Part 1 covered how to identify, frame, and conceptualize these kinds of risks. Part 2, this post, introduces several tips and steps I use to brainstorm emerging risks and include the results in your risk register.

FAIR Community Expert Contributor

Tony Martin-Vegue co-chairs the San Francisco Chapter of the FAIR Institute and is Senior Information Security Risk Engineer at Netflix. Tony was honored with the FAIR Institute’s FAIR Ambassador Award at the 2020 FAIR Conference in recognition of his longtime advocacy for FAIR. This post originally appeared on Tony’s blog about risk management.

What’s a “forward-looking risk register”? 

Before we get started, here’s the single most important takeaway of this blog post:

Risk registers should be forecasts, not a big ‘o list of problems that need to be fixed.

It shouldn't be a list of JIRA tickets of all the systems that are vulnerable to SQL injection, don't have working backups, or are policy violations. That's a different list.

 A risk register: 

• Identifies the bad things that happen. For example, a threat uses SQL injection against your database and obtains your customer list
• Forecasts the probability of the bad things happening, and
• How much it could cost you if it does happen

In other words, risk registers look forward, not back. They are proactive, not reactive.

When I revamp a risk program, the first thing I do is make sure the company's risk register - the authoritative list of all risks that we know and care about - is as comprehensive and complete as possible. Next, I look for blind spots and new, emerging risks.

Here's my 4-step process to identify risk register blind spots, brainstorm new risks, how to integrate them into your register, and implement continuous monitoring.

Learn FAIR, the international standard for cyber risk quantification, with training through the FAIR Institute.

Step 1: Inventory historical vulns and identify blind spots in your register

Run-of-the-mill risks like data breaches, outages, phishing, and fraud are easily turned into risk scenarios. It's a bit harder to identify risk blind spots. When a security incident story hits the major media and is big enough that I think I'm going to be asked about it, I start to analyze it. I look at who the threat actors are, their motivations, vector of attack, and probable impact. I then compare my analysis with the list of existing risks and ask myself, Am I missing anything? What lessons can I learn from the past to help me forecast the future?

Here are some examples:

Step 2: Brainstorm any additional risks

Keep it high-level and focus on resiliency instead of modeling out specific threat actions, methods, state-sponsored versus cybercriminals activity, etc. For example, you don't need to predict the next cold-boot type hardware attack. Focus on what you could do to improve overall security and resilience against scenarios in which the attackers have physical access to your hardware, whoever they may be. 

Step 3: Integrate into the risk register 

This step is a bit more complex, and the approach will significantly depend on your company's risk culture and what your audience expects out of a risk register.

One approach is to integrate your new scenarios into existing risk scenarios. For example, suppose you already have an existing data breach risk analysis. In that case, you can revisit the assumptions, probability of occurrence, and the factors that make up the loss side of the equation and ensure that events, such as Shadowbrokers or Target, are reflected.

Another approach is to create new risk scenarios, but this could make the register very busy with hypotheticals. Risk managers at Microsoft, the US State Department, and defense contractors probably would have a robust list of hypotheticals. The rest of us would just build the risks into existing scenarios.

Step 4: Continuous monitoring

As new attacks, methods, vectors, and vulnerabilities are made public, ask the following questions:

• Conceptually and from a high level, do you have an existing scenario that covers this risk? Part 1 gives more advice on how to determine this.
• Framing the event as a risk scenario, does it apply to your organization?
• Is the risk plausible and probable, given your organization's risk profile? I never try to answer this myself; I convene a group of experts and elicit opinions.

In addition to the above, hold yearly emerging risk brainstorming sessions. What's missing, what's on the horizon, and where should we perform risk analyses?

I hope this gives you some good pointers to future-proof your risk register. What do you think? How do you approach identifying emerging risk? Let me know in the comments below.

Read the original post: Risk modeling the vulnerability du jour, part 2: Forward-looking risk registers.