agenda critical infrastructure protection committee meeting

RELIABILITY | RESILIENCE | SECURITY

Agenda Critical Infrastructure Protection Committee Meeting September 17, 2019 | 1:00-5:00 p.m. Central September 18, 2019 | 8:00 a.m.-12:00 p.m. Central

Intercontinental – Minneapolis/St. Paul Airport 5005 Glumack Drive Minneapolis, MN 55450

Call to Order

NERC Antitrust Compliance Guidelines and Public Announcement

Introduction and Chair’s Remarks

1. Administrative Items – Tom Hofstetter, NERC Staff, CIPC Secretary

a. Safety Briefing and Emergency Precautions – Intercontinental hotel staff

b. Welcoming Remarks – Steve Brown, Vice President, Enterprise Security Services and ChiefSecurity Officer of Xcel Energy

c. Declaration of CIPC Quorum

d. Parliamentary Procedures – In the absence of specific provisions in the CIPC charter, thecommittee shall conduct its meetings guided by the most recent edition of Robert’s Rules ofOrder, Newly Revised.

e. Participant Conduct Policy

f. Introductions

g. CIPC Roster

Consent Agenda – Approve

2. Minutes*

a. June, 2019 Meeting Minutes

Regular Agenda

3. Remarks and Reports – Chair Child

a. Work Plan*

b. Board of Trustees meeting summary

https://www.nerc.com/gov/Annual%20Reports/NERC_Participant_Conduct_Policy.pdf

https://extranet.nerc.net/CIProtectionComm/GeneralDocuments/CIPC_Roster_5-2019.pdf

Agenda – Critical Infrastructure Protection Committee Meeting – September 17-18, 2019 2

4. Stakeholder Engagement Team (SET)* – Lloyd Linke, NERC Operating Committee (OC)

5. Nominating Committee Report – Chair Larry Bugh, Reliability First

6. Agency Updates

a. Federal Energy Regulatory Commission – Joshua Okoniewski,OER; Jim McGlone, OEIS

b. Department of Energy – no report

c. Department of Homeland Security – Ron Keen, DHS

d. Public Safety Canada – no report

7. NERC Update

a. Compliance – Kiel Lyons, NERC Staff

b. Supply Chain – Howard Gugel, NERC Staff

c. Standards Development* – Jay Cribb, Southern Co.

8. Reliability Issues Steering Committee (RISC) Update* – Chuck Abell, Ameren

9. E-ISAC Updates

a. E-ISAC long term plan and highlights* – Sam Chanoski, E-ISAC

b. Cyber Security* – Carlo Castañeda, E-ISAC Staff

c. Physical Security* – Benjamin Gibson, E-ISAC Staff

d. E-ISAC Physical Security Advisory Group (PSAG)* – Mike Bowen

10. National Laboratory Updates

a. Argonne National Laboratory* – Steve Folga, ANL;James Kavicky, ANL

b. Idaho National Laboratory – Andrew Bochman, INL

c. Oak Ridge National Laboratory – Thomas King, ORNL

d. Pacific Northwest National Laboratory – no report

11. Research and Development Updates

a. EPRI* – Tobias Whitney, EPRI

b. SEEDS Cybersecurity Research Center: "Research in Vulnerability Intelligence"* – Philip Huff,UALR; Dr. Qinhua Li, UALR

12. Industry Group Updates*

a. CEA: Canadian Legislative Highlights – Ross Johnson, Bridgehead Security

b. EEI: U.S. Legislative Highlights* – Andrea Koch, EEI

c. North American Generator Forum – no report

d. North American Transmission Forum* – Chuck Abell, Ameren


e. EnergySec* – Steve Parker, EnergySec

13. Policy Working Group Updates – Chair Jeffrey Fuller, AES Corporation

a. Security Metrics Working Group (SMWG) – Chair Larry Bugh, ReliabilityFirst

i. SMWG Final Report*

b. Compliance Input Working Group (CIWG)* – Chair Paul Crist, Lincoln Electric System

i. Cloud Implementation Guidance

(1) Federal Risk and Authorization Management Program (FedRAMP)

(2) Bulk Electric System Cyber System Information (BCSI)

(3) Tabletops

c. DEIRTF

14. Operating Security Working Group Updates – Chair Chuck Abell, Ameren

a. Grid Exercise Working Group (GEWG) Update – Chair Jake Schmitter, E-ISAC Staff; Vice Chair Stuart Brindley, S. J. Brindley Consulting, Inc.

b. Supply Chain Working Group (SCWG) Approve – Chair Tony Eddleman, NPPD

i. Security Guidelines*

(1) Secure Equipment Delivery

(2) Open Source Software

(3) Risk Management Lifecycle

(4) Vendor Risk Management Lifecycle

(5) Provenance

15. Cybersecurity Working Group Updates – Chair Brenda Davis, CPS Energy

a. Security Training Working Group (STWG) – Chair Amelia Anderson, CenterPoint Energy

i. Training agenda (Review)*

b. Remote Access Guideline Task Force (RAGTF) Approve – Chair Davis

i. Scope document*

16. Physical Security Working Group Updates – Chair Ross Johnson, Bridgehead Security Consulting, Inc.

a. Physical Security Working Group (PSWG)

b. Physical Security Guidelines Task Force (PSGTF) – Chair Darrell Klimitchek, South Texas Electric Cooperative.

c. Other – Chair Johnson


i. Alberta Provincial Physical Security Projects

17. Roundtable

a. Smart Grid Cybersecurity Workshop* – Mike Kraft, Basin Electric Power Cooperative

IEEE SMART GRID Cybersecurity Workshop

b. Classified Briefing December – process & deadlines

c. from June: increasing threat from UAV/drones; is now the time for pursuing guidance?

d. Update CIP requirements to NIST cybersecurity framework

18. Technology support

19. Schedule of Important Dates*:

2019 Meeting Dates Date Organization Event Location Venue Remarks

Sep. 17-18 NERC CIPC meeting Minneapolis Intercontinental, Minneapolis - St. Paul Airport

Details

Oct. 22-25 E-ISAC Grid Security Conference (GridSecCon)

Atlanta Westin Peachtree Plaza

Details

Nov. 13-14 E-ISAC GridEx N/A N/A Details Dec. 4 E-ISAC Unclassified Threat

Workshop Washington DC

E-ISAC/NERC offices

E-ISAC

Dec. 10-11 NERC CIPC meeting Atlanta Intercontinental Buckhead

2020 Meeting Dates

Dates Event Location Venue Remarks March 3-4 2020 CIPC meeting Atlanta, GA TBD TBD

Pending Board decision, transition to Reliability and Security Council June 2-3 2020 TBD TBD TBD

20. Closing Remarks and Action Items

21. Adjournment *Background materials included. Attendees TBD

https://attend.ieee.org/smartgridcybercon

https://cipc-september-2019.eventbrite.com/

https://cvent.me/q9Dyo

https://www.nerc.com/pa/CI/CIPOutreach/Pages/GridEx.aspx


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.

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

NERC Antitrust Compliance Guidelines 2

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 REMINDER FOR USE AT BEGINNING OF MEETINGS AND CONFERENCE CALLS THAT HAVE BEEN PUBLICLY NOTICED AND ARE OPEN TO THE PUBLIC Conference call version: 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. Face-to-face meeting version: Participants are reminded that this meeting is public. Notice of the meeting was posted on the NERC website and widely distributed. Participants should keep in mind that the audience may include members of the press and representatives of various governmental authorities, in addition to the expected participation by industry stakeholders. For face-to-face meeting, with dial-in capability: Participants are reminded that this meeting is public. Notice of the meeting was posted on the NERC website and widely distributed. The notice included the number for dial-in participation. Participants should keep in mind that the audience may include members of the press and representatives of various governmental authorities, in addition to the expected participation by industry stakeholders.

August 10, 2010

NERC Participant Conduct Policy

General Consistent with its Rules of Procedure, Bylaws, and other governing documents, NERC regularly collaborates with its members and other stakeholders to help further its mission to assure the effective and efficient reduction of risks to the reliability and security of the grid. Many NERC members and other bulk power system experts provide time and expertise to NERC, and the general public, by participating in NERC committees, subcommittees, task forces, working groups, and standard drafting teams, among other things. To ensure that NERC activities are conducted in a responsible, timely, and efficient manner, it is essential to maintain a professional and constructive work environment for all participants, including NERC staff, members of NERC committees, subcommittees, task forces, working groups, and standard drafting teams, as well as any observers of these groups. To that end, NERC has adopted the following Participant Conduct Policy (this “Policy”) for all participants engaged in NERC activities. Nothing in this Policy is intended to limit the powers of the NERC Board of Trustees or NERC management as set forth in NERC’s organizational documents, the NERC Rules of Procedure, or under applicable law. This Policy does not apply to the NERC Board of Trustees or the Member Representatives Committee.

Participant Conduct Policy All participants in NERC activities must conduct themselves in a professional manner at all times. This Policy includes in‐person conduct and any communication, electronic or otherwise, made as a participant in NERC activities. Examples of unprofessional conduct include, but are not limited to, verbal altercations, use of abusive language, personal attacks, or derogatory statements made against or directed at another participant, and frequent or patterned interruptions that disrupt the efficient conduct of a meeting or teleconference.

Additionally, participants shall not use NERC activities for commercial purposes or for their own private purposes, including, but not limited to, advertising or promoting a specific product or service, announcements of a personal nature, sharing of files or attachments not directly relevant to the purpose of the NERC activity, and communication of personal views or opinions, unless those views are directly related to the purpose of the NERC activity. Unless authorized by an appropriate NERC officer, individuals participating in NERC activities are not authorized to speak on behalf of NERC or to indicate their views represent the views of NERC, and should provide such a disclaimer if identifying themselves as a participant in a NERC activity to the press, at speaking engagements, or through other public communications.

Finally, participants shall not distribute work product developed during the course of NERC activities if that work product is deemed Confidential Information consistent with the NERC Rules of Procedure Section 1500. Participants also shall not distribute work product developed during the course of NERC activities if distribution is not permitted by NERC or the relevant committee chair or vice chair (e.g., an embargoed report), provided that NERC, or the committee chair or vice chair in consultation with NERC staff, may grant in writing a request by a participant to allow further distribution of the work product to one or more


NERC Participant Conduct Policy 2

specified entities within its industry sector if deemed to be appropriate. Any participant that distributes work product labeled “embargoed,” “do not release,” or “confidential” (or other similar labels) without written approval for such further distribution would be in violation of this Policy. Such participants would be subject to restrictions on participation, including permanent removal from participation on a NERC committee or other NERC activity.

Reasonable Restrictions on Participation If a participant does not comply with this Policy, certain reasonable restrictions on participation in NERC activities may be imposed, as described below.

If a NERC staff member, or committee chair or vice chair after consultation with NERC staff, determines, by his or her own observation or by complaint of another participant, that a participant’s behavior is disruptive to the orderly conduct of a meeting in progress or otherwise violates this Policy, the NERC staff member or committee chair or vice chair may remove the participant from a meeting. Removal by the NERC staff member or committee chair or vice chair is limited solely to the meeting in progress and does not extend to any future meeting. Before a participant may be asked to leave the meeting, the NERC staff member or committee chair or vice chair must first remind the participant of the obligation to conduct himself or herself in accordance with this Policy and provide an opportunity for the participant to comply. If a participant is requested to leave a meeting by a NERC staff member or committee chair or vice chair, the participant must cooperate fully with the request.

Similarly, if a NERC staff member, or committee chair or vice chair after consultation with NERC staff, determines, by his or her own observation or by complaint of another participant, that a participant’s behavior is disruptive to the orderly conduct of a teleconference in progress or otherwise violates this Policy, the NERC staff member or committee chair or vice chair may request the participant to leave the teleconference. Removal by the NERC staff member or committee chair or vice chair is limited solely to the teleconference in progress and does not extend to any future teleconference. Before a participant may be asked to leave the teleconference, the NERC staff member or committee chair or vice chair must first remind the participant of the obligation to conduct himself or herself in accordance with this Policy and provide an opportunity for the participant to comply. If a participant is requested to leave a teleconference by a NERC staff member or committee chair or vice chair, the participant must cooperate fully with the request. Alternatively, the NERC staff member or committee chair or vice chair may choose to terminate the teleconference.

At any time, a NERC officer, after consultation with NERC’s General Counsel, may impose a restriction on a participant from one or more future meetings or teleconferences, a restriction on the use of any NERC‐administered listserv or other communication list, or such other restriction as may be reasonably necessary to maintain the orderly conduct of NERC activities. Before approving any such restriction, the NERC General Counsel must provide notice to the affected participant and an opportunity to submit a written objection to the proposed restriction no fewer than seven days from the date on which notice is provided. If approved, the restriction is binding on the participant, and NERC will notify the organization employing or contracting with the restricted participant. A restricted participant may request removal of the restriction by submitting

NERC Participant Conduct Policy 3

a request in writing to the NERC General Counsel. The restriction will be removed at the reasonable discretion of the NERC General Counsel or a designee.

Upon the authorization of the NERC General Counsel, NERC may require any participant in any NERC activity to execute a written acknowledgement of this Policy and its terms and agree that continued participation in any NERC activity is subject to compliance with this Policy.

Guidelines for Use of NERC Email Lists NERC provides email lists, or “listservs,” to NERC stakeholder committees, groups, and teams to facilitate sharing information about NERC activities. It is the policy of NERC that all emails sent to NERC listservs be limited to topics that are directly relevant to the listserv group’s assigned scope of work. NERC reserves the right to apply administrative restrictions to any listserv or its participants, without advance notice, to ensure that the resource is used in accordance with this and other NERC policies.

Prohibited activities include using NERC‐provided listservs for any price‐fixing, division of markets, and/or other anti‐competitive behavior. Recipients and participants on NERC listservs may not utilize NERC listservs for their own private purposes. This may include lobbying for or against pending balloted standards, announcements of a personal nature, sharing of files or attachments not directly relevant to the listserv group’s scope of responsibilities, or communication of personal views or opinions, unless those views are provided to advance the work of the listserv’s group. Any offensive, abusive, or obscene language or material shall not be sent across the NERC listservs.

Any participant who has concerns about this Policy may contact NERC’s General Counsel.

Version History

Version Date Change Tracking 1 February 6, 20192 February 22, 2019 Clarified policy does not

apply to Board or MRC

Addressed participantsspeaking on behalf ofNERC


Meeting Minutes Critical Infrastructure Protection Committee June 4, 2019 | 1:00-5:00 p.m. Eastern June 5, 2019 | 8:00 a.m.–12:00 p.m. Eastern Hyatt Regency Orlando International Airport 9300 Jeff Fuqua Boulevard Orlando, FL 32827 Call to Order Chair Child called the meeting to order at 1:00 p.m. He welcomed members and guests, and noted the recent appointment of John Greaves as a SERC representative. NERC Antitrust Compliance Guidelines, Public Announcement, and Participant Conduct Policy The standard NERC announcements about NERC’s anti-trust policies and notice of public meeting were presented. Introduction and Chair’s Remarks

1. Administrative Items – Tom Hofstetter, NERC Staff, CIPC Secretary

a. Safety Briefing and Emergency Precautions – Hyatt Regency hotel staff briefed attendees about safety policies and procedures.

b. Welcoming Remarks – Kenneth Zambito, Vice President of Transmission, Orlando Utilities Commission

Mr. Zambito welcomed attendees to Orlando. Besides mentioning area highlights and attractions, he also described the services provided to the community by OUC.

c. Declaration of CIPC Quorum

d. Quorum was confirmed, with seven proxies designated:

Member Proxy Representing

Allan Wick Jay Spradling WECC Tom O'Neill Lori Pier Sanche NPCC Bob Richhart Richard Field NRECA Brian Irish Mike Kraft WECC John Greaves Don Roberts SERC Jim McNierney Sheranee Nedd NPCC David Revill Margaret Wilson NRECA

Minutes – Critical Infrastructure Protection Committee Meeting – June 4-5, 2019 2

e. Parliamentary Procedures – In the absence of specific provisions in the CIPC charter, the committee shall conduct its meetings guided by the most recent edition of Robert’s Rules of Order, Newly Revised.

