CIP-007-6 — Cyber Security – Systems Security Management

Standard Development Timeline

This section is maintained by the drafting team during the development of the standard and will
be removed when the standard becomes effective.

Development Steps Completed

1. SAR posted for comment on January 15, 2014
2.

Standard Drafting Team appointed on January 29, 2014

Description of Current Draft

This draft standard is being posted for an initial comment and ballot. The draft includes
modifications to meet the directives of FERC Order No. 791.

Anticipated Actions

Anticipated DateFirst 45-Day Comment Period Opens

June 2014

Additional 45-Day Comment Period (if necessary)

August 2014

Final Ballot is Conducted

October/November 2014

Board of Trustees (Board) Adoption

November 2014

Filing to Applicable Regulatory Authorities

December 2014

June 2, 2014

Page 1 of 50

CIP-007-6 — Cyber Security – Systems Security Management
Version History
VersionDate

Action1

1/16/06

R3.2 — Change “Control Center” to“control center.”2

9/30/09

Modifications to clarify therequirements and to bring thecompliance elements into conformancewith the latest guidelines for developing
compliance elements of standards.

Change Tracking
3/24/06

Removal of reasonable businessjudgment.
Replaced the RRO with the RE as a
responsible entity.
Rewording of Effective Date.
Changed compliance monitor toCompliance Enforcement Authority.
3

12/16/09

Updated Version Number from -2 to -3
In Requirement 1.6, deleted thesentence pertaining to removing
component or system from service inorder to perform testing, in response to
FERC order issued September 30, 2009.

3

12/16/09

3

3/31/104

1/24/11

Approved by the NERC Board ofTrustees.

5

11/26/12

Adopted by the NERC Board ofTrustees.

5

11/22/13

FERC Order issued approving CIP-007-5.

6

June 2014

Responding to FERC Order No. 791.

June 2, 2014

Approved by the NERC Board ofTrustees.
Approved by FERC.

Modified tocoordinate withother CIP
standards and torevise format touse RBS
Template.
RevisedPage 2 of 50

CIP-007-6 — Cyber Security – Systems Security Management
When this standard has received ballot approval, the text boxes will be moved to the Application
Guidelines Section of the Standard.
A. Introduction

1.

Title:

Cyber Security — System Security Management

2.

Number:

CIP-007-6

3.

Purpose: To manage system security by specifying select technical, operational,
and procedural requirements in support of protecting BES Cyber Systems against
compromise that could lead to misoperation or instability in the BES.

4.

Applicability:

4.1.

Functional Entities: For the purpose of the requirements contained herein, thefollowing 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; and4.1.2.1.2 performs automatic Load shedding under a common control systemowned by the Responsible Entity, without human operator initiation,of 300 MW or more.
4.1.2.2 Each Special Protection System or Remedial Action Scheme where theSpecial Protection System or Remedial Action Scheme is subject to one ormore requirements in a NERC or Regional Reliability Standard.
4.1.2.3 Each Protection System (excluding UFLS and UVLS) that applies toTransmission 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 switchingrequirements from a Blackstart Resource up to and including the firstinterconnection 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

June 2, 2014

Page 3 of 50

CIP-007-6 — Cyber Security – Systems Security Management
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 4.1 above
are those to which these requirements are applicable. For requirements in thisstandard 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 andequipment owned by the Distribution Provider for the protection or restorationof 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; and4.2.1.1.2 performs automatic Load shedding under a common control systemowned by the Responsible Entity, without human operator initiation,of 300 MW or more.
4.2.1.2 Each Special Protection System or Remedial Action Scheme where theSpecial Protection System or Remedial Action Scheme is subject to one ormore requirements in a NERC or Regional Reliability Standard.
4.2.1.3 Each Protection System (excluding UFLS and UVLS) that applies toTransmission 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 switchingrequirements from a Blackstart Resource up to and including the firstinterconnection 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-007-6:
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.

June 2, 2014

Page 4 of 50

CIP-007-6 — Cyber Security – Systems Security Management
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.1
identification and categorization processes.
5.

Effective Dates:
Reliability Standard CIP-007-6 shall become effective on the later of April 1, 2016 or
the first day of the first calendar quarter that is three calendar months after the datethat the standard is approved by an applicable governmental authority, or asotherwise provided for in a jurisdiction where approval by an applicable governmental
authority is required for a standard to go into effect. Where approval by an applicablegovernmental authority is not required, the standard shall become effective the laterof April 1, 2016 or on the first day of the first calendar quarter that is three months
after the date the standard is adopted by the NERC Board of Trustees, or as otherwise
provided for in that jurisdiction.
Registered Entities shall not be required to comply with the elements of Reliability
Standard CIP-007-6, Requirement R1, Part 1.2 that apply to PCAs andnonprogrammable communication components located inside a PSP and inside an ESP
and associated with High and Medium Impact BES Cyber Systems until six calendar
months after the effective date of Reliability Standard CIP-007-6.

6.

Background:Standard CIP-007 exists as part of a suite of CIP Standards related to cyber security,
which requires the initial identification and categorization of BES Cyber Systems andrequire 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 forthe 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.

June 2, 2014

Page 5 of 50

CIP-007-6 — Cyber Security – Systems Security Management
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 thestandards include the personnel risk assessment program and the personnel training
program. The full implementation of the CIP Cyber Security Standards could also bereferred 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 ofcompliance and should not be viewed as an all-inclusive list.
Throughout the standards, unless otherwise stated, bulleted items in therequirements 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 isspecifically addressing UVLS and UFLS, which are last ditch efforts to save the Bulk
Electric System. 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 conceptfrom 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“Applicable Systems” column as described.

June 2, 2014

Page 6 of 50

CIP-007-6 — Cyber Security – Systems Security Management••

June 2, 2014

High Impact BES Cyber Systems – Applies to BES Cyber Systems categorized ashigh 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.

•

Medium Impact BES Cyber Systems at Control Centers – Only applies to medium
impact BES Cyber Systems located at a Control Center.

•

Medium Impact BES Cyber Systems with External Routable Connectivity – Only
applies to medium impact BES Cyber Systems with External Routable Connectivity.
This also excludes Cyber Assets in the BES Cyber System that cannot be directly
accessed through External Routable Connectivity.

•

Electronic Access Control or Monitoring Systems (EACMS) – Applies to eachElectronic Access Control or Monitoring System associated with a referenced highimpact BES Cyber System or medium impact BES Cyber System in the applicability
column. 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.

•

Protected Cyber Assets (PCA) – Applies to each Protected Cyber Asset associatedwith a referenced high impact BES Cyber System or medium impact BES Cyber
System.

Page 7 of 50

CIP-007-6 — Cyber Security – Systems Security Management
B. Requirements and Measures

Rationale for Requirement R1:
The requirement is intended to minimize the attack surface of BES Cyber Systems through disabling or limiting access tounnecessary network accessible logical ports and services and physical I/O ports.
In response to FERC Order No. 791, specifically FERC’s reference to NIST 800-53 rev. 3 security control PE-4 in paragraph 149, Part
1.2 has been expanded to include PCAs and nonprogrammable communications components. This increase in applicability
expands the scope of devices that receive the protection afforded by the defense-in-depth control included in Requirement R1,
Part 1.2.
The applicability is limited to those nonprogrammable communications components located both inside a PSP and an ESP in order
to allow for a scenario in which a Responsible Entity may implement an extended ESP (with corresponding logical protections
identified in CIP-006, Requirement R1, Part 1.10). In this scenario, nonprogrammable components of the communication network
may exist out of the Responsible Entity’s control (i.e. as part of the telecommunication carrier’s network).
R1.

Each Responsible Entity shall implement one or more documented process(es) that collectively include each of theapplicable requirement parts in CIP-007-6 Table R1 – Ports and Services. [Violation Risk Factor: Medium] [Time Horizon:
Same Day Operations.]

