Overview
Threat Modeling is a structured process for identifying, analyzing, and mitigating security threats to systems based on their design and data flows. It ensures risks introduced by major changes are identified and addressed in alignment with SOC 2 CC3.2 risk assessment requirements.
Step-by-Step Process
Identify change scope
The Engineering Lead documents the major system change triggering the threat model, including new components, integrations, or data flows. The output is a written scope statement identifying in-scope systems and boundaries.
Role: Engineering Lead
Define system architecture
Engineering creates or updates an architecture diagram showing components, data stores, external dependencies, and trust boundaries. The output is a current-state architecture diagram approved by the Engineering Lead.
Role: Senior Engineer
Identify assets and data types
The team lists critical assets, sensitive data types, and security objectives (confidentiality, integrity, availability). The output is an asset and data classification list linked to the architecture.
Role: Security Engineer
Enumerate threats
Using a recognized methodology (e.g., STRIDE), the team identifies potential threats for each component and data flow. The output is a documented threat list mapped to system elements.
Role: Security Engineer
Assess risk severity
Each identified threat is rated for likelihood and impact using the company risk scoring model. The output is a prioritized threat register with risk ratings and rationale.
Role: Engineering Lead
Define mitigations
Engineering identifies existing or planned controls to mitigate each high or medium risk threat. The output is a mitigation plan with owners and target dates.
Role: Engineering Lead
Review and approve model
The completed threat model is reviewed in a design or security review meeting and formally approved. The output is an approval record with reviewer names and dates.
Role: Engineering Lead
Track remediation
Approved mitigations are tracked to completion in the issue tracking system. The output is a set of linked tickets showing remediation status and closure dates.
Role: Engineering Manager
What You Need Before Starting
- Description of the major system change or new feature
- Current architecture and data flow diagrams
- Access to threat modeling tool (OWASP Threat Dragon, Microsoft TMT, or Lucidchart)
- Company risk scoring or risk assessment methodology
Evidence Your Auditor Expects
- Threat model file or project export showing creation and last updated dates
- Architecture diagram with version history or timestamp
- Threat register including risk ratings and mitigation decisions dated within the change window
- Meeting notes or approval record showing reviewer names and approval date
- Issue tracker screenshots showing mitigation tickets with creation and closure dates
How This Looks In Your Tools
OWASP Threat Dragon
Open OWASP Threat Dragon and select “Create New Project” from the home screen. Enter the project name matching the system or change, then choose “Web Application” or “Desktop Application” as applicable. Save the project to the shared repository or approved storage location.
Navigate to the “Diagram” tab and use the left-hand palette to drag processes, data stores, and trust boundaries onto the canvas. Use the “Data Flow” connector to link components and label each flow with the data type.
Select “Threats” in the top menu and click “Add Threat” for each component or flow. Choose a STRIDE category, document the threat description, set severity, and record mitigations. Export the project (File > Export > JSON or PDF) for audit evidence.
Microsoft Threat Modeling Tool (TMT)
Launch Microsoft Threat Modeling Tool and select “Create a new model” from the start screen. Enter the model name and description, then click “Create” to open the diagram workspace.
From the right-hand stencil, drag entities such as “Process,” “Data Store,” and “External Interactor” onto the diagram. Use “Data Flow” to connect elements and double-click each element to document properties and data types.
Click “Analyze” in the top menu to automatically generate threats. Review the “Threats” tab, adjust severity and status, and document mitigations. Save the model (.tm7 file) and export a report via Report > Create Report for evidence.
Lucidchart
Log in to Lucidchart and select “New Document” from the dashboard. Choose a blank canvas or a network architecture template, then name the document to match the system change.
Use the shape libraries (Network, Cloud, or Custom Shapes) to diagram components, data stores, and external systems. Draw containers or shaded boxes to represent trust boundaries and label all data flows.
Add threat annotations using callouts or comments linked to each component, referencing STRIDE categories and risk ratings. Share the document with reviewers using the “Share” button and export a dated PDF via File > Download for audit evidence.
Common Audit Findings
- Threat model not updated for major change
- This occurs when teams treat threat modeling as a one-time activity. Prevent it by making threat modeling a required step in the change or design review checklist.
- Missing risk ratings
- Auditors see threats listed without likelihood or impact scores. Use a standard risk scoring section in the tool or template and require completion before approval.
- No documented mitigations
- Threats are identified but not tied to controls or actions. Prevent this by requiring a mitigation field and linking tickets before sign-off.
- Lack of formal approval
- Threat models exist but have no evidence of review. Require dated approval comments, meeting notes, or tool-based approval records.