This three-part series discusses the requirements and cybersecurity architecture and controls associated with protecting the network boundary for transmission facilities. Most of these cybersecurity controls are commonly deployed but boundary protection is still the leading issue identified by the National Cybersecurity and Communications Integration Center’s (NCCIC) Industrial Control Systems Cyber Emergency Readiness Team (ICS-CERT). Part One in this series explored one of the indicators outlined in the ICS CERT report: inadequate boundary protection for industrial control system (ICS) networks. This part explores the following indicators in the ICS CERT report and what steps should be taken to mitigate the associated risk:
- No logical separation of the ICS from enterprise networks or untrusted networks (such as the internet)
- No dedicated jump server to provide access to ICS data
This series was presented at the CIGRE US National Committee 2018 Grid of the Future Symposium.
No logical separation of ICS network
The second indicator discusses the lack of logical separation of the ICS network from corporate or other networks or even the internet. While this may sound like the previous indicator, there are several elements included in logical separation of networks that go beyond the firewall.
Logical network separation can involve several different design elements at multiple locations in the network. With new technology enabling virtualization at nearly every level of the traditional layered network model, it’s important to review logical separation at each layer.
In an Ethernet network, logical separation begins at the data link layer. As indicated in the Guide to Industrial Control Systems Security developed by the National Institutes of Standards and Technology (NIST) SP 800-82 R2, VLANs can provide logical separation and segregate traffic for ICS networks at layer two. ICS networks should not use the default VLAN in their design as many devices added to a network will default to VLAN 1 and therefore may become active on the VLAN.
In many modern substation networks, the Ethernet network is used to carry IEC 61850 protocol traffic which may include time-sensitive protection and control functions using Generic Object-Oriented Substation Event (GOOSE), so the proper design and separation of virtual Local Area Networks (VLANs) is critical for proper operation. VLANs should be grouped by operational function and all devices participating in GOOSE messaging associated with a specific function should belong to the same VLAN and class of service priority to avoid latency issues.
Most network switches allow for the definition of port and VLAN access control lists, or a forbidden port list for VLAN membership. Use of these mechanisms to limit VLAN membership by physical ports are recommended to minimize the chance of device misconfiguration and improper traffic on VLANs. As with the firewall management tasks described earlier, a robust configuration management process helps ensure that network switches are configured properly.
Moving up to the network level, we introduce the ability to route traffic between local area networks. This is the traditional location where firewalls and routers separate network segments into security domains. The ability to route network traffic is an important distinction in the NERC CIP Standards and underscores the additional risks associated with routable network protocols.
Some of the fundamental architectural and design choices for boundary protection at layer three include:
- Deny all network traffic by default and allow network connections by exception to ensure that only approved connections are allowed.
- Defining a demilitarized zone (DMZ) between the ICS security domain and all other security domains. This architecture is covered in more detail in the Inadequate Security Services to Support ICS System Maintenance section in Part Three.
- Only allowing communication between specific, pre-defined source and destination addresses that require approval and periodic review.
- Disabling control and troubleshooting services and protocols such as SNMP and DNS.
- Configuring boundary devices such as firewalls and routers to fail in a predetermined state based on the operational priorities of the organization.
- Configuring ICS security domain devices with separate network addresses that are fundamentally different from corporate network addressing.
At the transport and application layers, the focus should be on defense-in-depth and providing a secure configuration of operating system and application software. Since the focus of this series is on boundary protection, there are no specific details because of the wide number of operating systems and application software packages that may be installed in the ICS security domain. However, there are some architectural elements that can be applied across the transport and application layers:
- Develop and enforce an effective set of policies, procedures and processes that describe and govern the security program for the ICS security domain.
- Implement the principle of least privilege throughout the overall ICS system. Only configure the communications and application access and features required to achieve the operational requirements of the system. For example, there is normally no need to allow operator accounts to make configuration changes, or to allow protective relays to communicate directly with the revenue meters; therefore, there should be an access control list or a firewall rule that prevents that type of communication from happening. As a corresponding issue, if that type of access or traffic is detected on the network, the reason should be investigated immediately as malicious code may be trying to configure or communicate to any device that will respond.
- Implement and enforce configuration and change management processes to provide a review and approval element for all hardware and software configurations and help maintain an acceptable risk level.
- Implement an aggressive patch and vulnerability management program to assess, detect and patch vulnerabilities across all elements of the ICS security domain.
- Implement an extensive security monitoring system, including network security monitoring, centralized log management, and security incident and event monitoring.
No dedicated jump server for ICS access
In many cases, firewall rules are defined to allow maximum flexibility for staff to access the ICS security domain from any remote location and connect to devices to provide troubleshooting and other maintenance functions. However, one of the major design goals for NERC CIP was to minimize the risk of having routable protocols available outside the ESP.
NERC CIP-005-5 describes the implementation of an intermediate system or jump server that resides between the ICS security domain and the corporate network and serves as a proxy for a remote user who wants to access devices in the ICS security domain. This eliminates any direct connection between external devices and all the devices in the ICS security domain.
There are several benefits to this architecture for interactive remote access:
- Firewall rules can be much more restrictive for inbound traffic to the ICS security domain — all remote access is forced to use the jump server as the source of the network connection.
- The jump server can enforce multi-factor authentication prior to any connection attempts to devices in the ICS security domain.
- The jump server can be configured to use an encrypted connection between the remote computer and the jump server to protect authentication credentials and other sensitive information.
Based on these benefits, the use of a jump server for interactive remote access is required for High Impact and Medium Impact Bulk Electric System (BES) Cyber Systems and their associated Protected Cyber Assets with external routable connectivity.
Part Three will address the remaining three indicators discussed in the FY 2016 report:
- Using the same user authentication credentials for the jump server and the enterprise network.
- Too many communication flows (ports and services) allowed to the boundary devices.
- Inadequate security services available in the DMZ to support ICS system patching and updates.
