Security Architecture Vocabulary: Threat Modeling, STRIDE, Zero Trust, and Defense-in-Depth

Security architecture is where software design meets adversarial thinking. Unlike operational security or pentesting, security architecture vocabulary is about the language of designing systems to be secure from the ground up — the words you use in threat modeling workshops, architecture reviews, security design documents, and risk acceptance discussions.

This vocabulary is used daily by security architects, senior engineers in security-sensitive domains (payments, healthcare, identity), and engineering leads who participate in security design reviews.

Section 1: Threat Modeling

Threat Modeling A structured process of identifying, analysing, and mitigating security threats during the design phase — before the system is built or changed. The goal: find security problems when they’re cheapest to fix.

“Before we build the new file upload feature, let’s run a threat model. We need to identify what an attacker could do with a malicious upload before we write any code.”

Threat Actor The entity that poses a threat: an external attacker, a malicious insider, an automated bot, a nation-state, or a competitor. Defining which threat actors are in scope helps focus design decisions.

“Our threat model considers three actors: external attackers (anonymous, internet), authenticated-but-malicious users (insider risk), and a compromised third-party vendor. State-actors are out of scope for this product.”

Attack Vector The method or pathway an attacker uses to access the system. Common vectors: network (remote code execution, SSRF), physical (device theft), software supply chain, social engineering.

“The attack vector here is SSRF — an attacker tricks our server into making a request to our internal metadata endpoint. We need to block requests to 169.254.0.0/16 from the upload processor.”

Threat A potential event that could harm the system. Defined as: a threat actor using an attack vector to exploit a vulnerability, resulting in an impact.

“Threat: An unauthenticated external attacker exploits a path traversal vulnerability in the file download endpoint to read arbitrary files from the server, including configuration containing database credentials.”

Mitigation A control or countermeasure that reduces the likelihood or impact of a threat. Mitigations can be preventive (prevent the attack from succeeding), detective (detect when an attack occurs), or corrective (limit damage after an attack).

“Mitigation for the SSRF threat: (1) Validate all URLs against an allowlist, (2) Use a separate egress-only network for the URL fetcher with no access to the internal network, (3) Enable SSRF-protection on the cloud metadata endpoint.”

Section 2: STRIDE and PASTA Frameworks

STRIDE A threat classification framework developed by Microsoft. An acronym for six threat categories:

Spoofing — impersonating another user or system
Tampering — modifying data or code
Repudiation — denying that an action occurred
Information Disclosure — exposing sensitive data
Denial of Service — making the system unavailable
Elevation of Privilege — gaining more permissions than intended

STRIDE is applied to each component in a system diagram to identify threats systematically.

“Running STRIDE against the API gateway: Spoofing → are JWT signatures validated? Tampering → is the request body signed? Repudiation → do we log authenticated user actions with non-repudiation? Information Disclosure → does the error response leak stack traces? We found three gaps in 20 minutes.”

PASTA (Process for Attack Simulation and Threat Analysis) A risk-centric threat modeling framework with seven stages, from defining business objectives to attack simulation. More rigorous than STRIDE for high-risk systems. Used in regulated industries (financial services, healthcare).

“For the payment processing system, we used PASTA because we needed a full risk analysis against business impact, not just a threat enumeration. STRIDE would have missed the business-context threats.”

Attack Tree A hierarchical diagram that models how an attacker can achieve a goal (the root node), broken down into sub-goals (branches) connected by AND and OR nodes. AND nodes require all sub-goals to be achieved; OR nodes require any one sub-goal. Used to systematically map attack paths and identify the easiest paths for an attacker.

“The attack tree for ‘attacker reads customer PII’ shows two OR branches: (1) exploit SQL injection in the search endpoint, or (2) compromise a developer machine and use their database credentials. Branch 1 is the higher-risk path — we address it first.”

Section 3: Trust Boundaries and Attack Surface

Trust Boundary A boundary in a system diagram where data crosses between zones of different trust levels — for example, between the internet (untrusted) and the application server (partially trusted), or between the application server and the database (trusted). Every crossing of a trust boundary requires validation.

“The trust boundary is at the API gateway. Anything that crosses inbound from the internet must be validated against our input schema before reaching the business logic layer. Nothing from the internet goes directly to the data tier.”

Trust Zone (Security Zone) A segment of the network or application where components have similar trust levels and permissions. Common zones: internet-facing DMZ (lowest trust), application tier, data tier (highest trust), and a separated admin zone.

“We use three trust zones: internet-facing (API gateway, CDN), application (microservices — no direct internet access), and data (databases, secret stores — only accessible from the application zone). Lateral movement across zone boundaries requires explicit rules.”

Principle of Least Privilege Every component, user, and service should have only the minimum permissions necessary to perform its function. Reduces the blast radius if a component is compromised.

“The image processing service has an IAM role with permission to read from the input S3 bucket and write to the output bucket — nothing else. If the service is compromised, the attacker can’t access the database or other services.”

Attack Surface The sum of all entry points (code, APIs, ports, interfaces, inputs) where an unauthorised user could attempt to interact with a system. A smaller attack surface means fewer places to defend.

