Introduction: Proactive Security by Design
In Lesson 5.1, we established the foundations of application security and secure software development principles for financial institutions. We explored the application threat landscape, including the threats, vulnerabilities, and attacks that target financial applications. We examined the Secure Software Development Lifecycle (SSDLC) and the integration of security into each phase of development. We analyzed DevSecOps principles and the importance of automation, integration, and culture. We also explored the core security principles that guide secure application development.
However, understanding threats and security principles is only the first step. Financial institutions must also proactively identify and mitigate threats during the design phase of application development. This is the purpose of Threat Modeling.
Threat Modeling is a structured process for identifying, analyzing, and mitigating threats to applications and systems. It is performed early in the development lifecycle, during the design phase, to identify potential security issues before they are implemented. Threat modeling helps answer critical questions such as:
-
“What threats does this application face?”
-
“Where are the vulnerabilities?”
-
“How can we mitigate these threats?”
Threat modeling is essential for financial applications because it enables proactive security by design. By identifying threats early, organizations can design mitigations that are less expensive and more effective than retrofitting security after deployment.
This lesson provides a comprehensive analysis of threat modeling for financial applications. We begin by examining the Threat Modeling Process: Asset Identification → Architecture Analysis → Threat Identification → Vulnerability Analysis → Risk Assessment → Mitigation Planning → Documentation.
We then examine the Threat Modeling Methodologies, including STRIDE, DREAD, PASTA, and OWASP Threat Dragon. We derive the STRIDE Threat Model: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
We also examine the Threat Modeling Frameworks, including the Microsoft Threat Modeling Tool and OWASP Threat Dragon. We derive the Threat Modeling Maturity Score: T_MM = A_sset * A_rchitecture * T_hreat * V_ulnerability * R_isk * M_itigation * D_ocumentation.
By the end, you will have a complete understanding of threat modeling for financial applications, and be able to identify and mitigate threats in financial applications.
Learning Objectives
Upon completion of this lesson, you will be able to:
-
Analyze the Threat Modeling Process: Asset Identification → Architecture Analysis → Threat Identification → Vulnerability Analysis → Risk Assessment → Mitigation Planning → Documentation.
-
Derive the STRIDE Threat Model:
Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. -
Analyze the Threat Modeling Methodologies: STRIDE, DREAD, PASTA, and OWASP Threat Dragon.
-
Analyze the Threat Modeling Frameworks: Microsoft Threat Modeling Tool and OWASP Threat Dragon.
-
Derive the Threat Modeling Maturity Score:
T_MM = A_sset * A_rchitecture * T_hreat * V_ulnerability * R_isk * M_itigation * D_ocumentation. -
Apply threat modeling to financial applications.
-
Design mitigations for identified threats.
Part 1: The Threat Modeling Process
1.1 The Process Definition
The Threat Modeling Process consists of seven steps:
Threat Modeling Process = Asset Identification -> Architecture Analysis -> Threat Identification -> Vulnerability Analysis -> Risk Assessment -> Mitigation Planning -> Documentation
1.2 The Seven Steps
| Step | Description | Key Activities |
|---|---|---|
| 1. Asset Identification | Identify assets that need protection | Data inventory, asset classification |
| 2. Architecture Analysis | Analyze the application architecture | Data flow diagrams, trust boundaries |
| 3. Threat Identification | Identify threats to the application | STRIDE, attack trees, threat libraries |
| 4. Vulnerability Analysis | Identify vulnerabilities | Vulnerability scanning, code review |
| 5. Risk Assessment | Assess the risks | Risk scoring, prioritization |
| 6. Mitigation Planning | Plan mitigations | Controls, countermeasures, validation |
| 7. Documentation | Document the threat model | Threat model document, findings |
1.3 Asset Identification
Assets: Data, systems, processes, and people that need protection.
| Asset Type | Description | Examples |
|---|---|---|
| Data | Sensitive information | Customer PII, financial data, credentials |
| Systems | Software and hardware | Applications, servers, databases |
| Processes | Business processes | Transactions, authentication, authorization |
| People | Users and administrators | Customers, employees, administrators |
1.4 Architecture Analysis
Purpose: Understand the application architecture and identify trust boundaries.
Tools:
-
Data Flow Diagrams (DFDs)
-
Trust Boundaries
-
Component Diagrams
1.5 Threat Identification
Purpose: Identify potential threats to the application.
Techniques:
-
STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege)
-
Attack Trees
-
Threat Libraries (CAPEC, CWE)
1.6 Vulnerability Analysis
Purpose: Identify vulnerabilities that could be exploited.
Techniques:
-
Vulnerability Scanning
-
Code Review
-
Penetration Testing
1.7 Risk Assessment
Purpose: Assess the risks of identified threats and vulnerabilities.
Risk Formula:
Risk = Likelihood * Impact
1.8 Mitigation Planning
Purpose: Plan mitigations for identified risks.
Mitigation Strategies:
-
Avoidance: Eliminate the risk
-
Reduction: Reduce the likelihood or impact
-
Transfer: Transfer the risk (e.g., insurance)
-
Acceptance: Accept the risk
1.9 Documentation
Purpose: Document the threat model for future reference.
Documentation Contents:
-
Asset inventory
-
Architecture diagrams
-
Threat list
-
Vulnerability list
-
Risk assessment
-
Mitigation plan
Threat Modeling Process (Visual): ┌─────────────────────────────────────────────────────────────────────────┐ | | | Step 1: Asset Identification │ | ┌─────────────────────────────────────────────────────────────────┐ │ | │ • Identify assets (data, systems, processes, people) │ │ | │ • Classify assets by criticality │ │ | └────────────────────────┬────────────────────────────────────────┘ │ | │ | | ▼ | | Step 2: Architecture Analysis │ | ┌─────────────────────────────────────────────────────────────────┐ │ | │ • Analyze architecture │ │ | │ • Create data flow diagrams │ │ | │ • Identify trust boundaries │ │ | └────────────────────────┬────────────────────────────────────────┘ │ | │ | | ▼ | | Step 3: Threat Identification │ | ┌─────────────────────────────────────────────────────────────────┐ │ | │ • Identify threats (STRIDE, attack trees) │ │ | │ • Use threat libraries (CAPEC, CWE) │ │ | └────────────────────────┬────────────────────────────────────────┘ │ | │ | | ▼ | | Step 4: Vulnerability Analysis │ | ┌─────────────────────────────────────────────────────────────────┐ │ | │ • Identify vulnerabilities │ │ | │ • Vulnerability scanning, code review │ │ | └────────────────────────┬────────────────────────────────────────┘ │ | │ | | ▼ | | Step 5: Risk Assessment │ | ┌─────────────────────────────────────────────────────────────────┐ │ | │ • Assess risks (likelihood * impact) │ │ | │ • Prioritize risks │ │ | └────────────────────────┬────────────────────────────────────────┘ │ | │ | | ▼ | | Step 6: Mitigation Planning │ | ┌─────────────────────────────────────────────────────────────────┐ │ | │ • Plan mitigations │ │ | │ • Identify controls, countermeasures │ │ | └────────────────────────┬────────────────────────────────────────┘ │ | │ | | ▼ | | Step 7: Documentation │ | ┌─────────────────────────────────────────────────────────────────┐ │ | │ • Document the threat model │ │ | │ • Document findings, mitigations │ │ | └─────────────────────────────────────────────────────────────────┘ │ | | └─────────────────────────────────────────────────────────────────────────┘
Part 2: STRIDE Threat Model
2.1 The STRIDE Definition
STRIDE is a threat categorization model developed by Microsoft for identifying threats in software applications.
STRIDE = {Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege}
2.2 STRIDE Categories
| Category | Description | Security Objective | Example Threat |
|---|---|---|---|
| Spoofing | Impersonating another user or system | Authentication | Session hijacking, credential theft |
| Tampering | Modifying data or code | Integrity | SQL injection, file modification |
| Repudiation | Denying an action | Non-repudiation | Disputing a transaction |
| Information Disclosure | Exposing sensitive information | Confidentiality | Data breach, data leakage |
| Denial of Service | Denying service to legitimate users | Availability | DDoS, resource exhaustion |
| Elevation of Privilege | Gaining unauthorized privileges | Authorization | Privilege escalation, admin takeover |
2.3 STRIDE Mapping to Security Objectives
| Security Objective | STRIDE Category |
|---|---|
| Authentication | Spoofing |
| Integrity | Tampering |
| Non-Repudiation | Repudiation |
| Confidentiality | Information Disclosure |
| Availability | Denial of Service |
| Authorization | Elevation of Privilege |
2.4 STRIDE Application Example
| Component | STRIDE Threat | Mitigation |
|---|---|---|
| User Authentication | Spoofing | MFA, strong passwords |
| Database | Tampering | Integrity checks, input validation |
| Transaction Logs | Repudiation | Digital signatures, audit trails |
| Customer Data | Information Disclosure | Encryption, access controls |
| Web Server | Denial of Service | DDoS protection, rate limiting |
| Admin Interface | Elevation of Privilege | RBAC, least privilege |
STRIDE Threat Model (Visual): ┌─────────────────────────────────────────────────────────────────────────┐ | | | ╔═══════════════════════════════════════════════════════════════════╗ | | ║ Spoofing ║ | | ╠═══════════════════════════════════════════════════════════════════╣ | | ║ Security Objective: Authentication ║ | | ║ Example: Session hijacking, credential theft ║ | | ║ Mitigation: MFA, strong authentication ║ | | ╚═══════════════════════════════════════════════════════════════════╝ | | | | ╔═══════════════════════════════════════════════════════════════════╗ | | ║ Tampering ║ | | ╠═══════════════════════════════════════════════════════════════════╣ | | ║ Security Objective: Integrity ║ | | ║ Example: SQL injection, file modification ║ | | ║ Mitigation: Input validation, integrity checks ║ | | ╚═══════════════════════════════════════════════════════════════════╝ | | | | ╔═══════════════════════════════════════════════════════════════════╗ | | ║ Repudiation ║ | | ╠═══════════════════════════════════════════════════════════════════╣ | | ║ Security Objective: Non-repudiation ║ | | ║ Example: Disputing a transaction ║ | | ║ Mitigation: Digital signatures, audit trails ║ | | ╚═══════════════════════════════════════════════════════════════════╝ | | | | ╔═══════════════════════════════════════════════════════════════════╗ | | ║ Information Disclosure ║ | | ╠═══════════════════════════════════════════════════════════════════╣ | | ║ Security Objective: Confidentiality ║ | | ║ Example: Data breach, data leakage ║ | | ║ Mitigation: Encryption, access controls ║ | | ╚═══════════════════════════════════════════════════════════════════╝ | | | | ╔═══════════════════════════════════════════════════════════════════╗ | | ║ Denial of Service ║ | | ╠═══════════════════════════════════════════════════════════════════╣ | | ║ Security Objective: Availability ║ | | ║ Example: DDoS, resource exhaustion ║ | | ║ Mitigation: DDoS protection, rate limiting ║ | | ╚═══════════════════════════════════════════════════════════════════╝ | | | | ╔═══════════════════════════════════════════════════════════════════╗ | | ║ Elevation of Privilege ║ | | ╠═══════════════════════════════════════════════════════════════════╣ | | ║ Security Objective: Authorization ║ | | ║ Example: Privilege escalation, admin takeover ║ | | ║ Mitigation: RBAC, least privilege ║ | | ╚═══════════════════════════════════════════════════════════════════╝ | | | └─────────────────────────────────────────────────────────────────────────┘
Part 3: Threat Modeling Methodologies
3.1 STRIDE
| Aspect | Description |
|---|---|
| Purpose | Threat identification and categorization |
| Method | Categorize threats into six categories |
| Output | List of threats by category |
| Best For | Early design phase, Microsoft environments |
3.2 DREAD
Definition: DREAD is a risk rating model that evaluates threats based on five criteria.
DREAD = {Damage, Reproducibility, Exploitability, Affected Users, Discoverability}
| Criteria | Description | Scoring (1-10) |
|---|---|---|
| Damage | How much damage would an attack cause? | 1 (Low) – 10 (High) |
| Reproducibility | How easy is it to reproduce the attack? | 1 (Hard) – 10 (Easy) |
| Exploitability | How easy is it to exploit the vulnerability? | 1 (Hard) – 10 (Easy) |
| Affected Users | How many users would be affected? | 1 (Few) – 10 (Many) |
| Discoverability | How easy is it to discover the vulnerability? | 1 (Hard) – 10 (Easy) |
3.3 PASTA
Definition: PASTA (Process for Attack Simulation and Threat Analysis) is a seven-step threat modeling methodology.
| Step | Description |
|---|---|
| 1. Definition of Objectives | Define business objectives and security requirements |
| 2. Definition of Technical Scope | Define the technical scope of the application |
| 3. Application Decomposition | Decompose the application into components |
| 4. Threat Analysis | Identify and analyze threats |
| 5. Vulnerability Analysis | Identify and analyze vulnerabilities |
| 6. Attack Modeling | Model attacks against the application |
| 7. Risk Analysis | Analyze and prioritize risks |
3.4 OWASP Threat Dragon
Definition: OWASP Threat Dragon is an open-source threat modeling tool.
| Feature | Description |
|---|---|
| Diagramming | Create threat models using diagrams |
| Threat Libraries | Use built-in threat libraries (STRIDE, OWASP Top 10) |
| Reporting | Generate threat model reports |
| Collaboration | Share threat models with team |
3.5 Threat Modeling Methodology Comparison
| Methodology | Approach | Best For | Complexity |
|---|---|---|---|
| STRIDE | Threat categorization | Early design phase | Low |
| DREAD | Risk rating | Risk prioritization | Low |
| PASTA | Attack simulation | Complex applications | High |
| OWASP Threat Dragon | Tool-based | Any application | Medium |
Part 4: The Threat Modeling Maturity Score
4.1 The Model Definition
The Threat Modeling Maturity Score quantifies the maturity of threat modeling practices:
T_MM = A_sset * A_rchitecture * T_hreat * V_ulnerability * R_isk * M_itigation * D_ocumentation
Where:
-
A_ssetis the Asset Score (0-1) -
A_rchitectureis the Architecture Score (0-1) -
T_hreatis the Threat Score (0-1) -
V_ulnerabilityis the Vulnerability Score (0-1) -
R_iskis the Risk Score (0-1) -
M_itigationis the Mitigation Score (0-1) -
D_ocumentationis the Documentation Score (0-1)
| Component | Description | Scoring Factors |
|---|---|---|
| Asset (A) | Asset identification and classification | Completeness, accuracy |
| Architecture (A) | Architecture analysis | DFDs, trust boundaries |
| Threat (T) | Threat identification | STRIDE, attack trees |
| Vulnerability (V) | Vulnerability analysis | Scanning, code review |
| Risk (R) | Risk assessment | Likelihood, impact |
| Mitigation (M) | Mitigation planning | Controls, countermeasures |
| Documentation (D) | Documentation | Threat model document |
4.2 Interpretation
| Score | Interpretation | Recommended Action |
|---|---|---|
T_MM >= 0.90 |
Excellent | Maintain and monitor |
0.80 <= T_MM < 0.90 |
Good | Continue improvement |
0.60 <= T_MM < 0.80 |
Fair | Identify and address gaps |
T_MM < 0.60 |
Poor | Immediate improvement required |
Summary and Bridge to Lesson 5.3
We have now completed the comprehensive analysis of threat modeling for financial applications. You have learned:
-
Threat Modeling Process: Asset Identification → Architecture Analysis → Threat Identification → Vulnerability Analysis → Risk Assessment → Mitigation Planning → Documentation.
-
STRIDE Threat Model:
Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. -
Threat Modeling Methodologies: STRIDE, DREAD, PASTA, and OWASP Threat Dragon.
-
Threat Modeling Maturity Score:
T_MM = A_sset * A_rchitecture * T_hreat * V_ulnerability * R_isk * M_itigation * D_ocumentation.
In Lesson 5.3, we will explore Secure Coding Practices for Financial Applications, analyzing the secure coding standards and practices for financial applications.
Ready to continue? Just say “Proceed to Lesson 5.3” and I will deliver the next lesson with the same exhaustive depth.