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 explored Inadequate boundary protection for industrial control system (ICS) networks and Part Two, no logical separation of the ICS from enterprise networks or untrusted networks (such as the internet), and no dedicated jump server to provide access to ICS data. This part discusses the following three indicators outlined in the ICS CERT report and what steps should be taken to mitigate the associated risk:
- 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 demilitarized zone (DMZ) to support ICS system patching and updates.
This series was presented at the CIGRE US National Committee 2018 Grid of the Future Symposium.
Using common authentication credentials
This indicator refers to the use of the same username and passwords on the corporate network and the jump server. One highly visible example of this issue is the Ukrainian Power Grid Attack of December 2015. In its analysis of this event, the Electricity Information Sharing and Analysis Center (EISAC) reviewed the attack techniques used to gain access — using malware to harvest credentials to the corporate network and then pivoting their efforts to access the control network where the SCADA dispatch workstations and servers existed.
While multi-factor authentication is a good practice, if the same username is used in both authentication domains, the attackers have a head start in gaining access to the jump server. If the authentication domains are managed so that there is no duplication in usernames, the overall security posture of the jump server, and in turn the ICS security domain, is increased.
Any administrative changes to the authentication and authorization systems should be reviewed and approved as per the configuration management process because of the potential impact of a failed authentication system. In addition, use of a centralized authentication service such as LDAP, Active Directory or RADIUS allows for easier credential maintenance and easier automation of disabled and removed user accounts. Some jump servers also provide the ability to manage default or other generic accounts on intelligent electronic devices (IEDs) such as protective relays, fault recorders and meters. Depending on the number of IEDs in the substation, this may be a valuable feature since NERC CIP requires password changes for these accounts every 15 calendar months.
Excessive network services to boundary devices
This indicator is related to the need for logical separation of the ICS security domain but is more focused on minimizing access to the servers housed in the DMZ and the access points for each ICS security domain. In many cases, these servers are treated similarly to servers on the corporate network that provide many different services to a broad category of users. Corporate servers are normally allowed access by default rather than by exception since nearly all employees use those servers daily. Servers that provide dedicated support to the ICS security domain should only be accessed by those devices that truly need access and only using the minimum number of services required operationally.
For example, a jump server located in the DMZ should only be accessed by approved users with ICS security domain accounts and only from certain locations on the corporate network. There should be no reason for the finance department to access the jump server, so those department accounts and IP addresses should be restricted from access.
Inadequate security services to support ICS system maintenance
A common practice in ICS system design is to allow outbound-only access to hardware and software vendors for patching and software updates, including anti-malware signatures. While this sounds reasonable to support these maintenance activities, it also allows communications directly from ICS devices to insecure networks and offers attackers a way to access the ICS security domain.
A better solution is to provide these services on the DMZ. The architecture is depicted as indicated in the Guide to Industrial Control Systems Security (NIST SP 800-82 R2) below. The devices in the ICS security domain would access one or more servers located in the DMZ to support hardware and software patching, anti-malware signature updates and other data exchange services such as a data historian. The corporate network can access the data historian and provide updates to the other servers in the DMZ but would not be allowed to directly access any server in the ICS security domain.
