CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments

Purpose:
To prevent and detect unauthorized changes to BES Cyber Systems by specifying configuration change management and vulnerability assessment requirements in support of protecting BES Cyber Systems from compromise that could lead to misoperation or instability in the Bulk Electric System (BES).

Applicability:
4.1. Functional Entities: For the purpose of the requirements contained herein, the following list of functional entities will be collectively referred to as “Responsible Entities.” For requirements in this standard where a specific functional entity or subset of functional entities are the applicable entity or entities, the functional entity or entities are specified explicitly.

4.1.1. Balancing Authority
4.1.2. Distribution Provider that owns one or more of the following Facilities, systems, and equipment for the protection or restoration of the BES:

4.1.2.1. Each underfrequency Load shedding (UFLS) or undervoltage Load shedding (UVLS) system that:

4.1.2.1.1. is part of a Load shedding program that is subject to one or more requirements in a NERC or Regional Reliability Standard; and
4.1.2.1.2. performs automatic Load shedding under a common control system owned by the Responsible Entity, without human operator initiation, of 300 MW or more

4.1.2.2. Each Remedial Action Scheme (RAS) where the RAS is subject to one or more requirements in a NERC or Regional Reliability Standard.
4.1.2.3. Each Protection System (excluding UFLS and UVLS) that applies to Transmission where the Protection System is subject to one or more requirements in a NERC or Regional Reliability Standard.
4.1.2.4. Each Cranking Path and group of Elements meeting the initial switching requirements from a Blackstart Resource up to and including the first interconnection point of the starting station service of the next generation unit(s) to be started.

4.1.3. Generator Operator
4.1.4. Generator Owner
4.1.5. Interchange Coordinator or Interchange Authority
4.1.6. Reliability Coordinator
4.1.7. Transmission Operator
4.1.8. Transmission Owner

4.2. Facilities: For the purpose of the requirements contained herein, the following Facilities, systems, and equipment owned by each Responsible Entity in Section 4.1 above are those to which these requirements are applicable. For requirements in this standard where a specific type of Facilities, system, or equipment or subset of Facilities, systems, and equipment are applicable, these are specified explicitly.

4.2.1. Distribution Provider: One or more of the following Facilities, systems and equipment owned by the Distribution Provider for the protection or restoration of the BES:

4.2.1.1 Each UFLS or UVLS System that:

4.2.1.1.1 is part of a Load shedding program that is subject to one or more requirements in a NERC or Regional Reliability Standard; and
4.2.1.1.2 performs automatic Load shedding under a common control system owned by the Responsible Entity, without human operator initiation, of 300 MW or more.

4.2.1.2 Each RAS where the RAS is subject to one or more requirements in a NERC or Regional Reliability Standard.
4.2.1.3 Each Protection System (excluding UFLS and UVLS) that applies to Transmission where the Protection System is subject to one or more requirements in a NERC or Regional Reliability Standard.
4.2.1.4 Each Cranking Path and group of Elements meeting the initial switching requirements from a Blackstart Resource up to and including the first interconnection point of the starting station service of the next generation unit(s) to be started.

4.2.2. Responsible Entities listed in 4.1 other than Distribution Providers: All BES Facilities.
4.2.3. Exemptions: The following are exempt from Standard CIP-010-3:

4.2.3.1. Cyber Assets at Facilities regulated by the Canadian Nuclear Safety Commission.
4.2.3.2. Cyber Assets associated with communication networks and data communication links between discrete Electronic Security Perimeters.
4.2.3.3. The systems, structures, and components that are regulated by the Nuclear Regulatory Commission under a cyber security plan pursuant to 10 C.F.R. Section 73.54.
4.2.3.4. For Distribution Providers, the systems and equipment that are not included in section 4.2.1 above.
4.2.3.5. Responsible Entities that identify that they have no BES Cyber Systems categorized as high impact or medium impact according to the CIP-002-5 identification and categorization processes.

Effective Date:
See Implementation Plan for Project 2016-03.

Background:
Standard CIP-010 exists as part of a suite of CIP Standards related to cyber security, which require the initial identification and categorization of BES Cyber Systems and require a minimum level of organizational, operational and procedural controls to mitigate risk to BES Cyber Systems

