UNITED STATES OF AMERICA FEDERAL ENERGY REGULATORY … · 2010. 6. 28. · Docket No. RM06 -22 -008...

130 FERC ¶ 61,211UNITED STATES OF AMERICA

FEDERAL ENERGY REGULATORY COMMISSION

Before Commissioners: Jon Wellinghoff, Chairman;Marc Spitzer, Philip D. Moeller,and John R. Norris.

Mandatory Reliability Standards forCritical Infrastructure Protection

Docket No. RM06-22-008

ORDER ADDRESSING VIOLATION SEVERITY LEVEL ASSIGNMENTS FORCRITICAL INFRASTRUCTURE PROTECTION RELIABILITY STANDARDS

(Issued March 18, 2010)

1. On June 30, 2009, the North American Electric Reliability Corporation (NERC)submitted a filing in compliance with Order No. 706, seeking the approval of ViolationSeverity Levels for eight Version 1 Critical Infrastructure Protection (CIP) ReliabilityStandards, CIP-002-1 through CIP-009-1 (Compliance Filing).1 In this Order, theCommission approves the proposed Violation Severity Level assignments, as revised asdiscussed herein, effective as of the date of issuance of this order. Further, the Commissionestablishes additional guidance for determining appropriate Violation Severity Levels inthe specific context of cyber security Requirements. Applying the new and existingguidelines for analyzing Violation Severity Levels, the Commission directs NERC tosubmit a compliance filing modifying 57 sets of Violation Severity Level assignmentswithin 60 days of the issuance of this order, as discussed below.

I. Background

A. Violation Severity Levels

2. NERC and the Regional Entities use Violation Severity Levels to determinepenalties for individual violations of Requirements of a Reliability Standard. A ViolationSeverity Level is a post-violation measurement of the degree to which a Reliability

1 Mandatory Reliability Standards for Critical Infrastructure Protection, OrderNo. 706, 122 FERC ¶ 61,040, order on clarification, Order No. 706-A, 123 FERC¶ 61,174 (2008), order on clarification, Order No. 706-B, 126 FERC ¶ 61,229 (2009).

20100318-3091 FERC PDF (Unofficial) 03/18/2010

Docket No. RM06-22-008 2

Standard Requirement was violated (“Lower,” “Moderate,” “High,” or “Severe”). Toestablish a Base Penalty range for a violation, NERC considers the Violation SeverityLevel, together with a Violation Risk Factor, which represents the potential risk toreliability.

3. In a June 2007 Order, the Commission directed NERC to develop ViolationSeverity Levels for each Requirement and sub-Requirement of each previously-approvedReliability Standard.2 NERC submitted the required filing and, in a June 2008 Order, theCommission approved Violation Severity Levels corresponding to the Requirements andsub-Requirements of 83 Reliability Standards, not including the CIP ReliabilityStandards.3 The Commission also directed NERC to submit a compliance filing andseveral reports. In addition, the Commission developed four guidelines for evaluating thevalidity of Violation Severity Level assignments. Specifically, Violation Severity Levels:(1) should not have the unintended consequence of lowering the current level ofcompliance; (2) should ensure uniformity and consistency among all approved ReliabilityStandards in the determination of penalties; (3) should be consistent with thecorresponding Requirement; and (4) should be based on a single violation, not on acumulative number of violations. The Commission also noted that it retains theflexibility to consider the development of additional guidelines as appropriate.4

4. On June 30, 2008, in a subsequent filing to revise certain Reliability Standards,NERC proposed to change the manner in which it assigns Violation Severity Levels,essentially eliminating assignments for certain sub-requirements. While the Commissionfound that it was “premature” to change its current policy of assigning Violation SeverityLevels to each Requirement and sub-Requirement, it encouraged NERC to develop acomprehensive approach that would better facilitate the assignment of Violation SeverityLevels.5

2 North American Electric Reliability Corp., 119 FERC ¶ 61,248, at P 80(June 2007 Order), order on clarification, 120 FERC ¶ 61,239 (2007).

3 North American Electric Reliability Corp., 123 FERC ¶ 61,284 (VSL Order),order on reh’g and clarification, 125 FERC ¶ 61,212 (2008) (VSL Rehearing Order).

4 VSL Order, 123 FERC ¶ 61,284 at P 17 n.12.

5 Version Two Facilities Design, Connections and Maintenance ReliabilityStandards, Order No. 722, 126 FERC ¶ 61,255, at P 44-46 (2009). In August 2009,NERC submitted an informational filing describing more fully its plans for a new,comprehensive approach to assigning Violation Severity Levels. See NERC,Informational Filing Regarding the Assignment of Violation Risk Factors and ViolationSeverity Levels, Docket No. RM08-11-000 (Aug. 10, 2009). NERC has not submitted a

(continued)



B. Order No. 706

5. NERC submitted eight CIP Reliability Standards for Commission approval: CIP-002-1 - Critical Cyber Asset Identification; CIP-003-1 - Security Management Controls;CIP-004-1 - Personnel & Training; CIP-005-1 - Electronic Security Perimeter(s); CIP-006-1 - Physical Security of Critical Cyber Assets; CIP-007-1 - Systems SecurityManagement; CIP-008-1 - Incident Reporting and Response Planning; CIP-009-1 -Recovery Plans for Critical Cyber Assets. The eight Version 1 CIP Reliability Standardsrequire certain users, owners, and operators of the Bulk-Power System to comply withspecific Requirements to safeguard critical cyber assets.

6. In Order No. 706, issued on January 18, 2008, the Commission approved the eightVersion 1 CIP Reliability Standards. In addition, pursuant to section 215(d)(5) of theFederal Power Act (FPA), the Commission directed NERC to develop modifications toaddress specific issues. NERC’s submission of the eight CIP Reliability Standards didnot include Violation Severity Level assignments. The Commission, therefore, alsodirected NERC to file Violation Severity Levels before July 1, 2009.6

II. NERC Compliance Filing

7. In the instant Compliance Filing, NERC proposes 118 sets of Violation SeverityLevels corresponding to 171 Requirements and sub-Requirements contained in theVersion 1 CIP Reliability Standards. NERC’s filing does not individually assign anyViolation Severity Levels to the remaining sub-Requirements; rather, NERC proposesthat they would be governed by the Violation Severity Levels assigned to their respectivemain Requirements (14 of the 118 sets of Violation Severity Levels). NERC states that,in developing the Violation Severity Levels for the CIP Reliability Standards, the draftingteam considered NERC’s “VSL Development Guidelines and Criteria” (included in thefiling as Exhibit E, for informational purposes only), a reference document thatestablishes seven categories to classify the various types of Requirements in NERCReliability Standards.

8. NERC explains the development of the proposed Violation Severity Levels and itsresponses to issues that arose during the balloting process, namely: (1) distinguishingbetween risk and severity, as Violation Severity Levels measure the degree to which aprovision is violated; (2) efforts to limit use of generic language to describe severity

formal filing on its proposed approach to setting Violation Severity Levels forCommission action as of the date of this order.

6 See Order No. 706, 122 FERC ¶ 61,040 at P 758.



(such as “minor element”) and make text as specific as possible; and (3) whether theSevere level should be assigned to “binary” Requirements.7

9. NERC also states that stakeholders raised concern regarding the potential for“double jeopardy” where Violation Severity Levels are assigned to every Requirementand sub-Requirement of a Reliability Standard. NERC decided the double jeopardy issuewas beyond the scope of the drafting team because it is a compliance issue. NERC statedthat, in accordance with current Commission policy, the standards drafting team assigneda Violation Severity Level to every Requirement and sub-Requirement that had aViolation Risk Factor previously assigned to it.

