At Level 2 are distributed control system controllers, programmable logic controllers, remote terminal units (RTUs), remote I/O devices, and other similar devices. Because they read and write field device parameters, controller-level devices require the second highest level of trust, generally attained through testing and experience.

Controller-level devices, other than some RTUs and other remote devices, usually have limited security-related features and rely on the Level 2 control network for protection. ICS vendors often use industrial grade, proprietary firewalls and Ethernet switches in the control network to separate it into two layers, the workstation layer and the control layer.

These network devices have three primary security objectives: to lock down the network to prevent unauthorized devices from connecting to it, to protect controller-level devices from unauthorized contact, and to prevent them from being saturated with network traffic by rate-controlling the network traffic flowing to them.

IT typically does not have the policies, procedures, tools, and expertise in place to manage the ICS vendor-specific Level 2 network and controller-level devices and the Level 1 I/O devices.

Also at Level 2, and sitting above controller-level devices, are the workstations/servers—configuration/engineering, maintenance, operator, historian stations—all having direct connectivity to the controllers, and all using components and operating systems familiar to IT, such as PCs, Windows, and Ethernet. Level 2 workstations and servers have the third highest level of trustworthiness in the ICS. They provide the buffer between the outside world (Level 3 and beyond) and the process, so outside direct access to controller-level devices should not be allowed. Access to controller-level devices should be limited to Level 2 workstations and servers approved by the ICS vendor.

The trust levels of Level 2 workstations and servers are lower than controller-level and field devices for three reasons:

1. They run commercial operating systems and software (e.g., SQL database software) with vulnerabilities that are continuously being discovered and exploited.
2. They have a better chance of being infected or compromised, because they can be accessed by Level 3.
3. They have users who may not always follow policies and procedures—some may plug in nonverified USB sticks, plug in their smartphones to charge, or bring in their own software that has not been tested to operate correctly with the ICS.

The trust levels associated with field devices, controller-level devices, and workstations are inherent to most control systems. Understanding them and maintaining separation/isolation between them is a responsibility that is normally not present in IT systems.

Difference #5: Physical components

Closely related to functional partitioning and trust levels are the physical components used to implement ICS and IT systems. IT systems are primarily composed of off-the-shelf networks, workstations, and servers that IT can access and administer. As a result, IT departments are able to define security policies for these components and enforce them with off-the-shelf security-related applications and devices, such as firewalls, antivirus systems, and patch management systems.

In contrast, ICSs are not IT systems doing control, as it may sometimes appear, but instead are tightly integrated proprietary systems. With the exception of workstations and servers, ICSs are composed of components that are generally custom built and foreign to IT. This often includes network devices built for industrial use, including Ethernet switches and firewalls. And, although ICS workstations and servers are typically based on Windows, they are usually hardened by the ICS vendor to the point that their software, other than the operating system, is custom built, and their security policies are set to industry standards that may conflict with the policies used within the IT system.

Consequently, IT security cannot just be mapped onto the ICS. Instead, the components used in the ICS may, and often do, require security-related ICS vendor-specific tools unknown to IT systems, such as custom event logs, port lockdown mechanisms, and features for disabling USB ports.

Difference #6: User accounts

IT systems generally support two levels of users: users known to the operating system (e.g., Windows users) and users of specific applications (e.g., order-entry systems). Operating system user accounts are used to authenticate the user during login and to identify which operating system resources the user can access. IT system administrators often administer operating system user accounts with Windows Domains/Active Directory. When multiple domains are present, IT administration establishes trusts between specific domains to let users access resources across domain boundaries.

IT systems also often contain applications, such as database applications, that have their own user accounts that can be independent of operating system accounts. For these applications, the user must go through a separate login screen before being allowed to access the data.

ICSs also use operating system user accounts and domains. However, allowing IT systems users to access the ICS by establishing trusts from IT system domains to the ICS domain is generally not recommended, since it reduces isolation of the ICS.

