Part VII — Security: ISO/SAE 21434¶

GUIDE · PART VII — ISO/SAE 21434

Disclaimer

Syscribe is a modeling and documentation tool provided "as-is" without warranty of any kind. The authors and contributors accept no responsibility or liability for the use of this tool in safety-critical, life-critical, or mission-critical applications.

Output from Syscribe — including validation results, generated templates, traceability reports, and analysis artifacts — must be independently reviewed and verified by qualified engineers before use in any certification, regulatory submission, or safety case. Compliance with standards such as ISO 26262, IEC 61508, ISO 13849-1, ISO/SAE 21434, IEC 61025, DO-178C, or any other functional safety or cybersecurity standard remains the sole responsibility of the user and their organisation.

This tool does not replace a certified safety process, a qualified safety engineer, or a formal assessment body.

7.1 The TARA workflow¶

Threat Analysis and Risk Assessment follows a chain analogous to HARA, but for security:

Asset (ASSET-*)                ← what is being protected (§15.3)
    ↓ assets:
DamageScenario (DS-*)          ← what damage occurs if the asset is compromised (§15.4)
    ↓ damageScenarios:
ThreatScenario (TS-*)          ← how an attacker achieves the damage (§15.5–15.7)
    ↓ threatScenarios:
CybersecurityGoal (CSG-*)      ← what the system must do to prevent the threat (§15.8)
    ↓ implementsGoals:
SecurityControl (SC-*)         ← the technical mechanism implementing the goal (§15.9)
    ↓ derivedFromCybersecurityGoal:
Requirement (REQ-*)            ← technical requirement derived from the CSG
    ↓ verifies:
TestCase (TC-*)                ← evidence of goal satisfaction

Two authoring styles for TARA elements

This guide shows TARA elements as standalone files — one .md per Asset, DamageScenario, ThreatScenario, etc. This is the recommended approach for large or evolving models because each element is independently diffable and reviewable.

An alternative is the TARASheet container (type: TARASheet): a single file that holds all four TARA tiers as inline tables. The parser expands each row into a first-class element at load time, so all validation rules and cross-reference checks apply identically. The TARASheet approach suits small models or initial drafts where all TARA artefacts fit comfortably in one file. See the Safety & Security Analysis guide for the TARASheet format and syscribe template TARASheet for a ready-to-fill skeleton.

7.2 Assets (ISO/SAE 21434 §15.3)¶

Assets are what an attacker wants to compromise. Define them explicitly before defining damage scenarios.

---
type: Asset
id: ASSET-KERNEL-001
name: "Thread Control Block (TCB)"
status: approved
cybersecurityProperties:
  - integrity
  - availability
assetOwner: SabatonRt::Software::KernelCore
relatedSafetyGoal: Safety::SG-KERNEL-002-SpatialIsolation
---

The TCB holds the thread's register save area, stack pointer, priority, and
IPC waitlist link. Corruption enables priority inversion or control-flow hijack.

cybersecurityProperties must be one or more of: confidentiality, integrity, availability, authenticity (E863 otherwise).

W810 fires if an Asset is not referenced by any DamageScenario.assets: — that means the asset has been identified but no attacker has been imagined damaging it yet.

7.3 Damage scenarios (§15.4)¶

---
type: DamageScenario
id: DS-KERNEL-001
name: "Attacker corrupts scheduler state causing priority inversion"
status: approved
damageSeverity: severe
impactCategories:
  - safety
  - operational
assets:
  - Security::Assets::ASSET-KERNEL-001
  - Security::Assets::ASSET-KERNEL-002
hazardRef: Safety::SG-KERNEL-001-SchedulingIntegrity   # safety↔security co-link
---

hazardRef creates the cross-domain link. W030 fires if a safety-tagged damage scenario lacks a hazardRef. View the full safety↔security overlap:

syscribe -m model co-analysis

7.4 Threat scenarios and risk (§15.5–15.8)¶

---
type: ThreatScenario
id: TS-KERNEL-001
name: "Local attacker overwrites TCB via stack overflow"
status: approved
attackFeasibility: high
attackVector: local
damageScenarios:
  - Security::DamageScenarios::DS-KERNEL-001