f. Introductions

Chair Child noted that this was the second consecutive CIPC meeting that reached capacity. Total registered attendance was 143.

g. CIPC Roster

Consent Agenda – Chair Marc Child, Great River Energy

Chair Child reviewed the agenda and indicated no additions or changes other than presentations that would occur in a different order than what was listed due to travel schedules.

2. Minutes*

a. March, 2019 Meeting

There were no additions or corrections to the minutes of the CIPC meeting from March 5-6, 2019. They were approved unanimously by a voice vote.

Regular Agenda

3. Remarks and Reports - Chair Child

a. Work Plan* – Chair Child’s comments focused on several issues:

Updates to the CIPC charter and to scoping documents for working groups were scheduled for voting as each working group’s report was presented.

CIPC was on track to complete its biennial work plan. A key deliverable has been the efforts to address supply chain risk mitigation.

With the pending dissolution of the region, FRCC’s representatives were recognized and thanked for their participation and support: Dawn Hamdorf, Carter Manucy, and Dawn Thomas.

Chair Child addressed the ongoing project that proposes a fundamental redesign of the structure and conduct of CIPC, Operating Committee, and Planning Committee. He encouraged members and guests to review the information about the project and submit comments to the Stakeholder Engagement Team.

b. Nominating Committee – Chair Child reported that Larry Bugh had agreed to lead the search for nominees for the upcoming term. He acknowledged the potential for the terms to be shortened due to the proposed restructuring of NERC committees.

4. CIPC Charter update*

The updates to the CIPC charter were approved unanimously by voice vote.

5. Agency Updates

a. Federal Energy Regulatory Commission – Simon Slobodnik, FERC

https://extranet.nerc.net/CIProtectionComm/GeneralDocuments/CIPC_Roster_5-2019.pdf


Mr. Slobodnik reviewed recent FERC activities and highlighted a new Commission newsletter with information about various topics. He also discussed an upcoming technical conference that will focus on cloud computing.

b. Department of Energy – no report

c. Department of Homeland Security* – Ron Keen, DHS

Mr. Keen provided an overview of risks and vulnerabilities that the Department of Homeland Security (DHS) has recently noted. He focused on DHS efforts to address supply chain security in multiple sectors.

d. Public Safety Canada – no report

6. NERC Update

a. Compliance – Lonnie Ratliff, NERC Staff

Mr. Ratliff discussed collaborative efforts with the Compliance Input Working Group to address how security and compliance concerns could affect entities using cloud-based service providers. He also reminded attendees of the upcoming “Small Group Advisory Sessions” (SGAS) that will provide an opportunity for entities to have detailed discussions about implementing requirements that support supply chain risk management.

b. Supply Chain* – Howard Gugel, NERC Staff

Mr. Gugel described a recent report to the Board of Trustees which included a recommendation to include electronic access controls in the Supply Chain Standards. He also discussed assistance from CIPC’s Supply Chain Working Group (SCWG) to develop a request to industry for data about reliability risks from low impact facilities.

c. Standards Development* – Jay Cribb, Southern Co.

7. Supply Chain Working Group (SCWG) Update* - Chair Tony Eddleman, NPPD

Mr. Eddleman gave an update on the activities and the status of the STWG’s projects:

Several sub-teams are working on security guidelines that focus on good business practices, not compliance.

The “Supply Chain Cyber Security Practices” letter that the SCWG developed has been posted on NERC’s web site under the related files section and can help an entity in its discussions with vendors.

The group is assisting with the development of a questionnaire that NERC will send to industry as a “Request For Data or Information,” as described in Section 1600 of NERC’s Rules of Procedure.

8. TOP Data Exchange Requirements Task Force - Chair Srinivas Kappagantula, PJM

Data Exchange Infrastructure Requirements Task Force (DEIRTF) Update*

Mr. Kappagantula summarized the proposed implementation guidance for TOP-001-4. Three CIPC members participated in the OC-led team that is developing the guidance, with feedback on the

https://www.nerc.com/comm/CIPC/Related%20Files%20DL/SupplyChainCyberSecurityPracticesLetter2019.pdf

https://www.nerc.com/AboutNERC/Pages/Rules-of-Procedure.aspx

https://www.nerc.com/AboutNERC/Pages/Rules-of-Procedure.aspx


draft received from CIPC and OC reviewers. If ERO Enterprise Compliance staff endorses the guidance, it will be available to industry.

9. Reliability Issues Steering Committee (RISC) Update * - Chuck Abell, Ameren

Mr. Abell’s update focused on the RISC’s recent survey to identify emerging risks. Survey responses were consolidated into five categories, with the recognized cyber and physical security risks likely to be the focus of CIPC’s activities in the biennial work plan.

10. E-ISAC Update

a. E-ISAC programs and planning Strategic plan, GridSecCon, and GridEx Updates* – Sam Chanoski, E-ISAC

Mr. Chanoski discussed upcoming activities and events in which E-ISAC is participating and described a communication tool that was recently introduced: “all points bulletins” will be used to share important information that does not warrant an urgent response. He also highlighted the need for asset owners to keep security features in all of their equipment up to date.

b. Cyber Security* – Philip Daigle, E-ISAC Staff

Mr. Daigle described recent cybersecurity issues that the E-ISAC has been monitoring.

c. Physical Security* – Kristen Bove, E-ISAC Staff

Ms. Bove discussed recent activities and items of interest pertaining to physical security.

d. E-ISAC Physical Security Advisory Group (PSAG)* – Ross Johnson, PSAG Co-chair

Mr. Johnson provided an overview of PSAG activities and projects, to include the development of a physical security maturity model as well as the publication of guides and other documents. He also discussed upcoming design basis threat workshops, and recently published implementation guides and other documents.

11. National Laboratory Updates

a. Argonne National Laboratory – James Kavicky, ANL

Mr. Kavicky’s update included an overview of Argonne’s work on gas-electric interdependencies, in collaboration with the North American Energy Standards Board (NAESB) and NERC’s Operating Reliability Subcommittee. He also mentioned projects and activities that support resilience metrics and methodology, and thanked CIPC for partnering with the national labs for mutual benefit.

b. Pacific Northwest National Laboratory* – Scott Mix, PNNL

Mr. Mix explained PNNL’s work on Software Defined Networks for Electric Distribution Systems (SDN4EDS). The presentation was an overview of the technology and the issues being considered to support implementation in an effective and compliant manner.

c. Idaho National Laboratory – Andrew Bochman, INL

Mr. Bochman discussed research into developing automated responses to cyber threats. A component of the effort is Structured Threat Intelligence Graph (STIG), which would use


computer network data to identify threats from adversaries who are targeting specific locations.

12. Legislative Update* – Andrea Koch, EEI

There was no presentation; background material was included with the agenda package that was provided to members.

13. EPRI Update* – John Stewart, EPRI

Mr. Stewart’s report focused on various cybersecurity programs led by EPRI, such as the development of automated systems to support asset management and monitoring, compliance, and threat identification. He also discussed an October workshop that will address digital substation technologies.

14. North American Transmission Forum* – Ken Keels, NATF

Mr. Keels discussed NATF’s collaboration with other groups in planning a response to the declaration of a Grid Security Emergency (GSE). Issues to be addressed include coordination among various organizations, communication protocols, and liability exemptions.

He also summarized other recent NATF activities: an upcoming security workshop; a supply chain security product targeted at vendors; and implementation guidance development efforts.

15. North American Generator Forum – Venona Greaff, Oxy

NAGF was officially represented at CIPC for the first time, and Ms. Greaff provided an overview of the organization, including a summary of its working groups and related information. The presentation included discussion about the standards procedure templates that were being developed for use by organizations with low impact cyber systems. She also highlighted the NAGF annual meeting, to be held at NERC’s Atlanta offices in October.

16. CIP Standards Development Update* – Jay Cribb, Southern Company

Mr. Cribb reviewed the status of CIP Reliability Standards development efforts. The drafting teams face challenges in developing technology agnostic requirements that address issues such as shared infrastructure and virtualized environments.

17. Policy Working Groups – Chair Jeffrey Fuller, AES Corporation

Chair Fuller presented updated scope documents for the “Policy” working groups: Security Metrics Working Group and Compliance Input Working Group. Motion to approve the documents was seconded and approved unanimously by voice vote.

a. Security Metrics Working Group (SMWG) Update* – Chair Larry Bugh, ReliabilityFirst

Chair Bugh described recent SMWG activities that included review and comment on NERC’s annual “State of Reliability Report.” He also discussed how E-ISAC’s development has reduced the need for SMWG to perform many of the tasks and analyses to which it was formerly assigned. He indicated that when archival information and other relevant records are finalized, the group can disband.

b. Compliance Input Working Group (CIWG) Update* – Chair Paul Crist, Lincoln Electric System


Mr. Crist reviewed the CIWG’s efforts to develop compliance guidance for using cloud based services. A CIWG-sponsored event in April brought together representatives from industry, government, cloud service providers, and ERO compliance staff to discuss the issue. There were also plans made for CIWG members and ERO auditors to visit a Microsoft data center to observe and evaluate security controls.

Mr. Crist also noted that an earlier project to develop compliance guidance for the use of voice systems has been abandoned; the group concluded that there is no longer a need for the document.

18. Operating Security Working Groups – Chair Chuck Abell, Ameren

Chair Abell presented updated scope documents for the “Operating Security” working groups: Grid Exercise Working Group and Supply Chain Working Group. Motion to approve the documents was seconded and approved unanimously by voice vote.

a. Grid Exercise Working Group (GEWG) Update – Chair Jake Schmitter, E-ISAC Staff; Vice Chair Stuart Brindley, S. J. Brindley Consulting, Inc.

Mr. Chanoski reported on Mr. Schmitter’s behalf and provided additional details about the GEWG scope document. Besides administrative updates, it also clarifies the operational relationship of the GEWG with E-ISAC, while oversight and reporting responsibilities are to CIPC. He also reported that group’s work on the Master Scenario Event List (MSEL) for GridEx 5 is complete, allowing entity lead planners more time to prepare for their implementation of the exercise.

19. Cyber Security Working Groups – Chair Brenda Davis, CPS Energy

Chair Davis provided an overview of updates to the scope document for the Security Training Working Group; it was approved by a voice vote.

a. Control Systems Security Working Group (CSSWG) Update – Chair Carter Manucy, Florida Municipal Power Agency; Vice-chair Tobias Whitney, EPRI

The CIPC Executive Committee determined that the CSSWG was no longer the most effective approach for developing security guidelines that pertain to control systems security. In light of this decision, the CSSWG was to stand down, effective immediately. The remote access guideline document currently being developed and future guidelines deemed to be necessary will be assigned to a designated task force.

b. Security Training Working Group (STWG) Update – Chair Amelia Anderson, CenterPoint Energy

Chair Davis reported that the training event immediately preceding the CIPC meeting was a success, with over 65 attendees on hand for the discussion about supply chain security.

20. Physical Security Working Groups – Chair Ross Johnson, Bridgehead Security Consulting, Inc.

a. Physical Security Working Group (PSWG) Update

Chair Johnson summarized changes to the scope document for the Physical Security Working Group; it was approved by a voice vote.


b. Physical Security Guidelines Task Force (PSGTF) Update – Chair Darrell Klimitchek, South Texas Electric Cooperative

PSGTF Chair Darrell Klimitchek discussed the guideline that was recently approved by CIPC via an email vote: “Physical Security Guideline Assessments and Resiliency Measures for Extreme Events.”

c. Other updates - Chair Johnson

Alberta Provincial Physical Security Projects

Chair Johnson reported that since retiring and moving from the area, his active involvement in Alberta has ended. There is no information regarding his replacement.

21. Roundtable

a. Smart Grid Cybersecurity Workshop* – Mike Kraft, Basin Electric Power Cooperative

