Thinking About Risk:

Sidebar #1: “Exposure”

This is the third part of my series on thinking about risk, and the beginning of a set of “sidebars” to part 1, my basic introduction to risk. It’ll make the most sense if you’ve read that piece and understand the terms risk, likelihood, and impact that I discussed there.

In that first part, I was deliberately simplistic about these definitions and about measuring Risk. To keep things focused, and to avoid overwhelming people new to the topic, I deliberately left out some really interesting notes and complication. So now it’s time to add them back in, to paint a richer picture of the foundations of analyzing risk. This post, and the next three, will make up a set of “sidebars” to that basic risk introduction.

First up: Exposure. Some disciplines include a third factor in defining risk:

Risk = Likelihood × Impact × Exposure

Here, Exposure refers to how long you’re exposed to some risk – e.g. how many days you keep an unpatched server online, how many runs you take in avalanche terrain, how many high-consequence river crosses you attempt, etc.

It’s not always necessary consider exposure as a separate component – often it’s either irrelevant (e.g. considering the risk of a single dangerous move), or it’s baked into the likelihood (e.g. when talking about security breaches, we often say things like “the probability of a breach of magnitude X in a given calendar year”). But if it can be helpful, I encourage you to break out exposure as a separate component.

Perhaps the most useful time to do this, in a software engineering context, is when considering the risk of temporary shortcuts or hacks. Most engineers have been in situations where we’ve decided to cut corners (to hit a deadline, to fix an issue quickly, to save money, etc.), and many of us have had the experience of seeing these “temporary” shortcuts turn into long-term (or permanent!) decisions. In circumstances like these, it can be very useful to specifically call out exposure.

For example: if you estimate that an exposed vulnerability has a 0.1% risk of being exploited every day it’s left unpatched, if you say that in exactly those words, it’s quite possible that someone not particularly versed in risk will think, “0.1%, that’s super low!” But if instead you do the math and tell that that 1% per day translates to a 30% chance of being exploited in the next year, that’s sounds very different. Even better, with exposure as a distinct factor, you can now discuss directly how long everyone’s comfortable leaving the issue unpatched. If the business decides they’re comfortable with a 5% risk of breach, you can now tell them that means they have 51 days to fix the issue.

Exposure as a district factor isn’t a tool in my risk toolbox I reach for all that often, but when I need it, it’s an important tool to have.

You can find all posts in this series here and follow me in various ways. And if you’ve got questions, or topics you’d like to see covered in this series, please get in touch.