In the simplest words:<\/p>\n\n\n\n
\nThreat modeling is the process of looking at an application before or during development and asking: “How can this system be attacked, what could go wrong, and how can we prevent it?”<\/strong><\/p>\n<\/blockquote>\n\n\n\n
Think of it as a security review of your application design<\/strong>.<\/p>\n\n\n\n
Normal development thinking<\/h3>\n\n\n\n
A developer may think:<\/p>\n\n\n\n
\n“How do I make this feature work?”<\/p>\n<\/blockquote>\n\n\n\n
Threat modeling adds:<\/p>\n\n\n\n
\n“How could someone misuse or attack this feature?”<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\n2. Simple Example<\/h1>\n\n\n\n
Imagine you’re building an online shopping application:<\/p>\n\n\n
Customer\n |\n \u2193\nWeb Application\n |\n \u2193\nDatabase<\/code><\/span><\/pre>\n\n\nA developer thinks:<\/p>\n\n\n\n
\nCustomer logs in \u2192 browses products \u2192 places order \u2192 data goes into database.<\/p>\n<\/blockquote>\n\n\n\n
A security engineer asks:<\/p>\n\n\n\n
\nWhat if someone sends a fake request?<\/p>\n<\/blockquote>\n\n\n\n
\nWhat if someone steals another user’s session?<\/p>\n<\/blockquote>\n\n\n\n
\nWhat if someone modifies the price?<\/p>\n<\/blockquote>\n\n\n\n
\nWhat if someone accesses the database directly?<\/p>\n<\/blockquote>\n\n\n\n
\nWhat if someone sends thousands of requests and brings the application down?<\/p>\n<\/blockquote>\n\n\n\n
Those questions are threat modeling<\/strong>.<\/p>\n\n\n\n
\n\n\n\n3. Threat Modeling in One Sentence<\/h1>\n\n\n\n
Remember this:<\/p>\n\n\n\n
\nThreat Modeling = Understand the system \u2192 Identify what can go wrong \u2192 Assess the risk \u2192 Decide how to protect it.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\n4. When Should We Do Threat Modeling?<\/h1>\n\n\n\n
Ideally, before the application is built<\/strong>.<\/p>\n\n\n
Requirement\n \u2193\nArchitecture\n \u2193\n\ud83d\udee1\ufe0f Threat Modeling\n \u2193\nDevelopment\n \u2193\nTesting\n \u2193\nDeployment\n \u2193\nProduction<\/code><\/span><\/pre>\n\n\nBut you can also perform it on an existing application.<\/p>\n\n\n\n
It’s particularly useful when:<\/p>\n\n\n\n
\n
- Designing a new application<\/li>\n\n\n\n
- Adding a major feature<\/li>\n\n\n\n
- Adding a new API<\/li>\n\n\n\n
- Introducing a payment system<\/li>\n\n\n\n
- Adding a third-party service<\/li>\n\n\n\n
- Changing authentication<\/li>\n\n\n\n
- Moving to cloud\/Kubernetes<\/li>\n\n\n\n
- Handling sensitive information<\/li>\n\n\n\n
- Changing architecture<\/li>\n<\/ul>\n\n\n\n
\n\n\n\n5. What is OWASP Threat Dragon?<\/h1>\n\n\n\n
Now introduce the tool.<\/p>\n\n\n\n
\nOWASP Threat Dragon is an open-source tool that helps you perform and document threat modeling visually.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
The important point:<\/p>\n\n\n\n
Threat Dragon does not replace threat modeling.<\/strong><\/p>\n\n\n\n
It helps you draw the system, identify threats, document them, and track mitigations.<\/strong><\/p>\n\n\n\n
Think:<\/p>\n\n\n
Threat Modeling\n +\nThreat Dragon\n \u2193\nVisual + Documented Threat Model<\/code><\/span><\/pre>\n\n\n
\n\n\n\n6. Why Not Just Use Excel?<\/h1>\n\n\n\n
Excellent question\u2014and this should actually be discussed in a good tutorial.<\/p>\n\n\n\n
You absolutely can use Excel, Notion, Markdown, Miro, etc.<\/strong><\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
Threat<\/th> Risk<\/th> Mitigation<\/th><\/tr><\/thead> SQL Injection<\/td> High<\/td> Parameterized queries<\/td><\/tr> Data leakage<\/td> High<\/td> Encryption<\/td><\/tr> Unauthorized access<\/td> High<\/td> RBAC<\/td><\/tr> DoS<\/td> Medium<\/td> Rate limiting<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n That’s perfectly valid.<\/p>\n\n\n\n
But when the architecture becomes larger:<\/p>\n\n\n
Internet\n \u2193\nCloudFront\n \u2193\nWAF\n \u2193\nALB\n \u2193\nEKS\n \u250c\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n \u2193 \u2193 \u2193\nAPI Redis Worker\n \u2193 \u2193\nRDS S3\n \u2193\nPayment Gateway<\/code><\/span><\/pre>\n\n\nvisual modeling becomes much more useful.<\/p>\n\n\n\n
Threat Dragon helps you see the system and the security boundaries<\/strong>, rather than just maintaining a list.<\/p>\n\n\n\n
\n\n\n\n7. The Core Threat Modeling Process<\/h1>\n\n\n\n
A practical gold-standard workflow is:<\/p>\n\n\n
1. Understand the system\n \u2193\n2. Draw the architecture\n \u2193\n3. Identify trust boundaries\n \u2193\n4. Identify assets\/data\n \u2193\n5. Identify threats\n \u2193\n6. Analyze risk\n \u2193\n7. Define mitigations\n \u2193\n8. Document\n \u2193\n9. Review\n \u2193\n10. Update when architecture changes<\/code><\/span><\/pre>\n\n\nThis is more important than learning the Threat Dragon buttons.<\/p>\n\n\n\n
\n\n\n\n8. Step 1 \u2014 Understand the System<\/h1>\n\n\n\n
Before opening Threat Dragon, understand what you’re building.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
Online Banking Application<\/strong><\/p>\n\n\n
User\n \u2193\nWeb Application\n \u2193\nAuthentication Service\n \u2193\nBanking API\n \u2193\nDatabase<\/code><\/span><\/pre>\n\n\nAsk:<\/p>\n\n\n\n
\n
- Who uses the system?<\/li>\n\n\n\n
- What data does it handle?<\/li>\n\n\n\n
- What are the important components?<\/li>\n\n\n\n
- Which systems are external?<\/li>\n\n\n\n
- Where does sensitive data travel?<\/li>\n\n\n\n
- Who can access what?<\/li>\n<\/ul>\n\n\n\n
\n\n\n\n9. Step 2 \u2014 Draw the System<\/h1>\n\n\n\n
Now create a Data Flow Diagram (DFD).<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
Internet\n |\n \u2193\n [User]\n |\n \u2193\n [Web Server]\n |\n \u2193\n [API]\n \/ \\\n \/ \\\n \u2193 \u2193\n [Database] [Payment API]<\/code><\/pre>\n\n\n\nThis is where Threat Dragon becomes useful.<\/p>\n\n\n\n
\n\n\n\n10. Step 3 \u2014 Identify Trust Boundaries<\/h1>\n\n\n\n
This is one of the most important concepts.<\/p>\n\n\n\n
A trust boundary<\/strong> is a place where the level of trust changes.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
INTERNET\n |\n================================\n TRUST BOUNDARY\n================================\n |\n Application\n |\n================================\n TRUST BOUNDARY\n================================\n |\n Database<\/code><\/pre>\n\n\n\nFor example:<\/p>\n\n\n\n
Internet \u2192 Application<\/strong><\/p>\n\n\n\n
The Internet is untrusted.<\/p>\n\n\n\n
Your application cannot simply trust everything coming from the Internet.<\/p>\n\n\n\n
\n\n\n\n11. Step 4 \u2014 Identify Important Assets<\/h1>\n\n\n\n
Ask:<\/p>\n\n\n\n
\n“What are we trying to protect?”<\/p>\n<\/blockquote>\n\n\n\n
Examples:<\/p>\n\n\n\n
\n
- Passwords<\/li>\n\n\n\n
- Personal information<\/li>\n\n\n\n
- Credit-card information<\/li>\n\n\n\n
- API keys<\/li>\n\n\n\n
- Authentication tokens<\/li>\n\n\n\n
- Customer records<\/li>\n\n\n\n
- Business data<\/li>\n\n\n\n
- Source code<\/li>\n\n\n\n
- Financial transactions<\/li>\n<\/ul>\n\n\n\n
These are your assets<\/strong>.<\/p>\n\n\n\n
\n\n\n\n12. Step 5 \u2014 Identify Threats<\/h1>\n\n\n\n
Now ask:<\/p>\n\n\n\n
\n“What could an attacker do?”<\/strong><\/p>\n<\/blockquote>\n\n\n\n
This is where STRIDE<\/strong> becomes useful.<\/p>\n\n\n\n
STRIDE<\/h2>\n\n\n\n
Letter<\/th> Threat<\/th> Simple Question<\/th><\/tr><\/thead> S<\/strong><\/td> Spoofing<\/td> Can someone pretend to be another user?<\/td><\/tr> T<\/strong><\/td> Tampering<\/td> Can someone modify data?<\/td><\/tr> R<\/strong><\/td> Repudiation<\/td> Can someone deny an action?<\/td><\/tr> I<\/strong><\/td> Information Disclosure<\/td> Can someone access private information?<\/td><\/tr> D<\/strong><\/td> Denial of Service<\/td> Can someone make the system unavailable?<\/td><\/tr> E<\/strong><\/td> Elevation of Privilege<\/td> Can someone gain unauthorized privileges?<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Example<\/h3>\n\n\n\n
For:<\/p>\n\n\n
User \u2192 Login API<\/code><\/span><\/pre>\n\n\nyou might identify:<\/p>\n\n\n\n
Spoofing<\/strong><\/p>\n\n\n\n
\nAttacker obtains another user’s credentials and logs in.<\/p>\n<\/blockquote>\n\n\n\n
Mitigation:<\/p>\n\n\n\n
\nMFA + strong authentication + session controls.<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\n13. Step 6 \u2014 Analyze the Risk<\/h1>\n\n\n\n
Not every threat has the same importance.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
Threat<\/th> Likelihood<\/th> Impact<\/th> Priority<\/th><\/tr><\/thead> SQL Injection<\/td> High<\/td> High<\/td> \ud83d\udd34 Critical<\/td><\/tr> Information disclosure<\/td> Medium<\/td> High<\/td> \ud83d\udfe0 High<\/td><\/tr> DoS<\/td> Medium<\/td> Medium<\/td> \ud83d\udfe1 Medium<\/td><\/tr> Minor UI issue<\/td> Low<\/td> Low<\/td> \ud83d\udfe2 Low<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n The purpose isn’t to create 100 threats just because you can<\/strong>.<\/p>\n\n\n\n
The goal is:<\/p>\n\n\n\n
\nFind the threats that actually matter and prioritize them.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\n14. Step 7 \u2014 Define Mitigations<\/h1>\n\n\n\n
For every meaningful threat, ask:<\/p>\n\n\n\n
\n“What are we going to do about it?”<\/strong><\/p>\n<\/blockquote>\n\n\n\n
Example:<\/p>\n\n\n
Threat:\nSQL Injection\n\nRisk:\nHigh\n\nMitigation:\n- Parameterized queries\n- ORM\n- Input validation\n- Least-privilege database account\n- Security testing<\/code><\/span><\/pre>\n\n\nAnother:<\/p>\n\n\n
Threat:\nCredential theft\n\nMitigation:\n- MFA\n- Password hashing\n- Secure session management\n- Rate limiting\n- Account lockout\/risk controls<\/code><\/span><\/pre>\n\n\n
\n\n\n\n15. Step 8 \u2014 Put It Into Threat Dragon<\/h1>\n\n\n\n
Now the tool becomes useful.<\/p>\n\n\n\n
You create your model and add components such as:<\/p>\n\n\n
User\nProcess\nData Store\nExternal Entity\nData Flow\nTrust Boundary<\/code><\/span><\/pre>\n\n\nThen document threats against the relevant components or data flows.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
User\n |\n | HTTPS\n \u2193\n \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n \u2502 API \u2502\n \u2514\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2518\n |\n | SQL\n \u2193\n \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n \u2502 RDS \u2502\n \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n\nThreat:\nSQL Injection\n\nMitigation:\nParameterized queries<\/code><\/pre>\n\n\n\nNow you have an architecture + threats + mitigations<\/strong> in one model.<\/p>\n\n\n\n
\n\n\n\n16. What Threat Dragon Should NOT Become<\/h1>\n\n\n\n
This is very important for a gold-standard tutorial.<\/p>\n\n\n\n
Don’t teach:<\/p>\n\n\n\n
\n“Every project must have a 200-page threat model.”<\/p>\n<\/blockquote>\n\n\n\n
\u274c That’s bureaucracy.<\/p>\n\n\n\n
Instead:<\/p>\n\n\n\n
\nThreat modeling should be proportional to the risk and complexity of the system.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
A small internal application might need:<\/p>\n\n\n
30-minute threat-modeling exercise\n+\nsimple checklist<\/code><\/span><\/pre>\n\n\nA large banking platform might require:<\/p>\n\n\n
Multiple architecture diagrams\n+\ntrust boundaries\n+\ndetailed threat analysis\n+\nrisk assessment\n+\nmitigation tracking\n+\nsecurity review<\/code><\/span><\/pre>\n\n\n
\n\n\n\n17. The DevSecOps Connection<\/h1>\n\n\n\n
Threat modeling fits very early<\/strong> in DevSecOps.<\/p>\n\n\n\n
DEVSECOPS\n\nPlan\n \u2193\nRequirements\n \u2193\n\ud83c\udff0 Threat Modeling\n \u2193\nDesign\n \u2193\nCode\n \u2193\nSAST\n \u2193\nSCA\n \u2193\nBuild\n \u2193\nContainer Security\n \u2193\nIaC Security\n \u2193\nDAST\n \u2193\nDeploy\n \u2193\nRuntime Security\n \u2193\nMonitoring<\/code><\/pre>\n\n\n\nNotice something important:<\/p>\n\n\n\n
Threat modeling happens before most security testing.<\/strong><\/p>\n\n\n\n
Why?<\/p>\n\n\n\n
Because testing can find vulnerabilities in an implementation.<\/p>\n\n\n\n
Threat modeling can identify security problems in the design itself<\/strong>.<\/p>\n\n\n\n
\n\n\n\n18. Threat Modeling vs SAST vs SCA<\/h1>\n\n\n\n
This distinction is excellent for students:<\/p>\n\n\n\n
Practice<\/th> Main Question<\/th><\/tr><\/thead> Threat Modeling<\/strong><\/td> How could our system be attacked?<\/td><\/tr> SAST<\/strong><\/td> Is there a security problem in our source code?<\/td><\/tr> SCA<\/strong><\/td> Are our third-party dependencies vulnerable?<\/td><\/tr> DAST<\/strong><\/td> Can our running application be attacked?<\/td><\/tr> Container Security<\/strong><\/td> Is our container\/image secure?<\/td><\/tr> IaC Security<\/strong><\/td> Is our infrastructure configuration secure?<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n So:<\/p>\n\n\n
Threat Modeling\n \u2193\nFind design-level risks\n\nSAST\n \u2193\nFind code-level risks\n\nSCA\n \u2193\nFind dependency risks\n\nDAST\n \u2193\nFind runtime\/application risks<\/code><\/span><\/pre>\n\n\nThey complement each other.<\/p>\n\n\n\n
\n\n\n\n19. The Golden Mental Model<\/h1>\n\n\n\n
If you’re teaching this, I’d make students remember this:<\/p>\n\n\n\n
THREAT MODELING\n\n \"What are we building?\"\n \u2193\n \"What do we need to protect?\"\n \u2193\n \"How could it be attacked?\"\n \u2193\n \"What is the risk?\"\n \u2193\n \"How will we mitigate it?\"\n \u2193\n \"Did we document it?\"\n \u2193\n \"Did the architecture change?\"\n \u2193\n Repeat<\/code><\/pre>\n\n\n\nAnd finally:<\/p>\n\n\n\n
\nThreat Dragon is the tool. Threat modeling is the security practice.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
That’s the distinction I’d make very clear in a professional DevSecOps course.<\/p>\n","protected":false},"excerpt":{"rendered":"
1. What is Threat Modeling? In the simplest words: Threat modeling is the process of looking at an application before or during development and asking: “How can… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_joinchat":[],"footnotes":""},"categories":[11138],"tags":[],"class_list":["post-78856","post","type-post","status-publish","format-standard","hentry","category-best-tools"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/78856","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=78856"}],"version-history":[{"count":1,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/78856\/revisions"}],"predecessor-version":[{"id":78857,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/78856\/revisions\/78857"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=78856"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=78856"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=78856"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}