agenda standards committee conference call highlights and minutes/sc … · 1. appoint candidates 1...

Agenda Standards Committee Conference Call October 19, 2016 | 1:00 p.m. to 4:00 p.m. Eastern Dial-in: 1-866-740-1260 | Access Code: 5153394 | Security/Passcode: 101916 Click here for: Webinar Access Introduction and Chair’s Remarks NERC Antitrust Compliance Guidelines and Public Announcement* Agenda Items

1. Review Agenda ― (Approve) (B. Murphy) (1 minute)

2. Consent Agenda ― (Approve) (B. Murphy) (1 minute)

a. September 14, 2016, Standards Committee Meeting Minutes* ― (Approve)

b. Project 2013-03 Geomagnetic Disturbance Mitigation Additional Standards Drafting Team Nomination Solicitation* ― (Authorize)

c. Project 2016-02 Standards Drafting Team Chair* ― (Appoint) 3. Upcoming Standards Projects or Issues― (Update)

a. Three-Month Outlook* (S. Noess; B. Murphy) (10 minutes)

4. Projects Under Development ― (Review)

a. Project Tracking Spreadsheet (B. Hampton; S. Noess) (15 minutes)

b. Projected Posting Schedule (S. Noess) (5 minutes)

5. Project 2016-03 Standards Authorization Request Cyber Security Supply Chain Management* ― (Authorize) (M. Olson) (10 minutes)

6. Project 2016-02 Modifications to CIP Standards – TCA* ― (Authorize) (S. Cavote) (10 minutes)

7. Request for Interpretation of PRC-002-2 Requirement R5 for Hydro Quebec* ― (Reject) (S. Noess) (10 minutes)

8. Request for Interpretation of PRC-002-2 Requirement R10 for Hydro Quebec* ― (Reject) (S. Noess) (10 minutes)

9. Drafting Team Reference Manual* ― (Approve) (P. Heidrich) (5 minutes)

https://cc.readytalk.com/r/i42q5moyuth1&eom

http://www.nerc.com/comm/SC/_layouts/xlviewer.aspx?id=/comm/SC/Project%20Management%20and%20Oversight%20Subcommittee%20DL/Project%20Tracking%20Spreadsheet.xlsx&Source=http%3A%2F%2Fwww%2Eqa%2Enerc%2Ecom%2Fcomm%2FSC%2FProject%2520Management%2520and%2520Oversi

http://www.nerc.com/pa/Stand/Documents/Projected_Posting_Schedule.pdf

Agenda - Standards Committee Meeting | October 19, 2016 2

10. NERC Guidelines and Technical Basis Section of a Standard* ― (Information) (S. Noess) (5 minutes)

11. Subcommittee Reports and Updates

a. Project Management and Oversight Subcommittee ― (Update) (B. Hampton) (10 minutes)

b. Process Subcommittee* ― (Update) (P. Heidrich) (5 minutes)

c. Functional Model Advisory Group* ― (Endorse) (P. Heidrich) (5 minutes)

12. Legal Update

a. Upcoming Standards Filings* ― (Review) (L. Perotti) (5 minutes)

13. Informational Items ― (Enclosed)

a. Directive to Change Violation Risk Factors (VRFs) in IRO-018-1 and TOP-001-1*

b. Standards Committee Expectations*

c. 2016 Meeting Dates and Locations*

d. 2016 Standards Committee Roster*

e. Highlights of Parliamentary Procedure*

14. Adjourn

*Background materials included.

Antitrust Compliance Guidelines I. General It is NERC’s policy and practice to obey the antitrust laws and to avoid all conduct that unreasonably restrains competition. This policy requires the avoidance of any conduct that violates, or that might appear to violate, the antitrust laws. Among other things, the antitrust laws forbid any agreement between or among competitors regarding prices, availability of service, product design, terms of sale, division of markets, allocation of customers or any other activity that unreasonably restrains competition. It is the responsibility of every NERC participant and employee who may in any way affect NERC’s compliance with the antitrust laws to carry out this commitment. Antitrust laws are complex and subject to court interpretation that can vary over time and from one court to another. The purpose of these guidelines is to alert NERC participants and employees to potential antitrust problems and to set forth policies to be followed with respect to activities that may involve antitrust considerations. In some instances, the NERC policy contained in these guidelines is stricter than the applicable antitrust laws. Any NERC participant or employee who is uncertain about the legal ramifications of a particular course of conduct or who has doubts or concerns about whether NERC’s antitrust compliance policy is implicated in any situation should consult NERC’s General Counsel immediately. II. Prohibited Activities Participants in NERC activities (including those of its committees and subgroups) should refrain from the following when acting in their capacity as participants in NERC activities (e.g., at NERC meetings, conference calls and in informal discussions):

• Discussions involving pricing information, especially margin (profit) and internal cost information and participants’ expectations as to their future prices or internal costs.

• Discussions of a participant’s marketing strategies.

• Discussions regarding how customers and geographical areas are to be divided among competitors.

• Discussions concerning the exclusion of competitors from markets.

• Discussions concerning boycotting or group refusals to deal with competitors, vendors or suppliers.

NERC Antitrust Compliance Guidelines 2

• Any other matters that do not clearly fall within these guidelines should be reviewed with NERC’s General Counsel before being discussed.

III. Activities That Are Permitted From time to time decisions or actions of NERC (including those of its committees and subgroups) may have a negative impact on particular entities and thus in that sense adversely impact competition. Decisions and actions by NERC (including its committees and subgroups) should only be undertaken for the purpose of promoting and maintaining the reliability and adequacy of the bulk power system. If you do not have a legitimate purpose consistent with this objective for discussing a matter, please refrain from discussing the matter during NERC meetings and in other NERC-related communications. You should also ensure that NERC procedures, including those set forth in NERC’s Certificate of Incorporation, Bylaws, and Rules of Procedure are followed in conducting NERC business. In addition, all discussions in NERC meetings and other NERC-related communications should be within the scope of the mandate for or assignment to the particular NERC committee or subgroup, as well as within the scope of the published agenda for the meeting. No decisions should be made nor any actions taken in NERC activities for the purpose of giving an industry participant or group of participants a competitive advantage over other participants. In particular, decisions with respect to setting, revising, or assessing compliance with NERC reliability standards should not be influenced by anti-competitive motivations. Subject to the foregoing restrictions, participants in NERC activities may discuss:

• Reliability matters relating to the bulk power system, including operation and planning matters such as establishing or revising reliability standards, special operating procedures, operating transfer capabilities, and plans for new facilities.

• Matters relating to the impact of reliability standards for the bulk power system on electricity markets, and the impact of electricity market operations on the reliability of the bulk power system.

• Proposed filings or other communications with state or federal regulatory authorities or other governmental entities.

Matters relating to the internal governance, management and operation of NERC, such as nominations for vacant committee positions, budgeting and assessments, and employment matters; and procedural matters such as planning and scheduling meetings.

Public Announcements

Conference call: Participants are reminded that this conference call is public. The access number was posted on the NERC website and widely distributed. Speakers on the call should keep in mind that the listening audience may include members of the press and representatives of various governmental authorities, in addition to the expected participation by industry stakeholders.

Meeting Minutes Standards Committee Meeting September 14, 2016 | 8:00 a.m. to 2:00 p.m. Pacific Brian Murphy, chair, called to order a duly noticed meeting of the Standards Committee (SC or the Committee) on September 14, 2016, at 8:00 a.m. Pacific, and a quorum was declared present. The SC member attendance and proxy sheet is attached hereto as Attachment 1. NERC Antitrust Compliance Guidelines and Public Announcement Committee Secretary Jordan Mallory called attention to the NERC Antitrust Compliance Guidelines and the public meeting notice. Any questions will be directed to NERC’s General Counsel, Charles Berardesco. Introduction and Chair’s Remarks B. Murphy welcomed the Committee and thanked PG&E for hosting the SC meeting at their facilities. B. Murphy welcomed the committee’s newest member Alexander Vedvik of Public Service Commission of Wisconsin and also welcomed NERC Board of Trustees (Board) member David Goulding. Steve Noess announced that Ryan Stewart and Stephen Crutchfield have transferred to another department and named the following staff changes to the Standards department, which is effective Friday, September 16, 2016:

• Soo Jin Kim, Manager of Standards Development

• Mat Bunch, Standards Developer D. Goulding congratulated the SC on how far the committee has come. D. Goulding spoke about the importance on understanding culture and that standards are a vehicle for moving people into a culture that promotes reliability. D. Goulding also expressed how training the next generation is important, and having the right culture prepares one to deal with anything on the system. Review Agenda The Committee approved the agenda by unanimous consent.

Consent Agenda The Committee approved the July 20, 2016, Standards Committee Meeting Minutes by unanimous consent.

Agenda Item 2a Standards Committee October 19, 2016

Minutes - Standards Committee Meeting | September 14, 2016 2

Upcoming Standards Projects or Issues Three-Month Outlook S. Noess reviewed the Three-Month Outlook. Projects Under Development Project Tracking Spreadsheet B. Hampton reviewed the Project Tracking Spreadsheet and informed the Committee that the NERC standards developers will be working with the respective Project Management and Oversight Subcommittee (PMOS) representative to update the annual project schedules accordingly. B. Hampton noted that COM-001 will be removed from the spreadsheet due to passing final ballot. Guy Zito thanked PMOS for taking the time to update the project tracking spreadsheet to make reviewing the spreadsheet easier for the Committee.

Projected Posting Schedule S. Noess reviewed the Projected Posting Schedule. Project 2016-03 Cyber Security Supply Chain Management B. Hampton made the motion to accept the action item as written; Frank McElvain seconded. The motion was as follows:

Appoint a drafting team for Project 2016-03 Cyber Security Supply Chain Management (Supply Chain standard drafting team (SDT)) to draft the Standards Authorization Request and new or revised standard(s), as follows:

1. Appoint candidates 1 through 11 on the attached recommendation to form the SDT

2. Appoint candidate 10 and candidate 8 on the attached recommendation to serve as chair and vice-chair, respectively

B. Hampton spoke briefly in support of the motion, noting the recommended SDT covers the Regions and appropriate functional entities needed for this project. Chris Gowder made a friendly amendment to add Candidate Number Eight and expressed that there are many large entities represented and the addition of this small entity would provide value to the team. B. Hampton accepted the friendly amendment; however, F. McElvain rejected the friendly amendment. Barry Lawson, then moved to amend the motion; C. Gowder seconded. The amended was as follows: Add Candidate Number Eight to the Supply Chain SDT.

Discussion was held around the lack of biography information regarding Candidate Number Eight provided. B. Murphy brought the amended motion to a vote.

http://www.nerc.com/comm/SC/_layouts/xlviewer.aspx?id=/comm/SC/Project%20Management%20and%20Oversight%20Subcommittee%20DL/Project%20Tracking%20Spreadsheet.xlsx&Source=http%3A%2F%2Fwww%2Eqa%2Enerc%2Ecom%2Fcomm%2FSC%2FProject%2520Management%2520and%2520Oversi

http://www.nerc.com/pa/Stand/Documents/Projected_Posting_Schedule.pdf


The Committee rejected the amendment with Robert Blohm abstaining and the following members voting no: S. Bodkin, L. Lee, B. Li, S. Miller, C. Norrish, W. Sipperly, B. Hampton, F. McElvain, D. Kiguel, R. Blohm, M. Harris, S. Rueckert, G. Zito, and Alexander Vedvik.

C. Yeung noted that Candidate Number four should have Southwest Power Pool (SPP) as a part of his/her Region. B. Murphy brought the original motion to a vote.

The Committee approved the motion to appoint the following SDT members with no objections or abstentions:

• Christina Alston, Georgia Transmission Corp.

• James W. Chuber, Duke Energy

• Norm Dang, IESO of Ontario

• Chris Evans, Southwest Power Pool

• Brian Gatus, Southern California Edison Company

• David Bryan Gayle, Dominion Resources Services, Inc.

• Thruston J. Griffin, CPS Energy

• JoAnn Murphy, PJM Interconnection, L.L.C.

• Skip Peeples, Salt River Project

• Corey Sellers, Southern Company

• Jason Witt, East Kentucky Power Cooperative

Project 2015-10 Single Points of Failure S. Rueckert made the motion to accept the action item as written; G. Zito seconded. The motion was as follows:

Appoint a standard drafting team (SDT) for Project 2015-10 Single Points of Failure as follows:

1. Appoint candidates 1 through 10 on the attached recommendation to form the SDT; and

2. Appoint candidate 9 and candidate 2 on the attached recommendation to serve as chair and vice chair, respectively.


S. Rueckert spoke briefly in support of the motion, noting the recommended SDT are all qualified for this project. B. Murphy brought the motion to a vote.

The Committee approved the motion with no objections or abstentions.

• Jonathan Hayes, SPP

• Delyn Kilpack, Louisville Gas Electric & Kentucky Utilities

• Chris Colson, Western Area Power Administration

• Bill Harm, PJM

• Baj Agrawal, Arizona Public Service Company

• Liqin Jiang, Duke Energy

• Rich Kowalski, ISO New England

• Prabhu Gnanam, ERCOT

• Manuela Dobrescu Dobritoiu, Hydro-Quebec

• Ruth Kloecher, ITC Holdings

Project 2016-04 Modifications to PRC-025 B. Li made the motion to accept the action item as written; B. Hampton seconded. The motion was as follows:

Authorize posting the Standards Authorization Request (SAR) for a 30-day formal comment period and authorize solicitation of nominations to form a 2016-04 Modifications to Reliability Standard PRC-025-1 SAR drafting team, which will be no less than 20 days.

B. Li spoke briefly in support of the motion. However, questioned the purpose of the North American Generator Forum endorsement. Scott Barfield-McGinnis explained that the endorsement is regarding the content of the SAR. G. Zito mentioned that the SAR supports addressing an issue that has been identified in instances of generators with long lead lines. B. Lawson inquired whether the potential changes could impact obligations under PRC-025 for other entities not affected by the issue G. Zito noted. S. Noess indicated the SAR is addressing a specific issue and does not foresee it impacting beyond those affected by the issue.


B. Murphy brought the motion to a vote.

The Committee approved the motion with no objections or abstentions. 2017-2019 Reliability Standards Development Plan and Grading G. Zito provided an overview of the grading process and explained which standards are currently eligible. S. Noess explained that the standards grading information will be used as a starting point for the Enhanced Periodic Review (EPR) teams. The first standards to move forward in 2016 for the EPR are VAR and PER. A question was asked regarding the attachment located in the Reliability Standards Development Plan (RSDP). It was explained that the RSDP is more of a summary format instead of detailed information, and the attachment contains a link to the more detailed information on the grading project. B. Murphy noted that the group is working on bringing the grading enhancements and recommended changes before the SC for approval. B. Murphy also thanked M. Bunch for all his work on the project and appreciated that he turned the documents into something the group could easily work with. Additional input was provided that the survey created a lot of work for some entities and to be mindful with the types of survey questions posed in the future. The motion was as follows:

Endorse the 2017-2019 RSDP with an additional statement added to the RSDP that the grades provided by the standing review team and industry stakeholders will be a consideration when determining the prioritization of the Enhanced Periodic Reviews.

G. Zito accepted the motion and B. Li seconded. G. Zito briefly spoke in support of the motion. B. Murphy brought the motion to a vote.


Standards Committee Charter Revision D. Kiguel made the motion; McElvain seconded. The motion was as follows:

Approve the Standards Committee (SC) Charter edits to Section 4.


The intent with these updates is to begin to more fully include Mexico in standards activities. The revised charter will be presented to the NERC Board at the same time as a series of corresponding changes to the Rules of Procedure (ROP). D. Kiguel briefly spoke to the motion, noting that it will be good to have Mexican presence at the SC meetings. Concern was raised of possible conflict of the changes with the current ROP, and it was explained that this should not become an issue because of the coordination to present both changes to the NERC Board at the same time, with recommendation that the charter changes will not become effective until the corresponding ROP changes are effective. Additionally, there was discussion questioning why the Canadian and Mexican terms were limited to one year each. It was explained that this term is specified in Appendix 3B to the ROP, Procedures for the Election of Members of the Standards Committee. It was explained that a one-year term was chosen so as to not interfere with the regular annual election of SC members. B. Murphy brought the amended motion to a vote:


Standards Committee Annual Accomplishments B. Li made the motion to accept the action item as written; G. Zito seconded. The motion was as follows: Endorse the following:

1. The Standards Committee Executive Committee (SCEC) using the following metrics and self-evaluation process to assess the SC’s 2016 accomplishments:

• Was a project schedule presented? (task 1) – yes/no

• Did the PMOS and NERC staff work together to present for SC endorsement a prioritization and timing of 2016 EPRs? (task 2) – yes/no

• With the assistance of NERC staff, the leadership of the Operating Committee, Planning Committee, and the Critical Infrastructure Protection Committee, did the SC develop a Standard metric approach for the NERC Board endorsement? (task 3) – yes/no

• Did the NERC staff and the Standards Committee Process Subcommittee consider revisions to the NERC Standard Processes Manual section 11 consistent with the Compliance Guidance Policy Paper? (task 4) – yes/no


• Did the SC conduct a review of its 2016-2018 Strategic Work Plan? (task 5) – yes/no

• Did the SCEC evaluate the need for additional reforms or enhancements to the SC Charter? (task 5) – yes/no; and

2. The SCEC plans on presenting the results of answers to the above questions to the SC in its December 2016 meeting for the SC’s endorsement.

B. Li spoke briefly in support of the motion, noting that the action page does not list those bullets as being in the 2016 strategic plan and suggested that be added. B. Murphy brought the motion to a vote.

