Security

Introduction: As a discipline, security in IT systems (cybersecurity) can be applied to all IoT devices the same way one would apply cybersecurity principles to any other IT system, assuming the device has enough computing resources available to implement them. However, the IoT has some unique challenges because most (not all) devices are designed to run for on batteries with a very low energy budget, so they may not have enough computing power to support normal security functions.

For example, it is difficult to install an anti-virus engine on the IOT devices to enable the scanning, as it adds to a systems overhead, affecting power consumption and performance of the device. So adding anti-virus applications such as white listing, secure VPN client, encryption at rest etc are often not options for an IOT device. It's also hard to develop standards for IoT security when there is a huge diversity of device processing capabilities.

In addition, IOT devices are generally supposed to run 24/7 but normal IT systems have evolved around regular maintenance windows to enable patching, installing later versions etc.  Another difference is that identity and access management (IAM) for IOT usually involves large numbers of generic and shared accounts, which diverges from the normal nominative accounts in IT.

Devices that have wired power available would, of course, allow more security options. However, if designers try to force a lot of traditional security tools and techniques onto IoT devices, they may impact the key cost, functionality and efficiency targets the device is meant to be providing. 

The broad requirements of cybersecurity include maintaining confidentiality, availability and integrity of IoT devices and systems. Confidentiality relates to information only being seen by the things and people that are supposed to see it. Availability is about ensuring the device works as intended and integrity is ensuring data hasn't been tampered with. How and if security is implemented in IOT depends on the context and the reality is that many IoT device vendors do not provide any security at all or update their devices.

If the IoT is conceptualised as everything connected to everything else, then it would be very difficult to secure. Generally, more connectivity options mean more threat vectors. One of the premises of security is to actually have centralized management of devices or networks. If there is no centralized control, it's very difficult to secure because every single thing and point of connection would have to be secured. However, IOT systems are generally hosted on a private network, with access to the Internet through a gateway, which goes to other private networks where the various devices are connected to or managed from. If the IOT is conceptualised this way, then the path to security is easier.

Practitioners in the IoT space need to have a robust understanding of cybersecurity because vendors of solutions will often market their solutions as having security. However, often they are only addressing part of the security landscape, such as SSL or TLS and not the broader concepts outlined below.

General approaches

The first step in IoT Security is to ensure that appropriate governance arrangements are in place. When organisations have a very large number of IoT devices connected to their network, it's important to understand who is accountable and responsible for the devices. There should be a central person who's concentrating on the IoT devices so they can devise strategy and policy around that.

Another important step is to be aware of what IoT devices are actually connected to an organisation's network. Search engines such as Shodan, enable administrators (and hackers) to identify the type and location of any device that is connected to the internet, including what SCADA protocol it is using. 

Developing strategy around IoT cyber-security involves two basic views – that of the device and the system.

The device view examines if the thing itself is secure. Security factors in this view include:

• User Access Controls
• Physical Protection (Tamper-Proofing)
• Product integrity
• Cryptography, Firewall, Alarms
• Support arrangements, remote access, security updates.
• Software Robustness (OWASP)
• Local Memory protection, Zeroing device memory
• Device Safety
• Trusted identity

A key challenge in IOT is the physical protection of the device, particularly if it is in a remote location. This can make it easier for someone to tamper with it or replace it with a device that is not legitimate but still recognised by the system as authenticated. Ideally, devices have a trusted identity which is built into them at all levels from chipset manufacture through to burning of firmware and testing. Quite often, there will be a symmetric token known as a transport key which can be used to build more complex and trusted identities.

When talking about trusting the identity of an IoT device, it is more than just having an IPV6 address. The identity may need to be cryptographically generated as a certificate, essentially device fingerprinting. If a trusted identity can be established then it may be able to talk directly to a server in the enterprise system.

Password security requirements for IoT devices have the same requirements as most ICT systems. For example, password length should be able to be configured or the password length should be enforced to be a strong password, enforced by the software, with a mix of characters and so forth, with a minimum number of characters. A basic requirement is to ensure passwords are changed from defaults. However, many consumer IoT devices such as security cameras did not enforce this, making it easy for massive numbers of devices to be hijacked via botnets and used for launching denial of service attacks. An example of a virus that has exploited weak password protection is Mirai.

IoT devices that are deployed in the field are often certified for security by independent third parties, using standards such as the Underwriters Laboratories 2900 Series of Standards linked below. These set out a list of security requirements similar to those listed above.

The cybersecurity certificate on an IoT device normally sets out any risks and vulnerabilities of the project that are still open, i.e. that haven't been mitigated. The manufacturer might recommend that the user or the buyer of this product actually mitigate that risk in the context where it's installed.

Also, users need to take into account that the out-of-the-box security might also not be as tight as you need. You actually need to understand the level of security provided and whether it would pass the required test. Many IOT projects might pass the simpler ones but not the most stringent ones.

Finally, viruses and other threats are constantly changing. However, it is often hard to upgrade the firmware of IoT devices due to the limited bandwidth available.

