Risk modeling the vulnerability du jour, part 2: Forward-looking risk registers
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 Yahoo happen to us? Are we at risk of a Heartbleed-type 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.
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.
Including new threats and vector in your risk register
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.
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:
| Vulnerability / Incident | What happened | Lessons for your risk register |
|---|---|---|
| Solarwinds hack (2020) | SolarWinds' software build process was infiltrated, giving attackers a foothold in Solarwinds customers' networks. | Software you trust gets delivered or updated with malware or provides access to system resources. |
| Target hack (2013) | Phishing email targeted at a vendor was successful, giving the attackers access to internal Target systems, leading to a breach of cardholder data. | Vendors you trust are compromised, giving attackers a foothold into your systems. |
| Sony Pictures Entertainment (SPE) (2014) | SPE released a movie that was unflattering to a particular regime, leading to a large-scale cyberattack that included ransom/extortion, massive data leaks, and a prolonged system outage. | State-sponsored groups or hacktivists are unhappy with a company's positions, products, leadership, or employee opinions and launch a cyber-attack in retaliation. |
| Rowhammer vuln | Privilege escalation and network-based attacks by causing a data leakage in DRAM. | There are hardware vulnerabilities that are OS-independent. OS/supplier diversification is not a panacea. |
| Spectre / Meltdown | An attacker exploits a vuln present in most modern CPUs, allowing access to data. | Same as above |
| Cold boot attack | An attacker with physical access to the target computer gains access to the data in memory. | You must assume that if an attacker is motivated, adequately resourced, and has the right knowledge, they can do anything with physical access to hardware. See the Evil Maid Attack. |
| Heartbleed | Bug in the OpenSSL library gives attackers access to data or the ability to impersonate sessions. | Linus’ Law (“given enough eyeballs, all bugs are shallow”) is not a risk mitigation technique. Open-source software has vulnerabilities just like commercial software, and sometimes they’re really bad. |
| Shadowbrokers leak (2016) | A massive leak of NSA hacking tools and zero-day exploits. | Criminal organizations and state-sponsored groups have some of the scariest tools and exploits and are unknown to software vendors and the general public. When these get leaked, adjust associated incident probabilities up. |
Step 2: Brainstorm any additional risks
"Brainstorms at INDEX: Views" by @boetter is licensed under CC BY 2.0
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.
