RELIABILITY | RESILIENCE | SECURITY

Agenda Critical Infrastructure Protection Committee Meeting December 10, 2019 | 1:00-5:00 p.m. Eastern December 11, 2019 | 8:00 a.m.-12:00 p.m. Eastern

Intercontinental Buckhead Atlanta 3315 Peachtree Rd NE Atlanta, GA 30326

Call to Order

NERC Antitrust Compliance Guidelines, Public Announcement, and Participant Conduct Policy

Introduction and Chair’s Remarks

Agenda Items

1. Administrative Items – Secretary Tom Hofstetter, NERC

a. Safety Briefing and Emergency Precautions – Intercontinental Hotel Staff

b. Welcoming Remarks* – Mark Lauby, NERC

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. September 2019 Meeting Minutes

Regular Agenda

3. Remarks and Reports

a. Work Plan* – Approve – Chair Child

Agenda – Critical Infrastructure Protection Committee Meeting — December 10–11, 2019 2

b. RSTC* – David Zwergel, MISO, RSTC Vice-Chair

c. Nominating Committee – Larry Bugh, Reliability First

4. Agency Updates

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

b. Department of Energy – Nicholas Andersen, DAS, DOE

c. Department of Homeland Security – John Ransom, DHS

d. Public Safety Canada

5. NERC Updates

a. Compliance* – Lonnie Ratliff, NERC

b. Supply Chain* – Lonnie Ratliff, NERC

c. Standards Development

i. 2016–02 Modifications to CIP Standards – Jay Cribb, Southern Co.

ii. 2019–02 BCSI Access Management* – John Hansen, Exelon; Josh Powers, SPP

iii. 2019–03 Supply Chain Risks* – Tony Hall, LG

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

7. E–ISAC Updates

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

b. Cyber Security* – Lauren Cirillo, E–ISAC

c. Physical Security* – Jacinta Meredith, E–ISAC

d. E–ISAC Physical Security Advisory Group (PSAG)* – Michael Bowen, E–ISAC

8. National Laboratory Updates

a. Argonne National Laboratory – James Kavicky, ANL

b. Idaho National Laboratory* – Andrew Bochman, INL

c. Oak Ridge National Laboratory* – Thomas King, ORNL

d. Pacific Northwest National Laboratory – Scott Mix, PNNL

i. Overview of Universal Utility Data Exchange (UUDEX) Project*

9. Research and Development Updates

a. EPRI* – Tobias Whitney, EPRI; Alekhya Avadhanula, EPRI

10. Industry Group Updates

a. CEA: Canadian Legislative Highlights – Doug Currie, Hydro One Networks, Inc

Agenda – Critical Infrastructure Protection Committee Meeting — December 10–11, 2019 3

b. EEI: U.S. Legislative Highlights* – David Batz, EEI

c. North American Generator Forum (NAGF)* – Venona Greaff, Oxy

d. North American Transmission Forum (NATF)* – Ken Keels, NATF

e. EnergySec

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

a. 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

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

a. Grid Exercise (GridEx) Working Group (GEWG)* – Chair Jake Schmitter, E–ISAC

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

i. Security Guidelines – (Approve)*

(1) Security Guideline – Vendor Identified Incident Response Measures

(2) Security Guideline – Risks Related to Cloud Service Providers

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

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

14. Physical Security Working Group Updates

15. Roundtable (Open Discussion)

a. Technology support* – Stephanie Lawrence, NERC

16. Schedule of Important Dates:

CIPC 2020 Event Calendar Dates Time Event Location Venue Remarks

March 3, 2020 March 4, 2020

1:00 p.m. – 5:00 p.m. 8:00 a.m. – 12:00 p.m. CIPC meeting Atlanta, GA TBD TBD

June X, 2020 10:00 a.m. – 12:00 p.m. OC/PC/CIPC Meeting TBD TBD TBD June Y, 2020 June Z, 2020

1:00 p.m. – 5:00 p.m. 8:00 a.m. – 12:00 p.m. RSTC Meeting TBD TBD TBD

17. Closing Remarks and Action Items

18. Adjournment

Agenda – Critical Infrastructure Protection Committee Meeting — December 10–11, 2019 4

*Background materials included. Attendees TBD

RELIABILITY | RESILIENCE | SECURITY

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.

RELIABILITY | RESILIENCE | SECURITY

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 

RELIABILITY | RESILIENCE | SECURITY

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

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

a. The standard NERC announcements with NERC’s anti-trust policies and notice of public meeting were presented. Hotel staff briefed the attendees about safety policies and procedures.

b. Welcoming Remarks – Steve Brown, Vice President, Enterprise Security Services and Chief Security Officer of Xcel EnergyMr. Brown’s remarks highlighted priorities and challenges in Xcel Energy’s eight state service territory. He also described attractions and highlights in the state and local areas.

c. Declaration of CIPC QuorumQuorum was confirmed with 100% of CIPC members attending or represented, to include four designated proxies:

RELIABILITY | RESILIENCE | SECURITY

MinutesCritical 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 Chair Marc Child called the meeting to order at 1:00 p.m., welcoming members and guests to the Minneapolis-St. Paul metropolitan area.

NERC Antitrust Compliance Guidelines, Public Announcement, and Participant Conduct Policy

Introduction and Chair’s Remarks

Member Proxy Representing

Damon Ounsworth Paul Crist MRO

John Breckenridge Tony Eddleman MRO

Charles Abell John Howard SERC

Bob Richhart Richard Field NRECA

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

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

Total attendance was 130

g. CIPC Roster

Consent Agenda – Chair Marc Child, Great River Energy Chair Child reviewed the agenda; no changes were noted.

2. Minutes*

a. June, 2019 Meeting Minutes – (Approve)

There were no additions or corrections to the minutes of the CIPC meeting of June 4-5, 2019;they were approved unanimously by a voice vote.

Regular Agenda

3. Remarks and Reports – Chair Child

a. Pre-meeting activities included an OATI hosted tour for approximately ten CIPC meetingattendees at its nearby Microgrid Technology Center. The technologies that OATIdemonstrated included Combined Cooling, Heat, and Power (CCHP), Solar Photovoltaic (PV)and wind generation, energy storage, and sophisticated microgrid control and optimizationsoftware.

b. Work Plan*

Chair Child discussed the CIPC Executive Committee’s upcoming strategic planning meeting,and stressed the need for the CIPC work plan to clearly link to concerns that are described inthe Reliability Issues Steering Committee (RISC) 2019 risk priorities report.

