Security strategies OEMs can use to protect vehicle entry points and in-vehicle networks.
As the industry continues to make advances in the autonomous vehicle as well as in vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communications, automotive OEMs must do everything possible to protect the connected automobile from potential cyberattacks. Unfortunately, attacks have become so prevalent, regulatory agencies are now defining cybersecurity requirements. New laws are being written to hold automotive OEMs and their supply chain accountable for security and safety breaches.
The good news is we have the means to combat these cyberattacks.
By following a multi-layered approach to connected vehicle safety and building a security architecture, OEMs have the means to protect vehicle entry points as well as in-vehicle networks. This article takes a look at several security strategies such as embedded firewalls, secure communications and authentication.
Perhaps one of the greatest challenges facing automotive OEMs is the increased use of software. In fact, there are more lines of code in the connected car than other more highly sophisticated machines of our time – and that includes a U.S. Air Force F-35 Joint Strike Fighter, Boeing 787 Dreamliner, or the U.S. Space Shuttle. Hardware today is more powerful and, as a result, millions of lines of code can be executed when performing a myriad of complex functions. This has created a multitude of systems inside the connected car.
The increased effectiveness and outright proliferation of automotive cyberattacks has created a new urgency in developing security solutions. An unprecedented level of commercial intervention is now underway around the globe, including new regulations by lawmakers to prevent cyberattacks.
The U.S. Security and Privacy in Your Car Act, also known as the “Spy Car Act of 2017” defines requirements for protecting against unauthorized data access and reporting. The bill directs the National Highway Traffic Safety Administration (NHSTA) to issue vehicle cybersecurity guidelines that require motor vehicles manufactured for sale in the United States to build in protection against unauthorized access to electronic controls and driving data.
Similarly, also in 2017, the U.S. House of Representatives passed H.R. 3388, called “The SELF DRIVE Act” to ensure the safe and innovative development, testing, and deployment of the self-driving automobile. This bill strikes a balance between consumer safety while encouraging innovation.
NHTSA’s Automotive Cybersecurity Research Program takes a threat analysis approach to cybersecurity, breaking down threats into six different categories.
The six threat categories include:
Spoofing – a situation in which a person, program or device conceals itself as something it is not by manipulating data to gain an illegitimate advantage.
Tampering – intentional alteration of data in a way that would make it harmful to the consumer. In the context of connected cars, it could refer to modifications to configuration data, software or hardware used in vehicle control systems.
Non-repudiation – describes a situation where a statement’s author cannot successfully dispute its authorship or validity. In other words, the author or the statement cannot later claim to have not made the statement. For example, when the authenticity of a signature is being challenged, the authenticity is being “repudiated.”
Info Disclosure – can refer to many types of sabotage related to data leakage.
Denial of Service (DoS) – refers to a cyberattack in which a machine is flooded with excessive requests from an attacker to an extent that it becomes unavailable for its legitimate users. DoS is typically accomplished by flooding the targeted resource with superfluous requests in an attempt to overload its systems and prevent legitimate requests from being fulfilled.
Elevation of Privilege – a situation in which an attacker can abuse a machine and performs unauthorized activities by gaining illegitimate access to resources. Hackers who are successful with elevation of privilege attacks have greater access to systems resources and data, allowing more damaging attacks.
When discussing a multi-layered security approach, many factors must be considered. An embedded firewall, or intrusion detection to protect the vehicle from accepting unauthorized traffic, data, or signals sent by a malicious IP address must be part of the mix. Of course, authentication is a key component as well. Utilizing a secure operating system (OS), multicore framework and hypervisor support should also be considered.
Embedded firewalls
Building a firewall into a vehicle is a highly specialized process. Understand that this is not a networking firewall running in a router or gateway or on an enterprise device. This is a highly specialized solution tailored exclusively to the automotive environment.
Fig. 1: Securing ECUs from cyberattack by employing an embedded firewall and certificate-based authentication. Source: Sectigo.
To begin building the firewall, a Software Development Kit (SDK) is needed. The SDK can be integrated directly into the communications stack, whether TCP/IP, CAN, or any other connected solution. The firewall has to meet specialized requirements. It needs to have built-in flexibility to run on any ECU. It should work with a real-time operating system (RTOS) or even in the AUTOSAR environment. To be successful, the embedded firewall must be a highly configurable, modular solution that works across a range of vehicle ECUs in use today (figure 1).
When building the firewall, it’s recommended to first step back and consider the requirements that must be satisfied. Many cyberattacks begin by sending packets to the connected car, probing for weaknesses. If the firewall can detect this activity early and ensure certain packets are not allowed to be received or forwarded, a potential attack will be thwarted before it even begins. It’s important to control what ports and protocols are used to receive messages for the vehicle. If one can control the IP addresses sending data to the vehicle it is possible to protect the vehicle and report suspicious activity.
It’s also important that the firewall support different types of filtering capabilities. The ideal firewall should support CAN bus filtering and rules-based filtering. Blocking messages by ports, protocol, IP addresses, etc. is a sure way to stop an attack from ever happening. The firewall must be able to do threshold-based filtering, static or rules-based filtering and stateful packet inspection. These are just a few of modules that need to be built into the firewall. The logging and reporting of attacks enables intrusion detection, which is knowing when something unusual is happening. Reporting this back to some type of a vehicle operations center, allows security operations teams to take action based upon that information.
Secure communications
Just as there are multiple use cases for the embedded firewall, so too are there numerous use cases for secure communications. Scenarios include communication between the car and external systems, vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communications. V2V communication is more common today and a critical form of communication that must be protected. And again, when discussing secure communications within the car, all of the ECUs must to be protected.
Secure communications is about ensuring that each time a communication session begins, the origin of that communication is known. To ensure secure communications, encryption is recommended. Encrypted communication uses IP protocols such as TLS, DTLS and SSH. If running over a CAN bus, CANcrypt can be used. Ensuring that all data is encrypted using strong cryptography is critical to warding off cyberattacks.
Authentication
Authentication is used when establishing a communication session to verify that who you are communicating with is actually who they say they are, i.e., is the other device or process really who it claims to be? For machine-to-machine communication, certificate-based authentication is frequently used. When discussing authentication, a critical aspect is the role of public key infrastructure (PKI) and how to manage and issue digital certificates. Every ECU has to be identifiable and PKI-based certificates are ideal as they provide strong authentication and can be utilized for machine-to-machine communication. Another aspect of PKI security is code signing which enables secure boot and secure updates for ECUs.
PKI certificates play a central role. V2V and V2I communications have been mentioned as critical areas to address in the connected car. With V2I communications, high-speed automated certificate issuance is a must. And having a way to host and manage the entire process in a secure fashion is an essential part of the process. Where is the certificate authority hosted? How is certificate issuance performed? Is it automated? Is it secure? How are private keys protected? These are all extremely important questions that must be taken into consideration.
When looking at a single automotive OEM and their cybersecurity solution, it’s common for that manufacturer to have their own internal strategy for the connected car. They are certainly allowed to have their own proprietary safety ecosystem. But when considering V2I or V2V communications, where vehicles from multiple OEMs travel the same road, vehicle manufacturers must construct a shared ecosystem with the same requirements for security, management capabilities and other safety-related capabilities to ensure interoperability among all vehicles on the road.
Building security into the connected car requires a multi-faceted approach. It cannot be done as an afterthought. To protect these vehicles, multiple layers of security are required, and all attack surfaces must be taken into consideration.
As the connected car evolves, it is recommended that cybersecurity configuration be performed remotely with an enterprise security management system. This integration provides centralized management of security policies, situational awareness and device data monitoring, event management and log file analysis for data analytics.
Finally, and perhaps most important, the automotive community must prove itself trustworthy if people are to trust connected cars. Along these lines, security should not be made into a competitive differentiating advantage. It needs to be a shared common resource so together OEMs can move forward with all the great potential the connected car promises to deliver.
To learn more, download our whitepaper Strategies to Secure Connected Cars with Firewalls.
 |
 |
 |
 |
 |
 |
Leave a Reply