Just before we start, there is one fact that should be emphasized, which is not emphasized in the articles: the hack, while carried out from a vehicle driving at a short distance, did not actually involve taking over the target vehicle without driver consent, e.g., over a communication link. Carrying out the attack required that the attackers connect, physically, to the CAN bus of the car. They did it with a laptop that was physically connected to the CAN bus inside the target car, with said laptop also maintaining the wireless connectivity to the other car (from which the attacks were launched). As of today, there is no clear way for an attacker to reach the CAN bus from outside the car using wireless connectivity alone.

This should not make us feel much better, though. The fact that no such clear way is known today does not mean that such a way is not found tomorrow. Consider that paths need not be “formal”, designed, ones. If there is an application in the car that connects on one end to a wireless network and on the other end to the CAN bus, and if this application has some flaw that allows it to be properly exploited, then the path from the wireless network to the CAN bus can be formed without having to install a laptop (or any other device) within the physical premise of the car. So keep using your car, but keep reading the news as well.

What I wanted to discuss is why this attack shall not come by as a surprise to anyone. It seems as we make a same mistake again; a mistake we’ve done already in the past, and thus should have known better. The mistake is designing a system with a hard external shell, which is very soft in the inside. We already tried this with networks on the Internet. Back in the nineties, it was widely accepted by most IT people that as long as a firewall is installed to isolate the corporate network from the Internet, not much else needs to be done, e.g., to protect internal components from each other. As long as the bad guys are kept out, why do we need to fortify what’s in? We then learned that firewalls can occasionally be bypassed, and that most attacks involve insider components anyway. Every network security manager knows by now that while a firewall is necessary, internal hosts need to be hardened, almost as if the firewall did not exist.

When designing car networks, it seems as we forgot what we learned when designing corporate networks. The CAN bus has no meaningful security of its own, and most applications using it are not any wiser. Instead, the entire vehicular system derives its security from the fact that the bus only spans the physical embodiment of the car, where all components are presumably cooperative and non-evil. As soon as an internal component becomes evil, either because it was taken over by an attacker exploiting a flaw in it, or, as was just demonstrated, because it was planted by someone else with different interests and morals, the system breaks apart.

What can be done? Use our past experience and wisdom to build security in the car network as we do in the corporate network. Entities speaking to each other need to be securely authenticated, and some access policy shall be enforced. Design the internal network as if outsides can get in, because one day they will.

In a paper of mine, Intra-Vehicle Information Security Framework (found here), I discuss a system that, among several other security features, provides for secure messaging between car components. Secure messaging would allow the brakes system to be able to tell signals coming from its valid controllers apart from signals coming from an outsider’s laptop, even if this laptop can access the CAN bus. As opposed to other secure messaging systems, it was built for low latency even on resource-constrained devices, to suit the typical vehicular use-cases.

We got very smart in network security over the past twenty years. We already paid the price of learning from experience. Let us not re-pay it; especially where the cost might be higher.