this Requirement seeks establishment of ``a program for managing access
to protected critical cyber asset information.'' They stress that CIP-
003-1, Requirement R5 relates to the governance and approval process,
not the implementation and review of individual access (the oversight
responsibility of which lies with the senior manager of the responsible
entity). NERC asserts that the three requirements work together. The
implementation provisions are in Requirement R5 of CIP-007-1, the
revocation requirements are in Requirement R4 of CIP-004-1, and the
management review and approval requirements are in Requirement R5 of
CIP-003-1. NERC argues that, together, these provisions serve as a
check that the CIP-004-1 revocation provision has been implemented.
---------------------------------------------------------------------------

    \79\ E.g., APPA/LPPC and California PUC.
---------------------------------------------------------------------------

Commission Proposal
    139. The Commission believes that the language of CIP-007-1,
Requirement R5, CIP-004-1, Requirement R4, and CIP-003-1, Requirement
R5 does not interlink these related provisions as clearly as some
commenters assert. We are not persuaded by commenters who claim these
Requirements adequately address the access issues related to employee
turnover. We believe that the interrelationship among these provisions
must be made clearer. We note that CIP-007-1, Requirement R5.1.3, which
specifically refers to CIP-003-1, Requirement R5, addresses ``user
accounts.'' Likewise, CIP-004-1, Requirement R4 addresses authorization
for unescorted physical or cyber access to ``critical cyber assets.''
However, the information for which Requirement R4 of CIP-003-1 requires
protection appears to be broader than ``user accounts'' and ``critical
cyber assets.'' According to CIP-003-1, Requirement R4, protected
information includes lists of critical cyber assets, floor plans, and
security configuration information. While the concept of access
authorization is similar across these provisions, there is no explicit
mention in them of revoking access to ``information'' about critical
cyber assets. While the priority must be on granting and revoking
access to the critical cyber assets themselves, access to information
concerning the critical cyber assets should also be adequately
protected, and revocations always should be made promptly. We also note
that Recommendation 44 of the Blackout Report stresses the need to
prevent inappropriate disclosure of information.\80\ Thus, the
Commission proposes to direct the ERO to modify Reliability Standards
CIP-003-1, CIP-004-1, and/or CIP-007-1, to ensure and make clear that
access to protected information is revoked promptly.
---------------------------------------------------------------------------

    \80\ See Blackout Report at 169, Recommendation 44.
---------------------------------------------------------------------------

e. Change Control and Configuration Management
    140. Requirement R6 requires the responsible entity to establish a
process of change control and configuration management for adding,
modifying, replacing, or removing critical cyber asset hardware or
software.
    141. The CIP Assessment noted that entities often rely on
commercial vendors to test and certify that electronic security patches
they provide will not adversely affect other electronic systems already
in place. It is not clear how a responsible entity could otherwise
verify that a problem does not exist without burdensome testing each
time a patch is implemented. Such a testing requirement may also
inhibit or delay the use of security patches and thereby prolong
vulnerabilities that would otherwise be relatively easy to fix.
    142. Santa Clara submits that electric utilities, like all ``cyber
users,'' must rely on information technology vendors for accurate and
reliable ``emergency or normal modifications.'' It suggests that it is
not only unrealistic, but unnecessary, to expect that all responsible
entities under the CIP Reliability Standards should, or could, possess
the technical expertise to understand an IT vendor's code in enough
detail to ensure that any modifications made by the IT vendor are
accurate and reliable.
    143. SPP believes that the purpose of the change management program
is to ensure the entity is aware of all changes being made to a
critical cyber asset and, in being aware, readily recognizes when an
unapproved change is made. An unapproved change could be an indication
of a cyber attack in progress. SPP comments that Requirement R6 may
fall short because it does not specify the need for detection and
monitoring controls to determine when changes occur. SPP also asserts
that a proper change management program includes provisions for
routine, planned changes and emergency, unplanned changes.
Commission Proposal
    144. While Requirement R6 of Reliability Standard CIP-003-1
captures the essence of managing changes intentionally made to critical
cyber assets, it fails to address accidental consequences or malicious
actions by individuals. Thus, the Commission believes that this
Requirement needs to go further and we propose to direct the ERO to
make two changes. First, we propose additional wording to require
verification that authorized changes made to critical cyber assets,
which include software and data, only affect processes that are
intended. Our concern here includes both accidental consequences and
malicious actions by individuals performing the changes. Second, we
propose a requirement for responsible entities to take actions to
detect unauthorized changes to critical cyber assets. Such changes
could result from malicious actions originating either outside or
inside the responsible entity. No electronic security perimeter is 100
percent effective, especially when a malicious action is performed by
an insider, and detection must be part of a good cyber security
program. Therefore, the Commission proposes, as suggested by SPP, to
direct the ERO to modify Requirement R6 of Reliability Standard CIP-
003-1 to include in the process of change control and configuration
management a requirement for detection and monitoring controls to
determine if changes are made as intended and to investigate whether
any unintended or unplanned changes have been made.
f. Interconnected Networks
    145. The CIP Assessment also raised a concern that interconnected
control system networks are more susceptible to infiltration by a cyber
intruder. Georgia Operators responds that every responsible entity must
protect its critical cyber assets by guarding its electronic access
points against the spread of harm from external interconnected
entities. This task can only be accomplished by assuming that such
external entities are themselves unprotected.
    146. NERC and ReliabilityFirst claim that the purpose of
establishing policy and procedure is for a responsible entity to
protect itself from the ``outside world'' wherever that ``outside
world'' might exist. It does not matter if the ``outside'' is an
internally connected corporate network, or a completely separate
entity. These commenters explain that the CIP Reliability Standards
address a responsible entity's area of responsibility--the equipment it
owns and controls. All interconnected control system network
communications will traverse through electronic access points;
therefore, there exists a need for ``security'' on the

interconnection points. Both commenters state that the electronic
security perimeter effectively implements a model of mutual distrust
between any collection of critical cyber assets within an electronic
security perimeter, and any and all other cyber assets.
Commission Proposal
    147. The Commission agrees with commenters who caution that a
responsible entity should protect itself from whatever is outside its
control system. The phrase ``mutual distrust'' has been used to denote
how these ``outside world'' systems are treated by those inside the
control system. However, there is very little guidance for how a
responsible entity would configure an architecture under a ``mutual
distrust'' posture to handle both interactive login-type connectivity
between the outside world and the control system as well as direct
application communications (data shared between programs) that also
occur between the control system and the outside world (both internal
and external to the responsible entity). In addition, the Commission
notes that, in our earlier discussion regarding the applicability of
the CIP Reliability Standards to small entities, we relied in part upon
the expectation that the responsible entities would adopt ``mutual
distrust'' postures when receiving communications from others that
impact the functioning of control systems. Therefore, the Commission
proposes to direct the ERO to modify Reliability Standard CIP-003-1 to
provide direction regarding the issues and concerns that a ``mutual
distrust'' posture must address to protect the control system from the
``outside world.'' \81\
---------------------------------------------------------------------------

    \81\ An architecture with a mutual distrust posture could
involve various hardware or software mechanisms or manual procedures
to restrict and verify access to the control system from these
outside sources. Examples include: Firewalls; data checking
software(s); or procedures for manually implementing a connection to
allow a vendor to perform maintenance work.
---------------------------------------------------------------------------

g. Commission Proposal Summary
    148. In summary, the Commission proposes to approve Reliability
Standard CIP-003-1 as mandatory and enforceable. In addition, the
Commission proposes to direct the ERO, pursuant to section 215(d)(5) of
the FPA and Sec.  39.5(f) of our regulations, to develop modifications
to CIP-003-1 through its Reliability Standards development process that
(1) provide additional guidance for the topics and processes that
should be addressed by the required cyber security policy in order to
ensure that the responsible entity reasonably protects its critical
cyber assets; (2) require a responsible entity to submit periodically
to the Regional Entity the documentation of exceptions to the cyber
security policy; (3) clarify that the exceptions mentioned in
Requirements R2.3 and R3 of CIP-003-1 do not except responsible
entities from the requirements of the CIP Reliability Standards; (4)
make clear that the senior manager ultimately remains responsible for
the responsible entity's compliance with the CIP Reliability Standards;
(5) ensure and make clear that access to protected critical cyber asset
information is revoked promptly (and make parallel modifications to
CIP-004-1 and CIP-007-1 as needed); (6) include in the process of
change control and configuration management a requirement for detection
and monitoring controls to determine if changes were made as intended
and to investigate whether any unintended or unplanned changes have
occurred; and (7) provide direction regarding the issues and concerns
that a ``mutual distrust'' posture must address in order to protect a
responsible entity's control system from the ``outside world.''
3. CIP-004-1--Personnel and Training
    149. Reliability Standard CIP-004-1 requires that personnel having
authorized cyber access or unescorted physical access to critical cyber
assets must have an appropriate level of personnel risk assessment,
training and security awareness. Responsible entities must develop and
implement a security awareness program that addresses concerns related
to cyber security; a cyber security training program for affected
personnel that addresses policies, access controls, procedures for the
proper use of critical cyber assets, physical and electronic access to
critical cyber assets, proper handling of asset information, and
recovery methods after a Cyber Security Incident; and a personnel risk
assessment program for all personnel having access to critical cyber
assets.
    150. The Commission proposes to approve Reliability Standard CIP-
004-1 as mandatory and enforceable. In addition, we propose to direct
the ERO to develop modifications to this Reliability Standard. In our
discussion below, the Commission addresses its concerns in the
following topic areas regarding CIP-004-1: (1) Training; (2) personnel
risk assessments; (3) access; and (4) jointly owned facilities.
a. Training
    151. The CIP Assessment noted that the training requirements
specified in Requirement R2 apply to all personnel, contractors, and
service vendors who have authorized cyber access or unescorted physical
access to critical cyber assets.\82\ It then expressed concern that
this requirement does not clearly address the interconnectivity of
systems; i.e., the required training programs should address not only
the critical cyber assets themselves, but also any networking hardware
or software linking them. It noted that the importance of network
support to overall security environment may not be understood by
personnel if the training does not encompass the related non-critical
cyber assets, such as switches and routers that can impact the security
of the critical cyber assets. Moreover, it pointed out that while this
requirement specifies the minimum topics that training should cover, it
does not provide criteria for assessing the quality and adequacy of the
training. With regard to both the awareness program of Requirement R1
and the training program of Requirement R2, the CIP Assessment noted
that certain NIST publications provide guidance on training of
personnel and practices that enhance the security posture of
information systems.\83\
---------------------------------------------------------------------------

    \82\ CIP Assessment at 23.
    \83\ See NIST Special Publication 800-16, Information Technology
Security Training Requirements: A Role- and Performance-Based Model
(1998); and NIST Special Publication 800-50, Building an Information
Technology Security Awareness Training Program (2003), available at:
http://csrc.nist.gov/publications/nistpubs/.

---------------------------------------------------------------------------

    152. NERC states that a subset of networking hardware and software
is included in Requirement R2 to the extent active communications
hardware and software reside within the defined electronic security
perimeter, and because hardware and software acts as an electronic
access control, defining the electronic security perimeter. NERC draws
attention to the fact that communication networks and data
communication links between discrete electronic security perimeters are
specifically excluded by Applicability section 4.2.2 of this
Reliability Standard.
    153. APPA/LPPC believe that most, if not all, networking hardware
and software will be essential to the operation and control of critical
cyber assets and therefore will be subject to the Reliability Standard
and encompassed by the security training requirement. FirstEnergy notes
the Measures and Compliance provisions currently require only
documentation of

the requirements and states that NERC should focus on developing
Reliability Standards to maintain the quality of personnel training in
this area. FirstEnergy states that training requirements should be
appropriate to each employee's experience and access level.
    154. The CIP Assessment also questioned whether it is appropriate
to allow personnel to have access to critical cyber assets for up to 90
days prior to receiving any cyber security training, as Requirement
R2.1 allows. It suggested that personnel should receive the training
prior to such access.
    155. NERC and ReliabilityFirst state that the sub-requirements of
