The Student's Threat Model

Step 1: Review the architecture

Before building the threat model, consolidate what you know about Dimitar's platform. Two attack surfaces share a backend:

• Consumer web platform. WordPress + WooCommerce. Customer accounts with order history. Stripe payment processing. About 200 consumer accounts.
• Restaurant API. Custom REST API. API key authentication. 12 restaurant partners. Wholesale pricing (potentially differentiated per partner). Order management and invoicing.

Both connect to the same database. Both serve different users with different access patterns. A vulnerability on one side may affect data accessible from the other.

Review Dimitar's responses to your questions. What did he reveal that he hadn't mentioned initially? What did he not answer because he does not know?

Step 2: Author the STRIDE threat model

No template is provided this time. You decide the structure.

For each STRIDE category, identify threats specific to this system. The word "specific" is doing work here -- AI will produce a generic STRIDE model that applies identically to any web application. That is not a threat model. That is a checklist.

Spoofing. What authentication exists and how could it be circumvented? Consumer login and restaurant API keys are different authentication mechanisms with different spoofing risks. A brute-forced API key and a hijacked session cookie are different attacks.

Tampering. What data could be modified if access controls fail? Consumer orders, wholesale pricing, product information -- each has different business impact. Tampered wholesale pricing is a direct revenue problem.

Repudiation. What actions could someone deny performing? An API request that modifies pricing -- can it be attributed to a specific partner?

Information Disclosure. What sensitive data exists and how is it compartmentalised? Consumer data, partner-specific pricing, wine club member details -- different data with different exposure paths.

Denial of Service. What would take the platform offline? During harvest season, when orders are flowing daily, what downtime is Dimitar most concerned about?

Elevation of Privilege. Can a consumer gain partner access? Can one partner access another's data? Can either reach administrative functions?

Tailor each threat to what you know about this system. The threat model should reference the architecture, the data, and the business context -- not generic threat descriptions.

Step 3: Select ATT&CK techniques

The threat model determines which techniques to test. Select ATT&CK techniques based on the threats you identified, not on AI's defaults.

If the API uses key-based authentication, T1078 (Valid Accounts) is relevant -- can keys be guessed or stolen? If the web platform has input fields exposed to untrusted users, T1190 (Exploit Public-Facing Application) is relevant. If the consumer and partner interfaces share a backend, T1530 (Data from Cloud Storage Object) may apply if data compartmentalisation is weak.

AI defaults to popular techniques (T1059, T1078) regardless of the target. Your selections should reference the threat model: "I'm testing T1190 because the STRIDE model identified input tampering risks on the consumer platform's search and ordering forms."

Step 4: Plan the engagement decomposition

Before starting any scanning or exploitation, plan the sequence. Each phase depends on the output of the previous one.

1. Passive reconnaissance -- done. Target profile built.
2. Vulnerability scanning -- next. Both surfaces. Scanner scope configured before execution.
3. Web exploitation -- after scanning. Test confirmed and probable findings.
4. API exploitation -- after web exploitation. Different techniques, different tools.
5. Detection -- after exploitation. Rules based on actual attack patterns.
6. Remediation -- after detection. Prevention-plus-detection pairing.
7. Hardening/compliance -- after remediation. CIS Benchmarks and OWASP ASVS.
8. Reporting -- after everything. Dual-audience report for Dimitar and his developer.

Use plan mode in Claude Code to make this decomposition explicit:

/plan

The plan should show the dependency chain. Detection rules depend on exploitation patterns. Remediation depends on detection. Each step has a reason for its position.

Step 5: Write constraints

Before starting the scanning phase, write explicit constraints:

• Scanner scope: only authorised targets in the scope document
• All Sigma rules must use the field names from the Loki log format
• Remediation must not break the application's functionality
• All findings documented with evidence at the time of discovery
• No testing of the mobile app or Stripe

Constraints tell AI what NOT to do. In security work, this has an ethical dimension. Scope constraints are not preferences -- they are professional requirements.