The Committee approved the motion with no objections or abstentions. 2017 Standards Committee Meeting Dates and Locations Discussion was held weighing the pros and cons for Option 1 (hold PMOS meeting the morning of and prior to the SC meeting) and Option 2 (same as 2016 schedule). B. Li made the motion to adopt Option 1; L. Lee seconded. B. Li briefly spoke in support of his motion, noting that this will allow more time for the two subcommittees to meet separately and possibly attend the other. B. Li also requested that once the meeting dates are set to provide the Committee members with the information as soon as possible. L. Lee mentioned that she liked Option 1 so SC members have the option to attend the PMOS meetings. Clarity was provided that the March 15, 2017 and September 7, 2017, SC meeting will be held during local time zone based on the meeting location. B. Murphy brought the motion to a vote.

The Committee approved the motion with F. McElvain voting no and there were no abstentions.

Request for Interpretation of CIP-006 for Cleco Corporation S. Noess provided an overview and explained that this Request for Interpretation (RFI) focuses on compliance approaches and that there are different mechanisms to address this concern like pursuing the compliance guidance process endorsed by the NERC Board. F. McElvain moved the motion as written; G. Zito seconded. The action item was as follows: Reject the RFI of CIP-006-6 Requirement R1 submitted by Cleco

Corporation (Cleco).


Discussion was held on whether the RFI was regarding compliance or applicability. B. Murphy brought the motion to a vote.

The Committee approved the motion with no objections and B. Lawson, A. Vedvik and S. Miller abstained.

Request for Interpretation of BAL-001-2 for Orlando Utilities Commission (OUC) C. Gowder made the motion to accept the RFI of BAL-001-2; S. Bodkin seconded. The action item was as follows:

Accept the RFI of BAL-001-2 submitted by OUC.

C. Gowder spoke in support of the motion, noting that the standard needs to be reopened for calculation corrections. S. Noess explained that if the standard needs to be reopened for corrections then an RFI is not the correct avenue, as an RFI cannot change a requirement. Discussion was held regarding the process from when an RFI is submitted to be rejected/accepted and the timeliness of RFI turn around once it is submitted. B. Murphy brought the motion to a vote:

The Committee rejected the motion with the following abstaining: B. Lawson, A. Vedvik, and S. Miller.

S. Rueckert accepted the motion as written; G. Zito seconded. The action item was as follows:

Reject the Request for Interpretation (RFI) of BAL-001-2 submitted by Orlando Utilities Commission (OUC).

S. Bodkin made a friendly amendment to reject the Request for Interpretation (RFI) of BAL-001-2 submitted by OUC including a statement that a SAR may be the appropriate method in addressing the issues proposed in the RFI. S. Rueckert and G. Zito accepted the friendly amendment. Conversation was held concerning the rejection reasoning of the standard being plain on its face and the issue already being addressed in the record, and if this was the correct rationale for rejection.


B. Lawson made a friendly amendment to reject the RFI of BAL-001-2 submitted by OUC, on the basis that the issue presented in the RFI has been addressed in the record, and to include a statement in the rejection that a SAR may be the appropriate method in addressing the issues proposed in the RFI. S. Rueckert and G. Zito accepted the friendly amendment. B. Li calls the question. S. Bodkin withdraws his friendly amendment. A. Vedvik states S. Bodkin’s friendly amendment. S. Rueckert and G. Zito accepted the friendly amendment. B. Murphy brought the motion to a vote:

The Committee approved the motion with F. McElvain, S. Miller, and A. Gallo voting no and there were no abstentions.

Revisions to the NERC Standard Processes Manual Section 6 B. Li made the motion to adopt the action item as written; G. Zito seconded. The motion was as follows:

Endorse the Standards Committee Process Subcommittee’s (SCPS) proposed revisions to Section 6 Process for Conducting Field Tests of the Standard Processes Manual (SPM).

B. Li briefly spoke to the motion. It was noted that additional redlines appeared in the definition of Reliability Standard in section 2.0, and that these changes were proposed by NERC Legal staff to reflect the currently-in-effect ROP definition of Reliability Standard. It was clarified that section 6 is the only section being voted on for the purpose of this motion.

It was noted that there was extensive outreach completed with the technical committees and those committees are assisting from the technical aspect whereas the SC can focus on the process. B. Murphy brought the motion to a vote.

The Committee approved the motion with A. Gallo and S. Miller voting no, and F. McElvain, A. Vedvik, and M. Harris abstaining.

Project 2015-04 Alignment of Terms B. Hampton made the motion to accept the action item as written; F. McElvain seconded. The motion was as follows:


Endorse (1) the SCEC reviewing the Phase II Recommendations of the Alignment of Terms drafting team and the comments of the PMOS liaisons on those recommendations, and (2) after the review, presenting a proposal by the SCEC to the SC on how to proceed with the recommendations by the December 2016 SC meeting.

B. Murphy brought the motion to a vote.


Subcommittee Reports and Updates

Project Management and Oversight Subcommittee B. Hampton provided the PMOS update and explained that there will no longer be an annual calendar moving forward. B. Hampton let the Committee know that each PMOS liaison will be working with the respective NERC Standards Developers to ensure timelines for each project are accurate and up to date. Process Subcommittee P. Heidrich provided the update for SCPS by reviewing the work plan. A couple of highlights are that the group is diligently working on Sections 7 and 11 of the SPM and the SAR submittal form is moving along nicely. The goal is to have these documents submitted for endorsement fourth quarter 2016. Additionally, there were four sets of comments received for the drafting team reference manual, which will require some substantial edits to the document. Functional Model Advisory Group P. Heidrich provided the update for the Functional Model Advisory Group. A 45-day comment period concluded on September 7, 2016 for the Reliability Functional Model and Reliability Functional Model Technical Document and there will be a three day meeting (when and where) scheduled to review and respond to comments. There was discussion around if the SC needs to be more involved with reviewing the comments. It was mentioned that G. Zito and B. Li are involved and happy to cover as SC representatives. In addition, B. Murphy and M. D’Antuono will work closely with G. Zito and B. Li to propose a process for SC review of the Functional Model Advisory Group workproduct. Further discussion was held around the purpose of the Functional Model and that is to provide guidance on process, not technical content.

Legal Update L. Perotti provided an overview on past and upcoming legal filings. No discussion was held.


Informational Items No discussion was had on the informational items.

Adjourn B. Murphy thanked the Committee members and adjourned the meeting at 12:12 p.m. Pacific time.

Attachment I

Segment and Term Representative Organization Proxy Present (Member or

Proxy)

Chair 2016‐17

Brian Murphy Senior Attorney

NextEra Energy, Inc. Yes

Vice‐Chair 2016‐17

Michelle D’Antuono Manager, Energy

Occidental Energy Ventures, LLC

Yes

Segment 1‐2015‐16 Lou Oberski Managing Director, NERC Compliance Policy

Dominion Resources Services, Inc.

Sean Bodkin

Yes

Segment 1‐2016‐17 Laura Lee Manager of ERO Support and Event Analysis, System Operations

Duke Energy Yes

Segment 2‐2015‐16 Charles Yeung Executive Director Interregional Affairs

Southwest Power Pool Yes

Segment 2‐2016‐17 Ben Li Consultant

Independent Electric System Operator

Yes

Segment 3‐2015‐16 John Bussman

Manager, Reliability Compliance Associated Electric Cooperative, Inc.

Yes

Segment 3‐2016‐17 Scott Miller

Manager Regulatory Policy MEAG Power

Yes

Segment 4‐2015‐16 Barry Lawson Associate Director, Power Delivery and Reliability

National Rural Electric Cooperative Association

Yes

Segment 4‐2016‐17 Chris Gowder Regulatory Compliance Specialist

Florida Municipal Power Agency

Yes

Segment 5‐2015‐16 Colt Norrish

Compliance Director PacifiCorp

Yes

Segment 5‐2016‐17 Randy Crissman Vice President – Technical Compliance

New York Power Authority Wayne Sipperly

Yes

Standards Committee Attendance – September 14, 2016

Segment and Term Representative Organization Proxy Present (Member or

Proxy)

Segment 6‐2015‐16 Brenda Hampton Director, NERC& TREAffairs

Energy Future Holdings – Luminant Energy Company LLC

Yes

Segment 6‐2016‐17 Andrew Gallo Director, Reliability Compliance

City of Austin dba Austin Energy

Yes

Segment 7‐2015‐16 Marion Lucas APGI Chief Compliance Officer, President & Director

Alcoa Power Marketing LLC Yes

Segment 7‐2016‐17 Frank McElvain Senior Manager, Consulting

Siemens Power Technologies International

Yes

Segment 8‐2015‐16 David Kiguel Independent Yes

Segment 8‐2016‐17 Robert Blohm, Managing Director

Keen Resources Ltd. Yes

Segment 9‐2015‐16 Mark Harris Electrical Engineer

Public Utilities Commission of Nevada

Yes

Segment 9‐2016‐17 Alexander Vedvik Public Service Commission of Wisconsin

Yes

Segment 10‐2015‐16 Steven Rueckert Director of Standards

Western Electricity Coordinating Council

Yes

Segment 10‐2016‐17 Guy Zito Assistant Vice President of Standards

Northeast Power Coordinating Council

Yes

Standards Committee Attendance – September 14, 2016

Agenda Item 2b Standards Committee October 19, 2016

Project 2013-03 Geomagnetic Disturbance Mitigation Additional Drafting Team

Nominations Actions Authorize posting to solicit nominations for additional standard drafting team (SDT) members to respond to directives from Federal Energy Regulatory Commission (FERC) Order No. 830.

Background On September 22, 2016, FERC issued Order No. 830 approving Reliability Standard TPL-007-1 − Transmission System Planned Performance for Geomagnetic Disturbance Events. In the order, FERC directed NERC to develop certain modifications to the Standard, including:

• Modify the benchmark GMD event definition used for GMD Vulnerability Assessments;

• Make related modifications to requirements pertaining to transformer thermal impact assessments;

• Require collection of GMD-related data, and for NERC to make it publicly available; and

• Require deadlines for Corrective Action Plans (CAPs) and GMD mitigating actions. FERC established a deadline of 18 months from the effective date of Order No. 830 for completing the revisions, which is May 2018. The appointed SDT members of the Project 2013-03 SDT (roster attached) are all well qualified to continue participating in the development of revisions. However, two SDT members, Randy Horton and Ken Fleischer, are no longer with their registered entities, and their situations may not allow them to continue participating fully as SDT members. Additionally, Emanuel Bernabeu is now employed at the same entity as the SDT chair. NERC staff requests authorization to solicit nominations for additional SDT members in order to maintain a diverse and well qualified team.

http://www.nerc.com/filingsorders/us/FERCOrdersRules/E-4.pdf

Standard Drafting Team Roster Project 2013-03 Geomagnetic Disturbance Mitigation

Name Entity

Chair Frank Koza PJM Interconnection

Vice Chair Randy Horton Electric Power Research Institute

Members Donald Atkinson Georgia Transmission Corporation

Emanuel Bernabeu PJM Interconnection

Kenneth Fleischer Fleischer Consultants, LLC

Luis Marti Hydro One Networks

Antti Pulkkinen NASA Goddard Space Flight Center

Qun Qiu American Electric Power

NERC Staff Mark Olson – Senior Standards Developer

North American Electric Reliability Corporation

Agenda Item 2c Standards Committee October 19, 2016

Project 2016-02 Modifications to CIP Standards

Action Appoint Christine Hasha and David Revill as standard drafting team (SDT) co-chairs for the Project 2016-02 Modifications to CIP Standards. Background Due to a recent job change, Chair Margaret Powell has resigned as a member of the SDT effective November 30, 2016. As a result, the current vice chairs have agreed to serve as SDT co-chairs. Neither SDT leadership nor NERC staff see a need to solicit for an additional SDT member(s) at this time.

Three-Month Outlook

Brian Murphy, SC Chair, NextEra Energy Resources, LLCSteven Noess, Director of Standards Development, NERCStandards Committee October 6, 2016

Agenda Item 3aStandards CommitteeOctober 19, 2016

RELIABILITY | ACCOUNTABILITY2

• October Project 2013-03 Geomagnetic Disturbance Mitigation

• November None

• December None

Authorize Nomination Solicitations


• October None

• November None

• December Project 2013-03 Geomagnetic Disturbance Mitigation SAR for Modifications to PRC-025-1 (Project 2016-04)

Authorize Team Appointments


• October Project 2016-03 Cyber Security Supply Chain Management

• November None

• December Project 2013-03 Geomagnetic Disturbance Mitigation

Authorize SAR Postings


• October None

• November None

• December Project 2015-10 Single Points of Failure (TPL-001-4) Project 2015-09 System Operating Limits (FAC-010, FAC-011, FAC-014) Project 2016-02 Modifications to CIP Standards (CIP-003-7(i))

Authorize Initial Postings


• September Order Approving Reliability Standards IRO-018-1 and TOP-010-1 Order No. 830 Approving Reliability Standard TPL-007-1 Notice of Proposed Rulemaking to Approve Reliability Standards BAL-005-1

and FAC-001-3

• October None

FERC Orders and NOPRs

Agenda Item 5 Standards Committee October 19, 2016

Project 2016-03 Cyber Security Supply Chain Management

Standards Authorization Request (SAR) Actions Authorize posting the SAR developed by the Project 2016-03 SAR and standards drafting team (SDT) to meet the directives from Federal Energy Regulatory Commission (FERC) Order No. 829 for 30-day informal comment period.

Background On July 21, 2016, FERC issued Order No. 829 directing NERC to develop a new or modified Reliability Standard that addresses supply chain risk management for industrial control system hardware, software, and computing and networking services associated with Bulk Electric System (BES) operations as follows:

"[The Commission directs] NERC to develop a forward-looking, objective-based Reliability Standard to require each affected entity to develop and implement a plan that includes security controls for supply chain management for industrial control system hardware, software, and services associated with bulk electric system operations. The new or modified Reliability Standard should address the following security objectives, [discussed in detail in the Order]: (1) software integrity and authenticity; (2) vendor remote access; (3) information system planning; and (4) vendor risk management and procurement controls."

The Commission established a filing deadline of one year from the effective date of Order No. 829, which is September 27, 2017. The SDT developed the attached SAR to specifically address the directives in Order No. 829 and is requesting to post for 30-day informal comment period as specified in the Standard Processes Manual. The SDT will review all comments and consider whether changes to the SAR are needed to address the directives in Order No. 829. The SDT anticipates completing this review prior to the Standards Committee's December meeting, at which time the SAR will be provided to the Standards Committee for acceptance.

http://www.nerc.com/FilingsOrders/us/FERCOrdersRules/Order_SupplyChain_20160721_RM15-14.pdf

Standards Authorization Request Form NERC welcomes suggestions to improve the reliability of the bulk power system through improved Reliability Standards. Please use this form to submit your request to propose a new or a revision to a NERC’s Reliability Standard.

Request to propose a new or a revision to a Reliability Standard

Title of Proposed Standard(s): Cyber Security - Supply Chain Controls

Date Submitted: September 28, 2016

SAR Requester Information

Name: Corey Sellers

Organization: Southern Company / Chair, SAR and Standards Drafting Team

Telephone: 205-257-7531 E-mail: [email protected]

SAR Type (Check as many as applicable)

New Standard

Revision to existing Standard

Withdrawal of existing Standard

Urgent Action

SAR Information

Purpose (Describe what the Standard action will achieve in support of Bulk Electric System reliability.):

The goal of this project is to establish forward-looking, objective-driven new or modified Reliability Standard(s) requiring entities to develop and implement a plan that includes security controls for supply chain management for industrial control system hardware, software, and computing and networking services that impact Bulk Electric System (BES) operations. The project will address the Federal Energy Regulatory Commission (FERC) directives contained in Order No. 829. Industry Need (What is the industry problem this request is trying to solve?):

On July 21, 2016, FERC issued Order No. 829 directing NERC to develop a forward-looking, objective-driven new or modified Reliability Standard(s) that addresses supply chain risk management for industrial control system hardware, software, and computing and networking services associated with BES operations. The supply chains for information and communications technology and industrial control systems present risks to the BES by providing potential opportunities for the introduction of

When completed, email this form to:

[email protected]


mailto:[email protected]

Project 2016-03 Cyber Security Supply Chain Management September 28, 2016 2

SAR Information

cybersecurity vulnerabilities. The new or modified Reliability Standard(s) is intended to reduce the risk of a cybersecurity incident affecting the reliable operation of the bulk power system. Brief Description (Provide a paragraph that describes the scope of this Standard action.)

The standards drafting team (SDT) shall develop new or modified Critical Infrastructure Protection (CIP) Standard(s) to require applicable entities to develop and implement a plan that includes security controls for supply chain management of industrial control system hardware, software, and computing and networking services that impact BES operations as described in Order No. 829. The work will include development of an Implementation Plan, Violation Risk Factors, Violation Severity Levels, and supporting documents, within the 12-month deadline established by FERC in Order No. 829. Detailed Description (Provide a description of the proposed project with sufficient details for the standard drafting team to execute the SAR. Also provide a justification for the development or revision of the Standard, including an assessment of the reliability and market interface impacts of implementing or not implementing the Standard action.)

The SDT shall address each of the Order No. 829 directives. The Reliability Standard(s) developed or revised in the project will require applicable entities to develop and implement a plan that addresses, at a minimum, the following four specific objectives as they relate to supply chain cybersecurity of the BES (Order No. 829 at P 45):

1. Software integrity and authenticity;

2. Vendor remote access;

3. Information system planning; and

4. Vendor risk management and procurement controls.

The plan may apply different controls based on the criticality of different assets (Order No. 829 at P 44). Requirements developed by the SDT will be aimed at the protection of aspects of the supply chain that are within the control of responsible entities (Order No. 829 at P 10). The new or modified Reliability Standard will also require periodic reassessment of the applicable entity’s selected controls by the applicable entity's CIP Senior Manager at least every 15 months (Order No. 829 at P 46). In addressing Objective 1 (Software integrity and authenticity), the SDT shall develop requirement(s) for applicable entities to address verification of: (1) the identity of the software publisher for all software and patches that are intended for use on BES Cyber Systems; and (2) the integrity of the software and patches before they are installed in the BES Cyber System. (Order No. 829 at P 48) In addressing Objective 2 (Vendor remote access), the SDT shall develop requirement(s) for applicable entities to address logging and controlling all third-party (i.e., vendor) initiated remote access sessions.


