Securing IoT: Stream Level Redaction

 

The Article you are about to read was first published by Gordon Young of Very Good Security

Wireless Sensor Networks (WSNs)
are increasingly being deployed for 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, 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 a 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 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 get the Access controls & privileges correct so only the intended parties may read the data. TDE/FDE does nothing for access control, only protecting the dormant storage of our sensor data.

 

A new approach: “stream level redaction” The concept of real-time “Stream Level Redaction” identifies and swaps any type of sensitive data, replacing it in real-time with “surrogate” values which retain 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 modelling:
https://medium.com/@gordon.young/threat-modeling-for-data-protection-f263ba1c54d9

 

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 a WSN IoT backend service via RestAPI Call.

 

IOT Data stream Armoring Flow

 

The RestAPI call contains a JSON Data Structure:

Headershost api.gordonyoung.us:443Accept-Encoding identity;q=1,chunked;q=0.1,*;q=0Content-type application/jsonUser-Agent ESP8266HTTPClient...Body{  "SensorID": "E25C67AF-CA37-4996-8C7A-3375499995FB",  "GPS": "334484N1120740WT1526864344",  "TEMP": "48.2C"}

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.

HeadersAccept-Encoding identity;q=1,chunked;q=0.1,*;q=0Content-type application/jsonUser-Agent ESP8266HTTPClient...host api.gordonyoung.us:443content-length 145Body{  "SensorID": "tok_sandbox_5BkDXb68SeBNZBeYagAeMa",  "GPS": "tok_sandbox_5TkDXb68SeBNZBeYagBWME",  "TEMP": "tok_sandbox_51y7ZoSyeKSAiZY8uGFUfW"}

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: https://www.verygoodsecurity.com

And set up a free account.
2. Configure your VGS Account:
https://www.verygoodsecurity.com/docs/getting-started

3. Install and configure Arduino:
a. https://www.arduino.cc/
b. https://learn.sparkfun.com/tutorials/esp8266-thing-hookup-guide/installing-the-esp8266-arduino-addon
4. Clone the sample IOT redaction project

 

$ https://github.com/gjyoung1974/vgs_iot_demo.git

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. https://www.arduino.cc/en/Guide/ArduinoUno
__7. Run the application && return to the VGS Dashboard: __

to configure your ‘Routes’ which is the set of rules you define for how to protect data elements on the stream.
a. https://www.verygoodsecurity.com/docs/getting-started#
b. https://www.verygoodsecurity.com/docs/getting-started#securing-data

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 https://dashboard.verygoodsecurity.com and view the result with 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!

 

 

Now your take on this argument.

We would also like to hear what you feel about the topic we discussed today. Your feedback is very important to us. Feel free to drop your comments and recommendations. If you have a contrary opinion, you can drop that too.

You can also join our Facebook Page CRMNigeria for more updates. You can do that by clicking on the link or searching for our page on Facebook.

 

 

You can also join our WhatsApp Group Here.
Kindly Subscribe to CRMNIGERIA Articles by Email