When is PASTA's full seven-stage run worth the cost, and how would you tailor it?
answer
- the cost is other people's calendars
- large loss, contested trust, long-lived design
- keep the spine, compress the middle
- reuse decomposition, re-enter by delta
- seven stages without business input is ritual
basics
~20 sRun all seven stages where loss is large, trust is contested and the design is long-lived — the case that justifies weeks of cross-functional input. Elsewhere keep stage one and stage seven, reuse decomposition, and compress the middle into one evidence-informed pass.
solid answer
~50 sPASTA's cost is not the seven stages, it is the people: stage one needs product and finance, stage four needs real abuse and incident evidence, and stage seven needs someone who can accept risk. Spend that where the stakes justify it — a rail revenue-apportionment clearing house splitting fare income between competing operators is a good example, because a partner operator inflating its own journey claims attacks both money and audit truth, the interfaces are contractual and long-lived, and no lightweight pass will price that. Everywhere else, keep the risk-centric spine and compress the middle: state the objective and impact, reuse the existing decomposition instead of redrawing it, do one combined threat-and-weakness pass, and still rate against the objective. On change, re-run only the stages the change touches. The failure mode to avoid is running all seven without the business inputs, which produces an expensive diagram exercise wearing a methodology's name.
go deeper
Know that PASTA is heavyweight compared with a quick per-element pass, and that teams reserve the full seven-stage run for systems where the potential loss justifies the effort.
Be able to say which stages are reusable between runs — decomposition above all — and which have to be redone when the objective or the interfaces change.
Show how you would compress the process on a real system while keeping the objective-and-rating spine, and name what the compression costs you in path enumeration.
Treat modeling depth as a portfolio allocation with named tiers, defend the spend against the loss figure it produced, and be candid about ritual completion as the dominant failure of heavyweight methodologies.
## The real cost of PASTA Seven stages sound like seven meetings. They are not. The expensive part of PASTA is that its inputs come from **outside the security team**: - Stage one needs product and finance to state objectives and price impact. - Stage two and three need architecture and operations time to scope and decompose honestly. - Stage four needs genuine abuse, fraud and incident evidence, which someone has to collect and keep current. - Stage seven needs a person with the authority to accept residual risk, not just record it. A method whose quality depends on other people's calendars does not scale to every service, and pretending otherwise is how threat modeling programmes die. The principal-level question is therefore not "is PASTA good" but "where do I spend it". ## What justifies a full run Four signals, and you generally want several together: 1. **Large or irreversible loss.** Money, regulatory exposure, or damage that cannot be undone once it happens. 2. **Contested or asymmetric trust.** Parties inside the system have legitimate access and a motive that diverges from yours. 3. **Longevity.** The design will be in place for years and the interfaces are contractual, so the model amortises. 4. **Novelty.** No existing model, pattern or reference architecture covers this shape, so cheap reuse is not available. **The worked case: a national rail revenue-apportionment clearing house.** It splits fare income between competing train operators according to journey data the operators themselves submit. Stage one's objective is apportionment that all operators accept as correct, and the impact is both money — misallocated fare revenue — and audit truth, because the settlement figures are the record of who is owed what. Stage three's decomposition puts a signed partner interface at the centre. Stage four's evidence points not at anonymous outsiders but at a **legitimate partner with a valid credential and a direct financial incentive to inflate its own journey claims**. Stage five finds where claim data is accepted without corroboration; stage six chains it into a sustained, low-margin inflation that stays inside plausible variance; stage seven prices it against the settlement pot and forces the countermeasure conversation — cross-corroboration against independent journey evidence, statistical anomaly review across operators, dispute and clawback mechanics, and immutability of the settlement record. That system earns all seven stages: the loss is large and recurring, the adversary holds a legitimate credential, the interface is contractual and hard to change, and the audit-truth dimension means the countermeasure has to survive being challenged by the party it constrains. ## How to tailor without gutting the method What makes PASTA *PASTA* is the risk-centric spine: an objective and impact at the front, a rating against them at the back, and traceability between. Tailoring should preserve that spine and compress the interior. - **Keep stage one, always** — but timebox it. On a small change, it may be two sentences and one number, reused from the parent system's model. - **Reuse stage two and three.** Decomposition is the most reusable artifact you own. Maintain one per system, update it as the architecture changes, and never redraw it for a modeling session. - **Merge stages four to six** into a single evidence-informed pass for lower-stakes systems: who realistically attacks this, through what weakness, along what path. You lose rigour in path enumeration; you keep the shape of the reasoning. - **Keep stage seven's decision, drop its ceremony.** The output still has to say what the loss is worth and who accepted the remainder. - **Re-run by delta.** When the design changes, re-enter at the earliest stage the change actually touches — a new partner interface re-enters at stage two, a new objective re-enters at stage one, a newly published weakness class re-enters at stage five — rather than restarting. ## Portfolio thinking At programme scale, treat modeling depth as a budget allocation, not a policy. A small number of systems get the full run and a maintained model. A larger tier gets the compressed version on a cadence. The long tail gets a lightweight per-change check that inherits objectives and impact from the tier above it. Then measure the thing that actually matters: whether the models are influencing design decisions before build, not how many models exist. ## The failure modes to name - **Ritual completion.** All seven stages run, no business input obtained, so stage one is invented by security and stage seven produces numbers with no authority behind them. This is worse than a lightweight model, because it costs more *and* misleads. - **Stale rigour.** A full model produced once at design time and never revisited, cited years later as if it still described the system. - **Uniform application.** Mandating seven stages everywhere guarantees the mandate gets ignored or faked; the exception process becomes the real process. - **Method attachment.** Arguing for PASTA where a fast per-element pass would have found the same things sooner. The point is the decisions the model changes, not which method's name is on the document.
- If you compress stages four through six into one pass, what do you actually lose?Path enumeration. Separate stages force you to list weaknesses exhaustively before chaining them, which is how you catch the case where two individually minor weaknesses compose into a serious route. A merged pass tends to follow the first plausible attack and stop, so it finds the obvious path and misses the composed one. That trade is acceptable on a system whose worst case is bounded, and it is not acceptable where the loss is large or irreversible — which is exactly the line you use to decide who gets the full run.
- How do you keep a full seven-stage model from going stale after the design ships?Attach re-entry triggers to the model rather than a calendar review nobody does. A new external interface, a change in the stage-one objective, a new class of weakness in a component you depend on, or a real incident in this system's class each re-enter the process at a defined stage. Keep the decomposition as a living artifact updated with the architecture, because that is what makes re-entry cheap; if the decomposition rots, every re-entry becomes a fresh full run and therefore never happens.
- How do you argue for the effort when leadership sees seven stages as bureaucracy?Argue from the decision, not the method. Show a case where the objective-first framing produced a countermeasure the team would not otherwise have built, or blocked one that would have broken the product, and put the cost of the full run next to the loss figure stage seven produced. Then propose it for a named tier of systems rather than as a blanket standard — a bounded ask is approvable, and a universal mandate invites a universal exception.
It is the difference between a full structural survey and a walk-round inspection: you commission the survey for the building you will own for thirty years and litigate over, not for every shed on the site.
saying these in an interview costs you the question
- Mandates all seven stages for every system
- Counts completed models rather than design changes
- Redraws decomposition from scratch for each session
- Runs the stages without any business or evidence input
- Treats the design-time model as valid indefinitely
- Defends the method rather than the decisions it changed