SAR Information

The objective covers both user-initiated and machine-to-machine vendor remote access. Additionally, applicable entities' controls must provide for rapidly disabling remote access sessions to mitigate a security event, if necessary. (Order No. 829 at P 51 and 52) In addressing Objective 3 (Information system planning), the SDT shall develop requirement(s) that address the applicable entities' CIP Senior Manager (or delegate) identification and documentation of risks for consideration by the applicable entity in proposed information system planning. (Order No. 829 at P 56) In addressing Objective 4 (Vendor risk management and procurement controls), the SDT shall develop requirement(s) for applicable entities to address the provision and verification of the following security concepts, at a minimum, in future contracts for industrial control system hardware, software, and computing and networking services associated with BES operations. (Order No. 829 at P 59)

• Vendor security event notification processes;

• Vendor personnel termination notification for employees with access to remote and onsite systems;

• Product/services vulnerability disclosures, such as accounts that are able to bypass authentication or the presence of hardcoded passwords;

• Coordinated incident response activities; and

• Other related aspects of procurement that the SDT determines should be addressed for supply chain cyber security risk management as stated in Order No. 829.

The SDT may, as an alternative, propose an equally efficient and effective means to meet the objectives in Order No. 829.

Reliability Functions

The Standard will Apply to the Following Functions (Check each one that applies.)

Regional Reliability Organization

Conducts the regional activities related to planning and operations, and coordinates activities of Responsible Entities to secure the reliability of the Bulk Electric System within the region and adjacent regions.

Reliability Coordinator Responsible for the real-time operating reliability of its Reliability Coordinator Area in coordination with its neighboring Reliability Coordinator’s wide area view.


Reliability Functions

Balancing Authority Integrates resource plans ahead of time, and maintains load-interchange-resource balance within a Balancing Authority Area and supports Interconnection frequency in real time.

Interchange Authority Ensures communication of interchange transactions for reliability evaluation purposes and coordinates implementation of valid and balanced interchange schedules between Balancing Authority Areas.

Planning Coordinator Assesses the longer-term reliability of its Planning Coordinator Area.

Resource Planner Develops a >one year plan for the resource adequacy of its specific loads within a Planning Coordinator area.

Transmission Planner Develops a >one year plan for the reliability of the interconnected Bulk Electric System within its portion of the Planning Coordinator area.

Transmission Service Provider

Administers the transmission tariff and provides transmission services under applicable transmission service agreements (e.g., the pro forma tariff).

Transmission Owner Owns and maintains transmission facilities.

Transmission Operator

Ensures the real-time operating reliability of the transmission assets within a Transmission Operator Area.

Distribution Provider Delivers electrical energy to the End-use customer.

Generator Owner Owns and maintains generation facilities.

Generator Operator Operates generation unit(s) to provide real and Reactive Power.

Purchasing-Selling Entity

Purchases or sells energy, capacity, and necessary reliability-related services as required.

Market Operator Interface point for reliability functions with commercial functions.

Load-Serving Entity Secures energy and transmission service (and reliability-related services) to serve the End-use Customer.


Reliability and Market Interface Principles

Applicable Reliability Principles (Check all that apply).

1. Interconnected bulk power systems shall be planned and operated in a coordinated manner to perform reliably under normal and abnormal conditions as defined in the NERC Standards.

2. The frequency and voltage of interconnected bulk power systems shall be controlled within defined limits through the balancing of real and Reactive Power supply and demand.

3. Information necessary for the planning and operation of interconnected bulk power systems

shall be made available to those entities responsible for planning and operating the systems reliably.

4. Plans for emergency operation and system restoration of interconnected bulk power systems shall be developed, coordinated, maintained and implemented.

5. Facilities for communication, monitoring and control shall be provided, used and maintained for the reliability of interconnected bulk power systems.

6. Personnel responsible for planning and operating interconnected bulk power systems shall be trained, qualified, and have the responsibility and authority to implement actions.

7. The security of the interconnected bulk power systems shall be assessed, monitored and maintained on a wide area basis.

8. Bulk power systems shall be protected from malicious physical or cyber attacks.

Does the proposed Standard comply with all of the following Market Interface Principles?

Enter

(yes/no)

1. A Reliability Standard shall not give any market participant an unfair competitive advantage.

YES

2. A Reliability Standard shall neither mandate nor prohibit any specific market structure.

YES

3. A Reliability Standard shall not preclude market solutions to achieving compliance with that Standard.

YES

4. A Reliability Standard shall not require the public disclosure of commercially sensitive information. All market participants shall have equal opportunity to access commercially non-sensitive information that is required for compliance with Reliability Standards.

YES

Related Standards

Standard No. Explanation

CIP-002-5 Cyber Security - BES Cyber System Categorization. Specifies categorization of BES Cyber Systems and BES Cyber Assets to support appropriate protection against compromises that could lead to misoperation or instability in the BES.


Related Standards

CIP-003-6 Cyber Security - Security Management Controls. Establishes responsibility and accountability to protect BES Cyber Systems against compromise that could lead to misoperation or instability in BES

CIP-004-6 Cyber Security - Personnel & Training

CIP-005-5 Cyber Security - Electronic Security Perimeter(s)

CIP-007-6 Cyber Security - System Security Management

CIP-010-2 Cyber Security - Configuration Change Management and Vulnerability Assessments

CIP-011-2 Cyber Security - Information Protection

Related SARs

SAR ID Explanation

Regional Variances

Region Explanation

FRCC

MRO

NPCC

RF

SERC

SPP RE

Texas RE

WECC


Project 2016-02 Modifications to CIP Standards Action Authorize the initial posting of (1) proposed Reliability Standard CIP-003-7(i), (2) the proposed revised definition of Transient Cyber Asset (TCA) to be incorporated into the NERC Glossary of Terms Used in NERC Reliability Standards (NERC Glossary), (3) the Violation Risk Factors (VRFs) and Violation Severity Levels (VSLs), and (4) the associated Implementation Plan for a 45-day formal comment period with initial ballots and nonbinding polls during the last 10 days of the comment period. The existing CIP-003-7 ballot pool will be used, with notice to stakeholders that anyone not currently in the pool may join during the first 30 days of the 45-day formal comment period. Background On January 21, 2016, the Federal Energy Regulatory Commission (FERC or Commission) issued Order No. 822, approving revisions to the cybersecurity Critical Infrastructure Protection (CIP) standards and directing NERC to develop certain modifications to requirements in the CIP standards and the definition of Low Impact External Routable Connectivity (LERC). Specifically, the Commission directed the following:

• Develop modifications to the CIP Reliability Standards to provide mandatory protection for transient devices used at Low Impact BES Cyber Systems based on the risk posed to bulk electric system reliability.

• Develop modifications to the CIP Reliability Standards to require responsible entities to implement controls to protect, at a minimum, communication links and sensitive bulk electric system data communicated between bulk electric system Control Centers in a manner that is appropriately tailored to address the risks posed to the bulk electric system by the assets being protected (i.e., high, medium, or low impact).

• Develop a modification to provide the needed clarity, within one year of the effective date of this Final Rule, to the LERC definition consistent with the commentary in the Guidelines and Technical Basis section of CIP-003-6.

On March 9, 2016, the NERC Standards Committee (SC) authorized the Standards Authorization Request (SAR) to be posted for a 30-day informal comment period from March 23 – April 21, 2016. Based on the comments received, the 2016-02 Modifications to CIP standards drafting team (SDT) made minor revisions to the SAR which was posted for an additional 30-day informal comment period June 1-30, 2016. The SC accepted the SAR on July 20, 2016. The SC authorized the initial posting of CIP-003-7 to address LERC on the July 2016 SC call. In response to the directive to provide mandatory protection for transient devices used at Low Impact BES Cyber Systems, the SDT is proposing additional revisions to Attachment 1 of CIP-003-6 to mitigate the risk of malware propagation to the Bulk Electric System (BES) through low impact BES Cyber Systems. Attachment 1 contains and outlines the required sections of a

http://www.nerc.com/FilingsOrders/us/FERCOrdersRules/Order%20Approving%20Revised%20CIP%20Reliability%20Standards.pdf


Responsible Entity’s cyber security plan(s) for its low impact BES Cyber Systems per Requirement R2. Under CIP-003-6, cyber security plan(s) are required to address four subject matter areas: (1) cyber security awareness; (2) physical security controls; (3) electronic access controls; and (4) Cyber Security Incident response. The SDT is proposing to expand Attachment 1 to include a fifth area: “Transient Cyber Asset and Removable Media Malicious Code Mitigation Plan(s)”. Requiring the Responsible Entity to develop and implement these plans will provide higher assurance against the propagation of malware from transient devices. As proposed, Section 5 of Attachment 1 of CIP-003-7(i) mandates that entities have malware protection on TCAs (both entity and vendor-managed) and for Removable Media. The SDT asserts that it is necessary to distinguish between the specific protections for: (i) TCAs managed by the Responsible Entity, (ii) TCAs managed by a party other than the Responsible Entity (e.g. vendors or contractors), and (iii) Removable Media. Additionally, the SDT revised the definition of a TCA to ensure the applicability of security controls and provide additional clarity. Posting approach/Redlines included Both CIP-003-7 (LERC) and CIP-003-7(i) (LERC and TCA) will be posted for comment and ballot concurrently. Thus, stakeholders will be asked to vote twice, once for CIP-003-7 and once for CIP-003-7(i). The primary purpose of posting and balloting concurrently is to ensure that NERC can meet its March 31, 2017 deadline for addressing the LERC directive. There is no deadline for the TCA directive. The language the SC is authorizing for posting is only the TCA language, as the SC previously authorized the initial posting of CIP-003-7 to address LERC on the July 2016 SC call. As stated in the action item, the ballot pool will be opened for stakeholders to opt in, so that those stakeholders that did not have an interest in LERC, but do for TCA, will have the ability to vote on TCA. Without this approach, there would need to be a new ballot pool formed for only CIP-007(i), which would likely be confusing and inefficient. Quality Review The Quality Review (QR) for this posting was performed October 9 - 11, 2016 by Brian Murphy (NextEra Energy Resources), Michelle D’Antuono (Occidental Energy Ventures), Margaret Powell, David Revill, and Christine Hasha (SDT leadership), Howard Gugel, Darrel Richardson, and Monica Bales (NERC Standards staff), Shamai Elstein (NERC Legal staff), and Scott Mix (NERC Compliance staff). The QR team reviewed the documents and provided feedback to the SDT. The SDT considered the feedback, made appropriate modifications to the draft documents, and approved submitting the final documents to the SC for authorization to post.

CIP-003-7(i) - Cyber Security — Security Management Controls

Draft 1 of CIP-003-7(i) July 2016 Page 1 of 53

Standard Development Timeline

This section is maintained by the drafting team during the development of the standard and will be removed when the standard becomes effective. Description of Current Draft This draft of CIP-003-7 is addressing the directive issued by the Federal Energy Regulatory Commission (Commission) in paragraph 73 of Order No. 822 which reads:

[T]he Commission concludes that a modification to the Low Impact External Routable Connectivity definition to reflect the commentary in the Guidelines and Technical Basis section of CIP-003-6 is necessary to provide needed clarity to the definition and eliminate ambiguity surrounding the term “direct” as it is used in the proposed definition. Therefore, pursuant to section 215(d)(5) of the FPA, we direct NERC to develop a modification to provide the needed clarity, within one year of the effective date of this Final Rule approving revisions to the cybersecurity Critical Infrastructure Protection (CIP) standards.

Previously, the Guidelines and Technical Basis had approximately 10 pages of explanation and numerous reference models to describe different forms of direct vs. indirect access that could be used to determine whether Low Impact External Routable Connectivity existed and thus whether a Low Impact BES Cyber System Electronic Access Point (LEAP) was required. In this revision, the term Low Impact External Routable Connectivity has been changed to Low Impact External Routable Communication (LERC) and simplified so that it is an attribute of a BES asset concerning whether there is routable protocol communications across the asset boundary without regard to 'direct vs. indirect' access that may occur. This greatly simplifies and clarifies the definition of LERC. It removes the dependency between the electronic access controls that may be in place and having those controls determine whether LERC exists or not. For those BES assets that have LERC, the standard drafting team (SDT) changed the requirement from requiring a LEAP to requiring electronic access controls to “permit only necessary electronic access to low impact BES Cyber Systems” (revised Attachment 1, Section 3.1) within the BES asset and expanded the Guidelines and Technical Basis with numerous examples of electronic access controls. Given the modified definition of LERC and the proposed modifications in Reliability CIP-003-7, there is no longer a need for the NERC Glossary term Low Impact BES Cyber System Electronic Access Point (LEAP). Consequently, NERC is proposing that term for retirement.

In summary, the CIP SDT revised CIP-003-7, Attachments 1 and 2, Sections 2 and 3 and the associated High VSL for Requirement R2. Non-substantive errata changes were also made within the standard, including changing “ES-ISAC” to “E-ISAC”.





Completed Actions Date

Standard Authorization Request (SAR) approved July 20, 2016

Draft 1 of CIP-003-7 posted for formal comment and initial ballot July 21 – September 6, 2016

Anticipated Actions Date

10-day final ballot October, 2016

NERC Board of Trustees (Board) adoption November, 2016



A. Introduction 1. Title: Cyber Security — Security Management Controls

2. Number: CIP-003-7(i)

3. Purpose: To specify consistent and sustainable security management controls that establish responsibility and accountability to protect BES Cyber Systems against compromise that could lead to misoperation or instability in the Bulk Electric System (BES).

4. Applicability:

4.1. Functional Entities: For the purpose of the requirements contained herein, the following list of functional entities will be collectively referred to as “Responsible Entities.” For requirements in this standard where a specific functional entity or subset of functional entities are the applicable entity or entities, the functional entity or entities are specified explicitly.

4.1.1 Balancing Authority

4.1.2 Distribution Provider that owns one or more of the following Facilities, systems, and equipment for the protection or restoration of the BES:

4.1.2.1 Each underfrequency Load shedding (UFLS) or undervoltage Load shedding (UVLS) system that:

4.1.2.1.1 is part of a Load shedding program that is subject to one or more requirements in a NERC or Regional Reliability Standard; and

4.1.2.1.2 performs automatic Load shedding under a common control system owned by the Responsible Entity, without human operator initiation, of 300 MW or more.

4.1.2.2 Each Special Protection System (SPS) or Remedial Action Scheme (RAS) where the SPS or RAS is subject to one or more requirements in a NERC or Regional Reliability Standard.

4.1.2.3 Each Protection System (excluding UFLS and UVLS) that applies to Transmission where the Protection System is subject to one or more requirements in a NERC or Regional Reliability Standard.

4.1.2.4 Each Cranking Path and group of Elements meeting the initial switching requirements from a Blackstart Resource up to and including the first interconnection point of the starting station service of the next generation unit(s) to be started.

4.1.3 Generator Operator

4.1.4 Generator Owner



4.1.5 Interchange Coordinator or Interchange Authority

4.1.6 Reliability Coordinator

4.1.7 Transmission Operator

4.1.8 Transmission Owner

4.2. Facilities: For the purpose of the requirements contained herein, the following Facilities, systems, and equipment owned by each Responsible Entity in 4.1 above are those to which these requirements are applicable. For requirements in this standard where a specific type of Facilities, system, or equipment or subset of Facilities, systems, and equipment are applicable, these are specified explicitly.

4.2.1 Distribution Provider: One or more of the following Facilities, systems and equipment owned by the Distribution Provider for the protection or restoration of the BES:

4.2.1.1 Each UFLS or UVLS System that:



4.2.1.2 Each SPS or RAS where the SPS or RAS is subject to one or more requirements in a NERC or Regional Reliability Standard.



4.2.2 Responsible Entities listed in 4.1 other than Distribution Providers:

All BES Facilities.

4.2.3 Exemptions: The following are exempt from Standard CIP-003-7(i):

4.2.3.1 Cyber Assets at Facilities regulated by the Canadian Nuclear Safety Commission.



4.2.3.2 Cyber Assets associated with communication networks and data communication links between discrete Electronic Security Perimeters (ESPs).

4.2.3.3 The systems, structures, and components that are regulated by the Nuclear Regulatory Commission under a cyber security plan pursuant to 10 C.F.R. Section 73.54.

4.2.3.4 For Distribution Providers, the systems and equipment that are not included in section 4.2.1 above.

5. Effective Dates:

See Implementation Plan for CIP-003-7(i).

6. Background:

Standard CIP-003 exists as part of a suite of CIP Standards related to cyber security, which require the initial identification and categorization of BES Cyber Systems and require organizational, operational, and procedural controls to mitigate risk to BES Cyber Systems.

The term policy refers to one or a collection of written documents that are used to communicate the Responsible Entities’ management goals, objectives and expectations for how the Responsible Entity will protect its BES Cyber Systems. The use of policies also establishes an overall governance foundation for creating a culture of security and compliance with laws, regulations, and standards.

The term documented processes refers to a set of required instructions specific to the Responsible Entity and to achieve a specific outcome. This term does not imply any naming or approval structure beyond what is stated in the requirements. An entity should include as much as it believes necessary in its documented processes, but it must address the applicable requirements.

The terms program and plan are sometimes used in place of documented processes where it makes sense and is commonly understood. For example, documented processes describing a response are typically referred to as plans (i.e., incident response plans and recovery plans). Likewise, a security plan can describe an approach involving multiple procedures to address a broad subject matter.

Similarly, the term program may refer to the organization’s overall implementation of its policies, plans, and procedures involving a subject matter. Examples in the standards include the personnel risk assessment program and the personnel training program. The full implementation of the CIP Cyber Security Reliability Standards could also be referred to as a program. However, the terms program and plan do not imply any additional requirements beyond what is stated in the standards.

