The Keys to Securing Industrial IoT (IIoT) Environments
According to the latest research, the total number of connected IoT devices will reach 75 billion by 2025, with almost 30% of them installed in industrial environments. Despite the technical challenges, a vast number of companies have embraced Industrial IoT (IIoT) solutions as a way to enhance their operations. But, as they quickly discovered, one of the big problems with this approach is that these new technologies greatly increase the industrial environment’s exposure to cyberattacks.In this blog post, we will discuss the ways industrial companies should approach the security challenges inherent in the IIoT market, as well as the solutions available to them. Specifically, we will focus on applying the secure-by-design approach to endpoint devices in the industrial market.
The Benefits and Challenges of the New IIoT Environments
The term Industrial IoT covers all the hardware devices that work together using internet connectivity with the goal of enhancing various industrial processes. IIoT provides intelligent technology insights that can drive significant improvements in efficiency, productivity and revenue. The most significant Industrial IoT sectors are manufacturing, Oil, Gas, electricity, water and transportation. One of the most important processes in the Industrial IoT market these days is the convergence of information technology (IT) and operational technology (OT). The latter refers to systems such as industrial control systems (ICS), supervisory control and data acquisition (SCADA), programming logic controllers (PLC), and human-machine interface (HMI). The key here is that this convergence does not just merge two technologies. Instead, it merges two entirely different worlds which also requires completely new ways of thinking. Successful IT/OT convergence will result in better automation, more optimized performance, significant cost savings, and full visibility across the entire operational process. The downside is that while these benefits are significant, the security risk that is created in the process is also significant.
The Issues Underlying the IIoT Security Challenge!
There are multiple issues that contribute to the severe security challenges in today’s IIoT environments, including:
Lack of risk mitigation
Operators and engineers in the OT environment typically do not have a deep understanding of complex security principles, while IT security specialists typically are not very familiar with OT environments. For this reason, only a few mitigating techniques are being used and in general, there is no coherent strategy for mitigation.
Multiple component vulnerabilities
Many, if not most, industrial systems were not designed with cybersecurity in mind because they were meant to be used only in closed networks. The shift to open networks has therefore exposed industrial companies to many vulnerabilities that weren’t previously on their radar.
Lack of endpoint visibility
To ensure that endpoint devices cannot be exploited, security teams need to achieve a critical level of visibility. The problem is that industrial environments only get more complex and less transparent as you add more isolated point solutions for endpoint security which are not in sync with each other. An additional problem is that existing IT tools are simply unable to adequately monitor OT services.
In many OT environments, applying security updates may be challenging since they need to be performed during full downtime. In addition, traditional update methodologies such as Over-The-Air (OTA) are not always available in industrial environments. As a result, manufacturers that run OT network rarely patch their components.
Industrial devices communicate over networks by using specific industrial protocols, such as Modbus, Ethernet/Ip, DNP3, PROFINET, and more. These protocols often fail to ensure proper security and do not employ any authentication, authorization or encryption methodologies.
Impact of critical security incidents
When industrial systems are hacked the effect can be catastrophic - loss of profits, data theft, major equipment damage, and even bodily harm. In some critical scenarios, hacks can even end up completely cutting off power, gas or water distribution.
Solving the IIoT Security Challenge
There are three complementary approaches to improving industrial IoT security:
- Adopting risk and threat management processes specific to your industry environment.
- Utilizing asset management tools to discover and identify relevant industrial assets, including the use of passive monitors where feasible.
- Implementing endpoint device security methodologies based on the secure-by-design approach adapted for endpoint devices.
All three need to be taken in order to ensure IIoT security but, for the purposes of this blog post, we will be focusing on how best to implement the third approach.
The first step towards securing IIoT devices is to run a risk and threat analysis to help determine whether they need to comply with relevant industrial standards. For example, in the Industrial IoT market ISA/IEC-62443 is one of the most important standard series, providing a framework to address current security vulnerabilities in the industrial area. Many industrial organizations demand compliance with this specific standard.
The points below follow the recommendations of ISA/IEC-62443 and the Industrial Internet Consortium (IIC) which is a global non-profit organization founded in 2014 to accelerate the growth of the industrial internet. For each security building block recommendation, we will provide examples of relevant security requirements and explanations on how to mitigate those concerns.
1. Endpoint Identity
Industrial devices must support acceptable authentication methods for user identification in order to provide Access Management and User Control functionality for all their services. For example, devices must support Public key infrastructure (PKI) support which is an arrangement that binds public keys to identities using a Certificate Authority (CA).
As an example, let’s look at the TLS certificate verification requirement, which is one of the critical security requirements in the Endpoint Identity category.
The TLS security requirement demands that TLS certificates must be verified on all the servers with which the device communicates. TLS or SSL connections that are not verified for authenticity using the server certificate are susceptible to Man-in-the-Middle attacks since the client cannot know whether it is connecting to a trusted server or to a malicious attacker impersonating that server. Applications and client services cannot just rely on URLs or fully qualified domain names, for instance, because the DNS services may also be compromised. When verifying the server certificate, the certificate signature algorithms and validity periods need to be checked. Self-signed certificates by unknown parties should not be accepted as root CA certificates. Devices that act as servers must include server-side certification support, providing an option for secure and authenticated communications from the client side.
2. Secure boot
Secure boot is a fundamental security mechanism which ensures the integrity and authenticity of running code. The idea behind it is that each piece of code that runs on the device, starting with the first code in ROM or even the bootstrap page in hardware, verifies the integrity and authenticity of the next piece and invokes its starting address.
Secure boot involves the following:
- The device code is organized in stages (commonly bootloader, OS kernel, and so on)
- The first stage uses public-key cryptography to verify the second stage
- The first stage code, and the keys used, should be non-modifiable
- The process can optionally continue to additional stages
As an example, let’s look at the U-boot integrity requirement. This is one of the critical security requirements for Linux based systems and demands that the U-Boot verifies the OS kernel before loading it.
One common way to enable the U-Boot integrity mechanism is:
- First, allow support of the Flattened Image Tree (FIT) image building. The monolithic FIT image includes all the images needed to boot a system and an option for image hashing.
- Secondly, configure the verified boot parameter in the U-boot configuration file.
- Finally, sign the kernel image. The recommended cryptographic algorithms for this purpose include RSA-2048 with SHA-256 or higher, or ECDSA using the P-256 or P-384 curves with SHA-256 or higher.
3. Cryptographic services
Industrial devices must use and implement cryptography across transport protocols, storage and applications. Using weak or non-standard security policies exposes communications to the risk of impersonation, eavesdropping and tampering, which could result in device takeovers or in the submission of falsified data to network services.
As an example, let’s look at the OPC-UA (Open Platform Communications United Architecture) security requirements. OPC-UA, a data exchange standard for industrial communication, is one of the most widely used protocols in the Industrial IoT market. One of the security requirements for this protocol is that the OPC-UA server needs to use strong cryptography policies.
The OPC-UA protocol includes many built-in security features that need to be configured correctly. One of the most critical ones is the SecurityPolicy configuration element that defines the cryptographic functions that should be used on a connection during authentication and throughout the session in ongoing message exchanges.
The OPC-UA protocol offers multiple profiles for configuring SecurityPolicy.
Basic256Sha256 is the most secure one and thus the recommended setting (other profiles include None, Aes128-Sha256-RsaOaep, Aes256-Sha256-RsaPss, PubSub-Aes128-CTR, PubSub-Aes256-CTR, Basic128Rsa15, and Basic256).
4. Secure communications
Industrial devices must support communication protocols with authentication and cryptographic protection, and implement a local endpoint firewall for network whitelisting and access control. The reason for this is that communicating online without authentication, encryption and integrity protections can result in spoofing, information disclosure and tampering. This means that all communications could be read, modified and even injected, which can result in device hijacking, and from there to device damage.
As an example, let’s look at a requirement for Modbus VPN. Modbus is a widely used industrial communication protocol standard that enables communication among many devices connected to the same network. Since its protocol specification is openly published, it can be used royalty-free. The basic Modbus protocol does not employ any authentication, authorization, or encryption.
The requirement for 'Modbus VPN' demands that endpoint devices provide VPN tunnelling support on connection to remote master/slave Modbus components such as SCADA systems. To complement this security requirement, a VPN server like OpenVPN or StrongSwan need to be integrated into the device.
The security level of these VPN servers strongly depends on the way the vendor integrates them into its device, and both can be tough to implement correctly. When using VPN servers, how-to’s and good practice recommendations from known security frameworks should be carefully followed to help ensure that the services are correctly configured.
5. Continuous monitoring and event management
Industrial devices must support real-time and continuous monitoring. The best way to do this is by using embedded runtime agents that are tailored for each device based on a thorough analysis of its firmware binary. This focuses the monitoring on the threats that each specific device is exposed to, and ensures that the resources the agent needs to provide runtime protection, including CPU, storage and memory, do not impact the device’s performance or functionality.
In addition, important and security-related events that occur on the device need to be audited and logged, including authentication errors, authorization errors and discrepancies found during integrity verification. For example, the log auditing security requirement demands that logs and alerts be generated for critical security-related events.
It is recommended to record the following details for each event:
- Date and time of the event (preferably using UTC)
- The component where the event occurred (host and software package)
- Type of event (for example, authentication error)
- Subject identity (device hostname or an application)
- The outcome of the event (success or failure, if applicable)
On the Road to Optimal Security for IIoT Environments
While there are many benefits to the industrial IoT world brings, this technological jump has also created many security concerns that need to addressed when it comes to critical connected devices. In addition to security solutions that are focused on the network, companies in this market also need to adopt a secure-by-design approach for endpoint devices.
At VDOO we are currently seeing major industrial vendors significantly ramping up their investments in adopting the secure-by-design approach for new products. This process has them facing multiple challenges including:
- Scaling up product security functions across multiple business units
- Translating standards such as ISA/IEC-62443 into a list of security requirements
- Finding best practices for designing and implementing more secure industrial devices
- Verifying whether specific requirements have been properly Implemented
- Finding references for similar requirements in leading standards and regulations
- Mitigating each problem without access to experienced security developers
Is your company facing similar cybersecurity challenges? Are you looking for more insights into the IIoT market? Please don’t hesitate to reach out to me on LinkedIn!
Share this post