Requirement R2 list specific expected outcomes from the training. NERC
and ReliabilityFirst state that the 90-day period is based on the
belief that certain conditions may require that personnel receive
access prior to specific additional training in cyber security
processes and procedures in order to maintain or restore the reliable
operation of the Bulk-Power System. They explain that standard industry
practice ensures anyone with access to sensitive systems has had
adequate training, but that such training may not have been specific to
the systems or environment to which they receive access, such as when,
in an emergency restoration, personnel with specialized knowledge may
be required to access systems outside their normal assignments.\84\
---------------------------------------------------------------------------

    \84\ APPA/LPPC, SPP and Xcel agree that this flexibility is
needed in emergency situations, and comment that training beforehand
would not always be practical.
---------------------------------------------------------------------------

    156. APPA/LPPC agree with the CIP Assessment that, whenever
possible, personnel should receive their cyber security training and
undergo the required personnel risk assessment before being allowed
access to critical cyber assets. However, APPA/LPPC favor retention of
the 90-day period for conducting training so that responsible entities
will not risk a technical violation of the Reliability Standard when
emergency conditions require that personnel obtain access before they
are trained or authorized with access.
    157. ISA Group agrees with the CIP Assessment that training in
critical security practices should occur prior to an individual having
the corresponding access and suggests making a distinction between the
training that is needed before access is granted and the remaining
training that is not critical for access but still significant. The ISA
Group also states that training and awareness programs should be
specific to the critical cyber assets to be protected and that persons
who provide the training should be adequately trained to address the
cyber security of the systems. SPP and ISO-NE agree with the CIP
Assessment that allowing unescorted access to critical cyber assets
prior to security training introduces an unnecessary risk. SPP suggests
that, under normal circumstances, training prior to access should be
the requirement with provisions made for emergency conditions.
Commission Proposal
    158. Training is clearly integral to the protection of critical
cyber assets. Allowing personnel to access critical cyber assets prior
to receiving training increases the vulnerability of and risk to such
assets. Thus, such access should not be the norm under the Reliability
Standard. Accordingly, we propose to direct the ERO to modify this
provision to require affected personnel to receive the required
training before obtaining access to critical cyber assets (rather than
within 90 days of access authorization), but allowing limited
exceptions, such as during emergencies, subject to documentation and
mitigation.
    159. Alternate provisions for emergencies and certain other
conditions could be designed, such as requiring documentation of all
personnel who received access to particular equipment during the
emergency and whether they received a briefing or any other training
prior to their access concerning the specific facilities; the extent to
which people needed for the emergency had received general training and
possessed appropriate specialized expertise for the circumstance; and
any risk mitigation steps taken during the emergency access, as
discussed by commenters in this proceeding. To facilitate
communications in emergency situations, the Commission proposes to
direct the ERO to require responsible entities to identify ``core
training'' elements to ensure that essential training elements will not
go unheeded in an emergency and other contingency situations where full
training prior to access will not best serve the reliability of the
Bulk-Power System. We note that during ``emergency conditions,'' the
Bulk-Power System could be particularly vulnerable to mischief or
mistakes, and we propose to require the ERO to consider this when
developing the modification. We also propose to direct the ERO to
consider what, if any, modifications to CIP-004-1 should be made to
address the concern raised by the ISA Group that security trainers be
adequately trained themselves.
    160. In addition, we propose to direct the ERO to modify the CIP-
004-1 to clarify that the cyber security training programs required by
Requirement R2 are intended to encompass training on the networking
hardware and software and other issues of electronic interconnectivity
supporting the operation and control of the critical cyber assets. As
indicated by the comments, it is not clear whether interconnectivity
issues are already included in the proposed language of the training
requirement of CIP-004-1. One method of clarification the ERO should
consider is the addition of a provision such as that contained in CIP-
005-1, Requirement R1.4, which specifically subjects any non-critical
cyber asset within a defined electronic security perimeter to the
Reliability Standard. CIP-004-1 should leave no doubt that cyber
security training concerning a critical cyber asset should encompass
the electronic environment in which the asset is situated and the
attendant vulnerabilities.
    161. Finally, we propose to direct the ERO to increase the guidance
in the Reliability Standard as to the scope and quality of training. We
note that part of the goal for training, in conjunction with awareness
programs, is to keep security practices on the minds of employees,
contractors, and vendors. Examples of some areas where the inclusion of
guidance can be considered are: control of electronic devices (such as
laptop computers), the appropriate audiences for the training, delivery
methods, and updates of training materials. In our view, the awareness
and training programs, addressed separately by Requirements R1 and R2,
complement each other and work in tandem. In parallel with the security
awareness program, we expect the ERO to consider relevant aspects of
the cited NIST Special Publications, as well as other relevant models,
to improve CIP-004-1 and prevent a lowest common denominator result.
b. Personnel Risk Assessment
    162. Requirement R3 of CIP-004-1 requires each responsible entity
to have a documented personnel risk assessment program. It also
requires that a personnel risk assessment, including a criminal check,
be conducted within 30 days after a person receives cyber access or
unescorted physical access to critical cyber assets. The CIP Assessment
noted that Requirement R3 would allow access to critical cyber assets
while investigation is still underway, and even before an investigation
has started.

    163. NERC and ReliabilityFirst assert that certain conditions
affecting the reliable operation of the Bulk-Power System may require
that personnel be allowed to access the critical cyber assets prior to
completing the personnel risk assessment process, although they may be
subject to escort and review during the investigative period.
    164. Several commenters agree with the CIP Assessment that an
appropriate personnel risk assessment should be completed before an
employee (especially a newly hired employee or vendor) is granted
access to critical cyber assets. SPP states that emergency contingency
procedures can be developed to handle situations where access must be
granted prior to completing the required background check.
    165. However, NERC and other commenters have concerns about
existing personnel. NERC and ReliabilityFirst assert that certain
conditions affecting the reliable operation of the Bulk-Power System
may require that personnel be allowed to access the critical cyber
assets prior to the completion of the personnel risk assessment
process, although they may be subject to escort and review during the
investigative period. National Grid expresses concern that, since the
Requirement appears to apply to a significant portion of existing
utility workforce, any attempt to revoke access to such employees while
completing their personnel risk assessments would create more
reliability concerns than simply allowing such employees to remain on
the job. FirstEnergy states that the 30-day window may be appropriate
for employees and vendors with which the responsible entity has had a
working relationship. FirstEnergy comments that Requirement R3 does not
provide sufficient detail on what constitutes an adequate personnel
risk assessment, which could cause variable interpretations of this
Requirement. ISO-NE agrees with the CIP Assessment that the Reliability
Standard provides insufficient direction regarding the elements of an
appropriate awareness program.
Commission Proposal
    166. Similar to our concerns regarding the training provisions of
Requirement R2, we believe that allowing applicable personnel,
including vendors, to access critical cyber assets prior to the
completion of their personnel risk assessment increases the
vulnerability of, and risk to, these assets. We also observe that
Recommendation 41 of the Blackout Report emphasizes the need for
guidance on implementing background checks.\85\ At the same time, we
believe that commenters have raised a valid concern regarding the
disruptions that would result if current employees and vendors with
established involvement were denied access to critical cyber assets for
a 30-day period. Accordingly, we propose that the ERO develop
modifications to Requirement R2 to provide that newly-hired personnel
and vendors should not have access to critical cyber assets, except in
specified circumstances such as an emergency. The ERO should determine
the parameters of such exceptional circumstances in developing the
proposed modification through its Reliability Standards development
process. However, to avoid disruptions, we propose that the 30-day
window allowing access before the personnel risk assessment is
completed remain in effect for current employees and vendors with
existing contractual relationships with the responsible entity as of
the effective date of the Reliability Standard. We propose to direct
that the ERO include, in developing modifications to CIP-004-1,
criteria that address circumstances in which current personnel can
continue access to critical cyber assets during the 30-day
investigative period during initial compliance with CIP-004-1.
---------------------------------------------------------------------------

    \85\ See Blackout Report at 167-168, Recommendation 41, where
the Blackout Report recommends that NERC provide guidance on
background checks to be completed on contractor and sub-contractor
employees in advance of allowing access to secure facilities.
---------------------------------------------------------------------------

c. Access
    167. Requirement R4 directs the responsible entity to maintain
list(s) of personnel with authorized cyber or authorized unescorted
physical access to critical cyber assets. The CIP Assessment observed
that the lists do not serve to deny personnel access from critical
cyber assets prior to completion of a personnel risk assessment.
However, Requirement R4.2 requires that access to critical cyber assets
be revoked within 24 hours for personnel terminated for cause and
within seven calendar days for personnel who no longer require such
access.
    168. NERC states that while the access list itself does not prevent
access, it does provide for identification of personnel for which
additional levels of review and escort may be assigned. California PUC
suggests amending the Reliability Standard to require immediate updates
when an employee is transferred, retires, or is terminated.
Commission Proposal
    169. Timely system updates to access rights are important.
Employee, contractor, or vendor access to critical cyber assets when
the employee, contractor, or vendor no longer has a need for such
access, due for example to a transfer or termination, represents a gap
in security. Moreover, while Requirement R4 of CIP-004-1 requires a
responsible entity to maintain a list of authorized personnel, it does
not indicate what the responsible entity must do with the list.
Accordingly, the Commission proposes to direct that NERC develop
modifications to CIP-004-1 to require immediate revocation of access
privileges when an employee, contractor, or vendor no longer performs a
function that requires authorized physical or electronic access to a
critical cyber asset for any reason (including disciplinary action,
transfer, retirement or termination). Because an organization is
typically aware in advance of personnel action dates, timely updating
of the authorization list should not be unduly burdensome. Further, we
propose to direct that NERC modify Requirement R4 to make clear that
unescorted physical access should be denied to individuals that are not
identified on the authorization list.
d. Question of Jointly Owned Facilities
    170. APPA/LPPC request that the Commission direct NERC to consider
clarifications for entities with facilities governed by existing joint
use or joint ownership agreements. They explain that most of there
members have joint facilities with neighboring entities (e.g., a
transmission substation at a point of interconnection with an adjacent
system), and that joint facility agreements often prohibit individual
co-owners from blocking the other co-owners' use of, or access to, such
facilities. APPA/LPPC state that CIP-004-1 obligates individual
responsible entities to block certain persons from their facilities,
possibly including persons with existing contractual rights of access.
APPA/LPPC believe that one joint facility owner should not be able to
block another unaffiliated entity's existing contractual rights of
access. APPA/LPPC also ask that entities with joint facilities not be
subject to sanctions solely because an unaffiliated entity that is a
party to one of its joint facility agreements failed to comply with
CIP-004-1 when acting independently.
Commission Proposal
    171. The Commission views joint owners of critical cyber assets as
being

equally subject to the CIP Reliability Standards as other responsible
entities. If an asset is designated as a critical cyber asset by one
joint owner, it must be treated likewise by the other owner(s). Thus,
each entity that possesses an interest in a jointly-owned facility
would be responsible to develop a list of its authorized personnel and
to respect each other joint owner's corresponding list.
    172. APPA/LPPC also raise the issue of ``joint use'' arrangements.
For example, an owner of a critical cyber asset substation may well
house electronic or other equipment on its premises that belongs to
another entity that may or may not be subject to these Reliability
Standards. The Commission believes that, in principle, the owner of a
critical cyber asset is responsible under the Reliability Standards for
ensuring that all persons having access to the critical cyber asset
meet the requirements of these Reliability Standards, much as the owner
is responsible to ensure that vendor personnel have the required levels
of security training, awareness and background checks.
    173. Nevertheless, we can appreciate that even with this general
guidance, further clarification regarding how ``joint use''
arrangements should be addressed. Therefore, we propose to direct the
ERO to address the ``joint use'' concerns expressed by APPA/LPPC while
developing any modifications to these Reliability Standards directed in
a final rule. Regardless of whether a facility subject to CIP-004-1 is
jointly owned or not, all entities that have access to it must comply
with CIP-004-1. Each entity, however, is responsible for only its
compliance and may not attempt to block or limit another's access on
the basis of its perception that the other entity has not complied with
CIP-004-1. In the event non-compliance is suspected, it must be
promptly reported to the Regional Entity or ERO.
e. Commission Proposal Summary
    174. In summary, the Commission proposes to approve Reliability