Responsible Entities can implement common controls that meet requirements for multiple high, medium, and low impact BES Cyber Systems. For example, a single



cyber security awareness program could meet the requirements across multiple BES Cyber Systems.

Measures provide examples of evidence to show documentation and implementation of the requirement. These measures serve to provide guidance to entities in acceptable records of compliance and should not be viewed as an all-inclusive list.

Throughout the standards, unless otherwise stated, bulleted items in the requirements and measures are items that are linked with an “or,” and numbered items are items that are linked with an “and.”

Many references in the Applicability section use a threshold of 300 MW for UFLS and UVLS. This particular threshold of 300 MW for UVLS and UFLS was provided in Version 1 of the CIP Cyber Security Standards. The threshold remains at 300 MW since it is specifically addressing UVLS and UFLS, which are last ditch efforts to save the BES. A review of UFLS tolerances defined within Regional Reliability Standards for UFLS program requirements to date indicates that the historical value of 300 MW represents an adequate and reasonable threshold value for allowable UFLS operational tolerances.



B. Requirements and Measures R1. Each Responsible Entity shall review and obtain CIP Senior Manager approval at least

once every 15 calendar months for one or more documented cyber security policies that collectively address the following topics: [Violation Risk Factor: Medium] [Time Horizon: Operations Planning]

1.1 For its high impact and medium impact BES Cyber Systems, if any:

1.1.1. Personnel and training (CIP-004);

1.1.2. Electronic Security Perimeters (CIP-005) including Interactive Remote Access;

1.1.3. Physical security of BES Cyber Systems (CIP-006);

1.1.4. System security management (CIP-007);

1.1.5. Incident reporting and response planning (CIP-008);

1.1.6. Recovery plans for BES Cyber Systems (CIP-009);

1.1.7. Configuration change management and vulnerability assessments (CIP-010);

1.1.8. Information protection (CIP-011); and

1.1.9. Declaring and responding to CIP Exceptional Circumstances.

1.2 For its assets identified in CIP-002 containing low impact BES Cyber Systems, if any:

1.2.1. Cyber security awareness;

1.2.2. Physical security controls;

1.2.3. Electronic access controls for Low Impact External Routable Communication (LERC) and Dial-up Connectivity; and

1.2.4. Cyber Security Incident response

M1. Examples of evidence may include, but are not limited to, policy documents; revision history, records of review, or workflow evidence from a document management system that indicate review of each cyber security policy at least once every 15 calendar months; and documented approval by the CIP Senior Manager for each cyber security policy.

R2. Each Responsible Entity with at least one asset identified in CIP-002 containing low impact BES Cyber Systems shall implement one or more documented cyber security plan(s) for its low impact BES Cyber Systems that include the sections in Attachment 1. [Violation Risk Factor: Lower] [Time Horizon: Operations Planning]

Note: An inventory, list, or discrete identification of low impact BES Cyber Systems or their BES Cyber Assets is not required. Lists of authorized users are not required.



M2. Evidence shall include each of the documented cyber security plan(s) that collectively include each of the sections in Attachment 1 and additional evidence to demonstrate implementation of the cyber security plan(s). Additional examples of evidence per section are located in Attachment 2.

R3. Each Responsible Entity shall identify a CIP Senior Manager by name and document any change within 30 calendar days of the change. [Violation Risk Factor: Medium] [Time Horizon: Operations Planning]

M3. An example of evidence may include, but is not limited to, a dated and approved document from a high level official designating the name of the individual identified as the CIP Senior Manager.

R4. The Responsible Entity shall implement a documented process to delegate authority, unless no delegations are used. Where allowed by the CIP Standards, the CIP Senior Manager may delegate authority for specific actions to a delegate or delegates. These delegations shall be documented, including the name or title of the delegate, the specific actions delegated, and the date of the delegation; approved by the CIP Senior Manager; and updated within 30 days of any change to the delegation. Delegation changes do not need to be reinstated with a change to the delegator. [Violation Risk Factor: Lower] [Time Horizon: Operations Planning]

M4. An example of evidence may include, but is not limited to, a dated document, approved by the CIP Senior Manager, listing individuals (by name or title) who are delegated the authority to approve or authorize specifically identified items.



C. Compliance 1. Compliance Monitoring Process

1.1. Compliance Enforcement Authority: As defined in the NERC Rules of Procedure, “Compliance Enforcement Authority” (CEA) means NERC or the Regional Entity in their respective roles of monitoring and enforcing compliance with the NERC Reliability Standards.

1.2. Evidence Retention: The following evidence retention periods identify the period of time an entity is required to retain specific evidence to demonstrate compliance. For instances where the evidence retention period specified below is shorter than the time since the last audit, the CEA may ask an entity to provide other evidence to show that it was compliant for the full time period since the last audit.

The Responsible Entity shall keep data or evidence to show compliance as identified below unless directed by its CEA to retain specific evidence for a longer period of time as part of an investigation:

• Each Responsible Entity shall retain evidence of each requirement in this standard for three calendar years.

• If a Responsible Entity is found non-compliant, it shall keep information related to the non-compliance until mitigation is complete and approved or for the time specified above, whichever is longer.

• The CEA shall keep the last audit records and all requested and submitted subsequent audit records.

1.3. Compliance Monitoring and Assessment Processes:

Compliance Audits

Self-Certifications

Spot Checking

Compliance Investigations

Self-Reporting

Complaints

1.4. Additional Compliance Information: None.



2. Table of Compliance Elements

R # Time Horizon VRF

Violation Severity Levels (CIP-003-7)

Lower VSL Moderate VSL High VSL Severe VSL

R1 Operations Planning

Medium The Responsible Entity documented and implemented one or more cyber security policies for its high impact and medium impact BES Cyber Systems, but did not address one of the nine topics required by R1. (R1.1)

OR

The Responsible Entity did not complete its review of the one or more documented cyber security policies for its high impact and medium impact BES Cyber Systems as required by R1 within 15 calendar months but did

The Responsible Entity documented and implemented one or more cyber security policies for its high impact and medium impact BES Cyber Systems, but did not address two of the nine topics required by R1. (R1.1)

OR


The Responsible Entity documented and implemented one or more cyber security policies for its high impact and medium impact BES Cyber Systems, but did not address three of the nine topics required by R1. (R1.1)

OR

The Responsible Entity did not complete its review of the one or more documented cyber security policies for its high impact and medium impact BES Cyber Systems as required by R1 within 17 calendar months but did complete this review in less than or equal to 18

The Responsible Entity documented and implemented one or more cyber security policies for its high impact and medium impact BES Cyber Systems, but did not address four or more of the nine topics required by R1. (R1.1)

OR

The Responsible Entity did not have any documented cyber security policies for its high impact and medium impact BES Cyber Systems as required by R1. (R1.1)

OR






complete this review in less than or equal to 16 calendar months of the previous review. (R1.1)

OR

The Responsible Entity did not complete its approval of the one or more documented cyber security policies for its high impact and medium impact BES Cyber Systems as required by R1 by the CIP Senior Manager within 15 calendar months but did complete this approval in less than or equal to 16 calendar months of the previous approval. (R1.1)


OR


calendar months of the previous review. (R1.1)

OR

The Responsible Entity did not complete its approval of the one or more documented cyber security policies for its high impact and medium impact BES Cyber Systems as required by R1 by the CIP Senior Manager within 17 calendar months but did complete this approval in less than or equal to 18 calendar months of the previous approval. (R1)

OR

The Responsible Entity documented one or more cyber security policies for its assets identified in CIP-002 containing low impact

The Responsible Entity did not complete its review of the one or more documented cyber security policies as required by R1 within 18 calendar months of the previous review. (R1)

OR

The Responsible Entity did not complete its approval of the one or more documented cyber security policies for its high impact and medium impact BES Cyber Systems as required by R1 by the CIP Senior Manager within 18 calendar months of the previous approval. (R1.1)






OR

The Responsible Entity documented one or more cyber security policies for its assets identified in CIP-002 containing low impact BES Cyber Systems, but did not address one of the four topics required by R1. (R1.2)

OR

The Responsible Entity did not complete its review of the one or more documented cyber security policies for its assets identified in CIP-002 containing low impact BES Cyber Systems as required by Requirement R1 within 15 calendar

OR

The Responsible Entity documented one or more cyber security policies for its assets identified in CIP-002 containing low impact BES Cyber Systems, but did not address two of the four topics required by R1. (R1.2)

OR


BES Cyber Systems, but did not address three of the four topics required by R1. (R1.2)

OR

The Responsible Entity did not complete its review of the one or more documented cyber security policies for its assets identified in CIP-002 containing low impact BES Cyber Systems as required by R1 within 17 calendar months but did complete this review in less than or equal to 18 calendar months of the previous review. (R1.2)

OR

The Responsible Entity did not complete its approval of the one or more documented cyber security policies for its

OR

The Responsible Entity documented one or more cyber security policies for its assets identified in CIP-002 containing low impact BES Cyber Systems, but did not address any of the four topics required by R1. (R1.2)

OR

The Responsible Entity did not have any documented cyber security policies for its assets identified in CIP-002 containing low impact BES Cyber Systems as required by R1. (R1.2)

OR






months but did complete this review in less than or equal to 16 calendar months of the previous review. (R1.2)

OR

The Responsible Entity did not complete its approval of the one or more documented cyber security policies for its assets identified in CIP-002 containing low impact BES Cyber Systems as required by Requirement R1 by the CIP Senior Manager within 15 calendar months but did complete this approval in less than or equal to 16 calendar months of


OR

The Responsible Entity did not complete its approval of the one or more documented cyber security policies for its assets identified in CIP-002 containing low impact BES Cyber Systems as required by Requirement R1 by the CIP Senior Manager within 16 calendar months but did complete this approval in less than or equal to 17

assets identified in CIP-002 containing low impact BES Cyber Systems as required by Requirement R1 by the CIP Senior Manager within 17 calendar months but did complete this approval in less than or equal to 18 calendar months of the previous approval. (R1.2)

The Responsible Entity did not complete its approval of the one or more documented cyber security policies for its assets identified in CIP-002 containing low impact BES Cyber Systems as required by Requirement R1 by the CIP Senior Manager within 18 calendar months of the previous approval. (R1.2)






the previous approval. (R1.2)

calendar months of the previous approval. (R1.2)


Lower The Responsible Entity documented its cyber security plan(s) for its assets containing low impact BES Cyber Systems, but failed to document cyber security awareness according to Requirement R2, Attachment 1, Section 1. (R2)

OR

The Responsible Entity documented its cyber security plan(s) for its assets containing low impact BES Cyber Systems, but failed to document one or more Cyber Security

The Responsible Entity documented its cyber security plan(s) for its assets containing low impact BES Cyber Systems, but failed to reinforce cyber security practices at least once every 15 calendar months according to Requirement R2, Attachment 1, Section 1. (R2)

OR

The Responsible Entity documented one or more incident response plans within its cyber security plan(s) for its assets containing

The Responsible Entity documented one or more Cyber Security Incident response plans within its cyber security plan(s) for its assets containing low impact BES Cyber Systems, but failed to test each Cyber Security Incident response plan(s) at least once every 36 calendar months according to Requirement R2, Attachment 1, Section 4. (R2)

OR

The Responsible Entity documented the determination of whether an identified Cyber Security Incident is a Reportable Cyber

The Responsible Entity failed to document and implement one or more cyber security plan(s) for its assets containing low impact BES Cyber Systems according to Requirement R2, Attachment 1. (R2).






Incident response plans according to Requirement R2, Attachment 1, Section 4. (R2)

OR

The Responsible Entity documented one or more Cyber Security Incident response plans within its cyber security plan(s) for its assets containing low impact BES Cyber Systems, but failed to update each Cyber Security Incident response plan(s) within 180 days according to Requirement R2, Attachment 1, Section 4. (R2)

OR

low impact BES Cyber Systems, but failed to include the process for identification, classification, and response to Cyber Security Incidents according to Requirement R2, Attachment 1, Section 4. (R2)

OR

The Responsible Entity documented its cyber security plan(s) for its assets containing low impact BES Cyber Systems, but failed to document the determination of whether an identified Cyber Security Incident is a Reportable Cyber Security Incident and

Security Incident, but failed to notify the Electricity Information Sharing and Analysis Center (E-ISAC) according to Requirement R2, Attachment 1, Section 4. (R2)

OR

The Responsible Entity documented electronic access controls for its assets containing low impact BES Cyber Systems, but failed to implement the electronic access controls according to Requirement R2, Attachment 1, Section 3. (R2)

OR

The Responsible Entity documented the physical access controls for its






The Responsible Entity documented its plan(s) for Transient Cyber Assets and Removable Media, but failed to manage its Transient Cyber Asset(s) according to Requirement R2, Attachment 1, Section 5.1. (R2)

OR

The Responsible Entity documented its plan(s) for Transient Cyber Assets and Removable Media, but failed to document the Removable Media sections according to Requirement R2, Attachment 1, Section 5.3. (R2)

subsequent notification to the Electricity Information Sharing and Analysis Center (E-ISAC) according to Requirement R2, Attachment 1, Section 4. (R2)

OR

The Responsible Entity documented its cyber security plan(s) for its assets containing low impact BES Cyber Systems, but failed to document physical security controls according to Requirement R2, Attachment 1, Section 2. (R2)

OR

The Responsible Entity documented

assets containing low impact BES Cyber Systems, but failed to implement the physical security controls according to Requirement R2, Attachment 1, Section 2. (R2)

OR

The Responsible Entity documented its plan(s) for Transient Cyber Assets and Removable Media, but failed to implement mitigation for the introduction of malicious code for Transient Cyber Assets managed by the Responsible Entity according to Requirement R2, Attachment 1, Section 5.1. (R2)

OR






its cyber security plan(s) for its assets containing low impact BES Cyber Systems, but failed to document electronic access controls according to Requirement R2, Attachment 1, Section 3. (R2)

OR

The Responsible Entity documented its plan(s) for Transient Cyber Assets and Removable Media plan, but failed to document mitigation for the introduction of malicious code for Transient Cyber Assets managed by the Responsible Entity according to Requirement R2,

The Responsible Entity documented its plan(s) for Transient Cyber Assets and Removable Media, but failed to implement mitigation for the introduction of malicious code for Transient Cyber Assets managed by a party other than the Responsible Entity according to Requirement R2, Attachment 1, Section 5.2. (R2)

OR

The Responsible Entity documented its plan(s) for Transient Cyber Assets and Removable Media, but failed to implement mitigation for threat of detected malicious code on the Removable Media prior to connecting






Attachment 1, Sections 5.1 and 5.3. (R2)

OR

The Responsible Entity documented its plan(s) for Transient Cyber Assets and Removable Media, but failed to document mitigation for the introduction of malicious code for Transient Cyber Assets managed by a party other than the Responsible Entity according to Requirement R2, Attachment 1, Section 5.2. (R2)

OR

The Responsible Entity documented its plan(s) for

Removable Media to a low impact BES Cyber System according to Requirement R2, Attachment 1, Section 5.3. (R2)






Transient Cyber Assets and Removable Media, but failed to implement the Removable Media section(s) according to Requirement R2, Attachment 1, Section 5.3. (R2)


Medium The Responsible Entity has identified by name a CIP Senior Manager, but did not document changes to the CIP Senior Manager within 30 calendar days but did document this change in less than 40 calendar days of the change. (R3)

The Responsible Entity has identified by name a CIP Senior Manager, but did not document changes to the CIP Senior Manager within 40 calendar days but did document this change in less than 50 calendar days of the change. (R3)


The Responsible Entity has not identified, by name, a CIP Senior Manager.

OR

The Responsible Entity has identified by name a CIP Senior Manager, but did not document changes to the CIP Senior Manager within 60 calendar days of the change. (R3)







Lower The Responsible Entity has identified a delegate by name, title, date of delegation, and specific actions delegated, but did not document changes to the delegate within 30 calendar days but did document this change in less than 40 calendar days of the change. (R4)

The Responsible Entity has identified a delegate by name, title, date of delegation, and specific actions delegated, but did not document changes to the delegate within 40 calendar days but did document this change in less than 50 calendar days of the change. (R4)


The Responsible Entity has used delegated authority for actions where allowed by the CIP Standards, but does not have a process to delegate actions from the CIP Senior Manager. (R4)

OR

The Responsible Entity has identified a delegate by name, title, date of delegation, and specific actions delegated, but did not document changes to the delegate within 60 calendar days of the change. (R4)



D. Regional Variances None.

E. Interpretations None.

F. Associated Documents None.



Version History

Version Date Action Change Tracking

1 1/16/06 R3.2 — Change “Control Center” to “control center.” 3/24/06

2 9/30/09 Modifications to clarify the requirements and to bring the compliance elements into conformance with the latest guidelines for developing compliance elements of standards.

Removal of reasonable business judgment.

Replaced the RRO with the RE as a responsible entity.

Rewording of Effective Date.

Changed compliance monitor to Compliance Enforcement Authority.

3 12/16/09 Updated Version Number from -2 to -3

In Requirement 1.6, deleted the sentence pertaining to removing component or system from service in order to perform testing, in response to FERC order issued September 30, 2009.

3 12/16/09 Approved by the NERC Board of Trustees.

3 3/31/10 Approved by FERC.


5 11/26/12 Adopted by the NERC Board of Trustees. Modified to coordinate with other CIP standards and to revise format to use RBS Template.




5 11/22/13 FERC Order issued approving CIP-003-5.

6 11/13/14 Adopted by the NERC Board of Trustees. Addressed two FERC directives from Order No. 791 related to identify, assess, and correct language and communication networks.

6 2/12/15 Adopted by the NERC Board of Trustees. Replaces the version adopted by the Board on 11/13/2014. Revised version addresses remaining directives from Order No. 791 related to transient devices and low impact BES Cyber Systems.

6 1/21/16 FERC Order issued approving CIP-003-6. Docket No. RM15-14-000

7 TBD Adopted by the NERC Board of Trustees. Revised to address FERC Order 822 directive regarding definition of LERC



