Skip to main content

What You Will Achieve

By the end of this tutorial you will have:
  • Identified threats with stakeholders, CIAx properties, damage and threat scenarios
  • Scored attack feasibility using 5 factors (TIME, EXP, KNOW, WOO, EQP)
  • Assessed risk verdicts using the Impact x Feasibility matrix
  • Defined risk treatment with cybersecurity goals and risk controls
  • Linked cybersecurity requirements and verification test cases

Prerequisites

RequirementDetails
TARA moduleCreated per Create Your First TARA Module
TARA recordsAt least 2-3 records with stakeholders and damage scenarios
CatalogsPopulated Threat Scenario and Stakeholder catalogs

Step 1: Identify Threats

Switch to view: “1. Identify Threats” This view shows the threat identification columns: stakeholder, ciaxProperty, damageScenario, threatScenario, and threatPath. For each TARA record:
  1. Stakeholder — Select the affected party from the Stakeholder Catalog dropdown (e.g., Vehicle Occupants, Road Users).
  2. CIAx Property — Choose the security property under threat: confidentiality, integrity, availability, authenticity, authorization, or nonRepudiation.
  3. Damage Scenario — Describe the harm that results from the threat being realized.
  4. Threat Scenario — Select a named scenario from the Threat Scenario Catalog dropdown.
  5. Threat Path — Describe the concrete attack vector or entry point.
Step 1 implements Clause 15.5 (Threat Scenario Identification) and Clause 15.4 (Damage Scenario Identification). Each record captures a unique combination of stakeholder, security property, and attack vector.

Step 2: Assess Feasibility

Switch to view: “2. Assess Feasibility” This view adds the 5 attack potential factors alongside the threat columns. For each TARA record, score the following factors:
FactorColumnOptions
Elapsed TimeattackTime<= 1 day (0), <= 1 week (1), <= 1 month (4), <= 6 months (17), > 6 months (19)
Specialist ExpertiseattackExpertiseLayman (0), Proficient (3), Expert (6), Multiple Experts (8)
Knowledge of ItemattackKnowledgePublic (0), Restricted (3), Confidential (7), Strictly Confidential (11)
Window of OpportunityattackWooUnlimited (0), Easy (1), Moderate (4), Difficult (10)
EquipmentattackEquipmentStandard (0), Specialized (4), Bespoke (7), Multiple Bespoke (9)
The taraFeasibility column auto-computes via the feasibilityFormula:
  • Sum of all 5 scores determines the aggregate feasibility level
  • Sum <= 13: High (easy to attack)
  • Sum 14-19: Medium
  • Sum 20-24: Low
  • Sum >= 25: Very Low (hard to attack)
The scoring system follows ISO/SAE 21434 Annex G (Attack Potential-based approach). Higher scores mean more difficult attacks and lower feasibility. See Attack Feasibility Scoring (EVITA) for the full rationale.

Step 3: Risk Assessment

Switch to view: “3. Risk Assessment” This view shows taraImpact, taraFeasibility, and taraVerdict. For each TARA record:
  1. Select an Impact level in the taraImpact column:
    • Severe — Life-threatening injuries; severe regulatory violation
    • Major — Severe injuries; significant consequences
    • Moderate — Light injuries; moderate consequences
    • Negligible — No injuries; negligible consequences
  2. The Verdict auto-computes from the risk matrix:
ImpactVery LowLowMediumHigh
Severe3455
Major2345
Moderate1234
Negligible1111
Verdict values are color-coded from green (V1) to red (V5). The row header also changes color to match the verdict.
Verdict 4 and 5 are unacceptable. They appear on the TARA Report dashboard as action items requiring immediate treatment. See Assess Risk Verdict.

Step 4: Risk Treatment

Switch to view: “4. Risk Treatment” This view adds treatment columns: treatmentChoice, treatmentStatus, cybersecurityGoal, goalCal, taraClaims, task (Risk Control), and taskTitle. For each TARA record with verdict >= 3:
  1. Select a Treatment Choice:
    • Reducing — Apply controls to lower the risk
    • Avoiding — Eliminate the threat source or vulnerability
    • Sharing — Transfer risk to another party
    • Retaining — Accept the risk with documented justification
  2. Based on the treatment choice: For Reducing or Avoiding:
    • Link a Cybersecurity Goal using the dropdown picker (creates a hasCybersecurityGoal link)
    • The CAL column auto-populates from the goal’s cal field. The calDecorator validates that the CAL meets the minimum for the verdict level (e.g., Verdict 5 requires CAL 4)
    • Add Risk Controls: create or link riskControl work items using the task column (creates a mitigates link)
    For Retaining or Sharing:
    • Document a Cybersecurity Claim in the taraClaims column justifying the decision
  3. Set the Treatment Status: planned, ongoing, or completed.
The Risksheet highlights missing fields with orange outlines. If you select Reducing/Avoiding but leave the cybersecurity goal empty, the goalHighlight decorator shows “Goal required.” Similarly, Retaining/Sharing without a claim triggers the claimHighlight decorator.

Step 5: Requirements and Verification

Switch to view: “5. Req & Verification” This view shows the downstream traceability: cybersecurityGoal, goalCal, task (Risk Control), taskTitle, requirements, and verification.
  1. For each cybersecurity goal, create cybersecurity requirements (sysReq type with classification = cybersecurity) that derive from the goal using the derivesRequirement link role.
  2. For each risk control, create requirements that implement the control using the implements link role.
  3. Link test cases (testCase type) to requirements using the verifies link role.
The requirements and verification columns use server-side rendering to traverse these link chains automatically:
  • Requirements column: shows all sysReq items linked from the risk control via implements
  • Verification column: shows all testCase items linked from requirements via verifies
The TARA solution implements two traceability tracks that converge at requirements and test cases. See Traceability Chain for the full architecture.

Verification

After completing all 5 steps, verify your work:
  1. TARA Report — Navigate to the TARA Report dashboard. Confirm your module appears in the structure tree with correct verdict distribution.
  2. Cybersecurity Case — Check that cybersecurity goals and requirements appear in the assurance argument dashboard.
  3. Overview — Switch to the Overview view in your Risksheet. All records should have verdicts, treatment choices, and linked goals or claims.

Next Steps