Exposure management - Managing assets, attack surface, attack paths, and vulnerabilities with purpose

2 minute read

There are a variety of cybersecurity product categories and activities intended to reduce the likelihood that an adversary finds and successfully exploits a vulnerability, resulting in an intrusion (and ultimately a breach):

  • Asset management (often including “inventory”)
  • Attack surface management
  • Attack path management
  • Vulnerability management
  • And more . . .

In thinking about how all of these fit, and in particular what a vertically integrated product or activity might look like, I find it helpful to think about the attributes or unique set of attributes that matter the most. In the context of assets that comprise our attack surface, any of which may have a number of points of vulnerability and thus be subject to attack, the attribute that seems to matter most is exposure.


You can have assets rife with vulnerabilities, but through a variety of controls make those vulnerabilities inaccessible enough (or contain the system such) that you have mitigated or deprioritized the risk. At the same time, you can have an asset with a single esoteric vulnerability, and if that vulnerability is exposed you can end up in a very serious situation.

Exposure management is the act of looking at your attack surface in the proper context to identify the subset of assets that are exposed–meaning that a vulnerability is exploitable by an adversary—so the corresponding risk can be mitigated or remediated. For example:

  • Threat intelligence is used to identify the highest likelihood and highest impact threats, and to ensure that risks to assets are tracked, understood, and actioned if necessary. It’s worth noting that exploitability of a vulnerability is a critical aspect of threat intelligence for this particular purpose. For example: Knowing that ransomware is a threat is obviously helpful. Knowing that a ransomware actor gains access through a software vulnerability with a publicly or commercially available exploit meaningfully impacts prioritization.
  • Data from technical controls will help to make determinations about which assets and corresponding vulnerabilities are reachable in the first place and/or whether there are mitigations in place. There’s a huge opportunity to better correlate data from endpoint, cloud, and application security products to make these determinations.
  • Lastly, but arguably most important, is using every piece of data and information at your disposal to ensure that you have the most complete picture of your attack surface. Unmanaged assets are the adversary’s plaything.

Naturally, the productization of this concept in any vertically integrated manner–meaning combined data, information, and intelligence spanning each of these areas–would move the needle in a manner that is more actionable, leading to better outcomes likely at a lower cost.

And in general, instead of trying to optimize for completeness or maturity in any or all of these areas on their own, consider how you might do just enough of each with a high degree of coordination, and in doing so actively and effectively reduce risk by managing your exposure.

Discussion on LinkedIn, Twitter

Threat modeling templates

less than 1 minute read

In the course of reviewing a number of published threat models, it became apparent that there is not (nor does there need to be) any standard output format, even given the same methodology (e.g., STRIDE).

I’m into spreadsheets. Applying structure to data in a tabular format makes it possible to sort, summarize, use math and statistics to glean insights, and generally makes data more portable. So, I started collecting threat modeling outputs that fit into columns and rows, and I put them in into a Google Sheet.

Threat modeling output templates


For now, the template includes the following output formats:

Shostack, from Table 1-3 Addressing Repudiation Threats in the canonical reference Threat Modeling: Designing for Security. The primary dimensions here are Threat Target, Mitigation Strategy, and Mitigation Technique.

Sysdig, from ECS Fargate threat modeling. This uses Asset, Threat, Security Control, and Mitigation Strategy as outputs.

Riggle, from An introduction to approachable threat modeling. This uses Principles, Goals, Adversaries, and Invariants as the entities in the model.

Threat modeling output templates

Threat modeling, the cloud, and shared responsibility

1 minute read

An interesting aspect of cloud-related threat models is that cloud-based threats must take into account shared responsibility models that are specific to each cloud provider and service.

If a key output of any threat modeling exercise is a set of identified threats, then the ideal state for any threat is that you eliminate it completely by way of design, engineering, or otherwise. Of course, the value of threat modeling is that you not only identify threats that you can eliminate, but that you make thoughtful decisions about how to deal with the remaining threats that you cannot.

