Security issues impact all types of digital systems. Intrusions or breaches constitute a nuisance at the least but also can compromise data or trigger unauthorized actions. Resulting problems for end users vary depending on their organization and systems. For industrial automation users, cyberattacks can lead to ruined product, damaged equipment and safety hazards. The potential cost of poor controller cybersecurity is clear.
As industrial operations technology (OT) systems evolve and cyber-attackers adapt, security requirements change. Greater integration of OT systems with IT systems and Internet connectivity create more exposure to cyberattacks. Integrating security provisions into automation system designs ─ and continued vigilance ─ are key to defending against these types of threats. As Bruce Schneier, a noted cryptographer and computer security professional, wrote in 2000, “Security is a process, not a product.”
To address security’s complex, changing nature, users must understand security risks, the digital environment and the available security tools. Security experts recognize several elements of system security, including physical security, network security and policies and procedures.
The ultimate security of your industrial automation system depends on you, but let’s look at network security features built into certain automation products, along with best practices for setting up a secure system network.
Security basics
Devices and practices for industrial automation have evolved over many decades, resulting in a wide spectrum of available products. Of interest here are applications where designers would typically deploy individual controllers, even if many of those controllers may be used in parallel as peers.
Products used in this space are digital controllers capable of being networked via Ethernet and include:
- Smart relays
- Programmable logic controllers (PLCs)
- Programmable automation controllers (PACs)
- Industrial personal computers (IPCs)
- Edge programmable industrial controllers (EPICs).
The first three products are deeply rooted in the origins of industrial automation. Conceived prior to the proliferation of PCs and before cybersecurity even existed, many early generations of these products remain in service today. While the latest iterations are updated with current computing and networking technology, these products are generally limited to offering a dedicated computing environment tailored for industrial control.
In contrast, an IPC is simply a robust version of a PC, which end users can outfit with various control software and communication elements to achieve industrial control.
The last product, an EPIC, is a newer generation of industrial controller, packaged like a PLC and offering similar real-time control functionality, but with many PC-like features and IT-friendly communication advantages added.
Enabling digital communications for all these products is essential not only for configuration and maintenance, but also for incorporating complementary products like human-machine interfaces (HMIs) and other intelligent devices.
Best practices for proper network security design of industrial controllers requires careful consideration of the following areas:
- Operating systems
- Network interfaces
- User access
- Data communications.
Operating systems
Any industrial controller’s operating system (OS) defines the extent of its computing and input/output (I/O) interfacing abilities. PLCs and PACs typically use dedicated or embedded closed-source OSs tailored to the required fast-acting logic solving. IPCs commonly use closed-source OSs also, most often Microsoft Windows. Another OS option is to use a variant of open-source Linux. Some IPCs use Linux, and many EPICs use Linux to take advantage of PC-like capabilities.
Counterintuitively, open-source OSs are often more secure than closed-source versions. The same worldwide high profile that helps a closed-source OS like Windows gain such market acceptance also makes it the target for cyber-attacks. And while the closed-source embedded OSs used for PLCs are relatively obscure, the emergence of Stuxnet almost a decade ago demonstrated that commercially available industrial control platforms are viable targets for cyberattacks.
A benefit of open source is its crowd-sourced nature. The large number of developers involved ─ far more than a traditional closed-source industrial controller manufacturer can employ ─ allows quick reaction to address vulnerabilities.
When open-source OSs are used for industrial applications, they should be custom-built for a specific device and include only the packages the device requires. This streamlining reduces the ways it can be attacked, also known as reducing the attack vectors or the attack surface.
In addition, the purpose-built OS for an industrial controller should be cryptographically signed by the manufacturer. Only vendor-approved OS builds should be accepted by the controller, guaranteeing the build’s origin and precluding unauthorized OS code alteration.
Network interfaces
Modern industrial controllers rely heavily on commercial Ethernet, although many specialized industrial fieldbuses remain in use. Ethernet for industrial controllers is provided by physically wired network interfaces. Wi-Fi devices may also provide connectivity.
For any networking, it is important to understand the concept of a trusted network as opposed to an untrusted network. A trusted network is usually within a private facility and may be an IT-managed network, where all users with access are known. An untrusted network is any network where those who can access it are unknown, like the Internet.
A router is a network device configurable to route traffic between any two networks. Many people are familiar with routers for home use, with these devices handling traffic between the Internet network and devices on the home network. These routers move data between these two networks.
Industrial applications, on the other hand, call for controllers with multiple independent network interfaces, so that trusted and untrusted networks can be kept separate. One network interface can be assigned to the local trusted network, and another to the external untrusted network. These interfaces must be non-routable, so that no external attacker can connect to the trusted network from the untrusted network (Figure 1).
Another crucial networking concept is a firewall, which provides security by preventing unsolicited traffic from accessing the network, device or host. Typically, local device-originated outbound connections are considered trustworthy and therefore allowed, as are the associated inbound responses. However, other inbound connection attempts from outside are rejected, although the firewall may be configured for certain specific ports to be opened and allow inbound traffic.
An industrial controller should have its own firewall and provide the means to configure it. For industrial applications, the trusted network interface will need the ports associated with control logic, I/O connections or other industrial protocols opened. But the untrusted network interface should typically have all ports blocked except for a secure port allowing authenticated users to access the controller over an encrypted connection. Best practice is to open only the ports specifically needed and to block all other ports, and for the untrusted network interface to block all ports by default (Figure 2).
Proper network configuration is essential, and it goes hand-in-hand with carefully assigning user access and privileges.
User access
A key feature of modern digital computing ─ whether used on mobile devices, PCs or industrial controllers ─ is the concept of user accounts with assigned access and privileges. Typically, an administrator account must be created initially; it has global privileges. This account must be carefully protected by the owner.
An industrial controller should not offer a default username or password on any account, but instead should require that the administrator select unique credentials upon account creation. Default credentials can be easily obtained and used by anyone, whereas a unique administrator account better protects the controller from nefarious actors. If administrator credentials are lost, the account should not be recoverable, and instead would require a reset of the controller to factory defaults.
The administrator account is used to create user accounts. For an industrial controller, authorized users may be people, but they may also be software services.
Best practices are to create accounts only for the necessary users, grant them only the essential privileges, assign strong passwords and always require authentication for system use. Careful user account management gives the administrator complete and granular control of who and what can access the system, and therefore of who and what cannot (Figure 3).
A common requirement is for offsite users to connect with a controller via the Internet. A secure port that encrypts all data communications and allows only authenticated users to connect can meet this requirement.
Another way is with a separate device on the network capable of creating a secure virtual private network (VPN) tunnel to outside clients or servers. However, setting up a VPN can require extensive involvement and coordination with IT personnel.
A better option is to select a controller with built-in secure VPN tunnel capabilities, giving OT personnel complete control of VPN connections to securely match their needs (Figure 4).
Whether using onboard controller features or site networking devices, best practice for remote connections via any form of untrusted network is to always use a properly configured secure VPN tunnel and to disable it when not needed.
Data communications
The whole point of equipping controllers with network interfaces is to provide data communication connections. However, the main thrust of this article has been how to prevent connections, at least from unauthorized entities. Communications on the trusted side of a controller are relatively simple, and as discussed, inbound connections over an untrusted network should go through a VPN or be blocked. So how do you communicate data if a VPN is difficult to set up? For example, how does an OEM get data needed from machines at customer sites for billing or maintenance?
The answer is to use outbound, device-originated data communication protocols. One such protocol is MQTT, which uses a publish/subscribe model (Figure 5). As pointed out above, outbound connections are generally allowed through a firewall because they are trusted. The controller is configured to publish data of interest to an external central broker using an outbound connection. Remote users connect and subscribe to the central broker in a similar manner. Because the connection originates from a trusted source, it is allowed through the firewall, and responses are allowed in return, safely permitting two-way data flow. All connections are authenticated and encrypted.
Another key feature to look for in an industrial controller is built-in security certificate management. A security certificate basically verifies a machine’s identity to another machine, so an originating machine can be sure it is connecting to the proper destination machine and not an imposter. Certificates can be implemented in various ways and can be generated by the end user or registered through a certificate authority (Figure 6). Industrial controllers should use industry-standard certificate practices, similar to banking and e-commerce sites.
Even with these security provisions in place, there are other best practices to consider.
Other best practices
So far, we have looked at configuration and best practices for system design. However, there also are procedural best practices for improving security.
- Minimum interfaces: The most cyber-secure system is air-gapped and has no interfaces. This isn’t usually practical, but it may be possible if the controller offers an onboard interface. In any case, always remove unnecessary network connections and block unused ports.
- Minimum access: Assign users the lowest possible privileges consistent with what they need to see and do, and require them to log out when inactive – especially administrators. This advice extends to all control system elements, including HMIs, which should be run in read-only kiosk mode whenever possible.
- Development versus production: Restrictions are sometimes relaxed for testing and prototyping. Make sure the controller is completely protected after testing and before being placed into production. Some Linux-based controllers allow users to take advantage of secure shell access (SSH) for developing custom applications. Once development is complete, make sure shell access is disabled.
A secure approach
The best practices outlined in this article are a solid starting point for embarking on any new industrial automation project, or for revisiting one already in service. Good security must be carefully implemented at many levels and is most effective when security provisions are built into automation products, not bolted on. Built-in security features help you implement security quickly with minimal expense.
Every situation is different, and you are most familiar with your applications and network architectures. Built-in network security features for industrial controllers can help you design and maintain a secure system, but ultimately you are responsible for using them wisely in your application and as part of your overall security strategy.
This article appears in the IIoT for Engineers supplement for Control Engineering and Plant Engineering. See other articles from the supplement below.
See additional cybersecurity strategy stories including:
Protect PLCs and PACs from cybersecurity threats
Compensating controls in ICS cybersecurity
Original content can be found at Control Engineering.
Do you have experience and expertise with the topics mentioned in this article? You should consider contributing content to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.