Standard CIP-004-1 as mandatory and enforceable. In addition, the
Commission proposes to direct the ERO, pursuant to section 215(d)(5) of
the FPA and Sec.  39.5(f) of our regulations, to develop modifications
to CIP-004-1 through its Reliability Standards development process
that: (1) Require affected personnel, with limited exceptions, to
receive required training before obtaining access to critical cyber
assets (rather than within 90 days of access authorization); (2)
require responsible entities to identify ``core training'' elements to
ensure that essential training elements will not go unheeded in an
emergency and other contingency situations where full training prior to
access will not best serve the reliability of the Bulk-Power System;
(3) clarify that the cyber security training programs required by
Requirement R2 are intended to encompass training on networking
hardware and software and other issues of electronic interconnectivity
supporting the operation and control of critical cyber assets; (4)
provide increased guidance on the scope and quality of training; (5)
make modifications to Requirement R2 to provide that newly-hired
personnel and vendors should not have access to critical cyber assets,
except in specified circumstances such as an emergency; (6) address
circumstances in which current personnel can continue access to
critical cyber assets during the 30-day investigative period during
initial compliance with CIP-004-1; and (7) require immediate revocation
of both physical and electronic access privileges when an employee, for
any reason (including disciplinary action, transfer, termination, or
retirement), no longer performs a function that requires access to
critical cyber assets.
    175. In addition, the Commission proposes to direct the ERO to (1)
consider what, if any, modifications to CIP-004-1 should be made to
address the concern raised by the ISA Group that security trainers be
adequately trained; (2) consider relevant aspects of certain NIST
Special Publications, as well as other relevant models, to improve CIP-
004-1; and (3) address the ``joint use'' concerns expressed by APPA/
LPPC and discussed herein by the Commission when developing
modifications to the Reliability Standards that the Commission may
direct when we issue our final rule.
4. CIP-005-1--Electronic Security Perimeter(s)
    176. Reliability Standard CIP-005-1 requires identification and
protection of the electronic security perimeters inside which all
critical cyber assets are located, as well as all access points. The
electronic security perimeters are to encompass all the critical cyber
assets that are identified using the risk-based assessment methodology
required by Reliability Standard CIP-002-1. Multiple electronic
security perimeters may be required; for example, one may be needed
around a control room while another may be established around a
substation. Once each electronic security perimeter has been
established, the responsible entity must develop mechanisms to control
and monitor electronic access to all electronic access points.
Furthermore, the responsible entity must assess the electronic security
perimeter's cyber vulnerability and test every electronic access point
at least annually.
    177. The Commission proposes to approve Reliability Standard CIP-
005-1 as mandatory and enforceable. In addition, we propose to direct
the ERO to develop modifications to this Reliability Standard. Further,
the Commission also proposes to require the ERO to consider various
other matters of clarification, guidance, and modification. In our
discussion below, the Commission addresses its concerns in the
following topic areas regarding CIP-005-1: (1) Adequacy of electronic
security perimeters; (2) protecting access points and controls; (3)
monitoring access logs; (4) vulnerability assessments; and (5) document
updates.
a. Adequacy of Electronic Security Perimeters
    178. Requirement R1 of CIP-005-1 addresses the identification of
electronic security perimeters to ensure that every critical cyber
asset resides within one. The CIP Assessment explained that the
electronic security perimeter constitutes the appropriate first line of
defense. However, a responsible entity should use a cyber security
protection program that contains additional security measures to detect
and stop intrusions that penetrate the outer shell of the defense
(i.e., a defense in depth approach).
    179. APPA/LPPC and Xcel agree with the CIP Assessment's concept of
defense in depth and when possible, securing the non-critical cyber
assets outside the electronic security perimeter. However, APPA/LPPC
state that the use of ``defense in depth'' may not be practical for all
critical cyber assets, such as assets supplied by vendors that are no
longer in business.
    180. Xcel notes that a line needs to be drawn in order to avoid
responsible entities taking expensive precautions that are not cost-
effective. It further adds that CIP-005-1 should not be extended to
equipment and systems beyond the electronic security perimeter.
Commission Proposal
    181. The Commission recognizes that there is a point at which
having multiple defense layers would not be cost effective. However,
the effectiveness of any one defense measure is often dependent upon
the quality of active human maintenance, and there is no one perfect
defense measure that will guarantee the

protection of the Bulk-Power System. Therefore, we believe that a
responsible entity must implement two or more distinct security
measures when constructing an electronic security perimeter. Thus, the
Commission proposes to direct the ERO to develop a requirement to
implement a defensive security approach including two or more defensive
measures in a defense in depth posture. This approach should not
inhibit, but instead supplement the establishment of an electronic
security perimeter. While such layers/measures are generally integrated
within and constitute part of a system or program, many are also
effectively, and more feasibly, placed ``in front of'' a system, such
as an older, legacy system.
b. Protecting Access Points and Controls
    182. Requirement R2 of CIP-005-1 requires a responsible entity to
implement organizational processes and technical and procedural
mechanisms for control of electronic access at all electronic access
points to the electronic security perimeter. Requirement R2.4 requires
``strong procedural and technical controls'' at enabled external access
points ``to ensure authenticity of the accessing party, where
technically feasible.''
    183. The CIP Assessment raised concerns regarding the qualifier
``where technically feasible'' in Requirement R2.4. The CIP Assessment
also cautioned that keeping pace with advances in cyber security is a
necessary part of the defense strategy needed to protect against
intrusion by an adversary. The CIP Assessment noted that implementation
and maintenance of strong controls to ensure authenticity of the
accessing party is not a question of technical feasibility. It
represents that the technology currently exists and that every
responsible entity identifying critical cyber assets should be able to
implement such controls. Balancing an appropriate mix of protections
and technology is part of achieving effective cyber security. The CIP
Assessment also expressed the view that Requirement R2.4 should not
allow a responsible entity to fail to implement rudimentary procedural
and technical access controls.
    184. California PUC states that electronic access from outside the
electronic security perimeter should require strong verification, such
as digital certificates or two-factor authentication. It suggests that
such a system is virtually impenetrable and that it, or some similar
system, should be required in the CIP Reliability Standards.
    185. California PUC comments that access controls should be
implemented at all access points to the network and that the caveat of
``technical feasibility'' in the NERC-proposed Reliability Standard is
inappropriate. California PUC further states that Requirement R2.0
prescribes, inter alia, that only those ports and services required for
normal or emergency operations should be enabled, while all others
should be disabled. Furthermore, it notes that access control,
including the authorization process and authentication method for each
access point, should be documented. Access should be monitored twenty-
four hours a day, seven days a week, and disturbances and unauthorized
access attempts should be identified. All responsible entities should
conduct vulnerability assessments of their access points, scanning to
verify that only the proper ports and services are enabled. California
PUC agrees with the CIP Assessment assertion that ``such (strong access
control) technology currently exists'' and implementation by every
entity is feasible.
    186. NERC disagrees with the CIP Assessment comment that a
``technical feasibility'' caveat is not needed in Requirement R2.4,
particularly for legacy implementations and substation environments.
NERC agrees that the CIP Assessment statement may be applicable in a
modern control center environment, where common IT systems have
migrated into the control environment. However, NERC states that this
is not the case for many existing field systems. The technical
feasibility clause, NERC claims, is needed to accommodate the vast
majority of legacy systems that cannot be upgraded due to the age and
nature of their system configurations.\86\
---------------------------------------------------------------------------

    \86\ Progress Energy, ReliabilityFirst, and Santa Clara agree
with NERC.
---------------------------------------------------------------------------

    187. Given the numerous scenarios surrounding access control, APPA/
LPPC believe that removing the ``technically feasibility'' caveat will
not provide a solution in every situation. They assert that Requirement
R2.4 is appropriate as currently written. APPA/LPPC note that some
access control solutions, such as biometric ones, are still subject to
failure and may grant access to unauthorized people.
Commission Proposal
    188. Requirement R2.4 of CIP-005-1 calls for the implementation of
``strong procedural or technical controls'' at access points to ensure
authenticity of the accessing party. While we agree with the goal of
Requirement R2.4, we are concerned that requiring ``strong'' controls
does not provide sufficient guidance and possibly sets subjective
criteria. Thus, we believe that Requirement R2.4 should provide greater
clarity regarding the expectation for adequate compliance by
identifying examples of specific verification technologies that would
satisfy the Requirement, while also allowing compliance pursuant to
other technically equivalent measures or technologies. The Commission
agrees with California PUC that strong verification includes
technologies such as digital certificates and two-factor
authentication. We also note that Recommendation 32 of the Blackout
Report emphasizes the need ``to ensure access is granted only to users
who have corresponding job responsibilities.'' \87\ We propose to
direct the ERO to modify this Reliability Standard accordingly.
---------------------------------------------------------------------------

    \87\ See Blackout Report at 164-165, Recommendation 32.
---------------------------------------------------------------------------

    189. The Commission believes that providing such basic security
measures as access control can be accomplished using/placing measures
``in front of'' systems as opposed to ``inside'' systems. Such an
approach can be used to secure even older, yet functioning, legacy
systems. The Commission proposes to direct the ERO to evaluate the
issue and provide specific guidance to responsible entities that must
face such issues.
    190. The Commission is persuaded by commenters that maintain that,
due to the variety of equipment and systems, some discretion must be
preserved that would allow responsible entities to control access
points. Further, in our general discussion of ``technical feasibility''
in section II.A.5.b above, we explained that, while we have concerns
regarding the broad discretion currently allowed in the use of the
technical feasibility language, we would not propose to eliminate the
provision but, rather, propose to require specific controls and
accountability when a responsible entity chooses to invoke the
provision. Specifically, a responsible entity invoking a technical
feasibility exception would have to: (1) Develop and implement interim
mitigation steps to address the vulnerabilities associated with each
exception; (2) develop and implement a remediation plan to eliminate
the exception, including interim milestones and a reasonable completion
date; and (3) obtain written approval of these steps by the senior
manager responsible for leading and managing compliance with the CIP
Reliability Standards. As discussed previously, the Commission proposes
that a responsible entity invoking a

technical feasibility exception must have a review by senior management
of the expediency and effectiveness of the manner in which a
responsible entity has addressed each of these three proposed
conditions. In addition, the Commission proposes to require a
responsible entity to report and justify to the ERO and the Regional
Entity for approval each exception and its expected duration.
    191. Consistent with our earlier discussion, we will not propose
the removal of the ``technical feasibility'' language from Requirement
R2.4 of CIP-005-1. However, such discretion will not lie solely with
the responsible entities. We propose to direct that Regional Entities
review the application of ``technical feasibility'' as the basis for
allowing a responsible entity an exception to full compliance with a
Requirement.
c. Monitoring Access Logs
    192. Requirement R3. of CIP-005-1 requires responsible entities to
implement electronic or manual processes for monitoring and logging
access at access points to the electronic security perimeter at all
times. Further, where technically feasible, the security monitoring
process must detect and alert for attempts at or actual unauthorized
access. Where such alerts are not technically feasible, Requirement
R3.2 requires a responsible entity to review access logs at least every
90 calendar days.
    193. The CIP Assessment noted that frequent reviews of access logs
are necessary to look for security breaches that automated alerts do
not detect. It cautioned that the ``technical feasibility'' caveat in
Requirement R3.2 can allow a 90-day lapse in review of access logs when
it is commonplace in the IT industry for logs to be reviewed every one
or two days. The CIP Assessment also advised that the use of discretion
to address ``technical feasibility'' permitted in Requirement R3.2
should not be a basis for failing to implement a process that detects
attempts to access or actual unauthorized access. Such monitoring
technology is available \88\ and no responsible entity should be
excepted due to technical infeasibility.
---------------------------------------------------------------------------

    \88\ Technology that is currently available for monitoring
access (e.g., network servers, firewalls, Intrusion Detection
Systems, Intrusion Prevention Systems) has alarm capability built
into it.
---------------------------------------------------------------------------

    194. NERC agrees with the CIP Assessment that logs should be
