Week 13 Quiz

Test your understanding of the weekly concepts.

Format: 10 multiple-choice questions. Passing score: 70%. Time: Untimed.

Take Quiz
CSY101 Week 13 Beginner

Master threat modeling through hands-on practice. These labs build your intuition for thinking adversarially.

Cybersecurity Essentials

Track your progress through this week's content

Week Introduction

💡 Mental Model

"Think like an attacker to build like a defender." Threat modeling is the systematic process of identifying, analyzing, and prioritizing threats to a system before they become vulnerabilities.

You cannot secure what you do not understand. Threat modeling forces you to map your system's attack surface, identify assumptions that could fail, and prioritize defenses based on realistic adversary behavior. This week introduces the frameworks and tools used by professional security architects.

Learning Outcomes (Week 13 Focus)

By the end of this week, you should be able to:

  • LO1 - STRIDE Application: Apply the STRIDE methodology to identify threats across six categories (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege)
  • LO2 - Diagram Creation: Create data flow diagrams (DFDs) for security analysis
  • LO3 - Attack Trees: Build attack trees to enumerate threat scenarios and countermeasures
  • LO4 - Tool Proficiency: Use threat modeling tools (Microsoft Threat Modeling Tool, OWASP Threat Dragon) to systematically analyze systems
  • LO5 - Risk Prioritization: Prioritize threats based on likelihood and impact

Lesson 13.1 · What Is Threat Modeling? (And Why It Matters)

Definition: Threat modeling is the structured identification of potential threats, vulnerabilities, and countermeasures for a system. It answers four key questions:

  1. What are we building? (System architecture, components, data flows)
  2. What can go wrong? (Threat enumeration, attack scenarios)
  3. What should we do about it? (Mitigations, security controls)
  4. Did we do a good job? (Validation, testing, review)

When to threat model:

  • Design phase (best): Identify security issues before they're built into the system. Fixing design flaws early costs 100x less than fixing them after deployment.
  • Major changes: When adding new features, integrating third-party services, or changing architecture
  • After incidents: Retrospective threat modeling to understand what was missed
  • Compliance requirements: Many frameworks (PCI DSS, HIPAA) require threat analysis

Real-world example: The 2019 Capital One breach occurred because attackers exploited a Server-Side Request Forgery (SSRF) vulnerability to access AWS metadata and steal IAM credentials. A threat model during the design phase would have asked: "What if an attacker can make our application server send requests on their behalf?" This question would have led to implementing controls like metadata protection (IMDSv2) and network segmentation.

Lesson 13.2 · The STRIDE Methodology

STRIDE is a threat categorization framework developed by Microsoft. It provides a systematic way to think about different classes of threats:

S - Spoofing Identity

Threat: An attacker pretends to be someone/something else to gain unauthorized access.
Example: Phishing emails pretending to be from your bank, stolen authentication tokens, impersonating a trusted server
Violated Property: Authentication
Countermeasures: Multi-factor authentication, certificate validation, digital signatures, mutual TLS (mTLS)

T - Tampering with Data

Threat: Unauthorized modification of data in transit or at rest.
Example: SQL injection modifying database records, man-in-the-middle attacks altering messages, tampering with log files to hide evidence
Violated Property: Integrity
Countermeasures: Digital signatures, hashing (HMAC), input validation, parameterized queries, file integrity monitoring, tamper-evident logs

R - Repudiation

