- The Model Context Protocol: Simplifying Building AI apps with Anthropic Claude Desktop and Docker | Docker
- This robot vacuum and mop performs as well as some flagship models - but at half the price
- Finally, a ThinkPad model that checks all the boxes for me as a working professional
- Why I recommend this Android phone for kids over a cheap Samsung or Motorola model
- My favorite USB-C accessory of all time scores a magnetic upgrade
It Isn’t Your Daddy’s Oldsmobile Anymore
By Dan Shoemaker, Professor and Distinguished Visitor IEEE
There is no situation where you are more vulnerable to a cyber-attack than when you are in your automobile. Are you surprised? If so, you still view your car as a transportation device. But today’s cars aren’t like your old man’s. They’re built around a complex array of microcontrollers and integrated circuits that enable all the wonders of the modern driving experience. And due to that thirst for digital technology, the automobile business has become one of the world’s primary consumers of microchips.
Your vehicle is a self-contained local area network. So, logically, every access point requires the same network security authentication and authorization processes. Likewise, your car interacts within a diverse electronic cyber-ecosystem. That makes it a prime target for exploitation. Over-the-air software updates of vehicle systems, GPS satellite connectivity, hands-free cell phones, onboard diagnostics, and even your remote keyless entry system are all legitimate points of entry. Yet, there are no guards posted at those gates.
You are probably familiar with the general shape of access control on a network because you use passwords to authenticate your systems. That is not the case with an automobile’s external interfaces. For instance, the interface between your cell phone and the functionality that enables hands-free calling or your onboard entertainment package are not firewalled. And so, exploits like RFID relay attacks, cell tower spoofing, hacks of OBD-II ports, or Software Defined Radio attacks pose a credible risk.
Controlling access to your vehicle’s internal systems is vital to driving safety because your car depends on tiny electronic control units (ECUs). These ECUs are nothing more than embedded logic installed to perform a single operation, like braking. A controller area network bus (CAN-bus) ties the car’s ECUs into a complex system. That system enables every aspect of your automobile’s digital functionality, from entertainment to throttle control. It should be clear that explicitly designed and implemented countermeasures are necessary to protect these digital components from unauthorized access. Otherwise, a malicious third party could take remote control of your car. That would be a dangerous condition in a parked vehicle. It is a subject of extreme concern if the car is doing seventy miles an hour down a local freeway.
Accordingly, adopting a standard, systematic approach to monitoring and controlling the interactions between the vehicle and its digital ecosystem is vital. There have been whack-a-mole attempts at addressing the problem, such as immobilizers and discussions of purpose-built PKI for authentication. But the fact is that the industry has always concentrated more on spreading the net to enable greater access rather than devising ways to control it. That’s because features sell cars. So dangerous functionality, like onboard internet, has always gotten precedence over implementing a proven set of best practices for stopping cyberattacks.
But that is going to change. In January of 2021, the International Standards Organization (ISO) promulgated a comprehensive set of standard best practices for Road Vehicle Cybersecurity Engineering (ISO/SAE 21434). These practices establish a formal and systematic cyber security management system (CSMS). Specifically, ISO/SAE 21434 describes a systematic way to protect the vehicle from design, development, production, operation, maintenance, and decommissioning risks. That advice encompasses all internal connections, embedded systems, and external interfaces.
Realistically, the prospect of an OEM adopting an organization-wide CSMS wouldn’t be worth discussing. Because in a world of profit, the requirements of ISO 21434 are far too costly. However, compliance with 21434 is tied to a United Nations Economic Commission for Europe (UNECE) regulation called UNECE R-155, “Uniform Provisions Concerning the Approval of Vehicles with Regarding Cyber Security and Cyber Security Management Systems.” Cyber security management systems involve practical control behaviors that ensure that all known cyber threats are addressed. R-155 mandates that every OEM must provide audited proof that they have implemented a functioning Cyber Security Management System (CSMS).
UNECE R-155 comes into effect in July of 2024. After that date, the countries that make up the UNECE will require certification of a correctly configured CSMS to grant vehicle type approvals. Those approvals are critical because the OEM would not be able to sell their cars if they didn’t have them. Of course, this deadline could change as the OEMs jockey with the UNECE, and It should also be noted that this mandate is for Europe only. Still, this initiative provides a commonly accepted standard definition of what each OEM needs to do to safeguard their products in this digital age.
Full and Systematic Vehicle Cybersecurity
So, what does systematic automotive cybersecurity look like? Well – first of all, it’s a process. In effect, the activities within this process satisfy the stated intentions of the standard. The standard imposes five global conditions. First, there’s the requirement for overall governance, which is stipulated in Clause Five. Governance is a general term that describes the coordination of the entire effort. In the case of 21434, we are talking about creating a comprehensive framework of cybersecurity policies that both align with the organization’s business purposes and define the organization’s solution. These policies regulate the internal and external actions undertaken in the assurance process.
Procedures are the specific means to implement a governance process. These must be tailored to each policy. These procedures represent the organization’s management solution. The requirements are itemized in Clause Six of the standard in the form of specific outcomes which will satisfy one of the particular criteria of the process.
Finally, there are the everyday operations that must be performed in an end-to-end fashion in the lifecycle. Requirements for this are specified in Clauses Nine through Fourteen of 21434. They are explicit actions that turn a defined procedure into specific activity in the local setting. These practices may differ as settings and products vary. But each activity will implement some integral aspect of the process. The outcomes of these actions are audited and documented to demonstrate compliance.
Two significant outside factors are also addressed. These are specified by the final three Clauses of the standard. First, the risk management process identifies threats, analyzes risks, develops mitigations where necessary, and communicates the findings across the organization. This is specified in Clauses Eight and Fifteen of the Standard. Finally, Clause Seven species best practices to address supply chain risk issues and is essentially a new feature in any standard for cybersecurity.
But wait… There’s More?
Still, UNECE R-155 isn’t the only regulation the OEMs will need to comply with. The other one is UNECE Regulation No. R-156. This regulation accompanies R-155, and it will be enforced in the same fashion. UNECE 156 requires the presence of a comprehensive software update management system (SUMS). For what ought to be obvious reasons, over-the-air (OTA) updates are a particular target for R-156 assurance. The SUMS manages in-vehicle software updates under the R-156 criteria. That requirement applies to any vehicle that allows software updates, which is essentially every car today.
In essence, R-156 stipulates the creation of a documented baseline of software configuration items (SWCI) for every applicable initial and updated software version utilized by a vehicle type. The items in that baseline must be uniquely identified and labeled.
What Does This All Mean?
It should be evident that any efforts to improve the cybersecurity of automobiles will introduce time-consuming and expensive new wrinkles. So, the obvious question is, what’s the point of doing it? If this were 1957, or even 1997, there wouldn’t be much reason for wasting your valuable time. However, programmed logic controllers are everywhere in your vehicle, from software-defined radio (SDR) to the CANbus and its network of vehicle ECUs. And that isn’t even to mention the prospective world of self-driving vehicles. Your automobile is a complex digital ecosystem where failure in any onboard device, for instance, an unauthorized OBD or RFICD access, could lead to disaster. Hence, there has to be a well-defined and highly organized effort to counter potential cyberattacks in this brave new world of digital technology.
About the Author
Dan can be reached online at dan.shoemaker@att.net, or Dan Shoemaker| IEEE Computer Society