Threat Modeling and Secure Requirements

A trust boundary is where data or control crosses between components with different privileges or assumptions.

2.1 Identify assets and trust boundaries

A trust boundary is where data or control crosses between components with different privileges or assumptions. Examples include browser-to-server, API-to-database, tenant-to-tenant, and application-to-third-party service.

Users and roles Entry points and external integrations Data stores and sensitive data flows Administrative and recovery pathways

2.2 Data-flow diagrams

Use a simple diagram to show processes, data stores, external entities, and flows.

For every arrow, ask: Can the input be forged? Is it authenticated? Is it authorized? Is it confidential in transit? Can it be replayed? Is it logged safely? Can it exhaust resources?

flowchart LR
    B[Browser] -->|HTTPS request| A[Web/API service]
    A -->|Parameterized query| D[(Database)]
    A -->|Short-lived credential| I[Identity provider]
    A -->|Authorized upload| F[(Private file storage)]
    A --> L[Security event log]

2.3 STRIDE threat categories

Can someone impersonate an identity or service?

Strong authentication, service identity Can data or commands be changed?

Integrity protection, authorization, safe parsing Can an action be denied because evidence is missing?

Protected, timestamped, attributable audit events Can private data leak?

Access control, minimization, encryption Denial of service Can resources be exhausted?

Limits, timeouts, quotas, load shedding Elevation of privilege Can a user gain stronger permissions?

Least privilege, server-side authorization, isolation STRIDE is a brainstorming aid, not a proof that all threats have been found.

STRIDE against the properties it threatens Property it attacks Accountability / non-repudiation

Pairing each category with the property it threatens makes it easier to pick a control: authenticity needs authentication, integrity needs integrity protection and authorization, and so on.

2.4 Threat modeling workflow

Define scope and assumptions.

Identify assets, actors, entry points, and trust boundaries.

Draw data flows.

Rate likelihood and impact using a documented scale.

Choose controls and owners.

Define verification tests.

Revisit after major architecture or dependency changes.

Threat record template

ID: TH-API-01
Asset: Private user documents
Threat: Authenticated user guesses another document ID
Weakness: Ownership not checked on download
Impact: Unauthorized disclosure
Mitigation: Object-level authorization on every read
Verification: User A cannot read User B's document
Owner: API team
Status: Open / In progress / Verified / Accepted

2.5 Security requirements

Requirements should be testable.

Weak: “The API must be secure.” Every private document read must verify access for the authenticated principal and tenant.

Passwords must never be stored in plaintext or reversible encryption.

Authentication and recovery endpoints must be rate-limited.

Sensitive traffic must use correctly configured TLS.

Logs must exclude passwords, access tokens, private keys, and full payment credentials.

Uploads must enforce configured size limits and store files outside executable paths.

Security-sensitive configuration must be version-controlled without plaintext secrets.

2.6 Abuse cases and misuse cases

Describe what a hostile or mistaken user may attempt:

Repeated password guesses Accessing another tenant's record Uploading an oversized file Replaying a payment request Abusing a password-reset flow

Causing expensive report generation repeatedly Supplying a URL that causes a backend service to contact an internal resource

For each, specify prevention, detection, response, and tests.

2.7 Risk prioritization

Use a consistent scheme such as likelihood × impact, or a recognized method such as CVSS for technical vulnerability severity. A score is a prioritization aid, not a replacement for context: internet exposure, exploitability, data sensitivity, compensating controls, and business impact matter.

A documented likelihood × impact scale Output (CPython 3.13.1):

The scale itself is a team decision; what matters is that it is written down, applied consistently and revisited when context changes. The builder in Module 1 uses the same 3 × 3 scale.

LEVELS = {"low": 1, "medium": 2, "high": 3}

def risk_score(likelihood: str, impact: str) -> tuple[int, str]:
    score = LEVELS[likelihood] * LEVELS[impact]
    band = "high" if score >= 6 else "medium" if score >= 3 else "low"
    return score, band

threats = [
    ("TH-API-01", "Read another student's document", "high", "high"),
    ("TH-API-02", "Enrollment request flood", "medium", "medium"),
    ("TH-API-03", "Missing audit trail for grade change", "low", "high"),
]
for tid, title, likelihood, impact in sorted(
        threats, key=lambda t: -risk_score(t[2], t[3])[0]):
    score, band = risk_score(likelihood, impact)
    print(f"{tid}  {score}  {band:<6}  {title}")

TH-API-01  9  high    Read another student's document
TH-API-02  4  medium  Enrollment request flood
TH-API-03  3  medium  Missing audit trail for grade change

Exercise

Threat-model a course enrollment API. Identify at least six threats from different STRIDE categories and write one testable requirement for each high-priority threat.

Quiz

? Which requirement is testable?
- "The API must be secure." :: There is no way to write a pass/fail test for this.
- "Use best practices for passwords." :: "Best practices" is not specific enough to verify.
+ "Every private document read verifies access for the authenticated principal and tenant." :: A test can try a permitted and a forbidden read and check the result.
- "Developers should be careful with uploads." :: This describes intent, not a verifiable behaviour.

? A user can change another user's grade by editing a request. Which STRIDE categories apply most directly? (select all that apply)
+ Tampering :: Data is altered improperly.
+ Elevation of privilege :: The user performs an action reserved for instructors.
- Denial of service :: Availability is not the issue here.
- Spoofing :: The user did not impersonate anyone; they used their own session.

? What is STRIDE best described as?
- A proof that all threats have been found :: The course says explicitly that it is not.
+ A brainstorming aid for enumerating threats :: Correct — it structures the search but does not guarantee completeness.
- A vulnerability scoring system :: That is closer to CVSS.
- A compliance standar
…