This comment form is no longer interactive because the comment period is closed.

2016-02 Modifications to CIP Standards | Virtualization - Draft 2

Description:

Start Date: 06/30/2021
End Date: 09/01/2021

Associated Ballots:

Ballot Name Project Standard Pool Open Pool Close Voting Start Voting End
2016-02 Modifications to CIP Standards | Virtualization CIP-002-7 AB 2 ST 2016-02 Modifications to CIP Standards | Virtualization CIP-002-7 01/22/2021 02/19/2021 08/23/2021 09/01/2021
2016-02 Modifications to CIP Standards | Virtualization CIP-003-9 AB 2 ST 2016-02 Modifications to CIP Standards | Virtualization CIP-003-9 01/22/2021 02/19/2021 08/23/2021 09/01/2021
2016-02 Modifications to CIP Standards | Virtualization CIP-004-7 AB 2 ST 2016-02 Modifications to CIP Standards | Virtualization CIP-004-7 01/22/2021 02/19/2021 08/23/2021 09/01/2021
2016-02 Modifications to CIP Standards | Virtualization CIP-005-8 AB 2 ST 2016-02 Modifications to CIP Standards | Virtualization CIP-005-8 01/22/2021 02/19/2021 08/23/2021 09/01/2021
2016-02 Modifications to CIP Standards | Virtualization CIP-006-7 AB 2 ST 2016-02 Modifications to CIP Standards | Virtualization CIP-006-7 01/22/2021 02/19/2021 08/23/2021 09/01/2021
2016-02 Modifications to CIP Standards | Virtualization CIP-007-7 AB 2 ST 2016-02 Modifications to CIP Standards | Virtualization CIP-007-7 01/22/2021 02/19/2021 08/23/2021 09/01/2021
2016-02 Modifications to CIP Standards | Virtualization CIP-008-7 AB 2 ST 2016-02 Modifications to CIP Standards | Virtualization CIP-008-7 01/22/2021 02/19/2021 08/23/2021 09/01/2021
2016-02 Modifications to CIP Standards | Virtualization CIP-009-7 AB 2 ST 2016-02 Modifications to CIP Standards | Virtualization CIP-009-7 01/22/2021 02/19/2021 08/23/2021 09/01/2021
2016-02 Modifications to CIP Standards | Virtualization CIP-010-5 AB 2 ST 2016-02 Modifications to CIP Standards | Virtualization CIP-010-5 01/22/2021 02/19/2021 08/23/2021 09/01/2021
2016-02 Modifications to CIP Standards | Virtualization CIP-011-3 AB 2 ST 2016-02 Modifications to CIP Standards | Virtualization CIP-011-3 01/22/2021 02/19/2021 08/23/2021 09/01/2021
2016-02 Modifications to CIP Standards | Virtualization CIP-013-3 AB 2 ST 2016-02 Modifications to CIP Standards | Virtualization CIP-013-3 01/22/2021 02/19/2021 08/23/2021 09/01/2021

Filter:

Hot Answers

Dan Zollner, Portland General Electric Co., 3, 9/1/2021

- 0 - 0

PGE FCD, Segment(s) 5, 1, 3, 6, 9/11/2018

- 0 - 0

Other Answers

Richard Jackson, U.S. Bureau of Reclamation, 1, 8/19/2021

- 0 - 0

The proposed definition of CIP System is confusing.  Dominion Energy recommends removing CIP System from the proposed defined terms and all references to the CIP System defined term throughout the definitions.  Dominion Energy recommends addressing the issues of applicability it appears the CIP System definition was intending to do at the Standard level.  

Dominion, Segment(s) 3, 5, 1, 9/19/2019

- 0 - 0

Jeanne Kurzynowski, On Behalf of: CMS Energy - Consumers Energy Company - RF - Segments 3, 4, 5

- 0 - 0

Chelan approves of this language.

CHPD, Segment(s) 3, 1, 6, 5, 8/24/2021

- 0 - 0

Glen Farmer, Avista - Avista Corporation, 5, 8/24/2021

- 0 - 0

It is understood that when SCI is included in the CIP Systems it is to be treated like the CIP System.  However, the other option for identification of SCI is not clear, as discussed in greater detail in the response to question 2.

Martin Sidor, NRG - NRG Energy, Inc., 6, 8/24/2021

- 0 - 0

It is understood that when SCI is included in the CIP Systems it is to be treated like the CIP System.  However, the other option for identification of SCI is not clear, as discussed in greater detail in the response to question 2.

Patricia Lynch, NRG - NRG Energy, Inc., 5, 8/24/2021

- 0 - 0

Consider modification of SCI to be based on the Cyber Asset definition. SCI’s basis on the “programmable electronic devices” terminology makes it unclear as to what type of devices are the intended target of the standard.

CIP-002 provides guidance for identification and classification of BCS (grouping of BCAs).  Other associated cyber assets are classified based on their connectivity, protection and relationship to the BCAs.  Suggest remove SCI identification from CIP-002.

Tennessee Valley Authority, Segment(s) 1, 3, 5, 6, 10/18/2018

- 0 - 0

Xcel Energy supports the comments of EEI.

Amy Casuscelli, On Behalf of: Xcel Energy, Inc. - MRO, WECC - Segments 1, 3, 5, 6

- 0 - 0

Andrea Jessup, On Behalf of: Bonneville Power Administration, WECC, Segments 1, 3, 5, 6

- 0 - 0

Mike Magruder, Avista - Avista Corporation, 1, 8/26/2021

- 0 - 0

The current definitions and requirement language place BCS, which are groups of Cyber Assets, at the same level as SCI.  SCI is likely to be handled as individual devices.  This adds complexity both to the CIP-002 R1 compliance process as well as creates complexity for CIP-002 R2.2 approval processes. 

Duke Energy requests that the SDT add a definition and update requirements to leverage the concept of an SCI Group (SCIG).  This would establish parity between the BCA -> BCS relationship with SCI -> SCIG. 

This also further simplifies applicability in the downstream standards from the current “High Impact BES Cyber Systems (BCS) and their associated: EACMS; PACS; and PCA” with a separate line for “SCI identified independently supporting an Applicable System above” to “High Impact BES Cyber Systems (BCS) and their associated: EACMS; PACS; PCA; and SCIG”. 

Further, the CIP-002 language can now be simplified to the following, which retains closer parity with current language while still addressing the SDT’s intentions:  “Identify each of the high impact BES Cyber Systems, if any, and associated Shared Cyber Infrastructure Groups, if any, according to Attachment 1, Section 1 at each asset”.

Katie Connor, On Behalf of: Duke Energy - SERC, RF - Segments 1, 3, 5, 6

- 0 - 0

The shared SCI and TCA definitions are clear and are understood by technical staff; however, the scope included in these definitions may be dfficult to communicate to management staff as written.   

AECI, Segment(s) 1, 3, 6, 5, 3/4/2021

- 1 - 0

See MRO-NSRF and EEI Comments

Clarice Zellmer, WEC Energy Group, Inc., 5, 8/26/2021

- 0 - 0

We believe the options are mostly clear and acceptable with the exception of the phrase “independent SCI supporting” either high or medium impact. It is unclear and confusing how an SCI can be both independent and supporting simultaneously. The proposed revised definition of BES Cyber System already would make it clear that SCI is to be included in CIP scope if applicable. We recommend removing the second bullet point entirely from both R1.1 and R1.2. 

Ronald Bender, Nebraska Public Power District, 5, 8/27/2021

- 0 - 0

Josh Johnson, Lincoln Electric System, 1, 8/27/2021

- 0 - 0

The identification of SCI is not clear within CIP-002, nor is it understood that SCI should be high-water marked to the highest impact applicable system that is sharing its infrastructure. The only thing that makes this clear is the definition of CIP System, which term is not used within CIP-002. 

WECC CIP, Segment(s) 10, 2/17/2021

- 0 - 0

The identification of SCI included in a CIP System is clear but the identification of Management Systems included in SCI is unclear. For the all-in scenario, with Provider1 as an example, the Provider management Cyber Asset would typically be outside the ESP currently.  With the new all-in, that CA would be a Management Interface, and would then be included as part of the SCI per the SCI 'including Management Interfaces' definition, which would then pull the CA into the BCS, making it a BCA, so it can no longer be outside of the ESP.

William Steiner, Midwest Reliability Organization, 10, 8/30/2021

- 0 - 0

AZPS agrees that the two options for identification of SCI within CIP-002 are clear.

Marcus Bortman, APS - Arizona Public Service Co., 6, 8/30/2021

- 0 - 0

It is confusing to understand the definition of Shared Cyber Infrastrure (SCI) and therefore the overall requirement is unclear. While significant education to industry would improve this, it is extremely dependent on interpretation by stakeholders and auditors.

Susan Sosbe, On Behalf of: Wabash Valley Power Association, , Segments 1, 3

- 0 - 0

The CIP-002 should maintain a section on BROS that establish the relationship with the BCS

Carl Pineault, Hydro-Qu?bec Production, 5, 8/30/2021

- 0 - 0

ACES agrees when SCI is included in the CIP Systems it falls into scope of CIP requirements where SCI is an Applicable System.  The issue is not with CIP-002’s usage of SCI or its definition, but the definition of CIP System as it lacks the inclusion of VCAs which could lead to confusion. 

 

AEPC has signed on to ACES comments.

Jennifer Bray, Arizona Electric Power Cooperative, Inc., 1, 8/30/2021

- 0 - 0

We believe the options are mostly clear and acceptable with the exception of the phrase “independent SCI supporting” either high or medium impact. It is unclear and confusing how an SCI can be both independent and supporting simultaneously. The proposed revised definition of BES Cyber System already would make it clear that SCI is to be included in CIP scope if applicable. We recommend removing the second bullet point entirely from both R1.1 and R1.2.

On a related note, we are concerned about revising the existing CIP standards to address virtual technologies and believe a better approach may be to address the majority of impacts and new requirements in a new standard. Please see our comment on this in response to question #14.

Justin MacDonald, On Behalf of: Midwest Energy, Inc., , Segments 1

- 0 - 0

The term 'SCI' is still unclear and ambiguous.The term 'SCI' is still unclear and ambiguous.

Steve Toosevich, NiSource - Northern Indiana Public Service Co., 1, 8/31/2021

- 0 - 0

CenterPoint Energy Houston Electric, LLC (CEHE) agrees that the two options in CIP-002 R1 are clear, due to the explanation in the Technical Rationale, and understands that SCI is an applicable system when it supports an applicable system either as part of the system or as independent SCI.  

Eli Rivera, On Behalf of: CenterPoint Energy Houston Electric, LLC, Texas RE, Segments NA - Not Applicable

- 0 - 0

Southwest Power Pool Standards Review Group (SSRG), Segment(s) 2, 9/4/2019

- 0 - 0

NCPA supports the “All-In” option which identifies the SCI is to receive the impact rating based on the BCS that it hosts.  It is not clear how the identified independently option is to be evaluated. 

Chris Carnesi, On Behalf of: Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6

- 0 - 0

Southern Indiana Gas and Electric Company (SIGE) agrees that the two options in CIP-002 R1 are clear, due to the explanation in the Technical Rationale, and understands that SCI is an applicable system when it supports an applicable system either as part of the system or as independent SCI. 

Brian Tooley, On Behalf of: Southern Indiana Gas and Electric Co., RF, Segments 3, 5, 6

- 0 - 0

It is not clear what is meant by independent SCI supporting any part of the high impact BCS.

Joe Tarantino, On Behalf of: Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6

- 0 - 0

Texas RE does not agree that the two options for identification of SCI are clear.  The distinction between SCI included in a BES Cyber System (BCS) and SCI operating independently adds an unnecessary level of complexity to the standards.  Texas RE recommends there be only one option, which is to categorize SCI as meeting the definitions of the VCAs they are hosting and subsequently include the SCI within BCS, Electronic Access Control or Monitoring Systems (EACMS), Physical Access Control Systems (PACS) and Protected Cyber Assets (PCAs), as applicable.

 

Additionally, Texas RE recommends that registered entities be required to identify all BCS, as well as their associated EACMS, PACS, and PCAs, as applicable.  System (PM5) and system component (CM-8) inventory are both controls from NIST 800-53 Rev. 5. Texas RE is concerned CIP-002-7 would be less effective if registered entities are not required to implement the full suite of the system and component inventory protections in a manner consistent with these requirements. 

 

Rachel Coyne, Texas Reliability Entity, Inc., 10, 8/31/2021

- 0 - 0

BC Hydro, Segment(s) 3, 5, 1, 12/18/2018

- 0 - 0

SDG&E supports EEI Comments 

Bridget Silvia, Sempra - San Diego Gas and Electric, 3, 8/31/2021

- 0 - 0

MEAG Power, Segment(s) 3, 1, 5, 6/15/2017

- 0 - 0

We support NPCC TFIST's comments as found below:

Request clarification when a SCI supports both high impact BES and medium impact BES. Is that SCI high watermarked to the high impact?

Request clarification of “it is a part of for CIP Requirement Applicability?” Is there a missing word? Should the language be “it is a part of it for CIP Requirement Applicability?”

Request clarification of the or in 1.3. Is the entity identifying low impact BCS or supporting SCI or both?

Request clarification of the 1.3 parenthetical. Is the entity required to provide an asset list for either low impact BCS or supporting SCI?

Gerry Adamski, Cogentrix Energy Power Management, LLC, 5, 8/31/2021

- 0 - 0

FE Voter, Segment(s) 1, 3, 5, 6, 4, 2/23/2021

- 0 - 0

OKGE supports EEI's comments. 

OKGE, Segment(s) 6, 1, 3, 5, 3/22/2021

- 0 - 0

The standard is clear about the two options. However, the Technical Rationale it is not clearly understood how the Standards Drafting Team anticipates treatment of systems.

Anthony Jablonski, ReliabilityFirst , 10, 8/31/2021

- 0 - 0

Darnez Gresham, Berkshire Hathaway Energy - MidAmerican Energy Co., 3, 8/31/2021

- 0 - 0

See MidAmerican Energy Company comments from Darnez Gresham.

Terry Harbour, Berkshire Hathaway Energy - MidAmerican Energy Co., 1, 8/31/2021

- 0 - 0

Cleco supports comments submitted by EEI.

Clay Walker, On Behalf of: Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6

- 0 - 0

In support of NPCC RSC comments.

Request clarification when a SCI supports both high impact BES and medium impact BES. Is that SCI high watermarked to the high impact?

Request clarification of “it is a part of for CIP Requirement Applicability?” Is there a missing word? Should the language be “it is a part of it for CIP Requirement Applicability?”

Request clarification of the or in 1.3. Is the entity identifying low impact BCS or supporting SCI or both?

Request clarification of the 1.3 parenthetical. Is the entity required to provide an asset list for either low impact BCS or supporting SCI?

 

We don’t understand how to categorize a Shared Cyber Infrastructure. The SDT seems to make a distinction between two types of SCI, one type is supporting, and the other type is independent supporting. Our hypothesis is that a “supporting SCI” is for BCS (BCA/PCA) and that an “independent supporting SCI” is for associated Electronic Access Control or Monitoring Systems (EACMS), Physical Access Control Systems (PACS)).

In both cases, the SCI is the categorization labels, like BCA, PCA, EACMS, PACS, TCA.

Yet in the Applicable Systems column in the other CIPs, the SDT seem to make a distinction between the SCI, for example

CIP-005 R1.5 1.5 … PACS hosted on SCI … SCI identified independently…

CIP-007 R1.1 SCI identified independently supporting.

Clarification is needed.

Are the two options for identification SCI required? Is there a difference in the controls that we want to apply?

We suggest simplifying the language or add more precision. Example:

Per Attachment 1, Section 1, identify each high impact BES Cyber System as either of the following, if any, at each asset; High Impact BCS and their associated Electronic Access Control or Monitoring Systems (EACMS), Physical Access Control Systems (PACS), Protected Cyber Assets (PCAs) or SCI.

Furthermore, in the definition of SCI the PCA is not listed. Is this intentional? Wouldn’t be possible to have a PCA supported by an SCI? We suggest that the SDT review the SCI / VCA/ PCA definitions, adjust the applicability and the requirements.

Reference SCI: One or more programmable electronic devices, including the software and Management Interfaces, that share:  • CPU and memory resources with one or more Virtual Cyber Assets identified as a BCA, EACMS, or PACS; or 

Nicolas Turcotte, Hydro-Qu?bec TransEnergie, 1, 9/1/2021

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Daniel Gacek, Exelon, 1, 9/1/2021

- 0 - 0

While AEP agrees with the inclusion of this CIP-002 mechanism (the term CIP Systems) for including the associated applicable systems (EACMS, PACS, and PCAs) as a means to have a singular requirement for the identification of EACMS, PACS and PCAs, the current language appears to limit the identification of only those virtual systems (and underlying infrastructure) related to EACMS, PACS and PCAs. We believe this leaves a gap for the identification of those physical systems performing the same function(s). We recommend SDT to add clarifying language to allow for the identification of both physical and virtual systems as EACMS, PACS and PCAs under CIP-002.

JT Kuehne, AEP, 6, 9/1/2021

- 0 - 0

Jamie Monette, On Behalf of: Allete - Minnesota Power, Inc., , Segments 1

- 0 - 0

IESO supports the comments submitted to all the questions by both NPCC and ISO/RTO Council

 

Request clarification when a SCI supports both high impact BES and medium impact BES. Is that SCI high watermarked to the high impact?

Request clarification of “it is a part of for CIP Requirement Applicability?” Is there a missing word? Should the language be “it is a part of it for CIP Requirement Applicability?”

Request clarification of the or in 1.3. Is the entity identifying low impact BCS or supporting SCI or both?

Request clarification of the 1.3 parenthetical. Is the entity required to provide an asset list for either low impact BCS or supporting SCI?

 

We don’t understand how to categorize a Shared Cyber Infrastructure. The SDT seems to make a distinction between two types of SCI, one type is supporting, and the other type is independent supporting. Our hypothesis is that a “supporting SCI” is for BCS (BCA/PCA) and that an “independent supporting SCI” is for associated Electronic Access Control or Monitoring Systems (EACMS), Physical Access Control Systems (PACS)).

In both cases, the SCI is the categorization labels, like BCA, PCA, EACMS, PACS, TCA.

Yet in the Applicable Systems column in the other CIPs, the SDT seem to make a distinction between the SCI, for example

CIP-005 R1.5 1.5 … PACS hosted on SCI … SCI identified independently…

CIP-007 R1.1 SCI identified independently supporting.

Clarification is needed.

Are the two options for identification SCI required? Is there a difference in the controls that we want to apply?

We suggest simplifying the language or add more precision. Example:

Per Attachment 1, Section 1, identify each high impact BES Cyber System as either of the following, if any, at each asset; High Impact BCS and their associated Electronic Access Control or Monitoring Systems (EACMS), Physical Access Control Systems (PACS), Protected Cyber Assets (PCAs) or SCI.

Furthermore, in the definition of SCI the PCA is not listed. Is this intentional? Wouldn’t be possible to have a PCA supported by an SCI? We suggest that the SDT review the SCI / VCA/ PCA definitions, adjust the applicability and the requirements.

Leonard Kula, Independent Electricity System Operator, 2, 9/1/2021

- 0 - 0

The phrases “supporting SCI” and “independent SCI supporting” are not clear and should be removed from CIP-002.  Resulting from SCI definition, SCI should be either a CIP cyber asset or no-CIP cyber asset, therefore SCI shouldn’t appear in CIP-002 and Applicable Systems of CIP-003 to CIP-013. SCI should be used for identifying additional BCAs, EACMS, PACS or PCAs that could be missed in the virtualization environment.

For the proposed All-in-Scenario, SCI should be identified as a BCA, EACMS, PACS or PCA rather than a new classification of CIP cyber asset. For example, if a SCI can initialize, deploy and configure a BCA, it should be categorized as a BCA since it can remove a virtual BCA thus having an impact to the BES within 15 minutes. Similarly, if a SCI can initialize, deploy and configure an EACMS, it should be categorized as an EACMS since it can remove the virtual EACMS thus having electronic control function.

For independently Identified SCI as SDT proposed below, for the right side SCI, if the right SCI containing Management Interface can initialize, deploy and configure a CIP Cyber Asset, it should be categorized as a CIP cyber asset (See our comments above). If the right-side SCI hosts VCA that is a CIP cyber asset regardless of the impact rating, the right side SCI should be identified as the same impact CIP cyber asset it hosts. The right side SCI is out of CIP scope only: (1) if all VCAs it hosts are non-CIP cyber assets, this SCI would be out of CIP scope thus no need to be identified; (2) If it is used only to configure high impact network policy, it would be out of CIP scope since out of band management for CIP cyber assets is not required by the current CIP requirements scope and the SAR

Based on our comments above, the “SCI” and “independently Identified SCI” are not needed to be identified in CIP-002 since the SCI or independently Identified SCI either is a CIP cyber asset or out of CIP scope.   

SEE ATTACHED DOCUMENT FOR PHOTO.

Resulting from our comments above, we recommend revising definitions of BCA, EACMS, PACS and PCA to include SCI so SCI would not be identified as another independently applicable CIP cyber asset. Our proposed changes align with FERC and NERC’s security objectives and the SDT’s goal to address cyber security risks to the reliability of the BES from virtualization technologies, while having less impact on the entities existing CIP programs, processes and documentation. Entities can use their existing CIP cyber asset identification processes to identify BCAs, EACMS, PACS and PCAs based on SCI and Management Interface language to address virtualization. If the responsible entities don’t have virtualization, they wouldn’t need to identify any additional CIP cyber assets at all.

Recommendations:

1.      Restore the CIP-002 R1 and its Parts resulting from our proposed definitions changes below.

2.      We propose the following changes to the new or existing definitions:

SCI:

SDT Proposed SCI definition

One or more programmable electronic devices, including the software and Management Interfaces, that share:

·        CPU and memory resources with one or more Virtual Cyber Assets identified as a BCA, EACMS, or PACS; or

·        storage resources with any part of a BES Cyber System or their associated EACMS or PACS.

Each SCI is either:

·        included in one or more BES Cyber Systems, EACMS, or PACS; or

·        identified independently.

SCI does not include the supported VCA or CA with which it shares its resources.

 

NSRF Proposed Changes to the Definition

One or more programmable electronic devices, including the software and Management Interfaces in those devices, that share:

  • CPU and memory resources with one or more Virtual Cyber Assets identified as a BCA, EACMS, PACS or PCA; or
  • storage resources with any part of a BES Cyber System or their associated EACMS, PACS or PCA.

This includes devices that contain Management Interfaces for virtualization management.

SCI does not include the supported VCA or CA with which it shares its resources.

Rationale: In the SDT proposed SCI definition, the device containing Management Interface is left out and is not identified as a CIP cyber part of SCI even though the management interface is in scope. For example, vCenter containing Management Interface, but it is not identified as a CIP cyber asset and is not protected. Also, PCA is missing from the SCI definition. In our proposed changes, it is not necessary to identify SCI independently since SCI would be identified as one of CIP Cyber Assets.

 

Management Interface:

SDT Proposed SCI definition

A user interface, logical interface, or dedicated physical port that is used to:

·        Control the processes of initializing, deploying, and configuring Shared Cyber Infrastructure; or

·        Provide lights-out management capabilities; or

·        Configure an Electronic Security Perimeter;

excluding physical user interfaces (e.g., power switch, touch panel, etc.).

Our Proposed Changes to the Definition

A user interface, logical interface, or dedicated physical port that is used to:

·        Initialize, deploy, and configure BCA, EACMS, PACS, or PCA; or

·        Control the processes of initializing, deploying, and configuring Shared Cyber Infrastructure; or

·        Configure EAP of an Electronic Security Perimeter; or

·        Configure EACMS that controls all communications to and from the BCS unless ESP model is used.

excluding physical user interfaces (e.g., power switch, touch panel, etc.). (See our rationale in Q6).

Rationale: In our view, the definition should focus on “in scope” CIP management interfaces. The term “Provide lights-out management capabilities” is not clear and should be removed since this criterion itself cannot make a management interface fall within CIP scope.

Also, the Management Interface on the SCI is absent. We have added a bullet in our proposed definition to address it.

Furthermore, we suggest edits to include:

a) changing configure an ESP to configure an EAP

b) adding configure EACMS to address the zero-trust mode based on our comments in Q4.

BCA:

SDT Proposed SCI definition

A Cyber Asset or Virtual Cyber Asset, that if rendered unavailable, degraded, or misused would, within 15 minutes of its required operation, misoperation, or non‐operation, adversely impact one or more Facilities, systems, or equipment, which, if destroyed, degraded, or otherwise rendered unavailable when needed, would affect the reliable operation of the Bulk Electric System. Redundancy of affected Facilities, systems, and equipment shall not be considered when determining adverse impact. Each BES Cyber Asset is included in one or more BES Cyber Systems. 

Our Proposed Changes to the Definition

A Cyber Asset or Virtual Cyber Asset, that if rendered unavailable, degraded, or misused would, within 15 minutes of its required operation, misoperation, or non‐operation, adversely impact one or more Facilities, systems, or equipment, which, if destroyed, degraded, or otherwise rendered unavailable when needed, would affect the reliable operation of the Bulk Electric System. Redundancy of affected Facilities, systems, and equipment shall not be considered when determining adverse impact. Each BES Cyber Asset is included in one or more BES Cyber Systems. This includes SCI that is used for initializing, deploying and configuring BCAs or storing information for the real-time operation of BCAs.

Rationale: In our view, if a SCI meets BCA criteria, it must be identified as a BCA.

EACMS:

SDT Proposed SCI definition

Cyber Assets, Virtual Cyber Assets, or Shared Cyber Infrastructure (SCI) that perform electronic access control or electronic access monitoring of the Electronic Security Perimeter(s) or BES Cyber Systems or SCI. This includes Intermediate Systems and SCI grouped, by the Responsible Entity, in the EACMS it supports.

 

Our Proposed Changes to the Definition

Cyber Assets or Virtual Cyber Assets that perform electronic access control or electronic access monitoring of the Electronic Security Perimeter(s) or BES Cyber Systems. This includes Intermediate Systems and SCI that is used for initializing, deploying and configuring EACMS or storing information for the real-time operation of EACMS.

Rationale: A SCI supporting EACMS doesn’t make it to be part of EACMS. For instance, if a SCI only stores historical information for EACMS, it could be a BCSI repository rather than part of EACMS. In our view, only a SCI that can initialize, deploy and configure EACMS should be identified as EACMS. 

PACS:

SDT Proposed SCI definition

Cyber Assets, Virtual Cyber Assets, or Shared Cyber Infrastructure (SCI) (including SCI grouped, by the Responsible Entity, in the Physical Access Control Systems it supports) that control, alert, or log access to the Physical Security Perimeter(s), exclusive of locally mounted hardware or devices at the Physical Security Perimeter such as motion sensors, electronic lock control mechanisms, and badge readers.

Our Proposed Changes to the Definition

Cyber Assets or Virtual Cyber Assets that control, alert, or log access to the Physical Security Perimeter(s), exclusive of locally mounted hardware or devices at the Physical Security Perimeter such as motion sensors, electronic lock control mechanisms, and badge readers. This includes SCI that is used for initializing, deploying and configuring PACS or storing information for the real-time operation of PACS.

Rationale: A SCI supporting PACS doesn’t make it to be part of PACS. For instance, if a SCI only stores historical information for PACS, it could be a BCSI repository rather than part of PACS. In our view, only a SCI that can initialize, deploy and configure PACS should be identified as PACS. 

PCA:

SDT Proposed SCI definition

One or more Cyber Assets or Virtual Cyber Assets that:

  • Are within an Electronic Security Perimeter but are not part of the highest impact BES Cyber System within the same Electronic Security Perimeter; or
  • Share CPU or memory with any part of a BES Cyber System, excluding Virtual Cyber Assets that are being actively remediated prior to introduction to the Electronic Security Perimeter.

 

Our Proposed Changes to the Definition

One or more Cyber Assets or Virtual Cyber Assets that:

  • Are within an Electronic Security Perimeter but are not part of the highest impact BES Cyber System within the same Electronic Security Perimeter; or
  •  Share CPU or memory with any part of a BES Cyber System, EACMS, PACS or PCA; or

This includes SCI that is used for initializing, deploying and configuring PCA or storing information for the real-time operation of PCA.

Rationale: In the SDT proposed PCA definition, if the bullet 2 is for identifying PCA that shares resources with BCS, the ESP should be irrelevant.  Also, it is not clear what the remediation actions are and why the one-time remediation makes it out of scope, noting that the compliance is an ongoing basis and the remediation shouldn’t exclude a VCA from CIP scope. Furthermore, if SDT intends to protect non-CIP cyber assets that share the CPU or memory with CIP cyber assets, EACMS, PACS and PCA sharing resources with non-CIP cyber assets should also be considered rather than only BCS. 

CA: Restore the CA definition.

Rationale: Given that SCI is defined as a programmable device, it meets the CA definition and should be treated as one type of CAs rather than excluding it from CA definition.

VCA: A logical instance of an operating system or firmware including software, data and virtual hardware on the logical instance hosted on a physical Cyber Asset.

BCS: Restore BCS definition.

Rationale: BCS should only include BCAs not other CIP cyber assets. Given that SCI could be an EACM, PACS or PCR, it shouldn’t be included in BCS definition.

CIP System: This definition is not needed based on our proposed changes above.

Rationale: CIP System won’t work for the CIP requirements since not each requirement applies to all CIP cyber assets that are included in the CIP System and the requirement has to specified which CIP cyber asset would apply.

ERC: Restore ERC definition since it is still effective (see our rationale in Q3).

EAP: Restore the definition

Rationale: Given that the current EAP is still clear and doesn’t exclude policy-based rules, there is no need to modify EAP definition.

ESP: Restore ESP definition since it is still effective for the perimeter-based network protection (see the rationale in Q4).

IRA:

SDT Proposed SCI definition

User-initiated real-time access by a person from outside of the Responsible Entity’s Electronic Security Perimeters (ESP) using a routable protocol:

·        to a Cyber System within an ESP;

·        through a Cyber Asset or Virtual Cyber Asset that is converting communications from a routable protocol to a non-routable protocol to a Cyber System not within an Electronic Security Perimeter;

·        To Management Interfaces of Shared Cyber Infrastructure; or

·        To Management Interfaces of an Electronic Access Control or Monitoring Systems that enforces an ESP.

Our Proposed Changes to the Definition

User-initiated interactive access by a person employing a remote access client or other remote access technology using a routable protocol. (This includes cases where a routable protocol is converted to a non-routable protocol)

Remote access originates from a Cyber Asset or Virtual Cyber Asset that is:

a.      not an Intermediate System

b.      is not located within any of the Responsible Entity’s Electronic Security Perimeter(s) or,

c.      at a defined Electronic Access Point (EAP).

Interactive remote access does not include system-to-system process communications. (See our rationale in Q5).

Rationale: IRA definition should only define what remote access constitutes an IRA and shouldn’t include the accessed end devices. The IRA accessed cyber assets should be addressed in the requirements rather than in the IRA definition. We propose to add additional language to clarify the routable protocol converting to non-routable still falls within IRA definition since the current IRA definition is not clear on this. The current IRA definition states the user-initiated access using a routable protocol and doesn’t say all communication sessions need to be routable.

Intermediate System: Restore the IS definition since the current definition is clear and no need to redefine it.

Rationale: The proposed IS definition starts from “EACMS”, which is not correct logically. A Cyber Asset should meet the IS definition and then becomes an EACMS. Otherwise an IS can be missed if it is not an EACMS originally.

BCSI: Restore the definition based on our proposed definition changes above.

Cyber Security Incident: Restore the definition based on our proposed definition changes above.

PSP: Restore the definition based on our proposed definition changes above.

Removable Medium: Restore the definition based on our proposed definition changes above.

Reportable Cyber Security Incident: Restore the definition based on our proposed definition changes above.

TCA: Restore the definition based on our proposed definition changes above.

We believe the options are mostly clear and acceptable with the exception of the phrase “independent SCI supporting” either high or medium impact. It is unclear and confusing how an SCI can be both independent and supporting simultaneously. The proposed revised definition of BES Cyber System already would make it clear that SCI is to be included in CIP scope if applicable. We recommend removing the second bullet point entirely from both R1.1 and R1.2.

 

 

MRO NSRF, Segment(s) 2, 4, 1, 6, 3, 5, 7/1/2021

Independently Identified SCI.jpg

- 0 - 0

Recommend spelling out "Shared Cyber Infrastructure" and its acronym within the standard text.

Recommend including the definition within the text, or make a statement in the text directing to the definition in the definition list.

Amy Jones, Public Utility District No. 2 of Grant County, Washington, 5, 9/1/2021

- 0 - 0

Evergy incorporates by reference and endorses the comments as filed by the Edison Electric Institute.

Alan Kloster, On Behalf of: Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Kinte Whitehead, Exelon, 3, 9/1/2021

- 0 - 0

Amy Bratkovic, On Behalf of: PNM Resources - Public Service Company of New Mexico, , Segments 1, 3

- 0 - 0

No comment.

Dwanique Spiller, On Behalf of: Berkshire Hathaway - NV Energy - WECC - Segments 5

- 0 - 0

The options for SCI association within CIP-002 may be clear, but the handling of SCI involving EACMS cases is not clear from CIP-002 since that standard is limited to assessment of HIGH, MEDIUM and LOW impact BCS cases.

John Galloway, On Behalf of: Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2

- 0 - 0

Tacoma Power, Segment(s) 1, 3, 4, 5, 6, 3/9/2021

- 0 - 0

GRE agrees with the comments submitted by the NSRF. 

Michael Brytowski, Great River Energy, 3, 9/1/2021

- 0 - 0

In support of IRC SRC/SWG.

Request clarification when a SCI supports both high impact BES and medium impact BES. Is that SCI high watermarked to the high impact?

Request clarification of “it is a part of for CIP Requirement Applicability?” Is there a missing word? Should the language be “it is a part of it for CIP Requirement Applicability?”

Request clarification of the OR in 1.3. Is the entity identifying low impact BCS OR supporting SCI OR both?

Request clarification of the 1.3 parenthetical. Is the entity required to provide an asset list for either low impact BCS or supporting SCI?

Monika Montez, On Behalf of: California ISO, WECC, Segments 2

- 0 - 0

Nurul Abser, NB Power Corporation, 1, 9/1/2021

- 0 - 0

Independent SCI supporting and supporting SCI are not clear. They should be removed from CIP-002. 

Donna Wood, Tri-State G and T Association, Inc., 1, 9/1/2021

- 0 - 0

Casey Jones, On Behalf of: Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5

- 0 - 0

The only exception of the phrase “independent SCI supporting” either high or medium Impact. The statement is unclear and confusing how an SCI can be both indendent and supporting sitmultaneously. The proposed revised definition of the BES Cyber System already would make it clear that SCI is to be included in CIP scope if applicable, It is recommended removing the second bullet entirely from both R1.1 and R1.2.

Israel Perez, On Behalf of: Salt River Project, WECC, Segments 1, 3, 5, 6

- 0 - 0

David Jendras, Ameren - Ameren Services, 3, 9/1/2021

- 0 - 0

We thank the SDT for it’s work but believe the changes to definitions will create greatly impact existing entity’s policies, procedures and documentation and increase administrative overhead when some basic changes can be drafted which will a) retain and address the issue of virtualization, b) allow entity’s the flexibility to identify risks and implement appropriate security controls, and c) clarify language for regulators and industry alike. The current drafts create much administrative overhead because it requires entity’s using virtual platforms to parse out subcomponents and assign risk to establish compliance for such components. As entity’s move to cloud environments this will not be possible and therefore it is more practical to allow entity’s to identify their systems, assess risk and categorize them based on hardware profiles. SCI does little to clarify and define. In general, WAPA recommends a focus on individual hardware components and software enforcment policies (AAA). For example, an entity could consider an ESXi platform a single BCS (or BCA) which contains VCAs. Just a perspective.

The phrases “supporting SCI” and “independent SCI supporting” are not clear and should be removed from CIP-002.  Recommend that SCI should be either categorized as a CIP Cyber Asset or not a CIP Cyber Asset (Hardware based decision). SCI shouldn’t appear in CIP-002 and Applicable Systems of CIP-003 to CIP-013. SCI should be evaluated using the criteria of a BCAs, EACMS, PACS or PCAs which can be missed in the virtualization environment.

For the proposed All-in-Scenario, SCI should be identified based on hardware such as BCA, EACMS, PACS or PCA rather than a new classification of CIP cyber asset. Creating separate definitions for SCI is tantamount to identifying hard drives and PCI cards as separate BCA and this will require entity’s a great deal of administrative overhead.

Secondly, SCI that can initialize, deploy and configure a BCA should be categorized as a BCA since it has a high risk profile - can remove a virtual BCA and impact to the BES within 15 minutes. Similarly, if a SCI can initialize, deploy and configure an EACMS and should be categorized as an EACMS since it can remove the virtual EACMS and it’s functions.

For independently Identified SCI proposed in the right box diagram below, SCI with an active Management Interface can initialize, deploy and configure a CIP Cyber Asset. This further supports the case for categorization based on hardware and not sub-components.

If the right-side SCI hosts VCA such as a CIP cyber asset regardless of the impact rating, the right side SCI should be identified as the same impact CIP cyber asset it hosts. It has the capability to impact the BES in 15 minutes.  The right side SCI is out of CIP scope only: (1) if all VCAs it hosts are non-CIP cyber assets, this SCI would be out of CIP scope thus no need to be identified; (2) If it is used only to configure high impact network policy, it would be out of CIP scope since out of band management for CIP cyber assets is not required by the current CIP requirements scope and the SAR

Based on our comments above, the “SCI” and “independently Identified SCI” are not needed to be identified in CIP-002 since the SCI or independently Identified SCI either is a CIP BES Cyber Asset or not in scope.   

 

We recommend revising definitions of BCA, EACMS, PACS and PCA to include SCI. Our proposed changes align with FERC and NERC’s security objectives and the SDT’s goal to address cyber security risks to the reliability of the BES from virtualization technologies, while having less impact on the entities existing CIP programs, processes and documentation. Entities can use their existing CIP cyber asset identification processes to identify BCAs, EACMS, PACS and PCAs based on SCI and Management Interface language to address virtualization. If the responsible entities don’t have virtualization, they wouldn’t need to identify any additional CIP cyber assets at all.

Recommendations:

  1. Restore the CIP-002 R1 and its Parts resulting from our proposed definitions changes below.

  2. We propose the following changes to the new or existing definitions:

    SCI: One or more programmable electronic devices, including the software and Management Interfaces in those devices, that share:

  • CPU and memory resources with one or more Virtual Cyber Assets identified as a BCA, EACMS, PACS or PCA; or

  • storage resources with any part of a BES Cyber System or their associated EACMS, PACS or PCA.

  • Includes devices that contain Management Interfaces for virtualization management.

  • SCI does not include the supported VCA or CA with which it shares its resources.

     

     

    Basis for this Recommendation: PCA is missing from the SCI definition. In our proposed changes, it is not necessary to identify SCI independently since SCI would be identified as a CIP Cyber Asset(s).

     

    Management Interface: A user interface, logical interface, or dedicated physical port that is used to:

  • Initialize, deploy, and configure BCA, EACMS, PACS, or PCA; or

  • Control the processes of initializing, deploying, and configuring Shared Cyber Infrastructure; or

  • Configure EAP of an Electronic Security Perimeter; or

  • Configure EACMS that controls all communications to and from the BCS unless ESP model is used.

  • Excludes physical user interfaces (e.g., power switch, touch panel, etc.). (Refer to Q6).

    Basis for this Recommendation: the definition should focus on “in scope” CIP management interfaces. The term “Provide lights-out management capabilities” is not clear and should be removed since this criterion itself cannot make a management interface fall within CIP scope.

  • Also, the Management Interface on the SCI is absent. We have added a bullet in our proposed definition to address it.

  • Furthermore, we suggest edits to include:

  • a) changing configure an ESP to configure an EAP

  • b) adding configure EACMS to address the zero-trust mode based on our comments in Q4

     

    CA: Restore the CA definition.

    Basis of this Recommendation: If SCI is defined as a programmable device, it meets the definition of a CA and should be treated as one type of CA’s rather than excluding it from CA definition.

    VCA: A logical instance of an operating system or firmware including software, data and virtual hardware on the logical instance hosted on a physical Cyber Asset.

    BCS: Restore BCS definition.

    Basis of this Recommendation: BCS should only include BCAs not other CIP cyber assets. Given that SCI could be an EACM, PACS or PCR, it shouldn’t be included in BCS definition.

    CIP System: This definition is not needed based on our proposed changes above.

    Basis of this Recommendation: CIP System won’t work for the CIP requirements since not each requirement applies to all CIP cyber assets that are included in the CIP System and the requirement has to specified which CIP cyber asset would apply.

    ERC: Restore ERC definition since it is still effective (see our rationale in Q3).

    EAP: Restore the definition

    Rationale: Given that the current EAP is still clear and doesn’t exclude policy-based rules, there is no need to modify EAP definition.

    ESP: Restore ESP definition since it is still effective for the perimeter-based network protection (see the rationale in Q4).

     

    IRA: User-initiated interactive access by a person employing a remote access client or other remote access technology using a routable protocol. (This includes cases where a routable protocol is converted to a non-routable protocol)

    Remote access originates from a Cyber Asset or Virtual Cyber Asset that is:

  1. not an Intermediate System

  2. is not located within any of the Responsible Entity’s Electronic Security Perimeter(s) or,

  3. at a defined Electronic Access Point (EAP).

  • Interactive remote access does not include system-to-system process communications. (See our rationale in Q5).

Basis for this Recommendation: IRA definition should only define what remote access constitutes as  IRA and shouldn’t include the accessed end devices. IRA accessed Cyber Assets should be addressed in the requirements rather than in the IRA definition. Recommend additional language to clarify the routable protocol converting to non-routable that falls within IRA definition - since the current IRA definition is not clear on this anyway. The current IRA definition states the user-initiated access using a routable protocol and doesn’t refer to communication sessions needing to be routable.

 

Intermediate System: Restore the IS definition since the current definition is clear and no need to redefine it.

Basis for this Recommendation: The proposed IS definition starts from “EACMS”, which is not correct logically. A Cyber Asset should meet the IS definition and then becomes an EACMS. Otherwise an IS can be missed if it is not an EACMS originally.

BCSI: Restore the definition based on our proposed definition changes above.

Cyber Security Incident: Restore the definition based on our proposed definition changes above.

PSP: Restore the definition based on our proposed definition changes above.

Removable Medium: Restore the definition based on our proposed definition changes above.

Reportable Cyber Security Incident: Restore the definition based on our proposed definition changes above.

TCA: Restore the definition based on our proposed definition changes above.

 

Barry Jones, On Behalf of: sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6

- 0 - 0

Benjamin Winslett, Georgia System Operations Corporation, 4, 9/1/2021

2016-02_Virtualization_Unofficial_Comment_Form_(FINAL).docx

- 0 - 0

Please clarify if the SCI “form” as an Cyber System that includes the Management Interface will not require a separate Cyber Asset in the BCS List for the Management Interface provided the SCI Management Interface is the document IP address in CIP-007 R1. 

Justin Welty, NextEra Energy - Florida Power and Light Co., 6, 9/1/2021

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Cynthia Lee, Exelon, 5, 9/1/2021

- 0 - 0

OPG concurs with NPCC's RSC comments

David Kwan, On Behalf of: Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Becky Webb, Exelon, 6, 9/1/2021

- 0 - 0

ACES Standard Collaborations, Segment(s) 1, 9/1/2021

- 0 - 0

Eversource recommends using "Independently identified".    The term seems inconsistent in regards to how its used in all the CIP Standards.

Eversource 1, Segment(s) 3, 1, 9/1/2021

- 0 - 0

Karie Barczak, DTE Energy - Detroit Edison Company, 3, 9/1/2021

- 0 - 0

James Baldwin, Lower Colorado River Authority, 1, 9/1/2021

- 0 - 0

Yes. The two options for SCI identification are clear within the CIP-002 standard revisions. However, the SDT should provide implementation guidance including examples of how to document the SCI, whether included within the CIP System or independently. Additionally, it would be helpful if the SDT was able to provide Implementation Guidance that included a logic diagram depicting how the device classifications and embedded definitions like Management Interface and CIP System can be applied.

In addition, the SDT has been clear that this project focuses on on-premise virtualization, however, many virtualization concepts, like SCI, could be interpreted as being related to use of cloud computing technologies. AWS suggests explicitly stating that the Standards do not apply to cloud within the Applicability section of CIP-002.  If these updated Standards do not apply to cloud, it should be obvious to the reader.

Maggy Powell, Amazon Web Services, 7, 9/1/2021

- 0 - 0

Southern agrees that the two options are clear and it is understood that when a high/medium impact BCS that includes any supporting SCI is identified as a complete BCS (‘all-in’), the SCI is included in CIP requirement applicability wherever a BCS is identified in applicability.

Southern Company, Segment(s) 1, 3, 6, 5, 1/14/2021

- 0 - 0

LCRA Compliance, Segment(s) 6, 5, 1, 5/11/2015

- 0 - 0

ERCOT supports the IRC SRC comments and offers these additional comments:

  • R1.1, bullet 1: Under the current version of CIP-002, there is no specific requirement to identify specific types of Cyber Assets applicable to the remaining CIP standards; it is implied at best. Going beyond the BCS identification into identifying specific Cyber Asset types, like Shared Cyber Infrastructure, is a change in to the fundamentals of CIP-002 and takes us back to CIP v1-v4 and the very granular level of Cyber Asset identification.  The SDT should determine if all Cyber Asset types should be identified in CIP-002 or not. Each Cyber Asset type under the CIP standards is important in its role, including the SCI. If the SDT does not think that all Cyber Asset types should be addressed, SCI should be removed from this standard.
  • R1.1, bullet 2: Please clarify the use of “independent.” It is unclear what this means. Independent of what?  
  • ERCOT recommends that no changes be made to requirement R1 in CIP-002.

Brandon Gleason, 9/1/2021

- 0 - 0

LeRoy Patterson, Public Utility District No. 2 of Grant County, Washington, 6, 9/1/2021

- 0 - 0

<duplicate>

Dana Showalter, On Behalf of: Electric Reliability Council of Texas, Inc., Texas RE, Segments 2

- 0 - 0

EEI agrees that the two options in CIP-002 R1 are clear based on the explanation contained in the technical rationale, and supports the changes made regarding the identification of SCI within CIP-002.    

Mark Gray, On Behalf of: Edison Electric Institute, NA - Not Applicable, Segments NA - Not Applicable

- 0 - 0

While the expectation is clear with regard to what needs to be protected and why, what is not clear is what is required to achieve compliance with CIP-002 R1.1 requirements.

The requirement requires the identification of BCS as either “including any supporting SCI as part of the BCS” or with “independent SCI supporting any part of the high impact BCS or its associated Electronic Access Control or Monitoring Systems (EACMS), Physical Access Control Systems (PACS) or Protected Cyber Assets (PCAs).” This does not allow for the identification of BCS independent of having SCI, and therefore doesn’t account for non-virtualized environments.

The requirements and measures of CIP-002 do not sufficiently detail what is required to demonstrate compliance. The requirements are to create a list that identifies “each [BCS] as either” including supporting SCI or having independent SCI. However, the independent SCI details an association to EACMS, PACS, PCA. The requirement expects an identification of “BES Cyber Systems” but the sub-bullets imply an expectation to identify SCI and corresponding asset/system classifications. The measures and technical rationale provide no additional clarity other than creating lists. Is the expectation to simply provide identification that the identified BCS either include SCI or are supported by SCI (e.g. Yes/No or Checkbox), or is the expectation to explicitly identify and categorize SCI that meet this criteria (e.g. “1.) ABC High Impact BCS; 2.) CDE High Impact EACMS SCI”). If the expectation is to classify SCI, what should be the approach for classifying SCI that supports multiple classifications (e.g. EACMS and PACS)?

Gail Golden, Entergy - Entergy Services, Inc., 5, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

Alyssia Rhoads, Public Utility District No. 1 of Snohomish County, 1, 9/1/2021

- 0 - 0

 

PJM signs on to the comments provided by the IRC SRC.

Elizabeth Davis, On Behalf of: Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2

- 0 - 0

Lindsay Wickizer, Berkshire Hathaway - PacifiCorp, 6, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

Sam Nietfeld, Public Utility District No. 1 of Snohomish County, 5, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

SNPD Voting Members, Segment(s) 4, 6, 5, 1, 6/18/2020

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

John Martinsen, Public Utility District No. 1 of Snohomish County, 4, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

John Liang, Snohomish County PUD No. 1, 6, 9/1/2021

- 0 - 0

Request clarification when a SCI supports both high impact BES and medium impact BES. Is that SCI high watermarked to the high impact?

Request clarification of “it is a part of for CIP Requirement Applicability?” Is there a missing word? Should the language be “it is a part of it for CIP Requirement Applicability?”

Request clarification of the or in 1.3. Is the entity identifying low impact BCS or supporting SCI or both?

Request clarification of the 1.3 parenthetical. Is the entity required to provide an asset list for either low impact BCS or supporting SCI?

 

We don’t understand how to categorize a Shared Cyber Infrastructure. The SDT seems to make a distinction between two types of SCI, one type is supporting, and the other type is independent supporting. Our hypothesis is that a “supporting SCI” is for BCS (BCA/PCA) and that an “independent supporting SCI” is for associated Electronic Access Control or Monitoring Systems (EACMS), Physical Access Control Systems (PACS)).

In both cases, the SCI is the categorization labels, like BCA, PCA, EACMS, PACS, TCA.

Yet in the Applicable Systems column in the other CIPs, the SDT seem to make a distinction between the SCI, for example

CIP-005 R1.5 1.5 … PACS hosted on SCI … SCI identified independently…

CIP-007 R1.1 SCI identified independently supporting.

Clarification is needed.

Are the two options for identification SCI required? Is there a difference in the controls that we want to apply?

We suggest simplifying the language or add more precision. Example:

Per Attachment 1, Section 1, identify each high impact BES Cyber System as either of the following, if any, at each asset; High Impact BCS and their associated Electronic Access Control or Monitoring Systems (EACMS), Physical Access Control Systems (PACS), Protected Cyber Assets (PCAs) or SCI.

Furthermore, in the definition of SCI the PCA is not listed. Is this intentional? Wouldn’t be possible to have a PCA supported by an SCI? We suggest that the SDT review the SCI / VCA/ PCA definitions, adjust the applicability and the requirements.

Reference SCI: One or more programmable electronic devices, including the software and Management Interfaces, that share:  • CPU and memory resources with one or more Virtual Cyber Assets identified as a BCA, EACMS, or PACS; or  

NPCC Regional Standards Committee, Segment(s) 10, 2, 4, 7, 3, 1, 5, 6, 8/6/2021

- 0 - 0

Ryan Olson, Portland General Electric Co., 5, 9/1/2021

- 0 - 0

Roger Fradenburgh, On Behalf of: Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1

- 0 - 0

The ISO/RTO Council (IRC) Standards Review Committee (SRC) requests clarification of how SCI is to be treated when it supports both high impact BES and medium impact BES; i.e. is the SCI to be watermarked to the highest impact?

Request clarification of “it is a part of for CIP Requirement Applicability?” Is there a missing word? Should the language be “it is a part of it for CIP Requirement Applicability?”

Request clarification of the OR in 1.3. Is the entity identifying low impact BCS OR supporting SCI OR both?

Request clarification of the 1.3 parenthetical. Is the entity required to provide an asset list for either low impact BCS or supporting SCI?

ISO/RTO Council Standards Review Committee 2016-02 Virtualization (Draft 2), Segment(s) 2, 9/1/2021

- 0 - 0

LaTroy Brumfield, American Transmission Company, LLC, 1, 9/1/2021

- 0 - 0

Gail Elliott, On Behalf of: Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1

- 0 - 0

Hot Answers

Portland General Electric Company supports this change, but generally agrees with the comments provided by EEI for this survey question.

Dan Zollner, Portland General Electric Co., 3, 9/1/2021

- 0 - 0

PGE FCD, Segment(s) 5, 1, 3, 6, 9/11/2018

- 0 - 0

Other Answers

Reclamation recommends adding the additional clarification (such as “SCI identified as supporting, but not part of…”).

Richard Jackson, U.S. Bureau of Reclamation, 1, 8/19/2021

- 0 - 0

Dominion Energy recommends modifying the definition as folows:  “SCI identified as supporting the functionality, but not part of…”.

Dominion, Segment(s) 3, 5, 1, 9/19/2019

- 0 - 0

Jeanne Kurzynowski, On Behalf of: CMS Energy - Consumers Energy Company - RF - Segments 3, 4, 5

- 0 - 0

The term "SCI identified independently" does not read intuitively without reading the guidance and technical rationale.  Since those documents are not auditable, it must stand on its own and needs more revision to be more clear.  Consider developing an additional defined term and classification:  "Independent SCI" - "An SCI that is not identified as part of a BCS or its associated EACMS, PACS, or PCAs."  This approach would keep the requirement language clean and include the needed guidance in the auditable parts of the standards and definitions.

CHPD, Segment(s) 3, 1, 6, 5, 8/24/2021

- 0 - 0

Glen Farmer, Avista - Avista Corporation, 5, 8/24/2021

- 0 - 0

The Applicable System, “SCI identified independently” is ambiguous and unclear at best.  Specifically, if SCI is hosting multiple Applicable Systems of different ratings, how is the SCI to be classified?  Should it be high watermarked and protected to the highest rating of those Applicable Systems?  If so, the SCI should be classified at the high watermark and be afforded the same protections as the Applicable System it supports - BCS, EACMS, PACS.  The current definition and requirement is ambiguous which could result in an interpretation that applies BCS controls to an SCI that only supports EACMS or PACS.  NRG requests the Standards Drafting Team provide more clarity between the two options: “All in” and “Identified SCI Option” as they seem to apply only when supporting a BCS and not in instances where SCI is hosting EACMS and/or PACS only.  NRG disagrees with the Technical Rationale that requires logical isolation of SCI that hosts EACMS/PACS and no impact cyber systems.  Within the context of the current CIP standards, there is no requirement for logical isolation between physical servers in this scenario.

Martin Sidor, NRG - NRG Energy, Inc., 6, 8/24/2021

- 0 - 0

The Applicable System, “SCI identified independently” is ambiguous and unclear at best.  Specifically, if SCI is hosting multiple Applicable Systems of different ratings, how is the SCI to be classified?  Should it be high watermarked and protected to the highest rating of those Applicable Systems?  If so, the SCI should be classified at the high watermark and be afforded the same protections as the Applicable System it supports - BCS, EACMS, PACS.  The current definition and requirement is ambiguous which could result in an interpretation that applies BCS controls to an SCI that only supports EACMS or PACS.  NRG requests the Standards Drafting Team provide more clarity between the two options: “All in” and “Identified SCI Option” as they seem to apply only when supporting a BCS and not in instances where SCI is hosting EACMS and/or PACS only.  NRG disagrees with the Technical Rationale that requires logical isolation of SCI that hosts EACMS/PACS and no impact cyber systems.  Within the context of the current CIP standards, there is no requirement for logical isolation between physical servers in this scenario.

Patricia Lynch, NRG - NRG Energy, Inc., 5, 8/24/2021

- 0 - 0

Additional clarification is required. Some SCI may provide underlying compute, storage, or network virtualization services, which is essential for the proper function of a BCS. Other SCI systems such as those providing overlays for management functions or monitoring, may not be required for real-time BCS functionality.  Accordingly, that distinction, and provision of controls accordingly, would be beneficial in the associated glossary terms.

Tennessee Valley Authority, Segment(s) 1, 3, 5, 6, 10/18/2018

- 0 - 0

Xcel Energy supports the comments of EEI.

Amy Casuscelli, On Behalf of: Xcel Energy, Inc. - MRO, WECC - Segments 1, 3, 5, 6

- 0 - 0

Andrea Jessup, On Behalf of: Bonneville Power Administration, WECC, Segments 1, 3, 5, 6

- 0 - 0

Mike Magruder, Avista - Avista Corporation, 1, 8/26/2021

- 0 - 0

Introduction of the SCI Group concept as enumerated in response to Question 1 would provide the further clarity needed to address the relationship of devices identified as SCI to the BCS or SCIG of which they are a member.  This additional clarity should be reinforced in the definitions, proposed as follows:

 

 

 

DUKE ENERGY PROPOSED DEFINITIONS FOR BCS, SCI, and SCIG:

BES Cyber System (BCS) -  One or more BES Cyber Assets logically grouped by a Responsible Entity to perform one or more reliability tasks for a functional entity, including Shared Cyber Infrastructure that the Responsible Entity chooses to group into the BES Cyber System it supports.

Shared Cyber Infrastructure (SCI) - Programmable electronic devices, including the software and Management Interfaces, that share…(proposed bullets remain)… Each SCI is grouped by the Responsible Entity into one or more BCS or SCIG. SCI does not include the supported VCA or CA with which it shares its resources.

Shared Cyber Infrastructure Group (SCIG) -   One or more Shared Cyber Infrastructure devices logically grouped by a Responsible Entity.

Katie Connor, On Behalf of: Duke Energy - SERC, RF - Segments 1, 3, 5, 6

- 0 - 0

AECI, Segment(s) 1, 3, 6, 5, 3/4/2021

- 1 - 0

See MRO-NSRF and EEI Comments

Clarice Zellmer, WEC Energy Group, Inc., 5, 8/26/2021

- 0 - 0

This is not clear. We assume that the phrase means SCI not declared as part of a BCA, PCA, EACMS, or PACS but it supports the BCA, PCA, EACMS, or PACS function (for example, a BCA can be run on VM system and the VM system will be defined as SCI, and the SCI can be declared as only SCI and not a dual declaration as a BCA and a SCI). However, this is only an assumption.

Further, the phrase “independent SCI supporting any part of the … BCS” is confusing. It is not clear how an SCI can both be independent and supporting any part of a BES Cyber System. On its face it would seem that if an SCI supports any part of a BES Cyber System then it is not independent and is supporting.

We acknowledge the SDT’s attempt to avoid a “hall of mirrors” scenario where it could be interpreted that a device serving as an EACMS is required to have its own EACMS. However we also feel this situation may already occur today in some audits and not just a possibility going forward in the future. We recommend modifying existing definitions of BES Cyber System, BES Cyber Asset, and/or EACMS (ex. including an exclusionary phrase that an EACMS does not require its own EACMS).

Ronald Bender, Nebraska Public Power District, 5, 8/27/2021

- 0 - 0

Josh Johnson, Lincoln Electric System, 1, 8/27/2021

- 0 - 0

This is already clarified in the third and fourth bullet of the SCI definition. Suggest using ‘SCI supporting an Applicable System above.’ See (CIP-005-8 Part 1.5)

WECC CIP, Segment(s) 10, 2/17/2021

- 0 - 0

Yes, this is clear.

William Steiner, Midwest Reliability Organization, 10, 8/30/2021

- 0 - 0

AZPS feels that “SCI identified as supporting, but not part of” provides more clarity than “SCI identified independently…”, as it could be interpreted as applied to an SCI that is only supporting an applicable system.

We feel the statement “SCI that supports an applicable system that is independently categorized as an SCI and as not part of the applicable BES Cyber System” provides more clarity.

Marcus Bortman, APS - Arizona Public Service Co., 6, 8/30/2021

- 0 - 0

The phrase “SCI Identified Indepedently, and more generally the desfinition of SCI is ambiguous and It is confusing to understand the definition of Shared Cyber Infrastrure (SCI) and therefore the overall requirement is unclear.  Is SCI watermarked at the highest level?  Strongly encourage better definition within the language of the standard and definitions to ensure that implementation is not dependent on independent on non-enforcable technical rationale and implementation guidelines. 

Susan Sosbe, On Behalf of: Wabash Valley Power Association, , Segments 1, 3

- 0 - 0

Additional clarification is needed

Carl Pineault, Hydro-Qu?bec Production, 5, 8/30/2021

- 0 - 0

While it is clear to those that have been following this project and or understand virtualization technologies and how it is used, a non-technical person may need more clarification.  Further, “SCI identified independently…” the information provided in the most recent webinar was much clearer than what reads in the standards and Technical Rationale, but that is not binding.  While both try to explain it, we don’t feel the Technical Rationale and glossary term does enough to distinguish exactly what is intended by the SDT. 

Secondly, CIP-002 R1.x doesn’t use the same verbiage.  For example, “A XXXX impact BCS and independent SCI supporting any part of the XXXX impact BCS...”  This should read:  “A XXXX impact BCS and any SCI identified independently… supporting any part of the XXXX impact BCS...”  

We do feel these two classifications could work for industry, but need significant and binding definitions and distinctions with technical basis so entities can avoid misclassification of SCI.

 

AEPC has signed on to ACES comments.

Jennifer Bray, Arizona Electric Power Cooperative, Inc., 1, 8/30/2021

- 0 - 0

The phrase “independent SCI supporting any part of the … BCS” is confusing. It is not clear how an SCI can both be independent and supporting any part of a BES Cyber System. On its face it would seem that if an SCI supports any part of a BES Cyber System then it is not independent and is supporting.

We acknowledge the SDT’s attempt to avoid a “hall of mirrors” scenario where it could be interpreted that a device serving as an EACMS is required to have its own EACMS. However we also feel this situation may already occur today in some audits and not just a possibility going forward in the future. We recommend modifying existing definitions of BES Cyber System, BES Cyber Asset, and/or EACMS (ex. including an exclusionary phrase that an EACMS does not require its own EACMS).

Justin MacDonald, On Behalf of: Midwest Energy, Inc., , Segments 1

- 0 - 0

Additional clarification is needed as “SCI identified independently…” remains ambiguous.

Steve Toosevich, NiSource - Northern Indiana Public Service Co., 1, 8/31/2021

- 0 - 0

CEHE finds the language “SCI identified independently supporting an Applicable System above” confusing.   It is confusing because “SCI identified independently” is a process, and CIP-002-7 R1.1 uses the term “independent SCI” when it asks to identify, “A high impact BCS and independent SCI supporting …” When stated in this context, the phrase “independent SCI” is a thing that can be defined.  CEHE proposes that the Applicable Systems column should state “Independent SCI that supports an Applicable System above” and that “independent SCI” can be defined or explained as “a Cyber System identified separately from the BCS, EACMS, PACS, and/or PCA it supports.” 

Eli Rivera, On Behalf of: CenterPoint Energy Houston Electric, LLC, Texas RE, Segments NA - Not Applicable

- 0 - 0

Southwest Power Pool Standards Review Group (SSRG), Segment(s) 2, 9/4/2019

- 0 - 0

NCPA does not support the definition and raises the question how SCI is to be identified independently.  At there very least there would need to be guidance on what should be considered in the identification process.  

Chris Carnesi, On Behalf of: Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6

- 0 - 0

SIGE finds the language “SCI identified independently supporting an Applicable System above” confusing.   It is confusing because “SCI identified independently” is a process, and CIP-002-7 R1.1 uses the term “independent SCI” when it asks to identify, “A high impact BCS and independent SCI supporting …” When stated in this context, the phrase “independent SCI” is a thing that can be defined.  SIGE proposes that the Applicable Systems column should state “Independent SCI that supports an Applicable System above” and that “independent SCI” can be defined or explained as “a Cyber System identified separately from the BCS, EACMS, PACS, and/or PCA it supports.”  

Brian Tooley, On Behalf of: Southern Indiana Gas and Electric Co., RF, Segments 3, 5, 6

- 0 - 0

It is not clear what is meant by “SCI identified independently…”

Joe Tarantino, On Behalf of: Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6

- 0 - 0

Rachel Coyne, Texas Reliability Entity, Inc., 10, 8/31/2021

- 0 - 0

The definition of Shared Cyber Infrastructure (SCI) will be better explained with the term “SCI identified as supporting, but not part of…”.

BC Hydro requests that SDT provide more clarity around the concept of "not part of.." to better understand the separation point between whether an SCI is considered supporting but not actually part of BCAs, PCAs, EACMS or PACS.

BC Hydro also requests that SDT include a couple of practical examples to explain this concept within the Technical Rationale and proposed definition of SCI.

BC Hydro, Segment(s) 3, 5, 1, 12/18/2018

- 0 - 0

SDG&E supports EEI Comments 

Bridget Silvia, Sempra - San Diego Gas and Electric, 3, 8/31/2021

- 0 - 0

MEAG Power adopts the Southern Company comments.

MEAG Power, Segment(s) 3, 1, 5, 6/15/2017

- 0 - 0

We support NPCC TFIST's comments as found below:

This language can be misinterpreted. Recommend clarification. Current language is “SCI identified independently supporting an Applicable System.” Suggest adding a comma to distinguish between “identified independently” and “supporting.” Resulting in “SCI identified independently, supporting an Applicable System”

Gerry Adamski, Cogentrix Energy Power Management, LLC, 5, 8/31/2021

- 0 - 0

FE Voter, Segment(s) 1, 3, 5, 6, 4, 2/23/2021

- 0 - 0

OKGE supports EEI's comments. 

OKGE, Segment(s) 6, 1, 3, 5, 3/22/2021

- 0 - 0

If the language “SCI identifieid independently” is used then it would be beneficial for “identified independently” to be explicitly defined.

Anthony Jablonski, ReliabilityFirst , 10, 8/31/2021

- 0 - 0

Additional guidance is needed for “SCI identified independently.” Also, the phrase “independent SCI supporting…” is not clear. Is this specifically to the VM environment used to create the virtual BCS?  

Darnez Gresham, Berkshire Hathaway Energy - MidAmerican Energy Co., 3, 8/31/2021

- 0 - 0

See MidAmerican Energy Company comments from Darnez Gresham.

Terry Harbour, Berkshire Hathaway Energy - MidAmerican Energy Co., 1, 8/31/2021

- 0 - 0

Cleco supports comments submitted by EEI.

Clay Walker, On Behalf of: Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6

- 0 - 0

In support of NPCC RSC comments

This language can be misinterpreted. Recommend clarification. Current language is “SCI identified independently supporting an Applicable System.” Suggest adding a comma to distinguish between “identified independently” and “supporting.” Resulting in “SCI identified independently, supporting an Applicable System”

 

The context of the question isn’t clear is this question a general question or it’s pertaining to CIP-002.  

Also, the question offers two choices; “Is this clear” or “is additional clarification needed” yet the choices are Yes/No.  

So, our answer; is No, it’s not clear and yes additional clarification is needed.  

Our hypothesis is that it must be a general question. We are not sure of the value of identifying the SCI (“supporting SCI” vs an “independent supporting SCI”), the SCI should be controlled and own requirements. 

If the SDT maintains its distinction, they should enforce two types of categorizations and the requirements should be defined with those two types of categorizations in mind. 

Nicolas Turcotte, Hydro-Qu?bec TransEnergie, 1, 9/1/2021

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Daniel Gacek, Exelon, 1, 9/1/2021

- 0 - 0

AEP fully supports EEI’s comments that the process for the independent identification of Shared Cyber Infrastructure (SCI) is not clear and needs additional clarification.

JT Kuehne, AEP, 6, 9/1/2021

- 0 - 0

Jamie Monette, On Behalf of: Allete - Minnesota Power, Inc., , Segments 1

- 0 - 0

This language can be misinterpreted. Recommend clarification. Current language is “SCI identified independently supporting an Applicable System.” Suggest adding a comma to distinguish between “identified independently” and “supporting.” Resulting in “SCI identified independently, supporting an Applicable System”

 

The context of the question isn’t clear is this question a general question or it’s pertaining to CIP-002.  

Also, the question offers two choices; “Is this clear” or “is additional clarification needed” yet the choices are Yes/No.  

So, our answer; is No, it’s not clear and yes additional clarification is needed.  

Our hypothesis is that it must be a general question. We are not sure of the value of identifying the SCI (“supporting SCI” vs an “independent supporting SCI”), the SCI should be controlled and own requirements. 

If the SDT maintains its distinction, they should enforce two types of categorizations and the requirements should be defined with those two types of categorizations in mind. 

Leonard Kula, Independent Electricity System Operator, 2, 9/1/2021

- 0 - 0

The language “SCI identified independently” is not clear and should be removed from CIP-002 to CIP-013 (see our comments 1 in Q1). Resulting from our proposed changes to the definitions in Q1, the language “SCI identified independently” is no longer needed. A SCI should be identified either as one of the existing CIP cyber assets or out of CIP cyber asset scope.

This is not clear. We assume that the phrase means SCI not declared as part of a BCA, PCA, EACMS, or PACS but it supports the BCA, PCA, EACMS, or PACS function (for example, a BCA can be run on VM system and the VM system will be defined as SCI, and the SCI can be declared as only SCI and not a dual declaration as a BCA and a SCI). However, this is only an assumption.

Further, the phrase “independent SCI supporting any part of the … BCS” is confusing. It is not clear how an SCI can both be independent and supporting any part of a BES Cyber System. On its face it would seem that if an SCI supports any part of a BES Cyber System then it is not independent and is supporting.

We acknowledge the SDT’s attempt to avoid a “hall of mirrors” scenario where it could be interpreted that a device serving as an EACMS is required to have its own EACMS. However we also feel this situation may already occur today in some audits and not just a possibility going forward in the future. We recommend modifying existing definitions of BES Cyber System, BES Cyber Asset, and/or EACMS (ex. including an exclusionary phrase that an EACMS does not require its own EACMS).

MRO NSRF, Segment(s) 2, 4, 1, 6, 3, 5, 7/1/2021

- 0 - 0

Additional clarification is needed.

Recommend spelling out "Shared Cyber Infrastructure" and its acronym within the standard text.

Recommend including the definition within the text, or make a statement in the text directing to the definition in the definition list.

Amy Jones, Public Utility District No. 2 of Grant County, Washington, 5, 9/1/2021

- 0 - 0

Evergy incorporates by reference and endorses the comments as filed by the Edison Electric Institute.

Alan Kloster, On Behalf of: Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Kinte Whitehead, Exelon, 3, 9/1/2021

- 0 - 0

Yes, although PNMR agrees with EEI that the term "independent SCI" should be clearly explained. 

Amy Bratkovic, On Behalf of: PNM Resources - Public Service Company of New Mexico, , Segments 1, 3

- 0 - 0

Additional guidance is needed for “SCI identified independently.” Also, the phrase “independent SCI supporting…” is not clear. Is this specifically to the VM environment used to create the virtual BCS?  

Dwanique Spiller, On Behalf of: Berkshire Hathaway - NV Energy - WECC - Segments 5

- 0 - 0

Please provide additional clarification with respect to Applicable Systems callout for SCI beyond the phrase "SCI identified independently...".

 

John Galloway, On Behalf of: Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2

- 0 - 0

Tacoma Power, Segment(s) 1, 3, 4, 5, 6, 3/9/2021

- 0 - 0

GRE agrees with the comments submitted by the NSRF. 

Michael Brytowski, Great River Energy, 3, 9/1/2021

- 0 - 0

In support of IRC SRC/SWG.

This language can be misinterpreted. Recommend clarification. Current language is “SCI identified independently supporting an Applicable System.” Suggest adding a comma to distinguish between “identified independently” and “supporting.” Resulting in “SCI identified independently, supporting an Applicable System”

Monika Montez, On Behalf of: California ISO, WECC, Segments 2

- 0 - 0

Nurul Abser, NB Power Corporation, 1, 9/1/2021

- 0 - 0

"SCI identified independently” is not clear and needs additional clarification. 

Donna Wood, Tri-State G and T Association, Inc., 1, 9/1/2021

- 0 - 0

Additional guidance is needed for “SCI identified independently.” Also, the phrase “independent SCI supporting…” is not clear. Is this specifically to the VM environment used to create the virtual BCS?  

Casey Jones, On Behalf of: Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5

- 0 - 0

Not clear on how the SCI is defined in this scenario. For the definition of "SCI identified indepently" is unclear what is meant by this definition, and is not clearly spelled out but an assumption is made. It appears to be assumed that the phrase means SCI not declared as part of a BCA, PCA, EACMS or PACS but it supports the BCA, PCA, EACMS, or PACS function.

Would like this clearly spelled out by defintion and by each of the Applicable Systems column.

Israel Perez, On Behalf of: Salt River Project, WECC, Segments 1, 3, 5, 6

- 0 - 0

David Jendras, Ameren - Ameren Services, 3, 9/1/2021

- 0 - 0

The draft language is not clear. We assume that the phrase means SCI not declared as part of a BCA, PCA, EACMS, or PACS but it supports the BCA, PCA, EACMS, or PACS function (for example, a BCA can be run on VM system and the VM system will be defined as SCI, and the SCI can be declared as only SCI and not a dual declaration as a BCA and a SCI). However, this is only an assumption. How can SCI can both be independent and supporting any part of a BES Cyber System? If SCI supports any part of a BES Cyber System then it is not independent and is supporting.

Barry Jones, On Behalf of: sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6

- 0 - 0

: GSOC recommends revising the language in the definition of SCI such that it is clear to registered entities that “Each SCI must be identified as either…” As well, when SCI is addressed within other definitions, requirements, or applicable systems columns, consistent language should be used throughout, i.e., within the body of the standards, within the definitions, and between the definitions and the standards. As an example of inconsistencies identified in the new definitions, SCI is characterized as “supporting,” “included in,” or “grouped in/with” in various definitions, which usage may not comport with the terms used in the definition of SCI.  Additionally, in CIP-002, SCI is referenced as “supporting” or “independent supporting,” but the term “supporting” is not utilized in the definition of SCI nor in its potential charcterizations as set forth in the definition.  Finally, SCI reference language included in CIP-006 and other standards, at times, includes a clarifications to ensure exclusion of those SCI grouped into a BCS, but that language is also not consistently applied throughout the standards.  To ensure clarity, it is recommended that the language utilized to reference SCIs is consistent throughout the definitions, throughout the standards, and between the definitions and standards.

Benjamin Winslett, Georgia System Operations Corporation, 4, 9/1/2021

- 0 - 0

Requesting better clarification as industry may misinterpret especially the SCI “form” relationship to a function.

Justin Welty, NextEra Energy - Florida Power and Light Co., 6, 9/1/2021

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Cynthia Lee, Exelon, 5, 9/1/2021

- 0 - 0

OPG concurs with NPCC's RSC comments

David Kwan, On Behalf of: Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Becky Webb, Exelon, 6, 9/1/2021

- 0 - 0

While it is clear to those that have been following this project and or understand virtualization technologies and how it is used, a non-technical person may need more clarification.  Further, “SCI identified independently…” the information provided in the most recent webinar was much clearer than what reads in the standards and Technical Rationale, but that is not binding.  While both try to explain it, we don’t feel the Technical Rationale and glossary term does enough to distinguish exactly what is intended by the SDT. 

Secondly, CIP-002 R1.x doesn’t use the same verbiage.  For example, “A XXXX impact BCS and independent SCI supporting any part of the XXXX impact BCS...”  This should read:  “A XXXX impact BCS and any SCI identified independently… supporting any part of the XXXX impact BCS...”  

We do feel these two classifications could work for industry, but need significant and binding definitions and distinctions with technical basis so entities can avoid misclassification of SCI. 

ACES Standard Collaborations, Segment(s) 1, 9/1/2021

- 0 - 0

Eversource recommends using "Independently identified".    The term seems inconsistent in regards to how its used in all the CIP Standards.

Eversource 1, Segment(s) 3, 1, 9/1/2021

- 0 - 0

Karie Barczak, DTE Energy - Detroit Edison Company, 3, 9/1/2021

- 0 - 0

James Baldwin, Lower Colorado River Authority, 1, 9/1/2021

- 0 - 0

Yes, it is clear that the “SCI identified independently” means that it is supporting any part of a high or medium impact BCS or associated EACMS, PACS or PCAs and is not included in the BCS. However, since “SCI identified independently…” is explicitly listed in the applicability columns, the other option for SCI to be included within the CIP System should also be explicitly stated. For example, “High Impact BCS, including supporting SCI, and their associated…”.

Maggy Powell, Amazon Web Services, 7, 9/1/2021

- 0 - 0

Southern agrees that “SCI identified independently” is clear and no additional clarification of that particular phrase is needed.  However, Southern is concerned with the lack of clarity around SCI that does not host a BES Cyber System and is not within an ESP. Specifically, the inclusion of EACMS and PACS within the definition of SCI (and SCI within the EACMS and PACS definitions).  As an example, an entity may have a VCA that is involved in processing access control logs. If this is an example of the “M” in EACMS (see discussion of this on Q14), and any part of the process executes as a VCA, then is the entire SCI now in scope? If so, what about backup systems that copy off snapshots of VCA for backup and thus may “share storage resources” with an EACMS?  It is not clear where the scope of this “EACMS” ends. Southern believes there is clarity and simplicity for SCI that hosts a BCS and is in an ESP, but suggests scoping SCI to that which hosts a BCS and creating separate requirements to specifically address access to the mgt plane of an EACMS or PACS, for example (however, see Q14 as even that is problematic with the broadness of EACMS).  This would be much more straightforward than treating SCI outside the ESP the same as SCI hosting a BCS.

 

Southern proposes the following alternative language for defining SCI, EACMS and PACS:

SCI: One or more programmable electronic devices, including the software and Management Interfaces, that share:

  • CPU and memory resources with one or more Virtual Cyber Assets identified as a BCA; or
  • storage resources with any part of a BES Cyber System.

Each SCI is either:

  • included in one or more BES Cyber Systems; or
  • identified independently. 

SCI does not include the supported VCA or CA with which it shares its resources.

 

EACMS: Cyber Assets or Virtual Cyber Assets that perform electronic access control or electronic access monitoring of the Electronic Security Perimeter(s) or BES Cyber Systems or SCI. This includes Intermediate Systems.

 

PACS: Cyber Assets or Virtual Cyber Assets that control, alert, or log access to the Physical Security Perimeter(s), exclusive of locally mounted hardware or devices at the Physical Security Perimeter such as motion sensors, electronic lock control mechanisms, and badge readers.

 

Southern Company, Segment(s) 1, 3, 6, 5, 1/14/2021

- 0 - 0

LCRA Compliance, Segment(s) 6, 5, 1, 5/11/2015

- 0 - 0

ERCOT supports the IRC SRC comments and offers these additional comments:

  • Clarify “identified independently supporting”. It is unclear what this means. Independent of what?
  • Listing the SCI in the applicable systems columns contradicts what was done in the definition of BES Cyber System. The proposed definition of BES Cyber System already includes SCI but does not have the same qualifiers as in the applicable systems column.

Brandon Gleason, 9/1/2021

- 0 - 0

LeRoy Patterson, Public Utility District No. 2 of Grant County, Washington, 6, 9/1/2021

- 0 - 0

<duplicate>

Dana Showalter, On Behalf of: Electric Reliability Council of Texas, Inc., Texas RE, Segments 2

- 0 - 0

The process for the independent identification of SCI is not clear and needs additional clarification.  EEI notes that within the VSLs for CIP-002, “independently identified SCI” is mentioned 27 times, yet no explanation is provided as to what it means or how this is to be accomplished.

It is also not clear what is meant by the term “independent SCI”.  This term is prominently used in Requirement R1, subpart 1.1 and 1.2 (bullet 2) but not explained.  EEI asks that the SDT either define the term or use another term that is more widely understood.

Note: While EEI has identified our concern related to the use of SCI identified independently in CIP-002, this phrase is used throughout the CIP standards.  For this reason, the SDT should provide more clarity to this term.

Mark Gray, On Behalf of: Edison Electric Institute, NA - Not Applicable, Segments NA - Not Applicable

- 0 - 0

Additional clarification such as mentioned in Question 1 comment would be a benefit. Also, additional clarity regarding how to group or identify the SCI objects would be beneficial. By chassis, by blade, by host, by logical grouping of functions, etc.

Gail Golden, Entergy - Entergy Services, Inc., 5, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

Alyssia Rhoads, Public Utility District No. 1 of Snohomish County, 1, 9/1/2021

- 0 - 0

 

PJM signs on to the comments provided by the IRC SRC.

Elizabeth Davis, On Behalf of: Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2

- 0 - 0

Additional guidance is needed for “SCI identified independently.” Also, the phrase “independent SCI supporting…” is not clear. Is this specifically to the VM environment used to create the virtual BCS?  

Lindsay Wickizer, Berkshire Hathaway - PacifiCorp, 6, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

Sam Nietfeld, Public Utility District No. 1 of Snohomish County, 5, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

SNPD Voting Members, Segment(s) 4, 6, 5, 1, 6/18/2020

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

John Martinsen, Public Utility District No. 1 of Snohomish County, 4, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

John Liang, Snohomish County PUD No. 1, 6, 9/1/2021

- 0 - 0

This language can be misinterpreted. Recommend clarification. Current language is “SCI identified independently supporting an Applicable System.” Suggest adding a comma to distinguish between “identified independently” and “supporting.” Resulting in “SCI identified independently, supporting an Applicable System”

 

The context of the question isn’t clear is this question a general question or it’s pertaining to CIP-002.  

Also, the question offers two choices; “Is this clear” or “is additional clarification needed” yet the choices are Yes/No.  

So, our answer; is No, it’s not clear and yes additional clarification is needed.  

Our hypothesis is that it must be a general question. We are not sure of the value of identifying the SCI (“supporting SCI” vs an “independent supporting SCI”), the SCI should be controlled and own requirements. 

If the SDT maintains its distinction, they should enforce two types of categorizations and the requirements should be defined with those two types of categorizations in mind. 

NPCC Regional Standards Committee, Segment(s) 10, 2, 4, 7, 3, 1, 5, 6, 8/6/2021

- 0 - 0

Portland General Electric Company supports this change, but generally agrees with the comments provided by EEI for this survey question.

Ryan Olson, Portland General Electric Co., 5, 9/1/2021

- 0 - 0

Roger Fradenburgh, On Behalf of: Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1

- 0 - 0

The existing language, “SCI identified independently supporting an Applicable System” is open to misinterpretation. The IRC SRC recommends the language be clarified by adding a comma to distinguish between “identified independently” and “supporting” as follows: “SCI identified independently, supporting an Applicable System”

ISO/RTO Council Standards Review Committee 2016-02 Virtualization (Draft 2), Segment(s) 2, 9/1/2021

- 0 - 0

LaTroy Brumfield, American Transmission Company, LLC, 1, 9/1/2021

- 0 - 0

ITC supports the response submitted by EEI for this question.

Gail Elliott, On Behalf of: Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1

- 0 - 0

Hot Answers

Portland General Electric Company supports the comments provided by EEI for this survey question.

Dan Zollner, Portland General Electric Co., 3, 9/1/2021

- 0 - 0

PGE FCD, Segment(s) 5, 1, 3, 6, 9/11/2018

- 0 - 0

Other Answers

Richard Jackson, U.S. Bureau of Reclamation, 1, 8/19/2021

- 0 - 0

Dominion Energy agrees with the reason for the reference “outside the asset containing…” but the definition itself does not help determine if ERC exists within a communication link that involves a routable protocol that is converted to serial protocol at the last leg of the link. However, based on the NERC SDT Webinar, presented on August 4, it appears that ERC exists in this kind of communication.  One or more high level reference diagrams that illustrate the general concept of the modified term ERC, or some examples of the concept, in an Implementation Guidance document would be beneficial.  See also response to #14A below.

Dominion, Segment(s) 3, 5, 1, 9/19/2019

- 0 - 0

Jeanne Kurzynowski, On Behalf of: CMS Energy - Consumers Energy Company - RF - Segments 3, 4, 5

- 0 - 0

Chelan agrees with the proposed definition changes for ERC.

CHPD, Segment(s) 3, 1, 6, 5, 8/24/2021

- 0 - 0

Glen Farmer, Avista - Avista Corporation, 5, 8/24/2021

- 0 - 0

Martin Sidor, NRG - NRG Energy, Inc., 6, 8/24/2021

- 0 - 0

Patricia Lynch, NRG - NRG Energy, Inc., 5, 8/24/2021

- 0 - 0

There is insufficient clarity provided within the proposed terms to ensure consistent understanding and identification of applicable traffic.

Tennessee Valley Authority, Segment(s) 1, 3, 5, 6, 10/18/2018

- 0 - 0

Xcel Energy supports the comments of EEI.

Amy Casuscelli, On Behalf of: Xcel Energy, Inc. - MRO, WECC - Segments 1, 3, 5, 6

- 0 - 0

Andrea Jessup, On Behalf of: Bonneville Power Administration, WECC, Segments 1, 3, 5, 6

- 0 - 0

Mike Magruder, Avista - Avista Corporation, 1, 8/26/2021

- 0 - 0

Duke has identified three concerns with the proposed ERC definition and underlying strategy:

First, the “outside the asset containing” language expands the current ambiguity in CIP-003 to High and Medium sites, allowing for auditor interpretation with respect to how communication that is translated or terminated through a bastion host locally at the asset should be assessed.  It is not clear from the definitions whether the SDT intends that communication from an outside location that first terminates on a non-CIP System at the asset and then pivots to a CIP System at the asset is included in this ERC definition, or if that break in communication is basis to exclude the CIP System from the ERC applicability. 

Second, use of the ERC definition to attempt to address security concerns associated with remote access to devices that are accessible based on Serial to IP conversion alone exacerbates the CIP-004, 006, and 007 scoping challenges noted by the SDT. 

The ERO has socialized a better path forward using the IRA definition to ensure that devices accessible in this manner are correctly secured.  This would be a better strategy for securing these assets while minimizing low-value compliance paperwork (e.g. documenting lack of syslog capability on a serial-only relay).  This change would take the SDT’s removal of ERC from the CIP-005 requirement language to its logical conclusion, removing the dependence on the ERC definition to define security posture and instead using it as a scoping tool. Refer to slides 9-11 in following presentation: https://www.nerc.com/pa/Stand/Project%20201602%20Modifications%20to%20CIP%20Standards%20RF/2016-02_ERC_and_IRA_Webinar_Slides_05072020.pdf

 

Third, the use of CIP Systems creates confusion as there are no ERC requirements applied to other classifications of devices that are included in the CIP Systems definition (e.g. EACMS, PACS, and TCA devices).  Although simplicity in definitions is desirable, it would be clearer to spell out the system types that are relevant to the defined term (e.g. BCS, PCA, SCI).

 

Therefore, Duke proposes the following definition of ERC, which incorporates the SDT’s improved “communicate” terminology while remaining focused on the ESP boundary as the point where the determination is made.

External Routable Connectivity (ERC) - The ability to communicate across a defined ESP via a bi-directional routable protocol connection.

It does not appear that the SDT’s rationale regarding the shrinkage of the ESP in Zero Trust environments is likely to reach the intra-device level given that the CA, VCA, and SCI definitions remain device-centric.  Therefore, Duke strongly feels that the fundamental change proposed by the SDT is not justified by the potential downside the SDT has identified.

Katie Connor, On Behalf of: Duke Energy - SERC, RF - Segments 1, 3, 5, 6

- 0 - 0

AECI, Segment(s) 1, 3, 6, 5, 3/4/2021

- 1 - 0

See MRO-NSRF and EEI Comments

Clarice Zellmer, WEC Energy Group, Inc., 5, 8/26/2021

- 0 - 0

Ronald Bender, Nebraska Public Power District, 5, 8/27/2021

- 0 - 0

Josh Johnson, Lincoln Electric System, 1, 8/27/2021

- 0 - 0

Just as it has been problematic for entities with assets containing low impact BES Cyber Systems to identify where electronic access controls must be afforded for routable protocol, the use of a physical construct for where logical controls are implemented for CIP-004 and CIP-006 appears to further the problem.

Consider the following two edit to the proposed ERC definition:

The ability to communicate to a CIP System using a bi-directional routable protocol from a nonCIP System.

WECC CIP, Segment(s) 10, 2/17/2021

- 0 - 0

The lower-case ‘asset’ used in the definition really erodes the intent of ERC.  This could allow an entity to not consider communication between corporate networks and BCS to be ERC if they are in the same building (‘asset’), for example at a Control Center.  Alternative proposal: The ability to communicate to a CIP System using a bi-directional routable protocol from a Cyber System that is not protected by an Electronic Security Perimeter located at the same asset. However, the alternate proposal still has a limitation on ‘asset’, which is an undefined term.

William Steiner, Midwest Reliability Organization, 10, 8/30/2021

- 0 - 0

AZPS feels that changing the language to “communicate to” instead of “accessing” has the potential to expand the scope of ERC unintentially. Including “outside the asset containing the CIP system” leads to ambiguity while use of ESP helps clarify intent.  The new definition suits virtual fully, but leaves vagueness and abiguity to physical aspects. AZPS respectfully recommends creating two separate definitions for physical and virtual.

Marcus Bortman, APS - Arizona Public Service Co., 6, 8/30/2021

- 0 - 0

The new language does not clarify where the border where bi-directional communication is considered. The current definition, which specifies the border to be at that EACMS (local firewall) is adequate for most cases.  We understand that the definition needs to be adjusted to recognize implementation of zero trust models.  However, clarifying that external routable connectivity is determined at the physical border of the asset would clearly identify where external routable connectivity is to be considered.

Susan Sosbe, On Behalf of: Wabash Valley Power Association, , Segments 1, 3

- 0 - 0

Additional clarification is needed

Carl Pineault, Hydro-Qu?bec Production, 5, 8/30/2021

- 0 - 0

ACES does not agree with the reference “outside the asset containing” as a scoping mechanism for CIP-007 R4.  We do not understand the correlation of ERC to CIP-007 logging or CIP-004 and CIP-006 risks.  Using the “asset” as a scoping mechanism could lead to various interpretations and allow for loop holes for access.  In our opinion, “outside the asset containing” is not necessary to define ERC.  We feel ESP is still the proper scoping mechanism. 

 

AEPC has signed on to ACES comments.

Jennifer Bray, Arizona Electric Power Cooperative, Inc., 1, 8/30/2021

- 0 - 0

Justin MacDonald, On Behalf of: Midwest Energy, Inc., , Segments 1

- 0 - 0

Steve Toosevich, NiSource - Northern Indiana Public Service Co., 1, 8/31/2021

- 0 - 0

CEHE does not agree with the proposed change to the ERC definition because the phrase “from outside the asset containing the CIP System” is not clear.  “Asset” is not a term in the NERC Glossary of Terms; therefore the definition cannot clarify precisely what “outside the asset” means.  Is it a room, building, geographical location, or something else?

In addition, the proposed definition greatly expands the existing definition by changing from “BES Cyber System” to “CIP System” and by changing from “... to access …” to “… to communicate …”.  However, this expansion can be controlled by specifying specific Cyber Systems in the requirements.   

CEHE suggests maintaining the currently approved definition until a more clearly defined proposal is offered or “Asset” is added as a defined term in the NERC Glossary.

Eli Rivera, On Behalf of: CenterPoint Energy Houston Electric, LLC, Texas RE, Segments NA - Not Applicable

- 0 - 0

Southwest Power Pool Standards Review Group (SSRG), Segment(s) 2, 9/4/2019

- 0 - 0

NCPA does not support the phrase “outside the asset” is vague and confusing.  NCPA suggests the change “…ability to communicate to a CIP System using bi-directional routable protocol from a separate asset containing the CIP system.”  

Chris Carnesi, On Behalf of: Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6

- 0 - 0

SIGE does not agree with the proposed change to the ERC definition because the phrase “from outside the asset containing the CIP System” is not clear.  “Asset” is not a term in the NERC Glossary of Terms; therefore the definition cannot clarify precisely what “outside the asset” means.  Is it a room, building, geographical location, or something else?

In addition, the proposed definition greatly expands the existing definition by changing from “BES Cyber System” to “CIP System” and by changing from “... to access …” to “… to communicate …”.  However, this expansion can be controlled by specifying specific Cyber Systems in the requirements.   

SIGE suggests maintaining the currently approved definition until a more clearly defined proposal is offered or “Asset” is added as a defined term in the NERC Glossary.    

Brian Tooley, On Behalf of: Southern Indiana Gas and Electric Co., RF, Segments 3, 5, 6

- 0 - 0

It’s not clear what is meant by the phrase “from outside the asset containing the CIP System.”  This makes it sound like all CIP Systems must reside within a electronic security perimeter.  It is unclear what it is that the SDT is attempting to accomplish with this wording or how it is allowing scoping based on connectivity of the logging systems as required by CIP-007. Further, the use of the term “asset,” with a lower case A, often causes confusion with “Cyber Asset” when discussing requirements with SMEs.

Joe Tarantino, On Behalf of: Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6

- 0 - 0

Texas RE is concerned the new proposed changes to the ERC definition only focus on WAN and excludes LAN network communications. LAN and WAN network communications are both captured under the current definition.  If the proposed changes are approved, registered entities could potentially argue that they have no ERC even though a bi-directional routable protocol connection is being utilized from LAN to LAN. 

 

As such, this change could reduce the entities’ overall security posture by placing such communications potentially outside the scope of the entities’ CIP-program.  For example, the proposed language for CIP-005 R2.1 includes in scope “medium impact BCS with ERC”.  Since the proposed ERC definition focuses on the term “asset”, Texas RE is concerned that entities could potentially read the “asset” language to remove from scope BCAs such as operator consoles that are not accessible from outside the Control Center (that is, from outside the “asset”).  Specifically, because there is no ERC from outside of the Control Center, it could be argued that the operator consoles no longer fall within the proposed ERC definition.  As a result, important CIP protections such as the use of an Intermediate System to access those assets, physical protections, and personnel training requirements would be limited. 

 

Given these concerns, Texas RE recommends retaining the current definition of ERC.

Rachel Coyne, Texas Reliability Entity, Inc., 10, 8/31/2021

- 0 - 0

BC Hydro seeks more clarity on the term "asset" in relation to the reference "outside the asset containing."  Specifically, it is not clear whether the term "asset" is meant to talk to individual BES Elements (i.e. a specific transformer, circuit breaker, etc.) or whether entities are given the latitude to define the boundaries of assets (i.e. could be based on defined physical boundaries of a broader transmission or generation station or a Control Centre).   Recommend providing specific drawing examples similar  to the models provided under the CIP-003-8 standard to help visualize through practical  network architecture to characterize what would constitute ERC under this new proposed definition.

BC Hydro, Segment(s) 3, 5, 1, 12/18/2018

- 0 - 0

SDG&E supports EEI Comments 

Bridget Silvia, Sempra - San Diego Gas and Electric, 3, 8/31/2021

- 0 - 0

MEAG Power adopts the Southern Company comments.

MEAG Power, Segment(s) 3, 1, 5, 6/15/2017

- 0 - 0

We support NPCC TFIST's comments as found below:

We understand that “outside the asset containing” is a scoping mechanism.

Request clarification. This new language creates an implicit requirement that the trust boundary is now at the asset not the ESP. Did the SDT intend this implicit requirement?

We are confused by the proposed change. We do not understand the trust boundary change from ESP to asset. Request clarification of demarcation. Where is the electronic boundary? Where is the physical boundary?

Given this update, we believe the Medium Impact boundary is not as well defined as the Low Impact boundary. ERC means external to what?

Gerry Adamski, Cogentrix Energy Power Management, LLC, 5, 8/31/2021

- 0 - 0

The modification to the definition to ERC brings serially connected OT Devices using a protocol-converter into scope for multiple CIP-007 requirements. In some instances, compliance with all CIP-007 requirements would be impossible. The use of a protocol converter does not facilitate centralized logging, review, and alarming (based on events). It simply facilitates data acquisition and IRA to these devices. We suggest not revising the definition of ERC, leaving the concept of a protocol break in place and require the protocol converter to either be categorized as a BCA, PCA or EACMS (depending on the circumstance). The serial OT device could still utilize the proposed definition for IRA to be in scope for CIP-005.

FE Voter, Segment(s) 1, 3, 5, 6, 4, 2/23/2021

- 0 - 0

OKGE supports EEI's comments. 

OKGE, Segment(s) 6, 1, 3, 5, 3/22/2021

- 0 - 0

Anthony Jablonski, ReliabilityFirst , 10, 8/31/2021

- 0 - 0

The proposed change to the ERC definition expands scope by making the boundary physical “asset” from the original electronic concept.  ERC could happen within a room where two systems have discrete ESPs that communicate between each other.  

Change the ability to “access” to “communicate to” to bring the connectivity rationale into the term.

Suggested definition - The ability to communicate to a BES Cyber System from a Cyber Asset that is outside of its associated Electronic Security Perimeter via a bi-directional routable protocol connection.

Darnez Gresham, Berkshire Hathaway Energy - MidAmerican Energy Co., 3, 8/31/2021

- 0 - 0

See MidAmerican Energy Company comments from Darnez Gresham.

Terry Harbour, Berkshire Hathaway Energy - MidAmerican Energy Co., 1, 8/31/2021

- 0 - 0

Cleco supports comments submitted by EEI.

Clay Walker, On Behalf of: Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6

- 0 - 0

In support of NPCC RSC comments.

We understand that “outside the asset containing” is a scoping mechanism.

Request clarification. This new language creates an implicit requirement that the trust boundary is now at the asset not the ESP. Did the SDT intend this implicit requirement?

We are confused by the proposed change. We do not understand the trust boundary change from ESP to asset. Request clarification of demarcation. Where is the electronic boundary? Where is the physical boundary?

Given this update, we believe the Medium Impact boundary is not as well defined as the Low Impact boundary. ERC means external to what?

 

The overall definition of ERC is  

The ability to communicate to a CIP System using a bi-directional routable protocol from outside the asset containing the CIP System. 

(The definition of CIP System is included for precision)  

The ability to communicate to a CIP System (A Cyber System identified by the Responsible Entity as a BES Cyber System, Electronic Access Control or Monitoring System, Physical Access Control System, Shared Cyber Infrastructure, Protected Cyber Asset, or Transient Cyber Asset.) using a bi-directional routable protocol from outside the asset containing the CIP System (A Cyber System identified by the Responsible Entity as a BES Cyber System, Electronic Access Control or Monitoring System, Physical Access Control System, Shared Cyber Infrastructure, Protected Cyber Asset, or Transient Cyber Asset.). 

We don’t see the added value of this “scoping” for CIP-007 R4, CIP-004, CIP-006. This definition includes additional asset types (EACMS, PACS, SCI, PCA, TCA) to the concept of ERC. One could think that future requirements could come forward, like for EACMS with ERC or even TCA with ERC, but it’s not the case.  

In reference to CIP-007 R4, the text used is the following 

Medium Impact BCS with External Routable Connectivity and their associated: 

1. EACMS;

2. PACS; and 

3. PCA 

SCI identified independently supporting an Applicable System above 

The ERC trigger is still based on the BCS.   

If the understanding of asset (“the asset containing “) is equivalent to the following … i. Control Centers and backup Control Centers; ii. Transmission stations and substations; iii. Generation resources; iv. Systems and facilities critical to system restoration, including Blackstart Resources and Cranking Paths and initial switching requirements; v. RAS that support the reliable operation of the Bulk Electric System; and vi. For Distribution Providers, Protection Systems specified in Applicability section 4.2.1 above… the suggested definition is interesting.  

Our comprehension is that if we have two HIGH/Medium-Impact BCS in the same Control Center (asset) using a bi-directional routable protocol to establish their communication and that any of those BCS doesn’t use a bi-directional routable protocol outside of the Control Center, the ERC definition wouldn’t be applied. Furthermore, if any of those two BCS would be using a bi-directional routable protocol outside of the asset of both BCS would be tagged as being ERC. 

We suggest the removal of CIP System in the definition. 

Nicolas Turcotte, Hydro-Qu?bec TransEnergie, 1, 9/1/2021

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Daniel Gacek, Exelon, 1, 9/1/2021

- 0 - 0

AEP does not support the proposed changes to the External Routable Connectivity (ERC) definition and is in support of EEI’s comments. The new definition for ERC expands the scope by (1) replacing the defined term “BES Cyber System (BCS)” with a proposed new term “CIP System”, and (2) changing “the ability to access …” to “the ability to communicate to …”. In addition, AEP seeks additional clarification on “asset containing the CIP System”. The term “asset” could be interpreted in many ways and could be a point of contention if an entity identified an “asset” at a fence line where an auditor may have a different opinion on where that line of demarcation for an “asset” might be drawn.

JT Kuehne, AEP, 6, 9/1/2021

- 0 - 0

Jamie Monette, On Behalf of: Allete - Minnesota Power, Inc., , Segments 1

- 0 - 0

We understand that “outside the asset containing” is a scoping mechanism.

Request clarification. This new language creates an implicit requirement that the trust boundary is now at the asset not the ESP. Did the SDT intend this implicit requirement?

We are confused by the proposed change. We do not understand the trust boundary change from ESP to asset. Request clarification of demarcation. Where is the electronic boundary? Where is the physical boundary?

Given this update, we believe the Medium Impact boundary is not as well defined as the Low Impact boundary. ERC means external to what?

 

The overall definition of ERC is  

The ability to communicate to a CIP System using a bi-directional routable protocol from outside the asset containing the CIP System. 

(The definition of CIP System is included for precision)  

The ability to communicate to a CIP System (A Cyber System identified by the Responsible Entity as a BES Cyber System, Electronic Access Control or Monitoring System, Physical Access Control System, Shared Cyber Infrastructure, Protected Cyber Asset, or Transient Cyber Asset.) using a bi-directional routable protocol from outside the asset containing the CIP System (A Cyber System identified by the Responsible Entity as a BES Cyber System, Electronic Access Control or Monitoring System, Physical Access Control System, Shared Cyber Infrastructure, Protected Cyber Asset, or Transient Cyber Asset.). 

We don’t see the added value of this “scoping” for CIP-007 R4, CIP-004, CIP-006. This definition includes additional asset types (EACMS, PACS, SCI, PCA, TCA) to the concept of ERC. One could think that future requirements could come forward, like for EACMS with ERC or even TCA with ERC, but it’s not the case.  

In reference to CIP-007 R4, the text used is the following 

Medium Impact BCS with External Routable Connectivity and their associated: 

1. EACMS;

2. PACS; and 

3. PCA 

SCI identified independently supporting an Applicable System above 

The ERC trigger is still based on the BCS.   

If the understanding of asset (“the asset containing “) is equivalent to the following … i. Control Centers and backup Control Centers; ii. Transmission stations and substations; iii. Generation resources; iv. Systems and facilities critical to system restoration, including Blackstart Resources and Cranking Paths and initial switching requirements; v. RAS that support the reliable operation of the Bulk Electric System; and vi. For Distribution Providers, Protection Systems specified in Applicability section 4.2.1 above… the suggested definition is interesting.  

Our comprehension is that if we have two HIGH/Medium-Impact BCS in the same Control Center (asset) using a bi-directional routable protocol to establish their communication and that any of those BCS doesn’t use a bi-directional routable protocol outside of the Control Center, the ERC definition wouldn’t be applied. Furthermore, if any of those two BCS would be using a bi-directional routable protocol outside of the asset of both BCS would be tagged as being ERC. 

We suggest the removal of CIP System in the definition. 

Leonard Kula, Independent Electricity System Operator, 2, 9/1/2021

- 0 - 0

We disagree to modifying ERC definition. Given that the ESP is still effective and the language BCS with ERC and IRA are still used by STD in the revised requirements, ERC should be still ESP and BCS based rather than asset based. If using the physical boundary to identify ERC, it is hard to decide which BCS with ERC and which BCS without ERC, which would cause ERC identification issues and various interpretations. Also the asset boundary will cause the security risk since the highwater marking wouldn’t apply within a physical boundary.  Furthermore, physical boundary would cause audit issue since it is not a defined term. For instance, whether a generating station power house and its switchyard are treated as the same asset or separate asset will get the different results. In addition, the proposed ERC definition overreaches the goal of SAR since the revised ERC refers to CIP System which includes all types of CIP cyber assets. The SRA doesn’t require entities to identify ERC for EACMS, PACS, and TCA that are outside ESP.

Recommendation: Restore the current ERC definition since it still fits the revised requirements.

MRO NSRF, Segment(s) 2, 4, 1, 6, 3, 5, 7/1/2021

- 0 - 0

Amy Jones, Public Utility District No. 2 of Grant County, Washington, 5, 9/1/2021

- 0 - 0

Evergy incorporates by reference and endorses the comments as filed by the Edison Electric Institute.

Alan Kloster, On Behalf of: Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Kinte Whitehead, Exelon, 3, 9/1/2021

- 0 - 0

As long as ERC is not used instead of IRA. PNMR supports EEIs suggested definition of ERC.

Amy Bratkovic, On Behalf of: PNM Resources - Public Service Company of New Mexico, , Segments 1, 3

- 0 - 0

The proposed change to the ERC definition expands scope by making the boundary physical “asset” from the original electronic concept.  ERC could happen within a room where two systems have discrete ESPs that communicate between each other.  

Change the ability to “access” to “communicate to” to bring the connectivity rationale into the term.

Suggested definition - The ability to communicate to a BES Cyber System from a Cyber Asset that is outside of its associated Electronic Security Perimeter via a bi-directional routable protocol connection.

Dwanique Spiller, On Behalf of: Berkshire Hathaway - NV Energy - WECC - Segments 5

- 0 - 0

ISO-NE does not have MEDIUM impact BCS cases and thus no cases for which the ERC definition would affect scope for requirements.

John Galloway, On Behalf of: Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2

- 0 - 0

Tacoma Power, Segment(s) 1, 3, 4, 5, 6, 3/9/2021

- 0 - 0

GRE agrees with the comments submitted by the NSRF. 

Michael Brytowski, Great River Energy, 3, 9/1/2021

- 0 - 0

In support of IRC SRC/SWG.

We understand that “outside the asset containing” is a scoping mechanism.

Request clarification. This new language creates an implicit requirement that the trust boundary is now at the asset not the ESP. Did the SDT intend this implicit requirement?

We are confused by the proposed change. We do not understand the trust boundary change from ESP to asset. Request clarification of demarcation. Where is the electronic boundary? Where is the physical boundary?

Given this update, we believe the Medium Impact boundary is not as well defined as the Low Impact boundary. ERC means external to what?

Monika Montez, On Behalf of: California ISO, WECC, Segments 2

- 0 - 0

Nurul Abser, NB Power Corporation, 1, 9/1/2021

- 0 - 0

Agree with change to ERC definition.

Donna Wood, Tri-State G and T Association, Inc., 1, 9/1/2021

- 0 - 0

The proposed change to the ERC definition expands scope by making the boundary physical “asset” from the original electronic concept.  ERC could happen within a room where two systems have discrete ESPs that communicate with each other.  

Change the ability to “access” to “communicate to” to bring the connectivity rationale into the term.

Suggested definition - The ability to communicate to a BES Cyber System from a Cyber Asset that is outside of its associated Electronic Security Perimeter via a bi-directional routable protocol connection.

Casey Jones, On Behalf of: Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5

- 0 - 0

Israel Perez, On Behalf of: Salt River Project, WECC, Segments 1, 3, 5, 6

- 0 - 0

We support EEI's comments on this question.

David Jendras, Ameren - Ameren Services, 3, 9/1/2021

- 0 - 0

Because the term and concept of ESP remains effective and the BCS language of ERC and IRA are used by STD in the revised requirements, ERC should remain ESP and BCS based rather than asset based. It is difficult to determine which BCS with ERC and which BCS without ERC would apply with the proposed language.

The asset boundary will cause a security risk since the highwater marking wouldn’t apply within a physical boundary.  Furthermore, physical boundary would cause audit issue since it is not a defined term. For instance, whether a generating station power house and its switchyard are treated as the same asset or separate asset will get the different results. In addition, the proposed ERC definition overreaches the goal of SAR since the revised ERC refers to CIP System which includes all types of CIP cyber assets. The SRA doesn’t require entities to identify ERC for EACMS, PACS, and TCA that are outside ESP.

Recommendation: Restore the current ERC definition since it still fits the revised requirements.

Barry Jones, On Behalf of: sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6

- 0 - 0

While GSOC agrees with the intent of the change, it cannot support the proposed change as use of the generic term “asset” could cause confusion and inconsistency regarding the meaning of the term “asset” and its use across the body of standards.  As an example, asset is utilized in CIP-002 and is meant to convey a physical facility or building.  The generic use of “asset” within the new definition of ERC could, therefore, also be construed as referring to the physical building or facility in which a system is located, which is likely not the intended or only meaning.  To reduce the potential for confusion, GSOC recommends that clarification be added to the definition of ‘ERC’ to ensure that the full intent and meaning of the term “asset” as used within the definition of ERC is clear and easily, consistently understood. 

Benjamin Winslett, Georgia System Operations Corporation, 4, 9/1/2021

- 0 - 0

  • The proposed change for ERC is confusing, including March and August discussions with the SDT during outreach, for when a CIP System that serial converts RS-232 or RS-485 may extend ERC beyond the ESP to medium impact BCAs, PCAs and Non-CIP Cyber Asset. We do not understand the trust boundary change from ESP to asset. Request clarification of demarcation.

    • Where is the electronic boundary and how does it apply when not routable?

    • Where is the physical boundary when serial extends out of the substation to field devices?

    • When does ERC apply to a CIP System that is connected serially that was previously consider non-routable before the new proposed updates from Project 2016-02 SDT?

      • Please clarify the language that extends applicability to a CIP System using serial communication within the asset/site?

    • If the serial link can change the configuration of a BCA is the SDT intending Entities now have a BCA with ERC when previously the demarcation was the serial link?

  • Please clarify how ERC is applied to standards when an SCI EACMS in a Medium Impact substation that provides conversion of ERC to serial for remote configuration support of RTU and Relays rated as Medium BCA along with Relays that are Low Impact BCA and Non-CIP System Relays how ERC is being applied when using serial communication has the proposed standard requirements intended that PSP and 15 month password changes now apply?

  • Will applicability today for BCA with ERC apply going forward with the new proposed definitions and requirements to a BCS Medium Impact Relay connected serially that is being managed through RS-232? 

  • Does a Non-CIP System distribution Relay now become a PCA because it is connected to the Medium Impact Serial converter? 

  • The SDT ERC changes appears to be impacting the BROS process may require improved language in CIP-002 Attachment 1 as it cascades into other standards applicability requiring clarification:

    • CIP-002 R1 and R2 - Would Entities now need to identify BCA’s that are serially connected and update CIP-002 BCS List to show these now as part of either SCADA or Protection with ERC? 

    • CIP-004 R4.3 – Would electronic access to devices with ERC now be an entitlement to be mapped all serially connected devices requiring and role authorization?

    • CIP-005 R1.1 – Does the SDT expect that the ESP diagrams to now show serially connected devices within the substation house PSP and cables external out of the PSP to the devices in the structure including Transformers, CAP Banks, etc?

    • CIP-006 R1.2, 1.4, 1.7, 1.8, 1.9, 2.2, 2.3, 3.1 – Does the SDT intend that devices without ERC currently are outside a PSP (allowed by CIP-006 R1.1) will now with the proposed changes require the establishment of a PSP, with control, alerting, response, logging, visitor escort and system testing for serially connected IED in transformer cabinet for temperature monitoring, metering devices or other IEDs outside of the Station House PSP?

    • CIP-007 R1 – Please confirm the P1.1 Logical ports justification and details for serially connected CIP Systems are excluded but expectation of the physical wiring will be required for P1.2?  

    • CIP-007 R4.2 – Please clarify the serial CIP System must now alert for failure of event logging.

    • CIP-007 R5.6 – Please clarify a serial CIP System such as an RTU or Relay that was a BCA or PCA without ERC now with the proposed change requires the password change every 15 months?

    • CIP-010 R1.1.4 – How will an Entity meet the baseline requirement for logical port open on each serially connected device or can a by device capability exclusion apply?

    • CIP-010 R1.2, 3, 4 – Do the proposed update require all the change management sub-requirements apply when a device is serially connected/disconnected to a network or moved within a network while still a serial device?

    • CIP-010 R3 – Please confirm the annual CVA including network discovery will require serial communication assessments throughout the site/facility/asset?

Justin Welty, NextEra Energy - Florida Power and Light Co., 6, 9/1/2021

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Cynthia Lee, Exelon, 5, 9/1/2021

- 0 - 0

OPG concurs with NPCC's RSC comments

David Kwan, On Behalf of: Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Becky Webb, Exelon, 6, 9/1/2021

- 0 - 0

ACES does not agree with the reference “outside the asset containing” as a scoping mechanism for CIP-007 R4.  We do not understand the correlation of ERC to CIP-007 logging or CIP-004 and CIP-006 risks.  Using the “asset” as a scoping mechanism could lead to various interpretations and allow for loop holes for access.  In our opinion, “outside the asset containing” is not necessary to define ERC.  We feel ESP is still the proper scoping mechanism.

ACES Standard Collaborations, Segment(s) 1, 9/1/2021

- 0 - 0

Eversource recommends clarification regarding what "outside the asset containing" is clarifying.

Eversource 1, Segment(s) 3, 1, 9/1/2021

- 0 - 0

Karie Barczak, DTE Energy - Detroit Edison Company, 3, 9/1/2021

- 0 - 0

LCRA is concerned with bringing serial devices into scope as part of ‘Applicable System with ERC’. This would require the serial relays to comply with additional CIP requirements. Expanding the scope of ERC to serial-based devices could significantly increase implementation cost and require new tools/products to help with ensuring compliance. The changes needed to enforce Physical Security requirement CIP-006 R1.2 will require long lead times to implement especially for shared control houses.

James Baldwin, Lower Colorado River Authority, 1, 9/1/2021

- 0 - 0

Yes, we argree with the proposed change because the language “through an EACMS controlling communications...” allows non‐perimeter‐based models of ERC including zero-trust.

Maggy Powell, Amazon Web Services, 7, 9/1/2021

- 0 - 0

Southern agrees with the concept but does not agree with the proposed language. “Asset” should be better defined as it is too ambiguous and many requirements’ scoping is based on clarity around ERC.  Additionally, ERC has changed from being defined in terms of a BCS to a ‘CIP System’ which includes all named types of devices.  If a BCS inside an “asset” is isolated, however there is a docked TCA on another network inside the 'asset', does the BCS inherit ERC because a “CIP System” can be accessed in the asset?  As the boundary broadens and the target is any CIP System, it has lost focus on the ability to externally communicate with a BCS.  Southern suggests that ERC be defined in terms of the BCS, not the overly broad “CIP System”.

Southern Company, Segment(s) 1, 3, 6, 5, 1/14/2021

- 0 - 0

LCRA is concerned with bringing serial devices into scope as part of ‘Applicable System with ERC’. This would require the serial relays to comply with additional CIP requirements. Expanding the scope of ERC to serial-based devices could significantly increase implementation cost and require new tools/products to help with ensuring compliance. The changes needed to enforce Physical Security requirement CIP-006 R1.2 will require long lead times to implement especially for shared control houses.

LCRA Compliance, Segment(s) 6, 5, 1, 5/11/2015

- 0 - 0

ERCOT supports the IRC SRC comments and offers this additional comment:

  • The proposed modification greatly expands the scope of the definition. “Asset” has historically referred to things like transmission, generation, etc. Before, ERC was limited to just BES Cyber System. Why is this needed with assets and systems that reside outside of an ESP? The definition also needs to accommodate technologies that do not use a routable protocol.

Brandon Gleason, 9/1/2021

- 0 - 0

LeRoy Patterson, Public Utility District No. 2 of Grant County, Washington, 6, 9/1/2021

- 0 - 0

<duplicate>

Dana Showalter, On Behalf of: Electric Reliability Council of Texas, Inc., Texas RE, Segments 2

- 0 - 0

EEI does not support the proposed change to the ERC definition because it expands the current definition by replacing the defined term BES Cyber System (BCS) with newly defined term “CIP System” and by changing from “... to access …” to “… to communicate …”. “Access” means the ability to make use of information (see NIST definition of access - https://csrc.nist.gov/glossary/term/access), while the term communicate has a much broader meaning and could be interpreted to mean that the act or ability to ping a device is now in scope.   

Additionally, the use of the term “asset” within the context of the ERC definition raises potential compliance ambiguity and lack of uniformity that could result in different interpretations during an audit.  To address these concerns, we offer the following:

The ability to access a BCS using a bidirectional routable protocol from outside the ESP that controls access to the BCS.

Mark Gray, On Behalf of: Edison Electric Institute, NA - Not Applicable, Segments NA - Not Applicable

- 0 - 0

This is a substantial change to the definition of ERC that has a larger impact than in the context of addressing virtualized environments.

This is a large change to bring into scope assets that are protected by the ESPs in the past but did not have to meet ERC requirement since this connection did not enable IRA.

Gail Golden, Entergy - Entergy Services, Inc., 5, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

Alyssia Rhoads, Public Utility District No. 1 of Snohomish County, 1, 9/1/2021

- 0 - 0

 

PJM signs on to the comments provided by the IRC SRC.

Elizabeth Davis, On Behalf of: Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2

- 0 - 0

The proposed change to the ERC definition expands scope by making the boundary physical “asset” from the original electronic concept.  ERC could happen within a room where two systems have discrete ESPs that communicate between each other.  

Change the ability to “access” to “communicate to” to bring the connectivity rationale into the term.

Suggested definition - The ability to communicate to a BES Cyber System from a Cyber Asset that is outside of its associated Electronic Security Perimeter via a bi-directional routable protocol connection.

Lindsay Wickizer, Berkshire Hathaway - PacifiCorp, 6, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

Sam Nietfeld, Public Utility District No. 1 of Snohomish County, 5, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

SNPD Voting Members, Segment(s) 4, 6, 5, 1, 6/18/2020

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

John Martinsen, Public Utility District No. 1 of Snohomish County, 4, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

John Liang, Snohomish County PUD No. 1, 6, 9/1/2021

- 0 - 0

We understand that “outside the asset containing” is a scoping mechanism.

Request clarification. This new language creates an implicit requirement that the trust boundary is now at the asset not the ESP. Did the SDT intend this implicit requirement?

We are confused by the proposed change. We do not understand the trust boundary change from ESP to asset. Request clarification of demarcation. Where is the electronic boundary? Where is the physical boundary?

Given this update, we believe the Medium Impact boundary is not as well defined as the Low Impact boundary. ERC means external to what?

 

The overall definition of ERC is  

The ability to communicate to a CIP System using a bi-directional routable protocol from outside the asset containing the CIP System. 

(The definition of CIP System is included for precision)  

The ability to communicate to a CIP System (A Cyber System identified by the Responsible Entity as a BES Cyber System, Electronic Access Control or Monitoring System, Physical Access Control System, Shared Cyber Infrastructure, Protected Cyber Asset, or Transient Cyber Asset.) using a bi-directional routable protocol from outside the asset containing the CIP System (A Cyber System identified by the Responsible Entity as a BES Cyber System, Electronic Access Control or Monitoring System, Physical Access Control System, Shared Cyber Infrastructure, Protected Cyber Asset, or Transient Cyber Asset.). 

We don’t see the added value of this “scoping” for CIP-007 R4, CIP-004, CIP-006. This definition includes additional asset types (EACMS, PACS, SCI, PCA, TCA) to the concept of ERC. One could think that future requirements could come forward, like for EACMS with ERC or even TCA with ERC, but it’s not the case.  

In reference to CIP-007 R4, the text used is the following 

Medium Impact BCS with External Routable Connectivity and their associated: 

1. EACMS;

2. PACS; and 

3. PCA 

SCI identified independently supporting an Applicable System above 

The ERC trigger is still based on the BCS.   

If the understanding of asset (“the asset containing “) is equivalent to the following … i. Control Centers and backup Control Centers; ii. Transmission stations and substations; iii. Generation resources; iv. Systems and facilities critical to system restoration, including Blackstart Resources and Cranking Paths and initial switching requirements; v. RAS that support the reliable operation of the Bulk Electric System; and vi. For Distribution Providers, Protection Systems specified in Applicability section 4.2.1 above… the suggested definition is interesting.  

Our comprehension is that if we have two HIGH/Medium-Impact BCS in the same Control Center (asset) using a bi-directional routable protocol to establish their communication and that any of those BCS doesn’t use a bi-directional routable protocol outside of the Control Center, the ERC definition wouldn’t be applied. Furthermore, if any of those two BCS would be using a bi-directional routable protocol outside of the asset of both BCS would be tagged as being ERC. 

We suggest the removal of CIP System in the definition. 

NPCC Regional Standards Committee, Segment(s) 10, 2, 4, 7, 3, 1, 5, 6, 8/6/2021

- 0 - 0

Portland General Electric Company supports the comments provided by EEI for this survey question.

Ryan Olson, Portland General Electric Co., 5, 9/1/2021

- 0 - 0

N&ST assumes this proposed revision is intended to bring into scope remote connections to serially-connected CIP Systems that traverse wide-area connections via TCP/IP before being converted, “locally,” to serial. However, as written, it would exclude end-to-end routable connections from non-CIP Systems to CIP Systems established within a given asset (example: TCP/IP connection from a PC on corporate network to a CIP server in the same building behind an ESP on a CIP network). One loophole closed, another opened.


N&ST believes the SDT should be able to address this problem by expanding the definition of ERC using an “either/or” format. ERC is either:

“The ability to access a BES Cyber System from a Cyber Asset that is outside of its associated ESP via a bi‐directional routable protocol connection; or
“The ability to communicate to a serially-connected CIP System using a bi‐directional routable protocol from outside the asset containing the CIP System.”

Roger Fradenburgh, On Behalf of: Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1

- 0 - 0

The IRC SRC understands “outside the asset containing” to be a scoping mechanism.

Request clarification. This new language creates an implicit requirement that the trust boundary is now at the asset and not the ESP. Is this understanding correct?

The IRC SRC is confused by the proposed change. We do not understand the trust boundary change from ESP to asset. Request clarification of demarcation. Where is the electronic boundary? Where is the physical boundary?

Given this update, we believe the Medium Impact boundary is not as well defined as the Low Impact boundary. External Routable Connectivity (ERC) now means external to what?

ISO/RTO Council Standards Review Committee 2016-02 Virtualization (Draft 2), Segment(s) 2, 9/1/2021

- 0 - 0

ATC supports the SDT’s intentions, however the proposed draft language is still somewhat unclear. For those reasons, ATC requests consideration of clearer language and perhaps supporting diagrams. One example of a question we’ve asked ourselves was: If you connect from a router (EACMS) to talk to a switch would that be ERC? Also, If my Control Center “asset” has several rooms and various subnets, and some devices are on a non-BCS subnet but still physically inside the “asset” containing the BCS, shouldn’t a routable connection from that device to a BCA be considered ERC?

LaTroy Brumfield, American Transmission Company, LLC, 1, 9/1/2021

- 0 - 0

ITC supports the response submitted by EEI for this question.

Gail Elliott, On Behalf of: Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1

- 0 - 0

Hot Answers

Dan Zollner, Portland General Electric Co., 3, 9/1/2021

- 0 - 0

PGE FCD, Segment(s) 5, 1, 3, 6, 9/11/2018

- 0 - 0

Other Answers

Richard Jackson, U.S. Bureau of Reclamation, 1, 8/19/2021

- 0 - 0

Dominion, Segment(s) 3, 5, 1, 9/19/2019

- 0 - 0

Jeanne Kurzynowski, On Behalf of: CMS Energy - Consumers Energy Company - RF - Segments 3, 4, 5

- 0 - 0

Chelan agrees with the proposed definition changes for ESP.

CHPD, Segment(s) 3, 1, 6, 5, 8/24/2021

- 0 - 0

Glen Farmer, Avista - Avista Corporation, 5, 8/24/2021

- 0 - 0

The proposed change to the ESP definition adds a significant amount of ambiguity.  Within the context of the new definition, the term “Electronic Security Perimeter” doesn’t seem to apply.  ESP references a “perimeter” and the definition doesn’t indicate a logical perimeter of any sort.  If anything, the definition essentially becomes synonymous only with the policies or rulesets mandated by a firewall.  NRG recommends reverting the ESP term back to its original definition.   

Martin Sidor, NRG - NRG Energy, Inc., 6, 8/24/2021

- 0 - 0

The proposed change to the ESP definition adds a significant amount of ambiguity.  Within the context of the new definition, the term “Electronic Security Perimeter” doesn’t seem to apply.  ESP references a “perimeter” and the definition doesn’t indicate a logical perimeter of any sort.  If anything, the definition essentially becomes synonymous only with the policies or rulesets mandated by a firewall.  NRG recommends reverting the ESP term back to its original definition.  

Patricia Lynch, NRG - NRG Energy, Inc., 5, 8/24/2021

- 0 - 0

While the term ESP was restored, the definition shifted to a logical format much like ACLs while referencing the physical ESP with the definition of IRA  Suggest clarify definition of ESP and IRA.

Tennessee Valley Authority, Segment(s) 1, 3, 5, 6, 10/18/2018

- 0 - 0

Xcel Energy supports the comments of EEI.

Amy Casuscelli, On Behalf of: Xcel Energy, Inc. - MRO, WECC - Segments 1, 3, 5, 6

- 0 - 0

BPA agrees that the modified definition is more flexible for future ESPs using a zero trust environment. However, additional language is needed to address whether the SDT still intends for standalone networks that have no external connectivity to other networks (”standalone networks”) to have a defined ESP.

Option 1: If standalone networks DO NOT require an ESP, please update the Technical Rationale to address standalone networks (as was traditionally done in the TR for CIP-005-6 and CIP-005-7).

Option 2: If standalone networks DO still require an ESP, the proposed definition requires all ESPs to be “enforced by an EACMS;” this will add a high burden for standalone networks.  For example, a standalone ESP consisting of a local operator HMI (PCA, used for local review of SCADA alarms) connected to 2 local SCADA RTUs (BCAs) via a switch (PCA) would need to have an EACMS added in order to meet the letter of the requirement, but without gaining any security or protection.

Option 2 proposed language: move the “enforced by an EACMS” from the definition of an ESP, to a new requirement for BCS with ERC:

(1)  Definition for Electronic Security Perimeter (ESP): A set of configurations or policies that controls communications to or from any part of a BES Cyber System. These configurations or policies group CIP Systems of the same impact rating and their associated PCAs.

Benefit: This would permit the isolated nature – or “configuration” – of the small local network to provide the control of communications to/from the BES Cyber System by simply excluding it.

(2) Add an additional requirement under CIP-005-8 R1.1 [hypothetically referenced here as R “1.1-A” for numbering clarity]  for the EACMS portion:

Requirement: 1.1-A

Applicable Systems: BCS with ERC and their associated PCA Requirements: Utilize an EACMS to enforce the control of communications to or from any part of a BES Cyber System.

(3) Related update is needed to correct the Applicable Systems in R2.1: “EACMS that enforces an ESP for the Applicable Systems in Part 1.1-A.”

(4) Update the Technical Rationale (TR) to clarify for standalone networks (as was traditionally done in the TR for CIP-005-6 and CIP-005-7).

Andrea Jessup, On Behalf of: Bonneville Power Administration, WECC, Segments 1, 3, 5, 6

- 0 - 0

Mike Magruder, Avista - Avista Corporation, 1, 8/26/2021

- 0 - 0

Duke Energy agrees with the directional change but has identified several concerns with the proposed language. 

First, the use of CIP Systems in the definition is in conflict with the use of BES Cyber System as the initial scoping in the definition, as it could be interpreted to require ESPs around EACMS and PACS that are outside the traditional ESP boundary on separate hardware.  Further, this introduces a redundancy between the CIP Systems and PCA definitions. 

Second, the use of the term policies is ambiguous in context and is likely to be conflicted with written policies (e.g. procedurally requiring password rotation).  Policy-based access control is configured into the enforcing system, and therefore is inherently included in the configuration term.  This should be made explicit in measures or guidance documents to ensure the intent to allow future policy-based access control is apparent. 

Third, the inclusion of qualifiers to address the host-based firewall concern in the requirement language is inappropriate as it addresses specific solutions.  A better means of addressing this concern would be to include qualifiers in the definition of ESP to ensure that the configurations enforcing the perimeter do not reside on a BES Cyber Asset.

DUKE ENERGY PROPOSED DEFINITION FOR ESP:

A set of configurations enforced by an EACMS that creates a logical boundary where communications to or from any part of a BES Cyber System and any PCA or SCIG associated with a BES Cyber System are controlled.  All BCS, PCA, and SCIG included in an ESP have the same impact rating as the highest included device.  The EACMS enforcing the ESP may not be part of a BES Cyber System.

Katie Connor, On Behalf of: Duke Energy - SERC, RF - Segments 1, 3, 5, 6

- 0 - 0

AECI, Segment(s) 1, 3, 6, 5, 3/4/2021

- 1 - 0

See MRO-NSRF and EEI Comments

Clarice Zellmer, WEC Energy Group, Inc., 5, 8/26/2021

- 0 - 0

We agree that the proposed ESP definition can be used for both traditional firewall based networks, as well as future networks such as zero trust. However, the routable protocol qualifier was removed and the new ESP qualifier is an EACMS. The EACMS definition does not have a routable protocol/communication qualifier, and it references ESPs. This seems like a circular definition. Also, it is our understanding that the SDT does not intend to have requirements baked into definitions but with the proposed ESP definition, and changes to CIP-005, the definition is the only place EACMS are required. We propose the following changes:

ESP definition: A set of configurations or policies that controls communications to or from any part of a BES Cyber System. These configurations or policies group CIP Systems of the same impact rating and their associated PCAs.

New CIP-005-X R1 Part 1.X:

Applicable Systems

High Impact BES Cyber Systems and their associated PCA

Medium Impact BES Cyber Systems and their associated PCA

Requirements

1.X.1 - EACMSs must be implemented to enforce ESPs where communication leaves the ESP, or where SCI is used.

1.X.2 - EAPs must be identified for ESPs.

When the proposed ESP definition is applied in the proposed CIP-005-X R1 Part 1.1 there is another issue since the definition no longer has the routable protocol qualifier. See our response to Question #10 below for further explanation.

Ronald Bender, Nebraska Public Power District, 5, 8/27/2021

- 0 - 0

While we do not believe it to be the intent of the SDT, we disagree with the new definition(s) of EACMS and ESP as it is less clear what is and is not considered an ESP. Currently, a substation facility BCS that is not utilizing routable protocols, such as an RTU serially connected to several relays, is not classified as an ESP and subsequently, the RTU (which could be used as a central access point to the relays) would not be classified as an EACMS. This clarity is lost with the proposed definition changes.

Recommendation:

Electronic Security Perimeter (ESP) – The logical border surrounding a network to which BES Cyber Systems are connected using a routable protocol; or

A set of configurations or policies enforced by an EACMS that controls routable communications to or from any part of a BES Cyber System. These configurations or policies group CIP Systems of the same impact rating and their associated PCAs.

Electronic Access Control or Monitoring Systems (EACMS) – Cyber Assets, Virtual Cyber Assets, or Shared Cyber Infrastructure (SCI) that perform electronic access control or electronic access monitoring via routable protocols of the Electronic Security Perimeter(s) or BES Cyber Systems or SCI. This includes Intermediate Systems and SCI grouped by the Responsible Entity, in the EACMS it supports.

Josh Johnson, Lincoln Electric System, 1, 8/27/2021

- 0 - 0

The first sentence alone in the ESP definition seems to be able to be used for both traditional firewall-based networks and future networks. The second sentence is confusing in that a CIP System would have an associated PCA when PCA is already part of the CIP System definition.

WECC CIP, Segment(s) 10, 2/17/2021

- 0 - 0

William Steiner, Midwest Reliability Organization, 10, 8/30/2021

- 0 - 0

AZPS agrees that the modified ESP definition can be used for both traditional and future networks.  However,  the inclusion of the phrase “and their associated PCAs” is redundant and unnecessary since CIP Systems include associated PCAs by definition.

Marcus Bortman, APS - Arizona Public Service Co., 6, 8/30/2021

- 0 - 0

There is no clear point of demarcation where the border of the ESP is defined, introducing significant concerns how the boundary of the CIP standard will be evaluated and enforced.  Recommend retaining current definition. While not necessary, it may be appropriate to clarify that additional controls may be implemented within the security perimeter to limit communication ports inside of requirement CIP-007 R1.1

Susan Sosbe, On Behalf of: Wabash Valley Power Association, , Segments 1, 3

- 0 - 0

Carl Pineault, Hydro-Qu?bec Production, 5, 8/30/2021

- 0 - 0

Jennifer Bray, Arizona Electric Power Cooperative, Inc., 1, 8/30/2021

- 0 - 0

Justin MacDonald, On Behalf of: Midwest Energy, Inc., , Segments 1

- 0 - 0

Steve Toosevich, NiSource - Northern Indiana Public Service Co., 1, 8/31/2021

- 0 - 0

The second sentence appears to be redundant due to the phrase “and their associated PCAs” since PCAs are included within the proposed “CIP System” definition.  CEHE proposes the following:

“A set of configurations or policies enforced by an EACMS that controls routable protocol communications to or from any part of a BES Cyber System and that groups CIP Systems of the same impact rating.”

Eli Rivera, On Behalf of: CenterPoint Energy Houston Electric, LLC, Texas RE, Segments NA - Not Applicable

- 0 - 0

Southwest Power Pool Standards Review Group (SSRG), Segment(s) 2, 9/4/2019

- 0 - 0

NCPA supports most of the definition change, however “policies” are a vague reference.  NCPA proposes using the phrase “technical policies” as to not confuse them with administrative policies.  

Chris Carnesi, On Behalf of: Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6

- 0 - 0

The second sentence appears to be redundant due to the phrase “and their associated PCAs” since PCAs are included within the proposed “CIP System” definition.  SIGE proposes the following:

“A set of configurations or policies enforced by an EACMS that controls routable protocol communications to or from any part of a BES Cyber System and that groups CIP Systems of the same impact rating.”

Brian Tooley, On Behalf of: Southern Indiana Gas and Electric Co., RF, Segments 3, 5, 6

- 0 - 0

New ESP definition would disallow including assets of lower impact ratings in a higher security environment, thus preventing the potential implementation of security best practices on Medium or Low impact assets.  The new definition of ESP would also prevent the use of VLANs as a method of demonstrating isolation of BCS and other Cyber Assets as the Switches involved with managing of VLANs are often classified as BCAs and under the current CIP standards an asset classified as a BCA cannot be classified also as an EACMS, PCA or PACS.

Joe Tarantino, On Behalf of: Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6

- 0 - 0

Texas RE agrees with the proposed definition of ESP.  The SDT could, however, consider revision it to the following for clarification:

  • A boundary of protection set by configurations or policies enforced by an EACMS that controls communications to or from any part of a BES Cyber System. These configurations or policies group CIP Systems of the same impact rating and their associated PCAs

 

Texas RE does note, however, that the proposed change to CIP-005 R1.1 explicitly states that host-based firewalls that only protect the host on which they reside are not a sufficient control to meet compliance with the requirement.  Mass deployment of host-based firewalls is one method by which an organization can work toward implementing a zero-trust security model.  The SDT may wish to consider this in the evaluation of its proposed ESP definition.

Rachel Coyne, Texas Reliability Entity, Inc., 10, 8/31/2021

- 0 - 0

The proposed change ignores the concept of an isolated ESP network and instead requires an EACMS be deployed regardless to control communications between BCS, PCAs within the same network.  The application of an EACMS in an isolated ESP network would add no extra protections or benefit for the purpose of controlling communications within the network given there are no Electronic Access Points applicable in relation to routable traffic from outside of the ESP or exiting the ESP. 

BC Hydro recommends clarifying that the EACMS requirement portion of the definition be applicable only in cases where ERC may exist (i.e. discrete ESPs or extended ESPs).

BC Hydro, Segment(s) 3, 5, 1, 12/18/2018

- 0 - 0

SDG&E supports EEI Comments 

Bridget Silvia, Sempra - San Diego Gas and Electric, 3, 8/31/2021

- 0 - 0

MEAG Power adopts the Southern Commany comments. 

MEAG Power, Segment(s) 3, 1, 5, 6/15/2017

- 0 - 0

We support NPCC TFIST's comments as found below:

We agree that the proposed change supports 1) traditional firewalls and 2) zero trust. However, the new language expands scope with “EACMS that controls communications to or from any part of a BES Cyber System.”

Gerry Adamski, Cogentrix Energy Power Management, LLC, 5, 8/31/2021

- 0 - 0

Although the revised definition allows for both traditional firewall-based networks as well as more modern protections, the definition remains incomplete.  We would suggest altering the definition as follows: “A logical boundary defined by a set of configurations or policies enforced by an EACMS that controls communications to or from any part of a BES Cyber System and that groups CIP Systems of the same or lower impact rating”

FE Voter, Segment(s) 1, 3, 5, 6, 4, 2/23/2021

- 0 - 0

OKGE supports EEI's comments. 

OKGE, Segment(s) 6, 1, 3, 5, 3/22/2021

- 0 - 0

Since the Glossary modifications are the foundation to all Standard changes, NERC should seek approval of the new terms prior to any changes being introduced in the Standards to reduce potential misunderstanding or misinterpretation of both the new definitions and modified Standards.  This will also allow NERC, and industry, time to determine additional courses of action, reduce confusion, and reduce additional risk associated with such wholesale changes.

Anthony Jablonski, ReliabilityFirst , 10, 8/31/2021

- 0 - 0

We suggest adding “routable protocol” to the revised definition.  We feel this can still be used for both types of networks.  We also suggest removing “CIP Systems,”and replace with “BES Cyber Systems.”  Remove “enforced by an EACMS.”

Suggested definition - A set of configurations or policies (Remove: enforced by an EACMS) that controls routable protocol communications to or from any part of a BES Cyber System. These configurations or policies group BES Cyber Systems of the same impact rating and their associated PCA.

Darnez Gresham, Berkshire Hathaway Energy - MidAmerican Energy Co., 3, 8/31/2021

- 0 - 0

See MidAmerican Energy Company comments from Darnez Gresham.

Terry Harbour, Berkshire Hathaway Energy - MidAmerican Energy Co., 1, 8/31/2021

- 0 - 0

Cleco supports comments submitted by EEI.

Clay Walker, On Behalf of: Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6

- 0 - 0

In support of NPCC RSC comments. 

We agree that the proposed change supports 1) traditional firewalls and 2) zero trust. However, the new language expands scope with “EACMS that controls communications to or from any part of a BES Cyber System.”

 

The new definition can be used for both traditional firewall-based networks, as well as future networks such as zero-trust but we don’t agree on the overall definition.  

The suggested definition broadens the current scope, it implies the presence of an EACMS, thus requesting another cyber asset (We have a BCA: VCA and we have an EACMS: Firewall) unless the SDT wanted to permit the double categorization (BCA/EACMS: a VCA with an embedded firewall) 

The language “that controls communications” isn’t consistent with the NERC CIP orientation, usage of the bi-directional routable protocol should be used because with the current language one could imply that serial, layer 2 communication needs to have a set of configurations or policies.  

Also, the definition states that this is for a BES Cyber System (…any part of a BES Cyber System…), yet the definition mention CIP System (… policies group CIP Systems of the same …). The definition of CIP System includes more than BES Cyber System. 

We suggest reviewing the definition.  

The proposal could be  

A set of configurations or policies enforced those controls bi-directional routable protocol communications to or from any part of a BES Cyber System. These configurations or policies group BES Cyber System of the same impact rating and their associated PCAs.  

Reference: A set of configurations or policies enforced by an EACMS that controls communications to or from any part of a BES Cyber System. These configurations or policies group CIP Systems of the same impact rating and their associated PCAs.

Nicolas Turcotte, Hydro-Qu?bec TransEnergie, 1, 9/1/2021

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Daniel Gacek, Exelon, 1, 9/1/2021

- 0 - 0

While AEP agrees that the modified Electronic Security Perimeter (ESP) definition can be used for both type of networks (i.e., traditional firewall based networks, as well as future networks such as zero trust), we recommend the second sentence be removed. The second sentence, “These configurations or policies group CIP Systems of the same impact rating and their associated PCAs”, seems to be an arbitrary statement that does not build upon the security requirement. A semantic argument could be made that once the configurations or policies are established, all CIP Systems inherit the highest water mark; however, prior to the establishment, the inherent risk of the associated CIP Systems could differ. We suggest removing the second sentence to avoid future confusive discussion.

JT Kuehne, AEP, 6, 9/1/2021

- 0 - 0

Jamie Monette, On Behalf of: Allete - Minnesota Power, Inc., , Segments 1

- 0 - 0

We agree that the proposed change supports 1) traditional firewalls and 2) zero trust. However, the new language expands scope with “EACMS that controls communications to or from any part of a BES Cyber System.”

 

The new definition can be used for both traditional firewall-based networks, as well as future networks such as zero-trust but we don’t agree on the overall definition.  

The suggested definition broadens the current scope, it implies the presence of an EACMS, thus requesting another cyber asset (We have a BCA: VCA and we have an EACMS: Firewall) unless the SDT wanted to permit the double categorization (BCA/EACMS: a VCA with an embedded firewall) 

The language “that controls communications” isn’t consistent with the NERC CIP orientation, usage of the bi-directional routable protocol should be used because with the current language one could imply that serial, layer 2 communication needs to have a set of configurations or policies.  

Also, the definition states that this is for a BES Cyber System (…any part of a BES Cyber System…), yet the definition mention CIP System (… policies group CIP Systems of the same …). The definition of CIP System includes more than BES Cyber System. 

We suggest reviewing the definition.  

The proposal could be  

A set of configurations or policies enforced those controls bi-directional routable protocol communications to or from any part of a BES Cyber System. These configurations or policies group BES Cyber System of the same impact rating and their associated PCAs.  

Reference: A set of configurations or policies enforced by an EACMS that controls communications to or from any part of a BES Cyber System. These configurations or policies group CIP Systems of the same impact rating and their associated PCAs.

Leonard Kula, Independent Electricity System Operator, 2, 9/1/2021

- 0 - 0

We disagree with the modified ESP definition as it cannot resolve the traditional firewall based network and the future networks. The virtualization zero trust topology is underneath the ESP network and is a non-ESP model. It is configured in the virtualization layer prior to VCAs reaching the ESP network. Also, IRA cannot be identified without ESP boundary being defined since IRA is initiated outside ESP. Furthermore, the SDT proposed ESP definition would include routable and non-routable BCAs in which it overreaches the goal of SAR. In our view, the EAP is still effective for the ESP model to control communications to and from BCS using routable protocol inside an ESP. We recommend adding an alternative requirement in CIP-005 R1.1 to address the zero-trust model in which the ESP model is not used rather than revising ESP definition. Our proposed changes won’t affect the existing ESP definition and ESP related requirements while still addressing virtualization to meet the goal of SAR.

Recommendations:

1.      Restore the current ESP definition since it is still effective for the perimeter-based routable network protection.

2.      We propose the following changes for CIP-005 R1.1:

a.      All applicable Cyber Assets connected to a network via a routable protocol shall reside within a defined ESP where all External Routable Connectivity must be through an identified EAP that permits only needed inbound and outbound access and denies all other access by default including the reason for granting access, or

b.      All BCAs connected to a network via a routable protocol shall through an EACMS that controls all communications to and from BCAs unless ESP model is used.

MRO NSRF, Segment(s) 2, 4, 1, 6, 3, 5, 7/1/2021

- 0 - 0

Amy Jones, Public Utility District No. 2 of Grant County, Washington, 5, 9/1/2021

- 0 - 0

Evergy incorporates by reference and endorses the comments as filed by the Edison Electric Institute.

Alan Kloster, On Behalf of: Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Kinte Whitehead, Exelon, 3, 9/1/2021

- 0 - 0

Suggest the following modification to the ESP definition:

“These configurations or policies protect a group of CIP Systems of the same impact rating and their associated PCAs.”

Amy Bratkovic, On Behalf of: PNM Resources - Public Service Company of New Mexico, , Segments 1, 3

- 0 - 0

We suggest adding “routable protocol” to the revised definition.  We feel this can still be used for both types of networks.  We also suggest removing “CIP Systems,”and replace with “BES Cyber Systems.”  Remove “enforced by an EACMS.”

Suggested definition - A set of configurations or policies enforced by an EACMS that controls routable protocol communications to or from any part of a BES Cyber System. These configurations or policies group BES Cyber Systems of the same impact rating and their associated PCA.

Dwanique Spiller, On Behalf of: Berkshire Hathaway - NV Energy - WECC - Segments 5

- 0 - 0

While the modified ESP definition is a definite improvement with respect to support for future development of zero trust networking adoption, the measures associated with proposed CIP-005-8 R1 include specification of business reasons associated with the configuration identified in the definition.  ISO-NE requests that the definition be updated to include the business reasons as a part of the ESP to clarify the relationship and the requirement to include such in the configuration and documentation related to ESP's.

John Galloway, On Behalf of: Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2

- 0 - 0

Tacoma Power, Segment(s) 1, 3, 4, 5, 6, 3/9/2021

- 0 - 0

GRE agrees with the comments submitted by the NSRF. 

Michael Brytowski, Great River Energy, 3, 9/1/2021

- 0 - 0

In support of IRC SRC/SWG.

We agree that the proposed change supports 1) traditional firewalls and 2) zero trust. However, the new language expands scope with “EACMS that controls communications to or from any part of a BES Cyber System.”

Monika Montez, On Behalf of: California ISO, WECC, Segments 2

- 0 - 0

Nurul Abser, NB Power Corporation, 1, 9/1/2021

- 0 - 0

We agree that the proposed ESP definition can be used for both traditional firewall based networks, as well as future networks such as zero trust. 

Donna Wood, Tri-State G and T Association, Inc., 1, 9/1/2021

- 0 - 0

We suggest adding “routable protocol” to the revised definition.  We feel this can still be used for both types of networks.  We also suggest removing “CIP Systems,” and replace with “BES Cyber Systems.”  Remove “enforced by an EACMS.”

Suggested definition - A set of configurations or policies [delete - enforced by an EACMS] that controls routable protocol communications to or from any part of a BES Cyber System. These configurations or policies group BES Cyber Systems of the same impact rating and their associated PCA.

Casey Jones, On Behalf of: Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5

- 0 - 0

Suggesting that the SD go back and make modifications to the definitions. We agree that the proposed ESP definition can be used for both traditional firewall based networks, as well as future networks such as zero trust. However, the routable protocol qualifier was removed and the new ESP qualifier is an EACMS. The EACMS definition does not have a routable protocol/communication qualifier, and it references ESPs. This seems like a circular definition. Also, it is our understanding that the SDT does not intend to have requirements baked into definitions but with the proposed ESP definition, and changes to CIP-005, the definition is the only place EACMS are required. We propose the following changes:

ESP definition: A set of configurations or policies that controls communications to or from any part of a BES Cyber System. These configurations or policies group CIP Systems of the same impact rating and their associated PCAs.

New CIP-005-X R1 Part 1.X:

Applicable Systems

High Impact BES Cyber Systems and their associated PCA

Medium Impact BES Cyber Systems and their associated PCA

Requirements

1.X.1 - EACMSs must be implemented to enforce ESPs where communication leaves the ESP, or where SCI is used.

1.X.2 - EAPs must be identified for ESPs.

When the proposed ESP definition is applied in the proposed CIP-005-X R1 Part 1.1 there is another issue since the definition no longer has the routable protocol qualifier.

Israel Perez, On Behalf of: Salt River Project, WECC, Segments 1, 3, 5, 6

- 0 - 0

In our opinion it should be clarified that a BCA or PCA controlling access only to itself (such as a host-based firewall) does not qualify as an EACMS and likewise does not constitue an ESP, except in cases where zero-trust is being used in place of a traditional EACMS and Access Point (such as a firewall). We also support EEI's comments on this question.

David Jendras, Ameren - Ameren Services, 3, 9/1/2021

- 0 - 0

The modified ESP definition does not resolve the traditional firewall based network or future networks. The virtualization zero trust topology is underneath the ESP network and is a non-ESP model. It is configured in the virtualization layer prior to VCAs reaching the ESP network. IRA cannot be identified without an ESP boundary being defined since IRA is initiated outside ESP. Furthermore, the SDT proposed ESP definition would include routable and non-routable BCAs in which it overreaches the goal of SAR. In our view, the EAP is still effective for the ESP model to control communications to and from BCS using routable protocol inside an ESP. We recommend adding an alternative requirement in CIP-005 R1.1 to address the zero-trust model in which the ESP model is not used rather than revising ESP definition. Our proposed changes won’t affect the existing ESP definition and ESP related requirements while still addressing virtualization to meet the goal of SAR.

Recommendations:

  1. Restore the current ESP definition since it is still effective for the perimeter-based routable network protection.

  2. We propose the following changes for CIP-005 R1.1:

    1. All applicable Cyber Assets connected to a network via a routable protocol shall reside within a defined ESP where all External Routable Connectivity must be through an identified EAP that permits only needed inbound and outbound access and denies all other access by default including the reason for granting access, or

    2. All BCAs connected to a network via a routable external protocol shall through an EACMS that controls all communications to and from BCAs unless ESP model is used.

      We agree that the proposed ESP definition can be used for both traditional firewall based networks, as well as future networks such as zero trust. However, the routable protocol qualifier was removed and the new ESP qualifier is an EACMS. The EACMS definition does not have a routable protocol/communication qualifier, and it references ESPs. This seems like a circular definition. Also, it is our understanding that the SDT does not intend to have requirements baked into definitions but with the proposed ESP definition, and changes to CIP-005, the definition is the only place EACMS are required. We propose the following changes:

      ESP definition: A set of configurations or policies that controls communications to or from any part of a BES Cyber System. These configurations or policies group CIP Systems of the same impact rating and their associated PCAs.

      New CIP-005-X R1 Part 1.X:

      Applicable Systems

      High Impact BES Cyber Systems and their associated PCA

      Medium Impact BES Cyber Systems and their associated PCA

      Requirements

      1.X.1 - EACMSs must be implemented to enforce ESPs where communication leaves the ESP, or where SCI is used.

      1.X.2 - EAPs must be identified for ESPs.

      When the proposed ESP definition is applied in the proposed CIP-005-X R1 Part 1.1 there is another issue since the definition no longer has the routable protocol qualifier. See our response to Question #10 below for further explanation.

Barry Jones, On Behalf of: sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6

- 0 - 0

Relative to the definition of ESP, GSOC is concerned that the second sentence proposed in the new definition is unnecessary and could cause confusion regarding its applicability beyond a virtualized environment.  In particular, use of the term “group” could connote actions or protections beyond the traditional and intended meaning of ESP.  As well, the second sentence appears to act as an additional requirement on the use of ESPs that would be better suited for inclusion in the actual requirements as set forth in CIP-005-8.  GSOC recommends deleting the second sentence from the definition and re-capturing the concept (as applicable) in the language of CIP-005-8.

GSOC requests the addition of clarifying language in CIP-005-8 R1.2 that would reinforce the approach of utilizing a traditional approach to electronic security perimeters in addition to the language proposed “EACMS that enforces an ESP for the Applicable System…”  Current proposed language could be interpreted to only apply to communications traversing an EACMS enforcing an ESP in a virtualized environment, without providing for requirements concerning the same traffic traversing a traditional ESP such as a firewall or similar device.

Benjamin Winslett, Georgia System Operations Corporation, 4, 9/1/2021

- 0 - 0

The new ESP may be logical/virtual or physical boundary applied using firewalls and zero trust.

Justin Welty, NextEra Energy - Florida Power and Light Co., 6, 9/1/2021

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Cynthia Lee, Exelon, 5, 9/1/2021

- 0 - 0

OPG concurs with NPCC's RSC comments

David Kwan, On Behalf of: Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Becky Webb, Exelon, 6, 9/1/2021

- 0 - 0

ACES Standard Collaborations, Segment(s) 1, 9/1/2021

- 0 - 0

Eversource 1, Segment(s) 3, 1, 9/1/2021

- 0 - 0

Karie Barczak, DTE Energy - Detroit Edison Company, 3, 9/1/2021

- 0 - 0

James Baldwin, Lower Colorado River Authority, 1, 9/1/2021

- 0 - 0

The SDT is using the update to the definition as a mechanism to support zero-trust models, but the existing ESP definition does not preclude a Responsible Entity from applying the concept of zero-trust to its environment(s) in addition to its traditional ESP. The proposed modification does not obligate a Responsible Entity to adopt additional security controls.

The statement in the Definitions and Exemptions Technical Rationale, “[i]n these models, the perimeter shrinks to increasingly more granular levels, potentially down to a process or resource level on a BCS and nothing on the network is trusted for unrestricted communications,” could be 

interpreted as meaning that traditional ESP-based perimeter security is not necessary or required. A Responsible Entity may choose to adopt a traditional ESP model, or a zero-trust model, without considering the benefits of a defense-in-depth approach that leverages both traditional perimeter-based security and zero-trust concepts.

AWS proposes the following language, “The logical border surrounding a network to which BES Cyber Systems are connected using a routable protocol that includes a set of configurations or policies enforced by an EACMS that controls communications to or from any part of a BES Cyber System. These configurations or policies group CIP Systems of the same impact rating and their associated PCAs.”

Detailed implementation guidance is necessary to support zero-trust and hybrid approaches. 

Maggy Powell, Amazon Web Services, 7, 9/1/2021

- 0 - 0

The phrase "control communication" is too broad; it could include any policy/configuration that configures anything that communicates (e.g., an internal API within an application).  The definition needs additional clarity such that an ESP is in the networking realm and is controlling the ability to deliver packets to a BCS on the network, which we gather is the intent since host-based firewalls are excluded.  We suggest modifying it to "control routable protocol communication" to clarify that an ESP is a network level construct (even in zero trust) concerned with delivery of packets.

The grouping statement in the ESP definition is confusing as it switches to "CIP Systems" and only BCS have impact ratings.  Suggest changing this to "These configurations or policies group BES Cyber Systems of the same impact rating with their associated PCAs".   In addition, we believe this sentence is attempting to say the ESP is the ‘innermost’ policy or configuration controlling access to the BCS and therefore grouping BCS of like impact rating and their PCAs.  We suggest making further clarifications to that end.  An enterprise’s Internet facing firewalls play some role in ‘controlling communications’ to eventual groups of BCS that may be many network zones deep behind many firewalls that are not the CIP-005 ESP of today.  However, there appears to be nothing in the definition or CIP-005 R1.1 that clearly states the ESP in question is the layer of segmentation/isolation method immediately ‘outside’ the BCS.

Southern Company, Segment(s) 1, 3, 6, 5, 1/14/2021

- 0 - 0

LCRA Compliance, Segment(s) 6, 5, 1, 5/11/2015

- 0 - 0

ERCOT supports the IRC SRC comments.

Brandon Gleason, 9/1/2021

- 0 - 0

LeRoy Patterson, Public Utility District No. 2 of Grant County, Washington, 6, 9/1/2021

- 0 - 0

<duplicate>

Dana Showalter, On Behalf of: Electric Reliability Council of Texas, Inc., Texas RE, Segments 2

- 0 - 0

EEI agrees that the modified ESP definition can be used for both types of networks but seeks clarification regarding the inclusion of the phrase “and their associated PCAs”, which appears to be redundant to the second sentence in the definition.  EEI notes that within the definition of CIP System, PCAs are clearly identified as a CIP System.  We suggest the following as one possible solution:

“A set of configurations or policies enforced by an EACMS that control routable protocol communications to or from any part of a BES Cyber System (BCS) and that groups BCS of the same impact rating.”

Alternatively, the SDT might consider leveraging the defined term “Electronic Access Point (EAP)” rather than modifying the term ESP.

Mark Gray, On Behalf of: Edison Electric Institute, NA - Not Applicable, Segments NA - Not Applicable

- 0 - 0

Gail Golden, Entergy - Entergy Services, Inc., 5, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

Alyssia Rhoads, Public Utility District No. 1 of Snohomish County, 1, 9/1/2021

- 0 - 0

 

PJM signs on to the comments provided by the IRC SRC.

Elizabeth Davis, On Behalf of: Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2

- 0 - 0

We suggest adding “routable protocol” to the revised definition.  We feel this can still be used for both types of networks.  We also suggest removing “CIP Systems,”and replace with “BES Cyber Systems.”  Remove “enforced by an EACMS.”

Suggested definition - A set of configurations or policies [delete - enforced by an EACMS] that controls routable protocol communications to or from any part of a BES Cyber System. These configurations or policies group BES Cyber Systems of the same impact rating and their associated PCA.

Lindsay Wickizer, Berkshire Hathaway - PacifiCorp, 6, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

Sam Nietfeld, Public Utility District No. 1 of Snohomish County, 5, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

SNPD Voting Members, Segment(s) 4, 6, 5, 1, 6/18/2020

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

John Martinsen, Public Utility District No. 1 of Snohomish County, 4, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

John Liang, Snohomish County PUD No. 1, 6, 9/1/2021

- 0 - 0

We agree that the proposed change supports 1) traditional firewalls and 2) zero trust. However, the new language expands scope with “EACMS that controls communications to or from any part of a BES Cyber System.”

 

The new definition can be used for both traditional firewall-based networks, as well as future networks such as zero-trust but we don’t agree on the overall definition.  

The suggested definition broadens the current scope, it implies the presence of an EACMS, thus requesting another cyber asset (We have a BCA: VCA and we have an EACMS: Firewall) unless the SDT wanted to permit the double categorization (BCA/EACMS: a VCA with an embedded firewall) 

The language “that controls communications” isn’t consistent with the NERC CIP orientation, usage of the bi-directional routable protocol should be used because with the current language one could imply that serial, layer 2 communication needs to have a set of configurations or policies.  

Also, the definition states that this is for a BES Cyber System (…any part of a BES Cyber System…), yet the definition mention CIP System (… policies group CIP Systems of the same …). The definition of CIP System includes more than BES Cyber System. 

We suggest reviewing the definition.  

The proposal could be  

A set of configurations or policies enforced those controls bi-directional routable protocol communications to or from any part of a BES Cyber System. These configurations or policies group BES Cyber System of the same impact rating and their associated PCAs.  

Reference: A set of configurations or policies enforced by an EACMS that controls communications to or from any part of a BES Cyber System. These configurations or policies group CIP Systems of the same impact rating and their associated PCAs.

NPCC Regional Standards Committee, Segment(s) 10, 2, 4, 7, 3, 1, 5, 6, 8/6/2021

- 0 - 0

Ryan Olson, Portland General Electric Co., 5, 9/1/2021

- 0 - 0

N&ST believes the “routable protocol” qualifier should be retained:


“A set of configurations or policies enforced by an EACMS that controls routable protocol communications to or from any part of a BES Cyber System. These configurations or policies group CIP Systems of the same impact rating and their associated PCAs.”

Roger Fradenburgh, On Behalf of: Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1

- 0 - 0

The IRC SRC agrees that the proposed change to the ESP definition supports 1) traditional firewalls and 2) zero trust. However, the new language expands scope with “EACMS that controls communications to or from any part of a BES Cyber System.”

ISO/RTO Council Standards Review Committee 2016-02 Virtualization (Draft 2), Segment(s) 2, 9/1/2021

- 0 - 0

LaTroy Brumfield, American Transmission Company, LLC, 1, 9/1/2021

- 0 - 0

ITC supports the response submitted by EEI for this question.

Gail Elliott, On Behalf of: Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1

- 0 - 0

Hot Answers

Portland General Electric Company supports the comments provided by EEI for this survey question.

Dan Zollner, Portland General Electric Co., 3, 9/1/2021

- 0 - 0

PGE FCD, Segment(s) 5, 1, 3, 6, 9/11/2018

- 0 - 0

Other Answers

Richard Jackson, U.S. Bureau of Reclamation, 1, 8/19/2021

- 0 - 0

Dominion, Segment(s) 3, 5, 1, 9/19/2019

- 0 - 0

Jeanne Kurzynowski, On Behalf of: CMS Energy - Consumers Energy Company - RF - Segments 3, 4, 5

- 0 - 0

Chelan agrees with the proposed definition changes for IRA.

CHPD, Segment(s) 3, 1, 6, 5, 8/24/2021

- 0 - 0

Glen Farmer, Avista - Avista Corporation, 5, 8/24/2021

- 0 - 0

The new IRA definition could expand scope significantly.  For instance, the second bullet within the proposed IRA definition – “through a Cyber Asset or Virtual Cyber Asset that is convering communications…” –  could potentially bring into scope an operator at a Control Center increasing megawatts at a Medium without ERC plant and classify that scenario as IRA.

Martin Sidor, NRG - NRG Energy, Inc., 6, 8/24/2021

- 0 - 0

The new IRA definition could expand scope significantly.  For instance, the second bullet within the proposed IRA definition – “through a Cyber Asset or Virtual Cyber Asset that is convering communications…” –  could potentially bring into scope an operator at a Control Center increasing megawatts at a Medium without ERC plant and classify that scenario as IRA.

Patricia Lynch, NRG - NRG Energy, Inc., 5, 8/24/2021

- 0 - 0

There is insufficient clarity provided within the proposed terms to ensure consistent understanding and identification of applicable traffic.

Tennessee Valley Authority, Segment(s) 1, 3, 5, 6, 10/18/2018

- 0 - 0

Xcel Energy supports the comments of EEI.

Amy Casuscelli, On Behalf of: Xcel Energy, Inc. - MRO, WECC - Segments 1, 3, 5, 6

- 0 - 0

Andrea Jessup, On Behalf of: Bonneville Power Administration, WECC, Segments 1, 3, 5, 6

- 0 - 0

Mike Magruder, Avista - Avista Corporation, 1, 8/26/2021

- 0 - 0

Duke Energy generally supports the SDT’s direction, but suggests several changes to address various concerns:

Duke recommends that the second bullet be updated to read more clearly: “through a Cyber Asset or Virtual Cyber Asset that converts the communication from a routable protocol to a non-routable protocol that is passed on to a Cyber System not within an ESP.”  This also consistently applies abbreviations after the first instance of the term is spelled out.

Duke has concerns with the application of the IRA definition to the Management Interfaces of EACMS that enforce ESPs.  This may result in reliability impacts when an EACMS Firewall management interface can only be accessed by an IS that is secured in a DMZ behind that firewall, and a failure of the firewall prevents access to the IS.  We would suggest that the last bullet be removed from the definition.  Proposed requirements in CIP-005 R1 Part 1.2 should provide adequate protection for these interfaces.

Finally, Duke Energy recommends that the SDT either explicitly refer to the defined term “Real-time” or use alternative language to avoid auditor interpretations as seen in the difference between “adverse impact” used in the BCA definition and the defined term “Adverse Reliability Impact”.     

 

Katie Connor, On Behalf of: Duke Energy - SERC, RF - Segments 1, 3, 5, 6

- 0 - 0

AECI, Segment(s) 1, 3, 6, 5, 3/4/2021

- 1 - 0

See MRO-NSRF and EEI Comments

Clarice Zellmer, WEC Energy Group, Inc., 5, 8/26/2021

- 0 - 0

Ronald Bender, Nebraska Public Power District, 5, 8/27/2021

- 0 - 0

Josh Johnson, Lincoln Electric System, 1, 8/27/2021

- 0 - 0

Suggest removing ‘Responsible Entity’s’ as it should still be considered IRA if a user at one entity, outside an ESP, connected remotely to another entity's ESP. Additionally, consider changing ‘person’ to Cyber Asset. The use of a person in the context being ‘outside an Electronic Security Perimeter’ does not make sense. Suggest the following - User-initiated real-time access from a Cyber Asset outside of the Electronic Security Perimeters (ESP) using a routable protocol: Bullets one and two are in the singular tense, consider changing bullets three and four from plural tense to single tense as well. Bullet three to – ‘To a Management Interface of a Shared Cyber Infrastructure; or’ and bullet four to – ‘To a Management Interface of an Electronic Access Control or Monitoring System that enforces an ESP.’

WECC CIP, Segment(s) 10, 2/17/2021

- 0 - 0

The use of ‘within an ESP’ doesn’t work with the new ESP definition.  Alternative proposal: Replace ‘from outside of the Responsible Entity’s Electronic Security Perimeters’ with ‘from a Cyber Asset that is not protected by an Entity’s Electronic Security Perimeters’, and replace ‘within an ESP’ and ‘within an Electronic Security Perimeter’ with ‘protected by an Electronic Security Perimeter’.

Additionally, focusing on Mangement Interfaces rather than SCI itself could allow access to the SCI through an additional port that doesn’t meet the definition of a Management Interface.

William Steiner, Midwest Reliability Organization, 10, 8/30/2021

- 0 - 0

AZPS agrees with the proposed change to the IRA definition.

Marcus Bortman, APS - Arizona Public Service Co., 6, 8/30/2021

- 0 - 0

This definition introduces significant ambiguity and would rely excessively on non-enforcable Technical rationales and guidelines.  As a result, it is subject to significant ambiguity.  This ambiguity is further increased by the change in the definition of ESP that removes a clearly defined border of the ESP. 

Susan Sosbe, On Behalf of: Wabash Valley Power Association, , Segments 1, 3

- 0 - 0

The second bullet point is not clear. Need for clarification

Carl Pineault, Hydro-Qu?bec Production, 5, 8/30/2021

- 0 - 0

Jennifer Bray, Arizona Electric Power Cooperative, Inc., 1, 8/30/2021

- 0 - 0

Justin MacDonald, On Behalf of: Midwest Energy, Inc., , Segments 1

- 0 - 0

The definition of 'IRA' is unclear on the overall impact to the current infrastructure. Please further clarify as the second bullet "through a Cyber Asset or Virtual Cyber Asset that is converting communications from a routable protocol to a non-routable protocol to a Cyber System not within an Electronic Security Perimeter;" suggests that non-CIP devices will fall under the purview of this definition with the use of the NERC-defined term "Cyber System" being contained within the above language

Steve Toosevich, NiSource - Northern Indiana Public Service Co., 1, 8/31/2021

- 0 - 0

CEHE does not agree with the proposed changes to the Interactive Remote Access definition because it seems to be unnecessarily confusing due to unneeded information within the definition.  

The first bullet “to a Cyber System within an ESP” covers access to any Cyber System including its user interface ports. Therefore it is unnecessary to have the third and fourth bullet items.  The third bullet specifies Management Interfaces of SCI, and similarly the fourth bullet specifies the Management Interfaces of the EACMS that enforces an ESP.  However both SCI and EACMS are Cyber Systems which are covered by the first bullet.

The purpose of the fourth bullet is to capture remote access through a “serial to IP” device, and to achieve this the bullet item goes through a complex explanation on the conversion of routable to non-routable communications and Cyber Systems not in an ESP.  The same thing can be accomplished by removing the phrase “using a routable protocol” from the first part of the definition. Then, to capture Cyber Systems not within an ESP, it seems that including “… Electronic Security Perimeter (ESP) or Physical Security Perimeter (PSP) …”  would more clearly capture this. 

In addition, CEHE understands that a cabinet can be a PSP, and someone standing outside of the cabinet and physically connecting to a system within a cabinet is not IRA.  This situation is not a remote connection therefore is not IRA and may need to be explained in the technical rationale.

IRA should not be prescribed to only “a routable protocol”.  It should include all methods by which this is accomplished, even by a dial-up connection.  However, CIP-005-8 requirement R2 specifically excludes Dial-up Connectivity.  This is how the process should work.  The definition states what IRA is, and the requirements specify exactly what applies.

Based upon those thoughts CEHE proposes the following:

“A user initiated real-time electronic access by a person from outside of a Responsible Entity’s Electronic Security Perimeter (ESP) or Physical Security Perimeter (PSP) to a CIP System within the Responsible Entity’s ESP or PSP, either directly or through another Cyber Asset or Virtual Cyber Asset for the purpose of connecting to any of the CIP System’s user interfaces.”

Eli Rivera, On Behalf of: CenterPoint Energy Houston Electric, LLC, Texas RE, Segments NA - Not Applicable

- 0 - 0

Comments:

Clarification is needed around the Management Interfaces of a Shared Cyber Infrastructure (SCI). Is the intent to limit the definition of Management Interfaces that manage SCI and the other bulleted items in the definition, or is the intent to include all Management Interfaces?

Southwest Power Pool Standards Review Group (SSRG), Segment(s) 2, 9/4/2019

- 0 - 0

Chris Carnesi, On Behalf of: Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6

- 0 - 0

SIGE does not agree with the proposed changes to the Interactive Remote Access definition because it seems to be unnecessarily confusing due to unneeded information within the definition.  

The first bullet “to a Cyber System within an ESP” covers access to any Cyber System including its user interface ports. Therefore it is unnecessary to have the third and fourth bullet items.  The third bullet specifies Management Interfaces of SCI, and similarly the fourth bullet specifies the Management Interfaces of the EACMS that enforces an ESP.  However both SCI and EACMS are Cyber Systems which are covered by the first bullet.

The purpose of the fourth bullet is to capture remote access through a “serial to IP” device, and to achieve this the bullet item goes through a complex explanation on the conversion of routable to non-routable communications and Cyber Systems not in an ESP.  The same thing can be accomplished by removing the phrase “using a routable protocol” from the first part of the definition. Then, to capture Cyber Systems not within an ESP, it seems that including “… Electronic Security Perimeter (ESP) or Physical Security Perimeter (PSP) …”  would more clearly capture this. 

In addition, SIGE understands that a cabinet can be a PSP, and someone standing outside of the cabinet and physically connecting to a system within a cabinet is not IRA.  This situation is not a remote connection therefore is not IRA and may need to be explained in the technical rationale.

IRA should not be prescribed to only “a routable protocol”.  It should include all methods by which this is accomplished, even by a dial-up connection.  However, CIP-005-8 requirement R2 specifically excludes Dial-up Connectivity.  This is how the process should work.  The definition states what IRA is, and the requirements specify exactly what applies.

Based upon those thoughts SIGE proposes the following:

“A user initiated real-time electronic access by a person from outside of a Responsible Entity’s Electronic Security Perimeter (ESP) or Physical Security Perimeter (PSP) to a CIP System within the Responsible Entity’s ESP or PSP, either directly or through another Cyber Asset or Virtual Cyber Asset for the purpose of connecting to any of the CIP System’s user interfaces.”

Brian Tooley, On Behalf of: Southern Indiana Gas and Electric Co., RF, Segments 3, 5, 6

- 0 - 0

The definition states that the communication is to a system within an ESP, but the last bullet states that IRA applies to Management Interfaces for EACMS that enforce an ESP.  The problem with this is that the Management Interface does not necessarily reside within the ESP. 

Joe Tarantino, On Behalf of: Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6

- 0 - 0

Texas RE is concerned with the use of the term “real-time” as it is a defined word in the NERC Glossary.  This could introduce confusion.  Texas RE recommends removing this term from the language.

Rachel Coyne, Texas Reliability Entity, Inc., 10, 8/31/2021

- 0 - 0

BC Hydro, Segment(s) 3, 5, 1, 12/18/2018

- 0 - 0

SDG&E supports EEI Comments 

Bridget Silvia, Sempra - San Diego Gas and Electric, 3, 8/31/2021

- 0 - 0

MEAG Power adopts the Southern Company comments.

MEAG Power, Segment(s) 3, 1, 5, 6/15/2017

- 0 - 0

We support NPCC TFIST's comments as found below:

Request clarification of the second bullet because it does not apply to any NERC CIP applicable system. Suggest changing from “through a Cyber Asset or Virtual Cyber Asset that is converting communications from a routable protocol to a non-routable protocol to a Cyber System not within an Electronic Security Perimeter;” to “to a Cyber System within an ESP, through a Cyber Asset or Virtual Cyber Asset that is converting communications from a routable protocol to a non-routable protocol from a Cyber System not within an Electronic Security Perimeter;”.

Gerry Adamski, Cogentrix Energy Power Management, LLC, 5, 8/31/2021

- 0 - 0

FE Voter, Segment(s) 1, 3, 5, 6, 4, 2/23/2021

- 0 - 0

OKGE supports EEI's comments. 

OKGE, Segment(s) 6, 1, 3, 5, 3/22/2021

- 0 - 0

As written and presented, there is a gap between what is system-to-system and what is Interactive Remote Access (IRA) with the new IRA definition.  Entities often rely on IRA ports for system-to-system communication, but have not adequately enforced protections to ensure that the ports are not used by malicious actors regardless of whether a remote access client is available or used.  Additional technical measures or controls should be added to ensure validity of communications to Applicable Systems.  In addition, approval of CIP-005-8 would be conditional, based upon approval of the entire suite of new standards associated with virtualization and approval of SCI terminology and other definitions associated with virtualization as a whole.

Anthony Jablonski, ReliabilityFirst , 10, 8/31/2021

- 0 - 0

The definition needs clarification that system-to-system communications are not considered IRA.  Add the following sentence back to the end of the definition as with the currently approved definition: “Interactive Remote Access does not include system-to-system process communications.”

Darnez Gresham, Berkshire Hathaway Energy - MidAmerican Energy Co., 3, 8/31/2021

- 0 - 0

See MidAmerican Energy Company comments from Darnez Gresham.

Terry Harbour, Berkshire Hathaway Energy - MidAmerican Energy Co., 1, 8/31/2021

- 0 - 0

Cleco supports comments submitted by EEI.

Clay Walker, On Behalf of: Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6

- 0 - 0

In support of NPCC RSC comments.

Request clarification of the second bullet because it does not apply to any NERC CIP applicable system. Suggest changing from “through a Cyber Asset or Virtual Cyber Asset that is converting communications from a routable protocol to a non-routable protocol to a Cyber System not within an Electronic Security Perimeter;” to “to a Cyber System within an ESP, through a Cyber Asset or Virtual Cyber Asset that is converting communications from a routable protocol to a non-routable protocol from a Cyber System not within an Electronic Security Perimeter;”.

 

The new definition of ESP mentions an ESP is a …set of configurations or policies enforced by an EACMS… This definition doesn’t establish a boundary (logical border) so the language outside of the Responsible Entity’s Electronic Security Perimeters (ESP) or within an ESP doesn’t work. 

The introduction of the converting functionality is interesting.  

We suggest reviewing the definition of ESP/IRA/EAP. 

Alternate proposal 

User-initiated real-time access by a person outside of BES Cyber System, using a routable protocol:  

• to a BES Cyber System;  

• through a Cyber Asset or Virtual Cyber Asset that is converting communications from a routable protocol to a non-routable protocol to a BES Cyber System  

• To Management Interfaces of a Shared Cyber Infrastructure; or  

• To Management Interfaces of an Electronic Access Control or Monitoring Systems that enforce an ESP.  

             Reference 

User-initiated real-time access by a person from outside of the Responsible Entity’s Electronic     Security Perimeters (ESP). using a routable protocol:  

• to a Cyber System within an ESP;  

• through a Cyber Asset or Virtual Cyber Asset that is converting communications from a routable protocol to a non-routable protocol to a Cyber System not within an Electronic Security Perimeter;  

• To Management Interfaces of a Shared Cyber Infrastructure; or  

• To Management Interfaces of an Electronic Access Control or Monitoring Systems that enforce an ESP.  

Nicolas Turcotte, Hydro-Qu?bec TransEnergie, 1, 9/1/2021

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Daniel Gacek, Exelon, 1, 9/1/2021

- 0 - 0

AEP believes additional clarity is needed to the proposed definition of Interactive Remote Access (IRA) and provides the following revised introduction sentence for consideration. 

“A user initiated electronic access by a person from outside of a Responsible Entity’s Electronic Security Perimeter (ESP) and Physical Security Perimeter (PSP) using a routable protocol to a CIP System within the Responsible Entity’s ESP, either directly or through another Cyber Asset or Virtual Cyber Asset for the purpose of connecting to any of the CIP System’s user interfaces. This includes access to:

  • Cyber Systems within an ESP;
  • Through a Cyber Asset or Virtual Cyber Asset that is converting communications from a routable protocol to a non-routable protocol to a Cyber System not within an Electronic Security Perimeter;
  • To Management Interfaces of a Shared Cyber Infrastructure; or
  • To Management Interfaces of an Electronic Access Control or Monitoring Systems that enforce an ESP”

We suggest “real-time” be stricken from the definition as we believe there is no function that would allow “a person” to interact with a system in any frame of time other than “real-time”. While we recognize the attempt to establish that this would not include batch processing, it is our opinion that the batch would run system-to-system and would not qualify as “a person”.

JT Kuehne, AEP, 6, 9/1/2021

- 0 - 0

We agree with the changes if real-time is being used as the NERC defined word. If that was the intent, it should be capitalized. If not, there should be more clarification around what real-time is. We agree if the intent is to continue to exclude system to system process communications. 

Jamie Monette, On Behalf of: Allete - Minnesota Power, Inc., , Segments 1

- 0 - 0

Request clarification of the second bullet because it does not apply to any NERC CIP applicable system. Suggest changing from “through a Cyber Asset or Virtual Cyber Asset that is converting communications from a routable protocol to a non-routable protocol to a Cyber System not within an Electronic Security Perimeter;” to “to a Cyber System within an ESP, through a Cyber Asset or Virtual Cyber Asset that is converting communications from a routable protocol to a non-routable protocol from a Cyber System not within an Electronic Security Perimeter;”.

 

The new definition of ESP mentions an ESP is a …set of configurations or policies enforced by an EACMS… This definition doesn’t establish a boundary (logical border) so the language outside of the Responsible Entity’s Electronic Security Perimeters (ESP) or within an ESP doesn’t work. 

The introduction of the converting functionality is interesting.  

We suggest reviewing the definition of ESP/IRA/EAP. 

Alternate proposal 

User-initiated real-time access by a person outside of BES Cyber System, using a routable protocol:  

• to a BES Cyber System;  

• through a Cyber Asset or Virtual Cyber Asset that is converting communications from a routable protocol to a non-routable protocol to a BES Cyber System  

• To Management Interfaces of a Shared Cyber Infrastructure; or  

• To Management Interfaces of an Electronic Access Control or Monitoring Systems that enforce an ESP.  

             Reference 

User-initiated real-time access by a person from outside of the Responsible Entity’s Electronic     Security Perimeters (ESP). using a routable protocol:  

• to a Cyber System within an ESP;  

• through a Cyber Asset or Virtual Cyber Asset that is converting communications from a routable protocol to a non-routable protocol to a Cyber System not within an Electronic Security Perimeter;  

• To Management Interfaces of a Shared Cyber Infrastructure; or  

• To Management Interfaces of an Electronic Access Control or Monitoring Systems that enforce an ESP.  

Leonard Kula, Independent Electricity System Operator, 2, 9/1/2021

- 0 - 0

We disagree with the proposed changes because much of the existing IRA definition is clear and effective. The SDT should only clarify whether the entire communication path needs to be routable from the remote client to the end device.

Recommendation: We recommend making a minor change to the existing IRA to clarify the concept of a routable protocol converting to non-routable so that it can meet the goal of the SAR. (See our proposed changes to IRA and rationale in Q1

MRO NSRF, Segment(s) 2, 4, 1, 6, 3, 5, 7/1/2021

- 0 - 0

Amy Jones, Public Utility District No. 2 of Grant County, Washington, 5, 9/1/2021

- 0 - 0

Evergy incorporates by reference and endorses the comments as filed by the Edison Electric Institute.

Alan Kloster, On Behalf of: Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Kinte Whitehead, Exelon, 3, 9/1/2021

- 0 - 0

Third bullet should read “To Management Interfaces of an Shared Cyber Infrastructure within an ESP; or” unless the SDT is trying to bring IRA restrictions to devices outside an ESP. In which case the applicability should be expanded further.  

Amy Bratkovic, On Behalf of: PNM Resources - Public Service Company of New Mexico, , Segments 1, 3

- 0 - 0

The definition needs clarification that system-to-system communications are not considered IRA.  Add the following sentence back to the end of the definition as with the currently approved definition: “Interactive Remote Access does not include system-to-system process communications.”

Dwanique Spiller, On Behalf of: Berkshire Hathaway - NV Energy - WECC - Segments 5

- 0 - 0

John Galloway, On Behalf of: Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2

- 0 - 0

Tacoma Power, Segment(s) 1, 3, 4, 5, 6, 3/9/2021

- 0 - 0

GRE agrees with the comments submitted by the NSRF. 

Michael Brytowski, Great River Energy, 3, 9/1/2021

- 0 - 0

In support of IRC SRC/SWG.

Request clarification of the second bullet because it does not apply to any NERC CIP applicable system. Suggest changing from “through a Cyber Asset or Virtual Cyber Asset that is converting communications from a routable protocol to a non-routable protocol to a Cyber System not within an Electronic Security Perimeter;” to “to a Cyber System within an ESP, through a Cyber Asset or Virtual Cyber Asset that is converting communications from a routable protocol to a non-routable protocol from a Cyber System not within an Electronic Security Perimeter;”.

Monika Montez, On Behalf of: California ISO, WECC, Segments 2

- 0 - 0

Nurul Abser, NB Power Corporation, 1, 9/1/2021

- 0 - 0

Agree with the change to IRA definition.

Donna Wood, Tri-State G and T Association, Inc., 1, 9/1/2021

- 0 - 0

The definition needs clarification that system-to-system communications are not considered IRA.  Add the following sentence back to the end of the definition as with the currently approved definition: “Interactive Remote Access does not include system-to-system process communications.”

Casey Jones, On Behalf of: Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5

- 0 - 0

Israel Perez, On Behalf of: Salt River Project, WECC, Segments 1, 3, 5, 6

- 0 - 0

We are concerned with the implications of these changes in conjunction with the changes in definition to ESP, EACMS, and the addition of serial communication. To avoid confussin we believe this needs to be clarified within CIP-005 that CIP-005 IRA requirements do not apply to BCAs or PCAs controlling access only to themselves (such as host-based firewalls) when a traditional EACMS and Access Point (such as a site firewall) is being used.

David Jendras, Ameren - Ameren Services, 3, 9/1/2021

- 0 - 0

We disagree with the proposed changes because much of the existing IRA definition is clear and effective. The SDT should only clarify whether the entire communication path needs to be routable from the remote client to the end device.

Recommendation: We recommend making a minor change to the existing IRA to clarify the concept of a routable protocol converting to non-routable so that it can meet the goal of the SAR. (See our proposed changes to IRA and rationale in Q1.

Barry Jones, On Behalf of: sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6

- 0 - 0

Benjamin Winslett, Georgia System Operations Corporation, 4, 9/1/2021

- 0 - 0

  • IRA with ERC has been confusing for Entities to understand when the conversion to serial devices appears to now be in scope if configurations may be impacted using serial thus requiring, for example password changes within 15 months.

    • Please provide more examples including transitioning BCA currently without ERC when it becomes BCA with ERC under the new proposed definitions and standards.  How and where is the change applied and if it will be part of CIP-002?

  • Does a Non-CIP System distribution Relay now become a PCA because it is connected to the Medium Impact Serial converter if it supports IRA? 

Justin Welty, NextEra Energy - Florida Power and Light Co., 6, 9/1/2021

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Cynthia Lee, Exelon, 5, 9/1/2021

- 0 - 0

OPG concurs with NPCC's RSC comments

David Kwan, On Behalf of: Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Becky Webb, Exelon, 6, 9/1/2021

- 0 - 0

ACES Standard Collaborations, Segment(s) 1, 9/1/2021

- 0 - 0

Eversource 1, Segment(s) 3, 1, 9/1/2021

- 0 - 0

Karie Barczak, DTE Energy - Detroit Edison Company, 3, 9/1/2021

- 0 - 0

James Baldwin, Lower Colorado River Authority, 1, 9/1/2021

- 0 - 0

No comments

Maggy Powell, Amazon Web Services, 7, 9/1/2021

- 0 - 0

Southern supports the changes concerning clarity for IP-serial conversions, but does not support the changes for Management Interfaces such as those on an “EACMS that enforces an ESP”.  An Intermediate System is an EACMS that helps enforce an ESP which could open up a “Hall of Mirrors” scenario where an Intermediate System is required to access an Intermediate System.  This hall of mirrors is stated in the Applicable Systems column of CIP-005 R2.1 (in the clean version of CIP-005 that was posted, which differs from the redline).

Southern Company, Segment(s) 1, 3, 6, 5, 1/14/2021

- 0 - 0

LCRA Compliance, Segment(s) 6, 5, 1, 5/11/2015

- 0 - 0

ERCOT supports the IRC SRC comments and offers these additional comments:

  • Bullet 2: This appears to be backwards. It reads like you are sending communications outside the ESP.
  • Bullet 3: Please clarify if “To Management Interfaces of a Shared Cyber Infrastructure” is only related to the Cyber Assets within the ESP.
  • Bullet 4: Adding “To Management Interfaces of an Electronic Access Control or Monitoring Systems that enforces an ESP” expands the scope of the existing definition by protecting more than just what resides inside the ESP.

Brandon Gleason, 9/1/2021

- 0 - 0

LeRoy Patterson, Public Utility District No. 2 of Grant County, Washington, 6, 9/1/2021

- 0 - 0

<duplicate>

Dana Showalter, On Behalf of: Electric Reliability Council of Texas, Inc., Texas RE, Segments 2

- 0 - 0

Comments: EEI asks for additional clarity for the proposed definition of IRA.  It is unclear why the definition includes “real-time” when the proposed definition specifically applies to access by a person.  If “real-time” was inserted for a specific purpose, then the SDT should provide a clear explanation.  Additionally, if “real-time” is needed, EEI recommends that the definition also include “IRA does not include system to system process communications or read-only access.” 

“A user initiated real-time electronic access by a person from outside of a Responsible Entity’s Electronic Security Perimeter (ESP) or Physical Security Perimeter (PSP) using a routable protocol to a CIP System within the Responsible Entity’s ESP or PSP, either directly or through another Cyber Asset or Virtual Cyber Asset for the purpose of connecting to any of the CIP System’s user interfaces. This includes access to:

  1. Cyber Systems within an ESP;
  2. Through a Cyber Asset or Virtual Cyber Asset that is converting communications from a routable protocol to a non-routable protocol to a Cyber System not within an Electronic Security Perimeter;
  3. To Management Interfaces of a Shared Cyber Infrastructure; or
  4. To Management Interfaces of an Electronic Access Control or Monitoring Systems that enforce an ESP”
  5. IRA does not include system to system process communications or read only access.

Mark Gray, On Behalf of: Edison Electric Institute, NA - Not Applicable, Segments NA - Not Applicable

- 0 - 0

Gail Golden, Entergy - Entergy Services, Inc., 5, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

Alyssia Rhoads, Public Utility District No. 1 of Snohomish County, 1, 9/1/2021

- 0 - 0

 

PJM signs on to the comments provided by the IRC SRC.

Elizabeth Davis, On Behalf of: Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2

- 0 - 0

The definition needs clarification that system-to-system communications are not considered IRA.  Add the following sentence back to the end of the definition as with the currently approved definition: “Interactive Remote Access does not include system-to-system process communications.”

Lindsay Wickizer, Berkshire Hathaway - PacifiCorp, 6, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

Sam Nietfeld, Public Utility District No. 1 of Snohomish County, 5, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

SNPD Voting Members, Segment(s) 4, 6, 5, 1, 6/18/2020

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

John Martinsen, Public Utility District No. 1 of Snohomish County, 4, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

John Liang, Snohomish County PUD No. 1, 6, 9/1/2021

- 0 - 0

Request clarification of the second bullet because it does not apply to any NERC CIP applicable system. Suggest changing from “through a Cyber Asset or Virtual Cyber Asset that is converting communications from a routable protocol to a non-routable protocol to a Cyber System not within an Electronic Security Perimeter;” to “to a Cyber System within an ESP, through a Cyber Asset or Virtual Cyber Asset that is converting communications from a routable protocol to a non-routable protocol from a Cyber System not within an Electronic Security Perimeter;”.

 

The new definition of ESP mentions an ESP is a …set of configurations or policies enforced by an EACMS… This definition doesn’t establish a boundary (logical border) so the language outside of the Responsible Entity’s Electronic Security Perimeters (ESP) or within an ESP doesn’t work. 

The introduction of the converting functionality is interesting.  

We suggest reviewing the definition of ESP/IRA/EAP. 

Alternate proposal 

User-initiated real-time access by a person outside of BES Cyber System, using a routable protocol:  

• to a BES Cyber System;  

• through a Cyber Asset or Virtual Cyber Asset that is converting communications from a routable protocol to a non-routable protocol to a BES Cyber System  

• To Management Interfaces of a Shared Cyber Infrastructure; or  

• To Management Interfaces of an Electronic Access Control or Monitoring Systems that enforce an ESP.  

             Reference 

User-initiated real-time access by a person from outside of the Responsible Entity’s Electronic     Security Perimeters (ESP). using a routable protocol:  

• to a Cyber System within an ESP;  

• through a Cyber Asset or Virtual Cyber Asset that is converting communications from a routable protocol to a non-routable protocol to a Cyber System not within an Electronic Security Perimeter;  

• To Management Interfaces of a Shared Cyber Infrastructure; or  

• To Management Interfaces of an Electronic Access Control or Monitoring Systems that enforce an ESP.  

NPCC Regional Standards Committee, Segment(s) 10, 2, 4, 7, 3, 1, 5, 6, 8/6/2021

- 0 - 0

Portland General Electric Company supports the comments provided by EEI for this survey question.

Ryan Olson, Portland General Electric Co., 5, 9/1/2021

- 0 - 0

N&ST believes the first sentence, “User‐initiated real‐time access by a person from outside of the Responsible Entity’s Electronic Security Perimeters (ESP) using a routable protocol” fails to account for Responsible Entities that only have ESPs at some of their in-scope facilities or, in some instances (e.g., a TO with only serial Med Impact BCS) have no ESPs at all. Suggested change:


“User‐initiated real‐time access by a person from outside of the Responsible Entity’s Electronic Security Perimeters (ESPs) using a routable protocol, or
“User‐initiated real‐time access by a person from outside of a Responsible Entity asset that contains only serially-connected BCS using a routable protocol… (etc.)”

Roger Fradenburgh, On Behalf of: Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1

- 0 - 0

The IRS SRC recommends the SDT clarify the second bullet under the Interactive Remote Access (IRA) definition because it does not apply to any NERC CIP applicable system. Suggest changing the language from: “through a Cyber Asset or Virtual Cyber Asset that is converting communications from a routable protocol to a non-routable protocol to a Cyber System not within an Electronic Security Perimeter;” to: “to a Cyber System within an ESP, through a Cyber Asset or Virtual Cyber Asset that is converting communications from a routable protocol to a non-routable protocol from a Cyber System not within an Electronic Security Perimeter;”.

ISO/RTO Council Standards Review Committee 2016-02 Virtualization (Draft 2), Segment(s) 2, 9/1/2021

- 0 - 0

LaTroy Brumfield, American Transmission Company, LLC, 1, 9/1/2021

- 0 - 0

ITC supports the response submitted by EEI for this question.

Gail Elliott, On Behalf of: Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1

- 0 - 0

Hot Answers

Dan Zollner, Portland General Electric Co., 3, 9/1/2021

- 0 - 0

PGE FCD, Segment(s) 5, 1, 3, 6, 9/11/2018

- 0 - 0

Other Answers

Richard Jackson, U.S. Bureau of Reclamation, 1, 8/19/2021

- 0 - 0

There appears to be ambiguity around what is meant by logical interface.  Does “user interface” refer to graphical user interface?  If not, what is the difference between a “user interface” and the excluded “physical user interfaces…”?

Dominion, Segment(s) 3, 5, 1, 9/19/2019

- 0 - 0

Jeanne Kurzynowski, On Behalf of: CMS Energy - Consumers Energy Company - RF - Segments 3, 4, 5

- 0 - 0

With the improvements to scoping in Draft 2, Chelan agrees with the definition Management Interface.

CHPD, Segment(s) 3, 1, 6, 5, 8/24/2021

- 0 - 0

Glen Farmer, Avista - Avista Corporation, 5, 8/24/2021

- 0 - 0

The inclusion of “user interface” within the Management Interface definition will overly broaden the impact of the proposed definition.  NRG recommends removing “user interface” from the definition.

Martin Sidor, NRG - NRG Energy, Inc., 6, 8/24/2021

- 0 - 0

The inclusion of “user interface” within the Management Interface definition will overly broaden the impact of the proposed definition.  NRG recommends removing “user interface” from the definition.

Patricia Lynch, NRG - NRG Energy, Inc., 5, 8/24/2021

- 0 - 0

The previously proposed term “Management Systems” provided better clarity for identification of systems that support patching, configuration management, anti-malware signature updates, and other management functions. This clarity was lost with the newly proposed term. Specifically, the ‘and’ clause in “Control the processes of initializing, deploying, and configuring Shared Cyber Infrastructure;’ seems to imply only inclusion of systems used for initial provisioning (e.g., installing an operating system & configuring a network card) as opposed to systems that supporting ongoing health and maintenance activities for deployed systems.

Tennessee Valley Authority, Segment(s) 1, 3, 5, 6, 10/18/2018

- 0 - 0

Xcel Energy supports the comments of EEI.

Amy Casuscelli, On Behalf of: Xcel Energy, Inc. - MRO, WECC - Segments 1, 3, 5, 6

- 0 - 0

iLO is a branded technology for Hewlett-Packard. BPA suggests replacing “lights-out” terminology with “dedicated out-of-band”.

Andrea Jessup, On Behalf of: Bonneville Power Administration, WECC, Segments 1, 3, 5, 6

- 0 - 0

The proposed changes appear to require significant modification to our current network architecture without clearly indicating how this can be accomplished in a compliant fashion or how that improves upon the existing security posture.

Mike Magruder, Avista - Avista Corporation, 1, 8/26/2021

- 0 - 0

Duke Energy supports a consolidated definition for the various management components that require protection but suggests the use of “Management System” instead of “Management Interface” for parity with BCS, Cyber System, etc. as the preferred terminology for Applicable Systems.  Additionally, Duke requests that the SDT provide thorough implementation guidance to assist in correctly classifying systems that provide management functions but are not associated specifically with SCI (e.g. SCOM) as this definition may introduce a confusing break in consistency of classification between SCI management (e.g. vCenter) and other management tools.

Katie Connor, On Behalf of: Duke Energy - SERC, RF - Segments 1, 3, 5, 6

- 0 - 0

The proposed changes are an improvement to the previous Management Module and Management Systems definition; however additional clarity could be provided when referring to "lights-out" management capabilites. All entities may not agree on the intent of the referenced term, it should be defined to address the ability for a system administrator to monitor and manage servers by remote control.

AECI, Segment(s) 1, 3, 6, 5, 3/4/2021

- 1 - 0

See MRO-NSRF and EEI Comments

Clarice Zellmer, WEC Energy Group, Inc., 5, 8/26/2021

- 0 - 0

Ronald Bender, Nebraska Public Power District, 5, 8/27/2021

- 0 - 0

Josh Johnson, Lincoln Electric System, 1, 8/27/2021

- 0 - 0

WECC CIP, Segment(s) 10, 2/17/2021

- 0 - 0

The proposed definition leaves a great deal of ambiguity about the intent of the ‘user interface, logical interface, or dedicated physical port’.  While in most cases, an entity would likely choose to go to the physical or logical (VLAN/sub-interface) port level, there are concerns about an approach where the entity may try to only protect the user interface, leaving other ports (TCP/UDP) on the same physical/logical port unprotected.  It is unclear how vCenter would be treated – MRO would interpret it to be a ‘user interface’ included with SCI (per SCI definition, “including the software and Management Interfaces”).

In an all-in scenario, how do the protections apply to a Management Interface that is a different Cyber Asset (CA) from the SCI.  For example, if vCenter is a different CA than the SCI its managing, how does the applicability of in CIP-005, CIP-007 and CIP-010 extend to that different CA running vCenter become SCI identified independently or a Cyber Asset?

The SCI definition includes Management Interfaces, if the Management Interface is a separate Cyber Asset how does the applicability extend to the separate Cyber Asset? For example, if a central firewall management system is outside of the ESP, how would this system be protected in the all-in scenario, or will it be required to be inside an ESP?

William Steiner, Midwest Reliability Organization, 10, 8/30/2021

- 0 - 0

AZPS agrees with the proposed definition included in EEIs comments filed in this matter.  AZPS requests additional information on what “Lights-Out capabilities”includes.

Proposed Definition: “A user interface, logical interface or dedicated physical port, excluding touch controls (e.g., power switch, touch panel, etc.), that is used to: control the processes of initializing, deploying, and configuring or lights-out management capabilities of Cyber Systems.”

Marcus Bortman, APS - Arizona Public Service Co., 6, 8/30/2021

- 0 - 0

We support the general approach.  However, the language is written using “or”.  As a result, a management interface that supports any lights out system.  In cases such as CIP-007 R1.3, this may be inappropriately interpreted to bring in unrelated items such as a UPS that support these devices. 

Susan Sosbe, On Behalf of: Wabash Valley Power Association, , Segments 1, 3

- 0 - 0

Request clarification of the second bullet – “Provide lights-out management capabilities; or.”

Carl Pineault, Hydro-Qu?bec Production, 5, 8/30/2021

- 0 - 0

ACES feels the inclusion of “Configure an Electronic Security Perimeter” does not cover what is intended and leaves a gap.  We feel EACMS is a more inclusive term in place of ESP.  Use of EACMS instead of ESP would then include Intermediate Systems, which pose a risk if Management Interfaces are not protected.  This would then be consistent with the IRA definition.  

 

AEPC has signed on to ACES comments.

Jennifer Bray, Arizona Electric Power Cooperative, Inc., 1, 8/30/2021

- 0 - 0

Justin MacDonald, On Behalf of: Midwest Energy, Inc., , Segments 1

- 0 - 0

Steve Toosevich, NiSource - Northern Indiana Public Service Co., 1, 8/31/2021

- 0 - 0

CEHE does not agree with the new Management Interface definition, because it singles out a few Cyber Systems within the definition.  The definition should define what a Management Interface is, and the standards/requirements will pinpoint which Cyber Systems should be applied. 

CEHE proposes the following:

“A user interface, logical interface or dedicated physical port, excluding touch controls (e.g., power switch, touch panel, etc.), that is used to: control the processes of initializing, deploying, and configuring or lights-out management capabilities of Cyber Systems.”

Eli Rivera, On Behalf of: CenterPoint Energy Houston Electric, LLC, Texas RE, Segments NA - Not Applicable

- 0 - 0

Southwest Power Pool Standards Review Group (SSRG), Segment(s) 2, 9/4/2019

- 0 - 0

NCPA support the modified definition, but suggest the language out-of-band instead of lights-out, since it a more general industry term and associated with a particular vendor. 

Chris Carnesi, On Behalf of: Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6

- 0 - 0

SIGE does not agree with the new Management Interface definition, because it singles out a few Cyber Systems within the definition.  The definition should define what a Management Interface is, and the standards/requirements will pinpoint which Cyber Systems should be applied. 

SIGE proposes the following:

“A user interface, logical interface or dedicated physical port, excluding touch controls (e.g., power switch, touch panel, etc.), that is used to: control the processes of initializing, deploying, and configuring or lights-out management capabilities of Cyber Systems.”

Brian Tooley, On Behalf of: Southern Indiana Gas and Electric Co., RF, Segments 3, 5, 6

- 0 - 0

Joe Tarantino, On Behalf of: Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6

- 0 - 0

Texas RE recommends clarifying the definition of Management Interface.  It is unclear what the three terms user interface”, “dedicated physical port”, and “physical user interfaces mean.  Texas RE recommends the following definition:

 Management Interface: Any interface that is used to provide interactive electronic access and:

• Controls the processes of initializing, deploying, and configuring Shared Cyber Infrastructure; or

• Provide lights‐out management capabilities; or

• Configure an Electronic Security Perimeter

Rachel Coyne, Texas Reliability Entity, Inc., 10, 8/31/2021

- 0 - 0

Additional clarity is required around the concept of "user interfaces" that are in scope per the new definition vs. the physical user interfaces that are indicated as being out of scope.  This is a confusing and contradictory element of the definition.  The definition is very broad and would include interface ports such as PS2 mouse/keyboard ports.  It is not clear as to how practical considerations of such ports that have connected mice and keyboards for example would need to be protected per the CIP-005-8 proposed standard requirements to permit only needed and controlled communications to and from Management Interfaces and deny all other communications.  Alternatively, as an example, it is not clear from a practical sense of how, per CIP-007-7, one would prevent the sharing of the CPU and memory of keyboard/mouse user interface ports.

BC Hydro recommends changing the reference per the bullet "Provide lights-out management capabilities' within the definition of Management Interface to a more generic reference such as "out-of-band management capabilities" to meet the security intent instead of limiting to a particular type/brand.

BC Hydro, Segment(s) 3, 5, 1, 12/18/2018

- 0 - 0

SDG&E supports EEI Comments 

Bridget Silvia, Sempra - San Diego Gas and Electric, 3, 8/31/2021

- 0 - 0

MEAG Power adopts the Southern Company comments.

MEAG Power, Segment(s) 3, 1, 5, 6/15/2017

- 0 - 0

We support NPCC TFIST's comments as found below:

Request clarification of the second bullet – “Provide lights-out management capabilities; or.” Suggest using the old language instead of a vendor’s term. The old language was “an autonomous subsystem of a Cyber Asset or Shared Cyber Infrastructure that provides management and monitoring capabilities independently of the host system's CPU, firmware, and operating system.”

Request clarification of the term “out-of-band.” What is the out-of-band risk? What is the requirement addressing?

Gerry Adamski, Cogentrix Energy Power Management, LLC, 5, 8/31/2021

- 0 - 0

FE Voter, Segment(s) 1, 3, 5, 6, 4, 2/23/2021

- 0 - 0

OKGE supports EEI's comments. 

OKGE, Segment(s) 6, 1, 3, 5, 3/22/2021

- 0 - 0

Since the Glossary modifications are the foundation to all Standard changes, NERC should seek approval of the new terms prior to any changes being introduced in the Standards to reduce potential misunderstanding or misinterpretation of both the new definitions and modified Standards.  This will also allow NERC, and industry, time to determine additional courses of action, reduce confusion, and reduce additional risk associated with such wholesale changes.

Anthony Jablonski, ReliabilityFirst , 10, 8/31/2021

- 0 - 0

Darnez Gresham, Berkshire Hathaway Energy - MidAmerican Energy Co., 3, 8/31/2021

- 0 - 0

See MidAmerican Energy Company comments from Darnez Gresham.

Terry Harbour, Berkshire Hathaway Energy - MidAmerican Energy Co., 1, 8/31/2021

- 0 - 0

Cleco supports comments submitted by EEI.

Clay Walker, On Behalf of: Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6

- 0 - 0

In support of NPCC RSC comments.

Request clarification of the second bullet – “Provide lights-out management capabilities; or.” Suggest using the old language instead of a vendor’s term. The old language was “an autonomous subsystem of a Cyber Asset or Shared Cyber Infrastructure that provides management and monitoring capabilities independently of the host system's CPU, firmware, and operating system.”

Request clarification of the term “out-of-band.” What is the out-of-band risk? What is the requirement addressing?

 

The definition seems to be too specific, i.e. direct reference to SCI, LOM, and ESP. Why not a more generic and simple definition like  

A user interface, logical interface, or dedicated physical port that is used to control the processes of initializing, deploying, and configuring a cyber asset, excluding physical user interfaces (e.g., power switch, touch panel, etc.). 

Reference  

A user interface, logical interface, or dedicated physical port that is used to:  

•          Control the processes of initializing, deploying, and configuring Shared Cyber Infrastructure; or  

•          Provide lights‐out management capabilities; or  

•          Configure an Electronic Security Perimeter; excluding physical user interfaces (e.g., power switch, touch panel, etc.). 

Nicolas Turcotte, Hydro-Qu?bec TransEnergie, 1, 9/1/2021

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Daniel Gacek, Exelon, 1, 9/1/2021

- 0 - 0

AEP supports EEI comments and revised definition on “Management Interface”.  In addition, please see response to Question #14 related to nesting acronyms within definitions. The revised definition for SDT’s consideration reads:

“A user interface, logical interface or dedicated physical port, excluding touch controls (e.g., power switch, touch panel, etc.), that is used to: control the processes of initializing, deploying, and configuring or lights-out management capabilities of Cyber Systems.”

JT Kuehne, AEP, 6, 9/1/2021

- 0 - 0

Jamie Monette, On Behalf of: Allete - Minnesota Power, Inc., , Segments 1

- 0 - 0

Request clarification of the second bullet – “Provide lights-out management capabilities; or.” Suggest using the old language instead of a vendor’s term. The old language was “an autonomous subsystem of a Cyber Asset or Shared Cyber Infrastructure that provides management and monitoring capabilities independently of the host system's CPU, firmware, and operating system.”

Request clarification of the term “out-of-band.” What is the out-of-band risk? What is the requirement addressing?

 

The definition seems to be too specific, i.e. direct reference to SCI, LOM, and ESP. Why not a more generic and simple definition like  

A user interface, logical interface, or dedicated physical port that is used to control the processes of initializing, deploying, and configuring a cyber asset, excluding physical user interfaces (e.g., power switch, touch panel, etc.). 

Reference  

A user interface, logical interface, or dedicated physical port that is used to:  

•          Control the processes of initializing, deploying, and configuring Shared Cyber Infrastructure; or  

•          Provide lights‐out management capabilities; or  

•          Configure an Electronic Security Perimeter; excluding physical user interfaces (e.g., power switch, touch panel, etc.). 

Leonard Kula, Independent Electricity System Operator, 2, 9/1/2021

- 0 - 0

We agree with the Management Interface definition, but disagree with the language in the definition. In our view, the definition should focus on in CIP scope management interfaces. “Provide lights-out management capabilities” should be removed since this criterion cannot make a management interface to fall within CIP scope. Also, we suggest changing “configure ESP” to “configure EAP” and “configure EACMS” to address the zero-trust mode (See our comments in Q4). Also, the Management Interface definition only covers the Management Interface of a management system such as vCenter that configures and manage SCI while the Hypervisor Management Interface that initializes, deploys and configures VCAs is missing from the definition. Furthermore, the Management Interface should include managing non-ESP model based on our comments in Q4.

Recommendation:  We propose the following changes to Management Interface definition and rationale in Q1.

     

MRO NSRF, Segment(s) 2, 4, 1, 6, 3, 5, 7/1/2021

- 0 - 0

Amy Jones, Public Utility District No. 2 of Grant County, Washington, 5, 9/1/2021

- 0 - 0

Evergy incorporates by reference and endorses the comments as filed by the Edison Electric Institute.

Alan Kloster, On Behalf of: Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Kinte Whitehead, Exelon, 3, 9/1/2021

- 0 - 0

Amy Bratkovic, On Behalf of: PNM Resources - Public Service Company of New Mexico, , Segments 1, 3

- 0 - 0

No comment.

Dwanique Spiller, On Behalf of: Berkshire Hathaway - NV Energy - WECC - Segments 5

- 0 - 0

ISO-NE requests that a term other than "lights out" be used in the definition to avoid diffuclty with interpretation related to marketing language related to such products.  Please re-cast the definition related to "lights out" management interfaces with respect to the character of the functions supported by the interface and the potential for risk to Cyber Asset support for reliability functions.

John Galloway, On Behalf of: Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2

- 0 - 0

Tacoma Power, Segment(s) 1, 3, 4, 5, 6, 3/9/2021

- 0 - 0

GRE agrees with the comments submitted by the NSRF. 

Michael Brytowski, Great River Energy, 3, 9/1/2021

- 0 - 0

In support of IRC SRC/SWG.

Request clarification of the second bullet – “Provide lights-out management capabilities; or.” Suggest using the old language instead of a vendor’s term. The old language was “an autonomous subsystem of a Cyber Asset or Shared Cyber Infrastructure that provides management and monitoring capabilities independently of the host system's CPU, firmware, and operating system.”

Request clarification of the term “out-of-band.” What is the out-of-band risk? What is the requirement addressing?

Monika Montez, On Behalf of: California ISO, WECC, Segments 2

- 0 - 0

Nurul Abser, NB Power Corporation, 1, 9/1/2021

- 0 - 0

Agree with the modified Management Interface definition.

Donna Wood, Tri-State G and T Association, Inc., 1, 9/1/2021

- 0 - 0

Casey Jones, On Behalf of: Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5

- 0 - 0

Israel Perez, On Behalf of: Salt River Project, WECC, Segments 1, 3, 5, 6

- 0 - 0

The term lights-out management capabilities is unclear. Additionally, in our opinion it should be specified that individual BCA or PCAs only controlling access to themselves  (such as host-based firewalls) and their user interfaces do not classify as EACMs and Management Interfaces.

 

David Jendras, Ameren - Ameren Services, 3, 9/1/2021

- 0 - 0

We agree with the Management Interface definition, but disagree with the language in the definition. In our view, the definition should focus on in CIP scope management interfaces. “Provide lights-out management capabilities” should be removed since this criterion cannot make a management interface to fall within CIP scope. Also, we suggest changing “configure ESP” to “configure EAP” and “configure EACMS” to address the zero-trust mode (See our comments in Q4). Also, the Management Interface definition only covers the Management Interface of a management system such as vCenter that configures and manage SCI while the Hypervisor Management Interface that initializes, deploys and configures VCAs is missing from the definition. Furthermore, the Management Interface should include managing non-ESP model based on our comments in Q4.

Recommendation:  We propose the following changes to Management Interface definition and rationale in Q1.

Barry Jones, On Behalf of: sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6

- 0 - 0

Benjamin Winslett, Georgia System Operations Corporation, 4, 9/1/2021

- 0 - 0

Defining the Management Interface is good however documenting in the CIP-002 when used as part of the SCI should be clarified.  

Justin Welty, NextEra Energy - Florida Power and Light Co., 6, 9/1/2021

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Cynthia Lee, Exelon, 5, 9/1/2021

- 0 - 0

OPG concurs with NPCC's RSC comments

David Kwan, On Behalf of: Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Becky Webb, Exelon, 6, 9/1/2021

- 0 - 0

ACES feels the inclusion of “Configure an Electronic Security Perimeter” does not cover what is intended and leaves a gap.  We feel EACMS is a more inclusive term in place of ESP.  Use of EACMS instead of ESP would then include Intermediate Systems, which pose a risk if Management Interfaces are not protected.  This would then be consistent with the IRA definition. 

ACES Standard Collaborations, Segment(s) 1, 9/1/2021

- 0 - 0

Eversource 1, Segment(s) 3, 1, 9/1/2021

- 0 - 0

Karie Barczak, DTE Energy - Detroit Edison Company, 3, 9/1/2021

- 0 - 0

James Baldwin, Lower Colorado River Authority, 1, 9/1/2021

- 0 - 0

No comments

Maggy Powell, Amazon Web Services, 7, 9/1/2021

- 0 - 0

Southern disagrees with the addition of “Configure an Electronic Security Perimeter” to the Management Interface definition. With the definition of ESP being “a set of configurations or policies”, a Management Interface is something that configures a configuration that controls communications of any type at all.  See Q14 for an example of the issues caused by this construct.  Southern suggests that requirements be written that apply to BES Cyber Systems and separate requirements that set clear expectations around the use and administration of electronic access controls (and by extension PACS) and begin the process of moving away from an EACMS as a ‘device’ focus.

Southern Company, Segment(s) 1, 3, 6, 5, 1/14/2021

- 0 - 0

LCRA Compliance, Segment(s) 6, 5, 1, 5/11/2015

- 0 - 0

ERCOT supports the IRC SRC comments and offers this additional comment:

  • Please clarify whether the Management Interface includes configuration of BCSs and PCAs within the ESP.

Brandon Gleason, 9/1/2021

- 0 - 0

LeRoy Patterson, Public Utility District No. 2 of Grant County, Washington, 6, 9/1/2021

- 0 - 0

<duplicate>

Dana Showalter, On Behalf of: Electric Reliability Council of Texas, Inc., Texas RE, Segments 2

- 0 - 0

The revised definition does provide improvement over what was provided in the last draft, however, additional clarity to the intended meaning of Management Interface is still needed.  This may be possible through additional enhancements to the definition or through additional explanation/defining what a Management Interface is through the Rationale.  EEI offers the following revised definition:

“A user interface, logical interface or dedicated physical port, excluding touch controls (e.g., power switch, touch panel, etc.), that is used to: control the processes of initializing, deploying, and configuring or lights-out management capabilities of Cyber Systems.”

Mark Gray, On Behalf of: Edison Electric Institute, NA - Not Applicable, Segments NA - Not Applicable

- 0 - 0

Gail Golden, Entergy - Entergy Services, Inc., 5, 9/1/2021

- 0 - 0

Alyssia Rhoads, Public Utility District No. 1 of Snohomish County, 1, 9/1/2021

- 0 - 0

 

PJM signs on to the comments provided by the IRC SRC.

Elizabeth Davis, On Behalf of: Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2

- 0 - 0

Lindsay Wickizer, Berkshire Hathaway - PacifiCorp, 6, 9/1/2021

- 0 - 0

Sam Nietfeld, Public Utility District No. 1 of Snohomish County, 5, 9/1/2021

- 0 - 0

SNPD Voting Members, Segment(s) 4, 6, 5, 1, 6/18/2020

- 0 - 0

John Martinsen, Public Utility District No. 1 of Snohomish County, 4, 9/1/2021

- 0 - 0

John Liang, Snohomish County PUD No. 1, 6, 9/1/2021

- 0 - 0

Request clarification of the second bullet – “Provide lights-out management capabilities; or.” Suggest using the old language instead of a vendor’s term. The old language was “an autonomous subsystem of a Cyber Asset or Shared Cyber Infrastructure that provides management and monitoring capabilities independently of the host system's CPU, firmware, and operating system.”

Request clarification of the term “out-of-band.” What is the out-of-band risk? What is the requirement addressing?

 

The definition seems to be too specific, i.e. direct reference to SCI, LOM, and ESP. Why not a more generic and simple definition like  

A user interface, logical interface, or dedicated physical port that is used to control the processes of initializing, deploying, and configuring a cyber asset, excluding physical user interfaces (e.g., power switch, touch panel, etc.). 

Reference  

A user interface, logical interface, or dedicated physical port that is used to:  

•          Control the processes of initializing, deploying, and configuring Shared Cyber Infrastructure; or  

•          Provide lights‐out management capabilities; or  

•          Configure an Electronic Security Perimeter; excluding physical user interfaces (e.g., power switch, touch panel, etc.). 

NPCC Regional Standards Committee, Segment(s) 10, 2, 4, 7, 3, 1, 5, 6, 8/6/2021

- 0 - 0

Ryan Olson, Portland General Electric Co., 5, 9/1/2021

- 0 - 0

Roger Fradenburgh, On Behalf of: Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1

- 0 - 0

The IRC SRC requests the SDT clarify the second bullet under the Management Interface definition; i.e. “Provide lights-out management capabilities; or,” by replacing vendor terminology with language from the prior Management Module definition; i.e. “an autonomous subsystem of a Cyber Asset or Shared Cyber Infrastructure that provides management and monitoring capabilities independently of the host system's CPU, firmware, and operating system.”

Request clarification of the term “out-of-band.” What is the out-of-band risk? What is the requirement addressing?

ISO/RTO Council Standards Review Committee 2016-02 Virtualization (Draft 2), Segment(s) 2, 9/1/2021

- 0 - 0

ATC understands the intent of the SDT and the rationale for Management Interface; however, the concepts of Management Plane and Operational Plane were clearer.  While ATC appreciates the attempt to consolidate these terms and views Draft 2 as an improvement over Draft 1, ‘interface’ may be an overly broad term. The words ‘user interface’ are doing some heavy lifting and while the application interface and physical interface are performing the same “user interface” function, they really are very different things. There may be room for entities to misinterpret the current definition to their own peril.

  • Is the overall purpose to protect from lateral movement, or to protect from unauthorized access to a management system?
  • Is identity the primary perimeter?
    • Would it help if the SDT considered that concept when reassessing this definition and corresponding requirement language?
  • The communication channel from which management is performed must be segregated from the channel with which operational functions are performed. 

LaTroy Brumfield, American Transmission Company, LLC, 1, 9/1/2021

- 0 - 0

ITC supports the response submitted by EEI for this question.

Gail Elliott, On Behalf of: Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1

- 0 - 0

Hot Answers

Dan Zollner, Portland General Electric Co., 3, 9/1/2021

- 0 - 0

PGE FCD, Segment(s) 5, 1, 3, 6, 9/11/2018

- 0 - 0

Other Answers

Richard Jackson, U.S. Bureau of Reclamation, 1, 8/19/2021

- 0 - 0

Dominion, Segment(s) 3, 5, 1, 9/19/2019

- 0 - 0

Jeanne Kurzynowski, On Behalf of: CMS Energy - Consumers Energy Company - RF - Segments 3, 4, 5

- 0 - 0

Chelan agrees with the change to ESP, but disagrees with the notion that the new definition reduces the burden of documenting ESPs in a zero trust environment, rather it simply enables zero trust to even be an option.

CHPD, Segment(s) 3, 1, 6, 5, 8/24/2021

- 0 - 0

Glen Farmer, Avista - Avista Corporation, 5, 8/24/2021

- 0 - 0

NRG believes that the modified ESP definition reduces the burden of documenting ESPs in a zero trust environment.  However, the modified ESP definition over complicates the documentation of ESPs in a traditional, firewall-based environment.

Martin Sidor, NRG - NRG Energy, Inc., 6, 8/24/2021

- 0 - 0

NRG believes that the modified ESP definition reduces the burden of documenting ESPs in a zero trust environment.  However, the modified ESP definition over complicates the documentation of ESPs in a traditional, firewall-based environment.

Patricia Lynch, NRG - NRG Energy, Inc., 5, 8/24/2021

- 0 - 0

There is insufficient clarity provided within the proposed terms to ensure that consistent understanding of the construct of policy – e.g.: whether policy refers to technical control or procedural document.

Tennessee Valley Authority, Segment(s) 1, 3, 5, 6, 10/18/2018

- 0 - 0

Xcel Energy supports the comments of EEI.

Amy Casuscelli, On Behalf of: Xcel Energy, Inc. - MRO, WECC - Segments 1, 3, 5, 6

- 0 - 0

BPA agrees that this will reduce the burden of documenting ESPs in a zero trust environment. However, additional language is needed to address whether the drafting committee still intends for standalone networks that have no external connectivity to other networks (”standalone networks”) to have a defined ESP.

Option 1: If standalone networks DO NOT require an ESP, please update the Technical Rationale to address standalone networks (as was traditionally done in the TR for CIP-005-6 and CIP-005-7).

Option 2: If standalone networks DO still require an ESP, the proposed definition requires all ESPs to be “enforced by an EACMS;” this will add a high burden for standalone networks.  For example, a standalone ESP consisting of a local operator HMI (PCA, used for local review of SCADA alarms) connected to 2 local SCADA RTUs (BCAs) via a switch (PCA) would need to have an EACMS added in order to meet the letter of the requirement, but without gaining any security or protection.

(1)  Definition for Electronic Security Perimeter (ESP): A set of configurations or policies that controls communications to or from any part of a BES Cyber System. These configurations or policies group CIP Systems of the same impact rating and their associated PCAs.

Benefit: This would permit the isolated nature – or “configuration” – of the small local network to provide the control of communications to/from the BES Cyber System by simply excluding it.

(2)  Add an additional requirement under CIP-005-8 R1.1 [hypothetically referenced here as R “1.1-A” for numbering clarity] for the EACMS portion:

Requirement: 1.1-A

Applicable Systems: BCS with ERC and their associated PCA

Requirements: Utilize an EACMS to enforce the control of communications to or from any part of a BES Cyber System.

(3)  Related update is needed to correct the Applicable Systems in R2.1: “EACMS that enforces an ESP for the Applicable Systems in Part 1.1-A.”

(4)  Update the Technical Rationale (TR) to clarify for standalone networks (as was traditionally done in the TR for CIP-005-6 and CIP-005-7).

Andrea Jessup, On Behalf of: Bonneville Power Administration, WECC, Segments 1, 3, 5, 6

- 0 - 0

Mike Magruder, Avista - Avista Corporation, 1, 8/26/2021

- 0 - 0

Although Duke Energy disagrees with the inclusion of “policy” in the definition, the spirit of this modified definition provides explicit clarity that evolving security technologies can be used in compliance with the NERC CIP Standards and will assist Registered Entities and the ERO in documenting CIP-005 compliance with increasingly secure postures.

Katie Connor, On Behalf of: Duke Energy - SERC, RF - Segments 1, 3, 5, 6

- 0 - 0

AECI, Segment(s) 1, 3, 6, 5, 3/4/2021

- 1 - 0

See MRO-NSRF and EEI Comments

Clarice Zellmer, WEC Energy Group, Inc., 5, 8/26/2021

- 0 - 0

We agree with the modified ESP definition but are not sure it reduces the burden as entities will have to prove to auditors they are compliant and we don’t know at this point what audit evidence requests will look like. We would also like to point out that because the routable protocol qualifier was eliminated from the ESP definition, and changes to the CIP-005 R1 Part 1.1, serial connectivity in some cases has been brought into the scope of an ESP.  Refer to question #10 below.

Ronald Bender, Nebraska Public Power District, 5, 8/27/2021

- 0 - 0

We disagree based on the reasoning and alternative proposal outlined in question 4.

Josh Johnson, Lincoln Electric System, 1, 8/27/2021

- 0 - 0

Suggest removing ‘and their associated PCAs’ from the ESP definition as PCAs are already included in the CIP Systems definition.

  ‘These configurations or policies group CIP Systems of the same impact rating (and their associated PCAs) delete this.

WECC CIP, Segment(s) 10, 2/17/2021

- 0 - 0

William Steiner, Midwest Reliability Organization, 10, 8/30/2021

- 0 - 0

AZPS doesn’t understand how the use of “configurations or policy” in the modified ESP definition can reduce the burden of documenting ESPs in a zero trust environment.

Marcus Bortman, APS - Arizona Public Service Co., 6, 8/30/2021

- 0 - 0

While Zero Trust and it’s assumption of assuming no network edge is an excellent security approach, it is necessary to ensure that a discrete boundary defines the edge of the auditable network.  The current definitions significantly blur this border introducing uncertainty into what will be audited under the CIP standards and introduces opportunity for significantly different viewpoints between auditors and entities regarding  the boundary of what will be subject to NERC compliance standards.  We support adopting definitions and standards that support virtualization.  However until this is resolved, it will be impossible to support the revised standards.  We recommending basing the new definition around the previous definition of an ESP as it has a defined border.

Susan Sosbe, On Behalf of: Wabash Valley Power Association, , Segments 1, 3

- 0 - 0

Carl Pineault, Hydro-Qu?bec Production, 5, 8/30/2021

- 0 - 0

ACES feels no matter how zero trust environments are implemented, the policy (ies) or configurations will be highly complex and exponentially more difficult to prove strict compliance, thus increasing compliance burden.  Additionally on the latest webinar, it was discussed each policy enforcement point would be an EACMS.  In a Cisco based SDN, each switch port, switch port group, VLAN, or switch has an enforcement policy applied to it from the policy server, increasing the number of EACMS significantly, therefore increasing compliance burden. 

Another issue will be varying technology compared to firewall rules/ACL as used today.  This will make auditing extremely complex and require an auditor to have significant knowledge of varying SDN/zero trust products to be able to accurately audit. 

 

AEPC has signed on to ACES comments.

Jennifer Bray, Arizona Electric Power Cooperative, Inc., 1, 8/30/2021

- 0 - 0

We are not sure it reduces the burden as entities will have to prove to auditors they are compliant and we don’t know at this point what audit evidence requests will look like. We also wish to verify that knowledge of the TR is not necessary for understanding or complying with the proposed revisions to CIP-005-X R1.

Justin MacDonald, On Behalf of: Midwest Energy, Inc., , Segments 1

- 0 - 0

Steve Toosevich, NiSource - Northern Indiana Public Service Co., 1, 8/31/2021

- 0 - 0

CEHE proposed an ESP definition in response to question #4.  However, it maintained the SDT approach on the use of configurations or policy.  This does seem to have the potential of reducing the burden of documenting ESPs in a zero-trust environment.

Eli Rivera, On Behalf of: CenterPoint Energy Houston Electric, LLC, Texas RE, Segments NA - Not Applicable

- 0 - 0

Southwest Power Pool Standards Review Group (SSRG), Segment(s) 2, 9/4/2019

- 0 - 0

NCPA supports most of the definition change, however “policies” are a vague reference.  NCPA proposes using the phrase “technical policies” as to not confuse them with administrative policies. 

Chris Carnesi, On Behalf of: Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6

- 0 - 0

SIGE proposed an ESP definition in response to question #4.  However, it maintained the SDT approach on the use of configurations or policy.  This does seem to have the potential of reducing the burden of documenting ESPs in a zero-trust environment.

Brian Tooley, On Behalf of: Southern Indiana Gas and Electric Co., RF, Segments 3, 5, 6

- 0 - 0

Joe Tarantino, On Behalf of: Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6

- 0 - 0

Texas RE recommends registered entities continue documenting ESPs in order to demonstrate compliance and show evidence of configuration of a zero-trust environment.

Rachel Coyne, Texas Reliability Entity, Inc., 10, 8/31/2021

- 0 - 0

While it may be the SDT's intent to reduce ESP documentation burden for entities employing Zero Trust environments, the language of the standards themselves do not reduce any such documentation burden pertaining to ESPs.  In fact, the requirements still require ESPs to be implemented. 

BC Hydro recommends adding clarifying language around documentation expectations when Zero Trust environments are implemented vs. traditional firewall bounded ESPs.

BC Hydro, Segment(s) 3, 5, 1, 12/18/2018

- 0 - 0

SDG&E supports EEI Comments 

Bridget Silvia, Sempra - San Diego Gas and Electric, 3, 8/31/2021

- 0 - 0

MEAG Power adopts the Southern Company comments.

MEAG Power, Segment(s) 3, 1, 5, 6/15/2017

- 0 - 0

We support NPCC TFIST's comments as found below:

We agree with the modified ESP definition. We do not agree this change reduces the documentation burden of ESPs in a zero-trust environment.

Gerry Adamski, Cogentrix Energy Power Management, LLC, 5, 8/31/2021

- 0 - 0

FE Voter, Segment(s) 1, 3, 5, 6, 4, 2/23/2021

- 0 - 0

OKGE supports EEI's comments. 

OKGE, Segment(s) 6, 1, 3, 5, 3/22/2021

- 0 - 0

Since the Glossary modifications are the foundation to all Standard changes, NERC should seek approval of the new terms prior to any changes being introduced in the Standards to reduce potential misunderstanding or misinterpretation of both the new definitions and modified Standards.  This will also allow NERC, and industry, time to determine additional courses of action, reduce confusion, and reduce additional risk associated with such wholesale changes.

Anthony Jablonski, ReliabilityFirst , 10, 8/31/2021

- 0 - 0

Darnez Gresham, Berkshire Hathaway Energy - MidAmerican Energy Co., 3, 8/31/2021

- 0 - 0

See MidAmerican Energy Company comments from Darnez Gresham.

Terry Harbour, Berkshire Hathaway Energy - MidAmerican Energy Co., 1, 8/31/2021

- 0 - 0

Cleco supports comments submitted by EEI.

Clay Walker, On Behalf of: Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6

- 0 - 0

In support of NPCC RSC comments. 

We agree with the modified ESP definition. We do not agree this change reduces the documentation burden of ESPs in a zero-trust environment.

 

Looking solely at the definition of ESP, the old definition required to simply produce a list of assets in a boundary, this resulted in a large ESP. Establishing these ESP was easy and there were only one criteria to evaluate (connected using a routable protocol), overall (less burden). The suggested definition permits potentially smaller ESP, so more ESP, but those ESPs come with more controls, i.e., configurations or policies enforced and EACMS. With the new definition, the burden of the demonstration is more. 

The ideas behind the new definition are interesting and they could facilitate the instauration of a zero-trust environment, but those ideas don’t lessen the burden of compliance demonstrations. 

Reference:  

Old Definition: The logical border surrounding a network to which BES Cyber Systems are connected using a routable protocol. 

Suggested Definition: A set of configurations or policies enforced by an EACMS that controls communications to or from any part of a BES Cyber System. These configurations or policies group CIP Systems of the same impact rating and their associated PCAs.

Nicolas Turcotte, Hydro-Qu?bec TransEnergie, 1, 9/1/2021

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Daniel Gacek, Exelon, 1, 9/1/2021

- 0 - 0

AEP agrees with EEI’s concern that it is unclear how the use of the terms “configuration or policy” reduces the burden of documenting ESPs in a zero trust environment. AEP also supports EEI’s recombination on providing additional clarity and examples. In addition, AEP suggests the removal of the second sentence in the proposed ESP definition as noted in response to Question #4 above.

JT Kuehne, AEP, 6, 9/1/2021

- 0 - 0

Minnesota Power has no experience with zero trust environments and has no feedback.

Jamie Monette, On Behalf of: Allete - Minnesota Power, Inc., , Segments 1

- 0 - 0

We agree with the modified ESP definition. We do not agree this change reduces the documentation burden of ESPs in a zero-trust environment.

 

Looking solely at the definition of ESP, the old definition required to simply produce a list of assets in a boundary, this resulted in a large ESP. Establishing these ESP was easy and there were only one criteria to evaluate (connected using a routable protocol), overall (less burden). The suggested definition permits potentially smaller ESP, so more ESP, but those ESPs come with more controls, i.e., configurations or policies enforced and EACMS. With the new definition, the burden of the demonstration is more. 

The ideas behind the new definition are interesting and they could facilitate the instauration of a zero-trust environment, but those ideas don’t lessen the burden of compliance demonstrations. 

Reference:  

Old Definition: The logical border surrounding a network to which BES Cyber Systems are connected using a routable protocol. 

Suggested Definition: A set of configurations or policies enforced by an EACMS that controls communications to or from any part of a BES Cyber System. These configurations or policies group CIP Systems of the same impact rating and their associated PCAs.

Leonard Kula, Independent Electricity System Operator, 2, 9/1/2021

- 0 - 0

MRO NSRF, Segment(s) 2, 4, 1, 6, 3, 5, 7/1/2021

- 0 - 0

Amy Jones, Public Utility District No. 2 of Grant County, Washington, 5, 9/1/2021

- 0 - 0

Evergy incorporates by reference and endorses the comments as filed by the Edison Electric Institute.

Alan Kloster, On Behalf of: Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Kinte Whitehead, Exelon, 3, 9/1/2021

- 0 - 0

Yes, although PNMR appreciates EEI suggestion regarding "...clarity and examples describing how the use of “configuration or policy” language in this definition reduces the current burdens of documenting ESPs."

Amy Bratkovic, On Behalf of: PNM Resources - Public Service Company of New Mexico, , Segments 1, 3

- 0 - 0

No comment.

Dwanique Spiller, On Behalf of: Berkshire Hathaway - NV Energy - WECC - Segments 5

- 0 - 0

John Galloway, On Behalf of: Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2

- 0 - 0

Tacoma Power, Segment(s) 1, 3, 4, 5, 6, 3/9/2021

- 0 - 0

GRE has not seen how the modified ESP definition can reduce the burden of documenting ESPs in a zero-trust environment (see NSRF comments in Q4). Given that a zero-trust environment in virtualization layer is a non-ESP topology and ESP drawings are not needed, there is no compliance burden reduction. Resulting from our comments in Q4, the zero-trust model can be resolved by adding an alternative requirement in CIP-005 R1.1.

Michael Brytowski, Great River Energy, 3, 9/1/2021

- 0 - 0

In support of IRC SRC/SWG.

We agree with the modified ESP definition. We do not agree this change reduces the documentation burden of ESPs in a zero-trust environment.

 

Monika Montez, On Behalf of: California ISO, WECC, Segments 2

- 0 - 0

Nurul Abser, NB Power Corporation, 1, 9/1/2021

- 0 - 0

We agree with the modified ESP definition but are not sure it reduces the burden as entities will have to prove to auditors they are compliant and we don’t know at this point what audit evidence requests will look like. We would also like to point out that because the routable protocol qualifier was eliminated from the ESP definition, and changes to the CIP-005 R1 Part 1.1, serial connectivity in some cases has been brought into the scope of an ESP.

Donna Wood, Tri-State G and T Association, Inc., 1, 9/1/2021

- 0 - 0

Casey Jones, On Behalf of: Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5

- 0 - 0

Regardless of which direction we go in will always have a burden - and again each entity will still have to show the auditors we are compliant. Depending on the auditor and their intreption of the requirement - can become burdensome. We don’t understand the zero trust environment as defined.

Israel Perez, On Behalf of: Salt River Project, WECC, Segments 1, 3, 5, 6

- 0 - 0

We are concerned that in hybrid environments with traditional firewalls AND zero-trust or host-based firewall applications, the new definitions of ESP and EACMs could create a burden to industry by requiring additional protections (such as encryption and multifactor authentication) on communications between devices that are already protected inside an ESP by a traditional firewall, and actually discourages the use of multi-layered protection.

David Jendras, Ameren - Ameren Services, 3, 9/1/2021

- 0 - 0

We haven’t seen the modified ESP definition can reduce the burden of documenting ESPs in a zero-trust environment (see our comments in Q4). Given that a zero-trust environment in virtualization layer is a non-ESP topology and ESP drawings are not needed, there is no compliance burden reduction. Resulting from our comments in Q4, the zero-trust model can be resolved by adding an alternative requirement in CIP-005 R1.1.

Barry Jones, On Behalf of: sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6

- 0 - 0

Benjamin Winslett, Georgia System Operations Corporation, 4, 9/1/2021

- 0 - 0

  • The ESP definition enables virtualization and logical boundaries but is not really going to reduce the documentation load.  Zero trust will require documentation of where controls are applied including locations.

  • The IP to serial conversion for ERC and IRA appears to require additional documentation beyond the ESP.  Please clarify how Entities are expected to document the logical boundaries beyond the ESP for serial devices.

Justin Welty, NextEra Energy - Florida Power and Light Co., 6, 9/1/2021

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Cynthia Lee, Exelon, 5, 9/1/2021

- 0 - 0

OPG concurs with NPCC's RSC comments

David Kwan, On Behalf of: Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Becky Webb, Exelon, 6, 9/1/2021

- 0 - 0

ACES feels no matter how zero trust environments are implemented, the policy (ies) or configurations will be highly complex and exponentially more difficult to prove strict compliance, thus increasing compliance burden.  Additionally on the latest webinar, it was discussed each policy enforcement point would be an EACMS.  In a Cisco based SDN, each switch port, switch port group, VLAN, or switch has an enforcement policy applied to it from the policy server, increasing the number of EACMS significantly, therefore increasing compliance burden. 

Another issue will be varying technology compared to firewall rules/ACL as used today.  This will make auditing extremely complex and require an auditor to have significant knowledge of varying SDN/zero trust products to be able to accurately audit. 

ACES Standard Collaborations, Segment(s) 1, 9/1/2021

- 0 - 0

Eversource agrees with the modified ESP definition, however, Eversource does not agree this change reduces the documentation burden of ESPs in a zero-trust environment.

Eversource 1, Segment(s) 3, 1, 9/1/2021

- 0 - 0

Karie Barczak, DTE Energy - Detroit Edison Company, 3, 9/1/2021

- 0 - 0

James Baldwin, Lower Colorado River Authority, 1, 9/1/2021

- 0 - 0

AWS supports the implementation of zero-trust architectures in fulfilling the security objectives of the NERC CIP Standards, but is seeking clarity on the assertion that the use of configurations or policies in the modified ESP definition can reduce the burden of documenting ESPs in a zero-trust environment. In a zero-trust environment the ESPs implemented by a Responsible Entity become more granular increasing the compliance documentation needed to support each policy or set of policies applied.

Maggy Powell, Amazon Web Services, 7, 9/1/2021

- 0 - 0

Southern agrees with the focus on network access policies rather than strictly network subnets (while not disallowing it) as things progress towards zero trust.  However, as more fully stated in Q4, the phrase “that control communications” is overly broad and the ESP definition has nothing that scopes it to network communications.

Southern Company, Segment(s) 1, 3, 6, 5, 1/14/2021

- 0 - 0

LCRA Compliance, Segment(s) 6, 5, 1, 5/11/2015

- 0 - 0

ERCOT supports the IRC SRC comments. 

Brandon Gleason, 9/1/2021

- 0 - 0

LeRoy Patterson, Public Utility District No. 2 of Grant County, Washington, 6, 9/1/2021

- 0 - 0

<duplicate>

Dana Showalter, On Behalf of: Electric Reliability Council of Texas, Inc., Texas RE, Segments 2

- 0 - 0

It is unclear how the use of the terms “configuration or policy” reduces the overall burden of documenting ESPs in a zero-trust environment.  Zero trust is not used under the current definition of ESPs within a substation environment and for those entities that plan to continue using traditional firewalls, their processes for maintaining documentation will remain unchanged.  For this reason, EEI requests additional clarity and examples describing how the use of “configuration or policy” language in this definition reduces the current burdens of documenting ESPs.   

Mark Gray, On Behalf of: Edison Electric Institute, NA - Not Applicable, Segments NA - Not Applicable

- 0 - 0

Gail Golden, Entergy - Entergy Services, Inc., 5, 9/1/2021

- 0 - 0

Alyssia Rhoads, Public Utility District No. 1 of Snohomish County, 1, 9/1/2021

- 0 - 0

 

PJM signs on to the comments provided by the IRC SRC.

Elizabeth Davis, On Behalf of: Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2

- 0 - 0

Lindsay Wickizer, Berkshire Hathaway - PacifiCorp, 6, 9/1/2021

- 0 - 0

Sam Nietfeld, Public Utility District No. 1 of Snohomish County, 5, 9/1/2021

- 0 - 0

SNPD Voting Members, Segment(s) 4, 6, 5, 1, 6/18/2020

- 0 - 0

John Martinsen, Public Utility District No. 1 of Snohomish County, 4, 9/1/2021

- 0 - 0

John Liang, Snohomish County PUD No. 1, 6, 9/1/2021

- 0 - 0

We agree with the modified ESP definition. We do not agree this change reduces the documentation burden of ESPs in a zero-trust environment.

 

Looking solely at the definition of ESP, the old definition required to simply produce a list of assets in a boundary, this resulted in a large ESP. Establishing these ESP was easy and there were only one criteria to evaluate (connected using a routable protocol), overall (less burden). The suggested definition permits potentially smaller ESP, so more ESP, but those ESPs come with more controls, i.e., configurations or policies enforced and EACMS. With the new definition, the burden of the demonstration is more. 

The ideas behind the new definition are interesting and they could facilitate the instauration of a zero-trust environment, but those ideas don’t lessen the burden of compliance demonstrations. 

Reference:  

Old Definition: The logical border surrounding a network to which BES Cyber Systems are connected using a routable protocol. 

Suggested Definition: A set of configurations or policies enforced by an EACMS that controls communications to or from any part of a BES Cyber System. These configurations or policies group CIP Systems of the same impact rating and their associated PCAs.

NPCC Regional Standards Committee, Segment(s) 10, 2, 4, 7, 3, 1, 5, 6, 8/6/2021

- 0 - 0

Ryan Olson, Portland General Electric Co., 5, 9/1/2021

- 0 - 0

Roger Fradenburgh, On Behalf of: Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1

- 0 - 0

The IRC SRC agrees with the modified ESP definition; however, we disagree this change will reduce the burden of documenting ESPs in a zero-trust environment.

ISO/RTO Council Standards Review Committee 2016-02 Virtualization (Draft 2), Segment(s) 2, 9/1/2021

- 0 - 0

LaTroy Brumfield, American Transmission Company, LLC, 1, 9/1/2021

- 0 - 0

ITC supports the response submitted by EEI for this question.

Gail Elliott, On Behalf of: Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1

- 0 - 0

Hot Answers

Portland General Electric Company supports the comments provided by EEI for this survey question. Additionally, Portland General Electric Company has concerns regarding the Interactive Remote Access (IRA) defintion. In the second bullet of the definition, the clause "to a Cyber System not within an Electronic Security Perimeter" implies that IRA can exist in scenarios where a person has no intent of remotely connecting to a BES Cyber System or PCA. The proposed definition of a Cyber System includes any number of Cyber Assets, Virtual Cyber Assets, or Shared Cyber Infrastructure that may be either CIP or non-CIP. If an individual was remotely communicating through a protocol converter to a device like a PACS, EACMS, or non-CIP Cyber Asset existing outside the ESP, that would be considered IRA under the current definition even if those systems didn't have connectivity to a BES Cyber System. Portland General Electric Company believes changing the clause to "to a BES Cyber System not within an Electronic Security Perimeter" achieves the objective of controlling IRA to BES Cyber Assets that are serially connected to the BES Cyber System.

Dan Zollner, Portland General Electric Co., 3, 9/1/2021

- 0 - 0

PGE FCD, Segment(s) 5, 1, 3, 6, 9/11/2018

- 0 - 0

Other Answers

Richard Jackson, U.S. Bureau of Reclamation, 1, 8/19/2021

- 0 - 0

Please see the response in Q14.

Dominion, Segment(s) 3, 5, 1, 9/19/2019

- 0 - 0

Jeanne Kurzynowski, On Behalf of: CMS Energy - Consumers Energy Company - RF - Segments 3, 4, 5

- 0 - 0

The definition of PCA is problematic.  The first is the general issue with the CPU/memory affinity requirements.  For details on this, see comments in Q14.  The PCA definition has a specific problem however.  It essentially places a requirement inside a definition.  The implicit requirement is that a BES Cyber Asset cannot share CPU/memory with a non-BCS of the same impact rating or a Protected Cyber Asset..  This is similar to the problem the current standards have with the definition of IRA having a requirement in it.  If the SDT wishes this to be an auditable requirement, they should place the requirement within the standards and not within the glossary of terms.

CHPD, Segment(s) 3, 1, 6, 5, 8/24/2021

- 0 - 0

Glen Farmer, Avista - Avista Corporation, 5, 8/24/2021

- 0 - 0

As articulated in greater detail above in response to previous questions, NRG disagrees with several of the proposed changes to the NERC Glossary terms.

Martin Sidor, NRG - NRG Energy, Inc., 6, 8/24/2021

- 0 - 0

As articulated in greater detail above in response to previous questions, NRG disagrees with several of the proposed changes to the NERC Glossary terms

Patricia Lynch, NRG - NRG Energy, Inc., 5, 8/24/2021

- 0 - 0

The SDT should consider NIST based approaches focused on defined outcomes instead of being prescriptive based on existing technologies.

Tennessee Valley Authority, Segment(s) 1, 3, 5, 6, 10/18/2018

- 0 - 0

Xcel Energy supports the comments of EEI.

Amy Casuscelli, On Behalf of: Xcel Energy, Inc. - MRO, WECC - Segments 1, 3, 5, 6

- 0 - 0

Andrea Jessup, On Behalf of: Bonneville Power Administration, WECC, Segments 1, 3, 5, 6

- 0 - 0

Mike Magruder, Avista - Avista Corporation, 1, 8/26/2021

- 0 - 0

Duke has a number of definition concerns that are enumerated in response to the specific questions where the definition is relevant.  In addition to those concerns, Duke Energy believes the following definition changes are required for the successful implementation of 2016-02’s goals:

CIP System – Duke Energy suggests removal of TCAs from this collection of other device types to ensure that there are no inadvertent changes to scoping that historically excluded TCA devices (e.g. list of Cyber Assets to be included on the ERT CA tab).

PACS/EACMS – definitions do not take advantage of the new Cyber System definition

Cyber System – Duke Energy suggests that the inclusion of the term group here may provide an auditor basis to expect REs to actively group things that otherwise would be passively addressed.  Additionally, it would be helpful to clarify that Cyber Systems are not necessarily in CIP scope.  Suggested language is as follows: One or more Cyber Assets, Virtual Cyber Assets, or Shared Cyber Infrastructure.  Cyber Systems may or may not receive one or more NERC CIP classifications.

ESP – Duke notes that the proposed definition for ESP drops the term “boundary” which was helpful in ensuring that auditors correctly evaluated this term.  We propose to add this concept back in a manner that supports future interpretation of how a boundary may be implemented.  This helps to ensure that dependent definitions (e.g. PCA use of “within”) remain compatible with this iteration of the standards.  Duke’s proposed definition is repeated from Question 4 here: “A set of configurations enforced by an EACMS that creates a logical boundary where communications to or from any part of a BES Cyber System and any PCA or SCIG associated with a BES Cyber System are controlled.  All BCS, PCA, and SCIG included in an ESP have the same impact rating as the highest included device.  The EACMS enforcing the ESP may not be part of a BES Cyber System.”

Katie Connor, On Behalf of: Duke Energy - SERC, RF - Segments 1, 3, 5, 6

- 0 - 0

AECI agrees with the new and revised several defined terms; however, the CIP standard are becoming increasingly difficult to understand and implement appropriately. 

AECI, Segment(s) 1, 3, 6, 5, 3/4/2021

- 1 - 0

See MRO-NSRF and EEI Comments

Clarice Zellmer, WEC Energy Group, Inc., 5, 8/26/2021

- 0 - 0

The definitions on their own are acceptable. 

Ronald Bender, Nebraska Public Power District, 5, 8/27/2021

- 0 - 0

We disagree based on the reasoning and alternative proposal outlined in question 4.

Josh Johnson, Lincoln Electric System, 1, 8/27/2021

- 0 - 0

Suggest removing 'by a Responsible Entity’ from the following definitions as it is implied or already stated in parent requirements.

BCS - One or more BES Cyber Assets logically grouped to perform one or more reliability tasks for a functional entity, including Shared Cyber Infrastructure grouped in the BES Cyber System it supports.

CIP System - A Cyber System identified as a BES Cyber System, Electronic Access Control or Monitoring System, Physical Access Control System, Shared Cyber Infrastructure, Protected Cyber Asset, or Transient Cyber Asset.

PACS - Cyber Assets, Virtual Cyber Assets, or Shared Cyber Infrastructure (SCI) (including SCI grouped in the Physical Access Control Systems it supports) that control, alert, or log access to the Physical Security Perimeter(s), exclusive of locally mounted hardware or devices at the Physical Security Perimeter such as motion sensors, electronic lock control mechanisms, and badge readers.

WECC CIP, Segment(s) 10, 2/17/2021

- 0 - 0

CIP System – The definition contains an implicit requirement for entities to identify CIP Cyber Systems.  The definition should not leave it up to the entity to make this identification, it should be criteria-based to include all of the described types of CAs.  Alternate proposal: A BES Cyber System and all associated Electronic Access Control or Monitoring Systems, Physical Access Control Systems, Shared Cyber Infrastructure, Protected Assets, and Transient Cyber Assets.

Transient Cyber Asset – The use of ‘network within an Electronic Security Perimeter’ no longer works with the new definition of ESP.  Alternate proposal: replace ‘network within an Electronic Security Perimeter’ with ‘network protected by an Electronic Security Perimeter’.  (Even though the ESP definition no longer includes ‘network’, it is reasonable that a network could be protected by an ESP protecting all BCAs on that network.)

Removeable Media - The use of ‘network within an Electronic Security Perimeter’ no longer works with the new definition of ESP.  Alternate proposal: replace ‘network within an Electronic Security Perimeter’ with ‘network protected by an Electronic Security Perimeter’.  (Even though the ESP definition no longer includes ‘network’, it is reasonable that a network could be protected by an ESP protecting all BCAs on that network.)

William Steiner, Midwest Reliability Organization, 10, 8/30/2021

- 0 - 0

AZPS does not agree with all changes to the NERC Glossary terms.  AZPS agrees with the concerns included in EEIs comments filed in this matter regarding Cyber Assets and Virtual Cyber Assets.  

Cyber Assets – This term should revert back to its original singular form.  While the definition refers to programmable electronic devices, the term remains singular in form and intent.  This change would also harmonize with the new definition for Virtual Cyber Asset, which is not pluralized. 

Virtual Cyber Asset (VCA) – The current definition is unclear and possibly unnecessary given the intent is to simply provide an equivalent virtualized term for a Cyber Asset, which is not a system but a programmable electronic device.  If the SDT believes this term is necessary, we suggest the following:

“A logical instance of a programmable device, including the software and data, hosted on Shared Cyber Infrastructure or a PCA.”

Marcus Bortman, APS - Arizona Public Service Co., 6, 8/30/2021

- 0 - 0

We support adopting definitions and standards that support virtualization.  However, it will be impossible to support the revised standards without a clearly defined demarcation of the auditable network infrastructure.  We do not have a reasonable recommendation to meet this need using the current approach to the proposed CIP standards.  The important items to consider are ensuring defined borders that clearly identify what is in and out of scope of the definitions, ensuring that a company that is implementing currently acceptable virtualization approach with high watermarking does not have extensive changes to their CIP programs, no inadvertent changes to compliance standards, and ensuring definitions that clearly separate hosts and guests within virtualization.

Susan Sosbe, On Behalf of: Wabash Valley Power Association, , Segments 1, 3

- 0 - 0

Need to define/clarify “asset” in the definition of ERC,

  Need clarification for the IRA definition (second bullet point is not clear)

  Need clarification for “identified independently” in the definition of SCI

 “CIP System” Definition – Transient Cyber Asset (TCA) should not be seen as a part of any system. A TCA is an asset connected to a system for a limited period of time. If it has to be seen as a part of a system, it is no longer a TCA. Also, this term is, in some ways, redundant compared to BCS. Even if “CIP System” designates any group of assets under CIP requirements, TCA cannot be seen as a “system”. It is an asset.

“Cyber System” Definition – Very confusing regarding “CIP System” and “BCS” definitions. Need more precisions or details about the context and when those definitions are used.

Carl Pineault, Hydro-Qu?bec Production, 5, 8/30/2021

- 0 - 0

ACES agrees with the added and modified terms except where noted in the responses to the questions in this comment form.

 

AEPC signed on to ACES comments.

Jennifer Bray, Arizona Electric Power Cooperative, Inc., 1, 8/30/2021

- 0 - 0

Individually each new or revised term is acceptable. On the whole, however, it makes for a somewhat confusing “alphabet soup” of acronyms which only those with past experience in these technologies are easily able to tell apart or know which term is the appropriate one to use for which compliance tasks. The multiple new terms confuse efforts to comply and thus entail, even if only minor, more compliance risk rather than less. Further, it is not clear why all these terms are needed if we have an acceptable definition for Virtual Cyber Asset and a revised definition of BES Cyber System that includes Virtual Cyber Assets. We recommend the SDT review the definitions again to determine if few terms are needed and, if a new term is needed, to provide further clarity on what it addresses that other definitions do not.

Justin MacDonald, On Behalf of: Midwest Energy, Inc., , Segments 1

- 0 - 0

Several of the terms and their usage, especially SCI, lends ambiguity with their use in the Standards. Further clarifications and refinements of the terms should be given attention.

Steve Toosevich, NiSource - Northern Indiana Public Service Co., 1, 8/31/2021

- 0 - 0

CEHE has listed below terms not previously covered by the questions above.

CIP System – Agree

Cyber Assets – Agree

Cyber System – Agree

EACMS – Agree.

EAP – Agree.

Intermediate Systems - Agree.

PACS – Agree

PCA – Agree

SCI – Agree

TCA – Agree

VCA – Since a VCA is a logical instance of a Cyber Asset it seems that the VCA definition should be like the Cyber Asset definition.  The current proposed VCA definition is radically different than the Cyber Asset definition.  For that reason, CEHE proposes:

“A logical instance of a programmable device, including the software and data, hosted on Shared Cyber Infrastructure or a PCA.”

Eli Rivera, On Behalf of: CenterPoint Energy Houston Electric, LLC, Texas RE, Segments NA - Not Applicable

- 0 - 0

Southwest Power Pool Standards Review Group (SSRG), Segment(s) 2, 9/4/2019

- 0 - 0

NCPA supports the proposed changes to IRA and Management Interface, however all others we do not support, please see comments above.  

Chris Carnesi, On Behalf of: Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6

- 0 - 0

SIGE has listed below terms not previously covered by the questions above.

CIP System – Agree

Cyber Assets – Agree

Cyber System – Agree

EACMS – Agree.

EAP – Agree.

Intermediate Systems - Agree.

PACS – Agree

PCA – Agree

SCI – Agree

TCA – Agree

VCA – Since a VCA is a logical instance of a Cyber Asset it seems that the VCA definition should be like the Cyber Asset definition.  The current proposed VCA definition is radically different than the Cyber Asset definition.  For that reason, SIGE proposes:

“A logical instance of a programmable device, including the software and data, hosted on Shared Cyber Infrastructure or a PCA.”

Brian Tooley, On Behalf of: Southern Indiana Gas and Electric Co., RF, Segments 3, 5, 6

- 0 - 0

The CIP standards as currently written are sufficient to accommodate virtualization based on security objectives.  The proposed changes to the standards are overly prescriptive and difficult to understand.  The previous proposed revision of the standards by this Project also adequately expanded the potential use of virtualization without removing backwards compatibility. Such drastic changes will be difficult to comply with and pose a security risk to the grid as time is taken away from practicing security and applied towards implementing overyly prescriptive compliance requirements that seem to be a hall of mirrors. 

Joe Tarantino, On Behalf of: Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6

- 0 - 0

Texas RE recommends revising the definition of Shared Cyber Infrastructure (SCI) to indicate that SCI inherit the impact categorizations of all hosted VCAs.  For example, the VCA definition states “A logical instance of an operating system or firmware hosted on Shared Cyber Infrastructure or a PCA.” Also, the BCA definition includes “…or Virtual Cyber Asset..”  This could lead to interpretations that PCAs can host BCAs.

 

The proposed definition for Protected Cyber Asset is written in a way where Virtual Cyber Assets may be out of scope for security requirements despite being hosted on SCI that host critical systems, such as high impact BCS.  These VCAs will hereafter be referred to as non-CIP VCAs.  These non-CIP VCAs would not be required to be protected by an ESP pursuant to CIP-005 R1.1 and as such permitting any and all network traffic to them would be permissible.  Additionally, as these non-CIP VCAs would not meet the definition of an applicable system in CIP-005 R1.1 then CIP-005 R1.3 would not apply and communications between the non-CIP VCAs and the SCI hosting them would be also permissible.

 

Texas RE notes that if there are security concerns related to network communications between CIP VCAs and their hosting SCI then these same concerns should be present for network communications between non-CIP VCAs and their hosting SCI.  Texas RE proposes that the portion of the PCA definition “Share CPU or memory with any part of a BES Cyber System,” be revised to “Share CPU or memory with any part of a BES Cyber System or Shared Cyber Infrastructure,”

 

Texas RE seeks clarity around the description of the definition of Intermediate System in the Definitions and Exemptions technical rationale document.  For the definition of Intermediate System, the “Definitions and Exemptions” technical rationale document states that requirement language has been removed from the definition.  The specific example of where the Intermediate System must reside was provided, as the current definition of Intermediate System prevents Intermediate Systems from being located within ESPs.  The technical rationale then goes on to say that such language has been moved to a mandatory requirement within CIP-005 R2.  Texas RE believes this statement is a reference to CIP-005 R2.6.2.

 

Texas RE seeks clarity around this concept and proposes the following language for CIP-005 R2.6.3: Communications between Intermediate Systems and Applicable Systems of Part 2.1. must go through an EACMS enforcing an ESP.

Rachel Coyne, Texas Reliability Entity, Inc., 10, 8/31/2021

- 0 - 0

While the new and revised defined terms are seen by BC Hydro to accommodate virtualization and future technologies, BC Hydro does not agree with the 'as is' state of the definitions associated with some of the  proposed NERC Glossary terms per comments provided in this project comment/ballot submission.

BC Hydro, Segment(s) 3, 5, 1, 12/18/2018

- 0 - 0

SDG&E supports EEI Comments 

Bridget Silvia, Sempra - San Diego Gas and Electric, 3, 8/31/2021

- 0 - 0

MEAG Power adopts the Southern Company comments.

MEAG Power, Segment(s) 3, 1, 5, 6/15/2017

- 0 - 0

We support NPCC TFIST's comments as found below:

Request clarification on ERC for serial – IP communications. We understand this will not be backward compatible. Is that correct? Such as CIP-005 R3.1 and CIP-007 R4.2

Request clarification of the updated BCSI definition. We believe this new definition should include “SCI identified independently supporting an Applicable System.”

Gerry Adamski, Cogentrix Energy Power Management, LLC, 5, 8/31/2021

- 0 - 0

As stated in Question 3, we do not agree with the modification to the definition for ERC.

FE Voter, Segment(s) 1, 3, 5, 6, 4, 2/23/2021

- 0 - 0

OKGE supports EEI's comments. 

OKGE, Segment(s) 6, 1, 3, 5, 3/22/2021

- 0 - 0

Since the Glossary modifications are the foundation to all Standard changes, NERC should seek approval of the new terms prior to any changes being introduced in the Standards to reduce potential misunderstanding or misinterpretation of both the new definitions and modified Standards.  This will also allow NERC, and industry, time to determine additional courses of action, reduce confusion, and reduce additional risk associated with such wholesale changes.

Anthony Jablonski, ReliabilityFirst , 10, 8/31/2021

- 0 - 0

Some additional revisions:

Remove “TCA” from CIP Systems - A Cyber System identified by the Responsible Entity as a BES Cyber System, Electronic Access Control or Monitoring System, Physical Access Control System, or Shared Cyber Infrastructure, or Protected Cyber Asset. (Remove: or Transient Cyber Asset.)

Remove “or a PCA” from the Virtual Cyber Asset - A logical instance of an operating system or firmware hosted on Shared Cyber Infrastructure (Remove: or a PCA).

Add “protocol” to EAP - A policy enforcement point or a Cyber Asset interface that allows routable protocol communication to and from the BES Cyber System within an Electronic Security Perimeter.

Cyber Asset – consider not excluding SCI, keeping the original - Programmable electronic devices, including the hardware, software, and data in those devices (Remove: ; excluding Shared Cyber Infrastructure).

Cyber System – we suggest reverting back to Cyber Assets where this is used or go with a generic “cyber system” term in the exemptions language.  Leave cyber system an undefined term. Simplifying applicability can create increased scope in the requirements.

Shared Cyber Infrastructure – Please provide more information in the technical rationale on what is intended with “including the software.”

Management Interface – In the non-virtualized environments there are applications that manage the policy implementation of firewalls that would be both a Management Interface and an EACMS under the new requirements and definitions. Was this the SDT’s intent?

Darnez Gresham, Berkshire Hathaway Energy - MidAmerican Energy Co., 3, 8/31/2021

- 0 - 0

See MidAmerican Energy Company comments from Darnez Gresham.

Terry Harbour, Berkshire Hathaway Energy - MidAmerican Energy Co., 1, 8/31/2021

- 0 - 0

Cleco supports comments submitted by EEI.

Clay Walker, On Behalf of: Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6

- 0 - 0

In support of NPCC RSC comments.

Request clarification on ERC for serial – IP communications. We understand this will not be backward compatible. Is that correct? Such as CIP-005 R3.1 and CIP-007 R4.2

Request clarification of the updated BCSI definition. We believe this new definition should include “SCI identified independently supporting an Applicable System.”

 

We suggest some additional work on the definitions (ESP/IRA/CIP System/SCI) and a better alignment with the current CIP language. 

Also, some definition includes some requirements on CPU and memory (isolation/shared), those requirements are not future proof.  Furthermore, the definitions by focusing on shared CPU and memory trend toward hypervisor-based virtualization and don’t seem to provide a clear framework around other types of virtualizations like containerization technology. 

We Suggest that the SDT review the definitions, the need for defining new terms and the nested definitions.

Nicolas Turcotte, Hydro-Qu?bec TransEnergie, 1, 9/1/2021

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Daniel Gacek, Exelon, 1, 9/1/2021

- 0 - 0

In general, AEP supports most of the new and revised terms, but we have concerns with the following terms:

  • BES Cyber System Information (BCSI):  There is no need to call out SCI in the BCSI definition when it is already covered in BES Cyber System definition. 
  • Cyber Assets: While the exclusion of Shared Cyber Infrastructure (SCI) in Cyber Assets definition seems okay upfront, it gets very confusing when applying this definition along with other definitions, such as SCI and Virtual Cyber Asset (VCA).  VCA definition says it might be hosted on SCI (i.e., “A logical instance of an operating system or firmware hosted on SCI or a PCA”); However, SCI definition says “SCI does not include the supported VCA or CA with which it shares its resources”. Implementation may become chaotic unless all four definitions of CA, VCA, SCI and PCA are all logically explained in a real life context.
  • External Routable Connectivity (ERC): See response to Question #3 above
  • Electronic Security Perimeter (ESP):  See responses to Questions #4 and #7 above.
  • Interactive Remote Access (IRA): See response to Question #5 above.
  • Management Interface: See response to Question #6 above.
  • Protected Cyber Asset (PCA): AEP seeks additional clarifications on the qualifier of “excluding VCA that are being actively remediated prior to introduction to the ESP.” If the VCA, or physical Cyber Asset, is outside of the ESP, how could it be considered a PCA when the required attribute of a PCA be that it is inside an ESP?  Please provide clarification.
  • Shared Cyber Infrastructure (SCI): AEP in general supports the definition of SCI except for “identified independently” and the nested inclusion of the Management Interface term.  Please see responses to Questions #2 and #6.
  • Transient Cyber Asset (TCA):  AEP seeks additional clarifications on the significance of "Virtual machines hosted on a physical TCA can be treated as software on that physical TCA". If there were stated outcome(s) of treating as software, it might be more clear (implications of treating as software, that is).

JT Kuehne, AEP, 6, 9/1/2021

- 0 - 0

Minnesota Power has concerns about acronyms CSI and SCI being confused. The SDT needs to consider other terms as it is close to an existing one.  The SDT should consider Private Cloud Infrastructure (PCI) or Virtual Cloud Infrastructure (VCI) which could help facilitate a move to Public Cloud Infrastructure should an entity decide to do so.  The second term may provide more flexibility in utlizing public cloud resources where an entity decides public cloud is more effective.

Jamie Monette, On Behalf of: Allete - Minnesota Power, Inc., , Segments 1

- 0 - 0

Request clarification on ERC for serial – IP communications. We understand this will not be backward compatible. Is that correct? Such as CIP-005 R3.1 and CIP-007 R4.2

Request clarification of the updated BCSI definition. We believe this new definition should include “SCI identified independently supporting an Applicable System.”

 

We suggest some additional work on the definitions (ESP/IRA/CIP System/SCI) and a better alignment with the current CIP language. 

Also, some definition includes some requirements on CPU and memory (isolation/shared), those requirements are not future proof.  Furthermore, the definitions by focusing on shared CPU and memory trend toward hypervisor-based virtualization and don’t seem to provide a clear framework around other types of virtualizations like containerization technology. 

We Suggest that the SDT review the definitions, the need for defining new terms and the nested definitions.

 

Leonard Kula, Independent Electricity System Operator, 2, 9/1/2021

- 0 - 0

We agree with the new definitions of VCA, SCI and Management Interface, but disagree with the language in the definitions. We disagree with the changes to the definitions of CA, ESP, ERC, EAP , IRA and CIP System. See our proposed changes to the new and existing definitions and rationale for the disagreement in Q1.

MRO NSRF, Segment(s) 2, 4, 1, 6, 3, 5, 7/1/2021

- 0 - 0

Amy Jones, Public Utility District No. 2 of Grant County, Washington, 5, 9/1/2021

- 0 - 0

Evergy incorporates by reference and endorses the comments as filed by the Edison Electric Institute.

Alan Kloster, On Behalf of: Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Kinte Whitehead, Exelon, 3, 9/1/2021

- 0 - 0

See comments in Q#5 above. With regard to EEI’s comment regarding definition of VCA PNMR disagrees that it needs to be altered to better conform with the Cyber Asset definition.  SMEs within our company found the definition proposed by the SDT to be clearer and a better fit than the definition proposed by EEI.

Amy Bratkovic, On Behalf of: PNM Resources - Public Service Company of New Mexico, , Segments 1, 3

- 0 - 0

See responses to previos questions.

Remove “TCA” from CIP Systems - A Cyber System identified by the Responsible Entity as a BES Cyber System, Electronic Access Control or Monitoring System, Physical Access Control System, or Shared Cyber Infrastructure, or Protected Cyber Asset. or Transient Cyber Asset.

Remove “or a PCA” from the Virtual Cyber Asset - A logical instance of an operating system or firmware hosted on Shared Cyber Infrastructure or a PCA.

Add “protocol” to EAP - A policy enforcement point or a Cyber Asset interface that allows routable protocol communication to and from the BES Cyber System within an Electronic Security Perimeter.

Cyber Asset – consider not excluding SCI, keeping the original - Programmable electronic devices, including the hardware, software, and data in those devices; excluding Shared Cyber Infrastructure.

Cyber System – we suggest reverting back to Cyber Assets where this is used or go with a generic “cyber system” term in the exemptions language.  Leave cyber system an undefined term. Simplifying applicability can create increased scope in the requirements.

Shared Cyber Infrastructure – Please provide more information in the technical rationale on what is intended with “including the software.”

Management Interface – In the non-virtualized environments there are applications that manage the policy implementation of firewalls that would be both a Management Interface and an EACMS under the new requirements and definitions. Was this the SDT’s intent?

Dwanique Spiller, On Behalf of: Berkshire Hathaway - NV Energy - WECC - Segments 5

- 0 - 0

ISO-NE requests that a term other than "lights out" be used in the Management Interface definition to avoid diffuclty with interpretation related to marketing language related to such products.  Please re-cast the definition related to "lights out" management interfaces with respect to the character of the functions supported by the interface and the potential for risk to Cyber Asset support for reliability functions.

John Galloway, On Behalf of: Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2

- 0 - 0

Tacoma Power, Segment(s) 1, 3, 4, 5, 6, 3/9/2021

- 0 - 0

GRE agrees with the comments submitted by the NSRF. 

Michael Brytowski, Great River Energy, 3, 9/1/2021

- 0 - 0

In support of IRC SRC/SWG.

Request clarification on ERC for serial – IP communications. We understand this will not be backward compatible. Is that correct? Such as CIP-005 R3.1 and CIP-007 R4.2

Request clarification of the updated BCSI definition. We believe this new definition should include “SCI identified independently supporting an Applicable System.”

Monika Montez, On Behalf of: California ISO, WECC, Segments 2

- 0 - 0

Nurul Abser, NB Power Corporation, 1, 9/1/2021

- 0 - 0

Agree with the new and revised definitions short of the SCI definition. 

Donna Wood, Tri-State G and T Association, Inc., 1, 9/1/2021

- 0 - 0

Remove “TCA” from CIP Systems - A Cyber System identified by the Responsible Entity as a BES Cyber System, Electronic Access Control or Monitoring System, Physical Access Control System, or Shared Cyber Infrastructure, or Protected Cyber Asset. [delete - or Transient Cyber Asset.]

Remove “or a PCA” from the Virtual Cyber Asset - A logical instance of an operating system or firmware hosted on Shared Cyber Infrastructure [delete - or a PCA.]

Add “protocol” to EAP - A policy enforcement point or a Cyber Asset interface that allows routable protocol communication to and from the BES Cyber System within an Electronic Security Perimeter.

Cyber Asset – consider not excluding SCI, keeping the original - Programmable electronic devices, including the hardware, software, and data in those devices; [delete - excluding Shared Cyber Infrastructure.]

Cyber System – we suggest reverting back to Cyber Assets where this is used or go with a generic “cyber system” term in the exemption's language.  Leave cyber system an undefined term. Simplifying applicability can create increased scope in the requirements.

Shared Cyber Infrastructure – Please provide more information in the technical rationale on what is intended with “including the software.”

Casey Jones, On Behalf of: Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5

- 0 - 0

Israel Perez, On Behalf of: Salt River Project, WECC, Segments 1, 3, 5, 6

- 0 - 0

We believe the definition of ERC is confusing because it is unclear what the term "asset" is referring to when it states "from outside the asset containing the CIP System". Is this referring to a cyber asset, a BES asset, or a Facility? The definition was much clearer when referring to an ESP. The additional concerns with definitions have been addressed above.

David Jendras, Ameren - Ameren Services, 3, 9/1/2021

- 0 - 0

We agree with the new definitions of VCA, SCI and Management Interface, but disagree with the language in the definitions. We disagree with the changes to the definitions of CA, ESP, ERC, EAP , IRA and CIP System. See our proposed changes to the new and existing definitions and rationale for the disagreement in Q1.

Barry Jones, On Behalf of: sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6

- 0 - 0

GSOC supports the majority of the revisions subject to its comment on particular definitions provided herein.

Benjamin Winslett, Georgia System Operations Corporation, 4, 9/1/2021

- 0 - 0

  • The ERC and IRA with serial conversion needs to be clarified with more industry use cases and may require improved language.

  • External Routable Connectivity (ERC) language enhancement:  The electronic bidirectional routable protocol communications between a CIP System and a Cyber System (Cyber Asset or Virtual Cyber Asset) located outside of the asset's PSP or ESP.

Justin Welty, NextEra Energy - Florida Power and Light Co., 6, 9/1/2021

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Cynthia Lee, Exelon, 5, 9/1/2021

- 0 - 0

OPG concurs with NPCC's RSC comments

David Kwan, On Behalf of: Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Becky Webb, Exelon, 6, 9/1/2021

- 0 - 0

ACES agrees with the added and modified terms except where noted in the responses to the questions in this comment form.

ACES Standard Collaborations, Segment(s) 1, 9/1/2021

- 0 - 0

Eversource 1, Segment(s) 3, 1, 9/1/2021

- 0 - 0

Karie Barczak, DTE Energy - Detroit Edison Company, 3, 9/1/2021

- 0 - 0

LCRA is concerned with using CIP System incorrectly due to SDT intent to only use it as a “non-CIP System”. CIP System does not appear to be a necessary term. TCAs are included in the CIP System definition. However, CIP System is used in the definition of ESP. This is an example of the confusion associated with the term.

James Baldwin, Lower Colorado River Authority, 1, 9/1/2021

- 0 - 0

In addition to the comments regarding the ESP definition provided in response to question 4, AWS offers comments on the terms: CIP System, Cyber System and Transient Cyber Asset.

The terms CIP System and Cyber System are similar and could easily be confused or misunderstood. Please clarify whether the term “System” implies that evidence of compliance can be presented at the system level rather than the device level.

In addition, we oppose and suggest reconsideration to the Transient Cyber Asset (TCA) definition revision that allows virtual machines running on a physical TCA to be treated as software on the device. As written, a Responsible Entity is not be required to apply the appropriate security controls to the virtual machines running on physical TCAs. For security purposes, Responsible Entities should be monitoring the state of the virtual machines running on their physical hardware for security issues. We propose removing the language “Virtual machines hosted on a physical TCA can be treated as software on that physical TCA” from the TCA definition, and modifying the VCA definition to read, “A logical instance of an operating system or firmware hosted on Shared Cyber Infrastructure, a PCA, or a TCA.”

Maggy Powell, Amazon Web Services, 7, 9/1/2021

- 0 - 0

For “CIP System”, Southern agrees with having defined terms as shorthand, such as in CIP-007 R1.3 with its use of “non-CIP Systems.”  However, Southern disagrees with the inclusion and nesting of this broad term within many other definitions. Analyzing the resulting scope of nested definitions based on “CIP System” is problematic, and our answers to Q3 and Q4 are specific examples of issues in its inclusion in ERC and ESP definitions.

Southern Company, Segment(s) 1, 3, 6, 5, 1/14/2021

- 0 - 0

LCRA is concerned with using CIP System incorrectly due to SDT intent to only use it as a “non-CIP System”. CIP System does not appear to be a necessary term. TCAs are included in the  CIP System definition. However, CIP System is used in the definition of ESP. This is an example of the confusion associated with the term.  

LCRA Compliance, Segment(s) 6, 5, 1, 5/11/2015

- 0 - 0

ERCOT supports the IRC SRC comments and offers this additional comment:

  • SCI should not be excluded from the Cyber Asset definition. SCI meet the definition of Cyber Asset in that it is comprised of hardware, software, and data.

Brandon Gleason, 9/1/2021

- 0 - 0

LeRoy Patterson, Public Utility District No. 2 of Grant County, Washington, 6, 9/1/2021

- 0 - 0

<duplicate>

Dana Showalter, On Behalf of: Electric Reliability Council of Texas, Inc., Texas RE, Segments 2

- 0 - 0

Generally, EEI supports most of the new/revised terms, but we have concerns with the following terms:

External Routable Connectivity (ERC): See our comments to Question 3 above.

Electronic Security Perimeter (ESP): See our comments to Questions 4 and 7 above.

Interactive Remote Access (IRA): See our comments to Question 5 above.

Management Interface: EEI disagrees with the practice of nesting other Glossary Terms within the definition of other Glossary Terms.  This practice makes it difficult to support definition that might otherwise be supported.  While there are a number of other examples of this practice (see SCI) Management Interface serves as a good example of our concern.

Protected Cyber Asset (PCA): EEI seeks additional clarifications on the qualifier of “excluding Virtual Cyber Assets that are being actively remediated prior to introduction to the ESP.” If the VCA, or physical Cyber Asset, is outside of the ESP, how could it be considered a PCA when the required attribute of a PCA is that it is inside an ESP?  Please provide clarification.

Virtual Cyber Asset (VCA) – The current definition is unclear and possibly unnecessary given the intent is to simply provide an equivalent virtualized term for a Cyber Asset, which is not a system but a programmable electronic device.  If the SDT believes this term is necessary, we suggest the following:

“A logical instance of a programmable device, including the software and data, hosted on Shared Cyber Infrastructure or a PCA.”

Mark Gray, On Behalf of: Edison Electric Institute, NA - Not Applicable, Segments NA - Not Applicable

- 0 - 0

Regarding ERC, this is a substantial change to the definition of ERC that has a larger impact than in the context of addressing virtualized environments.

Several of the terms have been removed from the proposed definitions but are still being used other definitions and standards.  For example Management Systems and Management Module have been removed but are still used in the SCI definition and in the CIP-005 R2.1 Measures and through the CIP-005 violation severity levels.

Gail Golden, Entergy - Entergy Services, Inc., 5, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

Alyssia Rhoads, Public Utility District No. 1 of Snohomish County, 1, 9/1/2021

- 0 - 0

 

PJM signs on to the comments provided by the IRC SRC.

Elizabeth Davis, On Behalf of: Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2

- 0 - 0

see responses to previous questions

Some additional revisions:

Remove “TCA” from CIP Systems - A Cyber System identified by the Responsible Entity as a BES Cyber System, Electronic Access Control or Monitoring System, Physical Access Control System, or Shared Cyber Infrastructure, or Protected Cyber Asset. [delete - or Transient Cyber Asset.]

Remove “or a PCA” from the Virtual Cyber Asset - A logical instance of an operating system or firmware hosted on Shared Cyber Infrastructure [delete - or a PCA.]

Add “protocol” to EAP - A policy enforcement point or a Cyber Asset interface that allows routable protocol communication to and from the BES Cyber System within an Electronic Security Perimeter.

Cyber Asset – consider not excluding SCI, keeping the original - Programmable electronic devices, including the hardware, software, and data in those devices; [delete - excluding Shared Cyber Infrastructure.]

Cyber System – we suggest reverting back to Cyber Assets where this is used or go with a generic “cyber system” term in the exemptions language.  Leave cyber system an undefined term. Simplifying applicability can create increased scope in the requirements.

Shared Cyber Infrastructure – Please provide more information in the technical rationale on what is intended with “including the software.”

Management Interface – In the non-virtualized environments there are applications that manage the policy implementation of firewalls that would be both a Management Interface and an EACMS under the new requirements and definitions. Was this the SDT’s intent?

Lindsay Wickizer, Berkshire Hathaway - PacifiCorp, 6, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

Sam Nietfeld, Public Utility District No. 1 of Snohomish County, 5, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

SNPD Voting Members, Segment(s) 4, 6, 5, 1, 6/18/2020

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

John Martinsen, Public Utility District No. 1 of Snohomish County, 4, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

John Liang, Snohomish County PUD No. 1, 6, 9/1/2021

- 0 - 0

Request clarification on ERC for serial – IP communications. We understand this will not be backward compatible. Is that correct? Such as CIP-005 R3.1 and CIP-007 R4.2

Request clarification of the updated BCSI definition. We believe this new definition should include “SCI identified independently supporting an Applicable System.”

 

We suggest some additional work on the definitions (ESP/IRA/CIP System/SCI) and a better alignment with the current CIP language. 

Also, some definition includes some requirements on CPU and memory (isolation/shared), those requirements are not future proof.  Furthermore, the definitions by focusing on shared CPU and memory trend toward hypervisor-based virtualization and don’t seem to provide a clear framework around other types of virtualizations like containerization technology. 

We Suggest that the SDT review the definitions, the need for defining new terms and the nested definitions.

NPCC Regional Standards Committee, Segment(s) 10, 2, 4, 7, 3, 1, 5, 6, 8/6/2021

- 0 - 0

Portland General Electric Company supports the comments provided by EEI for this survey question. Additionally, Portland General Electric Company has concerns regarding the Interactive Remote Access (IRA) defintion. In the second bullet of the definition, the clause "to a Cyber System not within an Electronic Security Perimeter" implies that IRA can exist in scenarios where a person has no intent of remotely connecting to a BES Cyber System or PCA. The proposed definition of a Cyber System includes any number of Cyber Assets, Virtual Cyber Assets, or Shared Cyber Infrastructure that may be either CIP or non-CIP. If an individual was remotely communicating through a protocol converter to a device like a PACS, EACMS, or non-CIP Cyber Asset existing outside the ESP, that would be considered IRA under the current definition even if those systems didn't have connectivity to a BES Cyber System. Portland General Electric Company believes changing the clause to "to a BES Cyber System not within an Electronic Security Perimeter" achieves the objective of controlling IRA to BES Cyber Assets that are serially connected to the BES Cyber System.

Ryan Olson, Portland General Electric Co., 5, 9/1/2021

- 0 - 0

N&ST recommendations for the definitions of ERC, ESP, and IRA are in our responses to Questions 3, 4 and 5, respectively. N&ST respectfully suggests the following changes to these additional definitions:


> EAP: “A policy enforcement point or a Cyber Asset interface that controls routable communication to and from a BES Cyber System from outside its Electronic Security Perimeter.”


> IS: The statement within the current IS definition, “The Intermediate System must not be located inside the Electronic Security Perimeter,” should be retained.

> EACMS and PACS: N&ST recommends both definitions, which begin with “Cyber Assets, Virtual Cyber Assets, or Shared Cyber Infrastructure (SCI),…” be modified to begin with, “Cyber Assets, Virtual Cyber Assets, Cyber Systems, or Shared Cyber Infrastructure (SCI),…” This would clarify that it’s permissible to group an SCI with the EACMS and/or the PACS it supports.

Roger Fradenburgh, On Behalf of: Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1

- 0 - 0

The IRC SRC requests the SDT clarify ERC for serial – IP communications to ensure backwards compatibility. We understand the proposed definition will not be backwards compatible; e.g. CIP-005, R3.1 and CIP-007, R4.2. Is that correct?  

In addition, we request the SDT clarify the definition for BES Cyber System Information (BCSI) to include “SCI identified independently, supporting an Applicable System.”

ISO/RTO Council Standards Review Committee 2016-02 Virtualization (Draft 2), Segment(s) 2, 9/1/2021

- 0 - 0

ATC continues to have some questions about ERC and devices wholly inside an ESP.

  • Where does the chain end?
  • Do Cyber Assets two hops removed from the IRA entry point inside the ESP, or the system to system routable communication path between a system inside and outside the ESP have ERC?

The use of the term asset may make it more difficult to determine where ERC exists. Non-CIP systems inside a Control Center “asset” that are connecting into a CIP System inside the same Control Center “asset” could be at varied trust levels and should be protected via ERC and IRA controls.

LaTroy Brumfield, American Transmission Company, LLC, 1, 9/1/2021

- 0 - 0

ITC supports the response submitted by EEI for this question.

Gail Elliott, On Behalf of: Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1

- 0 - 0

Hot Answers

Portland General Electric Company supports this change, but generally agrees with the comments provided by EEI for this survey question.

Dan Zollner, Portland General Electric Co., 3, 9/1/2021

- 0 - 0

PGE FCD, Segment(s) 5, 1, 3, 6, 9/11/2018

- 0 - 0

Other Answers

Richard Jackson, U.S. Bureau of Reclamation, 1, 8/19/2021

- 0 - 0

A more detailed explanation of the rationale behind the addition addition of “discrete” needs to be provided for further clarification to enable an accurate response. 

Dominion, Segment(s) 3, 5, 1, 9/19/2019

- 0 - 0

Jeanne Kurzynowski, On Behalf of: CMS Energy - Consumers Energy Company - RF - Segments 3, 4, 5

- 0 - 0

Chelan approves of the revisions to CIP-002 but suggests clarification be made per comments for Q2.

CHPD, Segment(s) 3, 1, 6, 5, 8/24/2021

- 0 - 0

Glen Farmer, Avista - Avista Corporation, 5, 8/24/2021

- 0 - 0

No.  Please see NRG’s response to question 2 for additional detail.

Martin Sidor, NRG - NRG Energy, Inc., 6, 8/24/2021

- 0 - 0

No.  Please see NRG’s response to question 2 for additional detail.

Patricia Lynch, NRG - NRG Energy, Inc., 5, 8/24/2021

- 0 - 0

CIP-002 should retain its focus on identification of BES Cyber Systems and the associated approval by the CIP Senior Manager.

Tennessee Valley Authority, Segment(s) 1, 3, 5, 6, 10/18/2018

- 0 - 0

Xcel Energy does not agree with proposed changes in CIP-002 and believe that the concept of SCI indenpednatly verified requires further clarity. We also support EEI comments on this question. 

Amy Casuscelli, On Behalf of: Xcel Energy, Inc. - MRO, WECC - Segments 1, 3, 5, 6

- 0 - 0

Andrea Jessup, On Behalf of: Bonneville Power Administration, WECC, Segments 1, 3, 5, 6

- 0 - 0

Mike Magruder, Avista - Avista Corporation, 1, 8/26/2021

- 0 - 0

As further discussed in response to Questions 1 and 2, Duke Energy disagrees with the complexity added to the CIP-002 requirements.  Based on our suggestion of the addition of an SCI Group defined term, simplified language proposed in response to Question 1 can be used.

In Requirement 1.3, the comma following BCS introduces confusion and should be removed to be clear that the SCI clause follows onto the identify clause, and is not a requirement for a separate/additional list of assets that contain SCI supporting low BCS. Alternatively, bulleting the requirement after “asset that contains:” may be clearer.

Changes to the Attachment 2 criteria 2.1 to incorporate the term “discrete” lose the context of the original RFI; if the SDT retains the new “discrete shared” language, a comma should be inserted between these terms, and clarification should be provided in the technical rationale to carry forward the clarification provided in the RFI.  Additionally, the SCI bullet appears to exclude the possibility of independently identifying SCI at Generation facilities.  If this was the SDT’s intent, justification should be provided that explains why this option is not available to this facility type under section 2.1.  Finally, Section 2.2 generally follows the same format as section 2.1 but was not given the second bullet related to SCI; was this intentional?  If so, it would be helpful to provide explanation in an appropriate document. 

Katie Connor, On Behalf of: Duke Energy - SERC, RF - Segments 1, 3, 5, 6

- 0 - 0

The draft CIP-002-7 standard now allows the Responsible Entity to identify SCI in the overall BCS or to identify them independently, it also requires the identification of SCI that supports EACMS, PACS, or PCAs.  This gives Regional Entity enforcement staff the ability to identify noncompliance in a single requirement for a missed (SCI based) EACM, PACS, or PCA; rather than identifying all applicable requirements for a missed EACMS, PACS, or PCA.

AECI, Segment(s) 1, 3, 6, 5, 3/4/2021

- 1 - 0

See MRO-NSRF and EEI Comments

Clarice Zellmer, WEC Energy Group, Inc., 5, 8/26/2021

- 0 - 0

While mostly in agreement, please see our comments above responding to question #1.

Ronald Bender, Nebraska Public Power District, 5, 8/27/2021

- 0 - 0

Josh Johnson, Lincoln Electric System, 1, 8/27/2021

- 0 - 0

WECC CIP, Segment(s) 10, 2/17/2021

- 0 - 0

William Steiner, Midwest Reliability Organization, 10, 8/30/2021

- 0 - 0

AZPS agrees with EEI’s comments around the concern that both data communication links and communication networks should be exempt.  AZPS asks the SDT to explain why they are now excluding communications networks.

Marcus Bortman, APS - Arizona Public Service Co., 6, 8/30/2021

- 0 - 0

We support these approach used for these changes once acceptable definitions are in place.

Susan Sosbe, On Behalf of: Wabash Valley Power Association, , Segments 1, 3

- 0 - 0

The CIP-002 should maintain a section on BROS that establish the relationship with the BCS

Carl Pineault, Hydro-Qu?bec Production, 5, 8/30/2021

- 0 - 0

The first draft contained the weighting to determine if a TOP Control Center met the medium impact criteria from CIP-002-6.  The second draft reverted back to CIP-002-5.1a’s criteria 2.12’s language without informing the industry.  While there is a new project to “study” the impacts to the BES with this change further delaying smaller entities compliance burden relief, it was not made clear to industry CIP-002’s language was being reverted back under this project and was not shown as a change/redline from the first or redlined in the second draft which is highly misleading.  If it is possible to incorporate other projects modifying other CIP standards into this project, why not the approved CIP-002-6 and complete the study at a later time?  

 

AEPC has signed on to ACES comments.

Jennifer Bray, Arizona Electric Power Cooperative, Inc., 1, 8/30/2021

- 0 - 0

Justin MacDonald, On Behalf of: Midwest Energy, Inc., , Segments 1

- 0 - 0

Several of the terms and their usage, especially SCI, lends ambiguity with their use in the Standards. Further clarifications and refinements of the terms should be given attention.

Steve Toosevich, NiSource - Northern Indiana Public Service Co., 1, 8/31/2021

- 0 - 0

CEHE does not agree with the proposed changes to the 4.2.3.2. Exemption because in the “Lessons Learned CIP Version 5 Transition Program CIP-002-5.1: Communications and Networking Cyber Assets” issued by NERC, “study participants [in the Implementation Study] made a distinction between devices facilitating network communication locally for the BES Cyber Systems and those facilitating network communication external to the BES Cyber System or Facility. Entities determined network devices used only for external communication were out of scope in association with the high or medium impact BES Cyber System.”  The “Lessons Learned CIP Version 5 Transition Program CIP-002-5.1: Communications and Networking Cyber Assets” was authorized by the Standards Committee on October 29, 2015 and is “ERO Enterprise – Endorsed Implementation Guidance.”  However, it is still not in the standards and auditors can only go by the standards and not “Lesson Learned” documents. 

The “between discrete ESPs” exemption is too narrow; all Cyber Systems used only for external communication need to be exempt, not just those between discrete ESPs.  The reason is that there are instances when the same Cyber Systems can be used between two discrete ESP and between an ESP and non-ESP site.  In one instance the Cyber Systems are exempt, in the other they are not, even though it is the same equipment performing the same function. 

This narrow exemption has the potential of pulling Cyber Systems used for only external network communications into scope.  Entities may have to bring telecommunication sites into compliance, which could mean additional costs, physical and electronic controls that would otherwise not be needed, and possibly more staff to produce and maintain the documentation required for compliance.  This could create a situation where an Entity may have to choose a leased network over a private network due to the leased network being exempt even though it performs the same function as a private system. 

Private systems are usually more reliable than leased systems, so overall the BES would be less reliable when using a leased system which is directly opposite of the purpose of the NERC standards.  Private systems should be encouraged and exempting all Cyber Systems used only for external communications would do that.

CEHE proposes the following: 

“4.2.3.2.  Cyber Systems used only for external network communication between assets, or one or more geographic locations.”

Eli Rivera, On Behalf of: CenterPoint Energy Houston Electric, LLC, Texas RE, Segments NA - Not Applicable

- 0 - 0

Southwest Power Pool Standards Review Group (SSRG), Segment(s) 2, 9/4/2019

- 0 - 0

NCPA does not support the modified language in CIP-002.  How SCI is to be independently identified is not clear. 

Chris Carnesi, On Behalf of: Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Dennis Sismaet, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Michael Whitney, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6; Jeremy Lawson, Northern California Power Agency, 3,4,5,6

- 0 - 0

SIGE does not agree with the proposed changes to the 4.2.3.2. Exemption because in the “Lessons Learned CIP Version 5 Transition Program CIP-002-5.1: Communications and Networking Cyber Assets” issued by NERC, “study participants [in the Implementation Study] made a distinction between devices facilitating network communication locally for the BES Cyber Systems and those facilitating network communication external to the BES Cyber System or Facility. Entities determined network devices used only for external communication were out of scope in association with the high or medium impact BES Cyber System.”  The “Lessons Learned CIP Version 5 Transition Program CIP-002-5.1: Communications and Networking Cyber Assets” was authorized by the Standards Committee on October 29, 2015 and is “ERO Enterprise – Endorsed Implementation Guidance.”  However, it is still not in the standards and auditors can only go by the standards and not “Lesson Learned” documents. 

The “between discrete ESPs” exemption is too narrow; all Cyber Systems used only for external communication need to be exempt, not just those between discrete ESPs.  The reason is that there are instances when the same Cyber Systems can be used between two discrete ESP and between an ESP and non-ESP site.  In one instance the Cyber Systems are exempt, in the other they are not, even though it is the same equipment performing the same function. 

This narrow exemption has the potential of pulling Cyber Systems used for only external network communications into scope.  Entities may have to bring telecommunication sites into compliance, which could mean additional costs, physical and electronic controls that would otherwise not be needed, and possibly more staff to produce and maintain the documentation required for compliance.  This could create a situation where an Entity may have to choose a leased network over a private network due to the leased network being exempt even though it performs the same function as a private system. 

Private systems are usually more reliable than leased systems, so overall the BES would be less reliable when using a leased system which is directly opposite of the purpose of the NERC standards.  Private systems should be encouraged and exempting all Cyber Systems used only for external communications would do that.

SIGE proposes the following: 

“4.2.3.2.  Cyber Systems used only for external network communication between assets, or one or more geographic locations.”

Brian Tooley, On Behalf of: Southern Indiana Gas and Electric Co., RF, Segments 3, 5, 6

- 0 - 0

It is unclear what “independent SCI supporting any part of the high impact BCS…” is referring to.

Joe Tarantino, On Behalf of: Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6; Kevin Smith, Balancing Authority of Northern California, 1; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Charles Norton, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Foung Mua, Sacramento Municipal Utility District, 1,3,4,5,6; Wei Shao, Sacramento Municipal Utility District, 1,3,4,5,6

- 0 - 0

As noted in the answer to Question #1, Texas RE recommends the language require identification of all BCS, as well as their associated EACMS, PACS, and PCAs.  Absent that change, Texas RE recommends the SDT review Requirement R1 for logical flow.  The proposed Requirement R1 language instructs registered entities to identify each BCS as either a BCS or as a BCS and independent SCI.  Texas RE notes that it is not possible to identify a BCS as an independent SCI.  If the system is a BCS then it must be identified as a BCS.  The SDT could consider revising the language to:  

 

1.1.         Per Attachment 1, Section 1:

1.1.1.     Identify each high impact BCS; and

1.1.2.     Identify each independent SCI supporting any part of the high impact BCS or its associated EACMS, PACS, or PCAs.

 

1.2.         Per Attachment 1, Section 2:

1.2.1.     Identify each medium impact BCS; and;

1.2.2.     Identify each independent SCI supporting any part of the medium impact BCS or its associated EACMS, PACS, or PCAs.

Rachel Coyne, Texas Reliability Entity, Inc., 10, 8/31/2021

- 0 - 0

However while the new and revised defined terms are seen by BC Hydro to accommodate virtualization and future technologies, BC Hydro does not agree with the proposed changes to the NERC glossary of terms. BC Hydro does not agree with the 'as is' state of the SCI  definition proposed in this project comment/ballot submission.

BC Hydro, Segment(s) 3, 5, 1, 12/18/2018

- 0 - 0

SDG&E supports EEI Comments 

Bridget Silvia, Sempra - San Diego Gas and Electric, 3, 8/31/2021

- 0 - 0

MEAG Power adopts the Southern Company comments.

MEAG Power, Segment(s) 3, 1, 5, 6/15/2017

- 0 - 0

We support NPCC TFIST's comments as found below:

Request clarification of capitalization of “High Impact,” “Medium Impact” and “Low Impact.” Parts 1.1, 1.2 and 1.3 use lower case while other Standards use capitalization. Is there a difference? If so, please explain.

Request clarification on the “OR” in Part 1.3. What is the Entity required to identify? Assets or BCSI/SCI?

Request correction of typo in R2 from the beginning “Each” to “The”

Request clarification on the new (second) bullet in 2.1 in Attachment 1. Does the SDT intend that a series of Low Impact asset could be consolidated into Medium Impact asset due to shared SCI?

Gerry Adamski, Cogentrix Energy Power Management, LLC, 5, 8/31/2021

- 0 - 0

FE Voter, Segment(s) 1, 3, 5, 6, 4, 2/23/2021

- 0 - 0

OKGE supports EEI's comments. 

OKGE, Segment(s) 6, 1, 3, 5, 3/22/2021

- 0 - 0

Since the Glossary modifications are the foundation to all Standard changes, NERC should seek approval of the new terms prior to any changes being introduced in the Standards to reduce potential misunderstanding or misinterpretation of both the new definitions and modified Standards.  This will also allow NERC, and industry, time to determine additional courses of action, reduce confusion, and reduce additional risk associated with such wholesale changes.

Anthony Jablonski, ReliabilityFirst , 10, 8/31/2021

- 0 - 0

Darnez Gresham, Berkshire Hathaway Energy - MidAmerican Energy Co., 3, 8/31/2021

- 0 - 0

See MidAmerican Energy Company comments from Darnez Gresham.

Terry Harbour, Berkshire Hathaway Energy - MidAmerican Energy Co., 1, 8/31/2021

- 0 - 0

Cleco supports comments submitted by EEI.

Clay Walker, On Behalf of: Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6; Stephanie Huffman, Cleco Corporation, 1,3,5,6; Robert Hirchak, Cleco Corporation, 1,3,5,6; Wayne Messina, LaGen, 4; John Lindsey, Cleco Corporation, 1,3,5,6; Maurice Paulk, Cleco Corporation, 1,3,5,6

- 0 - 0

In support of NPCC RSC comments.

Request clarification of capitalization of “High Impact,” “Medium Impact” and “Low Impact.” Parts 1.1, 1.2 and 1.3 use lower case while other Standards use capitalization. Is there a difference? If so, please explain.

Request clarification on the “OR” in Part 1.3. What is the Entity required to identify? Assets or BCSI/SCI?

Request correction of typo in R2 from the beginning “Each” to “The”

Request clarification on the new (second) bullet in 2.1 in Attachment 1. Does the SDT intend that a series of Low Impact asset could be consolidated into Medium Impact asset due to shared SCI?

The current wording creates more questions than answers. We suggest being more precise. See comments detailed in question one. 

 

Nicolas Turcotte, Hydro-Qu?bec TransEnergie, 1, 9/1/2021

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Daniel Gacek, Exelon, 1, 9/1/2021

- 0 - 0

“SCI independently identified” is frequently used throughout VSL in CIP-002, and “independent SCI” is used in the requirements. These phrases are not broadly understood and the intent needs to be clarified.  In addition, AEP recommends SDT to add clarifying language to allow for the identification of both physical and virtual systems as EACMS, PACS and PCAs under CIP-002 as noted in response to Question #1.

JT Kuehne, AEP, 6, 9/1/2021

- 0 - 0

 The concept of independent SCI needs to be defined as this leaves it wide open to interpretation for what it is and where it might exist.  The SDT also needs to consider defining terms vBCA and vBCS, this may help to provide clarity to the industry.

 

Jamie Monette, On Behalf of: Allete - Minnesota Power, Inc., , Segments 1

- 0 - 0

Request clarification of capitalization of “High Impact,” “Medium Impact” and “Low Impact.” Parts 1.1, 1.2 and 1.3 use lower case while other Standards use capitalization. Is there a difference? If so, please explain.

Request clarification on the “OR” in Part 1.3. What is the Entity required to identify? Assets or BCSI/SCI?

Request correction of typo in R2 from the beginning “Each” to “The”

Request clarification on the new (second) bullet in 2.1 in Attachment 1. Does the SDT intend that a series of Low Impact asset could be consolidated into Medium Impact asset due to shared SCI?

The current wording creates more questions than answers. We suggest being more precise. See comments detailed in question one. 

 

Leonard Kula, Independent Electricity System Operator, 2, 9/1/2021

- 0 - 0

We disagree with CIP-002 changes. CIP-002 R1 requirements should be restored and all other SCI language in CIP-002 Attachment 1 should be removed based on our comments in Q1.

MRO NSRF, Segment(s) 2, 4, 1, 6, 3, 5, 7/1/2021

- 0 - 0

Recommend including the definition within the text, or make a statement in the text directing to the definition in the definition list.

Amy Jones, Public Utility District No. 2 of Grant County, Washington, 5, 9/1/2021

- 0 - 0

Evergy incorporates by reference and endorses the comments as filed by the Edison Electric Institute.

Alan Kloster, On Behalf of: Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Allen Klassen, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Thomas ROBBEN, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Marcus Moor, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6; Derek Brown, Evergy, 1,3,5,6

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Kinte Whitehead, Exelon, 3, 9/1/2021

- 0 - 0

Amy Bratkovic, On Behalf of: PNM Resources - Public Service Company of New Mexico, , Segments 1, 3

- 0 - 0

Remove the following phrases:  from the second bullet on R1.1: “or its associated Electronic Access Control or Monitoring Systems (EACMS), Physical Access Control Systems (PACS) or Protected Cyber Assets (PCAs)” and from the second bullet on R1.2: “or its associated EACMS, PACS or PCAs.” These are expanding the scope of the CIP-002 identification and CIP Senior Manager approval, and identification of these associated with SCI will create confusion since these do not have to be identified in CIP-002 if they are not associated with SCI.

On Attachment 1, under the medium impact rating criteria 2.1, to clarify the second bullet, change it to begin: “Any SCI supporting BCS that could, within 15 minutes, adversely impact….” (Delete “(which must be included in a shared BCS),” “one or more” and “together.”

Dwanique Spiller, On Behalf of: Berkshire Hathaway - NV Energy - WECC - Segments 5

- 0 - 0

ISO-NE requests that the terms "high", "medium" and "low" used for impact ratings in the proposed CIP-002-7 be capitalized consistent with the rest of the CIP standards.

John Galloway, On Behalf of: Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2; Michael Puscas, ISO New England, Inc., 2

- 0 - 0

Tacoma Power, Segment(s) 1, 3, 4, 5, 6, 3/9/2021

- 0 - 0

GRE agrees with the comments submitted by the NSRF. 

Michael Brytowski, Great River Energy, 3, 9/1/2021

- 0 - 0

In support of IRC SRC/SWG.

Request clarification of capitalization of “High Impact,” “Medium Impact” and “Low Impact.” Parts 1.1, 1.2 and 1.3 use lower case while other Standards use capitalization. Is there a difference? If so, please explain

Request clarification on the “OR” in Part 1.3. What is the Entity required to identify? Assets or BCSI/SCI?

Request correction of typo in R2 from the beginning “Each” to “The”

Request clarification on the new (second) bullet in 2.1 in Attachment 1. Does the SDT intend that a series of Low Impact asset could be consolidated into Medium Impact asset due to shared SCI?

Monika Montez, On Behalf of: California ISO, WECC, Segments 2

- 0 - 0

Nurul Abser, NB Power Corporation, 1, 9/1/2021

- 0 - 0

While mostly in agreement,  we disagree with the SCI language and it should be removed from CIP-002. 

Donna Wood, Tri-State G and T Association, Inc., 1, 9/1/2021

- 0 - 0

Remove the following phrases:  from the second bullet on R1.1: “or its associated Electronic Access Control or Monitoring Systems (EACMS), Physical Access Control Systems (PACS) or Protected Cyber Assets (PCAs)” and from the second bullet on R1.2: “or its associated EACMS, PACS or PCAs.” These are expanding the scope of the CIP-002 identification and CIP Senior Manager approval, and identification of these associated with SCI will create confusion since these do not have to be identified in CIP-002 if they are not associated with SCI.

On Attachment 1, under the medium impact rating criteria 2.1, to clarify the second bullet, change it to begin: “Any SCI supporting BCS that could, within 15 minutes, adversely impact….” Delete -  “which must be included in a shared BCS,” “one or more,” and “together.”

Casey Jones, On Behalf of: Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5; Kevin Salsbury, Berkshire Hathaway - NV Energy, 5

- 0 - 0

Please see our comments above responding to question #1.

Israel Perez, On Behalf of: Salt River Project, WECC, Segments 1, 3, 5, 6

- 0 - 0

David Jendras, Ameren - Ameren Services, 3, 9/1/2021

- 0 - 0

We disagree with CIP-002 changes. CIP-002 R1 requirements should be restored and all other SCI language in CIP-002 Attachment 1 should be removed based on our comments in Q1.

Barry Jones, On Behalf of: sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6; sean erickson, Western Area Power Administration, 1,6

- 0 - 0

GSOC can support the changes to CIP-002 subject to ensuring the consistent identification of and reference to SCI.

Benjamin Winslett, Georgia System Operations Corporation, 4, 9/1/2021

- 0 - 0

  • CIP-002 should include clarification for Cyber Assets with ERC that communications are converted serial needs to identify the risk to be mitigated applying the additional controls of ERC.

    • Entities are concerned many new CIP identified Cyber Asset using serial will come into scope requiring PSP controls and Password changes every 15 months.

Justin Welty, NextEra Energy - Florida Power and Light Co., 6, 9/1/2021

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Cynthia Lee, Exelon, 5, 9/1/2021

- 0 - 0

OPG concurs with NPCC's RSC comments

David Kwan, On Behalf of: Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5; Constantin Chitescu, Ontario Power Generation Inc., 5

- 0 - 0

Exelon is aligning with EEI in response to this question. 

Becky Webb, Exelon, 6, 9/1/2021

- 0 - 0

The first draft contained the weighting to determine if a TOP Control Center met the medium impact criteria from CIP-002-6.  The second draft reverted back to CIP-002-5.1a’s criteria 2.12’s language without informing the industry.  While there is a new project to “study” the impacts to the BES with this change further delaying smaller entities compliance burden relief, it was not made clear to industry CIP-002’s language was being reverted back under this project and was not shown as a change/redline from the first or redlined in the second draft which is highly misleading.  If it is possible to incorporate other projects modifying other CIP standards into this project, why not the approved CIP-002-6 and complete the study at a later time? 

ACES Standard Collaborations, Segment(s) 1, 9/1/2021

- 0 - 0

Request clarification of capitalization of “High Impact,” “Medium Impact” and “Low Impact.” Parts 1.1, 1.2 and 1.3 use lower case while other Standards use capitalization. Is there a difference? If so, please explain.

Request clarification on the “OR” in Part 1.3. What is the Entity required to identify? Assets or BCSI/SCI?

Request correction of typo in R2 from the beginning “Each” to “The”

Request clarification on the new (second) bullet in 2.1 in Attachment 1. Does the SDT intend that a series of Low Impact asset could be consolidated into Medium Impact asset due to shared SCI?

Eversource 1, Segment(s) 3, 1, 9/1/2021

- 0 - 0

A long standing “error” appears to remain in the High VSL for R1, where it states “For Responsible Entities with a total of 100 or fewer high or medium impact and BCA, more than 10 but less than or equal to 15 identified BCA have not been categorized or have been incorrectly categorized at a lower category” where Medium and Severe mention “BCS” instead of “BCA”  This is the only mention of BCA in the VSL.  It appears as though the latest modifications only replaced definitions and did not correct this error.

Karie Barczak, DTE Energy - Detroit Edison Company, 3, 9/1/2021

- 0 - 0

James Baldwin, Lower Colorado River Authority, 1, 9/1/2021

- 0 - 0

The modifications to CIP-002 are complex and include a number of new terms and concepts.  For example, AWS supports the SDT’s addition of requirements for Management Interfaces, but Management Interfaces are not required to be identified in CIP-002. CIP-002 requires the identification of SCI and EACMS, not the associated Management Interface. This situation also occurs with Intermediate Systems under the currently enforceable Standards and has been problematic. The embedded classifications increase the opportunity for compliance violations and security oversights. AWS suggests including those terms directly in CIP-002 for clarity.

It would be helpful if the SDT provided in Implementation Guidance a logic diagram depicting how the device classifications and embedded definitions like Management Interface and CIP System can be applied.

Lastly, the SDT has been clear that this project focuses on on-premise virtualization, however, many virtualization concepts could be interpreted as being related to cloud computing technologies. AWS suggests explicitly stating that the Standards do not apply to cloud within the Applicability section of CIP-002.  If these updated Standards do not apply to cloud, it should be obvious to the reader.

Maggy Powell, Amazon Web Services, 7, 9/1/2021

- 0 - 0

Southern generally agrees with the proposed changes to CIP-002 but with these suggestions for improvement.  For R1.1 it would be clearer if it said “identify each high impact BCS as either of the following, if any, at each asset.” The same for R1.2, “identify each medium impact BCS as either of the following, if any, at each asset.” Both high and medium impact are clearly identified, and it does not imply that all BCS within an asset are of the same impact level.

In addition, we suggest that CIP-002 not imply any process steps as identification methods vary within differing environments.  Keep CIP-002 R1 as results-oriented as it has always been.  We suggest capturing the options for SCI identification within the relevant definitions (as it currently is in the SCI proposal) and keep CIP-002 as close to the version 5.1a language as possible.

Southern Company, Segment(s) 1, 3, 6, 5, 1/14/2021

- 0 - 0

LCRA Compliance, Segment(s) 6, 5, 1, 5/11/2015

- 0 - 0

ERCOT supports the IRC SRC comments and offers this additional comment:

  • Please see the ERCOT comments provided in Question 1.

Brandon Gleason, 9/1/2021

- 0 - 0

Recommend spelling out “Shared Cyber Infrastructure” within CIP-002 standard text

LeRoy Patterson, Public Utility District No. 2 of Grant County, Washington, 6, 9/1/2021

- 0 - 0

<duplicate>

Dana Showalter, On Behalf of: Electric Reliability Council of Texas, Inc., Texas RE, Segments 2

- 0 - 0

EEI notes significant improvements to CIP-002 but asks for additional clarity for the following:

1)      “SCI independently identified” is frequently used throughout CIP-002.  This phrase is not broadly understood and the intent needs to be clarified.

2)      In EEI’s comments to the previous draft of CIP-002, we expressed concern regarding the proposed removal of communications networks from the Exemption Section of the previous draft, noting that both data communication links and communication networks should remain exempt.  Nevertheless, this change remains in Draft 2 and EEI seeks clarification why communications networks remain excluded from the Exemptions section in this proposed draft of CIP-002.

3)      EEI recommends modifying 4.2.3.2 to align with endorsed ERO General Implementation Guidance titled “CIP Version 5 Transition Program, CIP-002-5-1: Communications and Networking Cyber Assets” dated October 6, 2015. EEI suggests the following:

4.2.3.2       Cyber Systems associated with:

4.2.3.2.1 Communication and networking devices between discrete Electronic Security Perimeters (ESP), and Cyber Systems associated with external communication to one or more geographic locations.” or

4.2.3.2.2 Non-routable communication externally directed between an ESP and one or more other geographic locations. or

4.2.3.2.3 Non-routable communication externally directed between BCS and one or more other geographic locations.

 4)      The inclusion of EACMS, PACS and PCAs seems redundant and possibly unnecessary in both the second bullet of R1.1 and the second bullet of R1.2.  If this is an intentional, EEI request clarification within the Technical Rationale explaining the purpose of including of EACMS, PACS and PCAs.  

Mark Gray, On Behalf of: Edison Electric Institute, NA - Not Applicable, Segments NA - Not Applicable

- 0 - 0

The requirement requires the identification of BCS as either “including any supporting SCI as part of the BCS” or with “independent SCI supporting any part of the high impact BCS or its associated Electronic Access Control or Monitoring Systems (EACMS), Physical Access Control Systems (PACS) or Protected Cyber Assets (PCAs).” This does not allow for the identification of BCS independent of having SCI, and therefore doesn’t account for non-virtualized environments.

The requirements and measures of CIP-002 do not sufficiently detail what is required to demonstrate compliance. The requirements are to create a list that identifies “each [BCS] as either” including supporting SCI or having independent SCI. However, the independent SCI details an association to EACMS, PACS, PCA. The requirement expects an identification of “BES Cyber Systems” but the sub-bullets imply an expectation to identify SCI and corresponding asset/system classifications. The measures and technical rationale provide no additional clarity other than creating lists. Is the expectation to simply provide identification that the identified BCS either include SCI or are supported by SCI (e.g. Yes/No or Checkbox), or is the expectation to explicitly identify and categorize SCI that meet this criteria (e.g. “1.) ABC High Impact BCS; 2.) CDE High Impact EACMS SCI”). If the expectation is to classify SCI, what should be the approach for classifying SCI that supports multiple classifications (e.g. EACMS and PACS)? As mentioned in Comment for #2 above, more clarity regarding grouping  SCI could be beneficial as well.

Gail Golden, Entergy - Entergy Services, Inc., 5, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

Alyssia Rhoads, Public Utility District No. 1 of Snohomish County, 1, 9/1/2021

- 0 - 0

 

PJM signs on to the comments provided by the IRC SRC.

Elizabeth Davis, On Behalf of: Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2; Tom Foster, PJM Interconnection, L.L.C., 2

- 0 - 0

Remove the following phrases:  from the second bullet on R1.1: “or its associated Electronic Access Control or Monitoring Systems (EACMS), Physical Access Control Systems (PACS) or Protected Cyber Assets (PCAs)” and from the second bullet on R1.2: “or its associated EACMS, PACS or PCAs.” These are expanding the scope of the CIP-002 identification and CIP Senior Manager approval, and identification of these associated with SCI will create confusion since these do not have to be identified in CIP-002 if they are not associated with SCI.

On Attachment 1, under the medium impact rating criteria 2.1, to clarify the second bullet, change it to begin: “Any SCI supporting BCS that could, within 15 minutes, adversely impact….” (Delete “(which must be included in a shared BCS),” “one or more” and “together.”

Lindsay Wickizer, Berkshire Hathaway - PacifiCorp, 6, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

Sam Nietfeld, Public Utility District No. 1 of Snohomish County, 5, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

SNPD Voting Members, Segment(s) 4, 6, 5, 1, 6/18/2020

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

John Martinsen, Public Utility District No. 1 of Snohomish County, 4, 9/1/2021

- 0 - 0

SNPD supports the comments provided by Sacramento Municipal Utility District (SMUD).

John Liang, Snohomish County PUD No. 1, 6, 9/1/2021

- 0 - 0

Request clarification of capitalization of “High Impact,” “Medium Impact” and “Low Impact.” Parts 1.1, 1.2 and 1.3 use lower case while other Standards use capitalization. Is there a difference? If so, please explain.

Request clarification on the “OR” in Part 1.3. What is the Entity required to identify? Assets or BCSI/SCI?

Request correction of typo in R2 from the beginning “Each” to “The”

Request clarification on the new (second) bullet in 2.1 in Attachment 1. Does the SDT intend that a series of Low Impact asset could be consolidated into Medium Impact asset due to shared SCI?

The current wording creates more questions than answers. We suggest being more precise. See comments detailed in question one. 

NPCC Regional Standards Committee, Segment(s) 10, 2, 4, 7, 3, 1, 5, 6, 8/6/2021

- 0 - 0

Portland General Electric Company supports this change, but generally agrees with the comments provided by EEI for this survey question.

Ryan Olson, Portland General Electric Co., 5, 9/1/2021

- 0 - 0

N&ST believes the proposed revisions to Medium Impact Criterion 2.1 are confusing, particularly the parenthetical note in the second bullet that SCI “…must be included in a shared BCS” in order to potentially meet this criterion. If N&ST’s understanding of the SDT’s intentions regarding SCI, namely, that a Responsible Entity has the option of either including an SCI in a BCS (or an EACMS or a PACS) or identifying it as “independent” but supporting one or more BCS, EACMS, or PACS is correct, then we believe the second bullet, as written, is unnecessary. However, “independently identified” SCI that support BCS that meet Criterion 2.1 should be accounted for.

N&ST also believes the SDT should address the fact that Criteria 2.1 and 2.2, although ostensibly similar, are not consistent with each other: Criterion 2.2, as proposed, makes no mention of SCI at all.

Roger Fradenburgh, On Behalf of: Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1; Nicholas Lauriat, Network and Security Technologies, 1

- 0 - 0

The IRC SRC requests the SDT clarify why the terms “High Impact,” “Medium Impact” and “Low Impact” are capitalized in some instances while in other instances; e.g. Parts 1.1, 1.2 and 1.3, lower case is used. Is there a difference? If so, please explain. If not, the IRC SRC recommends the SDT standardize the capitalization treatment of “High Impact,” “Medium Impact” and “Low Impact” throughout.

Request clarification on the “OR” in Part 1.3. What is the Entity required to identify? Assets or BCS/SCI?

Request correction of typo in R2 from the beginning “Each” to “The”

Request clarification on the new (second) bullet under 2.1 in Attachment 1. Does the SDT intend that a series of Low Impact assets could be consolidated into a Medium Impact asset due to shared SCI?

ISO/RTO Council Standards Review Committee 2016-02 Virtualization (Draft 2), Segment(s) 2, 9/1/2021

- 0 - 0

LaTroy Brumfield, American Transmission Company, LLC, 1, 9/1/2021

- 0 - 0

ITC supports the response submitted by EEI for this question.

Gail Elliott, On Behalf of: Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1; Michael Moltane, International Transmission Company Holdings Corporation, 1

- 0 - 0

Hot Answers

Portland General Electric Company supports the comments provided by EEI for this survey question. Additionally, Replacing "BES Cyber System" with "CIP System" in the proposed definition of ERC appears to expand the scope of ERC from what was previously in place and now would include remote routable connectivity to PACS or EACMS. PGE wonders if this was the drafting team’s intent. If not, Portland General Electric Company believes the phrase "CIP System" in the proposed definition of ERC could be replaced with "BES Cyber System" to resolve the scope expansion.

Dan Zollner, Portland General Electric Co., 3, 9/1/2021

- 0 - 0

Portland General Electric Company supports the comments provided by EEI for this survey question. Additionally, Replacing "BES Cyber System" with "CIP System" in the proposed definition of ERC appears to expand the scope of ERC from what was previously in place and now would include remote routable connectivity to PACS or EACMS. PGE wonders if this was the drafting team’s intent. If not, Portland General Electric Company believes the phrase "CIP System" in the proposed definition of ERC could be replaced with "BES Cyber System" to resolve the scope expansion.

PGE FCD, Segment(s) 5, 1, 3, 6, 9/11/2018

- 0 - 0

Other Answers

Richard Jackson, U.S. Bureau of Reclamation, 1, 8/19/2021

- 0 - 0

CIP-005-8 R1 Part 1.6 proposes the following:

Detect known or suspected malicious Internet Protocol (IP) communications entering or leaving an ESP.

In light of the new ESP definition, perhaps this requirement should state: Detect known or suspected malicious Internet Protocol (IP) communications entering or leaving an applicable system.

In the alternative, the new definition of ESP would need further refinement.  CIP-005-8 R1 Part 1.4 is another example where the language of the requirement appears to be using the approved ESP definition from CIP V5.

Dominion, Segment(s) 3, 5, 1, 9/19/2019

- 0 - 0

Jeanne Kurzynowski, On Behalf of: CMS Energy - Consumers Energy Company - RF - Segments 3, 4, 5

- 0 - 0

Chelan agrees in principle with CIP-005, but there is a major flaw in CIP-005 R2.  CIP-005-8 R2.1 includes "Intermediate Systems used to access Applicable Systems of Part 2.1" as part of the Applicable Systems. This language indicates that an Intermediate System is required to access an Intermediate System. Is this a typo? If not, additional clarification is requested.  This appears to create a hall of mirrors.

CHPD, Segment(s) 3, 1, 6, 5, 8/24/2021

- 0 - 0

 In Reference to CIP-005-8

No – As written, the proposed changes appear to require significant modification to our current network architecture without clearly indicating even how this can be accomplished in a compliant fashion or how that improves upon the existing security posture.  I have a request for additional information from the Standards Drafting Team to get clarity.

Glen Farmer, Avista - Avista Corporation, 5, 8/24/2021

- 0 - 0

No.  Please see NRG’s responses to questions 4 and 7.

Martin Sidor, NRG - NRG Energy, Inc., 6, 8/24/2021

- 0 - 0

:No.  Please see NRG’s responses to questions 4 and 7.

Patricia Lynch, NRG - NRG Energy, Inc., 5, 8/24/2021

- 0 - 0

See response to question #4.

Tennessee Valley Authority, Segment(s) 1, 3, 5, 6, 10/18/2018

- 0 - 0

Xcel Energy does not agree with the proposed changes in CIP-005. Independly identified SCI is listed throughout the applicable systems column and with our concern with the lack of clarity in Independly identified SCI, we can not support at this time.

While Xcel Energy does not support the approval of this Standard at this time, we do support other aspects in the modifications made as identified in EEI comments. 

Amy Casuscelli, On Behalf of: Xcel Energy, Inc. - MRO, WECC - Segments 1, 3, 5, 6

- 0 - 0

Andrea Jessup, On Behalf of: Bonneville Power Administration, WECC, Segments 1, 3, 5, 6

- 0 - 0

Mike Magruder, Avista - Avista Corporation, 1, 8/26/2021

- 0 - 0

For Part 1.1, we suggest including the word “directly” in this phrase “connected directly to a network” for absolute clarity that serial devices do not require an ESP, regardless of any upstream protections afforded by the newly proposed IRA definition. 

We also suggest that Part 1.1 be modified to remove the host-based language due to proposed inclusion in glossary term as described in response to Question 4.

We suggest aligning the Applicable Systems language in (current) Part 1.4 and (current) Part 1.6 using reference back to Part 1.1 with additional “at Control Centers” qualifier.

We suggest placing the “ESP outside PSP” requirement as the new Part 1.6 so that dial-up and malicious communications requirements maintain their current part numbers.  This minor change would allow for continuity of evidence references that would otherwise be confusing and burdensome. 

Inclusion of the ESP reference in the malicious communication requirement may present challenges for Zero Trust environments where an application layer firewall or IDS cannot be applied between each ESP.  Language such as the following would allow for more flexible implementations that still meet the security objective of this requirement: “Detect known or suspected malicious Internet Protocol (IP) communications entering or leaving an ESP.   Detection may occur at the boundary or as part of EACMS monitoring capabilities.”

Katie Connor, On Behalf of: Duke Energy - SERC, RF - Segments 1, 3, 5, 6

- 0 - 0

AECI, Segment(s) 1, 3, 6, 5, 3/4/2021

- 1 - 0

See MRO-NSRF and EEI Comments

Clarice Zellmer, WEC Energy Group, Inc., 5, 8/26/2021

- 0 - 0

NERC Definition Changes -- Electronic Security Perimeter (ESP) - removed the routable protocol qualifier. Consider the following:

  • The new ESP qualifier is an EACMS. The EACMS definition does not have a routable protocol/communication qualifier, and it references ESPs.  It seems like a circular definition.
  • When looking at the definitions only, it appears to require serial connected Cyber Assets have an EACMS to protect their serial communication links, however they are not required to have an Electronic Access Point (EAP) as the EAP definition has a routable communication qualifier.
  • When assessing CIP-005-8 R1.1 the Requirements section qualifies ESPs are only required for Applicable Systems with routable protocols.  It does not have a qualifier of ERC so if there is only ethernet within a system that never leaves an asset, an ESP is required even if you have no EAP.  This is the same as V5 of the standards.
  • If a BCA has both serial and Ethernet communications that leave an asset, auditors could require an EACMS for serial connections because a BCA that has routable protocol leaving an asset is required to have an ESP, and an ESP is required to have an EACMS. The same BCA serial that would leave the asset would require an EACMS because the ESP definition does not exclude serial communication. Not sure what type of device a serial EACMS would be.
  • The SDT proposed definition creates ambiguity around serial communication configurations and whether they have to be documented as part of an ESP. 

We recommend revising CIP-005-X R1 Part 1.1 to read:

Applicable Systems connected to a network via a routable protocol must be protected by an ESP that permits only needed communications and denies all other commuincations. Host-based firewalls that only protect the host on which they reside are not a sufficient control to meet this requirement.
Excluding:

  • Time sensitive protection or control functions between intelligent electronic devices
  • Cyber Asset to Cyber Asset serial communication not meeting the IRA definition

We also want to point out that CIP-005-8 R1 Part 1.1 specifically denies ‘Host-based firewalls that only protect the host on which they reside are not a sufficient control to meet this requirement’ which does not meet the objective based model that the standards are supposed to now be written to.  This very specifically identifies a technology that cannot be used to meet the requirement.  This statement appears to be in conflict with the Technical Rationale for the ERC term.

ERC is no longer based on ‘external’ being defined in terms of the ESP as ESPs are changing in light of Zero Trust models. Zero Trust will shrink ESP’s over time to the smallest, most granular object possible including a single device or possibly to process or resource level on a device.

 

Additionally, question #10 begins by asking about the revised CIP-005 but then asks about proposed changes to the NERC Glossary terms. We presume that this is a typo and that the question was about CIP-005.

Ronald Bender, Nebraska Public Power District, 5, 8/27/2021

- 0 - 0

We agree with the changes to the standard, however, the potential clarity issues that arise from the definition changes of ESP (and subsequently an EACMS) may cause unintended scoping regarding Registered Entities BCS in the field. See question 4 for further explanation and alternative proposal. 

Josh Johnson, Lincoln Electric System, 1, 8/27/2021

- 0 - 0

Consider adding ‘Virtual Cyber A