A practical approach to ICS cybersecurity

• By Gabe Faifman, Lee Neitzel
• Automation IT

Summary

Does ICS cybersecurity have to be complicated? In theory, yes, but in practice, no

By Lee Neitzel and Gabe Faifman

Industrial control system (ICS) cybersecurity can be intimidating. The stakes are high, and the technology is sophisticated. Ask any industrial cybersecurity expert about it, and you are likely to hear that ICS cybersecurity is different from information technology (IT) cybersecurity, that security risk assessments are indispensable, and that cybersecurity discussions are littered with highly specialized terminology. So far, that leaves us where we started, with a seemingly complex problem.

But, does ICS cybersecurity really have to be so complicated? In theory, yes, but in practice, no. From a practical perspective, you can begin building in a layered ICS security approach, often called defense-in-depth, by answering a few basic questions:

• Where can the attacker gain entry or break in to your ICS? Adding security to protect entrypoints is a first layer of defense.
• Once an attacker gains entry, what will the attacker do next? Providing barriers to absorb or deflect different types of attacks adds a second layer of defense.
• What are the ultimate objectives of an attack? Hardening the targeted elements of the system provides a third layer of defense.

This article explores possible answers to these questions and describes common defense-in-depth mechanisms for ICS systems. The selection of appropriate mechanisms for an ICS should be based on a thorough security assessment.

The primary goal of defense-in-depth is to restrict access to the ICS in terms of who has access and what they are permitted to do. Access controls include physical, procedural, and technical means. While perfect security is seldom achieved, the intention is to make it so difficult for attackers that they never try or they abandon an attack after becoming frustrated with attempting to penetrate multiple layers of defense.

Of primary importance for success is both the organization and its people accepting the need for a defense-in-depth strategy. Without conscious efforts to keep systems secure, technical means by themselves will be inadequate. It is much easier to steal a car with its doors unlocked and with keys in the ignition than it is to steal one that is locked with keys nowhere to be found.

Gaining entry to an ICS

The first step in developing an effective ICS defense-in-depth strategy is to determine where the attacker may be able to gain entry to the system. Entry points are interfaces of devices in the ICS that are accessible to attackers, such as communications interfaces and USB ports. Attackers can not only use these entry points to break into an ICS, but they can also use them to attempt denial-of-service (DoS) attacks on the ICS. DoS attacks attempt to reduce availability of the system or its components. Common DoS attacks attempt to crash devices or their software applications. More sophisticated DoS attacks may attempt to shut down equipment or affect physical processes.

The most common entry points in an ICS are human-machine interfaces (HMIs), ICS network interfaces, and device interfaces (figure 1). Each is discussed below.

---

Figure 1. HMI entry points

---

Human-machine interface entry points are devices used within the ICS that have a user interface. They include operator consoles, engineering workstations, handheld devices, laptops, tablets, and smartphones. They are arguably the most commonly used entry points, because every successful login, even by authorized personnel, provides the potential for an attack. Common examples include engineering, operator, and maintenance HMIs.

For an attack through an HMI to succeed, a login session with the ICS must first be established. For authorized users, logging in is often part of normal operation. If unauthorized users can gain physical access to an HMI, they may be able to look over a user's shoulder to observe displays and keystrokes, or even record them with a cell phone. The attacker may then use stolen credentials to log in to an unattended workstation, or alternatively, may be able to hijack a user session if it is left unattended.

Defensive measures: The first layer of defense for HMIs is to attempt to prevent attackers from viewing HMI displays and to keep them from using HMIs to access the system. Protections should include both physical security controls and user authentication mechanisms.

Physical security controls create restricted access areas for HMIs where physical access is limited to authorized users, and physical actions can be monitored and recorded for suspicious and malicious activity. Physical access controls are best supplemented by an active security awareness program that describes what to do, such as challenging unknown individuals and locking the screen when leaving an HMI unattended, and what not to do, such as using unauthorized USB memory sticks.

