Defend Autonomous Vehicles from Threat Actors with Fuzz Testing
In the automotive industry today, software-defined vehicles (SDVs), electric vehicles (EVs), and connected and autonomous vehicles are becoming more popular. As the development of vehicles with improved safety features, better operation and enhanced user experience progresses, it is important to recognize that all of these advancements require more-advanced and complex software. And that raises the risk of vulnerabilities, which in turn increases the attack surface.
Connected and autonomous automobiles collect gigabytes of data daily about driver whereabouts, driving patterns, billing and car performance. Call logs, contacts, text messages, music choices, and even tweets and social network posts are often stored in a car’s data storage when people sync or connect to Bluetooth. All of this makes vehicles a rich target for cyberattacks.
Automotive organizations should follow best practices and establish cybersecurity policies and processes based on, for example, ISO/SAE 21434, including deploying appropriate application security testing tools to establish a secure software development life cycle.
Focusing on project-level activities, a threat analysis and risk assessment should be performed to identify critical risks in the product. While organizations should implement static application security testing (SAST) to detect issues in the source code, and software composition analysis (SCA) to detect vulnerable open source software components, today we want to look at how organizations can use fuzz testing to detect implementation issues and security vulnerabilities on high-risk wireless and wired interfaces.
Determining the Interface and Level of Fuzzing
There are two important topics to consider when doing fuzz testing. First, the tester needs to identify high-risk interfaces to target. Second, they have to determine the level of fuzzing to perform. Threat analysis and risk assessment (TARA) is one approach that can be used to identify the high-risk interfaces. Additionally, cybersecurity assurance levels (CALs) can be used to help determine the level of fuzzing required to achieve a certain level of cybersecurity assurance.
Let’s use a simplified example of a connected vehicle ecosystem, illustrated in Figure 1, to perform this analysis.
Figure 1: Overview of connected vehicle ecosystem
In this example, we have a connected vehicle with an in-vehicle network using controller area network (CAN) and Ethernet. The vehicle communicates with backend and cloud services using network protocols such as TLS, HTTP and MQTT. Moreover, the vehicle can communicate with a user device over Wi-Fi or Bluetooth.
By performing a TARA, it is possible to identify threats that use these interfaces and protocols as attack paths, and to determine their impact. Additionally, using an attack vector-based approach with the respective impact values shown in Figure 2, CALs for the different interfaces and protocols can be determined, as summarized in Figure 3.
Figure 2: Attack vector-based approach
Figure 3: High-risk interfaces and protocols identified with their respective CALs
Using the CALs, testers can define quantitative and qualitative metrics to help determine the level of fuzzing required to achieve a certain level of cybersecurity assurance. An example is presented in Figure 4.
Figure 4: Quantitative and qualitative metrics for fuzz testing for respective CALs
For example, for CAL 1, which is the lowest level of cybersecurity assurance, quantitative metrics testers can define eight hours of fuzzing or 1 million fuzz test cases. For qualitative metrics, testers can define that only in-band instrumentation is required. On the other hand, for CAL 4, which is the highest level of cybersecurity assurance, quantitative metrics testers can define 160 hours of fuzzing or 20 million fuzz test cases. For qualitative metrics, testers can define that both in-band and external instrumentation are required. (Please note that these are just examples and actual metrics would need to be defined appropriately based on the target system and its risks.)
Autonomous Vehicles and 5G
Let’s also consider the autonomous driving use case. There are numerous cameras and sensors on the vehicle that can be considered target interfaces, but we will focus on how 5G supports autonomous driving. For example, 5GAA is a consortium of auto manufacturers and telecom companies focused on developing end-to-end solutions for future mobility and transportation services, and as such it supports a number of use cases for vehicle-to-everything communication (V2X) and autonomous driving. Some use-case examples defined by 5GAA include high-definition map sharing for AVs, automated valet parking, sensor sharing for AVs and tele-operated driving. Thus, the 5G network and its infrastructure will play a major role in supporting the autonomous driving use cases defined by 5GAA.
Figure 5 gives a simplified overview of the 5G network ecosystem. On the left is the user equipment that in this case consists of connected and autonomous vehicles. These vehicles may connect to 5G base stations (gNodeB) where available, and as a fallback, connect to 4G base stations (eNodeB), as shown in the middle of Figure 5. Additionally, there is communication between 4G base stations and 5G base stations as well as communication between 5G base stations. The 5G base stations are also connected to a 5G core network, as shown on the right side of Figure 5. There are also various network communications within the 5G base stations, as well as within the 5G core network.
Figure 5: Overview of 5G network used for connected and autonomous vehicles
For the 5G network ecosystem, rather than focusing on the vehicles as targets, we want to highlight the importance of a secure and robust 5G network. Therefore, the overview in Figure 5 also shows how it is possible to perform fuzz testing of the various protocols used in the communication between 5G base stations, between 4G and 5G base stations, between 5G base stations and the 5G core network, and within the 5G core network and the 5G base stations.
Conclusion
When fuzz testing connected and autonomous vehicles, it is important to first recognize the associated risks with different interfaces and communication protocols for the target systems. A TARA can be performed to help identify high-risk interfaces. Furthermore, CALs can be used to help define the appropriate level of testing to achieve a certain level of cybersecurity assurance.
How Synopsys Can Help
Defensics by Synopsys is a comprehensive, versatile, automated black box fuzzer that enables organizations to efficiently and effectively discover and remediate security weaknesses in software. The Defensics library contains over 300 prebuilt fuzz-testing suites that are continuously maintained by our team of engineers to include more request for comments (RFCs), more specifications, and more protocols, file formats and interfaces. Defensics is designed to detect implementation issues and security vulnerabilities on high-risk wireless and wired interfaces.
