nerc cip compliance - midwest reliability organization · pdf file[nerc cip compliance] p a g...

2774 Cleveland Avenue N Roseville, MN 55113 Phone (651) 855-1760 Fax (651) 855-1712 www.midwestreliability.org

NERC CIP

Compliance

10/11/2011

Authored by

Dan Barker, American Transmission Co.

Ron Bender, Nebraska Public Power District

Richard Burt, Minnkota Power Cooperative, Inc.

Marc Child, Great River Energy

Marc Gaudette, Dominion

Jennifer White, Alliant Energy

The Midwest Reliability Organization (MRO) Standards Committee (SC) is committed to

providing training and non-binding guidance to industry stakeholders regarding existing and

emerging Reliability Standards. Any materials, including presentations, were developed through

the Standards Committee by Subject Matter Experts from member organizations within the

MRO.

The materials have been reviewed by MRO staff and provide reasonable application guidance for

the standard(s) addressed. Ultimately, demonstrating compliance depends on a number of

factors including the precise language of the standard, the specific facts and circumstances, and

quality of evidence.

These documents may be reproduced or distributed to any person or entity only in its entirety.

MIDWEST RELIABILITY ORGANIZATION

[NERC CIP Compliance] P a g e | 2

MIDWEST RELIABILITY

ORGANIZATION

Contents Introduction ..................................................................................................................................... 3

Paper Overview ................................................................................................................................ 4

General Recommendations ............................................................................................................... 6

CIP-002-3 – Critical Cyber Asset Identification ................................................................................ 9

CIP-003-3 – Security Management Controls ................................................................................... 13

CIP-004-3 – Personnel and Training ............................................................................................... 20

CIP-005-3 – Electronic Security Perimeters .................................................................................... 25

CIP-006-3c – Physical Security of Critical Cyber Assets ................................................................. 33

CIP-007-3 – Systems Security Management .................................................................................... 41

CIP-008-3 – Incident Reporting and Response Planning ................................................................. 53

CIP-009-3 – Recovery Plans for Critical Cyber Assets .................................................................... 56

Summary ...................................................................................................................................... 60

About the Authors .......................................................................................................................... 61


MIDWEST RELIABILITY

ORGANIZATION

Introduction

This paper has been developed to address NERC CIP compliance. The focus of this

paper is not on specific requirements, but rather the overarching goal of achieving

compliance and demonstrating that achievement. The question answered herein can be

applied to every single entity:

How do I demonstrate that I’m complying with the NERC CIP Standards?

The key to successful compliance is to concentrate on performance and “doing the right

thing” while simultaneously collecting and maintaining evidence to demonstrate that

performance. It is easier to demonstrate compliance if the programs, documentation, and

process outputs are designed with that task in mind. Though the recommendations within

this paper will focus on demonstrating compliance, there may also be program design and

configuration suggestions that will overlap with achieving compliance.

Registered entities are in various stages of compliance – some have established, effective

compliance programs while others are still developing compliance programs and

considering the implications of CIP compliance. The authors of this paper have varied

levels of audit experience, ranging from sufficiency audits to audits of all 43

requirements in the CIP Standards. The guidance within this paper is derived from those

experiences, as well as the experiences of creating and implementing CIP compliance

programs in general. The recommendations in this paper should be helpful to entities

responsible for implementing brand new programs as well as those entities engaged in

adjusting existing programs to more effectively achieve compliance after audit

experiences or program maturation.


MIDWEST RELIABILITY

ORGANIZATION

Paper Overview

The authors of this paper engaged in hours of discussion over the finer points of

interpretation, security practices, and system capability. At the end of those discussions,

the authors didn’t always agree. In order to ensure that the results were based on a strict

application of the language of the Standards, the results of those conversations have been

categorized into the following sections:

General Recommendations:

A successful compliance program relies heavily on a few, universally applied principles.

These principles are so central that they were repeated in the discussion of every single

requirement. The recommendations in this section should be remembered and revisited

when each component of a compliance program is designed.

CIP-002-3 through CIP-009-3:

In addition to the general recommendations, each Standard has an approach more likely

to yield success than another. Those approaches have been identified in each section

using the following elements:

The actual Standards language is included in each

section for reference. This is included for ease of

use.

Definitions sections will identify the terms in each

Standard that should be clearly documented by the

entity. Actual definitions are not provided, as they

will differ based on the individual compliance

program. Instead, these are lists of terms used to

simply identify those that become pivotal within

that compliance program.

Recommendations for each requirement are based

on strict application. Where sub-requirements

require additional information, they will be

specifically addressed. It is important to remember

that all of the recommendations are to be

understood as suggestions and are non-binding

application guidance.


MIDWEST RELIABILITY

ORGANIZATION

Tips are included within each Recommendation

section. Adherence to these tips is not required for

strict compliance. Instead, following this guidance

may make compliance easier to achieve or

demonstrate.

Notes are also provided in the Recommendations

sections where the additional considerations are

necessary. They contain detail that should be

considered when implementing the

recommendation.

Evidence sections include a high-level list of the

types of evidence that an auditor will likely request

or the types of evidence that, if provided, will give

the auditors a clear demonstration of compliance.

Of course, additional evidence may be appropriate

based on the specific compliance implementation.

If it clearly answers a compliance question or

demonstrates an activity required for compliance,

it’s a good idea to include it, regardless of whether

or not it appears in the evidence lists in this paper.

Summary:

This paper is based on Version 3 of the CIP Standards. The authors are aware that at

least two more versions are underway and in various states of draft and/or approval. The

body of this paper does not address future versions or anticipated changes within those

versions.


MIDWEST RELIABILITY

ORGANIZATION

General Recommendations

While there are details within each requirement that require specific attention, some

aspects of compliance are consistent throughout. Each recommendation in this section

can be applied to most, if not all, of the requirements. When developing the individual

components of a compliance program, each of these recommendations should be

revisited. Where any of these can be uniquely applied to an individual requirement, they

will be mentioned again in that section.

Documentation: “If you didn’t document it, you didn’t do it.” Many of the

requirements speak directly to documenting a program or process. However, not all

documents are created equal.

o Structure – Documents used for compliance should have components that ensure

inclusion of necessary information, change management, and references to other

relevant documents. Remember your audience and choose a format that allows users

and auditors to find information quickly and easily. Helpful components include:

Owner/Approver, Definitions, Purpose (mapped to the CIP requirement addressed),

Procedure, etc.

o Revision history –Revision history makes it possible to demonstrate that revisions are

made in accordance with implementation deadlines, procedural change timeframes,

annual reviews, etc. Keeping revision history will establish point-in-time

compliance. It is also helpful to have a summary of what changed with each revision.

Maintain revision history for the duration of the audit period.

o Roles and Responsibilities – Written procedures are a great way to ensure that each

individual knows his or her role in the process. Additionally, they help add clarity in

identifying a Subject Matter Expert (SME) to participate during an audit.

o Tip: Unless required by the Standards, use titles not names.

Evidence Considerations: Evidence is more than just documentation. Demonstrating

compliance usually means “corroborating” evidence. In other words, compliance

programs should be designed to produce an output of several auditable records for each

requirement to demonstrate performance. A documented process is the first part of

demonstrating compliance. Additional examples include a log file, a change request

form, a visitor log, or an incident response drill attendance sheet. For each requirement, a

documented process and at least one other additional record should be available to

demonstrate compliance.

The best types of evidence are consistent throughout the organization. For example,

NERC CIP changes should require the same request form and follow the same processes,

yielding exactly the same types of output. They should also provide reliable time/date

stamps that are difficult to falsify. As an example, screen captures should include a

visible time and date stamp within the capture.

Attestations provided for compliance activities are considered weaker evidence, which

may need to be corroborated with stronger evidence. But where demonstration of a null


MIDWEST RELIABILITY

ORGANIZATION

list or the absence of an activity is necessary, an attestation may be the only record that

can be provided in addition to the documented process; therefore an attestation may be

sufficient.

Reviews: Another item expressly addressed throughout the CIP Standards is the

requirement to conduct “reviews.” Each documented process should be accompanied by

how reviews are initiated, conducted, and tracked. Rigor and formality in this process

will be rewarded. For each documented review, the auditor should easily understand:

o Who was the reviewer?

o What content was reviewed?

o When was it reviewed?

o What changes were made? If so, how were they communicated?

Definitions: Each requirement may contain words or phrases that are not entirely clear.

Even “industry” terms can be applied differently in relation to a specific program or

device. NERC has published, and continues to publish, documents that can be used to

understand what is meant by the terms included in the Standards. These documents

include, but are not limited to, Compliance Application Notices (CANs), Reliability

Standard Audit Worksheets (RSAWs), interpretation documents, and guidance

documents. Even though these documents can provide assistance, it is the obligation of

the entity to ensure that the definition or interpretation in use is documented. It’s

reasonable to use definitions from trusted resources in the industry, but reliance on that

definition should be supported in a documented part of the specific program to which it

applies. In fact, even where using a definition provided by NERC, ensure that definition

is documented with the program for point-in-time understanding of the entity’s

implementation of CIP compliance.

References: There are lots of available guidance documents for writing emergency and

operating plans, determining sound security practices, specifications for configuration of

physical and electronic controls, industry standards, etc. Adhering to the guidance within

those materials can aid in developing and maintaining compliance programs, as well as

demonstrate rigor in researching available solutions. Maintain copies of source material

to provide during audits, as this can help explain why specific elements were

implemented.

Support: Within the organization, it’s possible that disparate groups engage in the

support of the assets within the scope of CIP compliance. Historically segregated IT and

business areas are sharing responsibilities and control in order to achieve compliance.

Configurations required for compliance should be protected by strong change control

processes and clear documentation outlining roles and responsibilities. Personnel who

may only be peripherally involved in support of CIP assets, perimeters, and information

should receive CIP training.


MIDWEST RELIABILITY

ORGANIZATION

Correlation: Ensure a broad understanding of all the NERC Reliability Standards (BAL,

COM, CIP, EOP, FAC, INT, IRO, MOD, NUC, PER, PRC, TOP, TPL, VAR) when

developing a CIP Compliance program. This understanding should include reporting

obligations, definitions, and any cross-references. Ensure that documented processes are

consistent throughout the entity’s compliance programs.

Audits: When resources and time allow, internal and vendor audit resources should be

considered for program definitions, targeted auditing, or full mock audits. The entity can

rehearse interviewing, learn about its ability to respond to audit scenarios or information

requests, practice compiling evidence and documentation, and identify potential

insufficiencies. It can be helpful to check with neighboring entities for reliable vendors.

A pre-audit conference call or meeting with MRO audit staff is strongly encouraged by

MRO to address questions and answers. Keep in mind MRO staff will answer questions

like “what is evidence required to demonstrate compliance.” but will not answer “if I do

this will I be complaint?”

Collaboration: Within the constraints of information protection, entities can benefit from

sharing program designs, interpretations, implementation tips, and audit experiences.

Collaboration can result in innovative solutions to common problems, increased leverage

when dealing with common vendors, as well as shared expertise and lessons learned.

Note: It’s important to remember that individual audit experiences may vary, and

information should be carefully weighed by each entity before action, even if that

information is contained within this paper.

Timing: Consider your compliance activities when scheduling major projects that may

share personnel, technology, or other resources. Consider freezes on technology or

process changes when preparing for a regional audit, schedule internal audit activities

outside of self-certification windows, etc. Wherever possible, avoid competition and

individual priorities will line up appropriately.


MIDWEST RELIABILITY

ORGANIZATION

CIP-002-3 – Critical Cyber Asset Identification

The creation of a Risk-Based Assessment Methodology for identifying Critical Assets

and the subsequent evaluations of criticality for the associated cyber devices will

ultimately determine the size and scope of its CIP compliance program, including the

applicability of the CIP-003 through CIP-009 Standards.

CIP-002-3 Requirements: R1. Critical Asset Identification Method — The Responsible Entity shall identify and document a

risk-based assessment methodology to use to identify its Critical Assets.

R1.1. The Responsible Entity shall maintain documentation describing its risk-based

assessment methodology that includes procedures and evaluation criteria.

R1.2. The risk-based assessment shall consider the following assets:

R1.2.1. Control centers and backup control centers performing the functions of the

entities listed in the Applicability section of this standard.

R1.2.2. Transmission substations that support the reliable operation of the Bulk Electric

System.

R1.2.3. Generation resources that support the reliable operation of the Bulk Electric

System.

R1.2.4. Systems and facilities critical to system restoration, including blackstart

generators and substations in the electrical path of transmission lines used for initial

system restoration.

R1.2.5. Systems and facilities critical to automatic load shedding under a common

control system capable of shedding 300 MW or more.

R1.2.6. Special Protection Systems that support the reliable operation of the Bulk Electric

System.

R1.2.7. Any additional assets that support the reliable operation of the Bulk Electric

System that the Responsible Entity deems appropriate to include in its assessment.

R2. Critical Asset Identification — The Responsible Entity shall develop a list of its identified

Critical Assets determined through an annual application of the risk-based assessment

methodology required in R1. The Responsible Entity shall review this list at least annually, and

update it as necessary.

R3. Critical Cyber Asset Identification — Using the list of Critical Assets developed pursuant to

Requirement R2, the Responsible Entity shall develop a list of associated Critical Cyber Assets

essential to the operation of the Critical Asset. Examples at control centers and backup control

centers include systems and facilities at master and remote sites that provide monitoring and

control, automatic generation control, real-time power system modeling, and real-time inter-

utility data exchange. The Responsible Entity shall review this list at least annually, and update it

as necessary. For the purpose of Standard CIP-002-3, Critical Cyber Assets are further qualified

to be those having at least one of the following characteristics:

R3.1. The Cyber Asset uses a routable protocol to communicate outside the Electronic

Security Perimeter; or,

R3.2. The Cyber Asset uses a routable protocol within a control center; or,

R3.3. The Cyber Asset is dial-up accessible.

R4. Annual Approval — The senior manager or delegate(s) shall approve annually the risk-based

assessment methodology, the list of Critical Assets and the list of Critical Cyber Assets. Based on

Requirements R1, R2, and R3 the Responsible Entity may determine that it has no Critical Assets


MIDWEST RELIABILITY

ORGANIZATION

or Critical Cyber Assets. The Responsible Entity shall keep a signed and dated record of the

senior manager or delegate(s)’s approval of the risk-based assessment methodology, the list of

Critical Assets and the list of Critical Cyber Assets (even if such lists are null.)

Definitions: The terminology used within any CIP-002 risk based methodology should

be carefully defined and included in all documentation. If any proprietary terms impact

the risk based methodology or its application, be sure to include those, as well as the

following:

o “Essential to the operation of the critical asset” – Have some criteria for this

evaluation.

