NERC CIP is a body of standards that addresses critical cyber infrastructure technologies, policies, and procedures by promoting (not guaranteeing) a sound approach to risk avoidance for the Bulk Electric System (BES) providers of the North American power grid.
While not specifically mandating a particular risk avoidance framework or underlying specific industry standards, much of NERC CIP is compatible with the National Institute of Standards and Technology (NIST) Security and Privacy Controls for Federal Information Systems and Organizations (for example, NIST Special Publication 800-53) initiatives and philosophy.
Prescriptive methods are not present within the CIP standards. Instead, they each contain a section on Requirements and Measures, where specific outcome-based directives are provided, and a means to evaluate compliance with these directives is specified.
The NERC CIP standards are a compilation of both technical requirements and a suite of policy requirements. The technical portions can be mapped to VMware and partner technologies, while the policies cannot, as they pertain to programs, personnel, and procedures. Although these are critical to overall Cyber Systems security and they might have technical support supplied by VMware technologies, as a byproduct of how they can be implemented (physical access control often runs on VMs in ESXi, which is managed by vCenter, for example) the actual requirements of the standard do not provide a technical basis for a control.
The matrix below, which is based upon recent (2024) updates of the standards for Project 2016-02 modifications, shows all the specific CIP requirements and their applicability to VMware products. ‘Supported’ is listed when an available solution can be applied to a technical measure. ‘N/A’ is listed for the organizational and policy requirements, including CIP-002, -003, -004, -006, -008, -011, and -014 standards in their entirety, as well as some individual requirements.
When an available solution can be applied to a technical measure, it is denoted as Supported.
The organizational and policy requirements, including CIP-002, -003, -004, -006, -008, -011, and -014 standards in their entirety, and some individual requirements - is denoted by N/A.
NERC CIP Requirement No. |
Topic/Description (Requirement) |
Measures |
Applicability to VMware Products |
|---|---|---|---|
CIP-002-7 Bulk Electric System - Cyber System (BCS) Categorization |
|||
R1 |
Process to classify all BCS assets (high-, medium, or low-impact) |
N/A |
|
R2 |
Recurring review and approval of process (R1) |
||
CIP-003-8 Security Management Controls |
|||
R1 |
Review and approval of cyber security policies |
N/A |
|
R2 |
Low-impact cyber security plan implementation |
||
R3 |
CIP Senior Manager assignment |
||
R4 |
Delegation of authority |
||
CIP-004-8 Cyber Security Personnel and Training |
|||
R1 |
Security awareness program |
N/A |
|
R2 |
Cyber security training program |
||
R3 |
Personnel risk assessment program |
||
R4 |
Access management program |
||
R5 |
Access revocation |
||
R6 |
Access management for BCS information |
||
CIP-005-8 Electronic Security Perimeter |
|||
R1.1 |
Applicable systems must be protected by an Electronic Security Perimeter (ESP) |
Listing of all ESPs and all systems connected within that use a routable protocol. |
Supported |
R1.2 |
Deny all routable traffic through the ESP, except what is deemed necessary (excludes time-sensitive protection systems) |
Network infrastructure and Electronic Access Point (EAP) configuration. |
Supported |
R1.3 |
Deny all routable traffic to/from all management interfaces of Shared Cyber Infrastructure (SCI) or Electronic Access Controller Monitoring Systems w/associated SCI, except what is deemed necessary. |
Documentation of access enforcement or configuration/settings logically isolating the management plane. |
Supported |
R1.4 |
Authentication of dial-up connections. |
N/A |
|
R1.5 |
Detection of malicious Internet Protocol (IP) ingress/egress ESP traffic. |
Documentation that detection methods have been implemented. |
Supported |
R1.6 |
Protecting data over links spanning between separate Physical Security Perimeters (PSPs) within an ESP. |
Proof of data encryption. |
Supported |
R2.1 |
Interactive Remote Access (IRA) only allowed through an "intermediate system". |
Evidence that all IRA funnels through an intermediate system. |
Supported |
R2.2 |
Protection of IRA communications between Virtual Cyber Assets (VCAs) and the intermediate system. |
Details of confidentiality and integrity controls. |
Supported |
R2.3 |
Multi-factor authenticated access to the intermediate system for IRA use. |
Details of authenticators used. |
Supported |
R2.4 |
Detection of active vendor IRA sessions or system-to-system remote access. |
Documentation of detection methods, such as monitoring logs and active sessions, and recording requests for nth-factor information to be used for access. |
Supported |
R2.5 |
Methods for disabling active vendor access |
Details of methods. |
Supported |
R2.7 |
The "intermediate system" of R2.1 cannot share CPU or memory with any part of a high- or medium-impact BCS and must restrict its routable communication to BCSs and their associated Protected Cyber Assets via an ESP |
Documentation of architecture, configuration, and settings. |
Supported |
R3.1 |
Methods to identify vendor remote sessions |
Documentation of detection methods. |
Supported |
R3.2 |
Methods to terminate vendor remote connections and block reconnection. |
Details of methods. |
Supported |
CIP-006-7 Physical Security of BES Cyber Systems |
|||
R1 |
Physical Security Plan. |
N/A |
|
R2 |
Visitor Control Plan. |
||
R3 |
Physical Access Controls Maintenance/Testing. |
||
CIP-007-7 Systems Security Management |
|||
R1.1 |
Disable/prevent unnecessary connections with routable protocol to applicable systems. |
Documentation of all ports/services and configurations/settings of mechanisms that block unnecessary connections. |
Supported |
R1.2 |
Protect against unnecessary physical port usage. |
N/A |
|
R1.3 |
Prevent sharing of CPU and memory resources (excluding storage) between VCAs that are not classified as the same impact category. |
Documentation of configurations or settings showing affinity rules. |
Supported |
R2.1 |
Cyber security patch management process (evaluate and install), including tracking newly released/available patches. |
Documentation of process and proof of monitoring sources for latest. |
Supported |
R2.2 |
Evaluation of latest cyber security patches every ≤35 days. |
Evidence of evaluation. |
Supported |
R2.3 |
Action required on patches evaluated to apply, create a dated plan, or revise an existing dated plan. |
Dated records showing implementation, or plans showing timeframe for completion. |
Supported |
R2.4 |
Planned actions for R2.3 must be within planned timeframes specified (or exception approved). |
Dated records showing implementation, or approved revisions/exceptions. |
Supported |
R3.1 |
Methods to deter, detect, and prevent malicious code. |
Evidence of process. |
Supported |
R3.2 |
Plan for mitigating detected malicious code. |
Records of process performance. |
Supported |
R3.3 |
Plan for updating "signatures or patterns" identified as malicious. |
Plans for updating process from R3.1 to address testing/installing the signatures or patterns. |
Supported |
R4.1 |
Log security events to identify cyber security incidents including successful login, failed access/login attempts, and malicious code. |
Listing of event types capable of being detected and logged. |
Supported |
R4.2 |
Alert for detected malicious code event or failure of event logging system. |
Listing of events or system configuration. |
Supported |
R4.3 |
Retain logged security events for at least 90 days. |
Documentation of event log retention process and retention of ≥90 days. |
Supported |
R4.4 |
Review a summary or sampling of logged events at least every 15 days. |
Dated documentation of review and findings. |
Supported |
R5.1 |
Methods to enforce authentication of interactive user access.Description of access authentication. |
Supported |
|
R5.2 |
Identify/inventory all enabled default/generic accounts by system, system groups, location, or system type. |
Listing of all accounts by type, in use. |
Supported |
R5.3 |
Identify all individuals with authorized access to shared accounts. |
Listing of all shared accounts and individuals who have access. |
Supported |
R5.4 |
Change default passwords. |
Dated records of updates. |
Supported |
R5.5 |
For password-only authenticated systems, also meet passwords of at least 8 characters and complex (three of more different characters of uppercase, lowercase, numeric, and non-alphanumeric) or of max. system capability. |
N/A |
|
R5.6 |
For password-only authenticated systems, passwords must be rotated at least once per 15 months. |
N/A |
|
R5.7 |
Alert for unsuccessful authentication attempts (user-defined threshold). |
Documentation of lockout parameters. |
Supported |
CIP-008-7 Incident Reporting and Response Planning |
|||
R1 |
Cyber security incident response plan. |
N/A |
|
R2 |
Cyber security incident response plan implementation/testing. |
||
R3 |
Cyber security incident response plan review/update/communicate. |
||
R4 |
Notifications and reporting for cyber security incidents. |
||
CIP-009-7 Recovery Plans for BES Cyber Systems |
|||
R1.1 |
Conditions for activation of the recovery plans. |
N/A |
|
R1.2 |
Roles and responsibilities of responders. |
N/A |
|
R1.3 |
Process(es) for backup/storage of info required to restore functionality. |
Evidence of processes/configurations for backup/storage of information to fully recover BCSs. |
Supported |
R1.4 |
Methods for verifying backup/storage. |
Evidence of successful backup (for example, logs, workflow). |
Supported |
R1.5 |
Methods to preserve data. |
Documentation of procedures for preserving data by redundancy or other disaster recovery methods. |
Supported |
R2.1 |
Testing of each recovery plan identified in R1, at least every 15 months. |
Dated evidence from an actual incident, tabletop drill/exercise, operational exercise. |
Supported |
R2.2 |
Testing a sample of information used to recover, at least every 15 months. |
Dated logs or test results. |
Supported |
R2.3 |
Test each recovery plan every three years. |
Dated evidence from an actual incident or operational exercise. |
Supported |
R3.1 |
No later than 90 days after completing a test or actual recovery: document lessons learned, update plans, communicate changes. |
N/A |
|
R3.2 |
No later than 60 days after a change is made, update and notify affected personnel. |
||
CIP-010-5 Configuration Change Management and Vulnerability Assessments |
|||
R1.1 |
Control changes made to software systems to avoid weakening systems by authorization and verification of cyber security controls. |
Documented process for any changes to be made to security controls implemented for CIP-005 and -007. This includes the installation, update, or removal of operating systems, applications, firmware, or patches. This also includes configuration changes to network access, SCI/ESPs between systems of different impact ratings, or to parent images from which child images are derived. Change management (dated requests and change application, along with output of vulnerability scans) required. |
Supported |
R1.2 |
Intended changes in production environment to be tested either in an isolated environment or in a manner that minimizes adverse effects (ensuring cyber security remains in-tact throughout duration), and test results are documented to include any differences existing between production and test environments. |
Documentation of the testing and any differences in the test and production environment. |
Supported |
R1.3 |
Verify the identity and integrity of changes before application. |
Evidence of a process that verifies intended software changes (operating systems, applications, firmware, or patches) with its source, prior to implementation. |
Supported |
R2.1 |
Method to monitor for unauthorized changes to software/settings at least every 35 days. |
Evidence of a monitoring system with records for investigation of any changes detected. |
Supported |
R3.1 |
Conduct an active vulnerability assessment of Electronic Access Controller Monitoring Systems (EACMS), Physical Access Control Systems (PACS), and Protected Cyber Assets (PCAs) at least every 15 calendar months. |
Dated documentation of assessment output |
Supported |
R3.2 |
Conduct active vulnerability assessment of high-impact SCI at least every three years. |
Dated documentation of assessment output and any differences between test and production environments. |
Supported |
R3.3 |
Conduct vulnerability assessment on any new system prior to application. |
Dated documentation of assessment output, prior to becoming an applicable system. |
Supported |
R3.4 |
Documentation and mitigation planning for vulnerability assessments, including dated plan of action. |
Reports or logs from automated mechanisms that perform remediation of assets at instantiation. |
Supported |
R4.1 |
Transient Cyber Assets (TCAs) that are self-managed must meet requirements before connection for all users and locations, only be used as needed to perform business functions. They must be securely patched and have vulnerability mitigation, and methods for mitigating malicious code. |
Documentation of management methods, overall architecture, and hardening practices, along with malicious code mitigation and access restriction. |
Supported |
R4.2 |
TCAs managed by a 3rd party must have methods to mitigate vulnerabilities and malicious code. |
Evidence of change management processes (may include cataloging machine states for all software and security patches installed, patching and update methods, whitelisting capabilities, and vulnerability mitigation practices). |
Supported |
R4.3 |
Removable media must be authorized by user and location and must have methods in place to detect malicious code and threat mitigation of it. |
Documentation of authorized removable media types and individuals or groups/roles, and the methods used to scan/detect/mitigate malicious code. |
Supported |
CIP-011-4 Information Protection |
|||
R1 |
Identification of BES Cyber System Information (BCSI), which could be leveraged to gain unauthorized access. |
N/A |
|
R2 |
Protection and secure handling of BCSI. |
N/A |
|
CIP-012-1 Communications between Control Centers |
|||
R1.1 |
Protection to mitigate risk of disclosure of real-time assessment and monitoring data. |
Documented plan meeting the security objectives and dated demonstration of implementation. |
Supported |
R1.2 |
Location of protection implemented for R1.1 |
N/A |
|
R1.3 |
Identification of responsible entities if ownership of control centers differs. |
N/A |
|
CIP-013-3 Supply Chain Risk Management (SCRM) |
|||
R1.1 |
Process to assess risk in procurement, including transitions from vendor-to-vendor, and installation of products and services. |
Documented SCRM plan |
Supported |
R1.2 |
Processes to:
|
Evidence of methods used to address all specific processes listed |
Supported |
R2 |
Implemented supply chain cyber security risk management plan |
N/A |
|
R3 |
Approval of implemented plan by CIP Senior Manager, recurring a minimum of every 15 months |
N/A |
|