Most requirements open with, “Each Responsible Entity shall implement one or more documented [processes, plan, etc.] that include the applicable items in [Table Reference].” The referenced table requires the applicable items in the procedures for the requirement’s common subject matter.

The term documented processes refers to a set of required instructions specific to the Responsible Entity and to achieve a specific outcome. This term does not imply any particular naming or approval structure beyond what is stated in the requirements. An entity should include as much as it believes necessary in its documented processes, but it must address the applicable requirements in the table.

The terms program and plan are sometimes used in place of documented processes where it makes sense and is commonly understood. For example, documented processes describing a response are typically referred to as plans (i.e., incident response plans and recovery plans). Likewise, a security plan can describe an approach involving multiple procedures to address a broad subject matter.

Similarly, the term program may refer to the organization’s overall implementation of its policies, plans, and procedures involving a subject matter. Examples in the standards include the personnel risk assessment program and the personnel training program. The full implementation of the CIP Cyber Security Standards could also be referred to as a program. However, the terms program and plan do not imply any additional requirements beyond what is stated in the standards.

Responsible Entities can implement common controls that meet requirements for multiple high and medium impact BES Cyber Systems. For example, a single training program could meet the requirements for training personnel across multiple BES Cyber Systems.

Measures for the initial requirement are simply the documented processes themselves. Measures in the table rows provide examples of evidence to show documentation and implementation of applicable items in the documented processes. These measures serve to provide guidance to entities in acceptable records of compliance and should not be viewed as an all-inclusive list.

Throughout the standards, unless otherwise stated, bulleted items in the requirements and measures are items that are linked with an “or,” and numbered items are items that are linked with an “and.”

Many references in the Applicability section use a threshold of 300 MW for UFLS and UVLS. This particular threshold of 300 MW for UVLS and UFLS was provided in Version 1 of the CIP Cyber Security Standards. The threshold remains at 300 MW since it is specifically addressing UVLS and UFLS, which are last ditch efforts to save the BES. A review of UFLS tolerances defined within regional reliability standards for UFLS program requirements to date indicates that the historical value of 300 MW represents an adequate and reasonable threshold value for allowable UFLS operational tolerances.

“Applicable Systems” Columns in Tables: Each table has an “Applicable Systems” column to further define the scope of systems to which a specific requirement row applies. The CSO706 SDT adapted this concept from the National Institute of Standards and Technology (“NIST”) Risk Management Framework as a way of applying requirements more appropriately based on impact and connectivity characteristics. The following conventions are used in the applicability column as described.
• High Impact BES Cyber Systems – Applies to BES Cyber Systems categorized as high impact according to the CIP-002-5.1 identification and categorization processes.
• Medium Impact BES Cyber Systems – Applies to BES Cyber Systems categorized as medium impact according to the CIP-002-5.1 identification and categorization processes.
Electronic Access Control or Monitoring Systems (EACMS) – Applies to each Electronic Access Control or Monitoring System associated with a referenced high impact BES Cyber System or medium impact BES Cyber System. Examples may include, but are not limited to, firewalls, authentication servers, and log monitoring and alerting systems.
Physical Access Control Systems (PACS) – Applies to each Physical Access Control System associated with a referenced high impact BES Cyber System or medium impact BES Cyber System with External Routable Connectivity. • Protected Cyber Assets (PCA) – Applies to each Protected Cyber Asset associated with a referenced high impact BES Cyber System or medium impact BES Cyber System.

Requirements and Measures
R1. Each Responsible Entity shall implement one or more documented process(es) that collectively include each of the applicable requirement parts in CIP-010-3 Table R1 – Configuration Change Management. [Violation Risk Factor: Medium] [Time Horizon: Operations Planning].
M1. Evidence must include each of the applicable documented processes that collectively include each of the applicable requirement parts in CIP-010-3 Table R1 – Configuration Change Management and additional evidence to demonstrate implementation as described in the Measures column of the table.

CIP-010-3 Table R1 – Configuration Change Management

