What kinds of threats does Trike's requirements-driven derivation systematically miss?
answer
- complete only over what you modelled
- count the columns you never wrote
- batch jobs and backups are actors too
- tokens, logs and backups are assets too
- a stated rule can itself be the flaw
basics
~20 sAnything the requirements never named: actors nobody wrote down, assets outside the grid such as tokens, logs and backups, and threats that are not one actor acting on a business asset. A stated rule that is itself over-broad also passes silently.
solid answer
~50 sThe derivation is complete only with respect to the rules you fed it, and real requirements are thin. Take an HR performance-review tool whose written rule grants a manager access to their direct reports. Build the grid and you find actors the document never named — the skip-level manager, the acting manager covering a leave, the nightly export job, the support engineer with an admin console. Each is an empty column, and an empty column produces no threats at all. Assets go missing the same way: the review record is a row, but the session token, the audit log and the nightly backup usually are not. Third, some threats are not "actor X performs action Y on asset Z" — a weak session token, a key in config, a compromised build shipping code that bypasses the check. And the matrix faithfully ratifies a stated rule that is itself over-broad, such as a manager keeping access after a report transfers away.
go deeper
Know that the derived threat list only covers the actors and assets someone put in the grid. If a role or a data store was never written down, no threat about it will appear.
Be able to name the two silent gaps — missing columns and missing rows — and give concrete examples such as an export job or an audit log, then explain why a missing entry produces zero threats rather than an obvious error.
Demonstrate the recovery: enumerate actors by walking real flows and talking to operations, add derived assets, and follow up with a mechanism-level pass. Interviewers here want evidence you have watched a tidy matrix miss something in production.
Own the harder point that the requirements themselves are in scope. Be ready to argue for changing an over-broad stated rule, and to decide how much residual risk a requirements-only pass leaves on a given system.
## The completeness claim, read carefully Requirements-driven derivation offers something rare: a threat list that is reproducible rather than dependent on who was in the room. The claim is real, but it is conditional. The list is complete **with respect to the modelled actors, the modelled assets, and the expressiveness of the verb set** — and each of those three is a place where real systems leak. Use an HR performance-review tool as the running example. The written requirement is one line: a manager may read and comment on reviews for their direct reports. ## Blind spot one: actors nobody wrote down Build the grid and the columns come from the requirements document. That document names *manager* and *employee*. It does not name: - the **skip-level manager**, who in practice needs to read a report's review during calibration; - the **acting manager** covering parental leave, a temporary grant with no stated expiry; - the **HR business partner** and the compensation analyst; - the **nightly export job** that lands reviews in a reporting warehouse; - the **support engineer** with an admin console, and the operator with direct database access; - the **backup system**, which reads every asset in the product. A missing column contributes zero threats. This is the failure mode that matters most, because it is silent: the matrix looks complete, every filled cell is adjudicated, and an entire class of access is simply absent. The counter-move is to derive actors from the *system* rather than from the document — walk each real flow and ask who or what touches the record, then talk to operations and support, not only product. ## Blind spot two: assets that never made the rows Requirements are written about business objects: the review, the rating, the comment. The system also holds derived and incidental assets that carry the same sensitivity — the session token that grants a manager's access, the audit log of who read which review, the search index, the message on the queue, the nightly backup, the exception report that quotes review text into a log line. If those are not rows, no cell exists for "support engineer reads the log containing review text", and the threat cannot be derived. Adding derived assets to the grid is cheap and is usually where a second pass earns its keep. ## Blind spot three: threats the verb set cannot express Some threats are not one actor performing create, read, update or delete on a business asset: - **Mechanism weaknesses.** A predictable session token, a check enforced only in the browser, a missing server-side authorization call. The matrix says the manager must not read another team's review; it says nothing about how that is enforced. - **Cross-cutting infrastructure compromise.** A poisoned dependency or a compromised build system that ships code with the check removed. The attacker here is not one of your columns. - **Inference and side channels.** Learning *that* an employee has an open performance case from a notification badge, a URL that returns a different error, or a calendar invite — without reading the record at all. - **Key and secret handling.** An encryption key checked into configuration is not an action on a modelled asset unless you make the key an asset. ## Blind spot four: the requirement itself is the problem Derivation treats the stated rules as ground truth. If the rule says a manager retains access to a former report's history indefinitely, the matrix marks the cell *allowed* and produces no threat — the model has ratified the over-broad grant. Requirements-driven work therefore needs a separate review of the rules themselves against least privilege, data-retention expectations and what the people described in the records would consider reasonable. "The requirement said so" is not a security argument. ## What good looks like in the answer Say the completeness claim out loud and then bound it: complete over what was modelled, silent about what was not. Then give the recovery moves — enumerate actors from flows rather than from the document, add derived and incidental assets as rows, run a separate mechanism-level pass on how each rule is actually enforced, and review the rules themselves. That combination is what separates someone who has used a requirements model on a real system from someone who has read the description of one. ## Interview framing Expect this as a live challenge: an interviewer hands you a one-line access rule, watches you build the grid, and then asks what you would still be missing. The wrong answer is that the matrix covers it. The right answer names the missing columns first, because that is the blind spot that hides itself.
- How do you find the actors the requirements never named?Derive them from the running system instead of the document. Walk each flow and ask who or what touches the record: the admin console, the support tooling, the export job, the backup, the on-call operator with database access. Interview operations and support rather than only product, since the informal grants — acting manager, temporary calibration access — live in their world and never reach a written requirement.
- The matrix says the rule can be violated but not how. What fills that gap?A separate mechanism-level pass. For each violation worth taking seriously you ask what would have to be true for it to happen — a missing server-side check, a shared account, direct database access, a token that survives a role change — and then confirm which control actually stops it. The requirements pass sets the agenda; it does not discharge it.
- What if the written requirement is itself over-broad?The derivation will ratify it, so you need a review of the rules as rules. Read each allowed cell against least privilege, retention and the expectations of the people in the records: does a manager still need access after a report transfers, does the export need every field, does support need read access at all or only a masked view. Argue the change as a requirement change.
- Does adding every derived asset make the grid unmanageable?It can, so be selective. Add the derived assets that carry the same sensitivity as the business object — tokens that grant access, logs and exports that copy content, backups — and skip the rest. A grid nobody finishes finds nothing; the goal is to catch the copies of sensitive data that requirements language never mentions.
saying these in an interview costs you the question
- Claims the model is complete because every cell was filled
- Assumes a requirements document lists every real actor
- Treats batch jobs, backups and admin tooling as non-actors
- Says a filled matrix removes the need for mechanism-level analysis
- Accepts a stated rule as a security argument in itself