3. Security Should be Thought of in Layers
With all the potential for individual security measures to be overcome, IoT developers need to start thinking of IoT security in multiple layers. To borrow an analogy from physical security, banks don’t protect their vault contents with just a good vault door; they use a good vault door as well as CCTV, intruder alarm and security guards. This way, if one of these measures is compromised there are others to fall back on.
In a similar way, when securing our IoT data, developers of things need to look at all the available options and potentially use multiple layers of security to protect it. As an example, let’s consider transmitting data to a back-end service and let’s further assume that the server that initially receives the data is not its final destination. There may be a number of hops that the data makes before reaching its final destination. This scenario is not uncommon. Many services will (partly for reasons of security) expose front-end servers to receive data which subsequently forward the data to back-end servers for processing/storage.
The logical first step in securing users’ data in this scenario is to use SSL/TLS encryption between the device and the front-end server; this is commonly referred to as point-to-point encryption as it is only between two adjacent points in the network. It would also be sensible to use SSL/TLS encryption when transmitting the data between the front-end and back-end servers. However, in this scenario there is no reason for the data sent to be exposed to the application layer in the front-end servers as the back-end does all the processing/storage.
With this in mind an additional layer of encryption could be added to the payload. One where only the sending device and the processing/storage back-end could successfully decrypt the data; this is commonly referred to as end-to-end encryption as only the sending device and the intended destination server can encrypt/decrypt data. There are a number of suitable encryption schemes that could be used for this additional layer of security, so you’ll need to choose one that is suitable for your system architecture and resources.
4. Protect Data in Rest, in Motion and in Flight
The next consideration is securing data in its different states: in rest, in motion and in flight. We’ll use the terms “in rest” to refer to data that is written to disk; “in motion” to refer to data that is in application memory; and “in flight” to data that is being transmitted between two entities. Each of these scenarios presents a security threat to a service provider.
If you ever find yourself in the unenviable position that your back-end storage servers have been compromised, you will no doubt be wondering how much data did the attackers obtain and how serious the breach is. These two considerations may seem like they are the same but they are not. A 3MB file with credit card information is a much more serious breach than a 30GB file with anonymized sensor data from your customers’ IoT devices. Additionally, if that 3MB file is correctly secured, the seriousness of the breach decreases considerably. Your servers will suffer an efficiency hit if you encrypt your data so make sure you use encryption wisely; encrypt sensitive data but perhaps leave non-sensitive data in plaintext format.
If you choose to encrypt your data, then you need to choose a strong encryption scheme. In this case, if your imagined attacker was good enough to breach your back-end systems, it would be foolish to assume they would be unable to crack weak encryption schemes.
Your data will have to be decrypted in memory; otherwise your applications wouldn’t be able to process it. Unencrypted data is vulnerable to attack – Heartbleed is an excellent example of an attack on data in memory – so you need to protect against such leaks by ensuring your application processes won’t leak memory when attacked. In the case of Heartbleed, information was leaked due to a lack of simple bounds checking. Be sure that any process that responds to requests strictly checks what data it should be returning.
You must protect your data when it is being transported between network entities, whether it is from a device to a back-end server or between devices in a Wi-Fi or WPAN. The former can be addressed using SSL/TLS encryption with the caveat that you may want to add end-to-end encryption. The latter can be handled with a combination of link-layer security and, possibly, additional encryption. Link-layer security in Wi-Fi networks is beyond the developer’s control as it is determined by the user’s Wi-Fi Access Point. If they are using WPA2 with a strong passphrase then the data is probably safe, but they could just as easily be using WEP or no link-layer security at all; public hotspots often forgo link-layer security to allow users to more easily access their networks.. With this in mind, for particularly sensitive data additional encryption should be used.
Link-layer security in WPANs certainly falls more under the control of the developer than Wi-Fi. We saw earlier that if good key exchange algorithms are employed then using encryption in Bluetooth (specifically using the Secure Connections standard) and ZigBee networks can be very robust. However, you will need to interoperate with other vendors’ devices and that might mean using less robust security configurations in Bluetooth or ZigBee.
5. Always Balance the Application, End-User Needs and Processing Resources Required for Each Security Measure
Finally, it would be easy to say you never have enough security and should add several layers of security to each part of your systems architecture. The truth of the matter is that it’s just not feasible, particularly on the more resource constrained devices in your system. You can add additional hardware to your IoT devices to enable them to handle the extra security, however that brings with it an increased cost of manufacturing and ultimately increased cost to the consumer. You will need to balance the need for security with providing a price point to the customer that will get them interested in your brand.
With that in mind, prioritize your security in areas that need it. For example, if personal health information is being transmitted you can beef up the security but for a device transmitting anonymized temperature information for a building, the security layers don’t need to be as rigorous.
There will probably be a lot of decisions around how security is applied in your IoT system and to which layers, but you now have the information needed to start making those decisions.