M1. Evidence must include the documented processes that collectively include each of the applicable requirement parts in CIP007-6 Table R1 – Ports and Services and additional evidence to demonstrate implementation as described in the Measurescolumn of the table.

June 2, 2014

Page 8 of 50

CIP-007-6 — Cyber Security – Systems Security Management

CIP-007-6 Table R1– Ports and Services
Part
1.1

Applicable Systems
High Impact BES Cyber Systems andtheir associated:
1. EACMS;
2. PACS; and3. PCA
Medium Impact BES Cyber Systems
with External Routable Connectivity
and their associated:
1. EACMS;
2. PACS; and3. PCA

Requirements

Measures

Where technically feasible, enable only
logical network accessible ports thathave been determined to be needed by
the Responsible Entity, including port
ranges or services where needed tohandle dynamic ports. If a device has
no provision for disabling or restricting
logical ports on the device then thoseports that are open are deemedneeded.

Examples of evidence may include, but
are not limited to:•••June 2, 2014

Documentation of the need forall enabled ports on all
applicable Cyber Assets andElectronic Access Points,
individually or by group.
Listings of the listening ports on
the Cyber Assets, individually or
by group, from either the device
configuration files, command
output (such as netstat), or
network scans of open ports; orConfiguration files of hostbased firewalls or other device
level mechanisms that only
allow needed ports and deny allothers.

Page 9 of 50

CIP-007-6 — Cyber Security – Systems Security Management
CIP-007-6 Table R1– Ports and Services
Part
1.2

Applicable Systems
High Impact BES Cyber Systems andtheir associated:
1. PCA; and2. Nonprogrammablecommunication components
located inside both a PSP and
an ESP.

Requirements

MeasuresProtect against the use of unnecessary
physical input/output ports used for
network connectivity, consolecommands, or Removable Media.

An example of evidence may include,
but is not limited to, documentation
showing types of protection of physicalinput/output ports, either logicallythrough system configuration or
physically using a port lock or signage.

Medium Impact BES Cyber Systems at
Control Centers and their associated:
1. PCA; and2. Nonprogrammablecommunication components
located inside both a PSP and
an ESP.

June 2, 2014

Page 10 of 50

CIP-007-6 — Cyber Security – Systems Security Management
Rationale for Requirement R2:
Security patch management is a proactive way of monitoring and addressing known security vulnerabilities in software before
those vulnerabilities can be exploited in a malicious manner to gain control of or render a BES Cyber Asset or BES Cyber System
inoperable.
R2.

Each Responsible Entity shall implement one or more documented process(es) that collectively include each of theapplicable requirement parts in CIP-007-6 Table R2 – Security Patch Management. [Violation Risk Factor: Medium] [TimeHorizon: Operations Planning].

M2. Evidence must include each of the applicable documented processes that collectively include each of the applicablerequirement parts in CIP-007-6 Table R2 – Security Patch Management and additional evidence to demonstrate
implementation as described in the Measures column of the table.

CIP-007-6 Table R2 – Security Patch Management
Part
2.1

Applicable Systems

Requirements

Measures

High Impact BES Cyber Systems andtheir associated:
1. EACMS;
2. PACS; and3. PCAA patch management process for
tracking, evaluating, and installingcyber security patches for applicable
Cyber Assets. The tracking portion
shall include the identification of asource or sources that the
Responsible Entity tracks for the
release of cyber security patches forapplicable Cyber Assets that are
updateable and for which a patchingsource exists.

An example of evidence may include,
but is not limited to, documentationof a patch management process anddocumentation or lists of sources thatare monitored, whether on an
individual BES Cyber System or Cyber
Asset basis.

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

June 2, 2014

Page 11 of 50

CIP-007-6 — Cyber Security – Systems Security Management
CIP-007-6 Table R2 – Security Patch Management
Part
2.2

Applicable Systems

Requirements

Measures

High Impact BES Cyber Systems andtheir associated:
1. EACMS;
2. PACS; and3. PCAAt least once every 35 calendar days,
evaluate security patches forapplicability that have been released
since the last evaluation from thesource or sources identified in Part
2.1.

An example of evidence may include,
but is not limited to, an evaluation
conducted by, referenced by, or on
behalf of a Responsible Entity of
security-related patches released by
the documented sources at least once
every 35 calendar days.

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

June 2, 2014

Page 12 of 50

CIP-007-6 — Cyber Security – Systems Security Management
CIP-007-6 Table R2 – Security Patch Management
Part
2.3

Applicable Systems

Requirements

High Impact BES Cyber Systems andtheir associated:
1. EACMS;
2. PACS; and3. PCAFor applicable patches identified inPart 2.2, within 35 calendar days ofthe evaluation completion, take oneof the following actions:

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

June 2, 2014•••

Measures
Examples of evidence may include,
but are not limited to:•

Apply the applicable patches; orCreate a dated mitigation plan;or
Revise an existing mitigation
plan.

Mitigation plans shall include the
Responsible Entity’s planned actions
to mitigate the vulnerabilities
addressed by each security patch anda timeframe to complete thesemitigations.

•

Records of the installation of
the patch (e.g., exports fromautomated patch
management tools thatprovide installation date,verification of BES Cyber
System Component software
revision, or registry exportsthat show software has been
installed); or
A dated plan showing whenand how the vulnerability will
be addressed, to include
documentation of the actions
to be taken by the Responsible
Entity to mitigate thevulnerabilities addressed by
the security patch and atimeframe for the completionof these mitigations.

Page 13 of 50

CIP-007-6 — Cyber Security – Systems Security Management
CIP-007-6 Table R2 – Security Patch Management
Part
2.4

Applicable Systems
High Impact BES Cyber Systems andtheir associated:
1. EACMS;
2. PACS; and3. PCA

Requirements

Measures

For each mitigation plan created or
An example of evidence may include,
revised in Part 2.3, implement the
but is not limited to, records ofplan within the timeframe specified in implementation of mitigations.
the plan, unless a revision to the planor an extension to the timeframe
specified in Part 2.3 is approved by
the CIP Senior Manager or delegate.

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

June 2, 2014

Page 14 of 50

CIP-007-6 — Cyber Security – Systems Security Management

Rationale for Requirement R3:
Malicious code prevention has the purpose of limiting and detecting the addition of malicious code onto the applicable Cyber
Assets of a BES Cyber System. Malicious code (viruses, worms, botnets, targeted code such as Stuxnet, etc.) may compromise theavailability or integrity of the BES Cyber System.
R3.

Each Responsible Entity shall implement one or more documented process(es) that collectively include each of theapplicable requirement parts in CIP-007-6 Table R3 – Malicious Code Prevention. [Violation Risk Factor: Medium] [TimeHorizon: Same Day Operations].

M3. Evidence must include each of the documented processes that collectively include each of the applicable requirement
parts in CIP-007-6 Table R3 – Malicious Code Prevention and additional evidence to demonstrate implementation as
described in the Measures column of the table.
CIP-007-6 Table R3 – Malicious Code Prevention
Part
3.1

Applicable Systems

Requirements

Measures

High Impact BES Cyber Systems andtheir associated:
1. EACMS;
2. PACS; and3. PCA

Deploy method(s) to deter, detect, or
prevent malicious code.

An example of evidence may include,
but is not limited to, records of the
Responsible Entity’s performance of
these processes (e.g., throughtraditional antivirus, systemhardening, policies, etc.).

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

June 2, 2014

Page 15 of 50

CIP-007-6 — Cyber Security – Systems Security Management
CIP-007-6 Table R3 – Malicious Code Prevention
Part
3.2

Applicable Systems
High Impact BES Cyber Systems andtheir associated:
1. EACMS;
2. PACS; and3. PCA

Requirements
Mitigate the threat of detected
malicious code.

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

High Impact BES Cyber Systems andtheir associated:
1. EACMS;
2. PACS; and3. PCAFor those methods identified in Part
3.1 that use signatures or patterns,
have a process for the update of thesignatures or patterns. The process
must address testing and installing thesignatures or patterns.