10. NERC states that the Violation Severity Levels received 84 percent weightedsegment approval with 87 percent of the ballot pool participating. The NERC Board ofTrustees approved the proposed Violation Severity Levels on June 29, 2009. NERCrequests that the Commission approve the Violation Severity Levels for the Version 1CIP Reliability Standards, effective on approval.

III. Notice of Filing

11. Notice of NERC’s June 30, 2009 compliance filing was published in the FederalRegister, 74 Fed. Reg. 39314 (2009), with interventions and comments due on or beforeAugust 20, 2009. The Southwest Transmission Dependent Utility Group (STDUG) fileda timely motion to intervene and comment.

IV. Discussion

A. Procedural Matters

12. Pursuant to Rule 214 of the Commission's Rules of Practice and Procedure,18 C.F.R. § 385.214 (2009), the timely, unopposed motion to intervene serves to makethe entity that filed it a party to this proceeding.8

7 NERC explains that binary Requirements are those that can only be fully met ornot met, and explains that violations of binary Requirements are designated as Severebecause the Violation Severity Level is a measure of how well or completely theRequirement has been met (as distinguished from the Violation Risk Factor considerationof the expected impact to the Bulk-Power System resulting from a violation of aparticular Requirement).

8 STDUG submitted comments that are beyond the scope of the immediateproceeding because they pertain to a proposed relay loadability Reliability Standard,PRC-023-1, which is pending before the Commission in Docket No. RM08-13-000.



B. Commission Determination

13. NERC submitted 118 sets of Violation Severity Levels. The Commissionapproves the proposed Violation Severity Levels. Further, for the reasons discussedbelow, the Commission directs NERC to submit modifications to 57 sets of ViolationSeverity Level assignments within 60 days of the issuance of this order.9

14. In making these determinations, the Commission considered the ViolationSeverity Level Guidelines set forth in the VSL Order. Further, in the VSL Order, theCommission stated that it retains the flexibility to consider the development of additionalguidelines as appropriate.10 The Commission determines that, in the context of the cybersecurity Requirements of the CIP Reliability Standards, additional guidelines areappropriate to better reflect certain characteristics of the cyber environment. Specifically,we have developed the following two additional guidelines for analyzing the validity ofViolation Severity Levels that pertain to cyber security:

(1) Requirements where a single lapse in protection cancompromise computer network security, i.e., the “weakestlink” characteristic, should apply binary rather than gradatedViolation Severity Levels; 11 and

(2) Violation Severity Levels for cyber security Requirementscontaining interdependent tasks of documentation andimplementation should account for their interdependence.

9 The Appendix to this order lists the Version 1 CIP Reliability StandardRequirements for which the Commission is directing revisions to correspondingViolation Severity Levels. The revisions are shown in redline against the ViolationSeverity Levels proposed in NERC’s Compliance Filing. In addition, the existingVersion 1 Violation Risk Factors previously approved by the Commission are shown forreference. The Violation Severity Levels that are approved without change are not shownin the Appendix.

10 VSL Order, 123 FERC ¶ 61,284 at P 17 n.12. As noted, the VSL Order did notaddress Violation Severity Levels assigned to CIP Reliability Standards.

11 Violation Severity Level “gradation” refers to the ability to identify degrees ofnoncompliance that result in performance that partially meets the reliability objective ofthe Requirement such that the performance or product has some reliability-related value.Violation Severity Level sets with several levels are “gradated” and those with fewerlevels than others are “less gradated.” VSL Order, 123 FERC ¶ 61,284 at P 26-27; VSLRehearing Order, 125 FERC ¶ 61,212 at P 65.



These guidelines are discussed below and applied in our analysis of whether to accept theproposed Violation Severity Levels corresponding to the provisions of the CIP ReliabilityStandards.

1. Additional Guidelines to Address Cyber Security Characteristics

a. CIP Guideline 1: Requirements where a single lapse inprotection can compromise computer network security,i.e., the “weakest link” characteristic, should apply binaryViolation Severity Levels

15. A single lapse of computer protection can create the opening for malicious activitythat has systemic critical infrastructure consequences. In this sense, the control systemsthat support Bulk-Power System reliability are “only as secure as their weakest links.” Insuch cases, the severity of non-compliance is not necessarily dependent on the number ofsimilar lapses because a single vulnerability opens the computer network to potentialmalicious activity. Thus, in the context of cyber-security, severity of non-compliance isin many instances better assessed in a binary, as opposed to a gradated approach.

16. Although the Commission previously stated a preference for assigning ViolationSeverity Levels in multiple levels, i.e., the gradated approach, it also recognized that abinary approach can be appropriate, such as when a failure to comply is absolute.12 TheCommission concludes that a Requirement of the CIP Reliability Standards with the“weakest link” characteristic is such an instance, and directs NERC to revise specificViolation Severity Level assignments for such Requirements to employ a binaryapproach.13

17. A number of CIP Reliability Standards Requirements address a “weakest-link”vulnerability where the system is either in a “secure” or “not secure” state. In particular,the gradation of Violation Severity Levels across several severity levels is not appropriatefor specific CIP Reliability Standards that require security actions to be taken for allCritical Cyber Assets or concern all access points to such assets. For example, CIP-005-1, Requirement R4 requires a vulnerability assessment of electronic access points to anElectronic Security Perimeter. If any one required preventative measure is neglected, the

12 VSL Rehearing Order, 125 FERC ¶ 61,212 at P 65.

13 The relevant provisions of the Version 1 CIP Reliability Standards, alsoidentified in the Appendix, are as follows: CIP-004-1, Requirement R2.1; CIP-005-1,Requirements R1, R1.4, R1.5, R1.6, R2.2, R2.5, R3, R3.1, R3.2, R4 and R5.2; CIP-006-1Requirements R1.5, R1.8 and R6; and CIP-007-1, Requirements R1, R2.1, R2.2, R4,R5.1.1, R5.2.3, R5.3, R6, and R8.



result is one or more insecure points of ingress – an unmitigated vulnerability thatpresents a severe risk to the Critical Cyber Asset.

18. There are also instances where monitoring controls present a “weakest link”condition. For example, CIP-005-1, Requirement R 3.2 requires responsible entities todetect attempts at unauthorized access to one or more components of a Critical CyberAsset. If even one access point does not have monitoring processes implemented thatinclude detection and alerting for attempts at or actual unauthorized accesses, there is anopportunity for undetected unauthorized access to the Critical Cyber Asset.

19. A variation on this theme is presented by CIP-007-1, Requirement R1, which isintended to address adverse consequences relating to adding or changing Cyber Assetswithin the Electronic Security Perimeter. The Requirement encompasses protection tasksenumerated in three sub-Requirements, and NERC proposes to gradate according to thenumber of sub-Requirements completed. However, when viewed independently, eachsub-Requirement is binary; compliance with each is needed to complete the parentRequirement. Therefore, the Commission directs a binary approach, as shown in theAppendix.

b. CIP Guideline 2: Violation Severity Levels for CyberSecurity Requirements Containing Interdependent Tasksof Documentation and Implementation Should Accountfor Their Interdependence

