Security in IoT

If you are looking for a cyber-physical security challenge then look no further than an IoT deployment.

What is IoT

Let us start by a very dry defintion of what IoT is. According to IETF, “The Internet of Things is the network of physical objects or “things” embedded with electronics, software, sensors, and connectivity to enable objects to exchange data with the manufacturer, operator and/or other connected devices.”

NIST have a better defintion; “The Internet of Things (IoT) refers to systems that involve computation, sensing, communication, and actuation (as presented in NIST Special Publication (SP) 800-183). IoT involves the connection between humans, non-human physical objects, and cyber objects, enabling monitoring, automation, and decision making.”

Is there a reference architecture?

Although there is not an all-encompassing IoT architecture in place, there are some key components and characteristics that are shared across most IoT deployments;

• Endpoints: devices capable of sensing and/or performing an action
• Sensors/actuators: key building component of the IoT ecosystem, generating data from its environment
• Connectivity: communication between IoTs to an IoT platform or from an IoT platform to other systems
• Data generation and sharing: fundamental to the concept of IoT is the ability to produce and provide data
• Enabling technologies: typically, cloud-computing technology that provides services such as storage, analytics, AI/ML, etc.
• Data driven insights: the key reason behind implementing an IoT. To use information gathered to make observations or to act
• Security: critical to the business success of IoT as well as to the privacy and safety of consumers

There are several bodies and organisations who have released their own reference architectures. Of note, are the ISO/IEC 30141 – shown below – and Microsoft Azure IoT reference architecture which can be obtained here.

The ISO/IEC reference architecture defines the following six domains;

Physical Entity Domain (PED): all physical objects subject to sensing and controlling in a given IoT system and the primary environment in which an IoT system is responsible for tasks or functions such as monitoring, sensing, and controlling

Sensing and Controlling Domain (SCD): consists of IoT devices, sensors used for sensing (digitising) physical objects state or characteristics, and of actuators that control physical objects. It provides critical information about the given environment to all the other domains of an IoT system. In the SCD, IoT devices depend on network communications of different types such as limited range, low power networks. Such types of network communications are often called proximity networks to refer to all local connections to IoT devices. It is common for proximity networks to use specialised protocols suited to the specialised nature of these networks. IoT Gateways connect networks of different types, typically between the proximity networks and the WANs.

Operations and Management Domain (OMD): represents the collection of functions responsible for provisioning, managing, monitoring and optimisation of the systems’ operational performance in real-time. System operators and managers are the actors of the OMD maintaining the overall health of IoT systems.

Application Service Domain (ASD): offers business-driven services to IoT Users and contains all service providers involved in an IoT system. Also, where alarms, notification, or actions are triggered through several defined business rules.

Resource and Interchange Domain (RID): interacts with external to the IoT system entities, applications, services, and systems in terms of resources. The service providers interact with external organisations, such as other IoT systems and platforms via the RID.

User domain (UD): consists of the stakeholders and actors of an IoT system.

IoT Security

NIST has identified three high-level considerations that may affect the management of cybersecurity and privacy risks for IoT systems;

1. Many IoT devices interact with the physical world in ways conventional IT devices usually do not. The potential impact of some IoT devices making changes to physical systems and thus affecting the physical world needs to be explicitly recognised and addressed from cybersecurity and privacy perspectives.
2. Many IoT devices cannot be accessed, managed, or monitored in the same ways conventional IT devices can.
3. The availability, efficiency, and effectiveness of cybersecurity and privacy capabilities are often different for IoT devices than conventional IT devices

In addition to what NIST has identified, there are other key challenges associated with securing IoT systems. These include lack of standards, the scale of single IoT deployments, the number of stakeholders involved, Complexity of the ecosystem, Legal and regulatory compliance, Liability and uncleared demarcations, Lifecycle updates (SOTA and FOTA (Software/Firmware update over the air)) and Security awareness among IoT manufacturers.

In June 2019 NIST released its Considerations for Managing Internet of Things (IoT) Cybersecurity and Privacy Risks whitepaper. In it, cybersecurity and privacy risks for IoT devices are laid out in terms of three high-level risk mitigation goals:

1. Protect device security. In other words, prevent a device from being used to conduct attacks, including participating in distributed denial of service (DDoS) attacks against other organisations, and eavesdropping on network traffic or compromising other devices on the same network segment. This goal applies to all IoT devices.
2. Protect data security. Protect the confidentiality, integrity, and/or availability of data (including personally identifiable information [PII]) collected by, stored on, processed by, or transmitted to or from the IoT device. This goal applies to each IoT device except those without any data that needs protection.
3. Protect individuals’ privacy. Protect individuals’ privacy impacted by PII processing beyond risks managed through device and data security protection. This goal applies to all IoT devices that process PII or that directly or indirectly impact individuals

These goals are to be mapped on to the NIST cybersecurity framework presented below;

But what if you do not wish to follow the NIST guidelines, what will you do then? Lucky for you, the IIC has also published a great IoT Security framework. The document titled Industrial Internet of Things Security Framework, introduces the concept of Trustworthiness. The Trustworthiness of an IIoT system is defined by the IIC as the degree of confidence one has that the system performs as expected in respect to all the key system characteristics in the face of environmental disruptions, human errors, system faults and attacks. A key attribute of this model is the convergence of IT and OT (Operational Technology) Trustworthiness.

Whether you choose the NIST, the IIC or your own framework, you will need to map it to an IoT Security Governance model. One such governance model is shown below;

IoT Security Strategy: It should cover topics such as training, solution architecture, associated vulnerabilities, threats, risks, risk management plan, etc. aross both OT and IT

IoT Processes: Should include IoT operational readiness plan, security audits, onboarding protocols, etc.

Data strategy plan: policies and procedures for data collection, retention and sharing, data privacy, security, encryption, and data compliance and sovereignty

Monitoring and reporting plan: monitoring device status and performance, setting up alarms and notifications, and ensuring regulatory and policy compliance

Lifecycle management: should include software patches and firmware updates, assets management, assets disposal

Good practices: should include industry collaboration, transparency, security standards and best practice adoption

What next?

This is the expensive bit. This is where people, processes and technology (yes, that means buying a whole lot of security stuff) come together in shape of one massive bill which if spent right, should provide you with protection against most – never all – attacks. Of course, you have the other options of accepting and transferring risk, which can be very valid depending on the type of your IoT deployment and your business model (and other factors).

references: IIC, ISO/IEC, ISC2, NIST, Seriot