The latest in a line of connected vehicle attacks (http://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/) has generated a lot of buzz in the IoTSec community and concern among consumers and decision makers alike about security and the Internet of Things.Are vehicle manufacturers to blame for some form of negligence when an attacker is able to commandeer vehicle systems, causing anything to happen from adjusting seat positions and adjusting entertainment system and climate control settings to disabling a moving vehicle on a highway, and possibly far worse?Since Zero Day vulnerabilities can always exist, what is a reasonable expectation by consumers of safety, security, and privacy safeguards to be in place, and how can attempts to mitigate risk be gauged? What is the rightful role of network operators that provide connectivity in helping to mitigate risks?

Manufacturer Responsibility in the Face of Potential Vulnerabilities

Potential Zero Day vulnerabilities will always pose a risk of attack on hardware and software systems, and always have, and it would be unreasonable to expect otherwise or expect manufacturers to be able to prevent all such vulnerabilities. I would caution against designing a system that could pose risk to human life and having that include unnecessary attack vectors and lack obvious firewalling---systems that pose risk to human life probably are best left disconnected from the Internet.(As a tinkerer and owner of one of the connected vehicles with a high amount of integration between its CAN event/control bus and its entertainment system, I was in the middle of enjoying the sport of finding new vehicle subsystems to access via my entertainment system when news broke that my vehicle was not only well-connected with a wide-open, unrestricted shared networking bus within the confines of my vehicle, but it was also vulnerable to remote attacks via its emergency assistance subsystem that could easily take my life. Allowing me to hack my own vehicle, from within my vehicle, is one thing; however, allowing attackers to access my vehicle remotely and kill me is a little personal, and there is no practical benefit to even allowing two-way communications between the assistance/entertainment system and the control bus in the first place.)But, with that cautionary statement being said, the convenience of and rising demand for things like connected homes and other devices is bound to continue raising many additional risks to safety, security, and privacy as connectedness might actually be increasing faster than our ability as societies to understand, comprehensively, the complex intersection of old ways of thinking about the systems around us, seen and unseen effects of technology, and legal and social responsibilities and standards.

How Manufacturers Can Mitigate Risk in the Face of Zero Day Vulnerabilities

If Zero Day vulnerabilities are unavoidable, what can be done to minimize the potential of such vulnerabilities being exploited, and to minimize the effects of a successful attack? Here are some tips that can help:

1. Only allow device-to-device direct communication when needed: Yes, there are cases where a mesh topology is needed in order to scale; however, it can be just as difficult for a device to know when to trust another device as it is to trust a carny that a game isn't rigged---broker transactions and block peer-to-peer traffic whenever a star topology is needed to enforce security
2. Do not allow everyone on the Internet to connect inbound to a device: It is pretty much imperative that you have at least one additional line of defense that can perform authentication and broker the transaction; if not to improve the ability to authenticate and determine whether or not to trust the source of the inbound data, it at least affords you the opportunity to create heterogeneity (in other words, different systems, different operating systems, different software; thus, a different set of vulnerabilities and, therefore, it is less probable that vulnerabilities will align to activate an attack vector)
3. Do not trust the source, even if it appears to come from a dedicated M2M network: If someone removes a SIM card or performs a direct, local attack on a device, or compromises some other system residing on the network, that device can become an entrypoint into what otherwise might appear to be a secure area; thus, always require authentication and do not simply trust a device due to its access
4. Implement a way to perform over-the-air updates (securely) to patch devices before they are deployed: All too often devices remain vulnerable in the field because OTA updating, an essential part of the product lifecycle, was not implemented until a need arose; instead, assume your device is vulnerable when it ships and that you will need to send it a security patch on very short notice

The most important aspect to designing a secure product is to not treat the application as simply software, hardware, a peripheral, or even a desired use case; rather, it's to establish homeostasis between all the software/hardware/people components, service providers, and third-party entities that make the product possible, where there is a common understanding of: (a) the security needs, (b) what are potential risks to safety, security, and/or privacy, and (c) what risks are acceptable and what ones are not.Securing the application includes making sure a comprehensive policy is applied throughout all aspects of the product, which should extend to network topology as well.

How Network Operators Can Help Mitigate Risk

A network operator can be envisioned in one of two ways---a provider of a dumb pipe, or a provider of a smart pipe. What type of relationship a company has with a network operator, as influenced by these two "pipe" models, will affect what role the operator can play in helping secure connected devices.In the dumb pipe model, an operator simply provides a connection to the Internet---this is the most common way of thinking about an Internet connection that a service provider provides, and is the basis of where we get the ethereal "cloud" clip-art to represent the Internet in every business or networking diagram ever created. In this model, nobody cares about how data traverses the mythical entity known as the Internet; as long as it gets from Point A to Point B, we thank the provider by paying our bill. The downsides to this type of relationship are that: (a) all features of an application or solution must be developed/deployed at each endpoint (including security features), (b) the developer loses the opportunity to leverage capabilities unique or better suited to the network operator.In the smart pipe model, an operator provides a connection to the Internet (or, alternately, a WAN that is not general Internet routable), and can provide many other value-added services beneficial to a particular application. A smart pipe relationship between an application developer and a service provider that provides them with connectivity allows for intimate understanding of the capability and security needs for an application.Of the questions that could be asked to establish an understanding and design a tailored solution to an application, the most critical to reducing potential attack vectors include:

1. What topology is needed---do devices need to talk to one another directly, or should that be blocked?
2. Is general Internet access needed, or just routes to specific servers?
3. Are inbound connections to devices from non-devices needed, or should that be blocked?
4. If inbound connections to devices are needed, can that be accomplished via a VPN connection to provide access behind a firewall instead of forwarding ports?
5. What IP addresses should be whitelisted for privileged access?

The reality is that all of these remote connected vehicle attacks carried out to date could have been prevented, even in the presence of the vulnerability on the vehicle and without hardening the design of the vehicle itself, if only one of these five questions resulted in tailoring the network to suit the application.Preventing successful exploit of Zero Day or other vulnerabilities in one system is usually accomplished by having multiple rings of defense (so that a successful attack must align multiple vulnerabilities or weaknesses simultaneously in order for an attack vector to be established). This is not to say that hardening a device is a task to be taken lightly, but that a comprehensive security policy and system design that spans both device and the network is ideal for mitigating risk.

How Konekt Can Help

Konekt provides a smart pipe, at dumb pipe prices.We understand IoT security and privacy, manufacturing, system integration, and web application development, and the full application lifecycle. In addition to being able to disable unneeded services and eliminate unnecessary attack vectors, our Application Engineers can assist in building a comprehensive solution tailored to your application's needs.Furthermore, utilizing our off-the-shelf hardware modules and dev kits, or designing around our open source hardware and software, will allow your product to immediately leverage our integrated security, encryption, key management, and over-the-air update features on our platform.