o “Annual” – Be sure to document what you consider “annual” – once per calendar

year, 12 rolling months, etc. Even if this lines up with the NERC guidance document,

write it down.

o “Control Center,” “Critical Asset,” “Critical Cyber Asset,” and “Cyber Assets” –

These are all terms that have industry-established definitions, but entities should

consider including those definitions within compliance documentation. Documenting

the definition will also allow the entity to add qualifiers and conditions that may be

useful in determining inclusion or exclusion of devices or locations while

demonstrating that compliance is still achieved.

Recommendations:

CIP-002-3 R1 Critical Asset Identification Method and R2 Critical Asset Identification

o R1.2 is formatted to include sub-requirements for each type of asset that should be

included in the risk based methodology. Consider mapping documentation to

those sub-requirements. Also, use common terminology or ensure direct mapping

from proprietary terminology to the verbiage used within the Standards.

o Document the criteria used to evaluate the criticality of each type of asset. It

might be helpful to enlist Bulk Electric System (BES) Asset Subject Matter

Experts (SMEs) to assist in the establishment of those criteria, as they are the best

equipped to understand impact and criticality. Document the process for applying

the risk based methodology and completing the evaluation. Include the results of

the evaluations (scorecard) and the name(s) and expertise of the individual(s)

completing the assessment.

o The application of the risk based methodology should start with a complete

inventory of all systems and assets. Clearly document any filter applied to the

inventory before the application of the risk based methodology, reducing the

number of assets considered in the application of the risk based methodology.

The risk based methodology should also include a dynamic understanding of the

entire list of systems and assets to be assessed.

o Ensure that new assets can be added in between approval cycles to address

periodic changes to BES assets. It may help to keep documentation from regular

meetings designed to address any changes.

o If the application of the risk based methodology results in a null list, the

application results and the list, itself, must be documented.


MIDWEST RELIABILITY

ORGANIZATION

o Avoid basing an evaluation on any assets, facilities, or systems as though they are

isolated. Make sure you are considering common mode failures.

o If any additional assets are identified pursuant to R1.2.7, ensure complete

documentation of the criteria or definitions used to identify them.

CIP-002-3 R3 Critical Cyber Asset Identification

o Document the criteria used to evaluate the criticality of each type of cyber asset.

It might be helpful to enlist system administrators for each type of asset, system,

or perimeter in the establishment of those criteria, as they are best equipped to

understand impact and criticality.

o Document the process for applying the risk based methodology and completing

the criticality evaluation. Include the process of acquiring the original list of

cyber devices to which the risk based methodology will be applied, the results of

the criticality evaluations (scorecard), and the name(s) and expertise of the

individual(s) completing the assessment.

o For both the criticality methodology and associated documentation, consider

grouping Critical Cyber Assets (CCAs) based on identified subcategories (e.g.,

Operating System (OS), device type, etc.) These categories can expedite the

application of the risk based methodology and make it easier to create

documentation for the other Standards.

o Once the criteria for determining the criticality of a cyber asset are determined,

consider removal of non-Critical Cyber Assets (nCCAs) from within Electronic

Security Perimeters (ESPs) (e.g. printers) that house CCAs. Because nCCAs

within the ESP must be protected in most of the ways CCAs must be protected,

reduction of that list will reduce the overall compliance effort.

o Be prepared to defend what is on your list and what is not on your list.

CIP-002-3 R4 Annual Approval

o Ensure that the senior manager designated in accordance with CIP-003 R2 has, on

an annual basis is approved, signed and dated:

CIP-002-3 R1 and R2 Evidence Considerations:

Critical Asset identification risk-based methodology

Annual records of the application of the risk-based methodology (dated

scorecards)

Critical Asset List or null attestation

CIP-002-3 R3 Evidence Considerations:

Critical Cyber Asset identification methodology

Annual records of the application of the methodology (dated

scorecards)

Critical Cyber Asset list or null attestation


MIDWEST RELIABILITY

ORGANIZATION

the risk-based assessment methodology for determining Critical Assets

(new in CIP-002-2 and continued in CIP-002-3)

the list of Critical Assets

the list of Critical Cyber Assets

o If a delegate has approved, signed and dated any of the identified lists or

methodologies, ensure the delegation of those responsibilities is documented.

o If any null lists exist for the CA or CCA identification, they must still be

approved, signed, and dated.


Dated Sr. Manager or delegate approval for the Critical Asset

identification risk-based methodology

Dated Sr. Manager or delegate approval for the Critical Asset List or

null attestation

Dated Sr. Manager or delegate approval for Critical Cyber Asset List or

null attestation


MIDWEST RELIABILITY

ORGANIZATION

CIP-003-3 – Security Management Controls

The requirements in CIP-003 need to be considered for more than just the Security

Management Controls. Due to potentially-related procedures and literal cross-references,

many of the requirements in CIP-007 will tie back to the requirements herein. It is up to

each entity to determine the extent to which these relationships between the Standards

will create relationships in the individual procedures. Whether operationally tied or not,

where cross-references exist, the requirements should be considered as additive

requirements rather than as replacements.

CIP-003-3 Requirements: R1. Cyber Security Policy — The Responsible Entity shall document and implement a cyber

security policy that represents management’s commitment and ability to secure its Critical Cyber

Assets. The Responsible Entity shall, at minimum, ensure the following:

R1.1. The cyber security policy addresses the requirements in Standards CIP-002-3

through CIP-009-3, including provision for emergency situations.

R1.2. The cyber security policy is readily available to all personnel who have access to,

or are responsible for, Critical Cyber Assets.

R1.3. Annual review and approval of the cyber security policy by the senior manager

assigned pursuant to R2.

R2. Leadership — The Responsible Entity shall assign a single senior manager with overall

responsibility and authority for leading and managing the entity’s implementation of, and

adherence to, Standards CIP-002-3 through CIP-009-3.

R2.1. The senior manager shall be identified by name, title, and date of designation.

R2.2. Changes to the senior manager must be documented within thirty calendar days of

the effective date.

R2.3. Where allowed by Standards CIP-002-3 through CIP-009-3, the senior manager

may delegate authority for specific actions to a named delegate or delegates. These

delegations shall be documented in the same manner as R2.1 and R2.2, and approved by

the senior manager.

R2.4. The senior manager or delegate(s), shall authorize and document any exception

from the requirements of the cyber security policy.

R3. Exceptions — Instances where the Responsible Entity cannot conform to its cyber security

policy must be documented as exceptions and authorized by the senior manager or delegate(s).

R3.1. Exceptions to the Responsible Entity’s cyber security policy must be documented

within thirty days of being approved by the senior manager or delegate(s).

R3.2. Documented exceptions to the cyber security policy must include an explanation as

to why the exception is necessary and any compensating measures.

R3.3. Authorized exceptions to the cyber security policy must be reviewed and approved

annually by the senior manager or delegate(s) to ensure the exceptions are still required

and valid. Such review and approval shall be documented.

R4. Information Protection — The Responsible Entity shall implement and document a program

to identify, classify, and protect information associated with Critical Cyber Assets.

R4.1. The Critical Cyber Asset information to be protected shall include, at a minimum

and regardless of media type, operational procedures, lists as required in Standard CIP-


MIDWEST RELIABILITY

ORGANIZATION

002-3, network topology or similar diagrams, floor plans of computing centers that

contain Critical Cyber Assets, equipment layouts of Critical Cyber Assets, disaster

recovery plans, incident response plans, and security configuration information.

R4.2. The Responsible Entity shall classify information to be protected under this

program based on the sensitivity of the Critical Cyber Asset information.

R4.3. The Responsible Entity shall, at least annually, assess adherence to its Critical

Cyber Asset information protection program, document the assessment results, and

implement an action plan to remediate deficiencies identified during the assessment.

R5. Access Control — The Responsible Entity shall document and implement a program for

managing access to protected Critical Cyber Asset information.

R5.1. The Responsible Entity shall maintain a list of designated personnel who are

responsible for authorizing logical or physical access to protected information.

R5.1.1. Personnel shall be identified by name, title, and the information for which

they are responsible for authorizing access.

R5.1.2. The list of personnel responsible for authorizing access to protected

information shall be verified at least annually.

R5.2. The Responsible Entity shall review at least annually the access privileges to

protected information to confirm that access privileges are correct and that they

correspond with the Responsible Entity’s needs and appropriate personnel roles and

responsibilities.

R5.3. The Responsible Entity shall assess and document at least annually the processes

for controlling access privileges to protected information.

R6. Change Control and Configuration Management — The Responsible Entity shall establish

and document a process of change control and configuration management for adding, modifying,

replacing, or removing Critical Cyber Asset hardware or software, and implement supporting

configuration management activities to identify, control and document all entity or vendor-related

changes to hardware and software components of Critical Cyber Assets pursuant to the change

control process.

Definitions: In addition to those listed below, any proprietary terms used in the

application of CIP-003-3 should be included in any related documentation:

o “Emergency Situations” – It might be helpful to include examples or criteria with a

definition.

o “Critical Cyber Asset Information” – While an information protection program can be

compliant without having a special classification for NERC CIP information, be

prepared to defend any information included, and especially excluded, from the

overall information protection program as it relates to the types of information

prescribed by the Standards.


MIDWEST RELIABILITY

ORGANIZATION

Recommendations:

CIP-003-3 R1 Cyber Security Policy

o The Cyber Security Policy is the only document requiring a senior manager

signature that cannot be delegated. Ensure the individual identified in CIP-003

R2 is the individual that signs/approves this policy.

o For R1.1, “including provision for emergency situations”, is an additive

requirement and must be addressed. It may help to treat it as a separate

requirement. Ensure thorough documentation of the individual(s) with authority

to declare and conclude emergency situations, along with the specific procedures

for those activities. Document the changes to normal operating procedures that

are allowed during emergency situations, as well as the compensatory measures in

place to mitigate risk. (e.g., emergency change controls, exceptions to physical

and logical controls, etc.).

o If your organization has a corporate emergency restoration or business continuity

plan, it is important to ensure that these plans do not contain instructions or

processes that contradict those in place for compliance. To the extent that it is

possible, cross-references will aid responders in ensuring all requirements are

met.

o If your organization allows electronic signatures, consider document management

systems to expedite approvals.

o For R1.2, be prepared to demonstrate that all personnel have access to the cyber

security policy. The text within the policy should explicitly state that availability,

as well as any electronic or hardcopy methods of dissemination. Be sure to

address availability for external personnel.

o TIP: Methods for ensuring availability for external personnel include, but are not

limited to: access to company/corporate internet pages, delivery with annual

training, mailings, or corporate/company billboards.

CIP-003-3 R2 Leadership

o This procedure should, at a minimum, address:

The process for documenting the designation of the “Senior Manager”

responsibilities and any relationship to other roles within the organization

Any delegation processes specific to these responsibilities, including the

approval of the delegation by the Senior Manager

Processes for changing the designation of the “Senior Manager” or any

delegates due to personnel changes or absence.

o Ensure procedures include the relevant documentation updates within 30 calendar

days of the personnel changes.


A Cyber Security Policy

Evidence of availability

Dated Senior Manager review and approval record


MIDWEST RELIABILITY

ORGANIZATION

o TIP: Consider an official form for any delegation which specifies the

responsibilities being delegated and the period of delegation.

o TIP: Minimize delegation. Delegation used in excess can create a negative

impression of corporate leadership and their awareness of and engagement in CIP

activities.

CIP-003-3 R3 Exceptions

o Even if no exceptions are currently necessary, processes for declaration,

authorization, and conclusion should be documented.

o Within exception processes, potential scope of allowable exceptions, any

relationship to Technical Feasibility Exceptions (TFEs), and documentation

requirements for necessity and compensatory measures should be addressed.

o Approval procedures should address annual reviews for existing exceptions as

well as approval of new exceptions outside of the annual review cycle.

o Exception approval and review records should include, at a minimum:

Exception duration

Senior Manager approval date

Summary of exception, along with necessity

Risk analysis

Mitigation/compensatory measures

Subsequent evidence of annual review and approval

o TIP: Long term exceptions are discouraged within successful compliance

programs, unless required by technical infeasibility and documented in

accordance with those requirements.

CIP-003-3 R4 Information Protection

o Information classifications should be defined, including the individual(s) or

role(s) that determines the classification and what protective measures need to be

applied based on that classification.

o Information Protection policies and procedures should ensure the protection of

information through its lifecycle. Procedures should address labeling, access

controls, proper handling/distribution, proper use, storage, and disposal.


Designation of a Senior Manager

Senior Manager approval for delegates

List of delegates with responsibilities

Evidence documentation updates for personnel changes


Initial exception review / approval records

Annual Senior Manager review / approval records


MIDWEST RELIABILITY

ORGANIZATION

o Before classifying information, ensure awareness of its uses, both internally and

publicly. For example, in some locations, floor plans are stored at the county

court house. In those instances, a “confidential” classification may not make

sense unless a copy of that floor plan includes additional, sensitive information.

o For R4.3, ensure a procedure for the assessments is documented, including

initiation, required personnel, sampling criteria, etc. Define any situations or

criteria that would constitute a “deficiency,” as well as acceptable timeframes for

mitigations. Document the process for creating mitigation plans and ensuring

completion within specified timeframes. Also, ensure that the results from the

annual assessments are maintained. Official forms may be helpful for capturing

assessment information.

o TIP: Information protection policies and procedures should be flexible enough to

address newly identified types of information and repositories.

o TIP: An information protection program should include the components found in

requirement #4.

o TIP: If existing information protection policies will be used for NERC CIP

compliance, ensure an annual review of those policies if not already implemented.

CIP-003-3 R5 Access Control

o This requirement is not limited to information protection, it should also be used to

establish access controls for account management as a product of the cross-

reference in CIP-007 R5. As these sub-requirements relate to account

management, they will be addressed in that section of this white paper.

o Know what you have and where it lives. For information, this means a

comprehensive understanding (which can be an inventory) of existing information

is the first step. This includes formats, physical and electronic repositories, any

copies, etc. With respect to information, the Standards do not explicitly require

an information inventory, though it is easy to see how maintenance of an

inventory would aid ongoing compliance. At a minimum, an annual collection

and review of the quantity, quality, and location of information is sufficient.

o Be cognizant of duplicate data used for multiple types of documentation and

different business needs. Multiple controls and repositories may be appropriate to

limit access appropriately.

o At least once annually, the actual access to each repository should be identified,

reviewed, and verified as “appropriate.” Understand that this list may include

personnel (IT or physical plant) that support the infrastructure in addition to users

of the actual information. Even though these personnel do not use the actual


Information Protection policies and procedures

Assessment methodology

Assessment results and action plans


MIDWEST RELIABILITY

ORGANIZATION