reviewed frequently. However, NERC believes that a strict requirement
for the review period cannot be specified because of the varied methods
and technologies used to gather and review the logs. NERC asserts that
automated alert technology can detect many attempts and breaches, and
leave a much smaller set of ``questionable'' events which can readily
be analyzed manually.\89\
---------------------------------------------------------------------------

    \89\ FirstEnergy, ReliabilityFirst, ISO/RTO Council, Georgia
System, Xcel, and Santa Clara agree with NERC.
---------------------------------------------------------------------------

Commission Proposal
    195. The Commission is persuaded by the commenters that varied
technologies and locations make setting a ``one size fits all''
frequency of access log review requirement difficult. However, the
Commission believes that, while automated review systems provide a
reasonable day-to-day check of the system and a convenient screening
for obvious system breaches, periodic manual review provides the
opportunity to recognize an unanticipated form of malicious activity
and improve automated detection settings. Thus, regular manual review
is beneficial.
    196. The Commission believes that frequent reviews of access logs
are necessary to detect breaches that automated alerts do not detect.
Moreover, where automated alerts are not used, frequent monitoring
takes on even greater importance. The Commission recognizes that
accessibility of an access log may affect the review interval. For
instance, logs that are readily available, such as those from within a
control room setting, should be reviewed at least weekly. Those logs
that are not readily available, such as those located at a remote
substation, are less accessible and therefore can be read less
frequently. However, any attempt to differentiate the required
frequency of review of these logs must be balanced against the
criticality of the facilities. It is not acceptable to dismiss a
critical facility from timely review simply because it is remote.
    197. For the reasons discussed above, the Commission believes that
more frequent review of access logs is important and therefore proposes
to direct the ERO to develop a bifurcated review requirement of access
logs at electronic access points in which readily available logs are
reviewed more frequently than every 90 days. The Commission believes
such review should be performed at least weekly. As part of developing
this bifurcated review requirement, the ERO must include in the
Reliability Standard guidance on how a responsible entity should
designate individual assets as ``readily accessible'' or ``not readily
accessible,'' consistent with our discussion above.
d. Vulnerability Assessments
    198. The CIP Assessment stated that Requirement R4 fails to specify
whether a live vulnerability assessment is required, as opposed to a
paper assessment.\90\ It recommends performing a ``live'' cyber
vulnerability assessment at least annually and developing an action
plan to remediate any weaknesses identified. It also notes that
permitting a one year window, without any specificity regarding
updates, could be inadequate.
---------------------------------------------------------------------------

    \90\ A live vulnerability assessment typically involves the use
of specialized software or hardware to scan electronic access points
to determine which communications each access point allows to pass
through.
---------------------------------------------------------------------------

    199. NERC, Progress Energy and ReliabilityFirst state that
Requirement R4 intentionally allows for either vulnerability assessment
approach, live or paper-based, to allow a responsible entity to
determine the approach best suited to its own level of sophistication
and tolerance for risk. NERC acknowledges that some responsible
entities already perform live testing but notes that such testing is
limited to specific systems and circumstances of the responsible
entity.
    200. Georgia System argues that the existing Requirement R4 is
well-designed. It suggests, however, that annual testing of each
electronic access point should not be imposed, because such wide-spread
``live'' testing could have adverse impacts on system reliability.
APPA/LPPC disagree with the CIP Assessment and insist that an annual
testing requirement is sufficient, as long as the responsible entity
does not make changes to any border devices. APPA/LPPC argue that, if
changes occur to the perimeter, then the entity should, as a good
business practice, reassess the vulnerability of that portion of the
perimeter.
Commission Proposal
    201. The Commission believes that annual vulnerability assessments
are sufficient, provided that no modifications are made to the
electronic security perimeter during the year. However, when the
electronic security perimeter, or another measure in a defense in depth
strategy, is modified, it is not acceptable to wait a year to test
modifications. Thus, the Commission proposes to direct the ERO to
revise the Reliability Standard to require a vulnerability assessment
of the electronic access points as part of, or contemporaneously with,
any

modifications to the electronic security perimeter or defense in depth
strategy.
    202. In addition, the Commission proposes that Requirement R4
should provide for the conduct of live vulnerability assessments at
least once every three years, with subsequent annual paper assessments
in the intervening years. If such live vulnerability assessments are
not ``technically feasible,'' consistent with the Commission's earlier
determination, a responsible entity may seek to be excused from full
compliance via an application to the Regional Entity fully documenting
the necessary interim actions, milestone schedule, and mitigation plan.
e. Commission Proposal Summary
    203. In summary, the Commission proposes to approve Reliability
Standard CIP-005-1 as mandatory and enforceable. In addition, the
Commission proposes to direct the ERO, pursuant to section 215(d)(5) of
the FPA and Sec.  39.5(f) of our regulations, to develop modifications
to CIP-005-1 through its Reliability Standards development process that
(1) require implementation of a defensive security approach, including
two or more defensive measures in a defense in depth posture; (2) add
guidance to Requirement R2 by identifying examples of specific
verification technologies that would satisfy compliance with the
``strong controls'' in Requirement R2.4, such as digital certificates
and two-factor authentication, while also allowing compliance by means
of technically equivalent measures; (3) evaluates and provides guidance
regarding the use of access security measures ``in front of'' as
opposed to ``inside of'' older systems; (4) require additional controls
and accountability when a responsible entity invokes the ``technical
feasibility'' exception in Requirement R2.4 consistent with the
proposal discussion in section II.A.5.b of the NOPR; (5) provide a
bifurcated review requirement of access logs at electronic access
points in which readily available logs are reviewed more frequently
than 90 days including guidance on which assets should be designated
``readily accessible;'' (6) require a vulnerability assessment of
electronic access points as part of, or contemporaneously with, any
modifications to an electronic security perimeter or defense in depth
strategy; and (7) provide for the conduct of live vulnerability
assessments at least once every three years, with subsequent annual
paper assessments in the intervening years.
5. CIP-006-1--Physical Security of Critical Cyber Assets
    204. Reliability Standard CIP-006-1 addresses the physical security
of the critical cyber assets identified in Reliability Standard CIP-
002-1. In particular, CIP-006-1 requires a responsible entity to create
and maintain a physical security plan that ensures that all cyber
assets within an electronic security perimeter also reside within an
identified physical security perimeter.\91\ The physical security plan
must be approved by senior management and must contain processes for
identifying, controlling, and monitoring all access points and
authorization requests.
---------------------------------------------------------------------------

    \91\ As defined in the NERC Glossary, an ``Electronic Security
Perimeter'' means, ``[t]he logical border surrounding a network to
which Critical Cyber Assets are connected and for which access is
controlled. * * * and a Physical Security Perimeter is ``the
physical, completely enclosed (``six-wall'') border surrounding
computer rooms, telecommunications rooms, operations centers, and
other locations in which Critical Cyber Assets means are housed and
for which access is controlled * * *.''
---------------------------------------------------------------------------

    205. Reliability Standard CIP-006-1 also addresses operational and
procedural controls to manage physical access at all access points to
the physical security perimeter at all times by the use of alarm
systems and/or human observation or video monitoring. The Reliability
Standard also requires that the logging of physical access must occur
at all times, and the information logged must be sufficient to uniquely
identify individuals crossing the perimeter. Finally, the Reliability
Standard requires responsible entities to test and maintain all
physical security mechanisms on a three-year cycle.
    206. The Commission proposes to approve Reliability Standard CIP-
006-1 as mandatory and enforceable. In addition, we propose to direct
the ERO to develop modifications to this Reliability Standard. Further,
the Commission also proposes to require the ERO to consider various
other matters of clarification, guidance, and modification. In our
discussion below, we address our concerns in the following topic areas
regarding CIP-006-1: (1) Physical security plan; (2) physical access
controls and monitoring physical access controls; (3) physical security
breach; and (4) maintenance and testing.
a. Physical Security Plan
    207. Requirement R1.1 of CIP-006-1 addresses processes that a
responsible entity must include in its physical security plan to ensure
that all cyber assets within an electronic security perimeter also
reside within an identified physical security perimeter. The CIP
Assessment noted that Requirement R1.1 anticipates that there may be
instances where a completely enclosed border cannot be established and
that, in such instances, the responsible entity shall deploy and
document ``alternative measures'' to control physical access to the
critical cyber assets. It cautioned, however, that Requirement R1.1
does not provide guidance on how an alternative measure should be
identified or determined to be adequate.
    208. SPP recognizes the CIP Assessment concern with Requirement
R1.1, but disagrees that the language of the Requirement needs
revision. SPP maintains that while the Reliability Standard prescribes
what must be done, it does not and should not prescribe how a
particular Requirement is to be implemented. SPP states that NERC's FAQ
document offers suggestions on how to physically secure critical cyber
assets when they cannot be enclosed within a restricted access six-wall
boundary. Progress Energy agrees with the CIP Assessment that NERC
should provide guidance on how an alternative measure would be
identified or determined adequate. However, Progress Energy contends
that this guidance should not be in the Reliability Standard itself,
but rather in an interpretive document like a FAQ document.
Commission Proposal
    209. The Commission's current view is that the phrase ``alternative
measures'' as referenced in Requirement R1.1 should be interpreted to
be a Requirement exception.\92\ Under this Requirement, the responsible
entity is required to deploy and document alternative measures if a
completely enclosed ``six-wall'' border cannot be established to
control physical access to the critical cyber assets. However, the
Requirements do not provide guidance on how an alternative measure
should be identified or determined to be adequate. Therefore, the
Commission proposes to direct the ERO to treat the allowance of
``alternative measures'' as ``interim actions'' developed and
implemented as part of a mitigation plan under a ``technical
feasibility'' exception.
---------------------------------------------------------------------------

    \92\ The Commission's discussion elsewhere in this NOPR,
relating to discretion to make exceptions to a Requirement based on
technical feasibility applies here.

---------------------------------------------------------------------------

b. Physical Access Controls and Monitoring Physical Access Controls
    210. The CIP Assessment noted that Requirement R2 of the
Reliability Standard requires the use of at least one of four listed
physical access control methods, but does not require or suggest that
the method(s) employed to control physical access consider the
characteristics of the access point at issue and the criticality of the
asset being protected.\93\ Requirement R3 requires monitoring at each
access point to the physical security perimeter, including alarm
systems and/or human monitoring. For both Requirement R2 and
Requirement R3, a responsible entity can choose whether to implement
single or multiple access control methods and monitoring devices. The
CIP Assessment suggested that, consistent with a defense in depth
strategy, a layered approach would increase the complexity of an
intrusion by requiring that multiple security provisions be
circumvented. The CIP Assessment further suggested that such an
approach would provide redundancy in case one system requires
maintenance or unexpectedly fails to function as expected.
---------------------------------------------------------------------------

    \93\ CIP Assessment at 29.
---------------------------------------------------------------------------

    211. Xcel, FirstEnergy and others agree that redundancy and the
number of layers should be a function of a reasonable risk assessment
and good utility practice, which provide an objective basis for
measuring compliance. They also state that unnecessary redundancy would
take funds and resources away from the assets that need the elaborate
redundancy.
    212. Xcel agrees with the CIP Assessment that defense in depth is
an optimal strategy, but states that it is not always practical. For
example, Xcel notes that where a substation has cyber security
equipment inside a control building surrounded by a fence, it may not
be worth the cost or administrative burden to install fence detection
equipment at a remote substation.
    213. FirstEnergy agrees with the CIP Assessment that Requirement R2
should include a process for identifying the criticality of critical
cyber assets and a process for applying an appropriate number of layers
based on criticality. NERC and ReliabilityFirst point out that,
throughout the Reliability Standards, assets are classified as either
critical or non-critical, with no subjectivity involved in determining
their ``level'' of criticality. They suggest that all assets classified
as critical must be afforded the same level of protection, regardless
of their location or perceived level of criticality. Consequently, they
believe the specific implementation of protection must be functionally
equivalent and sufficient at all locations.
Commission Proposal
    214. We do not believe that the proposal to require a minimum of
