I have tried to use a tool from OWASP called Threat Dragon for threat modelling. It took me 6 hours honestly in total. But if you follow my guide, you can see if it worths to try.
Security expert Adam Shostack, a leading authority on threat modeling, emphasizes the importance of understanding the system before assessing risks. Which means, you can't draw it, you can't secure it.
What Governance, Regulators, auditors like to see: Nice graphs, signatures, dates. Jokes aside. Let's break down who, should own what.
1- At Tribe (product) level: The tribe architect draws the diagram. Security engineer should always be part of it (not optional). Three model lives in wiki / confluence/ documented.
2- Company Level (yearly): This is the main document that auditors like to see the threat landscape and the threat modelling exercise, owned by security engineer. Make sure, the mitigations for the risks are actual and not out of date.
3- After incidents, suggest to go through the threat model document and update it after incidents hit if applicable.
Now, back to engineering.. What did I do?!
Remember the rule, you have to draw it so you can secure it.
Start with Data Flow Diagram: In Data Flow Diagrams (DFDs), external entities are typically represented by rectangles, processes by circles, and data stores by parallel lines.
The tool was not very much user friendly, as I run it on virtual machine, so it was super slow. The outcome of the DFD (Data Flow Diagram was as below).
The diagram is a simple application (for abstract only) to understand the idea how we would make the threat model.
Content Delivery
From → To What Happens
2 CDN → User Browser Delivers static content
3 Web Frontend → User Browser Returns web app responses
Authentication Flow
From → To What Happens
4 Web Frontend → External IdP Redirects user to log in
5 External IdP → API Gateway Sends back auth response
6 API Gateway → Auth Service Requests token validation
7 Auth Service → Credentials DB Checks user credentials
8 Credentials DB → Auth Service Returns validation result
9 Auth Service → API Gateway Issues session token
10 API Gateway → Web Frontend Returns authenticated session
Product Data Flow
From → To What Happens
11 Web Frontend → API Gateway Requests product data
12 API Gateway → Product Service Forwards the request
13 Product Service → Product DB Queries product info
14 Product DB → Product Service Returns product data
15 Product Service → API Gateway Sends product details
16 API Gateway → Web Frontend Returns product data
The result of the Data Flow Diagram as follows (The tool is not user friendly, and it was lagging a little on the virtual machine, thus the outcome):
Later you can click on each object and open a threat as follows, with the suggested mitigation and identify the status:
By the end of this excersise, you would be able to identify all the threats and the mitigation controls for each threat tied to an object in the Data Flow Diagram (DFD). The process of the threat modelling is not a one time, it keeps updated, and each time a threat is identified, it needs to be communicated.
Next, you need to identify for each threat, the threat source and the impacted assets.
For each component you need to ask STRIDE:
STRIDE = Spoofing, Tampering, Repudiation, Info Disclosure, Denial of Service, Elevation of Privilege.
To get even more out of it, we can use Threat Composer
The threat model at the end will contain all impacted assets with linked threats, and each threat linked to mitigation. You will also have the list of mitigations (called mitigation pack).
Certain points and challenges that I found in threat modelling:
1- A threat model is useless if you don't verify it. Write tests for every mitigation. Run those tests before deployment and yearly in audit. If reality doesn't match the model, update the model.
2- Assumptions, in cybersecurity are dangerous. You assume things are true but they are not.
3- Third party dependencies, for example the rate limiting you do for API is handled by third party Cloudflare, and the rate limiting silently stops working.
The above would give you the know-how, key takeaways, the minimum, main challenges for threat modelling.
Top comments (0)