User authentication mechanisms verify the user's identity. In general, users are represented by accounts that associate user identities with roles, privileges, and permissions. User identities are verified through the use of credentials the user provides to authentication mechanisms.

Credentials usually consist of a user identifier, such as a name, number, or email address, and one or more secrets known or possessed by the user, such as a password, personal identification number (PIN), smart card, retinal scan, or fingerprint. All successful and unsuccessful credential validations, such as login attempts, should be logged. Credentials should be carefully managed using industry best practices to protect against disclosure and unauthorized modification.

It is not uncommon in an ICS environment for an HMI to require the operating system (OS) login that follows startup (boot) of the HMI workstation to persist across operator shift changes. In these cases, all operators use the same OS session to eliminate the need for closing and reopening control system applications and data viewing screens that would occur if an OS logout and login were required.

The identity of the operator, not the identity of the logged-on OS user, should be used when authorizing and logging control system actions. Therefore, a separate login and authorization scheme for control system users should be provided.

It is highly recommended that control system users not be allowed to log in to perform control actions when the logged-on OS user has elevated privileges and permissions, such as those of the administrator or power user. This helps prevent lower-privileged users, such as operators, engineers, and desktop applications that have been infected, from installing software, modifying installed software, changing system settings, or otherwise manipulating protected OS resources.

It is also highly recommended that the built-in OS administrator account be removed or renamed if removal is not possible. Instead of using this built-in account, administrators should be given unique user names without any indication of their administrator status and be assigned to administrator groups. This will make it more difficult for attackers to target well-known administrator accounts.

When selecting user-authentication mechanisms, it is important to provide authentication for all logins. Guest and anonymous logins and user logins to service accounts for server applications should not be allowed. When passwords are used, password policies should be configured for adequate password length and complexity, periodic password changes, and rules against password reuse.

Multifactor authentication, such as smart cards and a PIN, should be used for all HMIs that are in open areas or that can connect from a remote location. For remote access, a secure channel, such as a virtual private network, and an intervening perimeter security device (e.g., firewall) should be used.

Mutual authentication should be used for website and server application logins. Mutual authentication requires websites and servers to additionally provide their identity to the user to protect the user from giving login credentials to an attacker pretending to be the desired website or server. Kerberos is used in Microsoft Windows environments for mutual authentication, while websites often rely on public key infrastructure (PKI) technology. Note that although PKI supports the use of self-signed certificates, their use is discouraged because their authenticity cannot be easily verified.

Finally, ICS OS accounts should be defined and managed independently from other OS accounts, such as plant IT accounts. This is typically accomplished by the ICS having its own user account directory, which is more commonly referred to as a domain (after the Microsoft Windows domain). Further, trusts should be prohibited between ICS domains and non-ICS domains, including those used for demilitarized zones (DMZs). Trusts between domains generally allow users logged into one domain to access a second domain without supplying credentials for the second domain. Plant system users who need to access the ICS should be given their own ICS OS account. All other plant system users should not have access to the ICS.

Perimeter security devices

Perimeter security devices are network security devices used to segment ICS networks from external networks. Perimeter security devices include firewalls and routers (e.g., those with access control lists), and mediate communications between external devices and the ICS.

They can be used to gain entry to the ICS by discovering and exploiting weaknesses in rules that forward authorized messages to the ICS and block unauthorized messages. Entry is also possible if the attacker is able to gain configuration access to a perimeter security device and change its rule.

Defensive measures: Perimeter security devices designed specifically for industrial applications should be used to protect the ICS from external access. Network security devices designed for industrial networks provide visibility and defense against ICS-related protocols and traffic, which are significantly different from traditional IT traffic.

Perimeter security devices should be physically protected from tampering and from having unauthorized devices connected to them. This is often done by placing them in locked closets or locked cabinets and using conduit to protect network cabling.

Perimeter security devices should be configured to allow only communications with devices that are essential to the operation of the ICS. This configuration should explicitly authorize or whitelist inbound and outbound communication paths in terms of their source and destination network addresses, application end points (e.g., TCP/UDP port), protocols, and allowed content. Role-based access controls should be used to allow configuration by authorized network administrators and review of the configuration by authorized maintenance personnel.

