Threat Modeling - Thinking Like an Attacker¶

Look, here's the truth about security. You can't defend against threats you don't understand. Most security failures happen because people build something first and then try to bolt security on afterwards. That's backwards. Threat modeling lets you think about security from the beginning.

This isn't academic theory. This is practical stuff you'll use every day in security work. Whether you're building a new application, evaluating an existing system, or responding to an incident, threat modeling helps you understand where the real risks live.

What is Threat Modeling?¶

Threat modeling is a structured approach to identifying, quantifying, and addressing security risks in a system. Think of it like putting on an attacker's hat and asking: "How could someone break this?"

Here's what that really means in practice. You systematically think through what could go wrong. You figure out how likely it is to happen. You assess how bad it would be if it did. Then you decide what you're going to do about it.

In simple terms, instead of waiting for an attack to happen, you proactively think like an attacker. You find weaknesses before they do.

The mental shift matters. You're not building something and then securing it. You're thinking about security as you build, which works way better.

Why Threat Modeling Matters¶

I've seen way too many projects where security was an afterthought. "We'll add security at the end" turns into "We don't have time for security" which turns into "How did we get breached?"

Proactive Security:

The cheapest vulnerability to fix is the one you never create. Finding security issues during design costs way less than fixing them in production. When you threat model, you catch problems early.

Here's a real example. A web application I worked on had a SQL injection vulnerability. If we'd threat modeled during design, we would have caught it before writing a single line of code. Instead, we found it in production during a security audit. Cost to fix early: zero. Cost to fix in production: developer time, testing, deployment, potential data exposure. Don't be that project.

Cost-Effective:

Every security professional knows this. Fixing bugs gets exponentially more expensive as you move through development. Design phase? You change a diagram. Coding phase? You refactor some code. Testing phase? You rework features. Production? You deal with emergency patches, downtime, customer impact, reputation damage.

Threat modeling happens early, when changes are cheap. It's the most cost-effective security activity you can do.

Risk Management: You can't secure everything equally. Resources are limited. Threat modeling helps you understand which risks matter most, so you can focus your security efforts where they'll have the biggest impact.

Real talk: A startup with 5 developers doesn't need the same threat model as a bank. Threat modeling helps you understand what's actually important for your specific situation.

Compliance: Most security frameworks (ISO 27001, NIST, PCI-DSS, HIPAA, GDPR) require some form of risk assessment. Threat modeling is how you do that systematically. Plus, when auditors ask "How do you identify security risks?" you have a real answer instead of hand-waving.

Better Architecture: When you think about threats early, you build better systems. Security isn't a bolt-on - it's built into the architecture from the start. Systems designed with security in mind are easier to secure than systems where security was an afterthought.

Basic Threat Modeling Process - A Step-by-Step Guide¶

I'm going to walk you through threat modeling in a way you can actually use. This isn't just theory - this is the process I use on real projects. Follow these steps, and you'll build a threat model that actually helps you make decisions.

1. Identify Assets - What Are You Actually Protecting?¶

This sounds obvious but most people skip this step or do it superficially. You can't protect what you haven't identified.

What are you trying to protect?

This isn't just "user data". Be specific. What data? Where is it? Who owns it? What happens if it's lost?

Types of assets: - User data: Names, emails, passwords, payment info, personal information - System access: Admin accounts, API keys, service accounts - Financial information: Credit cards, bank accounts, transaction records - Intellectual property: Source code, proprietary algorithms, business processes - Reputation: Customer trust, brand value - Availability: System uptime, service reliability

How to identify assets:

Start with a simple list: 1. What data does this system handle? 2. What would hurt if it was stolen? 3. What would hurt if it was destroyed? 4. What would hurt if it was unavailable?

Real example - E-commerce site: - Customer PII (names, addresses, emails) - Payment card data (PCI-DSS requirement) - Order history - User credentials - Product catalog and pricing - Customer payment methods - Session tokens - Admin access to system

