This post was authored by Lee Neitzel, senior engineer at Wurldtech Security Technologies, a GE company, and Gabe Faifman, global cybersecurity architect & innovation manager at Schneider Electric.

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 blog 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 cellphone. 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. Figure 2 illustrates the use of perimeter security devices.

Figure 2. Perimeter security devices

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 3.

Figure 3. 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 from outside the plant 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.

Local network devices

Local network devices, as shown in figure 4, are network devices, such as routers, switches, and wireless access points, that connect Ethernet devices, including workstations, servers, and controllers/programmable logic controllers (PLCs), to the ICS network. Although local network devices support connection to a limited number of Ethernet devices, they can be interconnected to each other to expand the size of the network. Routers can be used to divide the ICS network into separate Ethernet segments if necessary.

Figure 4. Local network devices connect Ethernet device to the ICS network.

Defensive measures: Like perimeter security devices, local network devices and their cabling should be physically protected from tampering and from having unauthorized devices connected to them. Apply the recommendations given above for perimeter security device configuration and maintenance to local network devices. Also, wireless Ethernet access points should only be connected to networks external to the DMZ, and they should be configured to enforce security that protects against eavesdropping and having unauthorized wireless devices connected to them.

ICS networks should have their own IP address spaces that are separate from DMZ and plant networks to further isolate them. Static, private IP addresses should be assigned to devices, because automatic assignment mechanisms, such as DHCP, have been shown to be susceptible to exploit by attackers. The ICS network should be scanned periodically to look for unauthorized IP addresses and unauthorized application end points (e.g., TCP/UDP ports). Because scans have the potential to be disruptive, care must be taken when using them.

In addition, only authorized network administrators should be allowed to connect Ethernet devices to the network. This should be supplemented with role-based access controls that allow authorized network administrators to configure switches to allow connectivity to authorized devices and deny connectivity to all others. Connectivity is often controlled using IEEE 802.1 switch port authentication, or by other mechanisms that support specifying the switch ports that are enabled, those that are disabled, and the devices/users that are authorized to communicate through these ports. In addition, maintenance personnel should periodically verify that only authorized devices are connected, and role-based access controls should be used to allow them to review switch configurations to ensure configurations are correct.

Device interfaces

Device interfaces, as shown in figure 5, provide connectivity to ICS devices through their Ethernet ports and application end points, peripheral interfaces, and field I/O modules. All of these interfaces, except Ethernet ports and application end points, require the attacker to have direct physical access to the device, or indirect access via a legitimate user, for example, by giving the user an infected USB memory device.

Figure 5. Device interfaces provide connectivity to ICS devices through their Ethernet ports and application end points, peripheral interfaces, and field I/O modules.

Ethernet ports

Ethernet ports provide access to Ethernet networks at the transmit/receive level. They manage the transfer of messages between application end points and the network. They include both wired and wireless connections to the network.

Defensive measures: Attacks against Ethernet ports usually try to exhaust buffer space or processing capabilities of the network interface card or its associated communications software. These attacks may be intentional or unintentional, such as a network storms or network scans that are configured to run too rapidly.

To protect against these attacks, physical access to these devices and ports should be controlled, and unused ports should be disabled or locked. For devices with both wired and wireless Ethernet ports, the wireless Ethernet ports should be removed or disabled. In addition, firewalls, either internal or external, should be used and configured to allow only authorized devices to communicate with the device.

In addition, devices should be required to pass a recognized communication robustness certification, such as Achilles Communication Certification. These certifications use a battery of tests to verify that network ports and their communications software have been implemented to withstand high traffic rates and malformed packets.

Application end points

Application end points are addressable access points within a device, such as TCP/UDP ports, that software applications use to communicate over the network. There are two basic types of software applications that communicate over the network: desktop applications and server applications.

Desktop applications are software programs with a user interface. They are typically started by selecting an item on the main menu, such as the Windows start menu, or on the menu of another desktop application. They often operate as clients, such as OPC clients and Web browsers, that issue requests to server applications. They typically run under the account of the logged-on OS user, but they may be able to change their account privileges by supplying the credentials of a different user.

