How to Ensure Security of Your Real-Time Data Analytics Pipelines

Fog computing, a paradigm that aims to bring cloud-like services closer to users and data sources, has become quite popular among IoT firms. Not only does it allow speeding up reaction to events and acting on perishable insights, but it also helps companies conserve core network bandwidth.

Moving computations to where IoT data (in all its variety and velocity) is generated has some downsides too. The devices at the edge usually have a low computing capacity and they may, due to slow uplinks, receive security updates with substantial delays.

Besides that, all sensor data in IoT networks usually flows through multiple vulnerable infrastructure components, which opens a wide attack surface.

First, we must talk about the unique characteristics of IoT data:

1) It comes in large volumes as there are, typically, myriads of devices in a connected network that are constantly emitting events.

2) The datasets are heterogeneous as the devices producing them are of different types.

3) Each data object may come with both location and time stamps attached to it.

4) IoT data is often very noisy as the devices producing and transmitting it (weak in terms of computational power) tend to distort it.

Another key point is that information from IoT devices (say at a manufacturing plant) requires a quick reaction as opposed to general big data that can be stored in remote data centers for days. The insights extracted from IoT data are typically extremely perishable.

Fog computing was created specifically to address the latency issue in cloud-based IoT networks, but, as it turns out, processing lots of information at the edge, one or a few hops from the IoT devices, is quite risky.

If an attacker manages to break into an IoT network, which shouldn’t be too hard to do given the devices’ vulnerability, they would not only access sensitive data; they could potentially corrupt datasets, send them to the cloud and thus compromise a firm’s entire IoT deployment.

As far as protection goes, one of the most recent (and promising) approaches has been locking both edge data and computations into a Trusted Execution Environment and thus, preventing their direct contact with the sophisticated and untrustworthy infrastructure components at the edge such as commodity operating systems, user libraries, etc.

Applying this strategy, however, also creates challenges: it’s tough to execute high-throughput analytics in a single, separated TEE due to it being constrained by a small trusted computing base (TCB).