Keep Your Edges Secure

Edge computing is game-changing for industrial environments, but is not without significant security risks.

By Peter G. Allor, Honeywell Connected Enterprise

The promise of edge devices and the ability to move computing to them, while having connectivity to cloud assets, has never been brighter. The resultant benefits of being predictive, extending the work force, and delivering efficiency to operations makes it a must-do consideration. It is how we, as organizations, need to be effective and deliver to our stakeholders.

Like all promises of change, we can expect some common challenges and weaknesses. We put our operations at risk while moving or upgrading from one operational construct to another. From the corporate board to the worker in the plant, from the organization changing their operations to the suppliers and vendors providing the necessary tools, we all need to address these risks with diligent security implementation.

Worker awareness, at all levels, is needed to understand that it only takes one person to place the entire system at risk. Everyone needs to be aware of the importance of spotting and addressing insecure configurations and devices or systems as we work on these daily. This is not a one-and-done approach.

Edge Importance

The edge is a boon for many industrial operations in today’s economy. It has allowed plant expansion and reduced repetitive tasks, leading to improved safety and reduced costs.

Edge is the traditional domain of the operations technology (OT) department. Over time, we extended the workforce by adding communications paths from the edge device to management interfaces and then over the internet using TCP/IP. As our understanding of operations expands, we’re learning to implement ever-increasing capabilities to manage, interpret, and analyze the generated data.

Mixing OT and IT

Let’s address an area of confusion that is creeping into the lexicon. IoT generates many concerns in today’s threat landscape as it is synonymous with a wide range of attacks and lack of protections. With expectation that, by 2020, there will be more than 5.8-billion enterprise IoT devices deployed, one can see a cause for some security concern. However, IoT is quite different from the Industrial Internet of Things (IIoT) and being able to distinguish between these definitions is probably the most difficult aspect to understand.

So why not describe IoT as simply services for consumers and consumer electronics? Think of personal wearables, or set-top digital-video recorders, or today’s mobile phones. They are fully TCP/IP dependent for their communication mechanism through hard-wire or Wi-Fi systems. These IoT devices are dependent on the consumer to configure and maintain them.

Because they are so easy to use, IoT devices are becoming a portion of “shadow IT devices” deployed in the workplace and are being attached to corporate networks. Many of these IoT devices have a very short market lifespan, compared with an industrial device, and they have little in the way of support from the supplier/vendor. Besides initial setup, there is little action taken by the user for support.

IIoT Devices

IIoT is primarily focused on commercial devices/applications with long use or dwell times, in operation for 10 to 50 years or more. IIoT is normally a part of a system or set of systems working an industrial process with sustained support, a secure development lifecycle (SDLC), and a robust incident-response team from the vendor. With system lifecycles measured in decades versus years, there is a completely different support, security, and operational construct at work. Initially IIoT was established for use on a communication network separate from serial communication to modem, radio (high-frequency), cellular, and later, of IT networks using TCP/IP.

Even within IIoT, there is a spectrum of what is doable when it comes to security and configuration changes. Looking at a device that has been in use for decades, you will most likely see that it was originally part of OT serial communications. Later it became attached to the IT network over TCP/IP. That was a boon in being able to manage devices over broad areas. What legacy devices are missing is the ability to be updated over the air, and to have a changeable user identity (UID) and password. In essence, legacy OT does not have the ability to make system-wide changes or quick changes, if at all.

Devices manufactured in the past ten years or so have likely been capable of being attached to the network, simplifying operations and networking. They normally allow UID and passwords to be changed, however, in day-to-day operations. This is not done consistently. This one option of being able to change access to the device and network would be a boon to securing our operations and, at the same time, of course requires further security considerations.

Connected devices now in design and coding, benefiting from the use of the IT world’s Secure Software Development Lifecycle (SSDLC), are able to incorporate Secure-by-Design and Privacy-by-Design constructs. Extending my example above for legacy and today, the ability of a software industrial manufacturer or an information-technology vendor to issue a product with a user ID and password requiring change on deployment and configuration, and to follow change policies from an organizations’ identity and access-management baselines, allows better control and security postures.

Being able to update code over the wire/air changes the entire operational picture for an industrial plant. In turn, this allows better oversight through single-pane-of-glass approaches and consolidation of operations to extend efficiency. Hence a connected IIoT is way ahead of consumer-focused IoT on security. Everyone needs to understand these two differing approaches as the explosion of interconnected devices continues.

OT, IT Vulnerabilities

So what is the downside? As we all design and employ OT devices, we will see that our techniques and coding can introduce errors and vulnerable conditions. Rigor in development and in deployment configurations, and operations safeguarding, are how we need to protect against these risks.

SSDLC requires adjusting the entire development process and inserting education, security tools, and trained security personnel to support and enhance the engineering teams. SSDLC is a process with tools and reviews, with hard work by all to release secure products. As the NIST Cybersecurity Framework (NIST, Gaithersburg, MD, nist.gov) points out, organizations also need to be ready with an incident-
response process to accept and fix issues as they are reported or discovered.

For older code that is already in industrial networks, we have to apply controls through segmentation, access control, and in protecting the data across the entirety of the operation. Don’t forget about the vendors with access to your networks. Allow them access only as necessary, and then only to the extent required to do the work. Deploy security controls such as secure remote-access solutions to log, record, and secure sessions.

Many suggest that their security is fine because they are on a serial-only connection. In theory, that will work. However, in practice, I often see challenges as the out-of-band connections through microwave, dial-up modem, high-frequency radio, and cellular make a circuit, and then the attacker is in. So the convergence and overlap of communications paths forces us to look again at our configurations. Serial by itself will not be the protection. We have three things to protect in these situations: the data itself, identity and access to the data, and the device holding the data. This requires that we form a risk-based approach as well as safeguards for the data and the industrial-automation systems protecting the same.

Edge computing, with its ability to provide efficiency for industrial operations and reduced workloads, is well worth our attention, notwithstanding the security challenges. It is incumbent upon every person involved to address and employ secure practices. The attackers rely on our inability to effectively close openings and will take advantage when we are not diligent. Done correctly, we can quickly realize the promise of edge computing. EP

Peter Allor is the chief security officer for Honeywell Connected Enterprise, Atlanta (Honeywell.com) covering cloud platform, applications, and edge devices. He is responsible for the secure software development and deployment of HCE products and the security operations and monitoring of those products in the cloud. He manages the Product Security Incident Response Team and represents Honeywell in incident-response forums. such as ICASI (icasi.org) and FIRST (first.org).