In VAST threat modeling, what is the difference between an application model and an operational model?
answer
- Two models, not one
- One follows features, one follows deployment
- Notation a delivery team can draw unaided
- Process-flow application, data-flow operational
- Shared platform lives only in the second
basics
~20 sVAST builds two model types. An application threat model uses a process-flow diagram that follows features and the calls between components the way a delivery team designs them. An operational threat model uses a data-flow diagram of the deployed shared infrastructure those applications run on.
solid answer
~50 sVAST — Visual, Agile and Simple Threat modeling — deliberately splits the model in two. The **application threat model** is drawn as a process-flow diagram: features, use cases, the sequence a user moves through, and the component-to-component calls and protocols behind them. That notation matters because it mirrors how a product team already describes its own work, so the team can produce the model without a security facilitator. The **operational threat model** (sometimes called the infrastructure model) is drawn as a data-flow diagram of the deployed environment — shared services, stores, network paths, operator access. The split exists because the two views catch different threats. A shared card-tokenisation platform used by twelve retail brands appears in twelve application models only as "call the tokenisation service"; the vault, the per-brand integration credential and the operator path to it exist in exactly one place, the operational model, and so does the threat of one brand's leaked credential reaching another brand's tokens.
go deeper
Be able to expand the acronym — Visual, Agile and Simple Threat modeling — and say that it produces two kinds of model rather than one. Knowing which diagram belongs to which model already puts you ahead of most candidates.
Explain both notations and why the process-flow one was chosen: it resembles artefacts a delivery team already writes, so they can draw it without a security facilitator. Be ready to say what each view catches and misses.
Show it on a real shape. Given a shared platform with many consumers, argue why it belongs in one operational model rather than being smeared across every consumer's application model, and name the threat that only appears there.
Own the consequence of the split for who does the work. The application model is delegable to product teams; the operational model needs a platform owner, and if nobody funds that half you end up with wide coverage and no home for shared-service threats.
## What VAST is VAST stands for **Visual, Agile and Simple Threat modeling**. It starts from a different complaint than STRIDE or PASTA. Those methods ask "how do we find the most threats in this one design?" VAST asks "how do we hold a current threat model for *every* system we own, produced by the people who build them?" Almost everything distinctive about VAST — including the two-model split — follows from that premise. ## The two model types **Application threat model — process-flow diagram.** A process-flow diagram is organised around how an application is designed and used: its features and use cases, the path a user takes through them, and the calls and protocols between the components that serve them. It is coarser than a code-level sequence diagram; it sits at the level of "customer submits a claim", "claims service calls the document store". The reason VAST chose this notation is social, not technical: it looks like the artefacts a delivery team already produces — journeys, user stories, service maps — so a product team can draw one unaided. A data-flow diagram, by contrast, is a security-analyst's notation that most product teams have to be taught. **Operational threat model — data-flow diagram.** This one describes the deployed environment rather than any single application: shared services, data stores, network paths, the boundaries data crosses, and privileged operator access. It is where things that belong to nobody's application live. ## Why the split earns its keep Take a retail group whose twelve brands all consume one shared card-tokenisation platform. Model each brand as an application and you get twelve process-flow models that each contain the same single arrow: "call the tokenisation service". The token vault at rest, the per-brand integration credential, and the operator path into the vault appear in none of them, because no brand owns them. Modelled once as an operational data-flow model, the interesting threat becomes visible immediately: a compromised or careless brand integration whose credential reaches tokens belonging to a different brand. The mitigation — distinct credentials per brand, scoped authorisation, per-brand rate limits — lands on the platform team, who are the only people who can actually build it. Twelve application models would have distributed that threat into twelve places where nobody was responsible for it. The reverse gap is just as real. An operational model of the infrastructure will not tell you that a business rule lets a user approve their own claim; that is a feature-level flaw and it shows up in the application model. ## The scope of a process-flow model is a journey, not a service A common misreading is that one application model equals one deployable service. Because the notation follows a use case, a process-flow model can legitimately span teams. A telco's number-porting journey may cross nine internal teams and two external registries; drawn as one process-flow model of the customer journey, the port-out account-takeover threat becomes obvious, because you can see a weak identity check performed by a retail agent early in the flow being treated downstream as proof of identity. A set of nine per-service models never shows that handoff to anyone, because the flaw is not inside any of the nine. ## Side by side | | Application model | Operational model | | --- | --- | --- | | Notation | Process-flow diagram | Data-flow diagram | | Perspective | How the system is built and used | How it is deployed and run | | Usually produced by | The delivery team | Platform / infrastructure owners | | Catches | Feature and workflow abuse, missing authorisation in a journey, handoffs between teams | Shared services, credentials and stores, operator access, boundary crossings | | Misses | Shared infrastructure nobody owns | Business-logic and feature-level flaws | ## Common mistakes - Saying VAST abandons data-flow diagrams. It does not; it *relocates* them to the operational model. - Treating the process-flow diagram as a UML sequence diagram of code calls. It is deliberately coarser and feature-shaped. - Skipping the operational model. This is the most common real failure: a portfolio of application models with no operational counterpart has nowhere to put shared-service threats, so they are never written down. ## An honest caveat worth saying out loud VAST's public specification is thinner than STRIDE's or PASTA's, and it originated with a commercial tool vendor, which is why some practitioners are sceptical of it as an independent methodology. In an interview, state the premise and the two-model split confidently, describe what each view catches, and be candid that the procedural detail beyond that is not as publicly documented as the older methods. That is a stronger answer than inventing steps.
- Where does a card-tokenisation platform shared by twelve retail brands actually get modelled in VAST?In one operational model. Twelve application models would each show only an arrow to the service, so the vault, the per-brand integration credentials and the operator path would appear nowhere. Held once as an operational data-flow model, the threat of one brand's credential reaching another brand's tokens is visible, and its mitigation lands on the platform team who can build it.
- A number-porting journey crosses nine teams and two external registries. How would you scope a VAST process-flow model for it?Model the journey, not any one service. A process-flow model follows a use case, so it may legitimately span teams. Doing so exposes the port-out takeover: a weak identity check by a retail agent early in the flow is trusted downstream as proof of identity. Nine per-service models never surface that, because the flaw sits in the handoff rather than inside any service.
- Does a process-flow application model give you the trust-boundary view a data-flow diagram would?Not really, and VAST does not claim it does. A process-flow model is strong on sequence, features and who calls whom, and weak on data at rest and on where data crosses a privilege boundary. That is precisely why the operational model exists and why treating it as optional infrastructure paperwork is the standard way a VAST programme goes wrong.
One is the floor plan of how people move through a building; the other is the plumbing and wiring diagram of the block it sits in. You need both, and different people draw them.
saying these in an interview costs you the question
- Says VAST is just STRIDE renamed
- Claims VAST uses only data-flow diagrams
- Treats the operational model as optional paperwork
- Equates a process-flow diagram with a code sequence diagram
- Assumes one application model equals one deployable service