Attachment 1

Required Sections for Cyber Security Plan(s) for Assets Containing Low Impact BES Cyber Systems

Responsible Entities shall include each of the sections provided below in the cyber security plan(s) required under Requirement R2. Responsible Entities with multiple-impact BES Cyber Systems ratings can utilize policies, procedures, and processes for their high or medium impact BES Cyber Systems to fulfill the sections for the development of low impact cyber security plan(s). Each Responsible Entity can develop a cyber security plan(s) either by individual asset or groups of assets. Section 1. Cyber Security Awareness: Each Responsible Entity shall reinforce, at least once

every 15 calendar months, cyber security practices (which may include associated physical security practices).

Section 2. Physical Security Controls: Each Responsible Entity shall control physical access, based on need as determined by the Responsible Entity, to (1) the asset or the locations of the low impact BES Cyber Systems within the asset, and (2) the Cyber Asset(s), as specified by the Responsible Entity, that provide electronic access control(s) implemented for Section 3.1, if any.

Section 3. Electronic Access Controls: Each Responsible Entity shall:

3.1 Implement electronic access control(s) for LERC, if any, to permit only necessary electronic access to low impact BES Cyber System(s).

3.2 Implement authentication for all Dial-up Connectivity, if any, that provides access to low impact BES Cyber Systems, per Cyber Asset capability.

Section 4. Cyber Security Incident Response: Each Responsible Entity shall have one or more Cyber Security Incident response plan(s), either by asset or group of assets, which shall include:

4.1 Identification, classification, and response to Cyber Security Incidents;

4.2 Determination of whether an identified Cyber Security Incident is a Reportable Cyber Security Incident and subsequent notification to the Electricity Information Sharing and Analysis Center (E-ISAC), unless prohibited by law;

4.3 Identification of the roles and responsibilities for Cyber Security Incident response by groups or individuals;

4.4 Incident handling for Cyber Security Incidents;

4.5 Testing the Cyber Security Incident response plan(s) at least once every 36 calendar months by: (1) responding to an actual Reportable Cyber Security Incident; (2) using a drill or tabletop exercise of a Reportable Cyber Security



Incident; or (3) using an operational exercise of a Reportable Cyber Security Incident; and

4.6 Updating the Cyber Security Incident response plan(s), if needed, within 180 calendar days after completion of a Cyber Security Incident response plan(s) test or actual Reportable Cyber Security Incident.

Rationale for Section 5 of Attachment 1 (Requirement R2):

Requirement R2 mandates that entities develop and implement one or more cyber security plan(s) to meet specific security control objectives for assets containing low impact BES Cyber System(s). In Paragraph 32 of FERC Order No. 822, the Commission directed NERC to “…provide mandatory protection for transient devices used at Low Impact BES Cyber Systems based on the risk posed to bulk electric system reliability.” Transient devices are potential vehicles for introducing malicious code into a facility and subsequently into low impact BES Cyber Systems. Section 5 of Attachment 1 is intended to mitigate the risk of malware propagation to the BES through low impact BES Cyber Systems by requiring entities to develop and implement one or more Transient Cyber Asset and Removable Media Malicious Code Mitigation plan(s). The cyber security plan(s) along with the cyber security policies required under Requirement R1, Part 1.2, provide a framework for operational, procedural, and technical safeguards for low impact BES Cyber Systems.

Section 5. Transient Cyber Asset and Removable Media Malicious Code Mitigation Plan(s): Each Responsible Entity shall implement one or more plan(s) to achieve the objective of mitigating the introduction of malicious code to low impact BES Cyber Systems through the use of Transient Cyber Assets or Removable Media, which shall include:

5.1 For Transient Cyber Asset(s) managed by the Responsible Entity, if any, use of one or a combination of the following methods in an ongoing or on-demand manner (per Transient Cyber Asset capability):

• Antivirus software, including manual or managed updates of signatures or patterns;

• Application whitelisting; or

• Other method(s) to mitigate the introduction of malicious code.

5.2 For Transient Cyber Asset(s) managed by a party other than the Responsible Entity, if any, use of one or a combination of the following methods prior to connecting the Transient Cyber Asset to a low impact BES Cyber System (per Transient Cyber Asset capability):

• Review of antivirus update level;



• Review of antivirus update process used by the party;

• Review of application whitelisting used by the party;

• Review use of live operating system and software executable only from read-only media;

• Review of system hardening used by the party; or


5.3 For Removable Media, perform each of the following:

5.3.1 Use of method(s) to detect malicious code on Removable Media using a Cyber Asset other than a BES Cyber System; and

5.3.2 Mitigation of the threat of detected malicious code on the Removable Media prior to connecting Removable Media to a low impact BES Cyber System.



Attachment 2

Examples of Evidence for Cyber Security Plan(s) for Assets Containing Low Impact BES Cyber Systems

Section 1. Cyber Security Awareness: An example of evidence for Section 1 may include, but is not limited to, documentation that the reinforcement of cyber security practices occurred at least once every 15 calendar months. The evidence could be documentation through one or more of the following methods:

• Direct communications (for example, emails, memos, or computer-based training);

• Indirect communications (for example, posters, intranet, or brochures); or

• Management support and reinforcement (for example, presentations or meetings).

Section 2. Physical Security Controls: Examples of evidence for Section 2 may include, but are not limited to:

• Documentation of the selected access control(s) (e.g., card key, locks, perimeter controls), monitoring controls (e.g., alarm systems, human observation), or other operational, procedural, or technical physical security controls that control physical access to both:

a. The asset, if any, or the locations of the low impact BES Cyber Systems within the asset; and

b. The Cyber Asset specified by the Responsible Entity that provides electronic access controls implemented for Section 3.1, if any.

Section 3. Electronic Access Controls: Examples of evidence for Section 3 may include, but are not limited to:

1. Documentation, such as representative diagrams or lists of implemented electronic access controls (e.g., restricting IP addresses, ports, or services; authenticating users; air-gapping networks; terminating routable protocol sessions on a non-BES Cyber Asset; implementing unidirectional gateways) showing that for LERC at each asset or group of assets containing low impact BES Cyber Systems, is confined only to that access the Responsible Entity deems necessary; and

2. Documentation of authentication for Dial-up Connectivity (e.g., dial out only to a preprogrammed number to deliver data, dial-back modems, modems that must be remotely controlled by the control center or control room, or access control on the BES Cyber System).

Section 4. Cyber Security Incident Response: An example of evidence for Section 4 may include, but is not limited to, dated documentation, such as policies, procedures, or process



documents of one or more Cyber Security Incident response plan(s) developed either by asset or group of assets that include the following processes:

1. to identify, classify, and respond to Cyber Security Incidents; to determine whether an identified Cyber Security Incident is a Reportable Cyber Security Incident and for notifying the Electricity Information Sharing and Analysis Center (E-ISAC);

2. to identify and document the roles and responsibilities for Cyber Security Incident response by groups or individuals (e.g., initiating, documenting, monitoring, reporting, etc.);

3. for incident handling of a Cyber Security Incident (e.g., containment, eradication, or recovery/incident resolution);

4. for testing the plan(s) along with the dated documentation that a test has been completed at least once every 36 calendar months; and

5. to update, as needed, Cyber Security Incident response plan(s) within 180 calendar days after completion of a test or actual Reportable Cyber Security Incident.

Section 5. Transient Cyber Asset and Removable Media Malicious Code Mitigation Plan(s):

1. Examples of evidence for Section 5.1 may include, but are not limited to, documentation of the method(s) used to mitigate the introduction of malicious code such as antivirus software and processes for managing signature or pattern updates, application whitelisting practices, processes to restrict communication, or other method(s) to mitigate the introduction of malicious code. If a Transient Cyber Asset does not have the capability to use method(s) that mitigate the introduction of malicious code, evidence may include documentation by the vendor or Responsible Entity that identifies that the Transient Cyber Asset does not have the capability.

2. Examples of evidence for Section 5.2 may include, but are not limited to, documentation from change management systems, electronic mail or procedures that document a review of the installed antivirus update level; memoranda, electronic mail, system documentation, policies or contracts from the party other than the Responsible Entity that identify the antivirus update process, the use of application whitelisting, use of live operating systems or system hardening performed by the party other than the Responsible Entity; evidence from change management systems, electronic mail or contracts that identifies the Responsible Entity’s acceptance that the practices of the party other than the Responsible Entity are acceptable; or documentation of other method(s) to mitigate malicious code for Transient Cyber Asset(s) managed by a party other than the Responsible Entity. If a Transient Cyber Asset does not have the capability to use method(s) that mitigate the introduction of malicious code, evidence may include documentation by the Responsible Entity or the party



other than the Responsible Entity that identifies that the Transient Cyber Asset does not have the capability

3. Examples of evidence for Section 5.3.1 may include, but are not limited to, documented process(es) of the method(s) used to mitigate malicious code such as results of scan settings for Removable Media, or implementation of on-demand scanning. Examples of evidence for Section 5.3.2 may include, but are not limited to, documented process(es) for the method(s) used for mitigating the threat of detected malicious code on Removable Media, such as logs from the method(s) used to detect malicious code that show the results of scanning and the mitigation of detected malicious code on Removable Media or documented confirmation by the entity that the Removable Media was deemed to be free of malicious code.

CIP-003-7 - Supplemental Material


Guidelines and Technical Basis Section 4 – Scope of Applicability of the CIP Cyber Security Standards Section “4. Applicability” of the standards provides important information for Responsible Entities to determine the scope of the applicability of the CIP Cyber Security Requirements.

Section “4.1. Functional Entities” is a list of NERC functional entities to which the standard applies. If the entity is registered as one or more of the functional entities listed in Section 4.1, then the NERC CIP Cyber Security Standards apply. Note that there is a qualification in Section 4.1 that restricts the applicability in the case of Distribution Providers to only those that own certain types of systems and equipment listed in 4.2.

Section “4.2. Facilities” defines the scope of the Facilities, systems, and equipment owned by the Responsible Entity, as qualified in Section 4.1, that is subject to the requirements of the standard. In addition to the set of BES Facilities, Control Centers, and other systems and equipment, the list includes the set of systems and equipment owned by Distribution Providers. While the NERC Glossary term “Facilities” already includes the BES characteristic, the additional use of the term BES here is meant to reinforce the scope of applicability of these Facilities where it is used, especially in this applicability scoping section. This in effect sets the scope of Facilities, systems, and equipment that is subject to the standards. Requirement R1: In developing policies in compliance with Requirement R1, the number of policies and their content should be guided by a Responsible Entity's management structure and operating conditions. Policies might be included as part of a general information security program for the entire organization, or as components of specific programs. The Responsible Entity has the flexibility to develop a single comprehensive cyber security policy covering the required topics, or it may choose to develop a single high-level umbrella policy and provide additional policy detail in lower level documents in its documentation hierarchy. In the case of a high-level umbrella policy, the Responsible Entity would be expected to provide the high-level policy as well as the additional documentation in order to demonstrate compliance with CIP-003-7, Requirement R1.

If a Responsible Entity has any high or medium impact BES Cyber Systems, the one or more cyber security policies must cover the nine subject matter areas required by CIP-003-7, Requirement R1, Part 1.1. If a Responsible Entity has identified from CIP-002 any assets containing low impact BES Cyber Systems, also referred to herein as BES assets, the one or more cyber security policies must cover the four subject matter areas required by Requirement R1, Part 1.2.

Responsible Entities that have multiple-impact rated BES Cyber Systems are not required to create separate cyber security policies for high, medium, or low impact BES Cyber Systems. The Responsible Entities have the flexibility to develop policies that cover all three impact ratings.

Implementation of the cyber security policy is not specifically included in CIP-003-7, Requirement R1 as it is envisioned that the implementation of this policy is evidenced through successful implementation of CIP-003 through CIP-011. However, Responsible Entities are



encouraged not to limit the scope of their cyber security policies to only those requirements in NERC cyber security Reliability Standards, but to develop a holistic cyber security policy appropriate for its organization. Elements of a policy that extend beyond the scope of NERC’s cyber security Reliability Standards will not be considered candidates for potential violations although they will help demonstrate the organization’s internal culture of compliance and posture towards cyber security.

For Part 1.1, the Responsible Entity should consider the following for each of the required topics in its one or more cyber security policies for medium and high impact BES Cyber Systems, if any:

1.1.1 Personnel and training (CIP-004)

• Organization position on acceptable background investigations

• Identification of possible disciplinary action for violating this policy

• Account management

1.1.2 Electronic Security Perimeters (CIP-005) including Interactive Remote Access

• Organization stance on use of wireless networks

• Identification of acceptable authentication methods

• Identification of trusted and untrusted resources

• Monitoring and logging of ingress and egress at Electronic Access Points

• Maintaining up-to-date anti-malware software before initiating Interactive Remote Access

• Maintaining up-to-date patch levels for operating systems and applications used to initiate Interactive Remote Access

• Disabling VPN “split-tunneling” or “dual-homed” workstations before initiating Interactive Remote Access

• For vendors, contractors, or consultants: include language in contracts that requires adherence to the Responsible Entity’s Interactive Remote Access controls

1.1.3 Physical security of BES Cyber Systems (CIP-006)

• Strategy for protecting Cyber Assets from unauthorized physical access

• Acceptable physical access control methods

• Monitoring and logging of physical ingress

1.1.4 System security management (CIP-007)

• Strategies for system hardening

• Acceptable methods of authentication and access control



• Password policies including length, complexity, enforcement, prevention of brute force attempts

• Monitoring and logging of BES Cyber Systems

1.1.5 Incident reporting and response planning (CIP-008)

• Recognition of Cyber Security Incidents

• Appropriate notifications upon discovery of an incident

• Obligations to report Cyber Security Incidents

1.1.6 Recovery plans for BES Cyber Systems (CIP-009)

• Availability of spare components

• Availability of system backups

1.1.7 Configuration change management and vulnerability assessments (CIP-010)

• Initiation of change requests

• Approval of changes

• Break-fix processes

1.1.8 Information protection (CIP-011)

• Information access control methods

• Notification of unauthorized information disclosure

• Information access on a need-to-know basis

1.1.9 Declaring and responding to CIP Exceptional Circumstances

• Processes to invoke special procedures in the event of a CIP Exceptional Circumstance

• Processes to allow for exceptions to policy that do not violate CIP requirements

Requirements relating to exceptions to a Responsible Entity’s security policies were removed because it is a general management issue that is not within the scope of a reliability requirement. It is an internal policy requirement and not a reliability requirement. However, Responsible Entities are encouraged to continue this practice as a component of their cyber security policies.

In this and all subsequent required approvals in the NERC CIP Reliability Standards, the Responsible Entity may elect to use hardcopy or electronic approvals to the extent that there is sufficient evidence to ensure the authenticity of the approving party. Requirement R2: Using the list of assets containing low impact BES Cyber Systems from CIP-002, the intent of the requirement is for each Responsible Entity to create, document, and implement one or more cyber security plan(s) that addresses objective criteria for the protection of low impact BES



Cyber Systems. The protections required by Requirement R2 reflect the level of risk that misuse or the unavailability of low impact BES Cyber Systems poses to the BES. The intent is that the required protections are part of a program that covers the low impact BES Cyber Systems collectively either at an asset or site level (assets containing low impact BES Cyber Systems), but not at an individual device or system level.

There are four subject matter areas, as identified in Attachment 1, that must be covered by the cyber security plan: (1) cyber security awareness, (2) physical security controls, (3) electronic access controls for LERC and Dial-up Connectivity, and (4) Cyber Security Incident response. Requirement R2, Attachment 1 As noted, Attachment 1 contains the sections that must be in the cyber security plan(s). The intent is to allow entities that have a combination of high, medium, and low impact BES Cyber Systems the flexibility to choose, if desired, to cover their low impact BES Cyber Systems (or any subset) under their programs used for the high or medium impact BES Cyber Systems rather than maintain two separate programs. Guidance for each of the four subject matter areas of Attachment 1 is provided below. Requirement R2, Attachment 1, Section 1 – Cyber Security Awareness The intent of the cyber security awareness program is for entities to reinforce good cyber security practices with their personnel at least once every 15 calendar months. The entity has the discretion to determine the topics to be addressed and the manner in which it will communicate these topics. As evidence of compliance, the Responsible Entity should be able to produce the awareness material that was delivered according to the delivery method(s) (e.g., posters, emails, or topics at staff meetings, etc.). The Responsible Entity is not required to maintain lists of recipients and track the reception of the awareness material by personnel.

Although the focus of the awareness is cyber security, it does not mean that only technology-related topics can be included in the program. Appropriate physical security topics (e.g., tailgating awareness and protection of badges for physical security, or “If you see something, say something” campaigns, etc.) are valid for cyber security awareness. The intent is to cover topics concerning any aspect of the protection of BES Cyber Systems. Requirement R2, Attachment 1, Section 2 – Physical Security Controls The Responsible Entity must document and implement methods to control physical access to (1) the asset or the locations of low impact BES Cyber Systems within the asset, and (2) Cyber Assets that implement the electronic access control(s) specified by the Responsible Entity in Section 3, if any. If these Cyber Assets are located within the BES asset and inherit the same controls outlined in Section 2, this can be noted by the Responsible Entity in either its policies or cyber security plan(s) to avoid duplicate documentation of the same controls.

The Responsible Entity has the flexibility in the selection of the methods used to meet the objective to control physical access to the asset(s) containing low impact BES Cyber System(s) or the low impact BES Cyber Systems themselves, as well as physical protection of the electronic access control Cyber Assets specified by the Responsible Entity, if any. The Responsible Entity may use one or a combination of access controls, monitoring controls, or



other operational, procedural, or technical physical security controls. Entities may use perimeter controls (e.g., fences with locked gates, guards, or site access policies, etc.) or more granular areas of physical access control in areas where low impact BES Cyber Systems are located, such as control rooms or control houses. User authorization programs and lists of authorized users for physical access are not required although they are an option to meet the security objective.

