IriusRisk Threat Modeling for Security and Development Teams

13 October 2022 Staff

482

Threat modelling: what is it?
Basics of Threat Modeling Threat modeling’s fundamental tenet is the identification, disclosure, and management of security flaws. This is accomplished by being aware of the threats and attacks the system might face as well as the corresponding countermeasures (controls). Security by design vs. Fixing in production Threat modeling’s guiding principle is “secure design,” which in practise means addressing design from the project’s inception during the design phase and continuing throughout the development life cycle.

Why should we model threats?

Reduce production time. Security reviews have historically been conducted at the end of the development life cycle, when it is most expensive and time-consuming to conduct the analysis. It takes 5 hours during the coding/development stage, testing, and 10-15 times longer during production, according to research. Additionally, early and ongoing security testing reduces the time to production by as much as 25%, according to this study. This kind of research demonstrates that it is cheaper and simpler to identify and address security flaws from the beginning of the development life cycle onward. This is one justification for threat modelling activities having one of the highest returns on investment (ROI) in the security context.

Develop Your Concept

When a product’s functions and components are known and the architectural design is being developed, threat modelling should start. Threat modelling has a dual method in that it influences security requirements from the outset. Additionally, this makes sure that security is integrated throughout the process rather than being bolted on at the end.

Modeling Threats in Any Design

Stage It is important to note that, even if threat modelling cannot be included in the early design stages, benefits from this activity may still be realised throughout the product’s life cycle, including during production, as you become more aware of the implicit risk trade-offs that were made. Additionally, since many products share characteristics, parts of earlier threat models may be reused, and risk patterns and templates may be developed.

The process of modelling threats

A diagram that describes and maps the architecture, components, trust zones, and authentication flows is typically the first step in the threat modelling process. It is incredibly helpful to include data flows in the diagram: Data flows display information’s path through the system, including where it is stored, how it is changed, and how it enters and exits. A data flow diagram (DFD) is used to illustrate the boundaries and scope of a system as a whole.

Methodologies

Potential points of weakness and attack are shown in the diagram. Referring to attack trees (MITRE or CAPEC), standards (PCI DSS, GDPR, SO, NIST), or guides (such as OWASP’s Mobile Application Guide) may help to promote and facilitate this threat enumeration activity (MASVS). Additionally helpful in this regard are the Common Weakness Enumeration (CWE) and Common Vulnerabilities and Exposures (CVE). Spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege are the six categories that Microsoft’s STRIDE Methodology divides security threats into. Click here to read more about methodologies.

Cooperation is Essential

Two factors are crucial whether the process is formal or informal, carried out on a whiteboard or with software. The diagram must accurately depict the system, and it is best if as many of the cross-disciplinary stakeholder partners involved in the project attend as possible. By doing this, a line of communication is established between security and other departments, allowing for the testing of presumptions and the consideration of opposing viewpoints.

The Four Questions of Adam Shostack

Collaboration, communication, and knowledge-sharing between people with various specialties are at the core of threat modelling. A lingua franca will develop as a result of cross-discipline teams working together, which will be extremely beneficial for intercompany communication. Although there are numerous threat modelling methodologies, Adam Shostack identified four fundamental questions that can be used to summarise most of them:

What are we building?

Architecture/ Data flow/ Data classification

What can go wrong?

Main threats that apply to your application

What are we going to do about that?

Actions to take in response to this

Did we do a good enough job?

Retrospective analysis of the above