5 Key Requirements to Securing IoT Communications
1. Devices Must Not Have Open Inbound Ports
For one device - say, a server - to push data, another device (i.e. an IoT device) has to be listening. In a traditional model, the listening device will open an inbound port and wait for data to be pushed. While
this can work in some scenarios, it is a massive risk for IoT as these ports must remain open indefinitely. The security risks of leaving inbound ports open include malware infections, modification or theft of data, DoS attacks, and arbitrary code execution.
Let’s be very clear: any device on the Internet with an open inbound port will be attacked. It’s a matter of when, not if.
Devices connected to a secure IoT network should make only outbound connections. These connections are not vulnerable to the kind of attacks that open inbound ports are. The outbound-only design pattern eliminates one major threat to IoT devices. To support this design pattern, we’ll also need to use a publish/subscribe communication design so devices can send data bi-directionally.
“Any device on the Internet with an open inbound port will be attacked. It’s a matter of when, not if.”
2. End-to-End Encryption
Transportation Layer Security (TLS) is an industry standard communication layer for sending encrypted data over a wide area network (WAN) that can be paired with AES encryption to provide true end to end
security. TLS/SSL protects the top level of data streaming between devices, encrypting the data from device to device at the endpoint when the data is transferred. While TLS/SSL is suitable for data
transmission security, data generated from IoT devices is still vulnerable over the network unless it is encrypted. For true end-to-end security, the data itself should be encrypted with the Advanced Encryption Standard (AES) encryption specification.
3. Token-Based Access Control
While AES and TLS/SSL can be used to encrypt the data as it is being transferred, another major challenge is fine grain access control over who and what can transmit and receive data. With potentially millions of devices trying to listen to the correct channels and topics, it is extremely inefcient and insecure to ask end devices to filter out topics they don’t subscribe to. Instead, the network should handle the bulk of this task.
4. Device Status Monitoring
In both consumer and industrial IoT, it is critical to actively monitor the online/ofine status (“presence”) of devices. When a device such as a home security monitor, oil field sensor, or home appliance disappears
or stops sending and receiving data, the owner or monitoring system needs to know about it. An ofine device could mean local tampering is taking place, or a broader issue like a power or Internet outage
has occurred.
“An ofine device could mean local tampering is taking place, or a broader issue like a power or Internet outage has occurred”
5. User-Friendly Setup and Upgrades
Thus far, we have assumed that the IoT devices in question are operational and connected to the internet. It’s time to address the process of getting devices up and running, and keeping them up to
date with software and firmware upgrades.
Imagine this scenario: a consumer purchases a system of 6 wi-fi enabled cameras with motion sensors for home security. The customer expects that these cameras will work like any other peripheral device once they are plugged in and connected. Today, that expectation is rarely met.
“A publish/subscribe paradigm makes it easy to securely set up and provision IoT devices.”
For one device - say, a server - to push data, another device (i.e. an IoT device) has to be listening. In a traditional model, the listening device will open an inbound port and wait for data to be pushed. While
this can work in some scenarios, it is a massive risk for IoT as these ports must remain open indefinitely. The security risks of leaving inbound ports open include malware infections, modification or theft of data, DoS attacks, and arbitrary code execution.
Devices connected to a secure IoT network should make only outbound connections. These connections are not vulnerable to the kind of attacks that open inbound ports are. The outbound-only design pattern eliminates one major threat to IoT devices. To support this design pattern, we’ll also need to use a publish/subscribe communication design so devices can send data bi-directionally.
“Any device on the Internet with an open inbound port will be attacked. It’s a matter of when, not if.”
2. End-to-End Encryption
Transportation Layer Security (TLS) is an industry standard communication layer for sending encrypted data over a wide area network (WAN) that can be paired with AES encryption to provide true end to end
security. TLS/SSL protects the top level of data streaming between devices, encrypting the data from device to device at the endpoint when the data is transferred. While TLS/SSL is suitable for data
transmission security, data generated from IoT devices is still vulnerable over the network unless it is encrypted. For true end-to-end security, the data itself should be encrypted with the Advanced Encryption Standard (AES) encryption specification.
3. Token-Based Access Control
While AES and TLS/SSL can be used to encrypt the data as it is being transferred, another major challenge is fine grain access control over who and what can transmit and receive data. With potentially millions of devices trying to listen to the correct channels and topics, it is extremely inefcient and insecure to ask end devices to filter out topics they don’t subscribe to. Instead, the network should handle the bulk of this task.
4. Device Status Monitoring
In both consumer and industrial IoT, it is critical to actively monitor the online/ofine status (“presence”) of devices. When a device such as a home security monitor, oil field sensor, or home appliance disappears
or stops sending and receiving data, the owner or monitoring system needs to know about it. An ofine device could mean local tampering is taking place, or a broader issue like a power or Internet outage
has occurred.
“An ofine device could mean local tampering is taking place, or a broader issue like a power or Internet outage has occurred”
5. User-Friendly Setup and Upgrades
Thus far, we have assumed that the IoT devices in question are operational and connected to the internet. It’s time to address the process of getting devices up and running, and keeping them up to
date with software and firmware upgrades.
Imagine this scenario: a consumer purchases a system of 6 wi-fi enabled cameras with motion sensors for home security. The customer expects that these cameras will work like any other peripheral device once they are plugged in and connected. Today, that expectation is rarely met.
“A publish/subscribe paradigm makes it easy to securely set up and provision IoT devices.”
Leave a Comment