A few months ago I introduced the concept of “ACLV” and its dependence on the transportation centric ontology (TCO). In this post, I discuss the risk associated with the potential hacking of the TCO. Okay, arguably “potential” is a bit too noncommittal. Strike that and replace it with “inevitable.”

Sometimes it seems that (some) law makers are scrambling to demonstrate their relevancy by talking about cyber security. If you don’t talk about it, you don’t exist. I do not think of Sen. Edward Markey (D-Mass.) as one of those, however. His recently published report decrying the anemic efforts by car makers to defend sensitive data stored in vehicles from hackers is spot on; at least in terms of the topic, if not so much on grading their efforts. Among the Senator’s interesting initiatives in this regard is pushing the federal government into mandating that car buyers have access to a vehicle’s cybersecurity profile/rating, just like they would to its crash rating. This is intuitively comfortable to digest. After all, the more connected a vehicle is to the internet and/or to a TCO, (what I referred to as ACLVs) the greater likelihood that a hack could have paralyzing, if not much more devastating effects. Additionally, making it easier to efficiently evaluate the quality of a vehicle empowers consumers, and that’s a good thing.

We don’t need to look far to find practical solutions for what is needed to effectively protect our TCO. On the vehicle side of the equation, we can conceptualize that a vehicle’s cybersecurity system should protect its connectivity to the TCO just as it does other sensitive driver data. On the database side of things, we can similarly conceptualize that a standards-driven cybersecurity regime will also yield the necessary protective framework. We can then take the next step and take a closer look at relatively recent, relevant efforts and see what can be gleaned from them.

Enter the National Highway Traffic Safety Administration’s (NHTSA) work on vehicle cybersecurity. Among other things, the NHTSA has recently proposed measuring the viability of a vehicle’s cybersecurity system by evaluating the presence of: (i) security-compromising gaps, (ii) response capabilities, (iii) the impact of “unintended consequences” on the vehicle’s performance due to the fact it has a cyber security system and (iv) the presence of disciplined certification to standardize and promote the security of “critical vehicle subsytems.” Items (i), (ii) and (iii) are of most interest here and should also easily lend themselves (with relevant adjustments) to the construct and measurement of the effectiveness of a TCO-centric cybersecurity system.

Protecting the TCO ecosystem (vehicle and database) with a strong cybersecurity system is in everyone’s interest. As I also recently discussed here, some of the obvious benefits of building such a system is that it will help ensure we have a thriving ACLV market.

***Postscript***

November 3, 2021: The Cybersecurity & Infrastructure Security Agency (CISA) recently released the “Autonomous Ground Vehicle Security Guide.” It is a digest of best practices and does a nice job of laying out key autonomous vehicle (AV) security risks and challenges. Although it does not mention a transportation centric ontology (TCO), it is possible to see and appreciate that the concept has a foundation, is gaining traction, namely in the call to “ensure physical access points to networks and systems are secure” and the “adopt and implement system security guidance, best practices, and design principles” headings. Since the TCO concept comprises a critical infrastructure asset of the AV ecosystem, I expect CISA will provide additional guidance along with NIST, NHTSA and other federal agencies.

October 1, 2017: Data integrity is the most important feature of the transportation centric ontology (TCO). I have written and spoken about the role of blockchain (most recently at Stanford Law School June 12, 2017) in securing the TCO and how the law needs to coalesce around such key technologies to enhance vehicle cybersecurity. Enter quantum entanglement technology. It holds significant promise in taking the data integrity principle not only to a new level, but effectively creating a new cybersecurity app paradigm, rendering blockchain apps obsolete.  This is because in quantum entanglement a data hack is, simply put, impossible. In contrast, in a blockchain app, a hack is merely evident; i.e., the app will merely signal that the data was compromised, but that’s just not good enough. To be effective the TCO data cannot be compromised at all. Once a quantum entanglement app is viable, it could very well become, and should be, the go-to standard for ensuring the TCO is safe. It will also concomitantly enhance NHTSA and other autonomous vehicle cybersecurity legal initiatives and help foster a thriving autonomous vehicle market.

August 9, 2017: The UK government recently issued guidance for autonomous vehicle manufacturers that closely follows the NHTSA’s guidance on the topic. The UK’s data storage and transmission principles call for a system design that is “…resilient to attacks and responds appropriately when its [defenses] or sensors fail.” As I have written and spoken on this topic before (most recently at the 2017 Stanford Law School’s E-Commerce Best Practices Conference) this type of task is ideally suited for blockchain apps.

April 13, 2017: Blockchain acceptance as a mainstream, best-in-class authentication practice received an important endorsement with Arizona’s H.B. 2417. The law (in 2417) amplifies the trust quality in the authentication technology, referring to blockchain entries as an “uncensored truth.” This acceptance is particularly important in cultivating adoption in cyber environments that depend on absolute trust in data integrity (e.g., FIPS 199) such as is the case in autonomous vehicles and computational law applications.

June 8, 2016: Question marks hang in the air as the SWIFT system increasingly looks like a major weak link facilitating expensive bank data breaches. (Think back to the Bank of Bangladesh.) So as SWIFT continues to draw unflattering attention and inflates doubt about its efficacy and relevancy, the incident highlights the importance of implementing alternative authentication systems. In a number of respects, the blockchain represents the right modern remedy, not only to SWIFT, but also to securing the TCO and other similar repositories. And when you consider the prospect of neural networks feeding data to the TCO, the criticality of security, and more granularly, data integrity and availability, becomes much more magnified.

August 25, 2015: On securing the TCO: I propose implementing a mandatory (users cannot bypass) two-factor authentication in every ACLV.  Vehicle’s computer system only accepts changes from (i) trusted sources that have (ii) authenticated, each time the car starts, or some other random pattern. The authentication can be controlled/managed through blockchain technology.