Measures
Examples of evidence may include,
but are not limited to:•Records of response processes
for malicious code detection•

Records of the performance of
these processes when malicious
code is detected.

An example of evidence may include,
but is not limited to, documentation
showing the process used for the
update of signatures or patterns.

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

June 2, 2014

Page 16 of 50

CIP-007-6 — Cyber Security – Systems Security Management
Rationale for Requirement R4:
Security event monitoring has the purpose of detecting unauthorized access, reconnaissance and other malicious activity on BES
Cyber Systems, and comprises of the activities involved with the collection, processing, alerting and retention of security-related
computer logs. These logs can provide both (1) the detection of an incident and (2) useful evidence in the investigation of anincident. The retention of security-related logs is intended to support post-event data analysis.
Audit processing failures are not penalized in this requirement. Instead, the requirement specifies processes which must be inplace to monitor for and notify personnel of audit processing failures.
R4.

Each Responsible Entity shall implement one or more documented process(es) that collectively include each of theapplicable requirement parts in CIP-007-6 Table R4 – Security Event Monitoring. [Violation Risk Factor: Medium] [TimeHorizon: Same Day Operations and Operations Assessment.]

M4. Evidence must include each of the documented processes that collectively include each of the applicable requirement
parts in CIP-007-6 Table R4 – Security Event Monitoring and additional evidence to demonstrate implementation as
described in the Measures column of the table.

June 2, 2014

Page 17 of 50

CIP-007-6 — Cyber Security – Systems Security Management
CIP-007-6 Table R4 – Security Event Monitoring
Part
4.1

Applicable Systems

Requirements

Measures

High Impact BES Cyber Systems andtheir associated:
1. EACMS;
2. PACS; and3. PCALog events at the BES Cyber Systemlevel (per BES Cyber System capability)
or at the Cyber Asset level (per Cyber
Asset capability) for identification of,and after-the-fact investigations of,Cyber Security Incidents that includes,
as a minimum, each of the following
types of events:

Examples of evidence may include, but
are not limited to, a paper or systemgenerated listing of event types forwhich the BES Cyber System is capableof detecting and, for generated
events, is configured to log. This listing
must include the required types of
events.

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

4.2

High Impact BES Cyber Systems andtheir associated:
1. EACMS;
2. PACS; and3. PCA
Medium Impact BES Cyber Systems
with External Routable Connectivity
and their associated:
1. EACMS;
2. PACS; and3. PCA

June 2, 2014

4.1.1. Detected successful login
attempts;
4.1.2. Detected failed accessattempts and failed login
attempts;
4.1.3. Detected malicious code.
Generate alerts for security events
that the Responsible Entity
determines necessitates an alert, that
includes, as a minimum, each of thefollowing types of events (per Cyber
Asset or BES Cyber System capability):
4.2.1. Detected malicious code fromPart 4.1; and4.2.2. Detected failure of Part 4.1
event logging.

Examples of evidence may include, but
are not limited to, paper or systemgenerated listing of security events
that the Responsible Entity
determined necessitate alerts,
including paper or system generated
list showing how alerts are configured.

Page 18 of 50

CIP-007-6 — Cyber Security – Systems Security Management
CIP-007-6 Table R4 – Security Event Monitoring
Part
4.3

Applicable Systems

Requirements

Measures

High Impact BES Cyber Systems andtheir associated:
1. EACMS;
2. PACS; and3. PCA

Where technically feasible, retain
applicable event logs identified in Part
4.1 for at least the last 90 consecutive
calendar days except under CIP
Exceptional Circumstances.

Examples of evidence may include, but
are not limited to, documentation of
the event log retention process andpaper or system generated reports
showing log retention configuration
set at 90 days or greater.

Review a summarization or samplingof logged events as determined by the
Responsible Entity at intervals nogreater than 15 calendar days toidentify undetected Cyber Security
Incidents.

Examples of evidence may include, but
are not limited to, documentation
describing the review, any findings
from the review (if any), and dated
documentation showing the review
occurred.

Medium Impact BES Cyber Systems at
Control Centers and their associated:
1. EACMS;
2. PACS; and3. PCA
4.4

June 2, 2014

High Impact BES Cyber Systems andtheir associated:
1. EACMS; and2. PCA

Page 19 of 50

CIP-007-6 — Cyber Security – Systems Security Management
Rationale for Requirement R5:
To help ensure that no authorized individual can gain electronic access to a BES Cyber System until the individual has beenauthenticated, i.e., until the individual's logon credentials have been validated. Requirement R5 also seeks to reduce the risk thatstatic passwords, where used as authenticators, may be compromised.
Requirement Part 5.1 ensures the BES Cyber System or Cyber Asset authenticates individuals that can modify configuration
information. This requirement addresses the configuration of authentication. The authorization of individuals is addressed
elsewhere in the CIP Cyber Security Standards. Interactive user access does not include read-only information access in which theconfiguration of the Cyber Asset cannot change (e.g. front panel displays, web-based reports, etc.). For devices that cannot
technically or for operational reasons perform authentication, an entity may demonstrate all interactive user access paths, both
remote and local, are configured for authentication. Physical security suffices for local access configuration if the physical security
can record who is in the Physical Security Perimeter and at what time.
Requirement Part 5.2 addresses default and other generic account types. Identifying the use of default or generic account types
that could introduce vulnerabilities has the benefit ensuring entities understand the possible risk these accounts pose to the BES
Cyber System. The Requirement Part avoids prescribing an action to address these accounts because the most effective solution issituation specific, and in some cases, removing or disabling the account could have reliability consequences.
Requirement Part 5.3 addresses identification of individuals with access to shared accounts. This Requirement Part has theobjective of mitigating the risk of unauthorized access through shared accounts. This differs from other CIP Cyber Security
Standards Requirements to authorize access. An entity can authorize access and still not know who has access to a shared account.
Failure to identify individuals with access to shared accounts would make it difficult to revoke access when it is no longer needed.
The term “authorized” is used in the requirement to make clear that individuals storing, losing, or inappropriately sharing apassword is not a violation of this requirement.
Requirement 5.4 addresses default passwords. Changing default passwords closes an easily exploitable vulnerability in manysystems and applications. Pseudo-randomly system generated passwords are not considered default passwords.
For password-based user authentication, using strong passwords and changing them periodically helps mitigate the risk of
successful password cracking attacks and the risk of accidental password disclosure to unauthorized individuals. In theserequirements, the drafting team considered multiple approaches to ensuring this requirement was both effective and flexible
enough to allow Responsible Entities to make good security decisions. One of the approaches considered involved requiring
minimum password entropy, but the calculation for true information entropy is more highly complex and makes several
assumptions in the passwords users choose. Users can pick poor passwords well below the calculated minimum entropy.

June 2, 2014

Page 20 of 50

CIP-007-6 — Cyber Security – Systems Security Management
Rationale for Requirement R5 (continued):
The drafting team also chose to not require technical feasibility exceptions for devices that cannot meet the length and complexity
requirements in password parameters. The objective of this requirement is to apply a measurable password policy to deter
password cracking attempts, and replacing devices to achieve a specified password policy does not meet this objective. At thesame time, this requirement has been strengthened to require account lockout or alerting for failed login attempts, which in many
instances better meets the requirement objective.
The requirement to change passwords exists to address password cracking attempts if an encrypted password were somehow
attained and also to refresh passwords which may have been accidentally disclosed over time. The requirement permits the entity
to specify the periodicity of change to accomplish this objective. Specifically, the drafting team felt determining the appropriate
periodicity based on a number of factors is more effective than specifying the period for every BES Cyber System in the Standard.
In general, passwords for user authentication should be changed at least annually. The periodicity may increase in some cases. For
example, application passwords that are long and pseudo-randomly generated could have a very long periodicity. Also, passwords
used only as a weak form of application authentication, such as accessing the configuration of a relay may only need to be changed
as part of regularly scheduled maintenance.
The Cyber Asset should automatically enforce the password policy for individual user accounts. However, for shared accounts inwhich no mechanism exists to enforce password policies, the Responsible Entity can enforce the password policy procedurally andthrough internal assessment and audit.
Requirement Part 5.7 assists in preventing online password attacks by limiting the number of guesses an attacker can make. Thisrequirement allows either limiting the number of failed authentication attempts or alerting after a defined number of failed
authentication attempts. Entities should take caution in choosing to limit the number of failed authentication attempts for all
accounts because this would allow the possibility for a denial of service attack on the BES Cyber System.