20. Certain provisions of the CIP Reliability Standards identify two or more taskswithin one Requirement. For example, some provisions of the CIP Reliability Standardsrequire performance of both implementation and documentation tasks. For a number ofthese Requirements, NERC proposes Violation Severity Level sets with gradationsparsing out multiple actions contained in the Requirement. In fact, NERC’s approach isconsistent with the guidance provided in the VSL Order, in which the Commission statedits concern that the Violation Severity Levels need to consider the scenario where anentity has documented all the required elements in a plan, but failed to implement theplan.14 However, upon further consideration, while this approach is generally appropriatefor assigning Violation Severity Levels, a different approach is needed in the context ofcritical infrastructure protection, for the reasons discussed below.

21. In critical infrastructure protection, and especially in the cyber securityenvironment, the implementation of security measures is largely dependent on complexplans, policies and procedures that must be repeatable and verifiable. This necessitatesdocumentation of both (1) the procedures to be followed and (2) verification that the

14 VSL Order, 123 FERC ¶ 61,284 at P 34.



procedures were followed as directed. These complex procedures require clear andconsistent instructions (documentation) and consistent execution (implementation).Further, these procedures also require a method for reporting their completion. Eachcomponent is part of an iterative operation security framework. Planning, design andimplementation of documentation enable the effective implementation of securitymeasures and documentation of results. In fact, for certain Requirements of CIPReliability Standards, it is difficult if not impossible to demonstrate that a networkoperator has implemented a specific plan or program without developing thedocumentation for the plan or program. Thus, the Commission believes that theinterdependency between documentation and implementation in the context of criticalinfrastructure should be recognized in Violation Severity Level assignments.

22. For instance, CIP-005-1, Requirement R2 provides that a responsible entity mustimplement and document the processes and mechanisms for control of electronic accessat all electronic access points to the Electronic Security Perimeter(s). NERC proposesgradated Violation Severity Levels based on implementation without documentation andvise versa. However, verifying the successful electronic implementation of manycontrols regarding electronic access depends on the documentation. Thus, separatingimplementation and documentation for Violation Severity Level assignments is notappropriate in this instance. If a responsible entity documents the processes andmechanisms, but does not follow through to implement them, then the entity is notsecure. Also, if the entity attempts to implement the controls set forth in RequirementR2, but does not have documented organizational processes and mechanisms required tocontrol electronic access to the Electronic Security Perimeter, the implementation may befaulty due to such factors as an imperfect memory of an employee or a recent change tocyber assets with which an employee is unfamiliar.

23. Other provisions of the CIP Reliability Standards include similar interdependenttasks, and present a similar concern with the appropriate assignment of Violation SeverityLevels. Accordingly, we direct NERC to revise seventeen sets of Violation SeverityLevel assignments, specified in the Appendix, to address interdependency concernsdiscussed above.15

2. Timeliness of Compliance and Commission Guideline No. 1

24. For several Requirements in the CIP Reliability Standards, NERC proposes thatthe Violation Severity Level sets should be gradated according to the length of time inwhich an entity is not compliant. For certain of these Violation Severity Level sets, the

15 Version 1 CIP Reliability Standards: CIP-003-1, Requirements R1, R1.3, R3.3,R4, R5, and R6; CIP-005-1, Requirements R2, R3, and R3.1; CIP-006-1, RequirementsR2, R3, and R4; CIP-007-1, Requirements R2, R3, R4.2, R5, R6.1.



Commission believes that the proposed lengths of time are too permissive and violate theCommission’s Guideline No. 1 as described in the VSL Order. Guideline No. 1 statesthat Violation Severity Level assignments should not have the unintended consequence oflowering the current level of compliance.16 For example, in that Order, we expressed aconcern that “assigning up to 25 percent non-compliance at the ‘Lower’ ViolationSeverity Level may have the unintended consequence of signaling that a greater level ofnon-compliance than historically evident is condoned.17 The Commission furtherexplained its intent to rely on historical compliance data to establish the current level ofcompliance in the VSL Rehearing Order.

25. However, the CIP Requirements at issue here are new and historical compliancedata is extremely limited at best. While certain entities had to be auditably compliantwith some of these CIP Requirements by June 30, 2009, the earliest auditably compliantdate for other CIP Requirements is June 30, 2010.

26. The Violation Severity Level assignments proposed by NERC for theseRequirements allow multiples of the time periods specified in the Requirement languagebefore a violation is considered severe. For example, CIP-003-1, Requirement R3.1requires an entity to document exceptions to its security policy within 30 days of beingapproved by the senior manager or delegate(s). The proposed Violation Severity Levelassignments would allow an entity to take almost twice as long (59 days) to documentexceptions and only trigger a “Lower” Violation Severity Level. They would allow anentity to take four-times as long (120 days) as the Requirement language specifies beforetriggering a “Severe” Violation Severity Level.

27. The magnitude of non-compliance allowed by NERC’s proposed gradations forthese CIP Requirements before reaching the “Severe” level of Violation Severity Level,in light of the lack of applicable historical compliance data that proves otherwise, leadsthe Commission to conclude that the proposed Violation Severity Level assignments forthese CIP Requirements would condone a greater level of non-compliance than isappropriate. In making this determination, without applicable historical evidence, theCommission is placing significant weight on the terms of the Requirements in question.Once such historical evidence accumulates, NERC may return to us to demonstrate thebasis for greater gradation. Until such a time, the Commission directs NERC to revisespecific Violation Severity Level assignments, specified in the Appendix, to address theconcern described above about levels of non-compliance.18

16 VSL Order, 123 FERC ¶ 61,284 at P 17.

17 Id. P 21.

18 This reasoning applies to gradation modifications directed to CIP-003-1,(continued)



3. Consistency and Clarity Concerns

28. In the VSL Order, the Commission’s Guideline 2(b) provides that, to better ensureconsistency and uniformity in the determination of penalties, Violation Severity Levelassignments should not contain ambiguous language.19 In numerous Violation SeverityLevels corresponding to the CIP Reliability Standards, NERC uses the term “nor” to referto two or more tasks where other language is more appropriate to clearly indicate thatnon-compliance of either one is captured by the Violation Severity Level category. TheCommission directs revisions to clarify conjunction usage issues in various ViolationSeverity Level assignments, along with other changes, as identified in the Appendix.20

29. The Commission has identified other matters of consistency and clarity in theseand other sets of Violation Severity Level assignments that require revision based on theapplication of Guideline 2(b) set forth in the VSL Order. Specifically, the Commissionstated that “in general, relative and subjective language is subject to multipleinterpretations that could result in inconsistent application of the Violation SeverityLevels when determining penalties.”21

30. For example, CIP-003-1, Requirement R3 specifies that a responsible entity mustdocument as exceptions, authorized by the senior manager, instances where it cannotconform to its cyber security policy. The cyber security policy is required by CIP-003-1,Requirement R1, which specifies that the policy must address the Requirements instandards CIP-002-1 through CIP-009-1. NERC’s proposed Violation Severity Levelsfor CIP-003-1, Requirements R3, R3.2 and R3.3 insert the parenthetical phrase,“pertaining to CIP-002 through CIP-009” even though this phrase does not appear inthese specific Requirements. This phrase could be misunderstood to mean that an entityhas the discretion to except itself from Requirements of the mandatory CIP ReliabilityStandards, which is not permitted.22

Requirements R2.2 and 3.1; CIP-007-1, Requirement R3.1; and CIP-009-1, RequirementR3.

19 VSL Order, 123 FERC ¶ 61,284 at P 22-23, 28-31.

20 Commission approved Reliability Standards: CIP-003-1, Requirements R1,R1.3, R2.1, R3.3, R4, R4.3, R5, R5.1.1, and R6; CIP-005-1, Requirements R1, R1.4, R2,R2.2, R3, and R3.1; CIP-006-1, Requirements R1.5, R2, R3, and R4; and CIP-007-1,Requirements R1, R2, R2.1, R2.2, R3, R4, R4.2, R5, R5.3, and R6.1.