Server applications are standalone programs, often called services or daemons, that do not interact directly with user interface devices (e.g., keyboard, monitor). They typically are configured to start either manually or automatically, and to run under an account configured for their execution. However, some can be configured to start dynamically in response to a client program and to run under their configured account, the account of the client, or an account for which credentials are supplied by the client. And, like desktop applications, they may also be able to dynamically change their account privileges.

Attacks against application end points attempt first to establish communications with the application and then to use its capabilities. Alternatively, attacks may attempt to find vulnerabilities in the application and then take advantage of (exploit) these vulnerabilities to crash the application or to insert code into it. Inserting code allows the attacker to take control of the application and potentially the platform on which it runs.

Defensive measures: Like Ethernet ports, access to application end points should be limited. Only approved end points should be enabled and accessible. Software applications that are installed but not approved should be uninstalled, disabled, or their end points blocked from receiving messages from the network.

Communications sent to an application end point should employ some level of authentication. End points or their applications should verify that received messages are sent by authorized senders. This may be accomplished with user authentication mechanisms or by using firewalls configured to limit access to the application to authorized senders. For example, industrial protocols often do not have authentication built into them, so using a firewall between their end points provides a base level of authentication using the addresses of the communicating end points.

When user authentication mechanisms are used, the credentials passed should identify a user account with permission to access the application and its data or database. Further, for communications with devices external to the ICS or that are in public areas, multifactor authentication is desirable to protect against attackers who have infected these devices or who are attempting to use stolen or disclosed passwords.

In addition to authentication of the user, some means of protecting the communications from disclosure or modification, including man-in-the-middle attacks, should be used. This is usually accomplished using digital signatures or encryption.

Finally, well-known application end point identifiers, such as TCP Port 23 for Telnet, should be changed if possible. Using standard identifiers gives the attacker a significant head start. Attackers who find open TCP/UDP ports on a device will generally not know what protocol is being used for nonstandard ports and will then have to expend additional effort to determine the protocol.

Peripheral ports

Peripheral ports are device interfaces used to connect peripheral devices, such as CDs/DVDs, printers, user interface devices (e.g., keyboard, mouse, displays), and serial devices, such as handheld maintenance and diagnostic devices. They pose a problem of being infected with malicious software, often referred to as malware, that can be used to attack or infect the device to which they connect.

With the advent of the USB protocol, the range of serial devices increased to include data devices, such as USB sticks, and more recently, fully programmable devices, such as smartphones and tablets. Because smartphones and tablets support external communications via their cellphone capabilities, they are an alternate avenue of attack for remote attackers. This further expands the sophistication of attacks that can be conducted through these interfaces, putting them on par with attacks conducted through network interfaces.

Handheld devices historically have been special-purpose serial port devices used for troubleshooting, diagnostics, maintenance, and configuration. As technology has advanced, handheld devices are now using wireless Ethernet and cellphone technology. All of these technologies provide yet another avenue of attack for assailants who have the use of a handheld device at the site or are able to infect one that will be connected to a device.

Defensive measures: Protection of peripheral ports should be a combination of technology, training, and procedures. Personnel should be trained to be aware of the dangers posed by these interfaces and should be instructed accordingly, with the instruction supplemented by written policies and procedures as necessary.

For example, policies and procedures that prohibit phones and tablets from being connected to ICS devices should be enforced. Policies and procedures should also require all removable media and portable devices, such as USB memory sticks and diagnostics/maintenance devices, to be approved before being used. Additionally, policies and procedures should require approved removable media to be used only within the ICS and to be scanned and inspected before use. Finally, supply-chain requirements should be applied to all removable media shipped to the site and include the use of tamperproof seals and digital signatures.

Coupled with these policies and procedures, technical measures should be employed for disabling all peripheral ports when they are not needed. They should be enabled only for the period of time when they are needed.

Ports used for memory devices, such as USB ports and DVD/CD drives, should be configured to show hidden files contained on memory devices. They should not allow files on them to be automatically opened or executed. This will allow for inspection of their contents before use.

ISA offers standards-based industrial cybersecurity training, certificate programs, conformity assessment programs, and technical resources. Please visit the following ISA links for more information:

• Cybersecurity Books
• Cybersecurity Training Courses
• Cybersecurity Blog Posts
• Cybersecurity Resources Portal
• ISA Global Cybersecurity Alliance
• IEC 62443 Conformance Certification
• ISA Suite of Security Standards
• ISA Family of Standards
• ISA/IEC 62443 Cybersecurity Certificate Programs

I/O ports

I/O ports connect field I/O devices to PLCs and controllers using protocols such as HART, FOUNDATION Fieldbus, Profibus, DeviceNet, and Modbus. The attack surface for I/O ports like these is relatively small, but it does exist.

Defensive measures: Physical access controls should be used for I/O devices and for the wiring. Examples include access restrictions for personnel, locked marshalling cabinets, and conduit for wiring that is in easily accessible areas. For wireless I/O, standards that have built-in security measures should be used, such as WirelessHART and SP100. Additionally, surveillance cameras can be used to monitor and record all physical access to these devices.

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.

User interface attacks

User interface attacks generally target command-line interfaces and desktop applications to access OS resources or to manipulate the control system and its data. They generally follow an HMI entry point attack or an attack through a remote desktop communications protocol (see below) that results in a successful login. It is also possible that the attacker gains access to the user interface through the insertion of malware to command line interfaces or desktop applications.

Attackers may be authorized or unauthorized users. Attacks by authorized users can be unintentional and are often regarded as "user mistakes," but they can also be intentional and regarded as malicious. Whether conducted by an authorized or unauthorized user, the result of a user interface attack allows the attacker to manipulate the system through menu items on user interfaces and through commands using a command prompt.

Examples of compromises through these interfaces include command execution, which lets the attacker directly modify the operation of elements of the control system. Data-related compromises include disclosure, modification, addition, or deletion of data and files, including configuration data, calibration data, run-time parameters, alarm limits, and logs. Attacks may also be able to execute or copy untested software to the system or send commands and downloads to controllers and other devices.

Defensive measures: One of the primary defenses against user interface attacks is to enforce least privilege. Least privilege is the principle of giving users only the privileges and permissions they need. This applies to both their OS and their control system accounts. Users who are able to access the control system should have their own control system account configured for least privilege. Without their own account, their control system actions cannot be traced back to them. Where possible, role-based access controls should be used to simplify management of user privileges and permissions, including the reduction of account configuration errors.

Additionally, OS and control system administrator accounts should be closely controlled. They should be granted only to a limited few who perform administrative tasks, such as account management and the installation of new or replacement devices, software, and patches. When possible, control system administrator accounts should be configured with only the specific OS administrator privileges and permissions that they need, rather than making them OS administrators or assigning them to the OS administrators group.

To further protect administrator privileges in Microsoft Windows systems, enable Microsoft Windows user account control (UAC). Of course, this feature should be tested for compatibility with the control system during development and before use at a site. UAC causes all user sessions, including those for administrators, to run as standard users until administrative privileges are actually needed.

UAC can be configured to prompt the user, including administrators, for administrator credentials when this occurs. While this seems like an unnecessary burden, it is recommended for developers, integrators, and end users for two reasons. First, it is much more secure, and second, it raises security awareness by telling the user when privileged functions are being used, something that is sorely missing in today's operations.

In certain cases, authorization to perform critical control system operations should use an authorization scheme that requires two or more users to work together to complete an action critical to the ICS. Examples include (1) having one user turn a key switch that enables another user to change the configuration of a safety system, (2) having to schedule a remote access connection or secure shell (SSH) session through a security administrator, (3) requiring two operators to approve batch step changes, and (4) requiring a shift supervisor to approve operator changes to sensitive set points or alarm limits.

In addition, some display screens are often used in ways for which they were not intended. For example, many applications display a built-in "File Open" dialog box to allow a user to browse and select a file to open. However, this dialog box is often used as the basis for all file operations, including "File Save" and "File Delete." As a result, it is not uncommon for a "File Open" dialog box to also allow the user to delete files, bypassing normal file delete user interfaces and safeguards. Therefore, the use of such display screen capabilities should be evaluated and approved for the control system.

Finally, documented procedures and training should be available to provide an authoritative source of information for directing user operations. Without them, users may make uninformed decisions that could lead to misuse or abuse of the system.

Communications protocol attacks