two different security procedures creates an unreasonable burden. We
believe that a responsible entity must, at a minimum, implement two or
more different security procedures when establishing a physical
security perimeter. Use of a minimum of two different security
procedures will, for example, enable continuous security protection
when one of the security protection measures is undergoing maintenance
and provides redundant security protection in the event that one of the
measures is breached. Therefore, while the Commission recognizes that
there is a point at which implementing multiple layers of defense
becomes an unreasonable burden to responsible entities, the Commission
proposes to direct the ERO to modify this Reliability Standard to state
that a responsible entity must, at a minimum, implement two or more
different security procedures when establishing a physical security
perimeter around critical cyber assets.
c. Physical Security Breach
    215. The CIP Assessment noted that Reliability Standard CIP-006-1
does not include actions to be taken in response to a physical security
breach. Thus, the CIP Assessment suggested that the physical security
plan specify responsibilities and required communication in such an
event.
    216. California PUC states that CIP-006-1 is sound, except that it
does not require a plan in the contingency of a physical security
breach. California PUC suggests that a guideline for such a plan should
be incorporated into this Reliability Standard.
Commission Proposal
    217. Below, the Commission proposes, in CIP-008-1, to direct the
ERO to develop and include (in CIP-008-1) language regarding what
should be included in the term ``reportable incident.'' The Commission
proposes to direct the ERO, when it develops its language in
Reliability Standard CIP-008-1 on the term ``reportable incident,'' to
include a breach that may occur through cyber or physical means. Thus,
the Commission expects that the issue of a physical security breach
will be fully addressed through that proposed modification and no
revision of CIP-006-1 is needed to address this issue.
d. Maintenance and Testing
    218. Requirement R6, which requires a maintenance and testing
program, to ensure that all physical security systems under
Requirements R2, R3, and R4 function properly, is critical for the
overall success of CIP-006-1. The CIP Assessment explained that, if the
system's outer physical security perimeter fails to secure critical
assets, the electronic access controls may be rendered ineffective. The
CIP Assessment questioned whether consideration should be given to
testing the more important physical security mechanisms and systems
more frequently, with testing and maintenance records maintained for
the full three-year testing cycle.
    219. NERC and ReliabilityFirst reiterate that the Reliability
Standards do not make a distinction between levels of criticality.
These commenters assert that testing of more important systems cannot
be performed, because all critical assets have the same level of
criticality. Xcel states that a more frequent testing of the physical
security perimeter is not needed because most of the equipment will be
used on a weekly basis. Xcel maintains that since the equipment will be
in regular use, a Requirement for additional testing of the equipment
appears redundant.
    220. SPP agrees with the CIP Assessment, stating that a three-year
inspection cycle of physical access control is too infrequent if a
critical asset has high potential impact on reliability and where such
testing is not inconvenient. SPP argues that, while it may be
appropriate to test the physical access controls at a remote substation
once every three years, the physical access controls at a generating
plant and a control center can and should be tested far more
frequently. FirstEnergy also agrees with the CIP Assessment, stating
that more frequent testing should be required for critical facilities,
but that the Requirement should specify the form of testing that will
be considered adequate.
Commission Proposal
    221. Currently, Requirement R6 of CIP-006-1 requires that
responsible entities implement maintenance and testing programs of
physical security systems on a cycle no longer than three years and
retain testing and maintenance records for the same cycle. In addition,
Requirement R6 requires retention of outage records of certain physical
security systems for a

minimum of one year. The Commission agrees with SPP that maintenance
and testing of physical security systems should occur more frequently
than once every three years. However, the Commission also agrees with
SPP that such testing at remote substations should be allowed less
frequently. Therefore, the Commission proposes to direct the ERO to
modify this Reliability Standard to require that: (1) A readily
accessible critical cyber asset be tested every year with a one-year
record requirement for the retention of testing, maintenance, and
outage records; and (2) a non-readily accessible critical cyber asset
be tested in a three-year cycle with a three-year record retention
requirement. The Commission believes that this approach provides an
appropriate assurance that security measures for geographically
dispersed physical assets are functioning properly.
e. Commission Proposal Summary
    222. In summary, the Commission proposes to approve Reliability
Standard CIP-006-1 as mandatory and enforceable. In addition, the
Commission proposes to direct the ERO, pursuant to section 215(d)(5) of
the FPA and Sec.  39.5(f) of our regulations, to develop modifications
to CIP-006-1 through its Reliability Standards development process that
require that: (1) The ERO treats the allowance of ``alternative
measures'' referenced in Requirement R1.1 as ``interim actions''
developed and implemented as part of a mitigation plan under a
``technical feasibility'' exception; (2) a responsible entity must, at
a minimum, implement two or more different security procedures when
establishing a physical security perimeter around critical cyber
assets; (3) the ERO, when it develops its language in Reliability
Standard CIP-008-1 on the term ``reportable incident,'' include a
breach that may occur through cyber or physical means; (4) a readily
accessible critical cyber asset be tested every year with a one-year
requirement for the retention of testing, maintenance, and outage
records; and (5) a non-readily accessible critical cyber asset be
tested in a three-year cycle with a three-year record retention
requirement.
6. CIP-007-1--Systems Security Management
    223. The Purpose statement in Reliability Standard CIP-007-1 states
that it requires responsible entities to define methods, processes and
procedures for securing those systems determined to be critical cyber
assets, as well as the non-critical cyber assets within the electronic
security perimeter(s).
    224. The CIP Assessment explained that this Reliability Standard
deals primarily with changes made to the operating control system \94\
and verification that such changes will not inadvertently have adverse
effects.\95\ The CIP Assessment noted that the operating control system
is vulnerable during the testing process for an indeterminate period of
time prior to the installation of a patch, and an attacker could
exploit the vulnerability. It explained that contracts with vendors
present another security challenge. Service contracts typically provide
that the vendor will test patches before allowing an entity to install
them on its operating control system. The contracts also typically
prohibit installation before the vendor verifies the patch, at risk of
voiding the warranty. It explained that the time involved in the
testing and installation of a patch may provide an attacker a window of
opportunity to exploit the vulnerability that the patch is designed to
prevent.
---------------------------------------------------------------------------

    \94\ The term ``operating control system'' is used in this NOPR
to represent the control system used to control critical assets in
real time, as opposed to backup, training, or duplicate control
systems.
    \95\ CIP Assessment at 31.
---------------------------------------------------------------------------

    225. Another challenge the CIP Assessment identified is ensuring
that the test environment accurately approximates and mirrors the
operating control system. It noted that an inaccurate test environment
can allow potential failures of the new product to go undetected. It
noted that some entities may not have the resources to maintain a
backup system, let alone a duplicate of their operating control system.
    226. The Commission proposes to approve Reliability Standard CIP-
007-1 as mandatory and enforceable. In addition, we propose to direct
the ERO to develop modifications to this Reliability Standard. In our
discussion below, the Commission addresses its concerns in the
following topic areas regarding CIP-007-1: (1) Test procedures; (2)
ports and services; (3) security patch management; (4) malicious
software prevention; (5) security status Monitoring; (6) disposal or
redeployment; (7) cyber vulnerability assessment; and (8) documentation
review and maintenance.
a. Test Procedures
    227. Requirement R1 of CIP-007-1 requires a responsible entity to
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. Responsible entities must create,
implement, and maintain cyber security test procedures in a manner that
minimizes adverse effects on the production system or its operation.
They must document that testing is performed in a manner that reflects
the production environment and must document test results.
    228. The CIP Assessment suggested that Requirement R1.2 should
require the responsible entity to document how each significant
difference between the operation and testing environments is considered
and addressed.\96\
---------------------------------------------------------------------------

    \96\ CIP Assessment at 32.
---------------------------------------------------------------------------

    229. NERC and ReliabilityFirst comment that any test environment
that has a ``significant difference'' from the production environment
is not a true ``reflection'' of the production requirement, as required
by the Reliability Standard. National Grid states that the need for and
amount of testing will depend on the nature of the change that needs to
be implemented. Flexibility to assess each situation is necessary to
determine the type of testing required. National Grid states that it
may not be possible to establish an isolated testing environment for
all security upgrades because cyber assets in production operate
continuously. A responsible entity therefore may need to take
substantial steps to configure a test environment, such as taking an
entire substation out of service.
Commission Proposal
    230. If a testing environment does not accurately reflect the
operational environment, testing of systems may not be adequate to
judge impacts on reliability. While, ideally, testing should be
conducted on a precise duplicate of the production system, the
Commission acknowledges that this is not always possible. When it is
not, any differences between the test environment and the production
system should be documented. In addition, the Commission believes that
responsible entities should address to the satisfaction of senior
management these differences and how they propose to mitigate the
impact of any differences between the testing environment and the
production system. Therefore, the Commission proposes to direct the ERO
to modify Requirement R1 and its subparts to require documentation of
each significant difference between the testing and the production
environments, and how each such difference is mitigated or otherwise
addressed.

b. Ports and Services
    231. Requirement R2 of CIP-007-1 requires a responsible entity to
establish a process to ensure that only those ports and services
required for normal and emergency operations are enabled and all others
are disabled.
    232. The CIP Assessment stressed that the requirement to ``disable
other ports and services'' is a basic building block of a cyber
security program, and that it is a generally recognized security
practice to assume a ``deny all'' stance (i.e., disabling all ports and
services first) before opening the various ports that are needed only
for operations. The CIP Assessment expressed concern that Requirement
R2.3 allows a responsible entity to ``accept risk'' rather than take
mitigating action where unused ports and services cannot be disabled
due to ``technical limitations.'' This Requirement specifies that the
responsible entity must either document (1) compensating measures to
mitigate exposure or (2) an ``acceptance of risk.'' The CIP Assessment
noted that in situations where technical limitations prevent unused
ports and services from being disabled and risk can at best be
mitigated, acceptance of risk appears to mean acceptance of
vulnerabilities without further action. The CIP Assessment suggested
that clear guidance is needed to explain limited circumstances for its
use, and warned that accepting risk could potentially become an
exception from compliance that permits unacceptable risks.
    233. NERC and ReliabilityFirst comment that many situations exist
where ports and services must be left open due to operating system
requirements, the requirements of equipment manufacturers or vendors or
the lack of information from vendors that is necessary to determine if
a port or service can be disabled. APPA/LPPC agree with the CIP
Assessment that closing unused ports is generally a good business
practice, but they disagree that it should be mandated. They state that
in some cases there may be sound technical reasons why an unused port
cannot be closed. They further comment that this Requirement is
acceptable as written because it allows the responsible entity to use
reasonable business judgment.
Commission Proposal
    234. In section II.A.5.b above, the Commission discusses the
problems presented by acceptance of risk. For the reasons discussed
there, the Commission proposes to direct the ERO to eliminate the
acceptance of risk language from Requirement R2.3. At the same time,
the Commission proposes to leave intact the exception for ``technical
limitations.'' However, the Commission believes that the ``technical
limitations'' language of Requirement R2.3 raises the same concerns
here as the ``technical feasibility'' language referenced in section
II.A.5.b. While an exception for ``technical limitations'' may be
appropriate, it must include the same conditions as discussed in the
context of ``technical feasibility.'' Accordingly, we propose that the
same conditions and reporting requirements should apply here. Thus, the
Commission proposes to direct the ERO to revise Requirement R2 and its
subparts to reflect our determinations discussed above to remove the
``acceptance of risk'' language and to impose the same conditions and
reporting requirements here for ``technical limitations'' as imposed
elsewhere in this NOPR regarding ``technical feasibility.''
c. Security Patch Management
    235. Requirement R3 of CIP-007-1 requires a responsible entity to
establish and document a security patch management program for
tracking, evaluating, testing and installing applicable cyber security
software patches for all cyber assets within an electronic security
perimeter. Among other things, a responsible entity must document the
implementation of security patches. Where a patch is not installed, the
responsible entity must document compensating measure(s) applied to
mitigate risk exposure or an acceptance of risk.
    236. The CIP Assessment acknowledged that compensating measures are