Mr. Kraft provided an overview of an December workshop being sponsored by IEEE, immediately following the CIPC meeting. (Details are available at IEEE SMART GRID Cybersecurity Workshop

22. Schedule of Important Dates

Dates Time Type Location Hotel

September 17-18, 2019 12:00 p.m. - 5:00 p.m. 8:00 a.m. - Noon CIPC Meeting Minneapolis,

MN

Intercontinental Minneapolis – St. Paul Airport

November 13-14, 2019 N/A GridEx N/A N/A

December 10-11, 2019 12:00 p.m. - 5:00 p.m. 8:00 a.m. - Noon CIPC Meeting Atlanta, GA Intercontinental

Buckhead

December 12-13, 2019 TBD IEEE Workshop Atlanta, GA Intercontinental Buckhead

23. Closing Remarks and Action Items

24. Adjournment

*Background materials included.




Attendees First Name Last Name Company Felek Abbas Ernst & Young, LLP Charles Abell Ameren Mike Almeyda Force 5, Inc. Tom Alrich Tom Alrich LLC Amelia Anderson CenterPoint Energy Michael Andrews AMICO Security Sharla Artz UTC Elaine Bell NYISO Robin Berthier Network Perception Victoria Bethley Duke Energy Marshall Bissonnette Open Systems International Suzanne Black ISO-NE Andy Bochman DOE / Idaho National Lab Patricia Boody Lakeland Electric Byron Booker Oncor / Reliability and Security Compliance Kristen Bove E-ISAC Michael Bowdy E-ISAC Larry Bugh ReliabilityFirst Masuncha Bussey Duke Energy Eric Byres aDolus Inc. Dave Cates ACES Power Sam Chanoski NERC/E-ISAC Marc Child Great River Energy Dustin Cornelius Southern Company Jay Cribb Southern Company Paul Crist Lincoln Electric System Damon Crozier Wolverine Power Cooperative Doug Currie Hydro One Philip Daigle E-ISAC Brenda Davis CPS Energy Steven Dougherty IBM Tony Eddleman Nebraska Public Power District Richard Field Hoosier Energy Steen Fjalstad MRO Roger Fradenburgh Network and Security Technologies Jeffrey Fuller AES Joe Garmon Wabash Valley Power Dallas Glass Southern Company David Godfrey City of Garland Venona Greaff Oxy David Grubbs City of Garland Howard Gugel NERC Michael Hagee SERC


Anthony Hall LG&E/KU Energy Dawn Hamdorf Seminole Electric Cooperative Latrice Harkness NERC Matthew Harward Southwest Power Pool Rich Heidorn RTO Insider LLC Mark Henry Texas RE Tom Hofstetter NERC Jim Howard Lakeland Electric Alice Ireland Tri-State Generation and Transmission David Jacoby Boston Strategies International Jodi Jensen Western Area Power Administration Ross Johnson Bridgehead Security Consulting, Inc. Jeff Judy Entergy Corporation Peter Kaleda Alitek Response Srinivas Kappagantula PJM Interconnection LLC Jim Kavicky Argonne National Laboratory Ken Keels North American Transmission Forum Ronald Keen U.S. Department of Homeland Security Justin Kelly FERC Rich Kinas Orlando Utilities Commission Greg King Brian Kinstad Midwest Reliability Organization Chris Klemm Exelon Darrell Klimitchek South Texas Electric Cooperative Robert Koziy Open Systems International Mike Kraft Basin Electric Power Cooperative Scott Lamountain Salt River Project Steven Lancaster Beaches Energy Services Stephanie Lawrence NERC John Leitz PricewaterhouseCoopers Wally Magda WallyDotBiz LLC Carter Manucy FMPA Conor Martin Arizona Public Service Courtney Massey Florida Power and Light George Masters Schweitzer Engineering Laboratories Jim McGlone FERC Jacinta Meredith E-ISAC Brian Millard TVA Scott Mix PNNL Jerrod Montoya OATI Samara Moore Amazon Web Services Carlos Morales NextEra Energy FPL Nicholas Morton AEP Benny Naas Vectren Sheranee Nedd Public Service Enterprise Group


Thad Ness Xcel Energy Darren Nielsen Navigant Damon Ounsworth SaskPower Bryan Owen OSIsoft Chris Plensdorf DTE Energy Joe Polen MISO Renny Ramai FRCC Lonnie Ratliff NERC Sandra Revnell Wolverine Power Cooperative Erick Reynolds Avigilon Donald Roberts Southern Company David Rosenthal MISO Jim Rowan Alitek Response David Sampson DTE Energy Lori Pier Sanche Hydro Quebec Michael Sanders Southern Company Rebecca Sanders Southwest Power Pool Karla Sanmartin Con Edison Peter Scalici NPCC Matthew Schwartz Network & Security Technologies Simon Slobodnik FERC Robert Smith Idaho National Lab Jason Snodgrass Georgia Transmission Corp Jay Spradling Salt River Project Keith St. Amand MISO Scott Sternfeld Network Perception Kevin Stewart Beaches Energy Services John Stewart EPRI Katherine Street Duke Energy Jake Stricker PwC Craig Summers Dawn Thomas NextEra Energy/ FPL Barrett Thompson Avigilon Brian Tooley Vectren Brenda Truhe PPL Electric Utilities Larry Watt Lakeland Electric Scott Webb Network and Security Technologies William Wenz AES Gary Wetzel S&C Electric Company Tobias Whitney EPRI Margaret Wilson Georgia Systems Operations Corp Michele Wright FoxGuard Solutions Ken Zambito Orlando Utilities Commission Kimberly Zimmerman EnergySec

Agenda Item 3a Critical Infrastructure Protection Committee Meeting

September 17-18, 2019

Critical Infrastructure Protection Committee Work Plan Update Action Discussion Background Chair report on progress on Critical Infrastructure Protection Committee (CIPC) work plan items Summary Chair Child will welcome new committee members and review items from the 2018-2019 work plan, focusing on a few items that have either completed or are about to start. Additionally, notes from the recent NERC board of trustees meeting including a progress report on the Stakeholder Engagement Team.

Agenda Item 10a Critical Infrastructure Protection Committee Meeting


Physical Security Metrics for Electric Sector Assets Action Presentation and Open Discussion Background As part of DOE’s Grid Modernization Initiative, Argonne proposed and developed a prototype methodology and tool to characterize and quantify the physical security of an owner’s substations. Summary Argonne will provide a short presentation describing the substation physical security methodology developed as part of the DOE Grid Modernization Lab Consortium and follow with an open discussion to address comments and questions. The methodology is based on a DHS physical security approach, which accounts for a facilities’ physical security, security force, security management, information sharing, and protective measures. The tool also provides the ability to evaluate how proposed changes in current physical security could improve the security posture of an electric utility and allows the user to generate a report with charts and data that could be disseminated within the organization for further review.

Agenda Item 12b Critical Infrastructure Protection Committee Meeting


Legislative Update Action Update Background Federal Legislative Update – September Summary • Signs point to September being a busy month for Senate Energy and Natural Resources

Committee (SENR) on grid security / cyber issues. Over the summer, several bills (more below) were introduced that we expect to be included or the focus of any legislative hearing in September or October. We expect SENR’s schedule to be announced soon.

• S. 174 / H.R. 680, Securing Energy Infrastructure Act (SEIA) – This bill is currently in this year’s Senate passed National Defense Authorization Act (NDAA) bill and the House passed Intel bill. SENR also passed the bill out of committee by voice vote on July 16.

• The House Energy and Commerce Committee (E&C) marked up several grid security bills on July 17. We have flagged these bills in the past CIPC legislative updates as the House Homeland Security Committee expressed concerns over jurisdiction.

The bills included: H.R. 360, Cyber Sense Act, H.R. 362, Energy Emergency Leadership Act, H.R. 359, Enhancing Grid Security through Public-Private Partnerships Act, H.R. 370 - Pipeline and LNG Facility Cybersecurity Preparedness Act, and H.R. 2114, Enhancing State Energy Security Planning and Emergency Preparedness Act of 2019.

Senators Gardner and Bennet introduced a companion bills to H.R. 359 and H.R. 2114.

Grid Security: Liability Protections The industry is exploring the need for liability protections in the event electric companies are ordered to act in pursuant to a DOE Grid Security Emergency order. For example, the U.S. Government (USG) asks or orders an electric company to reduce load or ensure certain areas (e.g., critical military installation) have power during an emergency for national security purposes. We also are looking at the scenario of a cyber incident where the USG asks or orders an electric company to take no action when an adversary is observed on its system in order to observe it for intelligence collection as a matter of national security. In both scenarios, under existing law, grid owners and operators are not protected from legal liability for third party claims for acquiescing to such requests or orders. Thus, electric companies are disproportionately bearing the responsibility for the national defense of the US electric grid against nation-state actors. The threat of costly litigation and associated liabilities

also may hinder a company’s ability to collaborate or cooperate fully with the government, which is an outcome the sector is trying to avoid. On the Hill, outreach is underway to the Senate and House energy, homeland, judiciary committees. Telecommunications The industry continues to raise concerns about the Federal Communications Commission’s proposal to expand use of unlicensed devices in the 6 GHz band due to the potential of interference of electric company communications networks (e.g., point-to-point microwave systems) that monitor and support the reliable delivery of electricity and other critical services. We are advocating that incumbent critical infrastructure owners and operators must be protected and steps must be taken to better understand and test any technological solutions. Unmanned Aircraft Systems (UAS) It is unlikely Congress will take any legislative action on UAS in the coming months. A couple of things to keep an eye on that could change that include:

1. Federal Aviation Administration (FAA) failure to meet the September 20 deadline for the remote ID rule;

2. The Section 2209, "fixed site no fly list," rule is due by the end of October. However, the Section 2209 also is contingent on the remote ID rule.

NERC | Report Title | Report Date I


1325 G Street NW Suite 600

Washington, DC 20005 202-790-6000 | www.eisac.com

Final Report Security Metrics Working Group

DRAFT June 14, 2019

TLP:WHITE

E-ISAC | Security Metrics Working Group Final Report | DRAFT June 14, 2019 ii

TLP:WHITE

Table of Contents

Introduction ............................................................................................................................................................... iii

Background ............................................................................................................................................................ iii

Scope of the Security Metrics Working Group ...................................................................................................... iii

Chapter 1: Methodology ............................................................................................................................................1

Chapter 2: Security Metrics Currently In Place ..........................................................................................................3

Chapter 3: New Metrics Considered ..........................................................................................................................9

Chapter 4: Next Steps .............................................................................................................................................. 11

Appendix 1: SMWG Charter .................................................................................................................................... 12

Appendix 2: Historical Background ......................................................................................................................... 14

BES Reliability Metrics and Possible Analogies for Security Metrics ................................................................... 14

Conclusions Following Analysis of “Universe” of Cyber Security Metrics ........................................................... 19

E-ISAC | Security Metrics Working Group Final Report | DRAFT June 14, 2019 iii

TLP:WHITE

Introduction Background Since 2014, the Critical Infrastructure Protection Committee’s (CIPC) Security Metrics Working Group (SMWG) and the E-ISAC have developed security performance metrics to help determine the extent to which the reliability of the bulk power system (BPS) is impacted by physical and cyber security incidents and events. Since 2015, these security performance metrics have been published as part of NERC’s annual State of Reliability reports. As the E-ISAC has matured, particularly over the past two years, it now has the capabilities to further develop security metrics that reflect the threats and vulnerabilities observed on a day-to-day basis. Drawing from the comprehensive foundation laid by the SMWG, the E-ISAC has effectively assumed the role of the SMWG in its current form, and the SMWG recommends to CIPC that it stand down. This Security Metrics Final Report documents the work of the SMWG with the E-ISAC to develop security performance metrics. It provides the methodology for how security metrics are developed, and discusses metrics that are currently in place, or have been considered. It is expected that these insights will be of value for future security measurement efforts, and the E-ISAC is grateful to the leadership and members of the SMWG past and present.

Figure 1: Security Metrics Development Roadmap Scope of the Security Metrics Working Group Security metrics means different things to different people and for the purposes of this Roadmap it is important to understand what is and what is not within the scope of the SMWG. Appendix 1 – SMWG Charter provides details of the working group’s role, objectives, and structure. At a high level, consider that any security metric could fit into one or more of the following areas of interest:

• E-ISAC performance; metrics that help quantify the extent to which the E-ISAC is providing the necessary results to perform its mission.

Introduction

E-ISAC | Security Metrics Working Group Final Report | DRAFT June 14, 2019 iv

TLP:WHITE

• BPS reliability; metrics that help quantify the extent to which the grid is becoming more or less reliable and resilient to security-related risks.

• Utility performance; metrics that help quantify the extent to which a utility is able to demonstrate they are appropriately managing security-related risks.

Figure 2 illustrates each of these security metrics areas of interest and the different industry initiatives underway to address them.

Figure 2: Security Metrics Initiatives

E-ISAC | Security Metrics Working Group Final Report | DRAFT June 14, 2019 1

TLP:WHITE

Chapter 1: Methodology The SMWG used the SMART methodology to determine the relative value of proposed metrics. These definitions have been adapted from those used by NERC to develop metrics related to Adequate Level of Reliability.

• Specific/Simple: Easily understood, identifies factors that positively or negatively impact security, addresses reliability problems and solutions.

• Measurable: Easily measured with regularly collected information, measures past and current security performance, measures progress in ensuring security.

• Attainable: The results of the measure will help the electricity industry provide sufficient resources (i.e., funding, time and ability) to improve security, security will be measurably improved.

• Relevant: Linked to security goals, provides meaningful information, provides feedback for improving a security standard.

• Tangible/Timely: Reflects current top priority and urgent security issues or gaps. Table 1.1 illustrates how the SMWG assessed the first three of the security metrics developed using the SMART methodology.

Table 1.1: SMART Rating Methodology

Metric

SMART Rating (score of 0, 1, 2, or 3 – maximum total of 15)

Specific/Simple Measurable Attainable Relevant Tangible/Timely TOTAL Metric 1: Frequency of Reportable Cyber Security Incidents reported by entities

3 points Specific to the industry, Reportable Cyber Security Incident defined in NERC standard CIP-008-5

3 points Data readily available through E-ISAC portal

3 points Reports of incidents by industry will be closely monitored by industry peers and will prompt action

3 points Details of the incident will be directly applicable to entities operating similar technologies

3 points Reportable Cyber Security Incidents will likely be acted upon as a top priority issue by industry

15 points

Metric 2: Frequency of Reportable Events (physical damage or destruction) reported by entities

3 points Specific to the industry, Reportable Event defined in NERC standard EOP-004-2

3 points Data readily available through NERC Bulk Power System Analysis’ disturbance events analysis process

3 points Reports of events by industry will be closely monitored by industry peers and will prompt action

3 points Details of the events will be directly applicable to other entities

3 points Reportable Events will likely be acted upon as a top priority issue by industry

15 points

Chapter 1: Methodology TLP:WHITE


TLP:WHITE

Table 1.1: SMART Rating Methodology

Metric

SMART Rating (score of 0, 1, 2, or 3 – maximum total of 15)

Specific/Simple Measurable Attainable Relevant Tangible/Timely TOTAL Metric 3: Number of entities registered to access E-ISAC portal to share information (e.g., number of registrants, measured quarterly)

3 points Readily available, entities known to NERC through registration process

3 points Registration data readily available

1 point E-ISAC registration by itself will not necessarily enhance security

2 points Entities have access to industry specific data re: cyber threats and vulnerabilities, but data does not indicate that information is acted-upon

3 points Entities have ready access to most recent high priority threats and incidents

12 points


TLP:WHITE

Chapter 2: Security Metrics Currently In Place The SMWG has developed a total of seven metrics, provided in Table 2.1. The SMWG acknowledges that metrics need to be reviewed periodically to ensure they continue to meet their intended purpose. The SMWG supported the E-ISAC by reviewing the metrics data on a quarterly basis, clarifying the definition of the metric, interpreting the data, and identifying trends. Table 2.1 provides the metrics developed by the SMWG and offers suggestions regarding how they may be enhanced in the future.

Table 2.1: Metrics Currently In Place and Possible Enhancements

Name Description Possible Next Steps

Metric 1: Reportable Cyber Security Incidents Production Status: Reported quarterly by the E-ISAC as a NERC Corporate Performance Measure

• Total number of Reportable Cyber Security Incidents 1

• Total number of Reportable Cyber Security Incidents resulting in a loss of Load

1. Coordinate with Department of Energy (DOE) to ensure consistency with any metrics they have developed or are developing (e.g., based on OE-417 reports).

STATUS: TBD.

2. Consider a further breakdown of the reported data, if meaningful.

STATUS: Being considered by E-ISAC, but no suggested change to the metric at this time.

3. Recognize as part of trending analysis that CIPv5 will require more assets to be subject to the standards for Low and Medium Bulk Electric System (BES) Cyber Assets. This significantly increases the number of assets subject to the reporting process.

STATUS: Pending experience after full CIPv5 implementation.

1 Capitalized words indicate a term defined in NERC’s Glossary of Terms.

Chapter 2: Security Metrics Currently In Place TLP:WHITE


TLP:WHITE



Metric 2: Reportable Physical Security Events

Production Status: Reported quarterly by the E-ISAC as a NERC Corporate Performance Measure

• Total number of reportable events as a result of physical security threats to a Facility or BES control center without physical damage or destruction (as defined in EOP-004)

• Total number of reportable events that cause physical damage or destruction to a Facility

• Total number of reportable events as a result of physical security threats to a Facility or a BES control center, or cause physical damage or destruction to a Facility, that result in a loss of Load

4. Coordinate with DOE to ensure consistency with any metrics they have developed or are developing (e.g., based on OE-417 reports).

STATUS: TBD.

5. As part of reviewing 2015 data, consider a further breakdown of the reported data, if meaningful (e.g., gunfire, intrusion, surveillance, suspicious activity, vandalism, threat, theft).

STATUS: Underway by E-ISAC, but data not yet reported with this level of detail.



TLP:WHITE



Metric 3: E-ISAC Membership

Production Status: Reported quarterly by the E-ISAC as an E-ISAC Performance Measure

• Total number of electricity sector organizations registered as members of the E-ISAC.

• Total number of individuals in E-ISAC member organizations who have E-ISAC accounts

6. Consider ways to make this metric more meaningful, e.g.:

a. % load served by registered organizations (data available from NERC “Net Energy for Load” fee calculations)

b. Number of customers

c. Transmission line length

d. More detailed metrics regarding the frequency and extent of use by individuals

STATUS: Items a, b, c, above have been considered and dismissed, as they have little relationship to BPS reliability. Item d may be useful (e.g., #logins per user per quarter) but is more suitable as a metric E-ISAC performance, rather than BPS reliability.



TLP:WHITE



Metric 4: Industry-Sourced Information Sharing Production Status: Reported quarterly by the E-ISAC as an E-ISAC Performance Measure

• Total number of E-ISAC Cyber Bulletins based on information provided by the electricity sector

• Total number of E-ISAC Physical Bulletins based on information provided by the electricity sector

7. As part of reviewing 2015 data, consider a further breakdown of the reported data, if meaningful (e.g., zero-day malware, type of attack vector, type of targeted BES asset, reporting timeliness, value of the information to the E-ISAC).

STATUS: Second metric for Physical Bulletins implemented by E-ISAC starting Q4 2015. Sub-categories being considered by E-ISAC.

8. Consider number of entities using automated information-sharing Structured Threat Information Expression™ and Trusted Automated eXchange of Indicator Information™ methods.

STATUS: NERC’s Cyber Automated Information Sharing System (CAISS) project may be a useful source of data.

Metric 5: Global Cyber Vulnerabilities Production Status: Reported quarterly by the E-ISAC

• Number of global cyber vulnerabilities considered to be high severity (i.e., with a Common Vulnerability Scoring System of 7 or higher)

9. Consider other detailed Common Vulnerability Scoring System metrics useful in calculating a relative “score” for a vulnerability that is reported to the E-ISAC.

• https://www.first.org/cvss/calculator/3.0

• https://www.first.org/cvss/calculator/guide

• https://www.first.org/cvss/cvss-v30-user_guide_v1.1.pdf

STATUS: CLOSED.

https://www.first.org/cvss/calculator/3.0

https://www.first.org/cvss/calculator/guide

https://www.first.org/cvss/cvss-v30-user_guide_v1.1.pdf

https://www.first.org/cvss/cvss-v30-user_guide_v1.1.pdf



TLP:WHITE



Metric 6: Global Cyber Vulnerabilities and Incidents Production Status: No longer reported quarterly by the E-ISAC

• Number of global cyber security incidents

• Consider comparing the trending line of this metric with the number of incidents to monitor any correlation.

STATUS: Unfortunately, PwC data source stopped publishing the number of incidents in 2016. Consider alternate data source and similar metric from Verizon’s Data Breach Investigation Report.

• Consider surveying chief information security officers at utilities for their opinion on relative risk.

STATUS: CLOSED. Considered and discarded, too subjective, low value.

CONCLUSION: Metric deleted pending adequate available data.

Metric 7: GridEx Exercise Program Maturity Production Status: Reported every 2 years following GridEx exercises

• An indication of the extent to which NERC’s Grid Security Exercise program continues to mature in terms such as number of participants, scenario complexity, participant satisfaction, etc.

10. Consider using some of the data already collected as part of the GridEx program (i.e., survey, lessons-learned).

STATUS: Complete and included in NERC GridEx reports.



TLP:WHITE




TLP:WHITE

Chapter 3: New Metrics Considered Table 3.1 provides metrics recently considered.

Table 3.1: New Metrics Currently Under Development

Name Description Next Steps

1. Industrial Control System (ICS) Vulnerabilities

• Number of ICS vulnerabilities as reported by National Institute of Standards and Technology/ICS-Cyber Emergency Response Team (CERT)/etc.

Contact ICS-CERT and ICS Joint Working Group to determine their efforts to date.

STATUS: E-ISAC to analyze ICS-CERT vulnerability data related to commonly-used Emergency Management System/Supervisory Control and Data Acquisition (EMS/SCADA)/remote terminal unit platforms from MITRE’s cvedetails.com.

2. NERC Alerts • Number and frequency of NERC Alerts released over time

Consider a metric regarding the number of NERC Alerts (Advisories, Recommendations, Essential Action) over time.

STATUS: Historically, few NERC Alerts are released each year; sample size too small to be statistically meaningful at this time. For now, use anecdotal evidence and narrative to describe NERC alerts and possible impact on BPS reliability.

3. Automated Cyber Information-Sharing

• Number of entities participating in the E-ISAC’s Cybersecurity Risk and Information Sharing Program (CRISP) and CAISS programs.

• Total number of electricity entities participating in CRISP and CAISS.

• 100% stacked bar chart of the types of malware detected through CRISP and/or CAISS. The 100% stacked bar chart will normalize the data and help visualize which types of malware are trending.

STATUS: E-ISAC to draft metric definition based on quarterly data.

In future, the E-ISAC may wish to consider developing new security performance metrics from the perspective of three areas of interest: BPS reliability, E-ISAC performance, and utility performance. Figure 3.1 provides some illustrative examples.

Chapter 3: New Metrics Considered TLP:WHITE


TLP:WHITE

Figure 3.1: Security Metrics – Future Consideration


TLP:WHITE

Chapter 4: Next Steps

Table 4.1: Planning Milestones

What When

1 Review May 2019 Roadmap document June 3, 2019 SMWG meeting

2 Discuss and recommend any changes to SMWG Roadmap in the form of a final report

June 2019

3 Provide final report to CIPC and recommend SMWG stand down September 2019


TLP:WHITE

Appendix 1: SMWG Charter

Appendix 1: SMWG Charter TLP:WHITE


TLP:WHITE


TLP:WHITE

Appendix 2: Historical Background BES Reliability Metrics and Possible Analogies for Security Metrics Metrics that quantify the relative levels of BES reliability from a planning and operations perspective are well-established and have been developed and reported by NERC since 2008. Metrics that describe the relative levels of BPS security performance from a physical and cyber security perspective are in the relatively early stages of development. Table B.1 provides each of NERC’s Adequate Level of Reliability (ALR) reliability metrics and discusses the extent to which there is an opportunity to develop an analogous metric for security performance.

Table B.1: ALR Reliability Performance Metrics and Analogies for Security Metrics

ALR ALR Title ALR Purpose Security

Analogy? Discussion

ALR 1-3

Reserve Margin To gauge the amount of generation capacity available to meet expected demand

Yes Consider metrics related to the amount of security in place that is above the minimum required by the NERC CIP standards to prevent events that would reduce BPS reliability.

CONCLUSION: Decided not practical due to the vast array of physical and cyber security methods and solutions employed by entities.

ALR 1-4

Transmission related events resulting in loss of Load

To track BPS transmission related events which resulted in firm Load Loss. This will allow planners and operators to validate their design and operating criteria assuring acceptable performance of the system

Yes Two security metrics have been developed that are analogous:

• Security Metric 1: Reportable Cyber Security Incidents

Count the number of Reportable Cyber Security Incidents that occur over time that have compromised or disrupted one or more reliability tasks of a functional entity. Of these Reportable Cyber Security Incidents, also count those that have resulted in a loss of Load, either directly or indirectly caused by the cyber security incident.

• Security Metric 2: Reportable Physical Security Events

Count the number of physical security reportable events that occur over time as a result of threats to a Facility or BES control center or damage or destruction to a Facility. Of these reportable

Appendix 2: Historical Background TLP:WHITE


TLP:WHITE



Analogy? Discussion

events, also count those that have resulted in a loss of Load, either directly or indirectly caused by the event.

CONCLUSION: Analogous security metrics currently in place.

ALR 1-12

Interconnection Frequency Response

There is evidence of continuing decline in Frequency Response in the three Interconnections over the past 10 years, but no confirmed reason for the apparent decline. The metric data trends and analysis will assist in identifying root causes of decline

No CONCLUSION: Frequency response is a technical characteristic of AC power systems. There is no equivalent for cyber or physical security.

ALR 2-4

Disturbance Control Standard Failures

Measure the Balancing Authority or Reserve Sharing Groups’ ability to utilize contingency reserve to balance resources and demand and return the Interconnection frequency within defined limits following a Reportable Disturbance

Yes The concept of sharing resources may also apply to security events. Explore ways in which the industry is able to demonstrate sharing information resources, for example, through the E-ISAC.

• Security Metric 3: E-ISAC Membership

The ability of the electricity sector to prevent and respond to security threats, vulnerabilities, and incidents will improve as more electricity sector organizations have ready access to E-ISAC information. Membership is diverse and includes large utilities serving many customers as well as smaller utilities with fewer customers. This metric requires all members to recognize that security risks can affect the reliability of the bulk power system, regardless of the individual utility affected.

• Security Metric 4: Industry-Sourced Information Sharing



TLP:WHITE



Analogy? Discussion

As E-ISAC member organizations increase the extent to which they share their own information regarding cyber and physical security incidents, all member organizations will be able to increase their own awareness and ability to respond quickly and effectively. This should enhance the resilience of the BPS to new and evolving threats and vulnerabilities.


ALR 2-5

Disturbance Control Standard events greater than Most Severe Single Contingency (MSSC)

Report the Balancing Authority or Reserve Sharing Groups' Reportable Disturbances greater than MSSC in order to measure how much risk the system is exposed to for extreme/unusual contingencies. The results will help validate current contingency reserve requirements and document how often these contingencies occur

Yes Similar to Security Metrics 1 and 2 noted in ALR 1-5 above.

Consider enhancing these security metrics to identify events that cause power system operators to take action to mitigate the impact, whether or not there is a loss of Load.


ALR 3-5

IROL Exceedance The NERC Glossary of Terms defines an IROL as an Interconnection Reliability Operating Limit that, if violated, could lead to instability, uncontrolled separation, or Cascading Outages that adversely impact the reliability of the Bulk Electric System. This metric will provide the industry with data describing how often these events occur, as well as their duration

Yes Consider metrics involving how long security systems are out of service or rendered inoperable. May be equivalent, for example, to loss of EMS/SCADA for situational awareness.

Consider metrics related to the time needed to address a vulnerability after it becomes known.

CONCLUSION: Needs further consideration, depends on incidents reported by individual entities.

ALR 4-1

Correct Protection System Operations

The purpose of this metric is to gauge the performance of protection systems (both

Yes Consider metrics that identify instances where security systems and processes correctly prevented



TLP:WHITE



Analogy? Discussion

generator and transmission) on the bulk power system

unauthorized access (e.g., failed access card swipes, alarms from intrusion prevention systems, malware and antivirus detection logs).

CONCLUSON: May be useful for individual entities, but not at the BPS-level as the correlation between these individual instances are not likely to affect reliability.

ALR 6-1

Transmission Constraint Mitigation – Planning Horizon

To gauge the robustness of the transmission system to meet reliability criteria through installed transmission capacity

Yes Consider metrics related to the amount of security in place that is above the minimum required to prevent events that would reduce BPS reliability.

CONCLUSION: Decided not practical due to the vast array of physical and cyber security methods and solutions employed by entities.

ALR 6-2

Energy Emergency Alerts (EEA)

Measure the duration and number of times EEA1, EEA2 and EEA3 alerts are issued and measure any unserved energy related to EEA3 events resulting from the interruption of firm load due to capacity and/or energy deficiencies

Yes Consider metrics related to the number and type of NERC Alerts published to inform entities of security vulnerabilities or incidents.

CONCLUSION: The number of NERC Alerts published each year is very small and therefore not statistically relevant. Decided to instead provide a narrative discussion of the NERC Alerts as part of the annual State of Reliability report.

ALR 6-11

AC Transmission Outages – Failed Protection System Equipment

The purpose of this metric is to gauge Failed Protection System Equipment as one of many factors in the performance of AC transmission system Automatic Outages

Yes Consider metrics related to the frequency and duration of security systems or processes that fail or are out of service.

CONCLUSION: Decided not practical due to the vast array of physical and cyber security methods and solutions employed by entities and varying abilities to identify security system



TLP:WHITE



Analogy? Discussion

failures. Low correlation with BPS reliability.

ALR 6-12

AC Transmission Outages – Human Errors

The purpose of this metric is to gauge Human Errors as one of many factors in the performance of AC transmission system Automatic Outages

Yes Consider metrics related to the number of security events that occur as a result of human error (as opposed to automated system failures).

CONCLUSION: Decided not practical due to the vast array of physical and cyber security methods and solutions employed by entities. Low correlation with BPS reliability.

ALR 6-13

AC Transmission Outages – Failed AC Substation Equipment

The purpose of this metric is to gauge failed substation equipment as one of many factors in the performance of transmission system Automatic Outages

Yes Consider metrics related to the number of security events that occur as a result of automated system failures (as opposed to human error).

CONCLUSION: Decided not practical due to the vast array of physical and cyber security methods and solutions employed by entities. Low correlation with BPS reliability.

ALR 6-14

AC Transmission Outages – Failed AC Circuit Equipment

The purpose of this metric is to gauge failed AC circuit equipment as one of many factors in the performance of transmission system Automatic Outages

Yes Same as above.

ALR 6-15

Element Availability Percentage & Unavailability Percentage

To determine the percent of transmission system Elements operated at 200 kV and above that are available and unavailable when outages due to automatic and non-automatic events are considered

No Unlike the operation of elements of the BPS, security failures should be considered as binary.

CONCLUSION: Percentage measures of security would not be meaningful.


TLP:WHITE

Conclusions Following Analysis of “Universe” of Cyber Security Metrics Table B.2 was developed after reviewing over 150 metrics developed by leading experts2 in cyber security metrics. This expansive and detailed set of metrics was reviewed by the SMWG to decide which may be worth considering from a BPS perspective. The SMWG review of the 150 metrics revealed that the vast majority were applicable to the individual entities (similar to EPRI’s security metrics initiative) and not the BPS as a whole. Out of the over 150 metrics, five were considered worth analyzing in greater detail and are provided on Table B.2. While these metrics focused on cyber security, the SMWG will consider any equivalent physical security metrics that may be appropriate. So as not to duplicate or conflict with NERC’s mandate related to standards, the SMWG will not consider metrics that require data already collected by NERC in support of its Compliance Monitoring and Enforcement program.

Table B.2: Conclusions after Considering the “Universe of Security Metrics”

# Metric Note Relevant to BPS?

Data Available at NERC?

Data Available at Entity?

SMWG Assessment

1 Number of attacks Consider using CRISP and CAISS pilot program to provide high-level data to indicate participation rate and type of attacks. Need to address confidentiality concerns.

Y Y Y Mid-term (2017)

2 Days since the last serious information security incident

Consider same data source as BPS Security Metrics 1 and 2 but devise a clever way of illustrating frequency over time.

Y Y Y Mid-term (2017)

3 % of technical controls that fail-safe

Controls that fail, especially silently, can be very risky in certain circumstances, hence this is highly context-dependent. Consider a limited set of specific controls (cyber and physical). Would require a data request. Considered to be too complex.

Y N Y Long-term (2018)

2 Ref. PRAGMATIC Security Metrics, Applying Metametrics to Information Security, W. Krag Brotby and Gary Hinton, 2013



TLP:WHITE

Table B.2: Conclusions after Considering the “Universe of Security Metrics”

# Metric Note Relevant to BPS?

Data Available at NERC?

Data Available at Entity?

SMWG Assessment

4 % of incidents for which root causes have been diagnosed and addressed

Failure to determine root cause invites recurrence. Consider OE-417s as data source (BPS Metrics 1 and 2) with follow-up process by E-ISAC. Depends on a more mature level of information-sharing and analysis by the EISAC. Consider longer-term.

Y Y Y Long-term (2018)

5 Number of information security events and incidents, major and minor

Even minor security breaches or incidents are indicative of untreated threats and vulnerabilities. Consider leveraging Low/Medium/High impact rating assets per CIP V5 for cyber and CIP-014 for physical. Depends on a more mature level of information-sharing and analysis by the EISAC. Consider longer-term.

Y N Y Long-term (2018)

Agenda Item 13b Critical Infrastructure Protection Committee Meeting


Compliance Input Working Group Update Action Update Background Critical Infrastructure Protection Committee (CIPC) will support the NERC Compliance Monitoring and Enforcement Program (CMEP) initiatives by providing timely technical expertise on matters related to cyber and physical security as requested by the NERC Compliance Assurance department. With the development of the compliance implementation guidance process, the role of the group will be to provide CIPC with support in the process. Summary The Compliance Input Working Group Update (CIWG) continues to work on the implementation guidance for placing BCSI in the cloud. A vendor visit was conducted in June to review the FedRAMP audit evidence to help with developing implementation guidance. No approvals by CIPC are expected at this time. There will be a face-to-face meeting immediately following the conclusion of the CIPC meeting to discuss future tabletops, draft implementation guidance, and encryption key management. An update will be provided on the work being done for the NERC/CIWG Cloud Implementation Guidance project. A vendor visit was conducted in June to compare the audit evidence of the FedRAMP audit to that of a NERC CIP audit. There will be a discussion around future work with different SaaS products for audit examples to be included in the implementation guidance/tabletops. There will also be a meeting immediately following the CIPC meeting to further the discussion around the implementation guidance, tabletops, and encryption key management.


Security Guideline for the Electricity Sector - Supply Chain Secure Equipment Delivery The objective of the reliability guidelines is to distribute key practices and information on specific issues critical to promote and maintain a highly reliable and secure bulk power system (BPS). Reliability guidelines are not binding norms or parameters to the level that compliance to NERC’s Reliability Standards is monitored or enforced. Rather, their incorporation into industry practices is strictly voluntary. Introduction An important element of an organization’s Supply Chain Risk Management Program is safeguarding the transportation of “information systems and components, or applicable system and communications interfaces”.1 Guidance in ISO/IEC 27002:2013 cites the need to help ensure that “the delivered information and communication technology products are functioning as expected without any unexpected or unwanted features”.2 This paper highlights some of the aspects to consider regarding secure transportation and delivery of systems and components, from component manufacturers to integrators, to vendors, and ultimately to the Bulk Electric System (BES). Assessing Risk and Cost-Benefit Risk management starts with an estimate of the risk to the BES should a product be received already compromised. First evaluate the nature of the equipment, the sensitivity of the operation for which the equipment is intended to take part, and its ability to affect networks and other elements of the system. Consider possible methods by which the device can be compromised and how easily this might be discovered at incoming inspection. For example, if compromise would require disassembly of the device and reprogramming chips, the security risks will be different from a device that can be reprogrammed through a communications interface. Include in procurement language that the vendor must have processes in place to address supply chain risk for component vendors, including incident response and secure delivery where appropriate. The risk presented by the device is a combination of the likelihood that it might be compromised, the criticality of its function and placement in the system, and the probability that a compromise would be

1 NIST SP 800-161 – Supply Chain Risk Management Practices for Federal Information Systems and Organizations 2 ISO/IEC 27002:2013 – Information technology – Security techniques – Code of practice for information security controls

• What type of equipment is being transported? • What level of operation does it impact? • What is the equipment’s function and potential to

impact the operation within the total system? • How might the equipment be compromised?

https://www.nist.gov/publications/supply-chain-risk-management-practices-federal-information-systems-and-organizations

https://www.iso.org/obp/ui/#iso:std:iso-iec:27002:ed-2:v1:en

Security Guideline for the Electricity Sector - Supply Chain | Secure Equipment Delivery 2 Approved by the Critical Infrastructure Protection Committee on September 17, 2019

discovered before the device is placed into service. Enhanced controls for shipping, handling, and storage should be considered for devices that are both critical to the operation and difficult to inspect. A cost-effective strategy for secure equipment delivery must consider risk and the cost to secure the equipment in question. If the security cost outweighs the potential impact a compromised product would have on the BES, other strategies should be considered. Transportation Decisions Once you have analyzed the type of equipment and level of risk, and the options available for secure delivery, choose the carrier and the services required to ensure the appropriate level of security. Maintain a list of carriers that meet the requirements for transport of particular components or systems. Enhanced Packaging Risk can be further reduced through enhanced security measures such as tamper evident tape, security inks, truck/trailer serialized steel bands or security seals, RFID (tracking only), and blister or clamshell packaging. Tracking versus chain-of-custody Based on the analysis discussed above, the equipment can be tracked (an available option for most carriers including USPS and courier services) or you can require additional chain-of-custody procedures. While tracking records the movement of a package from facility to facility, chain-of-custody provides evidence of the identity of each person or entity who had access to it during its movement. This helps to ensure that equipment remains “in the same condition from the moment it was sealed in the container at origin until the moment it was released into the receipted custody of another”,3 and provides accountability for discrepancies. Delivery and Storage Security does not end once the equipment is delivered to its destination. Also consider incoming inspections and processes, secure storage facilities, and internal chain-of-custody through deployment of the equipment. Incoming inspection Incoming inspection provides an opportunity to formalize awareness and reduce risk by applying simple checks and recording evidence of findings, including careful documentation of exceptions. The receiving inspection procedure should dictate who the receiving operator should contact for further scrutiny of the package if any damage or other compromise is detected. For freight deliveries, it is advised to take several

3 https://www.maritime-executive.com/article/tracking-and-chain-of-custody-the-difference

• Facility of origin product and packing list details • Enhanced packaging details • Location, date and time of release • Signatures (released by, received by) • Description of the package (visual inspection) • Receiver comments or observations

https://www.maritime-executive.com/article/tracking-and-chain-of-custody-the-difference


photos of the unopened package while the product is still in the truck when any damage or possible compromise is found. Inspection records should be retained, as they may become of interest if the subject item is involved in an incident. Here are some inspection steps to consider:

• Is the carrier the one(s) normally used by the vendor?

• Was there any unexpected delay between shipment by the vendor and receipt of the item?

• Was the packaging and its condition consistent with other shipments from the same vendor?

• Was there any evidence on the packaging or the device indicating it may have been opened?

• In the case of equipment, when the unit is first powered up, is it in the expected state? Do logs show unexpected events? Does it indicate the expected version(s)? The expected state should be noted for a new vendor or product and those expectations be made part of incoming inspection.

• If the shipment includes software media, is it packaged as expected? Secure facilities and staff Restricted access to receiving and warehouse facilities is among the best controls for maintaining the integrity of the equipment prior to installation to the BES. Based on risk, additional measures may be warranted, such as secure cages and video monitoring. In addition to security measures taken when hiring receiving and warehouse staff, assess and implement training and awareness required for each position. Incident Management Consider establishing processes to be followed if a shipment is received damaged or in a condition that suggests tampering, or if a shipment is lost. Procedures for logging incident management activities, handling of evidence, communication and escalation should be documented and clearly communicated to management and other applicable personnel, and those procedures should be followed when an incident occurs. Where appropriate, post-incident analysis should be conducted in coordination with the vendor and the carrier. Detailed guidance on information security incident management can be found in ISO / IEC 270354 and NIST SP 800-161.5 Working with your vendor Establish confidence in each vendor’s policies and procedures for supply chain security during the initial qualification stage, including transportation service providers. Know your preferred vendors’ processes for handling shipments that appear to have been tampered with or damaged. Provide clear and timely communication regarding enhanced security requirements for any given shipment.

4 ISO/IEC 27035 – Security incident management 5 NIST SP 800-161 – Supply Chain Risk Management Practices for Federal Information Systems and Organizations

https://www.iso.org/standard/44379.html

https://www.nist.gov/publications/supply-chain-risk-management-practices-federal-information-systems-and-organizations


Conclusion Cargo theft, lost or damaged equipment, and malicious tampering are unfortunate realities in today’s world; however, an increasing focus on security in-transit presents a number of choices for mitigating the risk of receiving compromised equipment. Additional topics and guidance for Supply Chain Security can be found on the Supply Chain Risk Mitigation Program page.6

6 https://www.nerc.com/pa/comp/Pages/Supply-Chain-Risk-Mitigation-Program.aspx

https://www.nerc.com/pa/comp/Pages/Supply-Chain-Risk-Mitigation-Program.aspx


Security Guideline for the Electricity Sector - Supply Chain Risk Considerations for Open Source Software The objective of the reliability guidelines is to distribute key practices and information on specific issues critical to promote and maintain a highly reliable and secure bulk power system (BPS). Reliability guidelines are not binding norms or parameters to the level that compliance to NERC’s Reliability Standards is monitored or enforced. Rather, their incorporation into industry practices is strictly voluntary. Open Source Software “Open source software is software with source code that anyone can inspect, modify, and enhance”.1 It may or may not also be available for download in binary form, ready to use. Common examples of open-source software are The Linux Operating System, Mozilla Firefox, and Google Chrome.

Open-source software is built periodically, incorporating submissions from a community of contributing developers to implement new features, address security vulnerabilities, and fix bugs. Users obtain the software, as well as updates when new versions are released, from a distribution point maintained by the community.

User trust in open-source software involves a combination of trust in the distribution point for the software, “faith” in the supporting community of developers and supporters, and observations from inspecting the code, each in varying degrees depending upon the user’s technical capability. Most users are “downloaders”, entirely dependent on the development and user communities for security support.

Open-source projects differ widely in their assumptions regarding the technical capabilities of their users, the thoroughness of documentation, and the level of support from the developer community. Because there is no buyer-seller relationship or contract, the user is responsible for evaluating his ability to support his use of the product himself, which includes proper installation, configuration, and ongoing monitoring for security vulnerabilities and updates.

Analyzing Operational Risk

A useful way to analyze risk and set priorities for reducing risk is to create a threat model (operational environment for the software) for the system being considered. A threat model describes the things that affect the system, the things the system can affect, and the criticality of those things. It also describes what can go wrong, either accidental or deliberately induced by an attacker, and how likely those are, as

1 https://opensource.com/resources/what-open-source

https://opensource.com/resources/what-open-source

Security Guideline for the Electricity Sector - Supply Chain | Risk Considerations for Open Source Software 2 Approved by the Critical Infrastructure Protection Committee on September 17, 2019

well as ways those threats can be reduced. Shown below is a list of some common things to consider when analyzing operational risks for software.

• Does the software require an Internet connection?

• Can the system be reached by an internal network user in a different department?

• How directly can the system be reached by an external attacker?

• What would be the impact (criticality) if the system failed (went offline or was disabled)?

• What would be the impact (criticality) if the system mis-operated (had inappropriate outputs)?

• What systems can be connected to or are reachable from the system and how critical are they?

• Where do the system’s inputs come from and how trustworthy are those inputs?

• Does the software require or run with administrative privilege?

• How trustworthy is the software?

A threat model helps you to determine the type and extent of compensating security controls that might be needed to reduce risk to an acceptable level.2

Evaluating Trustworthiness of Software

Risks of software can be roughly divided into risk that the software might not be authentic (a malicious look-alike), and risk that the software has defects than can be exploited as security vulnerabilities or that might cause misoperation.

The risk of software being inauthentic or having been tampered with can be reduced by always obtaining the software from its original point of distribution, normally a web site maintained by its creators. The original distribution point can usually be found using an Internet search engine, or perhaps in blog posting by its users. The distribution site should be protected by TLS (an HTTPS URL), which allows you to check the web site certificate to ensure that it is valid and that the certificate was issued to a “subject” or “subject alternate name” that is consistent with expectations for the software.3

The risk from defects comes from a combination of the probability that defects will exist balanced with the existence of an active community of maintainers and their responsiveness in addressing defects. Intelligence Sources

The Internet provides many resources that will provide evidence bearing on the activity, reputation, and trustworthiness both of a software product and of its development community.

• Use an Internet search engine to find the distribution point, and search for references or reputation

2 https://en.wikipedia.org/wiki/Threat_model 3 https://www.globalsign.com/en/ssl-information-center/what-is-an-ssl-certificate/

https://en.wikipedia.org/wiki/Threat_model

https://www.globalsign.com/en/ssl-information-center/what-is-an-ssl-certificate/


• https://www.virustotal.com/en - use to perform virus scan of files and URLs

• https://nvd.nist.gov/vuln/search?execution=e2s1 – search for reported security vulnerabilities

• https://scan.coverity.com/projects - code analysis statistics for some open source projects

• https://www.openhub.net – activity statistics for some open source projects

Case Studies Studying some past cyber security issues in the software supply chain helps to understand these risks and illustrate how defensive principles can be applied.

• Havex4

An attacker compromised legitimate distribution points for proprietary industrial control system software, leading to compromise of the suppliers’ customers when these versions were installed as updates.

Risk: An attacker can compromise a distribution point for software.

Countermeasure: Verify authenticity of software by verifying its digital signature or verifying the correct hash value.

• Heartbleed5

Heartbleed (CVE-2014-0160) was a serious implementation flaw in OpenSSL of the SSL “heartbeat” feature. It allowed a malformed “heartbeat” request to obtain replies containing confidential data like usernames and passwords that had been sent protected by TLS. It was originally discovered on April 3, 2014, and a patch was announced by the OpenSSL project just four days later, on April 7, 2014.

Heartbleed is notable because it illustrates that even active and well-supported projects can have serious issues.

Risk: Serious defects can and do arise, even in projects with an attentive developer community.

Countermeasure: Ensure that you understand where security announcements and advisories will be published and have a process to ensure that you look for and receive updates when they are released.

Unsupported Software Both open-source and proprietary software can become unsupported, meaning that the software is no longer being actively developed or updated. Most seriously, this means that the application poses an unknown risk - any security issues discovered in the software will not be fixed, and even if vulnerabilities become known, you may not be made aware of them.

4 https://ics-cert.us-cert.gov/advisories/ICSA-14-178-01 5 https://www.us-cert.gov/ncas/alerts/TA14-098A http://xkcd.com/1354/

https://www.virustotal.com/en

https://nvd.nist.gov/vuln/search?execution=e2s1

https://scan.coverity.com/projects

https://www.openhub.net/

https://ics-cert.us-cert.gov/advisories/ICSA-14-178-01

https://www.us-cert.gov/ncas/alerts/TA14-098A

http://xkcd.com/1354/


Organizations with their own development staff might be able to take over (“fork”) the open-source code base and continue development, or in the case of proprietary software, obtain the source code from its developers. Doing this requires bringing the code into a secure development process, including managing security vulnerabilities in its components. Few organizations are prepared to take ownership at this level.

Unsupported software should be avoided, especially in critical applications, but if you need to use unsupported software, the following measures can be used to minimize risk.

• Reduce attack surface6

remove or disable non-essential features

reduce privilege level (software should not run with administrative privilege)

• Control access

Restrict access to users cognizant of the risks and trained in secure operation procedures

• Isolate

prevent access to or from the Internet and tightly control access to the internal network using restrictive firewall rules

Consider operating on a hardened system reserved for that application

• Monitor

Use and monitor a host-based firewall

Consider application whitelisting

Additional topics and guidance for Supply Chain Security can be found at the Supply Chain Risk Mitigation Program page.7

6 https://en.wikipedia.org/wiki/Attack_surface 7 https://www.nerc.com/pa/comp/Pages/Supply-Chain-Risk-Mitigation-Program.aspx

https://en.wikipedia.org/wiki/Attack_surface


Security Guideline

Instructions

Review Period

Name of Individual or Organization(s) (list multiple if submitted by a group): applicable)Region (if applicable)Contact TelephoneContact Email

Supply Chain and Risk Considerations for Open Source Software

[email protected]

NPCC

Con Ed; Eversource; HQ; IESO; ISO-NE; NSPI; NYISO; NYPA; NYSEG; OPG; ORU; PSEG; USI; VELCO

Please use this form to submit comments on the draft Security Guideline. Comments must be submitted within the review period below to Tom Hofstetter ([email protected]) with the words “SCWG Security Guideline Comments” in the subject line. Only comments submitted in this Microsoft Excel format will be accepted. Both general and specific comments should be provided within this form.

Comments may be submitted by individuals or organizations. Please provide the requested information in Row 6. If comments are submitted on behalf of multiple organizations, list all organizations in Row 6. Please provide the Industry Segment and Region (if applicable) in Rows 7 and 8 and provide the requested contact information in Rows 9 and 10.

If you have any questions regarding this process, please contact Tom Hofstetter ([email protected])

July 1 - July 31, 2019

mailto:[email protected]

Orga Page # Line / Comment Proposed ChNERC Response

1

Discussed the first paragraph on the first page, especially this document’s definition of “open source.” - Request clarification that the provided definition is specific to this guideline, since some people have different definitions. Please clarify that this definition is not intended to be used as a compliance requirement, or a defined term in the NERC Glossary

The NERC SCWG is not recommending the definition for inclusion in the NERC Glossary of Terms.

2

Recommend adding these questions to the “Evaluating Trustworthiness Software” section 1) How often is the software patched? 2) What code review process is followed? 3) Is the source code checked for vulnerabilities? 4) Is it open contribution? Can anyone make a change? Is there a peer review of code changes?

