Assets, Black Swans, and Threat-Centrism

"If you think a weakness can be turned into a strength, I hate to tell you this, but that's another weakness."
Deep Thoughts by Jack Handy

This post has been percolating for a few weeks now. Part of it was triggered as I read Taleb's The Black Swan, part of it was triggered by attending the ISSA International Conference a few weeks ago and hearing the same old quips, and part of it was triggered this morning by reading stories about yesterday's DARPA cybersecurity conference.

The challenge to this whole post is going to be keeping a coherent thread, so let me spell it out up-front: If "securing networks" is your goal, then I hate to tell you, but you've already failed. A strictly threat-centric approach to infosec is the failed approach we've been using for decades, and it's not going to solve any problems. The real problem is that we've lost sight of what is really important (assets!), and are not constructing our environments, defenses, etc., in a manner that is optimized toward protecting those things. More on this later.

The Threat-Centric Fallacy

Running scanners and conducting audits and penetration tests are easy. Enumerating threats and weaknesses can be a lot of fun for the assessors, but when done with the absence of asset information and impact estimates, the gleaned results lack context and meaning. Part of this is the old externality ax that Bruce Schneier likes to grind. Take consumers, for example: if their workstations become compromised as part of a botnet, and then used to spam the world, what's the impact to them? If none of their data is lost or compromised, then why should they care? This example illustrates weaknesses and threats without a necessary impact. Similarly, various reports on weaknesses ("vulnerabilities") and shallow threat modeling without any sort of meaningful, customized impact context makes it hard to know how serious to take the findings (e.g., a "serious" bug in a system that contains no valuable data is not likely a "critical" finding).

I'm starting to wonder how much longer we're going to continue listening to threat-centric talk before we realize that it's a failed approach? There are too many unknown unknowns from a threat and weakness perspective to be able to construct an adequate defensive strategy. It is this point that many risk critics have taken away from Taleb's "black swan" concept, and rightfully so. In a threat-centric world, you're always exposed to hidden risks, which are as likely as not to represent black swans (quick def: a "black swan" event must have three attributes: "rarity, extreme impact, and retrospective (though not prospective) predictability").

Here's the problem: If you look at the world through the lens of a standard distribution of threats and weaknesses, then the majority of your time and resources will be focused on the mundane every-day occurrence. Unfortunately, these aren't necessarily the occurrences you should care a lot about. Instead, you need to beware the long tails, where the big nasties lurk. Unfortunately, there's no good way to estimate all those hidden nasties.

Here's the answer: Quit trying to focus so much time and energy on the nebulous unknowables and instead start with what you can define completely. Start with assets.

Assets Are Most Important

Rather than relying on a threat-centric approach, which opens the door to all sorts of problems that are not solvable, it is instead better to start with the knowns. If you don't know what your corporate assets are, then you have no business using the word "risk," nor is there a lot of value in audits and assessments. If you do nothing else, then make it enumerating exhaustively your assets before you go about modeling anything else. Why? Because without the impact context associated with assets and their estimated value to your organization your information is fatally incomplete.

What's equally important here is this key point: You can exhaustively enumerate your assets and their associated values (to your organization). This is not an area where you're faced with such an extreme of imperfect data. In fact, in terms of statistical confidence, my hope is that your business would have a very good handle on just how valuable each asset is to the business. The only real uncertainty that I foresee would be in dependencies and externalities (e.g., value of assets to those outside your organization).

There are numerous benefits to starting with an asset-centric analysis. For starters, you can actually provide a useful impact context for various enumerated weaknesses and threats. For another, this should provide a ready shorthand method for prioritizing your defensive strategy. And, for one more thing, starting with asset profiles means that you'll be better positioned for modeling out threat scenarios going forward.

The main point here is this: Asset information leads directly to impact data, which is the key starting point for any analysis. Why? Because it's likely foolish and unnecessary to spend time and money running an in-depth analysis on various risk scenarios if the assets being analyzed have little or no value to the business. Moreover, while it can be interesting to have some threat and weakness information on various assets, you can never truly be exhaustive in these enumerations, bringing an analysis back to the relative importance of the given asset, either independently are chained through various dependencies.

