Risks are not risks, vulnerabilities are not vulnerabilities
In information security we emphasize the importance of risk, but we struggle to operationalize it. How do we make risk useful for auditors, executives, and security staff? Some of the challenges designing a useful system of record for risk (i.e. risk register) include:
- The term “risk” is not well-defined. It could be interpreted broadly (e.g. “risk of a data breach”) or narrowly (e.g. “risk of an executive using unapproved grammar-checking software”).
- The way we measure risks (Low, Medium, High) is often disconnected from the business perspective (“why do we care?”)
- Security projects (efforts to mitigate risks) aren’t traceable to the risks they mitigate
Rather than treating risk as a single concept, I propose four different categories: risk scenarios, vulnerabilities, findings, and deviations.
Risk scenarios describe probable loss events at the business level. They have metadata like threat actors (i.e. the people who cause the loss) and assets (i.e. the valuable thing that can be lost). Each risk scenario can also have a status (e.g. accepted, mitigating, etc.) indicating whether there is an active project to address that risk. They can be scored with an “Annualized Loss Exposure (ALE)”, which is measured in USD and calculated using FAIR concepts. As a rule, risk scenarios describe loss to the business - for example:
- Data breach caused by vulnerability in product
- Outage caused by accident during development process
- Compliance certification loss due to failed audit
Vulnerabilities are human-verified exploitable weaknesses in systems. They can identified in a code review, bug bounty, or penetration testing process, as well as during routine security monitoring of findings, as described below. While vulnerabilities represent information that affects risk, they are not risk scenarios because they do not directly describe loss events.
Findings are unverified weaknesses discovered by automated scanners. The goal is to review findings regularly, and verified findings that result in exploitable conditions in systems are recorded as vulnerabilities. Findings can be thought of as Schrodinger’s boxes. Most findings are not vulnerabilities, but you can’t be sure until you triage. The process of wheat/chaff separation here is tedious — see Vulnerability Inbox Zero.
Deviations are gaps in documented controls, processes, or standards. Deviations may be issues with the design of a control (e.g. we are not doing static analysis in a way that meets our security objectives) or the implementation of a control (e.g. we say everyone takes security training every year but a few employees haven’t).
Vulnerabilities and deviations are known opportunities for risk scenarios to play out, and their trends are valuable data for driving risk prediction exercises. The connections between these distinct but related concepts is described in this diagram:
At LaunchDarkly, when auditors ask for our “risk register”, we provide our risk scenarios. But we can still track the other sources of risk and how they relate. I’ve found that the clarification of these concepts help us define and operate controls to manage the deluge of security information we receive.
Do you have risk register designs that work for you? Let me know on Mastodon or LinkedIn.
