Basics of threat modeling

Preface

Whether it is mentioned in the devsecops system or the SDL system, the concept of threat modeling has been mentioned, but in the actual construction of the devops system or the SDL system, threat modeling is always ignored, because threat modeling requires a lot of time and a lot of communication. If threat modeling is done well, many threats can be eliminated at the design stage, which is of great benefit. This article will introduce what threat modeling is and how to do it.

A brief discussion on DevSecOps in corporate security

Initial exploration of the SDL system in corporate security

Due to the limited level of the author, some errors may occur in the article, and I welcome corrections from all senior experts, for which I am grateful. If you have any good ideas, welcome to communicate~~

Basics of threat modeling

What is threat modeling

Threat modeling is throughThe process of analyzing the system to discover defects caused by less than perfect design methodsIts goal is to identify these defects (due to implementation or deployment) before they are introduced into the system, so that corrective measures can be taken as soon as possible.

It can be seen from the above conceptsThreat modeling is a task in the system design phase, to find design flaws, so that problems can be solved as soon as possible.

Why is threat modeling needed

1) Understand the potential problems in the system and how to solve them, so that some security issues can be avoided in the design phase, and the probability of system problems can be reduced

2) Promote the formation of a clearer architecture

3) Define clear trust boundaries

4) Conduct targeted security testing and form better documentation

When to do threat modeling?

Threat modeling can be seen in both SDL and devsecops processes, and threat modeling is generally introduced in the design phase, which is also a continuous improvement process. The threat model should also be updated accordingly when the system is continuously updated.

How to do threat modeling

Threat modeling can be roughly divided into the following steps

1. Decompose the application or infrastructure

2. Model the decomposed scenarios

3. Analyze the threats existing in the system based on the system architecture and model

4. Determine how to eliminate or reduce risks

Decompose the application or infrastructure

A complete system may contain multiple application scenarios, and threat modeling is carried out for specific scenarios, so we need to decompose the business scenarios of our system according to the actual situation. For example, login scenario, user management scenario, payment scenario, data storage scenario, and so on.

As shown in the following system architecture diagram, we can decompose it into: login scenario, user management, billing scenario, and so on.

System modeling

After decomposing the system into scenarios, we can model each scenario, generally with three types of models:Data flow diagram, sequence diagram, process flow diagram.

Choose a suitable method according to the company's situation, generally using data flow diagrams.

Data flow diagram

The Data Flow Diagram (DFD) describes the data flow between system components and the attributes of each component and flow. DFD is the most commonly used system model form in threat modeling, and many drawing packages themselves support DFD, and the shapes in DFD are also easy for people to draw manually.

A data flow diagram includes four core elements:External entities, data flows, processing processes, and data storage.

External entities, which can be browsers, mobile devices, people, processes, and other types of entities.

Data flows, which can be function calls, network data flows, and other types of data flows.

Processing processes, which can be services, components, and other types of processes.

Data storage, which can also be files, registries, shared storage, caches, and other types of storage.

As shown below, a simple data flow diagram

Sequence diagram

This is an activity diagram in the Unified Modeling Language (UML), which describes the interaction relationships of system components in an orderly manner. Due to the sequence