Security Out of Focus; an incomplete thought

Someone sent me this quote in an attempt to convince me that we should focus on vulnerabilities and not threats…I don’t think they are mutually exclusive, but here nor there…

Our data tells us that focusing on vulnerabilities is more effective in reducing risk than focusing on threats.  In fact, of nine specific types of threats we examined in our survey, none proved to be statistically significantly related to increased risk, although many vulnerabilities were.  The enterprise can do little at best to control threats, especially external ones, but it can do a lot to control vulnerabilities.  Focusing on vulnerabilities reduces an enterprise’s tendency to react to what is apparently most urgent – such as the threat reported in yesterday’s newspaper – and helps the enterprise act instead to reduce vulnerabilities that might be exploited by any number of threats.  No nation can control the level of the sea, but a nation can build dikes to reduce the vulnerabilities of its lands to high waters; no enterprise can control a sea of external hackers, but an enterprise can plug the holes in its network dike that hackers might otherwise exploit.

In short, vulnerabilities, not threats, are the root cause for high risk exposure, and it’s best to focus on the root cause.

– IT Risk:  Turning Business Threats into Competitive Advantage by George Westerman, Richard Hunter, page 126

My response: If you live in the Ghetto, what contributes to your high risk exposure, your lack of steel doors and bullet proof glass or the shitty neighborhood you live in that is full of gangs, thugs, crack whores, and meth addicts?