In the system-wide view, there is a greater emphasis on risk management to ensure the integrity of the enterprise systems. This can be used to identify risk in two basic ways:

• Attack vectors from outside into the device: For example, what damage can be done by the Device Itself to the environment it operates in and controls?
• Attack vectors from the device to the network: What other things on the device’s network can be compromised if hackers launch an attack from the device?

The risk management approach is important because it determines the level of controls that need to be put in place. The higher the risk (likelihood and consequences) of catastrophic damage then the more effort needs to be put into cybersecurity. 

IOT devices within a private network are attractive targets for hackers because they are usually listed as an authentic device and it's feeding information of value to the network. This provides a great platform for internal attacks if the hacker can take over the IOT device.

A general principle of security, well known in industrial control systems, is that of enclaving or segration (see below) and controls are needed to protect the rest of the system and ensure the integrity of the data flow and communication channels. These controls include:

• Access controls (Personnel and Equipment)
• Firewalls in various network segments, including deep packet inspection
• Network design principles, segmentation, DMZ, Reverse Proxy, DNS
• Secure Protocols
• Use of SSL and VPN
• Encryption and Encryption Key Management
• Intrusion Detection and Protection Systems
• Secure Software Design
• Malware Protection
• Patching and Vulnerabilities Management
• Disaster Recovery, Resilient Design, Backups

The final step in the general approach is to test the security of the IT system, including the IoT devices. This can include penetration testing or even having a "red team" actively looking for ways to compromise the system. The aim is to learn and continually improve security.

Segregation

A core strategy underpinning most IoT security is segregation, whereby IoT devices are separated from the more important IT systems. Many security systems employ edge computing concepts whereby aggregation and initial processing of the raw data takes place in gateways (sometimes known as edge gateways - see below) which typically have more processing power than the sensing IoT devices themselves. The data is then passed via firewalls to the enterprise system. The addressing and control of the IoT devices are carried out directly by the edge gateways but only because it is cryptographically authorised to do so. For mission-critical functions, such as braking in a car, the digital identities of each component of the car should be set up so that the head unit (connected to the internet) is not authorized to send commands to the critical vehicle control units.  Thus, if a hacker was able to take control of an edge gateway, such as the head unit of a vehicle, they could not endanger the safety of the passengers. In this scenario, the security management of gateways in an IoT network is as important as the sensing and actuating things.

Another crude but effective segregation method is the use of data diodes, which effectively ensure the system only allows one-way traffic and can be thought of as a very simplified firewall. This is useful for IoT applications where the system only needs to receive data from the device and can be used for things like streaming CCTV. This removes one potential attack vector by restricting access by malicious third parties. Of course, this means the owner of the device is not able to control, configure or update it.

However, firewalls can be far more sophisticated and the general approach to segregation is to have an external firewall and an internal firewall, with a demilitarized zone between the two. It's heavily monitored and controlled by the intrusion protection system. Only certain data traffic is allowed. Intrusions can be detected by collecting all the log files from different devices so you know how many times it's been accessed and by whom.

Among the standards listed below, ISA/IEC 62443 introduces the concept of conduits and zones. Using this concept, various zones are identified for security purposes.

The Zone and Conduit Model introduced by ISA/IC 62442. Diagram courtesy Ed Custeau, Security Specialist at Spiral Systems.

The example illustrated above include and IOT Things zone for things like sensors geographically distributed around a district or state, in mountains, on the top of towers, etc. They all have certain physical protection requirements and have some isolation already. So the concept of network segmentation can be used to identify these devices as being on a separate network.

There can also be a central point like a control centre, with a firewall, that provides access through the demilitarized zone for the purpose of remote access control and basic configuration of the system.

Another firewall may also provide access to the main control zone which typically has a SCADA type of system, alarms, intrusion detection system, SNMP managers, and controls. This system may actually send commands to some other parts of the network and control IOT devices.

So in this example, there are three zones and engineers can define the conduits, which are very strict rules controlling what traffic is allowed from one point of the network to another and the characteristics of the traffic. For example, the IoT01 conduit illustrated might allow messages that authenticate the device when it’s turned on or when it comes to the network.

The red arrows illustrated may be control messages or alarms that are allowed to go through the demilitarized zone without intervention but with very strict rules. Each one of these flows is documented and is given to ICT people to program/configure the firewalls and the intrusion detection system. That in itself gives two layers of security.

A firewall is a bit like the lock in your house. It locks parts of the network and messages get bounced back. You can't go through that door if you don’t have the right key. The intrusion detection system is like a sensor in your home. Even though you locked the door, you still have a sensor inside with back-to-base monitoring, just to be double-sure.

The use of security features such as firewalls, secure socket layer,  single sign-on server, etc is part of convergence trend between enterprise and operational IT systems. With this trend, new concepts such as digital twins are emerging. For example, human administrators traditional use VPN to login to sensitive industrial systems. However, some argue that you are better off actually connecting to a secure web service API, which then securely connects off into an industrial control system secure network. In other words, using the principle of least privileges, you're creating abstraction layers between human being and devices, and also between devices themselves, which is enabled through service gateways and edge gateways (see below).  These kinds of  API abstraction layers are sometimes called digital twins.

