Applying security principles to building automation
Article By : Wouter van der Beek
Building automation is shifting from proprietary networks to IP networks, creating a large impact on network management as there will be an influx of Building IoT devices on the network...
Building automation is shifting from proprietary networks to IP networks, creating a large impact on network management as there will be an influx of Building IoT devices on the network. These devices will need to be securely added to the network and then provisioned in the Building Management System (BMS). This process will involve Information Technology (IT) administrators and the provisioning in the BMS system will involve Operational Technology (OT) administration. To reuse an existing, managed IT network, the devices on that network need to be evaluated by IT managers before onboarding to the network, since being on the same network can cause disruption for the other services that are running on the same network. Using the same IT network for IoT devices will avoid duplicating a second network in the building, with the additional benefit of reusing the existing operational infrastructure to manage the devices.
It is for these reasons that the same security requirements should be applied for Building IoT devices as for other devices managed by the IT department.
The initial step is to get the Building IoT device onto the network, usually on a secure, segmented virtual-LAN (VLAN) to provide a controlled, homogenous environment for the BMS system. With the number of Building IoT devices increasing, the management steps need to be automated as much as possible. The introduction of a new type of device will be a manual, albeit assisted process, however, the introduction of a second device of the same type must be completely automated. Furthermore, there are different network layers involved in getting on the network, for example the process might be different for Wi-Fi, mesh (e.g.Thread), and wired Ethernet. It’s even possible to re-use the wires from a legacy BMS for IP by using single-pair Ethernet (SPE)!
Although these steps are not specified by the Open Connectivity Foundation, the OCF is interacting with the relevant organizations to align them so it just works when used under the OCF Core Framework. OCF is one of the leading IoT standards, producing the ISO-30118 series of specifications, which essentially defines a secure session management layer that can be leveraged by IoT applications as a form of device “middleware” that allows you to standardize everything below the application protocol, while binding to whatever IP-based physical layer you desire. This allows legacy BMS protocols to quickly migrate to IP networks. Best of all, OCF specifications are enabled in the IoTivity open source project, meaning a BMS device manufacturer can start with compliant code, rather than interpreting specifications.
To make an IoT device part of the operational environment, the device needs to be configured. An important security aspect of this includes making sure the strongest available security mechanisms are used to join the secure domain. To achieve strong security only Datagram Transport Layer Security (DTLS) security methods are allowed. The clients and servers within the same secure domain can securely interoperate due to having proper security credentials provisioned, which allows them to set up the secure communication channels when communicating with each other.
OCF devices use Public Key Infrastructure (PKI) certificates for onboarding, giving the same level of security as used for internet banking and other highly sensitive environments. A PKI is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates, and manage public-key encryption. OCF provides a PKI service based on the OCF root certificate to enable secure interoperability for vendors of all size, but also allows large manufacturers to use their own PKI infrastructure so they can embed the certificates at the time the chip is created, further streamlining the provisioning process. Because PKI certificates provide the device with unique, verified identity, the private part of the keys should be stored securely on the device in specialized hardware that prevents unauthorized access.
The unique identity provided by PKI certificates allows the granular access to the device’s functionality and resources based on who is making the request, for example role-based access control (RBAC) can be set up. This is achieved with Access Control List (ACL) mechanisms. ACLs can be set up so that a set of users will have the same role, thus accessing the same set of functions implemented in the device. A different role can be granted access to a different set functions on the device, and so users can be created with access defined by the allocated role.
Because IoT devices will be part of an operational environment, in most cases the manufacturer must work in concert with the OT manager to manage upgrades, because the manufacturer alone may not be aware of critical activities and time periods that require uninterrupted service. Also, the OT manager will often need to evaluate upgrades in a lab environment before applying the update. To address these issues, the manufacturer needs to supply a software upgrade package and both the IT and OT managers will be responsible for applying the software update.
Manufacturers will have to indicate when the IoT device will no longer be serviceable. When the End of Service/End of Life is known, the IT/OT manager will have to find replacement devices with at least the same capabilities so that the operational state of the building is maintained. They will also need to have a process in place to decommission the devices, revoking the identity/keys and removing sensitive information such as network credentials and application data.
Next to the security of the device itself, keeping the network secure is also of critical importance. The devices perform a single task, and derived from the task, the devices can indicate their intended use of network resources. For example, if a router or switch knows which TCP or UDP ports an IoT device will be using, and anomalous traffic is subsequently seen on other ports, the device can be quickly quarantined by the network. In addition, the expectation of only proximal traffic versus only cloud-bound traffic can be indicated, further strengthening anomalous traffic detection efforts. Or, in other words, simple devices that have the intent to act only on the local network should not be able to contact any cloud-based system.
Most of these security requirements are high-level and can be implemented with different technologies. The Council to Secure the Digital Economy (CSDE) is working with other relevant organizations to establish common security requirements, this resulted in the document “The C2 Consensus on IoT Device Security Baseline Capabilities”.
In addition to having the devices and the IP network secured, a business organization must have processes in place to manage security. As an example of these procedures, the National Institute for Standards and Technology (NIST) has defined a cyber-security framework. This framework describes a continuous cycle of steps to identify and mitigate issues with security.
The IoT devices on the network will be part of such a framework, and the OCF has created its own incident response plan to deal with security breaches. This plan analyzes root causes and takes action on the OCF-sponsored open source implementation called IoTivity, and, if needed, will result in changes to OCF specifications. The OCF incident response plan can be part of the overall cybersecurity processes that are executed by a business.
— Wouter van der Beek is a Technical Leader at Cisco Systems