Part Applicable Systems Requirements Measures
1.1 High Impact BES Cyber Systems and their associated:
1. EACMS;
2. PACS; and
3. PCA
Medium Impact BES Cyber Systems and their associated:
1. EACMS;
2. PACS; and
3. PCA
For a change that deviates from the existing baseline configuration, update the baseline configuration as necessary within 30 calendar days of completing the change. An example of evidence may include, but is not limited to, updated baseline documentation with a date that is within 30 calendar days of the date of the completion of the change.
1.2 High Impact BES Cyber Systems and their associated:
1. EACMS;
2. PACS; and
3. PCA
Medium Impact BES Cyber Systems and their associated:
1. EACMS;
2. PACS; and
3. PCA
Authorize and document changes that deviate from the existing baseline configuration. Examples of evidence may include, but are not limited to:
• A change request record and associated electronic authorization (performed by the individual or group with the authority to authorize the change) in a change management system for each change; or
• Documentation that the change was performed in accordance with the requirement.
1.3 High Impact BES Cyber Systems and their associated:
1. EACMS;
2. PACS; and
3. PCA
Medium Impact BES Cyber Systems and their associated:
1. EACMS;
2. PACS; and
3. PCA
For a change that deviates from the existing baseline configuration, update the baseline configuration as necessary within 30 calendar days of completing the change. An example of evidence may include, but is not limited to, updated baseline documentation with a date that is within 30 calendar days of the date of the completion of the change.
1.4 High Impact BES Cyber Systems and their associated:
1. EACMS;
2. PACS; and
3. PCA
Medium Impact BES Cyber Systems and their associated:
1. EACMS;
2. PACS; and
3. PCA
For a change that deviates from the existing baseline configuration:
1.4.1. Prior to the change, determine required cyber security controls in CIP-005 and CIP-007 that could be impacted by the change;
1.4.2. Following the change, verify that required cyber security controls determined in 1.4.1 are not adversely affected; and
1.4.3. Document the results of the verification.
An example of evidence may include, but is not limited to, a list of cyber security controls verified or tested along with the dated test results.
1.5 High Impact BES Cyber Systems Where technically feasible, for each change that deviates from the existing baseline configuration:
1.5.1. Prior to implementing any change in the production environment, test the changes in a test environment or test the changes in a production environment where the test is performed in a manner that minimizes adverse effects, that models the baseline configuration to ensure that required cyber security controls in CIP-005 and CIP-007 are not adversely affected; and
1.5.2. Document the results of the testing and, if a test environment was used, the differences between the test environment and the production environment, including a description of the measures used to account for any differences in operation between the test and production environments
An example of evidence may include, but is not limited to, a list of cyber security controls tested along with successful test results and a list of differences between the production and test environments with descriptions of how any differences were accounted for, including of the date of the test.
1.6 High Impact BES Cyber Systems
Medium Impact BES Cyber Systems

Note: Implementation does not require the Responsible Entity to renegotiate or abrogate existing contracts (including amendments to master agreements and purchase orders). Additionally, the following issues are beyond the scope of Part 1.6: (1) the actual terms and conditions of a procurement contract; and (2) vendor performance and adherence to a contract.

Prior to a change that deviates from the existing baseline configuration associated with baseline items in Parts 1.1.1, 1.1.2, and 1.1.5, and when the method to do so is available to the Responsible Entity from the software source:
1.6.1. Verify the identity of the software source; and
1.6.2. Verify the integrity of the software obtained from the software source.
An example of evidence may include, but is not limited to a change request record that demonstrates the verification of identity of the software source and integrity of the software was performed prior to the baseline change or a process which documents the mechanisms in place that would automatically ensure the identity of the software source and integrity of the software.

R2. Each Responsible Entity shall implement one or more documented process(es) that collectively include each of the applicable requirement parts in CIP-010-3 Table R2 – Configuration Monitoring. [Violation Risk Factor: Medium] [Time Horizon: Operations Planning].
M2. Evidence must include each of the applicable documented processes that collectively include each of the applicable requirement parts in CIP-010-3 Table R2 – Configuration Monitoring and additional evidence to demonstrate implementation as described in the Measures column of the table.

CIP-010-3 Table R2 – Configuration Monitoring

Part Applicable Systems Requirements Measures
2.1 High Impact BES Cyber Systems and their associated:
1. EACMS; and
2. PCA
Monitor at least once every 35 calendar days for changes to the baseline configuration (as described in Requirement R1, Part 1.1). Document and investigate detected unauthorized changes. An example of evidence may include, but is not limited to, logs from a system that is monitoring the configuration along with records of investigation for any unauthorized changes that were detected.