Prioritize assets: Not all assets are equal. Classify them: - Critical: Loss would cause severe damage (customer PII, payment data) - Important: Loss would cause significant damage (order history, product catalog) - Normal: Loss would cause moderate damage (session tokens, non-sensitive logs)

Documentation format:

Asset: Customer Payment Information
Type: Financial Data
Classification: Critical
Location: Encrypted database, payment processor
Owner: Finance Department
Value: High - Regulatory fines, customer trust
Recovery: Requires payment processor integration

2. Identify Entry Points - Where Can Attackers Get In?¶

Attackers need a way in. Entry points are anywhere your system touches the outside world.

Where can attackers get in?

Web interfaces: - Login pages - Registration forms - Search functionality - File uploads - Admin panels - Customer portals

APIs: - REST endpoints - GraphQL endpoints - SOAP services - Webhooks (incoming and outgoing) - Third-party integrations

Network connections: - Internet-facing services - VPN connections - Remote access (SSH, RDP) - Internal network interfaces - Wireless networks

Physical access: - Servers in data centers - Employee workstations - Mobile devices - Backup storage - Network equipment

Other entry points: - Email (phishing, malware) - USB devices - Social engineering (people are entry points too) - Supply chain (third-party software, vendors)

How to identify entry points:

For each component in your system, ask: 1. What interfaces does it expose? 2. Who can access those interfaces? 3. What authentication/authorization protects them? 4. What's the attack surface?

Document entry points:

Entry Point: Customer Login Form
Type: Web Interface
URL: https://example.com/login
Authentication: Username/password
Authorization: Customer role
Protection: Rate limiting, CAPTCHA
Attack Vectors: Brute force, credential stuffing, session hijacking

Attack surface reduction: Every entry point is a potential vulnerability. Reduce your attack surface by: - Removing unnecessary interfaces - Restricting access to admin interfaces - Using strong authentication everywhere - Implementing network segmentation - Limiting what each interface can do

3. Identify Threats - What Could Go Wrong?¶

This is where you put on the attacker hat. Think creatively about what could go wrong.

What could go wrong?

Think in terms of attacker goals: - Steal data: Confidentiality attacks - Modify data: Integrity attacks - Stop service: Availability attacks (DoS) - Gain unauthorized access: Authorization attacks - Deny actions: Repudiation attacks - Impersonate users: Authentication attacks

Common threat categories:

Data theft: - Database breach - API abuse - Credential theft - Man-in-the-middle attacks - Insider threats

Service disruption: - DDoS attacks - Resource exhaustion - Malware/ransomware - Database corruption - Configuration errors

Unauthorized access: - Privilege escalation - Broken access controls - Session hijacking - Default credentials - Weak passwords

Data modification: - SQL injection - File upload attacks - Command injection - Cross-site scripting (XSS) - CSRF attacks

How to identify threats:

