Break Attack Paths With Layered Controls

By the end of this lesson, you will be able to...

• Place preventive, detective, response, and recovery controls against specific steps in an attack path.

• Explain what each control changes, what it depends on, and what it cannot undo.

• Choose a layered control argument that supports a stated security requirement without confusing it with the requirement.

Idea in one sentence: Controls are useful when they interrupt, expose, limit, or recover from a named step in a threat path—not when they are simply added to a security shopping list.

Core Insight

ShareBox has a requirement: for a proposal shared with a named partner, the download endpoint must return content only when the verified requester identity matches the recorded recipient. The team now asks, “Which controls should we add?”

The tempting answer is one strong control: require a sign-in. It helps, but the team must still ask whether the identity matches the recipient, whether a valid link was revoked, what evidence remains after a rejected request, and what happens if the wrong person received a file before the team learned about it.

The stronger model is a layered control argument. Each layer changes a particular transition in the attack path. Some prevent success; some expose activity; some limit future use; some help recover from consequences. No layer gets credit for work it cannot perform.

The Path We Need to Break

The following is a teaching model, not an incident record.

The requirement from lesson 009 changes step 3: a valid link alone must not authorize delivery. Controls now make that required behavior real and provide protection around the other steps.

The Initial Model: Add a Familiar Control

“Add authentication” is a reasonable first idea. It stops a person with only a link from completing step 3 if the endpoint actually requires a verified identity. But it is incomplete.

• A verified identity may belong to partner-b, not the recorded partner-a.
• Authentication does not revoke a link already issued to the wrong person.
• It does not tell the sender whether an earlier delivery occurred.
• It cannot make a copied proposal unread after the response has left the service.

The missing idea is not “more controls” in the abstract. It is placing complementary controls where they change different conditions of the same path.

Map Controls to Path Breakpoints

Start with one question for every proposed control: which step or condition does it change?

| Layer | Control example | Path breakpoint | What it does | What it does not do | | --- | --- | --- | --- | | Preventive | Require a verified identity that matches the share’s recorded recipient. | Step 3, authorization decision. | Stops link possession alone from authorizing delivery. | Does not retract content delivered earlier. | | Preventive | Check expiry and revocation before every delivery. | Step 2–3, current share state. | Stops a stale or revoked link from continuing. | Does not establish who is requesting. | | Limiting | Use a short sharing period and require the sender to name a recipient. | Steps 0–1, opportunity to reuse or spread a link. | Reduces exposure time and accidental sharing routes. | Does not block use while the link is valid. | | Detective | Record a privacy-appropriate download decision and relevant share identifier. | Step 3–4, evidence of an attempt or delivery. | Makes later investigation and review possible. | Does not prevent the response. | | Response | Let the sender revoke a share and invalidate it at the endpoint. | Future attempts after a concern. | Stops later uses of that share. | Cannot undo a completed read. | | Recovery | Reissue a changed proposal and notify owners when a high-impact disclosure is confirmed. | After a confirmed consequence. | Limits the business impact of information that must change. | Does not erase a copy the recipient already made. |

The labels describe jobs, not products. A revocation feature is a response because it changes future requests after a concern. A log is detective because it creates evidence. Calling either one “prevention” would hide the remaining path.

A Worked Layered Trace

Suppose an unintended person has a forwarded but still-valid link. Follow the path with the control map in place.

The central preventive control is the identity-to-recipient match. Expiry and revocation make the share state less forgiving. Evidence and response cover what prevention cannot guarantee. The path is stronger because the controls have distinct failure modes rather than because there are more names in a table.

Dependencies Make Layers Honest

A control only helps if its dependencies are true. Make them visible before calling the design complete.

This does not turn the lesson into operations work. It exposes the assumptions that a design relies on. Lesson 013 will develop verification and signals in more detail.

Trade-offs and Limits

Layering improves resilience because one failed or late control does not make every other layer useless. The trade-off is complexity: recipient records, identity integration, revocation state, evidence handling, and recovery ownership all require product and operational work.

The right layer depends on the promise. Requiring identity binding is sensible for a named commercial proposal. It may be needless friction for a deliberately public brochure. Short expiry reduces exposure but can disrupt legitimate negotiations. Detailed evidence helps investigation but can create privacy and retention obligations. These are situated choices, not a universal control catalog.

Even a good layered design leaves residual risk. A legitimate recipient can forward downloaded content after a successful request. An employee can select the wrong recipient when creating a share. The path map makes these boundaries explicit so the next lessons can prioritize and decide which risks deserve further work.

Common Confusions

“More layers mean the path is impossible.”

Better model: layers reduce, block, expose, or limit different transitions. A completed delivery can still have consequences that later controls cannot reverse.

“A log is a preventive control.”

Better model: a log can show a decision or support investigation. It prevents only if another mechanism actively uses it before the harmful action.

“Revocation fixes a disclosure.”

Better model: revocation stops future use of the share. It cannot take back content that was already delivered.

“One control can stand in for the requirement.”

Better model: the requirement states the authorization outcome. Controls are the design choices that produce and support it.

Check Your Understanding

Check: A valid link is revoked after an unintended person has already downloaded the proposal. What does revocation change?

Think first, then reveal.

Answer: It stops future uses of that share if every delivery checks current revocation state. It does not undo the earlier delivery, so recovery and impact decisions may still be needed.

Check: A verified partner-b presents a valid link for partner-a. Which control must stop the path?

Think first, then reveal.

Answer: The authorization control that compares the verified requester identity with the recorded recipient. Authentication alone has succeeded; the recipient-binding decision must reject the request.

Practice: Layer a Nearby Path

A clinic portal sends a patient a link to view a test result. A household member obtains a valid link from a shared email account. The product promise is that only the named patient may view the result.

Map one preventive control, one detective control, and one response or recovery control to this path. For each, state the step it affects, what it changes, and one thing it cannot do.

A good answer should mention:

• an identity-to-patient match at the viewing decision, not merely a generic sign-in;
• evidence that helps investigate access without claiming it blocks the view;
• revocation or a changed-result response only for future or downstream impact; and
• the remaining risk that a legitimate patient may disclose a result after viewing it.

Connections

• Lesson 009 supplies the recipient-bound access requirement that the control design must satisfy.
• Lesson 011 compares the importance, plausibility, evidence confidence, and cost of paths and controls without fake numeric certainty.
• Lesson 013 turns control claims into tests and signals.

Resources

• [GUIDE] OWASP Threat Modeling Cheat Sheet — Focus: Compare threat responses with specific, actionable mitigation work.
• [PROJECT] OWASP Application Security Verification Standard — Focus: Use verification requirements to connect authorization controls with observable outcomes.
• [MANIFESTO] Threat Modeling Manifesto — Focus: Keep control choices grounded in system context and practical outcomes.

Key Takeaways

• Put each control on a named path breakpoint and state whether it prevents, detects, responds, limits, or helps recover.
• A recipient-identity match changes the ShareBox authorization decision; logging and revocation have different jobs.
• Make dependencies and irreversible boundaries visible before claiming that a layered design is complete.
• Control layers support a requirement; they do not replace the requirement or eliminate all residual risk.