THREAT SENTINEL X · TARA WORKBENCH
The TARAstops beinga spreadsheet.
Capture the item once — TSX builds the data-flow diagram, enumerates the threat register, scores attack feasibility against ISO/SAE 21434 §15.7, traverses the attack paths, and renders the signed deliverable your submission actually needs.
+ 34 more scenarios
Every row traces to its node, its catalogue entry and its §15.7 factors
- ISO/SAE 21434 §15
- UN R155
- UN R156
- AIS-189
- AIS-190
- STRIDE-LM
01 — The problem
Two engineers, one item, two different answers.
A TARA is weeks of expert spreadsheet work, and it is subjective. Give the same item to two competent engineers and you get materially different registers, different risk values, different assurance levels. The assessor notices — and asks which one is right.
But most of that work is not judgment. Enumerating threats across the architecture, scoring five feasibility factors, deriving risk and CAL, tracing goals back to threats, formatting a deliverable to clause order — that is mechanical, and it is exactly where the weeks go.
TSX takes the mechanical part and makes it repeatable, so the expert spends their hours on the part that actually differentiates an analysis: what is in scope, what the damage really is, and which argument will survive an assessment.
02 — The workbench
Item in, deliverable out.
A worked example: a body control module on two CAN-FD segments with a LIN sub-bus.
1.0
The item, described once.
Item definition, security functions, ECUs, interfaces, message flows, damage scenarios rated across safety, financial, operational and privacy. Entered once and reused by everything downstream.
- ECUs in scope
- 7
- Interfaces
- 2 × CAN-FD · 1 × LIN · 1 × DoIP
- Message flows
- 34
- Damage scenarios
- 9 · rated S/F/O/P
- Trust boundaries
- 3
The data-flow diagram is generated from this, not drawn by hand
2.0
A register, from a governed catalogue.
Threat scenarios drawn from a versioned STRIDE-LM catalogue your methodology team controls — so the analysis reflects your house method, and two projects a year apart are still comparable.
+ 34 more scenarios
Every row traces to its node, its catalogue entry and its §15.7 factors
3.0
Attack paths over your own diagram.
Entry points walked through the item's actual data-flow diagram to their targets. Not a canned list of generic paths — the ones your topology permits.
- EntryDoIP diagnostic interface
- Hop 1Gateway ECU · session hijack
- Hop 2CAN-FD 1 · forged frame
- TargetBody control module · door actuator
Traversed over this item's own diagram — not selected from a canned list
4.0
The document the submission needs.
An OEM-style PDF mapped clause by clause across §15.3 to §15.9, with a prepared-reviewed-approved grid, plus XLSX for the engineers who have to work the register.
- §15.3 Asset identification
- 7 assets
- §15.4 Damage scenarios
- 9
- §15.5 Impact rating
- S/F/O/P
- §15.6 Threat scenarios
- 39
- §15.7 Attack feasibility
- 39
- §15.8 Risk & treatment
- 39
- §15.9 Cybersecurity goals
- 12
Sign-off
PDF and XLSX, mapped clause by clause
03 — The determination
Arithmetic, not opinion.
The part an auditor will ask about, and the reason the answer holds.
Attack feasibility resolves through the ISO/SAE 21434 §15.7 five-factor model — elapsed time, specialist expertise, knowledge of the item, window of opportunity, equipment. Impact comes from the damage ratings you set. Risk is a lookup in a fixed matrix. CAL follows defined rules.
Change nothing about the item and every one of those values is identical on the next run. That is not a claim about discipline; it is a property of using tables instead of judgment for the parts that should not vary.
Same input, same numbers, every time — which is precisely what an assessor asks about a tool.
04 — A platform, not a script
Built for a team that will be audited.
Tenant isolation in the database
Separation is enforced by the database itself, not by a filter in application code — so a bug in a query cannot return another tenant's analysis.
Six roles, enforced twice
Permissions are checked at the API and reflected in the interface, so a reviewer sees a reviewer's controls and an approver's actions are actually restricted to approvers.
An audit log
Who changed which analysis, and when. The record an assessment asks for about the tool itself, not only about the vehicle.
Concurrent editing that fails safely
Two analysts on one project get an explicit conflict rather than a silent overwrite, and a project can be locked while it is being assessed.
05 — Built for
Three people, three reasons.
OEM homologation manager
TARAs arrive from three suppliers in three formats with three risk philosophies. Comparing them is archaeology. One method, one register shape, one set of rules makes them comparable.
Tier-1 product security
Every new item starts as a copy of the last spreadsheet, carrying its mistakes forward. Capture the item and the register, the scoring and the document come from the same governed source each time.
Tier-2 supplier
You have been asked for a 21434 TARA for the first time and handed a template that explains nothing. This is the method, with the arithmetic already in it.
06 — Where it sits
Against the tools you are probably comparing.
A spreadsheet
Free, universal, and the reason two engineers disagree. No versioned catalogue, no enforced scoring, no audit trail, and a deliverable assembled by hand every time.
A European modelling suite
Deep, capable, and priced and scoped for an organisation that already runs model-based engineering. If you are standing up your first TARA practice, most of that surface is a cost, not a feature.
An AI copilot
Fast at drafting, and — where risk values come out of the model — variable between runs. TSX is the other half of that trade: the determination is a table lookup, and the language work stays with your engineer.
07 — In practice
How a team actually runs it.
Four situations we built this for, because they are the four that consume the weeks.
Your first TARA, with nobody to copy from
A customer asks for a 21434 analysis and sends a template that explains nothing. Capture the item, and the method is already in the tool: the register comes from a governed catalogue, feasibility scores against the §15.7 factors, and the deliverable renders in clause order. You are learning the method by producing a real one, not by reading it.
A portfolio, not a project
Twenty items across three platforms, each analysed by a different engineer in a different quarter. One catalogue, one scoring scheme and one document template mean a register from March and a register from October are still comparable — and when the catalogue is updated, you know exactly which analyses were built on the old one.
The change that touches everything
A gateway is redesigned and six items reference it. Update the topology and re-run: the diagram, the paths and the determinations follow, and you review what moved instead of hand-checking twenty spreadsheets for the consequence.
The assessment itself
An assessor opens the register and asks how one risk value was reached. Every row traces back to its node, its catalogue entry and its five feasibility factors — so the answer is a screen, not a promise to check and come back.
08 — What you get
The deliverable, and everything under it.
Bring the TARA you least want to redo.
Give us one item you have already analysed. We will run it through TSX beside your existing register and walk you through both — including wherever ours is weaker.
Request a walkthrough09 — Start here
Bring us the file you are least sure about.
Most conversations start with a gap assessment, or a type approval submission that is closer than it feels. Either is a good place to begin.
Direct
- Email[email protected]
- Phone+91 98672 75102
- Book a callcalendly.com/contact-autosifu
Jaipur · registered office
Plot No. 8, ABS Plaza, Chanakya PuriJagatpura, Jaipur – 302017, RajasthanAUTOSIFU Pvt Ltd · India