As technology revolutionizes the way OEMs build cars, this software-powered shift has also introduced new risks and challenges. As cars become more connected, they are exposed to more cyber security threats. Software vulnerabilities and open-source code can be exploited by hackers to compromise safety-critical systems, access personal data, or even start a car from a remote location. In addition, due to the increasing complexity of the vehicle software ecosystem, integration and maintaining code quality have also become more difficult.
Let’s examine some practical steps that OEMs and Tier 1 suppliers can take to reduce security risks, achieve regulatory compliance, and streamline the automotive software development cycle.
Meeting regulatory expectations
Over the last few years, we have seen dramatic changes in standardization and regulation of cyber security practices in automotive. Some notable ones are ISO 21434, ASPICE cybersecurity extension and UNR155, which have become a de-facto way of ensuring a cyber security-minded development process and product. While UNR155 is mostly applicable in the EU, many other countries follow it or have similar guidelines or regulations in place. Moreover, due to the global nature of the automotive market, EU regulation has a tremendous impact on non-EU manufacturers as well.
With the introduction of such expectations, the industry is slowly shaping itself to comply and meet these new requirements. This is a slow process, which has an impact on many different departments of all automotive manufacturers and their suppliers. It also has an impact on auditors and assessors who need to learn how to inspect that the new regulatory expectations are met.
These changes introduce new steps into the development cycle, and throughout the rest of the vehicle lifecycle (production, post-production, etc.). New efforts mean additional work and increased costs for manufacturers.
So how are OEMs and Tier 1s coping with these new efforts, which require the investment of more time and materials into an already extremely tight project framework?
Shift left and automation
The answer is doing what all industries have always done. If you consider how automotive manufacturers and suppliers deal with quality aspects, you’ll see there is an ongoing effort to perform verification and validation as early in the process as possible (“shift left”) for each phase. By doing so, manufacturers reduce the impact of a potential mistake and the time it takes to fix it.
The other key element is automation. This is especially true for situations that require large scale. By automating the processes of requirement tracing, deployment, performance analysis, functional testing and others, each small change can be tested and undesired impacts on the project and product can be immediately reported and addressed.
As the industry implements tools and processes to meet the new cyber security regulatory requirements, it’s becoming clear that the same principles still hold. Slowly, we are seeing an emerging landscape of tools and methods for automating and “shifting left” the necessary cyber security phases that help reduce the effort and time required to meet compliance.
Working smarter, not harder (in practice!)
Part of what we do at Argus is supporting automotive companies with their processes related to cyber security and regulatory compliance. Through these interactions, we’ve identified some useful actions an OEM/supplier can take to become more efficient in implementing cyber security. For example, using internal expertise more effectively and relying less on outsourcing certain activities.
In this context, two important activities mandated by these new regulations that can help OEMs and Tier 1 suppliers detect and resolve security issues early in the development process are penetration testing (fuzz testing) and vulnerability management.
Automated fuzz testing
Fuzz testing is a software testing technique that involves feeding invalid, unexpected, or random data inputs to a program in order to uncover vulnerabilities, bugs, or unexpected behaviors. In the context of the automotive industry, fuzzing is used to assess the security and robustness of automotive software systems. For fuzzing to be effective, it must take into account automotive protocols, use cases and automated testing procedures. If implemented correctly, such tests will reveal flaws and vulnerabilities with minimal effort in the early project stages and beyond.
Most manufacturers today rely heavily on simulation systems to check the end product for functionality and safety. While there are many different implementations and vendors of such simulation and testing products, some are beginning to offer “cyber security” suites or tools as part of their solution. By deploying an automated Fuzzing test into your HIL/SIL setup, you can automatically increase the level of security in the system. Some products even provide automated reports referencing regulatory requirements tested by specific tests, so these can be easily used as evidence to achieve compliance.
Not just fuzzing
There are many other tools which can be used by the development or testing team to more easily detect security issues that are not necessarily part of a heavy-duty Hardware-in-the-Loop/Software-in-the-Loop) (HIL/SIL) system. Some tools are open source and completely free. One such example is “python-udsoncan”. This utility can be used by an engineer to interact with a UDS server in different ways and detect security flaws. Taking this one step further, an engineer with sufficient security expertise could create automated tests to ensure the correctness of the UDS functionality from a security perspective, and have these tests executed with every new software version.
Vulnerability Ma nagement
As vehicles become more and more software based, with more software libraries from different sources being integrated together, the risk of one of these pieces of code containing a vulnerability increases. What happens if two years after a vehicle hits the road, a vulnerability is published which affects one of the software libraries used in the vehicle? How do you know which vehicles are affected? How do you assess the potential impact and how do you respond?
This issue has been addressed by regulations and standards such as UNR 155 and ISO 21434 which directly require that a Software Bill Of Materials (SBOM) be kept and tracked throughout the vehicle lifetime. The SBOM should be continuously monitored, so newly published vulnerabilities are quickly identified and addressed. This activity must be done at an early stage of a project. By scanning your software early, automatically and with every new version, any known vulnerabilities that were introduced into the product are detected immediately, and can be addressed by the responsible engineer or supplier.
Performing this kind of scan only at a late release stage can create delays and/or a situation where risky compromises must be taken. A proper Vulnerability Management solution – one that automatically generates the SBOM from each new software release and provides a report of known vulnerabilities that affect it – dramatically reduces manual efforts involved in identifying and treating these issues.
Bottom Line
In today’s complex software-driven ecosystem, vehicle manufacturers have come to realize the importance of integrating security measures early in the development process. This “shift left” security approach enables automotive software developers to improve the overall quality and security of their products, while at the same time accelerating time-to-market and reducing development costs.
Incorporating advanced cyber security tools and processes, such as fuzz testing and vulnerability management, as an integral part of the software development process can help OEMs and Tier 1s to streamline product development and meet their compliance objectives.
About the Author
Oron Lavi is the Chief Technology Officer and Co-Founder of Argus Cyber Security, a pioneering company established in 2014. With a wealth of experience in the tech industry, Oron previously served as a senior software engineer at Salesforce.com and as the CTO at CBVW. He holds a Bachelor of Science degree in Computer Engineering, graduating magna cum laude from Tel Aviv University.
Oron can be reached online at. https://www.linkedin.com/in/oron-lavi-10777b3/, and at our company website https://argus-sec.com/