A model for this surely exists, but I wanted something very simple that could be used to classify unavoidable threats based on the two primary means of mitigating them: technical controls and monitoring. This has obvious utility when threat modeling applications built atop cloud platforms, but is similarly applicable when building atop any platform that you don’t fully control (hint: this is virtually all of them).


In this model, threats end up in one of three states:

  • Green, which is as good as it gets for a threat you can’t eliminate outright. Of course, if controls are available, there’s a good question to be asked re: whether those controls can be implemented such (i.e., by using restrictive defaults or policies) that the threat is eliminated and thus removed from this grid entirely.
  • Yellow, which is probably the most common. In this state, you’re able to rely on either technical controls or on monitoring. The trick with relying solely on monitoring to mitigate a threat is that monitoring is only an effective mitigation when coupled with detection (knowing the threat occurred) and response (doing something about it).
  • Red, which should leave you questioning your design, your cloud provider, or both. In particular, threats in this state require putting significant trust in both your cloud provider and the security inherent to their platform, as well as your ability to engineer for safety.

Discussion on LinkedIn

Roundup of threat modeling resources

5 minute read

I don’t know much about threat modeling, except that as long as I’ve been working in cybersecurity, we’ve been asking people about their threat model, telling them to do threat modeling, and in the worst cases using greedy threat models to convince folks that they should prioritize things that they probably should not.

I believe that, like most things in this industry, there’s a very approachable and “plenty good enough” version of threat modeling that would benefit a good enough percentage of organizations. In an effort to figure that out, I came across this handful of resources covering core threat modeling concepts and frameworks, real-world threat models, and tools you might find useful.

Learning about threat modeling

Adam Shostack

The canonical reference is Threat Modeling: Designing for Security by Adam Shostack. If you’re interested in threat modeling, you should read it. I’ve tried to read or page through a couple of other books, and frankly none of them compare.

Shostack also provides a beginner’s guide, which is less instructive and more of an overview of the purpose of threat modeling and a roundup of models and methodologies. This guide perfectly frames why we threat model by way of the specific questions that we should be trying to answer, using his Four Question Framework:

  • What are we working on?
  • What can go wrong?
  • What are we going to do about it?
  • Did we do a good job?

If you’re in search of “plenty good enough” threat modeling, answering these four questions relative to your subject system or application is a really great place to start.

Kevin Riggle, for Increment (Stripe)

The title and introduction to An introduction to approachable threat modeling say a lot:

Threat modeling is one of the most important parts of the everyday practice of security, at companies large and small. It’s also one of the most commonly misunderstood. Whole books have been written about threat modeling, and there are many different methodologies for doing it, but I’ve seen few of them used in practice. They are usually slow, time-consuming, and require a lot of expertise.

Riggle proposes a four-question framework based on Principals, Goals, Adversities, and Invariants:

  • What is the system, and who cares about it?
  • What does it need to do?
  • What bad things can happen to it through bad luck, or be done to it by bad people?
  • What must be true about the system so that it will still accomplish what it needs to accomplish, safely, even if those bad things happen to it?

The examples are few, clear, and illustrative.

Additional learning resources

Threat modeling examples

I learn best by example, and I’ve found that threat modeling examples–the outputs of the process–can be hard to come by.

Related: I threw together a free threat modeling template based on some of these examples.

AWS KMS, by Costas Kourmpoglou / Airwalk Reply

This excellent AWS KMS Threat Model leverages security model and product documentation from AWS and identifies a tabular list of threats.


For decision-making purposes, this flowchart makes it easy to determine which key management option you should choose based on standard trust boundaries:


Google Cloud Storage, by NCC Group

One of the best cloud infrastructure (IaaS or PaaS) threat models I’ve seen is by Ken Wolstencroft and the folks at NCC Group: Threat Modelling Cloud Platform Services by Example: Google Cloud Storage. This is a good reference for anyone looking to implement a STRIDE-based threat model.


AWS ECS Fargate threat model by Sysdig

This ECS Fargate threat model by Sysdig provides output in the form of a table:

  • Assets
  • Threats
  • Security controls
  • Mitigations

Cloud environments are often a rat’s nest of services, so I like the idea of being able to “stack” threat models, and do things like identify a unique set of security controls or mitigations.

