Changes from SAE and ISO 21434 DIS to Final

Since 21434 is final now, I collected the most important changes that happened to the TARA-related parts since the first public draft:

Controls as primary citizens

  • Controls are part of the security concept [RQ-09-08] and not only arise during development
  • Controls and their interactions are introduced based on function dependencies and claims [RQ-09-08] 

Iterative work on living documents

  • “[Development (10)] cybersecurity activities are performed iteratively until no further refinements of cybersecurity controls are needed”
  • Consider modularity when selecting your cybersecurity specification notation [RQ-10-04]
  • “The [TARA] methods […] can be invoked systematically, and from any point in the lifecycle of an item or component” [Clause 15]
  • “Threat scenarios can be updated based on the result of [evaluating cybersec. events].” [8.4.2]

TARA workflow got cleaned up

  • Risk Treatment Decisions are part of the TARA. Their rationales are called “claims” are prerequisites for the concept and go to monitoring
  • Use threat scenarios for calculating risk values instead of attack paths
  • The item definition is used on initial analysis of the whole item. After a component has passed development, its cybersec. specification is used for TARA-activities

TARA levels and categories got fixed

  • Fixed minimal set of impact categories: SFOP [RQ-15-04] with the rating within each being one of Severe, Major, Moderate, Negligible [RQ-15-05] (but you only need to rate the most-critical one)
  • Fixed set of Attack Feasibility Levels: High, Medium, Low, Very Low [RQ-15-10]
  • Fixed set of risk values: 1, 2, 3, 4, or 5 [RQ-15-16]

I like how they changed the role of controls in the process. This allows analysts to already think about controls during conception and then come up with a cybersecurity plan that might actually work. It will also allow them to modify a risk treatment decision based on how easy it turns out to control that risk. For example, we could possibly plan to transfer financial risk with an insurance if we don’t find an adequate control.

Additionally, fixing the impact and feasibility levels will ease the life of security consultants who might have multiple clients. However, it will not necessarily make analyses comparable across vendors, since it still remains non-standard, what precise level maps to which reality (such as how many euro will make it a Moderate impact?). Overall, these changes should be easy to digest.

What now?

Want to discuss further? Feel free to contact the itemis SECURE Team. Otherwise, read more on our insights from reading ISO21434.