Synopsys Cloud
Cloud native EDA tools & pre-optimized hardware platforms
Request a Free Trial →
Imagine driving off in your car and being able to rely on it to avoid collisions, properly light your path on a dark and winding road, and to stay in its lane. But, suddenly, the car accelerates and drives off the road. Has your car been hacked?
The above scenario is not so far-fetched—two ethical hackers pulled off a similar stunt with a Jeep Cherokee a few years ago. It goes without saying that vehicles cannot truly be safe if they are not also secure. In the automotive industry, functional safety and cybersecurity go hand in hand. This is evident with the impending release of ISO/SAE FDIS 21434 Road Vehicles – Cybersecurity Engineering, which was built with the ISO 26262 functional safety standard as its foundation. While ISO 26262 is designed to protect vehicles against hardware and systemic faults, ISO/SAE 21434 provides a cybersecurity framework for the lifecycle of road vehicles.
In this blog post, we’ll provide an overview of the key points addressed by ISO/SAE 21434. In addition, we’ll also explore how this automotive cybersecurity standard might impact electronic design automation (EDA) and IP solutions.
What Is ISO/SAE 21434?
ISO/SAE 21434 provides a rigorous framework intended to enable organizations to design vehicles that are protected against cybersecurity threats. The new standard, scheduled to be released in late 2021, covers:
- Security management
- Project-dependent cybersecurity management
- Continuous cybersecurity activities
- Associated risk assessment methods
- Cybersecurity within the concept product development and post development stages of road vehicles
- Ongoing cybersecurity monitoring
As with ISO 26262 on the functional safety side, ISO/SAE 21434 maps out planning activities that a design team’s processes, procedures, and documentation should align with in order to be prepared for upcoming regulatory requirements and independent cybersecurity audits. Complying with the new standard starts with a cybersecurity plan, and organizations are encouraged to define a series of cybersecurity assurance levels with associated goals and measurable metrics for each.
Managing cybersecurity risk, another important element of the standard, can be done via Threat Analysis and Risk Assessment (TARA). TARA covers risk evaluation and assessment methods, plus treatment and planning of identified risks. The methods are aligned with NIST SP-800-30 and ISO IEC 31010, which address the likelihood and associated impacts of attacks. TARA encompasses:
- Asset identification. The design team determines the security properties of each asset, along with the damage scenarios and their impacts from a road user perspective.
- Threat identification. After the team compiles the impacts of the damage scenarios, the next step is to identify the threats against them.
- Risk calculation and communication. A key outcome of the risk calculation exercise is a list of impact scenarios with identified risk ratings. The team will need to determine whether to avoid, reduce, transfer, or accept each risk. Risks should be communicated via a common language in policies and procedures.
How Does ISO/SAE 21434 Impact EDA Tools and IP?
Now that we’ve discussed the essentials of ISO/SAE 21434, let’s consider how the new standard might affect the EDA and IP world. Chip design software was not a part of the conversation when the standard was developed. However, thinking about the automotive value chain and how ISO 26262 has impacted EDA and IP solutions from a functional safety perspective, it’s not a stretch to conclude that ISO/SAE 21434 will have a similar impact on the cybersecurity side.
ISO/SAE 21434 is focused on developing consistent and repeatable processes to protect vehicles against malicious attacks, which are often unpredictable, for the duration of their lifecycles. Indeed, governments are calling on vehicle equipment manufacturers to consider the impacts of cyber-attacks. In the U.S., for example, the National Highway Traffic Safety Administration (NHTSA) has recently updated its Cybersecurity Best Practices for the Safety of Modern Vehicles report, which has implications across the vehicle supply chain. If electronic components and software are part of this mix, it stands to reason that this would also include the chip design, verification, and prototyping software and IP blocks that are used to create the components, along with the solutions used to build secure, high-quality software.
Cybersecurity starts at the foundation, so EDA vendors should build cybersecurity protections into their tools and IP from the beginning. While there aren’t yet ISO/SAE 21434 certification requirements for EDA solutions, this could happen down the road, as has happened with ISO 26262. For example, on the functional safety side, Synopsys offers various solutions that are aligned with ISO 26262, providing ASIL B and ASIL D compliance. DesignWare® IP for Automotive, for instance, is ASIL B and ASIL D compliant for ISO 26262 random hardware faults and systematic development, while automotive chip design and verification tools are certified to ISO 26262 ASIL D to accelerate quality and functional safety qualification. In the future, solutions might similarly be required to comply with ISO/SAE 21434. The automotive cybersecurity standard compels manufacturers to establish functional requirements for a product to meet, along with verification requirements to validate that the cybersecurity objectives have been satisfied.
To help vendors establish security objectives and requirements for their products, there are knowledge bases available of well-known attacks, attack patterns, and software weaknesses that can inform the design of EDA and IP solutions. These insights can help simplify the process of providing systematic analysis of vulnerabilities. Tool vendors can also consider factors such as building security into their test infrastructure, monitoring for vulnerabilities that may impact their supply chain, and ensuring that there’s an incident response process if a vulnerability is discovered.
On the IP side, how do you prepare these building blocks to fit into a cybersecurity model, where you can trace any potential faults back to the source, which could be the IP? How do you mitigate and address threats—and prove that you’ve done so? During the IP development process, faults could be injected at various points, such as when the RTL is being transferred to another party or at the fab. A good starting point is to tap into tools that run formal validation for simulations, code analysis, and static analysis to detect vulnerabilities early on. The steps outlined in TARA can provide guidance. Flexibility will also be important, as how cybersecurity activities are tracked and addressed may differ based on the type of IP. Static analysis solutions that help teams address security and quality defects early in the software development lifecycle can help ensure that the software components of IP blocks won’t have issues. When it’s time to write the RTL for the blocks, use well-known encryption standards. Ensure that the IP will perform as intended via formal verification and hardware module checking tools.
Investing in Automotive Cybersecurity from the Top Down
Ultimately, creating a cyber-secure solution—whether it’s the automotive SoC or software or the EDA tools and IP—depends upon an investment in people and the organization and their supply chain. Cybersecurity planning should ideally start at the corporate level and influence all aspects of the organization. People who are tasked with implementing the security measures should have a deep understanding of existing and emerging security vulnerabilities, how to monitor and address them, and how to document and track all of the processes across the entire lifecycle of the solution at hand. A safer and more secure ride depends on all of this.