He also emphasized that planning for security issues remains critical, regardless of how “CIPC”as an organizational element is configured in the future.

c. Board of Trustees meeting summary

Chair Child’s highlights from the most recent meeting of NERC’s Board of Trustees (Board)included the approval of the CIPC charter update that reflects the dissolution of FRCC. TheBoard also approved the issuance of a Section 1600 Data Request that CIPC’s Supply ChainWorking Group (SCWG) helped develop.

Discussion at the Board meeting included the proposed realignment of NERC’s technicalcommittees, a topic that was also mentioned several times during the CIPC meeting. Besidessummarizing the proposal and reviewing the expected timeline, Chair Child also encouraged

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

CIPC members and guests to be patient during the transition because CIPC’s efforts remain relevant and important to industry.

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

Operating Committee Chair Lloyd Linke spoke on behalf of the Stakeholder Engagement Team withdetails of the proposed realignment of NERC’s technical committees, stressing the goal ofcoordinating efforts among committees to increase effectiveness and efficiency while avoidingoverlap.

While the technical committees themselves will be replaced by a centralized oversight committee,it is expected that approximately 25 of the existing working groups and other subordinateorganizations will remain intact and focused on their assigned tasks

Mr. Linke also talked about desires expressed by members of existing committees to preserve aconvening venue for groups of professionals to come together and share information on a regularbasis.

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

Nominating subcommittee Chair Bugh recommended that the current CIPC chair and two vice-chairs be retained in those positions for the upcoming term. Their tenure in those roles is likely tobe brief since the proposed restructuring of the technical committees is expected to occur in early2020. The motion to accept the nominations was seconded and there were no additionalnominations from the floor; the motion was approved by voice vote with no objections orabstentions.

6. Agency Updates

a. Federal Energy Regulatory Commission – Justin Kelly, FERC; Simon Slobodnik, FERC; JimMcGlone, FERC

b. Mr. McGlone, Office of Energy Infrastructure Security, summarized the security assessmentsthat his office conducts for asset owners. There will be a more in-depth discussion about thoseengagements at the December CIPC meeting.

Mr. Okoniewski, Office of Electric Reliability, discussed FERC’s recently published "White Paperon Notices of Penalty Pertaining to Violations of Critical Infrastructure Protection ReliabilityStandards". FERC is seeking public comment regarding the submission and processing ofNotices of Penalty (NOPs) for violations of Critical Infrastructure Protection (CIP) ReliabilityStandards.

c. Department of Energy – no report

d. Department of Homeland Security – no report

e. Public Safety Canada – no report

7. NERC Update

a. Compliance

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

With no representative from NERC Compliance in attendance, Secretary Hofstetter relayed an update from Lonnie Ratliff of NERC staff. Besides project status reports, there were also reminders about available compliance resources and details about upcoming events.

b. Supply Chain – no report

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

Mr. Cribb reviewed recent activities of the Project 2016-02 CIP Standards Drafting Team, oneof three teams working on the CIP Reliability Standards.

The team’s focus on virtual computer systems has made it necessary to consider modifying oradding terms to NERC’s glossary of terms, one of many issues that the team has evaluated withindustry input. Mr. Cribb also stated that the 2016-02 team is coordinating with otherstandards drafting teams to minimize the risk of unintended consequences of changes to onestandard that impact others.

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

Speaking on Mr. Abell’s behalf, Mr. Chanoski’s RISC update focused on the draft “ERO EnterpriseLong-Term Strategy” (available here) that was posted for industry comment. The report addressesrisk in the context of four profiles that describe to common themes and emerging trends. Nosecurity priorities listed in the report were specifically designated for technical committees, but itcontains four recommendations that are relevant to security and eight others pertaining toresilience.

9. E-ISAC Updates

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

Mr. Chanoski discussed the E-ISAC Strategic Plan, emphasizing activities such as the hiring ofadditional staff, improvements to analysis capabilities, and opportunities for providing supportto industry. He also highlighted recent activity and resources from the Electricity SubsectorCoordinating Council (ESCC) and the growing concerns about issues pertaining to supply chainsecurity.

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

Mr. Castañeda addressed recent cybersecurity trends, specifically mentioning vulnerabilitiesthat could permit remote code execution. He also reminded the audience that vulnerabilityinformation that is shared with industry is largely dependent on input that the E-ISAC receives,so the analysis of threat actor activity can be better quality as more input is submitted byindustry.

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

Mr. Gibson reviewed recent physical security incidents and trends, also emphasizing the valueand need of voluntarily sharing information with E-ISAC. Other items of interest he sharedpertained to evolving current events and resources that are available to members.

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

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

Mr Johnson summarized discussions at its last meeting which included a Department ofHomeland Security report about risks to critical infrastructure from Unmanned Aerial Systems(UAS), the ongoing development of the physical security maturity model, and the need forentity physical and cyber security personnel to collaborate in efforts to mitigate risks.

10. National Laboratory Updates

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

Mr. Folga described a questionnaire based physical security assessment tool that ArgonneNational Laboratory developed to help organizations assess different scenarios before makingsecurity investments. Besides supporting grid modernization efforts to maintain & improvereliability, resiliency, flexibility, sustainability, affordability & security; spur electric industryadaptation of DHS Protective Measures Indices (PMI) for physical security metrics

b. Idaho National Laboratory – no report

c. Oak Ridge National Laboratory – Thomas King, ORNL

With this as the first CIPC meeting at which Oak Ridge National Lab was represented, Mr. Kingprovided a brief overview of the organization.

d. Pacific Northwest National Laboratory – no report

11. Research and Development Updates

a. EPRI* – Tobias Whitney, EPRI

Mr. Whitney gave an overview of EPRI activities that support supply chain security. Besideswork products that will be offered at no charge to support industry, EPRI is also working on acomplementary process for vendors who support industry.

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

Dr. Li and Mr. Huff described research into machine learning that will improve patchmanagement and decision making strategies. They described the effort as a way to optimizeand automate much of the patch assessment process as possible, so industry volunteers areinvited to participate and provide feedback to improve the tool.

12. Industry Group Updates*

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

Mr. Johnson briefly summarized current activities and upcoming events.

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

Ms. Koch’s written update was included with the agenda package; she also spoke about otherproposed legislation pertaining to energy infrastructure.

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

c. North American Generator Forum – no report

d. North American Transmission Forum* – Tony Eddleman, NPPD

Mr. Eddleman provided an overview of NATF’s recent activities. He emphasized the supplychain cyber security initiative, which is intended to provide guidance that supports industry’sefforts to be secure, efficient, effective, and compliant. Work products from the NATF effortare publicly available here.