necessary at times, especially when patches require vendor support, but
also expressed concern that Requirement R3.2 permits a wide variation
of processes for patching a system when it allows an ``acceptance of
risk'' in lieu of mitigating risk exposure through a patching program.
The CIP Assessment asserted that an effective Reliability Standard
cannot simply offer a responsible entity a choice between installing a
patch or accepting the risk of not doing so, and that at least some
form of mitigation should always be possible.
    237. NERC and ReliabilityFirst believe that ``acceptance of risk''
is not a permanent solution but would be used during a period where
testing and other required upgrades may be accomplished. In addition,
they and other commenters are concerned about implementing language in
the Reliability Standard that would seem to require installation of
patches on platforms where patches cannot be implemented due to
architecture, operating environment or warranty issues. Allegheny
states that if patches were not applied, it is highly unlikely there
would not be some form of mitigation available such as physical
protection and/or firewalls. It also states that compensating measures
should be in place before there is an acceptance of risk. SoCal Edison
states that acceptance of the risk of non-compliance should be clearly
documented so that an auditor can see the rationale for this decision.
    238. PG&E comments that older devices have a limited modification
capability, and as a result the responsible entity must balance the
risk of replacing devices that currently operate with new, untested,
and potentially inadequate devices.
Commission Proposal
    239. The Commission has discussed acceptance of risk above and,
because those remarks and proposals apply equally here, we propose that
the ``acceptance of risk'' language must be removed here also.\97\ With
the exception of references to acceptance of risk, the Commission
considers the provisions of Requirement R3 to be acceptable and
appropriate. Patch management must be weighed in light of the risks
involved, with senior management involved in the decision. As discussed
under Recommendation 33 of the Blackout Report,\98\ using the most up-
to-date patches that deal specifically with security vulnerabilities is
of the utmost importance, provided it does not degrade the system and
the patch does not create more vulnerability than the problem it is
intended to fix.
---------------------------------------------------------------------------

    \97\ See supra discussion in section II.A.5.b.
    \98\ See Blackout Report at 164, Recommendation 33.
---------------------------------------------------------------------------

d. Malicious Software Prevention
    240. Requirement R4 of CIP-007-1 requires responsible entities to
use anti-virus and other malicious software prevention tools. The CIP
Assessment noted that Reliability Standard CIP-007-1 does not provide
any direction on how to implement this type of protection or where it
should be deployed, and that care must be taken to implement and test
malicious code protection in order to avoid harm to the operating
control system. The CIP Assessment pointed out that the Reliability
Standard could suggest the use of a multi-layer, defense in depth
strategy, to forestall or detect an attacker's penetration of the
electronic security.\99\
---------------------------------------------------------------------------

    \99\ CIP Assessment at 33.

---------------------------------------------------------------------------

    241. Requirement R4 requires the responsible entity to use anti-
virus software and malicious software prevention tools where
``technically feasible.'' The CIP Assessment questioned this phrase as
allowing unnecessary discretion to opt out of Requirement R4. It noted
that Requirement R4.1 raises the same concerns regarding the phrase
``acceptance of risk'' as in Requirement R3.2, this time in connection
with cases where anti-virus software and malicious software prevention
tools are not installed. The CIP Assessment noted a lack of direction
in the Reliability Standard and sought comment on what types of
compensating measures are available and what would be an adequate
justification for accepting risk.
    242. In response to the CIP Assessment observation that Requirement
R4 does not provide any direction on how to implement anti-virus
protection or where it should be deployed, NERC and ReliabilityFirst
comment that the Reliability Standards are performance based; that they
do not specify how to perform a function, only that the Requirement
must be met. This comment is similar to the suggestion addressed in
Order No. 672,\100\ that, ``in general, a Reliability Standard should
address the `what' and not the `how' of reliability and that the actual
implementation of a Reliability Standard should be left to entities
such as control area operators and system planners * * *.'' \101\ NERC
and ReliabilityFirst conclude that, while the responsible entity must
implement a solution that meets the Requirement, it should not be
restricted with regard to how to do so. Thus, they argue the
Reliability Standard should remain silent as to whether the anti-virus
solution is implemented at the electronic security perimeter border, on
an in-line device, or on the critical cyber asset itself, so long as
the implemented solution meets the stated requirement.
---------------------------------------------------------------------------

    \100\ FERC Stats. & Regs. ] 31,204 at P 260.
    \101\ In Order No. 672, the Commission immediately followed this
