Threat Modeling

Threat Modeling turns a finished item definition into a TARA: VSEC reads the item’s components, connections, cybersecurity properties, and assumptions and generates the ISO/SAE 21434 §15 analysis — damage scenarios, threat scenarios, and attack paths — then lands you on a worst-first list of risks to review. Accept the real ones and they become risks in Risk Manager, each with a deterministic 1–5 score. This is assessment only; treatment stays in Risk Manager.

Open it from the sidebar under Tools → Design → Threat Modeling, a peer of Item Definition.

Before you run: agree the impact

The impact half of a TARA — the damage scenarios (ISO/SAE 21434 §15.4) — is settled first, on the item definition itself. A Damage scenarios panel sits under the item definition canvas:

• Generate proposes a first pass of damage scenarios from the item definition (the button reads Re-generate once AI-proposed scenarios exist). Each proposed scenario carries a source chip — AI for generated, Added for one you entered by hand.
• Each row rates impact across the four SFOP categories — Safety, Financial, Operational, and Privacy — from 0 to 5, and carries a Status of Proposed, Approved, or Rejected. Editing a rating approves that row (an edited rating is a decision); a status dropdown lets you approve or reject without editing.
• Only Approved scenarios feed into the next TARA run as fixed, agreed impact; the risks the run finds score against them.

This stage is optional — you can run the TARA directly and it will identify the damage scenarios itself.

Running a TARA

A TARA is run from an item definition, not from this page. Open one under Tools → Design → Item Definition and click Run TARA in the page header (the button reads Re-run TARA once a run exists, and Running TARA… while one is in flight). VSEC analyzes the item definition in the background — this usually takes a minute or two, and the run’s page updates on its own.

TARA generation uses the workspace’s configured intelligence provider. The generated run records which provider produced it, shown next to the run.

The item definition page also shows a TARA chip linking to the latest run for that item, so you can get back to it without hunting through the list.

Importing an existing TARA

If you already have a TARA in a spreadsheet, you can import it instead of generating one from scratch. VSEC extracts the workbook into a provisional item definition and threat run — the same review you’d get from a generated TARA — and, as with a generated one, nothing lands in Risk Manager until you accept. Like generation, the import uses the workspace’s configured intelligence provider.

There are two ways in:

• From an item definition — click Import existing TARA in the item definition page header. The Import existing TARA dialog takes one Excel workbook (.xlsx, .xlsm, or .xls); choose the file and click Import.
• From an asset — when you attach an Excel workbook to an asset and VSEC recognizes it as a TARA, a VSEC Design data detected card appears in the asset’s files, offering Import into VSEC Design (or Dismiss). The detection is a quick, deterministic check of the file — no analysis runs until you choose to import.

Either way, VSEC extracts the workbook in the background and notifies you (“Imported TARA ready to review”) when the run is ready. The import lands the item’s components, connections, subassets, and damage scenarios on a provisional item definition, and its risks in a threat run you review here on the Threat Modeling page exactly like a generated one — accepting a risk promotes it into Risk Manager.

The Threat Modeling list

The Threat Modeling page lists every TARA run across your item definitions. Filter chips across the top double as a queue, each showing a count:

• Needs review — a completed run whose risks haven’t been decided yet. The page opens on this filter when anything is waiting.
• In progress — a run still being generated.
• Stale — a run whose item definition changed after the run completed (only shown when there are any).
• Reviewed — a run whose risks have all been decided.
• All runs — everything.

Each run shows its item name, when it was generated (and the provider), and a status chip: Running…, {N} risks to review, Reviewed, or Failed. A run whose item definition has changed since it ran also carries an Item changed since run warning. Click a run to open it.

Reviewing the risks

A completed run opens on its risk list — highest concern first, sorted by the as-generated score so the order is stable across edits and reloads and a card never jumps out from under you. The header states how many risks were found; filter chips (All, To review, Accepted, Dismissed) narrow the list.

Each risk is a card. Collapsed, it’s a one-line read:

• a score chip — the 1–5 risk value (green 1–2, amber 3, red 4–5), or — when the risk has no attack path yet and so no feasibility to score against;
• the risk title, its anchor asset, and a narrative phrase combining the impact level (None, Negligible, Moderate, Major, Severe) with how exploitable it is (easy, feasible, hard, or very hard to exploit);
• an Accept button.

Expand a card for the reasoning in prose, laid out as Damage — the harm, Threat — how, and the Attack path. The two things that drive the score are edited in place by clicking them:

• Click the Impact chip to open the Impact ratings (SFOP) editor and set the Safety / Financial / Operational / Privacy ratings (0–5). The impact level is the worst of the four.
• Click an attack step to open its feasibility editor — the ISO/SAE 21434 Annex I attack-potential factors: Elapsed time, Expertise, Knowledge of the item, Window of opportunity, and Equipment. The step’s points, the path’s feasibility, and the 1–5 score recompute live as you change them, the same way the scoring engine does.

Accepting and dismissing

• Accept records the risk as real and promotes it into Risk Manager in one motion — a toast confirms “Risk created in Risk Manager”, and the card then links View in Risk Manager. Accept all does the same for every risk still awaiting a decision.
• Dismiss (from a card’s “This isn’t a real risk — dismiss it” link) marks a risk as not real and removes it from the review. It’s gated by a confirmation dialog — even a negligible risk is normally worth keeping, so dismiss only something the analysis got wrong. Dismissing does not delete other risks in the run.

Export JSON on the run page downloads the whole review payload.

If the item definition changed after the run, the run page shows a warning that the analysis may be out of date, with a Re-run TARA button that starts a fresh run on the current item definition.

Permissions

The Threat Modeling entry sits under Tools → Design, so — like Item Definition — it’s subject to the Design permission block being enabled for your workspace. Accepting a risk creates it in Risk Manager, so it also depends on your permission to create risks there.