21 VSL Order, 123 FERC ¶ 61,284 at 31.

22 Order No. 706, 122 FERC ¶ 61,040 at P 376.



31. CIP-004-1, Requirement R2.2 raises an issue of consistency of sub-parts with theparent Requirement. The sub-Requirements of CIP-004-1, Requirement R2 mandateminimum cyber security training tasks. NERC proposes gradation of Violation SeverityLevels for these sub-Requirements based on how many of the minimum tasks are notperformed. However, an effective and complete training program dealing with cyberassets requires all of these components. Therefore, the Commission directs a binaryapproach to reflect non-performance of one or more of the minimum required cybersecurity training tasks set forth in CIP-004-1, Requirement R2.2.

32. NERC’s proposed Violation Severity Level sets include several that containextraneous language that could cause confusion. For example, CIP-004-1, RequirementR2.3 requires that an entity “shall maintain documentation that training is conducted atleast annually, including the date the training was completed and attendance records.”NERC’s proposed Violation Severity Level text assumes that the training was “conductedannually,” and distinguishes gradation based on failure to “include either the date thetraining was completed or attendance records.” However, for the entity to plausibly“maintain documentation” that the training is conducted at least “annually,” the entitymust include at a minimum the date(s) the training was completed. Therefore, theeither/or phrase cited above is not needed because the only remaining aspect of theRequirement to reference is the existence of “attendance records.” The Commissiondirects NERC to remove the extraneous language concerning the date of training.

33. For the reasons set forth above, the Commission directs the ERO to revise certainViolation Severity Level assignments to remove ambiguity and improve consistency, asset forth in the Appendix.23

4. Violation Severity Levels that Address Main and Sub-PartsTogether

34. As discussed earlier, the Commission previously directed NERC to developViolation Severity Level sets for each Requirement and sub-Requirement of eachReliability Standard.24 However, NERC’s filing included 53 sub-Requirements for which

23 Commission-approved Reliability Standards: CIP-003-1 Requirements R2.1,R3, R3.2 and R3.3, R4.3, R5.1.1, R6; CIP-004-1 Requirements R2.2, R2.3 and R3; CIP-005-1, Requirements R3 and R3.1; CIP-006-1, Requirement R1.7; CIP-007-1Requirements R5.1.1, R6.4 and R7; CIP-008-1, Requirements R1 and R2; and CIP-009-1, Requirement R1.

24 June 2007 Order, 119 FERC ¶ 61,248 at P 80. As noted earlier, NERC has filedan Informational Filing describing how it intends, at a future time, to propose acomprehensive reformulation of Violation Severity Levels, but has yet to submit a formalfiling for Commission approval.



NERC proposes to apply the Violation Severity Levels assigned to the respective parentRequirements, 14 in all.25

35. Nonetheless, we will accept these Violations Severity Levels as an exception toour current policy. We are satisfied that none of the sub-parts without a ViolationSeverity Level assignment constitutes an independent compliance Requirement, separatefrom the primary Requirement. Accordingly, without ruling on the appropriateness ofthis approach for other standards or other versions of the CIP Reliability Standards, theCommission accepts the Violation Severity Levels assignments associated with these 14provisions, and will not require NERC to submit additional assignments for them.

36. While approving this consolidated assignment of Violation Severity Level sets forthese 14 Requirements, we are concerned about possible confusion as to which ViolationRisk Factor applies in the event of one or more violations,26 since the Commission hasalready approved Violation Risk Factor designations for each of the respective 53 sub-Requirements. To address this, we clarify that in such cases the ComplianceEnforcement Authority27 should determine the base penalty range for each sub-part of theRequirement that is violated by applying the Violation Risk Factor corresponding to thatsub-part.28

25 One of these 14 Requirements is CIP-002-1, Requirement R 2.1, for which theCommission approves the Violation Severity Level set NERC proposed to address it andits seven sub-Requirements. The remaining thirteen of these Requirements appear inAppendix A because their respective Violation Severity Level sets are subject torevisions directed by this order; these revisions also address the remaining 46 sub-Requirements for which NERC did not file individual Violation Severity Levels.

26 See NERC’s August 10, 2009 informational filing at 10-12.

27 See NERC Rules of Procedure, Appendix 4C, NERC Compliance Monitoringand Enforcement Program, section 1.1.7 (stating the Compliance Enforcement Authorityis NERC or the Regional Entity in their respective roles of monitoring and enforcingcompliance with the NERC Reliability Standards).

28 See also NERC Sanctions Guidelines, section 3.10 (stating that “in instances ofmultiple violations related to a single act or common incidence of non-compliance,” theresulting penalty should “generally be at least as large or expansive as what would becalled for individually for the most serious of the violations.”).



V. Conclusion

37. Applying the Commission’s previously articulated guidelines for analyzingViolation Severity Level assignments, as well as additional guidelines that applyspecifically in the cyber security context, we approve the proposed Violation SeverityLevel assignments. In addition, we direct NERC to revise 57 sets of Violation SeverityLevel assignments, as discussed in the body of this order and set forth in the Appendix.NERC must submit a compliance filing with the revised Violation Severity Levelassignments within 60 days of date of issuance of this order.

The Commission orders:

(A) NERC’s compliance filing is hereby approved, effective as of the date ofthis order, as discussed in the body of this order.

(B) NERC is hereby directed to submit a compliance filing that includesrevised Violation Severity Level assignments as identified in the Appendix, within 60days of the date of this order, as discussed in the body of this order.

By the Commission.

( S E A L )

Kimberly D. Bose,Secretary.


APPENDIX 1 to RM06-22-008 – Commission-Directed Changes to Proposed Violation Severity Levels for the Version 1 CIP ReliabilityStandards (CIP Requirements not shown here with edits to VSL Text are approved as filed)

1

Appendix

Standard Reqt. Requirement Language VRF

Lower VSL Moderate VSL High VSL Severe Guideline

CIP-003-1 R1. Cyber Security Policy — TheResponsible Entity shall documentand implement a cyber securitypolicy that representsmanagement’s commitment andability to secure its Critical CyberAssets. The Responsible Entityshall, at minimum, ensure thefollowing:

MED

N/A N/A N/A The Responsible Entityhas not documented orimplemented a cybersecurity policy.

CIPGuideline 2

VSLGuideline2(b)

CIP-003-1 R1.3. Annual review and approval of thecyber security policy by the seniormanager assigned pursuant toR2.

LOW

N/A N/A N/A The Responsible Entity'ssenior manager,assigned pursuant to R2,did not complete theannual review andapproval of its cybersecurity policy.

CIPGuideline 2

VSLGuideline2(b)

CIP-003-1 R2.1. The senior manager shall beidentified by name, title, businessphone, business address, anddate of designation.

LOW

N/A N/A The senior manager isidentified by name, title,and date of designationbut the designation ismissing business phoneor business address

Identification of thesenior manageris missing one of thefollowing: name,title, or date ofdesignation.

VSLGuideline2(b)

CIP-003-1 R2.2. Changes to the senior managermust be documented within thirtycalendar days of the effectivedate.

LOW

N/A N/A N/A Changes to the seniormanager were notdocumented within 30days of the effectivedate.

VSLGuideline 1



2



CIP-003-1 R3. Exceptions — Instances wherethe Responsible Entity cannotconform to its cyber security policymust be documented asexceptions and authorized by thesenior manager or delegate(s).

