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

In the first part of this article, we discussed the domain expertise that threat modeling requires and the DFD (DataFlow Diagram) methodology of threat modeling. In this article, we'll focus on identifying and countering vulnerabilities.

Threat mnemonics and intelligence knowledge base — divide sub-domains and conduct threat topics

With a basic framework, how to identify vulnerabilities? First, we need to start using the analogy of DDD thinking, and then proceed to the process of dividing sub-domains. Finally, we will have a threat model.

We all know that dividing subdomains is a challenging thing to domain experts. Fortunately, there are alot of methods that can guide us in a structured way. A large number of threats are summarized into enumerated types. Among them, the STRIDE model is most widely adopted:

• Spoofing

   

• Tampering

   

• Repudiation

   

• Information disclosure

   

• Denial of service

   

• Elevation of privilege

Many threat modeling beginners use the STRIDE model to conduct threat modeling of the system architecture, trying to describe a threat around particular components. This is actually a misunderstanding. STRIDE is actually a generalization of a large number of threat ontologies. They are summarized into mnemonic words. We should not establish ​​the assumption a particular framework or component may have specific risks. Instead, we should apply all threat types to each asset and component, and iterate the model as much as possible. That is, for most cases because the threats usually came from a specific attacking path, STRIDE modeling for each point and connection, rather than analyze a certain aspect for a certain point.

For example, for the "authentication service" in the system, we often subconsciously think that "spoofing" and "elevation of privilege" are its main threats.n fact "denial of service", "information disclosure", "denial of service" and even "tampering" can all impact that service.  For instance, when the authentication service encounters a DDoS attack, do we reserve enough cache or redirect traffic to prevent other systemic impact? Is it possible to leak users’ information on the site due to improper response, like registration status?

When thinking about the solutions or mitigation measures, you can consider the desired properties behind the different threats. It helps us to consider these threats in a problem-driven way, rather than only relying on the introduction of tools or controls.

Here are the desired properties of each threat:

In addition, in order to enlarge the scope of threat intelligence, there are a lot of standards and intelligence sources maintained by the community, such as CAPEC, CWE, and CVE, can all help us understand where the threat of a system comes from. Some common threats (attack vectors) are like the most fine-grained elements in domain modeling, which together form an attack tree of adversary.

Here is an example of an attack tree drawn starting from a threat in a monitoring service.

Continues thread modeling process over one off activity

Through threat modeling, we can obtain a relatively comprehensive list of threats in products, and use it as a cornerstone to iterate on the architecture design. This can reduce blind spots of unknown risks that can be introduced should the architecture design change in the future.

Therefore, threat modeling is also a long-term and insistent process. The time required for threat modeling itself is not very long (usually, a lightweight threat modeling workshop takes about two hours), but its output, the list of security requirements, often needs to be implemented over months or even multiple iterations. Thus it should not become an emergency action on the eve of the product launch or the moment before production. It needs to become a part of the routine in-product requirement analysis, architecture design, and test case alignment process, integrated into the daily work of the product design and development team. We also encourage teams to plan threat modeling in Agile iterations and write down stories to describe threats’ mitigation requirements which should also include acceptance criteria.

Adversary-based threat modeling - The horn of emerging the practical and theoretical

In the past few decades, there have been two factions in the security field, empiricism and methodism. Empiricism usually pays attention to practice, so it pays more attention to technical details, and it is easy to find problems that are difficult for ordinary people to recognize. Experts of the other method faction are good at using more comprehensive perspectives to decompose security issues. In recent years, as security issues have risen, we have gradually seen experts in these two directions merging with each other.

On one hand, the experience of exploiting vulnerabilities, especially the threats in a large number of offensive and defensive activities, has been gradually summarized as a threat/defense model library, such as ATT&CK, CAPEC, CVSS, which have been improved year by year, and have become a data set that can be used as a reference input in modeling activities.

In the other direction, security methodologies are not limited to paperwork. We see more and more security methodologies combining with practice, such as DevSecOps, CARTA (adaptive security) and other security methodologies. They all pay more attention to fully utilize automation tools in a business context, rather than being limited to compliance or audits.

The collision of these thoughts let us see that a more structured, more predictable and measurable overall security architecture framework is gradually emerging. This undoubtedly makes the security activities in the requirements design phase gradually become a more scientific and dialectical activity, and we have reason to believe that "threat modeling" from the perspective of adversaries is the horn of this movement.