June 2, 2014

Page 21 of 50

CIP-007-6 — Cyber Security – Systems Security Management
R5.

Each Responsible Entity shall implement one or more documented process(es) that collectively include each of theapplicable requirement parts in CIP-007-6 Table R5 – System Access Controls. [Violation Risk Factor: Medium] [TimeHorizon: Operations Planning].

M5. Evidence must include each of the applicable documented processes that collectively include each of the applicablerequirement parts in CIP-007-6 Table 5 – System Access Controls and additional evidence to demonstrate implementation
as described in the Measures column of the table.
CIP-007-6 Table R5 – System Access Control
Part

Applicable Systems

Requirements

Measures5.1

High Impact BES Cyber Systems andtheir associated:
1. EACMS;
2. PACS; and3. PCA

Have a method(s) to enforce
authentication of interactive user access,where technically feasible.

An example of evidence may include,
but is not limited to, documentation
describing how access isauthenticated.

Medium Impact BES Cyber Systems at
Control Centers and their associated:
1. EACMS;
2. PACS; and3. PCA
Medium Impact BES Cyber Systems
with External Routable Connectivity
and their associated:
1. EACMS;
2. PACS; and3. PCA

June 2, 2014

Page 22 of 50

CIP-007-6 — Cyber Security – Systems Security Management

CIP-007-6 Table R5 – System Access Control
Part

Applicable Systems

Requirements

Measures5.2

High Impact BES Cyber Systems andtheir associated:
1. EACMS;
2. PACS; and3. PCA

Identify and inventory all known enabled
default or other generic account types,
either by system, by groups of systems, by
location, or by system type(s).

An example of evidence may include,
but is not limited to, a listing ofaccounts by account types showing
the enabled or generic account types
in use for the BES Cyber System.

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

June 2, 2014

Page 23 of 50

CIP-007-6 — Cyber Security – Systems Security Management
CIP-007-6 Table R5 – System Access Control
Part

Applicable Systems

Requirements

Measures5.3

High Impact BES Cyber Systems andtheir associated:
1. EACMS;
2. PACS; and3. PCA

Identify individuals who have authorizedaccess to shared accounts.

An example of evidence may include,
but is not limited to, listing of sharedaccounts and the individuals who haveauthorized access to each sharedaccount.

Medium Impact BES Cyber Systems
with External Routable Connectivity
and their associated:
1. EACMS;
2. PACS; and3. PCA

June 2, 2014

Page 24 of 50

CIP-007-6 — Cyber Security – Systems Security Management

CIP-007-6 Table R5 – System Access Control
Part

Applicable Systems

Requirements

Measures

5.4

High Impact BES Cyber Systems andtheir associated:
1. EACMS;
2. PACS; and3. PCA

Change known default passwords, per
Cyber Asset capability

Examples of evidence may include, but
are not limited to:••
Medium Impact BES Cyber Systems
and their associated:
1. EACMS;
2. PACS; and3. PCA

June 2, 2014

Records of a procedure thatpasswords are changed when newdevices are in production; orDocumentation in system manuals
or other vendor documents
showing default vendor
passwords were generated
pseudo-randomly and are thereby
unique to the device.

Page 25 of 50

CIP-007-6 — Cyber Security – Systems Security Management
CIP-007-6 Table R5 – System Access Control
Part

Applicable Systems

5.5High Impact BES Cyber Systems andtheir associated:
1. EACMS;
2. PACS; and3. PCA
Medium Impact BES Cyber Systems
and their associated:
1. EACMS;
2. PACS; and3. PCA

June 2, 2014

Requirements

Measures

For password-only authentication for
Examples of evidence may include, butinteractive user access, either technicallyare not limited to:or procedurally enforce the following• System-generated reports or
password parameters:
screen-shots of the system5.5.1. Password length that is, at least,
enforced password parameters,
the lesser of eight characters or
including length and complexity;
the maximum length supported byor
the Cyber Asset; and• Attestations that include a
5.5.2. Minimum password complexity
reference to the documented
that is the lesser of three or more
procedures that were followed.
different types of characters (e.g.,
uppercase alphabetic, lowercase
alphabetic, numeric, nonalphanumeric) or the maximum
complexity supported by the Cyber
Asset.

Page 26 of 50

CIP-007-6 — Cyber Security – Systems Security Management

CIP-007-6 Table R5 – System Access Control
Part
5.6

Applicable Systems

Requirements

Measures

High Impact BES Cyber Systems andtheir associated:
1. EACMS;
2. PACS; and3. PCA

Where technically feasible, forpassword-only authentication forinteractive user access, either
technically or procedurally enforce
password changes or an obligation tochange the password at least once
every 15 calendar months.

Examples of evidence may include,
but are not limited to:

Medium Impact BES Cyber Systems
with External Routable Connectivity
and their associated:
1. EACMS;
2. PACS; and3. PCA

June 2, 2014•

System-generated reports orscreen-shots of the systemenforced periodicity of changing
passwords; or•Attestations that include areference to the documented
procedures that were followed.

Page 27 of 50

CIP-007-6 — Cyber Security – Systems Security Management
CIP-007-6 Table R5 – System Access Control
Part
5.7

Applicable Systems
High Impact BES Cyber Systems andtheir associated:
1. EACMS;
2. PACS; and3. PCA
Medium Impact BES Cyber Systems
at Control Centers and theirassociated:
1. EACMS;
2. PACS; and3. PCA

June 2, 2014

Requirements
Where technically feasible, either:• Limit the number ofunsuccessful authentication
attempts; or• Generate alerts after athreshold of unsuccessfulauthentication attempts.

Measures
Examples of evidence may include,
but are not limited to:• Documentation of the accountlockout parameters; or• Rules in the alerting configuration
showing how the system notified
individuals after a determined
number of unsuccessful login
attempts.

Page 28 of 50

CIP-007-6 — Cyber Security – Systems Security Management
C. Compliance1.

Compliance Monitoring Process:1.1. Compliance Enforcement Authority:
As defined in the NERC Rules of Procedure, “Compliance Enforcement Authority” (CEA) means
NERC or the Regional Entity in their respective roles of monitoring and enforcing compliancewith the NERC Reliability Standards.
1.2. Evidence Retention:
The following evidence retention periods identify the period of time an entity is required toretain specific evidence to demonstrate compliance. For instances where the evidence
retention period specified below is shorter than the time since the last audit, the CEA may ask
an entity to provide other evidence to show that it was compliant for the full time period since
the last audit.
The Responsible Entity shall keep data or evidence to show compliance as identified below
unless directed by its CEA to retain specific evidence for a longer period of time as part of aninvestigation:•

Each Responsible Entity shall retain evidence of each requirement in this standard for threecalendar years.

•

If a Responsible Entity is found non-compliant, it shall keep information related to the noncompliance 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 Assessment Processes:
Compliance Audits
Self-Certifications
Spot Checking
Compliance Violation Investigations
Self-Reporting
Complaints Text
1.4. Additional Compliance Information:
None

June 2, 2014

Page 29 of 50

CIP-007-6 — Cyber Security – Systems Security Management
D. Regional Variances
None.
E. Interpretations
None.
F. Associated Documents

None.

June 2, 2014

Page 30 of 50

CIP-007-6 — Cyber Security – Systems Security Management
2.

Table of Compliance Elements

R#

Time Horizon

VRF

Violation Severity Levels (CIP-007-6)
Lower VSL