“We reduced the attack surface by removing the internal admin HTTP endpoint and replacing it with a single authenticated gRPC endpoint on a non-standard port, accessible only from the ops VPN network.”

Attack Surface Reduction The practice of deliberately reducing the attack surface by disabling unused features, closing unused ports, removing unused dependencies, and restricting access to exposed interfaces.

“Attack surface reduction checklist: disable unused HTTP methods on the API (TRACE, PATCH, OPTIONS except CORS), remove admin endpoints from the public-facing service, pin dependency versions to prevent supply-chain attacks.”

Section 4: Defense-in-Depth

Defense-in-Depth A security architecture strategy that uses multiple, independent security controls at different layers — so that if one control fails, others still protect the system. No single point of security failure.

“Our defense-in-depth for the web API: (1) WAF at the edge, (2) API gateway authentication, (3) input validation in the service, (4) parameterised queries preventing SQL injection, (5) read-only DB user for reporting queries. An attacker must bypass all five layers.”

Security Control A safeguard or countermeasure that reduces security risk. Classified as:

Preventive: blocks the attack (firewall, authentication)
Detective: detects the attack (SIEM alerts, anomaly detection)
Corrective: limits damage after an attack (automatic revocation, snapshot restore)
Compensating: alternative control when the primary is not feasible

“We can’t patch the legacy component this month — the compensating control is network isolation: we move it into a restricted VLAN with no outbound internet access and log all inbound connections.”

Compensating Control A security control that provides equivalent protection when the standard control cannot be applied. Used when a vulnerability cannot be patched immediately, or when a legacy system cannot support the standard control.

“PCI DSS requires TLS 1.2+, but the POS terminal only supports TLS 1.0. Compensating control: the terminal communicates only through a dedicated encrypted tunnel to the payment gateway, with network monitoring for anomalous patterns.”

Section 5: Zero Trust Architecture

Zero Trust A security model where no entity — inside or outside the network perimeter — is trusted by default. Every access request is authenticated, authorised, and continuously validated, regardless of network location.

“We’ve moved to zero trust — being on the corporate VPN no longer grants access to internal services. Every service-to-service call requires a valid mTLS certificate, and every human user requires device attestation + SSO authentication.”

“Never Trust, Always Verify” The core principle of zero trust: never grant implicit trust based on network location. Always verify identity, device health, and authorisation before granting access.

Microsegmentation Dividing the network into small segments with strict access controls between each segment. In zero trust, even communication between internal services requires explicit authorisation. Limits lateral movement if one service is compromised.

“We use microsegmentation at the service mesh level — each service has a network policy that only allows inbound connections from the specific services that need to call it. A compromised billing service can’t reach the user service directly.”

BeyondCorp Google’s zero-trust network model (published 2014, now available as BeyondCorp Enterprise). Eliminates the VPN concept: all access is through an access proxy that authenticates device and user, grants access to specific applications only, and enforces continuous verification.

“We’re moving from VPN to a BeyondCorp model — the VPN is too coarse-grained. A compromised VPN credential gives access to the entire internal network. With BeyondCorp, a compromised credential only accesses the specific applications the user’s device is authorised for.”

Section 6: Security Design Review Language

Security Design Review A formal review of a system’s architecture and design for security vulnerabilities and compliance with security standards — conducted before implementation or before major changes. Different from a code security review (which examines implementation).

“Before we merge the architecture for the new payment gateway, we need a security design review. We’ll run STRIDE, check the trust boundary crossings, and validate against our security baseline.”

Risk Acceptance A formal decision to acknowledge a residual risk (a risk that remains after mitigations are applied) and proceed anyway — typically because the mitigation cost exceeds the expected impact.

“After mitigation, the residual risk of the file upload path is rated low — the attack requires a malicious PDF that bypasses our two-stage scanning. The business accepted this residual risk given the low probability and the cost of additional scanning infrastructure.”

Accept / Mitigate / Remediate / Transfer The four risk responses in security risk management:

Accept: acknowledge and tolerate the risk
Mitigate: reduce the risk with a control
Remediate: eliminate the vulnerability entirely
Transfer: shift the risk to a third party (insurance, vendor SLA)

“For the third-party SDK vulnerability: we can’t remediate it (the vendor fix is 3 months away), we mitigate with WAF rules blocking the attack pattern, and transfer the residual risk via our cyber insurance policy. We document the acceptance with CISO sign-off.”

Red/Amber/Green (RAG) Security Scoring A qualitative risk rating: 🟢 Green = acceptable risk, 🟡 Amber = needs mitigation before production, 🔴 Red = unacceptable risk, must be resolved or escalated to CISO.

“The threat model output gave us 2 red findings, 4 amber, and 8 green. We won’t go to production until both reds are resolved.”

Security Vocabulary: 40 Terms — foundational security vocabulary
English for Security Engineers — role-specific communication
How to Write a Post-Mortem in English — incident report writing
Security Vocabulary Practice — vocabulary exercises