The team was tasked with limiting this short paper to 2-3 pages and this paper is already three pages long. If these topics are added, some other sections must be cut. The intent of the short paper is not to make the reader an expert in these topics, but to introduce the topic to the reader.

3 - and throughout guideline

Question the use of links to third parties (like Wikipedia) in a CIPC Guideline

The team developing this short paper had a lengthy discussion around using this reference, but decided on this simple explanation because it summaries and helps the reader understand how to use a threat model. The team was specifically tasked to provide links for the reader to follow for more information.

3

We suggest that the bullets (recommendations) in “Unsupported Software” also apply to anysoftware. We suggest this topic could be its own Guideline (perhaps there is a better label herethan Unsupported Software). Additional discussion repeated this recommendation – thatUnsupported Software should be its own Guideline that spells out all of these concerns. Wesuggest leveraging an existing (controls) document.

Unsupported software has risks to the entity above normal risks associated with any software as discussed in the short paper. The NERC SCWG was tasked with developing a short paper on this topic and to introduce ideas to the reader without providing a lengthy document to review. The team agreed on the following general parameters (excerpt provided, not the full text) that address this comment:"Short papers should be limited to 2-3 pages each. The papers should be written to convey general guidance to the reader without having to read a lengthy document. Provide the reader references that they can research for more information, if they choose. Use the experience and expertise of the small team (and the SCWG) to identify best practices and challenges to the reader. What are the pitfalls the reader should know about and avoid? How does the reader learn about a specific topic and move forward to implement a solid program to improve reliability? If you start to get stuck on a specific issue, what is in the best interests of reliability?"


