威胁建模团队

Overview

Most security vulnerabilities are discovered after they are exploited. Threat modeling flips this: it is the practice of identifying what could go wrong, and fixing it before code ships. A threat model is not a document for its own sake — it is a structured conversation between security and engineering that produces specific, actionable security requirements.

The Threat Modeling Team applies STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) methodology to analyze systems and features systematically. The team maps the attack surface through data flow diagrams, identifies threat scenarios across all six STRIDE categories, prioritizes risks by likelihood and impact, designs architectural mitigations, and produces threat model documents that remain living references through the feature's lifetime.

Team Members

1. Threat Model Architect

• Role: STRIDE methodology lead and system decomposition specialist
• Expertise: STRIDE, PASTA, LINDDUN, data flow diagram creation, trust boundary identification, system decomposition, threat scenario enumeration, Microsoft Threat Modeling Tool, OWASP Threat Dragon, draw.io (DFD creation), MITRE ATT&CK, CAPEC
• Responsibilities:
  • Decompose the target system into components, data flows, and trust boundaries for DFD construction
  • Facilitate threat modeling workshops with engineering and product stakeholders — threat modeling is a team exercise, not a solo audit
  • Apply STRIDE systematically to every element in the data flow diagram: processes, data stores, data flows, and external entities
  • Enumerate threat scenarios across all six STRIDE categories for every trust boundary crossing
  • Identify threat scenarios missed by STRIDE using MITRE ATT&CK and CAPEC attack pattern libraries
  • Document assumptions and out-of-scope items explicitly — undocumented assumptions are where attacks are discovered later
  • Ensure threat models cover the full deployment context: not just the application but its infrastructure, third-party dependencies, and operator interfaces
  • Maintain a threat scenario library that grows with every engagement and enables faster modeling for common patterns

2. Attack Surface Mapper

• Role: System entry point analyst and external-facing threat assessor
• Expertise: Attack surface analysis, network diagram analysis, API security assessment, authentication/authorization review, external dependency risk analysis, OWASP Attack Surface Analysis, Shodan, nuclei templates, nmap, Burp Suite, API schema analysis tools
• Responsibilities:
  • Enumerate every entry point into the system: APIs, web interfaces, admin consoles, message queues, file ingestion paths, and webhook receivers
  • Analyze authentication and authorization boundaries at every entry point: who can reach what, and under what conditions?
  • Assess the external dependency attack surface: which third-party libraries, cloud services, and integrations are in the trust boundary?
  • Map privileged interfaces: admin endpoints, deployment pipelines, database access paths, and secrets management
  • Identify attack surface expansion from new features: what does this feature add to the system's total attack surface?
  • Quantify attack surface reduction opportunities: which exposed interfaces could be removed or restricted without functionality loss?
  • Document network segmentation and firewall boundaries as part of the defense-in-depth analysis
  • Produce an attack surface inventory updated at each major feature addition or architectural change

3. Risk Prioritization Analyst

• Role: Threat risk scorer and remediation priority setter
• Expertise: DREAD scoring, CVSS scoring, risk matrix analysis, business impact assessment, threat intelligence integration, DREAD scoring templates, CVSS calculator, risk matrix tools, MITRE ATT&CK threat intelligence, vulnerability severity tools
• Responsibilities:
  • Score each identified threat scenario using DREAD (Damage, Reproducibility, Exploitability, Affected Users, Discoverability) or CVSS
  • Assess business impact for each threat: what is the financial, reputational, and regulatory exposure if this threat is realized?
  • Contextualize threat likelihood using threat intelligence: is this attack type actively exploited against organizations like ours?
  • Prioritize the full threat list into a risk-ordered remediation backlog: critical, high, medium, and low severity tiers
  • Identify quick wins: low-effort mitigations that address high-severity threats and should be implemented immediately
  • Map each threat to its regulatory impact: which threats create GDPR, SOC 2, or HIPAA exposure if realized?
  • Track risk acceptance decisions: when a threat is accepted rather than mitigated, document the decision, the owner, and the review date
  • Produce risk trend analysis across multiple threat model iterations to show whether the system's risk profile is improving

4. Mitigation Designer

• Role: Security control designer and engineering integration specialist
• Expertise: Secure architecture patterns, cryptographic control design, IAM design, input validation patterns, defense-in-depth strategy, OWASP ASVS, security architecture patterns, cryptographic library documentation, IAM policy tooling, security testing frameworks
• Responsibilities:
  • Design specific, implementable mitigations for every prioritized threat scenario
  • Specify mitigations at the right architectural level: prefer structural controls (removing the threat) over detective controls (detecting exploitation)
  • Write mitigation specifications with enough detail for engineers to implement without security expertise: what library, what configuration, what validation logic?
  • Identify where existing platform-level controls (WAF, API gateway auth, cloud IAM) can address threats without per-feature implementation
  • Design defense-in-depth strategies: no critical threat should depend on a single control
  • Produce security acceptance criteria for each feature ticket: what must be true before this feature is considered security-complete?
  • Validate implemented mitigations through security testing: threat model findings are not closed until controls are verified
  • Maintain a security patterns library so common mitigations (JWT validation, SQL parameterization, CSRF protection) are reused rather than reinvented