Use threat modeling frameworks (we'll cover STRIDE next): 1. STRIDE: Systematic way to think about threats 2. Attack trees: Break down complex attacks 3. Threat intelligence: Learn from real world attacks 4. Brainstorming: Think like an attacker

Document threats:

Threat: SQL Injection on Login Form
Entry Point: Customer Login API
Asset: Customer Database
Likelihood: Medium (if input validation missing)
Impact: High (Full database access possible)
Attack Vector: Malformed SQL in username/password fields
Mitigation: Parameterized queries, input validation
Status: Mitigated

4. Analyze Risks - How Bad Would It Be?¶

Not all threats are created equal. Risk analysis helps you prioritize.

How bad would it be?

Impact assessment: - Financial: Cost of breach, fines, lost revenue - Reputational: Customer trust, brand damage - Operational: System downtime, service disruption - Legal: Regulatory fines, lawsuits - Privacy: Customer data exposure

Likelihood assessment: - High: Happens frequently, well-known attack - Medium: Possible with some attacker effort - Low: Requires significant expertise/resources

Risk calculation: Risk = Impact × Likelihood

Risk matrix:

          | Low Impact | Medium Impact | High Impact
----------|-----------|--------------|------------
High Likelihood | Medium | High | Critical
Medium Likelihood | Low | Medium | High
Low Likelihood | Low | Low | Medium

Example risk analysis:

Threat: Weak Password Policy
Impact: High (Full account compromise)
Likelihood: High (Common attack, easy to execute)
Risk Level: Critical
Priority: Fix immediately

Factors affecting likelihood: - Attack complexity - Required attacker skills - Public knowledge of vulnerability - Existing protections - Attacker motivation - Value of target

Factors affecting impact: - Data sensitivity - Number of affected users - Business criticality - Regulatory requirements - Recovery cost/time - Reputation damage

5. Mitigate Threats - How to Protect?¶

Identifying threats is useless if you don't do anything about them. This step is about choosing and implementing protections.

How to protect?

Security control types:

Preventive controls (stop attacks): - Firewalls - Access controls - Encryption - Input validation - Authentication/authorization - Secure coding practices

Detective controls (find attacks): - Logging - Monitoring/SIEM - Intrusion detection systems (IDS) - Audit trails - Security alerts

Corrective controls (respond to attacks): - Incident response procedures - Backups and recovery - Patch management - Disaster recovery - Forensic capabilities

Mitigation strategies:

For each high-risk threat, choose appropriate controls: 1. Eliminate: Remove the threat entirely (best) 2. Reduce: Lower likelihood or impact 3. Transfer: Move risk (insurance, third-party) 4. Accept: Acknowledge risk exists (document decision)

Document mitigations:

Threat: SQL Injection
Risk Level: Critical
Mitigation:
  - Preventive: Parameterized queries (implemented)
  - Preventive: Input validation (implemented)
  - Preventive: WAF (Web Application Firewall) (planned)
  - Detective: SQL error logging (implemented)
  - Corrective: Incident response plan (documented)
Residual Risk: Low (after mitigations)

Defense in depth: Don't rely on a single control. Layer multiple protections: - Network firewall + host firewall + application controls - Authentication + authorization + encryption - Input validation + parameterized queries + least privilege

Cost-benefit analysis: Controls cost money and time. Balance security with practicality: - High-risk, low-cost controls: Do these first - High-risk, high-cost controls: Evaluate carefully - Low-risk controls: Might not be worth it

This basic process gets you 80% of the value from threat modeling. The frameworks and advanced techniques we'll cover next build on this foundation, but you can start using this process today on real projects.

Security+ Core Concepts in Threat Modeling¶

CIA Triad - The Foundation¶

Confidentiality: Keeping data private and secure - Encryption - Access controls - Data classification

Integrity: Ensuring data accuracy and trustworthiness - Hashing - Digital signatures - Checksums

Availability: Ensuring systems are accessible when needed - Redundancy - Backups - Disaster recovery

Authentication vs Authorization¶

Authentication: Verifying identity - Passwords - Multi-factor authentication - Biometrics

Authorization: Determining access rights - Role-based access control - Permissions - Least privilege principle

Risk Management Concepts¶

Risk = Threat × Vulnerability × Impact - Threat: Potential danger - Vulnerability: Weakness that can be exploited - Impact: Consequences of successful attack

Risk Response Strategies: - Accept: Acknowledge risk exists - Avoid: Eliminate the risk entirely - Mitigate: Reduce risk likelihood/impact - Transfer: Shift risk to another party (insurance)

STRIDE Framework¶

A simple way to categorize threats:

**S**poofing: Pretending to be someone else - Impersonation attacks - Identity theft

**T**ampering: Modifying data or code - Data alteration - Code injection

**R**epudiation: Denying actions were taken - Transaction denial - Log manipulation

**I**nformation Disclosure: Exposing sensitive data - Data leakage - Eavesdropping

**D**enial of Service: Making services unavailable - Resource exhaustion - Network flooding

**E**levation of Privilege: Gaining unauthorized access - Privilege escalation - Admin rights abuse

Basic Threat Modeling Questions¶

Ask these questions about any system:

1. What are we building?
2. Describe the system simply

3. List components and connections

4. What can go wrong?

5. Think like an attacker

6. Consider all possible abuse cases

7. What are we going to do about it?

8. Choose security controls

9. Implement protections

10. Did we do a good job?

11. Test your assumptions
12. Verify protections work

Security Controls and Mitigations¶

Preventive Controls¶

• Firewalls
• Access controls
• Encryption
• Input validation

Detective Controls¶

• Logging
• Monitoring
• Intrusion detection
• Audit trails

Corrective Controls¶

• Backups
• Patch management
• Incident response
• Disaster recovery

Simple Threat Modeling Tools¶

Mind Maps¶

Visualize components and connections:

          [Web Server]
         /      |      \
[Database]  [Cache]  [Auth Service]

Data Flow Diagrams¶

Show how data moves:

User → Login Form → Auth Check → Database

Attack Trees¶

Break down attack steps:

                 [Gain Admin Access]
                /         |          \
[Guess Password] [Find Vulnerability] [Social Engineering]

Practical Exercise¶

Try threat modeling these everyday items:

Smartphone: - Assets: Contacts, photos, messages - Threats: Theft, malware, data leakage - Protections: Passcodes, encryption, backups

Home WiFi: - Assets: Internet access, connected devices - Threats: Unauthorized access, eavesdropping - Protections: Strong password, encryption, updates

Email Account: - Assets: Messages, contacts, attachments - Threats: Phishing, hacking, data loss - Protections: 2FA, strong password, spam filters

Common Security+ Attack Types¶

Social Engineering¶

• Phishing: Fake emails
• Pretexting: Fake scenarios
• Baiting: Malicious downloads
• Tailgating: Physical access

Network Attacks¶

• Man-in-the-middle: Intercepting communications
• DoS/DDoS: Service disruption
• DNS poisoning: Redirecting traffic
• ARP spoofing: Network manipulation

Application Attacks¶

• SQL injection: Database manipulation
• XSS: Client-side code execution
• CSRF: Unauthorized actions
• Buffer overflow: Memory corruption

Advanced Threat Modeling Frameworks¶

PASTA (Process for Attack Simulation and Threat Analysis)¶

7-Step Process: 1. Define Objectives: Business objectives and security requirements 2. Define Technical Scope: System components and data flows 3. Application Decomposition: Break down application architecture 4. Threat Analysis: Identify potential threats 5. Vulnerability Analysis: Find weaknesses 6. Attack Modeling: Simulate attack paths 7. Risk Analysis and Mitigation: Assess and address risks

OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation)¶

