What is missing from the threat statement "there is no rate limiting on the OTP endpoint"?
answer
- describes the fix, not the failure
- who reaches what, and how
- no asset, no loss, nothing to argue
- five slots in one sentence
- actor, entry point, action, asset, impact
basics
~20 sThat sentence names a missing control, not something that could go wrong. A threat statement has to name an actor, the entry point they reach, the action they take, the asset affected, and the concrete impact.
solid answer
~40 sIt describes an absent control, so there is nothing to argue with, own, or close. A threat statement fills five slots: **actor** (who, described by the position and access they already have), **entry point** (the interface they can actually reach), **action** (what they do through it), **asset** (what of value is touched), and **impact** (the loss, stated so a non-security reader recognises it). Rewritten for a pharmacy refill line: "an anonymous caller who knows a patient's phone number submits one-time codes to the refill line's verify step until one matches, then reads that patient's prescription history and places a refill." Now the asset (health data) and the loss are explicit, the statement can be disputed on its facts, and rate limiting is one candidate answer to it rather than the definition of the problem.
go deeper
Learn the five slots by name — actor, entry point, action, asset, impact — and be able to spot that a sentence about a control being absent has filled none of them.
Be ready to take a scanner-style or review-style finding handed to you in the interview and rewrite it live into a one-sentence threat, saying which slot each phrase fills and why the original could not be owned.
Show that you police this in other people's models during review, and that you can pull two distinct statements out of one missing control when the assets and losses differ.
Own the argument that statements are written for the engineer who has to answer them, not for a report: a corpus phrased as absent controls quietly hands mitigation choice to whoever wrote the finding.
## Why the original sentence fails "There is no rate limiting on the OTP endpoint" is a true observation about a system, and it is not a threat statement. Three things are wrong with it. First, it names **no asset and no loss**. A reader cannot tell whether the endpoint guards a marketing newsletter or a controlled-substance refill, so nobody can decide how much attention it deserves — and the person who has to decide is usually not the person who wrote the sentence. Second, it **presumes its own fix**. The sentence is the absence of one specific control, so the only way to close it is to add that control. If the better answer is a per-number backoff, an out-of-band callback, or moving verification off the phone line entirely, the statement cannot express that those also work. Third, it is **unarguable**. A good threat statement is a claim someone can push back on: "no, that caller cannot reach the verify step without an account number." A statement of an absent control invites no such conversation; it just sits there until someone adds a limiter and marks it done, without anyone having established what would have been lost. ## The five slots - **Actor** — who, described by the position and access they already hold: an anonymous internet caller, an authenticated low-privilege tenant, an employee with a legitimate console login, a contractor's laptop on the operations network. Not a label like "a hacker." - **Entry point** — the interface they can genuinely reach: a named endpoint, a queue, a file drop, an admin screen, a physical port. Specific enough that a reader can find it on the diagram. - **Action** — what they do through that interface, in verbs. - **Asset** — what of value is touched: personal data, money, a service's availability, source-code or model IP, credentials, the audit record itself. - **Impact** — the resulting loss, phrased so someone outside security recognises it. "A patient's prescription history is exposed and a refill is redirected" travels; "confidentiality is violated" does not. One sentence, one threat, no mitigation inside it. ## The rewrite Original: *there is no rate limiting on the OTP endpoint.* Rewritten: *an anonymous caller who knows a patient's phone number submits one-time codes to the refill line's verify step until one matches, reads that patient's prescription history, and places a refill to an address they choose.* Notice that the same missing control supports a **second, different** statement: *an anonymous caller floods the verify step with attempts so that genuine patients cannot complete a refill during pharmacy hours* — a different asset (availability of the refill line) and a different impact. That is a good illustration of why control-absence phrasing is lossy: it collapses several distinct things that could go wrong into one sentence about a knob that is turned off, and the two rewrites may deserve different answers. ## The two other phrasings that fail the same way **Bare bug class.** "SQL injection in the reporting module" names a flaw family and a location, and stops. It is not yet a threat statement. Add the missing slots: *an enrolled pupil, through the filter parameter on the grade-report screen, injects SQL that updates stored marks, so the district's academic record no longer reflects what teachers entered and the school cannot prove what was originally recorded.* Now the asset is the audit truth of the record, not "the database," and the impact is one a headteacher understands. **Control named where the impact belongs.** "The session token is not encrypted at rest" on an HR grievance case tracker says what is not done, not what is gained. Rewritten: *an HR user with read access to the case store lifts stored session tokens and replays them as a colleague, reading grievance files outside their own remit while the actions are attributed to that colleague.* The gain — reading restricted personal data, and doing it under someone else's name — is the point. ## Register Keep it to one sentence, present tense, concrete nouns, no fix inside. The candidate mitigation, the category you file it under, the owner and the rating all live in fields **next to** the statement, not inside it — that separation is what lets two people propose different mitigations for the same agreed threat, or accept a threat knowingly instead of silently. A statement written this way is usable downstream: an owner can be named because a component is named, an abuse test can be derived from the action, and "closed" means the loss can no longer occur or someone accepted it with their eyes open.
- The finding reads "SQL injection in the reporting module." Is that a threat statement?No — it names a flaw class and a location with no actor, asset or loss. Make it one by adding them: an enrolled pupil, through the grade-report screen's filter parameter, injects SQL that rewrites stored marks, so the academic record no longer matches what teachers entered and the school cannot prove what was recorded. Only then can someone dispute it, own it, or decide it is closed.
- How specific does the entry point have to be?Specific enough that a reader can point at it on the diagram and that a reviewer can argue the actor cannot reach it — a named endpoint, queue, file drop, admin screen or physical port. "The system" or "the backend" is not an entry point; it hides exactly the question of what the attacker can touch from where they stand.
- Should the statement name the mitigation?No. Put the candidate mitigation in a field beside the statement. Writing it inside freezes one answer into the problem, so nobody can propose a cheaper or stronger alternative, and "we shipped the control" becomes the closure test instead of "the loss can no longer happen." Keeping them separate also lets you accept a threat deliberately rather than by omission.
"The smoke alarm has no battery" is a maintenance note. "A chip-pan fire in the ground-floor kitchen spreads to the stairwell unnoticed at night" is what you actually plan against — and a battery is only one of the answers to it.
saying these in an interview costs you the question
- Reports an absent control and calls it a threat
- Names a bug class with no asset or impact
- States impact as "insecure" or "non-compliant"
- Writes the fix into the statement so alternatives cannot be weighed
- Uses "the system" or "the backend" as the entry point
- Assumes one missing control means exactly one threat