Communications protocol attacks target OS and ICS communications protocols and their applications. These attacks can be attempted after the attacker has successfully gained access to a device entry point or to the network or its media. Gaining access to the network or its media (cabling or wireless) may let the attacker listen to and potentially modify communications while in transit ("on the wire"). It may also allow the attacker to construct and send protocol messages to the listening OS or ICS application.

Malicious software is often the attacker in communications protocol attacks. Malicious software normally attempts to use features of the protocol to manipulate the ICS application, cause it to fail, or break into it. Malicious software may be able to use features of the protocol to send data to the application, to read data from it, and to cause it to perform some specified operation. In a sense, protocol features provide the software equivalent of the user interfaces just described.

A communications protocol break-in occurs when the attacker detects a weakness (vulnerability) in the application or the protocol and then exploits that vulnerability to cause the application to accept and run attacker software. Vulnerabilities are usually caused by software bugs or deficiencies in the system design and implementation. The attacker detects them by learning the version numbers of the various software components running in the ICS.

OPC provides an example of how communications protocols can lead to an attack. OPC Classic (DA, HDA, A&E) is based on Microsoft DCOM, which assigns an application end point address (a TCP port) to a client connection during connection establishment. The TCP port is taken from a range of dynamically assigned ports managed by the OS. This requires this range of ports to be opened in firewalls. Opening access to these ports allows them to be attacked through the firewall, whether or not they were actually assigned to an OPC server.

Conversely, OPC UA uses a single TCP port, which alleviates this DCOM problem. However, its authentication is based on self-signed certificates that have their own security issues. Further, these certificates are often not integrated with Windows authentication. OPC UA servers are configured to recognize certificates assigned to client applications, but they have no means of recognizing or authenticating the OS or control system user, and thus no ability to authorize actions for individual users or trace their actions back to them.

Defensive measures: The principle of least privilege, recommended above for ICS desktop and service applications, should also be applied. As a general rule, ICS desktop applications and services with network access should not have elevated OS privileges and permissions. This will prevent attackers from having elevated privileges and permissions should they gain access to one of these applications.

Privileges and permissions for desktop applications are inherited from the user account used to start them (see "user interface attacks" above). To further protect desktop applications that support communications access, including remote logins, access control lists should be explicitly configured to identify the users who are authorized to connect to them. In addition, remote login capabilities should be disabled and enabled only when needed.

Services, on the other hand, are configured with a specific account that should have only the privileges and permissions needed by the service. Further, privileges for service accounts should not support interactive logins. This prevents an attacker from logging into the system using service credentials.

Also, unlike desktop applications, service applications are not assigned control system privileges when they run. Therefore, it is highly recommended that service applications use the control system privileges of the logged-on control system user when a request originates from a desktop application in the same workstation. When the request comes from another device, the service should default to have a minimum set of control system privileges or it should have some method of obtaining the identity of the requesting control system user. Options include performing a control system user login, explicitly passing the control system user identity in a secure manner, or mapping the OS user to a corresponding control system user. In all cases, the assignment of control system privileges to the service should be logged.

Again, the example of an OPC server can be used to illustrate this point. If the OPC client desktop application is on the same workstation as the OPC server, then the OPC server should use a control system user account that has been mapped to the logged-on control system user to authorize requested operations. When the OPC client is on another workstation, then the OPC server should have a means of determining the control system credentials of the user making the request.

Equal in importance to the use of these measures, applications should be developed to validate input parameters for length and content. This is a primary method of preventing or minimizing exploitable vulnerabilities. And, in addition to normal testing, use fuzz testing to verify comprehensiveness of parameter validation. Fuzz tests send a variety of malformed messages as well as messages with unexpected parameter values and lengths to try to cause improper behavior in the end point or the application. For website applications, web page security best practices are well documented and should be used.

A second line of defense against vulnerabilities is assessing and resolving them using formal incident and vulnerability handling processes. If the resolution results in a patch, the patch should be developed, tested, and installed with all due diligence. In addition, OS and other third party software patches should be treated as untested software and should be thoroughly tested for compatibility with the ICS.

