Risk Assessment for UN R155: A Closer Look at Vehicle Fuzzing

Have you ever wondered how vehicle manufacturers secure vehicles from cyber threats? The cybersecurity implementation process starts way before the vehicle hits the road and encounters any threats. During the manufacturing process, security experts hack the vehicle’s system to uncover any bugs and vulnerabilities that may be present in the embedded code. There are many different ways of doing that. One of them is called fuzzing. Fuzzing is a software risk assessment method that involves overflowing the system with random inputs to uncover bugs and vulnerabilities that are difficult to find through other testing methods. Fuzzing is done to test the vehicle’s software during the development process to make sure that the software is reliable and can be released to consumers.

Why do we need vehicle fuzzing?

In the automotive industry, original equipment manufacturers (OEMs) face regulatory obligations to address vehicle security risks. Compliance with UNECE WP.29 Regulation No. 155 (UN R155) requires vehicle manufacturers to implement an automotive cybersecurity management system (CSMS) to verify appropriate security measures in vehicle architecture. Here, the security measures signify comprehensive risk assessment, risk management, and mitigation procedures.

During the type approval process, manufacturers must verify the sufficiency of cybersecurity measures by demonstrating their risk identification and testing practices. Here is where fuzzing comes in.

Fuzzing is a technique for detecting software vulnerabilities by inputting intentionally invalid and unexpected data into the selected program with the intention to crash it. Doing this helps detect bugs and vulnerabilities in the software that may have not been found otherwise. Vehicle fuzzing can be viewed as an essential and comprehensive way to test if the system functions correctly, thereby verifying the sufficiency of security measures.

Functional testing and penetration testing, among others, can also be used to verify the sufficiency of cybersecurity measures for UN R155 approval. According to the regulation, OEMs not only have to disclose the results of these tests but also keep testing procedures up to date.

Who is responsible for fuzzing?

Even though vehicle manufacturers are responsible for the regulatory type approval, cybersecurity regulations are aimed at the entire automotive industry. So, fuzzing does not have to be done exclusively by the vehicle manufacturer. Tier 1 suppliers and software providers are often asked to provide fuzzing results for their software as well. Moreover, third-party white hat hackers conduct fuzzing along with penetration testing on vehicles and report any newly found vulnerabilities to the manufacturers to receive a bounty. This type of third-party fuzzing is becoming a common practice in the industry, allowing for a wider pool of cybersecurity experts to participate in strengthening vehicle cybersecurity.

Types of vehicle fuzzing

In fact, members of the AUTOCRYPT Red Team have won a major OEM’s bounty for discovering several vehicle vulnerabilities after independently conducting fuzz tests. This type of independent fuzz testing is called a black box test. In other words, a black box fuzz test defines a test where testers have no knowledge of the internal structure of the software, and perform tests by using only publicly available information. Led by award-winning ethical hacker Dr. Jonghyuk Song, AUTOCRYPT Red Team is known for its innovative approaches in black box fuzzing on CAN and IP protocols.

Other types of fuzz tests include gray box and white box fuzzing. During the gray box fuzz test hackers have no knowledge of the internal structure of the software, but some non-publicly available information is shared with them in advance. Gray box testing is one of the most commonly practiced fuzz tests in the industry. White box fuzzing is the most open type, where ethical hackers have access to the complete internal structure of the software.

The difference in the amount of information in each of the fuzzing types affects how the fuzzing test will be performed.

Performing vehicle fuzzing

The first step in the vehicle fuzzing process would be to choose the testing target device. Fuzzing is aimed at testing the software operations of a specific device in a vehicle and modern-day software-defined vehicles have no shortage of devices that need to be tested for potential bugs and vulnerabilities.

The next step is test case generation, which is when the intentional software overflow happens. The fuzzer generates random invalid inputs in the target device code to detect abnormalities. The intentional software “attack” happens during the test case delivery stage.

If the test is successful and the fuzzer detects an abnormality, the tool ceases operation. This happens because software overflow induces a system crash. Detected bugs are then reported and fuzzing has to be restarted to continue testing. The crash and restart process can make vehicle fuzzing a rather time-consuming endeavor. However, more advanced fuzzing solutions can automate operations to significantly reduce testing time.

For instance, AutoCrypt Security Fuzzer records the behaviors from the fuzzing target after a successful round of testing and automatically moves back to the second stage of test case generation. The results of the preceding tests are used to generate semi-random inputs using machine learning-based algorithms, greatly reducing fuzzing time while increasing the likelihood of bug detection. On top of that, if the Security Fuzzer causes a crash, it reproduces the same series of inputs based on the delivery history. Reproducing the test case allows for the replication of the test scenario, helping developers pinpoint the problems in the software. This algorithm-based smart fuzzing process allows for more precise and time-efficient testing.