e. EnergySec* – Steve Parker, EnergySec

Mr. Parker gave an overview of EnergySec’s focus on cyber workforce development, describingtheir approach to building and maintaining a pipeline of available cybersecurity talentspecifically for the electric industry. Besides formal apprenticeship-type programs, there arevarious training and work experiences available.

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

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

The SMWG chair, Larry Bugh, gave the group’s final report; subsequently, CIPC membersapproved a motion to disband the group. E-ISAC and NERC are now fulfilling responsibilitiesand expectations that were previously supported by the SMWG. The group’s final report isavailable in the September 2019 Agenda Package

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

Mr. Crist’s reviewed the CIWG’s efforts to develop implementation guidance that addressescertain aspects of cloud based computing. The CIWG is working with ERO staff as well asgovernment and industry representatives to identify and describe the security controls thatwould be appropriate for protecting sensitive industry data when it is supported by a cloudbased solution.

c. DEIRTF – Benny Naas, Vectren

Mr. Naas reported that the implementation guidance which CIPC members helped to develophas been approved by the Operating Committee (OC) and will be sent the ERO for review andprocessing.

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

a. Grid Exercise Working Group (GEWG) Update – Chair Jake Schmitter, E-ISAC Staff

Mr. Schmitter reported that planning is complete for GridEx V, stating that the next step is theexecution of the November event. Nearly 400 entities are expected to participate, includingthe gas and oil industry as well as others.

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

Mr. Eddleman presented five “Supply Chain Security Guidelines” (listed below) that weredeveloped by the SCWG and were ready for posting. The guidelines were approvedunanimously by CIPC and subsequently posted for industry reference.

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

Each guideline is posted with a presentation that provides an overview of the topic.

(1) Secure Equipment Delivery

(2) Supply Chain and Risk Considerations for Open Source Software

(3) Supply Chain Cyber Security Risk Management Lifecycle

(4) Supply Chain and Risk Considerations for Open Source Software

(5) Supply Chain Security Guidelines on Provenance

Mr. Eddleman added that the Supply Chain Working Group is continuing to develop guidelines; two more are nearly ready for review and subsequent vote.

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

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

Ms. Davis reported that approximately 60 attendees participated in security training that wasoffered prior to the CIPC meeting. The session focused on firewall configuration as well ashands-on application of machine learning models for making risk-aware decisions invulnerability and patch management.

b. Remote Access Guideline Task Force (RAGTF) – no report

16. Physical Security Working Groups’ Updates – Chair Ross Johnson, Bridgehead SecurityConsulting, Inc.

a. Physical Security Working Group (PSWG)

Information pertinent to the PSWG was included with the PSAG summary (above).

b. Physical Security Guidelines Task Force (PSGTF)

The CIPC Executive Committee voted to disband the Physical Security Guideline Task Force,instead deciding to appoint individual task forces as issues to address are identified.

c. Other – Chair Johnson

i. Alberta Provincial Physical Security Projects: Mr. Johnson briefly summarized recent eventsand threats.

17. Roundtable

a. Smart Grid Cybersecurity Workshop* –

No report was presented; meeting attendees were provided relevant information about theevent from the IEEE Workshop Flyer

b. Classified Briefing December – Process and Deadlines

Secretary Hofstetter gave an overview of the process for those who wish to attend theclassified threat briefing immediately prior to the December CIPC meeting; more informationwould be forthcoming via email.

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

c. Unmanned Aerial Vehicles (UAVs)/Drones

Chair Child mentioned the growing security concerns for entities use of unmanned aerialvehicles (UAVs), commonly known as drones. He suggested that it may be an appropriate topicfor CIPC-developed guidance, especially since there are supply chain issues as well as concernsabout software that automatically transfers pictures to another country.

d. Update CIP requirements to NIST Cybersecurity Framework

CIPC worked with NIST several years ago to develop a document that maps the CIP ReliabilityStandards to NIST standards. While updates to the standards have made that mappingdocument outdated, it seems likely that further updates are better suited to be driven byothers, such as vendors, rather than using CIPC resources to prepare it.

18. Technology support – no report

19. Schedule of Important Dates*:

2019 Meeting Dates Date Organization Event Location Venue Remarks

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/NERCoffices

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

Agenda Item 3a CIPC Meeting

December 10-11, 2019

Critical Infrastructure Protection Committee Work Plan Update

Action Discussion

Background Chair report on development of the CIPC 2020-2021 work plan

Summary Chair Child will welcome committee members and proxies, and review the proposed 2020-2021 work plan, focusing on the process used to gather input and initial expectations on how the plan will be addressed under the Reliability and Security Technical Committee (RSTC).

Priority (H, M, L)

Group Subgroup Task Name Task Description / Notes RISC report ERO LTS

H Executive Committee New WGCharter a "CIP forum" working/outreach group (under RSTC or E-ISAC)

Maintain and expand relationships established by CIPC with federal partners, labs, trade groups, research groups, cross-sector entities, international entities, including Canadian center for cybersecurity

Value #3Focus #2Focus #4

H Operating Security Supply Chain Working Group (SCWG) Considerations for GMD EMP purchasing 2.3

H Operating Security Supply Chain Working Group (SCWG)Additional short-papers based on feedback from existing work products.

CIP-013 implementation date is July 1, and SCWG should stand ready (before/after) to address asset owner concerns or gaps

Focus #1Focus #2

M Operating Security Compliance Input Working Group (CIWG)Protection considerations for information traditionally shared between entities (modeling, load-flow, one-lines)

Perhaps a joint effort with OC? 1.1

MCyber SecurityPhysical Security

New TF Utility Essential Security Practices Whitepaper

Guidance for cyber/physical security protections for non-CIP utility technologies such as inverters, synchro-phasers, natural gas SCADA, etc.(Resources aligned with Electric-Gas Working Group (EGWG) )

4.4

M Physical Security New TFAttack scenarios on midstream or interstate natural gas pipelines

Joint effort with OC/PC 3.1

M Operating Security New TFDevelopment of planning approaches, models and simulation approaches that reduce the number of critical facilities

Joint effort with PC/OC 3.6

MCyber SecurityPhysical Security

New TF Response to GridEx V lessons learnedPlaceholder for anticipated work items stemming from the bi-annual GridEx lessons learned

4.3

M Executive Committee

Security Training Working Group (STWG) or Reliability Issues Steering Committee (RISC) orReliability and Security Technical Committee (RSTC)