The objective is to control the physical access based on need as determined by the Responsible Entity. The need can be documented at the policy level for access to the site or systems. The requirement does not obligate an entity to specify a need for each access or authorization of a user for access.

Monitoring as a physical security control can be used as a complement or an alternative to access control. Examples of monitoring controls include, but are not limited to: (1) alarm systems to detect motion or entry into a controlled area, or (2) human observation of a controlled area. Monitoring does not necessarily require logging and maintaining logs but could include monitoring that physical access has occurred or been attempted (e.g., door alarm, or human observation, etc.). The monitoring does not need to be per low impact BES Cyber System but should be at the appropriate level to meet the security objective. Requirement R2, Attachment 1, Section 3 – Electronic Access Controls Section 3 requires the establishment of electronic access controls for assets containing low impact BES Cyber Systems, also referred to herein as BES assets when external routable protocol communication (LERC) or Dial-up Connectivity is present to or from the asset containing the low impact BES Cyber System(s). The establishment of electronic access controls is intended to reduce the risks associated with uncontrolled communication using routable protocols or Dial-up Connectivity. In the case where there is no LERC or Dial-up Connectivity, the Responsible Entity can document the absence of such communication in its low impact cyber security plan(s).

When identifying electronic access controls, Responsible Entities are provided flexibility in the selection of the controls that meet their operational needs while meeting the security objective of allowing only necessary electronic access to low impact BES Cyber Systems.

In essence, Responsible Entities are to determine LERC or Dial-up Connectivity for their BES assets and then, if present, document and implement electronic access control(s). Determining LERC The defined term Low Impact External Routable Communication (LERC) is used to avoid confusion with the term External Routable Connectivity (ERC) used for high and medium impact BES Cyber Systems as these terms are different concepts. The input to this requirement from CIP-002 is a list of assets containing low impact BES Cyber Systems, therefore LERC is an attribute of a BES asset and involves routable protocol communications to or from the BES asset (crossing the asset boundary) without regard to connectivity to Cyber Assets within the BES asset. ERC on the other hand is an attribute of an individual high or medium impact BES Cyber System and is relative to an Electronic Security Perimeter (ESP).



With LERC being a BES asset level attribute, it is used as a higher level filter to exclude from further consideration those assets containing low impact BES Cyber Systems that have no routable protocol communications to them from outside the BES asset. Responsible Entities can then concentrate their electronic access control efforts on those BES assets that do have LERC. However, this also means that LERC can exist for a BES asset even if there is no routable protocol connectivity to any low impact BES Cyber System within the BES asset. In order to avoid future technology issues, the LERC definition specifically excludes communications between intelligent electronic devices that use routable communication protocols for time-sensitive protection or control functions between non-Control Center BES assets containing low impact BES Cyber Systems, such as IEC 61850 messaging. This does not exclude Control Center to field communication but rather excludes the communication between the intelligent electronic devices (e.g. relays) in the field. A Responsible Entity using this technology is not expected to implement the electronic access controls noted herein. This exception was included so as not to inhibit the functionality of the time-sensitive requirements related to this technology nor to preclude the use of such time-sensitive reliability enhancing functions if they use a routable protocol in the future. Determining Asset Boundary As LERC is a BES asset level attribute, it involves a determination by the Responsible Entity of a BES asset boundary for their assets containing low impact BES Cyber Systems. This boundary will vary by BES asset type (Control Center, substation, generation resource) and the specific configuration of the BES asset. The intent is for the Responsible Entity to define the BES asset boundary such that the low impact BES Cyber System(s) that are located at the BES asset are contained within the BES asset boundary. This is strictly for determining what constitutes the BES “asset” and for determining which routable protocol communications and networks are internal or inside or local to the BES asset and which are external to or outside the BES asset. This is not an Electronic Security Perimeter or Physical Security Perimeter as defined for medium and high impact BES Cyber Systems. For the asset containing low impact BES Cyber System(s), the BES asset boundary is synonymous to the concept of a “logical border” demarcation where routable protocol communication (e.g. LERC) enters and exits the BES asset containing the low impact BES Cyber System. Some examples of ways a Responsible Entity may determine BES asset boundaries are:

• For Control Centers

o Designated areas (room(s) or floor(s)) if the Control Center is located within a larger building.

o A building if in a dedicated building on a shared campus.

o The property/fence line if the Control Center is a dedicated facility on dedicated property.

• For substations, this could be the property/fence line or the control house.



• For generation resources:

o Fossil/hydro generating facilities: This could be the property/fence line. If pumps or wells or other equipment that are part of the plant asset are outside the property line, then the BES asset boundary could expand to accommodate all that is considered part of the plant.

o Solar farms: This could be the property line(s) or fence(s) surrounding all solar panels and interconnection facilities.

o Wind farms: This could be the collection of individual turbines plus the equipment needed for interconnection.

o Cogeneration facilities: This could be the identified portion of the larger plant that performs generation.

Determining Electronic Access Controls Once a Responsible Entity has determined that LERC exists at the BES asset boundary, the Responsible Entity documents and implements its chosen electronic access control(s). The control(s) must allow only “necessary” access as determined by the Responsible Entity and they need to be able to explain the reasons for the electronic access permitted with their electronic access controls. The reasoning for the “necessary” access controls can be documented within the Responsible Entity’s cyber security plan(s) or other policies or procedures associated with the electronic access controls. Concept Diagrams The diagrams on the following pages are provided as examples to illustrate various electronic access controls at a conceptual level. Regardless of the concepts or configurations chosen by the Responsible Entity, the security objective of permitting only necessary access to low impact BES Cyber Systems must be met when there is LERC to a BES asset. NOTE:

• This is not an exhaustive list of applicable concepts.

• LERC is present in each diagram.

• The same legend is used in each diagram; however, the diagram may not contain all of the articles represented in the legend.

• The term “BES Asset Boundary” is capitalized in the diagrams but it is not a defined term.



LERC Reference Model 1 – Physical Isolation The Responsible Entity may choose to physically isolate the low impact BES Cyber System(s) from the LERC. This control is commonly referred to as an ‘air gap’. The serial non-routable protocol connection and the routable protocol LERC are completely isolated from each other. There is no equipment shared with the low impact BES Cyber System(s).

BES Asset Boundary

SerialNon-routable

Protocol

Non-BES Cyber Asset

Non-BES Cyber Asset

RoutableProtocol

Air Gap

LERC

Low impactBES Cyber

System

Low impactBES Cyber

System

Non-BES Cyber Asset

Routable Protocol Routable ProtocolData FlowNon-routable Protocol

Reference Model 1



LERC Reference Model 2 – Logical Isolation The Responsible Entity may choose to logically isolate the low impact BES Cyber System(s) from the LERC. The low impact BES Cyber System(s) is on an isolated network segment with logical controls preventing routable protocol communication into or out of the network containing the low impact BES Cyber System(s).

BES Asset Boundary

RoutableProtocol

LERC

Network Devicewith logical network segmentation

Low impactBES Cyber

System

Non-BES Cyber Asset

Non-BES Cyber Asset

Low impactBES Cyber

System

Control Network Segment Non-Control Network Segment

`


Reference Model 2



LERC Reference Model 3 – Host-based Inbound & Outbound Access Permissions The Responsible Entity may choose to utilize a host-based firewall technology on the low impact BES Cyber System(s) that manages electronic access permission so that only necessary inbound and outbound routable protocol access is allowed to the low impact BES Cyber System(s).

BES Asset Boundary

RoutableProtocol

LERC

Low impactBES Cyber

System


Reference Model 3



LERC Reference Model 4 – Network-based Inbound & Outbound Access Permissions The Responsible Entity may choose to utilize a security device that permits only necessary access to the low impact BES Cyber System(s) within the BES asset. In this example, two low impact BES Cyber Systems are accessed over the LERC as the IP/Serial converter is continuing the same communications session from device(s) outside the BES asset boundary to the low impact BES Cyber Systems. The security device provides the electronic access controls to permit only necessary inbound and outbound routable protocol access to the low impact BES Cyber Systems.

BES Asset Boundary

LERC

SerialNon-Routable

Protocol

Low impactBES Cyber

System

Network

Low impactBES Cyber

System

IP/SerialConverter

RoutableProtocol


Reference Model 4



LERC Reference Model 5 – Centralized Network-based Inbound & Outbound Access Permissions The Responsible Entity may choose to utilize a security device at a centralized location that may or may not be another BES asset. The electronic access control(s) do not necessarily have to reside inside the asset containing the low impact BES Cyber System(s). A security device is in place at “Location X” to act as the electronic access control and permit only necessary inbound and outbound routable protocol access to the low impact BES Cyber System(s). Care should be taken that electronic access to or between each BES asset is through the electronic access controls at the centralized location.

Reference Model 5

Location X

BES Asset Boundary BES Asset Boundary

LERCLERC

`

Firewall, Router Access Control List,Gateway or Other Security Device

RoutableProtocol

RoutableProtocol

Network Network

Non BES CyberSystsem

Low impactBES Cyber

SystemNon BES Cyber

System

Low impactBES Cyber

System

RoutableProtocol




LERC Reference Model 6 – Uni-directional Gateway The Responsible Entity may choose to utilize a uni-directional gateway as the electronic access control. The low impact BES Cyber System(s) is not accessible (data cannot flow into the low impact BES Cyber System) from the LERC due to the implementation of a “one-way” (uni-directional) path for data to flow across the BES asset boundary.

BES Asset Boundary

RoutableProtocol

LERC

Low impactBES Cyber

System

Uni-directionalGateway


Reference Model 6



LERC Reference Model 7 – User Authentication The Responsible Entity may choose to utilize a non-BES Cyber Asset between the network outside the BES asset boundary and the low impact BES Cyber System to perform user authentication for interactive access. The non-BES Cyber Asset would require authentication before establishing a new connection to the low impact BES Cyber System. The electronic access control depicted in this reference model may not meet the security objective for controlling device-to-device communication across the LERC depending on the specific system configuration in place.

BES Asset Boundary

RoutableProtocol

LERC

Low impactBES Cyber

System

Non-BES Cyber AssetPerforming Authentication


Reference Model 7



LERC Reference Model 8 – Session Termination The Responsible Entity may choose to terminate routable protocol application sessions at a non-BES Cyber Asset inside the asset containing the low impact BES Cyber System(s) such that a separate application session is established to the low impact BES Cyber System(s) from the non-BES Cyber Asset (the routable session from outside the BES asset). The Responsible Entity may choose to authenticate access at a non-BES Cyber Asset either outside BES asset boundary or inside the asset containing the low impact BES Cyber System(s) such that unauthenticated access to the low impact BES Cyber System(s) is prohibited. The non-BES Cyber Asset sits on a demilitarized zone (DMZ) between the network outside the BES asset boundary and the low impact BES Cyber System(s). The non-BES Cyber Asset in the DMZ terminates the routable protocol session and establishes a new session to the low impact BES Cyber System(s). Additionally, a security device permits traffic from the network outside the BES asset boundary to flow only to and from the non-BES Cyber Asset in the DMZ (the routable session to the low impact BES Cyber System).

Reference Model 8

BES Asset Boundary

Network

Low impactBES Cyber

System

DMZ

Non-BES Cyber Asset(Separate routable protocolsessions for each data flow)

RoutableProtocol


LERC




LERC Reference Model 9 – LERC and ERC There is both LERC and ERC present in this reference model because there is at least one medium impact BES Cyber System and one low impact BES Cyber System within the BES asset. The Responsible Entity may choose to leverage an interface on the medium impact Electronic Access Control or Monitoring Systems (EACMS) device to provide electronic access controls for the LERC. The EACMS is therefore performing multiple functions – as a medium impact EACMS and as implementing low impact electronic access controls.

BES Asset Boundary


Network

Non BES CyberSystem

Low impactBES Cyber

System

RoutableProtocol

Network

Medium impactBES Cyber

System with ERC

EAP Interface

ESP

LERC

ERC


Reference Model 9



Dial-up Connectivity Dial-up Connectivity to a low impact BES Cyber System is set to dial out only (no auto-answer) to a preprogrammed number to deliver data. Incoming Dial-up Connectivity is to a dialback modem, a modem that must be remotely controlled by the control center or control room, has some form of access control, or the low impact BES Cyber System has access control. Insufficient Access Controls Some examples of situations that would lack sufficient access controls to meet the intent of this requirement include:

• An asset has Dial-up Connectivity and a low impact BES Cyber System is reachable via an auto-answer modem that connects any caller to the Cyber Asset that has a default password. There is no practical access control in this instance.

• An asset has LERC due to a BES Cyber System within it having a wireless card on a public carrier that allows the BES Cyber System to be reachable via a public IP address. In essence, low impact BES Cyber Systems should not be accessible from the Internet and search engines such as Shodan.

• Dual-homing or multiple-network interface cards without disabling IP forwarding in the non-BES Cyber Asset within the DMZ to provide separation between the low impact BES Cyber System(s) and the external network would not meet the intent of “controlling” inbound and outbound electronic access assuming there was no other host-based firewall or other security devices on the non-BES Cyber Asset.

Requirement R2, Attachment 1, Section 4 – Cyber Security Incident Response The entity should have one or more documented Cyber Security Incident response plan(s) that include each of the topics listed in Section 4. If, in the normal course of business, suspicious activities are noted at an asset containing low impact BES Cyber System(s), the intent is for the entity to implement a Cyber Security Incident response plan that will guide the entity in responding to the incident and reporting the incident if it rises to the level of a Reportable Cyber Security Incident.

Entities are provided the flexibility to develop their Attachment 1, Section 4 Cyber Security Incident response plan(s) by asset or group of assets. The plans do not need to be on a per asset site or per low impact BES Cyber System basis. Entities can choose to use a single enterprise-wide plan to fulfill the obligations for low impact BES Cyber Systems.

The plan(s) must be tested once every 36 months. This is not an exercise per low impact BES Cyber Asset or per type of BES Cyber Asset but rather is an exercise of each incident response plan the entity created to meet this requirement. An actual Reportable Cyber Security Incident counts as an exercise as do other forms of tabletop exercises or drills. NERC-led exercises such as GridEx participation would also count as an exercise provided the entity’s response plan is followed. The intent of the requirement is for entities to keep the Cyber Security Incident response plan(s) current, which includes updating the plan(s), if needed, within 180 days following a test or an actual incident.



For low impact BES Cyber Systems, the only portion of the definition of Cyber Security Incident that would apply is‚ “A malicious act or suspicious event that disrupts, or was an attempt to disrupt, the operation of a BES Cyber System.” The other portion of that definition is not to be used to require ESPs and PSPs for low impact BES Cyber Systems. Requirement R2, Attachment 1, Section 5 – Transient Cyber Assets and Removable Media Malicious Code Mitigation Plan(s) Most BES Cyber Assets and BES Cyber Systems are isolated from external public or untrusted networks, and therefore require Transient Cyber Assets and Removable Media to transport files to and from secure areas to maintain, monitor, or troubleshoot critical systems. Transient Cyber Assets and Removable Media are a potential means for cyber-attack. To protect the BES Cyber Assets and BES Cyber Systems, CIP-003, R2 Attachment 1, Section 5 requires entities to document and implement a plan for how they will mitigate the risk of malicious code introduction to BES Cyber Systems from Transient Cyber Assets and Removable Media. The approach of defining a plan allows the Responsible Entity to document processes that are supportable within its organization and in alignment with its change management processes.

Transient Cyber Assets can be one of many types of devices from a specially-designed device for maintaining equipment in support of the BES to a platform such as a laptop, desktop, or tablet that may interface with or run applications that support BES Cyber Systems and is capable of transmitting executable code to the BES Cyber Asset(s) or BES Cyber System(s). Removable Media in scope of this requirement can be in the form of floppy disks, compact disks, USB flash drives, external hard drives, and other flash memory cards/drives that contain nonvolatile memory.

Examples of these temporarily connected devices include, but are not limited to:

• Diagnostic test equipment;

• Equipment used for BES Cyber System maintenance; or

• Equipment used for BES Cyber System configuration.

The attachment was created to specify the capabilities and possible security methods available to Responsible Entities based upon asset type and ownership.

With the list of options provided in Attachment 1 for each control area, the entity has the discretion to use the option(s) that is most appropriate. This includes documenting its approach for how and when the entity reviews the Transient Cyber Asset under its control or under the control of parties other than the Responsible Entity. The entity should avoid implementing a security function that jeopardizes reliability by taking actions that would negatively impact the performance or support of the Transient Cyber Asset or BES Cyber Asset.



Vulnerability Mitigation The terms “mitigate”, “mitigating”, and “mitigation” are used in the sections in Attachment 1 to address the risks posed by malicious code when connecting Transient Cyber Assets and Removable Media to BES Cyber Systems. Mitigation in this context does not require that each vulnerability be individually addressed or remediated, as many may be unknown or not have an impact on the system to which the Transient Cyber Asset or Removable Media is connected. Mitigation is meant to reduce security risks presented by connecting the Transient Cyber Asset.

Per Transient Cyber Asset Capability As with other CIP standards, the requirements are intended for an entity to use the method(s) that the system is capable of performing. The use of “per Transient Cyber Asset capability” is to eliminate the need for a Technical Feasibility Exception when it is understood that the device cannot use a method(s). For example, for malicious code, many types of appliances are not capable of implementing antivirus software; therefore, because it is not a capability of those types of devices, implementation of the antivirus software would not be required for those devices.

Requirement R2, Attachment 1, Section 5.1 - Transient Cyber Asset(s) Managed by the Responsible Entity For Transient Cyber Assets and Removable Media that are connected to both low impact and medium/high impact BES Cyber Systems, entities must be aware of the differing levels of requirements and should consider managing these assets under the program that matches the highest impact level to which they will connect.

