Threat Modeling: STRIDE & PASTA
Mô hình Mối đe dọa: STRIDE & PASTA
STRIDE Threat Model (Microsoft)
STRIDE is the most widely used threat categorization framework and the one CISSP tests most heavily. It is asset/system-centric: for each component in a system, ask which STRIDE threats apply and what countermeasures address them.
| Letter | Category | Tiếng Việt | Threatens | Countermeasure |
|---|---|---|---|---|
| S | Spoofing | Giả mạo danh tính | Authentication | Strong auth (mTLS, HMAC-SHA256, MFA, certificate pinning) |
| T | Tampering | Giả mạo dữ liệu | Integrity | HMAC, digital signatures, input validation, TLS in transit, checksums |
| R | Repudiation | Phủ nhận hành động | Non-repudiation | Immutable audit trail + digital signatures (eSign Vendor eSign) |
| I | Information Disclosure | Tiết lộ thông tin | Confidentiality | Encryption at rest (AES-256), encryption in transit (TLS 1.3), access control, data masking |
| D | Denial of Service | Từ chối dịch vụ | Availability | Rate limiting, WAF, circuit breakers, auto-scaling, DDoS protection (CloudFlare) |
| E | Elevation of Privilege | Leo thang đặc quyền | Authorization | Least privilege, RBAC, ABAC, server-side authorization enforcement (client cannot self-promote) |
Memory Aid: Spoofing Tampering Repudiation Information Disclosure DoS Elevation of Privilege
STRIDE maps to CIA triad + Non-repudiation + Authorization: S→Auth, T→Integrity, R→Non-repudiation, I→Confidentiality, D→Availability, E→Authorization
PASTA — Process for Attack Simulation and Threat Analysis
PASTA is attacker-centric (rather than asset-centric). It asks: "How would an attacker actually attack this system?" and prioritizes risks by business impact.
Define Business Objectives
What is most valuable to protect? Regulatory obligations? Business impact of breach?
Define Technical Scope
Which systems, services, and APIs are in scope? What are the trust boundaries?
Application Decomposition
Data flow diagrams (DFDs) — how does data move? Where does it cross trust boundaries?
Threat Analysis
What threat actors exist? What are their capabilities, motivations, and likely tactics?
Vulnerability and Weakness Analysis
What weaknesses exist in the system that threats could exploit?
Attack Modeling
How would an attacker actually exploit weaknesses? Build attack trees for top scenarios.
Risk and Impact Analysis
Prioritize by business risk — likelihood × impact. Recommend controls for highest-risk scenarios first.
STRIDE vs PASTA & Attack Trees
| Attribute | STRIDE | PASTA |
|---|---|---|
| Perspective | System/asset-centric | Attacker-centric |
| Output | Threat category list per component | Risk-prioritized attack scenarios |
| Complexity | Simpler, faster (< 1 day per sprint) | Comprehensive (1-2 weeks) |
| Best for | Sprint-level design reviews, developer threat modeling | Enterprise risk analysis, regulatory audits |
Attack Trees
Hierarchical diagram representing attacker goals. Root node = attacker's objective. Branches = methods to achieve it. Leaves = specific actions. AND/OR logic for combining methods.
STRIDE Applied: Platform C eKYC Vendor eKYC Integration
| STRIDE Category | Specific Risk (eKYC context) | Mitigation |
|---|---|---|
| Spoofing | Fake Partner D partner API call without HMAC signature — attacker impersonates Partner D to submit fraudulent KYC results | HMAC-SHA256 request signing + fixed IP allowlist for Partner D source IPs |
| Tampering | Modify face_match=true result in transit between eKYC Vendor and Platform C |
mTLS (mutual TLS) for transport + eKYC Vendor signs response payload with private key; Platform C verifies signature |
| Repudiation | Customer denies submitting selfie for KYC — claims identity was stolen | Immutable audit trail with timestamp + OTP authorization step at KYC confirmation (customer must enter OTP to proceed) |
| Info Disclosure | Biometric template exposed via misconfigured API endpoint or debug logging | mTLS; biometric data NEVER stored in Platform C (eKYC Vendor-only); no PII in logs; structured logging with field masking |
| DoS | Flood KYC endpoint with bulk fake liveness requests — exhaust eKYC Vendor quota and disrupt legitimate customers | Rate limiting per user/IP (5 KYC attempts per hour); circuit breaker pattern in Temporal workflow; only Vault-authenticated calls can reach KYC endpoint |
| Elevation of Privilege | Bypass credit check stage in Temporal workflow by directly calling next-stage API without completing KYC | Workflow stage graph enforced server-side in Temporal; client cannot advance without server confirmation of prior stage completion; RBAC prevents direct stage API access |
Key Terms
Microsoft threat categorization framework — asset-centric, maps to CIA + non-repudiation + authorization
7-stage attacker-centric methodology — outputs risk-prioritized attack scenarios; better for enterprise risk analysis
Hierarchical goal decomposition — root = attacker goal, leaves = specific actions, AND/OR nodes combine methods
Maps how data flows through a system — identifies trust boundaries where STRIDE threats are most relevant
Time of Check to Time of Use — race condition; fix with atomic database transaction (SELECT FOR UPDATE)
Attacker (or customer) denies having performed an action — mitigate with digital signatures + immutable audit trail
- 1. STRIDE = threat CATEGORY framework, system/asset-centric. PASTA = attacker-centric, risk-prioritized. CISSP may ask "which is more attacker-focused?" → PASTA.
- 2. STRIDE full expansion required for exam: Spoofing / Tampering / Repudiation / Information Disclosure / Denial of Service / Elevation of Privilege. Know all 6 with their CIA/security property mapping.
- 3. TOCTOU = race condition; the fix is an ATOMIC TRANSACTION (not just re-checking the condition). Re-checking creates a second check-use gap.
- 4. Threat modeling should happen in DESIGN phase — before coding. Models created post-production are retroactive risk assessments, not architecture guidance.
- 5. Repudiation threat → requires TWO controls: digital signatures (proves the action occurred with a specific key) + immutable audit trail (time-stamped, tamper-evident log). Either alone is insufficient.
STRIDE for next integration (Partner E eCebuana payment redirect):
S: Does Partner E sign its redirect callbacks? (HMAC or signature verification?)
T: Can the payment amount be tampered between Platform C and Partner E? (signed payload?)
R: If customer disputes payment, is there an audit trail with timestamp and authorization proof?
I: What PII is included in the redirect URL? (avoid PII in URL params — use opaque tokens)
D: Rate limit Partner E-initiated callbacks per user per hour
E: Can a Partner E callback advance a loan stage without Platform C server-side confirmation?
When to run STRIDE: Required for any new external integration before coding starts. Optional for internal refactors — required when trust boundaries change.
Action: Add "STRIDE required" to Platform C's technical design document template. Populate before any new partner integration sprint begins.
Practice Questions
Q1: A customer submits someone else's ID photo for KYC verification. Which STRIDE category does this represent?
A: Spoofing — the attacker is impersonating another identity. Spoofing threatens Authentication. Mitigation: liveness detection (eKYC Vendor), face matching, document verification, and OTP to the phone number on the submitted ID.Q2: A credit limit check in Platform C's loan disbursement has a TOCTOU race condition. What database feature prevents it?
A:SELECT FOR UPDATE in PostgreSQL — acquires a row-level lock at read time, preventing any concurrent transaction from modifying the credit limit row between the check and the disbursement update. The entire check-and-update runs in a single atomic transaction.
BEGIN; SELECT credit_limit FROM loans WHERE id=? FOR UPDATE; UPDATE loans SET ...; COMMIT;Q3: STRIDE vs PASTA — which is more appropriate for a sprint-level design review of a new API endpoint?
A: STRIDE — it is simpler, faster, and asset/component-centric. A developer or architect can apply STRIDE to a new API endpoint in under an hour. PASTA's 7-stage process is better suited for enterprise-level risk analysis of entire systems.Q4: What two controls are required to mitigate a Repudiation threat?
A: (1) Digital signatures — cryptographically prove that a specific party performed the action (e.g., eSign Vendor eSign for loan agreement). (2) Immutable audit trail — tamper-evident, timestamped log of all actions that cannot be retroactively modified.Q5: At which SDLC phase should threat modeling be performed?
A: Design phase — before any code is written. This allows architects and developers to modify data flows, trust boundaries, and authentication mechanisms at minimal cost. Threat models performed post-development are retroactive and expensive to act on.