A third line of defense is encryption and digital signatures. Encryption is used to prevent disclosure of information, and should be employed whenever confidential data is being transmitted. In addition, communications used to write data/commands to an application, whether from an external or internal location, should be digitally signed or otherwise protected against tampering.

Untested code attacks

Untested code attacks occur when the attacker loads or inserts software that has not been tested with the system. Untested software is generally transferred to a system through user interfaces and communications protocols, and also by the exploitation of vulnerabilities.

Untested software, whether legitimate software or malware, has the potential to negatively affect the operation of the control system. Legitimate software includes games, graphics and drawing tools, analysis software, and in general, commercially available software. Malware includes a wide variety of malicious software. Its name is usually based on the behavior of the software, such as virus, worm, bot, rootkit, and spyware.

Untested legitimate software is dangerous because it may degrade performance by consuming too much memory or requiring too much processor time. It may also compete for other resources and cause the system to fail. Malicious software, on the other hand, intentionally tries to disrupt operation of the device through a variety of methods-deleting, renaming, encrypting, or changing files and changing configuration or operational settings. Disruptions can range from crashing the device to simply creating an annoyance for the user.

Sophisticated malware may elevate its privileges, scan the network for other devices, monitor system data, record keystrokes (including user names and passwords), and also attempt to hide itself from detection. Further, it may run continuously or put itself to sleep awaiting a specific event or time to trigger its operation. It may establish a connection back to the attacker, if one does not already exist, and give the attacker the ability to direct its operation. This may include infecting other devices and penetrating deeper into the system.

These are only a few of the consequences of falling victim to untested software attacks. The unfortunate part is that malware attacks can, and often do, happen without involving any of the control system software. That is, the insertion of malware is often accomplished by using commercially available hacker tools that exploit (take advantage of) known weaknesses in the OS or other commonly used software, such as drivers and applications. Of course, attackers may also be able to exploit vulnerabilities in control system applications that have network interfaces or other accessible interfaces, such as dynamic link library (DLL) interfaces and inter-process communications interfaces.

Hacker tool vendors pay hackers a premium for finding vulnerabilities and for providing malicious code to exploit them. They sell these tools to hackers who can use them to infect the device being attacked. The rationale is that software suppliers can buy these tools to harden their software against attack. However, malicious hackers can also discover vulnerabilities and exploit them to attack control systems.

A typical scenario for a malware attack is as follows. Once the attacker discovers a vulnerability, he or she sends a message that contains an infection (software instructions) to the device being attacked, and the vulnerability causes the instructions to be executed. The malware instructions then create a message that is sent back to the attacker asking for more code to be returned to the target program. In this way, the malware increases its capabilities and eventually graduates to a full-blown program that may even save itself to disk and restart itself whenever the computer reboots.

Another approach is through a legitimately established connection to an infected or malicious website. Phishing is one technique that is used to try to encourage, or trick (spoof) a user into connecting to such a site. Others involve changing network settings to cause legitimate connection requests (e.g., HTTP or TCP/UDP) to be redirected to malicious sites. Once connected to a malicious site, the malicious site can infect the user's computer by, for example, exploiting vulnerabilities in the client application or sending a web page that contains code to infect the user's computer. In most cases, the user will be unaware that his or her computer has been infected.

A third method is to copy an infected file to a computer, either from portable media or from another computer, or by downloading it from a web site. Common examples of this type of attack include malicious users who intentionally copy infected files, and nonmalicious users who copy files without knowing they are infected. This type of attack may also occur when a user inserts an infected USB memory device into a workstation and an infected file is automatically copied. More sophisticated attacks hide these files from view to make the user think they are not present on the USB device.

The types of malware that can infect a computer are limited only by the imagination of the malware programmer. For this reason, it is essential to protect the system from the mechanisms used to deliver malware.

Defensive measures: To help protect against malware, anti-malware mechanisms, including intrusion detection and prevention systems, can be added to the network to look for known malware code signatures (byte patterns) before they reach the target device. Anti-virus should also be employed in devices that support them to look for malware signatures and quarantine them. Also, application whitelisting can be used to allow only approved software to be run. Application whitelisting protects against untested software that has been copied to disk.