information, a “business need” for that access is still demonstrated as it is required

to perform support functions.

o The annual components of this requirement just apply to the access reviews, but

access controls are 24 / 7. Ensure that access to information, either electronic or

physical, has robust change control implemented. This can mean using the same

kinds of request, prerequisite, configuration, and removal processes/timeframes as

are implemented for CCA access, but that level is not required.

o In order to demonstrate the ability to understand point-in-time access to NERC

CIP information, you should either maintain a list with real-time updates to actual

access or you should be able to generate the current list of actual access at any

time. Thoroughly document whatever controls are in place to ensure one or the

other.

o For R5.2, the lists of access, the reviews for appropriateness, the personnel

performing the reviews, and any corrections/mitigations for identified issues

should all be included in the documentation of assessments.

o For R5.3, the controls in place to protect information should be reviewed. To

make this possible, all controls must be documented, and those processes and

procedures should be reviewed at least once annually.

o TIP: Design your data management system to be as automated as possible for

tracking, reviewing, approving, and communicating access changes and changes

to the information, itself.

CIP-003-3 R6 Change Control and Configuration Management

o For configuration management, identify the list of attributes that will be tracked

for each protected cyber asset. To ensure an ongoing understanding of the

configuration of protected devices, create a process and a schedule for verifying

the accuracy of the attributes.

o For change control, the first step is to thoroughly define the changes that must be

documented through this program. Consider decision trees or examples to help

determine whether or not change control processes are required.

o TIP: For defining significant changes, start with the list of significant changes

identified in CIP-007 R1 and R7 and add any others, as appropriate to the

protected systems. In some cases, changes within the application (e.g., clearance

code changes for physical access control systems) may constitute the kinds of

changes requiring formal request and approval processes.


List of personnel responsible for authorizing information access, which

includes names and titles

Annual verification of list of personnel responsible for authorizing

information access

Annual review / verification of the access privileges for information

Annual review of the process for controlling access


MIDWEST RELIABILITY

ORGANIZATION

o Change control programs should identify “normal” change control processes,

which include formal/documented:

request processes that include a description of the change thorough enough

to allow the approver to understand the changes and identify any BES risk

or impact

identification of the appropriate approver(s)

signed (electronic or manual) and dated approval

completion date of the change

o Change control and configuration management programs should have clear

request and approval processes for vendor-related changes or vendor-initiated

changes before the changes are implemented.

o Consider linking test records from CIP-007 R1 to change control processes to

ensure traceability between any significant changes and the required security

testing. NOTE: Be aware that linking change control to security testing by using

the exact same definitions for significant change may programmatically force

security posture testing for application changes that may not impact security of

the device, itself. Analyze several change examples to ensure each program is

joined where feasible and separated where reasonable.

o Consider linking documentation updates to related changes. This can help

demonstrate that changes to documentation were made within compliance

timeframes (usually 30 calendar days).

o Exceptions to normal change control processes should be documented.

“Emergency” change control processes, if allowed, should define acceptable

circumstances for initiation, approval processes, and personnel authorized to

make decisions if primary change approvers or implementers are unavailable.

o If emergency changes are allowed, document their relationship, or lack of

relationship, to the emergency provisions identified for CIP-003 R1.1 or even

other standards. An emergency situation, such as a flood, may not require

emergency changes to any individual cyber assets. Likewise, the necessary

changes may be isolated to a situation requiring immediate resolution for an

individual asset rather than any kind of over-arching emergency situation.


Documented Change Control & Configuration Management process

Change records


MIDWEST RELIABILITY

ORGANIZATION

CIP-004-3 – Personnel and Training

One of the most violated of the Standards is CIP-004. This is probably not due to the

difficulty of compliance, but rather to the strict timelines associated with each

requirement and the volume of individual records needed to prove compliance. Process

documentation will be particularly important, as it will aid in the understanding of inputs

and outputs for each step of any automated or manual processes. This documentation

will also help internal and external personnel understand specific responsibilities and

associated timeframes. Lastly, auditors attempting to understand the implemented access

controls will rely on process documentation and dated evidence to determine compliance.

CIP-004-3 Requirements: R1. Awareness — The Responsible Entity shall establish, document, implement, and maintain a

security awareness program to ensure personnel having authorized cyber or authorized unescorted

physical access to Critical Cyber Assets receive on-going reinforcement in sound security

practices. The program shall include security awareness reinforcement on at least a quarterly

basis using mechanisms such as:

Direct communications (e.g., emails, memos, computer based training, etc.);

Indirect communications (e.g., posters, intranet, brochures, etc.);

Management support and reinforcement (e.g., presentations, meetings, etc.).

R2. Training — The Responsible Entity shall establish, document, implement, and maintain an

annual cyber security training program for personnel having authorized cyber or authorized

unescorted physical access to Critical Cyber Assets. The cyber security training program shall be

reviewed annually, at a minimum, and shall be updated whenever necessary.

R2.1. This program will ensure that all personnel having such access to Critical Cyber

Assets, including contractors and service vendors, are trained prior to their being granted

such access except in specified circumstances such as an emergency.

R2.2. Training shall cover the policies, access controls, and procedures as developed for

the Critical Cyber Assets covered by CIP-004-3, and include, at a minimum, the

following required items appropriate to personnel roles and responsibilities:

R2.2.1. The proper use of Critical Cyber Assets;

R2.2.2. Physical and electronic access controls to Critical Cyber Assets;

R2.2.3. The proper handling of Critical Cyber Asset information; and,

R2.2.4. Action plans and procedures to recover or re-establish Critical Cyber

Assets and access thereto following a Cyber Security Incident.

R2.3. The Responsible Entity shall maintain documentation that training is conducted at

least annually, including the date the training was completed and attendance records.

R3. Personnel Risk Assessment —The Responsible Entity shall have a documented personnel

risk assessment program, in accordance with federal, state, provincial, and local laws, and subject

to existing collective bargaining unit agreements, for personnel having authorized cyber or

authorized unescorted physical access to Critical Cyber Assets. A personnel risk assessment shall

be conducted pursuant to that program prior to such personnel being granted such access except

in specified circumstances such as an emergency.

The personnel risk assessment program shall at a minimum include:

R3.1. The Responsible Entity shall ensure that each assessment conducted include, at

least, identity verification (e.g., Social Security Number verification in the U.S.) and


MIDWEST RELIABILITY

ORGANIZATION

seven-year criminal check. The Responsible Entity may conduct more detailed reviews,

as permitted by law and subject to existing collective bargaining unit agreements,

depending upon the criticality of the position.

R3.2. The Responsible Entity shall update each personnel risk assessment at least every

seven years after the initial personnel risk assessment or for cause.

R3.3. The Responsible Entity shall document the results of personnel risk assessments of

its personnel having authorized cyber or authorized unescorted physical access to Critical

Cyber Assets, and that personnel risk assessments of contractor and service vendor

personnel with such access are conducted pursuant to Standard CIP-004-3.

R4. Access — The Responsible Entity shall maintain list(s) of personnel with authorized cyber or

authorized unescorted physical access to Critical Cyber Assets, including their specific electronic

and physical access rights to Critical Cyber Assets.

R4.1. The Responsible Entity shall review the list(s) of its personnel who have such

access to Critical Cyber Assets quarterly, and update the list(s) within seven calendar

days of any change of personnel with such access to Critical Cyber Assets, or any change

in the access rights of such personnel. The Responsible Entity shall ensure access list(s)

for contractors and service vendors are properly maintained.

R4.2. The Responsible Entity shall revoke such access to Critical Cyber Assets

within 24 hours for personnel terminated for cause and within seven calendar days

for personnel who no longer require such access to Critical Cyber Assets.



o “Authorized Electronic Access” or “Authorized Physical Access” – It might be

helpful to define these where subtle aspects might materially change the access

controls in place.

o “Quarterly” – Like “annual,” this term can be interpreted in a couple different ways.

Document whether this is a rolling quarter or a calendar quarter.

o “Action plans and procedures” – given the sensitive nature of actual response and

recovery plans, it may not be appropriate to share the full plan prior to granting

access. For the purposes of training, create a reasonable abstract that can be used to

meet this requirement.

Recommendations:

CIP-004-3 R1 Awareness

o The quarterly awareness program process documentation should include typical

or acceptable communication methods and frequency, as well as the type of

content that is considered acceptable for the scope of this requirement.

o Security messages can relate specifically to NERC CIP or to general security

concepts.

o Evidence that quarterly awareness messages have been made available should be

kept and should include the date of the message and specific delivery method.

o Ensure that the awareness messages are made available to everyone with NERC

CIP access and that any special communication methods used to reach vendors

and off-site personnel are documented.


MIDWEST RELIABILITY

ORGANIZATION

o Evidence of the receipt/attendance for awareness messages is not required.

o TIP: Use multiple communication methods to reach all intended audience

members (e.g., company intranet for internal personnel plus an email message

directly to external personnel).

CIP-004-3 R2 Training

o Training must be delivered to every individual with physical or cyber access –

this will include physical plant workers, support personnel, and vendors.

Document the controls that prevent access configuration without training and

ensure that evidence of training reflects necessary time/date stamps.

o If third party training solutions or vendor-provided training courses are used,

ensure the content can be mapped back to the R2.2 requirements, and obtain

copies of the content. Be prepared to demonstrate that all training used to comply

with this requirement meets the same criteria. If the training content cannot be

modified to meet the requirements, be prepared to supplement it.

o All content requirements of R2.2 must be met prior to actual access being granted

within the system.

o The training program needs to encompass or include all authorized internal and

external personnel. Evidence of training records need to be maintained and

accessible for demonstrating compliance. Ensure the attendance records include

the necessary time and date stamps and/or signatures. Attestations or lists from

the third party companies with names and dates may not be sufficient.

o TIP: In order to ensure delivery of the training to all personnel with access,

consider multiple delivery methods and even multiple types of courses relative to

each type of access. All training courses, regardless of media or audience, should

map back to the content listed in R2.2.

CIP-004-3 R3 Personnel Risk Assessment

o As with training, the Personnel Risk Assessment (PRA) program needs to

accommodate internal and external individuals. Be prepared to provide the actual

results from the PRA for each individual who has or has had physical or cyber


Documented quarterly awareness program

Content of quarterly awareness messages

Method of dissemination


Documented annual training program

Annual training content, mapped back to R2.2, at a minimum

Annual program review record

Dated attendance records (Correlation with dated access configuration

records will be required for audit)


MIDWEST RELIABILITY

ORGANIZATION

access, regardless of who conducted the assessment. Again, attestations with

names and dates will not suffice. Nor will contracts that demonstrate obligation.

o PRA results can be redacted to remove SS# or driver’s license numbers, but there

should be enough information to uniquely identify the recipient. Also, the results

should contain the dates over which the background investigation was conducted.

o Make sure the personnel risk assessment is done prior to the granting of access. If

access was granted prior to a compliance date, ensure the PRA is completed prior

to that compliance date, as well. There is no such a thing as a “grandfather

clause.”

o Recommendation - Make sure you have a way to evaluate the information

contained in the PRA. Thoroughly define the types of findings that will result in a

denial or an acceptance.

o TIP: From an HR perspective, a restrictive definition for “for cause” used for

initiating an off-cycle PRA may inhibit your ability to conduct a PRA. Be

cautious with this definition, or be silent on its qualifiers.

CIP-004-3 R4 Access

o It is impossible to track too much information about an individual’s physical or

cyber access. Be prepared to produce evidence that specifically identifies the

individual, the acquisition and removal date for every discrete type of access, and

whether any removal was related to a termination or job change.

o Evidence of quarterly access reviews should follow the same guidance as

document reviews, i.e., maintain records that show what was reviewed, who

reviewed it, and any actions resulting from the review.

o The quarterly access review should be more than just a comparison between

approved and actual lists – appropriateness of access should also be verified.

o For R4.2, define the trigger for the 24 hour clock for terminations and the seven

day clock for job changes. This is especially relevant for external personnel

where automated access removals may not be possible. Triggers may vary based

on whether or not the individual is an internal employee.

o Make sure that when access is removed, evidence of the access is not deleted.

Disable accounts, don’t delete them.

o Due to extended transitions and nebulous role/responsibility changes, the actual

timeframes associated with job changes are notoriously difficult to manage.

Make sure your program has thoroughly defined what constitutes a job change or

the “end of business need,” and make sure you have a way to identify when

they’ve occurred. If manual processes are used to initiate changes in access,

make sure your program definitions account for realistic reaction times.


PRA program

Dated, redacted PRA results and assessments (Correlation with dated

access configuration records will be required for audit)


MIDWEST RELIABILITY

ORGANIZATION

o Understand the time requirements for component and potential point of failure for

the access removal process. Tip: Have a default option for removing access (e.g.,

the employee has three days to fill out the form, and if the employee doesn’t fill

out the form, then the manager has three days to fill out a form. If both stages

fail, perhaps access is removed automatically).


Access control processes and policies

Personnel access lists, including specific electronic and physical

privileges

Dated access configuration changes

Dated records of terminations or changes in business need (Correlation

with access configuration records will be needed for audit)

Quarterly access review records


MIDWEST RELIABILITY

ORGANIZATION

CIP-005-3 – Electronic Security Perimeters

In many cases, CIP-005 and CIP-007 are inter-related or look similar (e.g., both have

“vulnerability assessment” requirements). It’s important to remember that these

requirements are not actually duplicative. For CIP-005, the cyber assets addressed are

those that create the perimeter, itself, or any access points to it. For CIP-007, it’s the

devices within the perimeter. To avoid operational confusion and to make things easier

for an auditor to find, make sure your documentation includes a clearly defined scope, is

well-organized and is well-labeled. The documentation for this Standard may greatly

benefit from use of categorization by device type or function.

CIP-005-3a Requirements: R1. Electronic Security Perimeter — The Responsible Entity shall ensure that every Critical

Cyber Asset resides within an Electronic Security Perimeter. The Responsible Entity shall

identify and document the Electronic Security Perimeter(s) and all access points to the

perimeter(s).

R1.1. Access points to the Electronic Security Perimeter(s) shall include any externally

connected communication end point (for example, dial-up modems) terminating at any

device within the Electronic Security Perimeter(s).

R1.2. For a dial-up accessible Critical Cyber Asset that uses a non-routable protocol, the

Responsible Entity shall define an Electronic Security Perimeter for that single access

point at the dial-up device.

R1.3. Communication links connecting discrete Electronic Security Perimeters shall not

be considered part of the Electronic Security Perimeter. However, end points of these

communication links within the Electronic Security Perimeter(s) shall be considered

access points to the Electronic Security Perimeter(s).

R1.4. Any non-critical Cyber Asset within a defined Electronic Security Perimeter shall