R3. Each Responsible Entity shall implement one or more documented process(es) that collectively include each of the applicable requirement parts in CIP-010-3 Table R3– Vulnerability Assessments. [Violation Risk Factor: Medium] [Time Horizon: Long-term Planning and Operations Planning]
M3. Evidence must include each of the applicable documented processes that collectively include each of the applicable requirement parts in CIP-010-3 Table R3 – Vulnerability Assessments and additional evidence to demonstrate implementation as described in the Measures column of the table.

CIP-010-3 Table R3 – Vulnerability Assessments

Part Applicable Systems Requirements Measures
3.1 High Impact BES Cyber Systems and their associated:
1. EACMS;
2. PACS; and
3. PCA

Medium Impact BES Cyber Systems and their associated:
1. EACMS;
2. PACS; and
3. PCA

At least once every 15 calendar months, conduct a paper or active vulnerability assessment. Examples of evidence may include, but are not limited to:
• A document listing the date of the assessment (performed at least once every 15 calendar months), the controls assessed for each BES Cyber System along with the method of assessment; or
• A document listing the date of the assessment and the output of any tools used to perform the assessment.
3.2 High Impact BES Cyber Systems Where technically feasible, at least once every 36 calendar months:
3.2.1 Perform an active vulnerability assessment in a test environment, or perform an active vulnerability assessment in a production environment where the test is performed in a manner that minimizes adverse effects, that models the baseline configuration of the BES Cyber System in a production environment; and
3.2.2 Document the results of the testing and, if a test environment was used, the differences between the test environment and the production environment, including a description of the measures used to account for any differences in operation between the test and production environments.
An example of evidence may include, but is not limited to, a document listing the date of the assessment (performed at least once every 36 calendar months), the output of the tools used to perform the assessment, and a list of differences between the production and test environments with descriptions of how any differences were accounted for in conducting the assessment.
3.3 High Impact BES Cyber Systems and their associated:
1. EACMS;
2. PCA
Prior to adding a new applicable Cyber Asset to a production environment, perform an active vulnerability assessment of the new Cyber Asset, except for CIP Exceptional Circumstances and like replacements of the same type of Cyber Asset with a baseline configuration that models an existing baseline configuration of the previous or other existing Cyber Asset. An example of evidence may include, but is not limited to, a document listing the date of the assessment (performed prior to the commissioning of the new Cyber Asset) and the output of any tools used to perform the assessment.
3.4 High Impact BES Cyber Systems and their associated:
1. EACMS;
2. PACS; and
3. PCA

Medium Impact BES Cyber Systems and their associated:
1. EACMS;
2. PACS; and
3. PCA

Document the results of the assessments conducted according to Parts 3.1, 3.2, and 3.3 and the action plan to remediate or mitigate vulnerabilities identified in the assessments including the planned date of completing the action plan and the execution status of any remediation or mitigation action items. An example of evidence may include, but is not limited to, a document listing the results or the review or assessment, a list of action items, documented proposed dates of completion for the action plan, and records of the status of the action items (such as minutes of a status meeting, updates in a work order system, or a spreadsheet tracking the action items)

R4. Each Responsible Entity, for its high impact and medium impact BES Cyber Systems and associated Protected Cyber Assets, shall implement, except under CIP Exceptional Circumstances, one or more documented plan(s) for Transient Cyber Assets and Removable Media that include the sections in Attachment 1. [Violation Risk Factor: Medium] [Time Horizon: Long-term Planning and Operations Planning]
M4. Evidence shall include each of the documented plan(s) for Transient Cyber Assets and Removable Media that collectively include each of the applicable sections in Attachment 1 and additional evidence to demonstrate implementation of plan(s) for Transient Cyber Assets and Removable Media. Additional examples of evidence per section are located in Attachment 2. If a Responsible Entity does not use Transient Cyber Asset(s) or Removable Media, examples of evidence include, but are not limited to, a statement, policy, or other document that states the Responsible Entity does not use Transient Cyber Asset(s) or Removable Media.


Top