However, anti-virus and whitelisting software should be thoroughly tested to ensure they do not interfere with the operation, performance, or safety of the system. This testing should include stress testing and testing of a wide variety of operational scenarios. Operational scenario testing protects against surprises related to the use of this software. Whitelisting, in particular, has shown the need for extensive operational scenario testing. Whitelisting software sometimes degrades system performance during unusual circumstances or fails to authorize execution of an infrequently used application, because it was not added to the whitelist. Both can be serious problems.

Digital signatures for approved software executable and DLL files should be used to complement anti-virus and whitelisting. Digital signatures are secure checksums that detect when a file has been changed. They can be used to not only notify the user when changes in software and data files are detected, but also to prevent infected software files from being executed and used.

If the attacker gains administrative privileges and is familiar with the anti-virus, whitelisting, or digital signature capabilities of the system, he or she may be able to defeat these safeguards, but it would require a very sophisticated attack.

Finally, if a device becomes infected through exploitation of a vulnerability, formal incident and vulnerability handling processes ensure that the vulnerability is adequately assessed and resolved. If the resolution results in a patch, the patch should be developed and installed promptly.

Reaching the target of the attack

Targets of attack are often referred to as assets in traditional cybersecurity risk assessments. Attackers generally attack three types of assets: devices, information, and software.

The previous two sections discussed how attackers gain entry to the ICS and then attempt to use or misuse the system. This section describes elements of the system that are often targeted to achieve the ultimate goal for an attack, such as financial gain/industrial espionage (theft), sabotage (production loss), vandalism (damage), terrorism (destruction), joy riding (thrill seeking), and notoriety (recognition).

Device targets can be any of the devices used within the ICS. Attacks of primary concern against network, control, and safety devices are those that can directly command operational behavior or cause denial of service.

ICS supervisory workstations and servers are also devices that are commonly targets of attack. They include operator workstations, engineering workstations, application servers, virtualization servers, and special-purpose servers commonly referred to as appliances. Operator workstations let the operator view and modify run-time data of the physical process being controlled. Engineering workstations are used for developing and deploying configurations for the control strategy of the process, while application servers run control applications, such as OPC servers and historians. Virtualization servers support virtual machines. Appliances are typically used to monitor the health and safety of the ICS. Denial of service, including loss of view, modification of run-time parameters, and modification or disclosure of information are primary concerns for these targets.

Information targets are numerous, but generally can be classified as confidential data, configuration and administrative data, and run-time data. They normally reside on the targeted devices just discussed. Examples include the file system, OS data (e.g., the registry), network shares, control system data and configurations, and recipes. Attacks may be launched on the stored, backed-up, and redundant versions of these, on their values in executing software, and while they are being transferred between devices and applications.

Software targets primarily include executable files and DLLs. DLLs are files that contain binary code that is shared by executables. Attacks against these generally attempt to infect them or replace them with attacker code.

Defensive measures: The first step in protecting assets is to partition the ICS into security zones. Security zones separate devices, information, and software based on how critical they are to business objectives. The more critical a target is, the more its integrity has to be trusted. For devices and software, integrity refers to their ability to perform as required. For information, integrity refers to the validity of the data.

If trust is low (you are not sure about the integrity), then consequences critical to production can occur, such as safety events, loss of equipment/production, and loss of trade secrets/competitive edge. In the past, trust has been gained through testing and maturity. The more heavily tested a target is and the more it is used, the higher the trust-the more confidence there is that it can be used successfully in critical operations.

From a security perspective, that trust has to be protected from cybersecurity threats. This means that higher trust zones have to be protected from lower trust zones. Protective barriers, such as network segmentation and separate access domains with no trust between them (e.g., Active Directory domains) should be employed to minimize security risks within and between zones. Instead, users who need to access resources residing in another zone should be given credentials to access that zone.

Partitioning an ICS is not a new concept. The Purdue Enterprise Reference Architecture model, as standardized by ISA-95 and IEC 62264-1, divides the functions of a plant into levels that are directly applicable to the definition of ICS security zones. Security partitioning begins by segmenting the ICS from external systems using perimeter security devices and DMZ, as described previously.