R1

Same Day
Operations

MediumR2

Operations
Planning

MediumJune 2, 2014

N/A

The Responsible
Entity has
documented andimplemented one ormore process(es) toevaluate uninstalled
released security
patches forModerate VSLHigh VSL

Severe VSL

The Responsible
Entity has
implemented anddocumented
processes for Ports
and Services but had
no methods toprotect against
unnecessary
physical
input/output ports
used for network
connectivity,
console commands,
or Removable
Media. (1.2)

The Responsible
Entity has
implemented anddocumented
processes fordetermining
necessary Ports andServices but, where
technically feasible,
had one or moreunneeded logicalnetwork accessible
ports enabled. (1.1)

The Responsible
Entity did not
implement or
document one ormore process(es)that included theapplicable items in
CIP-007-6 Table R1.
(R1)

The Responsible
Entity has
documented or
implemented one ormore process(es) for
patch management
but did not include
any processes,

The Responsible
Entity has
documented or
implemented one ormore process(es) for
patch management
but did not include
any processes for

The Responsible
Entity did not
implement or
document one ormore process(es)that included theapplicable items inPage 31 of 50

CIP-007-6 — Cyber Security – Systems Security Management
R#

Time Horizon

VRF

Violation Severity Levels (CIP-007-6)
Lower VSL
applicability but did
not evaluate thesecurity patches forapplicability within
35 calendar days but
less than 50
calendar days of thelast evaluation forthe source orsources identified.
(2.2)

Moderate VSL
including theidentification ofsources, for tracking
or evaluating cybersecurity patches forapplicable Cyber
Assets. (2.1)

High VSL
installing cybersecurity patches forapplicable Cyber
Assets. (2.1)
OR

The Responsible
Entity has
ORdocumented and
The Responsible
implemented one or
Entity has
more process(es) toevaluate uninstalled
documented andOR
implemented one or released security
The Responsible
more process(es) to patches for
Entity has one orevaluate uninstalled applicability but did
more documented
released security
not evaluate theprocess(es) for
patches forsecurity patches forevaluating cyber
applicability but did applicability withinsecurity patches but, not evaluate the65 calendar days ofin order to mitigate security patches for the last evaluation
the vulnerabilities
for the source orapplicability within
exposed by
50 calendar days but sources identified.
(2.2)
applicable security
less than 65
patches, did notcalendar days of the OR
apply the applicable last evaluation for
The Responsible
patches, create athe source orEntity has one ordated mitigation
more documented
plan, or revise anJune 2, 2014

Page 32 of 50

Severe VSL
CIP-007-6 Table R2.
(R2)
OR
The Responsible
Entity has
documented or
implemented one ormore process(es) for
patch management
but did not include
any processes for
tracking, evaluating,or installing cybersecurity patches forapplicable Cyber
Assets. (2.1)
OR
The Responsible
Entity documented
a mitigation plan for
an applicable cybersecurity patch anddocumented arevision or
extension to thetimeframe but did

CIP-007-6 — Cyber Security – Systems Security Management
R#

Time Horizon

VRF

Violation Severity Levels (CIP-007-6)
Lower VSL
existing mitigation
plan within 35
calendar days but
less than 50
calendar days of theevaluation
completion. (2.3)

June 2, 2014

Moderate VSL
sources identified.
(2.2)

High VSL

process(es) for
evaluating cybersecurity patches but,ORin order to mitigate
The Responsible
the vulnerabilities
Entity has one or
exposed bymore documented
applicable security
process(es) for
patches, did notevaluating cyber
apply the applicablesecurity patches but, patches, create ain order to mitigate dated mitigation
the vulnerabilities
plan, or revise an
exposed byexisting mitigation
applicable security
plan within 65
patches, did notcalendar days of theapply the applicable evaluation
patches, create acompletion. (2.3)
dated mitigation
plan, or revise an
existing mitigation
plan within 50
calendar days but
less than 65
calendar days of theevaluation
completion. (2.3)

Page 33 of 50

Severe VSL
not obtain approvalby the CIP Senior
Manager ordelegate. (2.4)
OR
The Responsible
Entity documented
a mitigation plan for
an applicable cybersecurity patch but
did not implement
the plan as createdor revised within thetimeframe specified
in the plan. (2.4)

CIP-007-6 — Cyber Security – Systems Security Management
R#

Time Horizon

VRF

Violation Severity Levels (CIP-007-6)
Lower VSL

R3

June 2, 2014

Same Day
Operations

MediumN/A

Moderate VSL

The Responsible
Entity has
implemented one ormore documented
process(es), but,where signatures orpatterns are used,
the Responsible
Entity did not
address testing thesignatures orpatterns. (3.3)

Page 34 of 50

High VSLThe Responsible
Entity has
implemented one ormore documented
process(es) for
malicious code
prevention but did
not mitigate thethreat of detected
malicious code. (3.2)
OR
The Responsible
Entity has
implemented one ormore documented
process(es) for
malicious code
prevention, butwhere signatures orpatterns are used,
the Responsible
Entity did not
update malicious
code protections.
(3.3)

Severe VSL

The Responsible
Entity did not
implement or
document one ormore process(es)that included theapplicable items in
CIP-007-6 Table R3.
(R3)
OR
The Responsible
Entity has
implemented one ormore documented
process(es) for
malicious code
prevention but did
not deploy
method(s) to deter,
detect, or prevent
malicious code. (3.1)

CIP-007-6 — Cyber Security – Systems Security Management
R#

Time Horizon

VRF

Violation Severity Levels (CIP-007-6)
Lower VSL

R4Same Day
Operations
andOperations
Assessment

MediumThe Responsible
Entity has
documented andimplemented one ormore process(es) to
identify undetected
Cyber Security
Incidents byreviewing an entitydeterminedsummarization or
sampling of logged
events at least every
15 calendar days but
missed an intervaland completed thereview within 22
calendar days of theprior review. (4.4)

Moderate VSL
The Responsible
Entity has
documented andimplemented one ormore process(es) to
identify undetected
Cyber Security
Incidents byreviewing an entitydeterminedsummarization or
sampling of logged
events at least every
15 calendar days but
missed an intervaland completed thereview within 30
calendar days of theprior review. (4.4)

High VSLThe Responsible
Entity has
documented andimplemented one ormore process(es) togenerate alerts fornecessary security
events (asdetermined by the
responsible entity)
for the Applicable
Systems (per device
or system capability)
but did not generate
alerts for all of therequired types of
events described in
4.2.1 through 4.2.2.
(4.2)
ORThe Responsible
Entity has
documented andimplemented one ormore process(es) tolog applicable
events identified inJune 2, 2014

Page 35 of 50

Severe VSL
The Responsible
Entity did not
implement or
document one ormore process(es)that included theapplicable items in
CIP-007-6 Table R4.
(R4)
OR
The Responsible
Entity has
documented andimplemented one ormore process(es) tolog events for the
Applicable Systems(per device orsystem capability)
but did not detectand log all of therequired types of
events described in
4.1.1 through 4.1.3.
(4.1)

CIP-007-6 — Cyber Security – Systems Security Management
R#

Time Horizon

VRF

Violation Severity Levels (CIP-007-6)
Lower VSL

Moderate VSLHigh VSL
4.1 (where
technically feasible
and except during
CIP Exceptional
Circumstances) but
did not retain
applicable event
logs for at least thelast 90 consecutive
days. (4.3)
OR
The Responsible
Entity has
documented andimplemented one ormore process(es) to
identify undetected
Cyber Security
Incidents byreviewing an entitydeterminedsummarization or
sampling of logged
events at least every
15 calendar days but

June 2, 2014

Page 36 of 50

Severe VSLCIP-007-6 — Cyber Security – Systems Security Management
R#

Time Horizon

VRF

Violation Severity Levels (CIP-007-6)
Lower VSL

Moderate VSLHigh VSL

Severe VSL

missed two or moreintervals. (4.4)
R5June 2, 2014