Hold periodic emerging technologies security workshops RSTC action item

L Operating Security Compliance Input Working Group (CIWG)Security or implementation guidance for cloud-based EAMS and PAMS

In support of CIP development efforts pertaining to virtualization issues

Focus #2

L Operating Security Compliance Input Working Group (CIWG)Examine high risk violations for implementation guidance opportunities

CIWG can identify opportunities but may leverage Cyber or Physical workgroups to assist development

Focus #1

LCyber SecurityPhysical Security

New TF Cyber-Physical Resiliency Task ForceAddress resiliency issues identified through the RISC report and ERO LTS

Focus #2

L Operating Security New TFSupport ERO internal controls initiatives (whitepapers, compliance guidance)

L Cyber Security Remote Access Guideline Task Force (RAGTF) Update CIPC remote access guidelineUpdate remote access guideline taking (as input) the NERC remote access study, filed with FERC in 201x

Focus #2

Document TitleApproved

Version Number

Approval Date Due Date

Physical Security Guideline for the Electricity Sector: Assessments and Resiliency Measures for Extreme Events

1.0 Jun-19 Jun-22

Physical Security Guideline Security Considerations High Impact Control Centers

1.0 Mar-19 Mar-22

Security Guideline for the ElectricitySub-sector: Physical Security Response

4.0 Oct-13 Oct-16

Security Guideline for the Electricity Sector: Supply Chain Risk Considerations for Open Source Software

1.0 Sep-19 Sep-22

Security Guideline for the Electricity Sector - Supply Chain Provenance

1.0 Sep-19 Sep-22

Security Guideline for the Electricity Sector - Supply Chain Cyber Security Risk Management Lifecycle

1.0 Sep-19 Sep-22

Security Guideline for the Electricity Sector - Supply Chain Secure Equipment Delivery

1.0 Sep-19 Sep-22

Security Guideline for the Electricity Sector - Supply Chain Vendor Risk Management Lifecycle

1.0 Sep-19 Sep-22

Letter to Electric Industry Vendor Community:Supply Chain Cyber Security Practices

1.0 Mar-19 Mar-22

*Originating Subcommittee or Task ForcePSWG: Physical Security Working Group

CIWG: Compliance Input Working GroupSCWG: Supply Chain Working GroupCSSWG: Control System Security Working Group

Start DateOriginating

Subcommittee or Task Force*

Link

Jan-22 PSWG

https://www.nerc.com/comm/CIPC_Security_Guidelines_DL/Physical_Security_Guideline_%20Assessments_and_Resiliency_Measures_for_Extreme_Events_June_2019.pdf

Jan-22 CSSWG

https://www.nerc.com/comm/CIPC_Security_Guidelines_DL/Physical%20Security%20Guideline%20Security%20Considerations%20High%20Impact%20Control%20Centers.pdf

Jan-20 PSWGhttps://www.nerc.com/comm/CIPC_Security_Guidelines_DL/Electricity_Sector_Physical_Security_Guideline.pdf

Jan-22 SCWGhttps://www.nerc.com/comm/CIPC_Security_Guidelines_DL/Security_Guideline-Open_Source_Software.pdf

Jan-22 SCWGhttps://www.nerc.com/comm/CIPC_Security_Guidelines_DL/Security_Guideline-Provenance.pdf

Jan-22 SCWGhttps://www.nerc.com/comm/CIPC_Security_Guidelines_DL/Security_Guideline-Risk_Management_Lifecycle.pdf

Jan-22 SCWGhttps://www.nerc.com/comm/CIPC_Security_Guidelines_DL/Security_Guideline-Secure_Equipment_Delivery.pdf

Jan-22 SCWG

https://www.nerc.com/comm/CIPC_Security_Guidelines_DL/Security_Guideline-Vendor_Risk_Management_Lifecycle.pdf

Jan-22 SCWGhttps://www.nerc.com/comm/CIPC/Related%20Files%20DL/SupplyChainCyberSecurityPracticesLetter2019.pdf

Link to Associated Training Presentation (if any)

N/A

N/A

N/A

https://www.nerc.com/comm/CIPC_Security_Guidelines_DL/Security_Guideline-

Open_Source_Software_Presentation.pdfhttps://www.nerc.com/comm/CIPC_Security_G

uidelines_DL/Security_Guideline-Provenance_Presentation.pdf

https://www.nerc.com/comm/CIPC_Security_Guidelines_DL/Security_Guideline-

Risk_Management_Lifecycle_Presentation.pdfhttps://www.nerc.com/comm/CIPC_Security_G

uidelines_DL/Security_Guideline-Secure_Equipment_Delivery_Presentation.pdf

https://www.nerc.com/comm/CIPC_Security_Guidelines_DL/Security_Guideline-

Vendor_Risk_Management_Lifecycle_Presentation.pdf

N/A

Agenda Item 8d.i CIPC Meeting

December 10-11, 2019

Overview of Universal Utility Data Exchange (UUDEX) Project Action Information Background Utilities have been exchanging information with each other using standards-based protocols for more than 20 years. These tools have been extended and augmented for security while retaining the initial underlying architecture and protocol base. This has resulted in an inflexible, difficult to configure toolset that includes security as an optional add-on that is not used extensively in the United States. Pacific Northwest National Laboratory (PNNL) is developing a specification for a new protocol called the Universal Utility Data Exchange (UUDEX). UUDEX proposes to replace the existing control center data exchange protocol with a modern (2017–2019) architecture. The architecture will take advantage of current methods of data transport and configuration and result in a flexible, dynamic, and scalable platform. The platform will replace not only existing data exchanges, but could also be a replacement for the Reliability Coordinator Communications Information System (RCIS), incident reporting (DOE OE-417), threat and response data (including firewall rule updates and vulnerability and patch notifications), DER data, power system model exchanges, and market data. It will be a flexible and dynamic information exchange platform, designed with information security as a core component, that can rapidly respond to changing data exchange needs, allows for the addition of new data exchange partners on a permanent or temporary basis, and can be easily extended to other energy subsectors. Summary This presentation will provide an overview of the UUDEX project, including completed and planned work for the project, and actions to be performed after the existing project is complete.

Agenda Item 10b CIPC Meeting

December 10-11, 2019

Legislative Update Action Update Background Federal Legislative Update – December Summary • Senate Energy and Natural Resources Committee (SENR) continues to hold hearings and

mark up bills in the event floor time becomes available to move an energy package.