ICSs also have their own application-specific users. Unlike IT applications, however, the ICS is really a complete distributed system composed of configuration, operation, and maintenance applications, databases, and event journals. ICSs almost always use role-based access controls for granting/denying access to control data and devices. Operators, process engineers, and maintenance engineers are examples of these roles.

To manage access to these elements of the ICS, ICSs typically have an ICS-specific user management application. Although in principle this is similar to IT application security, the complexity, scope, and technical expertise required to administer ICS users is closely related to the nature of the process being controlled, which is generally not familiar to IT system administrators.

Finally, authorizing access from the plant network to the ICS becomes more difficult because of these differences. Do all external users become users of the ICS and its domain, or do DMZ server applications provide access to authorized IT system users but connect to the ICS using ICS credentials? Also, how is traceability maintained for auditable ICS transactions? Answering these questions normally requires collaboration between the ICS and IT systems administrators.

Difference #7: SIS

Plant safety is a critical part of plant operation, and ICSs, therefore, often include integrated, yet distinct, safety instrumented systems (SISs). The SIS is responsible for maintaining the safe operation of the process by placing the process into a safe state when process conditions that threaten safety are detected. IT systems have no systems analogous to the SIS.

SIS networks are usually proprietary and must be securely segmented and isolated from ICS networks. In addition, the SIS decision-making component, commonly called the logic solver, is also a custom, proprietary component, separate even from other components used in the ICS. Also, SIS-specific standards that include security are currently under development in ISA84. As a result, commonly used IT tools and network devices are not applicable to SIS network security.

Managing the security of an ICS includes an often manual effort to ensure that the SIS is protected from the ICS and from external interference, and that its integrity has not been compromised. These are capabilities not normally within the scope of IT systems professionals.

Difference #9: Patching

IT systems normally have patch management software that automatically installs security updates very quickly after their release. On the other hand, it is not uncommon for patches to be deferred or postponed indefinitely in ICSs. ICS patching requires testing, approval, scheduling, and validation to ensure safe and repeatable control. Scheduling is required because of the potential disruption to operations, such as reboots. Reboots can cause a temporary loss of view/control, and worse, they can fail, often requiring technical intervention to return a failed component to service. As a result of the effort required and because of the associated risks, patching is often not performed on an operational ICS, or at least not on the same schedule as IT system patching.

In addition, because the lifespan of ICSs is so long, patches for many older systems are no longer available. For example, there are many ICSs still in operation that run Windows NT and Windows XP.

The challenge for ICSs, which is not shared by IT systems, is to keep unpatched systems secure. Typically this is done through compensating security mechanisms in an ICS’s defense-in-depth strategy.

Difference #10: Security inconveniences

As most of us probably agree, cybersecurity measures add a degree of inconvenience to our jobs. Who has not had to wait while operating system patches are being installed? Or who has not had to call the service desk to report that he or she is locked out and needs to have a password reset? But as cumbersome as they can be, we have all learned to live with these inconveniences.

However, in an ICS environment, such inconveniences may not be tolerable, especially those that decrease performance. Imagine not receiving a critical system alarm in time to respond to it, or having to handle it while the workstation decides to reboot itself. Also, having to use a long and complex password during a process upset may not be acceptable. While many of these inconveniences are not specific to ICSs, they can be intolerable to them.

As a result, security measures that are acceptable in IT systems may not be acceptable in an ICS. If indiscriminately employed in an ICS, IT security measures may pose one of the biggest threats to ICS security. Because they are so painful or disruptive, they often result in the security mechanisms being bypassed, disabled, postponed, or otherwise ignored. Not only will this expose the ICS to vulnerabilities, but it will also negatively affect attitudes of ICS users toward future attempts to secure the ICS.

We have examined how ICSs differ from IT systems with respect to cybersecurity. Unfortunately, failure to understand these differences often leads to conflicts between IT and ICS administrators, which leads to a less-than-optimal security solution for the plant. These discussion points should help promote communications and resolve conflicts.