be identified and protected pursuant to the requirements of Standard CIP-005-3.

R1.5. Cyber Assets used in the access control and/or monitoring of the Electronic

Security Perimeter(s) shall be afforded the protective measures as a specified in Standard

CIP-003-3; Standard CIP-004-3 Requirement R3; Standard CIP-005-3 Requirements R2

and R3; Standard CIP-006-3 Requirement R3; Standard CIP-007-3 Requirements R1 and

R3 through R9; Standard CIP-008-3; and Standard CIP-009-3.

R1.6. The Responsible Entity shall maintain documentation of Electronic Security

Perimeter(s), all interconnected Critical and non-critical Cyber Assets within the

Electronic Security Perimeter(s), all electronic access points to the Electronic Security

Perimeter(s) and the Cyber Assets deployed for the access control and monitoring of

these access points.

R2. Electronic Access Controls — The Responsible Entity shall implement and document the

organizational processes and technical and procedural mechanisms for control of electronic

access at all electronic access points to the Electronic Security Perimeter(s).

R2.1. These processes and mechanisms shall use an access control model that denies

access by default, such that explicit access permissions must be specified.

R2.2. At all access points to the Electronic Security Perimeter(s), the Responsible Entity

shall enable only ports and services required for operations and for monitoring Cyber

Assets within the Electronic Security Perimeter, and shall document, individually or by

specified grouping, the configuration of those ports and services.


MIDWEST RELIABILITY

ORGANIZATION

R2.3. The Responsible Entity shall implement and maintain a procedure for securing

dial-up access to the Electronic Security Perimeter(s).

R2.4. Where external interactive access into the Electronic Security Perimeter has been

enabled, the Responsible Entity shall implement strong procedural or technical controls at

the access points to ensure authenticity of the accessing party, where technically feasible.

R2.5. The required documentation shall, at least, identify and describe:

R2.5.1. The processes for access request and authorization.

R2.5.2. The authentication methods.

R2.5.3. The review process for authorization rights, in accordance with Standard

CIP-004-3 Requirement R4.

R2.5.4. The controls used to secure dial-up accessible connections.

R2.6. Appropriate Use Banner — Where technically feasible, electronic access control

devices shall display an appropriate use banner on the user screen upon all interactive

access attempts. The Responsible Entity shall maintain a document identifying the

content of the banner.

R3. Monitoring Electronic Access — The Responsible Entity shall implement and document an

electronic or manual process(es) for monitoring and logging access at access points to the

Electronic Security Perimeter(s) twenty-four hours a day, seven days a week.

R3.1. For dial-up accessible Critical Cyber Assets that use non-routable protocols, the

Responsible Entity shall implement and document monitoring process(es) at each access

point to the dial-up device, where technically feasible.

R3.2. Where technically feasible, the security monitoring process(es) shall detect and

alert for attempts at or actual unauthorized accesses. These alerts shall provide for

appropriate notification to designated response personnel. Where alerting is not

technically feasible, the Responsible Entity shall review or otherwise assess access logs

for attempts at or actual unauthorized accesses at least every ninety calendar days.

R4. Cyber Vulnerability Assessment — The Responsible Entity shall perform a cyber

vulnerability assessment of the electronic access points to the Electronic Security Perimeter(s) at

least annually. The vulnerability assessment shall include, at a minimum, the following:

R4.1. A document identifying the vulnerability assessment process;

R4.2. A review to verify that only ports and services required for operations at these

access points are enabled;

R4.3. The discovery of all access points to the Electronic Security Perimeter;

R4.4. A review of controls for default accounts, passwords, and network management

community strings;

R4.5. Documentation of the results of the assessment, the action plan to remediate or

mitigate vulnerabilities identified in the assessment, and the execution status of that

action plan.

R5. Documentation Review and Maintenance — The Responsible Entity shall review, update,

and maintain all documentation to support compliance with the requirements of Standard CIP-

005-3.

R5.1. The Responsible Entity shall ensure that all documentation required by Standard

CIP-005-3 reflect current configurations and processes and shall review the documents

and procedures referenced in Standard CIP-005-3 at least annually.

R5.2. The Responsible Entity shall update the documentation to reflect the modification

of the network or controls within ninety calendar days of the change.


MIDWEST RELIABILITY

ORGANIZATION

R5.3. The Responsible Entity shall retain electronic access logs for at least ninety

calendar days. Logs related to reportable incidents shall be kept in accordance with the

requirements of Standard CIP-008-3.



o “Electronic Access Point” and “Interactive Access Attempt,” – Don’t rely on industry

familiarity for these definitions. Document the definition in use at your organization.

o “Ports and Services required for operation” – Documented definitions for this term

should indicate whether or not ports required for emergency or intermittent operation

are included in the list. Clarity in this definition will aid the development of

vulnerability assessment and security testing procedures for this Standard and CIP-

007.

o “Reportable Incident” or “Cyber Security Incident” – The definitions for these terms

will determine your reporting requirements and the time frames for which you have to

retain certain documentation. Make a clear distinction between these terms and the

types of circumstances that would simply constitute a “cyber security event.”

Recommendations:

CIP-005-3 R1 Electronic Security Perimeter (ESP)

o There are very few “all” statements that should be used in compliance discussions.

Here are two of them:

Make sure you have a list of all the cyber assets you have within the

Electronic Security Perimeter(s) associated with each Critical Asset. This

includes devices that are serially connected and/or considered non-critical.

Make sure you can demonstrate that all of the Critical Cyber Assets

identified under CIP-002 reside within an Electronic Security Perimeter

(ESP).

One method for accomplishing both of these tasks is through the use of ESP

Diagrams. Lists or spreadsheets may also be useful when used in combination

with the ESP diagrams to demonstrate compliance.

o The criticality of each Cyber Asset within the ESP should then be assessed, and

evidence for this assessment should include a list of all the devices, the criteria used

to assess them, and the result of the assessment. This assessment will tell you what

requirements must be followed for each device. It will also tell you where there are

opportunities to move devices out of the ESP to shrink the list of protected devices.

o For R1.1, be sure that documentation includes the process for discovering access

points. These methods may include physical walk-downs of equipment identified as

CCAs, reviews of network drawings, etc. For audit purposes, clear identification of

the individual(s) responsible for this will make it easier to identify the SME that

should be present for the interviews.

o Documentation for R1.1 should also define the implementation and maintenance of

the ESP. Consider addressing how temporary connections such as network sniffers,

test equipment, anti-virus updates, etc. are handled.


MIDWEST RELIABILITY

ORGANIZATION

o Lists of access points to the ESP should include those out of scope for CIP

compliance if those access points have been excluded from the protections identified

in CIP-003 through CIP-009, and the justification for that exclusion should be clearly

documented. For example, dial-up modems or serial connections into the ESP do not

require CIP protective measures if they are non-routable. Ensure your documentation

and your SMEs are prepared to address these.

o For R1.3, documentation for multiple ESPs should clearly indicate that the logical

borders end at the access point (e.g., firewalls or routers) and do not include the

communication links between discrete ESPs.

o For R1.4, with respect to both documentation and physical walk-downs, be able to

distinguish between Critical Cyber Assets and non-Critical Cyber Assets, including

any differences in the way they are protected.

o R1.5 is the first occurrence of two requirements that grow the list of protected devices

outside the ESP to include protection of Intrusion Detection Systems (IDS), Network

Management Systems (NMS), logging/monitoring/alerting solutions, etc. (The twin

of this requirement will be addressed in CIP-006.) For example, if a system has been

implemented to watch the network and parses syslogs for abnormalities on which to

alert support personnel, that system is included in R1.5.

o Note: Any flexibility allowed by a literal interpretation of “…used in access control

and monitoring…” in CIP-005-1 was eliminated when CIP-005-2 and CIP-005-3

included a change to “...used in access control and/or monitoring.” While individual

audit experiences, to date, may have varied with respect to the inclusion of devices

that just performed monitoring, the verbiage in this Standard may allow a stricter

interpretation going forward.

o TIP: Operationally, it may be easier and less confusing to identically protect CCAs,

non-CCAs, and the devices used in the control or monitoring of ESPs and PSPs, but

this is not strictly required for all the CIP Standards.

o For R1.6, ensure your network diagram is clear to someone unfamiliar with your

system to show that every CCA is within the ESP.

o TIP: For network diagrams, it may be easier to use a simple “Network Block

Diagram,” which just shows CCAs and Access Points, rather than a detailed network

diagram.


Documented procedures

Lists of access points

Lists of CCAs and nCCAs within each ESP

Records for Electronic Access Control Systems that mirror the

evidence required for compliance with CIP-003, CIP-004 R3, CIP-005

R2 & R3, CIP-006 R4 & R5, CIP-007 R1 & R3-R9, CIP-008, and CIP-

009.

ESP diagram(s)

Documentation for communication links between ESPs

Identification of dial-up accessible CCAs


MIDWEST RELIABILITY

ORGANIZATION

CIP-005-3 R2 Electronic Access Controls

o Develop policies and/or procedures to describe how electronic access control is

accomplished and maintained. For each individual access point, be capable of

demonstrating the technical and procedural mechanisms.

o Make sure that someone unfamiliar with your system can understand your

documentation for electronic access controls. In particular, the “processes and

mechanisms for control of electronic access” should be clearly documented and may

include a narrative explaining firewall configuration, as well as diagrams that show a

bit more detail than a simple network block diagram.

o Be prepared to provide actual firewall configurations for each access point. This

includes a list of all IP addresses for your CCAs and non-CCAs which will be

verified against the access list. Policies and procedures should clearly state how

access points are controlled and how configuration changes are requested and

implemented.

o Once electronic access controls are configured, a strong change control process will

be required for ensuring that each access point stays in compliance. The change

control process should include approvals by personnel familiar with compliance

requirements and checklists to ensure that configuration is appropriately managed and

tested for new devices or after changes.

o For R2.1, documentation should clearly indicate that “deny by default” policies are

implemented, but this documentation may not, by itself, be sufficient to demonstrate

compliance. Be prepared to provide actual evidence showing a deny-all baseline

configuration, which may include a screenshot of a sample firewall configuration or

logs demonstrating the denials.

o A generic list of all open ports and services will be insufficient to meet R2.2. Don’t

forget to document the “configuration of ports and services” The stack of evidence

for compliance may include any combination or all of the following:

A list of “required” ports and services, which may be based on a blend of

actual documentation from the vendor and narratives from the internal

system administrators explaining the necessity of each required

port/service

Actual lists generated from the firewalls that include comments on each

open port.

The actual scan of the open/enabled ports and services

o TIP: If you have a vendor or application that requires you to keep open a very large

range of ports, documentation from that vendor stating why this is required could

prove useful as evidence.

o If dial-up access is used in any circumstances, compliance evidence for R2.3 will

include documentation of the processes implemented to ensure that it is controlled,

including manual enablement, logging, timeouts, etc.

o For R2.4, be prepared to defend your controls as “strong.” Two-factor authentication

is accepted within the industry, but it is not explicitly required.

o It’s important to define “interactive access attempts.” Based on your definition and

the verbiage in the Standard, a TFE will be required for devices that can’t support the

display of the banner upon the access attempt.


MIDWEST RELIABILITY

ORGANIZATION

o TIP: The purpose of the Banner is to let unauthorized users know that they shouldn’t

be attempting to access the device and to reinforce security to authorized users. In

order to avoid giving additional information to those with potentially malicious intent,

it’s good security practice to avoid including your company name in your Appropriate

User Banner.

o TIP: In order to successfully document the content of the appropriate use banner,

consider incorporating the required banner content into a compliance policy or

procedure and requiring adherence to that verbiage.

CIP-005-3 R3 Monitoring Electronic Access

o For any manual components of compliance with this requirement, be prepared to

demonstrate that it is feasible. For example, if the daily review process for syslogs

for every CCA is manual, make sure that it’s humanly possible to do so.

o TIP: For log reviews, the task may be much more achievable using syslog servers

that have parsing capabilities to notify administrators of access alerts/attempts.

o Be prepared to corroborate the logs being reviewed and ensure evidence is maintained

for demonstrating compliance. An attestation that logs have been checked, either

through automated processes or manually, may not be sufficient. Be prepared to

demonstrate the log review and receipt/acknowledgement of alerts.

o TIP: To demonstrate a manual review, keep the log in data for your syslog server to

show who checked it and when. In order to explain any gaps, keep a log of

maintenance and/or outages for the syslog server.

o For automated alerting, document the rules used to determine notification thresholds.

This is where a distinction between “security events” and potential “security

incidents” will be helpful. (i.e., Alerts for each successful access is not necessary, but

a system administrator may want to investigate multiple failed logins or a single

failed login of an Admin account.)

o Documentation should clearly identify action plans for alerts and how those may be

related to CIP-008.

o TIP: Be cautious about heavy reliance on any messaging servers for NERC CIP

compliance, and be sure to create and document a “backup plan” for periods when the

email server is down.

o For systems that alert within the system itself rather than send an email or page, be

prepared to demonstrate the capability to auditors.

o TIP: Consider recording screenshots of alerts for audit record.


Documented technical and procedural controls

Firewall rules or access lists demonstrating “deny by default”

Lists of required ports and services

Lists of actual ports and services open or enabled

Documented processes for electronic access requests and authorization

Documented authentication methods

Screenshots or documentation of the appropriate use banner


MIDWEST RELIABILITY

ORGANIZATION

CIP-005-3 R4 Cyber Vulnerability Assessments

o Ensure that the vulnerability assessment process, whether managed in-house or via a

3rd

party vendor, addresses all of the sub-requirements of CIP-005 R4 and CIP-007

R8.

o TIP: For 3rd

party vendors, use the actual language of these CIP standards in the

contract with the vendor and use the contract as a portion of your stacked evidence.

o TIP: While a penetration test is useful information, and often accompanies 3rd

party

Vulnerability Assessments, it is not a requirement of the CIP standards.

o Keep ALL “raw” scan information and be prepared to present it. Data in its “ugly”

format does a better job of demonstrating compliance than files that are manipulated

to be easier to read, so be prepared to present both formats.

o Process documentation for vulnerability assessments should include a process for

handling any discovered vulnerabilities. If a vulnerability has been found and

corrected, but not on a device sampled during the audit, it might be helpful to provide

that evidence to show that the process has been implemented successfully.

o TIP: Avoid having the same vulnerability show up on successive assessments. (i.e.,

address the vulnerabilities from your previous assessment before your next one is

performed.)

o TIP: Have you remembered all the default user ID and passwords (e.g., IUser and

IWAM for Windows)? Ask the internet – you may have forgotten some. Again, show

documentation that your assessment verified that these are secured.

CIP-005-3 R5 Documentation Review and Maintenance

o ESP documentation should have strong change controls implemented, and version