LOW

N/A N/A In Instances where theResponsible Entitycannot conform to itscyber security policy, inR1, exceptions weredocumented, but werenot authorized by thesenior manager ordelegate(s).

In Instances where theResponsible Entitycannot conform to itscyber security policy, inR1, exceptions were notdocumented.

VSLGuideline2(b)

CIP-003-1 R3.1. Exceptions to the ResponsibleEntity’s cyber security policy mustbe documented within thirty daysof being approved by the seniormanager or delegate(s).

LOW

N/A N/A N/A Exceptions to theResponsible Entity’scyber security policywere not documentedwithin 30 days of beingapproved by the seniormanager or delegate(s).

VSLGuideline 1

CIP-003-1

.

R3.2. Documented exceptions to thecyber security policy must includean explanation as to why theexception is necessary and anycompensating measures, or astatement accepting risk.

LOW

N/A N/A N/A The Responsible Entityhas a documentedexception to the cybersecurity policy in R1, butdid not include both:1) an explanation as towhy the exception isnecessary, and2) any compensatingmeasures or a statementaccepting risk.

VSLGuideline2(b)

CIP-003-1 R3.3. Authorized exceptions to thecyber security policy must bereviewed and approved annuallyby the senior manager ordelegate(s) to ensure theexceptions are still required andvalid. Such review and approvalshall be documented.

LOW

N/A N/A N/A Exceptions to the cybersecurity policy were notreviewed or were notapproved on an annualbasis by the seniormanager or delegate(s)to ensure the exceptionsare still required andvalid or the review andapproval is notdocumented.

CIPGuideline 2

VSLGuideline2(b)



3



CIP-003-1 R4. Information Protection — TheResponsible Entity shallimplement and document aprogram to identify, classify, andprotect information associatedwith Critical Cyber Assets.

MED

N/A N/A N/A The Responsible Entitydid not implement or didnot document a programto identify, classify, andprotect informationassociated with CriticalCyber Assets.

CIPGuideline 2

VSLGuideline2(b)

CIP-003-1 R4.3. The Responsible Entity shall, atleast annually, assess adherenceto its Critical Cyber Assetinformation protection program,document the assessment results,and implement an action plan toremediate deficiencies identifiedduring the assessment.

LOW

N/A N/A N/A The Responsible Entitydid not annually assessadherence to its CriticalCyber Asset informationprotection program,including documentationof the assessmentresults,

OR

The Responsible Entitydid not implement anaction plan to remediatedeficiencies identifiedduring the assessment.

VSLGuideline2(b)

CIP-003-1 R5. Access Control — TheResponsible Entity shall documentand implement a program formanaging access to protectedCritical Cyber Asset information.

LOW

N/A N/A N/A The Responsible Entitydid not implement or didnot document a programfor managing access toprotected Critical CyberAsset information.

CIPGuideline 2

VSLGuideline2(b)

CIP-003-1 R5.1.1. Personnel shall be identified byname, title, business phone andthe information for which they areresponsible for authorizingaccess.

LOW

N/A N/A The Responsible Entitydid identify the personnelby name, title, and theinformation for whichthey are responsible forauthorizing access, butthe business phone ismissing.

Personnel are notidentified by name, title,or the information forwhich they areresponsible forauthorizing access.

VSLGuideline2(b)



4



CIP-003-1 R6. Change Control and ConfigurationManagement — The ResponsibleEntity shall establish anddocument a process of changecontrol and configurationmanagement for adding,modifying, replacing, or removingCritical Cyber Asset hardware orsoftware, and implementsupporting configurationmanagement activities to identify,control and document all entity orvendor related changes tohardware and softwarecomponents of Critical CyberAssets pursuant to the changecontrol process.

LOW

N/A N/A N/A The Responsible Entityhas not established ordocumented a changecontrol process for theactivities required in R6,

OR

The Responsible Entityhas not established ordocumented aconfigurationmanagement process forthe activities required inR6.

CIPGuideline 2

VSLGuideline2(b)

CIP-004-1 R2.1. This program will ensure that allpersonnel having such access toCritical Cyber Assets, includingcontractors and service vendors,are trained within ninety calendardays of such authorization.

MED

N/A N/A N/A Not all personnel havingaccess to Critical CyberAssets, includingcontractors and servicevendors, were trainedwithin ninety calendardays of suchauthorization.

CIPGuideline 1

CIP-004-1 R2.2. Training shall cover the policies,access controls, and proceduresas developed for the CriticalCyber Assets covered by CIP-004, and include, at a minimum,the following required itemsappropriate to personnel roles andresponsibilities:

MED

N/A N/A N/A The training does notinclude one or more ofthe minimum topics asdetailed in R2.2.1,R2.2.2, R2.2.3, R2.2.4.

VSLGuideline2(b)



5



CIP-004-1 R2.3. The Responsible Entity shallmaintain documentation thattraining is conducted at leastannually, including the date thetraining was completed andattendance records.

LOW

N/A N/A The Responsible Entitydid maintaindocumentation thattraining is conducted atleast annually, but did notinclude attendancerecords.

The Responsible Entitydid not maintaindocumentation thattraining is conducted atleast annually, includingthe date the training wascompleted andattendance records.

VSLGuideline2(b)

CIP-004-1 R3. Personnel Risk Assessment —The Responsible Entity shall havea documented personnel riskassessment program, inaccordance with federal, state,provincial, and local laws, andsubject to existing collectivebargaining unit agreements, forpersonnel having authorized cyberor authorized unescorted physicalaccess. A personnel riskassessment shall be conductedpursuant to that program withinthirty days of such personnelbeing granted such access. Suchprogram shall at a minimuminclude:

MED

N/A The Responsible Entityhas a personnel riskassessment program,as stated in R3, forpersonnel havingauthorized cyber orauthorized unescortedphysical access, butthe program is notdocumented.

The Responsible Entityhas a personnel riskassessment program asstated in R3, butconducted the personnelrisk assessment pursuantto that program in morethan thirty (30) days ofsuch personnel beinggranted such access.

The Responsible Entitydoes not have adocumented personnelrisk assessmentprogram, as stated in R3,for personnel havingauthorized cyber orauthorized unescortedphysical access. OR TheResponsible Entity didnot conduct thepersonnel riskassessment pursuant tothat program forpersonnel granted suchaccess.

VSLGuideline2(b)

CIP-005-1 R1. Electronic Security Perimeter —The Responsible Entity shallensure that every Critical CyberAsset resides within an ElectronicSecurity Perimeter. TheResponsible Entity shall identifyand document the ElectronicSecurity Perimeter(s) and allaccess points to the perimeter(s).

MED

N/A N/A N/A The Responsible Entitydid not ensure that everyCritical Cyber Assetresides within anElectronic SecurityPerimeter, OR theResponsible Entity didnot identify anddocument the ElectronicSecurity Perimeter(s) andall access points to theperimeter(s).

CIPGuideline 1

VSLGuideline2(b)



6



CIP-005-1 R1.4. Any non-critical Cyber Assetwithin a defined ElectronicSecurity Perimeter shall beidentified and protected pursuantto the requirements of StandardCIP-005.

MED

N/A N/A N/A One or more noncriticalCyber Asset within adefined ElectronicSecurity Perimeter is notidentified and OR is notprotected pursuant to therequirements of StandardCIP-005.

CIPGuideline 1

VSLGuideline2(b)

