After more than 25 years of developing our experience in securing the Internet, we know that there is no silver bullet, no one single control that is adequately going to protect a device. We know that security is a multi-layered approach. It starts when devices are powered up, when trusted communication paths are established, when data is transmitted and stored securely.
Security must be addressed throughout the device lifecycle, not just limited to an initial design, but evolving as knowledge is gained, standards are adopted, and adapting to the operational (threat) environment.
When power is first introduced to the device, the authenticity and integrity of the software on the device should be verified using cryptographically generated digital signatures. This could be an MD5 checksum, our specially-coded tags inserted into the binary image. In much the same way that a person signs a cheque or a legal document, a digital signature attached to the software image and verified by the device ensures that only the software that has been authorized to run on that device, and signed by the entity that authorized it, will be loaded. The foundation of trust has been established, but the device still needs protection from various run-time threats and malicious intentions.
Next, different forms of resource and access control are applied. Mandatory or role-based access controls built into the operating system limit the privileges of device components and applications so they access only the resources they need to do their jobs. If any component is compromised, access control ensures that the intruder has as minimal access to other parts of the system as possible. Device-based access control mechanisms are analogous to network-based access control systems: even if someone managed to steal corporate credentials to gain access to a network, compromised information would be limited to only those areas of the network authorized by those particular credentials. The principle of least privilege dictates that only the minimal access required to perform a function should be authorized in order to minimize the effectiveness of any breach of security.
When the device is plugged into the network, it should authenticate itself prior to receiving or transmitting data. Deeply embedded devices often do not have users sitting behind keyboards, waiting to input the credentials required to access the network. How, then, can we ensure that those devices are identified correctly prior to authorization?
Just as user authentication allows a user to access a corporate network based on user name and password, machine authentication allows a device to access a network based on a similar set of credentials stored in a secure storage area.
Firewalling and IPS
The device also needs a firewall or deep packet inspection capability to control traffic that is destined to terminate at the device. Why is a host-based firewall or IPS required if network-based appliances are in place? Deeply embedded devices have unique protocols, distinct from enterprise IT protocols. For instance, the smart energy grid has its own set of protocols governing how devices talk to each other. That is why industry-specific protocol filtering and deep packet inspection capabilities are needed to identify malicious payloads hiding in non-IT protocols. The device needn’t concern itself with filtering higher-level, common Internet traffic—the network appliances should take care of that—but it does need to filter the specific data destined to terminate on that device in a way that makes optimal use of the limited computational resources available.
Updates and patches
Once the device is in operation, it will start receiving hot patches and software updates. Operators need to roll out patches, and devices need to authenticate them, in a way that does not consume bandwidth or impair the functional safety of the device. It’s one thing when Microsoft sends updates to Windows® users and ties up their laptops for 15 minutes. It’s quite another when thousands of devices in the field are performing critical functions or services and are dependent on security patches to protect against the inevitable vulnerability that escapes into the wild. Software updates and security patches must be delivered in a way that conserves the limited bandwidth and intermittent connectivity of an embedded device and absolutely eliminates the possibility of compromising functional safety.
IT STARTS IN THE OS
Security cannot be thought of as an add-on to a device, but rather as integral to the device’s reliable functioning. Software security controls need to be introduced at the operating system level, take advantage of the hardware security capabilities now entering the market, and extend up through the device stack to continuously maintain the trusted computing base. Building security in at the OS level takes the onus off device designers and developers to configure systems to mitigate threats and ensure their platforms are safe.
THE END-TO-END SECURITY SOLUTION
Security at both the device and network levels is critical to the operation of IoT. The same intelligence that enables devices to perform their tasks must also enable them to recognize and counteract threats. Fortunately, this does not require a revolutionary approach, but rather an evolution of measures that have proven successful in IT networks, adapted to the challenges of IoT and to the constraints of connected devices. Instead of searching for a solution that does not yet exist, or proposing a revolutionary approach to security, focus instead on delivering the current state-of-the-art IT security controls, optimized for the new and extremely complex embedded applications driving the Internet of Things.