Why does PASTA begin with business objectives instead of the system design?
answer
- the yardstick is defined before the findings
- nothing broken, objective still defeated
- legitimate features abused at scale
- the objective also rules out fixes
- traceability walks back to stage one
basics
~20 sStarting from business objectives gives PASTA a yardstick: the final stage rates each attack path by the damage it does to a stated objective. It also surfaces abuse of legitimate features, which a design-first pass misses because nothing is technically broken.
solid answer
~50 sPASTA is risk-centric, so stage one exists to create the measuring stick that stage seven uses. Without a stated objective and impact figure, prioritisation collapses into whichever component attracted the most findings. Take a cross-border remittance corridor whose stated objective is sub-hour settlement. A design-first pass finds nothing wrong: an organised mule ring moves value through fully authenticated customer accounts, using the product exactly as built. Only the objective makes it visible — the loss is reversed settlement and correspondent-bank penalties, and it is *caused* by the objective, because sub-hour settlement means the money is gone before anyone reviews it. The objective also constrains the fix: you cannot propose a 24-hour hold, because that deletes the thing the system exists for. So stage one drives both what counts as a threat and which countermeasures are admissible.
go deeper
Know that PASTA is called risk-centric because its first stage captures business objectives and impact, and that the last stage rates threats against them.
Explain the mechanism, not the slogan: stage one creates the yardstick stage seven measures with, so prioritisation does not default to whichever component produced the most findings.
Bring a case where nothing in the design was broken and the business objective was defeated anyway, and show how the objective narrowed which countermeasures were even admissible.
Own the input problem. Be ready to say how you get credible objectives and impact figures out of product and finance, how you record assumptions when you cannot, and how you keep them from going stale.
## The claim being tested PASTA is described as **risk-centric**, in contrast with methods that are diagram-centric or attacker-centric. The concrete meaning of that label lives in stage one: *define objectives*, which captures business objectives, regulatory obligations and a business impact analysis before anyone opens the architecture. An interviewer asking this question wants to know whether you understand what that buys, or whether you treat stage one as paperwork before the real work starts. ## What stage one actually produces Three things: 1. **A statement of what the system is for**, in the business's own terms — not "a payments API" but "settle a customer-to-customer remittance in under an hour end to end". 2. **An impact analysis**: what it costs when that stops being true, or when it is achieved for the wrong party. This can be revenue, regulatory exposure, contractual penalty, or trust. 3. **The obligations** the system carries regardless of design — reporting duties, retention duties, licence conditions. All three are consumed at stage seven, where each viable attack path is rated against them. That is the whole architecture of the method: the yardstick is defined before the findings exist, so the findings cannot define the yardstick. ## Why design-first modeling misses a class of threat A per-element pass over a diagram asks, of each process, store and flow, what could go wrong with *it*. That is excellent at finding broken or missing mechanisms: unauthenticated endpoints, unencrypted flows, missing authorisation checks. It is structurally weak at finding **abuse of correctly working features**, because there is no defective element to point at. Take the cross-border remittance corridor. Its stage-one objective is sub-hour settlement, and its impact statement names reversed settlement costs and correspondent-bank penalties. Now put an organised money-mule ring against it: hundreds of genuine, fully verified customer accounts, each doing small, individually unremarkable, correctly authenticated transfers, aggregating stolen funds and pushing them out of the corridor. Walk the diagram element by element and everything is fine — authentication holds, authorisation holds, the flows are encrypted, the ledger is consistent. The system is not broken. It is being *used*, at scale, by the wrong people, for the wrong purpose. Starting from the objective inverts the question from "which element is weak" to "what would make the objective fail or be turned against us", and the mule ring appears immediately, because the loss it causes is exactly the loss the impact analysis names. ## The objective as a constraint on countermeasures The second, subtler payoff: stage one does not only tell you what to worry about, it fences what you are allowed to do about it. In the remittance corridor, sub-hour settlement is *why* the fraud pays — irreversibility inside an hour means the funds are unrecoverable by the time a review would have happened. The intuitive control is a holding period. Stage one forbids it: a 24-hour hold does not mitigate the risk, it deletes the product. So the admissible countermeasures are the ones that preserve the objective — velocity and network analysis across accounts at ingestion, graph detection of beneficiary reuse, risk-scored routing that only delays the small tail of transfers that score badly, corridor-level exposure limits. A model that never wrote down the objective would happily propose the hold, and the recommendation would be rejected by the business without either side understanding why the model was wrong. ## Traceability in both directions Because stage one anchors the chain, every stage-seven output can be walked backwards: this countermeasure defends this attack path, which uses this weakness, which serves this threat, which damages this objective by this much. That backwards walk is what lets a threat model survive contact with people who will not read a diagram. It also creates a discipline check — an item you cannot trace back to a stage-one objective is a finding you have not justified, and PASTA gives you an explicit place to notice that. ## Where the approach is fragile Stage one depends on someone outside security being able and willing to state the objectives and the impact. When the business cannot or will not, teams substitute their own guesses, and the whole method inherits that guess with a false air of rigour — a rating that looks quantitative but rests on an invented impact figure. The honest handling is to record the assumption explicitly, mark the rating as resting on it, and get it corrected rather than letting it harden. The other fragility is staleness: objectives change faster than architectures, and a model rated against last year's objective quietly stops being risk-centric at all. ## What a strong answer sounds like Name the mechanism (stage one defines the yardstick stage seven rates against), give one concrete case where the design was intact and the objective was still defeated, then show the constraint direction — that the objective also rules some countermeasures out. Candidates who only say "because business context matters" have restated the label without showing the machinery.
- What do you do when the business cannot state an objective or an impact number?Write down an explicit assumption rather than a silent one: state the objective as you understand it, state the impact range you are assuming, and mark every rating that depends on it. Then get it challenged by whoever owns the revenue or the regulatory exposure — the correction is usually fast once someone sees a number they disagree with. What you must not do is let an invented figure travel downstream as if it were given, because the whole method's rigour is inherited from that input.
- Does an objective-first start bias you toward money threats and away from availability or privacy?It biases you toward whatever the objective names, which is why the stage-one statement has to cover more than revenue. A well-formed set of objectives includes service commitments, regulatory and privacy obligations, and non-repudiation duties alongside margin, and the impact analysis prices each. If stage one only says 'make money', stage seven will only find money threats — but that is a defect in how stage one was run, not in the method.
- How often should the stage-one objectives be revisited?Whenever the product's commercial promise changes, not only when the architecture changes. Objectives shift faster than systems — a corridor that adds a new market, a settlement window that gets shortened, a new regulatory obligation — and every one of those changes what the same unchanged attack path is worth. In practice, tie a review of stage one to the product planning cycle and re-rate the existing paths against it rather than re-running the whole process.
saying these in an interview costs you the question
- Says stage one is documentation before the real modeling
- Cannot name a threat that a design-first pass would miss
- Treats every threat as a defect in some component
- Proposes controls that destroy the business objective
- Invents an impact figure and presents it as given