GPUs, Big Data, Security, and the IoT

At the GPU Technology Conference, NVIDIA CEO Jen-Hsun Huang and Tesla CEO Elon Musk talked about the security of a car. Musk stated that physical access is still required to hack most vehicles and that critical systems such as brakes and steering are segregated from the control display. This got me thinking about the security of the next generation of Internet of Things (IoT) devices.

Like a car, Z-Wave in a home or industrial plant, and many other controllers, the IoT starts with a mesh of devices all talking to each other locally. GPUs further enable the mesh of devices and local control of data, forming automatic actions on ingest of data local to the sensors. As the IoT becomes more complex, data will encounter multiple levels of meshed devices, controls, and automatic operations long before it reaches a big data repository.
Once data is within the repository, even more actions can be predicted, interrogated, and acted upon. We know how to secure the big data pool: companies like Dataguise have been doing it for years. The question now is “how do you protect the mesh of devices forming the sensor net?”
Encrypted overlay networks for movement of data within a mesh with no local storage come to mind. This is what happens within a car. Controlling how data moves between meshes also comes to mind, somewhat like verification before you gain more access to a secure environment. Ultimately, the data gets put into the data pool (or data lake).
Securing sensors is a major problem now and will continue to be so in the future. With the proper tools, securing sensors should be possible, but we need to think about things differently. Sensors are not part of a flat network: they are combinations of meshes of networks that share data at unique points within the meshes. Overlay encryption, both within a mesh and between meshes, is necessary.
This is where software-defined networking can particularly impact the security of the IoT. We can secure devices, but we should consider each mesh as a separate trust zone, and we should only allow access between trust zones at carefully considered locations. We should also consider how each sensor can be impacted by an action. Within well-designed cars, such as those from Audi, separate meshes ensure that brake and gas controls are not operable from within the display subsystem. While you can still fool the driver, there are several checks and balances within a car.
Elon Musk stated that control systems should not cross with display systems. However, the risks are subtler than that. If, for example, a display system showed the wrong data, it could prompt users to make different decisions than they would with the correct data. Within an industrial location, a sensor mesh may be segregated by gathering data, perhaps on controllable items and objects affected by actions. The same would hold true for a home or building.
Unfortunately, we are not currently giving most things such careful consideration. There are no segregated meshes of devices outside of cars. We tend to use flat, unprotected networks, putting both control and sensor on the same networks (except in the case of modern cars).
It is time we considered that the IoT is here. The environment is no longer simple, and it can be acted upon and manipulated in increasingly dangerous ways.

Broader Applications

Let us think about the hybrid cloud with this IoT model in mind. The same lessons lead to the same conclusions: each cloud interacts with specific data via specific paths. Each cloud could also be considered a mesh of applications and data. We can formulate this as a single trust zone per combination of data plus applications. This sounds like the sensor network we discussed before. As the data moves between application levels, we can formulate ways to protect the movement of that data.
The architecture works for hybrid cloud and IoT. The difference is in the scale: the IoT has tens of thousands of sensors, while a hybrid cloud may have only a few hundred per tenant. The keys to both are the data, data locality, and data handling within all parts of the environment.