general statement with the caution that, ``in other situations,
however, the `how' may be inextricably linked to the Reliability
Standard and may need to be specified by the ERO to ensure the
enforcement of the Reliability Standard.'' Order No. 672 at P 265.
---------------------------------------------------------------------------

    243. In response to the CIP Assessment comment that the Reliability
Standard does not suggest the use of a multi-layered, defense in depth
strategy through the use of various products from multiple vendors,
NERC and ReliabilityFirst state that a multi-layered defense may be
appropriate in a best practice document, but not in a mandatory
Reliability Standard.
Commission Proposal
    244. The Commission has discussed the issues of defense in depth,
technical feasibility, and risk acceptance elsewhere above in this
NOPR. The remarks and proposals there apply equally to the issue of
malicious software prevention. Therefore, the ``acceptance of risk''
language must be removed here, and the same conditions and reporting
requirements regarding ``technical feasibility'' that apply elsewhere
are applicable here. In addition, the Commission proposes to direct the
ERO to modify Requirement R4 to include safeguards against personnel
introducing, either maliciously or unintentionally, viruses or
malicious software in to a cyber asset within the electronic security
perimeter through remote access, electronic media, or other means.
e. Security Status Monitoring
    245. Requirement R6 of CIP-007-1 requires responsible entities to
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. Among other things, a responsible entity must maintain logs
of system events related to cyber security, where technically feasible,
to support incident response as required in Reliability Standard CIP-
008-1. Logs must be retained for 90 calendar days, and the responsible
entity must review logs of system events related to cyber security and
maintain records documenting review of logs.
    246. The CIP Assessment questioned the need to limit Requirement
R6.3, which requires logs of system events related to cyber security to
support incident reporting, as specified in CIP-008-1, to situations
where this is ``technically feasible.'' The CIP Assessment also raised
concerns about the record retention requirements for Requirements R6.3
and R6.4, which pertain to logs of cyber security-related system events
used to identify reportable incidents and to support incident response,
as required in CIP-008-1. It noted that, depending upon the frequency
of log review, the 90-day period specified may be inadequate and that
frequent review of logs would facilitate the early detection of
reportable incidents. It also would ensure that current data are
available for forensics. The CIP Assessment sought comment on whether
the Reliability Standard should address the frequency and scope of the
review of system event logs related to cyber security that is required
by Requirement R6.5. It also noted the lack of guidance on how data
should be saved, backed up and stored where computerized cyber incident
monitoring and logging is performed.
    247. Several commenters state that all devices of interest do not
have the capability to create logs or that they may not provide the
capability to capture ``security related'' information. They state that
many installed devices in power plants and substations do not have log
generation capability. If there is no capacity to generate logs, then
it is technically infeasible to maintain logs.
    248. NERC and ReliabilityFirst comment that generated logs from
remote locations may not be readily collected for frequent review. In
many cases, the telecommunications infrastructure connecting these
remote locations cannot support the rapid and frequent collection of
log data, especially if it is voluminous. The remote location of some
sites makes frequent visits to collect and store log data impractical.
    249. SPP recommends that logs be transferred in real time to a
separate logging system to mitigate the risk of a successful attack
destroying evidence of the intrusion. Where possible, the log should be
readable separately from the device that created it or the device
should be able to continue logging while in playback mode. Wisconsin
Electric submits that cyber security logs should be reviewed with the
frequency necessary to identify a cyber security incident within the
timeframe established in the entity's cyber security incident response
plan. The cyber security logs should be stored in a manner that assures
that information is protected as required in CIP-003-1 and that it is
available through the 90-day retention period.
Commission Proposal
    250. We have discussed the issue of technical feasibility. Our
remarks and proposals there apply equally to the technical feasibility
of monitoring and logging of system events related to cyber security.
    251. The Commission agrees with the CIP Assessment and Wisconsin
Electric that logs should be reviewed with the frequency necessary to
ensure timely identification of a cyber security incident. Simply
reviewing logs at the end of the retention period will not ensure an
appropriate level of security because it does not permit effective
response to all incidents. We note that

this issue of log review touches on Blackout Report Recommendation 35,
which addresses network monitoring, and Recommendation 37 which
addresses diagnostic capabilities.\102\ The Commission therefore
proposes to direct the ERO to revise Requirement R6 to include a
requirement that logs be reviewed on a weekly basis for readily
accessible critical assets and reviewed within the retention period for
assets that are not readily accessible. This direction should be
completed consistent with our discussion above regarding ``readily
accessible'' assets.\103\ Accessibility should take into account both
physical remoteness and available communications channels. We would
expect control centers to fall within the ``readily accessible''
category.
---------------------------------------------------------------------------

    \102\ See Blackout Report at 165-166, Recommendations 35 and 37.
    \103\ See section II.B.4.c (Monitoring Access Logs) in this
NOPR.
---------------------------------------------------------------------------

    252. The Commission also proposes to direct the ERO to revise
Requirement R6.4 to clarify that while the retention period for all
logs specified in Requirement R6 is 90 days, the retention period for
logs mentioned in Requirement R6.3 for the support of incident response
as required in CIP-008-1 is the retention period required by CIP-008-1,
i.e., three years. Requirement R6.4 is somewhat unclear and could be
read to suggest that the 90 day period also applies to logs kept for
purposes of CIP-008-1, and such an interpretation would conflict with
the Requirements of that Reliability Standard.
f. Disposal or Redeployment
    253. Requirement R7 of CIP-007-1 requires the responsible entity to
establish formal methods, processes and procedures for disposal or
redeployment of cyber assets. The CIP Assessment noted that erasing
alone may not be adequate because technology exists that allows
retrieval of ``erased'' data from storage devices, and that effective
protection requires discarded or redeployed assets to undergo high
quality degaussing.\104\
---------------------------------------------------------------------------

    \104\ CIP Assessment at 34-35. To degauss is to demagnetize.
Degaussing a magnetic storage medium removes all data stored on it.
---------------------------------------------------------------------------

    254. Allegheny and SPP agree with the CIP Assessment that erasing
alone may be inadequate because technology currently exists that allows
retrieval of ``erased'' data from storage devices. SPP also states that
if the magnetic media is being disposed of, physical destruction of the
media is also an appropriate technique to render it unreadable.
    255. NERC and ReliabilityFirst state that any method that fails to
``prevent unauthorized retrieval of sensitive cyber security or
reliability data'' does not satisfy the Requirement. Likewise, APPA/
LPPC believe that it is clear from the Requirement that ``erase'' means
that there is no opportunity for unauthorized retrieval of data from a
cyber asset prior to discarding it or redeploying it. They caution
against being overly prescriptive regarding the exact process that
responsible entities must use to meet this Requirement.
Commission Proposal
    256. The Commission agrees with commenters that degaussing is not
the sole means for achieving the goal of the requirement. As noted by
commenters, the issue is less one of erasure, which is as much a method
as it is a goal, than of assuring that there is no opportunity for
unauthorized retrieval of data from a cyber asset prior to discarding
it or redeploying it. The Commission therefore proposes to direct the
ERO to modify this Requirement to clarify this point.
g. Cyber Vulnerability Assessment
    257. Requirement R8 of CIP-007-1 requires a responsible entity to
perform a cyber vulnerability assessment of all cyber assets within the
electronic security perimeter at least annually. The CIP Assessment
noted that this Requirement provides little direction on what features,
functionality, and vulnerabilities responsible entities should focus on
in a vulnerability assessment. The CIP Assessment pointed out that a
poorly chosen vulnerability assessment process could result in a false
sense of security. The CIP Assessment also noted that while Requirement
R8.4 requires development of an action plan to remediate or mitigate
vulnerabilities identified in the assessment, it does not provide a
timeframe for completion of the action plan.\105\
---------------------------------------------------------------------------

    \105\ CIP Assessment at 35.
---------------------------------------------------------------------------

    258. Several commenters state that a responsible entity must
determine the approach it will implement based on its own level of
sophistication and its internal tolerance for risk. These commenters
state that every environment and implementation is different, and any
additional specificity would be impossible to describe for all possible
situations, and, consequently, would not be productive. NERC and
ReliabilityFirst state that requiring a specific timeframe for
completion of an action regardless of its complexity serves no useful
purpose because the timeframe will depend on the actions required. They
maintain that the requirement to document the ``execution status'' of
the action plan serves to keep the action plan on track.
    259. ISA Group states that experience shows that most companies do
not know what devices have actually been installed in the field. It
maintains that a requirement for a detailed walk-down of all critical
cyber assets should be mandatory for an acceptable vulnerability
assessment. Progress and Xcel comment that the scope of the
vulnerability test should be clearly defined.
Commission Proposal
    260. The Commission believes that vulnerability testing is a
valuable tool in determining whether actions that were taken to shore
up the security posture of the electronic security perimeter and other
areas of responsibility are in fact adequate. The Blackout Report
recognized the importance of vulnerability assessments in
Recommendation 38 that called for vulnerability assessment activities
to identify weaknesses and mitigating actions.\106\ The Commission
believes, as noted by NERC and ReliabilityFirst, that execution status
is a good means to keep the action plan on track. Therefore, the
Commission proposes to require that the ERO provide more direction on
what features, functionality, and vulnerabilities the responsible
entities should address when conducting the vulnerability assessments,
and to revise Requirement R8.4 to require an entity-imposed timeline
for completion of the already-required action plan.
---------------------------------------------------------------------------

    \106\ See Blackout Report at 167, Recommendation 38.
---------------------------------------------------------------------------

h. Documentation Review and Maintenance
    261. Requirement R9 of CIP-007-1 requires the responsible entity to
review, update and maintain all documentation needed to support
compliance with the Requirements of CIP-007-1 at least annually.
Changes resulting from modifications to the systems or controls must be
documented within 90 calendar days of the change. The CIP Assessment
expressed the view that the 90-day timeframe for updating documentation
appears excessively long, especially when one considers that this
Reliability Standard establishes a line of defense for protecting
critical cyber assets and that up-to-date documentation is essential in
case of an emergency.
    262. NERC and ReliabilityFirst state that the 90-day time period is
appropriate, given the nature and type of facilities and their
locations,

particularly in light of the potential need for internal reviews and
approvals by a number of people or groups of people before a
documentation change can be effected. ReliabilityFirst adds that the
90-day period also takes into account possible management changes or
extended time out of the office.
Commission Proposal
    263. The Commission proposes to direct the ERO to modify
Requirement R9 to state that the changes resulting from modifications
to the system or controls shall be documented within a 30-day time
period. We believe that the planning and engineering of system and
control modifications require sufficient lead time to enable the
documentation of such modifications to take place within a 30 calendar
day timeframe.
i. Commission Proposal Summary
    264. In summary, the Commission proposes to approve Reliability
Standard CIP-007-1 as mandatory and enforceable. In addition, the
Commission proposes to direct the ERO, pursuant to section 215(d)(5) of
the FPA and Sec.  39.5(f) of our regulations to develop modifications
to CIP-007-1 through its Reliability Standards development process
that: (1) Modify Requirement R1 and its subparts to require
documentation of each significant difference between the testing and
the production environments, and how each such difference is mitigated
or otherwise addressed; (2) revise Requirement R2 and its subparts to
remove the ``acceptance of risk'' language and apply the same
conditions and reporting requirements here for ``technical
limitations'' as imposed elsewhere in this NOPR for ``technical
feasibility;'' (3) remove the ``acceptance of risk'' provision from
Requirement R3 and R4; (4) modify Requirement R4 to include safeguards
against personnel introducing, either maliciously or unintentionally,
viruses or malicious software to a cyber asset within the electronic
security perimeter through remote access, electronic media, or other
means; (5) ensure that references to ``technical feasibility'' in CIP-
007-1 are subject to the same conditions and reporting requirements
discussed elsewhere; (6) revise Requirement R6 to include a requirement
that logs be reviewed on a weekly basis for readily accessible critical
assets and reviewed within the retention period for assets that are not
readily accessible; (7) revise Requirement R6.4 to clarify that while
the retention period for all logs specified in Requirement R6 is 90
days, the retention period for logs mentioned in Requirement R6.3 for
the support of incident response as required in CIP-008-1 is the
retention period required by CIP-008-1, i.e., three years; (8) revise
Requirement R7 of the Reliability Standard to clarify that the issue is
less one of erasure than of assuring that there is no opportunity for
unauthorized retrieval of data from a cyber asset prior to discarding
it or redeploying; (9) provide more direction on what features,
functionality, and vulnerabilities the responsible entities should
address when conducting the vulnerability assessments; (10) revise
Requirement R8.4 to require an entity-imposed timeline for completion
of the already-required action plan; and (11) revise Requirement R9 to
state that the changes resulting from modifications to the system or
controls shall be documented in within 30 days.
7. CIP-008-1--Incident Reporting and Response Planning
    265. Proposed Reliability Standard CIP-008-1 requires a responsible
entity to identify, classify, respond to, and report cyber security
incidents related to critical cyber assets. Specifically, Requirement
R1 of CIP-008-1 requires responsible entities to develop and maintain
an Incident Response Plan that addresses responses to a cyber security
incident. The plan should characterize and classify pertinent events as
reportable cyber security incidents and provide corresponding response
actions. The response actions should include: (1) The roles and
responsibilities of the incident response teams, (2) procedures for
handling incidents, and (3) associated communication plans. In
addition, cyber security incidents must be reported to the ESISAC
either directly or through an intermediary. The Incident Response Plan
should be reviewed and tested at least annually. Changes to the
Incident Response Plan are to be documented within 90 days. Responsible
entities must retain documentation related to reportable cyber security
incidents for a period of three years.
    266. The Commission proposes to approve Reliability Standard CIP-
008-1 as mandatory and enforceable. In addition, we propose to direct
the ERO to develop modifications to this Reliability Standard. In our
discussion below, the Commission addresses its concerns in the
following topic areas regarding CIP-008-1: (1) Definition of a
reportable incident; (2) reporting; and (3) full operational exercises
and lessons learned.
a. Definition of a Reportable Incident
    267. The CIP Assessment noted that Requirement R1 of CIP-008-1
makes reference to reportable cyber security incidents, but it does not
provide a definition of a ``reportable incident.'' Consequently, cyber
security incidents may go unreported depending upon a responsible
entity's interpretation of a ``reportable incident.'' \107\
---------------------------------------------------------------------------

    \107\ CIP Assessment at 36. The CIP Assessment recognized that
NERC's FAQ document answers the question of ``what is a reportable
incident?'' by referencing definitions in the ESISAC Indications,
Analysis, and Warnings Program guidelines document entitled
``Indications, Analysis and Warnings Program Standard Operating
Procedure'' and the Department of Energy Form OE 417 Report entitled
``Electric Emergency Incident and Disturbance Report.'' However,
since these materials are not incorporated into the proposed CIP
Reliability Standards, CIP-008-1 remains ambiguous in this regard.
North American Electric Reliability Council, Frequently Asked
Questions (FAQs) Cyber Security Standards CIP-002-1 through CIP-009-
1, March 6, 2006, page 27, question 1.
---------------------------------------------------------------------------

    268. NERC and ReliabilityFirst affirm the CIP Assessment concern,
stating that each responsible entity is required to develop the
required procedures for the determination of a reportable incident.
They add that the definition of a reportable incident is currently
undergoing extensive industry debate.
    269. A number of commenters state that FERC should require NERC to
clarify what types of cyber security incidents are ``reportable
incidents.'' National Grid points out that the Commission should seek
to ensure that any further interpretation of what is considered a
reportable incident be consistent with the reporting obligations of
utilities under the DOE Form 417. Allegheny suggests that, in order to
maintain consistency, the DOE Form 417 reporting requirements should be
referenced as part of the Reliability Standard. Progress Energy, on the
other hand, states that such increased specificity is not possible and
would be subject to constant revision in response to ever-changing
incidents or threats to cyber systems.
Commission Proposal
    270. The Commission believes that guidance regarding what should be
included in the term ``reportable incident'' can be provided. The
Blackout Report pointed out the need for ``uniform standards for the
reporting and sharing of physical and cyber security incident
information'' in Recommendation 42.\108\ As NERC and ReliabilityFirst
state, the definition of a ``reportable incident'' is currently
undergoing extensive industry debate.

This debate can be a catalyst for developing an appropriate level of
guidance. As noted in the NERC Glossary, a ``cyber security incident''
is defined as a compromise, or an attempt to compromise, the electronic
security perimeter or physical security perimeter of a critical asset.
The Commission proposes to direct the ERO to: (1) Develop and include
in CIP-008-1 language that takes into account a breach that may occur
through cyber or physical means; \109\ (2) harmonize, but not
necessarily limit, the meaning of the term reportable incident with
other reporting mechanisms, such as DOE Form 417; (3) recognize that
the term should not be triggered by ineffectual and untargeted attacks
that proliferate on the internet; and (4) ensure that the guidance
language that is developed results in a Reliability Standard that can
be audited and enforced.
---------------------------------------------------------------------------

    \108\ See also Blackout Report at 168, Recommendation 42.
    \109\ The Commission emphasizes that a cyber security incident
that does not result in a material loss of physical assets should
not prevent the incident from being reported.
---------------------------------------------------------------------------

b. Reporting
    271. CIP-008-1, Requirement R1.3, requires that each responsible
entity establish a process for reporting cyber security incidents to
the ESISAC. The responsible entity must ensure that all reportable
cyber security incidents are reported to the ESISAC either directly or
through an intermediary.
    272. ESISAC procedures require the reporting of a cyber incident
within one hour of a suspected malicious incident. However, compliance
with ESISAC's Indications, Analysis and Warnings Program (IAW) Standard
Operating Procedure (SOP) is voluntary. The CIP Assessment noted the
importance of other responsible entities receiving timely information
regarding a reportable cyber security incident, so they can take
precautions against being the target of a similar incident. The CIP
Assessment stated that, depending upon the nature of the incident,
timelines of incident reporting may be critical. It expressed concern
with regard to the voluntary nature of the one-hour reporting
requirement associated with ESISAC's IAW SOP. Therefore, the CIP
Assessment requested comment on whether CIP-008-1 should incorporate
ESISAC's one-hour reporting limit or another reporting interval that
would provide adequate time for another responsible entity to take
meaningful precautions.
    273. NERC and ReliabilityFirst agree that rapid reporting is
desirable. However, they state that imposing a specific time period is
not advisable because, when an event occurs, the need to meet a
reporting deadline should not be the entity's primary concern, rather
restoration of operations must take precedence. NERC and
ReliabilityFirst state that ESISAC's IAW SOP is intentionally not a
part of this Reliability Standard, and is classified as a guideline,
because it has not been through the ERO standards development process.
These commenters believe the requirement is to report incidents to the
ESISAC, with the implication that an established ESISAC reporting
protocol is to be used.
    274. APPA/LPPC do not believe that incorporating the ESISAC one-
hour reporting limit or any other deadline would provide adequate time
for another responsible entity to take meaningful precautions to
prevent a cyber attack. Cyber attacks are designed to occur nearly
simultaneously in more than one location. Thus, even an extremely short
deadline, such as one minute, is unlikely to provide other responsible
entities time to take precautions. Nonetheless, APPA/LPPC suggest that,
if a deadline is prescribed, it should run from the discovery of the
incident by the responsible entity, and not from the occurrence of the
incident.
    275. Several commenters argue against any time limit for reporting
security incidents. They believe the requirement to report such
incidents to the ESISAC is sufficient. Wisconsin Electric notes that
using the same one-hour limit in CIP 008-1 as in the ESISAC IAW SOP
would not represent a new performance threshold to the industry.
Commission Proposal
    276. The Commission believes that the ESISAC one-hour reporting
limit is reasonable and proposes that it be incorporated into CIP 008-
1. We reach this conclusion for several reasons. First, although it is
true that cyber attacks against different entities could occur
simultaneously, it would still be extremely useful to those attempting
to defend against those attacks to know what kind of threat they are
dealing with. The fact that simultaneous attacks are directed at other
entities would be important information about the nature of the
attacks.
    277. Second, while the Commission agrees that, in the aftermath of
a cyber attack, restoring the system is the utmost priority, we do not
believe that sending this short report would be a time consuming
distraction, and we judge that its probative value would justify the
minimal time spent in making this report.
    278. Third, the Commission disagrees with commenters that believe
that a reporting limit will not provide others with time for responsive
action to mitigate other potential Cyber Security Incidents. While a
reporting time limit may not allow such mitigation in every situation,
it very well could allow such mitigation in many situations.
    279. Fourth, although ESISAC's time limit is voluntary, a one hour
NERC reporting time limit would match up with the ESISAC reporting time
limit and, thus, would avoid conflicting requirements and would not
cause any new reporting burden.
    280. Thus, the Commission proposes to direct the ERO to modify CIP-
008-1 to require a responsible entity to contact appropriate government
authorities and industry participants in the event of a Cyber Security
Incident as soon as possible, but, in any event, within one hour of the
event, even if it is a preliminary report. While we leave development
of the details to NERC, the Commission agrees with APPA/LPPC that the
reporting timeframe should run from the discovery of the incident by
the responsible entity, and not the occurrence of the incident.
c. Full Operational Exercises and Lessons Learned
    281. The CIP Assessment stated that the annual testing of the
Incident Response Plan should require full operational exercises due to
the potential for such exercises to uncover unforeseen
complications.\110\ In addition, it indicated that CIP-008-1 does not
require documentation or reassessment of a plan's adequacy as a result
of lessons learned from testing or in response to specific issues.
---------------------------------------------------------------------------

    \110\ CIP Assessment at 37.
---------------------------------------------------------------------------

    282. NERC and ReliabilityFirst state that there are many instances
in substations or power plants where backup or fully functional test
systems do not exist, making a full operational exercise an extremely
risky proposition. Because of this, NERC and ReliabilityFirst believe
that a universal requirement for a full operational exercise may be
unduly disruptive and burdensome to reliable operations, and represent
a threat to the overall reliability of the Bulk-Power System. NERC and
ReliabilityFirst believe that table-top exercises are sufficient to
test the effectiveness of an Incident Response Plan. Several commenters
agree. Ontario IESO posits that there is no evidence that a paper drill
would be materially inferior to an operational exercise.

    283. A number of commenters believe that requiring a full
operational exercise during the three-year documentation cycle and
paper drills during the other two years should provide the desired
benefits of testing the Incident Response Plan. An actual incident
response would satisfy the need for a full operational exercise during
a three-year cycle. One commenter, the ISA Group, believes that full
operational exercises should be mandated at least yearly. Wisconsin
Electric states that, if full drills become a requirement, they should
be conducted every five years, with paper drills only when the process
or procedure is created or changed.
    284. Several commenters note that there may be a significant
benefit in executing an operational exercise over a paper drill, but
note that an operational exercise also can require expensive back-up
systems and may unnecessarily risk damaging system functionality in
case of an error or unforeseen system effect. Georgia System believes
each responsible entity has to determine whether the incremental
benefit from a yearly exercise is worth the costs and reliability risks
associated with the exercise. MidAmerican states it could support full
operational exercises for a limited number of critical assets, with
paper exercises for the remaining facilities. National Grid suggests
that operational drills are more appropriate for actual recovery plans
under CIP-009-1, and paper drills are more than adequate to assess
whether the response plans under CIP-008-1 identify and alert the right
responders. Xcel Energy is concerned that operational drills (like
vulnerability tests) could cause an inadvertent disruption to EMS and
SCADA systems.
    285. NERC and ReliabilityFirst state that collection and
maintenance of lessons learned, and plan improvement are included in
the ``update'' language of Requirement R1.4. Allegheny states that
documentation and implementation of lessons learned is a critical part
of any incident response or drill. As such, Allegheny believes the need
to maintain a collection of lessons learned as a result of testing the
Incident Response Plan and to apply them to plan improvements is
necessary to ensure response plans remain viable. Wisconsin Electric
submits that lessons learned from incident response exercises should be
documented as well as audited for completion of any enhancements to the
process.
Commission Proposal
    286. We understand from commenters that annual testing may be
costly and disruptive. Nonetheless, periodic operational drills are
important because they may reveal weaknesses, vulnerabilities, and
opportunity for improvement that a paper drill would not identify. The
Commission agrees with the commenters that suggest that a full
operational exercise should be performed at least once every three
years, and that tabletop exercises are sufficient for the other two
years. We believe this strikes an appropriate balance between the
benefits of executing an operational exercise and the associated costs
and potential risks of misoperations. Therefore, the Commission
proposes to direct the ERO to revise the Reliability Standard to
require responsible entities to perform a ``full operational exercise''
at least once every three years, or to fully document its reason for
not conducting an exercise in full operational mode pursuant to the
technical feasibility parameters discussed earlier in section II.A.5.b.
Further, the Commission proposes to direct the ERO to provide guidance
on the meaning of the term ``full operational exercise.'' \111\
---------------------------------------------------------------------------

    \111\ We address the meaning of the term ``full operational
exercise'' in section II.B.8.c below.
---------------------------------------------------------------------------

    287. The Commission believes that industry will benefit from a
requirement to document and implement lessons learned from testing or
responses to actual cyber security incidents. Although NERC and
ReliabilityFirst suggest that this is included in the ``update''
language of Requirement R1.4, we believe that the Reliability Standard
would be improved by making a ``lessons learned'' requirement explicit.
Therefore, the Commission proposes to direct that the ERO refine CIP-
008-1, Requirement R2 to require responsible entities to maintain
documentation of paper drills, full operational drills, and responses
to actual incidents, all of which must include lessons learned. The
Commission also proposes to direct the ERO to include language to
require revisions to the Incident Response Plan to address these
lessons learned.
d. Commission Proposal Summary
    288. In summary, the Commission proposes to approve Reliability
Standard CIP-008-1 as mandatory and enforceable. In addition, the
Commission proposes to direct the ERO, pursuant to section 215(d)(5) of
the FPA and Sec.  39.5(f) of our regulations to develop modifications
to CIP-008-1 through its Reliability Standards development process
that: (1) Develop and include language regarding the term ``reportable
incident'' that takes into account a breach that may occur through
cyber or physical means; (2) harmonize, but not necessarily limit, the
meaning of the term reportable incident with other reporting
mechanisms, such as DOE Form 417; (3) recognize that the term
``reportable incident'' should not be triggered by ineffectual and
untargeted attacks that proliferate on the internet; (4) ensure that
the guidance language that is developed results in a Reliability
Standard that can be audited and enforced; (5) require a responsible
entity to contact appropriate government authorities and industry
participants in the event of a Cyber Security Incident as soon as
possible, but at least within one hour of the event, even if it is a
preliminary report; (6) require responsible entities to perform a
``full operational exercise'' at least once every three years, or to
fully document its reason for not conducting an exercise in full
operational mode pursuant to the technical feasibility parameters
discussed earlier herein and provide guidance on the meaning of the
term ``full operational exercise;'' (7) refine Requirement R2 to
require responsible entities to maintain documentation of paper drills,
full operational drills, and responses to actual incidents, all of
which must include lessons learned; and (8) require revisions to the
Incident Response Plan to address the lessons learned.
8. CIP-009-1--Recovery Plans for Critical Cyber Assets
    289. The purpose of proposed Reliability Standard CIP-009-1 is to
ensure that recovery plans for critical cyber assets are in place and
following established business continuity and disaster recovery
techniques and practices. This Reliability Standard establishes
required development, updating, and testing of recovery plans, as well
as storage and testing of associated backup data and backup media.
    290. The Commission proposes to approve Reliability Standard CIP-
009-1 as mandatory and enforceable. In addition, we propose to direct
the ERO to develop modifications to this Reliability Standard. Further,
the Commission also proposes to require the ERO to consider various
other matters of clarification, guidance, and modification. In our
discussion below, the Commission addresses its concerns in the
following topic areas regarding CIP-009-1: (1) Recovery plans; (2)
forensic data collection; (3) operational exercises; (4) recovery plan
updates; (5) backup and storage of restoration data and (6) testing of
backup media.

a. Recovery Plans
    291. Requirement R1 of CIP-009-1 requires the responsible entity to
create and annually review recovery plans for critical cyber assets.
The CIP Assessment expressed concern that the ``events or conditions of
varying duration and severity that would activate the recovery
plan(s)'' language is very general and does not provide or require a
definition of what constitutes a precipitating event or triggering
condition necessary for recovery plan implementation.
    292. NERC, MidAmerican, Xcel, and Allegheny comment that providing
additional detail will limit the scope of potential ``precipitating
events'' addressed by recovery plans, and will not provide for the
needed flexibility. NERC states that the determination of which events
warrant a recovery plan is intentionally left to the discretion of
responsible entities. Wisconsin Electric and others agree with the CIP
Assessment that additional clarification should be added to this
Requirement.
Commission Proposal
    293. The Commission shares the concern that ``precipitating
events'' are readily recognized by responsible entities so that
recovery plans are promptly implemented. While we do not propose to
require modifications regarding the ``events and conditions'' language
at this time, we do note that Requirement R1 fails to state that the
plans it requires must be implemented when needed. That is, it requires
that recovery plans must be ``created and reviewed'' but does not
explicitly require actual implementation when the ``events or
conditions of varying duration and severity'' occur. We propose to
direct the ERO to modify to CIP-009-1 to include this requirement. In
the interim period, the Commission will infer that implementation is
embodied in this Requirement when enforcing it; i.e., if an entity has
the required recovery plan but does not implement it when the
anticipated event or conditions occur, the entity will not be in
compliance with this Reliability Standard.
b. Forensic Data Collection
    294. The CIP Assessment pointed out that Requirement R1 does not
provide guidance on whether and how the recovery plans should preserve
data for forensics purposes. In particular, Requirement R1 does not
specify whether forensics collection should occur prior to,
contemporaneously with, or after recovery of the critical cyber assets.
    295. NERC, ReliabilityFirst, and PG&E assert that there are no
Bulk-Power System reliability issues associated with forensic data
collection, and that there is a possibility that collection of forensic
data could impede the restoration of cyber assets, which in turn could
affect the reliable operation of the Bulk-Power System. NERC comments
that each entity must consider the balance between data collection and
actions required to rapidly restore the electric power transmission.
NERC states that after-the-fact recovery of incident data cannot be
assumed to be technically possible on legacy equipment and that,
therefore, it cannot be a requirement. Georgia System stresses that
restoring the Bulk-Power System should remain the foremost objective of
all immediate efforts, over issues of data collection.
    296. Allegheny comments that forensics collection should also be
addressed within this range of plans. Noting again that one size does
not fit all in regards to scenarios for recovery planning, Allegheny
says that forensic collection should be addressed in each of the plans
that addresses the various scenarios.
Commission Proposal
    297. The Commission is concerned that Requirement R1 of CIP-009-1
does not require the collection of forensics data and does not address
how such collection activities relate to restoration of service
efforts. The Commission believes that concern for the reliability of
the Bulk-Power System requires attention to forensics data collection.
The Blackout Report also emphasized the need to improve forensics and
diagnostic capabilities in Recommendation 37.\112\ Obtaining forensic
data will benefit the long-term reliability of the Bulk-Power System
because the lessons learned from one event assist in eliminating or
dealing with a repeat (or similar) event. Forensic data collection
procedures could be as minimal as preserving a corrupted drive, making
a data mirror of the system before proceeding with recovery, or taking
the important assessment steps necessary to avoid reintroducing the
precipitating or corrupted data. Technical capabilities to do so will
likely vary with the facility, and many legacy systems present
considerable technical limitations in this regard. In the interest of
``raising the bar'' above what the least capable equipment can do to
collect forensic data, the Commission proposes to direct the ERO to
modify CIP-009-1 to incorporate use of good forensic data collection
practices into this CIP Reliability Standard.
---------------------------------------------------------------------------