Phases: - Organizational View: Business objectives and threats - Technological View: System vulnerabilities - Risk Analysis: Evaluate consequences and likelihood

Trike¶

Key Concepts: - Requirements Model: What system should do - Implementation Model: How system actually works - Analysis: Compare models to find discrepancies

Risk Assessment Methodologies¶

Quantitative Risk Analysis¶

Formula: Risk = Threat × Vulnerability × Impact

Steps: 1. Identify Assets: Value critical assets 2. Assess Threats: Probability of occurrence 3. Evaluate Vulnerabilities: Ease of exploitation 4. Calculate Impact: Financial and operational costs 5. Determine Risk Level: High, Medium, Low

Example Calculation: - Asset Value: $100,000 - Threat Probability: 0.3 (30%) - Vulnerability Ease: 0.7 (70%) - Impact: 0.8 (80% of asset value) - Risk = 0.3 × 0.7 × 0.8 × $100,000 = $16,800

Qualitative Risk Analysis¶

Risk Levels: - Critical: Immediate action required - High: Action within weeks - Medium: Action within months - Low: Monitor and review

Risk Matrix:

Impact →   Low     Medium    High
Threat ↓
High       Medium  High      Critical
Medium     Low     Medium    High
Low        Low     Low       Medium

Attack Trees and Modeling¶

