facebook noscript

Securing IOT: Stream Level Redaction

May 27, 2018
engineering-default

Wireless Sensor Networks (WSNs) are increasingly being deployed for various applications and you no longer need a degree in computer science to understand the benefits of them. A wireless sensor network is an interconnected group of devices that monitor the environment through sensors and communicate via wireless.

You can now find these distributed sensor networks used in the military, health care, environmental, medical/life sciences, industrial process management, industrial, and agricultural industries. It even includes mobile ad hoc networks (MANET).

But when we look at any interconnected platform, we need to inspect IoT network security. Wireless sensor networks are no different. The top WSN security issue, among others, deals with protecting sensitive data from being captured by malicious parties. Hackers can manipulate sensor nodes or subvert routing protocol to gain access to personal information. A sensor node is used to process information and can communicate with other nodes in your WSN system. These nodes often include a security protocol called key pre-distribution, but this doesn’t ensure the integrity of the system.

The traditional threat model for securing wireless sensor networks covers security and attack vectors at stack levels within the wireless sensor network itself, such as protecting data passing through sensor nodes.

Solutions to the IoT security vulnerabilities associated with WSNs typically cover the following categories: cryptography techniques, key establishment, key management, key distribution, secure data aggregation and intrusion detection. In addition, we throw the various communication and secure routing protocols in the mix. We must also consider security mechanisms at high-level and low-level management in WSNs.

Traditionally there is a lot of overhead and required domain expertise in managing data security in a wireless sensor, and at a general IoT Device level overall. And as more data is processed through these sensors, which must also handle extra security protocols, ultimately the life of your devices and energy consumption is affected.

To better understand the best way to securing wireless networks, we need to look at the data security options and challenges they present.

Traditional data protection approaches and challenges:

There are few different approaches to wireless network security, all with their own set of challenges:

SSL/TLS: Our RestAPI post is done over TLS which is great. But 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 major event happening about every 1–3 years. Even when TLS attack vectors are identified, they are not always patched in a timely fashion, which hampers wireless sensor network security. In addition, 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 being transmitted to our backend service using SSL/TLS we want to keep the data in our backend system either in a database, queue, or index. Here, the issue with wireless sensor network security is that 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 and privileges correct so only the intended parties may read the data. TDE/FDE do nothing for access control or key management, only protecting the dormant storage of our sensor data.

A new approach: 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 safeguards the data on behalf of the WSN IoT device before it is processed by a sensor node.

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, SOC2, and more.

Here is more on data protection threat modeling.

Example Scenario in IoT Network Security

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. We want to ensure that the wireless sensor network security protects the data during the secure routing protocol as well as at rest.

IoT Data stream Armoring Flow:

data-flow

The RestAPI call contains a JSON Data Structure:

Headers
host api.gordonyoung.us:443
Accept-Encoding identity;q=1,chunked;q=0.1,*;q=0
Content-type application/json
User-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.

Headers
Accept-Encoding identity;q=1,chunked;q=0.1,*;q=0
Content-type application/json
User-Agent ESP8266HTTPClient
...
host api.gordonyoung.us:443
content-length 145
Body{
  "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 and is no longer showing 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 rewrite” 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 is offloaded from our IoT sensors, backend service, and even the aata consumers. All the security processing happens on the stream intercepting proxy service.

Don't miss the next Developer Office Hours with our CTO

Join Us

Try securing wireless networks yourself!

The good news is, you don’t need a degree in computer and information science to secure your WSN. 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.
__7. Run the application and 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.
a. https://www.verygoodsecurity.com/docs/getting-started#
b. https://www.verygoodsecurity.com/docs/getting-started#securing-data

routes

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
debugger

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 the Dashboard’s builtin “Secure Debugger” tool:

vgs-debugger

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 wireless sensor networks for any application!

gordon-young Gordon Young

Security Specialist

Share

You Might also be interested in...

compliance-default

PCI Scope Reduction: Understanding the Process

Stefan Slattery June 15, 2018

engineering-default

Threat Modeling for Data Protection

Gordon Young May 24, 2018

engineering-default

User Management Feature Release

Ulyana Falach December 13, 2017