Software Security Policy is vital to Automation

The modern vehicle comes equipped with a variety of software systems. Especially features that connect it to the outside world, such as online updates, fleet management and communication between vehicles, offer attack surface. The security of automotive software is crucial, not only because bug-induced call-backs are costly, but also because the well-being of passengers depends on it.

To keep up with the increasing complexity in modern vehicles, the ISO/SAE 21434 standard is going to set forth a new framework for secure software development in the automotive sector. In this article, we will give you an overview of everything you need to know to comply with the new standard

SO/SAE 21434 “Road Vehicles – Cybersecurity Engineering” has been developed by the International Standard of Organization (ISO) and the Society of Automotive Engineers (SAE) for the past two years. It will soon be introduced to provide a holistic guideline for secure automotive software development.

The ISO standard covers all software devices within the vehicle, as well as connectivity to external systems. Since existing norms and standards were developed in a time when vehicles did not depend on software too heavily, they do not place too much value on its security.

 

SO 21434 will be implemented with several goals in mind. These are the most important ones:

 

·       Creating a standardized terminology for software security within the automotive landscape;

·       Defining minimal requirements for software security engineering;

·       Improving collaboration within the automotive value chain;

·       Becoming the new security benchmark;

·       Incorporating security early on in the development lifecycle;

·       Establishing a security culture.

 

The main challenge in reaching these goals is that all processes, management systems, and vehicle requirements, concern the entire lifecycle of the vehicles. Implementing the new standard will call for a high degree of communication across the entire supply chain.

 

In software development, there is a distinction between “safety” and “security”. Safe software describes a system that is generally free of defects or crashes – or simply put “does not fail”. Secure software means that a system is immune to external interference or ungranted access.

 

In automotive systems such as for example lane-assist or automatic brake systems, safety obviously plays a crucial role, as a defect in these programs can be fatal. Due to the increase in connectivity platforms in modern vehicles, however, the importance of security is increasing rapidly.

 

The famous Jeep case has shown, that exactly these platforms can serve as entry points for hackers to gain control over the entire vehicle. It goes without saying that this needs to be prevented at all costs. This is where ISO 21434 comes into play.

SO 21434 is not the first standard, that recommends fuzzing. The list above shows some of the recently published standards that recommend feedback-based fuzzing and DevSecOps to improve software security. The reason for this popularity of fuzz testing among vehicle manufacturers and OEMs is that it perfectly fits their demands: 

As mentioned above, there is no room for errors in automotive software. Feedback-based fuzzing allows for accurate bug detection without the disadvantage of time-consuming false positives. It is a highly automated “shift-left” approach, that paves the way for a decentralized testing culture.

 

Due to its wide field of application, feedback-based fuzzing can be implemented at different steps of the software development lifecycle, making it the most attractive solution for vehicle manufacturers and OEMs.

 

SO 21434 offers a great opportunity for vehicle manufacturers and OEMs to keep up with the latest developments in automotive software security. Sustainable security testing methods such as feedback-based fuzzing are key elements for ISO 21434 compliance. If you are interested in the toolchain required to effectively integrate feedback fuzzing into automotive development processes, you can book a demo with one of our colleagues.

 

Make Cyber Security a priority

 

The first step towards secure software is cultural acceptance. For a healthy security culture, everyone involved in software development should be educated and made aware of basic security protocols. Similar as in DevSecOps, this means that security controls should be employed directly within the various delivery teams, throughout all stages of the software development lifecycle.

 

Choose the Right Language

 

To meet the requirements of ISO 21434 security aspects should be kept in mind when choosing a programming language. A secure language is characterized by • unambiguous syntax • two semantic definitions • secure design and coding techniques.

 

A language subset is a carved-out part of a programming language that can help mitigate any activity that poses a security risk. Using a language subset can improve the security of an infrastructure to make it more compliant with ISO 21434 requirements. Since C/C++ is very common in the automotive industry, creating a subset for it is highly recommended. ISO 21434 explicitly recommends compliance with the coding standard MISRA C:2012 revision 1 and 3 the CERT C guidelines for C/C++. Both are centred around language subsets.

 

Strong typing means that developers will have to abide by strict typing rules. This can cause exceptions and errors during compiling. Still, it prevents unpredictable results and ensures good code quality. Strong typing is recommended in both the MISRA C:2012 revision 1 and the CERT C guidelines.

 

Defensive implementation means preparing a software for unpredictable events. To foresee this, it is crucial to have an understanding of possibly tainted data and the order of evaluation of arithmetic functions. Basically, this means that the code should be easily understandable. To achieve this, you should implement recognized coding guidelines. For C/C++, these guidelines can be found in MISRA C: 2012 revision 1 and CERT C.

 

Achieving ISO 21434 compliance with external pentests would require a time-consuming increase of pentesting resources and make OEMs and suppliers even more reliant on external testing bodies. ISO 21434 recommends fuzz testing as a method to cope with its increased testing requirements. Instead of outsourcing more pentests, modern fuzz testing can be used to partially automate them. With the addition of automated fuzz testing, dev teams can run continuous security tests. Finding and fixing bugs throughout CI/CD speeds up the development process, as it reduces the need for a large-scale bug-rampdown later on.