Security Guideline for the Electricity Sector - Supply Chain Cyber Security Risk Management Lifecycle The objective of the reliability guidelines is to distribute key practices and information on specific issues critical to promote and maintain a highly reliable and secure bulk power system (BPS). Reliability guidelines are not binding norms or parameters to the level that compliance to NERC’s Reliability Standards is monitored or enforced. Rather, their incorporation into industry practices is strictly voluntary. Introduction The supply chain is one of the biggest sources of cyber security risk for all businesses and government agencies in the world today. For example, the Target, Stuxnet and NotPetya cyber breaches all started in the supply chain. For the electric power industry in North America, supply chain cyber security is especially important because of the serious – and ongoing – attacks by foreign nation-states against critical infrastructure, extensively documented by the U.S. Department of Homeland Security1 and the Director of National Intelligence2. Because no NERC entity has resources that are adequate to mitigate all or even most of the supply chain cyber security threats that it faces, the entity should develop a plan to identify the threats that pose the greatest risk and mitigate those. Therefore, all NERC entities need to identify, assess and mitigate supply chain cyber security threats to their Bulk Electric System (BES) assets. Identifying Threats The entity’s first objective in the supply chain cyber security risk management (hereinafter “risk management”) process is to identify important threats to its BES assets. Some of these threats are common to all NERC entities, others to a small group of entities, and yet others to just one entity. Threats that are very unlikely to occur in the entity’s environment – or that would produce little impact if they did - should be documented, but need not be considered further. There are many sources for information on supply chain cyber security threats. These include:

