Securing IOT: Stream Level Redaction

Wireless Sensor Networks (WSN’s) are increasingly being deployed in various applications. Some applications are military, health care, environmental, medical/life-sciences, industrial process management, industrial, agriculture etc.

The traditional threat model for WSN’s
covers security and attack vectors at stack levels within WSNs. The threat model typically covers these categories: cryptography techniques, a key management schemes, secure routing protocols, secure data aggregation and intrusion detection. Along with this we throw the various communication and routing protocols in the mix. Also must we consider security mechanism at high level and low level management in WSNs”. Traditionally there is a lot of overhead and required domain expertise in managing data security at an IOT Device level.

Traditional Data protection approaches and Challenges:

SSL/TLS: Our RestAPI post is done over TLS which is great. One of the challenges we’ve seen with TLS in recent years is that there have been very severe vulnerabilities with SSL and TLS with one happening about every 1–3 years. Even when TLS attack vectors are identified, they are not always patched in a timely fashion. Also Service providers or those that self host may not properly harden the TLS Configuration leaving it vulnerable to interception.

Data Storage: Even though we can protect the transport of our sensor data while “in motion” being transmitted to our backend service using SSL/TLS we want to persist the data in our backend system either in a database, queue, or index. SSL/TLS protects only the transmission of the data not the the storage. We could use Full Disk Encryption (FDE) or Transparent Data Encryption (FDE). Both of these only protect our sensor data while at rest. Once database tables are read into memory: Data In Use (DIU) it’s up to the system administrators to getting the Access controls & privileges correct so only the intended parties may read the data. TDE/FDE do nothing for access control, only protecting the dormant storage of our sensor data.

A new approach: Stream level redaction
The concept of realtime “Stream Level Redaction” identifies and swaps any type of sensitive data, replacing it in real-time with “surrogate” values which retains the functionality and utility of the original data. This is achieved by leveraging a service that works as a type of proxy. the Proxy performs the “Armoring” of data on behalf of the WSN IoT device. This approach allows us to instantly achieve a best-in-class security posture, free from the risk of data breaches, with low stack level implementation overhead. This approach also meets regulatory compliance requirements such as (PCI-DSS, EI3PA, SOC2, HIPAA, CERC, NERC, and more).

More on data protection threat modeling:

Example Scenario

We have a very basic Wireless Sensor Device (WSN IoT) that reports Sensor ID, Temperature, and GPS coordinates. We would like to protect the sensitive nature of the site’s location from interception. Our device reads GPS and Temperature and reports it to an WSN IoT backend service via RestAPI Call.

IOT Data stream Armoring Flow

The RestAPI call contains a JSON Data Structure:

As we can see the device does not protect the sensitive fields: “SensorID, GPS, or TEMP.

With Stream level data redaction we can securely intercept and armor the original data as it’s streaming to our backend service for storage.

Now we see the re-written fields: “SensorID, GPS, or TEMP. Notice that the sensitive data has been transformed into secure surrogate values vs the original data.

When the consumers of our data need to perform data driven operations They simply make a call to our API read method but proxy via our Stream redaction service which performs the reverse operation and reveals the data.

Since we are using either a “URL re-write” simples option for IOT devices, or setting the HTTP_PROXY environment variable on our IOT backend service and API consumers which need to read the original data, this is a zero to very limited code change integration. The processing of the data transformation as well as the Access and privilege management are offloaded from our IOT sensors, Backend service and even the Data consumers. All the security processing happens on the stream intercepting proxy service.

Try it yourself!
For this simple demo we will use a WiFi enabled ESP8266 or ESP32 development board

1. Visit Very Good Security:
And set up a free account.

2. Configure your VGS Account:

3. Install and configure Arduino:


4. Clone the sample IOT redaction project

5. open Arduino IDE and, open the file:
“<path you cloned the project to>/vgs_iot_demo/vgs_iot_demo.ino”

6. Compile and upload to your device.

7. Run the application && return to the VGS Dasboard: to configure your ‘Routes’ which is the set of rules you define for how to protect data elements on the stream.

8. Upload & run the Arduino “sketch” program: Open the Arduino “Serial Monitor” to view the responses from the API

Backend API Response showing securely redacted fields of data

9. View the result in the Dashboard: We can also see the whole message flow results when we return to and view the result with the the Dashboard’s builtin “Secure Debugger” tool:

WSN IoT RestAPI Message “re-written” by intercepting proxy. Sensitive values are secured

Click any of the tabs to see each phase of the data protection process. The debugger is very handy to see what your data looks like as it is exposed to the remote endpoint!

What’s Next

Congratulations! If you have made it this far, it means you have a functional and working demo of a secure and compliant Wireless Sensor Network message stream, and are on your way to securing WSNs for any application!



Information Assurance & DevOps/SecOps is my passion

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store