Could CIP-005 have prevented the SolarWinds attack?

It has been four months since we discovered the SolarWinds attack and many organizations are still deep into clean-up efforts. If you have been affected by this event, excellent resources have been published to dissect the malware involved and to help with identification and remediation. We previously discussed lessons learned from the SolarWinds compromise to emphasize the importance of maintaining continuous visibility over networks and to ensure clear separation of duties between monitoring and control solutions. In this article, we are exploring the role of network segmentation through the lens of CIP-005 and the concept of Electronic Security Perimeter (ESP).

Best Practices from the Electric Industry

In the world of industrial control systems (ICS), priorities are different compared to a traditional corporate environment. Indeed, an IT server shutting down unexpectedly may frustrate users and cause financial damage, but an Operational Technology (OT) server shutting down unexpectedly may impact industrial equipment and possibly injure people. As a result, safety and reliability are top priorities for ICS and this is why the adoption of a strict risk assessment and compliance framework is paramount in the OT space.

To that end, the NERC CIP standards have significantly impacted the way electric utilities in North America are deploying and configuring the firewalls protecting their critical cyber assets. This is particularly important in the context of the SolarWinds attack since understanding trusted communication paths and data flows can directly help mitigate and prevent not only current but also future cyber attacks. It could even be said that better network segmentation could have prevented the breach of the SolarWinds build environment in the first place. To quote from Tom Alrich’s article:

The software build environment would need to be protected in a similar fashion to how the Electronic Security Perimeter (ESP) is required to be protected by the NERC CIP standards – in other words, there should be no direct connection to the internet, and any connection to the IT network should be carefully circumscribed through measures like those required by CIP-005.

At Network Perception, we know CIP-005 quite well since we have designed NP-View and NP-Live with the specific goal of helping the NERC industry with implementation and control of CIP-005 requirements. Following up on Tom’ suggestion, we are providing practical guidance in the section below about how CIP-005 could be leveraged by any organization that has critical systems to protect, whether they reside in the IT or the OT space.

Hardening Network Segmentation with CIP-005

NERC CIP spans multiple reliability standards, ranging from categorizing critical cyber assets (CIP-002) to personnel and training (CIP-004), as well as incident reporting (CIP-008) and configuration change management (CIP-010). The standard that is explored in this article is CIP-005: Electronic Security Perimeter. Before listing the requirements, it is important to understand the terminology which is provided in the NERC Glossary. Here is the summarized version:

• The Bulk Electric System (BES) is defined to identify the most critical systems to protect. In the electric industry, the BES covers transmission elements operated at 100 kV or higher. The concept of BES could be translated to other industries. For instance, the systems storing and transmitting credit card information in the payment industry.
• A Cyber Asset (CA) is a programmable electronic device, which includes computers, servers, and connected equipment.
• A BES Cyber Asset (BCA) is a cyber asset that can impact the BES within 15 minutes. This definition is important because it allows us to separate mission-critical systems from the rest.
• An Electronic Security Perimeter (ESP) is the logical border surrounding a network to which BCAs are connected.
• An Electronic access control and monitoring system (EACMS) is a cyber asset that performs access control or monitoring—like a firewall or an intrusion prevention system.
• An Electronic access point (EAP) is a cyber asset interface on an ESP that allows routable communication. For example, a network interface on a firewall.
• A Protected Cyber Asset (PCA) is a cyber asset inside the ESP that is not a BCA.
• An Interactive Remote Access (IRA) is a user-initiated remote network access that uses a routable protocol. An IRA allows us to identify trusted communication paths and separate them from non-interactive system-to-system communications.
• An Intermediate Systems (IS) is a cyber asset performing access control to restrict IRA to only authorized users. Typically, an IS is a jump host on which a user has to authenticate before accessing a critical resource.

The diagram below illustrates a network with ten nodes, among which three nodes are BCA (the crown jewels) and all communications to the BCA have to go through a firewall (the EACMS). An ESP has been defined around the BCA and also includes a non-critical node (the PCA). Since the PCA resides in the same broadcast domain with the BCA, it has to be protected with the same criticality level. Finally, an IS (jump host) enables users to connect to the ESP through an interactive session (for instance, SSH or Remote Desktop).

Now that we understand the CIP-005 terminology, we can list the five requirement parts that electric utilities with medium and high impact cyber systems have to comply with:

• CIP-005 R1.1: All applicable Cyber Assets connected to a network via a routable protocol shall reside within a defined ESP
• CIP-005 R1.2: All External Routable Connectivity must be through an identified Electronic Access Point (EAP)
• CIP-005 R1.3: Require inbound and outbound access permissions, including the reason for granting access, and deny all other access by default
• CIP-005 R2.1: Utilize an Intermediate System such that the Cyber Asset initiating Interactive Remote Access does not directly access an applicable Cyber Asset
• CIP-005 R2.2: Interactive Remote Access sessions must be encrypted to the Intermediate System to protect the confidentiality and integrity of the communications

In summary, utilities have to (1) identify their critical systems and the networks in which they are connected, (2) protect those networks with firewalls, (3) ensure that firewall access rules are justified and follow a principle of least privilege, (4) ensure that interactive remote connections go through a well-identified jump host, and (5) ensure that those interactive remote connections are encrypted outside of the critical networks. This means that critical systems should be in a separate network zone and not have direct access to the corporate network and the Internet.

Coming back to the SolarWinds attack and the software vendor industry at large, here is how the CIP-005 requirements could be adopted to better protect the digital supply chain:

• Step 1: We should start by translating the concept of the Bulk Electric System (BES) to the software industry. We are suggesting the Critical Build Environment (CBE) that would cover all systems used to compile, package, and deploy a software application for production.
• Step 2: We then identify CCA, the cyber assets that are either part of the CBE or can connect directly to the CBE.
• Step 3: We define an ESP to segment the CCA in a clearly-defined network zone and ensure that there are firewalls to control inbound and outbound connections to the ESP. The access lists should prevent CCA from being directly accessible externally, especially from assets in the corporate network and the Internet.
• Step 4: We deploy jump hosts to allow engineers and devops to access CCA through interactive remote sessions and we ensure that multi-factor authentication as well as encryption are correctly configured.

There is, of course, a cost to implementing this framework, but it pales in comparison to the impact of a sophisticated supply chain attack such as the one that targeted SolarWinds. This is work-in-progress and we invite you to start a conversation with your team. If you have questions or would like to make suggestions on how this framework could be applied to different industries, please drop us a note at info@network-perception.com.