Section 5.1: Entities are to document and implement their process(es) to mitigate malicious code through the use of one or more of the protective measures listed. This needs to be applied based on the capability of the Transient Cyber Asset. When addressing malicious code protection, the Responsible Entity should address methods deployed to mitigate the introduction of malicious code. The Responsible Entity has the flexibility to apply the selected method(s) to meet the objective of mitigating the introductions of malicious code either in an on-going or in an on-demand manner. An example of a managed device in an on-going manner is one that has an antivirus solution that is managed as part of an end-point security solution with current signature or pattern updates, regularly scheduled systems scans, etc. An example of managing a device in an on-demand manner may be for devices that are used infrequently whereas the signatures or patterns are not kept current which requires an update to the signatures or patterns and a scan of the device before the device is connected to ensure that it is free of malicious code. Selecting management in an on-going or on-demand manner is not intended to imply that the control has to be verified at every single connection. For example, if the device is managed in an on-demand manner, but will be used to perform maintenance on several BES Cyber Asset(s), the Responsible Entity may choose to document that the Transient Cyber Asset has been updated before being connected as a Transient Cyber Asset for the first use of that maintenance work. If malicious code is discovered, it must be removed or mitigated to prevent it from being introduced into the BES Cyber Asset or BES Cyber System. Entities should also consider whether the detected malicious code is a Cyber Security Incident.



• Antivirus software, including manual or managed updates of signatures or patterns, provides flexibility to manage Transient Cyber Asset(s) by deploying antivirus or endpoint security tools that maintain a scheduled update of the signatures or patterns. Also, for devices that do not regularly connect to receive scheduled updates, entities may choose to update the signatures or patterns and scan the Transient Cyber Asset prior to connection to ensure no malicious software is present.

• Application whitelisting is a method of authorizing only the applications and processes that are necessary on the Transient Cyber Asset. This reduces the risk that malicious software could execute on the Transient Cyber Asset and impact the BES Cyber Asset or BES Cyber System.

• When selecting to use other methods that mitigate the introduction of malicious code to those listed, entities need to have documentation that identifies how the other method(s) meet the mitigation of the introduction of malicious code objective.

Requirement R4, Attachment 1, Section 5.2 - Transient Cyber Asset(s) Managed by a Party Other than the Responsible Entity The attachment also recognizes the lack of control for Transient Cyber Assets that are managed by parties other than the Responsible Entity. However, this does not obviate the Responsible Entity’s responsibility to ensure that methods have been deployed to mitigate the introduction of malicious code on Transient Cyber Assets it does not manage. The requirements listed herein allow entities the ability to review the assets to the best of their capability and to meet their obligations. The use of “prior to connecting the Transient Cyber Assets” is intended to ensure that the Responsible Entity conducts the review before the first connection of the Transient Cyber Asset to ensure that the Transient Cyber Asset is meeting the objective to mitigate the introduction of malicious code. It is not intended that a Responsible Entity conduct a review for every single connection of that Transient Cyber Asset once the Responsible Entity has established the Transient Cyber Asset is meeting the security objective.

To facilitate these controls, Responsible Entities may choose to execute agreements with other parties to provide support services to BES Cyber Systems and BES Cyber Assets that may involve the use of Transient Cyber Assets. Entities may consider using the Department of Energy Cybersecurity Procurement Language for Energy Delivery dated April 2014.1 Procurement language may unify the other party and entity actions supporting the BES Cyber Systems and BES Cyber Assets. CIP program attributes may be considered including roles and responsibilities, access controls, monitoring, logging, vulnerability, and patch management along with incident response and back up recovery may be part of the other party’s support. Entities should consider the “General Cybersecurity Procurement Language” and “The Supplier’s Life Cycle Security Program” when drafting Master Service Agreements, Contracts, and the CIP program processes and controls.

1



Section 5.2: Entities are to document and implement their process(es) to mitigate the introduction of malicious code through the use of one or more of the protective measures listed.

• Review the use of antivirus software and signature or pattern levels to ensure that the level is adequate to the Responsible Entity to mitigate the risk of malicious software being introduced to an applicable system.

• Review the antivirus or endpoint security processes of the other party to ensure that their processes are adequate to the Responsible Entity to mitigate the risk of introducing malicious software to an applicable system.

• Review the use of application whitelisting used by the other party to mitigate the risk of introducing malicious software to an applicable system.

• Review the use of live operating systems or software executable only from read-only media to ensure that the media is free from malicious software itself. Entities should review the processes to build the read-only media as well as the media itself.

• Review system hardening practices used by the other party to ensure that unnecessary ports, services, applications, etc. have been disabled or removed. This will reduce the attack surface on the Transient Cyber Asset and reduce the avenues by which malicious software could be introduced.

Requirement R4, Attachment 1, Section 5.3 - Removable Media Entities have a high level of control for Removable Media that are going to be connected to their BES Cyber Assets.

Section 5.3: Entities are to document and implement their process(es) to mitigate the introduction of malicious code through the use of one or more method(s) to detect malicious code on the Removable Media before it is connected to a BES Cyber Asset. When using the method(s) to detect malicious code, it is expected to occur from a system that is not part of the BES Cyber System to reduce the risk of propagating malicious code into the BES Cyber System network or onto one of the BES Cyber Assets. If malicious code is discovered, it must be removed or mitigated to prevent it from being introduced into the BES Cyber Asset or BES Cyber System. Entities should also consider whether the detected malicious code is a Cyber Security Incident. Frequency and timing of the methods used to detect malicious code were intentionally excluded from the requirement because there are multiple timing scenarios that can be incorporated into a plan to mitigate the risk of malicious code.

As a method to detect malicious code, entities may choose to use Removable Media with on-board malicious code detection tools. For these tools, the Removable Media are still used in conjunction with a Cyber Asset to perform the detection. For Section 5.3.1, the Cyber Asset used to perform the malicious code detection must be outside of the BES Cyber System.



Requirement R3: The intent of CIP-003-7, Requirement R3 is effectively unchanged since prior versions of the standard. The specific description of the CIP Senior Manager has now been included as a defined term rather than clarified in the Reliability Standard itself to prevent any unnecessary cross-reference to this standard. It is expected that the CIP Senior Manager will play a key role in ensuring proper strategic planning, executive/board-level awareness, and overall program governance. Requirement R4: As indicated in the rationale for CIP-003-7, Requirement R4, this requirement is intended to demonstrate a clear line of authority and ownership for security matters. The intent of the SDT was not to impose any particular organizational structure, but, rather, the intent is to afford the Responsible Entity significant flexibility to adapt this requirement to its existing organizational structure. A Responsible Entity may satisfy this requirement through a single delegation document or through multiple delegation documents. The Responsible Entity can make use of the delegation of the delegation authority itself to increase the flexibility in how this applies to its organization. In such a case, delegations may exist in numerous documentation records as long as the collection of these documentation records shows a clear line of authority back to the CIP Senior Manager. In addition, the CIP Senior Manager could also choose not to delegate any authority and meet this requirement without such delegation documentation.

The Responsible Entity must keep its documentation of the CIP Senior Manager and any delegations up-to-date. This is to ensure that individuals do not assume any undocumented authority. However, delegations do not have to be re-instated if the individual who delegated the task changes roles or the individual is replaced. For instance, assume that John Doe is named the CIP Senior Manager and he delegates a specific task to the Substation Maintenance Manager. If John Doe is replaced as the CIP Senior Manager, the CIP Senior Manager documentation must be updated within the specified timeframe, but the existing delegation to the Substation Maintenance Manager remains in effect as approved by the previous CIP Senior Manager, John Doe. Rationale: During development of this standard, text boxes were embedded within the standard to explain the rationale for various parts of the standard. Upon Board approval, the text from the rationale text boxes was moved to this section. Rationale for Requirement R1: One or more security policies enable effective implementation of the requirements of the cyber security Reliability Standards. The purpose of policies is to provide a management and governance foundation for all requirements that apply to a Responsible Entity’s BES Cyber Systems. The Responsible Entity can demonstrate through its policies that its management supports the accountability and responsibility necessary for effective implementation of the requirements.



Annual review and approval of the cyber security policies ensures that the policies are kept-up-to-date and periodically reaffirms management’s commitment to the protection of its BES Cyber Systems. Rationale for Requirement R2: In response to FERC Order No. 791, Requirement R2 requires entities to develop and implement cyber security plans to meet specific security control objectives for assets containing low impact BES Cyber System(s). The cyber security plan(s) covers four subject matter areas: (1) cyber security awareness; (2) physical security controls; (3) electronic access controls; and (4) Cyber Security Incident response. This plan(s), along with the cyber security policies required under Requirement R1, Part 1.2, provides a framework for operational, procedural, and technical safeguards for low impact BES Cyber Systems.

Considering the varied types of low impact BES Cyber Systems across the BES, Attachment 1 provides Responsible Entities flexibility on how to apply the security controls to meet the security objectives. Additionally, because many Responsible Entities have multiple-impact rated BES Cyber Systems, nothing in the requirement prohibits entities from using their high and medium impact BES Cyber System policies, procedures, and processes to implement security controls required for low impact BES Cyber Systems, as detailed in Requirement R2, Attachment 1.

Responsible Entities will use their identified assets containing low impact BES Cyber System(s) (developed pursuant to CIP-002) to substantiate the sites or locations associated with low impact BES Cyber System(s). However, there is no requirement or compliance expectation for Responsible Entities to maintain a list(s) of individual low impact BES Cyber System(s) and their associated cyber assets or to maintain a list of authorized users. Rationale for Requirement R3: The identification and documentation of the single CIP Senior Manager ensures that there is clear authority and ownership for the CIP program within an organization, as called for in Blackout Report Recommendation 43. The language that identifies CIP Senior Manager responsibilities is included in the Glossary of Terms used in NERC Reliability Standards so that it may be used across the body of CIP standards without an explicit cross-reference.

FERC Order No. 706, Paragraph 296, requests consideration of whether the single senior manager should be a corporate officer or equivalent. As implicated through the defined term, the senior manager has “the overall authority and responsibility for leading and managing implementation of the requirements within this set of standards” which ensures that the senior manager is of sufficient position in the Responsible Entity to ensure that cyber security receives the prominence that is necessary. In addition, given the range of business models for responsible entities, from municipal, cooperative, federal agencies, investor owned utilities, privately owned utilities, and everything in between, the SDT believes that requiring the CIP Senior Manager to be a “corporate officer or equivalent” would be extremely difficult to interpret and enforce on a consistent basis.



Rationale for Requirement R4: The intent of the requirement is to ensure clear accountability within an organization for certain security matters. It also ensures that delegations are kept up-to-date and that individuals do not assume undocumented authority.

In FERC Order No. 706, Paragraphs 379 and 381, the Commission notes that Recommendation 43 of the 2003 Blackout Report calls for “clear lines of authority and ownership for security matters.” With this in mind, the Standard Drafting Team has sought to provide clarity in the requirement for delegations so that this line of authority is clear and apparent from the documented delegations.






Previously, the Guidelines and Technical Basis had approximately 10 pages of explanation and numerous reference models to describe different forms of direct vs. indirect access that could be used to determine whether Low Impact External Routable Connectivity existed and thus whether a Low Impact BES Cyber System Electronic Access Point (LEAP) was required. In this revision, the term Low Impact External Routable Connectivity has been changed to Low Impact External Routable Communication (LERC) and simplified so that it is an attribute of a BES asset concerning whether there is routable protocol communications across the asset boundary without regard to 'direct vs. indirect' access that may occur. This greatly simplifies and clarifies the definition of LERC. It removes the dependency between the electronic access controls that may be in place and having those controls determine whether LERC exists or not. For those BES assets that have LERC, the SDT changed the requirement from requiring a LEAP to requiring electronic access controls to “permit only necessary electronic access to low impact BES Cyber Systems” (revised Attachment 1, Section 3.1) within the BES asset and expanded the Guidelines and Technical Basis with numerous examples of electronic access controls. Given the modified definition of LERC and the proposed modifications in Reliability CIP-003-7, there is no longer a need for the NERC Glossary term Low Impact BES Cyber System Electronic Access Point (LEAP). Consequently, NERC is proposing that term for retirement.

In summary, the CIP Standard Drafting Team revised CIP-003-7, Attachments 1 and 2, Sections 2 and 3 and the associated High VSL for Requirement R2. Non-substantive errata changes were also made within the standard, including changing “ES-ISAC” to “E-ISAC”.










NERC Board of Trustees (BOT) adoption November, 2016




2. Number: CIP-003-7(i)


4. Applicability:



























All BES Facilities.

4.2.3 Exemptions: The following are exempt from Standard CIP-003-7(i):







5. Effective Dates:

See Implementation Plan for CIP-003-7(i).

6. Background:

















Compliance Audits

Self-Certifications

Spot Checking


Self-Reporting

Complaints










OR



OR



OR



OR


OR







OR



OR



OR


OR



OR







OR


OR


OR


OR



OR


OR


OR


OR


OR







OR



OR













OR



OR



OR


The Responsible Entity failed to document or and implement one or more cyber security plan(s) for its assets containing low impact BES Cyber Systems according to Requirement R2, Attachment 1. (R2).







OR


OR


OR



OR


OR







The Responsible Entity documented its plan(s) for Transient Cyber Assets and Removable Media, but failed to manage its Transient Cyber Asset(s) according to Requirement R2, Attachment 1, Section 5.1. (R2)

OR

The Responsible Entity documented its plan(s) for Transient Cyber Assets and Removable Media, but failed to document the Removable Media sections according to Requirement R2, Attachment 1, Section 5.3. (R2)


OR


OR



OR

The Responsible Entity documented its plan(s) for Transient Cyber Assets and Removable Media, but failed to implement mitigation for the introduction of malicious code for Transient Cyber Assets managed by the Responsible Entity according to Requirement R2, Attachment 1, Section 5.1. (R2)

OR







OR

The Responsible Entity documented its plan(s) for Transient Cyber Assets and Removable Media plan, but failed to document mitigation for the introduction of malicious code for Transient Cyber Assets managed by the Responsible Entity according to Requirement R2,

The Responsible Entity documented its plan(s) for Transient Cyber Assets and Removable Media, but failed to implement mitigation for the introduction of malicious code for Transient Cyber Assets managed by a party other than the Responsible Entity according to Requirement R2, Attachment 1, Section 5.2. (R2)

OR

The Responsible Entity documented its plan(s) for Transient Cyber Assets and Removable Media, but failed to implement mitigation for threat of detected malicious code on the Removable Media prior to connecting






Attachment 1, Sections 5.1 and 5.3. (R2)

OR

The Responsible Entity documented its plan(s) for Transient Cyber Assets and Removable Media, but failed to document mitigation for the introduction of malicious code for Transient Cyber Assets managed by a party other than the Responsible Entity according to Requirement R2, Attachment 1, Section 5.2. (R2)

OR

The Responsible Entity documented its plan(s) for

Removable Media to a low impact BES Cyber System according to Requirement R2, Attachment 1, Section 5.3. (R2)






Transient Cyber Assets and Removable Media, but failed to implement the Removable Media section(s) according to Requirement R2, Attachment 1, Section 5.3. (R2)






OR

The Responsible Entity has identified by name a CIP Senior Manager, but did not document changes to the CIP Senior Manager within 60 calendar days of the change. (R3)











OR




Version History
















Attachment 1


















Rationale for Section 5 of Attachment 1 (Requirement R2):

Requirement R2 mandates that entities develop and implement one or more cyber security plan(s) to meet specific security control objectives for assets containing low impact BES Cyber System(s). In Paragraph 32 of FERC Order No. 822, the Commission directed NERC to “…provide mandatory protection for transient devices used at Low Impact BES Cyber Systems based on the risk posed to bulk electric system reliability.” Transient devices are potential vehicles for introducing malicious code into a facility and subsequently into low impact BES Cyber Systems. Section 5 of Attachment 1 is intended to mitigate the risk of malware propagation to the BES through low impact BES Cyber Systems by requiring entities to develop and implement one or more Transient Cyber Asset and Removable Media Malicious Code Mitigation plan(s). The cyber security plan(s) along with the cyber security policies required under Requirement R1, Part 1.2, provide a framework for operational, procedural, and technical safeguards for low impact BES Cyber Systems.

Section 5. Transient Cyber Asset and Removable Media Malicious Code Mitigation Plan(s): Each Responsible Entity shall implement one or more plan(s) to achieve the objective of mitigating the introduction of malicious code to low impact BES Cyber Systems through the use of Transient Cyber Assets or Removable Media, which shall include:

5.1 For Transient Cyber Asset(s) managed by the Responsible Entity, if any, use of one or a combination of the following methods in an ongoing or on-demand manner (per Transient Cyber Asset capability):

• Antivirus software, including manual or managed updates of signatures or patterns;

• Application whitelisting; or


5.2 For Transient Cyber Asset(s) managed by a party other than the Responsible Entity, if any, use of one or a combination of the following methods prior to connecting the Transient Cyber Asset to a low impact BES Cyber System (per Transient Cyber Asset capability):

• Review of antivirus update level;



• Review of antivirus update process used by the party;

• Review of application whitelisting used by the party;

• Review use of live operating system and software executable only from read-only media;

• Review of system hardening used by the party; or


5.3 For Removable Media, perform each of the following:

5.3.1 Use of method(s) to detect malicious code on Removable Media using a Cyber Asset other than a BES Cyber System; and

5.3.2 Mitigation of the threat of detected malicious code on the Removable Media prior to connecting Removable Media to a low impact BES Cyber System.



Attachment 2



• Direct communications (for example, e-mails, memos, or computer-based training);



















Section 5. Transient Cyber Asset and Removable Media Malicious Code Mitigation Plan(s):

1. Examples of evidence for Section 5.1 may include, but are not limited to, documentation of the method(s) used to mitigate the introduction of malicious code such as antivirus software and processes for managing signature or pattern updates, application whitelisting practices, processes to restrict communication, or other method(s) to mitigate the introduction of malicious code. If a Transient Cyber Asset does not have the capability to use method(s) that mitigate the introduction of malicious code, evidence may include documentation by the vendor or Responsible Entity that identifies that the Transient Cyber Asset does not have the capability.