history with distribution processes. Maintain version history and be prepared to

discuss or demonstrate the changes for each revision.

o TIP: Keeping redlined versions will expedite the summarization of changes for

ESP documentation.

o Logs must be kept for a minimum of 90 calendar days, and it is not prescribed by

the Standards to do any more. However, for ease of demonstration of compliance,

it might be helpful to keep samples of logs for the entire period between audits to


Documented processes for monitoring and logging access

Access logs and reports

Screenshots/documentation of alerts


Documentation of vulnerability assessment process

Annual vulnerability assessment results, including review of controls

and ports and services

Action plan documentation and status updates related to vulnerabilities

found


MIDWEST RELIABILITY

ORGANIZATION

demonstrate compliance with the logging requirements. Samples can include a 90

day sample for each year or a few days of each 90 day period from each year.

o Before logs are destroyed or deleted, make sure they do not relate to a reportable

cyber security incident, which would increase the retention to 3 years.

o CIP-005 has the only remaining 90 calendar day documentation update

requirement, as the rest of the Standards changed to 30 calendar days with version

2.

o TIP: It might be easier to enforce changes within 30 calendar days within CIP-

005 just like the rest of the compliance program, but it is not strictly required.


Dates of operational changes or infrastructure changes

Dates of documentation updates (Correlation of updates with changes

will be required to demonstrate updates within compliance timeframes)

90 calendar days of logs

Logs, alerts, or documentation related to reportable cyber security

incidents must be kept for 3 years


MIDWEST RELIABILITY

ORGANIZATION

CIP-006-3c – Physical Security of Critical Cyber Assets

It is commonly held in the Information Technology industry that if someone has physical

access to a device, he or she “owns” that device. That can relate to the ability to render

that device ineffective by physical destruction or disconnection, and it can also relate to

the various means that a sophisticated attacker can use to manipulate its functionality, get

information from the device, or leave behind malicious code to cause ongoing damage or

information security issues. For those reasons, the Standard devoted to physical

protection of CCAs is as important as the rest of them and will be rigorously audited.

CIP-006-3c Requirements: R1. Physical Security Plan — The Responsible Entity shall document, implement, and maintain a

physical security plan, approved by the senior manager or delegate(s) that shall address, at a

minimum, the following:

R1.1. All Cyber Assets within an Electronic Security Perimeter shall reside within an

identified Physical Security Perimeter. Where a completely enclosed (“six-wall”) border

cannot be established, the Responsible Entity shall deploy and document alternative

measures to control physical access to such Cyber Assets.

R1.2. Identification of all physical access points through each Physical Security

Perimeter and measures to control entry at those access points.

R1.3. Processes, tools, and procedures to monitor physical access to the perimeter(s).

R1.4. Appropriate use of physical access controls as described in Requirement R4

including visitor pass management, response to loss, and prohibition of inappropriate use

of physical access controls.

R1.5. Review of access authorization requests and revocation of access authorization, in

accordance with CIP-004-3 Requirement R4.

R1.6. A visitor control program for visitors (personnel without authorized unescorted

access to a Physical Security Perimeter), containing at a minimum the following: R1.6.1.

Logs (manual or automated) to document the entry and exit of visitors, including the date

and time, to and from Physical Security Perimeters.

R1.6.2. Continuous escorted access of visitors within the Physical Security

Perimeter.

R1.7. Update of the physical security plan within thirty calendar days of the completion

of any physical security system redesign or reconfiguration, including, but not limited to,

addition or removal of access points through the Physical Security Perimeter, physical

access controls, monitoring controls, or logging controls.

R1.8. Annual review of the physical security plan.

R2. Protection of Physical Access Control Systems — Cyber Assets that authorize and/or log

access to the Physical Security Perimeter(s), exclusive of hardware at the Physical Security

Perimeter access point such as electronic lock control mechanisms and badge readers, shall:

R2.1. Be protected from unauthorized physical access.

R2.2. Be afforded the protective measures specified in Standard CIP-003-3; Standard

CIP-004-3 Requirement R3; Standard CIP-005-3 Requirements R2 and R3; Standard

CIP-006-3 Requirements R4 and R5; Standard CIP-007-3; Standard CIP-008-3; and

Standard CIP-009-3.


MIDWEST RELIABILITY

ORGANIZATION

R3. Protection of Electronic Access Control Systems — Cyber Assets used in the access control

and/or monitoring of the Electronic Security Perimeter(s) shall reside within an identified

Physical Security Perimeter.

R4. Physical Access Controls — The Responsible Entity shall document and implement the

operational and procedural controls to manage physical access at all access points to the Physical

Security Perimeter(s) twenty-four hours a day, seven days a week. The Responsible Entity shall

implement one or more of the following physical access methods: • Card Key: A means of

electronic access where the access rights of the card holder are predefined in a computer database.

Access rights may differ from one perimeter to another.

Special Locks: These include, but are not limited to, locks with “restricted key”

systems, magnetic locks that can be operated remotely, and “man-trap” systems.

Security Personnel: Personnel responsible for controlling physical access who may

reside on-site or at a monitoring station.

Other Authentication Devices: Biometric, keypad, token, or other equivalent devices

that control physical access to the Critical Cyber Assets.

R5. Monitoring Physical Access — The Responsible Entity shall document and implement the

technical and procedural controls for monitoring physical access at all access points to the

Physical Security Perimeter(s) twenty-four hours a day, seven days a week. Unauthorized access

attempts shall be reviewed immediately and handled in accordance with the procedures specified

in Requirement CIP-008-3. One or more of the following monitoring methods shall be used:

Alarm Systems: Systems that alarm to indicate a door, gate or window has been

opened without authorization. These alarms must provide for immediate notification to

personnel responsible for response.

Human Observation of Access Points: Monitoring of physical access points by

authorized personnel as specified in Requirement R4.

R6. Logging Physical Access — Logging shall record sufficient information to uniquely identify

individuals and the time of access twenty-four hours a day, seven days a week. The Responsible

Entity shall implement and document the technical and procedural mechanisms for logging

physical entry at all access points to the Physical Security Perimeter(s) using one or more of the

following logging methods or their equivalent:

Computerized Logging: Electronic logs produced by the Responsible Entity’s selected

access control and monitoring method.

Video Recording: Electronic capture of video images of sufficient quality to determine

identity.

Manual Logging: A log book or sign-in sheet, or other record of physical access

maintained by security or other personnel authorized to control and monitor physical

access as specified in Requirement R4.

R7. Access Log Retention — The Responsible Entity shall retain physical access logs for at least

ninety calendar days. Logs related to reportable incidents shall be kept in accordance with the

requirements of Standard CIP-008-3.

R8. Maintenance and Testing — The Responsible Entity shall implement a maintenance and

testing program to ensure that all physical security systems under Requirements R4, R5, and R6

function properly. The program must include, at a minimum, the following:

R8.1. Testing and maintenance of all physical security mechanisms on a cycle no longer

than three years.


MIDWEST RELIABILITY

ORGANIZATION

R8.2. Retention of testing and maintenance records for the cycle determined by the

Responsible Entity in Requirement R8.1.

R8.3. Retention of outage records regarding access controls, logging, and monitoring for

a minimum of one calendar year.



o “Six-wall Border”– The level of specificity for this definition should include actual

measurements or materials, the sizes of openings, etc. Be prepared to defend this

definition.

o “Physical Access Point” – Again, be as specific as possible with this definition. It

will help create the scope of work necessary for both documentation and controls.

Understand that that the “intent” for the opening will have very little to do with

whether or not it’s considered an access point. Define the types of openings and the

characteristics that create access points, including the disablement of mechanisms that

would have created an opening if unsecured.

o “Response to Loss,” and “Continuous Escort” – The definitions may seem like an

English lesson, but clear and specific definitions will ensure that compliance can be

demonstrated and mapped directly back to the requirements. What kind of loss

(system, badge, etc.)? How many escorts are needed for a certain number of visitors?

Who can be an escort?

o “Physical Access Attempt” and “Forced Entry” – Often the attempts to determine

what alerts should be generated will result in a conversation about what constitutes an

access attempt or a forced entry. Also, it’s unlikely that one card swipe with no

further action is either of these. Document the criteria your company uses to

determine whether either of these two situations existed.

Recommendations:

CIP-006-3 R1 Physical Security Plan

o The physical security plan must contain both a process to ensure that all of the

Critical Cyber Assets identified under CIP-002 reside within a Physical Security

Perimeter (PSP)…and documentation to demonstrate the fact that they actually do

reside with a PSP.

o It can be helpful to implement checklists to ensure that all newly identified CCAs

get assigned to an existing PSP or initiate the commissioning of a new PSP.

o It should be easy to map the documented physical security plan back to each sub-

requirement for CIP-006 R1, and that can mean ensuring each sub-requirement

has its own section or entire document to ensure it’s addressed completely. Each

primary control document should including compensating measures for situations

where that control becomes unavailable or compromised.

o Six-wall borders do not end at ceiling or floor tiles. Ensure that your

implemented and documented borders demonstrate that the perimeter is truly six-

wall. Any portion of that perimeter that can move may be interpreted as an access

point, regardless of whether or not it’s intended to move.


MIDWEST RELIABILITY

ORGANIZATION

o Make sure alternative protective measures are documented and are sufficient to

prevent access to the protected item without the use of special tools. Alternative

measures may include the use of alarms or cameras, posting of a security guard,

or other physical protection.

o Regardless of your specific physical security controls and monitoring systems

(electronic/automated, security guards, etc…), make sure you have provisions in

your plan for special circumstances beyond just outages and maintenance. For

example, automated system alerts may be set at a 15 second threshold for access

points remaining open. There may be reasonable situations that require a longer

opening, like equipment delivery or HVAC issues. Be prepared with documented

alternatives and methods for logging, authentication, etc. when those are in place.

o Don’t forget to address any communication links for a single ESP that span

multiple PSPs. The controls used to protect that cabling should be well

documented. Electronic (Intrusion Detection, other alerts, etc.) and physical

(armored cable, non-public space, etc.) controls can both be used to protect those

links if the actual six-wall border cannot be extended.

o Document the process that will be used to log and escort visitors while in the PSP,

with as much detail as possible around internal definitions, conditions, alternative

methods, and even potential issues caused by restrooms within a PSP.

o Whether paper or automated logging is used for visitor management, be able to

demonstrate, for a given time frame, the date and time of entry and exit, the name

of the visitor, and the name of the escort. If paper logs are used, make sure the

logs identify the specific physical perimeter for which the log is being used.

NOTE: “Calling on,” which is often used in visitor logs to identify the person

being visited, is not the same as “escorted by.” Recording both fields is

acceptable, but the omission of the escort is not.

o In order to make providing logs easier during audits, consider establishing a

process for periodic review and retrieval of the logs for storage in a centralized,

secure repository.

o TIP: Reinforce “continual” escort of visitors to your employees so they can

appropriately plan for ad-hoc or extended visitor requirements. For example,

entities will need to be prepared to provide a continuous escort for a week-long

HVAC project in an EMS equipment room.

o For approvals to the Physical Security Plan, be sure to define the initiation for the

annual review as well as any ad-hoc reviews that would be necessary for updates.

Be clear about which changes require senior manager approval and which do not.


MIDWEST RELIABILITY

ORGANIZATION

CIP-006-3 R2 Protection of Physical Access Control Systems

o This requirement and CIP-005 R1.5 are the two requirements that grow the list of

protected devices outside the CA ESP to include protection of a different class of

devices. These are not CCAs or non-CCAs. Instead, for physical security, these

devices include any device used to authorize or log access to the PSP, like badge

servers or any logging/monitoring/alerting solutions, etc. For example, if a panel

can authenticate a user when connectivity to the badge server is lost, that device

must be protected under the specific requirements referenced by CIP-006 R2.2.

o Physical Access Control Systems only have to be protected by a subset of the

requirements within the Standards, so ensure that any compliance work related to

the cross-referenced requirements are clearly defined in the Physical Security Plan

or other process documentation. For example, Physical Access Control Systems

must be within a PSP, but not an ESP, so have clear documentation reflecting how

these systems are treated differently than CCAs.

CIP-006-3 R3 Protection of Electronic Access Control Systems

o The Electronic Access Control Systems are defined in CIP-005 R1.5, and

documentation should clearly demonstrate that those devices reside within a PSP.


Physical Security Plan

Dates of operational changes or infrastructure changes

Dates of documentation updates (Correlation of updates with changes

will be required to demonstrate updates within compliance timeframes)

Annual Senior Manager review and approval records

PSP diagrams showing borders, controls, and access points

Diagrams or spreadsheets that map each protected device to a location

within an identified PSP

ESP/PSP diagrams showing where a single ESP spans multiple PSPs

Quarterly access review records for all PSPs, along with evidence that

physical access was revoked within compliance timeframes stated in

CIP-004 R4


Physical Security Plan or procedural documentation


within an identified PSP.

Records for Physical Access Control Systems that mirror the evidence

required for compliance with CIP-003, CIP-004 R3, CIP-005 R2 & R3,

CIP-006 R4 & R5, CIP-007, CIP-008, and CIP-009


MIDWEST RELIABILITY

ORGANIZATION

CIP-006-3 R4 Physical Access Controls

o While most physical access is controlled by the methods listed within the

requirement, hard keys can usually be found in one or two locations as additional

methods of entry. Be sure to address physical key management in your policy.

o TIP: Eliminate hard keys wherever possible.

o If you require egress card scans when leaving the PSP, and the card swipe is what

triggers the door mechanism, be sure to understand and document how that

mechanism may be impacted by fire codes and potential corporate safety

programs.

o Your Physical Security Plan or alerting documentation should define the threshold

for forced entry attempts. For example, does presenting a badge that does not

have access rights to a specific door count as an access attempt? If so, you may

be receiving alerts when a passerby gets too close to a badge reader.

o Make sure you understand and document the access that the vendor of your

Physical Access Control System maintains. For example, if the maintenance of

your Physical Access Control System is outsourced to the vendor, they may have

a “skeleton key card” that they use for testing, likely granting them access to

every PSP access point. Eliminate or document this type of situation.

CIP-006-3 R5 Monitoring Physical Access

o When using automated systems, make sure you are able to distinguish between

“unauthorized physical access” and “authorized physical access”. For example, if

a key card is the method used for monitoring, will your system detect when

someone forcibly opens a door? Without being able to recognize when an

unauthorized physical access has occurred, you are only monitoring “authorized”

access. Be sure your monitoring program includes a mechanism to recognize

both types of access or access attempt.

o Glass should be clearly defined as part of the six-wall boundary or as part of an

access point, and then monitored and controlled as appropriate for that definition.

o Documentation should include the types of situations that cause alarms, the