Threat: Users deny performing actions (and you can't prove they did).
Example: A user claims "I never authorized that transaction" with no audit trail, an admin deletes logs showing their actions
Violated Property: Non-repudiation (accountability)
Countermeasures: Audit logging, digital signatures, timestamps from trusted sources, write-once logs (append-only), blockchain for critical transactions

I - Information Disclosure

Threat: Exposure of information to unauthorized users.
Example: Database breach exposing customer data, verbose error messages revealing system internals, unencrypted data in transit, debug endpoints left in production
Violated Property: Confidentiality
Countermeasures: Encryption (at rest and in transit), access controls, data classification, secure error handling, principle of least privilege

D - Denial of Service (DoS)

Threat: Making a system unavailable to legitimate users.
Example: DDoS attacks flooding servers, resource exhaustion (filling disk/memory), algorithmic complexity attacks, ransomware locking systems
Violated Property: Availability
Countermeasures: Rate limiting, CDNs, auto-scaling, input validation (prevent algorithmic DoS), DDoS mitigation services (Cloudflare, AWS Shield), backups and disaster recovery

E - Elevation of Privilege

Threat: Gaining capabilities beyond what's authorized (escalating from user to admin).
Example: Exploiting OS vulnerabilities to gain root/admin, SQL injection to bypass authorization checks, JWT manipulation to change user roles, container escape to host
Violated Property: Authorization
Countermeasures: Least privilege by default, input validation, role-based access control (RBAC), security updates, sandboxing, defense in depth

How to apply STRIDE: For each component in your system (web server, database, API, etc.), walk through all six threat categories and ask "Could this happen here?" Not every threat applies to every component, but STRIDE ensures you consider all categories systematically.

Lesson 13.3 · Data Flow Diagrams (DFDs) for Security Analysis

Purpose: Data Flow Diagrams visualize how data moves through a system. For security, they help identify trust boundaries, data flows that cross security zones, and potential attack surfaces.

DFD Elements (Security-Focused)

Why Trust Boundaries Matter

Key principle: Data crossing a trust boundary is untrusted and must be validated. Most vulnerabilities occur when data crosses boundaries without proper validation or authorization checks.

Example: User input from a web form (untrusted) crosses the boundary into your application (trusted). Without validation, this enables SQL injection, XSS, command injection, etc.

Simple DFD Example: Web Application Login

[User Browser] ---(username/password)---> | Trust Boundary | ---> [Web Server]
                                                                         |
                                                          (SQL query with credentials)
                                                                         |
                                                                         v
                                                                    [Database]
                                                                         |
                                                             (return user record)
                                                                         |
                                                                         v
                        | Trust Boundary | <---(session token)--- [Web Server]
                                |
                                v
                           [User Browser]

Threats identified from this DFD:

Lesson 13.4 · Attack Trees - Enumerating Attack Paths

What is an attack tree? A hierarchical diagram showing ways an attacker could achieve a goal. The root node is the attacker's objective, and child nodes represent ways to achieve that objective.

Attack Tree Example: Compromise User Account

                        [Compromise User Account]
                                    |
                    +---------------+---------------+
                    |                               |
            [Steal Credentials]            [Bypass Authentication]
                    |                               |
        +-----------+-----------+         +---------+---------+
        |                       |         |                   |
  [Phishing]           [Credential     [SQL           [Session
                         Stuffing]     Injection]     Hijacking]
        |                       |         |                   |
   (Send fake         (Try leaked    (Inject         (Steal
    email)             passwords)      malicious       cookie)
                                       SQL)

How to use attack trees:

  1. Identify goal: What would an attacker want? (steal data, gain access, cause downtime)
  2. Enumerate paths: What are ALL the ways they could achieve this? (brainstorm with team)
  3. Add details: For each leaf node, estimate difficulty, required skills, detectability
  4. Prioritize countermeasures: Focus on paths that are easy for attackers but high-impact

Advanced: AND vs OR nodes:

Example: To access production database, attacker needs: Valid VPN credentials AND database password AND IP whitelisting bypass (AND node = defense in depth).

Lesson 13.5 · Threat Modeling Tools

Manual threat modeling works for small systems, but as systems grow, you need tools to manage complexity, collaborate with teams, and track mitigations.

Microsoft Threat Modeling Tool (TMT)

Best for: Windows-based applications, Azure cloud services
Features:

Workflow: Draw your architecture → TMT analyzes → Suggests threats based on STRIDE → You review and document mitigations

OWASP Threat Dragon

Best for: Cross-platform, web applications, open-source projects
Features:

Advantage: Lightweight, works on any OS, integrates into DevOps workflows (threat models versioned alongside code)

Other Notable Tools

Lesson 13.6 · Putting It All Together - The Threat Modeling Process

Step-by-step threat modeling workflow:

Step 1: Decompose the Application (What are we building?)

Step 2: Identify Threats (What can go wrong?)

Step 3: Mitigate Threats (What should we do about it?)

Step 4: Validate (Did we do a good job?)

Anti-pattern: Checkbox threat modeling. Do NOT just generate a report and file it away. Threat modeling is iterative—as your system evolves, threats evolve. Revisit your models quarterly or after major changes.

🎯 Hands-On Labs (Free & Essential)

Master threat modeling through hands-on practice. These labs build your intuition for thinking adversarially.

🔬 Lab 1: Microsoft Threat Modeling Tool - Model a Web Application

What you'll do: Download Microsoft Threat Modeling Tool (free), create a data flow diagram for a simple e-commerce checkout system, and let the tool automatically generate STRIDE threats.
System to model: User → Web Server → Payment API → Database
Why it matters: Industry-standard tool used by Microsoft, Azure users, and enterprise teams. Understanding automated threat generation saves hours of manual analysis.
Prerequisites: Windows PC or VM (TMT is Windows-only)
Time estimate: 2-3 hours

Steps:
1. Download Microsoft Threat Modeling Tool from aka.ms/threatmodelingtool
2. Create new threat model for "E-Commerce Checkout"
3. Add elements: External Entity (User), Process (Web Server, Payment Processor), Data Store (Database)
4. Draw data flows with trust boundaries (internet → DMZ → internal network)
5. Generate threats (right-click each element → View Threats)
6. Review suggested mitigations
7. Export report and screenshot your DFD
Deliverable: Screenshot of DFD + 5 identified threats with mitigations

🔬 Lab 2: OWASP Threat Dragon - Threat Model an API

What you'll do: Use OWASP Threat Dragon (web-based, cross-platform) to create a threat model for a RESTful API that handles user authentication and data retrieval.
System to model: Mobile App → API Gateway → Auth Service → User Database
Why it matters: APIs are increasingly targeted (OWASP API Security Top 10). Threat Dragon integrates into DevOps workflows and works on any OS.
Prerequisites: Web browser (no installation needed for web version)
Time estimate: 2-3 hours

Steps:
1. Visit threatdragon.com and use the web version
2. Create new threat model for "Mobile API"
3. Build DFD with trust boundaries (mobile app → internet → API servers → database)
4. For each component, manually identify STRIDE threats
5. Document mitigations (authentication, rate limiting, input validation, encryption)
6. Export model as JSON/PDF
Deliverable: Completed threat model with at least 8 threats identified and mitigated

🔬 Lab 3: Attack Tree Exercise - Compromise Cloud Storage

What you'll do: Build an attack tree for the goal "Gain unauthorized access to company's S3 bucket containing customer data." Enumerate at least 6 different attack paths.
Why it matters: Attack trees force you to think like an attacker and enumerate multiple paths (not just obvious ones). This reveals gaps in your defenses.
Time estimate: 1-2 hours

Starter paths to explore:
• Steal AWS credentials (how? phishing? leaked in code? stolen from developer machine?)
• Exploit misconfigured S3 bucket permissions (public access? overly permissive IAM policies?)
• Compromise an application that has S3 access (SQL injection → read AWS credentials from env variables?)
• Social engineering (convince employee to share credentials?)
• Insider threat (malicious employee with legitimate access?)
• Supply chain attack (compromise third-party service with S3 access?)
Deliverable: Hand-drawn or digital attack tree with 6+ attack paths, difficulty ratings, and countermeasures for each path

💡 Lab Strategy: Start with Microsoft TMT if you have Windows (most automated). If on Mac/Linux, use OWASP Threat Dragon. Complete the attack tree exercise to build adversarial thinking skills.

Resources

📚 Building on Prior Knowledge

This week connects to concepts you've already learned:

💡 Reflection Prompt: How would threat modeling have changed your analysis in Week 1's Lab 1? What threats would STRIDE have helped you identify that you might have missed?

Weekly Reflection Prompt

Write 200-300 words answering this prompt:

Choose ONE component from a system you analyzed earlier in CSY101 (email, banking app, LMS, etc.). Apply STRIDE to that component—walk through all six threat categories and identify at least one threat for each category.

For each threat you identify, answer:
Finally, which ONE threat poses the highest risk and why?

What good looks like: You demonstrate systematic thinking (covering all STRIDE categories, not just obvious threats). You show understanding that different threats require different countermeasures. You prioritize based on risk (likelihood + impact), not just severity.