7 Points to Add to Your IT Policy Framework for Securing IoT Deployments

James Branigan, Partner, Bright Wolf

Ever since computers were connected together on a network, IT leaders have faced an uphill battle keeping their systems and business applications secure, an endeavor made increasingly daunting by the advent of the Internet of Things in the enterprise. The good news is IT leaders can increase the level of native immunity and reduce avenues of attack within their production connected systems by adopting a 7-part IT policy framework during the planning phase of IoT projects inside their organizations. These IoT-specific elements enable IT leaders to augment and extend their existing enterprise application and system policy frameworks to include approval of IoT systems as well. 

IT leaders should require IoT solutions to either meet all of the following criteria or demonstrate clear justification for waivers on any points.  

1. Encrypting Data in Motion

This requirement exists in almost every IT policy frameworks already.  However, the requirement should be updated to require applications to account for the differences between traditional client-server and server-server data transfers and those that take place in an IoT environment.

  ​Any system that does not have clear and documented solutions for each requirement risks failure through both malicious intrusion and simple errors of complexity over time  

There are several ways in which data transfer in an IoT system can vary from typical client-server topologies. 

1. Multiple radio links for data transfer prior to the final connection to the network.  Examples can include Bluetooth, LoRA, 900Mhz and others.
2. Legacy devices in the field that have connectivity added as a part of a retrofit.  (It’s important to ensure the retrofit capability meets your requirements)
3. Devices are deployed inside customer IT environments rather than operating behind the corporate firewall.

2. Secure Connection Establishment Criteria

In general, IoT devices should not accept incoming connections over the network.  As a best practice, IoT devices should establish an outbound connection.

There are cases where devices require provisioning/configuration modes that are often more permissive and open during initial setup and configuration. This is especially the case if configuring a device to communicate on a corporate Wi-Fi network.

Any cases where a device is listening for an incoming connection should be carefully scrutinized to ensure that there aren’t inherent security risks. Any devices that listen MUST be software updatable (See Policy Point #6). Even if a device ships with no known vulnerabilities, over time the software that devices use can have a vulnerability uncovered in the portion of the stack listening for connections.

3. Device Talking to Right Server

Like any connected system, IoT devices are susceptible to Man-in-the-Middle attacks.  Due to complex embedded system design constraints, validating correct behavior can be challenging. It often isn’t feasible for IT to dictate that a specific piece of software or configuration be utilized. 

Technologies such as DNSSEC and techniques such as Device-generated and signed challenges to the Server are useful in mitigating this risk. Applications requiring high security will often utilize a cellular communications channel, with a private VPN connection from the cellular providers network to their IoT application.  This approach significantly raises the bar for attackers and allows for greater control over DNS, enabling a chain of trust to be established for DNSSEC.

4. Server Validation of Device Identity

In order for a server to validate the identity of each device it is communicating with for both sending and receiving data, a challenge-response protocol is necessary using a unique set of encryption keys. These keys must not be directly accessible to malware that may infiltrate the device, and are critical aspects of device design and firmware implementation. This is typically enabled through the use of a trusted compute module in the embedded system design that can respond to server challenges. Management of these keys, including rotation in the event of a key compromise, is a critical point where IT leaders should require project teams to prove that they meet industry best practices.   

5. Server Validation of Device Software Version

Consumer grade IoT devices have already been shown to be susceptible to malware type attacks by botnets. For consumer applications a loss of service can be frustrating, and is simply unacceptable in an enterprise. It is critical for the design of an Enterprise IoT system to have the capability for the server to validate the versions of each piece of software running on the device(s).  This is typically accomplished by challenging a chip in the embedded system to sign the contents of its program storage and comparing the result on the server side to ensure the device is running the version of software that it claims to be running.

6. Distribution of Software Updates and Secure Build Chain

Compared with traditional Enterprise environments, the IoT requirements for managing software updates are unique in several ways. Typically, software updates are deployed to devices using an automated process. These updates are built from software stored in version control software, run through a build and test process and packaged for delivery. This entire chain, from the software commits to the built packages must be signed and secured to ensure the software delivered to the device isn’t compromised along the way. The actual update processes themselves are often driven by application specific scenario logic (i.e. A firmware update should only be applied when the refrigerated trailer is not running and only when the door is open). It is important the policies for distribution and update are configurable to allow this application specific logic to determine when an update is safe to perform, while not allowing the application to side step required security measures. Additionally, bandwidth may be constrained and metered. This expense can result in application designs that download an update to a physical location once, and then proceed to update other peer devices on the same local network. The details of this local mirroring must be reviewed as an additional part of the approval process.

7. Device Validation of Signed Updates

When a device receives a new software update, it must be able to verify the signature of that update to ensure that it hasn’t been replaced with a different version. Validation of updates throughout the chain and at both endpoints is critical for keeping the end-to-end system secure.  Published signatures for the updates should be validated by devices prior to applying an update. Layering this requirement with the desire for local mirrors of updates can also result in non-trivial interactions.

Conclusion

The specific methods for meeting these criteria will vary across industry and application. Any system that does not have clear and documented solutions for each requirement risks failure through both malicious intrusion and simple errors of complexity over time. On a positive note, major cloud providers have made strides to address several of these concerns. Enterprise solutions leveraging connected infrastructures like AWS IoT and Azure IoT Hub provide IT leaders a good starting point for addressing these challenges. IT leaders will still have their hands full keeping their networks and business applications secure. Through a rigorous policy framework, the set of additional challenges added by the Internet of Things can be further reduced and managed.