• NERC documents including Cyber Security Supply Chain Risk Management Plans and the EPRI/NERC Supply Chain Risk Assessment: Final Report, and the NERC Cyber Security Supply Chain Risks report.

• White papers by the industry trade associations, including APPA, NRECA, EEI, NATF and NAGF • NIST 800-161 and NIST 800-171

1 DHS CISA, “Alert (TA18-074A) Russian Government Cyber Activity Targeting Energy and Other Critical Infrastructure Sectors”, available at https://www.us-cert.gov/ncas/alerts/TA18-074A 2 Daniel R. Coats, Director of National Intelligence, “Statement for the Record: Worldwide Threat Assessment of the US Intelligence Community”, available at https://www.dni.gov/files/ODNI/documents/2019-ATA-SFR---SSCI.pdf (ditto)

https://www.nerc.com/pa/Stand/Project%20201603%20Cyber%20Security%20Supply%20Chain%20Managem/Implementation_Guidance_071117.pdf

https://www.nerc.com/pa/comp/SupplyChainRiskMitigationProgramDL/EPRI_Supply_Chain_Risk_Assessment_Final_Report_public.pdf

https://www.nerc.com/pa/comp/SupplyChainRiskMitigationProgramDL/NERC%20Supply%20Chain%20Final%20Report%20(20190517).pdf

https://www.nerc.com/pa/comp/SupplyChainRiskMitigationProgramDL/NERC%20Supply%20Chain%20Final%20Report%20(20190517).pdf

https://www.us-cert.gov/ncas/alerts/TA18-074A

https://www.dni.gov/files/ODNI/documents/2019-ATA-SFR---SSCI.pdf

Security Guideline for the Electricity Sector - Supply Chain | Cyber Security Risk Management Lifecycle 2 Approved by the Critical Infrastructure Protection Committee on September 17, 2019

• NERC CIP-013-1 R1.2.1 – R1.2.6 • Cybersecurity Procurement Language for Energy Delivery Systems, developed by the Control

Systems Working Group of US DoE and the NERC CIPC • White papers developed by the NERC CIPC Supply Chain Working Group (SCWG), such as this one.

These as well as other NERC documents about supply chain cyber security are available at https://www.nerc.com/pa/comp/Pages/Supply-Chain-Risk-Mitigation-Program.aspx.

• Best Practices in Supply Chain Risk Management for the Federal Government, developed by the FBI

All of the above documents list mitigations for supply chain cyber security threats, not the threats themselves. However, it is easy to reword these mitigations as threats – although it’s important to remember that a statement of a threat must include the impact to the BES of the realization of the threat. An example of a good threat statement is “A vendor system that has been granted system-to-system access to a NERC entity's OT systems will be compromised by a malicious third party or a rogue insider and used to exploit an OT system at an entity-owned BES asset. This will result in damage to the BES.” This is a restatement of one of the two threats behind the mitigations in CIP-013 R1.2.6. Assessing Threats The result of the threat identification step is a list of supply chain cyber security threats that the entity deems worthy of consideration. Because the entity won’t be able to mitigate all of these threats, it needs to determine which pose the most risk to the BES. The entity does this by assigning a risk score to each threat, then ranking the threats according to their risk scores. Risk is a combination of likelihood and impact. The value of each of these two factors must be estimated; their sum or product is the risk score. Because there is no way to reliably assign precise numerical values to the likelihood and impact of a cyber event, the majority of NERC entities will likely assign values of low/medium/high or 1/2/3 to both factors. Other schemes like 1-5 and low/high are also possible. In determining the likelihood or impact of a threat being realized, the NERC entity can either use fixed criteria or simply estimate based on experience and knowledge. For example, one way to use fixed criteria to estimate likelihood of a threat is to a) identify vulnerabilities that would allow the threat to be realized, b) estimate the likelihood that each of those vulnerabilities will be in place, then c) take the highest of these estimates as the likelihood of the threat itself being realized. For example, using the threat discussed earlier, one vulnerability that would enable the threat to be realized is “A BCS vendor doesn’t have a good patch management program for its own systems.” If the likelihood of that vulnerability being in place – for one vendor or for vendors in general – is high, this means the likelihood of the threat itself being realized is high; this is the case no matter the likelihood of any other vulnerabilities that might be identified for this threat.

https://www.energy.gov/sites/prod/files/2014/04/f15/CybersecProcurementLanguage-EnergyDeliverySystems_040714_fin.pdf


https://www.fbi.gov/file-repository/scrmbestpractices-1.pdf


Once the entity has estimated both likelihood and impact of a threat as low/medium/high, they may assign values of 1/2/3 to both estimates, then add them to get the risk score. The risk score will be in a range of 2 to 6. After developing risk scores for all the important threats, the entity now should rank those threats from high to low risk, and choose the threats it will mitigate. The entity should try to choose threats to mitigate so that the maximum amount of total risk is mitigated, given the resources available to the entity. This will usually, although not necessarily always, be achieved by mitigating the threats with the highest risk scores. The threats that the entity chooses to mitigate are called Actionable Threats. Mitigating Threats Once the entity has chosen the Actionable Threats that it will mitigate, it will determine appropriate mitigations for those threats. These can include mitigations that are applied on an ongoing basis, such as vendor contract language, as well as mitigations that are only applied when there is a particular transaction – e.g. a purchase or installation of a BES Cyber System. The goal of mitigation is to bring the risk posed by a threat to the low level – e.g. a risk score of 2 or 3, out of a possible range of 2-6. This is achieved by mitigating each of the significant vulnerabilities that could enable that threat to be realized. Returning to the original threat example, significant vulnerabilities could include the vendor’s a) ineffective patch management program, b) lack of anti-phishing training, and c) inadequate controls over remote access to vendor systems. One way to mitigate each of these significant vulnerabilities would be to require the vendor to a) improve their patch management program, b) conduct anti-phishing training, and c) require two-factor authentication for remote access to their systems. This commitment could be documented in an RFP, in a contract, in a letter from the vendor’s management, etc. However, no matter how the NERC entity documents the vendor’s commitment, the entity also needs to verify the vendor kept its promises. If these requirements don’t provide enough risk mitigation in the case of a particular vendor, or if the vendor refuses to cooperate, the entity should also institute controls of its own to mitigate the risk. Going back to the example, one particularly effective mitigation might be ending system-to-system remote access for the vendor. Procurements and Installations Each new product or service procurement or installation should be the subject of a risk assessment. Two powerful tools that aid these assessments are vendor risk score and product risk score. A vendor risk score can be determined for each Actionable Threat, based on – for example – the vendor’s responses to a questionnaire. For each Actionable Threat that applies to the procurement, a procurement risk score can be calculated by adding the vendor and product risk scores for that threat. If the procurement risk score is low, the entity may choose not to mitigate this particular Actionable Threat (beyond the level they would in the case of any other procurement). If the score is medium or high, the entity can mitigate the threat by mitigating each of the vulnerabilities that allow the threat to be realized (i.e. reducing each


vulnerability’s risk score to low, by reducing its likelihood of being present, its BES impact or both). This same procedure can be followed in the case of installations of procured products. Updating the Risk Management Plan All the steps described above should be included in a supply chain cyber security risk management plan. The plan should be updated approximately annually, and perhaps more frequently if new developments warrant doing that. The update should include:

• Identifying significant new threats and assignment of risk scores to them; • Re-scoring the threats identified previously, based on new estimates of likelihood and impact; • Updating the list of Actionable Threats based on updated risk scores of both previously-identified

and newly-identified threats; • Identifying significant new vulnerabilities that would enable Actionable Threats to be realized; and • Reviewing mitigations for each Actionable Threat, to determine whether they are still appropriate.

Considerations include whether any current mitigations have proven insufficient or unnecessary, and whether new mitigations have become available that might provide further risk reduction.

Conclusion The fundamental problem of supply chain cyber security is that no NERC entity has the resources to mitigate all BES risks, or even the majority of them. Following an approach like the one described above is the best way to ensure the entity mitigates the greatest possible total supply chain security risk, given its available resources.

Security Guideline

Instructions

Review Period

Name of Individual

or Organization(s)

(list multiple if submitted by a group):

Industry Segment (if applicable)

Region (if applicable)

Contact Telephone

Contact Email

212.840.1070

[email protected]

NPCC

Con Ed; Eversource; HQ; IESO; ISO‐NE; NYISO; NYPA; OPG; ORU; USI; VELCO;

Supply Chain Cyber Security Risk Management Lifecycle

Please use this form to submit comments on the draft Security Guideline. Comments must be submitted within the review period below to Tom Hofstetter

([email protected]) with the words “SCWG Security Guideline Comments” in the subject line. Only comments submitted in this Microsoft Excel

format will be accepted. Both general and specific comments should be provided within this form.



July 1 ‐ July 31, 2019

Organization(s) Page # Line / Paragraph Comment Proposed Change SCWG Response

1

We recommend replacing the second Introduction paragraph with “Entities should assess theresources to identify and mitigate the threats.” This is a more positive tone than the existingnegative tone. The existing second paragraph could be read differently – imply that theindustry is in worse shape.

Entities should assess the resources to identify and mitigate the threats.

We revised the sentence in question. That should be less negative. Change is highlighted in red.

general

We don't know what you're referring to. Each guideline covers a different concept, so they of course use different language.

1 ‐ 2

Bottom of page 1 says the bullets are “sources of information on supply chain security threats” and the top of page 2 says those bullets are mitigations for supply chain cyber security threats. Recommend clarifying by keeping one or the other but not both statements.

The documents are sources of information. The information they contain is mitigations. We think this is clear with the current wording, which we have highlighted on page 2.

1

For sources, E-ISAC should be listed.

We are just listing documents here. We know of no E-ISAC document on supply chain security threats, but if there is one, we will list it.

2

Mitigation activities should be in the Mitigation section of the document, which is not the Identification section.

As discussed above, the Identification section states that the documents list mitigations, and the entity needs to reword those mitigations as threats. Threats are what is being identified, not mitigations.

2

We suggest re-wording the paragraph at the top of page 2 since it appears to be backward – determining the threat by knowing the mitigation. Suggest a reference to the NIST Risk Management – IT Threat Assessment

The point of this section is that we know of no document that lists supply chain cyber threats directly. However, documents that list mitigations, like the documents listed in bullet points, implicitly list threats, since every mitigation addresses a threat. The entity can fairly easily reword the mitigations to state the threats behind them. It would be desirable if there were a document that listed supply chain security threats to the BES, but there isn't one now.

2 Assessing Threats

The description of threat and risk assessment in Supply Chain Risk Management Lifecycle is fine, but we would very much like to see what would be considered adequate in regard to coverage with threat assessment and risk assessment as part of the guidance on page 2 (Assessing Threats). How many and which kinds of threats and at what level of granularity (strategic, tactical, per cyber asset or function, etc.) should be addressed by a responsible entity? Is there a definitive or indicative list of subjects to cover? Are there references that would be considered adequate or minimally complete in this regard? The general description does not convey what would be considered good enough practice in this regard and would possibly lead to disagreements or dispute during audit of an entity’s practice.

This is a good suggestion, but these Guidelines were limited to 3-4 pages, in order to make each one readable. What you suggest would be a good topic for another paper.

2 Assessing Threats

Recommend removing “BCS” from “A BCS vendor doesn’t have a good patch management program for its own systems.” We suggest making similar changes elsewhere so that this Guideline can be used for future revisions of CIP-013, which will put additional assets into scope

Good idea, but not for the reason you're suggesting. Remember, this paper isn't about CIP-013 compliance, and it never will be. But BCS is a CIP term, and it shouldn't be in there. We removed it in the two places it appears, and replaced it with "an OT system".

2 Assessing Threats

Recommend using “exploited” instead of “threat realized”

We understand that exploit is the more common term. The problem is it implies that there's some identifiable party doing the exploiting. A few threats have identifiable (in principle) actors, but most don't. For example, the threat that a vendor will unexpectedly stop issuing patches for a system which isn't scheduled to be replaced and is currently working well.

3 Mitigating Threats

The second paragraph uses a risk scoring but does not mention the methodology / framework. Request clarification. Should not use a risk score unless the guideline provides specifics.

The methodology is described on the previous page.

general for all guidelines

guidelines should not use “need” or “must.”

Remember again, we're not talking about compliance in any of these papers. We would need to see examples of what you think is objectionable.


Recommend changing this third paragraph from “However, no matter how the NERC entity documents the vendor’s commitment, the entity also needs to verify the vendor kept its promises.” To “However, no matter how the NERC entity documents the vendor’s commitment, the entity should follow its procurement practices in verifying the vendor met its obligation.”

However, no matter how the NERC entity documents the vendor’s commitment, the entity should follow its procurement practices in verifying the vendor met its obligation.

We like our wording better. We don't want to assume the entity already has procurement practices spelled out. If they do, they probably don't need these guidelines in the first place. You seem to be concerned that this is a compliance document. It isn't.


Request help with how-to verify the vendor met its obligation. What are the means? What will the auditor be looking for?

We were aiming for 3 pages for each white paper, although this one is a little over. We just can't provide much detail at all. This might possibly be a topic for a future white paper. But of course, you'll find no discussion of what auditors are looking for in any of these papers!


Last paragraph – first sentence is may be acceptable. We recommend clarification. Recommend striking the last sentence. Do these requirements refer to CIP-013?

No, nothing in this or any other paper refers to CIP-013. We like this wording as it is.

3

Procurements and Installations

We suggest that the vendor’s risk score is more than how the vendor addresses Actionable Threats, like the vendor’s cyber security practices, vendor’s cyber security controls, how well those controls are implemented, etc.

The vendor's practices and controls are mitigations for the threats. If the vendor has done a good job of mitigating a particular threat, that threat will have low likelihood for the vendor, and probably a low risk score as well.

general

we request the Guideline tell us which procedural methodology / framework the authors are using. Are these examples custom developed? Are the examples referring to NIST? Are the examples consistent with each other? Perhaps an Appendix with a thorough (start to finish) example that the Guideline can keep referencing

We're flattered that you think we developed this from a particular authoritative source. It was developed from a number of sources and extensive discussions among the group. The same goes for all the other papers. If there were authoritative sources for these topics, we wouldn't have needed the white papers in the first place.

3 ‐ 4Updating the Risk Management Plan

This language gets too prescriptive for a guideline

We don't agree. Once again, this has nothing to do with compliance.


We believe that the Plan should be develop / maintain threat model. This section is more about the model not the plan – making the title or the words incorrect. This section describes how to maintain the risk register, not the plan

This paper discusses how an entity (in any industry) can develop a plan for identifying and mitigating supply chain cyber security risks. If anybody wanted to make it different from that, they were welcome to join the numerous discussions we had on this paper. We're not going to go back and make fundamental changes now.