• This week, SENR marked up S. 2556 – The PROTECT Act. The bill will amend the Federal Power Act to provide energy cybersecurity investment incentives and to establish a grant and technical assistance program for cybersecurity investments. Also, SENR voted out of the committee the Brouillette (DOE), Danly (FERC), and MacGregor’s (DOI) nominations.

• Earlier this month, SENR – in partnership with APPA, EEI, and NRECA – held a grid briefing for Senate energy and homeland security staff. Topics discussed by government and industry alike will include the "all-hazards" approach to grid security, the role of public private partnerships, cross-sector coordination, tools and resources along with roles and responsibilities in protecting the electric sector.

• In September, the Senate passed H.R. 1158 – DHS Cyber Incident Response Teams Act of

2019 by voice vote with a minor amendment from Senator Hassan (D-NH). If the two chambers reconcile some relatively minor differences, the legislation will proceed to the President for his signature. The bill would codify DHS cyber hunt and incident response teams into law. Senator Hassan and others have presented the legislation as a partial remedy to the rise of ransomware attacks across the nation.

• After Thanksgiving, we expect Congress to come back to finish the National Defense

Authorization Act (NDAA). NDAA negotiations are ongoing at the leadership level in both chambers. We won’t know until the final bill text is released if S. 174 / H.R. 680, Securing Energy Infrastructure Act (SEIA) will remain in the final bill or not.

Grid Security: Liability Protections The industry continues to engage the Hill (Senate & House energy, homeland, judiciary and armed services committees) on 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. 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. Recent developments include:

• Multi-sector coalition letter • 12 U.S. Senators letter • NARUC resolution • Stakeholder meetings, including the wireless carries, the large technology companies,

and the FCC Unmanned Aircraft Systems (UAS)

• Politico reported last week that the FAA will finally propose a rule on remote identification of drones in December, which will help clear a bottleneck of other drone rules the private sector desperately wants.

Agenda Item 11a CIPC Meeting

December 10-11, 2019

Compliance Input Working Group Update Action The Compliance Input Working Group (CIWG) continues to work on the implementation guidance for placing Bulk Electric System Cyber System Information (BCSI) in the cloud. No approvals by CIPC are expected at this time. 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 An update will be provided on the work being done for the NERC/CIWG Cloud Implementation Guidance project.

RELIABILITY | RESILIENCE | SECURITY

DRAFT Security Guideline for the Electricity Sector - Supply Chain Vendor Identified Incident Response Measures 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, among others, risks that originate with vendors. The procurement process should include agreement on a risk management plan, inclusive of cyber-incident response elements such as identification, notification, mitigation, remediation, and recovery. Defining a Vendor-Identified Incident The definition of a vendor-identified incident and criteria of what poses a risk to the Bulk Electric System (BES) could differ from vendor to vendor and entity to entity. Discuss this definition with the vendor during procurement evaluation, to ensure there is a common, documented understanding of what both parties define as a vendor-identified incident. Potential Incidents Supply chain security measures protect a NERC entity’s Bulk Electric System (BES) components from incidents that originate within the entity’s supply chain. These incidents could occur outside the control or visibility of an entity’s security program, but could still pose a risk to the products or services that support the BES. This in turn could compromise a vendor’s development process, ongoing support of delivered systems, trusted connections between vendor and entity network(s), trusted communications channels, or vendor employees. Incidents could be attempts to gain access to or adversely affect an entity’s BES systems, including, but not limited to: System integrity compromises:

• Of the vendor code for patches, updates, software, installation or configuration files, used on a BES Cyber System at any point in the software development lifecycle

• Of vendor hardware such as malicious chip or board level implants or modifications, or malicious factory configuration

• Of manufacturing specifications or proprietary information that could be used by a malicious actor to exploit physical or cyber vulnerabilities

Security Guideline for the Electricity Sector - Supply Chain | Vendor Identified Incident Response Measures 2 Approved by the Critical Infrastructure Protection Committee on XX XX, XXXX

• Discovery of a back door or other potential for unauthorized electronic access to a BES Cyber System

• Vendor software (known or active exploitation of a software vulnerability by a malicious actor) Vendor network compromises:

• To a vendor’s computer network used for access to an entity’s BES Cyber System(s)

• Of a vendor’s trusted communication channels that may have been used to transmit malicious messages to an entity, such as postal shipped items, compromised file transfer systems or social engineering methods e.g. (phishing or vishing)

• Of a vendor’s authorized remote access to an entity’s network by a malicious actor Vendor employee compromises:

• Vendor employee or anyone acting on behalf of vendor perpetrating a cybercrime or physical crime that indicate an increased risk to their customers, such as a violation of the Computer Fraud and Abuse Act1, computer espionage, theft, trespassing, or acts of violence

• Vendor employee linked to terrorist organization, or organizations that promote attacks against the electric power industry

Coordination of Responses to Vendor-Identified Incidents When a vendor becomes aware of an actual or potential incident (e.g., notification by a third party, public disclosure), the vendor should implement its notification process in a mutually agreed upon time and method. Notifications should include circumstantial and technical details, remedial steps being undertaken, recommended mitigations, and the method and timing for sharing updated information. Based on the size and scope of the incident, direct communication with the entity might not be viable as the initial means of notification. Vendors may disclose incidents publicly or through an advisory organization such as the Electricity Information Sharing Analysis Center (E-ISAC), Department of Homeland Security, or Federal Bureau of Investigation. If disclosures occur in this manner, the vendor should notify entities with updated information throughout the incident investigation through established communications channels. Establish mutual points of contact (or roles) with the vendor, in order to assure there are no single points of failure in the incident response process. Both parties should ensure that the established notification method(s) remain viable by testing the established process at an agreed-upon frequency. Incident Response Lifecycle Considerations

1 https://www.nacdl.org/Landing/ComputerFraudandAbuseAct

Security Guideline for the Electricity Sector - Supply Chain | Vendor Identified Incident Response Measures 3 Approved by the Critical Infrastructure Protection Committee on XX XX, XXXX

