🎯 Threat Modeling Vocabulary

Trust boundary = a line in a Data Flow Diagram (DFD) where data moves between different trust levels, requiring validation or re-authentication.

Trust boundary crossing example	Threat question to ask
Internet → Web application (DMZ)	Who can impersonate a legitimate user? (Spoofing)
Web application → Internal API (intranet)	Can input data be tampered with in transit? (Tampering)
Application → Database	Is authorisation re-checked at this layer? (Elevation of Privilege)
User browser → CDN → Origin	Can a CDN node disclose sensitive data? (Information Disclosure)

Key vocabulary:

• Trust boundary crossing — data moving from a lower-trust to a higher-trust zone (or vice versa)
• Validation required — all input crossing a trust boundary must be validated before being processed
• Privilege transition — a change in the security context (e.g., anonymous → authenticated)
• DFD (Data Flow Diagram) — the diagramming notation used in structured threat modeling to map processes, data stores, external entities, and data flows

STRIDE is a Microsoft-developed threat modeling framework. Each letter maps to a threat category and a violated security property.

Letter	Threat	Security property violated	Example
S	Spoofing	Authentication	Forging a JWT to impersonate another user
T	Tampering	Integrity	Modifying an order amount in transit (MITM)
R	Repudiation	Non-repudiation	Denying that an action was performed (insufficient audit logs)
I	Information Disclosure	Confidentiality	Leaking PII in error messages or logs
D	Denial of Service	Availability	Flooding an API endpoint to make it unavailable
E	Elevation of Privilege	Authorisation	Exploiting a bug to gain admin rights from a regular user account

Attack surface = the total set of different points where an attacker could try to enter a system or extract data from it.

Attack surface component	Example	Reduction technique
Network-exposed endpoints	Public API, admin panel, SSH port open to internet	Close unnecessary ports; use VPN for admin access
Input entry points	Web forms, file uploads, querystring parameters	Validate and sanitise all input; disable unused endpoints
Third-party dependencies	npm packages, open-source libraries	Minimise dependency count; audit supply chain
Internal services	Microservices communicating without mutual TLS	Zero-trust internal networking; mTLS between services

Key principle: "Attack surface reduction" = remove, disable, or restrict anything not strictly necessary. Every unused feature, open port, or exposed interface is a potential entry point.

Spoofing = impersonating another user or system. The primary mitigation is strong authentication — making identity unforgeable.

STRIDE threat	Primary mitigation
Spoofing	Strong authentication (MFA, signed tokens, certificates), session binding
Tampering	HMAC / message signatures, TLS, access controls on data stores
Repudiation	Tamper-evident audit logging, digital signatures on critical actions
Information Disclosure	Encryption at rest and in transit, role-based access control
Denial of Service	Rate limiting, auto-scaling, DDoS mitigation (CDN, WAF)
Elevation of Privilege	Principle of least privilege, input validation, authorisation checks

Why the other options are incomplete: Rate limiting slows brute force but doesn't prevent spoofing with a stolen credential. Input validation prevents injection. Network segmentation limits reach but doesn't authenticate identity.

Risk acceptance = the team has evaluated the risk and consciously decided not to act on it. This is a valid and documented strategy — not inaction through ignorance.

Risk response	Action taken	Example
Accept	Acknowledge and consciously decide not to act; document in risk register	Low-severity theoretical attack vector with no known exploit
Mitigate	Implement controls to reduce likelihood or impact	Add WAF, MFA, input validation to reduce risk to acceptable level
Transfer	Shift risk to a third party (insurance, vendor SLA, contractual liability)	Cyber insurance policy covering breach costs
Avoid	Eliminate the risky activity entirely	Remove the feature that introduces the risk from the product

Risk acceptance requires documentation and sign-off — it must be a deliberate decision by a risk owner, not an oversight. Key vocabulary: "residual risk", "risk appetite", "risk register", "risk owner", "accepted with conditions".

This scenario suggests a brute-force attack, where an attacker is systematically trying many passwords to gain unauthorized access. The repeated failed login attempts are the key indicator. Brute-force attacks aim to guess credentials through sheer volume, and this aligns with known threat models.

Lateral movement describes an attacker's progression *after* successfully breaching a perimeter. Exploiting vulnerabilities and using stolen credentials are common tactics used to move between systems within the compromised network. Network scanning is often a preliminary step but doesn't inherently represent lateral movement.

This code snippet directly inserts user input into an SQL query without proper sanitization or parameterization. This allows a malicious user to craft input that alters the intended query logic, potentially gaining unauthorized access to the database. SQL injection is a classic and pervasive vulnerability.

Encryption is the most effective control for protecting sensitive data like payment card information. It renders the data unreadable if accessed without the correct decryption key. While rate limiting and other controls are important, they do not directly address the core risk of unauthorized access to payment card details.

The reviewer's comment highlights a potential injection vulnerability. Input sanitization is the process of removing or modifying potentially harmful characters from user input before it's used in an operation – in this case, validating that the `user_id` is what the application expects. The other options represent distinct threat modeling concepts.

Liam's message describes exposing sensitive information via a response header. Response headers are often used to convey metadata about the response itself, but should never contain confidential data like database credentials. Exfiltration refers to the act of taking data out, and vulnerability scanning is just a tool – this specific action is what's being described.

Sarah's message focuses on attempts to guess passwords repeatedly. This directly relates to brute-force attacks, a common threat modeled during access control analysis. Options information disclosure and privilege escalation represent different types of threats and are less relevant in this specific Slack context. Denial of Service is a broader category.

Mark's statement is about understanding the consequences of a successful attack. This aligns directly with threat modeling's core purpose: identifying and analyzing potential threats and their impact on systems. Risk assessment encompasses this, but Mark specifically asked about *what* process it was.

The comment explicitly mentions 'overwhelm the server with requests,' which is the definition of a denial-of-service (DoS) attack. Rate limiting is a *control* designed to mitigate this specific threat. Injection vulnerabilities and data breaches are different types of attacks.

David's limited validation demonstrates a lack of consideration for file uploads. File upload vulnerabilities are a common security issue where an attacker can upload malicious files (e.g., executable code) that could compromise the system. Options XSS and SQL injection relate to different attack vectors.

The PR description highlights the sensitivity of the data. This immediately necessitates a comprehensive identification of *all* potential attack vectors that could exploit this vulnerability. While impact prioritization and control implementation are important downstream activities, starting with a full attack surface analysis is crucial.