A difference needs to be made between greenfield and brownfield IoT devices. Greenfield devices are those that have been recently manufactured with cybersecurity in mind. They have full cryptographic capability. Brownfield devices are legacy devices, such as PLC controllers, that were deployed with different (not IoT) security principles in mind, if at all. Brownfield devices should be shielded behind an edge gateway. 

Trusted identity and cryptography

A key approach to improving security is to ensure that every component in an IoT network is a trusted identity with authentication and authorisation protocols in place. Having an identity, such as an IPV6 address, is not the same as being trusted. A key to trust is to have a cryptographic root of trust which authorises key gateways throughout the system, as shown below, including laterally to third party device vendors, operators and service providers.

Source: Entrust Datacard, see webinar link below.

As nodes in the network are added, the root of trust signs in the root key of subordinate certificate authorities (CA) creating a trusted zone and assign trust out to the field devices.  After that, the online connection with the Root of Trust is not required. The sensing and actuating devices themselves may not have the processing power to handle certificate/identity revocation processes so the aim is to put these processes as close to the IoT devices as possible. Any device that can handle cryptographic processes becomes a trust anchor and is authorised/trusted to send data, issue commands and accept commands. Generally, these devices have secure boot protocols with cryptographically code-signed firmware.

The service gateway issues certificates to the edge gateways and manages policy. The edge gateway accepts identities and actually controls the addressability to the IoT device.  The IoT devices themselves usually only talk to the edge gateway, whereas the service gateway talks to the cloud. It will also speak to programmable APIs that are accessing it. 

One advantage of the use of edge gateways is to allow sophisticated cryptographic algorithms to be implemented and upgraded. A key issue for any system today is that many older algorithms are no longer sufficient to provide adequate security. It important to not only use the best possible cryptography so that it will be adequate for up to 10 years but also have the flexibility to be upgraded as required. Many IoT vendors believe that using a password hard-coded into firmware is good enough. However, the mirai botnet has proven that stronger forms of authentication are required. IoT practitioners need to analyse the security requirements and question whether solutions such as symmetric token strong or a dynamically-generated key (that is not managed and will never be revocable) are sufficient or if a fully-managed cryptographic identity is required. 

IoT systems can also have a Hardware Security Module (HSM) which is physically isolated and very secure. The HSM holds and issues the private keys which form part of the cryptographic identity of devices throughout the network. As part of the process of verifying that devices issuing and receiving authentication challenges, validations services are required. Two common enterprise IT validation services are OCSP and CRL but there are many more. 

Safe failure

An important concept in industrial control systems is to ensure that devices that have been compromised fail in a safe manner. The concepts around this are set out in IEEE 1609.2 which is actually an automotive standard. The aim is not to instantly revoke certificates or digital identities of an automobile or its parts (e.g. brakes) which could cause a collision. Similarly, it would not normally be ideal to just instantly stop a pump or an actuator from functioning which could cause an industrial safety issue or unnecessarily affect up-time and reliability. IEEE 1609.2 outlines a way of compartmentalising misbehaving devices in such a way that they won't cause an issue.

Relevant standards and regulations:

For detailed instructions on how to implement security for IoT, the general approach is to reference the wide range of standards available on the topic. The main standards and guidelines of relevance are:

• There is a product called Security Public Domain Standard, IPSec looking at security top to bottom, from the network at a packet level authentication and encryption so that the packets are sound and have not been interfered with and it maintains integrity. 

• Underwriters Laboratories released the 2900 Series of Standards in April 2016. This is primarily for gaining UL certification for IOT products. UL have a strong history in certification of electrical products and has extended into the cyber security sphere to accommodate IOT.

• NIST Special Series 800-53, is recommended for government and corporate security

• FIPS xxx for PCI DSS -- this is the Payment Card Industry Data Security Standard and used as the US Federal Information Processing Standard. This is important if the system the IOT device is embedded in collects payments.

• ISO 27001 – The international standard on general Information Security Management

• Information Security Manual (ISM) for Australian Government(s)

• ISA/IEC 62443 –, primarily for industrial control systems

• The Industrial Internet Consortium has published an Industrial Internet Security Framework aimed at the application of IOT systems in industry.

• Strategic Principles for Securing the IoT published by the US Department of Homeland Security

• Online Trust Alliance as a ten point checklist for IoT device security.

Other organisations that have roles to play in IOT security include:

• IEEE
• Online Trust Alliance
• Open Connectivity Foundation
• OWASP (Open Web Applicaiton Security Project)
• IPSO Alliance
• Internet Society
• Thread

News items

• Zigbee vulnerabilities
•  

Sources:

• Presentation by Ed Custeau, Security Specialist at Spiral Systems, titled Cybersecurity and the Internet of Things

• Presentation by Michael O'Flaherty, Security Consultant, UXC Saltbush titled Picking locks with a blowtorch – IT Security in age of the IOT 

• Presentation by Jason Soroko, Manager - Security, Entrust Datacard titled Ensuring a Trusted Internet of Things