CIP-005-1 R1.5. Cyber Assets used in the accesscontrol and monitoring of theElectronic Security Perimeter(s)shall be afforded the protectivemeasures as a specified inStandard CIP-003, Standard CIP-004 Requirement R3, StandardCIP-005 Requirements R2 andR3, Standard CIP-006Requirements R2 and R3,Standard CIP-007, RequirementsR1 and R3 through R9, StandardCIP-008, and Standard CIP-009.

MED

N/A N/A N/A A Cyber Asset used inthe access control andmonitoring of theElectronic SecurityPerimeter(s) is notprovided in one (1) ormore of the protectivemeasures as specified inStandard CIP-003,Standard CIP-004Requirement R3,Standard CIP-005Requirements R2 andR3, Standard CIP- 006Requirements R2 andR3, Standard CIP-007,Requirements R1 and R3through R9, StandardCIP-008, and StandardCIP- 009.

CIPGuideline 1



7



CIP-005-1 R1.6. The Responsible Entity shallmaintain documentation ofElectronic Security Perimeter(s),all interconnected Critical andnon-critical Cyber Assets withinthe Electronic SecurityPerimeter(s), all electronic accesspoints to the Electronic SecurityPerimeter(s) and the CyberAssets deployed for the accesscontrol and monitoring of theseaccess points.

LOW

N/A N/A N/A The Responsible Entitydid not maintaindocumentation of one ormore of the following:Electronic SecurityPerimeter(s),interconnected Criticaland noncritical CyberAssets within theElectronic SecurityPerimeter(s), electronicaccess points to theElectronic SecurityPerimeter(s) and CyberAssets deployed for theaccess control andmonitoring of theseaccess points.

CIPGuideline 1

CIP-005-1 R2. Electronic Access Controls — TheResponsible Entity shallimplement and document theorganizational processes andtechnical and proceduralmechanisms for control ofelectronic access at all electronicaccess points to the ElectronicSecurity Perimeter(s).

MED

N/A N/A N/A The Responsible Entitydid not implement or didnot document theorganizational processesand technical andprocedural mechanismsfor control of electronicaccess at all electronicaccess points to theElectronic SecurityPerimeter(s).

CIPGuideline 2

VSLGuideline2(b)



8



CIP-005-1 R2.2. At all access points to theElectronic Security Perimeter(s),the Responsible Entity shallenable only ports and servicesrequired for operations and formonitoring Cyber Assets withinthe Electronic Security Perimeter,and shall document, individually orby specified grouping, theconfiguration of those ports andservices.

MED

N/A N/A N/A At one or more accesspoints to the ElectronicSecurity Perimeter(s), theResponsible Entityenabled ports andservices not required foroperations and formonitoring Cyber Assetswithin the ElectronicSecurity Perimeter, or didnot document,individually or byspecified grouping, theconfiguration of thoseports and services.

CIPGuideline 1

VSLGuideline2(b)

CIP-005-1 R2.5. The required documentation shall,at least, identify and describe:

LOW

N/A N/A N/A The requireddocumentation for R2 didnot include one or moreofthe elements describedin R2.5.1 through R2.5.4

CIPGuideline 1

CIPGuideline 2

CIP-005-1 R3. Monitoring Electronic Access —The Responsible Entity shallimplement and document anelectronic or manual process(es)for monitoring and logging accessat access points to the ElectronicSecurity Perimeter(s) twenty-fourhours a day, seven days a week.

MED

N/A N/A N/A The Responsible Entitydid not implement or didnot document electronicor manual processesmonitoring and loggingaccess points.

CIPGuideline 1

CIPGuideline 2

VSLGuideline2(b)



9



CIP-005-1 R3.1. For dial-up accessible CriticalCyber Assets that use non-routable protocols, theResponsible Entity shallimplement and documentmonitoring process(es) at eachaccess point to the dial-up device,where technically feasible.

MED

N/A N/A N/A Where technicallyfeasible, the ResponsibleEntity did not implementor did not documentelectronic or manualprocesses for monitoringat one or more accesspoint to dial-up devices.

CIPGuideline 1

CIPGuideline 2

VSLGuideline2(b)



10



CIP-005-1 R3.2. Where technically feasible, thesecurity monitoring process(es)shall detect and alert for attemptsat or actual unauthorizedaccesses. These alerts shallprovide for appropriate notificationto designated responsepersonnel. Where alerting is nottechnically feasible, theResponsible Entity shall review orotherwise assess access logs forattempts at or actual unauthorizedaccesses at least every ninetycalendar days.

MED

N/A N/A N/A Where technicallyfeasible, the ResponsibleEntity did not implementsecurity monitoringprocess(es) to detect andalert for attempts at oractual unauthorizedaccesses.

OR

the above alerts do notprovide for appropriatenotification to designatedresponse personnel.

OR

Where alerting is nottechnically feasible, theResponsible Entity didnot review or otherwiseassess access logs forattempts at or actualunauthorized accesses atleast every ninetycalendar days

CIPGuideline 1



11



CIP-005-1 R4. Cyber Vulnerability Assessment— The Responsible Entity shallperform a cyber vulnerabilityassessment of the electronicaccess points to the ElectronicSecurity Perimeter(s) at leastannually. The vulnerabilityassessment shall include, at aminimum, the following:

MED

N/A N/A N/A The Responsible Entitydid not perform aVulnerability Assessmentat least annually for oneor more of theaccesspoints to the ElectronicSecurity Perimeter(s).

OR

The vulnerabilityassessment did notinclude one (1) or moreof the subrequirements R4.1, R4.2, R4.3, R4.4,R4.5.

CIPGuideline 1

CIP-005-1 R5.2. The Responsible Entity shallupdate the documentation toreflect the modification of thenetwork or controls within ninetycalendar days of the change.

LOW

N/A N/A N/A The Responsible Entitydid not updatedocumentation to reflecta modification of thenetwork or controls withinninety calendar days ofthe change.

CIPGuideline 1

CIP-006-1 R1.5. Procedures for reviewing accessauthorization requests andrevocation of accessauthorization, in accordance withCIP-004 Requirement R4.

MED

N/A N/A N/A The Responsible Entity'sphysical security plandoes not includeprocedures for reviewingaccess authorizationrequests or does notincluderevocation ofaccess authorization, inaccordance with CIP-004Requirement R4.

CIPGuideline 1

VSLGuideline2(b)



12



CIP-006-1 R1.7. Process for updating the physicalsecurity plan within ninetycalendar days of any physicalsecurity system redesign orreconfiguration, including, but notlimited to, addition or removal ofaccess points through the physicalsecurity perimeter, physicalaccess controls, monitoringcontrols, or logging controls.

LOW

N/A N/A N/A The Responsible Entity'sphysical security plandoes not include aprocess for updating thephysical security planwithin ninety calendardays of any physicalsecurity system redesignor reconfiguration.

OR

The plan was notupdated within 90calendar days of anyphysical security systemredesign orreconfiguration.

VSLGuideline2(b)

CIP-006-1 R1.8. Cyber Assets used in the accesscontrol and monitoring of thePhysical Security Perimeter(s)shall be afforded the protectivemeasures specified in StandardCIP-003, Standard CIP-004Requirement R3, Standard CIP-005 Requirements R2 and R3,Standard CIP-006 RequirementR2 and R3, Standard CIP-007,Standard CIP-008 and StandardCIP-009.

LOW

N/A N/A N/A A Cyber Asset used inthe access control andmonitoring of thePhysical SecurityPerimeter(s) is notafforded one (1) or moreof the protectivemeasures specified inStandard CIP-003,Standard CIP-004Requirement R3,Standard CIP-005Requirements R2 andR3, Standard CIP- 006Requirements R2 andR3, Standard CIP-007,Standard CIP-008, andStandard CIP-009.

