Cybersecurity goals are security requirements that are identified in the concept phase of a product. Each goal is associated with one or more Threat Scenarios. They are part of the security concept that is supposed to be implemented in the development phases. Security goals are created based on the risks that have been decided to be reduced. The risks and their treatment decisions (such as reduction) are the major outcome of the TARA.

The role of cybersecurity goals

The DIS lists the following relationships for security goals in Figure 2 of the PDF:

  • cybersecurity goals are allocated to an item
  • cybersecurity goals are mitigating the risk of an asset
  • cybersecurity goals are addressing damage scenarios and through them have an indirect reference to the threat scenarios which lead to them
  • cybersecurity goals are realized by cybersecurity requirements

With these relationships, security goals serve as some central connecting element between assets, damage scenarios and cybersecurity requirements. However, we should remember that security goals are not created yet, when performing the TARA. As a result, the ISO examples (Appendix G) create a chain of elements: The items relate to the assets, which are attributed by a cybersecurity property, which is compromised by a damage scenario, which is lead-to by a threat scenario. The security goals then will have a relationship to a subset of these: items, assets, and damage scenarios.

The DIS PDF of ISO21434 calls the whole section 9.4 “Cybersecurity Goals”. The section lists goals and claims as its work products. These are mainly based on the identified risks and decided treatments. To get these risks and treatment decisions, it asks to perform a TARA as specified in clause 8.

Parallels to Safety

The term Cybersecurity Goal aligns well with the term Safety Goal, as it is introduced in ISO26262. Albeit it doesn’t work to reuse the processes or tools between the security and safety domains (they are of too different natures for that), the goals of the two disciplines are both high-level concept-time requirements. One major difference to safety is though, that security controls are heavily intertwined with the concrete implementation details. As a result, the implementation of security controls requires reanalyzing the system’s security. Especially the assets that are introduced with a control need to be considered. While hierarchical safety requirements work well in a V-model process, the strong dependency on controls gives security processes an iterative nature. Consequently, safety goals have a different role for a safety process than security goals have for a security process.

What now?

Want to discuss about what are Security Goals according to ISO21434 further? Feel free to contact the itemis SECURE Team. Otherwise, read more on our insights from reading ISO21434.