Fuzzing is unique to its counterparts in that it can help uncover vulnerabilities that were previously unknown and help protect vehicle systems from zero-day attacks. Its special ability to detect unprecedented software issues makes it essential for vulnerability testing and risk assessment for UN R155. While complex and time-consuming, a fuzz test can be viewed as a health check-up that gives you an insight into how the systems are performing when there are no apparent symptoms present. When paired with other cybersecurity measures like penetration testing, a fuzz test can generate a holistic picture of in-vehicle systems operations and cybersecurity measure robustness.

To learn more about AUTOCRYPT’s vehicle cybersecurity testing measures and cybersecurity regulation compliance consulting services, contact global@autocrypt.io.

WP.29 Background Overview

As we near the end of 2020, the term “WP.29” has become an oft-discussed topic for those of us in the automotive industry, especially when it comes to compliance and the need for universal regulations for vehicles and security. Although we throw this term around quite a bit when it comes to discussion of the new regulations, WP.29 is not the name or title of the regulations, but the shorthand title of the working party – World Forum for Harmonization of Vehicle Regulations. This working party is part of the United Nations Economic Commission for Europe (UNECE). 

Though this working party has been established for over 50 years, the concept of transportation has evolved and continues to develop. With the rise of autonomous vehicles, a new working party within WP.29 was commissioned – the GRVA, Working Party on Automated/Autonomous and Connected Vehicles – which began its work on drafting up a new UN regulation for cyber security management systems for these vehicles. 

In June 2020, WP.29 released two new regulations for the industry, and while the regulations themselves are quite complex in terms of all the details, generally it divides up into the implementation of a Cybersecurity Management System (CSMS) and Software Update Management System (SUMS).

Of the two, the CSMS compliance regulation is what may take people off-guard as it’s quite a large, umbrella term. While “system” in terms of computing refers to a hardware or software system handled by a server, in this case a “system” is merely the people, products, and processes that one goes through in order to ensure that cybersecurity needs are being met.

Delving further, a CSMS should cover the entire lifecycle of a vehicle from development, production, and even post-production. Security is to be prioritized in all areas, not merely to monitor and detect abnormal activity, but to prevent it from even happening in the first place as well as risk identification and assessment.  

What does this mean for the automotive industry?

Firstly, manufacturers will be held to a much higher standard, as they will have to hold a valid Certificate of Compliance for proper implementation of the aforementioned CSMS. The documentation that they submit will have to provide information on the supply chain of all parts and software, risk assessment, test results, mitigations, and treatment/management history. The manufacturers will also have to demonstrate that vehicles are protected against the risks and describe future testing and security measures in comprehensive detail.

The regulations enter into force in January 2021. However, this does not mean that at the stroke of midnight all regulations will become mandated. This is simply the date when countries that have signed the 1958 UNECE agreement can begin to integrate the regulations into national legislation. For example, in the European Union, the regulations will be mandatory beginning in July 2022. This means automotive manufacturers will have to consider the region in which their automotive business operations take place. Though their headquarters may be in one country, if sales and software providers are located in another region, jurisdiction will take precedent.

Therefore, this regulation not only affects vehicle manufacturers but also suppliers, software-providers, and service providers who will also have to comply with the cybersecurity management system requirements to be able to work with manufacturers. After all, the term “system” is all-encompassing when it comes to securing the vehicles on the road.

For cybersecurity companies, this means being able to provide products and solutions that ensures compliance of manufacturers, suppliers, and providers with the WP.29 regulations. However, although CSMS seeks to be comprehensive in terms of security solutions, the number of companies that can provide comprehensive solutions are quite limited.

Here at AUTOCRYPT, we believe that security should not be a complex, or multi-stop issue. From V2X to in-vehicle systems, we ensure that all points of the vehicle environment are covered in terms of security, and are here to work with companies who are looking to meet the compliance requirements for the new WP.29 regulations.

For more information about AUTOCRYPT’s solutions, visit our official WP.29 page.

However, as keys become more connected and less physical, there is yet another element to consider: cybersecurity. It is crucial that we consider that the more connectivity we usher in, the more enticing it can be for attackers to look for a way to infiltrate. This is why it is also essential to incorporate security technology like Public Key Infrastructure (PKI) into the system to guarantee security even in its convenience.

While we will ultimately get to a point in vehicle evolution where a physical key does not necessarily need to be carried around, the reality is that though the idea of the traditional key will change, ultimately the concept will remain. A key’s purpose is to help its owner access different entry points, but to also keep them safe by locking out unwanted intruders. Therefore, no matter the form of the key, digital or physical, security will remain essential.

For more information about AUTOCRYPT and its digital key, learn more here.