Be prepared to activate an established incident response plan upon notification from a vendor of a cybersecurity incident. If an incident is discovered internally, determine the size and scope of the incident and respond accordingly, as defined by the entity’s plan. Establish ongoing communication methods between the vendor and the entity. This may take the form of public notices published by the vendor. However communicated, vendor notifications about the incident should establish the method and frequency for additional information regarding the incident. During the procurement process, establish a mutually agreed upon approach to submitting and receiving responses to specific questions from the vendor about incidents . Design incident action plans in accordance with the type of incident, impact, and stage of detection to support the response plan. Incident action plans establish standard response measures based on the stage and potential impact of the affected system or service. Be specific in reports and notifications to E-ISAC as to observations of the incident and attach information that the vendor has already released. Reporting specific observations and technical details supports the collecting analyst’s ability to determine the full size and scope of all the reporting parties, allowing them to assess and share actionable intelligence. After the incident, conduct a post mortem review with the vendor, focusing on the interaction, coordination, and communication that took place throughout the detection, notification, and response process. Identify security control improvements and establish target dates for implementation of the improvements. Update the Incident Response Plan as needed. Security Control Improvement After completing the vendor-identified incident investigation and determining its root cause, evaluate the associated security controls and improvements that were identified during the post mortem to help prevent future incidents. The vendor should provide documented evidence of the implemented changes. Unfortunately, there is always the possibility that the vendor will fail to perform some or all of what was expected. In that case, possible actions include:

• Apply internal mitigating security controls to reduce the risk

• Document and communicate issues which were not addressed

Engage management and/or senior leadership of the vendor as needed, emphasizing the importance of the control(s) or mitigation(s) and the need to implement appropriate measures

Communicate to the vendor that unresolved issues may impact future scoring or evaluation of new purchases of products or services or renewal of existing product and service contracts

• Evaluate terminating the relationship with the vendor

• If appropriate, take legal action

Security Guideline for the Electricity Sector - Supply Chain | Vendor Identified Incident Response Measures 4 Approved by the Critical Infrastructure Protection Committee on XX XX, XXXX

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

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

RELIABILITY | RESILIENCE | SECURITY

Vendor-Identified IncidentSupply Chain Working Group Guideline

Steven Briggs, TVACritical Infrastructure Protection CommitteeDecember 10-11, 2019 | Atlanta, GA

RELIABILITY | RESILIENCE | SECURITY2

• Vendor-Identified Incident Definition: Based on the Supply Chain Cybersecurity Risk Management Plan

(“Risk Management Plan”)o Established during the procurement processo Inclusive of cyber-incident response elements

– Identification– Notification– Mitigation– Remediation– Recovery

Introduction

RELIABILITY | RESILIENCE | SECURITY3

• Of the vendor code for patches, updates, software, installation or configuration files, used on a BES Cyber System at any point in the software development lifecycle

• Of vendor hardware such as malicious chip or board level implants or modifications, or malicious factory configuration

• Of manufacturing specifications or proprietary information that could be used by a malicious actor to exploit physical or cyber vulnerabilities

• Discovery of a back door or other potential for unauthorized electronic access to a BES Cyber System

• Vendor software (known or active exploitation of a software vulnerability by a malicious actor)

System Integrity Compromises

Potential Incidents

Vendor Network Compromises• To a vendor’s computer network used for access to

an entity’s BES Cyber System(s)• Of a vendor’s trusted communication channels that

may have been used to transmit malicious messages to an entity, such as:

• postal shipped items• compromised file transfer systems or• social engineering methods e.g. (phishing or vishing)

• Of a vendor’s authorized remote access to an entity’s network by a malicious actor

Vendor Employee Compromises• Vendor employee or anyone acting on behalf of vendor• Vendor employee or anyone acting on behalf of vendor

perpetuating a cybercrime or physical crime that indicate an increased risk to their customers, such as

• Computer Fraud and Abuse Act

• Computer espionage• Theft• Trespassing• Acts of violence

• Linked to terrorist organization, or organizations that promote attacks against the electric power industry

RELIABILITY | RESILIENCE | SECURITY4

• Actual or potential• Notified by a third party (could be the affected utility)

• Publicly Disclosed• The Vendor should implement its notification process

in a mutually agreed upon time and method

Vendor Identification

Coordination of Responses to Vendor-Identified Incidents

Incident Information Needed• Circumstantial and technical details• Remedial steps being undertaken• Recommended mitigations• Method and timing for sharing updated information

Disclosure Options• Direct Individual Entity notification based on methods

established during procurementBased on the size and scope of the incident, direct communications with the entity might not be a viable first means of notification.• Disclose Publically• Disclose through an advisory organization• Follow up with entities through established

communication channels.

RELIABILITY | RESILIENCE | SECURITY5

• Be prepared to activate your established incident response plan.• If an incident is discovered internally, determine the size and

scope of the incident and report accordingly, as defined by the entity’s plan.

• Establish ongoing communication methods between the vendor and the entity.

• Specific questions requiring vendor response should follow the methods for conveying these questions that were established and agreed upon during the procurement process.

Incident Response Lifecycle Considerations

RELIABILITY | RESILIENCE | SECURITY6

• Incident action plans designed in accordance with the type of incident, impact, and stage of detection can support the response plan. Incident action plans establish standard response measures based on the stage and potential impact of the affected system or service.

• Be specific in reporting and notifications to E-ISAC as to your observations of the incident, and attach information that the vendor has already released.

• After the incident, conduct a post mortem review with the vendor, focusing on the interaction, coordination, and communication that took place throughout the response time.

Incident Response Lifecycle Considerations

RELIABILITY | RESILIENCE | SECURITY7

• After completion of the vendor-identified incident investigation and determination of its root cause, evaluate the associated security controls and improvements identified during the post mortem, to help prevent future incidents. The vendor should provide documented evidence of the implemented changes. Apply internal mitigating security controls to reduce the risk Document and communicate any issues which were not addressed Engage management and/or senior leadership of the vendor as needed, to

impress on them the importance of the control(s) or mitigation(s) and the need to implement appropriate measures

Communicate to the vendor that unresolved issues may impact future scoring or evaluation of new purchases of products or services or renewal of existing product and service contracts

Evaluate terminating the relationship with the vendor If appropriate, take legal action

Security Control Improvements

RELIABILITY | RESILIENCE | SECURITY8

• Additional topics and guidance for Supply Chain Security can be found at https://www.nerc.com/pa/comp/Pages/Supply-Chain-Risk-Mitigation-Program.aspx

Security Control Improvements

RELIABILITY | RESILIENCE | SECURITY9

RELIABILITY | RESILIENCE | SECURITY

DRAFT Security Guideline for the Electricity Sector - Supply Chain Risks Related to Cloud Service Providers 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 Cloud computing offerings, defined as those which enable “ubiquitous, convenient, and on-demand network access to a shared pool of configurable computing resources”1, have been introduced to the market over the past decade. In some cases, this new model has resulted in the potential to reduce costs and increase efficiency, but as with any major technological change, it also brought a range of risks and security factors to be considered. Recognizing that the electricity subsector is among the potential customer base for many of these new technologies, engagement and partnerships between the vendor community and the electricity subsector are highly important – particularly given the rate at which these technologies and offerings evolve. Vigilance and oversight from all parties are essential to both identify and address risks associated with the paradigm shift.