method for “reviewing” them, the way each alarm is “handled,” and a definition

for “immediately.”




within an identified PSP.



Documentation for physical access controls

PSP diagrams showing borders, controls, and access points

Hard Key documentation and logging processes


MIDWEST RELIABILITY

ORGANIZATION

o If an alarm triggers events and investigations associated with a reportable cyber

security incident, those records must be maintained for 3 years. Know, up front,

how you will export/maintain these records.

.

CIP-006-3 R6 Logging

o Both computerized logging and paper logging are allowed, and both may be

necessary to ensure a total logging solution for both unescorted, authorized

personnel entering PSPs using card readers and guests/visitors being escorted.

Ensure the circumstances for using each type of logging are clearly defined in

documentation, including, potentially, the use of paper logs as a compensatory

measure should electronic logging fail.

o Regardless of the method of logging, ensure that enough information is collected

to uniquely identify each person entering a PSP. For escort situations, additional

information should be captured to ensure that the visitor can be linked to an

escort.

CIP-006-3 R7 Access Log Retention

o Logs for a 90 calendar day period must demonstrate 24/7 logging. For the periods

of time between audits but longer than 90 calendar days ago, consider keeping

actual logs or log samples to demonstrate ongoing compliance with any logging

requirements.

o For logged events associated with a reportable cyber security incident, those

records must be maintained for 3 years. Know, up front, how you will

export/maintain these records.

o TIP: Documentation for the processes in place to ensure continuous logging will

provide additional evidence of compliance. For example, is logging verified after

every change? Is logging output verified during other reviews? Are automated

alarms established should any device or perimeter experience a lapse in logs?



Logs of alarms that have been generated

Logs of the review/acknowledgement of each alarm

Evidence and/or documentation of the “handling” of each alarm



Electronic and/or paper logs demonstrating 24/7 tracking of access to

the PSP

Documentation or maintenance/outage records for any lapses


MIDWEST RELIABILITY

ORGANIZATION

CIP-006-3 R8 Maintenance and Testing

o Maintenance and testing programs should clearly document, at a minimum:

Schedules to ensure devices and controls are tested within 3 years

Testing methods, mechanisms, and tools

Lists of expected results from successful tests

Potential responses for any identified issues, including timeframes,

mitigations, and specific actions,

Methods for recording and retaining the results of the testing

o Testing records should contain, at a minimum:

Tester

Date/time stamp

Device/controls tested

Method for testing

Any notes and/or signatures recording during testing

Actual results – stating that no issues were found or listing any issues

identified

If corrective actions or mitigation plans were necessary, that status of

those plans along with resolution dates should be maintained with the

testing records.

o Maintenance records should include dated work orders and any records of

outages. During outages, the compensatory measures put in place to ensure the

perimeter was still controlled should be clearly documented.


Physical Security Plan and/or process documentation

Electronic and/or paper logs demonstrating 24/7 tracking of access to

the PSP

Documentation or maintenance/outage records for any lapses


Physical Security Plan and/or process documentation, including a

Maintenance and Testing Program

Testing records (retained for 3 years)

Maintenance records (retained for 3 years)

Outage records (retained for 3 years)


MIDWEST RELIABILITY

ORGANIZATION

CIP-007-3 – Systems Security Management

CIP-007, in its entirety, applies to every device that has been identified in CIP-002 or

brought into scope with CIP-006. With only the exception of CIP-007 R2, this Standard

also applies to devices brought into scope with CIP-005. Due to the likely breadth and

number of devices, as well as the nature of the requirements, CIP-007 will be the

Standard with the most varied and complicated programs, the highest number of

Technical Feasibility Exceptions (TFEs), and the most frequent and voluminous audit

record creation. The best chance for audit success will be clear documentation for each

requirement on a device by device basis, demonstrating a comprehensive understanding

of the entire inventory of devices as well as rigor in the programs protecting them.

CIP-007-3 Requirements: R1. Test Procedures — The Responsible Entity shall ensure that new Cyber Assets and

significant changes to existing Cyber Assets within the Electronic Security Perimeter do not

adversely affect existing cyber security controls. For purposes of Standard CIP-007-3, a

significant change shall, at a minimum, include implementation of security patches, cumulative

service packs, vendor releases, and version upgrades of operating systems, applications, database

platforms, or other third-party software or firmware.

R1.1. The Responsible Entity shall create, implement, and maintain cyber security test

procedures in a manner that minimizes adverse effects on the production system or its

operation.

R1.2. The Responsible Entity shall document that testing is performed in a manner that

reflects the production environment.

R1.3. The Responsible Entity shall document test results.

R2. Ports and Services — The Responsible Entity shall establish, document and implement a

process to ensure that only those ports and services required for normal and emergency operations

are enabled.

R2.1. The Responsible Entity shall enable only those ports and services required for

normal and emergency operations.

R2.2. The Responsible Entity shall disable other ports and services, including those used

for testing purposes, prior to production use of all Cyber Assets inside the Electronic

Security Perimeter(s).

R2.3. In the case where unused ports and services cannot be disabled due to technical

limitations, the Responsible Entity shall document compensating measure(s) applied to

mitigate risk exposure.

R3. Security Patch Management — The Responsible Entity, either separately or as a component

of the documented configuration management process specified in CIP-003-3 Requirement R6,

shall establish, document and implement a security patch management program for tracking,

evaluating, testing, and installing applicable cyber security software patches for all Cyber Assets

within the Electronic Security Perimeter(s).

R3.1. The Responsible Entity shall document the assessment of security patches and

security upgrades for applicability within thirty calendar days of availability of the

patches or upgrades.


MIDWEST RELIABILITY

ORGANIZATION

R3.2. The Responsible Entity shall document the implementation of security patches. In

any case where the patch is not installed, the Responsible Entity shall document

compensating measure(s) applied to mitigate risk exposure.

R4. Malicious Software Prevention — The Responsible Entity shall use anti-virus software and

other malicious software (“malware”) prevention tools, where technically feasible, to detect,

prevent, deter, and mitigate the introduction, exposure, and propagation of malware on all Cyber

Assets within the Electronic Security Perimeter(s).

R4.1. The Responsible Entity shall document and implement anti-virus and malware

prevention tools. In the case where anti-virus software and malware prevention tools are

not installed, the Responsible Entity shall document compensating measure(s) applied to

mitigate risk exposure.

R4.2. The Responsible Entity shall document and implement a process for the update of

anti-virus and malware prevention “signatures.” The process must address testing and

installing the signatures.

R5. Account Management — The Responsible Entity shall establish, implement, and document

technical and procedural controls that enforce access authentication of, and accountability for, all

user activity, and that minimize the risk of unauthorized system access.

R5.1. The Responsible Entity shall ensure that individual and shared system accounts and

authorized access permissions are consistent with the concept of “need to know” with

respect to work functions performed.

R5.1.1. The Responsible Entity shall ensure that user accounts are implemented as

approved by designated personnel. Refer to Standard CIP-003-3 Requirement R5.

R5.1.2. The Responsible Entity shall establish methods, processes, and procedures

that generate logs of sufficient detail to create historical audit trails of individual

user account access activity for a minimum of ninety days.

R5.1.3. The Responsible Entity shall review, at least annually, user accounts to

verify access privileges are in accordance with Standard CIP-003-3 Requirement

R5 and Standard CIP-004-3 Requirement R4.

R5.2. The Responsible Entity shall implement a policy to minimize and manage the

scope and acceptable use of administrator, shared, and other generic account privileges

including factory default accounts.

R5.2.1. The policy shall include the removal, disabling, or renaming of such

accounts where possible. For such accounts that must remain enabled, passwords

shall be changed prior to putting any system into service.

R5.2.2. The Responsible Entity shall identify those individuals with access to

shared accounts.

R5.2.3. Where such accounts must be shared, the Responsible Entity shall have a

policy for managing the use of such accounts that limits access to only those with

authorization, an audit trail of the account use (automated or manual), and steps

for securing the account in the event of personnel changes (for example, change in

assignment or termination).

R5.3. At a minimum, the Responsible Entity shall require and use passwords, subject to

the following, as technically feasible:

R5.3.1. Each password shall be a minimum of six characters.

R5.3.2. Each password shall consist of a combination of alpha, numeric, and

“special” characters.

R5.3.3. Each password shall be changed at least annually, or more frequently

based on risk.


MIDWEST RELIABILITY

ORGANIZATION

R6. Security Status Monitoring — The Responsible Entity shall ensure that all Cyber Assets

within the Electronic Security Perimeter, as technically feasible, implement automated tools or

organizational process controls to monitor system events that are related to cyber security.

R6.1. The Responsible Entity shall implement and document the organizational processes

and technical and procedural mechanisms for monitoring for security events on all Cyber

Assets within the Electronic Security Perimeter.

R6.2. The security monitoring controls shall issue automated or manual alerts for

detected Cyber Security Incidents.

R6.3. The Responsible Entity shall maintain logs of system events related to cyber

security, where technically feasible, to support incident response as required in Standard

CIP-008-3.

R6.4. The Responsible Entity shall retain all logs specified in Requirement R6 for ninety

calendar days.

R6.5. The Responsible Entity shall review logs of system events related to cyber security

and maintain records documenting review of logs.

R7. Disposal or Redeployment — The Responsible Entity shall establish and implement formal

methods, processes, and procedures for disposal or redeployment of Cyber Assets within the

Electronic Security Perimeter(s) as identified and documented in Standard CIP-005-3.

R7.1. Prior to the disposal of such assets, the Responsible Entity shall destroy or erase the

data storage media to prevent unauthorized retrieval of sensitive cyber security or

reliability data.

R7.2. Prior to redeployment of such assets, the Responsible Entity shall, at a minimum,

erase the data storage media to prevent unauthorized retrieval of sensitive cyber security

or reliability data.

R7.3. The Responsible Entity shall maintain records that such assets were disposed of or

redeployed in accordance with documented procedures.

R8. Cyber Vulnerability Assessment — The Responsible Entity shall perform a cyber

vulnerability assessment of all Cyber Assets within the Electronic Security Perimeter at least

annually. The vulnerability assessment shall include, at a minimum, the following:

R8.1. A document identifying the vulnerability assessment process;

R8.2. A review to verify that only ports and services required for operation of the Cyber

Assets within the Electronic Security Perimeter are enabled;

R8.3. A review of controls for default accounts; and,

R8.4. Documentation of the results of the assessment, the action plan to remediate or

mitigate vulnerabilities identified in the assessment, and the execution status of that

action plan.

R9. Documentation Review and Maintenance — The Responsible Entity shall review and update

the documentation specified in Standard CIP-007-3 at least annually. Changes resulting from

modifications to the systems or controls shall be documented within thirty calendar days of the

change being completed.



o “Significant Change”– This definition may or may not be tied to change control

activities in CIP-003 R6, as a relationship between the two is acceptable, but not

necessary. For its application here, the Standard lists some examples of the types of


MIDWEST RELIABILITY

ORGANIZATION

changes that will require testing, but each entity should ensure that internal

documentation includes any other examples or criteria for determining significant

change.

o “Ports and Services required for operation” – Documented definitions for this term

should indicate whether or not ports required for emergency or intermittent operation

are included in the list. This definition will likely be the same as that used for CIP-

005.

o “Applicable Security Patch” – Ensure the criteria for determining the applicability of

a security patch are well-documented. Criteria can include OS version, implemented

features, or specific configurations of each particular device.

o “All user activity” or “Individual user account access activity” – It’s important to

understand the types of security events you intend and are able to log. Those types of

activity should be clearly documented. Be able to justify these definitions.

o “Logs of sufficient detail” – What can/will the logs capture and how can that be tied

to individual users?

o “Security Events” and/or “System Events” – If the definitions for these terms are in

use for CIP-005, they may be used again in CIP-007 to define the parameters of

Security Status Monitoring. If the terms have not yet been defined as part of

compliance efforts, it’s crucial to do so for this Standard.

Recommendations:

CIP-007-3 R1 Test Procedures

o The documented definition for “Significant Change” should start with the list

provided in CIP-007 R1. It is clear in the Standard that these are considered the

“minimum,” so be prepared to identify more examples of significant change. Use

caution in creating a large list of potential significant changes, as application

changes that happen on a daily or weekly basis may not affect the cyber security

posture of a device and should not be included.

o TIP: Create a decision tree to help system administrators understand when this

requirement must be strictly followed. There should be enough flexibility within

the decision tree to allow some discussion, depending on the situation.

o Within the definition or decision tree for significant change, be sure to address

changes for systems pertaining to physical access, as well. There are

configuration changes that can be made within the application that certainly

change the security posture of a PSP, and those changes should be followed by

testing to ensure that all documented controls are still effective.

o Testing cannot be skipped if test environments do not readily exist. Document

acceptable alternatives for testing, including testing done by the vendor or testing

conducted at similar locations (but not CIP locations) in your organization. All of

this will count.

o Testing can be accomplished in the production environment if documentation

thoroughly justifies that this can be done without adversely impacting that system.

o Test procedures should be defined for every type of covered device, not just PCs

and servers, and those test procedures may vary based on the type of change

implemented. Test procedures should identify, at a minimum:


MIDWEST RELIABILITY

ORGANIZATION

The types of device(s) to which that particular testing methodology applies

The types of changes to which that particular testing methodology applies

Testing timeframes in relation to the implementation and any

documentation updates – Where does it fit?

The test environment used, including any non-production or non-CIP

environments, including vendor locations, or production environments.

Production environment use should be accompanied by justification that

there is no adverse impact

If/How test environments differ from the production environment and a

justification for their use as test environments for significant changes

Any additional operational process that may not be required by the

Standard but impact testing procedures and timelines, including additional

approvals or communications for test completion

o Even though a significant change may not have been related to cyber security

functionality, it may, inadvertently, impact those controls. Therefore, testing for

the change must include more than just the “functionality” of the newly

configured system. Test procedures and accompanying test results should prove

that you were testing for anything that could have had an “adverse affect on

existing cyber controls.”

o Test records should include:

Date or date range

Tester

Device(s) tested

Actual results, including any issues that were found

Action plans and status updates for any identified issues

o While not strictly required, a close relationship can exist between the Testing

program and the program(s) for Change Control and Configuration Management.

A close relationship between those programs may help with ensuring that they do

not occur out of sequence or with any missed tasks. Even if the programs aren’t

closely linked, it will be helpful to be able to identify the specific change that

created the need for each test record.

o TIP: Consider establishing standard test protocols that can be repeated for each

type of significant change.

CIP-007-3 R2 Ports and Services

o Documentation should clearly identify the specific steps used to verify ports and

services. How are “required” ports and services identified and documented? By

what mechanisms and using what tools are open ports and enabled services

obtained from each device? Does that method vary based on the type of device or