18 thoughts on “Security Out of Focus; an incomplete thought

  1. It is an interesting perspective to focus on vulnerabilities and not threats. IMO, half of the vulnerabilities that your cool new vuln scanner identifies is directly related to known attack vectors that was discovered via some external threat.

    Threats will always be there. And vulnerabilities can be mitigated *IF* you know where they are. In order to be diligent, you need to know where the vulnerabilities are. I believe you will only detect the presence of the vulnerabilities by knowing the threats (and their mindsets in the case of malicious hackers) and couple that with the attack vector du jour. If you only look at it from the vulnerabilities, why bother reading about that new threat at all in the paper, when you vulnerablity scanner will have put together all the pieces to check for a realistic threat + existing attack vector (aka vulnerability) in a couple of months. Heck, why not just wait for Microsoft to admit the flaws and patch it…much easier, but what about the 18 months that they knew about it, but never “disclosed” it publicly? I guess that brings us to the topic of responsible disclosure…but that is a topic for another time.


  2. As usual, Amrit cuts right to the chase….

    I think that the key is balance. Focusing on threat to the detriment of vulnerability or, flavor-of-the-day-difference, focusing on vulnerability to the detriment of threat *will* cause suboptimal outcomes.

    That’s what makes this hard…. You *must* take a holistic view of the environment to have the best possible chance of making positive change. You can’t defend against threats you don’t know about which attack vulnerabilities you don’t know you have….


  3. I’m not sure that framing the choice as “vulnerability” vs “threat” covers the universe. They’re not wholly independent (how do you estimate the likelihood of a vulnerability that only a nation state has the resources to exploit?) “Asset”, “Configuration” and other elements also play in the mix. As NSG says, if you’ve invested heavily in your attack surface, that will change the mix between threat and vulnerability. If you’ve inve

    I think this is closer to diminishing marginal returns – At any moment you’ve implemented some form of risk modelling and a corresponding risk management. The trick is to look at all the options (Threat, Vulnerability, etc.) and decide which will give you the best return on investment for the next evolution of your risk management practice. Of course I’ve got no practical advice on how to make that decision.

    • @Mark

      Yes I agree, now the problem is the risk model and as you point out how to make that decisions. Most folks are terribly unsophisticated here, there is little consensus on how to approach and trying to get cross-organizational cooperation is very challenging.

  4. I think there’s a misinterpretation one way or another.

    Just because someone doesn’t care about the threat vector, doesn’t mean they don’t care about code which cannot be exploitable by an attacker.

    I’m wondering if the interpretation shouldn’t be: I don’t care if it is a script kiddie, a hacker, someone trying to get my customer data, or an insider – I just care that there’s an XSS vulnerability on my site. I don’t care who/what can be abusing it.

    Ex: I don’t consider someone saying “clickjacking” is a threat as much as I consider that someone is saying clickjacking is a vulnerability.

    Maybe?? Possible…

  5. @Appsec

    Good points.

    For most folks in operational security it probably doesn’t matter the profile of the malicious actor, but if we want to change the risk/reward dynamic and make it an economically unattractive proposition to hack then we do need to know if the actors are script kiddies or organized criminal agents.

  6. Exam any major system failure–NASA’s loose of two space shuttle crews, 9/11, medical misadventures, and so forth–and you will find myriad factors that contributed to the calamity.

    Not only that, had some small number of those vulnerabilities not existed–more competence with wand screening at Logan, more alertness to odd behavior (leaving planes on the taxiway) at Florida flight schools, the calamity well likely would not have happened.

    That leads to an important lesson in managing complex systems for exceptionally high performance: Vulnerabilities–which often present themselves as minor perturbations–are leading indicators of threats–successful and not.

    Therefore, threat analysis is useful but not sufficient to ensure reliability and responsiveness. Also necessary is vulnerability detection, early, often, and non stop to break the network of factors that would otherwise string together into a threat.

    Steve Spear
    Sr. Lecturer MIT
    Author: The High Velocity Edge

    • Hey @Steve,

      Thanks for commenting I think most would generally agree with your premise that threat analysis is useful but not sufficient and that you need a balanced approach, including understanding vulnerable conditions.

      Couple of observations on your examples though:

      * The fact that a certain vulnerabile condition led to a compromise, operational failure or catastrophe doesn’t mean that if that certain vulnerable condition was removed there would have been no compromise, operational failure or catastrophe, it simply means that the outcome was not attributable to a specific vulnerable condition. The outcome could still occur through a number of other ways
      * there is a difference between negligent actions and malicious actions. Malicious actors will generally take the easiest route to compromise, but removing vulnerabilities will only make the malicious actor look for other forms of compromise. So for example if I know that sql injection vulnerabilities can lead to a compromise of my externally facing web servers and accompanying backen infrastructure and I remove those vulnerabilities doesn’t mean I am anymore secure than I was prior, it only means that I am less susceptible to sql injection attacks of a nature that I understand. A malicious actor can still compromise my systems in a number of ways, many of which I may not even know about
      * You cannot remove every vulnerable condition in every situation, the best you can do is remove as many vectors for compromise or operational failure and limit their impact when they occur, which they will


  7. Amrit,

    From my perspective both vulnerability and threat analysis must be part of a healthy and explicitly designed management system to achieve a goal or goals.

    So often security folks are trying to bolt on these functions very late in the life cycle where the costs of remediation are highest and the likelihood that the remediation efforts will bring additional risk of operational failure and create unplanned work.

    At the National Academies of Science Risk Management event a few years back I spoke about this very topic. The largest risk and threat to availability is ourselves.

    Unless IT Operations is explicitly defined and designed to maximize return from IT Service Assets by assuring a fully operational value generating run state IT will often fail to perform the right actions at the right times leading to complicated failure chains and unplanned work as Steve describes.

    The longer the operations organization operates with out a systemic approach supported by an effective root cause analysis practice the more other disciplines such as infosec and audit are taxed to describe the poor results acheived.

    Kevin Behr
    Coauthor of Visible Ops
    @kevinbehr on twitter

  8. Thank you for replying to my comment.

    Here are some thoughts on the topic of threat and vulnerability analysis. Please let me know what you think.

    In short:

    Threat analysis requires multi factor prospective anticipation, vulnerability analysis requires single (or few) factor retrospective investigation.

    Therefore, threat analysis is difficult by the challenge of constructing the multiple, plausible scenarios by which systems might fail.

    Vulnerability analysis is difficulty by the challenge of identifying myriad system weaknesses, many of which may present themselves with low signal, high noise fashion.

    In more detail:

    If we define:
    ‘Threat’ as a series of actions with potential to cause system failure.

    ‘Vulnerability’ as a condition that allows a particular action to take place.

    A successful threat must capitalize on a set (series or network) of system vulnerabilties.

    For the purposes of achieving system safety/reliability by _anticipating_ threats, we have to first identify individual vulnerabilities and then construct the set of vulnerabilities that will manifest themselves as a successful threat.

    Doing so requires prospective imagination.

    Achieving system safety/reliability by identifying vulnerabilities requires retrospective (or real time) recognition that a vulnerability exists.

    The challenge with vulnerability identification is that it is exceptionally hard to raise sensitivity for seemingly minor (in scale) perturbations that have seemingly minor consequences when occurring in isolation.

    Likewise, correcting vulnerabilities _may_ run into the obstacle of demonstrating _value_ for investing in the fixing of something that seems to have little impact (in isolation) on performance.

    The evidence is that systems managed with great attention to vulnerabilities perform exceptionally well over time.

    As for malicious versus negligent: The 9/11 terrorists were clearly malicious in intent; however, they actively exploited a set of vulnerabilities (not just one or two), the disruption of just a few would have forced them to find a path of more resistance than the one they took.

    In the case of medical misadventures (neglect, not maliciousness), same thing. The realized threats depend on exploiting paths of least resistance through a network of vulnerabilities. Disrupt that network in part, and the path of least resistance is interrupted.

    I look forward to your feedback.

    Best wishes,
    Steve Spear

    Sr. Lecturer, MIT Sloan School of Management
    Author: The High Velocity Edge

    • Hey Steve,

      I really enjoy this thread, it also strikes me that everyone is basically saying the same thing – we need both and there really is no ‘vs.’.

      I agree with almost all of your points. I did have some concern about an earlier point you made, which was…

      “had some small number of those vulnerabilities not existed–more competence with wand screening at Logan, more alertness to odd behavior (leaving planes on the taxiway) at Florida flight schools, the calamity well likely would not have happened.”

      I do not believe malicious and negligent are the same. In the case of a malicious actors removal of a vulnerability or set of vulnerability will most likely NOT prevent a calamity, it would only force the malicious actor to find alternative means of exploit, you state as much above

      “the disruption of just a few would have forced them to find a path of more resistance than the one they took.”

      Whereas with a negligent or an accident removal of a vulnerability or set of vulnerabilities would most likely result in prevention of a calamity.

  9. Hey Amrit – holistic holistic holistic. So there.

    In my opinion, the management of threats (preparation, mitigation) and vulnerabilities (identification, remediation) cannot be mutually exclusive, and the reason for this is attack vector, or likelihood based on position and circumstances. Just ignoring threats is one thing, if you are focusing on the vulnerabilities only, but this doesn’t take into account whether the vulnerability even IS one based on the asset and where it is.

    I don’t know a single organization I consult with that “just fixes vulnerabilities”. There’s a scale there, which is tied to the underlying principles of risk assessment and management. So can you “control” threats? No, not really (at least not ‘external’ ones). But that doesn’t mean they don’t warrant consideration.

    In general, I agree with Steve, but I think we’re susceptible to human nature, the fallacy that we *can* potentially imagine all vulnerabilities. In hindsight, after an incident, it’s much easier to deconstruct everything that “went wrong” and “was vulnerable”. Up front? Not so much, especially with limited time, budget, and staff.

    • Yo D-Shack,

      You are now banned from my blog for the triple use of the term holistic, but you have also gained +3 tech marketing points and are now able to cast press releases of utter annoyance spells =)


  10. I think that is a complicated analogy, but goes a long way in describing the deeper structure (or lack thereof) that is in play here. In the ghetto scenario, we have a situation where the probability of becoming a victim increases in relation to the number of individuals who, for whatever reason, will prey on others. To compare it to “threat” versus “vulnerability”, it’s merely as the threat multiplies, it becomes more important.

    TL;DR: Preventing specifically exploitable software flaws and protecting against DoS attacks are different beasts. Same clever required, different approach to the problem.

    Hi, Amrit!

  11. I love the ghetto scenario! I’d take that one step further and argue that everyone running the Windows operating system is living in the ghetto and if they are surfing the Internet, they are taking risky walks outside.

    In other words, you had better wear a bullet proof vest (reduce vulnerabilities) *and* carry an assault rifle (eliminate threats).

  12. From a financial point of view – How are you going to address plugging every hole in your system if you can’t estimate the probability of the threat? For example if you have two vulnerabilities one being a 0 day that is not known in the wild on a custom piece of software built in house and another, a known IIS vulnerability that has been out for six months. The vulnerabilities are technically the same, but the threat from a custom written attack is going to be lower than the threat of an attack from a script kiddy. All things being equal you are going to categorize the script kiddy vulnerability as “high risk” exposure compared to the other attack.

    You can’t just look at one piece of the puzzle to get the picture.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s