Operations
Planning

MediumThe Responsible
Entity has
implemented one ormore documented
process(es) for
password-only
authentication forinteractive user
access but did nottechnically orprocedurally enforce
password changes
or an obligation tochange thepassword within 15
calendar months but
less than or equal to
16 calendar monthsof the last password
change. (5.6)

The Responsible
Entity has
implemented one ormore documented
process(es) for
password-only
authentication forinteractive user
access but did nottechnically orprocedurally enforce
password changes
or an obligation tochange thepassword within 16
calendar months but
less than or equal to
17 calendar monthsof the last password
change. (5.6)

Page 37 of 50

The Responsible
Entity has
implemented one ormore documented
process(es) for
System AccessControls but, did notinclude theidentification orinventory of all
known enabled
default or othergeneric accounttypes, either bysystem, by groups ofsystems, by location,or by system type(s).
(5.2)
OR
The Responsible
Entity has
implemented one ormore documented
process(es) for

The Responsible
Entity did not
implement or
document one ormore process(es)that included theapplicable items in
CIP-007-6 Table R5.
(R5)
OR
The Responsible
Entity has
implemented one ormore documented
process(es) for
System AccessControls but, where
technically feasible,
does not have amethod(s) to
enforceauthentication ofinteractive user
access. (5.1)

CIP-007-6 — Cyber Security – Systems Security Management
R#

Time Horizon

VRF

Violation Severity Levels (CIP-007-6)
Lower VSL

Moderate VSLHigh VSL
System AccessControls but, did notinclude theidentification of theindividuals withauthorized access toshared accounts.
(5.3)
OR
The Responsible
Entity has
implemented one ormore documented
process(es) for
password-only
authentication forinteractive user
access that did nottechnically orprocedurally enforce
one of the two
passwordparameters as
described in 5.5.1
and 5.5.2. (5.5)
OR

June 2, 2014

Page 38 of 50

Severe VSL
OR
The Responsible
Entity has
implemented one ormore documented
process(es) for
System AccessControls but, where
technically feasible,
does not have amethod(s) to
enforceauthentication ofinteractive user
access. (5.1)
OR
The Responsible
Entity has
implemented one ormore documented
process(es) for
System AccessControls but did not,per device
capability, changeCIP-007-6 — Cyber Security – Systems Security Management
R#

Time Horizon

VRF

Violation Severity Levels (CIP-007-6)
Lower VSL

Moderate VSLHigh VSLThe Responsible
Entity has
implemented one ormore documented
process(es) for
password-only
authentication forinteractive user
access that did nottechnically orprocedurally enforce
one of the two
passwordparameters as
described in 5.5.1
and 5.5.2. (5.5)
OR
The Responsible
Entity has
implemented one ormore documented
process(es) for
password-only
authentication forinteractive user
access but did nottechnically orJune 2, 2014

Page 39 of 50

Severe VSL
known default
passwords. (5.4)
OR
The Responsible
Entity has
implemented one ormore documented
process(es) for
password-only
authentication forinteractive user
access but the
Responsible Entity
did not technicallyor procedurally
enforce all of thepasswordparametersdescribed in 5.5.1
and 5.5.2. (5.5)
OR
The Responsible
Entity has
implemented one ormore documented
process(es) forCIP-007-6 — Cyber Security – Systems Security Management
R#

Time Horizon

VRF

Violation Severity Levels (CIP-007-6)
Lower VSL

Moderate VSLHigh VSL
procedurally enforce
password changes
or an obligation tochange thepassword within 17
calendar months but
less than or equal to
18 calendar monthsof the last password
change. (5.6)

Severe VSL
password-only
authentication forinteractive user
access but did nottechnically orprocedurally
enforce password
changes or an
obligation to change
the password within
18 calendar monthsof the last password
change. (5.6)
OR
The Responsible
Entity has
implemented one ormore documented
process(es) for
System AccessControl but, where
technically feasible,
did not either limit
the number ofunsuccessfulauthentication
attempts orJune 2, 2014

Page 40 of 50

CIP-007-6 — Cyber Security – Systems Security Management
R#

Time Horizon

VRF

Violation Severity Levels (CIP-007-6)
Lower VSL

Moderate VSLHigh VSL

Severe VSL
generate alerts after
a threshold of
unsuccessfulauthentication
attempts. (5.7)

June 2, 2014

Page 41 of 50

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 thestandard. 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 othersystems and equipment, the list includes the set of systems and equipment owned byDistribution 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 thestandards.
Requirement R1:
Requirement R1 exists to reduce the attack surface of Cyber Assets by requiring entities todisable known unnecessary ports. The SDT intends for the entity to know what network
accessible (“listening”) ports and associated services are accessible on their assets and systems,
whether they are needed for that Cyber Asset’s function, and disable or restrict access to allother ports.
1.1.
This requirement is most often accomplished by disabling the corresponding service orprogram that is listening on the port or configuration settings within the Cyber Asset. It canalso be accomplished through using host-based firewalls, TCP_Wrappers, or other means on
the Cyber Asset to restrict access. Note that the requirement is applicable at the Cyber Assetlevel. The Cyber Assets are those which comprise the applicable BES Cyber Systems and theirassociated Cyber Assets. This control is another layer in the defense against network-based
attacks, therefore the SDT intends that the control be on the device itself, or positioned inline
in a non-bypassable manner. Blocking ports at the ESP border does not substitute for thisdevice level requirement. If a device has no provision for disabling or restricting logical portson the device (example - purpose built devices that run from firmware with no port
configuration available) then those ports that are open are deemed ‘needed.’
1.2.
Examples of physical I/O ports include network, serial and USB ports external to thedevice casing. BES Cyber Systems should exist within a Physical Security Perimeter in which
June 2, 2014

Page 42 of 50

Guidelines and Technical Basiscase the physical I/O ports have protection from unauthorized access, but it may still bepossible for accidental use such as connecting a modem, connecting a network cable thatbridges networks, or inserting a USB drive. Ports used for ‘console commands’ primarily means
serial ports on Cyber Assets that provide an administrative interface.
The protection of these ports can be accomplished in several ways including, but not limited to:•

Disabling all unneeded physical ports within the Cyber Asset’s configuration•

Prominent signage, tamper tape, or other means of conveying that the ports
should not be used without proper authorization•

Physical port obstruction through removable locks

The network ports included in the scope of this requirement part are not limited to those on
the BES Cyber System itself. The scope of physical network ports includes those ports that may
exist on nonprogrammable devices such as unmanaged switches, hubs, or patch panels.
This is a ‘defense in depth’ type control and it is acknowledged that there are other layers ofcontrol (the PSP for one) that prevent unauthorized personnel from gaining physical access tothese ports. Even with physical access, it has been pointed out there are other ways tocircumvent the control. This control, with its inclusion of means such as signage, is not meant
to be a preventative control against intruders. Signage is indeed a directive control, not apreventative one. However, with a defense-in-depth posture, different layers and types ofcontrols are required throughout the standard with this providing another layer for depth inControl Center environments. Once physical access has been achieved through the otherpreventative and detective measures by authorized personnel, a directive control that outlines
proper behavior as a last line of defense are appropriate in these highest risk areas. In essence,
signage would be used to remind authorized users to “think before you plug anything into oneof these systems” which is the intent. This control is not designed primarily for intruders, but
for example the authorized employee who intends to plug his possibly infected smartphone
into an operator console USB port to charge the battery.
Requirement R2:
The SDT’s intent of Requirement R2 is to require entities to know, track, and mitigate theknown software vulnerabilities associated with their BES Cyber Assets. It is not strictly an“install every security patch” requirement; the main intention is to “be aware of in a timely
manner and manage all known vulnerabilities” requirement.
Patch management is required for BES Cyber Systems that are accessible remotely as well as
standalone systems. Stand alone systems are vulnerable to intentional or unintentional
introduction of malicious code. A sound defense-in-depth security strategy employs additional
measures such as physical security, malware prevention software, and software patch
management to reduce the introduction of malicious code or the exploit of known
vulnerabilities.
One or multiple processes could be utilized. An overall assessment process may exist in a top
tier document with lower tier documents establishing the more detailed process followed forJune 2, 2014

