By Andrew Wu, MRO Risk Assessment and Mitigation Engineer, CIP

There have been several new iterations of the NERC Critical Infrastructure Protection (CIP) CIP-003 Standard developed by industry through the Reliability Standards development process in the past few years. These new iterations are not yet subject to enforcement but are either already approved or pending approval by FERC. Understanding the objective and intent behind the changes in each iteration may help a Responsible Entity effectively develop its CIP-003 Security Management Controls program to address the identified risks for low impact BES Cyber Systems.

At the time of this publication, CIP-003-8 is the current version that is subject to enforcement across all regions. Further iterations of the standard include CIP-003-9, CIP-003-10, and CIP-003-11. Reference Table 1 for enforcement information about these standard versions.

Table 1: Approved and Pending Versions of CIP-003

Standard Version	Enforcement Date	Approval Status	Standard Drafting Team
CIP-003-9	April 1, 2026	Approved by FERC	Project 2020-03 Supply Chain Low Impact Revisions
CIP-003-10	TBD	Filed with FERC on July 10, 2024, pending approval	Project 2016-02 Modifications to CIP Standards
CIP-003-11	TBD	Filed with FERC on December 20, 2024, pending approval	Project 2023-04 Modifications to CIP-003

CIP-003-9

This standard version develops upon the existing CIP-003-8, which is currently enforceable. The changes in this version are based on the recommendations from the Supply Chain Risk Assessment Report¹ to address the risk associated with supply chain vulnerabilities for assets containing low impact BES Cyber Systems (BCS) with External Routable Connectivity (ERC).

The changes introduce additional requirements in Attachment 1, Section 6 to address these identified risks. MRO published a newsletter article² highlighting the changes in CIP-003-9 and provides guidance on planning and preparing for these changes.

The objective of the changes is to ensure that vendor electronic remote access is identified and controlled by a Responsible Entity to prevent security events and propagation of potential malicious communications to adversely affect its assets containing low impact BCS. As part of the controls for vendor electronic remote access, the ability to detect known or suspected malicious communications allows a Responsible Entity to respond to and remediate adverse impacts associated with the vendor communication.

The term ‘electronic remote access’ is not defined within the NERC Glossary of Terms; however, the intent of the Standards Drafting Team was to capture remote access using a non-physical method. This aligns with the use of “electronic remote access” in other CIP standards.

This developed language gives a Responsible Entity flexibility to define processes to identify and manage vendor electronic remote access. This may include developing new processes, or extending the use of existing processes, programs, and methodology that are designated for medium and high impact BCS and applying it to assets containing low impact BCS.

CIP-003-10

This standard version develops upon CIP-003-9. The proposed changes in this version are based on FERC Order No. 822³ and the issues identified by the CIP Version 5 Transition Advisory Group⁴ to revise and update the Version 5 CIP Standards, with focus on addressing the risk associated with virtualization for assets containing low impact BCS. The proposed changes introduce several new and revised NERC Glossary of Terms definitions⁵ as part of the wholesale update to CIP Standards. This primarily includes, but is not limited to, the introduction of Virtual Cyber Asset (VCA), Shared Cyber Infrastructure (SCI), Cyber System, and a revised definition to both BES Cyber Asset (BCA) and Transient Cyber Asset (TCA).

Virtual Cyber Asset is a new type of Cyber Asset that is a logical instance of an operating system or firmware executing on a virtual machine.

Shared Cyber Infrastructure is a new type of programmable electronic device that:

Cyber System is a logical grouping of one or more Cyber Assets, VCAs, or SCI.

BES Cyber Asset and Transient Cyber Asset largely remain the same but encompass Virtual Cyber Asset.

The objective of the changes is to enable the use of SCI to host a VCA that supports and provides BES functionality, while ensuring these Cyber Systems are afforded equal security controls as the low impact BCS it supports. This includes updates to the required physical security controls in Attachment 1, Section 2, electronic access controls in Attachment 1, Section 3, and controls to mitigate the risk of malicious code from Removable Media in Attachment 1, Section 5 with the new and revised definitions.

