Threat modeling: ask before building

Imagine a community photo-sharing service. Before choosing security tools, ask what it must protect: private photos, account access, and the ability to remove an unwanted share. Threat modeling turns those goals into design questions.

Trust boundary: A boundary where data or authority crosses between contexts with different security assumptions.

Draw the system you actually have

Show people, services, data stores, external providers, and the flows between them. Mark trust boundaries where data or authority moves between contexts with different assumptions. Include administration and recovery, not just the happy path.

An asset is something of value. A threat is a potential cause of harm. A vulnerability is a weakness that could contribute to that harm. Keeping these ideas separate prevents a list of tools from masquerading as a model.

Write a failure story with consequences

Use a concrete sentence: a former album member retains access because a cached permission decision outlives membership removal, exposing later photos. This identifies an actor, a condition, an action, and an impact. It also raises a precise design question about invalidation.

Structured prompts such as spoofing, tampering, information disclosure, and service disruption help generate questions. They do not automatically rank risk or prove every important scenario has been found. Include mistakes and dependency failures as well as deliberate misuse.

Choose a response and make it testable

A control should interrupt a part of the scenario. For the photo service, define when membership changes affect cached permissions and existing sessions. A test with synthetic albums can verify that a removed member loses the intended access.

Record remaining uncertainty, the owner, and any accepted limitation. Revisit the model when a new sharing feature, provider, or data type changes the assumptions. A small maintained model is more useful than a large diagram nobody updates.

Worked model: removal is a deadline, not a button

The community photo service’s owner supplies a concrete promise: removing an album member must stop new online reads within two minutes. The promise includes images added after removal. It does not claim to erase images already downloaded by that member. Assume the clocks in the following fictional records are aligned closely enough to compare these minute boundaries.

• T1: Mira’s album membership is removed at 10:00. The owner’s deadline for denying new reads is therefore 10:02.
• T2: An application authorization cache contains an allow decision created at 09:59, valid until 10:09. The design record says removal does not currently invalidate that entry.
• T3: At 10:03, the service records a new online read by Mira using that cache entry. The supplied delivery record confirms that the image added at 10:02 was returned.
• T4: Mira also has an image downloaded at 09:50. No mechanism for controlling previously downloaded client copies is part of the service.

PredictThe membership database is correct and the cache behaves exactly as configured. Has the security requirement nevertheless failed?

Yes. T3 records a new online read after 10:02, when the owner requires denial. Correct execution of a ten-minute cache policy does not make that policy meet a two-minute revocation promise. The observed failure is specific; it does not prove every album or access route behaves identically.

Follow authority across the cache boundary

The asset is the private image. The actor is a removed member. The important boundary is where a saved permission decision is accepted as authority for a new read. The weakness is not simply “caching is insecure”; it is the mismatch between membership changes, cache validity and the required access deadline.

Possible design responses include invalidating relevant decisions when membership changes or rechecking membership before the protected read. Their suitability depends on availability, consistency and performance needs. The requirement should specify safe behavior when current membership information is unavailable, rather than assuming the dependency never fails.

Keep the response testable: record removal time, the latest allowed decision boundary, a denied read after that boundary and a continuing member’s successful read. These are acceptance-evidence requirements, not a request to test a real service. Account sign-out alone is insufficient if a later session can still reuse a stale membership decision.

Model note: the service violated its online revocation deadline in T3. Fix and verify that decision path; treat T4 as a separate limitation of sharing copies. Revisit the model before introducing public links, offline access or a new image-delivery provider, because each can change who controls the next read.

EXPLORE THE CONCEPT

From vague worry to design decision

Choose a statement about the fictional photo service.

“Hackers could attack it”

This is too broad to guide a control or a test. Specify a resource, a boundary, and a consequence.

“Removed members may retain cached access”

This describes a condition and a consequence. Define invalidation behavior and test it.

“We installed a security product”

A product is not the threat model. Explain which scenario it changes and which assumptions remain.

A simplified learning model. It connects to no systems and uses no real data.

Turn the idea into a decision

The output is a set of reasoned decisions, not a prediction of every future incident.