The concept of connected vehicles wherein a gamut of software inside a car interacts with the physical world, brings in safety and security concerns. An ADAS system that is connected to an external cloud is vulnerable to cyber-attacks that might result in the hacker taking control of the car. Several such incidences have been recorded in the past.
ISO 26262 standard has been around for a decade now and has become a de facto standard for ensuring functional safety while developing automotive software or hardware. More recently, with the development of various cyber-physical systems, security has emerged as an equally concerning and important issue. And the release of ISO 21434 standard for automotive cybersecurity makes it amply evident.
It is not the first automotive cybersecurity standard to be released. However, ISO 21434 has been created keeping in the mind the ever-evolving threat landscape, and that makes it the most definitive standard for cybersecurity. The standard also incorporates various aspects of other standards such as SAE J3016.
ISO 21434 standard has been created along the lines of ISO 26262 standard and therefore, you would find a lot of similarities in terms of processes. As a matter of fact, several members of ISO 26262 committee were also part of the committee put together to prepare ISO 21434 standard.
The reason why we are discussing functional safety and cybersecurity in the same breath is due to the fact that both showcase a high degree of overlap. If you happen to look at SAE J3016 model, safety-critical system is considered as a sub-set of cybersecurity-critical system. Even in terms of processes, there is a lot in common.
In this blog, our focus will be on the commonalities between the implementation of FuSa and automotive cybersecurity and how the two standards overlap.
ISO 26262 and ISO 21434: Commonalities and Differences
Both these standards provide a set of guidelines to achieve their respective goals. In the context of FuSa, it is all about meeting the safety goals while developing an automotive solution. On the other hand, cybersecurity standard aims to help you achieve protection from cyberattacks. In both cases, the lifecycle starts with identifying the items to work on and moves on to finding the risks, threats and finally ends with developing the solution in a way to mitigate these risks and threats.
Let’s put both ISO 26262 and ISO 21434 lifecycle side by side and make a comparative study.
At first glance, you can spot a lot of similarities in the way both standards explain their scopes. There is the management phase, concept phase, product development phase and post development phase. Since ISO 21434 follows the same approach as ISO 26262, these similarities are expected. However, a closer view brings forth a few new phases that are unique to cybersecurity.
New additions in ISO 21434 are:
- Part 6 – Project dependent cybersecurity management: Since the requirements and application of cybersecurity might differ across automotive solutions, part-6 has been added to the standard.
- Part 7- Continuous cybersecurity activities: Cybersecurity threat is ever-evolving which makes it a continuous activity. New threats must be analyzed, and the automotive software must be updated to deal with them. In this regard, cybersecurity has a sharp contrast with functional safety standard wherein, hazards and associated risks are analyzed on the onset and safety mechanisms are put in place.
- Part 8- Risk assessment methods: ISO 21434 standard explicitly specifies the methods for risk assessment which include processes such as asset identification, attack path analysis and so on. ISO 26262 specifies HARA as the primary way to identify hazards and associated risk and is pretty much covered in the concept phase.
In the diagram below, a correlation between ISO 26262 and ISO 21434 has been showcased. HARA is replaced with TARA, safety goals with security goals and safety requirements with security requirements. At the core of it, the execution and work products of these activities are quite similar. The requirement flows down from the product’s concept phase to the design and implementation phases. Post the implementation phase, integration, and validation follows that leads to the production phase.
Integration of ISO 26262 and ISO 21434: Challenges and Solutions
Conceptually, most of the analysis like HARA and TARA are quite similar. Security and safety team usually work in tandem so that any common work products can be shared. In the previous sections, we observed how different activities in ISO 26262 can be corelated to ISO 21434, be it HARA or safety concepts or safety goals.
In order to design a system that is both safe and secure, multiple challenges need to be mitigated. From requirement traceability, coding compliance and structural coverages to tool qualification and code verification, FuSa and cybersecurity experts have a lot to think about. Integration of both standards seem to be the right approach to ensure that functional safety and cybersecurity concerns are handled in tandem and both teams are able to share resources, work products, tools and more. In addition to sharing resources, there is a lot more that can be achieved if integration of ISO 26262 and ISO 21434 is done right.
For instance, Hardware Security Module (HSM) has emerged as one of the reliable components to implement cybersecurity. Keeping functional safety in mind, HSM can be developed as safety element out of context as per the ASIL requirements specified in ISO 26262 standards. It can then be integrated in the ECU in a manner that prevents interference between HSM and the host ECU and hence does not impact any of its safety-relevant function.
Some of the best practices that can be incorporated for the successful integration of ISO 26262 and ISO 21434 are:
- Cybersecurity aspects should be incorporated into the functional safety assessment
- Risk assessment during security lifecycle should be ideally carried out from the perspective of functional safety
- If the project under development has a cybersecurity aspect to it, ASIL should be determined keeping cybersecurity related threats also
- Communication networks should be designed such that there is enhanced protection of safety-relevant data
- Components responsible for ensuring cybersecurity should be utilized in ways to achieve functional safety, for example hardware security module.
Final Remark
Modern connected vehicles need to be as secure as they are safe. In many aspects, security will be directly responsible for safety of the vehicle. Hence, there is a need for cybersecurity and functional safety to work in tandem.
The similarity between both the standards clearly highlights their co-existence. Since the cybersecurity standard is relatively new, we will soon be witnessing various tools that would support implementation of both standards simultaneously. Whatever the future holds, it would be interesting to see different stakeholders work together to realize the concept of cybersecurity and functional safety together.