This guideline presents some supply chain risk considerations associated with cloud computing. It is not intended to endorse hosting Bulk Electric System (BES), BES Cyber Systems (BCS) or BCS Information (BCSI) in the cloud. Rather, this guideline is provided to support entities in their evaluation of the supply chain risks associated with vendors providing or utilizing cloud services. Cloud Services Supply Chain Risk Considerations Shared Services - One of the starting points when considering a move into the cloud is to understand the implications of shared services, which share resources such as the computing platform or storage with multiple clients. Understanding the responsibilities of security for the solution being provided is important in assessing risk. Shared services, by their nature, present security challenges not encountered when an organization owns and operates “end-to-end” solutions. For instance, cloud risks exemplified by the Spectre and Meltdown2 vulnerabilities demonstrated how an adversary could obtain confidential information by manipulating shared features of cloud resources, such as storage devices. When considering the deployment of cloud-based services, the entity is responsible for ensuring that capabilities are maintained for security, change management, and other considerations of the cloud

1 National Institute of Standards and Technology (NIST) Special Publication (SP) 800-145 NIST Definition of Cloud Computing 2 https://www.us-cert.gov/ncas/alerts/TA18-004A

Security Guideline for the Electricity Sector - Supply Chain | Risks Related to Cloud Service Providers 2 Approved by the Critical Infrastructure Protection Committee on XX XX, XXXX

solution. Risks associated with each cloud implementation will depend on the service model chosen as well as the business requirements for confidentiality, integrity, and availability for the application. Many third-party security service providers and software security brokers offer security oversight and monitoring for cloud services; however, this ultimately adds another layer of supply chain risk in procuring and managing third party services. Service Level - Cloud service solutions are available in various configurations and may involve multiple tiers of vendors. The service model chosen should be considered and proper service level agreements established commensurate with the value or sensitivity of data being stored. Organizations should clearly understand their tolerance to interruptions in service. The National Institute of Standards and Technology (NIST) provides a number of resources for helping an entity categorize the importance of information being stored in the cloud. For example, NIST publication FIPS 1993 uses the security objectives of confidentiality, integrity, and availability to assess risk and categorize information. Among the practices and controls a vendor and entity should implement are:

• Mitigate the effects of denial of service attacks and unauthorized access to information.

• Ensure individuals who have access protect the information entrusted to them.

• Ensure data is not modified by accidental or unauthorized means. This would include ensuring each client’s data is segregated from other clients’ data.

Security Controls - The entity should determine the demarcation point of security controls between the vendor and the entity to determine the scope of cloud service provider (CSP) security controls and the entity’s security controls for the cloud services. A security controls gap analysis will assist the entity in determining incident response and recovery strategies. Refer to the security frameworks addressed below under “Verifications/Certifications.” Service Model – CSPs’ service offerings include Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). Organizations can select the service model that best satisfies its needs, but it is important to perform due diligence/analysis for services to be provided. Each layer of cloud services (IaaS, PaaS, and SaaS) may encompass shared responsibility, meaning each layer of the cloud stack may be provided by different vendors. Therefore, a vendor providing cloud services may also be relying on other CSPs to support different service models. For example, an entity could choose a SaaS vendor that is using another vendor for IaaS. Thus, while an entity may think its attack surface includes only the SaaS vendor, there may actually be three vendors providing SaaS, PaaS and IaaS. An entity should always seek to understand what aspects of the cloud service are being provided by the vendor or CSP and whether third parties are critical to that service delivery. Instituting clauses in contracts

3 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.199.pdf

Security Guideline for the Electricity Sector - Supply Chain | Risks Related to Cloud Service Providers 3 Approved by the Critical Infrastructure Protection Committee on XX XX, XXXX

or supplements, as well as asking questions in a risk assessment as to the number and types of vendors the service provider uses to provide cloud services, is vital to understanding and addressing the actual risk in the relationship. Data Sovereignty - Data may be restricted legally from being stored in or routed through foreign jurisdictions depending on data classification, sensitivity, ownership, and other factors. Such restricted data may reside on servers that are accessible to and monitored by government entities. As a result, organizations should ensure that agreements with CSPs include a high level of transparency. See “Regulatory Limitations” below for additional information. Regulatory Limitations – While the goal is always to reduce risk, there may be legal constraints that limit the extent to which mitigations can be applied to cloud-based services. Regulations that prohibit the vendor from customizing certain aspects of its service offerings may present inherent limitations to mitigations that could otherwise be applied. One notable example is “eTag” – a specification required by the North American Energy Standards Board.4 Consider issues like these when assessing risks. Verification/ Certifications - How a vendor demonstrates and communicates its security is an important consideration when considering a CSP. Some vendors describe their security programs with references to standards or frameworks such as ISO 270015, NIST SP800-536, NIST Cybersecurity Framework7, or Cloud Security Alliance (CSA) Security Trust Assurance and Risk (STAR) Program8. Vendors adhering to security standards or frameworks should provide an attestation report from a certified and independent third-party auditor on controls relevant to security, availability, processing integrity, and confidentiality. It is a best practice to ensure the evaluation was conducted according to the rules published by the standard’s governing authority. It is also imperative to understand the scope of the products and services that are covered under the certification. FedRAMP9 (Federal Risk Authorization Management Program) is an example of a certification that an organization could use to demonstrate that it has met the requirements of an independent standard. Additionally, FedRAMP and CSA are developing a joint certification system called FedSTAR 10. Alternatives to the above mentioned certifications or third party attestations include the vendor’s assessment of controls in response to an Entity questionnaire or onsite inquiry. A greater level of scrutiny should be applied with the security questionnaire method since it lacks independent verification of the information being provided by the vendor.

4 https://www.naesb.org/ 5 https://www.iso.org/isoiec-27001-information-security.html 6 https://csrc.nist.gov/publications/detail/sp/800-53/rev-4/final 7 https://www.nist.gov/cyberframework 8 https://cloudsecurityalliance.org/star/ 9 https://www.fedramp.gov/ 10 https://cloudsecurityalliance.org/articles/cloud-security-alliance-announces-fedstar-a-new-joint-certification-system-with-

fedramp/

Security Guideline for the Electricity Sector - Supply Chain | Risks Related to Cloud Service Providers 4 Approved by the Critical Infrastructure Protection Committee on XX XX, XXXX