Page 43 of 50

Guidelines and Technical Basis
individual systems. Lower tier documents could be used to cover BES Cyber System nuancesthat may occur at the system level.
2.1.
The Responsible Entity is to have a patch management program that covers tracking,evaluating, and installing cyber security patches. The requirement applies to patches only,
which are fixes released to handle a specific vulnerability in a hardware or software product.
The requirement covers only patches that involve cyber security fixes and does not coverpatches that are purely functionality related with no cyber security impact. Tracking involves
processes for notification of the availability of new cyber security patches for the Cyber Assets.
Documenting the patch source in the tracking portion of the process is required to determine
when the assessment timeframe clock starts. This requirement handles the situation wheresecurity patches can come from an original source (such as an operating system vendor), butmust be approved or certified by another source (such as a control system vendor) before they
can be assessed and applied in order to not jeopardize the availability or integrity of the control
system. The source can take many forms. The National Vulnerability Database, Operating
System vendors, or Control System vendors could all be sources to monitor for release of
security related patches, hotfixes, and/or updates. A patch source is not required for Cyber
Assets that have no updateable software or firmware (there is no user accessible way to update
the internal software or firmware executing on the Cyber Asset), or those Cyber Assets thathave no existing source of patches such as vendors that no longer exist. The identification ofthese sources is intended to be performed once unless software is changed or added to the
Cyber Asset’s baseline.
2.2. Responsible Entities are to perform an assessment of security related patches within 35
days of release from their monitored source. An assessment should consist of determination of
the applicability of each patch to the entity’s specific environment and systems. Applicability
determination is based primarily on whether the patch applies to a specific software or
hardware component that the entity does have installed in an applicable Cyber Asset. A patchthat applies to a service or component that is not installed in the entity’s environment is notapplicable. If the patch is determined to be non-applicable, that is documented with thereasons why and the entity is compliant. If the patch is applicable, the assessment can include
a determination of the risk involved, how the vulnerability can be remediated, the urgency andtimeframe of the remediation, and the steps the entity has previously taken or will take.
Considerable care must be taken in applying security related patches, hotfixes, and/or updates
or applying compensating measures to BES Cyber System or BES Cyber Assets that are no longer
supported by vendors. It is possible security patches, hotfixes, and updates may reduce thereliability of the system, and entities should take this into account when determining the typeof mitigation to apply. The Responsible Entities can use the information provided in the
Department of Homeland Security “Quarterly Report on Cyber Vulnerabilities of Potential Risk
to Control Systems” as a source. The DHS document “Recommended Practice for PatchManagement of Control Systems” provides guidance on an evaluative process. It uses severity
levels determined using the Common Vulnerability Scoring System Version 2. Determinationthat a security related patch, hotfix, and/or update poses too great a risk to install on a system
or is not applicable due to the system configuration should not require a TFE.

June 2, 2014

Page 44 of 50

Guidelines and Technical Basis
When documenting the remediation plan measures it may not be necessary to document themon a one to one basis. The remediation plan measures may be cumulative. A measure toaddress a software vulnerability may involve disabling a particular service. That same service
may be exploited through other software vulnerabilities. Therefore disabling the single service
has addressed multiple patched vulnerabilities.
2.3. The requirement handles the situations where it is more of a reliability risk to patch arunning system than the vulnerability presents. In all cases, the entity either installs the patchor documents (either through the creation of a new or update of an existing mitigation plan)
what they are going to do to mitigate the vulnerability and when they are going to do so. There
are times when it is in the best interest of reliability to not install a patch, and the entity can
document what they have done to mitigate the vulnerability. For those security related
patches that are determined to be applicable, the Responsible Entity must within 35 days either
install the patch, create a dated mitigation plan which will outline the actions to be taken or
those that have already been taken by the Responsible Entity to mitigate the vulnerabilities
addressed by the security patch, or revise an existing mitigation plan. Timeframes do not haveto be designated as a particular calendar day but can have event designations such as “at nextscheduled outage of at least two days duration.” “Mitigation plans” in the standard refers tointernal documents and are not to be confused with plans that are submitted to Regional
Entities in response to violations.
2.4.
The entity has been notified of, has assessed, and has developed a plan to remediate
the known risk and that plan must be implemented. Remediation plans that only include steps
that have been previously taken are considered implemented upon completion of the
documentation. Remediation plans that have steps to be taken to remediate the vulnerability
must be implemented by the timeframe the entity documented in their plan. There is no
maximum timeframe in this requirement as patching and other system changes carries its own
risk to the availability and integrity of the systems and may require waiting until a planned
outage. In periods of high demand or threatening weather, changes to systems may becurtailed or denied due to the risk to reliability.
Requirement R3:
3.1. Due to the wide range of equipment comprising the BES Cyber Systems and the wide
variety of vulnerability and capability of that equipment to malware as well as the constantly
evolving threat and resultant tools and controls, it is not practical within the standard toprescribe how malware is to be addressed on each Cyber Asset. Rather, the Responsible Entity
determines on a BES Cyber System basis which Cyber Assets have susceptibility to malware
intrusions and documents their plans and processes for addressing those risks and provides
evidence that they follow those plans and processes. There are numerous options available
including traditional antivirus solutions for common operating systems, white-listing solutions,network isolation techniques, Intrusion Detection/Prevention (IDS/IPS) solutions, etc. If an
entity has numerous BES Cyber Systems or Cyber Assets that are of identical architecture, they
may provide one process that describes how all the like Cyber Assets are covered. If a specificCyber Asset has no updateable software and its executing code cannot be altered, then that
Cyber Asset is considered to have its own internal method of deterring malicious code.

June 2, 2014

Page 45 of 50

Guidelines and Technical Basis
Entities should also have awareness of malware protection requirements for Transient Cyber
Assets and Removable Media (“transient devices”) in CIP-010-2. The protections required here
in CIP-007-6, Requirement R3 complement but do not meet the additional obligations fortransient devices.
3.2. When malicious code is detected on a Cyber Asset within the applicability of thisrequirement, the threat posed by that code must be mitigated. In situations where traditional
antivirus products are used, they may be configured to automatically remove or quarantine themalicious code. In white-listing situations, the white-listing tool itself can mitigate the threat as
it will not allow the code to execute, however steps should still be taken to remove themalicious code from the Cyber Asset. In some instances, it may be in the best interest ofreliability to not immediately remove or quarantine the malicious code, such as whenavailability of the system may be jeopardized by removal while operating and a rebuild of thesystem needs to be scheduled. In that case, monitoring may be increased and steps taken to
insure the malicious code cannot communicate with other systems. In some instances theentity may be working with law enforcement or other governmental entities to closely monitor
the code and track the perpetrator(s). For these reasons, there is no maximum timeframe or
method prescribed for the removal of the malicious code, but the requirement is to mitigate
the threat posed by the now identified malicious code.
3.3. In instances where malware detection technologies depend on signatures or patterns ofknown attacks, the effectiveness of these tools against evolving threats is tied to the ability tokeep these signatures and patterns updated in a timely manner. The entity is to have a
documented process that includes the testing and installation of signature or pattern updates.
In a BES Cyber System, there may be some Cyber Assets that would benefit from the more
timely installation of the updates where availability of that Cyber Asset would not jeopardize
the availability of the BES Cyber System’s ability to perform its function. For example, some
HMI workstations where portable media is utilized may benefit from having the very latest
updates at all times with minimal testing. Other Cyber Assets should have any updates
thoroughly tested before implementation where the result of a ‘false positive’ could harm theavailability of the BES Cyber System. The testing should not negatively impact the reliability of
the BES. The testing should be focused on the update itself and if it will have an adverse impact
on the BES Cyber System. Testing in no way implies that the entity is testing to ensure thatmalware is indeed detected by introducing malware into the environment. It is strictly focusedon ensuring that the update does not negatively impact the BES Cyber System before those
updates are placed into production.
Requirement R4:
Refer to NIST 800-92 and 800-137 for additional guidance in security event monitoring.
4.1. In a complex computing environment and faced with dynamic threats andvulnerabilities, it is not practical within the standard to enumerate all security-related events
necessary to support the activities for alerting and incident response. Rather, the Responsible
Entity determines which computer generated events are necessary to log, provide alerts andmonitor for their particular BES Cyber System environment.