Communication paths that are not authorized by the configuration should be rejected and logged, or at least logged if rejection is not practical. When possible, configure intrusion detection capabilities of perimeter security devices to inspect for known attacks and suspicious traffic. Additionally, traffic flows to and from an ICS are predictable, and deviations often are indicative of an attack. Therefore, traffic flows should also be inspected for potential attacks. Lack of an industrial perimeter security device or deficient configurations can allow unauthorized communications to enter and leave the ICS.

Perimeter security devices should be connected externally only to DMZs that reside between perimeter security devices and plant networks, as shown in figure 2.

---

Figure 2. Perimeter security devices should be connected externally only to DMZs that reside between perimeter security devices and plant networks.

---

DMZs are buffers that protect ICSs from being directly accessed by external systems. Perimeter security devices should be configured to allow only DMZ devices to communicate with the ICS workstation networks. All external devices, including wireless workstations (e.g., laptops), should have their communications with the ICS mediated by the DMZ by terminating them in the DMZ, validating them, and then reestablishing them between the DMZ and the ICS.

In addition, remote desktop access to the ICS should require a pair of remote access connections, one from the remote device to the DMZ, and the other from the DMZ to the ICS that is mediated by an ICS perimeter security device. If the remote device is external to the plant, a VPN connection to the plant network should also be used. The perimeter security device should be configured for each remote access connection, and also specify when and for how long remote access is allowed.

Finally, the ability to configure and maintain perimeter security must be controlled and must be performed only from authorized HMIs within the ICS. External HMI access to perimeter security devices should not be allowed. All configuration and maintenance should be controlled by change management procedures, and they should be performed only by authorized network administrators. In addition, backup copies of the configuration should be stored in a secure location.

Administrative connections for configuration and maintenance should use mutual authentication and role-based access controls that limit network administrators to only those operations that they need, such as viewing, configuring, upgrading software, and installing patches. Encryption should be used for configuration. Maintenance sessions and cryptographic methods, such as encryption or cryptographic hashes, should be used for storing sensitive data, such as user credentials, in the perimeter security device.

Once inside, the attack continues

Understanding how various types of attacks are conducted after an attacker gains access is critical to defending an ICS. This understanding will help you to develop customized scenarios of how your ICS can be attacked, often referred to as threat modeling, and add appropriate defense-in-depth safeguards.

Once access has been gained to the system, the attacker generally attempts to misuse, abuse, or corrupt the system with a combination of user interfaces, communications protocols, and untested software (e.g., games and malware). One of the primary objectives of these attacks is to escalate OS privileges to give the attacker control of the device under attack. If an attacker gains control, he or she will have free reign to carry out the attack.

Misuse or abuse of the system can affect the system at two levels: compromising OS resources, such as files, registry entries, and OS user account information, and compromising control system resources, such as set points, alarm limits, historical values, and control system account information. Of considerable concern is the ability of an attacker who has access to OS resources that contain control system data\, such as configuration files and access control lists of the control system. In these cases, the attacker may be able to compromise the control system by tampering with data managed by the OS, even if the attacker does not have control system privileges and permissions.

An example attack begins with a logged-on user copying a file infected with malware through the network, from a USB memory device, or from a CD or DVD. Alternatively, the attacker may find a vulnerability in a communications protocol and exploit it to infect the application with the malware. The purpose of this malware may be to record keystrokes or to prompt users for passwords, and then send them back to the attacker to use to log in to the system or pivot/hop to another computer in the system.

More information on a practical approach to ICS cybersecurity

The expanded web exclusive version of this article (www.isa.org/intech/201706web) explores many attack methods and includes these additional cybersecurity topics: local network devices, device interfaces, Ethernet ports, application end points, peripheral ports, I/O ports, user interface attacks, communications protocol attacks, untested code attacks, and reaching the target of the attack.

• Facebook
• Twitter
• Linked In