CIPGuideline 1



13



CIP-006-1

.

R2. Physical Access Controls — TheResponsible Entity shall documentand implement the operationaland procedural controls tomanage physical access at allaccess points to the PhysicalSecurity Perimeter(s) twenty-fourhours a day, seven days a week.The Responsible Entity shallimplement one or more of thefollowing physical accessmethods:

MED

N/A N/A N/A - The Responsible Entityhas not documented, orhas not implemented theoperational andprocedural controls tomanage physical accessat all access points to thePhysical SecurityPerimeter(s) twenty-fourhours a day, seven daysa week using at least oneof the access controlmethods identified inR2.1, R2.2, R2.3, orR2.4.

CIPGuideline 2

VSLGuideline2(b)

CIP-006-1 R3. Monitoring Physical Access —The Responsible Entity shalldocument and implement thetechnical and procedural controlsfor monitoring physical access atall access points to the PhysicalSecurity Perimeter(s) twenty-fourhours a day, seven days a week.Unauthorized access attemptsshall be reviewed immediately andhandled in accordance with theprocedures specified inRequirement CIP-008. One ormore of the following monitoringmethods shall be used:

MED

N/A N/A N/A The Responsible Entityhas not documented orhas not implementedthe technical andprocedural controls formonitoring physicalaccess at all accesspoints to the PhysicalSecurity Perimeter(s)twentyfour hours a day,seven days a week usingat least one of themonitoring methodsidentified inRequirements R3.1 orR3.2. OR One or moreunauthorized accessattempts have not beenreviewed immediatelyand handled inaccordance with theprocedures specified inCIP-008.

CIPGuideline 2

VSLGuideline2(b)



14



CIP-006-1 R4. Logging Physical Access —Logging shall record sufficientinformation to uniquely identifyindividuals and the time of accesstwenty-four hours a day, sevendays a week. The ResponsibleEntity shall implement anddocument the technical andprocedural mechanisms forlogging physical entry at allaccess points to the PhysicalSecurity Perimeter(s) using one ormore of the following loggingmethods or their equivalent:

LOW

N/A N/A N/A The Responsible Entityhas not implemented orhas not documentedthe technical andprocedural mechanismsfor logging physical entryat all access points to thePhysical SecurityPerimeter(s) using one ormore of the loggingmethods identified inRequirements R4.1,R4.2, or R4.3 or has notrecorded sufficientinformation to uniquelyidentify individuals andthe time of accesstwenty-four hours a day,seven days a week.

CIPGuideline 2

VSLGuideline2(b)

CIP-006-1 R6. Maintenance and Testing — TheResponsible Entity shallimplement maintenance andtesting program to ensure that allphysical security systems underRequirements R2, R3, and R4function properly. The programmust include, at a minimum, thefollowing:

MED

N/A - N/A N/A The Responsible Entityhas not implemented amaintenance and testingprogram to ensure thatall physical securitysystems underRequirements R2, R3,and R4 function properly.

ORThe implementedprogram does not includeone or more of therequirements; R6.1,R6.2, and R6.3.

CIPGuideline 1



15



CIP-007-1 R1. Test Procedures — TheResponsible Entity shall ensurethat new Cyber Assets andsignificant changes to existingCyber Assets within the ElectronicSecurity Perimeter do notadversely affect existing cybersecurity controls. For purposes ofStandard CIP- 007, a significantchange shall, at a minimum,include implementation of securitypatches, cumulative servicepacks, vendor releases, andversion upgrades of operatingsystems, applications, databaseplatforms, or other third-partysoftware or firmware.

MED

N/A N/A N/A

The Responsible Entitydid not ensure theprevention of adverseaffects described in R1,by not including therequired minimumsignificant changes,

OR

The Responsible Entitydid not address one ormore of the following:R1.1, R1.2, R1.3.

CIPGuideline 1

VSLGuideline2(b)

CIP-007-1 R2. Ports and Services — TheResponsible Entity shall establishand document a process toensure that only those ports andservices required for normal andemergency operations areenabled.

MED

N/A N/A N/A The Responsible Entitydid not establish or didnot document a processto ensure that only thoseports and servicesrequired for normal andemergency operationsare enabled.

CIPGuideline 2

VSLGuideline2(b)

CIP-007-1 R2.1. The Responsible Entity shallenable only those ports andservices required for normal andemergency operations.

MED

N/A N/A N/A The Responsible Entityenabled one or moreports or services notrequired for normal andemergency operations onCyber Assets inside theElectronicSecurityPerimeter(s).

CIPGuideline 1

VSLGuideline2(b)



16



CIP-007-1 R2.2. The Responsible Entity shalldisable other ports and services,including those used for testingpurposes, prior to production useof all Cyber Assets inside theElectronic Security Perimeter(s).

MED

N/A N/A N/A The Responsible Entitydid not disable one ormore other ports orservices, including thoseused for testingpurposes, prior toproduction use for CyberAssets inside theElectronic SecurityPerimeter(s).

CIPGuideline 1

VSLGuideline2(b)

CIP-007-1

.

R3. Security Patch Management —The Responsible Entity, eitherseparately or as a component ofthe documented configurationmanagement process specified inCIP-003 Requirement R6, shallestablish and document a securitypatch management program fortracking, evaluating, testing, andinstalling applicable cyber securitysoftware patches for all CyberAssets within the ElectronicSecurity Perimeter(s).

LOW

N/A N/A N/AThe Responsible Entitydid not establish or didnot document, eitherseparately or as acomponent of thedocumentedconfigurationmanagement processspecified in CIP-003Requirement R6, asecurity patchmanagement program fortracking, evaluating,testing, and installingapplicable cyber securitysoftware patches for allCyber Assets within theElectronic SecurityPerimeter(s)

CIPGuideline 2

VSLGuideline2(b)



17



CIP-007-1 R3.1. The Responsible Entity shalldocument the assessment ofsecurity patches and securityupgrades for applicability withinthirty calendar days of availabilityof the patches or upgrades.

LOW

N/A N/A N/A The Responsible Entitydid not document theassessment of securitypatches and securityupgrades for applicabilityas required inRequirement R3 within30 calendar days afterthe availability of thepatches and upgrades.

VSLGuideline 1

CIP-007-1 R4. Malicious Software Prevention —The Responsible Entity shall useanti-virus software and othermalicious software (“malware”)prevention tools, where technicallyfeasible, to detect, prevent, deter,and mitigate the introduction,exposure, and propagation ofmalware on all Cyber Assetswithin the Electronic SecurityPerimeter(s).

MED

N/A N/A N/A The Responsible Entity,where technicallyfeasible, did not use anti-virus software or othermalicious software(“malware”) preventiontools, , on one or moreCyber Assets within theElectronic SecurityPerimeter(s).

CIPGuideline 1

VSLGuideline2(b)

CIP-007-1 R4.2. The Responsible Entity shalldocument and implement aprocess for the update of anti-virus and malware prevention“signatures.” The process mustaddress testing and installing thesignatures.

MED

N/A N/A N/A The Responsible Entitydid not documentor didnot implement aprocess includingaddressing testing andinstalling the signaturesfor the update of anti-virus and malwareprevention “signatures.”

CIPGuideline 2

VSLGuideline2(b)



18



