Threat modeling: domain-driven design from an adversary's point of view (part one)

Threat modeling is a process that helps discover potential vulnerabilities, shifting security practices to the left (such as architecture design flaws or lack of appropriate protection measures) and determines the priority of mitigation measures.

The purpose of threat modeling is to provide a holistic system analysis for defenders: analyzing which control or defense measures need to be included; the characteristics of the system; the profile of possible attackers; the profile of the most likely attackers; and the most likely attackers. You can answer “what kind of threats our architecture design will need to face?”, "how big of an impact will this threat be?", "what is the most possible threat to our system?", "do I need to solve these problems immediately or later?" and so on.

In addition, "threats found in the business process" are often one of the most advantageous and valuable parts of threat modeling, because the abstraction granularity of threat modeling workshops is very high, and the participation of "business domain experts" can be introduced early. One of the big benefits of threat modeling is that it enables you to construct a model of adversaries from a business perspective.

In short, threat modeling is domain-driven design from an adversary's point of view.

What is the domain expertise needed for threat modeling?

An excellent security tester needs to understand various types of vulnerabilities and attack patterns. They need to build the structure between each attack vector, need to be able to read the source code or binary disassembled code to find the clues of vulnerabilities, and need to operate automated tools for scripting. To really excel at security testing, you might even require proficient reverse engineering skills to understand software under the hood. But some lack the background knowledge of software development and architects, especially those who have been immersed in the security field for many years. Many of them lack the follow-up and practical experience of the latest technical architecture, platforms and tools.

An expert who has only made achievements in security testing may struggle to establish a dialogue with software developers. Threat modeling is essentially a process of dialogue between security experts and the architects. The dialogue requires sufficient common language and mutual understanding. Therefore, new requirements are put forward for security testing, the requirement of a "common language between security expert and architects".

Throughout the modeling process, the threat modeling expert should play the role of an imaginary adversary, and interact with the software/hardware architect or developers, so as to clarify and explain the source of the threat and the possible impact.

"This position is so difficult to recruit. We haven't found a good match for almost a year." - Head of threat modeling in a global enterprise security lab. As they spent very long time to staff a suitable person

Threat modeling is not a new concept, but in the cybersecurity industry, you may find just one in 10 candidates have threat modeling experience written in their resumes, if you’re lucky. Candidates that can fill this position are even scarcer. Most of the threat modeling experts choose to stay in universities and institutions to engage in the role of researcher. There is no extensive technical experience in the enterprise, and this position is rarely seen in a product-driven enterprise or IT departments.

Why is it so hard to find a good candidate? The main reason is that threat modeling is not a capability that a traditional security testing position can easily develop.

The essential competence of threat modelers requires this role  to not only accumulate a large amount of knowledge related to security vulnerabilities and risks, but also to understand a large amount of software architecture design principles, technical concepts, and even need to be very familiar with implementation details. This also leads to a very interesting phenomenon. Threat modelers are mostly developed from developers, not business analysts or security testers.

Thus we recommend some architects to start considering this niche career path.

Adding a security perspective to the architecture modeling process

To meet the demand of those companies that have an urgent need for threat modeling activities but lack the expertise, a lot of threat modeling "methodologies" have emerged. Among them, the DFD (DataFlow Diagram) model is the most prominent. This attempts to abstract the software architecture into a series of data flows, and points out the security specific attributes in the system (roles, components, data assets, interaction relationships, boundaries).

Usually in a threat modeling workshop, the host will start the topic from the following steps:

1. What systems do we have, and who are the users of these systems?

    

2. From the perspective of each business event, what are the interactions between this user and the system?

    

3. What data entities are generated during our interaction? What are the most important assets we care about?

    

4. What external systems or third-party dependencies do we have? (introduction of threats that are difficult for us to control)

    

5. What system security boundary designs do we have, such as network isolation, authentication and access control, etc? (security controls that we have considered and implemented)

If you are familiar with domain-driven design, you’ll notice that the first three steps of this modeling process are very similar to business events, interactive command recognition, and domain aggregation in the "event storm" method. The other steps reflect security considerations: core assets that need to be protected, attack surface, supply chain risks and security boundaries.

The final output of a DFD chart may be as follows:

Diagram with systems’ boundaries and data flows to identify potential risks

However, simply using threat modeling to express the structure of the system cannot obtain enough information to produce an analysis of the adversary. At this time, it is necessary to use "security expertise" to attack every aspect of the system and find out potential vulnerabilities.

In the next part, we'll discuss how to identify and counter these vulnerabilities.