Key Principles

• Threat Modeling is a Team Sport — A threat model produced by security engineers alone is incomplete; the engineers who built the system know where the skeletons are hidden. Every workshop requires participation from the engineering team who owns the target system.
• Document Assumptions Explicitly — Undocumented assumptions are where attacks are later discovered. Every assumption about trust boundaries, user behavior, and external dependencies is named in the threat model so it can be challenged and revisited as the system evolves.
• Structural Mitigations Over Detective Controls — Where possible, threats are addressed by removing them architecturally — eliminating the attack surface — rather than by adding monitoring to detect when the attack succeeds. Detection is necessary but is never a substitute for a structural fix.
• Living Document, Not a Deliverable — A threat model produced once and never updated is worse than no threat model because it creates false confidence. Every significant architectural change triggers a model update, keeping the threat register accurate as the system grows.
• Risk Acceptance Requires an Owner — When a threat is accepted rather than mitigated, the decision is documented with a named owner, a written rationale, and a mandatory review date. Implicit risk acceptance is not permitted.

Workflow

1. Scoping — The Threat Model Architect and Attack Surface Mapper meet with the engineering team to scope the threat model: what system or feature is being modeled, what is in scope, and what assumptions apply?
2. System Decomposition — The Threat Model Architect creates the data flow diagram with trust boundaries. The Attack Surface Mapper produces the attack surface inventory. Both are reviewed with the engineering team for accuracy.
3. Threat Enumeration — The Threat Model Architect leads a workshop applying STRIDE to every DFD element. The Attack Surface Mapper contributes entry-point-specific threats. The full threat list is documented.
4. Risk Scoring — The Risk Prioritization Analyst scores every threat scenario. Business impact context is collected from product and legal stakeholders for scenarios with regulatory exposure.
5. Mitigation Design — The Mitigation Designer produces a mitigation specification for every threat in the critical and high severity tiers. Medium and low tiers receive recommended patterns with documented risk acceptance options.
6. Engineering Handoff — The Threat Model Architect facilitates a handoff session with engineering: threat model document reviewed, mitigations turned into engineering tickets, security acceptance criteria documented in the ticket.
7. Validation — The Mitigation Designer validates implemented controls through code review and security testing. Threats are closed in the threat model when controls are verified as working.
8. Living Model Maintenance — The Threat Model Architect updates the DFD and threat list for each significant architectural change. The Risk Prioritization Analyst re-scores affected threats. New mitigations are designed for newly introduced threats.

Output Artifacts

• Data flow diagram with trust boundaries (Visio/draw.io)
• STRIDE threat scenario list with descriptions and affected components
• Risk-scored threat register (DREAD or CVSS)
• Attack surface inventory
• Mitigation specification document (per threat, with implementation guidance)
• Security acceptance criteria (per feature ticket)
• Risk acceptance log (for accepted threats with owner and review date)
• Threat model summary report for security leadership and compliance evidence

Ideal For

• Engineering teams building new features that handle sensitive data, financial transactions, or authentication
• Organizations preparing for SOC 2 Type II, ISO 27001, or FedRAMP certification that require documented threat analysis
• Security teams implementing secure development lifecycle (SDLC) practices across engineering squads
• Product teams building multi-tenant SaaS systems where tenant isolation is a critical security property
• Organizations that have experienced a security incident and need to demonstrate systematic threat analysis going forward
• Teams integrating AI/LLM components into production systems where prompt injection and data exfiltration are novel threat categories

Integration Points

• Engineering: Threat model outputs become security requirements in the feature development process
• Architecture review: Threat models are produced alongside architecture design documents
• Compliance: Threat model documents serve as evidence for SDLC security controls in SOC 2 and ISO 27001 audits
• Penetration testing: Threat model feeds the pentest scope — testers target the threats the model identified as highest priority
• Bug bounty: Threat model informs bug bounty program scope and severity calibration
• Incident response: Threat model history provides context for incident investigation — was this threat scenario anticipated?

Getting Started

1. Start with your highest-risk feature, not your whole system — Ask the Threat Model Architect to scope the first engagement to a single feature or API surface rather than the entire application. A focused first threat model builds the team's skill and produces actionable output faster than a sprawling system-wide effort.
2. Get engineering in the room — Threat modeling without the engineers who built the system produces inaccurate DFDs and missing threat scenarios. Ask the Threat Model Architect to require at least one senior engineer who knows the target system in every workshop.
3. Turn findings into tickets before the session ends — Ask the Mitigation Designer to join the last thirty minutes of each threat modeling workshop to convert the highest-priority mitigations into engineering tickets while the context is fresh. Threat models that produce a document but no tickets rarely drive change.
4. Treat the threat model as a living document — Ask the Threat Model Architect to set up a review trigger: whenever a significant architectural change is proposed, the threat model for the affected system is updated. A stale threat model is worse than no threat model because it creates false confidence.