TLS v1.2 threat model

This may be one of the most concise representations of a threat model available, and is an excellent example of an ideal final output of a threat modeling exercise: A prose explanation of the purpose of the application, assumptions about operator and attackers, and how the application design addresses threats (which may include acknowledging a threat but not attempting to mitigate it at all).

The TLS protocol is designed to establish a secure connection between a client and a server communicating over an insecure channel. This document makes several traditional assumptions, including that attackers have substantial computational resources and cannot obtain secret information from sources outside the protocol. Attackers are assumed to have the ability to capture, modify, delete, replay, and otherwise tamper with messages sent over the communication channel.

See RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2, Appendix F (Security Analysis) for the remainder of the analysis.

Other threat modeling examples

Notably, there are some threat models that have been codified as their own RFCs:

And these are collections of a wide variety of threat models and threat model formats:

Tools for threat modeling

And of course, everyone loves to software their way out of or through a process problem, so here’s some software that came recommended.

General purpose tools

End-to-end tools for threat modeling.

Diagraming tools

Useful for diagraming systems and corresponding threat models.


Useful for capturing the output of threat modeling exercises.

Alternatives to threat modeling

One thing that’s apparent from all of the above is that there’s no established means of threat modeling, and certainly no “right” way. Considering threats and making purposeful decisions regarding whether or how you’ll mitigate them is better than doing nothing, and more important than any set of processes or artifacts. That said, using an established process and repeating it will mean that you mature your understanding of both the systems and the threats, so it’s worth doing consistently and well.

Mozilla Rapid Risk Assessment (RRA)

Of course, sometimes what you need is a fast, good enough risk assessment. The Mozilla Rapid Risk Assessment (RRA) process is intended to be very fast (~30 minutes).

One thing that I appreciate is the simplicity of their list of issues and corresponding impacts. When defining any type of risk or incident management policy, it’s common to get hung up on questions like “what’s the difference between medium and high impact?” This list is a convenient shortcut and will speed up risk classification and determination of impact.


Information asymmetry is the root cause of every breach

1 minute read

Information asymmetry is the root cause of every breach. Your adversary knows something that you do not.

For instance, your adversary might discover:

  • A remote management system exposed to the Internet that you haven’t adequately protected
  • An account that uses weak, legacy authentication (e.g., an account lacking multi-factor authentication
  • A software vulnerability that you don’t know about, or know about but haven’t mitigated through patching or otherwise

Of course, this aspect of asymmetry doesn’t just apply to weaknesses on the target side. Your adversary likely has some level of specialization that works to their advantage, and that you can’t effectively predict. This might include deep understanding of:

  • One or more particular pieces of software
  • The inner workings of underlying compute and/or infrastructure platforms
  • The limitations of security controls or mitigations

Apex adversaries often have a deep bench, able to tap individuals or teams with specialization in myriad technical, operational, and other disciplines. You should assume that these adversaries either check every box on the lists above, or have the resources to do so.

Information asymmetry applies to intrusion operations, too.

Your adversary has the benefit of initiative. In addition to knowing technical, operational, and other aspects of intrusion operations, they are able to:

  • Plan and coordinate amongst themselves and their partners
  • Be as patient as needed
  • Balance things like the urgency of their operations against their risk tolerance (where risks are things like outright failure, attribution, and more)

So what’s the good news? If you can identify points of asymmetry, you can counter them.

We love to tell people to “think like an adversary”. Thinking like an adversary isn’t really a thing. It’s a few things, coupled with intent. But most of what adversaries are doing is looking for points of asymmetry and exploiting them.

Look at the lists above, and then consider how you might approach the same points of asymmetry, but to a different end. Selected examples:

  • Double down on understanding your attack surface, particular the subset that is most exposed
  • Provide strong identity protection, at virtually any acceptable cost
  • Patch your software, focusing first on vulnerabilities that have been actively exploited (don’t forget that your security controls are attack surface, too!)

Identify areas where asymmetry exists, and do a little work to try to learn the things that an adversary would seek to learn.

Get there first.