Building Attack Trees¶

Root Node: Ultimate goal (e.g., "Steal Customer Data")

Branch Nodes: Methods to achieve goal

#Steal Customer Data
├── Exploit Web Application
│   ├── SQL Injection
│   │   ├── Find vulnerable input field
│   │   └── Craft malicious payload
│   └── XSS Attack
│       ├── Find input validation weakness
│       └── Inject malicious script
└── Social Engineering
    ├── Phishing Attack
    │   ├── Craft convincing email
    │   └── Trick user into clicking link
    └── Physical Access
        ├── Tailgate into building
        └── Access server room

Attack Tree Analysis¶

AND Nodes: All sub-goals must succeed OR Nodes: Any sub-goal can succeed

Cost Analysis: - Calculate cost of each attack path - Identify cheapest/most likely paths - Focus defenses on high-probability attacks

Security Requirements Engineering¶

Functional Security Requirements¶

Authentication: - Users must authenticate using multi-factor authentication - Passwords must meet complexity requirements - Session timeouts after 30 minutes of inactivity

Authorization: - Role-based access control (RBAC) - Principle of least privilege - Access reviews every 90 days

Auditing: - All security events logged - Logs retained for 1 year - Real-time monitoring of critical events

Non-Functional Security Requirements¶

Confidentiality: - Data encrypted at rest and in transit - Access controls prevent unauthorized viewing - Secure deletion of sensitive data

Integrity: - Data validation on input - Checksums for file integrity - Digital signatures for critical transactions

Availability: - 99.9% uptime requirement - Redundant systems for failover - Disaster recovery within 4 hours

Threat Intelligence Integration¶

Sources of Threat Intelligence¶

Open Sources: - CVE databases - Security blogs and newsletters - Government alerts (CISA, NCSC)

Commercial Sources: - Threat intelligence platforms - Security vendors - Industry-specific feeds

Internal Sources: - Security logs and alerts - Incident response reports - Vulnerability scan results

Using Threat Intelligence in Modeling¶

Steps: 1. Collect Intelligence: Gather relevant threat data 2. Analyze Patterns: Identify trends and tactics 3. Update Models: Incorporate new threats 4. Adjust Controls: Modify defenses based on intelligence

Compliance Frameworks Integration¶

Common Frameworks¶

NIST Cybersecurity Framework: - Identify: Asset management, risk assessment - Protect: Access control, data security - Detect: Continuous monitoring, anomaly detection - Respond: Incident response, communication - Recover: Backup and recovery, improvements

ISO 27001: - Risk management methodology - Security controls catalog - Certification requirements

PCI DSS (Payment Card Industry): - Specific to payment systems - 12 requirements for cardholder data protection - Quarterly vulnerability scanning

Mapping Threats to Compliance¶

Example Mapping: - Threat: SQL Injection - NIST Control: SI-10 (Information Input Validation) - ISO 27001 Control: A.12.1.3 (Application security) - PCI DSS Requirement: 6.5 (Develop and maintain secure systems)

Case Studies and Examples¶

Case Study 1: E-commerce Platform¶

System Description: - Web application with user accounts - Payment processing - Product catalog and shopping cart

Threat Model: - Assets: Customer data, payment information, inventory - Threats: Data breaches, payment fraud, DDoS attacks - Vulnerabilities: SQL injection, XSS, weak authentication

Mitigations: - Input validation and parameterized queries - Content Security Policy (CSP) - Multi-factor authentication - Web Application Firewall (WAF)

Case Study 2: Healthcare System¶

System Description: - Electronic Health Records (EHR) - Patient portal - Medical device integration

Threat Model: - Assets: Protected Health Information (PHI) - Threats: HIPAA violations, ransomware, insider threats - Vulnerabilities: Unpatched systems, weak access controls

Mitigations: - Encryption of PHI at rest and in transit - Role-based access with audit logging - Regular security assessments - Incident response plan

Case Study 3: IoT Smart Home¶

