I love the summer holidays! Even more when I haven’t much of a plan and can enjoy a sense of freedom and adventure. A few years back, I went traveling with a campervan with a few friends, and we did exactly that. In fact, with the COVID-19 situation, traveling with a campervan is a great holiday option. The only problem is that I don’t quite enjoy driving. I would rather plan my next destination, sit back, and relax watching the view, chatting, or sleeping and waking up at the arrival. We are not there yet, but the technology for autonomous vehicles (AVs) is progressing rapidly. I am confident it is only a matter of time. Unfortunately, cybersecurity attacks are also on the rise. Should I worry that some nasty engineers may hack my vehicle and drive me to the office instead of my favorite beach?
The upcoming ISO/SAE 21434 international standard is dedicated to the cybersecurity of electrical and electronic (E/E) systems in road vehicles. Besides reducing the risk of holiday disruptions, the standard will dramatically improve the privacy of car owners and help protect intellectual properties (IPs) and other assets of car producers and their supply chain. As there is no safety without security, a successful car hack could put many lives in danger. That is why ISO/SAE 21434 references and complements the ISO 26262 automotive functional safety standard. As it may be expected, threat scenarios that could lead to high-severity consequences deserve more attention and, potentially, require the specification and implementation of controls for risk reduction.
In my previous post, I introduced the new 6 Minutes of Security blog series from OneSpin Solutions. In this post, I am going to look at two specific aspects of ISO/SAE 21434, namely the concepts of risk value and cybersecurity assurance level (CAL).
ISO/SAE 21434 demands that for any identified threat scenario, a risk value is determined. This is a number between 1 (lowest risk) and 5 (highest risk). The risk associated with a threat scenario depends on the feasibility of the attack and its impact. If the attack requires a team of expert hackers and costly equipment, the risk will be lower compared to an attack that anyone can execute and lead to the same damage. In the worst-case scenario, the attack is easy to carry out and has severe consequences. The standard does not prescribe a specific method to analyze the system and calculate risk values, but it does provide some guidance and examples.
The Cybersecurity Assurance Level (CAL) is an attribute that can be associated with a system, a component, or a specific cybersecurity goal. There are 4 CALs, CAL1 being the least stringent, and CAL4 the most demanding. The CAL is determined based on information on the attack and its impact. Depending on the target CAL, certain cybersecurity activities can be omitted or carried out with less rigor. A component classified as CAL4 indicates that it might be suitable to perform critical functions that require a high level of security assurance and protection of critical assets. CALs are important to tailor cybersecurity activities according to the target assurance level and to simplify the communication among stakeholders and parties in the supply chain. Engineers familiar with ISO 26262 will see a strong resemblance between CALs and Automotive Safety Integrity Levels (ASILs).
While CALs and risk values may sound similar, they are, in fact, quite different. CALs are described in an annex of the standard, which is an informative (as opposed to normative) section. This could change in the first release of the standard. Apparently, CALs are a controversial topic within the committee developing the standard, and subject to an ongoing debate. The concept of risk value and its determination, on the other hand, is part of ISO/SAE 21434 requirements. Moreover, while CALs are, at least in an ideal case, constant, risk values may change during the product lifecycle. A risk value that is deemed too high may trigger the implementation of additional controls until it is reduced to an acceptable level. During product operation, a new vulnerability could be discovered, which increases the risk value.
I hope you found this post interesting. In future posts, I will cover other aspects of the ISO/SAE 21434 standard and make comparisons with ISO 26262.
(all posts) Sergio Marchese is technical marketing manager at OneSpin Solutions. He started his career at Infineon Technologies, applying coverage-driven constrained-random simulation and formal methods to verify the TriCore CPU, an architecture widely used in today's automotive SoCs. He has since worked on projects in the communications, consumer, industrial and aerospace domains. Most recently, he served as verification expert at Huawei Technologies, leading worldwide formal verification activities for ARM CPU and consumer SoC designs. Marchese also built and managed state-of-the-art teams, successfully signing off complex hardware designs using formal verification.