within certain ESPs?


Test procedures

Test records


MIDWEST RELIABILITY

ORGANIZATION

o Required ports and services will likely vary for each cyber asset or type of cyber

asset. The documentation for this requirement will be more than just one simple

list. For each device, document the required ports and services and why each one

is necessary. Required ports can be documented in a range, if vendor or

operational documentation will justify the need.

o Your ports and services documentation should address the inclusion or exclusion

of enabled services that do not require a port.

o Ports and services can be considered “required” even if they are not in use. It is

acceptable to allow the inclusion of emergency operations and anything that can

be constituted as operationally necessary by the entity or the vendor

o For the annual verification, the entire list of “required” ports and services does not

have to be open or enabled at the time of the scan. A discrepancy is only noted if

extra ports and services not included in the “required” list are open or enabled.

o TIP: Maintain a baseline list of existing ports and services and record any changes

that occur. When ports or services are no longer required, review access point

controls to deny that port access to the ESP.

o Make sure unnecessary ports and services are disabled before any asset is

implemented.

o If a port is not used but cannot be disabled, ensure the port is not accessible

through the ESP access point, as one of the compensatory measures.

o TIP: Port scanners, if successfully implemented, can be used to automate the

process of determining what ports are open. The success of this will depend

heavily on the specific configuration of the environment, so use extreme caution

and careful evaluation by a highly qualified expert is necessary.

CIP-007-3 R3 Security Patch Management

o Ensure that you can justify your method of “tracking” software patches, like

mailing lists or internet portals, etc. If that type of service is not available, as is

the case with some vendors, the entity is still obligated to document the method

used for monitoring patches for that asset within the 30 calendar day compliance

timeframe. NOTE: If the process is manual, ensure those efforts are tracked (e.g.

Record regular searches conducted on vendor websites for new patches).

o Define the kinds of patches that are considered “security” patches, an inventory of

the software/firmware components that are included in the patch program, and list

the vendors of those types of patches for the covered devices. Have a justification

for those that you choose to include/exclude.

o There is no documented timeframe for the installation of security patches. The

only timeframe established by the Standards is the 30 calendar day applicability

assessment.


Procedures for the controls in place ensuring only required ports and

services are open/enabled

Device by device list of required ports and services

Evidence/scans that demonstrate only those ports and services are open


MIDWEST RELIABILITY

ORGANIZATION

o Applicability assessing are more than just an acknowledgement of the release of

an individual security patch. The assessment process and documented results

should demonstrate a functional knowledge of the types of devices to which it

may be applied and a determination based on the specific configuration of that

device. Applicability assessments should include:

Patch ID

Patch release date

Applicability assessment

Assessment date

o The applicability of a patch will partially depend on the OS version of the

particular device. Additionally, applicability will depend on the specific feature

sets implemented for a particular system. The applicability assessment program

should address the types of factors that will impact whether or not a security patch

can be installed.

o TIP: The same SME may not be able to determine the applicability for every

patch, so it will be helpful to document and/or automate routing for the

assessments.

o Be prepared to demonstrate that *if* a patch is determined “applicable,” it has

either been successfully installed or that documentation exists identifying the

reasons it was not installed. Documentation for not installing an applicable

security patch should include:

The justification for skipping installation

A risk analysis for the specific devices and the BES related to the security

issues resolved by the patch

Measures implemented to mitigate any identified risk

o TIP: Define a timeframe for installation, even though the Standard doesn’t require

a timeframe. Without an internal timeframe for installation, patches could be

considered “applicable” and wait, indefinitely, for installation. If a security patch

remained uninstalled for 2 years after its applicability assessment, it would be

easy for an auditor to argue, at that point, that you decided not to install it and

should be compensating for it. Because installing security patches is risky, it’s

reasonable to use a timeframe that accounts for infrequent patch cycles.

o TIP: For applicable patches not installed, consider documenting a standard set of

mitigating measures already in your environment that mitigate risk.

CIP-007-3 R4 Malicious Software Prevention

o Process documentation should include the type(s) of malware prevention tools

that are implemented as well as the procedure and controls around maintaining

those tools.

o TIP: It might be helpful to include the verification of Malware Prevention

Software in a checklist for all new devices before they are added to an ESP.


Patch Management program documentation

Applicability assessments


MIDWEST RELIABILITY

ORGANIZATION

o Process documentation should address the process for and frequency of signature

file updates, including any testing or implementation in similar environments

prior to update in the production CIP environments.

o TIP: Consider including a step to verify signature files are current and alert if not

within specified parameters.

o If anti-virus software or malware prevention tools cannot be installed on a device,

a TFE is required, and compensating measures for that device must be

documented.

o TIP: Compensating measures for TFEs may include host-based intrusion

detection software, local firewalls, switch port access lists, etc.

o The updates to anti-malware software should use change control process and

testing procedures, in order to be consistent with other types of changes that affect

cyber controls.

CIP-007-3 R5 Account Management

o Account management programs will require both technical and procedural

mechanisms to control access and achieve compliance. Ensure that all controls

are clearly documented. Where strict compliance is not feasible for a specific

device or device type, TFEs must be submitted.

o Define the “user activity” that will be logged, and document which logs are used

to create an audit trail of that activity. Logs should include:

Uniquely identify the user that accessed the system

The account used to access the system

The date and time the user logged in