System Description: - Connected devices (cameras, thermostats, locks) - Mobile app for control - Cloud backend for data storage

Threat Model: - Assets: Personal privacy, physical security - Threats: Device hijacking, data interception, DDoS - Vulnerabilities: Weak default passwords, unencrypted communication

Mitigations: - Device authentication and authorization - Encrypted communication protocols - Regular firmware updates - Network segmentation

Tools for Threat Modeling¶

Microsoft Threat Modeling Tool¶

Features: - Data flow diagrams - STRIDE threat categorization - Risk assessment - Report generation

Process: 1. Create DFD of system 2. Identify trust boundaries 3. Analyze elements for threats 4. Mitigate identified threats

OWASP Threat Dragon¶

Features: - Web-based interface - Draw.io integration - Custom threat libraries - Export to various formats

Capabilities: - Element-based threat modeling - Custom threat properties - Mitigation suggestions - Team collaboration

Other Tools¶

PTA (Pyramid of Pain Threat Analysis): - Focuses on indicators of compromise - Helps prioritize defenses

ThreatModeler: - Automated threat modeling - Integration with development tools - Compliance reporting

Advanced Threat Modeling Techniques¶

Attack Path Analysis¶

Steps: 1. Identify Entry Points: All possible ways to access system 2. Map Attack Paths: From entry to goal 3. Calculate Complexity: Difficulty of each path 4. Assess Detection: Likelihood of detection 5. Prioritize Defenses: Focus on most dangerous paths

Threat Actor Profiling¶

Types of Actors: - Script Kiddies: Use pre-made tools, low skill - Hacktivists: Motivated by ideology - Cybercriminals: Financial gain - Nation-State: Government-sponsored - Insiders: Authorized users abusing access

Profiling Elements: - Motivation: Why they attack - Capabilities: Technical skills and resources - Opportunity: Access and timing - Detection Risk: Willingness to be caught

Supply Chain Risk Analysis¶

Third-Party Risks: - Vendor security assessments - Software supply chain attacks - Dependency vulnerabilities - Service provider risks

Assessment Steps: 1. Map Supply Chain: Identify all third parties 2. Assess Security: Review vendor security 3. Monitor Changes: Track updates and patches 4. Plan Contingencies: Backup suppliers and solutions

Integrating Threat Modeling into SDLC¶

Waterfall Model Integration¶

Requirements Phase: - Security requirements definition - Threat model initiation

Design Phase: - Architecture threat modeling - Security design reviews

Implementation Phase: - Code security reviews - Security testing

Testing Phase: - Penetration testing - Security validation

Deployment Phase: - Security configuration - Monitoring setup

Agile Integration¶

Sprint Planning: - Include security stories - Threat model updates

Daily Standups: - Security task progress - Risk discussions

Sprint Reviews: - Security feature demonstrations - Threat model validation

Retrospectives: - Security improvement identification - Process refinement

Measuring Threat Modeling Effectiveness¶

Metrics and KPIs¶

Process Metrics: - Number of threats identified - Time to complete threat model - Coverage of system components

Quality Metrics: - Threats found by testing vs. modeling - False positive/negative rates - Mitigation effectiveness

Business Metrics: - Security incidents prevented - Cost of security controls - ROI of threat modeling program

Continuous Improvement¶

Feedback Loops: - Post-incident reviews - Regular threat model updates - Lessons learned sessions

Benchmarking: - Compare against industry standards - Track improvement over time - Share best practices

Getting Started with Threat Modeling¶

1. Pick a simple system: Start with something small
2. Brainstorm threats: Think creatively
3. Prioritize risks: Focus on what matters most
4. Implement controls: Add basic protections
5. Review regularly: Threat models need updates

Next Steps¶

Threat modeling is a skill that improves with practice. Start applying it to:

• Your personal devices
• Small applications
• Home network
• Work projects

Remember: The goal isn't to eliminate all risks, but to understand them and make informed decisions about security.

Ready to continue? Let's move on to Lab Setup to create your practice environment.