It is important to note the direct relationship between the burden of proving security that is placed on vendors and the cost of services. This is an important consideration when choosing the proper verification/certification method. A program like FedRAMP imposes the greatest burden on the vendor, which is attractive from a security standpoint, but could be very costly too. At the other extreme, a security questionnaire can be very cost-effective, but lacks the impartiality of an independent third-party review. In other words, there is a tradeoff between risk and cost associated with all of the verification methods discussed above. Response and Recovery - Incident response and recovery plans should identify responsibilities and points of contact for both organizations to act appropriately to security incidents and interruptions of service. The service level agreement should clearly define security incidents and expectations of all parties involved. For further information and references, visit the NERC Supply Chain Risk Mitigation Program site.11 References, Acronyms and Definitions

• Cloud Service Provider12

CSPs offer network and telecommunication services, infrastructure, or business applications hosted in a data center that can be accessed by companies or individuals using network connectivity.

• Cloud Computing13

Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model is composed of five essential characteristics, three service models, and four deployment models.

• SaaS (Software as a Service)

SaaS allows users to connect to and use various types of cloud-based applications over the Internet.14 The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based email), or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings..15

• PaaS (Platform as a Service)13

11 https://www.nerc.com/pa/comp/Pages/Supply-Chain-Risk-Mitigation-Program.aspx 12 https://www.sdxcentral.com/cloud/definitions/what-are-cloud-service-providers/ 13 https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf 14 https://www.us-cert.gov/ncas/alerts/TA18-004A 15 https://azure.microsoft.com/en-us/overview/what-is-saas/

Security Guideline for the Electricity Sector - Supply Chain | Risks Related to Cloud Service Providers 5 Approved by the Critical Infrastructure Protection Committee on XX XX, XXXX

The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider.16 The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.

• IaaS (Infrastructure as a Service)13

The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications; and possibly limited control of select networking components (e.g., host firewalls).

16 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.199.pdf

Risks Related to Cloud Service Providers Supply Chain Working Group Guideline

Brenda Davis, CPS EnergyCritical Infrastructure Protection CommitteeDecember 10-11, 2019 | Atlanta, GA

RELIABILITY | ACCOUNTABILITY2

Introduction• NIST describes cloud computing1 as ubiquitous, convenient, on-

demand network access to a shared pool of configurable resources.

• As with any new technology, a range of risks and security factors are introduced.

• This guideline is intended to support entities in evaluating supply chain risks associated with vendors providing or utilizing cloud services, however, does not provide compliance guidance.

Supply Chain Risks related to Cloud Service Providers

1 NIST SP800-145 NIST Definition of Cloud Computing

RELIABILITY | ACCOUNTABILITY3

Cloud Services Supply Chain Risk Considerations

• Shared Services - Cloud services that share resources such as the computing platform or storage with multiple clients.

• Service Level – Establish proper service level agreements commensurate with the value or sensitivity of the data.

• Security Controls – Determine the demarcation point of security controls between the vendor and the entity.

• Service Model – Related to the concept of shared services, the service model chosen (SaaS, IaaS, PaaS) may include risks of layered services with multiple vendors.

Supply Chain Risks related to Cloud Service Providers

RELIABILITY | ACCOUNTABILITY4

Cloud Services Supply Chain Risk Considerations• Data Sovereignty – Data may be restricted legally from being stored

in or routed through foreign jurisdictions depending on data classification, sensitivity, ownership and other factors.

• Regulatory Limitations – There may be inherent limitations to mitigations that could be applied that must be considered when assessing risks.

• Verification/ Certifications – How a vendor may demonstrate and communicate security. For example: ISO/IEC 27001 – Information Security Management Standard NIST SP 800-53 – Security and Privacy Controls for Federal Information Systems and

Organizations CSA STAR – Cloud Security Alliance Security Trust Assurance and Risk Program FedRAMP – Federal Risk and Authorization Management Program 3rd Party Attestation - (Example: SOC2, Type 2 attestation)

Supply Chain Risks related to Cloud Service Providers

.

RELIABILITY | ACCOUNTABILITY5

Cloud Services Supply Chain Risk Considerations• Response and Recovery– Incident response and recovery plans should identify responsibilities and

points of contact for both organizations to respond appropriately to security incidents and interruptions of service.

The service level agreement should clearly define security incidents and expectations of all parties involved.

Supply Chain Risks related to Cloud Service Providers

RELIABILITY | ACCOUNTABILITY6

APPENDIX A - References, Acronyms and Definitions

Supply Chain Risks related to Cloud Service Providers

Cloud Service Provider2

Cloud service providers (CSP) offer network and telecommunication services, infrastructure, or business applications hosted in a data center that can be accessed by companies or individuals using network connectivity.

Cloud Computing3

Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model is composed of five essential characteristics, three service models, and four deployment models.

SaaS

(Software as a Service)3

The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure. The applications are accessible from various client devices through either a thin client interface, such as a web browser (e.g., web-based email), or a program interface. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

2 https://www.sdxcentral.com/cloud/definitions/what-are-cloud-service-providers/3 https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf)

RELIABILITY | ACCOUNTABILITY7

Supply Chain Risks related to Cloud Service Providers

APPENDIX A - References, Acronyms and Definitions

PaaS

(Platform as a Service)3

The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, or storage, but has control over the deployed applications and possibly configuration settings for the application-hosting environment.

IaaS

(Infrastructure as a Service)3

The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, and deployed applications; and possibly limited control of select networking components (e.g., host firewalls).

3 https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf)

RELIABILITY | ACCOUNTABILITY8

References https://www.us-cert.gov/ncas/alerts/TA18-004A (Meltdown and Spectre)https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.199.pdfhttps://www.naesb.org/https://www.iso.org/isoiec-27001-information-security.htmlhttps://csrc.nist.gov/publications/detail/sp/800-53/rev-4/finalhttps://www.nist.gov/cyberframeworkhttps://cloudsecurityalliance.org/star/https://www.fedramp.gov/https://cloudsecurityalliance.org/articles/cloud-security-alliance-announces-fedstar-a-new-joint- certification-system-with-fedramp/

Example of cloud services infrastructure:https://azure.microsoft.com/en-us/overview/what-is-saas/

Additional topics and guidance for Supply Chain Security can be found at https://www.nerc.com/pa/comp/Pages/Supply-Chain-Risk-Mitigation-Program.aspx.

Supply Chain Risks related to Cloud Service Providers

RELIABILITY | ACCOUNTABILITY9

Supply Chain Risks related to Cloud Service Providers