riskTreatment: reduce
residualRisk: "Low after PSPLIM stack-limit enforcement (REQ-STKLIM-001)"
---

Risk is derived automatically: score = damageSeverity + attackFeasibility → low / medium / high / critical. W031 fires if a high/critical-risk threat has no riskTreatment and is not addressed by a CybersecurityGoal. Gate this in CI:

syscribe -m model validate --deny W031

Run the full risk matrix:

syscribe -m model cyber-risk

7.4a Configuring the risk and CAL method (`[cyber]`)¶

By default risk is the simple rank-sum above and the expected CAL follows the risk level 1:1 (low→CAL1 … critical→CAL4). Nothing about that changes unless the project adds a [cyber] table to .syscribe.toml:

[cyber]
method = "annex"            # "simple" (default) | "annex"

# Override single cells of the impact x feasibility matrix (merges over the method's base).
[cyber.risk_matrix.moderate]
high = 4                    # integer risk value, mapped to a level by [cyber.risk_levels]

[cyber.risk_levels]         # default: 1,2 low · 3 medium · 4 high · 5 critical
"4" = "high"

# CAL from impact x attackVector, and/or from the risk level.
[cyber.cal_table.severe]
network = "CAL4"
[cyber.cal_by_risk]
critical = "CAL4"

# Attack-potential scoring (used when a ThreatScenario/AttackStep supplies the factors).
[cyber.attack_potential.thresholds]
high_max = 13
medium_max = 19
low_max = 24

The annex tables are examples, not the standard. They are modelled on the informative annexes of ISO/SAE 21434 (attack-potential scoring, a 1–5 risk matrix, CAL from impact and attack vector) as best recalled, and the repository does not contain the standard. Verify every cell against your project's copy of the standard and override with [cyber.*] where it differs. Never cite them as normative.

Attack potential. A ThreatScenario or AttackStep may supply the five factors elapsedTime, expertise, knowledge, windowOfOpportunity and equipment, each a label from its table (e.g. expertise: proficient) or a plain integer of points. The points are summed and mapped through the thresholds to high/medium/low/very_low. An explicit attackFeasibility always wins (W642 if it disagrees with the factors); a partial set of factors is ignored (W641); an unknown label is E641. Attack-tree roll-up (§7.5) uses the derived value for steps that give factors instead of attackFeasibility.

Per-category impact. A DamageScenario may rate each category separately (safetyImpact, financialImpact, operationalImpact, privacyImpact, each severe/major/moderate/negligible, else E640); the overall impact used for risk is the max of these and damageSeverity.

A malformed [cyber] entry raises W640 and only that entry falls back to its default. cyber-risk then adds Vector, Risk value and Expected CAL columns (JSON: method, attackVector, riskValue, expectedCal) and prints the active method. W031 and W032 use the configured matrix and CAL tables.

7.5 Attack trees (§15.7)¶

Attack trees decompose a threat scenario into the attack steps an adversary must execute. Feasibility rolls up automatically — AND gates take MIN (a sequential path is only as feasible as its hardest step), OR gates take MAX (the attacker picks the easiest path). This mirrors FTA logic but for adversarial feasibility rather than random hardware failure.

Directory layout. Gates and steps live under a subdirectory named after the AttackTree file (an AttackTree with no gate/step nested under it raises W036). The tree's computed feasibility is taken from its root — the single gate or step placed directly in that subdirectory — so keep exactly one node there and nest the rest one level deeper. Do not add an _index.md to these subdirectories: each directory already takes the qualified name of the file it is named after (a package _index.md would collide, E108).

model/Security/AttackTrees/
  AT-KERNEL-001.md             ← AttackTree
  AT-KERNEL-001/
    ATG-KERNEL-001.md          ← AttackTreeGate (root gate)
    ATG-KERNEL-001/
      ATS-KERNEL-001.md        ← AttackStep (leaf)
      ATS-KERNEL-002.md        ← AttackStep (leaf)

AttackTree requires id, name, status and threatRef: (E915); threatRef must resolve to a ThreatScenario (E917):