Further, if guideline sets the expectation of the plan’s scope – we recommend that a good plan should include . . .

The entire paper is a recommendation of what a good plan might include, but we're not going to use "should". You said you didn't want prescriptive language, but now you seem to be asking explicitly for that.


Security Guideline for the Electricity Sector - Supply Chain Vendor Risk Management Lifecycle The objective of the reliability guidelines is to distribute key practices and information on specific issues critical to promote and maintain a highly reliable and secure bulk power system (BPS). Reliability guidelines are not binding norms or parameters to the level that compliance to NERC’s Reliability Standards is monitored or enforced. Rather, their incorporation into industry practices is strictly voluntary. Introduction The supply chain cybersecurity risk management plan (“risk management plan”) addresses risks that originate with vendors; these form part of the total set of supply chain cybersecurity risks. The stages of the vendor risk management lifecycle include vendor acquisition, procurement(s) from the vendor, installation and use of the product or service (including vendor support and patching), and termination of the vendor relationship. Vendor risks need to be mitigated during each of these stages. As is the case for all supply chain cybersecurity risks, a NERC entity must identify, assess, and mitigate vendor risks. The vendor risk management lifecycle constitutes one component of the entity’s supply chain cyber security risk management plan. The plan itself is the subject of a separate SCWG white paper, “Supply Chain Cyber Security Risk Management Lifecycle,” which describes the general processes of identification, assessment, and mitigation of supply chain cybersecurity risks. Because this white paper provides examples of vendor risks and suggested mitigations for them, NERC entities should consider these as they develop their overall risk management plans. Mitigating Risks during Vendor Acquisition In some cases, acquiring a new vendor will occur as a separate process from actual procurements from that vendor; in other cases, the vendor acquisition and procurement steps will be combined. In the former case, the NERC entity will usually put out a Request for Proposal (RFP) to multiple vendors. Some possible steps for the entity to mitigate BES risk through the RFP process are:

• For closed RFPs, consider establishing a process for cyber risk informed invitations to participate in the RFP. Such a process should consider approved entity lists, intelligence sources, and public information such as history of vulnerability handling and web site hygiene.

• Require the vendor to sign a mutual non-disclosure agreement (MNDA), so that any information provided to the NERC entity will be protected, and vice versa.

• Include a questionnaire designed to gather information about the vendor’s mitigations for the identified BES risks documented in the risk management plan. If a standardized questionnaire is used, questions that don’t relate to the set of risks that the entity has decided to mitigate in their risk management plan should be omitted; it is a waste of both the entity’s and the vendor’s time

Security Guideline for the Electricity Sector - Supply Chain | Vendor Risk Management Lifecycle 2 Approved by the Critical Infrastructure Protection Committee on September 17, 2019

to require answers to questions that the entity has already decided don’t deal with risks that are important enough to mitigate.

• The RFP can include sample contract language; the vendor might be asked to agree to this language or to suggest modifications. Similarly to the questionnaire, the entity should make sure there are no contract provisions that don’t correspond to risks it has decided to mitigate.

• As an alternative to including security provisions in contract language, the NERC entity can make these deliverables in the RFP itself.

• If the vendor wishes to cite particular security certifications as risk mitigation measures, they should be required to provide supporting evidence such as an audit report.

• One risk mitigation measure is to request that the vendor provide a software bill of materials (SBoM) for all components of their software and/or firmware that were developed by third parties - whether purchased or open source. An SBoM allows the entity to identify components known to present risks and hold the vendor accountable for providing patches for those components, when available and applicable.

Assessing Vendor Risks after Acquisition Once a vendor relationship is in place, the NERC entity needs to continually identify, assess and mitigate residual and new risks posed by the vendor. Following are some of the steps that NERC entities can take to assess vendor risk:

• Entity-developed questionnaires can be provided regularly (on a schedule determined during procurement) to the vendor. The questionnaire should address the set of BES risks documented in the then-current risk management plan. It should be designed to determine, for each risk in the risk management plan, if changes have occurred that would increase or reduce this risk, or if the vendor has effectively mitigated this risk. It is important to let the vendor know in the original RFP that failure to answer questions, or failure to take mitigation steps requested, may cause the entity to terminate the relationship.

• Before submitting a questionnaire to a vendor, the entity should go through any documents made available by the vendor (on their public web site or directly to their customers), to determine whether any of the questions have already been satisfactorily answered in those documents.

• The entity may also use questionnaires developed by industry organizations. If the vendor has already provided answers to such a questionnaire, the NERC entity should first review those answers, to determine whether these have addressed at least some of their questions. They should then submit the remaining questions to the vendor.

• The entity should consider a vendor’s certification to an industry recognized third-party cybersecurity standard, such as ISA/IEC 62443, ISO 27001 or SOC2, if available from the vendor. Such standards require annual audits by accredited independent third parties, and provide constant oversight of the vendor’s ability to meet industry best practices for supply chain security and secure development practices. Such a certification may address many of the questions in the entity’s questionnaire, although the entity should not hesitate to ask the vendor to identify where


specifically in the certification document each of their questions is answered, and to still require the vendor to answer any questions not satisfactorily addressed by the certification. However, making certification to such standards an absolute requirement for the vendor may lead to cost increases or refusal by the vendor to sell to the entity.

• The NERC Implementation Guidance for CIP-013-11 suggests “Periodic review processes…can be used with critical vendor(s) to review and assess any changes in vendor’s security controls, product lifecycle management, supply chain, and roadmap to identify opportunities for continuous improvement.”2 The entity can conduct direct assessments or use a third party engaged by the entity. The entity and the vendor should agree during the procurement on the frequency and content of assessments, as well as who will bear the costs. However, these assessments can be expensive, both for the entity and for the vendor.

Means of Securing the Vendor’s Commitment to Mitigations No matter the means used to assess vendor risks, once it has identified risks applicable to a particular vendor, the NERC entity should try to get the vendor to help mitigate those risks. The vendor’s agreement to do this should be documented using one or more of the following methods:

• Language in an RFP should provide clear criteria for vendor responses, so that the entity can determine to what degree the vendor has mitigated each of the risks it considers important.

• Language in a contract should document the vendor’s commitment to implement specific security controls, provide for the entity to review the vendor’s progress, and identify methods for future communication on these matters. If prewritten contract language is used, it should be reviewed and tailored only to include clauses that correspond to risks identified in the entity’s risk management plan.

• Letter from the Vendor. If contract language is infeasible or impractical, a letter – preferably from a high-ranking official at the vendor - can also be used to document the vendor’s commitment to implementing particular security controls to mitigate risks the entity considers important.

• Verbal commitment. If the commitment from a vendor can only be obtained verbally, record the conversation, with permission, or take notes. Document the person’s name, title, date, time, and key points of the conversation. Document the vendor’s exact words as closely as possible.

• Vendor meeting. The NERC entity might have regular meetings for vendors. At those meetings, the agenda should include a discussion of relevant risks and discussion of how the vendors can work with the entity to mitigate those risks. The entity should take notes during the meeting and publish minutes for all vendors, whether or not they were able to attend the meeting.

When evaluating the usefulness of vendor contract language for risk mitigation, it is important to consider:

1 Implementation Guidance for CIP-013-1 2 NERC, “Cyber Security Supply Chain Risk Management Plans - Implementation Guidance for CIP-013-1”, July 2017, p. 3.

https://www.nerc.com/pa/Stand/Project%20201603%20Cyber%20Security%20Supply%20Chain%20Managem/Implementation_Guidance_071117.pdf


• Contract language governing purchases made from resellers or other intermediaries may not be binding on manufacturers or software developers; and

• Contract language may not apply to purchases made from stores or distributors, or products or services purchased from online-only vendors, since these transactions typically are not governed by a contract.

Verifying Vendor Compliance with the Entity’s Security Requests No matter how the entity has documented that a vendor agreed to comply with its request for risk mitigation(s), the NERC entity always needs to verify that the vendor is actually complying. There are many different means to accomplish this goal, which will vary according to a) the degree of trust the entity places in the vendor, and b) the nature of the mitigations agreed to. These means can include a new questionnaire, emails, face-to-face meetings, phone calls, audit by the entity or a third party, and direct evidence such as entity documents showing the degree to which a vendor has taken particular steps – e.g. notifying the entity when an employee with BES Cyber Systems access has been terminated. However, there is always the possibility that the vendor will fail to perform some or all of what it promised to do. When that happens, the entity should always take some action. Possible actions include:

• Document and communicate with the vendor the gap in performance, the expected service, and applicable contract terms or documented commitment.

• Engage management or senior leadership of the vendor, to impress on them the importance of the control(s) or mitigation(s) and the need to implement remediation of the gap in performance.

• Communicate to the vendor that performance measures will be reflected in future scoring or evaluation of new purchases of products or services.

• Take legal action if needed.

• Evaluate terminating the relationship with the vendor.

• Apply internal mitigations to the risk, if the vendor simply will not cooperate. If the entity has committed to mitigating a particular risk in its risk management plan, it must do that, whether or not a vendor cooperates.

Mitigating Risk in Particular Procurement Transactions Every procurement should begin with an assessment of the risks that apply to procuring a product or service, as well as threats that apply to installing a product. The entity should determine risk scores for each vendor and each product or service procured (preferably at the level of individual threats). The vendor and product risk scores can be combined to obtain an overall procurement or installation risk score. The procurement or installation risk score can be used to determine the level of mitigations applied to the applicable risks during the procurement or installation. Higher scores could warrant strong mitigations, while low scores could warrant little or no mitigation beyond the entity’s normal procedures.


Terminating a Vendor Relationship or Transitioning between Vendors When an entity terminates an existing vendor relationship or transitions to a new vendor, a process should be in place to identify and mitigate the risks associated with the termination or transition.3 Additional topics and guidance for Supply Chain Security can be found at Supply Chain Risk Mitigation Program page.4

3 For a good discussion of mitigating risks attendant on terminating a vendor relationship, see Utilities Telecom Council, “CYBER SUPPLY CHAIN RISK MANAGEMENT FOR UTILITIES - ROADMAP FOR IMPLEMENTATION”, available at https://utc.org/wp-content/uploads/2018/02/SupplyChain2015-2.pdf, pp 13-14. 4 https://www.nerc.com/pa/comp/Pages/Supply-Chain-Risk-Mitigation-Program.aspx

https://utc.org/wp-content/uploads/2018/02/SupplyChain2015-2.pdf

https://utc.org/wp-content/uploads/2018/02/SupplyChain2015-2.pdf


Security Guideline

Instructions

Review Period

Name of Individual

or Organization(s)


applicable)

Region (if applicable)Contact Telephone

Contact Email

Security Guideline Vendor Cyber Security Risk Management Lifecycle

212.840.1070

[email protected]

NPCC

Cogentrix; Con Ed; Eversource; ISO‐NE; NYSEG; NYISO; OPG; ORU; PSEG;

Please use this form to submit comments on the draft Security Guideline. Comments must be submitted within the review period below to Tom Hofstetter ([email protected]) with the words “SCWG

Security Guideline Comments” in the subject line. Only comments submitted in this Microsoft Excel format will be accepted. Both general and specific comments should be provided within this form.



July 1 ‐ July 31, 2019

Organization(s) Page # Line / Paragraph Comment Proposed Change SCWG Response

3

Means of Securing the Vendor’s Commitment to Mitigations

These bullets are in the preferred order The order has nothing to do with preference.

3 ‐ 4

Verifying Vendor Compliance with the Entity’s Security Requests

This is too much compliance and does not belong in a guideline - “No matter how the entity has documented that a vendor agreed to comply with its request for risk mitigation(s), the NERC entity always needs to verify that the vendor is actually complying.” Suggest that the Entity should follow its procurement procedure(s). And we question if this language expands CIP-013’s scope?

This paper is about supply chain security, not CIP-013. These papers are aimed at NERC entities, so they may sound like compliance guidance, but they're not. This passage is simply saying that, rather than just be satisfied with getting the vendor to agree to do something, you should take steps to verify they're actually doing it. The word "complying" means the vendor's compliance with their promise, nothing about CIP-013 at all.

3 ‐ 4

Verifying Vendor Compliance with the Entity’s Security Requests

We recommend removing “Take legal action if needed” because a guideline should not recommend such an extreme response. We suggest that legal action should be the last resort

Exactly. It should only be used when needed - i.e. as a last resort. That is what it says. There's no need to change it.

4

Terminating a Vendor Relationship or Transitioning between Vendors

We are concerned that this language may expand CIP-013’s scope – “When an entity terminates an existing vendor relationship or transitions to a new vendor, a process should be in place to identify and mitigate the risks associated with the termination or transition.” We suggest something like “An Entity may want to consider the risk associated with this process.”

We suggest something like “An Entity may want to consider the risk associated with this process.”

Again, the paper has nothing to do with CIP-013 compliance. The entity should identify and mitigate risks associated with termination or transition of a vendor relationship. There's nothing that needs to be changed.


Security Guideline for the Electricity Sector - Supply Chain Provenance The objective of the reliability guidelines is to distribute key practices and information on specific issues critical to promote and maintain a highly reliable and secure bulk power system (BPS). Reliability guidelines are not binding norms or parameters to the level that compliance to NERC’s Reliability Standards is monitored or enforced. Rather, their incorporation into industry practices is strictly voluntary. Introduction Knowing the source of supply chain threats can help in designing targeted and effective defenses against counterfeiting, unlawful intrusion, industrial espionage, and other cyber-security breaches. The risks of not knowing the sources of threats occur at all stages of planning, development, installation, maintenance, and disposal.1 Risks and Possible Outcomes of Poor Provenance Awareness or Management Table 1.1: Risks and Possible Outcomes. At a minimum, “provenance” helps ascertain whether a source is authentic (genuine or counterfeit). More fully, related to chain of custody and lineage, it entails traceability – having a “record of element origin along with the history of, the changes to, and the record of who made those changes.”2 Acquirers, integrators and suppliers should have best practices in provenance as a part of supply chain cyber-security. Good provenance requires tools and processes for identity management, access, tagging, tracing, and more.

Table 1.1: Risks and Possible Outcomes

Stage Origination (Provenance) Risk Possible Outcome

Planning • Buyers not aware of adversaries or their actions

• Provenance not considered in procurement process

• Adversaries operate undetected within active contracts, under subcontracts, or from outside

• New contracts signed with no visibility past the immediate vendor

1 Additional guidance for Supply Chain Security is at https://www.nerc.com/pa/comp/Pages/Supply-Chain-Risk-Mitigation-Program.aspx. 2 National Institute of Standards and Technology (NIST) Notional Supply Chain Risk Management Practices for Federal Information Systems


Security Guideline for the Electricity Sector - Supply Chain | Provenance 2 Approved by the Critical Infrastructure Protection Committee on September 17, 2019

Table 1.1: Risks and Possible Outcomes

Stage Origination (Provenance) Risk Possible Outcome

Development • Equipment and software of unknown or unverified origin

• Adversaries operate invisibly through subcontracts

• Open source software used with no vetting

• Inadvertent dealings with Denied Persons

• Remote connections hacked using stolen credentials or back doors

Installation • Equipment and software of unknown or unverified origin

• Code is inserted or altered by Adversaries before insertion or use

Maintenance • Equipment sent for repair or replacement without traceability

• Weak access privileges

• Weak Human Resource policies on personnel and access

• Vendors don’t inform customers of vulnerabilities or threats

• Unknown third parties substitute or alter, inserting malware or security weaknesses, intentionally, to cut cost, or negligently

• Adversaries make malicious critical configuration changes

• Patches do more harm than good

• Adversaries penetrate live sites

• Vulnerabilities and threats undetected until it’s too late

Disposal • No end-of-life disposal process • Adversaries repurpose obsolete product or code with security vulnerabilities


