Download:
pdf |
pdfCIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments
A. Introduction
1.
Title:
Cyber Security — Configuration Change Management and Vulnerability
Assessments
2.
Number:
3.
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).
4.
Applicability:
CIP-010-3
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
Page 1 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments
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.
Page 2 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments
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.
5.
Effective Date:
See Implementation Plan for Project 2016-03.
6.
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.
Page 3 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments
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.
Page 4 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments
•
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.
Page 5 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments
B. 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
1.1
Applicable Systems
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
Requirements
Develop a baseline configuration,
individually or by group, which shall
include the following items:
1.1.1. Operating system(s) (including
version) or firmware where no
independent operating system
exists;
1.1.2. Any commercially available or
open-source application
software (including version)
intentionally installed;
Measures
Examples of evidence may include, but
are not limited to:
•
A spreadsheet identifying the
required items of the baseline
configuration for each Cyber Asset,
individually or by group; or
•
A record in an asset management
system that identifies the required
items of the baseline configuration
for each Cyber Asset, individually or
by group.
1.1.3. Any custom software installed;
1.1.4. Any logical network accessible
ports; and
1.1.5. Any security patches applied.
Page 6 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments
CIP-010-3 Table R1 – Configuration Change Management
Part
1.2
Applicable Systems
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
Requirements
Authorize and document changes that
deviate from the existing baseline
configuration.
Measures
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.
Page 7 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments
CIP-010-3 Table R1 – Configuration Change Management
Part
1.3
Applicable Systems
High Impact BES Cyber Systems and
their associated:
1. EACMS;
2. PACS; and
3. PCA
Requirements
Measures
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.
For a change that deviates from the
existing baseline configuration:
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.
Medium Impact BES Cyber Systems
and their associated:
1. EACMS;
2. PACS; and
3. PCA
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
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.
Page 8 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments
CIP-010-3 Table R1 – Configuration Change Management
Part
1.5
Applicable Systems
High Impact BES Cyber Systems
Requirements
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
Measures
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.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.
Page 9 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments
CIP-010-3 Table R1 – Configuration Change Management
Part
1.6
R2.
Applicable Systems
High Impact BES Cyber Systems
Requirements
Prior to a change that deviates from the
existing baseline configuration
associated with baseline items in Parts
Medium Impact BES Cyber Systems
1.1.1, 1.1.2, and 1.1.5, and when the
method to do so is available to the
Note: Implementation does not require Responsible Entity from the software
the Responsible Entity to renegotiate
source:
or abrogate existing contracts
(including amendments to master
1.6.1. Verify the identity of the
agreements and purchase orders).
software source; and
Additionally, the following issues are
1.6.2. Verify the integrity of the
beyond the scope of Part 1.6: (1) the
software obtained from the
actual terms and conditions of a
software source.
procurement contract; and (2) vendor
performance and adherence to a
contract.
Measures
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.
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.
Page 10 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments
CIP-010-3 Table R2 – Configuration Monitoring
Part
2.1
R3.
Applicable Systems
High Impact BES Cyber Systems and
their associated:
1. EACMS; and
2. PCA
Requirements
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.
Measures
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.
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.
Page 11 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments
CIP-010-3 Table R3 – Vulnerability Assessments
Part
3.1
Applicable Systems
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
Requirements
At least once every 15 calendar
months, conduct a paper or active
vulnerability assessment.
Measures
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.
Page 12 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments
CIP-010-3 Table R3 – Vulnerability Assessments
Part
3.2
Applicable Systems
High Impact BES Cyber Systems
Requirements
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
Measures
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.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.
Page 13 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments
CIP-010-3 Table R3 – Vulnerability Assessments
Part
Applicable Systems
Requirements
Measures
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
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).
Medium Impact BES Cyber Systems
and their associated:
1. EACMS;
2. PACS; and
3. PCA
Page 14 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments
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.
Page 15 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments
C. Compliance
1.
Compliance Monitoring Process
1.1. Compliance Enforcement Authority: “Compliance Enforcement Authority”
means NERC or the Regional Entity, or any entity as otherwise designated by an
Applicable Governmental Authority, in their respective roles of monitoring
and/or enforcing compliance with mandatory and enforceable Reliability
Standards in their respective jurisdictions.
1.2. Evidence Retention: The following evidence retention period(s) identify the
period of time an entity is required to retain specific evidence to demonstrate
compliance. For instances where the evidence retention period specified below
is shorter than the time since the last audit, the Compliance Enforcement
Authority may ask an entity to provide other evidence to show that it was
compliant for the full-time period since the last audit.
The applicable entity shall keep data or evidence to show compliance as
identified below unless directed by its Compliance Enforcement Authority to
retain specific evidence for a longer period of time as part of an investigation.
•
Each applicable entity shall retain evidence of each requirement in this
standard for three calendar years.
•
If an applicable entity is found non-compliant, it shall keep information
related to the non-compliance until mitigation is complete and approved or
for the time specified above, whichever is longer.
• The CEA shall keep the last audit records and all requested and submitted
subsequent audit records.
1.3. Compliance Monitoring and Enforcement Program: As defined in the NERC
Rules of Procedure, “Compliance Monitoring and Enforcement Program” refers
to the identification of the processes that will be used to evaluate data or
information for the purpose of assessing performance or outcomes with the
associated Reliability Standard.
Page 16 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments
Violation Severity Levels
R#
R1.
Violation Severity Levels
Lower VSL
Moderate VSL
High VSL
Severe VSL
The Responsible Entity has
documented and
implemented a
configuration change
management process(es)
that includes only four of
the required baseline items
listed in 1.1.1 through 1.1.5.
(1.1)
The Responsible Entity has
documented and
implemented a
configuration change
management process(es)
that includes only three of
the required baseline items
listed in 1.1.1 through 1.1.5.
(1.1)
The Responsible Entity has
documented and
implemented a
configuration change
management process(es)
that includes only two of
the required baseline items
listed in 1.1.1 through
1.1.5. (1.1)
The Responsible Entity has
not documented or
implemented any
configuration change
management process(es).
(R1)
OR
The Responsible Entity has
a process as specified in
Part 1.6 to verify the
identity of the software
source (1.6.1) but does not
have a process as specified
in Part 1.6 to verify the
integrity of the software
provided by the software
source when the method
to do so is available to the
Responsible Entity from
the software source.
(1.6.2)
OR
The Responsible Entity has
documented and
implemented a
configuration change
management process(es)
that includes only one of
the required baseline items
listed in 1.1.1 through 1.1.5.
(1.1)
OR
The Responsible Entity does
not have a process(es) that
requires authorization and
documentation of changes
that deviate from the
existing baseline
configuration. (1.2)
Page 17 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments
R#
Violation Severity Levels
Lower VSL
Moderate VSL
High VSL
Severe VSL
OR
The Responsible Entity does
not have a process(es) to
update baseline
configurations within 30
calendar days of completing
a change(s) that deviates
from the existing baseline
configuration.(1.3)
OR
The Responsible Entity does
not have a process(es) to
determine required security
controls in CIP-005 and CIP007 that could be impacted
by a change(s) that deviates
from the existing baseline
configuration. (1.4.1)
OR
The Responsible Entity has
a process(es) to determine
required security controls in
CIP-005 and CIP-007 that
could be impacted by a
change(s) that deviates
from the existing baseline
Page 18 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments
R#
Violation Severity Levels
Lower VSL
Moderate VSL
High VSL
Severe VSL
configuration but did not
verify and document that
the required controls were
not adversely affected
following the change. (1.4.2
& 1.4.3)
OR
The Responsible Entity does
not have a process for
testing changes in an
environment that models
the baseline configuration
prior to implementing a
change that deviates from
baseline configuration.
(1.5.1)
OR
The Responsible Entity does
not have a process to
document the test results
and, if using a test
environment, document
the differences between
the test and production
environments. (1.5.2)
Page 19 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments
Violation Severity Levels
R#
Lower VSL
Moderate VSL
High VSL
Severe VSL
OR
The Responsible Entity does
not have a process as
specified in Part 1.6 to
verify the identity of the
software source and the
integrity of the software
provided by the software
source when the method to
do so is available to the
Responsible Entity from the
software source. (1.6)
R2.
R3.
N/A
The Responsible Entity has
implemented one or more
documented vulnerability
assessment processes for
each of its applicable BES
Cyber Systems, but has
N/A
The Responsible Entity has
implemented one or more
documented vulnerability
assessment processes for
each of its applicable BES
Cyber Systems, but has
N/A
The Responsible Entity has
implemented one or more
documented vulnerability
assessment processes for
each of its applicable BES
Cyber Systems, but has
The Responsible Entity has
not documented or
implemented a process(es)
to monitor for, investigate,
and document detected
unauthorized changes to the
baseline at least once every
35 calendar days. (2.1)
The Responsible Entity has
not implemented any
vulnerability assessment
processes for one of its
Page 20 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments
Violation Severity Levels
R#
Lower VSL
Moderate VSL
performed a vulnerability
assessment more than 15
months, but less than 18
months, since the last
assessment on one of its
applicable BES Cyber
Systems. (3.1)
performed a vulnerability
assessment more than 18
months, but since the last
assessment on one of its
applicable BES Cyber
Systems. (3.1)
OR
The Responsible Entity has
implemented one or more
documented active
vulnerability assessment
processes for Applicable
Systems, but has performed
an active vulnerability
assessment more than 39
months, but less than 42
months, since the last active
assessment on one of its
applicable BES Cyber
Systems. (3.2)
The Responsible Entity has
implemented one or more
documented active
vulnerability assessment
processes for Applicable
Systems, but has performed
an active vulnerability
assessment more than 36
months, but less than 39
months, since the last active
assessment on one of its
applicable BES Cyber
Systems. (3.2)
OR
High VSL
performed a vulnerability
assessment more than 21
months, but less than 24
months, since the last
assessment on one of its
applicable BES Cyber
Systems. (3.1)
OR
The Responsible Entity has
implemented one or more
documented active
vulnerability assessment
processes for Applicable
Systems, but has
performed an active
vulnerability assessment
more than 42 months, but
less than 45 months, since
the last active assessment
on one of its applicable BES
Cyber Systems. (3.2)
Severe VSL
applicable BES Cyber
Systems. (R3)
OR
The Responsible Entity has
implemented one or more
documented vulnerability
assessment processes for
each of its applicable BES
Cyber Systems, but has
performed a vulnerability
assessment more than 24
months since the last
assessment on one of its
applicable BES Cyber
Systems. (3.1)
OR
The Responsible Entity has
implemented one or more
documented active
vulnerability assessment
processes for Applicable
Systems, but has performed
an active vulnerability
assessment more than 45
months since the last active
assessment on one of its
Page 21 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments
R#
Violation Severity Levels
Lower VSL
Moderate VSL
High VSL
Severe VSL
applicable BES Cyber
Systems.(3.2)
OR
The Responsible Entity has
implemented and
documented one or more
vulnerability assessment
processes for each of its
applicable BES Cyber
Systems, but did not
perform the active
vulnerability assessment in
a manner that models an
existing baseline
configuration of its
applicable BES Cyber
Systems. (3.3)
OR
The Responsible Entity has
implemented one or more
documented vulnerability
assessment processes for
each of its applicable BES
Cyber Systems, but has not
documented the results of
the vulnerability
Page 22 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments
Violation Severity Levels
R#
Lower VSL
Moderate VSL
High VSL
Severe VSL
assessments, the action
plans to remediate or
mitigate vulnerabilities
identified in the
assessments, the planned
date of completion of the
action plan, and the
execution status of the
mitigation plans. (3.4)
R4.
The Responsible Entity
documented its plan(s) for
Transient Cyber Assets and
Removable Media, but
failed to manage its
Transient Cyber Asset(s)
according to CIP-010-3,
Requirement R4,
Attachment 1, Section 1.1.
(R4)
The Responsible Entity
documented its plan(s) for
Transient Cyber Assets and
Removable Media, but
failed to implement the
Removable Media sections
according to CIP-010-3,
Requirement R4,
Attachment 1, Section 3.
(R4)
The Responsible Entity
documented its plan(s) for
Transient Cyber Assets and
Removable Media, but
failed to authorize its
Transient Cyber Asset(s)
according to CIP-010-3,
Requirement R4,
Attachment 1, Section 1.2.
(R4)
OR
OR
OR
The Responsible Entity
documented its plan(s) for
Transient Cyber Assets and
Removable Media, but
failed to document the
Removable Media sections
The Responsible Entity
documented its plan(s) for
Transient Cyber Assets and
Removable Media plan, but
failed to document
mitigation of software
The Responsible Entity
documented its plan(s) for
Transient Cyber Assets and
Removable Media, but
failed to implement
mitigation of software
The Responsible Entity failed
to document or implement
one or more plan(s) for
Transient Cyber Assets and
Removable Media according
to CIP-010-3, Requirement
R4. (R4)
Page 23 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments
Violation Severity Levels
R#
Lower VSL
Moderate VSL
High VSL
according to CIP-010-3,
Requirement R4,
Attachment 1, Section 3.
(R4)
vulnerabilities, mitigation
for the introduction of
malicious code, or
mitigation of the risk of
unauthorized use for
Transient Cyber Assets
managed by the
Responsible Entity
according to CIP-010-3,
Requirement R4,
Attachment 1, Sections 1.3,
1.4, and 1.5. (R4)
vulnerabilities, mitigation
for the introduction of
malicious code, or
mitigation of the risk of
unauthorized use for
Transient Cyber Assets
managed by the
Responsible Entity
according to CIP-010-3,
Requirement R4,
Attachment 1, Sections 1.3,
1.4, and 1.5. (R4)
OR
OR
OR
The Responsible Entity
documented its plan(s) for
Transient Cyber Assets and
Removable Media, but failed
to document authorization
for Transient Cyber Assets
managed by the Responsible
Entity according to CIP-0103, Requirement R4,
Attachment 1, Section 1.2.
(R4)
The Responsible Entity
documented its plan(s) for
Transient Cyber Assets and
Removable Media, but failed
to document mitigation of
software vulnerabilities or
mitigation for the
introduction of malicious
code for Transient Cyber
Assets managed by a party
other than the Responsible
Entity according to CIP-0103, Requirement R4,
Severe VSL
The Responsible Entity
documented its plan(s) for
Transient Cyber Assets and
Removable Media, but failed
to implement mitigation of
software vulnerabilities or
mitigation for the
introduction of malicious
code for Transient Cyber
Assets managed by a party
other than the Responsible
Entity according to CIP-0103, Requirement R4,
Page 24 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments
R#
Violation Severity Levels
Lower VSL
Moderate VSL
Attachment 1, Sections 2.1,
2.2, and 2.3. (R4)
High VSL
Severe VSL
Attachment 1, Sections 2.1,
2.2, and 2.3. (R4)
D. Regional Variances
None.
E. Associated Documents
None.
Page 25 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments
Version History
Version
Date
Action
Change
Tracking
1
11/26/12
Adopted by the NERC Board of Trustees.
Developed to
define
the configuratio
n change
management
and vulnerability
assessment
requirements
in coordination
with other CIP
standards and to
address the
balance of the
FERC directives
in its Order 706.
1
11/22/13
FERC Order issued approving CIP-010-1.
(Order becomes effective on 2/3/14.)
2
11/13/14
Adopted by the NERC Board of Trustees.
Addressed two
FERC directives
from Order No.
791 related to
identify, assess,
and correct
language and
communication
networks.
2
2/12/15
Adopted by the NERC Board of Trustees.
Replaces the
version adopted
by the Board on
11/13/2014.
Revised version
addresses
remaining
directives from
Order No. 791
related to
transient devices
and low impact
Page 26 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability Assessments
Version
Date
Action
Change
Tracking
BES Cyber
Systems.
2
1/21/16
FERC Order issued approving CIP-010-3.
Docket No. RM15-14-000
3
07/20/17
3
08/10/17
Modified to address certain directives in
FERC Order No. 829.
Adopted by the NERC Board of Trustees.
Revised
Page 27 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability
Assessments
CIP-010-3 - Attachment 1
Required Sections for Plans for Transient Cyber Assets and Removable Media
Responsible Entities shall include each of the sections provided below in their plan(s) for
Transient Cyber Assets and Removable Media as required under Requirement R4.
Section 1.
Transient Cyber Asset(s) Managed by the Responsible Entity.
1.1.
Transient Cyber Asset Management: Responsible Entities shall manage Transient
Cyber Asset(s), individually or by group: (1) in an ongoing manner to ensure
compliance with applicable requirements at all times, (2) in an on-demand manner
applying the applicable requirements before connection to a BES Cyber System, or
(3) a combination of both (1) and (2) above.
1.2.
Transient Cyber Asset Authorization: For each individual or group of Transient
Cyber Asset(s), each Responsible Entity shall authorize:
1.2.1. Users, either individually or by group or role;
1.2.2. Locations, either individually or by group; and
1.2.3. Uses, which shall be limited to what is necessary to perform business
functions.
1.3.
1.4.
1.5.
Software Vulnerability Mitigation: Use one or a combination of the following
methods to achieve the objective of mitigating the risk of vulnerabilities posed by
unpatched software on the Transient Cyber Asset (per Transient Cyber Asset
capability):
•
Security patching, including manual or managed updates;
•
Live operating system and software executable only from read-only media;
•
System hardening; or
•
Other method(s) to mitigate software vulnerabilities.
Introduction of Malicious Code Mitigation: Use one or a combination of the
following methods to achieve the objective of mitigating the introduction of
malicious code (per Transient Cyber Asset capability):
•
Antivirus software, including manual or managed updates of signatures or
patterns;
•
Application whitelisting; or
•
Other method(s) to mitigate the introduction of malicious code.
Unauthorized Use Mitigation: Use one or a combination of the following methods
to achieve the objective of mitigating the risk of unauthorized use of Transient
Cyber Asset(s):
Page 28 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability
Assessments
•
Restrict physical access;
•
Full-disk encryption with authentication;
•
Multi-factor authentication; or
•
Other method(s) to mitigate the risk of unauthorized use.
Section 2.
2.1
2.2
2.3
Section 3.
3.1.
Transient Cyber Asset(s) Managed by a Party Other than the Responsible Entity.
Software Vulnerabilities Mitigation: Use one or a combination of the following
methods to achieve the objective of mitigating the risk of vulnerabilities posed by
unpatched software on the Transient Cyber Asset (per Transient Cyber Asset
capability):
•
Review of installed security patch(es);
•
Review of security patching process used by the party;
•
Review of other vulnerability mitigation performed by the party; or
•
Other method(s) to mitigate software vulnerabilities.
Introduction of malicious code mitigation: Use one or a combination of the
following methods to achieve the objective of mitigating malicious code (per
Transient Cyber Asset capability):
•
Review of antivirus update level;
•
Review of antivirus update process used by the party;
•
Review of application whitelisting used by the party;
•
Review use of live operating system and software executable only from readonly media;
•
Review of system hardening used by the party; or
•
Other method(s) to mitigate malicious code.
For any method used to mitigate software vulnerabilities or malicious code as
specified in 2.1 and 2.2, Responsible Entities shall determine whether any
additional mitigation actions are necessary and implement such actions prior to
connecting the Transient Cyber Asset.
Removable Media
Removable Media Authorization: For each individual or group of Removable
Media, each Responsible Entity shall authorize:
3.1.1. Users, either individually or by group or role; and
3.1.2. Locations, either individually or by group.
Page 29 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability
Assessments
3.2.
Malicious Code Mitigation: To achieve the objective of mitigating the threat of
introducing malicious code to high impact or medium impact BES Cyber Systems
and their associated Protected Cyber Assets, each Responsible Entity shall:
3.2.1. Use method(s) to detect malicious code on Removable Media using a Cyber
Asset other than a BES Cyber System or Protected Cyber Assets; and
3.2.2. Mitigate the threat of detected malicious code on Removable Media prior
to connecting the Removable Media to a high impact or medium impact
BES Cyber System or associated Protected Cyber Assets.
Page 30 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability
Assessments
CIP-010-3 - Attachment 2
Examples of Evidence for Plans for Transient Cyber Assets and Removable Media
Section 1.1: Examples of evidence for Section 1.1 may include, but are not limited to, the
method(s) of management for the Transient Cyber Asset(s). This can be
included as part of the Transient Cyber Asset plan(s), part of the documentation
related to authorization of Transient Cyber Asset(s) managed by the
Responsible Entity or part of a security policy.
Section 1.2: Examples of evidence for Section 1.2 may include, but are not limited to,
documentation from asset management systems, human resource
management systems, or forms or spreadsheets that show authorization of
Transient Cyber Asset(s) managed by the Responsible Entity. Alternatively, this
can be documented in the overarching plan document.
Section 1.3: Examples of evidence for Section 1.3 may include, but are not limited to,
documentation of the method(s) used to mitigate software vulnerabilities
posed by unpatched software such as security patch management
implementation, the use of live operating systems from read-only media,
system hardening practices or other method(s) to mitigate the software
vulnerability posed by unpatched software. Evidence can be from change
management systems, automated patch management solutions, procedures or
processes associated with using live operating systems, or procedures or
processes associated with system hardening practices. If a Transient Cyber
Asset does not have the capability to use method(s) that mitigate the risk from
unpatched software, evidence may include documentation by the vendor or
Responsible Entity that identifies that the Transient Cyber Asset does not have
the capability.
Section 1.4: Examples of evidence for Section 1.4 may include, but are not limited to,
documentation of the method(s) used to mitigate the introduction of malicious
code such as antivirus software and processes for managing signature or
pattern updates, application whitelisting practices, processes to restrict
communication, or other method(s) to mitigate the introduction of malicious
code. If a Transient Cyber Asset does not have the capability to use method(s)
that mitigate the introduction of malicious code, evidence may include
documentation by the vendor or Responsible Entity that identifies that the
Transient Cyber Asset does not have the capability.
Section 1.5: Examples of evidence for Section 1.5 may include, but are not limited to,
documentation through policies or procedures of the method(s) to restrict
physical access; method(s) of the full-disk encryption solution along with the
authentication protocol; method(s) of the multi-factor authentication solution;
or documentation of other method(s) to mitigate the risk of unauthorized use.
Page 31 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability
Assessments
Section 2.1: Examples of evidence for Section 2.1 may include, but are not limited to,
documentation from change management systems, electronic mail or
procedures that document a review of installed security patch(es); memoranda,
electronic mail, policies or contracts from parties other than the Responsible
Entity that identify the security patching process or vulnerability mitigation
performed by the party other than the Responsible Entity; evidence from
change management systems, electronic mail, system documentation or
contracts that identifies acceptance by the Responsible Entity that the practices
of the party other than the Responsible Entity are acceptable; or
documentation of other method(s) to mitigate software vulnerabilities for
Transient Cyber Asset(s) managed by a party other than the Responsible Entity.
If a Transient Cyber Asset does not have the capability to use method(s) that
mitigate the risk from unpatched software, evidence may include
documentation by the Responsible Entity or the party other than the
Responsible Entity that identifies that the Transient Cyber Asset does not have
the capability.
Section 2.2: Examples of evidence for Section 2.2 may include, but are not limited to,
documentation from change management systems, electronic mail or
procedures that document a review of the installed antivirus update level;
memoranda, electronic mail, system documentation, policies or contracts from
the party other than the Responsible Entity that identify the antivirus update
process, the use of application whitelisting, use of live of operating systems or
system hardening performed by the party other than the Responsible Entity;
evidence from change management systems, electronic mail or contracts that
identifies the Responsible Entity’s acceptance that the practices of the party
other than the Responsible Entity are acceptable; or documentation of other
method(s) to mitigate malicious code for Transient Cyber Asset(s) managed by a
party other than the Responsible Entity. If a Transient Cyber Asset does not
have the capability to use method(s) that mitigate the introduction of malicious
code, evidence may include documentation by the Responsible Entity or the
party other than the Responsible Entity that identifies that the Transient Cyber
Asset does not have the capability.
Section 2.3: Examples of evidence for Section 2.3 may include, but are not limited to,
documentation from change management systems, electronic mail, or contracts
that identifies a review to determine whether additional mitigations are
necessary and that they have been implemented prior to connecting the
Transient Cyber Asset managed by a party other than the Responsible Entity.
Section 3.1: Examples of evidence for Section 3.1 may include, but are not limited to,
documentation from asset management systems, human resource
management systems, forms or spreadsheets that shows authorization of
Removable Media. The documentation must identify Removable Media,
individually or by group of Removable Media, along with the authorized users,
Page 32 of 47
CIP-010-3 – Cyber Security — Configuration Change Management and Vulnerability
Assessments
either individually or by group or role, and the authorized locations, either
individually or by group.
Section 3.2: Examples of evidence for Section 3.2 may include, but are not limited to,
documented process(es) of the method(s) used to mitigate malicious code such
as results of scan settings for Removable Media, or implementation of ondemand scanning. Documented process(es) for the method(s) used for
mitigating the threat of detected malicious code on Removable Media, such as
logs from the method(s) used to detect malicious code that show the results of
scanning and that show mitigation of detected malicious code on Removable
Media or documented confirmation by the entity that the Removable Media
was deemed to be free of malicious code.
Page 33 of 47
Guidelines and Technical Basis
Guidelines and Technical Basis
Section 4 – Scope of Applicability of the CIP Cyber Security Standards
Section “4. Applicability” of the standards provides important information for Responsible
Entities to determine the scope of the applicability of the CIP Cyber Security Requirements.
Section “4.1. Functional Entities” is a list of NERC functional entities to which the standard
applies. If the entity is registered as one or more of the functional entities listed in Section 4.1,
then the NERC CIP Cyber Security Standards apply. Note that there is a qualification in Section
4.1 that restricts the applicability in the case of Distribution Providers to only those that own
certain types of systems and equipment listed in 4.2.
Section “4.2. Facilities” defines the scope of the Facilities, systems, and equipment owned by
the Responsible Entity, as qualified in Section 4.1, that is subject to the requirements of the
standard. As specified in the exemption section 4.2.3.5, this standard does not apply to
Responsible Entities that do not have High Impact or Medium Impact BES Cyber Systems under
CIP-002-5.1’s categorization. In addition to the set of BES Facilities, Control Centers, and other
systems and equipment, the list includes the set of systems and equipment owned by
Distribution Providers. While the NERC Glossary term “Facilities” already includes the BES
characteristic, the additional use of the term BES here is meant to reinforce the scope of
applicability of these Facilities where it is used, especially in this applicability scoping section.
This in effect sets the scope of Facilities, systems, and equipment that is subject to the
standards.
Requirement R1:
Baseline Configuration
The concept of establishing a Cyber Asset’s baseline configuration is meant to provide clarity on
requirement language found in previous CIP standard versions. Modification of any item within
an applicable Cyber Asset’s baseline configuration provides the triggering mechanism for when
entities must apply change management processes.
Baseline configurations in CIP-010 consist of five different items: Operating system/firmware,
commercially available software or open-source application software, custom software, logical
network accessible port identification, and security patches. Operating system information
identifies the software and version that is in use on the Cyber Asset. In cases where an
independent operating system does not exist (such as for a protective relay), then firmware
information should be identified. Commercially available or open-source application software
identifies applications that were intentionally installed on the cyber asset. The use of the term
“intentional” was meant to ensure that only software applications that were determined to be
necessary for Cyber Asset use should be included in the baseline configuration. The SDT does
not intend for notepad, calculator, DLL, device drivers, or other applications included in an
operating system package as commercially available or open-source application software to be
included. Custom software installed may include scripts developed for local entity functions or
Page 34 of 47
Guidelines and Technical Basis
other custom software developed for a specific task or function for the entity’s use. If
additional software was intentionally installed and is not commercially available or opensource, then this software could be considered custom software. If a specific device needs to
communicate with another device outside the network, communications need to be limited to
only the devices that need to communicate per the requirement in CIP-007-6. Those ports
which are accessible need to be included in the baseline. Security patches applied would
include all historical and current patches that have been applied on the cyber asset. While CIP007-6 Requirement R2, Part 2.1 requires entities to track, evaluate, and install security patches,
CIP-010 Requirement R1, Part 1.1.5 requires entities to list all applied historical and current
patches.
Further guidance can be understood with the following example that details the baseline
configuration for a serial-only microprocessor relay:
Asset #051028 at Substation Alpha
•
R1.1.1 – Firmware: [MANUFACTURER]-[MODEL]-XYZ-1234567890-ABC
•
R1.1.2 – Not Applicable
•
R1.1.3 – Not Applicable
•
R1.1.4 – Not Applicable
•
R1.1.5 – Patch 12345, Patch 67890, Patch 34567, Patch 437823
Also, for a typical IT system, the baseline configuration could reference an IT standard that
includes configuration details. An entity would be expected to provide that IT standard as part
of their compliance evidence.
Cyber Security Controls
The use of cyber security controls refers specifically to controls referenced and applied
according to CIP-005 and CIP-007. The concept presented in the relevant requirement subparts in CIP-010 R1 is that an entity is to identify/verify controls from CIP-005 and CIP-007 that
could be impacted for a change that deviates from the existing baseline configuration. The SDT
does not intend for Responsible Entities to identify/verify all controls located within CIP-005
and CIP-007 for each change. The Responsible Entity is only to identify/verify those control(s)
that could be affected by the baseline configuration change. For example, changes that affect
logical network ports would only involve CIP-007 R1 (Ports and Services), while changes that
affect security patches would only involve CIP-007 R2 (Security Patch Management). The SDT
chose not to identify the specific requirements from CIP-005 and CIP-007 in CIP-010 language as
the intent of the related requirements is to be able to identify/verify any of the controls in
those standards that are affected as a result of a change to the baseline configuration. The SDT
believes it possible that all requirements from CIP-005 and CIP-007 may be identified for a
major change to the baseline configuration, and therefore, CIP-005 and CIP-007 was cited at the
standard-level versus the requirement-level.
Page 35 of 47
Guidelines and Technical Basis
Test Environment
The Control Center test environment (or production environment where the test is performed
in a manner that minimizes adverse effects) should model the baseline configuration, but may
have a different set of components. For instance, an entity may have a BES Cyber System that
runs a database on one component and a web server on another component. The test
environment may have the same operating system, security patches, network accessible ports,
and software, but have both the database and web server running on a single component
instead of multiple components.
Additionally, the Responsible Entity should note that wherever a test environment (or
production environment where the test is performed in a manner that minimizes adverse
effects) is mentioned, the requirement is to “model” the baseline configuration and not
duplicate it exactly. This language was chosen deliberately in order to allow for individual
elements of a BES Cyber System at a Control Center to be modeled that may not otherwise be
able to be replicated or duplicated exactly; such as, but not limited to, a legacy map-board
controller or the numerous data communication links from the field or to other Control Centers
(such as by ICCP).
Software Verification
The concept of software verification (verifying the identity of the software source and the
integrity of the software obtained from the software source) is a key control in preventing the
introduction of malware or counterfeit software. This objective is intended to reduce the
likelihood that an attacker could exploit legitimate vendor patch management processes to
deliver compromised software updates or patches to a BES Cyber System. The intent of the SDT
is for Responsible Entities to provide controls for verifying the baseline elements that are
updated by vendors. It is important to note that this is not limited to only security patches.
NIST SP-800-161 includes a number of security controls, which, when taken together, reduce
the probability of a successful “Watering Hole” or similar cyber attack in the industrial control
system environment and thus could assist in addressing this objective. For example, in the
System and Information Integrity (SI) control family, control SI-7 suggests users obtain software
directly from the developer and verify the integrity of the software using controls such as digital
signatures. In the Configuration Management (CM) control family, control CM-5(3) requires
that the information system prevent the installation of firmware or software without the
verification that the component has been digitally signed to ensure that the hardware and
software components are genuine and valid. NIST SP-800-161, while not meant to be definitive,
provides examples of controls for addressing this objective. Other controls also could meet this
objective.
Page 36 of 47
Guidelines and Technical Basis
In implementing Requirement R1 Part 1.6, the responsible entity should consider their existing
CIP cyber security policies and controls in addition to the following:
•
Processes used to deliver software and appropriate control(s) that will verify the identity
of the software source and the integrity of the software delivered through these
processes. To the extent that the responsible entity utilizes automated systems such as a
subscription service to download and distribute software including updates, consider how
software verification can be performed through those processes.
•
Coordination of the responsible entity’s software verification control(s) with other cyber
security policies and controls, including change management and patching processes, and
procurement controls.
Use of a secure central software repository after the identity of the software source and
the integrity of the software have been validated, so that verifications do not need to be
performed repeatedly before each installation.
Additional controls such as examples outlined in the Software, Firmware, and
Information Integrity (SI-7) section of NIST Special Publication 800-53 Revision 4, or
similar guidance.
Additional controls such as those defined in FIPS-140-2, FIPS 180-4, or similar guidance,
to ensure the cryptographic methods used are acceptable to the Responsible Entity.
•
•
•
Responsible entities may use various methods to verify the integrity of software obtained from
the software source. Examples include, but are not limited to, the following:
•
•
•
•
Verify that the software has been digitally signed and validate the signature to ensure
that the software’s integrity has not been compromised.
Use public key infrastructure (PKI) with encryption to ensure that the software is not
modified in transit by enabling only intended recipients to decrypt the software.
Require software sources to provide fingerprints or cipher hashes for all software and
verify the values prior to installation on a BES Cyber System to ensure the integrity of
the software. Consider using a method for receiving the verification values that is
different from the method used to receive the software from the software source.
Use trusted/controlled distribution and delivery options to reduce supply chain risk
(e.g., requiring tamper-evident packaging of software during shipping.)
Requirement R2:
The SDT’s intent of R2 is to require automated monitoring of the BES Cyber System. However,
the SDT understands that there may be some Cyber Assets where automated monitoring may
not be possible (such as a GPS time clock). For that reason, automated technical monitoring
was not explicitly required, and a Responsible Entity may choose to accomplish this
requirement through manual procedural controls.
Page 37 of 47
Guidelines and Technical Basis
Requirement R3:
The Responsible Entity should note that the requirement provides a distinction between paper
and active vulnerability assessments. The justification for this distinction is well-documented in
FERC Order No. 706 and its associated Notice of Proposed Rulemaking. In developing their
vulnerability assessment processes, Responsible Entities are strongly encouraged to include at
least the following elements, several of which are referenced in CIP-005 and CIP-007:
Paper Vulnerability Assessment:
1. Network Discovery - A review of network connectivity to identify all Electronic Access
Points to the Electronic Security Perimeter.
2. Network Port and Service Identification - A review to verify that all enabled ports and
services have an appropriate business justification.
3. Vulnerability Review - A review of security rule-sets and configurations including
controls for default accounts, passwords, and network management community strings.
4. Wireless Review - Identification of common types of wireless networks (such as
802.11a/b/g/n) and a review of their controls if they are in any way used for BES Cyber
System communications.
Active Vulnerability Assessment:
1. Network Discovery - Use of active discovery tools to discover active devices and identify
communication paths in order to verify that the discovered network architecture
matches the documented architecture.
2. Network Port and Service Identification – Use of active discovery tools (such as Nmap)
to discover open ports and services.
3. Vulnerability Scanning – Use of a vulnerability scanning tool to identify network
accessible ports and services along with the identification of known vulnerabilities
associated with services running on those ports.
4. Wireless Scanning – Use of a wireless scanning tool to discover wireless signals and
networks in the physical perimeter of a BES Cyber System. Serves to identify
unauthorized wireless devices within the range of the wireless scanning tool.
In addition, Responsible Entities are strongly encouraged to review NIST SP800-115 for
additional guidance on how to conduct a vulnerability assessment.
Requirement R4:
Because most BES Cyber Assets and BES Cyber Systems are isolated from external public or
untrusted networks, Transient Cyber Assets and Removable Media are a means for cyberattack. Transient Cyber Assets and Removable Media are often the only way to transport files
to and from secure areas to maintain, monitor, or troubleshoot critical systems. To protect the
BES Cyber Assets and BES Cyber Systems, entities are required to document and implement a
plan for how they will manage the use of Transient Cyber Assets and Removable Media. The
Page 38 of 47
Guidelines and Technical Basis
approach of defining a plan allows the Responsible Entity to document the processes that are
supportable within its organization and in alignment with its change management processes.
Transient Cyber Assets and Removable Media are those devices connected temporarily to: (1) a
BES Cyber Asset, (2) a network within an ESP, or (3) a Protected Cyber Asset. Transient Cyber
Assets and Removable Media do not provide BES reliability services and are not part of the BES
Cyber Asset to which they are connected. Examples of these temporarily connected devices
include, but are not limited to:
•
Diagnostic test equipment;
•
Packet sniffers;
•
Equipment used for BES Cyber System maintenance;
•
Equipment used for BES Cyber System configuration; or
•
Equipment used to perform vulnerability assessments.
Transient Cyber Assets can be one of many types of devices from a specially-designed device for
maintaining equipment in support of the BES to a platform such as a laptop, desktop, or tablet
that may just interface with or run applications that support BES Cyber Systems and is capable
of transmitting executable code. Removable Media in scope of this requirement can be in the
form of floppy disks, compact disks, USB flash drives, external hard drives, and other flash
memory cards/drives that contain nonvolatile memory.
While the definitions of Transient Cyber Asset and Removable Media include a conditional
provision that requires them to be connected for 30 days or less, Section 1.1 of Attachment 1
allows the Responsible Entity to include provisions in its plan(s) that allow continuous or ondemand treatment and application of controls independent of the connected state. Please note
that for on-demand treatment, the requirements only apply when Transient Cyber Assets and
Removable Media are being connected to a BES Cyber System or Protected Cyber Asset. Once
the transient device is disconnected, the requirements listed herein are not applicable until that
Transient Cyber Asset or Removable Media is to be reconnected to the BES Cyber Asset or
Protected Cyber Asset.
The attachment was created to specify the capabilities and possible security methods available
to Responsible Entities based upon asset type, ownership, and management.
With the list of options provided in Attachment 1 for each control area, the entity has the
discretion to use the option(s) that is most appropriate. This includes documenting its approach
for how and when the entity manages or reviews the Transient Cyber Asset under its control or
under the control of parties other than the Responsible Entity. The entity should avoid
implementing a security function that jeopardizes reliability by taking actions that would
negatively impact the performance or support of the Transient Cyber Asset, BES Cyber Asset, or
Protected Cyber Asset.
Vulnerability Mitigation
The terms “mitigate”, “mitigating”, and “mitigation” are used in the sections in Attachment 1 to
address the risks posed by malicious code, software vulnerabilities, and unauthorized use when
Page 39 of 47
Guidelines and Technical Basis
connecting Transient Cyber Assets and Removable Media. Mitigation in this context does not
require that each vulnerability is individually addressed or remediated, as many may be
unknown or not have an impact on the system to which the Transient Cyber Asset or
Removable Media is connected. Mitigation is meant to reduce security risks presented by
connecting the Transient Cyber Asset.
Per Transient Cyber Asset Capability
As with other CIP standards, the requirements are intended for an entity to use the method(s)
that the system is capable of performing. The use of “per Transient Cyber Asset capability” is to
eliminate the need for a Technical Feasibility Exception when it is understood that the device
cannot use a method(s). For example, for malicious code, many types of appliances are not
capable of implementing antivirus software; therefore, because it is not a capability of those
types of devices, implementation of the antivirus software would not be required for those
devices.
Requirement R4, Attachment 1, Section 1 - Transient Cyber Asset(s) Managed by the
Responsible Entity
Section 1.1: Entities have a high level of control for the assets that they manage. The
requirements listed herein allow entities the flexibility to either pre-authorize an inventory of
devices or authorize devices at the time of connection or use a combination of these methods.
The devices may be managed individually or by group.
Section 1.2: Entities are to document and implement their process(es) to authorize the use of
Transient Cyber Assets for which they have direct management. The Transient Cyber Assets
may be listed individually or by asset type. To meet this requirement part, the entity is to
document the following:
1.2.1
User(s), individually or by group/role, allowed to use the Transient Cyber
Asset(s). This can be done by listing a specific person, department, or job
function. Caution: consider whether these user(s) must also have authorized
electronic access to the applicable system in accordance with CIP-004.
1.2.2
Locations where the Transient Cyber Assets may be used. This can be done by
listing a specific location or a group of locations.
1.2.3
The intended or approved use of each individual, type, or group of Transient
Cyber Asset. This should also include the software or application packages that
are authorized with the purpose of performing defined business functions or
tasks (e.g., used for data transfer, vulnerability assessment, maintenance, or
troubleshooting purposes), and approved network interfaces (e.g., wireless,
including near field communication or Bluetooth, and wired connections).
Activities, and software or application packages, not specifically listed as
acceptable should be considered as prohibited. It may be beneficial to educate
individuals through the CIP-004 Security Awareness Program and Cyber Security
Training Program about authorized and unauthorized activities or uses (e.g.,
Page 40 of 47
Guidelines and Technical Basis
using the device to browse the Internet or to check email or using the device to
access wireless networks in hotels or retail locations).
Entities should exercise caution when using Transient Cyber Assets and ensure they do not have
features enabled (e.g., wireless or Bluetooth features) in a manner that would allow the device
to bridge an outside network to an applicable system. Doing so would cause the Transient
Cyber Asset to become an unauthorized Electronic Access Point in violation of CIP-005,
Requirement R1.
Attention should be paid to Transient Cyber Assets that may be used for assets in differing
impact areas (i.e., high impact, medium impact, and low impact). These impact areas have
differing levels of protection under the CIP requirements, and measures should be taken to
prevent the introduction of malicious code from a lower impact area. An entity may want to
consider the need to have separate Transient Cyber Assets for each impact level.
Section 1.3: Entities are to document and implement their process(es) to mitigate software
vulnerabilities posed by unpatched software through the use of one or more of the protective
measures listed. This needs to be applied based on the capability of the device. Recognizing
there is a huge diversity of the types of devices that can be included as Transient Cyber Assets
and the advancement in software vulnerability management solutions, options are listed that
include the alternative for the entity to use a technology or process that effectively mitigates
vulnerabilities.
•
Security patching, including manual or managed updates provides flexibility to the
Responsible Entity to determine how its Transient Cyber Asset(s) will be used. It is
possible for an entity to have its Transient Cyber Asset be part of an enterprise patch
process and receive security patches on a regular schedule or the entity can verify
and apply security patches prior to connecting the Transient Cyber Asset to an
applicable Cyber Asset. Unlike CIP-007, Requirement R2, there is no expectation of
creating dated mitigation plans or other documentation other than what is
necessary to identify that the Transient Cyber Asset is receiving appropriate security
patches.
•
Live operating system and software executable only from read-only media is
provided to allow a protected operating system that cannot be modified to deliver
malicious software. When entities are creating custom live operating systems, they
should check the image during the build to ensure that there is not malicious
software on the image.
•
System hardening, also called operating system hardening, helps minimize security
vulnerabilities by removing all non-essential software programs and utilities and only
installing the bare necessities that the computer needs to function. While other
programs may provide useful features, they can provide "back-door" access to the
system, and should be removed to harden the system.
•
When selecting to use other methods that mitigate software vulnerabilities to those
listed, entities need to have documentation that identifies how the other method(s)
meet the software vulnerability mitigation objective.
Page 41 of 47
Guidelines and Technical Basis
Section 1.4: Entities are to document and implement their process(es) to mitigate malicious
code through the use of one or more of the protective measures listed. This needs to be applied
based on the capability of the device. As with vulnerability management, there is diversity of
the types of devices that can be included as Transient Cyber Assets and the advancement in
malicious code protections. When addressing malicious code protection, the Responsible Entity
should address methods deployed to deter, detect, or prevent malicious code. If malicious code
is discovered, it must be removed or mitigated to prevent it from being introduced into the BES
Cyber Asset or BES Cyber System. Entities should also consider whether the detected malicious
code is a Cyber Security Incident.
•
Antivirus software, including manual or managed updates of signatures or patterns,
provides flexibility just as with security patching, to manage Transient Cyber Asset(s)
by deploying antivirus or endpoint security tools that maintain a scheduled update
of the signatures or patterns. Also, for devices that do not regularly connect to
receive scheduled updates, entities may choose to scan the Transient Cyber Asset
prior to connection to ensure no malicious software is present.
•
Application whitelisting is a method of authorizing only the applications and
processes that are necessary on the Transient Cyber Asset. This reduces the
opportunity that malicious software could become resident, much less propagate,
from the Transient Cyber Asset to the BES Cyber Asset or BES Cyber System.
•
Restricted communication to limit the exchange of data to only the Transient Cyber
Asset and the Cyber Assets to which it is connected by restricting or disabling serial
or network (including wireless) communications on a managed Transient Cyber
Asset can be used to minimize the opportunity to introduce malicious code onto the
Transient Cyber Asset while it is not connected to BES Cyber Systems. This renders
the device unable to communicate with devices other than the one to which it is
connected.
•
When selecting to use other methods that mitigate the introduction of malicious
code to those listed, entities need to have documentation that identifies how the
other method(s) meet the mitigation of the introduction of malicious code objective.
Section 1.5: Entities are to document and implement their process(es) to protect and evaluate
Transient Cyber Assets to ensure they mitigate the risks that unauthorized use of the Transient
Cyber Asset may present to the BES Cyber System. The concern addressed by this section is the
possibility that the Transient Cyber Asset could be tampered with, or exposed to malware,
while not in active use by an authorized person. Physical security of the Transient Cyber Asset is
certainly a control that will mitigate this risk, but other tools and techniques are also available.
The bulleted list of example protections provides some suggested alternatives.
•
For restricted physical access, the intent is that the Transient Cyber Asset is
maintained within a Physical Security Perimeter or other physical location or
enclosure that uses physical access controls to protect the Transient Cyber Asset.
•
Full disk encryption with authentication is an option that can be employed to protect
a Transient Cyber Asset from unauthorized use. However, it is important that
Page 42 of 47
Guidelines and Technical Basis
authentication be required to decrypt the device. For example, pre-boot
authentication, or power-on authentication, provides a secure, tamper-proof
environment external to the operating system as a trusted authentication layer.
Authentication prevents data from being read from the hard disk until the user has
confirmed they have the correct password or other credentials. By performing the
authentication prior to the system decrypting and booting, the risk that an
unauthorized person may manipulate the Transient Cyber Asset is mitigated.
•
Multi-factor authentication is used to ensure the identity of the person accessing the
device. Multi-factor authentication also mitigates the risk that an unauthorized
person may manipulate the Transient Cyber Asset.
•
In addition to authentication and pure physical security methods, other alternatives
are available that an entity may choose to employ. Certain theft recovery solutions
can be used to locate the Transient Cyber Asset, detect access, remotely wipe, and
lockout the system, thereby mitigating the potential threat from unauthorized use if
the Transient Cyber Asset was later connected to a BES Cyber Asset. Other low tech
solutions may also be effective to mitigate the risk of using a maliciouslymanipulated Transient Cyber Asset, such as tamper evident tags or seals, and
executing procedural controls to verify the integrity of the tamper evident tag or
seal prior to use.
•
When selecting to use other methods that mitigate the risk of unauthorized use to
those listed, entities need to have documentation that identifies how the other
method(s) meet the mitigation of the risk of unauthorized use objective.
Requirement R4, Attachment 1, Section 2 - Transient Cyber Asset(s) Managed by a Party
Other than the Responsible Entity
The attachment also recognizes the lack of control for Transient Cyber Assets that are managed
by parties other than the Responsible Entity. However, this does not obviate the Responsible
Entity’s responsibility to ensure that methods have been deployed to deter, detect, or prevent
malicious code on Transient Cyber Assets it does not manage. The requirements listed herein
allow entities the ability to review the assets to the best of their capability and to meet their
obligations.
To facilitate these controls, Responsible Entities may choose to execute agreements with other
parties to provide support services to BES Cyber Systems and BES Cyber Assets that may involve
the use of Transient Cyber Assets. Entities may consider using the Department of Energy
Cybersecurity Procurement Language for Energy Delivery dated April 2014. 1 Procurement
language may unify the other party and entity actions supporting the BES Cyber Systems and
BES Cyber Assets. CIP program attributes may be considered including roles and
responsibilities, access controls, monitoring, logging, vulnerability, and patch management
along with incident response and back up recovery may be part of the other party’s support.
1
http://www.energy.gov/oe/downloads/cybersecurity-procurement-language-energy-delivery-april-2014
Page 43 of 47
Guidelines and Technical Basis
Entities should consider the “General Cybersecurity Procurement Language” and “The
Supplier’s Life Cycle Security Program” when drafting Master Service Agreements, Contracts,
and the CIP program processes and controls.
Section 2.1: Entities are to document and implement their process(es) to mitigate software
vulnerabilities through the use of one or more of the protective measures listed.
•
Conduct a review of the Transient Cyber Asset managed by a party other than the
Responsible Entity to determine whether the security patch level of the device is
adequate to mitigate the risk of software vulnerabilities before connecting the Transient
Cyber Asset to an applicable system.
•
Conduct a review of the other party’s security patching process. This can be done either
at the time of contracting but no later than prior to connecting the Transient Cyber
Asset to an applicable system. Just as with reviewing the security patch level of the
device, selecting to use this approach aims to ensure that the Responsible Entity has
mitigated the risk of software vulnerabilities to applicable systems.
•
Conduct a review of other processes that the other party uses to mitigate the risk of
software vulnerabilities. This can be reviewing system hardening, application
whitelisting, virtual machines, etc.
•
When selecting to use other methods to mitigate software vulnerabilities to those
listed, entities need to have documentation that identifies how the other method(s)
meet mitigation of the risk of software vulnerabilities.
Section 2.2: Entities are to document and implement their process(es) to mitigate the
introduction of malicious code through the use of one or more of the protective measures
listed.
•
Review the use of antivirus software and signature or pattern levels to ensure that the
level is adequate to the Responsible Entity to mitigate the risk of malicious software
being introduced to an applicable system.
•
Review the antivirus or endpoint security processes of the other party to ensure that
their processes are adequate to the Responsible Entity to mitigate the risk of
introducing malicious software to an applicable system.
•
Review the use of application whitelisting used by the other party to mitigate the risk of
introducing malicious software to an applicable system.
•
Review the use of live operating systems or software executable only from read-only
media to ensure that the media is free from malicious software itself. Entities should
review the processes to build the read-only media as well as the media itself.
•
Review system hardening practices used by the other party to ensure that unnecessary
ports, services, applications, etc. have been disabled or removed. This will limit the
chance of introducing malicious software to an applicable system.
Page 44 of 47
Guidelines and Technical Basis
Section 2.3: Determine whether additional mitigation actions are necessary, and implement
such actions prior to connecting the Transient Cyber Asset managed by a party other than the
Responsible Entity. The intent of this section is to ensure that after conducting the selected
review from Sections 2.1 and 2.2, if there are deficiencies that do not meet the Responsible
Entity’s security posture, the other party is required to complete the mitigations prior to
connecting their devices to an applicable system.
Requirement R4, Attachment 1, Section 3 - Removable Media
Entities have a high level of control for Removable Media that are going to be connected to
their BES Cyber Assets.
Section 3.1: Entities are to document and implement their process(es) to authorize the use of
Removable Media. The Removable Media may be listed individually or by type.
•
Document the user(s), individually or by group/role, allowed to use the Removable
Media. This can be done by listing a specific person, department, or job function.
Authorization includes vendors and the entity’s personnel. Caution: consider whether
these user(s) must have authorized electronic access to the applicable system in
accordance with CIP-004.
•
Locations where the Removable Media may be used. This can be done by listing a
specific location or a group/role of locations.
Section 3.2: Entities are to document and implement their process(es) to mitigate the
introduction of malicious code through the use of one or more method(s) to detect malicious
code on the Removable Media before it is connected to a BES Cyber Asset. When using the
method(s) to detect malicious code, it is expected to occur from a system that is not part of the
BES Cyber System to reduce the risk of propagating malicious code into the BES Cyber System
network or onto one of the BES Cyber Assets. If malicious code is discovered, it must be
removed or mitigated to prevent it from being introduced into the BES Cyber Asset or BES
Cyber System. Entities should also consider whether the detected malicious code is a Cyber
Security Incident. Frequency and timing of the methods used to detect malicious code were
intentionally excluded from the requirement because there are multiple timing scenarios that
can be incorporated into a plan to mitigate the risk of malicious code. The entities must use the
method(s) to detect malicious code on Removable Media before it is connected to the BES
Cyber Asset. The timing dictated and documented in the entity’s plan should reduce the risk of
introducing malicious code to the BES Cyber Asset or Protected Cyber Asset.
As a method to detect malicious code, entities may choose to use Removable Media with onboard malicious code detection tools. For these tools, the Removable Media are still used in
conjunction with a Cyber Asset to perform the detection. For Section 3.2.1, the Cyber Asset
used to perform the malicious code detection must be outside of the BES Cyber System or
Protected Cyber Asset.
Page 45 of 47
Guidelines and Technical Basis
Rationale
Rationale for Requirement R1:
The configuration change management processes are intended to prevent unauthorized
modifications to BES Cyber Systems.
Rationale for Requirement R2:
The configuration monitoring processes are intended to detect unauthorized modifications to
BES Cyber Systems.
Requirement R1 Part 1.6 addresses directives in Order No. 829 for verifying software integrity
and authenticity prior to installation in BES Cyber Systems (P. 48). The objective of verifying
software integrity and authenticity is to ensure that the software being installed in the BES
Cyber System was not modified without the awareness of the software supplier and is not
counterfeit.
Rationale for Requirement R3:
The vulnerability assessment processes are intended to act as a component in an overall
program to periodically ensure the proper implementation of cyber security controls as well as
to continually improve the security posture of BES Cyber Systems.
The vulnerability assessment performed for this requirement may be a component of
deficiency identification, assessment, and correction.
Rationale for R4:
Requirement R4 responds to the directive in FERC Order No. 791, at Paragraphs 6 and 136, to
address security-related issues associated with Transient Cyber Assets and Removable Media
used on a temporary basis for tasks such as data transfer, vulnerability assessment,
maintenance, or troubleshooting. These tools are potential vehicles for transporting malicious
code into a facility and subsequently into Cyber Assets or BES Cyber Systems. To mitigate the
risks associated with such tools, Requirement R4 was developed to accomplish the following
security objectives:
• Preventing unauthorized access or malware propagation to BES Cyber Systems through
Transient Cyber Assets or Removable Media; and
• Preventing unauthorized access to BES Cyber System Information through Transient
Cyber Assets or Removable Media.
Requirement R4 incorporates the concepts from other CIP requirements in CIP-010 and CIP-007
to help define the requirements for Transient Cyber Assets and Removable Media.
Summary of Changes: All requirements related to Transient Cyber Assets and Removable
Media are included within a single standard, CIP-010. Due to the newness of the requirements
and definition of asset types, the SDT determined that placing the requirements in a single
standard would help ensure that entities were able to quickly identify the requirements for
these asset types. A separate standard was considered for these requirements. However, the
Page 46 of 47
Guidelines and Technical Basis
SDT determined that these types of assets would be used in relation to change management
and vulnerability assessment processes and should, therefore, be placed in the same standard
as those processes.
Page 47 of 47
| File Type | application/octet-stream |
| File Title | NERC |
| File Modified | 0000-00-00 |
| File Created | 0000-00-00 |