---
type: AttackTree
id: AT-KERNEL-001
name: "TCB corruption via stack overflow"
status: approved
threatRef: TS-KERNEL-001
---

AttackTreeGate requires id, name and gateType: — AND (sequential path) or OR (alternatives), else E919; inputs: lists the child gates/steps by id or qualified name (a gate with no inputs is W037):

---
type: AttackTreeGate
id: ATG-KERNEL-001
name: "Overwrite a TCB"
gateType: OR      # alternative paths — the attacker takes the easiest
inputs:
  - ATS-KERNEL-001
  - ATS-KERNEL-002
---

AttackStep requires id and name; attackFeasibility: is high, medium, low or very_low (E921):

---
type: AttackStep
id: ATS-KERNEL-001
name: "Induce deep recursion in a thread without a stack limit"
attackFeasibility: high
---

---
type: AttackStep
id: ATS-KERNEL-002
name: "Program a DMA-capable peripheral to write kernel memory"
attackFeasibility: low
---

Here the OR gate rolls up to MAX(high, low) = high, matching the attackFeasibility: high declared on TS-KERNEL-001 in §7.4. Had the gate been AND (both steps needed in sequence), the tree would roll up to MIN = low. W035 fires when the computed tree feasibility disagrees with the linked ThreatScenario.attackFeasibility. This is the security equivalent of W033 — it catches inconsistencies between your qualitative threat model and your tree decomposition.

7.6 Cybersecurity goals and CAL level (§15.8)¶

---
type: CybersecurityGoal
id: CSG-KERNEL-001
name: "Prevent scheduler starvation via priority manipulation"
status: approved
securityProperty: availability
calLevel: CAL4
threatScenarios:
  - Security::ThreatScenarios::TS-KERNEL-001
---

W032 fires if calLevel is below the minimum implied by the threat risk level (low→CAL1, medium→CAL2, high→CAL3, critical→CAL4). W802 fires if no SecurityControl implements the goal; W804 fires if no requirement is derived from it.

7.7 Security controls and requirements¶

---
type: SecurityControl
id: SC-KERNEL-001
name: "PSPLIM stack-limit register enforcement"
status: approved
controlType: prevention
implementsGoals:
  - Security::Goals::CSG-KERNEL-001
---

Requirements derived from the cybersecurity goal carry the link:

derivedFromCybersecurityGoal: Security::Goals::CSG-KERNEL-001-SchedulingAvailability

7.8 Security verification (§13.3)¶

Group all security test cases under a security TestPlan with scope: security. The plan demonstrates: the CSGs it provides evidence for. Individual test cases carry securityTestMethod: from the 21434 §13.3 vocabulary.

---
type: TestPlan
id: TP-SEC-001
name: "Kernel Security Verification Plan"
status: approved
scope: security
demonstrates:
  - Security::Goals::CSG-KERNEL-001
  - Security::Goals::CSG-KERNEL-002
selection:
  tags: [security]
---

# On a relevant TestCase:
tags: [security]
securityTestMethod: penetration_test

W612 fires if the plan's effective test case set is empty (tags don't match any TestCase).

7.9 Vulnerability tracking¶

Track discovered CVEs with VulnerabilityReport:

---
type: VulnerabilityReport
id: VR-KERNEL-001
name: "Stack overflow via unbounded recursion in thread entry function"
status: open
cvssScore: 7.2
mitigatedBy:
  - Security::Controls::SC-KERNEL-001
affectedElements:
  - SabatonRt::Software::KernelCore
---

W803 fires when status is open — use this to track unresolved vulnerabilities in the gate.

7.10 What syscribe does NOT compute for security¶

Unlike the safety side (where syscribe metrics gives quantitative PMHF / SPFM / LFM), the security computation remains qualitative — this mirrors ISO/SAE 21434 itself, which defines CAL 1–4 (qualitative risk levels) rather than a numeric probability target.

The attack tree feasibility rollup and the cyber-risk risk matrix are the security equivalents of the fault tree probability rollup, but they produce low / medium / high / critical verdicts rather than numeric failure rates.