Initial Best Practices in Supply Chain Provenance Management Establish a policy that governs and limits development in adversarial environments Establish a corporate data governance policy that limits the flow of development to riskier development environments. As an example, the U.S. Bureau of Industry and Security (BIS) establishes policies on commerce between the U.S. and foreign countries and maintains a list of Sanctioned Destinations.3 Monitor compliance against Denied Persons, Disapproved Vendors, and Related lists and orders Establish procedural checks against lists of current and potential adversaries. Executive Order 13873 establishes criteria for prohibiting certain trade,4 and the Department of Commerce maintains a Consolidated Screening List that is built from a Denied Persons List5, an Entity List, and an Unverified List. In addition to screening, make sure procurement decisions take into account the ultimate beneficial owner, not just the party of record.6 Most companies’ procurement departments have approved vendors and some have a blacklist based on these or similar principles and tools. Use standard contract language about provenance Consider standard contract language regarding provenance. EEI provides four pages (pages 8-11) of contract language specifically designed to address CIP-013 Section R1.2.5.7 Also, “Cybersecurity Procurement Language for Energy Delivery Systems” provides sample contract language for Account Management, Session Management, Logging and Auditing, and Secure Development.8 Require internal and external vendors to validate the authenticity and origins of third party hardware and software Obtain confirmation from integrators and suppliers that outsourced products and services are from where they purport to be, which includes requiring vendors to identify open source products, at the prequalification stage. EEI’s contract language (R1.2.5a on page 8) includes two paragraphs on validating origins. NIST IR 7622 provides additional language for procedural requirements, with more specificity and in some cases more directly relation to data lineage.9 O-TPPS (section 4.2.1.10) offers language specific to open-source software and requires suppliers to provide assurance of reliable component lineage.10 NATF requires suppliers to be able to ensure the integrity and authenticity of all software and patches.11 Require vendors to use strong authentication and cryptographic methods Ensure that vendors are using strong, multi-factor authentication methods that make it much harder for impostors to make configuration changes to configuration management and other product delivery 3 https://www.bis.doc.gov/index.php/policy-guidance/country-guidance/sanctioned-destinations 4 Executive Order 13873: Securing the Information and Communications Technology and Services Supply Chain. Federal Register Vol. 84, No. 96. May 17, 2019. 5 https://www.bis.doc.gov/index.php/policy-guidance/lists-of-parties-of-concern/denied-persons-list 6 https://www.fincen.gov/sites/default/files/2018-04/FinCEN_Guidance_CDD_FAQ_FINAL_508_2.pdf 7 Edison Electric Institute (EEI) Model Procurement Contract Language (Version 2) 8 U.S. Department of Energy (funded) Cybersecurity Procurement Language for Energy Delivery Systems 9 Edison Electric Institute (EEI) Model Procurement Contract Language (Version 2) 10 ISO/IEC Open Trusted Technology Provider Standard (O-TTPS) -- Mitigating maliciously tainted and counterfeit products: Part 1. 11 North American Transmission Forum CIP-013-1 Implementation Guidance

https://www.bis.doc.gov/index.php/policy-guidance/country-guidance/sanctioned-destinations

https://www.bis.doc.gov/index.php/policy-guidance/lists-of-parties-of-concern/denied-persons-list

https://www.fincen.gov/sites/default/files/2018-04/FinCEN_Guidance_CDD_FAQ_FINAL_508_2.pdf


systems. PCI’s Data Security Standard recommends authenticating users based on a multi-factor process consisting of something you know, such as a password, something you have, such as a token device, and something you are, such as a biometric.12 The Energy Delivery Systems report specifies cryptographic systems. DOE and DHS recommend assigning multifactor credentials for higher-risk access.13 ISO 27034 favors using a computer-driven security protocols for higher risk access, without human intervention.14 Require vendors to manage credentials stringently, including periodic deprovisioning Examine vendors’ processes for managing their access credentials in order to make it harder for malicious actors to fraudulently gain access to credentials and access privileges. At C2M2’s Maturity Level Indicator (MIL) 2, IT administrators should regularly ensure that credentials are associated with the correct person or entity, and they should deprovision access within defined time thresholds when they are no longer required. At MIL3, the requirements for credentials are determined by a multi-factor risk assessment.15 Require vendors to deny communications with risky profiles and log denied access incidents Maintain a secure boundary and log all traffic and its attributes; log denied access incidents to maximize forensic investigative potential. AICPA’s Trust Services include provisions to authenticate data subjects' identity, as well as to communicate denial of access requests, in order to allow better traceability, diagnostics, and forensics that ultimately would allow for better management of provenance issues.16 CIS’s “CIS Controls” recommend denying communications with known malicious I.P. addresses.17 Use intelligence about active and potential threat sources to mitigate active threats Integrate knowledge about current threats to mitigate active supply chain cybersecurity risks. SAFECode’s Framework for Supply Chain Integrity recommends referencing a threat library,18 and NIST 800-53r4 recommends using “All-Source Intelligence.”19 NIST maintains a National Vulnerability Database,20 and the U.S. Cybersecurity and Infrastructure Security Agency (CISA) lists cyber threat resources.21 Require vendors to establish a documented patch process with safeguards against malicious actors Review the adequacy of security within vendors’ patch processes and consider requiring suppliers to be capable of ensuring the integrity and authenticity of software and patches, as recommended by NATF.22 They should define the process flow as well as responsibilities, accountabilities, consulted parties, and informed parties (RACI), and the timeliness of security measures.

12 PCI (Payment Card Industry) DSS Quick Reference Guide, Data Security Standard version 3.2. 13 U.S. Department of Energy and U.S. Department of Homeland Security Cybersecurity Capability Maturity Model (C2m2). MIL3. 14 International Standards Organization ISO 27034, “Information Technology – Security Techniques – Application Security 15 U.S. Department of Energy and U.S. Department of Homeland Security Cybersecurity Capability Maturity Model (C2m2), p. 26. 16 TSP 100—2017 Trust Services Criteria. American Institute of CPAs System & Organizational Control. Pp. 47-50. 17 Center for Internet Security CIS Controls 18 The Software Supply Chain Integrity Framework: Defining Risks and Responsibilities for Securing Software in the Global Supply Chain. SafeCODE. 19 NIST SP 800-53r4. “Security and Privacy Controls for Federal Information Systems and Organizations System and Services Acquisition.” 20 https://nvd.nist.gov/vuln/search 21 https://www.us-cert.gov/related-resources 22 North American Transmission Forum CIP-013-1 Implementation Guidance

https://nvd.nist.gov/vuln/search

https://www.us-cert.gov/related-resources


Verify patch authenticity via cryptography, hashes, certificates, or 2-factor authentication Erect authentication barriers that ensure validity of patches and patch processes. EEI provides language for a contractor publishing a hash (see 2.1.5 (b) (i)) as a means to verify legitimacy and safety of a patch. NIST IR 7622 suggests to perform security assessments of configuration management processes and systems to detect ongoing attacks. (Section 4.3).

Security Guideline

Instructions

Review Period

Name of Individual

or Organization(s)


applicable)

Region (if applicable)Contact Telephone

Contact Email

Organization(s) Page # Line / Paragraph Comment Proposed Change NERC Response

guideline We suggest keeping page 1 – through that table. No response required

2 ‐ 3

Initial Best Practices in Supply Chain Provenance Management

We recommend removing “Initial Best Practices in Supply Chain Provenance Management.” These are not “initial.” Next, we agree with the principles, however implementation, is not practicable with 3,000 global suppliers of just computers. Having a total history of all those pieces, with all those vendors of vendors is too much paperwork and thereby guidance on CIP-013.

This comment was discussed during the August 19, 2019 SCWG meeting. The word "initial" was changed to "Considerations for". Also, a disclaimer will be added to the short paper to address this comment. SCWG will work with NERC staff on the best approach to add the disclaimer.

Supply Chain Security Guidelines on Provenance

212.840.1070

[email protected]

NPCC

Cogentrix; Con Ed; Eversource; ISO‐NE; NYSEG; NYISO; OPG; ORU; PSEG;

Please use this form to submit comments on the draft Security Guideline. Comments must be submitted within the review period below to Tom Hofstetter ([email protected]) with the

words “SCWG Security Guideline Comments” in the subject line. Only comments submitted in this Microsoft Excel format will be accepted. Both general and specific comments should be

provided within this form.



July 1 ‐ July 31, 2019


Critical Infrastructure Protection Task Force Scope Remote Access Guideline Task Force (RAGTF) September 17, 2019 Statement of Need The Critical Infrastructure Protection Committee (CIPC) has created working groups (WGs) and task forces (TFs) to manage the objectives and deliverables of the cyber and physical security challenges facing the North American Electric Reliability Corporation and the electricity sector. The management of these various WGs and TFs has been delegated to the members of the CIPC Executive Committee (EC), in their role as chairs of the Physical Security, Cyber Security, Operating Security, and Policy Subcommittees. Background Originally formed in 2005, the Control Systems Security Working Group (CSSWG) is charged with working as a cross‐functional team. The asset owners and vendors are tasked to develop economical procedures that apply security into existing systems, as well as, built‐in security into newly designed or delivered systems. In addition, the CSSWG looks at control systems specific issues, such as patch installation and management, which cannot be blindly adopted from the traditional IT methodologies. RAGTF Objectives/Duties

• Actively stay informed through participation in, or liaison with, NERC groups, other industry groups, government, and vendors to enhance their understanding of security issues within control systems;

Provide guidance and recommendations to asset owners to improve the security and protection of control systems used by the electricity sector by:

Creating and publishing electricity sector specific documents and guidelines for administration and maintenance of control systems in areas related to system security;

Assisting CIPC and the Standard Drafting Teams with guidance related to the protection of control systems;

Assist with the implementation of programs outlined in the CIPC Strategic Plan.

Research and recommend activities to EC that improve the security of Bulk Electric System facilities;

Volunteer control systems cybersecurity expertise to liaise and coordinate with the Events Analysis Working Group (EAWG) and Cyber Security Analysis Work Group (CSAWG) as required.

Critical Infrastructure Protection Committee | Remote Access Guideline Task Force Scope 2

Members and Structure The CSSWG will generally follow the organizational structure and voting rights of the Critical Infrastructure Protection Committee with the following additions:

• Leverage the available industry subject matter experts, for the work at hand.

• A NERC staff member will be assigned to the CSSWG.

• The RAGTF chair and vice‐chair will be appointed by the Cyber Security Subcommittee chair.

Reporting The RAGTF shall coordinate reports with, and administratively report to the chair of the Cyber Security Subcommittee. As requested, the CSSWG chair or designee shall issue progress reports for all:

• CIPC Executive Committee meetings

• CIPC meetings

RAGTF Deliverables and Work Schedule

• There will be four to six meetings per year. Emphasis will be given to conference calls and web‐based meetings.

• Research and recommend activities to the EC that improve the security of Bulk Electric System facilities.

• Provide guidance and recommendations to CIPC and asset owners that improve the security and protection of control systems used by the electricity sector by:

Developing and publishing, on an as needed basis, electricity sector specific documents and guidelines for administration and maintenance of control systems in areas related to system security;

Assisting NERC departments, CIPC, and Standard Drafting Teams with guidance related to the protection of control systems;

Assist CIPC and EC with the implementation of programs outlined in the CIPC Strategic Plan; and

Volunteering control systems cybersecurity expertise to liaise and coordinate with the Events Analysis Working Group (EAWG) and Cyber Security Analysis Work Group (CSAWG) as required.

Approved by the NERC Critical Infrastructure Protection Committee (CIPC): CIPC Chair

FOR QUESTIONS CONTACT: Workshop Chair – Steve Kunsman, [email protected]

#SmartGridCyberCon


https://attend.ieee.org/smartgridcybercon/village/

https://attend.ieee.org/smartgridcybercon/village/

Agenda Item 19 Critical Infrastructure Committee Meeting


CIPC Current Events Action Information Background Below is an informal summary of the upcoming meetings, workshops, conferences, and similar activities that may be of interest to members of the CIPForum mailing list. Most events that appear on this list are sponsored/led by NERC or a Regional Entity (the “ERO Enterprise”) or E-ISAC. However, a few events from external organizations are included merely as informational; there is no expressed or implied endorsement, sponsorship, or guarantee about the event’s schedule, content, etc. Summary

Date Organization Event Location Venue Remarks Aug. 21 MRO Security Advisory

Council: One Company’s Path to Establishing Threat Intelligence and Hunting

webinar N/A details

Sep. 9-12 ASIS Global Security Exchange (GSX)

Chicago

Sep. 17-18 NERC CIPC meeting Minneapolis Intercontinental, Minneapolis - St. Paul Airport

details

Sep. 17-18 SERC CIP Compliance Seminar Charlotte NC

SERC offices details

Sep. 24-25 NERC Monitoring and Situational Awareness Technical Conference

Little Rock AR

SPP offices details

Sep. 24-25 CEA Security and Infrastructure Protection Committee (SIPC)

Halifax NS

Sep. 25 MRO Security Conference: Beyond Theory-Lessons from the Field

St. Paul & webinar

MRO offices details

Sep. 26 MRO Security Advisory Council meeting

St. Paul & webinar

MRO offices details

Oct. 1 Texas RE CIP Low Impact Workshop

Houston 5 Greenway Plaza

details

Oct. 1-3 RF Reliability and CIP Workshop

Cleveland OH

Cleveland Marriott

details

Oct. 15-17 NAGF Annual Meeting & Compliance Conference

Atlanta NERC offices

Oct. 22-24 WECC Reliability & Security Workshop

Las Vegas Paris Hotel details

Oct. 22-25 E-ISAC Grid Security Conference (GridSecCon)

Atlanta Westin Peachtree Plaza

details

Formatted Table

https://www.eventbrite.com/e/threat-intelligence-and-hunting-webinar-registration-64255288297

https://cipc-september-2019.eventbrite.com/

https://www.serc1.org/outreach/events-calendar/event-details?id=0ff182e7-9a2e-4bb3-b4f5-55f0c7b742bc

https://www.eventbrite.com/e/monitoring-and-situational-awareness-technical-conference-september-2019-registration-64305986938

https://www.mro.net/_layouts/15/listform.aspx?PageType=4&ListId=%7B027D97C5%2D22C1%2D4A29%2DB82C%2D5AD494207013%7D&ID=342&ContentTypeID=0x0102009712D50809731449BEC5EBD460959B21

https://www.mro.net/Lists/Calendar/DispForm_New.aspx?ID=321&ContentTypeId=0x0102009712D50809731449BEC5EBD460959B21

https://www.texasre.org/Lists/Calendar/DispForm_New.aspx?ID=1122&Source=https%3A%2F%2FTXREWEBAPP01%2FPages%2FCalendar%2Easpx%3FCalendarDate%3D9%2F1%2F2019%26CalendarView%3DMonthView%26wpGuid%3Dg%5F66d8bf05%5F4747%5F4b51%5Fa855%5Fb977864de1c8&ContentTypeId

https://www.rfirst.org/eventdetail?EventId=92

https://www.wecc.org/_layouts/15/WopiFrame.aspx?sourcedoc=/Administrative/2019-10-22%20ReliabilityandSecurityWorkshopAnnouncement.pdf&action=default&DefaultItemOpen=1

https://cvent.me/q9Dyo

Nov. 6 MRO Security Advisory Council meeting

webinar N/A details

Nov. 13-14 E-ISAC GridEx N/A N/A details Nov. 20-21 NPCC Compliance and

Standards Workshop Newport RI Newport

Marriott details

Dec. 3-4 CEA Security and Infrastructure Protection Committee (SIPC)

Ottawa

Dec. 4 E-ISAC Unclassified Threat Workshop

Washington DC

E-ISAC/NERC offices

see E-ISAC website

Dec. 10-11 NERC CIPC meeting Atlanta Intercontinental Buckhead

https://www.mro.net/_layouts/15/listform.aspx?PageType=4&ListId=%7B027D97C5%2D22C1%2D4A29%2DB82C%2D5AD494207013%7D&ID=322&ContentTypeID=0x0102009712D50809731449BEC5EBD460959B21

https://www.nerc.com/pa/CI/CIPOutreach/Pages/GridEx.aspx

https://www.npcc.org/Compliance/CW/_layouts/listform.aspx?PageType=4&ListId=%7b81CAB9CC-8F47-4610-BBDA-8F7BF63D1EE7%7d&ID=87

https://www.eisac.com/portal-home/event-detail?id=119996