2. Examples of evidence for Section 5.2 may include, but are not limited to, documentation from change management systems, electronic mail or procedures that document a review of the installed antivirus update level; memoranda, electronic mail, system documentation, policies or contracts from the party other than the Responsible Entity that identify the antivirus update process, the use of application whitelisting, use of live operating systems or system hardening performed by the party other than the Responsible Entity; evidence from change management systems, electronic mail or contracts that identifies the Responsible Entity’s acceptance that the practices of the party other than the Responsible Entity are acceptable; or documentation of other method(s) to mitigate malicious code for Transient Cyber Asset(s) managed by a party other than the Responsible Entity. If a Transient Cyber Asset does not have the capability to use method(s) that mitigate the introduction of malicious code, evidence may include documentation by the Responsible Entity or the party



other than the Responsible Entity that identifies that the Transient Cyber Asset does not have the capability

3. Examples of evidence for Section 5.3.1 may include, but are not limited to, documented process(es) of the method(s) used to mitigate malicious code such as results of scan settings for Removable Media, or implementation of on-demand scanning. Examples of evidence for Section 5.3.2 may include, but are not limited to, documented process(es) for the method(s) used for mitigating the threat of detected malicious code on Removable Media, such as logs from the method(s) used to detect malicious code that show the results of scanning and the mitigation of detected malicious code on Removable Media or documented confirmation by the entity that the Removable Media was deemed to be free of malicious code.




BES Asset Boundary

SerialNon-routable

Protocol

Non-BES Cyber Asset

Non-BES Cyber Asset

RoutableProtocol

Air Gap

LERC

Low impactBES Cyber

System

Low impactBES Cyber

System

Non-BES Cyber Asset


Reference Model 1




BES Asset Boundary

RoutableProtocol

LERC


Low impactBES Cyber

System

Non-BES Cyber Asset

Non-BES Cyber Asset

Low impactBES Cyber

System


`


Reference Model 2




BES Asset Boundary

RoutableProtocol

LERC

Low impactBES Cyber

System


Reference Model 3




BES Asset Boundary

LERC

SerialNon-Routable

Protocol

Low impactBES Cyber

System

Network

Low impactBES Cyber

System

IP/SerialConverter

RoutableProtocol


Reference Model 4




Reference Model 5

Location X


LERCLERC

`


RoutableProtocol

RoutableProtocol

Network Network


Low impactBES Cyber

SystemNon BES Cyber

System

Low impactBES Cyber

System

RoutableProtocol





BES Asset Boundary

RoutableProtocol

LERC

Low impactBES Cyber

System



Reference Model 6




BES Asset Boundary

RoutableProtocol

LERC

Low impactBES Cyber

System



Reference Model 7




Reference Model 8

BES Asset Boundary

Network

Low impactBES Cyber

System

DMZ


RoutableProtocol


LERC





BES Asset Boundary


Network

Non BES CyberSystem

Low impactBES Cyber

System

RoutableProtocol

Network


System with ERC

EAP Interface

ESP

LERC

ERC


Reference Model 9



For low impact BES Cyber Systems, the only portion of the definition of Cyber Security Incident that would apply is‚ “A malicious act or suspicious event that disrupts, or was an attempt to disrupt, the operation of a BES Cyber System.” The other portion of that definition is not to be used to require ESPs and PSPs for low impact BES Cyber Systems. Requirement R2, Attachment 1, Section 5 – Transient Cyber Assets and Removable Media Malicious Code Mitigation Plan(s) Most BES Cyber Assets and BES Cyber Systems are isolated from external public or untrusted networks, and therefore require Transient Cyber Assets and Removable Media to transport files to and from secure areas to maintain, monitor, or troubleshoot critical systems. Transient Cyber Assets and Removable Media are a potential means for cyber-attack. To protect the BES Cyber Assets and BES Cyber Systems, CIP-003, R2 Attachment 1, Section 5 requires entities to document and implement a plan for how they will mitigate the risk of malicious code introduction to BES Cyber Systems from Transient Cyber Assets and Removable Media. The approach of defining a plan allows the Responsible Entity to document processes that are supportable within its organization and in alignment with its change management processes.

Transient Cyber Assets can be one of many types of devices from a specially-designed device for maintaining equipment in support of the BES to a platform such as a laptop, desktop, or tablet that may interface with or run applications that support BES Cyber Systems and is capable of transmitting executable code to the BES Cyber Asset(s) or BES Cyber System(s). Removable Media in scope of this requirement can be in the form of floppy disks, compact disks, USB flash drives, external hard drives, and other flash memory cards/drives that contain nonvolatile memory.

Examples of these temporarily connected devices include, but are not limited to:

• Diagnostic test equipment;

• Equipment used for BES Cyber System maintenance; or

• Equipment used for BES Cyber System configuration.

The attachment was created to specify the capabilities and possible security methods available to Responsible Entities based upon asset type and ownership.

With the list of options provided in Attachment 1 for each control area, the entity has the discretion to use the option(s) that is most appropriate. This includes documenting its approach for how and when the entity reviews the Transient Cyber Asset under its control or under the control of parties other than the Responsible Entity. The entity should avoid implementing a security function that jeopardizes reliability by taking actions that would negatively impact the performance or support of the Transient Cyber Asset or BES Cyber Asset.



Vulnerability Mitigation The terms “mitigate”, “mitigating”, and “mitigation” are used in the sections in Attachment 1 to address the risks posed by malicious code when connecting Transient Cyber Assets and Removable Media to BES Cyber Systems. Mitigation in this context does not require that each vulnerability be individually addressed or remediated, as many may be unknown or not have an impact on the system to which the Transient Cyber Asset or Removable Media is connected. Mitigation is meant to reduce security risks presented by connecting the Transient Cyber Asset.

Per Transient Cyber Asset Capability As with other CIP standards, the requirements are intended for an entity to use the method(s) that the system is capable of performing. The use of “per Transient Cyber Asset capability” is to eliminate the need for a Technical Feasibility Exception when it is understood that the device cannot use a method(s). For example, for malicious code, many types of appliances are not capable of implementing antivirus software; therefore, because it is not a capability of those types of devices, implementation of the antivirus software would not be required for those devices.

Requirement R2, Attachment 1, Section 5.1 - Transient Cyber Asset(s) Managed by the Responsible Entity For Transient Cyber Assets and Removable Media that are connected to both low impact and medium/high impact BES Cyber Systems, entities must be aware of the differing levels of requirements and should consider managing these assets under the program that matches the highest impact level to which they will connect.

Section 5.1: Entities are to document and implement their process(es) to mitigate malicious code through the use of one or more of the protective measures listed. This needs to be applied based on the capability of the Transient Cyber Asset. When addressing malicious code protection, the Responsible Entity should address methods deployed to mitigate the introduction of malicious code. The Responsible Entity has the flexibility to apply the selected method(s) to meet the objective of mitigating the introductions of malicious code either in an on-going or in an on-demand manner. An example of a managed device in an on-going manner is one that has an antivirus solution that is managed as part of an end-point security solution with current signature or pattern updates, regularly scheduled systems scans, etc. An example of managing a device in an on-demand manner may be for devices that are used infrequently whereas the signatures or patterns are not kept current which requires an update to the signatures or patterns and a scan of the device before the device is connected to ensure that it is free of malicious code. Selecting management in an on-going or on-demand manner is not intended to imply that the control has to be verified at every single connection. For example, if the device is managed in an on-demand manner, but will be used to perform maintenance on several BES Cyber Asset(s), the Responsible Entity may choose to document that the Transient Cyber Asset has been updated before being connected as a Transient Cyber Asset for the first use of that maintenance work. If malicious code is discovered, it must be removed or mitigated to prevent it from being introduced into the BES Cyber Asset or BES Cyber System. Entities should also consider whether the detected malicious code is a Cyber Security Incident.



• Antivirus software, including manual or managed updates of signatures or patterns, provides flexibility to manage Transient Cyber Asset(s) by deploying antivirus or endpoint security tools that maintain a scheduled update of the signatures or patterns. Also, for devices that do not regularly connect to receive scheduled updates, entities may choose to update the signatures or patterns and scan the Transient Cyber Asset prior to connection to ensure no malicious software is present.

• Application whitelisting is a method of authorizing only the applications and processes that are necessary on the Transient Cyber Asset. This reduces the risk that malicious software could execute on the Transient Cyber Asset and impact the BES Cyber Asset or BES Cyber System.

• When selecting to use other methods that mitigate the introduction of malicious code to those listed, entities need to have documentation that identifies how the other method(s) meet the mitigation of the introduction of malicious code objective.

Requirement R4, Attachment 1, Section 5.2 - Transient Cyber Asset(s) Managed by a Party Other than the Responsible Entity The attachment also recognizes the lack of control for Transient Cyber Assets that are managed by parties other than the Responsible Entity. However, this does not obviate the Responsible Entity’s responsibility to ensure that methods have been deployed to mitigate the introduction of malicious code on Transient Cyber Assets it does not manage. The requirements listed herein allow entities the ability to review the assets to the best of their capability and to meet their obligations. The use of “prior to connecting the Transient Cyber Assets” is intended to ensure that the Responsible Entity conducts the review before the first connection of the Transient Cyber Asset to ensure that the Transient Cyber Asset is meeting the objective to mitigate the introduction of malicious code. It is not intended that a Responsible Entity conduct a review for every single connection of that Transient Cyber Asset once the Responsible Entity has established the Transient Cyber Asset is meeting the security objective.

To facilitate these controls, Responsible Entities may choose to execute agreements with other parties to provide support services to BES Cyber Systems and BES Cyber Assets that may involve the use of Transient Cyber Assets. Entities may consider using the Department of Energy Cybersecurity Procurement Language for Energy Delivery dated April 2014.1 Procurement language may unify the other party and entity actions supporting the BES Cyber Systems and BES Cyber Assets. CIP program attributes may be considered including roles and responsibilities, access controls, monitoring, logging, vulnerability, and patch management along with incident response and back up recovery may be part of the other party’s support. Entities should consider the “General Cybersecurity Procurement Language” and “The Supplier’s Life Cycle Security Program” when drafting Master Service Agreements, Contracts, and the CIP program processes and controls.

1 http://www.energy.gov/oe/downloads/cybersecurity-procurement-language-energy-delivery-april-2014

http://www.energy.gov/oe/downloads/cybersecurity-procurement-language-energy-delivery-april-2014



Section 5.2: Entities are to document and implement their process(es) to mitigate the introduction of malicious code through the use of one or more of the protective measures listed.

• Review the use of antivirus software and signature or pattern levels to ensure that the level is adequate to the Responsible Entity to mitigate the risk of malicious software being introduced to an applicable system.

• Review the antivirus or endpoint security processes of the other party to ensure that their processes are adequate to the Responsible Entity to mitigate the risk of introducing malicious software to an applicable system.

• Review the use of application whitelisting used by the other party to mitigate the risk of introducing malicious software to an applicable system.

• Review the use of live operating systems or software executable only from read-only media to ensure that the media is free from malicious software itself. Entities should review the processes to build the read-only media as well as the media itself.

• Review system hardening practices used by the other party to ensure that unnecessary ports, services, applications, etc. have been disabled or removed. This will reduce the attack surface on the Transient Cyber Asset and reduce the avenues by which malicious software could be introduced.

Requirement R4, Attachment 1, Section 5.3 - Removable Media Entities have a high level of control for Removable Media that are going to be connected to their BES Cyber Assets.

Section 5.3: Entities are to document and implement their process(es) to mitigate the introduction of malicious code through the use of one or more method(s) to detect malicious code on the Removable Media before it is connected to a BES Cyber Asset. When using the method(s) to detect malicious code, it is expected to occur from a system that is not part of the BES Cyber System to reduce the risk of propagating malicious code into the BES Cyber System network or onto one of the BES Cyber Assets. If malicious code is discovered, it must be removed or mitigated to prevent it from being introduced into the BES Cyber Asset or BES Cyber System. Entities should also consider whether the detected malicious code is a Cyber Security Incident. Frequency and timing of the methods used to detect malicious code were intentionally excluded from the requirement because there are multiple timing scenarios that can be incorporated into a plan to mitigate the risk of malicious code.

As a method to detect malicious code, entities may choose to use Removable Media with on-board malicious code detection tools. For these tools, the Removable Media are still used in conjunction with a Cyber Asset to perform the detection. For Section 5.3.1, the Cyber Asset used to perform the malicious code detection must be outside of the BES Cyber System.



Requirement R3: The intent of CIP-003-7, Requirement R3 is effectively unchanged since prior versions of the standard. The specific description of the CIP Senior Manager has now been included as a defined term rather than clarified in the Reliability Standard itself to prevent any unnecessary cross-reference to this standard. It is expected that the CIP Senior Manager will play a key role in ensuring proper strategic planning, executive/board-level awareness, and overall program governance. Requirement R4: As indicated in the rationale for CIP-003-7, Requirement R4, this requirement is intended to demonstrate a clear line of authority and ownership for security matters. The intent of the SDT was not to impose any particular organizational structure, but, rather, the intent is to afford the Responsible Entity significant flexibility to adapt this requirement to its existing organizational structure. A Responsible Entity may satisfy this requirement through a single delegation document or through multiple delegation documents. The Responsible Entity can make use of the delegation of the delegation authority itself to increase the flexibility in how this applies to its organization. In such a case, delegations may exist in numerous documentation records as long as the collection of these documentation records shows a clear line of authority back to the CIP Senior Manager. In addition, the CIP Senior Manager could also choose not to delegate any authority and meet this requirement without such delegation documentation.

The Responsible Entity must keep its documentation of the CIP Senior Manager and any delegations up-to-date. This is to ensure that individuals do not assume any undocumented authority. However, delegations do not have to be re-instated if the individual who delegated the task changes roles or the individual is replaced. For instance, assume that John Doe is named the CIP Senior Manager and he delegates a specific task to the Substation Maintenance Manager. If John Doe is replaced as the CIP Senior Manager, the CIP Senior Manager documentation must be updated within the specified timeframe, but the existing delegation to the Substation Maintenance Manager remains in effect as approved by the previous CIP Senior Manager, John Doe. Rationale: During development of this standard, text boxes were embedded within the standard to explain the rationale for various parts of the standard. Upon BOT approval, the text from the rationale text boxes was moved to this section. Rationale for Requirement R1: One or more security policies enable effective implementation of the requirements of the cyber security Reliability Standards. The purpose of policies is to provide a management and governance foundation for all requirements that apply to a Responsible Entity’s BES Cyber Systems. The Responsible Entity can demonstrate through its policies that its management supports the accountability and responsibility necessary for effective implementation of the requirements.






FERC Order No. 706, Paragraph 296, requests consideration of whether the single senior manager should be a corporate officer or equivalent. As implicated through the defined term, the senior manager has “the overall authority and responsibility for leading and managing implementation of the requirements within this set of standards” which ensures that the senior manager is of sufficient position in the Responsible Entity to ensure that cyber security receives the prominence that is necessary. In addition, given the range of business models for responsible entities, from municipal, cooperative, federal agencies, investor owned utilities, privately owned utilities, and everything in between, the SDT believes that requiring the CIP Senior Manager to be a “corporate officer or equivalent” would be extremely difficult to interpret and enforce on a consistent basis.



Rationale for Requirement R4: The intent of the requirement is to ensure clear accountability within an organization for certain security matters. It also ensures that delegations are kept up-to-date and that individuals do not assume undocumented authority.


CIP-003-7 - Cyber Security — Security Management Controls

Draft 1 of CIP-003-7 July 2016 Page 1 of 45




Previously, the Guidelines and Technical Basis had approximately 10 pages of explanation and numerous reference models to describe different forms of direct vs. indirect access that could be used to determine whether Low Impact External Routable Connectivity existed and thus whether a Low Impact BES Cyber System Electronic Access Point (LEAP) was required. In this revision, the term Low Impact External Routable Connectivity has been changed to Low Impact External Routable Communication (LERC) and simplified so that it is an attribute of a BES asset concerning whether there is routable protocol communications across the asset boundary without regard to 'direct vs. indirect' access that may occur. This greatly simplifies and clarifies the definition of LERC. It removes the dependency between the electronic access controls that may be in place and having those controls determine whether LERC exists or not. For those BES assets that have LERC, the standard drafting team (SDT) changed the requirement from requiring a LEAP to requiring electronic access controls to “permit only necessary electronic access to low impact BES Cyber Systems” (revised Attachment 1, Section 3.1) within the BES asset and expanded the Guidelines and Technical Basis with numerous examples of electronic access controls. Given the modified definition of LERC and the proposed modifications in Reliability CIP-003-7, there is no longer a need for the NERC Glossary term Low Impact BES Cyber System Electronic Access Point (LEAP). Consequently, NERC is proposing that term for retirement.

In summary, the CIP SDT revised CIP-003-7, Attachments 1 and 2, Sections 2 and 3 and the associated High VSL for Requirement R2. Non-substantive errata changes were also made within the standard, including changing “ES-ISAC” to “E-ISAC”.










NERC Board of Trustees (Board) adoption November, 2016




2. Number: CIP-003-7


4. Applicability:



























All BES Facilities.

4.2.3 Exemptions: The following are exempt from Standard CIP-003-7:







5. Effective Dates:

See Implementation Plan for CIP-003-7.

6. Background:

















Compliance Audits

Self-Certifications

Spot Checking


Self-Reporting

Complaints










OR



OR



OR



OR


OR







OR



OR



OR


OR



OR







OR


OR


OR


OR



OR


OR


OR


OR


OR







OR



OR













OR



OR



OR


The Responsible Entity failed to document or implement one or more cyber security plan(s) for its assets containing low impact BES Cyber Systems according to Requirement R2, Attachment 1. (R2).







OR



OR



OR


OR








OR


OR














OR

The Responsible Entity has identified by name a CIP Senior Manager, but did not document changes to the CIP Senior Manager within 60 calendar






days of the change. (R3)






OR
