We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningAdvanced · Security Testing & Operations
A structured process for identifying security threats, attack surfaces, and mitigations during system design. STRIDE and DREAD are common frameworks.
In short
Threat modeling is a structured process for finding security weaknesses in a system before attackers do, by mapping how data flows, listing what could go wrong at each point, and deciding how to defend against it. Teams usually do it during design using frameworks like STRIDE to enumerate threat categories and rank which ones to fix first.
In short
Threat modeling is a structured process for finding security weaknesses in a system before attackers do, by mapping how data flows, listing what could go wrong at each point, and deciding how to defend against it. Teams usually do it during design using frameworks like STRIDE to enumerate threat categories and rank which ones to fix first.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Threat Modeling across a run of lessons, not one page. These 4 alone are about 74 minutes of step-by-step reading, every one with a quiz.
Systematically identifying and prioritizing threats to your system before attackers find them.
Adversarial security exercises, one team attacks, one defends, both learn.
The organizational framework for managing data as a strategic asset: ownership, standards, policies, and accountability.
Logs as data, not text, making every log line queryable and machine-parseable.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Threat Modelingpay once,
yours for life
Threat modeling is the practice of looking at a system the way an attacker would, on purpose and on paper, before you build it or while you change it. You draw how data moves through the system, ask what an attacker could do at each step, and write down both the threats and what you will do about them.
It is not a scan and it is not a penetration test. A scanner checks running code for known bugs. A pen test attacks the deployed system. Threat modeling happens earlier, at the design level, and catches problems that no scanner can see, like a missing authorization check between two services or a token that lives too long.
The output is concrete: a diagram, a list of threats with severity, and a set of mitigations tied to specific components. A good model answers four questions. What are we building, what can go wrong, what are we going to do about it, and did we do a good enough job.
Most teams start with a data flow diagram. You draw the external users, the processes (services, APIs), the data stores (databases, queues, S3 buckets), and the arrows between them. Then you draw trust boundaries, the lines where data crosses from a less trusted zone into a more trusted one, like the edge between the public internet and your internal network, or between an unauthenticated and an authenticated request.
Every place an arrow crosses a trust boundary is where you focus. The most common framework for enumerating threats is STRIDE, from Microsoft. It gives you six categories to check each element against: Spoofing (pretending to be someone else), Tampering (changing data in transit or at rest), Repudiation (denying you did something with no audit trail), Information disclosure (leaking data), Denial of service (knocking it offline), and Elevation of privilege (gaining rights you should not have).
Once threats are listed, you rank them. DREAD is one scoring method (Damage, Reproducibility, Exploitability, Affected users, Discoverability), though many teams just use a simple high/medium/low based on likelihood times impact. The point is to spend your limited time on the threats that matter, not to file 200 tickets nobody will close.
For each high priority threat you pick a mitigation: add authentication, sign the request, encrypt the field, rate limit the endpoint, add an audit log. Then you re-check the model, which is why threat modeling is repeated whenever the design changes, not done once and filed away.
Do it for anything that handles money, personal data, authentication, or sits on a trust boundary. A new payments flow, a public API, a multi-tenant database, an admin panel: these are exactly where a missed authorization check becomes a breach. Skip the heavy version for a static marketing page or an internal tool with no sensitive data.
The big payoff is that fixing a design flaw on a whiteboard costs minutes, while fixing it after launch can mean a rewrite, an incident, and a disclosure notice. The IBM Cost of a Data Breach report puts the average breach near 4 to 5 million dollars, and some of those start from design level mistakes that a model would have surfaced.
The trade-off is time and discipline. A full STRIDE pass on a complex system can take a day or more and needs people who understand both the architecture and how attacks work. Models also rot. If you threat model once and never update it after the design changes, you get false confidence. Lightweight, frequent modeling beats one heavy document that is out of date by the next sprint.
Take a file upload feature where a user uploads a profile photo that gets stored in an S3 bucket and served back through a CDN. You draw the flow: browser, upload API, S3, CDN, browser. The trust boundary is between the public browser and your API.
Walking STRIDE: Tampering means a user could upload a malicious SVG or an oversized file, so you validate content type and cap the size. Information disclosure means a predictable file URL could let someone enumerate other people's photos, so you use random object keys and signed URLs. Elevation of privilege means the upload endpoint might let one user overwrite another user's object, so you scope the key to the authenticated user ID. Denial of service means someone could spam uploads, so you rate limit.
None of that requires exotic security knowledge. It comes from systematically asking what could go wrong at each arrow and trust boundary, which is the entire discipline in one feature.
Microsoft
Created STRIDE and the free Threat Modeling Tool, and bakes threat modeling into its Security Development Lifecycle for products like Windows and Azure.
AWS
Publishes threat modeling guidance and the open source Threat Composer tool, and uses it across service teams as part of its security review process.
OWASP
Maintains the Threat Dragon open source modeling tool and the community Threat Modeling Cheat Sheet that many engineering teams follow.
Runs design level security reviews on new services that are threat modeling in practice, mapping trust boundaries and required controls before launch.
Threat modeling happens at design time on a diagram and finds flaws in the architecture itself, like a missing authorization check. Penetration testing happens against running code and finds exploitable bugs in what was actually built. They are complementary: modeling tells you where to look, pen testing confirms whether the defenses hold.
Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. They are six categories of threat, and you check each component or data flow against all six to make sure you have not missed a class of attack.
During design, before code is written, and again whenever the design changes in a way that touches data flows, trust boundaries, authentication, or sensitive data. It is a repeated activity, not a one time document. The earlier you do it, the cheaper the fixes are.
Yes, but keep it lightweight. You do not need a 40 page document. For each new feature that handles auth, money, or user data, spend 30 minutes drawing the flow and asking what could go wrong at each step. That alone catches the most common design mistakes.
DREAD is a scoring method for ranking threats by Damage, Reproducibility, Exploitability, Affected users, and Discoverability. It has fallen out of favor because the scores are subjective and inconsistent between people. Many teams now rank threats with a simpler likelihood times impact rating or use CVSS for known vulnerabilities.
Penetration Testing
Authorized simulated attacks against a system to find security vulnerabilities before real attackers do. White-hat hackers probe for weaknesses in a controlled environment.
Zero Trust
A security model that never trusts any request by default, even from inside the network. Every request must be authenticated, authorized, and encrypted regardless of origin.
WAF
Web Application Firewall: filters and monitors HTTP traffic between a web application and the internet. Blocks SQL injection, XSS, and other OWASP top-10 attacks.
Incident Response
The structured process for detecting, containing, eradicating, and recovering from security incidents. Includes communication plans, runbooks, and post-incident reviews.
Security Audit
A systematic evaluation of a system's security posture against standards and best practices. Covers access controls, encryption, logging, vulnerability management, and compliance.
This page explains the idea. The "Threat Modeling" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Threat Modeling lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Threat Modeling in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