CIP-007-1 R5 Account Management — TheResponsible Entity shall establish,implement, and documenttechnical and procedural controlsthat enforce access authenticationof, and accountability for, all useractivity, and that minimize the riskof unauthorized system access.

N/A N/A N/A The Responsible Entitydid not document or didnot implement technicaland procedural controlsthat enforce accessauthentication of, andaccountability for, all useractivity.

CIPGuideline 2

VSLGuideline2(b)

CIP-007-1 R5.1.1. The Responsible Entity shallensure that user accounts areimplemented as approved bydesignated personnel. Refer toStandard CIP-003 RequirementR5.

LOW

N/A N/A N/A One or more useraccounts implemented bythe Responsible Entitywere not implemented asapproved by designatedpersonnel.

CIPGuideline 1VSLGuideline2(b)

CIP-007-1 R5.2.3. Where such accounts must beshared, the Responsible Entityshall have a policy for managingthe use of such accounts thatlimits access to only those withauthorization, an audit trail of theaccount use (automated ormanual), and steps for securingthe account in the event ofpersonnel changes (for example,change in assignment ortermination).

MED

N/A N/A N/A Where such accountsmust be shared, theResponsible Entity hasnot implemented (one ormore components of) apolicy for managing theuse of such accounts thatlimits access to onlythose with authorization,an audit trail of theaccount use (automatedor manual), and steps forsecuring the account inthe event of personnelchanges (for example,change in assignment ortermination).

CIPGuideline 1



19



CIP-007-1 R5.3. At a minimum, the ResponsibleEntity shall require and usepasswords, subject to thefollowing, as technically feasible:

LOW

N/A N/A N/A The Responsible Entitydoes not requirepasswords subject toR5.3.1, R5.3.2., R5.3.3 .

or

does not usepasswords subject toR5.3.1, R5.3.2., R5.3.3.

CIPGuideline 1

VSLGuideline2(b)

CIP-007-1 R6. Security Status Monitoring — TheResponsible Entity shall ensurethat all Cyber Assets within theElectronic Security Perimeter, astechnically feasible, implementautomated tools or organizationalprocess controls to monitorsystem events that are related tocyber security.

LOW

N/A N/A N/A The Responsible Entityas technically feasible,did not implementautomated tools ororganizational processcontrols, , to monitorsystem events that arerelated to cyber securityon one % or more ofCyber Assets inside theElectronic SecurityPerimeter(s).

CIPGuideline 1

CIP-007-1 R6.1. The Responsible Entity shallimplement and document theorganizational processes andtechnical and proceduralmechanisms for monitoring forsecurity events on all CyberAssets within the ElectronicSecurity Perimeter.

MED

N/A N/A N/A The Responsible Entitydid not implement ordid not document theorganizational processesand technical andprocedural mechanismsfor monitoring for securityevents on all CyberAssets within theElectronic SecurityPerimeter.

CIPGuideline 2

VSLGuideline2(b)

CIP-007-1 R6.4. The Responsible Entity shallretain all logs specified inRequirement R6 for ninetycalendar days.

LOW

N/A N/A N/A The Responsible Entitydid not retain one ormore of the logsspecified in RequirementR6 for at least 90calendar days.

CIPGuideline 1

VSLGuideline2(b)



20



CIP-007-1 R7. Disposal or Redeployment — TheResponsible Entity shall establishformal methods, processes, andprocedures for disposal orredeployment of Cyber Assetswithin the Electronic SecurityPerimeter(s) as identified anddocumented in Standard CIP-005.

LOW

N/A N/A The Responsible Entityestablished formalmethods, processes, andprocedures forredeployment of CyberAssets within theElectronic SecurityPerimeter(s) as identifiedand documented inStandard CIP-005 butdid not addressredeployment asspecified in R7.2.

The Responsible Entitydid not establish formalmethods, processes, andprocedures for disposalor redeployment of CyberAssets within theElectronic SecurityPerimeter(s) as identifiedand documented inStandard CIP-005.

OR

The Responsible Entityestablished formalmethods, processes, andprocedures forredeployment of CyberAssets within theElectronic SecurityPerimeter(s) as identifiedand documented inStandard CIP-005 but didnot address disposal asspecified in R7.1..

OR

did not maintain recordspertaining to disposal orredeployment asspecified in R7.3 .

VSLGuideline2(b)



21



CIP-007-1 R8. Cyber Vulnerability Assessment— The Responsible Entity shallperform a cyber vulnerabilityassessment of all Cyber Assetswithin the Electronic SecurityPerimeter at least annually. Thevulnerability assessment shallinclude, at a minimum, thefollowing:

LOW

N/A N/A N/A The Responsible Entitydid not perform aVulnerability Assessmenton one or more CyberAssets within theElectronic SecurityPerimeter at leastannually.

OR

The vulnerabilityassessment did notinclude one (1) or moreof the subrequirements8.1, 8.2, 8.3, 8.4.

CIPGuideline 1

CIP-008-1 R1. Cyber Security Incident ResponsePlan — The Responsible Entityshall develop and maintain aCyber Security Incident responseplan. The Cyber Security IncidentResponse plan shall address, at aminimum, the following:

LOW

N/A N/A The Responsible Entityhas developed a CyberSecurity Incidentresponse plan thataddresses all of thecomponents required byR1.1 through R1.6 buthas not maintained theplan in accordance withR1.4 or R1.5.

The Responsible Entityhas not developed aCyber Security Incidentresponse plan thataddresses allcomponents of the sub-requirements R1.1through R1.6.

VSLGuideline2(b)

CIP-008-1 R2. Cyber Security IncidentDocumentation — TheResponsible Entity shall keeprelevant documentation related toCyber Security Incidentsreportable per Requirement R1.1for three calendar years.

LOW

N/A N/A N/A The Responsible Entityhas not kept relevantdocumentation related toCyber Security Incidentsreportable perRequirement R1.1 for atleast three calendaryears.

VSLGuideline2(b)



22



CIP-009-1 R1. Recovery Plans — TheResponsible Entity shall createand annually review recoveryplan(s) for Critical Cyber Assets.The recovery plan(s) shalladdress at a minimum thefollowing:

MED

N/A N/A N/A The Responsible Entityhas not created or hasnot annually reviewedtheir recovery plan(s) forCritical Cyber Assets

OR

has created a plan butdid not address one ormore of the requirementsCIP- 009-1 R1.1 andR1.2.

VSLGuideline2(b)

CIP-009-1 R3. Change Control — Recoveryplan(s) shall be updated to reflectany changes or lessons learnedas a result of an exercise or therecovery from an actual incident.Updates shall be communicatedto personnel responsible for theactivation and implementation ofthe recovery plan(s) within ninetycalendar days of the change.

LOW

N/A N/A . N/A The Responsible Entity'srecovery plan(s) have notbeen updated to reflectany changes or lessonslearned as a result of anexercise or the recoveryfrom an actual incident.

ORThe Responsible Entity'srecovery plan(s) havebeen updated to reflectany changes or lessonslearned as a result of anexercise or the recoveryfrom an actual incidentbut the updates were notcommunicated topersonnel responsible forthe activation andimplementation of therecovery plan(s) within90 calendar days of thechange.

VSLGuideline 1


Document Content(s)

RM06-22-008.DOC.......................................................1-35


UNITED STATES OF AMERICA FEDERAL ENERGY REGULATORY … · 2010. 6. 28. · Docket No. RM06 -22 -008...

Documents

Transcript of UNITED STATES OF AMERICA FEDERAL ENERGY REGULATORY … · 2010. 6. 28. · Docket No. RM06 -22 -008...