June 2, 2014

Page 46 of 50

Guidelines and Technical Basis
Specific security events already required in Version 4 of the CIP Standards carry forward in thisversion. This includes access attempts at the Electronic Access Points, if any have been
identified for a BES Cyber Systems. Examples of access attempts include: (i) blocked network
access attempts, (ii) successful and unsuccessful remote user access attempts, (iii) blocked
network access attempts from a remote VPN, and (iv) successful network access attempts or
network flow information.
User access and activity events include those events generated by Cyber Assets within theElectronic Security Perimeter that have access control capability. These types of events include:(i) successful and unsuccessful authentication, (ii) account management, (iii) object access, and(iv) processes started and stopped.
It is not the intent of the SDT that if a device cannot log a particular event that a TFE must be
generated. The SDT’s intent is that if any of the items in the bulleted list (for example, user
logouts) can be logged by the device then the entity must log that item. If the device does nothave the capability of logging that event, the entity remains compliant.
4.2.
Real-time alerting allows the cyber system to automatically communicate events ofsignificance to designated responders. This involves configuration of a communication
mechanism and log analysis rules. Alerts can be configured in the form of an email, text
message, or system display and alarming. The log analysis rules can exist as part of theoperating system, specific application or a centralized security event monitoring system. On
one end, a real-time alert could consist of a set point on an RTU for a login failure, and on theother end, a security event monitoring system could provide multiple alerting communications
options triggered on any number of complex log correlation rules.
The events triggering a real-time alert may change from day to day as system administratorsand incident responders better understand the types of events that might be indications of acyber-security incident. Configuration of alerts also must balance the need for responders toknow an event occurred with the potential inundation of insignificant alerts. The following list
includes examples of events a Responsible Entity should consider in configuring real-time alerts:
•
•
•
•
•
•
•
•
•
•

Detected known or potential malware or malicious activity
Failure of security event logging mechanisms
Login failures for critical accounts
Interactive login of system accounts
Enabling of accounts
Newly provisioned accounts
System administration or change tasks by an unauthorized user
Authentication attempts on certain accounts during non-business hours
Unauthorized configuration changes
Insertion of Removable Media in violation of a policy

4.3
Logs that are created under Part 4.1 are to be retained on the applicable Cyber Assets or
BES Cyber Systems for at least 90 days. This is different than the evidence retention period

June 2, 2014

Page 47 of 50

Guidelines and Technical Basis
called for in the CIP standards used to prove historical compliance. For such audit purposes,
the entity should maintain evidence that shows that 90 days were kept historically. One
example would be records of disposition of event logs beyond 90 days up to the evidence
retention period.
4.4.
Reviewing logs at least every 15 days (approximately every two weeks) can consist ofanalyzing a summarization or sampling of logged events. NIST SP800-92 provides a lot of
guidance in periodic log analysis. If a centralized security event monitoring system is used, log
analysis can be performed top-down starting with a review of trends from summary reports.
The log review can also be an extension of the exercise in identifying those events needing realtime alerts by analyzing events that are not fully understood or could possibly inundate thereal-time alerting.
Requirement R5:
Account types referenced in this guidance typically include:•

Shared user account: An account used by multiple users for normal business functions
by employees or contractors. Usually on a device that does not support Individual User
Accounts.

•

Individual user account: An account used by a single user.

•

Administrative account: An account with elevated privileges for performing
administrative or other specialized functions. These can be individual or sharedaccounts.

•

System account: Accounts used to run services on a system (web, DNS, mail etc). No
users have access to these accounts.

•

Application account: A specific system account, with rights granted at the applicationlevel often used for access into a Database.

•

Guest account: An individual user account not typically used for normal business
functions by employees or contractors and not associated with a specific user. May or
may not be shared by multiple users.

•

Remote access account: An individual user account only used for obtaining Interactive
Remote Access to the BES Cyber System.

•

Generic account: A group account set up by the operating system or application to
perform specific operations. This differs from a shared user account in that individual
users do not receive authorization for access to this account type.

5.1

Reference the Requirement’s rationale.

5.2
Where possible, default and other generic accounts provided by a vendor should be
removed, renamed, or disabled prior to production use of the Cyber Asset or BES Cyber System.
If this is not possible, the passwords must be changed from the default provided by the vendor.
Default and other generic accounts remaining enabled must be documented. For common

June 2, 2014

Page 48 of 50

Guidelines and Technical Basisconfigurations, this documentation can be performed at a BES Cyber System or more generallevel.
5.3
Entities may choose to identify individuals with access to shared accounts through theaccess authorization and provisioning process, in which case the individual authorization
records suffice to meet this Requirement Part. Alternatively, entities may choose to maintain aseparate listing for shared accounts. Either form of evidence achieves the end result of
maintaining control of shared accounts.
5.4.
Default passwords can be commonly published in vendor documentation that is readily
available to all customers using that type of equipment and possibly published online.
The requirement option to have unique password addresses cases where the Cyber Assetgenerates or has assigned pseudo-random default passwords at the time of production or
installation. In these cases, the default password does not have to change because the systemor manufacturer created it specific to the Cyber Asset.
5.5.
Interactive user access does not include read-only information access in which theconfiguration of the Cyber Asset cannot change (e.g. front panel displays, web-based reports,etc.). For devices that cannot technically or for operational reasons perform authentication, an
entity may demonstrate all interactive user access paths, both remote and local, are configured
for authentication. Physical security suffices for local access configuration if the physicalsecurity can record who is in the Physical Security Perimeter and at what time.
Technical or procedural enforcement of password parameters are required where passwords
are the only credential used to authenticate individuals. Technical enforcement of the password
parameters means a Cyber Asset verifies an individually selected password meets the required
parameters before allowing the account to authenticate with the selected password. Technicalenforcement should be used in most cases when the authenticating Cyber Asset supports
enforcing password parameters. Likewise, procedural enforcement means requiring the
password parameters through procedures. Individuals choosing the passwords have theobligation of ensuring the password meets the required parameters.
Password complexity refers to the policy set by a Cyber Asset to require passwords to have one
or more of the following types of characters: (1) lowercase alphabetic, (2) uppercase
alphabetic, (3) numeric, and (4) non-alphanumeric or “special” characters (e.g. #, $, @, &), in
various combinations.
5.6
Technical or procedural enforcement of password change obligations are required
where passwords are the only credential used to authenticate individuals. Technicalenforcement of password change obligations means the Cyber Asset requires a password
change after a specified timeframe prior to allowing access. In this case, the password is not
required to change by the specified time as long as the Cyber Asset enforces the password
change after the next successful authentication of the account. Procedural enforcement means
manually changing passwords used for interactive user access after a specified timeframe.
5.7
Configuring an account lockout policy or alerting after a certain number of failed
authentication attempts serves to prevent unauthorized access through an online password

June 2, 2014

Page 49 of 50

Guidelines and Technical Basisguessing attack. The threshold of failed authentication attempts should be set high enough to
avoid false-positives from authorized users failing to authenticate. It should also be set low
enough to account for online password attacks occurring over an extended period of time. This
threshold may be tailored to the operating environment over time to avoid unnecessary
account lockouts.
Entities should take caution when configuring account lockout to avoid locking out accounts
necessary for the BES Cyber System to perform a BES reliability task. In such cases, entities
should configure authentication failure alerting.

June 2, 2014

Page 50 of 50