Turn Threats Into Security Requirements

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

• Rewrite a concrete threat path as a security requirement with a subject, condition, expected behavior, and owner.

• Distinguish a security requirement from a threat statement, a control name, and a vague aspiration.

• Create acceptance checks that show whether a requirement changes the intended path.

Idea in one sentence: A security requirement says what the system must reliably do at a specific boundary so that a known threat path can no longer reach its unwanted outcome.

Core Insight

ShareBox has a retained threat path: an unintended person receives a forwarded, still-valid sharing link, presents it to the public download endpoint, and reads a proposal because link possession is accepted as sufficient authorization.

The team’s first reaction is understandable: “We need more security.” Another person writes, “Use authentication.” A third says, “Require MFA.” None of these sentences is yet a usable requirement. The first names a goal without a boundary. The second names a family of mechanisms without saying whose identity matters or what the endpoint must do. The third selects one implementation before the team has written the behavior it needs.

The stronger move is to write the promise that breaks the path. The requirement should let a designer choose controls, a developer implement behavior, and a reviewer test an outcome without guessing what the original threat-model discussion meant.

The Threat We Are Converting

Keep the source material visible. We are not inventing a new risk.

This is a teaching model, not a claim about a real product. It gives us a precise job: change the acceptance decision at the endpoint so the link alone cannot complete this path.

The Initial Model: Name a Control

These are common first drafts:

Use authentication.
Make proposal links secure.
Add MFA to downloads.
Log every download.

They can all be useful ideas later. They fail as requirements for different reasons.

The missing piece is an expected system behavior tied to the threat’s breakpoint.

The Better Model: A Behavioral Requirement

For this kind of design work, use five fields:

Protected subject: What value, action, or decision must be protected?
Condition: When does the requirement apply?
Expected behavior: What must the system allow, reject, record, or preserve?
Owner: Who is accountable for making and maintaining that behavior?
Evidence: What would demonstrate that it happens and fails safely?

The first four fields make the requirement actionable. The fifth keeps it connected to later verification instead of treating a sentence in a document as protection.

For ShareBox, the product decision is that a proposal is shared with a named partner, not with anyone who possesses a link. Under that stated constraint, write:

SR-01 — Recipient-bound proposal access. For a proposal share that records an intended partner, when a request reaches the download endpoint with a currently valid sharing link, ShareBox must return the proposal only after it verifies that the requester’s authenticated partner identity matches the recipient recorded on that share. Otherwise, it must reject the request without returning proposal content. The ShareBox service team owns this behavior.

This requirement does not prescribe passwords, a particular identity provider, a login screen, or a protocol. Those are control and design choices. It does specify the security-relevant decision: a valid link is necessary but no longer sufficient.

Work the Requirement From the Path

Build it one part at a time rather than writing polished language first.

Notice a small but important distinction: “the partner must log in” is not the exact requirement. A login may establish an identity, but the security property needed here is the match between that verified identity and the share’s recipient. An authenticated but different partner must not receive the proposal.

A Worked Acceptance Trace

Requirements become useful when the team can test their decision boundary. These outcomes are illustrative test cases, not production observations.

The original attack path breaks in case 2: the forwarded-link holder can reach the endpoint, but cannot satisfy the authorization condition. Case 3 protects against a different nearby mistake—treating any authenticated partner as the intended recipient. Case 1 matters too: a requirement that blocks all downloads is not a successful implementation of the product promise.

So far, the requirement has done something the earlier slogans could not: it gives the team a decision table that exposes both permitted and denied behavior.

Separate Requirements From Controls

The same requirement can be met by different designs. That is why we do not collapse it into a single control name.

Lesson 010 will compare controls at different points in the path. Do not choose them merely because their names sound reassuring. First preserve the requirement’s intent; then ask which combination changes the required steps without breaking legitimate sharing.

Trade-offs and Limits

Recipient-bound access improves confidentiality for named shares, but it costs identity onboarding, account recovery work, and extra steps for legitimate partners. It is a good fit when the product promise is “this named organization may read this proposal.” It may be a bad fit when a link is deliberately public, such as a marketing document. In that case, calling the recipient-bound rule a universal requirement would misrepresent the product’s objective.

The requirement also does not solve every related concern. It does not retract a proposal already delivered before a link is revoked. It does not prove that the recorded partner identity is the intended human. It does not answer the open question about availability under heavy token validation. The boundary is visible in the test results: rejected access tells us about this authorization decision, not about every possible disclosure or outage.

Common Confusions

“A threat statement is already a requirement.”

Why it is tempting: both can mention the same asset and harm.

Better model: a threat explains what could go wrong. A requirement states the behavior that must change or hold so the system can address that path.

“A control name is a requirement.”

Why it is tempting: controls are concrete and familiar.

Better model: “use MFA” may be one design choice. A requirement says what authorization result must be true regardless of the chosen mechanism.

“Authentication solves authorization.”

Why it is tempting: both involve identity.

Better model: authentication establishes who is requesting. Authorization decides whether that verified identity may receive this specific proposal under this share.

“One requirement should solve every concern around a feature.”

Why it is tempting: a long sentence feels comprehensive.

Better model: keep each requirement tied to one protected behavior and path. Evidence, availability, revocation, and residual-risk questions may need their own requirements or decisions.

Check Your Understanding

Check: Which draft is closest to a usable requirement for the forwarded-link path?

1. “Use MFA for sensitive documents.”
2. “Secure document sharing.”
3. “For a named proposal share, return content only when the verified requester identity matches the recorded recipient; otherwise return no content.”

Think first, then reveal.

Answer: Draft 3. It names the condition and observable authorization behavior. It still needs an owner and test evidence to become a complete work item, but it does not confuse the behavior with a chosen control.

Check: A verified partner-b presents a valid link issued to partner-a. Should SR-01 allow the download?

Think first, then reveal.

Answer: No. The identity is verified, but it does not match the recorded recipient. This is why “require authentication” alone is weaker than the requirement.

Practice: Write a Nearby Requirement

A clinic portal sends a patient a link to view a test result. A review finds that a household member can use a forwarded valid link because the page does not verify the requester’s patient identity. The product promise is that only the named patient may view the result.

Write one security requirement with a protected subject, condition, expected behavior, owner, and one acceptance check. Then name one design choice that could support it without presenting that choice as the requirement itself.

A good answer should mention:

• the test result and the named patient, not generic “data security”;
• the result-viewing endpoint and a valid link as the relevant condition;
• rejection without result content when identity is absent or mismatched;
• an accountable clinic-portal owner; and
• a test for a mismatched patient identity as well as a successful intended-patient path.

Connections

• Lesson 008 supplies the reviewed threat path and evidence that earn the requirement.
• Lesson 010 places complementary controls at specific path breakpoints.
• Lesson 013 returns to acceptance tests and runtime signals as evidence that requirements still hold.

Resources

• [GUIDE] OWASP Threat Modeling Cheat Sheet — Focus: Compare threat responses with the need for mitigations to become actionable system work.
• [PROJECT] OWASP Application Security Verification Standard — Focus: See how stated security properties become verifiable application requirements.
• [MANIFESTO] Threat Modeling Manifesto — Focus: Keep requirements traceable to a shared model and the product context that makes them useful.

Key Takeaways

• Start with a retained threat path, then write the behavior that must break or constrain that path.
• A useful requirement names the protected subject, condition, expected behavior, owner, and evidence.
• Requirements state outcomes; controls are design choices that may achieve them.
• Test both the denied path and the legitimate path so security does not silently defeat the product promise.