Introduction

This is part 2 of creating shared understanding for security leaders. More from this series:

• Part 1: intent, pyramid principle, strategy

Being a Staff+ Security engineer is not only about being technically sharp. That’s just a baseline requirement. You also need to drive change across teams and organizations, aligning them. That means it’s crucial that you can create shared understanding and communicate effectively.

Over the years I’ve built a communication toolset. I’m still learning a lot, but I hope this article is already helpful.

In this post I’m describing how to apply user journey mapping from user experience design in the security context.

Adversary Journey Mapping

Overview

User Journey Mapping is the process of creating a visual representation of how a user interacts with a product to achieve their goals. Let’s take a very simple example of buying a book online. The high-level phases of the journey are shown in purple, the more detailed steps in yellow.

Now let’s change our perspective to security: Instead of following a user through her journey, let’s analyze what an adversary would do. As the phases we’ll use a simplified version of Mitre’s ATT&CK framework: Reconnaissance, Initial Access, … for the various details like Pivot and Impact and finally Profit. Profit is important, because most adversaries are financially motivated.

We can represent the many options an adversary has as different paths in our diagram. Later we can also assign likelihoods to paths, because financially motivated adversaries are economic in how they operate.

curl CVE-2023-38545

Let’s apply this concept to a practical example: On October 11th, 2023 a HIGH severity CVE was published for curl: A heap overflow vulnerability related to hostname handling when using a SOCKS5 proxy. Many details about this vulnerability can be found in the blog How I made a heap overflow in curl. Definitely worth a read. But now the key question is: How bad of a problem is this CVE for you and your company? Given that curl is deployed to over 20 billion devices this looks certainly pretty bad.

There are two very distinct ways of how curl might be exposed to adversaries: As a service or via an application running on a user’s system.

For exploiting a service Reconnaissance would involve figuring out which services process URLs. To gain Initial Access the adversary would simply request the service to process a user-supplied URL and then deliver an exploit payload. Assuming the adversary has an effective exploit payload, it would only work where curl is used with a SOCKS5 proxy.

For exploiting a application Reconnaissance would mean identifying desktop or mobile applications that process URLs as well. Most of them can only be attacked indirectly via user interaction, for example via phishing. This means only very widely deployed applications like browsers and operating system components are interesting targets. And even in this case exploiting them requires again the presence of a SOCKS5 proxy, for example in the form of the Tor Onion Router.

Here’s the diagram, which additionally has green failure scenarios, where the adversary was not successful. The numbers represent likelihoods of success for each path.

The key challenge for our adversary: most systems don’t use SOCKS5. In conclusion: A purely financially motivated adversary would likely not invest into exploiting this CVE. Using this approach we can decide how strong of a reaction we need to have to this or any other vulnerability disclosure.

Ransomware

Let’s apply the same technique, slightly modified, to a Ransomware scenario. Again based on a simplified version of ATT&CK. Arrows have been omitted from this diagram, because different adversaries might choose very different paths, usually based on the specific context within their target environments. A commodity campaign might start using phishing and systematic exploitation of a CVE (for example log4shell) and in later phases adapt as necessary to the victim environment. Instead of only focusing on the adversary, in this map I’ve included the most common recovery strategies as well.

This map is very useful when applied to a specific situation, like a company’s network or a specific service. It helps focus defensive efforts on things that matter the most, while considering how good we are at recovering from such an attack.

Other use cases

Adversary journey maps are surprisingly easy to read by non-security experts. They also can lead to discussions of changing a product’s design: Minor changes that are not relevant to normal users, might detract adversaries a lot. This works especially well in situations where mail abuse for phishing or card holder data (carding) is involved. Threat modeling during early design combined with this technique can be can be very powerful.

Additional Resources

• Mitre’s ATT&CK framework
• Deciduous: A Security Decision Tree Generator is essentially the same idea, applied a bit differently