It’s become glaringly obvious that I did a miserable job of communicating the point in my last post.  In fact, some of the the smartest people I know misunderstood what I was trying to get across, which doesn’t speak highly of my post.  So, because I think the point(s) are important, I’ll try again.  I’ll also try to keep it from being too wonkish, per Andy’s good advice.

As professionals, two of our objectives include helping management understand:

• Which issues they should be concerned about, and
• The importance of each issue (for prioritization’s sake)

As a profession, an argument could be made that we’re pretty good at the first objective — identifying problems.  Even the lamest amongst us can grab a checklist of controls and an inventory of assets and threats, and pretty quickly identify a laundry list of concerns within most organizations.  Giving us the benefit of the doubt, we’re also reasonably good at intuitively identifying, roughly, which of the concerns in the list we believe are most problematic.

Okay, so let’s say we’ve boiled down our laundry list to a set of top-ten “risks”.  And logically, I suspect that anything making the top-ten would be labeled a “high risk” risk.  If this list is like most I’ve seen, it contains things like:

• Inappropriate access privileges
• Absence of patching
• Disgruntled insiders
• Wireless access points
• Data leakage
• Lack of user awareness
• Reputation damage
• Regulatory compliance
• Etc…

So what, if anything, is wrong with this list of “risks”?  If you’re just looking for an inventory of things that may significantly contribute to how often bad things are likely to happen and how bad they’re likely to be when they do happen, then the list is probably fine.  However, by calling each of the things in this list “a risk”, several problems occur….

Which of these things is not like the other?

By calling each of these things “a risk”, a lot of people seem to lose sight of the fact that many of the issues in the list are fundamentally different.  In fact, the list above contains six very different categories of issues:

• Control deficiencies (inappropriate access privileges, absence of patching, lack of user awareness)
• Threats (disgruntled insiders)
• Assets (wireless access points)
• Scenarios/events (data leakage)
• Objectives/requirements (regulatory compliance)
• Outcomes (reputation damage)

On the surface, this taxonomical blurring of the things that make up our risk landscape may seem to be no big deal.  After all, most of the time won’t a conversation’s context provide clarity about what’s being said?  Perhaps.  However I can’t count the number of times I’ve seen confusion and miscommunication within a conversation between two professionals because one of them is using the term “risk” to mean a threat when the other person is assuming the term “risk” means vulnerability, etc.  Yes, it tends to get figured out eventually, but it contributes to inefficiency and is a hallmark of a profession whose act is not together.

Perhaps even more importantly…

…you can’t measure “a risk” — at least not most of the “risks” you see in these lists.  In fact, out of the list above only one (data leakage) is what I would call a risk scenario that can be evaluated in terms of frequency and magnitude of loss.  All of the other “risks” in the list are really elements (subcomponents, if you will) that, until combined with other elements, don’t make up scenarios that can be measured meaningfully.  As a result, we’re unable to meet the second objective given at the start of this post — helping management understand the importance of the issues.

But wait a minute.  Didn’t I state earlier that by including these issues in a top-ten list we had at least implicitly provided information regarding their importance?  Yes I did, and no we haven’t — not meaningfully anyway.

Choices, and what does “high risk” mean, anyway?

Running a business requires constantly balancing resources against opportunities, operational expenses, and risk issues of various sorts.  In most cases the opportunities (at least in the commercial world) and operational expenses are understood quantitatively.  Likewise, what we might think of as more “traditional” business risk issues (e.g., credit, investment, etc.) also tend to be expressed quantitatively.  Unfortunately, when all we do is slap a qualitative label on something we call “a risk”, management is left to wonder where, really, it fits within the portfolio of all the other things they have to choose to deal with.  And, because many of the “risks” in our lists can’t individually be measured meaningfully, it can become very uncomfortable for us if/when management pushes back and asks us to explain/defend our risk ratings.

I have to wonder…

…whether a lot of us intuitively and subconsciously recognize the problems I’ve described above, and that the resulting uneasiness is part of the reason some of us believe risk is so problematic.  My own experience has been that having a clear and logical taxonomy of the elements that drive risk makes it a much easier (but still not trivial) problem to tackle, and allows us to do a much better job of helping management understand where infosec risk issues stand relative to the other things on their plates.  And with that clearer understanding, I find that management is more receptive to our conclusions and recommendations.  It also significantly reduces the communications challenges amongst those who are operating from the same set of definitions.

Although there are a number of definitions for “risk” out there, most of us seem to gravitate around a definition that relates to the likelihood (or frequency) and consequences (or magnitude of loss).  So with that in mind I’m going to ask a question about something that’s bugged me for a long time — What is “a risk“?  Likewise, what are “risks” (the plural of “a risk”)?

If you survey a set of people who deal with risk or security professionally (inside or outside of infosec) and ask them to list key “risks” within their scope of responsibilities, you tend to get an interesting set of answers.  For example, the list you get from an infosec professional might look something like:

• Insiders
• Lack of user awareness
• Data leakage
• Non-compliance
• Reputation
• Web applications

Why it matters

Clearly, all of these can be issues worthy of concern for an organization, so what’s the problem?  Well, maybe nothing.  If all you’re looking for is a list of issues that contribute to the amount of risk an organization has, then a list like this is probably fine.  A problem arises though, when you try to measure, compare, and/or prioritize these, for (at least) two reasons:

• They aren’t the same kind of thing — e.g., Insiders are a threat community, lack of user awareness is a control deficiency, data leakage is a type of loss event, non-compliance is a condition, reputation (damage) is an outcome, and web applications are a type of asset.  A very apples vs. oranges problem.
• They aren’t distinct or solitary in their contribution to risk.  In other words, two or more of them can be combined in different ways to describe different risk scenarios with different probabilities and consequences.  As a result, any individual measurement of significance in terms of risk is invalid.

The definition for risk mentioned above implies a measurement of some sort — i.e., a pair of values (some version of likelihood and consequence) —  yet we use the terms “a risk” and “risks” in a way that implies reference to one or more objects or “things” rather than a value.

Unfortunately, I see a lot of instances where people have tried to characterize “risks” in terms of likelihood and consequence, and it’s never pretty.  The results are very difficult to defend logically, which I suspect contributes to people’s notion that dealing with risk is hard.  My experience has been that once you get clarity around risk terminology the kind of confusion that comes from “risks” goes away and the problem becomes a lot easier to wrap your head around.