In Trike, how does the actor-asset-action matrix turn stated requirements into a threat list?
answer
- start from the rules, not the diagram
- actors against assets, in a grid
- four verbs per cell: create, read, update, delete
- threats are the complement of allowed
- only two threat kinds come out
basics
~20 sTrike grids every actor against every asset, marking each create, read, update and delete cell allowed, disallowed, or conditional. Threats are the complement: an actor performing a disallowed action, or being denied an allowed one.
solid answer
~50 sTrike is requirements-driven, so the first artifact is a matrix, not a diagram. Rows are assets, columns are actors, and each cell holds the four data actions — create, read, update, delete — marked allowed, disallowed, or allowed with a stated rule. Threat enumeration is then mechanical: you take the complement. Every disallowed action an actor could still perform is an elevation-of-privilege threat, and every allowed action an actor could be prevented from is a denial-of-service threat; the vocabulary stays that small on purpose. In a court e-filing system whose rules say a filing clerk may seal a document but only a judge may unseal it, `clerk / seal status / update` is a disallowed cell, so "clerk unseals a document" is a threat you must show is prevented. Cells nobody wrote a rule for — who may read the seal log — go back to the stakeholders, not into a default.
go deeper
Recall the three pieces — actors, assets, and the four create/read/update/delete actions — and that each cell says allowed, disallowed, or allowed with rules. Be able to fill one row for a simple system.
Explain the complement rule out loud: threats are what the stated rules do not allow, plus the denial of what they do. Name both derived threat kinds and show a cell producing each.
Show judgment on the blank cells. An interviewer wants to see you turn an unstated permission into a decision someone owns, and to recognise that a rule can be stated correctly yet unenforced in the built system.
Own the argument for a fixed, tiny verb set and a fixed threat vocabulary: determinism and reviewability bought at the cost of expressiveness. Be ready to say where that trade stops paying on your systems.
## What Trike models first Most design-time methods start from the architecture and ask what could go wrong with it. Trike starts from the other end: from what the system is *supposed* to permit. Its central artifact is the **requirements model**, and everything downstream is derived from it. Three terms carry the model: - **Actor** — a role or principal that can act on the system: a human role (filing clerk, judge, public portal user), but equally a service account, a nightly batch job, or an operator with database access. - **Asset** — something of value the system stores, moves or protects: a filed document, a seal status, an audit log entry, a payment record. - **Action** — one of the four data actions **create, read, update, delete**. Trike deliberately uses this fixed, tiny verb set so the grid is finite and comparable across systems. The matrix crosses actors with assets, and each cell records, per action, one of three states: **allowed**, **disallowed**, or **allowed with rules** (a conditional permission, such as "a clerk may update a filing only before it is accepted"). ## A worked grid Take a county court e-filing system. The written rules say a filing clerk may seal a document; only a judge may unseal one. Just for the asset "seal status": | Action on seal status | Filing clerk | Judge | Public portal user | |---|---|---|---| | create (seal) | allowed | allowed | disallowed | | read | not stated | allowed | disallowed | | update (unseal) | disallowed | allowed | disallowed | | delete | not stated | not stated | disallowed | Filling this in takes minutes and immediately produces two different kinds of output. ## Threats are the complement Trike defines a threat as the complement of the allowed actions. Concretely, each cell yields threats in one of exactly two kinds: - **Elevation of privilege** — an actor performs an action the rules disallow. "Filing clerk unseals a document" is not a category you guessed at from a checklist; it falls out of the grid the moment the rule is written down. - **Denial of service** — an actor is prevented from an action the rules allow. "Judge cannot unseal a document" is a threat of equal standing, which is why availability does not go missing here the way it does in purely attacker-centric passes. That is the whole threat vocabulary. The payoff is determinism: given a complete rule set, the threat list is not a matter of imagination or of how good the person at the whiteboard is that day. Two people who fill the same matrix produce the same list. ## The empty cell is a finding, not a default The cells marked *not stated* above are the part interviewers actually probe. Nobody wrote down who may read the seal log, or whether a seal record may be deleted at all. Trike treats that as a defect in the requirements, and the correct move is to take the gap back to the people who own the rules — the court's process owners — and get a decision. The tempting shortcut, quietly reading an empty cell as "deny", hides the fact that the business never made the call, and it means the eventual implementation choice is nobody's decision on the record. Surfacing unstated authorization rules is arguably the method's strongest practical effect, and it happens before any threat is discussed. ## What the rest of Trike adds The matrix is not the whole method. Trike layers a **risk model** on top — assets carry values and actors carry trust weightings — so the derived threats can be ordered rather than left as a flat list. It also has an **implementation model**, where the built system is drawn out and compared against the requirements model to check that the actions the software actually supports match the actions it was intended to support. A rule can be perfectly stated and still be unenforced in code; that comparison is where you catch it. ## What it does not give you The matrix tells you *that* a rule can be violated and by whom. It does not tell you *how* — whether the clerk gets there through a missing server-side check, a shared account, or direct database access. That mechanism-level work is a separate pass, and it is the natural next step after the derivation. ## In an interview Be able to draw the grid on a whiteboard for a system you are handed, name the three cell states, and state the complement rule and its two threat kinds without hedging. The strongest signal is treating the blank cell as a question for a stakeholder rather than an assumption you make on their behalf.
- What do you do with a cell nobody ever wrote a rule for?Treat it as a finding and take it back to the people who own the process. An unstated cell means the business never decided, so any behaviour the code happens to have is an accident. Recording it as "deny by default" hides the missing decision; recording it as an open question gets it made, dated and owned before implementation locks something in.
- How does Trike express an availability threat, given the matrix is about permissions?As the denial of an allowed action. If the rules say a judge may unseal a document, then "judge cannot unseal" is a threat in exactly the same sense as "clerk can unseal". Because both directions are derived from the same cell, availability threats appear automatically instead of depending on someone remembering to ask about uptime.
- How do you record a permission that only holds under a condition?As allowed with rules, with the condition written into the cell — for example, a clerk may update a filing only before it is accepted. The condition then becomes its own threat: the clerk updating after acceptance. Vague conditions are the trap; "where appropriate" is not a rule and should be pushed back on until it is testable.
It is a seating chart rather than a list of suspects: you write down who is allowed in which seat, and every other seating arrangement is automatically something to explain.
saying these in an interview costs you the question
- Describes Trike as another name for a category checklist
- Reads a cell with no stated rule as implicitly forbidden
- Lists only what attackers can do, ignoring denied legitimate actions
- Treats the filled matrix as the finished threat model with no risk step
- Confuses the violated rule with the flaw that permits the violation