To prepare for the changes, a Responsible Entity should review its Cyber Assets, infrastructure, and compliance programs to determine:

If these types of Cyber System(s) exist within the infrastructure and are associated with or communicate with a low impact BES Cyber System, a Responsible Entity should prepare to accommodate the new requirements. This will include updating and implementing its compliance program, providing training, and determining how to demonstrate compliance with the Cyber System(s).

CIP-003-11

This standard version develops upon the pending FERC approval CIP-003-10. The proposed changes in this version are based on the recommendations from the Low Impact Criteria Review Team Report⁶ to address the aggregate risk and potential impact associated with a coordinated cyber-attack on multiple low impact BCS facilities.

The objective of the changes is to control electronic access to low impact BCS and SCI that supports a low impact BCS, through detecting malicious communications, ensuring each user is authenticated before they gain electronic access to a network of low impact BCS, and protecting the authentication information. These controls mitigate and address the aggregate risk and potential impact associated with a coordinated cyber-attack on multiple low impact BCS facilities.

There are several notable changes under Requirement R2, Attachment 1, Section 3.

The change merges CIP-003-10 Attachment 1, Section 6 into Section 3 to create a single location where all required electronic access controls reside, whether it is vendor, dial-up, or inter-network. The change re-organizes Section 3 as a result, such as moving the electronic access qualifiers for required controls, but several of the controls that a Responsible Entity is required to implement remain the same.

For electronic access where the qualifiers in Section 3 are met, the change expands the scope of detecting known or suspected malicious communications to all qualified electronic access and not just vendor electronic remote access as previously required in Section 6.

Additionally, for electronic access where the qualifiers in Section 3 are met, the change introduces a new requirement that a Responsible Entity must authenticate each user prior to permitting user-initiated electronic access to a network(s) containing low impact BCS or SCI that supports a low impact BCS.

The intent of this language focuses on the initial authentication to a network(s) and not all subsequent access to downstream networks. Multiple authentications are not required for a collection of sub-networks within the network containing the low impact BCS or SCI that supports a low impact BCS. However, the authentication needs to occur prior to the user-initiated electronic access being permitted, and the authentication system cannot exist within or on the network containing the low impact BCS or SCI that supports a low impact BCS.

Finally, for electronic access where the qualifiers in Section 3 are met, the change introduces a new requirement that requires a Responsible Entity to protect user authentication information for user-initiated electronic access while in transit to the authentication system or the asset containing the low impact BCS or SCI that supports a low impact BCS.

This proposed language gives a Responsible Entity flexibility with where and how the detection of malicious communications is implemented based on its architecture and technologies. For example, an Intrusion Detection System or deep packet inspection through decrypting and re-encrypting communications is not prescribed. Automated logging and alerting may be justified to address the risk and meet compliance requirements. Similarly, the detective control may be implemented through a centralized Operational Technology (OT) location or local to each low impact BES Cyber System.

This proposed language also gives a Responsible Entity flexibility with where authentication is implemented and how the authentication information is protected. For example, the implementation can authenticate the user-initiated electronic access with an authentication system that is local to the asset containing the low impact BCS, if the authentication system is separated from the network containing the low impact BCS. In this case, encryption from a Cyber System to the asset containing the low impact is effective. Alternatively, a centralized OT authentication system using a proxy server as a gateway, such as an existing Intermediate System, can be used to authenticate the electronic access, and the encryption of authentication information is only required from the Cyber System to the proxy server.

To prepare for the changes, a Responsible Entity can consider reviewing its Cyber Assets, infrastructure, existing technologies, and its programmatic and technical controls to determine:

Reviewing the existing technologies and implemented controls to detect malicious communications, to authenticate users, and to protect user authentication information for electronic access, can provide a Responsible Entity insight into the solution(s) that can be implemented. Similarly, reviewing network infrastructure that contains low impact BCS or SCI that supports a low impact BCS can provide a Responsible Entity insight into where and how it needs to implement the solution(s). Ultimately, a Responsible Entity will need to update its compliance program, provide training, and determine how to demonstrate compliance to accommodate the new requirements.

Submit questions to [email protected].

---