FAIR, Black Swans & BCM

One of the more common criticisms of quantitative risk analysis methods (like FAIR) is that the Threat Event Frequency estimates are at best ballpark and at worse way off base. Since Taleb's The Black Swan was introduced, the din has grown around the artificiality of these estimates. I, however, am not so concerned, and I'll tell you why: FAIR is greatly for doing your "everyday risk analysis" where a normal distribution is adequate. Sure, it doesn't generally account for the long tails much (though that does depend on how many rounds you do in the Monte Carlo sim), but that's not necessarily pertinent, either. If it did account for the long tails, then the analysis would inevitably be skewed, since that's the effect of a "black swan" event.

On the flip side, there absolutely is a risk discipline analysis that is ideally geared toward addressing the "black swan" events, and that is business continuity management (BCM). Whereas your routine risk analysis with tools like FAIR can help guide your daily decisions, BCM is inherently focused on a higher purpose: survivability. As such, a good BCM program will spend a lot of its time looking at the long tails that include the "black swan" type events, but from the perspective of how to minimize the impact of a major event and how to quickly recover. In this sense, "prevention" is not so much a concern as "detection" and "correction" are. Recoverability and resilience are the key attributes that a BCM will often look at, whereas on a daily basis you're going to also consider preventative actions.

Ultimately, though, both of these analyses come back to asset-centrism; that is, if you don't know what is valuable to the business, then you won't be able to build contingencies and protective measures around them.

There's a Time and Place...

Now that I've dismissed threat-centrism, let me just say that I think there is definitely value in using threat-centric analysis methods, though with the caveat that it needs to be in a properly contextualized environment. Specifically, once assets have been enumerated and valued, it then may be useful to add threat modeling analysis.

Similarly, weakness enumeration techniques are also useful and valuable. In fact, from a purely operational perspective, running routine vulnerability scans can be provide tremendous value to ensure that patching and access management are properly configured and deployed.

However, in both cases it is still imperative that asset data be enumerated and available. Running scans that return findings is useful, but only if it's applied to assets that have a reasonable value. Asset value data can assist with prioritizing which systems get remediated first, as well as helping to ensure that resources are properly tasked. Fundamentally, this is the much-fabled "IT-business alignment" problem, but into concrete terms.

A Top-Down View of Risk Management

When all is said and done, there will always be a range of perspectives to consider. Much of the discussion here pertains to a top-down view of the enterprise, which is most concerned about financial impact. Operational teams should also be concerned with financial impact, since making money typically helps pay for things like salaries. Even for organizations that aren't profit-driven, it's still imperative that ops teams understand the relative value of the assets they're supporting.

Starting with asset information is a reasonable point because it's not as subject to the "black swan" phenomenon. In general, you should be able to exhaustively define all your direct assets and know their relative value to the organization. Where uncertainty crops in is with threat and weakness enumeration, which is where we then move to the bifurcated risk management approach, leveraging standard risk analysis methods using normal distributions (or equivalent) on the one hand, and BCM on the other hand to account for potentially catastrophic "black swan" events that hold the potential for inflicting material damage.

In the end, without a proper asset context you can't achieve a reasonable impact assessment, which in turn will negatively impact the reliability of things like remediation prioritization schemes. It's thus imperative to spin-up better asset inventory and valuation now before things get even further off-track than they already are.


Great read Ben, and I wholeheartedly agree with you :)

Too much time on the who, what, where, why, and how versus the whom...

Hugely interesting article, far more strategic then the typical aproach of: "Argh, I need a firewall here, av here, ips here..."

My Other Pages

Support Me

Support EFF

Bloggers' Rights at EFF

Creative Commons License
This blog is licensed under a Creative Commons License.
Powered by Movable Type 5.2.10