Then, within the ICS perimeter, devices involved in controlling physical processes (Purdue Model Level 1), such as field devices, are the most critical to production, followed in criticality by ICS devices in Level 2 and Level 3, respectively. These levels are a starting point for defining security zones within the ICS, with further partitioning within these levels becoming necessary if the security risks between components is deemed significant. For example, controllers in Level 2 will generally have a higher criticality than Level 2 HMI devices. As a result, they are placed in separate zones within Level 2. Additionally, safety instrumented systems and control systems, both of which reside in Levels 1 and 2, should be placed into separate security zones.

By the time the ICS becomes operational, much of the groundwork for identifying potential targets within zones has already been done. Alarm rationalization activities confirm which control elements are critical to the operation of the ICS. Similarly, safety hazard analysis activities can be used to identify safety-critical targets. In some cases, these targets coincide with those identified for alarms. In addition, devices that contain critical or valuable data are well known and documented, such as user accounts, control strategy configurations, calibration data, logs, and recipes. These should be placed in zones appropriate to their level of criticality.

Once zones are defined, security policies for each zone should be defined, and controls between zones should be identified and implemented. Common controls include firewalls, authentication mechanisms, access control lists, and cryptographic measures. The primary objective of these controls is to restrict access between zones to only those that are necessary.

The second step in protecting assets is additional hardening measures that complement those discussed in previous sections. Complementary hardening measures include disabling or removing all nonessential software and implementing security configuration/hardening benchmarks, such as those published by the Center for Internet Security.

In addition, unused certificates and Certificate Authorities should be removed from the certificate store. Further, self-signed certificates should not be used. The purpose of the certificate is to give the client application confidence that it is connecting to a server whose identity is verified by a trusted Certificate Authority. Self-signed certificates have no such verification, and they allow attackers to insert their own server into the ICS and provide a self-signed certificate for it.

Some information targets, such as SQL databases, may have their own access controls that are separate from those used by the OS and control system. When these access controls are present, they should be configured separately to prevent attackers who have gained access to a system from directly accessing these information targets.

The third step in protecting assets is anti-tampering mechanisms for software, data files, and downloads (e.g., configuration and recipe downloads). Digitally signing these when they are created is a recommended practice to protect their integrity and allow their users to verify that their contents have not changed.

The fourth step in protecting assets is the use of encryption to protect information transfers against unauthorized disclosure. Encryption should be used for transfers between the ICS and external systems, and within and between zones when it does not interfere with diagnostics and troubleshooting.

If a target is compromised, a combination of redundancy and backup/restore capabilities should be available to recover the target if necessary. Redundancy provides for rapid recovery through switchover from the compromised target to its redundant partner. However, there must be assurances that the redundant partner is not also compromised. Backup/restore capabilities are used to recover the target back to a known, uncompromised state, and their use should be integrated into a disaster recovery plan maintained for the system.

To protect against in-memory infections-those that have not been written to disk-devices can be rebooted periodically to clear them of memory-resident malware. While this is not always convenient, it will ensure that software processes are restored to their disk images. If that does not work, backups can restore the device to a previous state. Backups of both software and data should be made for this purpose.

Finally, if a vulnerability is discovered in a device, use incident and vulnerability handling processes aligned with those described above for communications protocol and untested software attacks to assess and resolve the issue, and patch the device if necessary. To supplement these processes, regularly monitor for and log suspicious activities, breaches, and compromises. Review these logs, along with control system logs, to better understand the security posture of the ICS and to determine the root causes of identified issues.

About the Author
Lee Neitzel is a senior engineer at Wurldtech Security Technologies, a GE company. He has been involved in security and network standards for more than 30 years and is currently leading the development of the IEC 62443 standards and conformance assessment program. Neitzel holds multiple patents in the area of control system cybersecurity and has a master’s degree in computer science with a focus on computer security from George Washington University in Washington, D.C.

Connect with Lee

About the Author
Gabe Faifman global cybersecurity architect & innovation manager at Schneider Electric. He formerly was director of strategic programs for Wurldtech Security Technologies. Faifman has been involved for 25 years in the design, deployment, and operation of automation and security infrastructure projects in the power generation, power distribution, oil and gas, and food and beverage industries. He holds a BS in electronics engineering from the University of Buenos Aires and a CSS1 InfoSec Professional certification from NSA.

Connect with Gabe

A version of this article also was published at InTech magazine.