The date and time the user logged out (depending on the definition of

“user activity”

o Document the process for performing annual reviews. Review programs should

clearly identify the information that will be reviewed and how to document the

review. Review records should include:

The date of the review

Reviewer name

The information reviewed, including the verification that access is

appropriate and based on “need to know”

o Account management controls should include processes to ensure the change of

administrative or shared passwords for personnel changes or a change in a user’s

“need to know.”

o TIP: In order to reduce the number of administrative controls necessary for shared

accounts and to make it easier to track individual user activity, eliminate as many

shared accounts as are technically feasible. Instead, assign administrative rights


Process documentation

TFE (if necessary)

Evidence of malware prevention software installation (Screen prints are

acceptable)


MIDWEST RELIABILITY

ORGANIZATION

to individual accounts. Where administrative or shared accounts must exist,

administrative controls should include policies to limit the use of shared “admin”

accounts.

o Access to shared accounts must be tracked and reviewed at least annually.

Tracking mechanisms can include spreadsheets, lists, password vaults, etc. For

the duration of the audit period, be prepared identify all users with access to any

shared account, the duration for which each user had access, and the individual(s)

who authorized the access.

o Document all manufacturer default accounts and the status of those accounts.

Identify the accounts that have been disabled and purpose and method of securing

the accounts still in use.

o TIP: If the technical enforcement of password strength is based on application

settings or configuration, test and verify the actual enforcement capabilities before

documenting them as part of the implemented controls. For example, some

applications with settings to enforce password rules have actual capability for

verifying only the first few characters, rather than the entire password.

o TIP: Provide individual accounts to vendors and contractors with access rather

than shared accounts, if possible, to allow the tracking user account activity.

CIP-007-3 R6 Security Status Monitoring

o Document the methods and mechanisms used for monitoring, including the source of

data, frequency, any alerts generated, and the basis for the criteria used to establish

alert parameters.

o Document what action is taken when alerts are issued.

o Define which logs contain system events related to cyber security. Ensure that the

method for recovering and retaining these logs is documented and can be maintained

for three years if related to a reported incident.

o For any manual components of compliance with this requirement, be prepared to

demonstrate that it is feasible. For example, if a daily review process is manual,

make sure that it’s humanly possible to do so or use automated parsing solutions for

monitoring and alerting.

o An attestation that logs have been checked, either through automated processes or

manually, will be insufficient. Be prepared to demonstrate the log review or

receipt/acknowledgement of alerts.


Administrative control documentation

Technical control documentation

Shared account lists

Default account lists

Password policies and implemented controls

User access activity logs

Access review records


MIDWEST RELIABILITY

ORGANIZATION

o TIP: To demonstrate a manual review, keep the log in data for your syslog server to

show who checked it and when. In order to explain any gaps, keep a log of when

maintenance or outages for the syslog server.

o For automated alerting, document the rules used to determine notification thresholds.

This is where a distinction between “security events” and potential “security

incidents” will be helpful. (i.e., Alerts for each successful access is not necessary, but

a system administrator may want to investigate multiple failed logins or a single

failed login of an Admin account.)

o TIP: Be cautious about heavy reliance on the email server for NERC CIP

compliance, and be sure to create and document a “backup plan” for periods when the

email server is down.

o For systems that alert within the system itself rather than send an email or page, be

prepared to demonstrate the capability to auditors.

o TIP: Consider recording screenshots of alerts for audit record.

o Be able to demonstrate 90 days of logs have been retained. This may include log

samples from periods within the entire audit period.

o Log review records should contain:

The period of the logs reviewed

The reviewer

The review date

Any action required as a result of the review , along with status updates

CIP-007-3 R7 Disposal or Redeployment

o Disposal and redeployment procedural documentation should clearly identify

controls in place to make sure information is removed and the creation of disposal

or redeployment records.

o Disposal and redeployment records should contain, at a minimum:

Uniquely identified device(s) being removed or redeployed

Date information was removed from the device(s)

Chain of custody until the information was removed

o TIP: If the IP address of the redeployed asset will not be re-used within the ESP,

ensure your process includes a review of access point controls (e.g., firewall

rules) to prohibit access by that IP address.

o For data removal, use methods that will ensure the data is unrecoverable when

erased. Document that method in your process and ensure organizations

responsible for this process are aware of this requirement.


Procedural documentation

Alert review / acknowledgement records

Log review records

90 calendar days of logs

Logs, alerts, or documentation related to reportable cyber security

incidents must be kept for 3 years


MIDWEST RELIABILITY

ORGANIZATION

o TIP: Reference National Institute of Standards and Technology (NIST) or

Department of Defense (DoD) standards for “wiping” drives.

o Disposal and redeployment records should be maintained for the entire audit

period to ensure tracking of all assets removed from the ESP.

CIP-007-3 R8 Cyber Vulnerability Assessment

o Procedural documentation for cyber vulnerability should describe the components

included in the vulnerability assessment process, how the process should be

performed, and how to document the results of the assessment.

o Ensure that the vulnerability assessment process, whether managed in-house or

via a 3rd

party vendor, addresses all of the sub-requirements of CIP-007 R8.

o TIP: For 3rd

party vendors, use the actual language of these CIP standards in the

contract with the vendor and use the contract as a portion of your stacked

evidence.

o TIP: While a penetration test is useful information, and often accompanies 3rd

party Vulnerability Assessments, it is not a requirement of the CIP standards.

o Keep all “raw” scan information and be prepared to present it. Data in its “ugly”

format does a better job of demonstrating compliance than files that are

manipulated to be easier to read, so be prepared to present both formats.

o TIP: If screen captures are included in evidence stacks, make sure the screen

captures include a visible date and time stamp.

o Process documentation for vulnerability assessments must include a process for

handling any discovered vulnerabilities. If a vulnerability has been found and

corrected, but not on a device sampled during the audit, it might be helpful to

provide that evidence to show that the process has been implemented

successfully.

o TIP: Avoid having the same vulnerability show up on successive assessments.

(i.e., address the vulnerabilities from your previous assessment before your next

one is performed.)

o Review system manuals, vendor information, and internet resources to identify all

default accounts. Review controls associated with these accounts to ensure they

are changed from the default value. Again, show documentation that your

assessment verified that these are secured.

o Don’t forget the “assessment” piece. While electronic comparisons can be used

for components of the vulnerability assessment, the final report should contain an

evaluation completed by an SME. Assessment records should list the reviewer or

assessor. .

o Processes for verifying that only necessary ports and services are open and

enabled should include an actual comparison between the required and the actual

ports and services.


Procedural documentation

Vendor or third-party agreements for disposal

Disposal and redeployment records


MIDWEST RELIABILITY

ORGANIZATION

o The assessment, assessment report, and action plan to remediate assessment

findings should be completed within the annual time limit. Action plans should

identify the nature of the finding, the cyber assets affected, the action required, the

individual(s) responsible for those actions and the date due. Actions should be

tracked and brought to completion as promptly as possible.

CIP-007-3 R9 Documentation Review and Maintenance

o All documentation related to CIP-007 compliance should have strong change

controls implemented and distribution processes for communicating changes.

o Version history can demonstrate point-in-time compliance as well as changes

within 30 calendar days for operational changes. Maintain version history and be

prepared to discuss or demonstrate the changes for each revision.

o Annual reviews must be recorded. If no changes are necessary at the time of the

review, a review record should still be captured, and it should include an

attestation that no changes were made. Review records should include, at a

minimum:

A description of the content that was reviewed

Reviewer name

Review date

A summary of changes or an attestation


Documentation of vulnerability assessment process

Annual vulnerability assessment results, including review of controls

and ports and services

Action plan documentation and status updates related to vulnerabilities

found


Annual review records

Version history to demonstrate point-in time compliance

Evidence of updates related to changes


MIDWEST RELIABILITY

ORGANIZATION

CIP-008-3 – Incident Reporting and Response Planning

For this Standard, the bulk of the work is related to making sure everyone knows what to

do if something goes wrong, rather than in the recording and reporting of actual

problems. That having been stated, the value of clearly documenting and practicing

emergency response is undisputed…especially by those who have ever had to face these

types of situations while unprepared to do so.

CIP-008-3 Requirements: R1. Cyber Security Incident Response Plan — The Responsible Entity shall develop and maintain

a Cyber Security Incident response plan and implement the plan in response to Cyber Security

Incidents. The Cyber Security Incident response plan shall address, at a minimum, the following:

R1.1. Procedures to characterize and classify events as reportable Cyber Security

Incidents.

R1.2. Response actions, including roles and responsibilities of Cyber Security Incident

response teams, Cyber Security Incident handling procedures, and communication plans.

R1.3. Process for reporting Cyber Security Incidents to the Electricity Sector Information

Sharing and Analysis Center (ES-ISAC). The Responsible Entity must ensure that all

reportable Cyber Security Incidents are reported to the ES-ISAC either directly or

through an intermediary.

R1.4. Process for updating the Cyber Security Incident response plan within thirty

calendar days of any changes.

R1.5. Process for ensuring that the Cyber Security Incident response plan is reviewed at

least annually.

R1.6. Process for ensuring the Cyber Security Incident response plan is tested at least

annually. A test of the Cyber Security Incident response plan can range from a paper

drill, to a full operational exercise, to the response to an actual incident.

R2. Cyber Security Incident Documentation — The Responsible Entity shall keep relevant

documentation related to Cyber Security Incidents reportable per Requirement R1.1 for three

calendar years.



o “Cyber Security Event” – We all have lots of these, both planned and unplanned.

Access activity, file modification, outages, etc. Cyber Security Events become

important when they happen in a quantity or sequence that might constitute a Cyber

Security Incident. Examples of symptoms will help responders recognize potential

incidents.

o “Cyber Security Incident” – One or more Cyber Security Events might lead us to

believe that further research is necessary to identify a potential problem. If one

exists, we might have the type of incident that needs to be documented and

potentially reported. Be clear in your criteria and in the roles/responsibilities of those

tasked with making that identification.

o “Reportable Incident” – It’s possible that your program stops at “Cyber Security

Incident” and the “reportable” part is included in that definition. If not, make sure the


MIDWEST RELIABILITY

ORGANIZATION

thresholds that make a “Cyber Security Incident” a “Reportable Cyber Security

Incident” are clearly documented.

Recommendations:

CIP-008-3 R1 Cyber Security Incident Response Plan

o It should be easy to map the documented Cyber Security Incident Response Plan

back to each sub-requirement for CIP-008 R1, and that can mean ensuring each

sub-requirement has its own section or entire document to ensure it’s addressed

completely.

o At a minimum, a Cyber Security Incident Response Plan should include:

Possible characterizations/classifications/tiers for cyber security events

Thresholds for determining whether or not observed situations constitute a

Cyber Security Incident and must be reported to ES-ISAC

The person(s) responsible for contacting ES-ISAC and the contact

information should it be necessary.

Response actions for each classification/tier of event/incident

Steps for any investigation or the formation of teams to investigate each

classification/tier

Calling Trees

The expected forensic information that will/should be collected

o TIP: There are lots of available guidance documents for writing these types of

plans. Documenting referenced materials will help demonstrate rigor in

establishing a good plan.

o Understand and address the additional reporting/documentation requirements that

other compliance requirements bring into scope for certain types of events. In

particular, someone should be responsible for ensuring compliance with CIP-001,

CIP-009, EOP-004, and EOP-008.

o Ensure that the drill can be easily mapped back to each section of the Incident

Response plan. The drill should test the plan, and the records from the drill

should demonstrate that.

o Drill records should include, at a minimum:

Signed attendance sheets

A description of the event/scenario tested

The classification of the event and any supporting reasoning

Responses, actions, and communications occurring during the drill

The determination of whether or not ES-ISAC would have been contacted

o TIP: Drills for CIP-009 can be correlated with these drills, as most of the same

personnel will likely be involved, and it will only take a few additions to take care

of both requirements with the same time commitment.

o During annual reviews or exercises, clearly identify any sections/components of

the Incident Response Plan or contact sheets that needed to be updated. Maintain

the record of these corrections to demonstrate the review/update of the plan.

o Communication records should include a distribution list, the notification of

changes (which may include an actual distribution of the new plan or may just be


MIDWEST RELIABILITY

ORGANIZATION

a link to the available materials), and the date of communication demonstrating

the completion within 30 days of the changes.

CIP-008-3 R2 Cyber Security Incident Documentation

o Several other Standards tie into this particular requirement, including log reviews,

alerting/monitoring, etc. Where any of those records indicate or were in response

to an actual Cyber Security Incident, they must be retained for 3 calendar years.

o Because it’s entirely possible that no reportable cyber security incident has

occurred during the previous 3 years, it’s important to create a null attestation for

audit. Silence on this topic is allowed, but it will result in additional questions

during an audit.


Cyber Security Incident Response Plan

Process documentation for conducting the annual drills and reviews

Drill records

Dated records of any updates made to the plan

Dated communication records


Forensic evidence and records collected during the investigation and/or

reporting of an event

Null attestation (if no reportable cyber security incidents occurred)


MIDWEST RELIABILITY

ORGANIZATION

CIP-009-3 – Recovery Plans for Critical Cyber Assets

Most of us are very familiar with disaster recovery plans, and many of us have

participated in the drills associated with those plans. Disaster recovery planning, and in

some cases, business continuity planning, is a normal part of good operational planning.

CIP compliance also requires recovery planning, but there are important distinctions

between the types of disaster recovery plans and drills with which we are all accustomed.

Most disaster recovery plans are activated with the loss of a facility or the loss of a

significant portion of the personnel required for doing business. Recovery plans and

drills for CIP-009 can certainly address those issues, and they should. However, they

also need to address the loss of just one device, potentially related to an isolated failure or

cyber security incident.

CIP-009-3 Requirements: R1. Recovery Plans — The Responsible Entity shall create and annually review recovery plan(s)

for Critical Cyber Assets. The recovery plan(s) shall address at a minimum the following:

R1.1. Specify the required actions in response to events or conditions of varying duration

and severity that would activate the recovery plan(s).

R1.2. Define the roles and responsibilities of responders.

R2. Exercises — The recovery plan(s) shall be exercised at least annually. An exercise of the

recovery plan(s) can range from a paper drill, to a full operational exercise, to recovery from an

actual incident.

R3. Change Control — Recovery plan(s) shall be updated to reflect any changes or lessons

learned as a result of an exercise or the recovery from an actual incident. Updates shall be

communicated to personnel responsible for the activation and implementation of the recovery

plan(s) within thirty calendar days of the change being completed.

R4. Backup and Restore — The recovery plan(s) shall include processes and procedures for the

backup and storage of information required to successfully restore Critical Cyber Assets. For

example, backups may include spare electronic components or equipment, written documentation

of configuration settings, tape backup, etc.

R5. Testing Backup Media — Information essential to recovery that is stored on backup media

shall be tested at least annually to ensure that the information is available. Testing can be

completed off site.



o “Responder” – Not everyone related to CA locations will be required for a recovery

of a device or devices. Make sure the plan clearly states the individuals responsible

for activation and completing any restoration activities, including vendors.

o “Test” – Make sure the components/activities that constitute a test of backup media

are clearly documented and mapped back to the record from that test.


MIDWEST RELIABILITY

ORGANIZATION

Recommendations:

CIP-009-3 R1 Recovery Plans

o At a minimum, a Recovery Plans should include:

The device(s) or device type(s) covered by the specific recovery plans

Roles and responsibilities for each responder

Thresholds, with durations and severities, for determining the activation of

the recovery plan

Steps for the recovery of the each CCA or type of CCA, as well as the

devices brought into scope in CIP-005 and CIP-006

o TIP: You may be able to rely on vendor documentation that already exists.

Vendor services may also be available to get the devices restored to everything

except entity-specific settings or configurations.

o Recovery plans are not necessary for non-CCAs.

o Disaster recovery plans that already exist may not be sufficient for recovery plans,

unless they get to the level of device by device recovery. These plans are not

necessarily for large-scale emergency situations or failovers to other locations.

Recovery may be necessary for just one device, and these plans should reflect

that.

CIP-009-3 R2 Exercises

o It is not necessary to test every restoration of every device or type of device every

year, but entities should construct a drill that creates a realistic scenario that tests

one or more devices.

o Drill records should include, at a minimum:

Signed attendance sheets

The type of drill (actual recovery, tabletop, etc.)

A description of the event/scenario tested

Responses, actions, and communications occurring during the drill

o TIP: Actual recovery activities, if recorded appropriately, can be used to achieve

compliance for the annual exercise.

o TIP: Drills for CIP-008 can be correlated with these drills, as most of the same

personnel will likely be involved, and it will only take a few additions to take care

of both requirements with the same time commitment.


Recovery Plans

Any referenced vendor documentation or contracts/agreements for

portions of the plans handled externally


Drill Records


MIDWEST RELIABILITY

ORGANIZATION

CIP-009-3 R3 Change Control

o During annual reviews or exercises, clearly identify any sections/components of

the Recovery Plan or contact sheets that needed to be updated. Maintain the

record of these corrections to demonstrate the review/update of the plan.

o Communication records should include a distribution list, the notification of

changes (which may include an actual distribution of the new plan or may just be

a link to the available materials), and the date of communication demonstrating

the completion within 30 days of the changes.

CIP-009-3 R4 Backup and Restore

o Again, this is asset by asset documentation of the backup of information required

to get each device back into production operation. Restoration plans are not

necessary for non-CCAs.

o System redundancy is not sufficient to meet this requirement. For example, one

CCA cannot be used as a backup to another CCA in the same location if recovery

is necessary for both devices. Restoration plans should accommodate situations

where all the devices in one location are unavailable.

o If vendor services include the delivery of a device ready for production, plans

should indicate that and identify whether or not additional information is required

by the entity before that device can be used. If additional information is

necessary, the backup location of that information should be documented.

CIP-009-3 R5 Testing Backup Media

o It may be feasible to use different kinds of tests for the various ways information

necessary for restoration is stored. For example, in some cases, the information

may just be a configuration file stored on off-site media. In other cases, backup

media may be a spare hard drive. Be able to justify the testing used for each type

of media.

o Test the backup media for each type of CCA or type of backup process used in the

compliance program, not necessarily every individual CCA. The purpose of this

requirement is to determine that the backup processes produce reliable recovery

ability, rather than an exhaustive test for every discrete file.

o Test records should include, at a minimum:

Tester

Test date


Lessons learned from Drill and the resulting record of changes to the

Recovery Plan

Communication Record


Recovery Plans

Any referenced vendor documentation or contracts/agreements


MIDWEST RELIABILITY

ORGANIZATION

Test method/activities

Device(s) dependent on the media tested

Test results

Any actions taken to mitigate any issues found

o If any testing is conducted by vendors, ensure that records of those tests can be

collected and retained.

o Backup media testing is required, annually, so if the backup media is not tested

during the annual drill, another test must be scheduled and recorded.


Test records


MIDWEST RELIABILITY

ORGANIZATION

Summary

For several important reasons, this paper is not the one, all-compassing set of instructions

for anyone designing a CIP compliance program. First of all, this is just one of the

resources available, and the impact of collaboration with peers, NERC and MRO

guidance documents, CANs, etc., should not be overlooked. Secondly, while this paper

was reviewed by current MRO staff for accuracy, interpretations and experiences of the

auditors will change as time passes, and the expectations for program maturation are

impossible to predict. Lastly, and perhaps most importantly, the CIP Standards are in a

constant state of redraft.

Since 2007, the industry has seen the adoption and enforcement of 3 distinct versions of

the CIP Standards. For some entities, the quantity and quality of the changes with each

of the first few versions may have been relatively mild and predictable. Depending on

the individual implementations, however, some entities may have experienced major

programmatic changes with each version. Regardless of the individual impacts with the

versions up to this point, every entity will soon see dramatic changes in the versions on,

and just beyond, the quickly approaching horizon.

CIP-002-4 through CIP-009-4, including the CIP-005-4 currently working its way

through approval processes, will require entities to prepare in 2011 for an enforcement

date in 2012. The addition of “bright line criteria” removes each entity’s ability to

determine, for itself, which assets are Critical. At a minimum, each organization gets to

scrap any existing methodologies for determining the CA list. At a maximum, many

organizations are going to see scope changes in the number of assets requiring protection,

some of whom are starting from null list today.

Regular updates from members of the drafting team provide glimpses into the format and

intended changes with that version, but the obvious fluctuation in both areas prevent most

entities from planning any actions or determining new direction for existing compliance

programs.

So, our opportunities and obligations, as an industry, remain the same. We must do

today’s work of diligently implementing sustainable programs that clearly demonstrate

compliance while attempting to make tomorrow’s work easier. We must use every

method possible to make the Standards as robust, straight-forward, and well-documented

as our compliance programs have to be.


MIDWEST RELIABILITY

ORGANIZATION

About the Authors

All of the authors have been involved with the NERC CIP compliance efforts at their

organizations. During that time, they have all gathered compliance experience and

knowledge through the design and maintenance of CIP Compliance programs, collaboration

with industry peers, mock and documentation audits with internal and third-party audit

groups, and sufficiency audits and spot-checks.

Dan Barker

Dan has been in the Information Technology field for 15 years, eight of those years as a

member of ATC's Cyber-Security team. Dan is currently a Cyber-Security Compliance

Consultant for ATC, providing input and accountability across all CIP Standards. Dan was

the lead for the Information Technology group, providing testimony and evidence for

NERC's CIP spot-check on all 43 CIP requirements in October of 2010.

Ronald Bender

Ronald Bender has been a Real-Time Analyst with Nebraska Public Power District (NPPD)

for the past 17 years. He designs and maintains computer systems and networks at NPPD’s

System Control Center. He has 21 years of IT experience, 19 years of which are in the utility

industry and has achieved several IT industry certifications. Ron is the NPPD SME for the

CIP-005 and assists with implementation of the other CIP Standards. NPPD completed a CIP

spot-check on all 43 CIP requirements in September, 2010.

Richard Burt

Richard Burt has been with Minnkota Power for 11 years, working in multiple roles within

engineering including telecommunications, SCADA, system studies, and EMS,

including advanced realtime applications such as state estimation and contingency

analysis. He is currently the manager of Minnkota's EMS and Compliance

department, responsible for all control center computer systems, as well as Minnkota's overall

NERC compliance program. He is Minnkota's primary SME on all of the CIP standards, as

well as multiple planning and operating standards. Richard is also Minnkota's Primary

Compliance Contact (PCC), and led Minnkota through a full NERC audit in September of

2009, including a spot check on the first 13 CIP requirements.

Marc Child

Marc Child is an information security professional with fifteen years experience in cyber,

physical, personnel, and data security. As Security Administrator for Great River Energy, he

has responsibility for managing the design and implementation of a security program for

Minnesota’s second largest electric utility, including NERC CIP. Marc currently serves as a

cyber security subject-matter expert on the Critical Infrastructure Protection Committee at

NERC – and in various security roles with the Midwest Reliability Organization.


MIDWEST RELIABILITY

ORGANIZATION

Marc Gaudette

Marc Gaudette has been with Dominion in Richmond, Virginia for more than 20 years.

During that time, he spent approximately 10 years as a nuclear project engineer and 6 years

as Manager of IT and telecommunications support for the nuclear fleet. Marc was also an IT

Program Manager responsible for information security strategic initiatives, security

vulnerability assessments and penetration testing; and Manager of IT Compliance. Marc is

currently the Director of IT Risk Management responsible for cyber security regulatory

compliance programs, security architecture, security policy and litigation support at

Dominion. Dominion completed a NERC CIP-002 Sufficiency Review in July of 2010 and a

SERC TFE Audit in September of 2010.

Jennifer White

Jennifer White has been with Alliant Energy in Madison, Wisconsin for more than 12 years.

During that time, she spent almost 7 years in Information Technology, during which she

assisted with Sarbanes-Oxley compliance efforts and achieved certifications in technical

writing and technical training. Jennifer has been working in the NERC CIP Compliance

Program Office for four years, leading the team for almost the last 2 years. Alliant Energy

completed a CIP spot-check on all 43 CIP requirements in November, 2010.