ESCAR was an interesting event. There were about 150 in attendance from various parts of the auto cybersecurity community including OEMs, tier 1 vendors, and defense products. There were speakers on a variety of good topics, the full lineup is available at https://www.escar.info/escar-usa/program.html. Being an “outsider” to the auto security community I really enjoyed the opportunity to meet people and have some interesting discussions.
The opening keynote by Alex Halderman of U of Michigan was highly interesting regarding the all-too-common re-use of keys or predictable keys that are prevalent in embedded systems due to a common starting point. Relevant information that will hopefully sink in and be of use in the future as more devices are incorporating encryption, but as of now those devices are rare (in both the auto industry and ICS).
“Methods for Penetration Testing of Automotive Embedded Systems” presented by Argus was a good primer in security analysis for these types of systems. A few talks discussed handling the increasing connectivity in vehicles moving forward and how to best separate the concerns of interactive vehicle features affecting safety and operational control systems. I feel like this is the most important area to be considered at the moment for the industry.
Vendors at the conference seem to be focusing on IDS/IPS for vehicle systems. The idea being that installing extra equipment to monitor the CANBus to identify messages that occur when they should not and to prevent those messages from reaching the ECU. This requires keeping a knowledgeable running state of the vehicle to determine if the “steering wheel left park assist” action is correct at a given time. Some vendors seem to do this via software on existing vehicles and others via entirely separate sensor systems to be installed aftermarket. I think this is a *VERY* difficult problem to solve (having worked in the situational awareness space previously) and is a common issue that people attempt to band-aid over in cybersecurity.
The trouble with CANBus messages, or ICS protocols, is that it is extremely difficult to quantify and ascribe intent to a given message. If a message comes from the HMI to the PLC that says “open valve C” how do you determine if that is legitimate or if it’s an attacker? Unfortunately, there is no “evil bit” that gets set in attacker packet headers. This kind of band-aid approach is very unlikely to work in the automotive industry, in my opinion.
Interesting new technologies that I would love a chance to get hands-on experience with are the vehicle interconnectivity and collision avoidance systems. The idea being that a vehicle will beacon out it’s location and statistics for other vehicles to use in order to avoid collisions and warn drivers. Cool technology to watch but I’m suspect at the ease of abuse. “Yes I am law enforcement please pull to the side so I can move unobstructed, thank you.”
One thing that surprised me was the mixed response and emotions I got to the Charlie Miller/Chris Valasek research. There were a great many attendees who had nothing but disdain for the pair and the way that they conducted their research.
For instance, Beau Woods from I Am The Calvary gave a talk in which he showed a picture of the torn-up dashboard of the Miller/Valasek vehicle. His point was something akin to “if this is what it takes to hack a car, I’m not too worried. I just won’t get in the car…” to which the room gave a loud agreement of laughter. This is disingenous, however, as the dashboard was destroyed because Miller/Valasek had to do the laborous work of reverse engineering the CAN message IDs because the OEMs keep those as a guarded secret (even though it’s all completely cleartext on CAN). To ACTUALLY CONDUCT ATTACKS, nothing but 2 wires into the OBDII port are needed.
Personally, this worries me. We’ve made great progress in the last decade to create real relationships between security researchers and the vendors and asset owners in the ICS space. The auto-industry, it seems, is far behind when it comes to accepting that all software has bugs and security researchers exist to help, not to harm. The researchers looking to harm are not the ones they are going to be hearing anything about. The head-in-the-sand attitude and active denial only serve to hurt cybersecurity in vehicles. By the way: look for the Miller/Valasek presentation at Blackhat this year, it directly combats the idea that vehicle attacks require tearing apart dashboards to succeed.
In general, I see a LOT of parallels between auto and ICS in terms of security, development histories, paradigms, and (lack of) software development lifecycles and security testing. Where the two diverge is perhaps more interesting. Auto being so consumer-driven seems to change what consideration is given to security. Unsurprisingly, business trumps security and privacy. In auto it is cited as the primary reason that companies cannot implement proper cybersecurity or to get their software tested by third parties.
Personally, I dislike this line of thought because I think it comes from a misunderstanding of security testing as an expense without tangible return on investment. The idea being investing in security only matters if you would have otherwise gotten hacked. The less obvious benefits are often overlooked. Security testing and software development strategies like the SDL and unit testing help to create a system that is resistant to attack, easily adjusted to new technologies, and more healthy overall — saving many man-hours of development time.
One of the speakers presented a slide containing line counts of software and estimated the auto industry as having an order of magnitude more lines of code than Windows XP. Such a massive code base demands strong organization, unit testing, and third party audits. All of that said, any developer who has ever worked will be the first to say that the road to spagetti code is littered with abandoned guidelines.
I believe that if vendors treated vehicle security as a trusted/untrusted network boundary it would take care of a large majority of problems. Does the infotainment unit need fuel economy data? Send it out one-way read-only that gets published. Does the infotainment need to write on the bus to affect fuel economy? Insert an intermediary that only allows writing signals of a specific ID. Basic distrust of any user-controlled input would go a LONG way in making vehicles more robust and secure.
photo courtesy creativecommons license: https://www.flickr.com/photos/jar0d/6066734168