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

2019-02 BES Cyber System Information Access Management

Description:

Start Date: 12/20/2019
End Date: 02/03/2020

Associated Ballots:

Ballot Name Project Standard Pool Open Pool Close Voting Start Voting End
2019-02 BES Cyber System Information Access Management CIP-004-7 IN 1 ST 2019-02 BES Cyber System Information Access Management CIP-004-7 12/20/2019 01/20/2020 01/24/2020 02/03/2020
2019-02 BES Cyber System Information Access Management CIP-011-3 IN 1 ST 2019-02 BES Cyber System Information Access Management CIP-011-3 12/20/2019 01/20/2020 01/24/2020 02/03/2020
2019-02 BES Cyber System Information Access Management Implementation Plan IN 1 OT 2019-02 BES Cyber System Information Access Management Implementation Plan 12/20/2019 01/20/2020 01/24/2020 02/03/2020

Filter:

Hot Answers

OPG is in agreement with RSC provided comment

Constantin Chitescu, Ontario Power Generation Inc., 5, 2/3/2020

- 0 - 0

In its current form, CIP-004 and CIP-011 already provides flexibility.

The current requirements to address access to sensitive data and information seem acceptable in the current formats.

What is unclear is how the BCSI will be usable if it must always reside in specific locations? For example, is it violation if someone who has access, temporary pulls that information off the stored location and prints the document for review? While a copy of that data is stored in the storage location, the hard copy now creates an issue. What happens when that person takes it outside the physical security perimeter? Entities should be required to describe how they identify BCSI, how BCSI is transmitted, whom may have access to the data and information, the description electronic access controls, and how exceptions, if any, exist in relation to the use of the information outside of those parameters.

The real issue is where it is stored. Auto saves, inadvertent machine shutdowns, etc. may cause the data to be stored in a location outside the acceptable storage location. Virtualization, Office 365, etc. may cause issues for entities to be able to ensure the information is never stored outside of a set storage location. While SunPower believes there can be adequate controls, the programs and systems industry use will likely cause an increase of possible violations as those programs and systems change by the provider. Temporary storage on local devices that are also secured by an approved user should be allowed, at least on a temporary basis.

Bradley Collard, 2/3/2020

- 0 - 0

Other Answers

I don't see the referenced changes in CIP-004-7.  If you are refering to CIP-011-3, "storage locations" is very broad.  This could be a problem during audits, if the auditor does not like the interpretation.  We need a much stricter wording for storage locations.

Kevin Conway, Public Utility District No. 1 of Pend Oreille County, 1, 12/23/2019

- 1 - 0

Calvin Wheatley, On Behalf of: Wabash Valley Power Association, SERC, RF, Segments 1, 3

- 0 - 0

While the requirement seems flexible, it is subject to confusion in implementation.  The previous version specificially identified electronic or physical controls.  This version extends scope to include the cloud.  However, in doing so, it removes the context for full understanding of the requirement.  Lacking this context, there is a signficant potential of having multiple interpretations of the requirement. 

Susan Sosbe, Wabash Valley Power Association, 3, 1/22/2020

- 1 - 0

Comments: We feel the language could be clearer if the BES Cyber System itself was excluded being it is already being protected by the NERC CIP requirements.  The same problem exists within the standard today. It does not exclude BCSI contained within the BES Cyber System itself.  Although it is inherent BES Cyber Systems contain BCSI, the standards do not exclude those systems/Cyber Assets from containing BCSI, thus the Cyber Assets themselves would be BCSI repositories and should be documented as such.  We have not seen this as a problem in audit, but a strict auditor could make this an issue the way it is written. 

Also, examples of potential Cyber Assets containing BCSI could be better expanded in the Guidelines and Technical Basis, such as SIEMs, Anti-virus servers, backup servers, etc. which are not a part of a BES Cyber System and the rationale behind why they are or are not considered BCSI repositories. 

William Hutchison, On Behalf of: Southern Illinois Power Cooperative, , Segments 1

- 0 - 0

Duke Energy generally agrees that CIP-011-3 R1, Part 1.1 allows flexibility to identify which storage locations are for BCSI and agree the requirement is necessary.

Duke Energy, Segment(s) 1, 5, 6, 3, 12/13/2019

- 0 - 0

While we agree that including the need to identify storage locations, this could prove burdensome to entities. Identification of a location in cloud storage providers (e.g. OneDrive, Microsoft Teams, Sharepoint, etc.) which offer seamless creation and storage of documentation may make it difficult to identify specific storage locations. This could result in entities not listing key storage locations or generalizing, at a loss of security, in order to meet the requirement.

DTE Energy - DTE Electric, Segment(s) 5, 4, 3, 2/27/2017

- 0 - 0

There is more than one question and we vote yes on the first question and no on the second. There should only be one quetion, not two.

Scott Miller, On Behalf of: Roger Brand, MEAG Power, 1,3; Roger Brand, MEAG Power, 1,3; Roger Brand, MEAG Power, 1,3; David Weekley, MEAG Power, 1,3; David Weekley, MEAG Power, 1,3; David Weekley, MEAG Power, 1,3

- 0 - 0

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

- 0 - 0

Yes, due to improved applicability and exclusion of low impact assets.

Public Utility District No. 1 of Chelan County, Segment(s) 3, 1, 1/27/2020

- 0 - 0

Karl Blaszkowski, CMS Energy - Consumers Energy Company, 3, 1/28/2020

- 0 - 0

Donald Lynd, CMS Energy - Consumers Energy Company, 1, 1/28/2020

- 0 - 0

It is already implied in CIP-004 R4 that storage locations have to be identified and adds to the complexity of the compliance requirement.  Flexibility is already provided under CIP-004 R4.  Access controls were grouped in CIP-004 R4, relocating these controls to CIP-011 creates additional complexities.

Joe Tarantino, On Behalf of: Kevin Smith, Balancing Authority of Northern California, 1; Kevin Smith, Balancing Authority of Northern California, 1; Kevin Smith, Balancing Authority of Northern California, 1; Jamie Cutlip, Sacramento Municipal Utility District, 1,3,4,5,6; Jamie Cutlip, Sacramento Municipal Utility District, 1,3,4,5,6; Jamie Cutlip, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Beth Tincher, Sacramento Municipal Utility District, 1,3,4,5,6; Beth Tincher, Sacramento Municipal Utility District, 1,3,4,5,6; Beth Tincher, Sacramento Municipal Utility District, 1,3,4,5,6; Arthur Starkovich, Sacramento Municipal Utility District, 1,3,4,5,6; Arthur Starkovich, Sacramento Municipal Utility District, 1,3,4,5,6; Arthur Starkovich, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6

- 0 - 0

An overarching problem with this proposed draft of CIP-011-3 is the removal of the qualifying language “with ERC” from the applicability of Medium Impact BES Cyber Systems in CIP-011-3 R1.1 as currently provided in CIP-004-6 R4.1, and how this greatly and needlessly expands the scope of all subsequent parts of R1, and R2.

Identifying BCSI storage locations for system information pertaining to Medium Impact BES Cyber Systems without ERC is not necessary, as Cyber Systems without remote connectivity can only be compromised locally by a breach of physical security. The information protection mandated by this standard will afford no protection should an adversary gain physical access to the Cyber Systems.

We will not be able to vote affirmative unless “with ERC” is added to the Applicability of of Medium Impact BES Cyber Systems in R1 Part 1.1.

We agree that the language provides flexibility in identifying BCSI storage locations.

We would prefer to retain the less prescriptive “Method(s)” over the proposed requirement change to “Process(es).” Making this change to “process” implies that existing programs will need to be updated to a procedural format. Again, this is not requested by the SAR and does not increase reliability, yet this would add administrative burden and increase compliance risk.

To clarify location with respect to electronic storage locations, recommend the definition of “BCSI Repository” per EEI comments along these lines:

“BCSI Repositories are either physical or electronic storage locations where BCSI is retained for long term storage.  For physical BCSI Repositories, this would be a physical location.  For electronic BCSI Repositories, this would be a logical location.  Short term storage locations for working copies are not part of this definition.”

MRO NSRF, Segment(s) 3, 4, 5, 6, 1, 2, 1/29/2020

- 0 - 0

FE Voter, Segment(s) 1, 3, 5, 6, 4, 10/31/2019

- 0 - 0

Xcel Energy support the comments submitted by EEI.

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

- 0 - 0

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

- 0 - 0

Support the MRO NSRF comments

Jeremy Voll, Basin Electric Power Cooperative, 3, 1/30/2020

- 0 - 0

Anthony Jablonski, ReliabilityFirst , 10, 1/30/2020

- 0 - 0

Agree with adding requirement to identify BCSI storage locations even though it is already

Implicitly required to be identified in CIP-004-6 R4.1. To better identify BCSI storage locations, we

would suggest making a definition of BCSI Repository as follows:

“A multi-user electronic or physical locations where a collection of BCSI is retained for long-term

  storage.”

Bruce Reimer, Manitoba Hydro , 1, 1/30/2020

- 0 - 0

Although the proposed revision explicitly states the requirement to identify specific BCSI storage locations, it does not add any actual new flexibility about designating BCSI storage locations. The same flexibility exists today between the lines of existing CIP-004 and CIP-011. It is just implicit, rather than explicit. The confusion remains about the necessity (or lack thereof) to store BCSI in designated BCSI storage locations, how large a collection of BCSI has to be to warrant a BCSI storage location of its own, or how long BCSI can be in use outside of a storage location without creating security and compliance concerns.

Seattle City Light believes a more effective approach would be to clearly state a security objective (“to prevent unauthorized access to BCSI”), require an entity to develop a risk-informed BCSI security plan to achieve this objective, and then require implementation and periodic review of the BCSI security plan. Beyond this, almost all details about specific approaches for and elements that might be expected in a BCSI security plan should be provided in the measures and/or technical guidelines. A few specific elements of the security plan might be requested as sub-requirements, such as i) how to identify BCSI; ii) controls to limit unauthorized access to BCSI in use, transit, and storage; and iii) security requirements expected of third party that uses and/or stores BCSI for the entity, if an entity chooses to employ such parties. Note that by iii) Seattle does NOT mean that any specific security requirements for third party providers should be spelled out as requirement in the revised Standard, but rather than each entity should develop its own risk-based list of the security controls/requirements it demands of any third party provider it may employ with regard to BCSI. And that such entity-specific control requirements would only be required if an entity elected to use third-party BCSI providers. Guidance as to what these requirements might be could be provided in the Measures or supporting technical document.

If a more prescriptive approach to controls is desired, Seattle shares the same concerns expressed by Sacramento Municipal Utility District (SMUD) regarding the change of language about BCSI storage locations.

Matthew Nutsch, On Behalf of: Seattle City Light, WECC, Segments 1, 3, 4, 5, 6

- 0 - 0

‘System Information pertaining to’ in the applicability column may broaden scope expectations and should be removed.

Kjersti Drott, Tri-State G and T Association, Inc., 1, 1/31/2020

- 0 - 0

We support the overall effort. However, we do not support introducing "System information pertaining to" in the applicability section.  This creates some ambiguity.  We believe that the applicability should be limited to BCSI.

Payam Farahbakhsh, Hydro One Networks, Inc., 1, 1/31/2020

- 0 - 0

The draft language in present form would obligate entities to establish a Data Loss Prevention program to fully satisfy this requirement. This doesn’t support the scope or intent of the original SAR. This goes far beyond controlling access to BCSI and includes topic that may cover how an individual may handle that information (replication, forwarding, etc.). The previous version included the term “Designated repository” for identification of scope of protection. Removal of this qualification creates an obligation to manage BCSI regardless of where it may occur.

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

- 0 - 0

As written the requirement may require the Registered Entity (RE) identify the physical locations a third-party provider is storing the RE’s BCSI. We think that it would make more sense to identify the access controls and methods the RE has in place controlling the ability to obtain and use the information.

Maryanne Darling-Reich, On Behalf of: Black Hills Corporation - MRO, WECC - Segments 1, 3, 5, 6

- 0 - 0

AEP agrees with EEI’s comments and requests clarification on the requirement to identify BES Cyber System Information (BCSI) storage locations as proposed by the Standard Drafting Team (SDT) for CIP-011-3, Requirement R1, Part 1.1.  As written, this requirement would require registered entities to work with their third-party cloud-based service providers to identify the physical location where their BCSI resided on the service provider’s cloud-based network.  This would be difficult (or possibly impractical) for entities to maintain suitable records on an ongoing basis. 

Also, from a compliance perspective, registered entities would have difficulty proving that they granted or removed access to BCSI, as required in the proposed draft for CIP-004-7.  To resolve this concern, we suggest that the SDT modify the proposal to require registered entities to prove access is granted or removed to a BCSI Repository.

Kent Feliks, AEP, 3, 1/31/2020

- 0 - 0

Russel Mountjoy, Midwest Reliability Organization, 10, 1/31/2020

- 0 - 0

AECI supports comments filed by NRECA

AECI, Segment(s) 1, 3, 6, 5, 5/31/2019

- 0 - 0

NRECA does not support the replacement of the term “method” with the term “process.”  A “method” for identification allows Responsible Entities to provide guidelines and criteria to their personnel to aid in identification of BCSI without requiring a pre-defined series of steps or action (e.g., a process) to be utilized by such personnel in the identification.  This distinction is critical because a process can be high-level and – thereby – provide significant variability in what is identified as BCSI whereas a method provides personnel with enough guidance to provide consistency relative to BCSI identification without being overly prescriptive regarding how such identification is accomplished.

Additionally, NRECA does not support the addition of a requirement to “identify applicable BES Cyber System Information storage location.”  The Technical Rationale indicates that the SDT wanted to shift focus from the storage location to the information; however, this addition places the focus back on to the storage location for what appears to be solely administrative purposes.  As well, the description of what was intended for identification in the Technical Rationale exceeds the scope of the verbiage added to Requirement R1.1.  Identification of an object is different than description of an object and the requirement language addresses only the former while the Technical Rationale is clearly suggesting the latter.  Thus, this addition creates ambiguity and confusion regarding Responsible Entity’s obligations for little or no benefit to BES reliability. 

Barry Lawson, National Rural Electric Cooperative Association, 4, 2/3/2020

- 0 - 0

The addition of a new requirement is not necessary because 1) REs already have the flexibility to identify BCSI storage locations, and 2) None of the rest of the proposed requirements reference storage locations anyway.  

Andy Fuhrman, On Behalf of: Theresa Allard, Minnkota Power Cooperative Inc., 1; Theresa Allard, Minnkota Power Cooperative Inc., 1; Theresa Allard, Minnkota Power Cooperative Inc., 1

- 0 - 0

GSOC does not support the replacement of the term “method” with the term “process.”  A “method” for identification allows Responsible Entities to provide guidelines and criteria to their personnel to aid in identification of BCSI without requiring a pre-defined series of steps or action (e.g., a process) to be utilized by such personnel in the identification.  This distinction is critical because a process can be high-level and – thereby – provide significant variability in what is identified as BCSI whereas a method provides personnel with enough guidance to provide consistency relative to BCSI identification without being overly prescriptive regarding how such identification is accomplished.

Additionally, GSOC does not support the addition of a requirement to “identify applicable BES Cyber System Information storage location.”  The Technical Rationale indicates that the SDT wanted to shift focus from the storage location to the information; however, this addition places the focus back on to the storage location for what appears to be solely administrative purposes.  As well, the description of what was intended for identification in the Technical Rationale exceeds the scope of the verbiage added to Requirement R1.1.  Identification of an object is different than description of an object and the requirement language addresses only the former while the Technical Rationale is clearly suggesting the latter.  Thus, this addition creates ambiguity and confusion regarding Responsible Entity’s obligations for little or no benefit to BES reliability. 

Andrea Barclay, Georgia System Operations Corporation, 4, 2/3/2020

- 0 - 0

SMEC agrees with comments submitted by NRECA.

SMEC also disagrees with the removal of the qualifying language “with ERC” from the applicability of Medium Impact BES Cyber Systems in CIP-011-3 R1.1 as currently provided in CIP-004-6 R4.1, and how this greatly and needlessly expands the scope of all subsequent parts of R1, and R2.

Lana Smith, San Miguel Electric Cooperative, Inc., 5, 2/3/2020

- 0 - 0

We feel the language could be clearer if the BES Cyber System itself was excluded being it is already being protected by the NERC CIP requirements.  The same problem exists within the standard today. It does not exclude BCSI contained within the BES Cyber System itself.  Although it is inherent BES Cyber Systems contain BCSI, the standards do not exclude those systems/Cyber Assets from containing BCSI, thus the Cyber Assets themselves would be BCSI repositories and should be documented as such.  We have not seen this as a problem in audit, but a strict auditor could make this an issue the way it is written. 

Also, examples of potential Cyber Assets containing BCSI could be better expanded in the Guidelines and Technical Basis, such as SIEMs, Anti-virus servers, backup servers, etc. which are not a part of a BES Cyber System and the rationale behind why they are or are not considered BCSI repositories. 

ACES Standard Collaborations, Segment(s) 1, 3, 2/3/2020

- 0 - 0

Dwayne Parker, 2/3/2020

- 0 - 0

IESO agrees in principle with the comments submitted by NPCC:

  1. We recommend security objectives instead of prescriptive requirements. Information protection program should include identification, access control, etc.
  2. For the Applicability column referencing “system information,” we suggest changing “System information pertaining to:” to “Information associated with,” or clarification of what is considered “system information”
  3. We recommend clarifying by stipulating that the Entity’s information protection plan includes a description of the storage location(s) and that the Entity maintains a list of those storage locations
  4. It is unclear if the intent of R1.1. is also for an entity to *develop a process* to list the storage locations or the actual inventory list of the storage locations. If the intention is not a “process”, then subdivide 1.1 requirement into two component parts:  1.1.1 a process to identify what constitutes BCSI and 1.1.2 a second requirement to have an inventory of locations.

Leonard Kula, Independent Electricity System Operator, 2, 2/3/2020

- 0 - 0

No, the current version of CIP-004 already provides for the identification of BCSI storage locations.  Keeping all the requirements for access and revocation in one standard decreases the complexity for compliance.

Santee Cooper, Segment(s) 1, 3, 5, 6, 2/3/2020

- 0 - 0

 

The SDT should consider that with cloud computing the physical location of BCSI is irrelevant. It is more important to protect the data vs where the data is located. Cloud computing currently replicates data in data centers world-wide. Entities will not be able to verify where cloud BCSI exists.

This is duplicative in nature.  The requirement to approve access by itself requires entitites to know where the data is located.  Hence authorization though roles or entitlments identifies the locations of the BCSI.  

sean erickson, Western Area Power Administration, 1, 2/3/2020

- 0 - 0

With respect to Applicability, the term 'System Information" is undefined.  Perhaps the team intended to include "BES Cyber System Information"  In any case, greater clarification of this term is needed.

The term "Method" allows the Registered Entity greater flexibility to provide guidance to meet the intended security objectives of the requirement.  In that regard, I do not agree that the use of the term "process" is a better choice for this requirement as this implies a rigid step-by-step structure.

With respect to the Measure concerning "Indications on information.......", the language should be clarified to permit classification of the electronic storage location as contaning BCSI and not each individual document or file while at rest within that access-controlled location.  Indications should be considered for data in transit.

I agree that a listing of individual storage locations for BCSI should be identified and maintained.

Gerry Adamski, Cogentrix Energy Power Management, LLC, 5, 2/3/2020

- 0 - 0

Vivian Moser, 2/3/2020

- 0 - 0

New and emerging technologies shift the paradigm of security controls away from a specific storage location/repository to the ability to access and use the information itself. For example, an entity that utilizes file level security can apply encrypted protections on the data that preclude unauthorized access to the data regardless of where it is stored.  Requiring a list of storage locations is an antiquated construct that disincentivizes entities from using potentially more secure mechanisms because of the impossibility of compliance with documenting storage locations. The requirement should be technology agnostic and objective based, so it is written to focus on the implementation of effective methods that afford adequate security protections to prevent unauthorized access to the information.    

LaTroy Brumfield, American Transmission Company, LLC, 1, 2/3/2020

- 0 - 0

Truong Le, On Behalf of: Chris Gowder, Florida Municipal Power Agency, 3,4,5,6; Chris Gowder, Florida Municipal Power Agency, 3,4,5,6; Chris Gowder, Florida Municipal Power Agency, 3,4,5,6; Carol Chinn, Florida Municipal Power Agency, 3,4,5,6; Carol Chinn, Florida Municipal Power Agency, 3,4,5,6; Carol Chinn, Florida Municipal Power Agency, 3,4,5,6; Dale Ray, Florida Municipal Power Agency, 3,4,5,6; Dale Ray, Florida Municipal Power Agency, 3,4,5,6; Dale Ray, Florida Municipal Power Agency, 3,4,5,6; Richard Montgomery, Florida Municipal Power Agency, 3,4,5,6; Richard Montgomery, Florida Municipal Power Agency, 3,4,5,6; Richard Montgomery, Florida Municipal Power Agency, 3,4,5,6; David Owens, Gainesville Regional Utilities, 1,3,5; David Owens, Gainesville Regional Utilities, 1,3,5; David Owens, Gainesville Regional Utilities, 1,3,5

- 0 - 0

‘System Information pertaining to’ in the applicability column may broaden scope expectations and should be removed.

Janelle Marriott Gill, Tri-State G and T Association, Inc., 3, 2/3/2020

- 1 - 0

See NRECA submitted comments. 

Jonathan Robbins, Seminole Electric Cooperative, Inc., 4, 2/3/2020

- 1 - 0

New R1.1 still stresses “Identify applicable BES Cyber System information storage locations.” According to the SAR, the emphasis was supposed to move away from storage “locations” and focus on the protection of the information itself. However, to maintain security of information being stored outside of a Registered Entity using cloud services and vendors, to conform to the SAR, and without imposing undue regulatory burdens to entities using encryption key management for BCSI stored within the Responsible Entity, the language should be modified to say “Identify applicable BES Cyber System information storage locations not owned or managed by the Responsible Entity.

Anton Vu, Los Angeles Department of Water and Power, 6, 2/3/2020

- 0 - 0

N&ST suggests changing: “Process(es) to identify information that meets the definition of BES Cyber System Information and identify applicable BES Cyber System Information storage locations” to “Process(es) to identify information that meets the definition of BES Cyber System Information and to identify BES Cyber System Information storage locations.”

Nicholas Lauriat, Network and Security Technologies, 1, 2/3/2020

- 0 - 0

Yes, we agree that the language in R1 Part 1.1, as written, allows the Responsible Entity the flexibility in identifying BCSI storage locations.

 

While the requirement is necessary, we do propose splitting R1 Part 1.1 into two parts as follows:

 

In Part 1.1: change the Requirement to delete the phrase, “and identify applicable BES Cyber System Information storage locations.” Also, in the Measures, delete last bullet.

 

Recommend creating a new Part 1.2: with the ‘Applicability’ as Part 1.1, but add, “with ERC” to Medium Impact BES Cyber Systems, and in the Requirement section,  “Method(s) to identify applicable BES Cyber System Information storage locations.”

 

We agree with EEI’s suggestion to create the new term “BCSI Repository” to better define BCSI storage locations.

 

Applicability of current R1 Parts 1.3 to 1.6, and R2 Parts 2.1 and 2.2, change to reference a newly created R1 Part 1.2.

Sandra Shaffer, Berkshire Hathaway - PacifiCorp, 6, 2/3/2020

- 0 - 0

ALAN ADAMSON, New York State Reliability Council, 10, 2/3/2020

- 0 - 0

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

- 0 - 0

Texas RE recommends revising “System information” to “Information” in the Applicability column to be consistent with the Requirement language.

Rachel Coyne, Texas Reliability Entity, Inc., 10, 2/3/2020

- 0 - 0

Dominion Energy supports the work the SDT has done on develoing the current draft. Dominion energy suggests that the team focus on the approach taken in the current NERC CMEP Guidance document in addressing the issue and further supports EEIs comments.

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

- 0 - 0

Exelon supports EEI's comments on behalf of Exelon Segments 1, 3, 5, and 6.

Kinte Whitehead, Exelon, 3, 2/3/2020

- 0 - 0

Ameren agrees with and supports EEI comments.

David Jendras, Ameren - Ameren Services, 3, 2/3/2020

- 0 - 0

NCEMC supports the comments by Barry Lawson, National Rural Electric Cooperative Association and ACES

Kagen DelRio, On Behalf of: North Carolina Electric Membership Corporation - SERC - Segments 3, 4, 5

- 0 - 0

Part 1.1 as written requires a process for identifying two things; BCSI and BCSI storage locations.  However there is no other mention of BCSI storage locations within the standard.  Since there are no proposed requirements for these storage locations, a process to identify them has no function.  The remainder of the requirements apply to the BCSI as identified in R1.1 with no further mention of the storage locations.  We are concerned with the philosophical shift from BCSI storage locations as the object of many of the requirements to the BCSI itself, in particular all the requirements that were previously in CIP-004.  Managing and auditing access to BCSI as simply information in whatever form and wherever it is being used is an infinite scope.  In order for access to be managed and audited, it must have finite and discrete objects such as designated BCSI storage locations.  For example, entities will be unable to prove compliance with CIP-011 (R1.3 and R1.5 in particular) on BCSI as it exists in the form of a working copy of a printed network diagram used by a technician in a substation to troubleshoot a communications issue.  By making BCSI the object of the requirements rather than the designated storage locations, the scope has been expanded to a point that is unmanageable and unmeasurable with which entities are unable to prove compliance.  We suggest the object of the requirements remain as they were in CIP-004 and explicitly reference designated BCSI storage locations as their object, not simply BCSI.

 

 

Also, the requirement does not “allow an entity the flexibility” to identify storage locations for BCSI, it requires that an entity do so. The identification of storage locations containing BCSI is, for all practical audit purposes, already required under CIP-011-2 (See the NERC Evidence Request Tool, BCSI Tab), and the proposed wording does not allow any flexibility – it explicitly requires an entity to develop and maintain a list.

 

The applicability of Part 1.1 has changed to “System information pertaining to…”, which raises a concern over what “system information” is and how does an entity prove they have performed their BCSI identification process on the universe of all such information?  We are concerned that “system information” is not a finite or discrete scope for this requirement.  A requirement with a stated applicability of all possible information about a system is a showstopper issue. 

 

Southern suggests that instead it should require a process for determining BCSI for high/medium impact BCS.  An example replacement R1 that is not in “table format” could state “Each Responsible Entity shall have a process to identify BCSI that pertains to high impact or medium impact BCS and their associated EACMS and PACS.”   Subsequent R2, R3, etc. could then outline the necessary parts of the information protection program scoped to that identified BCSI.

 

If keeping the table format for R1 is desired, retaining the the high/medium impact BCS as the applicability of Part 1.1 and then require “Processes to identify BCSI that pertain to the applicable systems” is preferable.  It should stay scoped to high/med impact BCS and not the full universe of system information. 

Southern Company, Segment(s) 1, 3, 5, 6, 12/13/2019

- 0 - 0

Tho Tran, On Behalf of: Lee Maurer, Oncor Electric Delivery, 1; Lee Maurer, Oncor Electric Delivery, 1; Lee Maurer, Oncor Electric Delivery, 1

- 0 - 0

SDG&E supports EEI’s comments submitted on our behalf.

In addition, as an alternative to EEI’s proposed definition for BCSI Repository, SDG&E tenders its alternate definition below:

BCSI Repository – Either a physical or electronic storage location where BES Cyber System Information is stored, and for which access is controlled. For physical BCSI Repositories, this would be a physical location. For electronic BCSI Repositories, this would be a logical location.

Bridget Silvia, Sempra - San Diego Gas and Electric, 3, 2/3/2020

- 0 - 0

ITC supports the response found in the NSRF Comment Form

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

- 0 - 0

  1. We would recommend security objectives (similar to CIP-013-1) instead of prescriptive requirements. Information protection program should include identification, access control, etc.

  2. We suggest changing “System information pertaining to:” to “Information associated with,” or clarify the term “system information”.

Eversource Group, Segment(s) 3, 1, 4/12/2019

- 0 - 0

Yes, we agree that the language in R1 Part 1.1, as written, allows the Responsible Entity the flexibility in identifying BCSI storage locations.

 

However, we share the concerns expressed by EEI.

 

While the requirement is necessary, we do propose splitting R1 Part 1.1 into two parts as follows:

 

In Part 1.1: change the Requirement to delete the phrase, “and identify applicable BES Cyber System Information storage locations.” Also, in the Measures, delete last bullet.

 

Recommend creating a new Part 1.2: with the ‘Applicability’ as Part 1.1, but add, “with ERC” to Medium Impact BES Cyber Systems, and in the Requirement section,  “Method(s) to identify applicable BES Cyber System Information storage locations.” This could in turn be changed to “Method(s) to identify applicable BES Cyber System Information Repositories” per the EEI recommendations.

 

We agree with EEI’s suggestion to create the new term “BCSI Repository” to better define BCSI storage locations.

 

Applicability of current R1 Parts 1.3 to 1.6, and R2 Parts 2.1 and 2.2, change to reference a newly created R1 Part 1.2.

Kevin Salsbury, Berkshire Hathaway - NV Energy, 5, 2/3/2020

- 0 - 0

Please see comments submitted by Edison Electric Institute

Ayman Samaan, 2/3/2020

- 0 - 0

Our first suggestion is that the Applicability for 1.1 be returned to it’s original state without any additional conditions or prerequites.  Absent that,

  1. We recommend security objectives instead of prescriptive requirements. Information protection program should include identification, access control, etc.

  2. Since we have some debate over “system information,” we suggest changing “System information pertaining to:” to “Information associated with,” or clarification of “system information”.  At a minimum, if “system information” must be used. It should be established as a NERC glossary Defined Term.

  3. We recommend clarifying by stipulating that the Entity’s plan includes a description of the storage location(s) and maintains a list of those storage locations.

David Rivera, New York Power Authority, 3, 2/3/2020

- 0 - 0

The SAR stressed that changes would be focused on “…BCSI and the ability to obtain and make use of it”, where the current standard “…focused on access to the ‘storage location’…”, yet the proposed changes add additional requirements to identify the storage locations.  This seems to be contrary to the main objective of the SAR.  We have additional concerns about what the SDT means about storage location and how it pertains to storage at vendors and their networks.  We suggest that the SDT clarify what their intent was regarding the changed requirement on storage location. 

 

Additionally, the proposed changes add PCAs as applicable systems, which by definition do not contain BCSI.   It seems that this addition is outside of the SAR and it would be helpful for the SDT to describe how adding this “clarifies the protections expected when utilizing third-party solutions”.  We believe that no changes are needed to R1 Part 1.1 to address the SAR and thus, the current language should remain the same. 

PPL NERC Registered Affiliates, Segment(s) 1, 3, 5, 6, 9/6/2018

- 0 - 0

Support MRO comments.

Wayne Guttormson, SaskPower, 1, 2/3/2020

- 0 - 0

Steve Toosevich, NiSource - Northern Indiana Public Service Co., 1, 2/3/2020

- 0 - 0

See Steven Toosevich's comments.  

Kathryn Tackett, NiSource - Northern Indiana Public Service Co., 5, 2/3/2020

- 1 - 0

CenterPoint Energy Houston Electric, LLC (CEHE) supports the comments as submitted by the Edison Electric Institute.

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

- 0 - 0

EEI member companies (EEI) identified four issues for further consideration by the SDT and proposes solutions to address some of those issues.

First, EEI urges the SDT to clarify the requirement to identify BES Cyber System Information (BCSI) storage locations as proposed by the SDT for CIP-011-3, Requirement R1, Part 1.1. The requirement, as written, requires registered entities to work with their third-party cloud-based service providers to identify the physical location where their BCSI resided on the service provider’s cloud-based network. The challenge is the difficulty and, potential impracticality for entities to track down and maintain records from service providers to demonstrate compliance on a continuing basis.  To address this challenge, the SDT should clarify BCSI “Storage Location” and address electronic and physical repositories within that definition.  As an alternative, EEI suggests the SDT define the term “BCSI Repository,” which would provide registered entities a simpler solution than what was provided in the proposed revisions to CIP-004-7 and CIP-011-3.  Additionally, EEI offers the following definition for SDT review and consideration: 

BCSI Repository – Either a physical or electronic storage location where BES Cyber System Information is retained.  For physical BCSI Repositories, this would be a physical location.  For electronic BCSI Repositories, this would be a logical location.  Notes: Issues surrounding short term storage of BCSI (e.g., working copies, etc.) are not intended to be part of this definition but would need to be addressed by responsible entity’s policies and procedures.

Second, to provide clarity with respect to the applicability of Requirement R1, Part 1.1., EEI suggests replacing the undefined term, “system information” with the NERC defined term, “BES Cyber System Information.”

Third, the SDT’s proposal creates compliance challenges.   Registered entities would have difficulty proving the granting and removal of access to BCSI as contemplated in the proposed draft for CIP-004-7.  As an alternative, EEI suggests using the BCSI Repository definition shown above, and revising proposed CIP-004-7 to require registered entities to prove access and removal of access to a BCSI Repository.

Fourth, EEI is concerned that the SAR scope may have expanded without providing necessary justification within the Technical Rationale.  See our comments to Questions 11 below.

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

- 0 - 0

NYISO felt that the changes are necessary.  The existing language in CIP-004-6, requirement R4, part 4.1.3 implies and/or can be interpreted as limiting access to storage location options as opposed to controlling access to BCSI regardless of location. By adding language to require identifying information coupled with an identification of applicable BCSI storage locations would certainly add acceptable options and provide a responsible entity flexibility in choosing technology solutions.

In addition, NYISO feels that the SDT more clearly articulated key distinctions during the Q&A portion of the 2019-02: BES Cyber System Information Access Management Webinar that was hosted on January 16, 2020.  In order to make this clearer, NYISO would suggest that the SDT should endeavor to expand the language of the last example in the current draft provided under requirement R1, Part 1.1, Measures as follows:

“An inventory of locations, either physical or electronic, either housed within a responsible entity’s data center or vendor hosted that are identified as housing the responsible entity’s BES Cyber System Information be a part of the entity’s information protection program”

Gregory Campoli, On Behalf of: New York Independent System Operator, , Segments 2

- 0 - 0

1)      We recommend security objectives instead of prescriptive requirements. Information protection program should include identification, access control, etc.

2)      Since we have some debate over “system information,” we suggest changing “System information pertaining to:” to “Information associated with,” or clarification of “system information”.

3)      We recommend clarifying by stipulating that the Entity’s plan includes a description of the storage location(s) and maintains a list of those storage locations.

RSC no NextEra, Segment(s) 10, 2, 4, 5, 7, 3, 1, 6, 2/3/2020

- 0 - 0

SNPD is concerned that the proposed wording INCREASES rather than DECREASES ambiguity.  The current language is understood to require Entities to designate BCSI storage locations, which is the fundamental security imperative to enable proper access control.  Semantics between terms such as “designate” vs. “identify” or another synonym will not fundamentally alter how Entities choose to interpret and respond to R1. There are already substantial differences between how Entities interpret the current language.  In other words, the current wording is descriptive and defines the imperative.

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

- 1 - 0

Alliant Energy agrees with NSRF and EEI’s comments.

Jenifer Holmes, On Behalf of: Alliant Energy Corporation Services, Inc. - MRO, RF - Segments 4

- 0 - 0

Jamie Monette, Allete - Minnesota Power, Inc., 1, 2/3/2020

- 0 - 0

See Steven Toosevich's comments. 

Dmitriy Bazylyuk, 2/3/2020

- 0 - 0

Comments: MISO agrees the changes are necessary; however, we also have concerns. As the existing language in CIP-004-6, requirement R4, part 4.1.3 implies and/or can be interpreted as limiting access to the storage location as opposed to controlling access to BCSI regardless of location, MISO supports adding language to require identifying information and applicable BCSI storage locations will expand flexibility and options.

That said, MISO proposes the SDT more clearly articulate the following key distinctions raised during the Q&A portion of the 2019-02: BES Cyber System Information Access Management Webinar hosted on January 16, 2020: physical or electronic, responsible entity or vendor hosted. To make this clear in the proposed standard, MISO proposes the SDT expand the language of the last example provided under requirement R1, Part 1.1, Measures as follows:

“Storage locations (physical or electronic, responsible entity or vendor hosted) identified for housing BES Cyber System Information in the entity’s information protection program”

Bobbi Welch, On Behalf of: Midcontinent ISO, Inc., , Segments 2

- 0 - 0

The approach of identifying the storage locations is welcomed since this is where controls are applied and is compatible to current CIP-004 requirements. The drafting team needs to avoid requirements that can be interpreted as requiring protection of each individual piece of BCSI.

 

It would be helpful to clearly define what is meant by “storage locations”. Is it geographical? Is it the server or tenant with a cloud provider? This distinction could be important when BCSI is housed by a vendor or other third-party. Consider adding identification of a) storage locations with the entity, b) with a vendor who provides custom services with identified personnel for in scope cyber systems or assets and c) with a certified cloud service provider who provides generic cloud based services without insider knowledge. 

 

The Applicability column needs to be modified to limit the information to only BCSI, and not all system information pertaining to the system categories listed. Just using “system information” will cast too wide of a net on identifying BCSI. Consider revising as, “BES Cyber System Information for:” This is easily understood since it is a defined term with defined criteria.

James Brown, On Behalf of: California ISO, WECC, Segments 2

- 0 - 0

PGE agrees with EEI’s comments

PGE Group 2, Segment(s) 1, 3, 6, 5, 2/3/2020

- 1 - 0

No, The term “designated storage locations” offered additional clarity that it was only those storage locations designated as such by the responsible entity that would meet this requirement. However, the updated term “applicable BES Cyber System Information storage locations” offers no clarity of which storage locations would be applicable. This could have the unintended consequence of increasing the scope of locations to be managed under CIP. The term is too broad, and should be left as “designated storage locations” or amended to “designated storage locations of BCSI.”

Jennie Wike, On Behalf of: Marc Donaldson, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Marc Donaldson, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Marc Donaldson, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; John Merrell, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; John Merrell, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; John Merrell, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Hien Ho, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Hien Ho, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Hien Ho, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Terry Gifford, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Terry Gifford, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Terry Gifford, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Ozan Ferrin, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Ozan Ferrin, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Ozan Ferrin, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6

- 0 - 0

Please see comments PGE Group 2

Angela Gaines, Portland General Electric Co., 1, 2/3/2020

- 0 - 0

The requirement is not necessary.  Why should we have to identify our locations to NERC? There should be security objectives instead of prescriptive requirements.

Dennis Sismaet, Northern California Power Agency, 6, 2/3/2020

- 0 - 0

Yes, we agree that the language in R1 Part 1.1, as written, allows the Responsible Entity the flexibility in identifying BCSI storage locations.

However, we share the concerns expressed by EEI and the MRO NSRF.

While the requirement is necessary, we do propose splitting R1 Part 1.1 into two parts as follows:

In Part 1.1: change the Requirement to delete the phrase, “and identify applicable BES Cyber System Information storage locations.” Also, in the Measures, delete last bullet.

Recommend creating a new Part 1.2: with the ‘Applicability’ as Part 1.1, but add, “with ERC” to Medium Impact BES Cyber Systems, and in the Requirement section,  “Method(s) to identify applicable BES Cyber System Information storage locations.” This could in turn be changed to “Method(s) to identify applicable BES Cyber System Information Repositories” per the EEI and MRO NSRF recommendations.

Applicability of current R1 Parts 1.3 to 1.6, and R2 Parts 2.1 and 2.2, change to reference a newly created R1 Part 1.2.

Terry Harbour, Berkshire Hathaway Energy - MidAmerican Energy Co., 1, 2/3/2020

- 0 - 0

The approach of identifying the storage locations is welcomed because this is where controls are applied, and the approach is compatible to current CIP-004 requirements.  ERCOT suggests the drafting team avoid requirements that can be interpreted as requiring protection of each individual piece of BCSI.

 

ERCOT believes it would be helpful to clearly define what is meant by “storage locations.”  Is it geographical?  Is it the server or tenant with a cloud provider?  This distinction could be important when BCSI is housed by a vendor or other third-party.  ERCOT suggests the drafting team consider adding identification of (a) storage locations with the entity, (b) vendors that provide custom services with identified personnel for in scope cyber systems or assets, and (c) certified cloud service providers that provide generic cloud based services without insider knowledge.  

 

The Applicability column should be modified to limit the information to only BCSI, and not all system information pertaining to the system categories listed.  Just using “system information” may cast too wide of a net on identifying BCSI.  ERCOT suggests the drafting team consider revising to read “BES Cyber System Information for:”  This would likely be more easily understood because it is a defined term with defined criteria.

Brandon Gleason, Electric Reliability Council of Texas, Inc., 2, 2/3/2020

- 0 - 0

Westar and Kansas City Power & Light Company, endorse Edison Electric Institute's (EEI) comments.

Westar-KCPL, Segment(s) 1, 3, 5, 6, 12/18/2018

- 0 - 0

PG&E does not agree with required identification of BCSI storage locations.  The stated purpose and emphasis of the modifications is the protection of “System Information” (i.e. BCSI) and PGAE does not believe that this burdensome requirement enhances protection of BCSI.  The requirement to identify storage locations has been administratively burdensome and challenging for BCSI placed on internal servers but could be impossible for BCSI placed on third-party provider infrastructure (i.e. cloud), especially if the service providers have the capability to store the BCSI on multiple instances of their infrastructure for redundancy and resilience.

PG&E recommends the required identification of storage locations be removed while maintaining the emphasis on the protection of the BCSI.

PG&E All Segments, Segment(s) 1, 3, 5, 1/29/2020

- 0 - 0

The change from "designated storage locations" to "applicable ... storage locations" increases the confusion that already surrounds this topic. 

Allan Long, Memphis Light, Gas and Water Division, 1, 2/3/2020

- 0 - 0

Yes, we agree that the language in R1 Part 1.1, as written, allows the Responsible Entity the flexibility in identifying BCSI storage locations.

 

However, we share the concerns expressed by EEI and the MRO NSRF.

 

While the requirement is necessary, we do propose splitting R1 Part 1.1 into two parts as follows:

 

In Part 1.1: change the Requirement to delete the phrase, “and identify applicable BES Cyber System Information storage locations.” Also, in the Measures, delete last bullet.

 

Recommend creating a new Part 1.2: with the ‘Applicability’ as Part 1.1, but add, “with ERC” to Medium Impact BES Cyber Systems, and in the Requirement section,  “Method(s) to identify applicable BES Cyber System Information storage locations.” This could in turn be changed to “Method(s) to identify applicable BES Cyber System Information Repositories” per the EEI and MRO NSRF recommendations.

 

Applicability of current R1 Parts 1.3 to 1.6, and R2 Parts 2.1 and 2.2, change to reference a newly created R1 Part 1.2

Darnez Gresham, Berkshire Hathaway Energy - MidAmerican Energy Co., 3, 2/3/2020

- 0 - 0

Laura Nelson, IDACORP - Idaho Power Company, 1, 2/3/2020

- 0 - 0

Colleen Campbell, On Behalf of: AES - Indianapolis Power and Light Co., , Segments 3

- 0 - 0

We recommend clarifying the requirement by stipulating that the Entity’s plan includes a description of the storage locations for BCSI and maintains a list of those storage locations.  In addition, there should be language describing what is meant by “storage locations.”  The definition is important when BCSI is housed by a vendor or other third-party.  Finally, the requirement should cover only BCSI and not all system information pertaining to the system categories listed in the Applicability column.  Accordingly, “system information” in the Applicability column should be changed to the defined term “BES Cyber System Information.”

Michael Puscas, On Behalf of: ISO New England, Inc., , Segments 2

- 0 - 0

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

- 1 - 0

The requirement is not necessary.  Why should we have to identify our locations to NERC? There should be security objectives instead of prescriptive requirements.

Marty Hostler, Northern California Power Agency, 5, 2/3/2020

- 0 - 0

Hot Answers

OPG is in agreement with RSC provided comment

Constantin Chitescu, Ontario Power Generation Inc., 5, 2/3/2020

- 0 - 0

It appears the scope has greatly expanded. Because of the focus of all possible BCSI storage locations, entities will not only be focused on who should have access and how access is controlled, but where that information may be stored temporally and where it might be duplicated.

Additionally, how are Cloud storage services handled in the new CIP-011-3? The physical security perimeter of that service exists outside of the control of the registered entity.

If, during a CIP Exceptional Circumstance, information is transmitted to another person to help facilitate an issue, at the end of the CIP Exceptional Circumstance, data cleanup becomes a problem.

Are entities to identify the RE file server location if an entity is required to send a Regional Entity BCSI?

The focus should be access controls, as the long-term storage is already considered in that process.

Bradley Collard, 2/3/2020

- 0 - 0

Other Answers

The requirment in CIP-011-3 R1.2 appears circular.  Are we trying to elimiate the abiltiy to use the BCSI while we are using it?

System Information by eliminating the ability to obtain and use BES Cyber System Information during, including storage, transit, use, and disposal .

Kevin Conway, Public Utility District No. 1 of Pend Oreille County, 1, 12/23/2019

- 0 - 0

Calvin Wheatley, On Behalf of: Wabash Valley Power Association, SERC, RF, Segments 1, 3

- 0 - 0

While this change is minimal, it is relocated from the standard that contains all other authorization and provisioning requirements.  This component of the requirement is about authorization, and is appropriate to be tracked and enforced in the same set of requirements, rather than potentially creating two separate violations when one violation would have occurred previously.

Susan Sosbe, Wabash Valley Power Association, 3, 1/22/2020

- 0 - 0

William Hutchison, On Behalf of: Southern Illinois Power Cooperative, , Segments 1

- 0 - 0

Duke Energy generally agrees with moving the requirement to CIP-011. However, notes the change in applicabiltiy will be more than miminal effort to meet the new objectives.

Duke Energy, Segment(s) 1, 5, 6, 3, 12/13/2019

- 0 - 0

DTE Energy - DTE Electric, Segment(s) 5, 4, 3, 2/27/2017

- 0 - 0

Due to having a strong disagreement with R1.2, 1.4 and R2, we disagree with this clarity statement. 

Scott Miller, On Behalf of: Roger Brand, MEAG Power, 1,3; Roger Brand, MEAG Power, 1,3; Roger Brand, MEAG Power, 1,3; David Weekley, MEAG Power, 1,3; David Weekley, MEAG Power, 1,3; David Weekley, MEAG Power, 1,3

- 0 - 0

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

- 0 - 0

Public Utility District No. 1 of Chelan County, Segment(s) 3, 1, 1/27/2020

- 0 - 0

Karl Blaszkowski, CMS Energy - Consumers Energy Company, 3, 1/28/2020

- 0 - 0

Donald Lynd, CMS Energy - Consumers Energy Company, 1, 1/28/2020

- 0 - 0

The new standard expands the scope of BES CSI repositories to anywhere BES CSI may be, including in use and transit.  This language is similar to the v3 language that was changed based on lessons learned.  This may put entities across North America out of compliance because the current standard focuses on storage locations,  not information in use or transit.  Tracking BES CSI in use and transit will not be technically feasible and will but a great burden on business processes.

Joe Tarantino, On Behalf of: Kevin Smith, Balancing Authority of Northern California, 1; Kevin Smith, Balancing Authority of Northern California, 1; Kevin Smith, Balancing Authority of Northern California, 1; Jamie Cutlip, Sacramento Municipal Utility District, 1,3,4,5,6; Jamie Cutlip, Sacramento Municipal Utility District, 1,3,4,5,6; Jamie Cutlip, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Beth Tincher, Sacramento Municipal Utility District, 1,3,4,5,6; Beth Tincher, Sacramento Municipal Utility District, 1,3,4,5,6; Beth Tincher, Sacramento Municipal Utility District, 1,3,4,5,6; Arthur Starkovich, Sacramento Municipal Utility District, 1,3,4,5,6; Arthur Starkovich, Sacramento Municipal Utility District, 1,3,4,5,6; Arthur Starkovich, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6

- 0 - 0

Disagree that the qualifying language “with ERC” was dropped from the applicability of Medium Impact BES Cyber Systems from CIP-004-6 R4.1 when moved to CIP-011-3 R1.3. This deletion greatly expands the scope of this requirement. This expansion of scope is not justified, as the deliberate choice of not implementing ERC to Medium Impact BES Cyber Systems is currently recognized as a considerable and sufficient protection in and of itself.

Lack of ERC also renders BCSI pertaining to Medium Impact BES Cyber Systems outside the scope of R1 Part 1.2, as any such information, if obtained, cannot be used remotely, as there is no remote access to the Cyber Systems. These Cyber Systems can only be compromised by breaching physical security, in which case this standard provides no protection.

There also is significant scope expansion with the authorization/revocation and review requirements now applying to all BCSI (not just designated storage locations of BCSI).

We disagree with moving requirements for access to BCSI from CIP-004-6 to CIP-011-3. We appreciate the attempt to streamline Requirements associated with BCSI by placing all related compliance activities solely within the CIP-011-3 Standard. However, by doing so Responsible Entities would be subject to the potential of having multiple compliance issues with one failed compliance activity as a result of the overlapping NERC CIP Standards.

For example, it is conceivable that one process could remove the ability to access BCSI as well as other logical access.  In this approach if there was a failure in this process  it could result in a violation of both CIP-004-7 R5 and for CIP-011-3 R1, where under current Standards this situation would result in a single potential non-compliance with CIP-004-6 R5.

Due to these reasons we suggest that access control Requirements remain in CIP-004-6 with other access control Requirements.

MRO NSRF, Segment(s) 3, 4, 5, 6, 1, 2, 1/29/2020

- 0 - 0

FE Voter, Segment(s) 1, 3, 5, 6, 4, 10/31/2019

- 0 - 0

Xcel Energy support the comments submitted by EEI.

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

- 0 - 0

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

- 0 - 0

Support the MRO NSRF comments

Jeremy Voll, Basin Electric Power Cooperative, 3, 1/30/2020

- 0 - 0

Anthony Jablonski, ReliabilityFirst , 10, 1/30/2020

- 0 - 0

We disagree with moving requirements for access to BCSI from CIP-004-6 to CIP-011-3 since it

causes unnessessay revisions of the exsiting CIP-004 and CIP-011 progroms without gaining any

security values. CIP-004 were originally developed for centralizing the access management within

one standard and we don’t think SDT wants backwards, otherwise, does electronic access and

physical access need to be moved back to CIP-004 to CIP-007 and CIP-006 as well?                                                                                                                                                                                          

Bruce Reimer, Manitoba Hydro , 1, 1/30/2020

- 0 - 0

Seattle finds the proposed requirements are not backward compatible in that they significantly expand scope, from controls for access to BCSI about High and Medium-with-ERC BCS, to access to all High and Medium BCS. Although this change does address the conflict between the different BCSI applicabilities of CIP-004 and CIP-011, it does not seem necessary to address the objective of the SAR, which is to revise the Standards to clearly accommodate BCSI storage and use solutions that are not based on local, physically-focused concepts. Like the change proposed in Q1 above, it is a clarifying change but appears to do little or nothing to address the central object of these revisions.

If specific access controls are deemed desirable, Seattle recommends that the access termination requirement be changed from the unique-to-BCSI “one calendar day” to the “24 hours” that is used for all other access termination requirements.

Seattle also supports the comments of SMUD to this question.

Matthew Nutsch, On Behalf of: Seattle City Light, WECC, Segments 1, 3, 4, 5, 6

- 0 - 0

Tri-State is generally ok with the movement of the requirements from CIP-004 to CIP-011. However, we do not agree with several of the changes.

1) Tri-State does not agree with the addition of PCAs to the scope. Furthermore, this was not in scope of the SAR to address.

2) As for R1.2, we think the original language was correct and the concept of “obtain and use” should instead be incorporated into the access requirements, especially R1.3. This will make it clear that in order for someone to be deemed to have access to BCSI, they must have the ability to obtain and use it, which would align with the ERO Practice Guide. Although, we don’t recommend using the term “use” without providing more clarification as to its meaning.

3) Also as it relates to R1.2, we do not agree with the addition of “disposal”. While this is certainly a good security practice, adding this as a compliance requirement would be overly burdensome and unnecessary. Furthermore, this was not in scope of the SAR to address. 

4) We think the modifications made to R3 are more prescriptive than the prior version in how to prevent unauthorized retrieval of BCSI and unnecessarily limits the entity’s options in how to meet the security objective. This should be reverted back to previous objective-based language. Furthermore, this was not in scope of the SAR to address.

Kjersti Drott, Tri-State G and T Association, Inc., 1, 1/31/2020

- 0 - 0

Payam Farahbakhsh, Hydro One Networks, Inc., 1, 1/31/2020

- 0 - 0

The removal of the term “designated” greatly expands the scope to cover handling BCSI, including creating replicated copies of applicable BCSI, and ensuring applicable processes and controls are applied to new identified locations / instances of BSCI.

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

- 0 - 0

Black Hills would be in favor of seeing less perscriptive models of access and termination requirements. Additionally, the failure to remove BCSI per CIP-011 could potentially create a scenario where CIP-004’s requirements were also unmet, creating a double violation.

Maryanne Darling-Reich, On Behalf of: Black Hills Corporation - MRO, WECC - Segments 1, 3, 5, 6

- 0 - 0

While AEP is appreciative of the SDT’s efforts to consolidate BCSI requirements into CIP-011, we do not feel there is minimal effort involved in ensuring compliance. Moving these requirements to a different standard creates more challenges that those who are responsible for        complying are required to overcome, leading to more overall work and effort for those involved.

Kent Feliks, AEP, 3, 1/31/2020

- 0 - 0

Russel Mountjoy, Midwest Reliability Organization, 10, 1/31/2020

- 0 - 0

AECI supports comments filed by NRECA

AECI, Segment(s) 1, 3, 6, 5, 5/31/2019

- 0 - 0

NRECA appreciates the SDT’s consideration of the important concept of backwards compatibility; however, giving due consideration to the proposed scope expansion to include PCAs; the shift from access authorization to BCSI generally and not storage locations; the shift from methods to processes; and the incorporation of vendor risk assessments and required mitigations into the proposed requirements, NRECA does not agree that the proposed requirements are actually backwards compatible nor that minimal effort will be required to meet these new requirements.

Barry Lawson, National Rural Electric Cooperative Association, 4, 2/3/2020

- 0 - 0

No, not as proposed. 

There is a difference between authorizing access and provisioning access.  Per CIP-004-6 Rationale for Requirement R4:

"Authorization" should be considered to be a grant of permission by a person or persons empowered by the Responsible Entity to perform such grants and included in the delegations referenced in CIP-003-6. 

"Provisioning" should be considered the actions to provide access to an individual.

The scope of CIP-004 could be maintained while also changing the focus to the BCSI itself to meet the goals of the SAR by slightly modifying CIP-004 applicable requirement parts to “access to BES Cyber System Information in designated storage locations”, such as in part 4.1.3:

R4.1     Process to authorize based on need, as determined by the Responsible Entity, except for CIP Exceptional Circumstances:

            4.1.3 Access to BES Cyber System Information in designated storage locations.

CIP-004 R4.4 and R5.3 refer to provisioned access, and could be modified to include this language as well.  For example:

R4.4     Verify at least once every 15 calendar months that provisioned access to BES Cyber System Information in designated storage locations is authorized and implemented correctly.

R5.3     For termination actions, revoke the individual’s provisioned access to BES Cyber System Information in designated storage locations by the end of the next calendar day following the effective date of the termination action.

Andy Fuhrman, On Behalf of: Theresa Allard, Minnkota Power Cooperative Inc., 1; Theresa Allard, Minnkota Power Cooperative Inc., 1; Theresa Allard, Minnkota Power Cooperative Inc., 1

- 0 - 0

GSOC appreciates the SDT’s consideration of the important concept of backwards compatibility; however, giving due consideration to the proposed scope expansion to include PCAs; the shift from access authorization to BCSI generally and not storage locations; the shift from methods to processes; and the incorporation of vendor risk assessments and required mitigations into the proposed requirements, GSOC cannot agree that the proposed requirements are actually backwards compatible nor that minimal effort will be required to meet these new requirements.

Andrea Barclay, Georgia System Operations Corporation, 4, 2/3/2020

- 0 - 0

SMEC agrees with comments submitted by NRECA.

SMEC also disagrees with the removal of the qualifying language “with ERC” from the applicability of Medium Impact BES Cyber Systems in CIP-011-3 R1.1 as currently provided in CIP-004-6 R4.1, and how this greatly and needlessly expands the scope of all subsequent parts of R1, and R2

Lana Smith, San Miguel Electric Cooperative, Inc., 5, 2/3/2020

- 0 - 0

ACES Standard Collaborations, Segment(s) 1, 3, 2/3/2020

- 0 - 0

Dwayne Parker, 2/3/2020

- 0 - 0

We agree this update is backward compatible and this update provides greater flexibility.

Leonard Kula, Independent Electricity System Operator, 2, 2/3/2020

- 0 - 0

The change made to CIP-011-3 Part 1.2 does not add clarity.  The choice of the second “use” in Part 1.2 is confusing and does not make sense; “…by eliminating the ability to obtain and use BES Cyber System Information during, storage, transit, use, and disposal.”  The SDT needs to elaborate on “…eliminating the ability…”  What constitutes elimination of ability? 

Santee Cooper, Segment(s) 1, 3, 5, 6, 2/3/2020

- 0 - 0

CIP-004 is the appropriate place to require applicable levels of approval prior to granting access to BCSI.  Removing the language from CIP-004 and adding it to CIP-011 creates two separate standards that cover access controls in place to protect the Bulk Electic System Information.  CIP-011 defines what consititues BCSI and the requirements to protect it.  It should not be an standard for approval, auditing  and access monitoring.

Secondly, entities will be required to make major changes to their internal governance and compliance program procedures, policies and documentation in order to meet this requirement. Please do not mix standards/requirements

sean erickson, Western Area Power Administration, 1, 2/3/2020

- 0 - 0

Gerry Adamski, Cogentrix Energy Power Management, LLC, 5, 2/3/2020

- 0 - 0

Although AZPS agrees that meeting this objective likely requires minimal effort, AZPS recommends the SDT address the concept of designated storage locations throughout the Standard.  Part 1.1 requires the identification of BCSI storage locations; however, subsequent Requirements omit references to storage locations and instead refer only to the protection of BCSI.  The switch from storage locations to BCSI causes confusion and may create challenges in executing the required access management and protection controls. 

Vivian Moser, 2/3/2020

- 0 - 0

New and emerging technologies shift the paradigm of security controls away from a specific storage location/repository to the ability to access and use the information itself. For example, an entity that utilizes file level security can apply encrypted protections on the data that preclude unauthorized access to the data regardless of where it is stored.  Requiring a list of storage locations is an antiquated construct that disincentivizes entities from using potentially more secure mechanisms because of the impossibility of compliance with documenting storage locations. The requirement should be technology agnostic and objective based, so it is written to focus on the implementation of effective methods that afford adequate security protections to prevent unauthorized access to the information

LaTroy Brumfield, American Transmission Company, LLC, 1, 2/3/2020

- 0 - 0

Truong Le, On Behalf of: Chris Gowder, Florida Municipal Power Agency, 3,4,5,6; Chris Gowder, Florida Municipal Power Agency, 3,4,5,6; Chris Gowder, Florida Municipal Power Agency, 3,4,5,6; Carol Chinn, Florida Municipal Power Agency, 3,4,5,6; Carol Chinn, Florida Municipal Power Agency, 3,4,5,6; Carol Chinn, Florida Municipal Power Agency, 3,4,5,6; Dale Ray, Florida Municipal Power Agency, 3,4,5,6; Dale Ray, Florida Municipal Power Agency, 3,4,5,6; Dale Ray, Florida Municipal Power Agency, 3,4,5,6; Richard Montgomery, Florida Municipal Power Agency, 3,4,5,6; Richard Montgomery, Florida Municipal Power Agency, 3,4,5,6; Richard Montgomery, Florida Municipal Power Agency, 3,4,5,6; David Owens, Gainesville Regional Utilities, 1,3,5; David Owens, Gainesville Regional Utilities, 1,3,5; David Owens, Gainesville Regional Utilities, 1,3,5

- 0 - 0

Tri-State is generally ok with the movement of the requirements from CIP-004 to CIP-011. However, we do not agree with several of the changes.

1) We do not agree with the addition of PCAs to the scope. Furthermore, this was not in scope of the SAR to address.

2) As for R1.2, we think the original language was correct and the concept of “obtain and use” should instead be incorporated into the access requirements, especially R1.3. This will make it clear that in order for someone to be deemed to have access to BCSI, they must have the ability to obtain and use it, which would align with the ERO Practice Guide. Although, we don’t recommend using the term “use” without providing more clarification as to its meaning.

3) Also as it relates to R1.2, we do not agree with the addition of “disposal”. While this is certainly a good security practice, adding this as a compliance requirement would be overly burdensome and unnecessary. Furthermore, this was not in scope of the SAR to address. 

4) We think the modifications made to R3 are more prescriptive than the prior version in how to prevent unauthorized retrieval of BCSI and unnecessarily limits the entity’s options in how to meet the security objective. This should be reverted back to previous objective-based language. Furthermore, this was not in scope of the SAR to address.

Janelle Marriott Gill, Tri-State G and T Association, Inc., 3, 2/3/2020

- 0 - 0

See NRECA submitted comments. 

Jonathan Robbins, Seminole Electric Cooperative, Inc., 4, 2/3/2020

- 0 - 0

Anton Vu, Los Angeles Department of Water and Power, 6, 2/3/2020

- 0 - 0

N&ST sees no benefit in moving BCSI storage location access management requirements from CIP-004 to CIP-011, and believes there is no need for clarification between BCSI and BCS requirements. Furthermore, N&ST believes that the impact of moving some access management requirements from CIP-004 to CIP-011 could be significant for some Responsible Entities, compelling needless modification and disruption of mature and effective CIP compliance programs.

Nicholas Lauriat, Network and Security Technologies, 1, 2/3/2020

- 0 - 0

We disagree with the qualifying language “with ERC” dropping from the applicability of Medium Impact BES Cyber Systems from CIP-004-6 R4.1 when moved to CIP-011-3 R1.3. This deletion greatly expands the scope of this requirement, and may have created a situation where Responsible Entities could be subject to multiple compliance violations based on a single action due to overlapping obligatations in the CIP Standards.

 

Having a lack of ERC also renders BCSI pertaining to Medium Impact BES Cyber Systems outside the scope of R1 Part 1.2, as such information, if obtained, cannot be used remotely, as there is no remote access to the Cyber Systems. Information pertaining to these Cyber Systems can only be used to compromise them by breaching physical security, in which case the CIP-011 standard provides no protection.

 

There also is significant scope expansion with the authorization/revocation and review requirements now applying to all BCSI (not just designated storage locations of BCSI). This expansion of scope is not justified, as the deliberate choice of not implementing ERC to Medium Impact BES Cyber Systems is currently recognized as a sufficient protection.

Sandra Shaffer, Berkshire Hathaway - PacifiCorp, 6, 2/3/2020

- 0 - 0

ALAN ADAMSON, New York State Reliability Council, 10, 2/3/2020

- 0 - 0

BPA believes this is not a minimal effort.  There is a difference between access to a location and consuming information stored in that location. The need to know standard is not contained in the verbiage of the requirement, but is in the guidance. Need to know implies consuming the information while need to access is simply controlling access. The need to know standard for actually consuming and using information is an unsustainable burden at remote, especially rarely occupied, locations and could interfere with the ability to perform operations in an emergent situation. All personnel with access to storage locations have authorization; those who do not actually consume and use that information nonetheless have a business need to access the location. This covers the risk while keeping the burden minimal. A more sustainable objective would be to ensure that all personnel with access are authorized rather than a strict need to know standard. Strict need to know implies compartmentalization that is not sustainable for large organizations with the need to deploy technicians across multiple districts. The language proposed so far would be sustainable if all information were stored electronically and cryptographically protected but this proposes a problem for hard copies stored in substations.

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

- 0 - 0

Rachel Coyne, Texas Reliability Entity, Inc., 10, 2/3/2020

- 0 - 0

Dominion Energy supports the work the SDT has done on develoing the current draft. Dominion energy suggests that the team focus on the approach taken in the current NERC CMEP Guidance document in addressing the issue and further supports EEIs comments.

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

- 0 - 0

Exelon supports EEI's comments on behalf of Exelon Segments 1, 3, 5, and 6.

Kinte Whitehead, Exelon, 3, 2/3/2020

- 0 - 0

Ameren agrees with and supports EEI comments.

David Jendras, Ameren - Ameren Services, 3, 2/3/2020

- 0 - 0

NCEMC supports the comments by Barry Lawson, National Rural Electric Cooperative Association and ACES

Kagen DelRio, On Behalf of: North Carolina Electric Membership Corporation - SERC - Segments 3, 4, 5

- 0 - 0

We do not agree as one of the fundamental concepts of CIP-004 R4 Part 4.1.3 that was lost in the proposed transition to CIP-011 R1 Part 1.3 is the difference between authorizing access to BCSI storage locations, which is a discrete and finite object that can be monitored and audited (the current CIP-004 approach), while the new CIP-011 approach is access to BCSI wherever and however it exists inside or outside of its storage locations (i.e. a hardcopy of a network diagram in a company truck).  This fundamental change has made the requirement unmeasurable and non-auditable.  We believe the primary issue of hardware or device level requirements that prevented the use of cloud services was in CIP-011 R2 that required data destruction at a Cyber Asset/physical storage media level.  We do not agree with moving the authorization programs away from BCSI storage locations.  A “storage location” can be a designated encrypted area on a cloud service.

 

Additionally, we do not agree with moving the “access management” requirements for BCSI out of CIP-004-6 and into CIP-011-3.  Although one argument is to keep all requirements applicable to BCSI in a single standard, the same argument could be applied to keep all “access management” requirements in the same standard.  This is additionally supported by the fact that this is how all entities have currently structured their compliance programs, and the justification to reallocate those requirements to CIP-011-3 causes more undue burden than any resultant benefit.

Southern Company, Segment(s) 1, 3, 5, 6, 12/13/2019

- 0 - 0

Tho Tran, On Behalf of: Lee Maurer, Oncor Electric Delivery, 1; Lee Maurer, Oncor Electric Delivery, 1; Lee Maurer, Oncor Electric Delivery, 1

- 0 - 0

SDG&E supports EEI’s comments submitted on our behalf.

SDG&E would like to additionally speak to the new draft standard R1.3 requirement of “Process(es) to authorize access to BES Cyber System Information…”  The existing requirements require authorization for the repositories that BCSI is stored in.  A change to authorizing access to BCSI generally will be a large deviation from current practices and creates many questions about how to authorize/track access to each piece of BCSI.

Bridget Silvia, Sempra - San Diego Gas and Electric, 3, 2/3/2020

- 0 - 0

ITC supports the response found in the NSRF Comment Form

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

- 0 - 0

We do apprecitate the SDT concern with backwards compatibity, but since we are recommending changes to the current drafts of CIP-004-7 and CIP-011-3, we are not able to agree at this time.

Eversource Group, Segment(s) 3, 1, 4/12/2019

- 0 - 0

We support the EEI comments that disagree with the qualifying language “with ERC” dropping from the applicability of Medium Impact BES Cyber Systems from CIP-004-6 R4.1 when moved to CIP-011-3 R1.3. This deletion greatly expands the scope of this requirement, and may have created a situation where Responsible Entities could be subject to multiple compliance violations based on a single action due to overlapping obligatations in the CIP Standards.

 

Having a lack of ERC also renders BCSI pertaining to Medium Impact BES Cyber Systems outside the scope of R1 Part 1.2, as such information, if obtained, cannot be used remotely, as there is no remote access to the Cyber Systems. Information pertaining to these Cyber Systems can only be used to compromise them by breaching physical security, in which case the CIP-011 standard provides no protection.

 

There also is significant scope expansion with the authorization/revocation and review requirements now applying to all BCSI (not just designated storage locations of BCSI). This expansion of scope is not justified, as the deliberate choice of not implementing ERC to Medium Impact BES Cyber Systems is currently recognized as a sufficient protection.

Kevin Salsbury, Berkshire Hathaway - NV Energy, 5, 2/3/2020

- 0 - 0

Please see comments submitted by Edison Electric Institute

Ayman Samaan, 2/3/2020

- 0 - 0

NYPA believes that some backward compatibility has been lost since the modified Standard has been modified to extend to ALL Medium Impact BES Cyber Systems

David Rivera, New York Power Authority, 3, 2/3/2020

- 0 - 0

While we understand the reasoning behind including access to BES Cyber System Information storage locations in CIP-011, the 2016-02 SDT made great efforts to consolidate like requirements together and remove the “spaghetti” requirements.  We believe that these changes are undoing that effort.  The ability for an entity to have a single access management program (dealing with physical, electronic and information access) provides economy of scale and less opportunities for mistakes or confusion.  While we do believe these changes maintain backwards compatibility, we cannot support splitting access management into multiple Standards. 

PPL NERC Registered Affiliates, Segment(s) 1, 3, 5, 6, 9/6/2018

- 0 - 0

Support MRO comments.

Wayne Guttormson, SaskPower, 1, 2/3/2020

- 0 - 0

The standards development team should support specific requirements providing appropriate levels of security for Cloud Service Providers and 3rd Party Access. Transferring the CIP-004 BCSI requirements to CIP-011 does not address the unique issues created by storing BCSI in repositories that are not controlled by registered entities. The standards development team should draft separate requirements.

Steve Toosevich, NiSource - Northern Indiana Public Service Co., 1, 2/3/2020

- 0 - 0

See Steven Toosevich's comments.  

Kathryn Tackett, NiSource - Northern Indiana Public Service Co., 5, 2/3/2020

- 0 - 0

CEHE does not agree that there is a minimal effort to meet the proposed obligations due to the addition of PCAs.  Adding the phrase, “System information pertaining to:” in the Aplicability column does provide greater clarity between BCSI and BES Cyber Systems.

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

- 0 - 0

EEI appreciates the considerable efforts of the SDT to streamline Requirements associated with BCSI within the proposed changes to CIP-004-7 and CIP-011-3.  However, EEI is concerned that the proposed changes may create a situation where responsible entities could be subject to multiple compliance violations based on a single action due to overlapping obligations in the CIP Standards.  For example, if an entity developed a process to remove access to BCSI, including other logical access, and there was a failure in that process, the proposed requirement could be interpreted as a violation of CIP-004-7 R5 and CIP-011-3 R1.  Whereas, under the current approved standards this situation would result in a single violation of CIP-004-6 R5.

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

- 0 - 0

NYISO’s response is based on the assumption this question relates to the proposed changes in CIP-011-3 within requirement R1, parts 1.3, 1.5 and 1.6.

NYISO believes that the proposed changes maintain backwards capability. That said, the proposed changes in CIP-011-3 also introduce a potential complication; having to maintain similar access authorization, revocation and control measures as that currently contained within CIP-004-7. This could create a situation whereby a single deficiency in an entity’s access management program could lead to potential non-compliance with two separate NERC standards. 

Note – during the Q&A portion of the 2019-02: BES Cyber System Information Access Management Webinar hosted on January 16, 2020, the SDT explained that their intent in proposing these modifications was to direct the content of CIP-004-7 solely on BCS while focusing the content of CIP-011-3 solely on BCSI.

 NYISO recognizes and agrees with the SDT’s intent to consolidate similar issues. Our recommendation would be for the SDT to maintain all personnel and access management requirements within CIP-004-7 to better align with existing industry practices. In addition, NYISO would also propose that the SDT consider similar treatment of vendor related risk assessment requirements be incorporated and consolidated within CIP-013-2.

Gregory Campoli, On Behalf of: New York Independent System Operator, , Segments 2

- 0 - 0

1.      We agree this update is backward compatible and this update provides greater flexibility.

RSC no NextEra, Segment(s) 10, 2, 4, 5, 7, 3, 1, 6, 2/3/2020

- 0 - 0

SNPD is concerned that the proposed wording INCREASES rather than DECREASES ambiguity.  The current language is understood to require Entities to designate BCSI storage locations, which is the fundamental security imperative to enable proper access control.  Semantics between terms such as “designate” vs. “indentify” or another synonym will not fundamentally alter how Entities choose to interpret and respond to R1. There are already substantial differences between how Entities interpret the current language.  In other words, the current wording is descriptive and defines the imperative. 

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

- 1 - 0

Alliant Energy agrees with NSRF and EEI’s comments.

Jenifer Holmes, On Behalf of: Alliant Energy Corporation Services, Inc. - MRO, RF - Segments 4

- 0 - 0

All BCSI access requirements should remain under CIP-004 as one Standardized Security Standard (centralized location).  Leaving the BCSI access with cyber and physical provides a holistic security  access management and review program verses fragmenting access management. 

Jamie Monette, Allete - Minnesota Power, Inc., 1, 2/3/2020

- 0 - 0

See Steven Toosevich's comments. 

Dmitriy Bazylyuk, 2/3/2020

- 0 - 0

MISO’s response assumes this question relates to the proposed changes in CIP-011-3, requirement R1, parts 1.3, 1.5 and 1.6.

MISO believes the proposed changes maintain backwards capability; however, the proposed changes in CIP-011-3 also introduce a new complication, that of having to maintain similar access authorization, revocation and control measures as that in CIP-004-7. This could create a situation whereby a single deficiency in an entity’s access management program could lead to potential non-compliance with two NERC standards at the same time. 

Note – during the Q&A portion of the 2019-02: BES Cyber System Information Access Management Webinar hosted on January 16, 2020, the SDT explained their intent in proposing these modifications is to focus the content of CIP-004-7 solely on BCS and the content of CIP-011-3 solely on BCSI.

MISO recognizes and agrees with the SDT’s intent to consolidate similar issues. We recommend that the SDT maintain all personnel and access management requirements within CIP-004-7 to better align with existing industry practices. Likewise, MISO would propose the SDT consider similar treatment of vendor related requirements by incorporating them into CIP-013-2.

Bobbi Welch, On Behalf of: Midcontinent ISO, Inc., , Segments 2

- 0 - 0

We agree that the concepts of the current version of CIP-004 are maintained. However, a better approach would be to correct this with new parts in CIP-004. Also see comments on question 10.

James Brown, On Behalf of: California ISO, WECC, Segments 2

- 0 - 0

PGE agrees with EEI’s comments

PGE Group 2, Segment(s) 1, 3, 6, 5, 2/3/2020

- 0 - 0

No, The term “designated storage locations” offered additional clarity that it was only those storage locations designated as such by the responsible entity that would meet this requirement. However, the updated term “applicable BES Cyber System Information storage locations” offers no clarity of which storage locations would be applicable. This could have the unintended consequence of increasing the scope of locations to be managed under CIP. The term is too broad, and should be left as “designated storage locations” or amended to “designated storage locations of BCSI.”

Additionally, the CIP-004-6 access level requirements were scoped to High Impact BCS, and Medium Impact BCS with ERC. The CIP-011 replacement broadly expands the scope of the access level requirements.

Jennie Wike, On Behalf of: Marc Donaldson, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Marc Donaldson, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Marc Donaldson, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; John Merrell, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; John Merrell, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; John Merrell, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Hien Ho, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Hien Ho, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Hien Ho, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Terry Gifford, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Terry Gifford, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Terry Gifford, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Ozan Ferrin, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Ozan Ferrin, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Ozan Ferrin, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6

- 0 - 0

Please see comments PGE Group 2

Angela Gaines, Portland General Electric Co., 1, 2/3/2020

- 0 - 0

I don't see backwards compatibility based on the methods listed in 1.2.

Dennis Sismaet, Northern California Power Agency, 6, 2/3/2020

- 0 - 0

We support the EEI and MRO NSRF comments that disagree with the qualifying language “with ERC” dropping from the applicability of Medium Impact BES Cyber Systems from CIP-004-6 when moved to CIP-011-3 R1.3. This deletion greatly expands the scope of this requirement, and may have created a situation where Responsible Entities could be subject to multiple compliance violations based on a single action due to overlapping obligatations in the CIP Standards.

Having a lack of ERC also renders BCSI pertaining to Medium Impact BES Cyber Systems outside the scope of R1 Part 1.2, as such information, if obtained, cannot be used remotely, as there is no remote access to the Cyber Systems. Information pertaining to these Cyber Systems can only be used to compromise them by breaching physical security.

There also is significant scope expansion with the authorization/revocation and review requirements now applying to all BCSI (not just designated storage locations of BCSI). This expansion of scope is not justified, as the deliberate choice of not implementing ERC to Medium Impact BES Cyber Systems is currently recognized as a considerable protection.

Terry Harbour, Berkshire Hathaway Energy - MidAmerican Energy Co., 1, 2/3/2020

- 0 - 0

ERCOT agrees that the concepts of the current version of CIP-004 are maintained.  However, a better approach may be to correct this with new parts in CIP-004.  ERCOT also refers the drafting team to the comments submitted by ERCOT in response to Question No. 10.

Brandon Gleason, Electric Reliability Council of Texas, Inc., 2, 2/3/2020

- 0 - 0

Westar and Kansas City Power & Light Company, endorse Edison Electric Institute's (EEI) comments.

Westar-KCPL, Segment(s) 1, 3, 5, 6, 12/18/2018

- 0 - 0

PG&E agrees the placement of access authorization and revocation as written in CIP-011-3, R1, Parts 1.3 and 1.5 does maintain backward compatibility to existing CIP-004 processes if an entity elects to use those existing processes.

As noted in Question 1, PGAE does not agree storage locations need to be identified to establish the protections for the BCSI.

PG&E All Segments, Segment(s) 1, 3, 5, 1/29/2020

- 0 - 0

"Method(s) to prevent the unauthorized access to and use of BES Cyber System Informatin during storage, transit, use, and disposal." is a practical than "elminate the ability to ...."

Allan Long, Memphis Light, Gas and Water Division, 1, 2/3/2020

- 0 - 0

We support the EEI and MRO NSRF comments that disagree with the qualifying language “with ERC” dropping from the applicability of Medium Impact BES Cyber Systems from CIP-004-6 when moved to CIP-011-3 R1.3. This deletion greatly expands the scope of this requirement, and may have created a situation where Responsible Entities could be subject to multiple compliance violations based on a single action due to overlapping obligatations in the CIP Standards.

 

Having a lack of ERC also renders BCSI pertaining to Medium Impact BES Cyber Systems outside the scope of R1 Part 1.2, as such information, if obtained, cannot be used remotely, as there is no remote access to the Cyber Systems. Information pertaining to these Cyber Systems can only be used to compromise them by breaching physical security.

 

There also is significant scope expansion with the authorization/revocation and review requirements now applying to all BCSI (not just designated storage locations of BCSI). This expansion of scope is not justified, as the deliberate choice of not implementing ERC to Medium Impact BES Cyber Systems is currently recognized as a considerable protection.

Darnez Gresham, Berkshire Hathaway Energy - MidAmerican Energy Co., 3, 2/3/2020

- 0 - 0

Laura Nelson, IDACORP - Idaho Power Company, 1, 2/3/2020

- 0 - 0

By moving the requirements from CIP-004 to CIP-011 will require a reworking of existing evidence and will cause confusion during any subsequent audits. 

Colleen Campbell, On Behalf of: AES - Indianapolis Power and Light Co., , Segments 3

- 0 - 0

Comments: No. The CIP-004-6 requirements are based on an “Applicable System” approach and access to BCSI designated electronic and physical storage locations. However, CIP-011 shifts the paradigm to “Applicability,” access to BCSI, and the ability to obtain and use the information. 

Recommendation: Ensure that the implementation timeline accounts for the need to shift the construct of an Entity’s information protection program. 

Michael Puscas, On Behalf of: ISO New England, Inc., , Segments 2

- 0 - 0

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

- 1 - 0

I don't see backwards compatibility based on the methods listed in 1.2.

Marty Hostler, Northern California Power Agency, 5, 2/3/2020

- 0 - 0

Hot Answers

Constantin Chitescu, Ontario Power Generation Inc., 5, 2/3/2020

- 0 - 0

SunPower agrees with MRO NSRF’s comments

Bradley Collard, 2/3/2020

- 0 - 0

Other Answers

I cannot find these references in CIP-004-7.  If you are referring to CIP-011-3, we see where you are trying to go, but we dont think that it is clear enough.

Kevin Conway, Public Utility District No. 1 of Pend Oreille County, 1, 12/23/2019

- 0 - 0

Calvin Wheatley, On Behalf of: Wabash Valley Power Association, SERC, RF, Segments 1, 3

- 0 - 0

The requirement mixes two types of usage needs.  One is cloud storage and a separate requirement for vendors using information to perform work.  The standard is appropriate for cloud storage type vendors.  However, vendors using information for contract work should be moved or added to CIP-013 as part of an appropriate risk assessment.

Susan Sosbe, Wabash Valley Power Association, 3, 1/22/2020

- 0 - 0

Comments: Although the language allows Entities to expand information storage solutions, it then leaves the Entity open to risk due to interpretation of how their process and security measures are interpreted by an auditor.  As long as there is consistency in audit, that if an Entity follows their process, as required by the standard, no audit findings will be given.  If an auditor takes issue with the Entity’s process(es) or security technology, an audit recommendation would be given, not a finding and or associated fine.

William Hutchison, On Behalf of: Southern Illinois Power Cooperative, , Segments 1

- 0 - 0

Duke Energy generally agrees that this approach is reflected in the proposed requirements. However, the requirements as written are problematic for reasons provided in subsequent responses.

Duke Energy, Segment(s) 1, 5, 6, 3, 12/13/2019

- 0 - 0

DTE Energy - DTE Electric, Segment(s) 5, 4, 3, 2/27/2017

- 0 - 0

There are too many ambiquities and additional clarity is required.

Scott Miller, On Behalf of: Roger Brand, MEAG Power, 1,3; Roger Brand, MEAG Power, 1,3; Roger Brand, MEAG Power, 1,3; David Weekley, MEAG Power, 1,3; David Weekley, MEAG Power, 1,3; David Weekley, MEAG Power, 1,3

- 0 - 0

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

- 0 - 0

Public Utility District No. 1 of Chelan County, Segment(s) 3, 1, 1/27/2020

- 0 - 0

Karl Blaszkowski, CMS Energy - Consumers Energy Company, 3, 1/28/2020

- 0 - 0

Donald Lynd, CMS Energy - Consumers Energy Company, 1, 1/28/2020

- 0 - 0

The increase in storage solutions adds ambiguity this could have been done in a more effective way by removing references to physical and electronic storage. If this new version is intended to allow Storage as a Service model by external vendors, it should be clearified.  We recommend that the BES CSI also be clearified to define terms such as ‘context’.

Joe Tarantino, On Behalf of: Kevin Smith, Balancing Authority of Northern California, 1; Kevin Smith, Balancing Authority of Northern California, 1; Kevin Smith, Balancing Authority of Northern California, 1; Jamie Cutlip, Sacramento Municipal Utility District, 1,3,4,5,6; Jamie Cutlip, Sacramento Municipal Utility District, 1,3,4,5,6; Jamie Cutlip, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Beth Tincher, Sacramento Municipal Utility District, 1,3,4,5,6; Beth Tincher, Sacramento Municipal Utility District, 1,3,4,5,6; Beth Tincher, Sacramento Municipal Utility District, 1,3,4,5,6; Arthur Starkovich, Sacramento Municipal Utility District, 1,3,4,5,6; Arthur Starkovich, Sacramento Municipal Utility District, 1,3,4,5,6; Arthur Starkovich, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6

- 0 - 0

Cloud storage and encryption technologies are not excluded under the current standards. The ERO Enterprise CMEP Practice Guide: BES Cyber System Information dated April 26, 2019 suggests that CIP-004-6 and CIP-011-2 already accommodate BCSI on the cloud. 

We believe it would be better to focus efforts on Requirements that do not hinder the use of other solutions while allowing for the development of access control programs by Responsible Entities that address risk posed to the industry. Any new Requirements need to meet the objective of protecting access to BCSI without constraining or prescribing types of storage solutions.  

MRO NSRF, Segment(s) 3, 4, 5, 6, 1, 2, 1/29/2020

- 0 - 0

FE Voter, Segment(s) 1, 3, 5, 6, 4, 10/31/2019

- 0 - 0

Xcel Energy support the comments submitted by EEI.

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

- 0 - 0

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

- 0 - 0

Support the MRO NSRF comments

Jeremy Voll, Basin Electric Power Cooperative, 3, 1/30/2020

- 0 - 0

Anthony Jablonski, ReliabilityFirst , 10, 1/30/2020

- 0 - 0

We disagree with the requirement language for achieving the SDT’s goal. One of the SAR goals is to clarify the protections expected when utilizing third-party solutions (e.g., cloud services), but we haven’t see the cloud storage and encryption language in the revised requirements yet.

Bruce Reimer, Manitoba Hydro , 1, 1/30/2020

- 0 - 0

The revision succeeds in part but at the risk of considerable new ambiguities and unintended consequences (such as returning to the difficulty inherent in CIP v1-3 of controlling access to each individual piece of BCSI, or the necessity to understand the capability of an outside party to reasonably assess if they can “obtain and use” BCSI). The proposed language from CIP-011 R1.1 to R1.3 seems to Seattle a promising start to an objective-based, risk-focused approach to protection of BCSI, but then subsequent sub-requirements and requirements revert to an old-school prescriptive approach that creates confusion, speaks to specific technologies, and limits options. Seattle would prefer that a new Standard state a security objective, require a risk-based plan to meet this object (with certain, minimal components that must be in the plan), and then require implementation and periodic review of the plan.

Seattle also supports the comments of SMUD to this question.

Matthew Nutsch, On Behalf of: Seattle City Light, WECC, Segments 1, 3, 4, 5, 6

- 0 - 0

Tri-State does not agree that this approach is aproppriately reflected in the proposed requirements. Some items allow for expanded use of BCSI solutions; however, the new R2 requirements are too prescriptive and cannot be prudently applied across all BCSI storage solutions and they limit the ability for the entity to manage their own compliance. Instead, these requirements should be objective based, which can be tailored to the specific solution and security options.  

Kjersti Drott, Tri-State G and T Association, Inc., 1, 1/31/2020

- 0 - 0

Payam Farahbakhsh, Hydro One Networks, Inc., 1, 1/31/2020

- 0 - 0

The proposed language is too prescriptive and loses the focus on controlling access to BCSI. In its present form, it precludes technical advances that may improve how an RE controls access (e.g., geolocation, biometric, and other potential solutions).

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

- 0 - 0

Black Hills agrees that these changes make, what was understood to be possible under the current standards more explicit, however we are concerned that the standard remains too rigid. Instead we would prefer to see guidelines which then allow the RE to document its approach for using new technologies.

Maryanne Darling-Reich, On Behalf of: Black Hills Corporation - MRO, WECC - Segments 1, 3, 5, 6

- 0 - 0

AEP is of the opinion that the approach to expand information storage solutions is reflected in the proposed modifications. However, we feel that while this approach may help organizations having information storage isssues, we also feel that this approach produces security concerns as a result of BCSI being stored using cloud technology.

Kent Feliks, AEP, 3, 1/31/2020

- 0 - 0

Russel Mountjoy, Midwest Reliability Organization, 10, 1/31/2020

- 0 - 0

AECI supports comments filed by NRECA

AECI, Segment(s) 1, 3, 6, 5, 5/31/2019

- 0 - 0

NRECA agrees that this is reflected in the proposed revisions; however, we are concerned that the way this has been incorporated places additional unnecessary compliance obligations on those entities that have chosen not to engage in the storage of BCSI in a cloud or other storage solution.  Additionally, NRECA notes that the proposed revisions are very limiting relative to compatibility with future or differently configured storage solutions.    For these reasons, NRECA is concerned that the proposed revisions will only work for specifically configured storage solutions and will not be properly scoped or flexible enough to accommodate the evolving storage and other solutions that could be employed in the future.

Barry Lawson, National Rural Electric Cooperative Association, 4, 2/3/2020

- 0 - 0

Agree with MRO NSRF comments.

Andy Fuhrman, On Behalf of: Theresa Allard, Minnkota Power Cooperative Inc., 1; Theresa Allard, Minnkota Power Cooperative Inc., 1; Theresa Allard, Minnkota Power Cooperative Inc., 1

- 0 - 0

GSOC agrees that this is reflected in the proposed revisions; however, is concerned that the manner in which this has been  incorporated places additional unnecessary compliance obligations on those entities that have chosen not to engage in the storage of BCSI in a cloud or other storage solution.  Additionally, GSOC notes that the proposed revisions are very limiting relative to compatibility with future or differently configured storage solutions.  Finally, GSOC respectfully asserts that standard revisions to accommodate cloud storage are unnecessary and would be better addressed in implementation or compliance guidance.  For these reasons, GSOC is concerned that the proposed revisions will only work for specifically configured storage solutions and will not be properly scoped or flexible to enough to accommodate the evolving storage and other solutions that could be employed in the future.

Andrea Barclay, Georgia System Operations Corporation, 4, 2/3/2020

- 0 - 0

SMEC agrees with comments submitted by NRECA.

Lana Smith, San Miguel Electric Cooperative, Inc., 5, 2/3/2020

- 0 - 0

Although the language allows Entities to expand information storage solutions, it then leaves the Entity open to risk due to interpretation of how their process and security measures are interpreted by an auditor.  As long as there is consistency in audit, that if an Entity follows their process, as required by the standard, no audit findings will be given.  If an auditor takes issue with the Entity’s process(es) or security technology, an audit recommendation would be given, not a finding and or associated fine.

ACES Standard Collaborations, Segment(s) 1, 3, 2/3/2020

- 0 - 0

Dwayne Parker, 2/3/2020

- 0 - 0

No comment.

Leonard Kula, Independent Electricity System Operator, 2, 2/3/2020

- 0 - 0

Yes, agree that a stand alone requirement where a vendor stores an entitiy’s BCSI is needed.  1.4.1 requires an initial risk assessment of vendors but the SDT needs to define what is acceptable evidence for a risk assessment.

Santee Cooper, Segment(s) 1, 3, 5, 6, 2/3/2020

- 0 - 0

 

 It is unclear in this draft or guidance how the SDT is expanding information storage soluctions or security technologies.

sean erickson, Western Area Power Administration, 1, 2/3/2020

- 0 - 0

Yes the expanded approach is available in the proposed standard; however, as discussed later, the requirements need to be improved.

Gerry Adamski, Cogentrix Energy Power Management, LLC, 5, 2/3/2020

- 0 - 0

Although AZPS agrees that the SDT’s intent is reflected in Part 1.4, the requirements as written do not clearly reflect an approach to expand information storage solutions or security technologies.  

Vivian Moser, 2/3/2020

- 0 - 0

New and emerging technologies shift the paradigm of security controls away from a specific storage location/repository to the ability to access and use the information itself. For example, an entity that utilizes file level security can apply encrypted protections on the data that preclude unauthorized access to the data regardless of where it is stored.  Requiring a list of storage locations is an antiquated construct that disincentivizes entities from using potentially more secure mechanisms because of the impossibility of compliance with documenting storage locations. The requirement should be technology agnostic and objective based, so it is written to focus on the implementation of effective methods that afford adequate security protections to prevent unauthorized access to the information

LaTroy Brumfield, American Transmission Company, LLC, 1, 2/3/2020

- 0 - 0

Truong Le, On Behalf of: Chris Gowder, Florida Municipal Power Agency, 3,4,5,6; Chris Gowder, Florida Municipal Power Agency, 3,4,5,6; Chris Gowder, Florida Municipal Power Agency, 3,4,5,6; Carol Chinn, Florida Municipal Power Agency, 3,4,5,6; Carol Chinn, Florida Municipal Power Agency, 3,4,5,6; Carol Chinn, Florida Municipal Power Agency, 3,4,5,6; Dale Ray, Florida Municipal Power Agency, 3,4,5,6; Dale Ray, Florida Municipal Power Agency, 3,4,5,6; Dale Ray, Florida Municipal Power Agency, 3,4,5,6; Richard Montgomery, Florida Municipal Power Agency, 3,4,5,6; Richard Montgomery, Florida Municipal Power Agency, 3,4,5,6; Richard Montgomery, Florida Municipal Power Agency, 3,4,5,6; David Owens, Gainesville Regional Utilities, 1,3,5; David Owens, Gainesville Regional Utilities, 1,3,5; David Owens, Gainesville Regional Utilities, 1,3,5

- 0 - 0

Tri-State G&T does not agree that this approach is aproppriately reflected in the proposed requirements. Some items allow for expanded use of BCSI solutions however, the new R2 requirements are too prescriptive and cannot be prudently applied across all BCSI storage solutions and they limit the ability for the entity to manage their own compliance. Instead, these requirements should be objective based, which can be tailored to the specific solution and security options.  

Janelle Marriott Gill, Tri-State G and T Association, Inc., 3, 2/3/2020

- 0 - 0

See NRECA submitted comments. 

Jonathan Robbins, Seminole Electric Cooperative, Inc., 4, 2/3/2020

- 0 - 0

Anton Vu, Los Angeles Department of Water and Power, 6, 2/3/2020

- 0 - 0

While N&ST understands one of the SDT’s key goals is to facilitate the use of an expanded array of storage options, we believe the associated imposition of a specific technology (encryption + key management) is likely to inhibit, not promote, the use of newer storage options such as cloud-based solutions. Furthermore, N&ST is concerned that the SDT’s proposed changes could have significant cost and effort impacts on Responsible Entities that neither store BCSI in the cloud today nor have any plans to do so in the future.

Nicholas Lauriat, Network and Security Technologies, 1, 2/3/2020

- 0 - 0

We disagree because cloud based storage technologies and encryption technologies are not excluded under the current standards. The ERO Enterprise CMEP Practice Guide stated: BES Cyber System Information dated April 26, 2019 suggests that CIP-004-6 and CIP-011-2 already accommodates BCSI on the cloud. 

Sandra Shaffer, Berkshire Hathaway - PacifiCorp, 6, 2/3/2020

- 0 - 0

ALAN ADAMSON, New York State Reliability Council, 10, 2/3/2020

- 0 - 0

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

- 0 - 0

Rachel Coyne, Texas Reliability Entity, Inc., 10, 2/3/2020

- 0 - 0

Dominion Energy supports the work the SDT has done on develoing the current draft. Dominion energy suggests that the team focus on the approach taken in the current NERC CMEP Guidance document in addressing the issue and further supports EEIs comments.

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

- 0 - 0

Exelon supports EEI's comments on behalf of Exelon Segments 1, 3, 5, and 6.

Kinte Whitehead, Exelon, 3, 2/3/2020

- 0 - 0

Ameren agrees with and supports EEI comments.

David Jendras, Ameren - Ameren Services, 3, 2/3/2020

- 0 - 0

NCEMC supports the comments by Barry Lawson, National Rural Electric Cooperative Association and ACES

Kagen DelRio, On Behalf of: North Carolina Electric Membership Corporation - SERC - Segments 3, 4, 5

- 0 - 0

The question asks if the approach expands two different things: information storage solutions and security technologies.  We agree the changes could allow for expanded storage solutions, but we do not agree that this approach expands security technologies for Responsible Entities. An example of a security technology may be a cloud service that needs to use the information in order to provide security or reliability benefit to the BES.  We find an applicable phrase in the “Industry Need” section of the SAR that states the expected reliability benefit is “providing a secure path towards utilization of modern third-party data storage and analysis systems” and the current draft doesn’t address third party analysis of the data to provide services to entities and actually further restricts such analysis.     

 

It seems the approach is focused solely on using cloud storage for BCSI in an encrypted form and managing the encryption keys.  Therefore, the focus seems to be on cloud storage only, not cloud services that need to use or analyze the data to provide services such as security monitoring technologies.

Southern Company, Segment(s) 1, 3, 5, 6, 12/13/2019

- 0 - 0

Tho Tran, On Behalf of: Lee Maurer, Oncor Electric Delivery, 1; Lee Maurer, Oncor Electric Delivery, 1; Lee Maurer, Oncor Electric Delivery, 1

- 0 - 0

SDG&E supports EEI’s comments submitted on our behalf.

Bridget Silvia, Sempra - San Diego Gas and Electric, 3, 2/3/2020

- 0 - 0

ITC supports the response found in the NSRF Comment Form

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

- 0 - 0

Eversource Group, Segment(s) 3, 1, 4/12/2019

- 0 - 0

We disagree with the proposed approach, as we do not see the necessity. Cloud-based storage technologies and encryption technologies are not excluded either under the current standards, or by the ERO Enterprise CMEP Practice Guide BES Cyber System Information dated April 26, 2019.

 

We agree with EEI comments that requirements should neither constrain nor prescribe solutions.  

Kevin Salsbury, Berkshire Hathaway - NV Energy, 5, 2/3/2020

- 0 - 0

Please see comments submitted by Edison Electric Institute

Ayman Samaan, 2/3/2020

- 0 - 0

No comments

David Rivera, New York Power Authority, 3, 2/3/2020

- 0 - 0

We appreciate the SDT’s effort to expand information storage solutions and security technologies; however, key management is the only technology that is explicitly detailed within the requirements.  We feel that this is contradictory to what the 2016-02 SDT is working to accomplish with risk-based standards. Additionally, as the requirement is currently written, an entity would need to prove a negative if this requirement is not applicable to them, which is administratively burdensome. Finally, while it might not have been the SDT’s intent, an auditor might interpret the requirement to mean that if an entity uses encryption internally (not with a third-party), then that entity must have a key management program, based on the requirement, for their internal encryption.  

PPL NERC Registered Affiliates, Segment(s) 1, 3, 5, 6, 9/6/2018

- 0 - 0

Support MRO comments.

Wayne Guttormson, SaskPower, 1, 2/3/2020

- 0 - 0

The standards development team should support specific requirements providing appropriate levels of security for Cloud Service Providers and 3rd Party Access. Transferring the CIP-004 BCSI requirements to CIP-011 does not address the unique issues created by storing BCSI in repositories that are not controlled by registered entities. The standards development team should draft separate requirements.

Steve Toosevich, NiSource - Northern Indiana Public Service Co., 1, 2/3/2020

- 0 - 0

See Steven Toosevich's comments.  

Kathryn Tackett, NiSource - Northern Indiana Public Service Co., 5, 2/3/2020

- 0 - 0

No, this approach is not clearly reflected in the proposed requirements.  If the SDT’s intent is to provide direction on protection of BCSI stored in the cloud, it should be clearly stated by saying that these requirements are intended to address vendor operated storage locations or services.  The vague language of “in cases where vendors store Responsible Entity’s BES Cyber System Information” opens a broad potential for auditor interpretation with unintended applicability, including instances where data has been shared with a vendor, but the vendor is not operating a storage location, or where a corporate resource with cloud functions is used to store working copies of data but is not a designated storage location.

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

- 0 - 0

EEI appreciates the SDT efforts to expand information storage solutions or security technologies for responsible entities.  However, the proposed approach appears to be too prescriptive and inconsistent with elements of a results-based standard.  The SDT should also ensure that the requirements are not tailored to any one solution or technology.

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

- 0 - 0

NYISO’s response is based on the assumption this question pertains to all proposed changes in CIP-011, requirement R1 (all subsections).

NYISO feels that the proposed changes do not clearly draw out or articulate key distinctions that were presented within the Q&A portion of the 2019-02: BES Cyber System Information Access Management Webinar hosted on January 16, 2020.  NYISO feels that additional language be inserted to account for use cases (physical or electronic data being housed within either the responsible entity’s controlled data centers or instances where the responsible entity has chosen to use vendor-hosted storage.

To make this clearer, NYISO proposes the SDT include the following changes:

Within Part 1.1:  Modifications be made to the last example provided under Measures to read:

“Storage locations (physical or electronic, responsible entity or vendor hosted) be identified as housing BES Cyber System Information in the entity’s information protection program.”

Within Part 1.2:   For clarity, modify the bullet under Measures to read:  

“Evidence of methods used to prevent the unauthorized access to BES Cyber System Information (e.g., encryption of BES Cyber System Information with a sound key management program, retention within the responsible entity’s Physical Security Perimeter).”

NYISO feels that Part 1.3 will become unnecessary if the SDT retains all access management provisions (BCS and BCSI) within CIP-004-7.

NYISO would recommend that provisions contained in the current draft within Part 1.4 be removed from CIP-011-3 and addressed as part of CIP-013-2.  This would have the effect of keeping all vendor requirements (BCS and BCSI) within the same standard.

NYISO would recommend that the provisions contained in the current draft within Part 1.5 be removed from CIP-011-3 and addressed as part of CIP-004-7.  This would have the effect of keeping all access management requirements (BCS and BCSI) within the same standard.

Overall, NYISO would like to see all of the requirements in R1 be made clearer to allow the Responsible Entity latitude to choose any applicable security technologies that adequately protects BCSI, based on risk.  Within the current draft, the language within R2 suggests that key management programs are mandatory; however, NYISO believes the intent was to allow other methods of protections as supported options.

Gregory Campoli, On Behalf of: New York Independent System Operator, , Segments 2

- 0 - 0

RSC no NextEra, Segment(s) 10, 2, 4, 5, 7, 3, 1, 6, 2/3/2020

- 0 - 0

No, SNPD does not believe the SDT’s objective has been met.  SNPD believes that without explicit, affirmative authorization to use managed service (“cloud”) storage solutions, Entities cannot and likely will not feel confident storing BCSI in the cloud.  Entities will likely take the most conservative response to avoid potential compliance risk and simply choose not to use cloud storage solutions.  Thereby, maintaining the status quo and depriving Entities of the flexibility desired under the proposed change.  Suggestion: establish “reciprocity” from current Federal IT certification standards such as FedRAMP/FISMA/DoD D-ITAR.  Issue a blanket statement that storage of BCSI is authorized in any/all FedRAMP/FISMA or DoD D-ITAR cloud.  This type of verbiage is both actionable and clear.

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

- 1 - 0

While Alliant Energy appreciates the SDT’s efforts to expand information storage solutions or security technologies for responsible entities, that expansion is only useful if the requirement language is written such that it is clearly auditable. The updated requirements should avoid the ability to audit to prescriptive requirements that are not stated in the language of the requirements.

Jenifer Holmes, On Behalf of: Alliant Energy Corporation Services, Inc. - MRO, RF - Segments 4

- 0 - 0

Jamie Monette, Allete - Minnesota Power, Inc., 1, 2/3/2020

- 0 - 0

See Steven Toosevich's comments. 

Dmitriy Bazylyuk, 2/3/2020

- 0 - 0

MISO’s response assumes this question pertains to all proposed changes in CIP-011, requirement R1 (parts 1.1 – 1.5).

The proposed changes as written, do not clearly draw out / articulate key distinctions that were noted during the Q&A portion of the 2019-02: BES Cyber System Information Access Management Webinar hosted on January 16, 2020: physical or electronic, responsible entity or vendor hosted. To make this clear in the proposed standard, MISO proposes the SDT include the following changes.

Part 1.1. Modify the last example provided under Measures to read as follows: “Storage locations (physical or electronic, responsible entity or vendor hosted) identified for housing BES Cyber System Information in the entity’s information protection program.”

Part 1.2 For clarity, modify the bullet under Measures as follows: “Evidence of methods used to prevent the unauthorized access to BES Cyber System Information (e.g., encryption of BES Cyber System Information, [delete the word "and"] key management program, retention in the Physical Security Perimeter).”

Part 1.3 May not be necessary if the SDT accepts MISO’s proposal to retain all access management provisions (BCS and BCSI) as part of CIP-004-7.

Part 1.4 MISO recommends the provisions in this section be eliminated from CIP-011-3 and addressed as part of CIP-013-2 thereby covering all vendor requirements (BCS and BCSI) in the same standard.

Part 1.5 MISO recommends the provisions in this section be eliminated from CIP-011-3 and addressed as part of CIP-004-7, requirement R5.3 thereby covering all access management requirements (BCS and BCSI) in the same standard.

 

Bobbi Welch, On Behalf of: Midcontinent ISO, Inc., , Segments 2

- 0 - 0

There is no expansion of solutions or technologies used. The proposed requirements codify the controls that have been discussed in informal manners. This is a slight improvement, but as long as CIP requirements can also be interpreted as applicable for cloud vendors and are in the audit scope of CIP audits, there is no real improvement.

 

Recommend excluding cloud vendors from applicability column of BCSI requirements and, instead setting requirements to be included in risk assessments of cloud vendors and have the CIP senior manager or delegate approve each assessment and applicable risk mitigations at minimum intervals. In addition cloud vendor requirements appears to be better addressed through CIP-013.

 

BCSI related cloud vendor risk assessment components can be a subset of CIP004 or CIP011 requirements that meet cloud vendor industry best practices such as the Cloud Security Alliance (CSA) Consensus Assessments Initiative Questionnaire (CAIQ) and the provision of certifications (e.g. ISO 27000) or audit reports (e.g. SOC for security) from accredited auditors who have verified cloud vendor claims of compliance.

James Brown, On Behalf of: California ISO, WECC, Segments 2

- 0 - 0

PGE agrees with EEI’s comments

PGE Group 2, Segment(s) 1, 3, 6, 5, 2/3/2020

- 0 - 0

No, in order to provide expanded security technology solutions (read “in the cloud”), the vendor may need both access and use of BCSI to provide any value to the registered entity. The approach offered in this proposal does not allow this access.

Jennie Wike, On Behalf of: Marc Donaldson, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Marc Donaldson, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Marc Donaldson, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; John Merrell, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; John Merrell, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; John Merrell, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Hien Ho, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Hien Ho, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Hien Ho, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Terry Gifford, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Terry Gifford, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Terry Gifford, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Ozan Ferrin, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Ozan Ferrin, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Ozan Ferrin, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6

- 0 - 0

Please see comments PGE Group 2

Angela Gaines, Portland General Electric Co., 1, 2/3/2020

- 0 - 0

We believe the existing standard already allows multiple solutions.  Why won't NERC/FERC tell Entities that the standard does not limited the scope of solutions available to entities and be done with this?

Dennis Sismaet, Northern California Power Agency, 6, 2/3/2020

- 0 - 0

We disagree with the proposed approach, as we do not see the necessity. Cloud-based storage technologies and encryption technologies are not excluded either under the current standards, or by the ERO Enterprise CMEP Practice Guide BES Cyber System Information dated April 26, 2019.

We agree with EEI and MRO NSRF comments that requirements should neither constrain nor prescribe solutions.  

Terry Harbour, Berkshire Hathaway Energy - MidAmerican Energy Co., 1, 2/3/2020

- 0 - 0

There is no expansion of solutions or technologies used.  The proposed requirements codify the controls that have been discussed in informal manners.  This is a slight improvement, but as long as CIP requirements can also be interpreted as applicable to cloud vendors, and are in the scope of CIP audits, there is no real improvement.

 

ERCOT recommends excluding cloud vendors from the applicability column of BCSI requirements, and instead setting requirements to be included in risk assessments of cloud vendors and having CIP senior managers or delegates approve each assessment and applicable risk mitigations at minimum intervals.  In addition, cloud vendor requirements appear to be better addressed through CIP-013.

 

BCSI related cloud vendor risk assessment components can be a subset of CIP-004 or CIP-011 requirements that meet cloud vendor industry best practices such as the Cloud Security Alliance (CSA), Consensus Assessments Initiative Questionnaire (CAIQ), and the provision of certifications (e.g. ISO 27000) or audit reports (e.g. SOC for security) from accredited auditors who have verified cloud vendor claims of compliance.

Brandon Gleason, Electric Reliability Council of Texas, Inc., 2, 2/3/2020

- 0 - 0

Westar and Kansas City Power & Light Company, endorse Edison Electric Institute's (EEI) comments.

Westar-KCPL, Segment(s) 1, 3, 5, 6, 12/18/2018

- 0 - 0

PGAE believes the modifications expand the capability to use third-party service providers without a risk of being non-compliant based on different interpretations of the current Standards.  The method(s) or technology used to protect the BCSI are non-prescriptive, providing the necessary flexibility to meet the objective of preventing unauthorized access.

PG&E All Segments, Segment(s) 1, 3, 5, 1/29/2020

- 0 - 0

Allan Long, Memphis Light, Gas and Water Division, 1, 2/3/2020

- 0 - 0

We disagree with the proposed approach, as we do not see the necessity. Cloud-based storage technologies and encryption technologies are not excluded either under the current standards, or by the ERO Enterprise CMEP Practice Guide BES Cyber System Information dated April 26, 2019.

 

We agree with EEI and MRO NSRF comments that requirements should neither constrain nor prescribe solutions.  

Darnez Gresham, Berkshire Hathaway Energy - MidAmerican Energy Co., 3, 2/3/2020

- 0 - 0

Laura Nelson, IDACORP - Idaho Power Company, 1, 2/3/2020

- 0 - 0

There has to be a better definition of the different storage and security technologies the SDT is considering. There will be a big difference between on premise and external solutions.

Colleen Campbell, On Behalf of: AES - Indianapolis Power and Light Co., , Segments 3

- 0 - 0

Comments: While there is clearly an effort to address expanded use of information storage solutions and security technologies, the current draft does not specifically address use cases associated with cloud services and information sharing with external parties as clearly as will be required.  For entities to make use of options available from external service providers, there will need to be specification of information protections specific to such situations (i.e. whether individual access to information must be demonstrated by the service provider to the responsible entity and the expectations for measures to demonstrate compliance of a third party).

Michael Puscas, On Behalf of: ISO New England, Inc., , Segments 2

- 0 - 0

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

- 1 - 0

We believe the existing standard already allows multiple solutions.  Why won't NERC/FERC tell Entities that the standard does not limited the scope of solutions available to entities and be done with this?

Marty Hostler, Northern California Power Agency, 5, 2/3/2020

- 0 - 0

Hot Answers

OPG is in agreement with RSC provided comment

Constantin Chitescu, Ontario Power Generation Inc., 5, 2/3/2020

- 0 - 0

1.2 becomes extremely burdensome by eliminating the ability to obtain and use BCSI during storage, transit, use, and disposal. Entities may need to employ methods such as chain of custody for disposal of hard drives that may contain BCSI.

SunPower encourages the term “reduce” the ability to obtain and use BES Cyber System Information during storage, transit, use. . .

Bradley Collard, 2/3/2020

- 0 - 0

Other Answers

If you can clean up the sentance better.

Kevin Conway, Public Utility District No. 1 of Pend Oreille County, 1, 12/23/2019

- 0 - 0

Calvin Wheatley, On Behalf of: Wabash Valley Power Association, SERC, RF, Segments 1, 3

- 0 - 0

Susan Sosbe, Wabash Valley Power Association, 3, 1/22/2020

- 0 - 0

Comments: It is impossible to completely “prevent” and or “eliminate” the ability to obtain and or use BCSI during storage, transit, use, and disposal, so all Entities would be in violation the way this is written.  The reasons the standards exist are to lower cyber security risks to the BPS.  Suggest replacing “eliminating” with “reducing” or rewording the requirement language to: “Method(s) to reduce the risk of unauthorized access to BCSI during storage, transit, use and disposal.” 

William Hutchison, On Behalf of: Southern Illinois Power Cooperative, , Segments 1

- 0 - 0

Duke Energy generally agrees that the inclusion of the terms “obtain” and “use” in requirement CIP-011-3, Requirement R1 Part 1.2 will more accurately address the risk related to the potential compromise of BCSI.  Duke Energy foresees a challenge to be able to demonstrate how we “eliminate” the ability to “obtain and use” BCSI.

Suggest change "eliminating" to "limiting" or "restricting". Insert "both" before "obtain and use".

Duke Energy, Segment(s) 1, 5, 6, 3, 12/13/2019

- 0 - 0

Adding the additional terms of “obtain” and “use” to try to imply the use of encryption without explicitly stating the requirement weakens the language. Further, the use of the word “eliminating” adds significant burden to entities to prove their choosen method can never be compromised. Removal of the phrase “by eliminating the ability to obtain and use BES Cyber System Information” makes the requirement clear and allows entities to select current and future technologies to protect BCSI during storage, transit, use, and disposal. Consequently, by including these four phases protections for “obtaining” access and during “use” are included in a number of current storage and transit technologies.

DTE Energy - DTE Electric, Segment(s) 5, 4, 3, 2/27/2017

- 0 - 0

1.       CIP-011 R1, Part 1.2 states “….by eliminating the ability to obtain and use BES Cyber System Information during storage, transit, use, and disposal.”  Does a format of portable storage media (e.g. flash drives) eliminate the ability to obtain and use BCSI?

Scott Miller, On Behalf of: Roger Brand, MEAG Power, 1,3; Roger Brand, MEAG Power, 1,3; Roger Brand, MEAG Power, 1,3; David Weekley, MEAG Power, 1,3; David Weekley, MEAG Power, 1,3; David Weekley, MEAG Power, 1,3

- 0 - 0

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

- 0 - 0

Public Utility District No. 1 of Chelan County, Segment(s) 3, 1, 1/27/2020

- 0 - 0

Karl Blaszkowski, CMS Energy - Consumers Energy Company, 3, 1/28/2020

- 0 - 0

Donald Lynd, CMS Energy - Consumers Energy Company, 1, 1/28/2020

- 0 - 0

The ‘obtain’ and ‘use’ terms are not defined and will lead to additional ambiguity and confusion. It is impossible for entities to know the capabilities of potential threats, ‘use’ from one party may be different than another.

Joe Tarantino, On Behalf of: Kevin Smith, Balancing Authority of Northern California, 1; Kevin Smith, Balancing Authority of Northern California, 1; Kevin Smith, Balancing Authority of Northern California, 1; Jamie Cutlip, Sacramento Municipal Utility District, 1,3,4,5,6; Jamie Cutlip, Sacramento Municipal Utility District, 1,3,4,5,6; Jamie Cutlip, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Beth Tincher, Sacramento Municipal Utility District, 1,3,4,5,6; Beth Tincher, Sacramento Municipal Utility District, 1,3,4,5,6; Beth Tincher, Sacramento Municipal Utility District, 1,3,4,5,6; Arthur Starkovich, Sacramento Municipal Utility District, 1,3,4,5,6; Arthur Starkovich, Sacramento Municipal Utility District, 1,3,4,5,6; Arthur Starkovich, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6

- 0 - 0

Agree with terms “obtain” and “use;” however, more explanation is needed within the requirement or guidelines. The drafting team has referred to the CMEP BCSI practice guide. Recommend defining “BCSI Access” in the NERC Glossary of Terms per the practice guide: “An instance or event during which a user obtains and uses BCSI. For access to occur, in this context, a user, authorized or unauthorized, must concurrently both obtain BCSI and possess the ability to use BCSI. An unauthorized individual who obtains encrypted BCSI but has no ability to use it within a meaningful timeframe should not be considered to have access.”

Disagree and very concerned with the phrase “by eliminating the ability” to obtain and use. This represents an unachievable evidencing threshold over and above the current “Procedure(s) for protecting and securely handling.” Responsible Entities can document protective procedures, but will be hard pressed to prove they have eliminated all ability to obtain and use, i.e. rendered unauthorized access impossible.

Disagree with the addition of “and disposal” to the end of the requirement. BCSI in BES Cyber Systems is already addressed in R3 Part 3.1., but Part 3.1 needs to reinstate the qualifying language in the Requirements “that contain BES Cyber System Information.” Deletion of this qualifying language is an expansion of scope to the current CIP-011-2 R2 requiring evidence of sanitization of assets not containing BCSI subject to this protection.

Although a logical inclusion as part of the lifecycle of BCSI, as applied in R1 Part 1.2, the evidencing we do in R3 for hardware is now going to be extended to the disposal/deletion of BCSI, on every medium, wherever stored, since the Measure calls for “Evidence of methods used to prevent the unauthorized access…” during disposal.  The evidencing burden here can be crushing. Example concerns include:

- How will auditors know what BCSI has been disposed of unless Entities maintain an active inventory of BCSI “info items” and status, active or disposed, just like we do for BES Cyber Systems?

- Entity may have a policy to shred paper-based BCSI as the disposal method, but to evidence the method was used, does Entity have to log documents shredded?

- Will every electronic file, document, or email containing BCSI require its deletion to be logged by IT? Will Entities have to obtain such logs from third-party vendors/data custodians?

 

MRO NSRF, Segment(s) 3, 4, 5, 6, 1, 2, 1/29/2020

- 0 - 0

FE Voter, Segment(s) 1, 3, 5, 6, 4, 10/31/2019

- 0 - 0

Xcel Energy support the comments submitted by EEI.

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

- 0 - 0

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

- 0 - 0

Support the MRO NSRF comments

Jeremy Voll, Basin Electric Power Cooperative, 3, 1/30/2020

- 0 - 0

Anthony Jablonski, ReliabilityFirst , 10, 1/30/2020

- 0 - 0

Disagree with the phrase “by eliminating the ability to obtain and use” and it should be moved to Guidelines and Technical Basis to explain what constitute a BCSI access. Agree with adding disposal since it was missing from current CIP-011-2 R1.2.

 

Suggest making the following changes for R1 Part 1.2:

“Method(s) to prevent unauthorized access to BES Cyber System Information during, including storage, transit, use, and disposal.”

 

Suggest adding the following language into Guidelines and Technical Basis based on CMEP BCSI Practice Guide:

“BCSI access means any instance or event during which a user obtains and uses BCSI. For access to occur, in this context, a user, authorized or unauthorized, must concurrently both obtain BCSI and possess the ability to use BCSI. An unauthorized individual who obtains encrypted BCSI but has no ability to use it within a meaningful timeframe should not be considered to have access.”

Bruce Reimer, Manitoba Hydro , 1, 1/30/2020

- 0 - 0

Seattle supports the comments of SMUD to this question.

Matthew Nutsch, On Behalf of: Seattle City Light, WECC, Segments 1, 3, 4, 5, 6

- 0 - 0

Tri-State does not agree. Need more clarity around what “use” means, especially considering this is an issue that currently exists under the version that is in effect. Similarly, there would need to be more clarity around the meaning of the term “obtain”.  

As for R1.2, we think the original language (other than “use” not being defined) was correct and the concept of “obtain and use” should instead be incorporated into the access requirements, especially R1.3. This will make it clear that in order for someone to be deemed to have access to BCSI, they must have the ability to obtain and use it, which would align with the ERO Practice Guide. Although, we don’t recommend using the actual terms “use” and “obtain”, without providing more clarification as to their meaning.

Kjersti Drott, Tri-State G and T Association, Inc., 1, 1/31/2020

- 0 - 0

There are issues with the wording.  eliminating the ability to obtain and use BES Cyber System Information during, including storage, transit, use, and disposal”

Payam Farahbakhsh, Hydro One Networks, Inc., 1, 1/31/2020

- 0 - 0

The removal of the word “designated” creates an insurmountable scope of program management. The use of the word “eliminate” sets an impossible threshold to achieve.

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

- 0 - 0

The ability to “obtain and use” allows for the use of encryption as an acceptable means of protecting BCSI and helps to clarify “knowing and utilizing the information” is what were aiming to protect, instead of simply possessing it. Additionally, Black Hills would like to see “Use” definded in the Glossary.

Maryanne Darling-Reich, On Behalf of: Black Hills Corporation - MRO, WECC - Segments 1, 3, 5, 6

- 0 - 0

AEP does not believe that the new language being proposed effectively addresses risks associated the compromise of BCSI. AEP has no opinion on the inclusion of the words “obtain” and “use”, but the inclusion of the word “eliminating” is a cause for concern. The absolute nature of the word has brought about concerns that it would be difficult to prove compliance.

Kent Feliks, AEP, 3, 1/31/2020

- 0 - 0

Russel Mountjoy, Midwest Reliability Organization, 10, 1/31/2020

- 0 - 0

AECI supports comments filed by NRECA

AECI, Segment(s) 1, 3, 6, 5, 5/31/2019

- 0 - 0

NRECA agrees that the approach essentially “eliminates” the risk associated with use of BCSI as the revisions require entities to completely eliminate the ability to obtain or use BCSI during nearly all life stages with the exception of creation.  NRECA believes that use of the term “eliminate” was inadvertent and should be revised to “control” or “restrict.”  Should the SDT remove the term “eliminate” and replace it with a feasible alternative, this requirement could achieve its intended purpose.  However, NRECA also notes, for the SDT’s consideration, the infeasibility of the term “prevent.” Responsible Entities cannot “prevent” or “eliminate” every risk or capability that could possibly manifest during the life cycle of BCSI.  Further, it is difficult to conceive of how prevention of “unauthorized access” would be documented and proven during compliance monitoring.

 

For this reason, NRECA recommends that the SDT revise the requirement to indicate an affirmative obligation to manage or control access rather than an obligation to prevent access, which would effectively require Responsible Entities to “prove” that unauthorized access did not occur rather than proving that they “controlled” or “managed” access through proactive security controls.  Such a revision will not only reduce the potential for confusion around whether unauthorized access was “prevented,” it will also remove the likelihood that Responsible Entities would be required to “prove a negative” during compliance monitoring activities.  For these reasons, NRECA recommends that the SDT consider revising the requirement as proposed below:

“Method(s) to "manage" access to BES Cyber System Information during storage, transit, use, and disposal.” 

Barry Lawson, National Rural Electric Cooperative Association, 4, 2/3/2020

- 0 - 0

While we appreciate the SDT’s effort to clarify what access means, this is better left to guidance documents, like it is now in the CMEP Practice Guide: BES Cyber System Information, dated April 26, 2019.  Without the additional context that the guidance document provides, this language just adds confusion to the requirement.  In addition, the ability to use information is open to interpretation, such as whether or not the individual has the knowledge to use the information in such a way as to affect the BES. 

Also, it is not possible to completely eliminate the ability to obtain and use BCSI, so “eliminate” should not be used.

Andy Fuhrman, On Behalf of: Theresa Allard, Minnkota Power Cooperative Inc., 1; Theresa Allard, Minnkota Power Cooperative Inc., 1; Theresa Allard, Minnkota Power Cooperative Inc., 1

- 0 - 0

GSOC agrees that the approach essentially “eliminates” the risk associated with use of BCSI as the revisions require entities to completely eliminate the ability to obtain or use BCSI during nearly all life stages with the exception of creation.  GSOC respectfully suggests that use of the term “eliminate” was inadvertent and should be revised to “control” or “restrict.”  Should the SDT remove the term “eliminate” and replace it with a feasible alternative, this requirement could achieve its intended purpose.  However, GSOC also notes, for the SDT’s consideration, the infeasibility of the term “prevent.” Responsible Entities cannot “prevent” or “eliminate” every risk or capability that could possibly manifest during the life cycle of BCSI.  Further, it is difficult to conceive of how prevention of “unauthorized access” would be documented and proven during compliance monitoring.

For this reason, GSOC recommends that the SDT revise the requirement to indicate an affirmative obligation to manage or control access rather than an obligation to prevent access, which would effectively require Responsible Entities to “prove” that unauthorized access did not occur rather than proving that they “controlled” or “managed” access through proactive security controls.  Such a revision will not only reduce the potential for confusion around whether unauthorized access was “prevented,” it will also remove the likelihood that Responsible Entities would be required to “prove a negative” during compliance monitoring activities.  For these reasons, GSOC recommends that the SDT consider revising the requirement as proposed below.

Method(s) to manage access to BES Cyber System Information during storage, transit, use, and disposal. 

Andrea Barclay, Georgia System Operations Corporation, 4, 2/3/2020

- 0 - 0

SMEC agrees with comments submitted by NRECA.

Lana Smith, San Miguel Electric Cooperative, Inc., 5, 2/3/2020

- 0 - 0

It is impossible to completely “prevent” and or “eliminate” the ability to obtain and or use BCSI during storage, transit, use, and disposal, so all Entities would be in violation the way this is written.  The reasons the standards exist are to lower cyber security risks to the BPS.  Suggest replacing “eliminating” with “reducing” or rewording the requirement language to: “Method(s) to reduce the risk of unauthorized access to BCSI during storage, transit, use and disposal.”  

ACES Standard Collaborations, Segment(s) 1, 3, 2/3/2020

- 0 - 0

Dwayne Parker, 2/3/2020

- 0 - 0

IESO agrees in principle with the comments submitted by NPCC:

While we agree that “obtain” and “use” more accurately address the risk, we have concerns with the overall wording because “eliminating” is an absolute (i.e. zero defect) which makes implementation and demonstrating Compliance too challenging

We recommend changing Part 1.2 from

<<Method(s) to prevent unauthorized access to BES Cyber System Information by *eliminating* the ability to obtain and use BES Cyber System Information during, including storage, transit, use, and disposal.>>

To

<<<<Method(s) to prevent unauthorized access to BES Cyber System Information by *controlling* the ability to obtain and use BES Cyber System Information during, including storage, transit, use, and disposal .>>

Leonard Kula, Independent Electricity System Operator, 2, 2/3/2020

- 0 - 0

The change made to CIP-011-3 Part 1.2 does not add clarity.  The choice of the second “use” in Part 1.2 is confusing and does not make sense; “…by eliminating the ability to obtain and use BES Cyber System Information during, storage, transit, use, and disposal.”  The standards drafting team needs to elaborate on “…eliminating the ability…”  The SDT should remove the second “use”.

Santee Cooper, Segment(s) 1, 3, 5, 6, 2/3/2020

- 0 - 0

WAPA requests changing the work “use” in the last sentence of the requirement.  “BES Cyber System Information during storage, transit, use and disposal.”  To “BES Cyber System Information during storage, transit, and disposal.  The lack of a clear definintion for the word “use” creates major problems for Registered Entities (REs).   Use in context of BCSI displayed a system screen, BCSI layed out on a drafting table, BCSI posted in a response/job aid binder  being read by an aoperator or BCSI in computer systems memory address? Without a better definition REs will need to implement procedures to address these scenarios; some of which are not commercially viable (memory encryption).

sean erickson, Western Area Power Administration, 1, 2/3/2020

- 0 - 0

Yes the requirement is improved with the suggested terms "use" and obtain".  However, the proposed requirement is somewhat circular and should be further improved as follows:

"Method(s) to prevent unauthorized access to BES Cyber System Information during storage, transit, use, sanitization, and disposal."  (The inclusion of sanitization here eliminates the need for R3 Part 3.1.)

The term "eliminating" suggests a zero-defect approach, which is an extremely challenging compliance outcome to achieve.

The second bullet in the both R1 Part 1.2 and Part 1.3 Measures is fragmented and introduces topics (e.g. key management program) that have yet to be presented in the standard.

Gerry Adamski, Cogentrix Energy Power Management, LLC, 5, 2/3/2020

- 0 - 0

While AZPS agrees that the inclusion of “obtain” and “use” more clearly addresses the risk related to the potential compromise of BCSI, AZPS believes that the proposed language in Part 1.2 creates an undue burden for Entities to execute and evidence “eliminating the ability to obtain and use BES Cyber System Information during storage, transit, use, and disposal”.   AZPS recommends that the SDT retain focus of the requirement language on “protecting and securely handling” BCSI, and address the inclusion of “obtain” and “use” in guidance documents.  AZPS offers proposed changes for Part 1.2 below:

“Procedure or method(s) to prevent unauthorized access, protect, and securely hande BES Cyber System Information during storage, transit, use, and disposal”.

Vivian Moser, 2/3/2020

- 0 - 0

The intention is good; however, the current proposed requirement language does not accomplish that intention; instead it seems to completely preclude the use of BCSI the way it is written.    

LaTroy Brumfield, American Transmission Company, LLC, 1, 2/3/2020

- 0 - 0

Truong Le, On Behalf of: Chris Gowder, Florida Municipal Power Agency, 3,4,5,6; Chris Gowder, Florida Municipal Power Agency, 3,4,5,6; Chris Gowder, Florida Municipal Power Agency, 3,4,5,6; Carol Chinn, Florida Municipal Power Agency, 3,4,5,6; Carol Chinn, Florida Municipal Power Agency, 3,4,5,6; Carol Chinn, Florida Municipal Power Agency, 3,4,5,6; Dale Ray, Florida Municipal Power Agency, 3,4,5,6; Dale Ray, Florida Municipal Power Agency, 3,4,5,6; Dale Ray, Florida Municipal Power Agency, 3,4,5,6; Richard Montgomery, Florida Municipal Power Agency, 3,4,5,6; Richard Montgomery, Florida Municipal Power Agency, 3,4,5,6; Richard Montgomery, Florida Municipal Power Agency, 3,4,5,6; David Owens, Gainesville Regional Utilities, 1,3,5; David Owens, Gainesville Regional Utilities, 1,3,5; David Owens, Gainesville Regional Utilities, 1,3,5

- 0 - 0

Tri-State G&T does not agree. Clarity is needed around what “use” means, especially considering this is an issue that currently exists under the version that is in effect. Similarly, there would need to be more clarity around the meaning of the term “obtain”.  

As for R1.2, we think the original language (other than “use” not being defined) was correct and the concept of “obtain and use” should instead be incorporated into the access requirements, especially R1.3. This will make it clear that in order for someone to be deemed to have access to BCSI, they must have the ability to obtain and use it, which would align with the ERO Practice Guide. Although, we don’t recommend using the actual terms “use” and “obtain”, without providing more clarification as to their meaning.

Janelle Marriott Gill, Tri-State G and T Association, Inc., 3, 2/3/2020

- 0 - 0

See NRECA submitted comments. 

For key retention in R1.2 of CIP-011, is this saying that where the key is stored needs to be behind a PSP? 

Jonathan Robbins, Seminole Electric Cooperative, Inc., 4, 2/3/2020

- 0 - 0

Anton Vu, Los Angeles Department of Water and Power, 6, 2/3/2020

- 0 - 0

N&ST does not believe the proposed terms will enhance general understanding of the risks associated with potential compromises of BCSI. In N&ST’s opinion, the NERC Glossary definition of BCSI (“Information about the BES Cyber System that could be used to gain unauthorized access or pose a security threat to the BES Cyber System.”) more than adequately defines the potential risks. Furthermore, in recent discussions with representatives from several Responsible Entities, it has become apparent to N&ST that there is NO good consensus on what it means to “use” BCSI. We believe the existing language in CIP-011-2, Requirement R1 Part 1.2 should be retained.

Nicholas Lauriat, Network and Security Technologies, 1, 2/3/2020

- 0 - 0

We agree with using the terms “obtain” and “use”. However, this will require the Responsible Entity document what the the terms “obtain” and “use” mean with respect to BCSI – we believe more explanation is needed within the requirement or guidelines.

 

Based on the CMEP BCSI practice guide. The practice guide provides very little additional information on what is meant by “obtain” and “use.” Without additional guidance evidencing this concept for audit purposes (that someone obtained BCSI but couldn’t use it) would be a significant challenge.

                                                                   

We disagree with the phrase, “by eliminating the ability” to obtain and use. This represents an unachievable threshold over and above the current “Procedure(s) for protecting and securely handling.”

Sandra Shaffer, Berkshire Hathaway - PacifiCorp, 6, 2/3/2020

- 0 - 0

ALAN ADAMSON, New York State Reliability Council, 10, 2/3/2020

- 0 - 0

BPA understands “obtain” to mean take possession of, and “use” to mean take an action on. “Obtain” is not much clearer than “gain access to” while “use” does add an element of clarity to the objective of what needs to be protected. “Use” implies that obtaining “unusable” (i.e., encrypted) information is a lesser risk.

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

- 0 - 0

Texas RE agrees that this will more accurately address the risk related to the potential compromise of BCSI versus the previous approach. This focus is on the BCSI (data) versus applicable systems that would contain BCSI. This also aligns with the CMEP Practice Guide:  ERO Enterprise CMEP Practice Guide BES Cyber System Information.

 

Texas RE does have a concern that entities could simply use the bare minimum controls.  For example, a registered entity could comply using encryption, but there is no established brightline criteria indicating what level of encryption is sufficient to meet the objective of this requirement.  This may result in inconsistent enforcement of this requirement across the regions.  If encryption is to be considered an acceptable means of prevent unauthorized access to BES Cyber System Information then Texas RE recommends that the SDT review NIST Special Publication 800-175B, Guideline for Using Cryptographic Standards in the Federal Government: Cryptographic Mechanisms, and incorporate guidance from the NIST publication into the CIP standard where appropriate and applicable.

 

Additionally, in the measures an example of evidence is ‘retention in the Physical Security Perimeter.’  Texas RE agrees that for BCSI in a physical form retention in a PSP is an adequate means of protection.  However, the PSP would not be considered adequate protection for electronic BCSI that is located on a server outside of the Entity’s ESP.

Rachel Coyne, Texas Reliability Entity, Inc., 10, 2/3/2020

- 0 - 0

Dominion Energy supports the work the SDT has done on develoing the current draft. Dominion energy suggests that the team focus on the approach taken in the current NERC CMEP Guidance document in addressing the issue and further supports EEIs comments.

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

- 0 - 0

Exelon supports EEI's comments on behalf of Exelon Segments 1, 3, 5, and 6.

Kinte Whitehead, Exelon, 3, 2/3/2020

- 0 - 0

Ameren agrees with and supports EEI comments.

David Jendras, Ameren - Ameren Services, 3, 2/3/2020

- 0 - 0

NCEMC supports the comments by Barry Lawson, National Rural Electric Cooperative Association and ACES

Kagen DelRio, On Behalf of: North Carolina Electric Membership Corporation - SERC - Segments 3, 4, 5

- 0 - 0

We do not agree with the modifications to Part 1.2 for the following reasons:

  • It requires methods to “prevent” unauthorized access.  We caution against using “100% words” in situations such as this because if ever a piece of encrypted information is cracked, the entity’s method did not 100% prevent it.  A technology breakthrough or suddenly discovered vulnerability in an encryption algorithm that enables cracking today’s encryption protocols makes the entire industry suddenly non-compliant. 

 

  • R1.2 goes on to say the process must prevent unauthorized access BY eliminating the ability to obtain and use BCSI.  A literal reading of this requirement says that entities must prevent unauthorized access by eliminating ALL ability for anyone to obtain and use BCSI.  We understand this phrasing is attempting to define “access”, but the way this is stated it says you must prevent unauthorized access by eliminating all access.  

 

  • Adding “disposal” to R1.2 is duplicative of R3.  That’s now required twice in two different requirements within the same standard, and we do not support including it here. We also question how “disposal” of BCSI is not inherently included in “storage, transit, and use” and why the additional qualifier is needed?

Southern Company, Segment(s) 1, 3, 5, 6, 12/13/2019

- 0 - 0

The language of “eliminating the ability to obtain the and use BES Cyber Information” sounds ambiguous.  Also, the term “use” that occurs twice within a sentence need more clarification.

Tho Tran, On Behalf of: Lee Maurer, Oncor Electric Delivery, 1; Lee Maurer, Oncor Electric Delivery, 1; Lee Maurer, Oncor Electric Delivery, 1

- 0 - 0

SDG&E supports EEI’s comments submitted on our behalf.

Bridget Silvia, Sempra - San Diego Gas and Electric, 3, 2/3/2020

- 0 - 0

ITC supports the response found in the NSRF Comment Form

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

- 0 - 0

Eversource Group, Segment(s) 3, 1, 4/12/2019

- 0 - 0

Agree with terms “obtain” and “use;” however, more explanation is needed within the requirement or guidelines. The drafting team has referred to the CMEP BCSI practice guide. We recommend defining “BCSI Access” in the NERC Glossary of Terms per the practice guide: “An instance or event during which a user obtains and uses BCSI. For access to occur, in this context, a user, authorized or unauthorized, must concurrently both obtain BCSI and possess the ability to use BCSI. An unauthorized individual who obtains encrypted BCSI but has no ability to use it within a meaningful timeframe should not be considered to have access.”

 

The draft R1 Part 1.2 Requirement could then be revised to “Method(s) to prevent unauthorized BCSI Access during BCSI storage, transit, and use.”

 

We disagree with the phrase, “by eliminating the ability” to obtain and use. This represents an unachievable threshold over and above the current “Procedure(s) for protecting and securely handling.”

 

We concur with MRO NSRF comments that disagree with the addition of “and disposal” to the end of the requirement. BCSI in BES Cyber Systems is already addressed in R3 Part 3.1., but Part 3.1 needs to reinstate the qualifying language in the Requirements “that contain BES Cyber System Information.” Deletion of this qualifying language is an expansion of scope to the current CIP-011-2 R2 requiring evidence of sanitization of assets not containing BCSI subject to this protection.

 

Although a logical inclusion as part of the lifecycle of BCSI, as applied in R1 Part 1.2, the Measures would need to address examples of acceptable evidence of disposal, such as shredding for paper. We do not see a practical method of evidencing the disposal of electronic BCSI, i.e. the day-to-day deletion of electronic files.

Kevin Salsbury, Berkshire Hathaway - NV Energy, 5, 2/3/2020

- 0 - 0

Please see comments submitted by Edison Electric Institute

Ayman Samaan, 2/3/2020

- 0 - 0

While we agree that “obtain” and “use” more accurately address the risk, we have concerns with the overall wording.  One of the below listed changes should be made to these modified Standards.

We recommend changing Part 1.2 from

<<Method(s) to prevent unauthorized access to BES Cyber System Information by eliminating the ability to obtain and use BES Cyber System Information during, including storage, transit, use, and disposal.>>

To

<<Method(s) to prevent the ability to obtain and use BES Cyber System Information through unauthorized access during, including storage, transit, use, and disposal.>>

because “eliminating” is an absolute which makes implementation and demonstrating Compliance too challenging.

David Rivera, New York Power Authority, 3, 2/3/2020

- 0 - 0

While we understand why “obtain and use” are included in Part 1.2, we fear that the way the requirement is written, the intent will be obscured.  For instance, the word “eliminating”, implies perfect execution.  This is unattainable and should be avoided in the requirement language.  While the changes to this part are a good start, we feel that they are too narrowly focused on cloud-service providers and add extra burden to existing information protection programs. 

We encourage the SDT to develop a thoughtful process across all of CIP-011. 

PPL NERC Registered Affiliates, Segment(s) 1, 3, 5, 6, 9/6/2018

- 0 - 0

Support MRO comments.

Wayne Guttormson, SaskPower, 1, 2/3/2020

- 0 - 0

The standards development team should support specific requirements providing appropriate levels of security for Cloud Service Providers and 3rd Party Access. Transferring the CIP-004 BCSI requirements to CIP-011 does not address the unique issues created by storing BCSI in repositories that are not controlled by registered entities. The standards development team should draft separate requirements.

Steve Toosevich, NiSource - Northern Indiana Public Service Co., 1, 2/3/2020

- 0 - 0

See Steven Toosevich's comments.  

Kathryn Tackett, NiSource - Northern Indiana Public Service Co., 5, 2/3/2020

- 0 - 0

CEHE recommends using the words “or” instead of “and” and proposes the following alternative: 

 “Method(s) to prevent unauthorized access to BES Cyber System Information by eliminating the ability to obtain or use BES Cyber System Information during storage, transit, use, and disposal.”

Protections to prevent access, like access control to the storage location, are separate and distinct from controls to prevent use, like encryption during transit. Entities may have systems with one but not the other, if the system is all in house and physically protected.  The proposed language would not be backward compatible.

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

- 0 - 0

EEI has concerns with defining risks regarding potential compromise of BCSI within the language of a Reliability Standard. EEI suggests that it may be simpler to address BCSI security concerns through the development of a definition for “Useable Access” within the NERC Glossary of Terms.  We also suggest the SDT consider using the language from the April 26, 2019, ERO Enterprise CMEP Practice Guide on BES Cyber System Information which appears to have the requisite clarity and could act as a clear definition for “Useable Access” (see below).  If the term is deemed to be unsuitable, the SDT could use the phrase “Access to the BCSI.…”

Useable Access: An instance or event during which a user obtains and uses BCSI.  For access to occur, in this context, a user, authorized or unauthorized, must concurrently both obtain BCSI and possess the ability to use BCSI.  An unauthorized individual who obtains encrypted BCSI but has no ability to use it within a meaningful timeframe should not be considered to have access.  Ref.: Page 2, Bullet 1:  https://www.nerc.com/pa/comp/guidance/CMEPPracticeGuidesDL/ERO%20Enterprise%20CMEP%20Practice%20Guide%20_%20BCSI%20-%20v0.2%20CLEAN.pdf

In consideration of access, CIP-004-6 already effectively addresses access controls for BCSI when stored by responsible entities at their facilities so protections would only need to be developed for a situation where third party cloud-based services are used.  Consequently, the above reference CMEP Practice Guide could effectively define access in a manner that addresses this issue. 

Within this alternative approach and once the definition for “Useable Access” is addressed, the changes needed to meet the intent of the SAR could be simply accomplished through the following changes to CIP-004-6:

4.1.1.        Electronic Access

4.1.2.        Unescorted physical access into a Physical Security Perimeter; and

4.1.3.       Useable Access to a BCSI Repository

The SDT should also consider restoring the language of CIP-004-6 R5.3, with the modification as shown below, or something similar, that achieves a similar result:

For termination actions, revoke the individual’s Useable Access to a BCSI Repository, whether physical or electronic (unless already revoked according to Requirement R5.1), by the end of the next calendar day following the effective date of the termination action.

With the proposed solution, the language within CIP-004-6, Part 5.3 could be largely retained while limiting the scope of any vendor’s “Useable Access.”  In such a situation, the vendor is simply a custodian to encrypted or otherwise masked data and does not have the ability to use it.  Additionally, vendors with “Useable Access” (i.e., both custody of data and ability to use BCSI) would continue to need provisional access granted by the responsible entity through their established access control process and procedures.

Lastly, EEI is concerned with the compliance issues in using the term “eliminate” as proposed in CIP-011-3 R1.2.  The word “eliminate” is ambiguous when considered within the context of demonstrating compliance.  It will be difficult to prove to an auditor that the responsible entity has eliminated all risk.  EEI suggests that the SDT modify the language and replace “eliminate” with “limit” or some similar language.

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

- 0 - 0

NYISO feels that “Obtain” and “use” are key distinctions providing clarity related to what is required to prevent unauthorized access. NYISO would also suggest that the following modification be made to the Requirements language:  

“Method(s) to prevent unauthorized access to BES Cyber System Information by restricting the ability to both obtain and use BES Cyber System Information during storage, transit, use, and disposal.”  In the case where BCSI is encrypted, information could still be obtained (physically or electronically) but would not be in a usable format.

Note – During the Q&A session on the 2019-02: BES Cyber System Information Access Management webinar (January 16, 2020), it appears that “access” equated to having the ability to “obtain and use.” Part 1.2 language seems to be focused on the prevention of unauthorized access by “restricting” the ability to “obtain and use,” NYISO recommends the SDT clarify this point within the Technical Rationale for Reliability Standard CIP-011-3.

Gregory Campoli, On Behalf of: New York Independent System Operator, , Segments 2

- 0 - 0

While we agree that “obtain” and “use” more accurately address the risk, we have concerns with the overall wording.

 

We recommend changing Part 1.2 from

<<Method(s) to prevent unauthorized access to BES Cyber System Information by eliminating the ability to obtain and use BES Cyber System Information during, including storage, transit, use, and disposal.>>

To

<<Method(s) to prevent the ability to obtain and use BES Cyber System Information through unauthorized access during, including storage, transit, use, and disposal.>>

because “eliminating” is an absolute which makes implementation and demonstrating Compliance too challenging.

RSC no NextEra, Segment(s) 10, 2, 4, 5, 7, 3, 1, 6, 2/3/2020

- 0 - 0

SNPD does not agree that this will more accurately address the risk related to the potential compromise of BCSI versus the previous approach and verbiage.  However, SNPD supports the reasoning behind the proposed change.

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

- 1 - 0

Alliant Energy agrees with NSRF and EEI’s comments.

Jenifer Holmes, On Behalf of: Alliant Energy Corporation Services, Inc. - MRO, RF - Segments 4

- 0 - 0

Jamie Monette, Allete - Minnesota Power, Inc., 1, 2/3/2020

- 0 - 0

See Steven Toosevich's comments. 

Dmitriy Bazylyuk, 2/3/2020

- 0 - 0

Yes – somewhat.  “Obtain” and “use” are key distinctions which help provide better clarity related to what is required to prevent unauthorized access. In addition, MISO suggests the following modification to the Requirements language:   

“Method(s) to prevent unauthorized access to BES Cyber System Information by [delete the word "eliminating"] restricting the ability to simultaneously obtain and use BES Cyber System Information during storage, transit, use, and disposal.”

Note – based on the Q&A session during the 2019-02: BES Cyber System Information Access Management webinar hosted on January 16, 2020, it appears that “access” equates to having the ability to “obtain and use.” 

As the intent of Part 1.2 is to prevent unauthorized access by “restricting” the ability to “obtain and use,” MISO recommends the SDT clarify this point in the Technical Rationale for Reliability Standard CIP-011-3.

Bobbi Welch, On Behalf of: Midcontinent ISO, Inc., , Segments 2

- 0 - 0

This is an improvement and provides clarity on the meaning of unauthorized access.

James Brown, On Behalf of: California ISO, WECC, Segments 2

- 0 - 0

PGE agrees with EEI’s comments

PGE Group 2, Segment(s) 1, 3, 6, 5, 2/3/2020

- 0 - 0

There appears to be a significant challenge with the proposed wording of Requirement Part 1.2, which appears to require entities to eliminate the ability to obtain and use BCSI even for authorized access holders.

Suggest the following replacement requirement text:

"Method(s) to prevent unauthorized access to BES Cyber System Information by eliminating the ability of unauthorized users to obtain and use BES Cyber System Information during storage, transit, use, and disposal."

            OR

"Method(s) to prevent unauthorized access to BES Cyber System Information by restricting the ability to obtain and use BES Cyber System Information during storage, transit, use, and disposal, to authorized access holders."

While this approach is better than previous approaches, there is still a need for security technology vendor service providers to have access and use of BCSI. The proposed update does nothing to allow MSSPs in a CIP program. Along with allowing Authorized users to both obtain and use, the EACMS split to EACS and EAMS is also required to allow MSSPs.

Jennie Wike, On Behalf of: Marc Donaldson, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Marc Donaldson, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Marc Donaldson, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; John Merrell, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; John Merrell, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; John Merrell, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Hien Ho, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Hien Ho, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Hien Ho, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Terry Gifford, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Terry Gifford, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Terry Gifford, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Ozan Ferrin, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Ozan Ferrin, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Ozan Ferrin, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6

- 0 - 0

Please see comments PGE Group 2

Angela Gaines, Portland General Electric Co., 1, 2/3/2020

- 0 - 0

However, see other Entities comments related to wording change suggestions

Dennis Sismaet, Northern California Power Agency, 6, 2/3/2020

- 0 - 0

Agree with terms “obtain” and “use;” however, more explanation is needed within the requirement or guidelines. The drafting team has referred to the CMEP BCSI practice guide. We recommend defining “BCSI Access” in the NERC Glossary of Terms per the practice guide: “An instance or event during which a user obtains and uses BCSI. For access to occur, in this context, a user, authorized or unauthorized, must concurrently both obtain BCSI and possess the ability to use BCSI. An unauthorized individual who obtains encrypted BCSI but has no ability to use it within a meaningful timeframe should not be considered to have access.”

The draft R1 Part 1.2 Requirement could then be revised to “Method(s) to prevent unauthorized BCSI Access during BCSI storage, transit, and use.”

We disagree with the phrase, “by eliminating the ability” to obtain and use. This represents an unachievable threshold over and above the current “Procedure(s) for protecting and securely handling.”

We concur with MRO NSRF comments that disagree with the addition of “and disposal” to the end of the requirement. BCSI in BES Cyber Systems is already addressed in R3 Part 3.1., but Part 3.1 needs to reinstate the qualifying language in the Requirements “that contain BES Cyber System Information.” Deletion of this qualifying language is an expansion of scope to the current CIP-011-2 R2 requiring evidence of sanitization of assets not containing BCSI subject to this protection.

Although a logical inclusion as part of the lifecycle of BCSI, as applied in R1 Part 1.2, the Measures would need to address examples of acceptable evidence of disposal, such as shredding for paper. We do not see a practical method of evidencing the disposal of electronic BCSI, i.e. the day-to-day deletion of electronic files.

Terry Harbour, Berkshire Hathaway Energy - MidAmerican Energy Co., 1, 2/3/2020

- 0 - 0

ERCOT believes this is an improvement and provides clarity on the meaning of unauthorized access.

Brandon Gleason, Electric Reliability Council of Texas, Inc., 2, 2/3/2020

- 0 - 0

Westar and Kansas City Power & Light Company, endorse Edison Electric Institute's (EEI) comments.

Westar-KCPL, Segment(s) 1, 3, 5, 6, 12/18/2018

- 0 - 0

PG&E agrees with the inclusion of the “obtain” and “use”.

PG&E recommends that examples of what is “obtain” and “use” be included in the Technical Rationale document to help better understand the intended meaning and to avoid potential future interpretation differences or ambiguities.

PG&E All Segments, Segment(s) 1, 3, 5, 1/29/2020

- 0 - 0

Allan Long, Memphis Light, Gas and Water Division, 1, 2/3/2020

- 0 - 0

Agree with terms “obtain” and “use;” however, more explanation is needed within the requirement or guidelines. The drafting team has referred to the CMEP BCSI practice guide. We recommend defining “BCSI Access” in the NERC Glossary of Terms per the practice guide: “An instance or event during which a user obtains and uses BCSI. For access to occur, in this context, a user, authorized or unauthorized, must concurrently both obtain BCSI and possess the ability to use BCSI. An unauthorized individual who obtains encrypted BCSI but has no ability to use it within a meaningful timeframe should not be considered to have access.”

 

The draft R1 Part 1.2 Requirement could then be revised to “Method(s) to prevent unauthorized BCSI Access during BCSI storage, transit, and use.”

 

We disagree with the phrase, “by eliminating the ability” to obtain and use. This represents an unachievable threshold over and above the current “Procedure(s) for protecting and securely handling.”

 

We concur with MRO NSRF comments that disagree with the addition of “and disposal” to the end of the requirement. BCSI in BES Cyber Systems is already addressed in R3 Part 3.1., but Part 3.1 needs to reinstate the qualifying language in the Requirements “that contain BES Cyber System Information.” Deletion of this qualifying language is an expansion of scope to the current CIP-011-2 R2 requiring evidence of sanitization of assets not containing BCSI subject to this protection.

 

Although a logical inclusion as part of the lifecycle of BCSI, as applied in R1 Part 1.2, the Measures would need to address examples of acceptable evidence of disposal, such as shredding for paper. We do not see a practical method of evidencing the disposal of electronic BCSI, i.e. the day-to-day deletion of electronic files.

Darnez Gresham, Berkshire Hathaway Energy - MidAmerican Energy Co., 3, 2/3/2020

- 0 - 0

The previous Part 1.2 approach gave Responsible Entities flexibility to accurately address the risk related to the potential compromise of BCSI. The new Part 1.2 approach does not appear to give Responsible Entities thae same flexibility, especially if third-party solutions (e.g., cloud services) are not utilized. If the purpose of the new Part 1.2 approach is to address the risk associated with the use of a third-party solution (e.g. cloud services), the Part 1.2 requirement language should be made more clear than is currently proposed. IPC requests that the SDT provide additional rationale information related to “the ability to obtain and use BES Cyber System Information” language in the proposed requirement as it is unclear what is intended by the phrase “obtain and use” in the requirement. IPC believes the Part 1.2 requirement language should focus more on a Responsible Entity ensuring they have appropriate measures in place within their BES Cyber System Information (BCSI) Protection Program to protect BCSI rather than requiring entities to encrypt their data in transit, storage, and use.

Laura Nelson, IDACORP - Idaho Power Company, 1, 2/3/2020

- 0 - 0

As long as both terms are defined properly, this methodology will help improve the storage of BCSI requirement.

Colleen Campbell, On Behalf of: AES - Indianapolis Power and Light Co., , Segments 3

- 0 - 0

Comments: 

The inclusion of the terms “obtain and use” help to more accurately identify the objective of the access protections that need to be implemented. However, inclusion of those terms does not accurately address the risk related to the potential compromise of BCSI. 

Moreover, the term “eliminating” is an absolute, so implementation and compliance would be challenging to demonstrate.

Recommendation: change the language to “methods to prevent the ability to obtain and use BCSI information through unauthorized access including storage, transit, use and disposal.” 

Michael Puscas, On Behalf of: ISO New England, Inc., , Segments 2

- 0 - 0

BC Hydro requests more clarity as to what is the extent of the application of the term “elimination” that is now included in the requirement. Please add clarity within the language of standard. Example: Is an encryption key sufficient to “eliminate” even though this is potentially hackable?

BC Hydro would also request additional clarity on what the “ability to use BCSI” means.

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

- 1 - 0

However, see other Entities comments related to wording change suggestions.

Marty Hostler, Northern California Power Agency, 5, 2/3/2020

- 0 - 0

Hot Answers

Constantin Chitescu, Ontario Power Generation Inc., 5, 2/3/2020

- 0 - 0

Bradley Collard, 2/3/2020

- 0 - 0

Other Answers

Kevin Conway, Public Utility District No. 1 of Pend Oreille County, 1, 12/23/2019

- 0 - 0

Calvin Wheatley, On Behalf of: Wabash Valley Power Association, SERC, RF, Segments 1, 3

- 0 - 0

No comments

Susan Sosbe, Wabash Valley Power Association, 3, 1/22/2020

- 0 - 0

Comments: Yes, it would be good to have BCSI in the “Applicability” column.  We feel BCSI repositories need to have a significant explanation in the “Guidelines and Technical Basis” section as stated in question 1. 

William Hutchison, On Behalf of: Southern Illinois Power Cooperative, , Segments 1

- 0 - 0

Duke Energy generally agrees that adding BCSI in the “Applicability” column provides further clarity on the focus of the requirements. However, Duke Energy suggests using the High and Medium designations carried with the applicability for consistency throughout the rest of the standards. Also, including the term “system information” in the applicability column and BES CSI in the requirement column may introduce scope ambiguity, particularly, for example, PCA is included in the applicability, but is not included in the NERC Glossary term BES CSI.

Duke Energy, Segment(s) 1, 5, 6, 3, 12/13/2019

- 0 - 0

DTE Energy - DTE Electric, Segment(s) 5, 4, 3, 2/27/2017

- 0 - 0

Due to strong disagreements with 1.2, 1.4 and R2, we disagree here.

 

Scott Miller, On Behalf of: Roger Brand, MEAG Power, 1,3; Roger Brand, MEAG Power, 1,3; Roger Brand, MEAG Power, 1,3; David Weekley, MEAG Power, 1,3; David Weekley, MEAG Power, 1,3; David Weekley, MEAG Power, 1,3

- 0 - 0

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

- 0 - 0

Public Utility District No. 1 of Chelan County, Segment(s) 3, 1, 1/27/2020

- 0 - 0

Karl Blaszkowski, CMS Energy - Consumers Energy Company, 3, 1/28/2020

- 0 - 0

Donald Lynd, CMS Energy - Consumers Energy Company, 1, 1/28/2020

- 0 - 0

Joe Tarantino, On Behalf of: Kevin Smith, Balancing Authority of Northern California, 1; Kevin Smith, Balancing Authority of Northern California, 1; Kevin Smith, Balancing Authority of Northern California, 1; Jamie Cutlip, Sacramento Municipal Utility District, 1,3,4,5,6; Jamie Cutlip, Sacramento Municipal Utility District, 1,3,4,5,6; Jamie Cutlip, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Beth Tincher, Sacramento Municipal Utility District, 1,3,4,5,6; Beth Tincher, Sacramento Municipal Utility District, 1,3,4,5,6; Beth Tincher, Sacramento Municipal Utility District, 1,3,4,5,6; Arthur Starkovich, Sacramento Municipal Utility District, 1,3,4,5,6; Arthur Starkovich, Sacramento Municipal Utility District, 1,3,4,5,6; Arthur Starkovich, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6

- 0 - 0

We can agree with identifying BCSI in CIP-011-3 R1.1 and then using BCSI only in later applicability tables, but cannot support the removal of Medium Impact BES Cyber Systems with ERC.

MRO NSRF, Segment(s) 3, 4, 5, 6, 1, 2, 1/29/2020

- 0 - 0

FE Voter, Segment(s) 1, 3, 5, 6, 4, 10/31/2019

- 0 - 0

Xcel Energy support the comments submitted by EEI.

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

- 0 - 0

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

- 0 - 0

Support the MRO NSRF comments

Jeremy Voll, Basin Electric Power Cooperative, 3, 1/30/2020

- 0 - 0

Anthony Jablonski, ReliabilityFirst , 10, 1/30/2020

- 0 - 0

Agree with proposing to have BCSI in the “Applicability” column and it is much clearer than the

current version since the CIP-011 requirements actually apply to BCSI rather than BCS and their

assocated cyber assets.

Bruce Reimer, Manitoba Hydro , 1, 1/30/2020

- 0 - 0

Although Seattle finds the proposed approach intriguing, it also finds unnecessarily  confusing the inconsistent application of this approach among R1.1-R1.3 and R1.4-1.5, R2, and R3. Better would be to revise the entire Standard one way or the other.

 

Seattle also believes that an objective-based, risk-focused approach would eliminate the need to add “BCSI” to the Applicability column at all. It would be up the entity to specify its own controls in its plan and whether they are controls for BCSI about specific impact ratings of BCS, BCSI storage locations, third party BCSI storage providers, etc.

Matthew Nutsch, On Behalf of: Seattle City Light, WECC, Segments 1, 3, 4, 5, 6

- 0 - 0

While having BCSI in the applicability column provides clarity, it unfortunately expands the scope of the requirements beyond what they are today. If the requirements are kept focused on designated storage locations for BCSI, it eliminates confusion with BCSI that may reside in BCS, EACMS and PACS. We understand that this is a challenging part of the project, but we are concerned that the applicability and associated requirements as currently drafted will create confusion, redundancy and expanded scope. Other than reverting back to the original structure, a possible solution could be to add exclusions to the applicability to exclude High and Medium Impact BCS and their associated EACMS and PACS.

Kjersti Drott, Tri-State G and T Association, Inc., 1, 1/31/2020

- 0 - 0

That is fine as long as the Applicability section for R1.1 is worded correctly.  We do not support introducing "System information pertaining to" in the applicability section for R1.1.  This creates some ambiguity.  We believe that the applicability be limited to BCSI.

Payam Farahbakhsh, Hydro One Networks, Inc., 1, 1/31/2020

- 0 - 0

What was the intent of stating “BCSI as identified in R1.1”? Is the SDT inferring that other BCSI exists that was not identified in R1.1?

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

- 0 - 0

Black Hills does not think the current definition of BCSI provided in the Glossary is clear enough to allow for BCSI to be listed as an Applicable System. We think it would make more sense to leave applicability listed as High and Medium BCS… and state in the requirement “For BCSI, perform action “X,”” as the current CIP-004 R4.1 is modeled, for example.

Maryanne Darling-Reich, On Behalf of: Black Hills Corporation - MRO, WECC - Segments 1, 3, 5, 6

- 0 - 0

AEP is in agreement that there is an overall increase in clarity on the focus of the standard. However, we were unable to find a justification for the change within the Technical Rationale and have concerns regarding the need for these modifications.

 

Kent Feliks, AEP, 3, 1/31/2020

- 0 - 0

Russel Mountjoy, Midwest Reliability Organization, 10, 1/31/2020

- 0 - 0

AECI supports comments filed by NRECA

AECI, Segment(s) 1, 3, 6, 5, 5/31/2019

- 0 - 0

While NRECA understands what the SDT was attempting to accomplish and does not disagree with the intended clarification, the replacement of “Applicable Systems” with “Applicability” is problematic as such term is already utilized in Section 4 of the CIP-011 standard, and, there, it is utilized to denote whether a registered function has responsibility under the Standard.  Utilization of the same term, but with a different scope within body of CIP-011 will result in confusion and ambiguity regarding the overall applicability of CIP-011.  Further, this change results in CIP-011 being different from the remaining CIP reliability standards relative to the CIP reliability standards overall approach to identification of asset scope.  Finally, NRECA notes that it is also concerned that the modifications to the contents of the “Applicability” column conflict with the definition of BCSI set forth in the Glossary of Terms Used in NERC Reliability Standards.  Specifically, the revisions limit the “applicability” to “system information pertaining to…” while BCSI is defined as

Information about the BES Cyber System that could be used to gain unauthorized access or pose a security threat to the BES Cyber System. BES Cyber System Information does not include individual pieces of information that by themselves do not pose a threat or could not be used to allow unauthorized access to BES Cyber Systems, such as, but not limited to, device names, individual IP addresses without context, ESP names, or policy statements. Examples of BES Cyber System Information may include, but are not limited to, security procedures or security information about BES Cyber Systems, Physical Access Control Systems, and Electronic Access Control or Monitoring Systems that is not publicly available and could be used to allow unauthorized access or unauthorized distribution; collections of network addresses; and network topology of the BES Cyber System.

There is information that is not “system information pertaining to” a particular asset that could be used to “gain unauthorized access or pose a security threat to the BES Cyber System.”  Further, the definition makes explicit reference to “security procedures or security information;” neither of which is confined to “system information” and both of which may be comprised of information that is not “system information.” These potential conflicts and contradictions between the standard and the Glossary of Terms Used in NERC Reliability Standards could result in increased ambiguity and confusion. 

Finally, NRECA notes that requirement applicability is already complicated and in need of simplification.  This modification and addition of the same term within the standard and requirement only serves to increase the complexity and the likelihood for ambiguity and confusion.  As well, it must be noted that this change presents a substantial challenge to audit as the implication is that all system information must be evaluated to demonstrate that it was evaluated for identification as BCSI and, further, relative to compliance monitoring activities, all such system information must be available to sample to determine whether the process identified it as BCSI or not.  NRECA does not agree that this provides better clarity on the focus of the requirements and, therefore, does not support this change.

Barry Lawson, National Rural Electric Cooperative Association, 4, 2/3/2020

- 0 - 0

We disagree with changing the column heading and adding “system information pertaining to” for the following reasons.  First, it is inconsistent with other standards and it is confusing to have “applicability” here and also in section A.4 where it lists “Applicability” of functional entities and facilities.  Secondly, the definition of BCSI includes information about low impact systems.  Therefore, we will be identifying all BCSI in our organization as required by R1 Part 1.1.  However, the applicable systems column defines the scope of systems to which the requirement row applies.  By referring to “BES Cyber System Information as identified in Requirement R1 Part 1.1” for the applicability of subsequent parts, the scope of systems to which the requirements applied has been increased, since we will have identified BCSI pertaining to low impact systems as well.  Third, CIP-011 has always been about BCSI, regardless of where it is stored, so this does not clarify anything further.

Andy Fuhrman, On Behalf of: Theresa Allard, Minnkota Power Cooperative Inc., 1; Theresa Allard, Minnkota Power Cooperative Inc., 1; Theresa Allard, Minnkota Power Cooperative Inc., 1

- 0 - 0

While GSOC understands what the SDT was attempting to accomplish and does not disagree with the intended clarification, the replacement of “Applicable Systems” with “Applicability” is problematic as such term is already utilized in Section 4 of the CIP-011 standard, and, there, is utilized to denote whether or not a particular registered function has responsibility under the Standard.  Utilization of the same term, but with a different scope within body of CIP-011 will result in confusion and ambiguity regarding the overall applicability of CIP-011.  Further, this change results in CIP-011 being different from the remaining CIP reliability standards relative to the CIP reliability standards overall approach to identification of asset scope.  Finally, GSOC notes that it is also concerned that the modifications to the contents of the “Applicability” column conflict with the definition of BCSI set forth in the Glossary of Terms Used in NERC Reliability Standards.  Specifically, the revisions limit the “applicability” to “system information pertaining to…” while BCSI is defined as

Information about the BES Cyber System that could be used to gain unauthorized access or pose a security threat to the BES Cyber System. BES Cyber System Information does not include individual pieces of information that by themselves do not pose a threat or could not be used to allow unauthorized access to BES Cyber Systems, such as, but not limited to, device names, individual IP addresses without context, ESP names, or policy statements. Examples of BES Cyber System Information may include, but are not limited to, security procedures or security information about BES Cyber Systems, Physical Access Control Systems, and Electronic Access Control or Monitoring Systems that is not publicly available and could be used to allow unauthorized access or unauthorized distribution; collections of network addresses; and network topology of the BES Cyber System.

There is information that is not “system information pertaining to” a particular asset that could be used to “gain unauthorized access or pose a security threat to the BES Cyber System.”  Further, the definition makes explicit reference to “security procedures or security information;” neither of which is confined to “system information” and both of which may be comprised of information that is not “system information.” These potential conflicts and contradictions between the standard and the Glossary of Terms Used in NERC Reliability Standards could result in increased ambiguity and confusion. 

Finally, GSOC notes that requirement applicability is already complicated and in need of simplification.  This modification and addition of the same term within the standard and requirement only serves to increase the complexity and the likelihood for ambiguity and confusion.  As well, it must be noted that this change presents a substantial challenge to audit as the implication is that all system information must be evaluated to demonstrate that it was evaluated for identification as BCSI and, further, relative to compliance monitoring activities, all such system information must be available to sample in order to determine whether the process identified it as BCSI or not.  For these reasons, GSOC does not agree that this provides better clarity on the focus of the requirements and, therefore, cannot support this change.

Andrea Barclay, Georgia System Operations Corporation, 4, 2/3/2020

- 0 - 0

SMEC agrees with comments submitted by NRECA.

Lana Smith, San Miguel Electric Cooperative, Inc., 5, 2/3/2020

- 0 - 0

Yes, it would be good to have BCSI in the “Applicability” column.  We feel BCSI repositories need to have a significant explanation in the “Guidelines and Technical Basis” section as stated in question 1.  

ACES Standard Collaborations, Segment(s) 1, 3, 2/3/2020

- 0 - 0

Dwayne Parker, 2/3/2020

- 0 - 0

No comment.

Leonard Kula, Independent Electricity System Operator, 2, 2/3/2020

- 0 - 0

Santee Cooper, Segment(s) 1, 3, 5, 6, 2/3/2020

- 0 - 0

 

R1.2 -  No

R1.3 – Move to R1.5 - these specific requirements should be placed in the appropriate standards CIP-004 and CIP-013.

sean erickson, Western Area Power Administration, 1, 2/3/2020

- 0 - 0

Gerry Adamski, Cogentrix Energy Power Management, LLC, 5, 2/3/2020

- 0 - 0

AZPS does not agree that the proposed revisions to the “Applicability” column provides better clarity on the focus of the requirements.  AZPS requests revising the applicability column to read as follows: “System information pertaining to (but not including the BES Cyber System (BCS) which may contain BCSI):…” or similar language to to clearly establish the focus on BCSI. 

Vivian Moser, 2/3/2020

- 0 - 0

The intention is good, and provides greater focus, however, the current proposed requirements still have some ambiguity due to the applicability of Requirement R1 including the BES Cyber System and associated Cyber Asset construct as the target.    

LaTroy Brumfield, American Transmission Company, LLC, 1, 2/3/2020

- 0 - 0

Truong Le, On Behalf of: Chris Gowder, Florida Municipal Power Agency, 3,4,5,6; Chris Gowder, Florida Municipal Power Agency, 3,4,5,6; Chris Gowder, Florida Municipal Power Agency, 3,4,5,6; Carol Chinn, Florida Municipal Power Agency, 3,4,5,6; Carol Chinn, Florida Municipal Power Agency, 3,4,5,6; Carol Chinn, Florida Municipal Power Agency, 3,4,5,6; Dale Ray, Florida Municipal Power Agency, 3,4,5,6; Dale Ray, Florida Municipal Power Agency, 3,4,5,6; Dale Ray, Florida Municipal Power Agency, 3,4,5,6; Richard Montgomery, Florida Municipal Power Agency, 3,4,5,6; Richard Montgomery, Florida Municipal Power Agency, 3,4,5,6; Richard Montgomery, Florida Municipal Power Agency, 3,4,5,6; David Owens, Gainesville Regional Utilities, 1,3,5; David Owens, Gainesville Regional Utilities, 1,3,5; David Owens, Gainesville Regional Utilities, 1,3,5

- 0 - 0

While having BCSI in the applicability column provides clarity, it unfortunately expands the scope of the requirements beyond what they are today. If the requirements are kept focused on designated storage locations for BCSI, it eliminates confusion with BCSI that may reside in BCS, EACMS and PACS. We understand that this is a challenging part of the project, but we are concerned that the applicability and associated requirements as currently drafted will create confusion, redundancy and expanded scope. Other than reverting back to the original structure, a possible solution could be to add exclusions to the applicability to exclude High and Medium Impact BCS and their associated EACMS and PACS.

Janelle Marriott Gill, Tri-State G and T Association, Inc., 3, 2/3/2020

- 0 - 0

See NRECA submitted comments. 

Jonathan Robbins, Seminole Electric Cooperative, Inc., 4, 2/3/2020

- 0 - 0

Neither agree nor disagree

Anton Vu, Los Angeles Department of Water and Power, 6, 2/3/2020

- 0 - 0

N&ST suggests deleting the word, “System,” thereby changing, “System information pertaining,…” to “Information pertaining,…”

Nicholas Lauriat, Network and Security Technologies, 1, 2/3/2020

- 0 - 0

 

We disagree with any and all Applicability that does not include the qualifying language “with ERC” for Medium Impact BES Cyber Systems except for the initial 1.1. The proposed language does not provide more clarity and needs to be more specific, not referencing another part. We recommend going back to ‘Applicable Systems’.

 

Recommendation: All parts of R1 needs to go back to “Applicable Systems”, The “Applicability” for R2, is acceptable.  Add clarity to the R2 Applicability with “BES Cyber System Information stored in Vendor managed electronic BCSI Repositories, and pertaining to:  (Applicable Systems)“ R3 needs to stay, ‘Applicable Systems’.

Sandra Shaffer, Berkshire Hathaway - PacifiCorp, 6, 2/3/2020

- 0 - 0

ALAN ADAMSON, New York State Reliability Council, 10, 2/3/2020

- 0 - 0

BPA finds the proposed language is a significant change, and entities (and possibly auditors) do not have experience in applying this requirement to information. This may cause some confusion. CIP-011 is an information protection standard and it is sensible to put such a requirement here. Referring to the CIA model of Confidentiality, Integrity, and Availability, cyber security methodology often differentiates between protecting systems functionality/availability, vs. data. It is sometimes desirable to share data while still protecting the system from unauthorized use. If the SDT’s intent is to address distinct protections for data that may be processed, stored, or transmitted by the system separately from configuration information about the system itself (i.e., versions, settings, and runtime parameters), the definition of “Cyber Assets” (NERC Glossary pg. 10) should be examined to further clarify which and to what extent “data in those devices” is subject to which requirement.

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

- 0 - 0

Rachel Coyne, Texas Reliability Entity, Inc., 10, 2/3/2020

- 0 - 0

Dominion Energy supports the work the SDT has done on develoing the current draft. Dominion energy suggests that the team focus on the approach taken in the current NERC CMEP Guidance document in addressing the issue and further supports EEIs comments.

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

- 0 - 0

Exelon supports EEI's comments on behalf of Exelon Segments 1, 3, 5, and 6.

Kinte Whitehead, Exelon, 3, 2/3/2020

- 0 - 0

Ameren agrees with and supports EEI comments.

David Jendras, Ameren - Ameren Services, 3, 2/3/2020

- 0 - 0

NCEMC supports the comments by Barry Lawson, National Rural Electric Cooperative Association and ACES

Kagen DelRio, On Behalf of: North Carolina Electric Membership Corporation - SERC - Segments 3, 4, 5

- 0 - 0

We agree it clarifies the focus is on protecting the information, however we disagree that is the right focus for this type of standard.  With the focus on BCSI comes the issue that the requirements are now impossible to measure on every piece of BCSI everywhere.  It is only measurable at BCSI storage locations or repositories. See answer to Question 2 for additional explanation. 

Southern Company, Segment(s) 1, 3, 5, 6, 12/13/2019

- 0 - 0

While providing better clarity it may expands the scope of requirements beyond what are in place today.

Tho Tran, On Behalf of: Lee Maurer, Oncor Electric Delivery, 1; Lee Maurer, Oncor Electric Delivery, 1; Lee Maurer, Oncor Electric Delivery, 1

- 0 - 0

SDG&E supports EEI’s comments submitted on our behalf.

Additionally, SDG&E would like to comment on CIP-011-3 requirement’s proposed inclusion of all Medium-Impact BCS, regardless of ERC.  The current CIP-004-6 R4.4 requirement specifies applicability for only High Impact BCS and Medium Impact BCS with ERC. The new CIP 011-3 brings all BCSI in scope regardless of ERC in Medium-Impact Sites. This change is significant and overburdensome to sites that don’t currently fall into this category of BCSI.

Bridget Silvia, Sempra - San Diego Gas and Electric, 3, 2/3/2020

- 0 - 0

ITC supports the response found in the NSRF Comment Form

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

- 0 - 0

Eversource Group, Segment(s) 3, 1, 4/12/2019

- 0 - 0

We disagree with any and all Applicability that does not include the qualifying language “with ERC” for Medium Impact BES Cyber Systems except for the initial 1.1. The proposed language does not provide more clarity and needs to be more specific, not referencing another part. We recommend going back to ‘Applicable Systems’.

 

Recommendation: All parts of R1 needs to go back to “Applicable Systems”, The “Applicability” for R2, is acceptable.  Add clarity to the R2 Applicability with “BES Cyber System Information stored in Vendor managed electronic BCSI Repositories, and pertaining to:  (Applicable Systems)“ R3 needs to stay, ‘Applicable Systems’.

Kevin Salsbury, Berkshire Hathaway - NV Energy, 5, 2/3/2020

- 0 - 0

Please see comments submitted by Edison Electric Institute

Ayman Samaan, 2/3/2020

- 0 - 0

No comments

David Rivera, New York Power Authority, 3, 2/3/2020

- 0 - 0

While we understand the reasoning behind the change, we feel that this change adds confusion and inconsistencies between CIP-011 and the rest of the CIP Standards.   

PPL NERC Registered Affiliates, Segment(s) 1, 3, 5, 6, 9/6/2018

- 0 - 0

Support MRO comments.

Wayne Guttormson, SaskPower, 1, 2/3/2020

- 0 - 0

Please provide more clarity on the phrase "System information pertaining to".  This needs to be well defined and understood.  There may be many systems that are associated with systems that may or may not house BCSI. 

Steve Toosevich, NiSource - Northern Indiana Public Service Co., 1, 2/3/2020

- 0 - 0

See Steven Toosevich's comments.  

Kathryn Tackett, NiSource - Northern Indiana Public Service Co., 5, 2/3/2020

- 0 - 0

CEHE supports the comments as submitted by the Edison Electric Institute.

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

- 0 - 0

EEI supports adding BSCI in the Applicability Column of CIP-011-3.  However, there are concerns with expanding the applicability to PCAs and Medium Impact BES Cyber Security Systems. 

First, in evaluating the proposed revision against the approved SAR, we are unable to find language to support the proposed revision.  Second, the SDT should provide support that this modification will alleviate a reliability gap.  Specifically, we ask the SDT to provide information regarding the reliability gap the proposed modifications are intended to address.  Alternatively, the SDT could study the issue and develop a white paper, to identify, justify and explain the gap that they believe exists and, if necessary, revise the SAR. 

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

- 0 - 0

NYISO understands the intent of the change.  However, we are concerned that this would create an inconsistency in format with the other current CIP standards. NYISO would propose keeping the original “Applicable Systems” title and adding language such as “System Information pertaining to:” at the head (or similar) of each applicable row in requirements R1 and R2.

Gregory Campoli, On Behalf of: New York Independent System Operator, , Segments 2

- 0 - 0

RSC no NextEra, Segment(s) 10, 2, 4, 5, 7, 3, 1, 6, 2/3/2020

- 0 - 0

Yes.  However, consistency is important when defining and using terms.  Please pick a single descriptor and use it consistently throughout. e.g. BCSI vs BES Cyber System Information.

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

- 1 - 0

Alliant Energy agrees with NSRF and EEI’s comments.

Jenifer Holmes, On Behalf of: Alliant Energy Corporation Services, Inc. - MRO, RF - Segments 4

- 0 - 0

Jamie Monette, Allete - Minnesota Power, Inc., 1, 2/3/2020

- 0 - 0

See Steven Toosevich's comments. 

Dmitriy Bazylyuk, 2/3/2020

- 0 - 0

MISO supports the proposed change as long as the change is coordinated with Project 2016-02 so there is consistency across all CIP standards.

Bobbi Welch, On Behalf of: Midcontinent ISO, Inc., , Segments 2

- 0 - 0

We agree with the approach. Retitling the column to “Applicability” will be beneficial for all Standards and Requirements to allow for more flexibility. This aligns well with the work of the Project 2016-02 Standard Drafting Team that is also introducing new applicability. There may be future instances where the applicability cannot be limited down to a system.

James Brown, On Behalf of: California ISO, WECC, Segments 2

- 0 - 0

PGE agrees with EEI’s comments

PGE Group 2, Segment(s) 1, 3, 6, 5, 2/3/2020

- 0 - 0

Jennie Wike, On Behalf of: Marc Donaldson, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Marc Donaldson, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Marc Donaldson, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; John Merrell, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; John Merrell, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; John Merrell, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Hien Ho, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Hien Ho, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Hien Ho, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Terry Gifford, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Terry Gifford, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Terry Gifford, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Ozan Ferrin, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Ozan Ferrin, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6; Ozan Ferrin, Tacoma Public Utilities (Tacoma, WA), 1,3,4,5,6

- 0 - 0

Please see comments PGE Group 2

Angela Gaines, Portland General Electric Co., 1, 2/3/2020

- 0 - 0

We do agree.  But does that mean NERC/FERC will consider the applicability section?  They don't consider the applicability section related to CIP-002 IRC 2.11 they and FERC claim that non-BES generation is to be considered when performing a nRP evaluation of a GOP Control Center.  The Applicability Section says "All BES Facilities". 

  • And BES Means BES not non-BES

  • and Facilities mean BES equipment not non-BES equipment

  • and GOP's don't have GOP functional obligations for non-BES generation. 

  • Non-GOPs are doing just fine not providing GOP functional obligation services to non-BES generation and so are GOP.  We reserve our GOP services for Facilities nor non-BES assets. 

  • According to NERC's March 1, 2019 Standards Process Manual Appendix 3A page 6 last paragraph "The only mandatory and enforceable components of a Reliability Standrd are the (1) Applicability, (2) Requirements, and (3) effective dates.

    What good is the Applicability Section if NERC/FERC are going to ignore it?

Dennis Sismaet, Northern California Power Agency, 6, 2/3/2020

- 0 - 0

We disagree with any and all Applicability that does not include the qualifying language “with ERC” for Medium Impact BES Cyber Systems, except for R1 Part 1.1, if restricted to identifying BCSI, and the identification of BCSI storage locations, or Repositories, is broken out into a separate part (with Applicability to include “with ERC”) per Q1 response. The proposed language does not provide more clarity and needs to be more specific, not referencing another part. We recommend going back to “Applicable Systems.”

Recommendation: All parts of R1 need to go back to “Applicable Systems.” The “Applicability” for R2, is acceptable.  Add clarity to the R2 Applicability with “BES Cyber System Information stored in Vendor managed electronic BCSI Repositories, and pertaining to: (Applicable Systems).” R3 needs to stay “Applicable Systems.”

Terry Harbour, Berkshire Hathaway Energy - MidAmerican Energy Co., 1, 2/3/2020

- 0 - 0

ERCOT agrees with this approach.  Retitling the column to “Applicability” will be beneficial for all Standards and Requirements, and allow for more flexibility.  This revision aligns well with the work of the Project 2016-02 Standard Drafting Team that is also introducing new applicability.  There may be future instances where the applicability cannot be limited down to a system.

Brandon Gleason, Electric Reliability Council of Texas, Inc., 2, 2/3/2020

- 0 - 0

Westar and Kansas City Power & Light Company, endorse Edison Electric Institute's (EEI) comments.

Westar-KCPL, Segment(s) 1, 3, 5, 6, 12/18/2018

- 0 - 0

PG&E agrees with the Applicability change to “System Information pertaining to” is appropriate and provides clarity on what is to be protected. 

PG&E has concerns about the addition of PCA to the “System Information” to be protected.  The concern is the additional effort to identify and protect this information and the potential benefit of those additional protections.  PG&AE is requesting the SDT articulate the reason for the proposed addition of PCA since there is no information in the Technical Rationale document to warrant its addition.

PG&E All Segments, Segment(s) 1, 3, 5, 1/29/2020

- 0 - 0

Allan Long, Memphis Light, Gas and Water Division, 1, 2/3/2020

- 0 - 0

We disagree with any and all Applicability that does not include the qualifying language “with ERC” for Medium Impact BES Cyber Systems, except for R1 Part 1.1, if restricted to identifying BCSI, and the identification of BCSI storage locations, or Repositories, is broken out into a separate part (with Applicability to include “with ERC”) per Q1 response. The proposed language does not provide more clarity and needs to be more specific, not referencing another part. We recommend going back to “Applicable Systems.”

 

Recommendation: All parts of R1 need to go back to “Applicable Systems.” The “Applicability” for R2, is acceptable.  Add clarity to the R2 Applicability with “BES Cyber System Information stored in Vendor managed electronic BCSI Repositories, and pertaining to: (Applicable Systems).” R3 needs to stay “Applicable Systems.”

Darnez Gresham, Berkshire Hathaway Energy - MidAmerican Energy Co., 3, 2/3/2020

- 0 - 0

IPC does not agree with the change from “Applicable Systems” (High Impact BES Cyber Systems and their associated:  EACMS and PACS, etc.) to “Applicability” (BES Cyber System Information as identified in Requirement R1 Part 1.1) nor any reference other than an “Applicable System” reference in the “Applicable Systems” column. IPC believes the “Applicable Systems” language and approach should remain consistent across all CIP Standards. IPC does not agree that this change provides better clarity on the focus of the requirements; rather, this changes introduces and creates ambiguity and inconsistencies across the CIP Standards.

Laura Nelson, IDACORP - Idaho Power Company, 1, 2/3/2020

- 0 - 0

Because the definition of BCSI is left for the most part up to the entity this could lead to confusion during an audit if the auditor has a different interpretation for BCSI.

Colleen Campbell, On Behalf of: AES - Indianapolis Power and Light Co., , Segments 3

- 0 - 0

Comments: 

Specification of information as an undefined category (i.e. “system information”) does not support understanding the intention of the information protections being addressed.  The shift to an information protection standard is welcome, but would require some support of identifying types of information and developing some sort of inventory that can allow for concrete demonstration of protections and measures to comply.  An entity could use a narrow interpretation of “system information” to overtly restrict what is considered BCSI and minimize the compliance burden at the expense of providing information protections.  Since the rest of CIP-011-3 R1 depends on R1.1 identification, this could remove most information relevant to protection of cyber assets from consideration for compliance.

Michael Puscas, On Behalf of: ISO New England, Inc., , Segments 2

- 0 - 0

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

- 0 - 0

Yes.  We do agree.  But does that mean NERC/FERC will consider the applicability section?  They don't consider the applicability section related to CIP-002 IRC 2.11 they and FERC claim that non-BES generation is to be considered when performing a nRP evaluation of a GOP Control Center.  The Applicability Section says "All BES Facilities". Why is the other CIP drafting team having to redefine BES in the new IRC 2.12.  Is NERC and FERC going to pull a fast one again and say entities need to include non-BES Cyber Information in their BCSI Protection Plans?????

 

  • And BES Means BES not non-BES

  • and Facilities mean BES equipment not non-BES equipment

  • and GOP's don't have GOP functional obligations for non-BES generation. 

  • Non-GOPs are doing just fine not providing GOP functional obligation services to non-BES generation and so are GOPs; i.e. neither GOP's and non-GOPs have GOP function obligations to any non-BES generator!.  We reserve our GOP services for Generation Facilities (I.e. BES by NERC Glossary definition for Facilities and GOP's provide services to a operate Facilities) not non-BES assets, see definition of GOP in NERC Glossary of Terms.

  • According to NERC's March 1, 2019 Standards Process Manual Appendix 3A page 6 last paragraph "The only mandatory and enforceable components of a Reliability Standrd are the (1) Applicability, (2) Requirements, and (3) effective dates.

  • What good is the Applicability Section if NERC/FERC are going to ignore it?

  •  

Marty Hostler, Northern California Power Agency, 5, 2/3/2020

- 0 - 0

Hot Answers

OPG is in agreement with RSC provided comment

Constantin Chitescu, Ontario Power Generation Inc., 5, 2/3/2020

- 0 - 0

How are entities to list NERC, Regional Entities, FERC, etc.? The Standard should allow certain exemptions. They should also allow for exemptions post NERC Exceptional Circumstance incidents where the information may be shared to expedite recovery.

Agree with Tarantino’s comment about this needs to be included in CIP-013.

Bradley Collard, 2/3/2020

- 0 - 0

Other Answers

This type of requirement often becomes a problem during enforcement, when the auditors evaluate the quality of the assessments.  This is a reoccuring issue with the auditors, and can only be resolved through more specific wording in the requirements.

Kevin Conway, Public Utility District No. 1 of Pend Oreille County, 1, 12/23/2019

- 0 - 0

Calvin Wheatley, On Behalf of: Wabash Valley Power Association, SERC, RF, Segments 1, 3

- 0 - 0

While this will promote a better understanding of the requirements, it suffers in that internally stored information does not require the same types of controls as externally stored information.  For example, a company may encrypt all data storage, whether or not BCSI.  However, requiring a separate key custody process for internally stored information in small registered entities is an excessive and overly prescriptive requirements.

Susan Sosbe, Wabash Valley Power Association, 3, 1/22/2020

- 0 - 0

Comments:  Doing a risk assessment of an 3rd party / offsite storage provider is practically useless.  The best a RE will get from most providers is a SOC1 or SOC-2 report.  The way this is written today only creates compliance risk and burden on the RE.  The majority of offsite/Cloud provider storage solutions (a majority if not all the providers RE’s would use) are not the issue when it comes to security risks.  These types of businesses would not be in business if they did not have strong security systems in place and would not be used by Federal, State, Local governments and Fortune ranked companies.  Instead of putting the burden on the RE, NERC/FERC needs create an approval process and keep an approved published list of 3rd party storage vendors list for RE’s to be able to use.  This is exactly what is done for government and government contractors.  This would be more efficient, more in-depth, and not create compliance burden on the RE’s.  This would not restrict competition or violate any laws as any 3rd party would be able to go through the process to get approved. 

William Hutchison, On Behalf of: Southern Illinois Power Cooperative, , Segments 1

- 0 - 0

Duke Energy generally agrees that these requirements will promote a better understanding of security risks. Duke Energy would like better understanding of the opportunities to address appropriate security controls. Also, Duke Energy would like more clarity on what consitutues an acceptable risk assessment and/or what other options would suffice instead of a risk assessment.

Duke Energy, Segment(s) 1, 5, 6, 3, 12/13/2019

- 0 - 0

We would encourage the SDT to include a time frame for when 3rd party security mitigations need to be completed. It is an improvement to see that a date must be included for closure of identified security risks, but this is still open ended and will not ensure timely closure of risks.

DTE Energy - DTE Electric, Segment(s) 5, 4, 3, 2/27/2017

- 0 - 0

1.       CIP-011 R1, Part 1.4 states “Process(es) to identify, assess, and mitigate risks in cases where vendors store Responsible Entity’s BES Cyber System Information….”  Since MEAG does not store its BCSI in the cloud with another vendor, would this requirement be N/A, or does MEAG still need to develop a risk assessment document (program/process) in the event we decide to use a cloud vendor for our BCSI in the future?

2.       CIP-011 R2 deals with a key management program.  Is this for physical and/or cyber?  This requirement seems to assume that all entities would have a key server for authentication, revocation, etc.  Is this only for those entities that are using a 3rd party vendor to store BCSI?  However, what about those entities that don’t issue ‘keys’.  For example, MEAG encrypts its files on the MEAG shared drive, but it is protected only by a secure password that is given to only a 3 people; the IS Administrators can’t even see the contents of the files.  Does MEAG need to call the software vendor to ask how files are encrypted by the software and how the keys get processed on the PC?  The encryption on the files works in the background; MEAG has no control on that process.  So, can this requirement be N/A for MEAG Power?  Will N/A be allowed by the Auditors?

Scott Miller, On Behalf of: Roger Brand, MEAG Power, 1,3; Roger Brand, MEAG Power, 1,3; Roger Brand, MEAG Power, 1,3; David Weekley, MEAG Power, 1,3; David Weekley, MEAG Power, 1,3; David Weekley, MEAG Power, 1,3

- 0 - 0

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

- 0 - 0

Please clarify if R1.4 would apply only to vendors providing storage as a service for BCSI, or if it would apply to any vendor possessing any amount of BCSI.

Public Utility District No. 1 of Chelan County, Segment(s) 3, 1, 1/27/2020

- 0 - 0

Karl Blaszkowski, CMS Energy - Consumers Energy Company, 3, 1/28/2020

- 0 - 0

Donald Lynd, CMS Energy - Consumers Energy Company, 1, 1/28/2020

- 0 - 0

We recommend that CIP-013 is expanded to include vendors that store BES CSI on behalf of entities.  The vendor requirements in CIP-011 exceed CIP-013 requirements may result in additional processes that can be covered by the CIP-013 standard.

Joe Tarantino, On Behalf of: Kevin Smith, Balancing Authority of Northern California, 1; Kevin Smith, Balancing Authority of Northern California, 1; Kevin Smith, Balancing Authority of Northern California, 1; Jamie Cutlip, Sacramento Municipal Utility District, 1,3,4,5,6; Jamie Cutlip, Sacramento Municipal Utility District, 1,3,4,5,6; Jamie Cutlip, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Goi, Sacramento Municipal Utility District, 1,3,4,5,6; Beth Tincher, Sacramento Municipal Utility District, 1,3,4,5,6; Beth Tincher, Sacramento Municipal Utility District, 1,3,4,5,6; Beth Tincher, Sacramento Municipal Utility District, 1,3,4,5,6; Arthur Starkovich, Sacramento Municipal Utility District, 1,3,4,5,6; Arthur Starkovich, Sacramento Municipal Utility District, 1,3,4,5,6; Arthur Starkovich, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6; Nicole Looney, Sacramento Municipal Utility District, 1,3,4,5,6

- 0 - 0

The draft requirement R2.1 regarding key management is unclear, and yet, at the same time, too prescriptive. Key management should not be specified as the means, as there are others. R2 Part 2.1 should be deleted in its entirety.

Also, for R1 Part 1.4 and R2 Part 2.2, Regional and Registered Entities, as well as NERC and FERC, need to be exempted from any possibility of being regarded as vendors or custodial entities.

R1 Part 1.4 and R2 Parts 2.1 and 2.2 exceed the scope of the SAR. We do not believe this is an appropriate place to promote better understanding of security risks involved, nor do we think we should be held to these extremely prescriptive requirements. Identifying, assessing, and mitigating vendor risks will already be addressed as part of preventing unauthorized access.

How a Responsible Entity chooses to implement their access control program should not be prescribed within standard language. We suggest removing all language from CIP-011-3 R1.2, R1.4, R2.1 and R2.2. We believe that the inclusion of storing BCSI with cloud based service providers can be addressed by defining “BCSI Access” in the NERC Glossary of Terms. The definition language could be taken from the April 26, 2019 ERO Enterprise CMEP Practice Guide on BES Cyber System Information: “An instance or event during which a user obtains and uses BCSI. For access to occur, in this context, a user, authorized or unauthorized, must concurrently both obtain BCSI and possess the ability to use BCSI. An unauthorized individual who obtains encrypted BCSI but has no ability to use it within a meaningful timeframe should not be considered to have access.”

Currently CIP-004-6 adequately addresses access controls to BCSI when stored by the responsible entity. The issue with the current access requirements is when applied to offsite vendors due to the fact that the Responsible Entity cannot control a vendor’s access to the BCSI.

With this definition in place the SDT can then simply change CIP-004-6 R4 to read:

R4: Process to authorize based on need, as determined by the Responsible Entity, except for CIP Exceptional Circumstances”:

4.1.1.   Electronic Access

4.1.2.   Unescorted physical access into a Physical Security Perimeter; and

4.1.3.   BCSI Access

The SDT could also change language in CIP-004-6 R5.3 to read:

For termination actions, revoke the individual’s access to BES Cyber System Information, whether physical or electronic (unless already revoked according to Requirement R5.1), by the end of the next calendar day following the effective date of the termination action.

Part CIP-004-7 R4.1.3 would limit “BCSI Access” appropriately to vendors that are custodians to encrypted or otherwise masked data but do not have the ability to use it. Any vendor with both custody of data and ability to use it (e.g. have an encryption key) would need to be provisioned access by the Responsible Entity through their established access control process and procedures.

MRO NSRF, Segment(s) 3, 4, 5, 6, 1, 2, 1/29/2020

- 0 - 0

FE Voter, Segment(s) 1, 3, 5, 6, 4, 10/31/2019

- 0 - 0

Xcel Energy support the comments submitted by EEI.

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

- 0 - 0

The language appears that the key management would be outside of the Responsible Entity. The Responsible Entity may manage their own keys in certain architectures. Clarification that separations are needed where an vendor (3rd party) is used for key management.

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

- 0 - 0

Support the MRO NSRF comments

Jeremy Voll, Basin Electric Power Cooperative, 3, 1/30/2020

- 0 - 0

Anthony Jablonski, ReliabilityFirst , 10, 1/30/2020

- 0 - 0

The requirement language is not clear as SDT expected. If it is intended that R1 Part 1.4 and R2 only apply when vendors are involved, the Requirement language should clearly state this. In addition, for R1 Part 1.4 and R2 Part 2.2, Regional and Registered Entities, as well as NERC and MRO, need to be exempted from any possibility of being regarded as vendors or custodial entities.

 

R2 requires entities to have a key management program, but the wording regarding encryption and vendors are missing. Suggest adding the following language to R2:

“… shall implement one or more documented key management program where vendors are custodians and BCSI are encrypted…”

 

In R2 Part 2.1, we believe “key suppression” is a typo and it should be “key supersession”. Also if it is intended to address the electronic key rather than physical key, it should clealy state electronic key or encryption key in the requirement language.

 

In R2 Part 2.2, what does the term “custodial entity” mean? If this is a term taken from other guidance or standard documents (NIST, Cloud Security Alliance etc.), those should be referenced. Across various NIST and CSA documents, the terms “data custodian” and “key custodian” are both in use.

 

In R2 Part 2.2, when separation of duties is being called for, it’s not clear which particular duties must be kept separate. Also it is not clear whether the separation of duties means between the vendors and Registered Entities.

 

In R2 Part 2.2, it is not clear if it is acceptable for a vendor to have both custody of data and ability to use it (e.g. have an encryption key.) if the vendor separate their staff’s duties.

Bruce Reimer, Manitoba Hydro , 1, 1/30/2020

- 0 - 0

Seattle is concerned about the overlap and potential for conflict between proposed CIP-011 vendor controls and CIP-013. Seattle prefers an objective-based, risk-focused approach that would leverage CIP-013 controls without restating them. Depending on how an entity used, transports, and stores its BCSI, additional controls might be warranted for third parties involved in BCSI processes, but these might be better left up to each entity to determine and defend, based on existing security concepts. For example, an entity may determine that a third-party with a valid FedRAMP certification is sufficiently risk-free to engage to store BCSI, or it might identify specific individual controls. Leaving it up to each entity, with some reasonable guidance, serves to break the Gordian Knot of third-party certifications that to date has stifled most NERC approaches to third party storage providers.

Matthew Nutsch, On Behalf of: Seattle City Light, WECC, Segments 1, 3, 4, 5, 6

- 0 - 0

While Tri-State agrees with the concept of performing a risk evaluation (proposed by Part 1.4) associated with a cloud solution, we do not agree it needs to be a compliance requirement. We think that the other requirements (access management, methods to protect/secure BCSI, etc.) already force the Registered Entity to evaluate and identify risks, possible solutions, etc. Making the risk evaluation a mandatory requirement does not add value, and instead adds unnecessary adminstrative compliance burden.

The R2 requirements as drafted are entirely too prescriptive and should instead be converted to objective-based requirements. Furthermore, as to R2.2, entity’s should be permitted to have the same vendor manage the keys and hold the encrypted data, as long as controls are in place to prevent unauthorized access and detect when an unauthorized action has been taken. Additionally, the use of the phrase “Where applicable” should be clarified. We recommend instead using the phrase “Where encryption is utilized as a method to restrict access to BCSI”.

Kjersti Drott, Tri-State G and T Association, Inc., 1, 1/31/2020

- 0 - 0

We support NPCC RSC comments.

Payam Farahbakhsh, Hydro One Networks, Inc., 1, 1/31/2020

- 0 - 0

The focus needs to be on protecting access to the information. This should be performed in a vendor/platform neutral manner - whether the systems are administered by in-house personnel or hosted on a shared cloud-based hosting provider, the outcome, regardless, should be that access to the information is limited to authorized individuals only.  The risk assessment is an additional undue burden on the entity that the existing process should account for regardless of the outside party the information is being shared with.  As such, suggest re-architect the standard to be outcome based so as not to preclude using specific technologies or adoption of emergent solutions, and to apply regardless of the outside party with whom the information is shared.

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

- 0 - 0

Maryanne Darling-Reich, On Behalf of: Black Hills Corporation - MRO, WECC - Segments 1, 3, 5, 6

- 0 - 0

Regarding CIP-011, Requirement 1, Part 1.4, AEP feels that this requirement does not belong in CIP-011. We believe vendor management/supply chain requirements belong in CIP-013 rather than CIP-011. If the current language in CIP-013 does not address BCSI protection when stored at a third party location, AEP recommends modifying the CIP-013 standard to address these needs.

In regards to CIP-011, Requirement 2, Parts 2.1 and 2.2, AEP is of the opinion that key management and encryption may not be enough to properly ensure the protection of BCSI when being stored in a third party facility. We also feel these requirements could use some clarification regarding when it’s necessary to use key management methods. AEP is unsure of how “where applicable” is defined within Part 2.1, which could lead to insufficient protection of BCSI based on how that phrase is interpreted.

Kent Feliks, AEP, 3, 1/31/2020

- 0 - 0

Russel Mountjoy, Midwest Reliability Organization, 10, 1/31/2020

- 0 - 0

AECI supports comments filed by NRECA

AECI, Segment(s) 1, 3, 6, 5, 5/31/2019

- 0 - 0

NRECA agrees that the proposed revisions will promote a better understanding of security risks involved while also providing opportunities for the Responsible Entity to address appropriate security controls; however, it does not support the way the proposed requirements do so.  Specifically, NRECA is concerned about introducing a separate vendor risk assessment for vendors under CIP-011 than is proposed in CIP-013.  Such segregation of similar and potentially related requirements and processes into 2 different standards introduces (rather than reduces) overall risk as discussed below in NRECA’s response to question #10.  If a risk assessment for a vendor is necessary, then, the team should work with the Supply Chain SDT to modify CIP-013.  This is especially important where cloud services are provided under a master or general services agreement that is in scope for CIP-013 as an additional requirement under CIP-011 creates redundancy and the potential for error.   Further, NRECA notes that mitigations are not required to be implemented in CIP-013, but are required to be implemented here for what is likely a less risky procurement. It is unclear as to why this would be necessary and, as this is not addressed within the Technical Rationale, it should be addressed by the SDT to ensure that there is an appropriate identification of risk associated with the recommendation to require a separate risk assessment and mandatory risk mitigation within CIP-011 for access to information when mandatory mitigation is not required within CIP-013.

Barry Lawson, National Rural Electric Cooperative Association, 4, 2/3/2020

- 0 - 0

R1 Part 1.4 and R2 Parts 2.1 and 2.2 exceed the scope of the SAR and significantly increase the compliance obligations.  CIP-011 should remain non-prescriptive and allow entities to implement the controls appropriate to their situations.  Vendor risk assessments are addressed in CIP-013 and should not be required here.  In any case, the end result of identifying, assessing, and mitigating vendor risks is still going to be the controls we implement to try and prevent unauthorized access, which is already required by CIP-011.

 

It is also unclear as to when/if these requirements are applicable.

Andy Fuhrman, On Behalf of: Theresa Allard, Minnkota Power Cooperative Inc., 1; Theresa Allard, Minnkota Power Cooperative Inc., 1; Theresa Allard, Minnkota Power Cooperative Inc., 1

- 0 - 0

GSOC agrees that the proposed revisions will promote a better understanding of security risks involved while also providing opportunities for the Responsible Entity to address appropriate security controls; however, it does not support the manner in which the proposed requirements do so.  Specifically, GSOC is concerned about introducing a separate vendor risk assessment for vendors under CIP-011 than is proposed in CIP-013.  Such segregation of similar and potentially related requirements and processes into 2 different standards introduces (rather than reduces) overall risk as discussed below in GSOC’s response to question #10.  If a risk assessment for a vendor is necessary, then, the team should work with the Supply Chain SDT to modify CIP-013.  This is especially important where cloud services are provided under a master or general services agreement that is in scope for CIP-013 as an additional requirement under CIP-011 creates redundancy and the potential for error.   Further GSOC notes that mitigations are not required to be implemented in CIP-013, but are required to be implemented here for what is likely a less risky procurement. It is unclear as to why this would be necessary and, as this is not addressed within the Technical guidance, it should be addressed by the SDT to ensure that there is an appropriate identification of risk associated with the recommendation to require a separate risk assessment and mandatory risk mitigation within CIP-011 for access to information when mandatory mitigation is not required within CIP-013.

Andrea Barclay, Georgia System Operations Corporation, 4, 2/3/2020

- 0 - 0

SMEC agrees with comments submitted by NRECA.

Lana Smith, San Miguel Electric Cooperative, Inc., 5, 2/3/2020

- 0 - 0

Doing a risk assessment of an 3rd party / offsite storage provider is practically useless.  The best a RE will get from most providers is a SOC1 or SOC-2 report.  The way this is written today only creates compliance risk and burden on the RE.  The majority of offsite/Cloud provider storage solutions (a majority if not all the providers RE’s would use) are not the issue when it comes to security risks.  These types of businesses would not be in business if they did not have strong security systems in place and would not be used by Federal, State, Local governments and Fortune ranked companies.  Instead of putting the burden on the RE, NERC/FERC needs create an approval process and keep an approved published list of 3rd party storage vendors list for RE’s to be able to use.  This is exactly what is done for government and government contractors.  This would be more efficient, more in-depth, and not create compliance burden on the RE’s.  This would not restrict competition or violate any laws as any 3rd party would be able to go through the process to get approved. 

 

In almost all documented cloud data breach cases we are aware of, it has been the end user which has caused data leaks not the provider themselves ref: https://www.wsj.com/articles/human-error-often-the-culprit-in-cloud-data-breaches-11566898203 .  We followed this article up by asking various cybersecurity experts from EY, Mandiant, and Cisco.  The only compromise which came up from them was 3rd party identity providers.  The compromise was of their own outward facing application and not the security of or compromise of customer storage solutions.  The greater risk in cloud/3rd party storage solutions lies more in a customer not having the knowledge of the risks and security tools necessary to protect data in the cloud than the cloud provider itself.  This is also significantly dependent on the type of environment being used such as a completely private cloud vs hybrid public/private cloud and its subsequent configuration

ACES Standard Collaborations, Segment(s) 1, 3, 2/3/2020

- 0 - 0

Dwayne Parker, 2/3/2020

- 0 - 0

IESO agrees in principle with the comments submitted by NPCC

We agree with that Part 1.4 will promote a better understanding the security risks involved. We have serious concerns with these controls:

  1. We have strong apprehensions on “mitigate” in Part 1.4 and possibly push some to vote NO on this project. Entities have little control of vendors their subcontractors vendors. We prefer the SDT consider that these vendor controls (mitigations) belong in CIP-013. If the SDT leaves these controls in CIP-011, we recommend the same type of strategy used in CIP-013 – a) have a plan and b) implement that plan rather that “mitigate”
  2. In regards to Part 2.2 , we request clarification with respect to physical security - Part 2.2 may be difficult to implement where the custodian and the person with the key are the same?

Leonard Kula, Independent Electricity System Operator, 2, 2/3/2020

- 0 - 0

Yes, agree that a stand alone requirement where a vendor stores an entitiy’s BCSI is needed.  1.4.1 requires an initial risk assessment of vendors but the SDT needs to define what is acceptable evidence for a risk assessment. 

Is requirement 2 only applicable to BCSI stored in the cloud?  For R2.1 the SDT should define key management and provide guidance in a GTB. 

For R2.2 if an entity uses secure thumdrives, how can they separate the duties?  Who in this requirement is the custodial entity?

Santee Cooper, Segment(s) 1, 3, 5, 6, 2/3/2020

- 0 - 0

 These additional requirements should be added to the language of CIP-013 and addressed in the entities supply chain risk management plan. Do not mix the standards requirements.

sean erickson, Western Area Power Administration, 1, 2/3/2020

- 0 - 0

Requirement R1 Part 1.4 is a step in the right direction for structuring a framework that considers third-party providers as a viable source.  However, as written, the language falls short in the following wasy:

  • This entire process should be included in the CIP-013 Supply Chain standard that already deals with bendor risk assessments, etc.  This is duplicative to that effort and one that would likely be collapsed into CIP-013 during a subsequent efficiency review
  • The intent to mitigate risk does not include the intended risk threshold or objective.  If this is to be determined by the entity, the outcome should be clearly indicated.  If this risk analysis were included in CIP-013, the entity already defines the process and risk objectives there, so this would also be a duplication.
  • Part 1.4.3 - is it necessary to state that the entity needs to "document the results of the risk assessment"? This serves as a Measure to Part 1.4.2 than a standalone requirement, which in and of itself, is administrative.  Furthermore, Part 1.4.3 should be reworded to state, "Implement an action plan to remediate or mitigate risk(s) identified in the risk assessment performed according to Parts 1.4.1 and 1.4.2, including the planned date of completing the action plan and the execution status of any remediation or mitigation action items."
  • Bullets 3 and 4 in the Measures - what is the difference between the "documentation of the vendor risk assessments" and "documentation of the results of the vendor risk assessments"?  It seems these could be combined into a singular measure.

With respect to R2 Parts 2.1 and 2.2:

  • The objective is to restrict access but it is not clear to what?  The requirement should be clarified.  Is the key management process intended for physical access to locations of BCSI storage locations?  Electronic access to folders and/or information containing BCSI?  Both?  Something else?  This appears to be an available Measure to meet Part 1.2 and not an independent requirement covering the same reliability objective of preventing unauthorized access.
  • There are several terms included in the Parts 2.1.1 - 2.1.9 list that are not commonly understood without further explanation (e.g. key suppression, periods).  These need to be presented or explained more clearly to inform the Registered Entity what the intent is.
  • In Part 2.2, the use of "custodial entity" is not well understood.  Furthermore, the intended security objective of this requirement is not clear as a result.

Gerry Adamski, Cogentrix Energy Power Management, LLC, 5, 2/3/2020

- 0 - 0

AZPS agrees that the proposed language in Part 1.4 addresses security risks associated with instances where a vendor stores a Responsible Entity’s BCSI.  However, Parts 1.4.1 through 1.4.3 introduce duplicative requirements to perform risk assessments, as the requirement will be satisfactorily met with the implementation of CIP-013-1 Part 1.1.  AZPS recommends retaining Part 1.4 and remove sub-parts 1.4.1 through 1.4.3. 

With respect to CIP-011-3 R2, AZPS provides its response in Question No. 8.     

Vivian Moser, 2/3/2020

- 0 - 0

The proposed language for CIP-011-3, Requirements R1, Part 1.4 are not only duplicative of CIP-013, they also prescribe mandatory timeframes for the performance of periodic risk assessments for what is otherwise an objective based standard in CIP-013.  This periodicity should be left up to each Registered Entity to define within their Supply Chain Risk Management plan. To remove double jeopardy, prevent confusion, and maintain consistency for supplier risk management requirements, CIP-011-3, Requirements R1, Part 1.4 should be removed and cloud-based suppliers for BCSI should be covered in CIP-013.   

LaTroy Brumfield, American Transmission Company, LLC, 1, 2/3/2020

- 0 - 0

Truong Le, On Behalf of: Chris Gowder, Florida Municipal Power Agency, 3,4,5,6; Chris Gowder, Florida Municipal Power Agency, 3,4,5,6; Chris Gowder, Florida Municipal Power Agency, 3,4,5,6; Carol Chinn, Florida Municipal Power Agency, 3,4,5,6; Carol Chinn, Florida Municipal Power Agency, 3,4,5,6; Carol Chinn, Florida Municipal Power Agency, 3,4,5,6; Dale Ray, Florida Municipal Power Agency, 3,4,5,6; Dale Ray, Florida Municipal Power Agency, 3,4,5,6; Dale Ray, Florida Municipal Power Agency, 3,4,5,6; Richard Montgomery, Florida Municipal Power Agency, 3,4,5,6; Richard Montgomery, Florida Municipal Power Agency, 3,4,5,6; Richard Montgomery, Florida Municipal Power Agency, 3,4,5,6; David Owens, Gainesville Regional Utilities, 1,3,5; David Owens, Gainesville Regional Utilities, 1,3,5; David Owens, Gainesville Regional Utilities, 1,3,5

- 0 - 0

While Tri-State G&T agrees with the concept of performing a risk evaluation (proposed by Part 1.4) associated with a cloud solution, we do not agree it needs to be a compliance requirement. We think that the other requirements (access management, methods to protect/secure BCSI, etc.) already force the Registered Entity to evaluate and identify risks, possible solutions, etc. Making the risk evaluation a mandatory requirement does not add value, and instead adds unnecessary adminstrative compliance burden.

The R2 requirements as drafted are entirely too prescriptive and should instead be converted to objective-based requirements. Furthermore, as to R2.2, entity’s should be permitted to have the same vendor manage the keys and hold the encrypted data, as long as controls are in place to prevent unauthorized access and detect when an unauthorized action has been taken. Additionally, the use of the phrase “Where applicable” should be clarified. We recommend instead using the phrase “Where encryption is utilized as a method to restrict access to BCSI”.

Janelle Marriott Gill, Tri-State G and T Association, Inc., 3, 2/3/2020

- 0 - 0

We believe the proposed vendor risk assessment is best under CIP-011 rather than combining with CIP-013. 

Jonathan Robbins, Seminole Electric Cooperative, Inc., 4, 2/3/2020

- 0 - 0

Anton Vu, Los Angeles Department of Water and Power, 6, 2/3/2020

- 0 - 0

N&ST believes that, following the Effective Date of 7/1/20 for CIP-013, vendors offering BCSI storage services will be subject to that Standard, which in our view renders proposed CIP-011-3 Requirement R1, Part 1.4 redundant. Moreover, the proposed requirement is more stringent than any requirement in CIP-013! The SDT is, in essence, proposing to require Responsible Entities to perform ANNUAL vulnerability assessments of their cloud storage vendors (if any). N&ST admits to being hard-pressed to imagine how a Responsible Entity could perform a credible “risk assessment” of, for instance, Microsoft Azure beyond asking them in writing if they still have the same FedRAMP authorization level as they had the previous year. The “Technical Rationale for Reliability Standard CIP-011-3” includes a statement, “If the focus is protection of BCSI, the device or storage location becomes less relevant,” that seems inconsistent with the proposed “risk assessment” requirement. N&ST recommends that it be dropped.

With regards to proposed Requirement R2, Parts 2.1 and 2.2, N&ST considers them vastly over-prescriptive. The goal here is to ensure that no individuals who manage BCSI storage, whether in the Responsible Entity’s own data center or “in the cloud,” can access BCSI unless they have been properly authorized in accordance with the requirements of CIP-004. Encryption and key management are certainly viable options, but they should remain options. N&ST suggests moving them to the “Measures” associated with an appropriately re-worded requirement.

Nicholas Lauriat, Network and Security Technologies, 1, 2/3/2020

- 0 - 0

We believe R1 Part 1.4 and R2 Parts 2.1 and 2.2 exceed the scope of the SAR. Vendor risk assessments are addressed in CIP-013. The result of identifying, assessing, and mitigating vendor risks is still going to be controls we implement to prevent unauthorized access, which is already required in various other current CIP Standards. The concern is that the SDT is developing a requirement that is duplicative of requirements contained within CIP-013, and any modifications should be addressed in that Standard, not in CIP-011-3. 

 

If R1 Part 1.4 needs to be pursued in CIP-011, per the definition of a Vendor in CIP-013, Regional and Registered Entities, need to be exempted from being regarded as vendors, suppliers, or custodial entities.

Sandra Shaffer, Berkshire Hathaway - PacifiCorp, 6, 2/3/2020

- 0 - 0

ALAN ADAMSON, New York State Reliability Council, 10, 2/3/2020

- 0 - 0

“System Information Pertaining to” BCS is far too vague. The NERC Glossary definition of BCSI shows examples rather than a principle by which to designate BCSI. Guidance on this point fails to approach data “classification” or “categorization” according to sound and well-developed principles in widespread use for which expertise and guidance exists from the Intelligence community.  One vital concept is aggregation of data leading to increased risk. The glossary definition gives an example or hints at it through the phrase “collections of network addresses:” but doesn’t explain how an Entity would create a guideline for policy that assesses risk based on aggregation, doesn’t discuss “Essential Elements of (Friendly) Information” concepts and doesn’t discuss derivative classification and marking. 

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

- 0 - 0

Texas RE recommends the SDT define the term “vendor”, which is used in Part 1.4 as well as referenced in CIP-005-6 and CIP-013-1.  This would ensure an understanding of what is considered a vendor.

Rachel Coyne, Texas Reliability Entity, Inc., 10, 2/3/2020

- 0 - 0

Dominion Energy supports the work the SDT has done on develoing the current draft. Dominion energy suggests that the team focus on the approach taken in the current NERC CMEP Guidance document in addressing the issue and further supports EEIs comments. Supply chain related related requirements should remain as part of the CIP-013 planning process.

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

- 0 - 0

Exelon supports EEI's comments on behalf of Exelon Segments 1, 3, 5, and 6.

Kinte Whitehead, Exelon, 3, 2/3/2020

- 0 - 0

Ameren agrees with and supports EEI comments.

David Jendras, Ameren - Ameren Services, 3, 2/3/2020

- 0 - 0

NCEMC supports the comments by Barry Lawson, National Rural Electric Cooperative Association and ACES

Kagen DelRio, On Behalf of: North Carolina Electric Membership Corporation - SERC - Segments 3, 4, 5

- 0 - 0

R1.4: Southern believes the wording “Process(es) to identify, assess, and mitigate risks in cases where vendors store Responsible Entity’s BES Cyber System Information” is less clear.  This has no wording to scope it to off-premise situations.  Vendors produce all types of data storage solutions and this could be interpreted to mean that all BCSI is stored by a vendor.  The requirement should specify the relationship the vendor has to the “storing” of the data as we believe this is about when vendors own/operate/maintain the storage in an off-premise cloud service environment. 

 

R2: Requires that an entity “shall implement one or more documented key management program(s) that collectively include the applicable requirement parts in CIP-011-3 Table R2 – Information Protection” regardless of whether or not an entity encrypts its BCSI or not. For entities that keep all BCSI on-premises and choose to not use 3rd party cloud solutions or encryption as a technical control, this main R requirement serves no purpose, and results in a documentation exercise to ‘prove the negative.’  Consider moving the term “where applicable” to the main R requirement to explicitly exempt those entities that do use encryption as a technical control to protect BCSI in storage, transit, or use.

 

Overall, Southern believes that the R2 requirements for VRA’s should be part of CIP-013 which is a more holistic approach to vendor risk.  We do not agree with the need to piecemeal different flavors of VRAs throughout the CIP standards for individual technical areas.  CIP-013-1 R2 currently has language containing a cyber security risk management plan for supply chain.  We suggest this be removed from the proposed CIP-011 and instead be coordinated with the Supply Chain SDT to add language or a requirement to align with conducting vendor risk assessments.

 

Part 1.4 seems to be somewhat a duplication of 1.6 where a verification of access to BCSI is required on the same time interval.

Southern Company, Segment(s) 1, 3, 5, 6, 12/13/2019

- 0 - 0

The BCSI should be protected regarless where it is.  When and how to perform risk assessments of the vendors that store the Responsible Entity’s BCSI should not become an extra burnden on Responsible Entity.

Tho Tran, On Behalf of: Lee Maurer, Oncor Electric Delivery, 1; Lee Maurer, Oncor Electric Delivery, 1; Lee Maurer, Oncor Electric Delivery, 1

- 0 - 0

SDG&E supports EEI’s comments submitted on our behalf.

Bridget Silvia, Sempra - San Diego Gas and Electric, 3, 2/3/2020

- 0 - 0

ITC supports the response found in the NSRF Comment Form

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

- 0 - 0

  1. We agree with that Part 1.4 will promote a better understanding the security risks involved. We have serious concerns with these controls. Entities have little control of vendors OR the vendors of the primary vendors. We recommend the path laid out by CIP-013 – a) have a plan and b) implement that plan.

  2. We request this SDT consider if these vendor controls (mitigations) belong in CIP-013.

  3. We request clarification of physical security. Part 2.2 may be difficult to implement where the custodian and the person with the key are the same.

Eversource Group, Segment(s) 3, 1, 4/12/2019

- 0 - 0

We believe R1 Part 1.4, and R2 Parts 2.1 and 2.2, exceed the scope of the SAR. We agree with EEI comments that vendor risk assessments with respect to hosting BCSI should be addressed with a modification to CIP-013.

 

We concur with EEI comments that the draft requirement R2.1 regarding key management is unclear, and yet, at the same time, too prescriptive.

 

Similar to the explanation of the term “vendor(s)” in the CIP-013 Supplemental Material, it must be made clear with respect to vendors in R1 Part 1.4, and custodial entity in R2 Part 2.2, that Regional and Registered Entities, as well as NERC and FERC, are exempted as such.

Kevin Salsbury, Berkshire Hathaway - NV Energy, 5, 2/3/2020

- 0 - 0

Please see comments submitted by Edison Electric Institute

Ayman Samaan, 2/3/2020

- 0 - 0

  1. We have strong apprehensions on “mitigate” in Part 1.4 and possibly push some to vote NO on this project. See #2 for more feedback.  NYPA is voting ‘NO’ based on these apprehensions.

  2. We agree with that Part 1.4 will promote a better understanding the security risks involved. We have serious concerns with these controls. Entities have little control of vendors OR the vendors of the primary vendors. We recommend the path laid out by CIP-013 – a) have a plan and b) implement that plan. The potential costs of these controls may not produce an effective result. Plus the submitted feedback to Standards Efficiency Review tends to question the value of annual reviews for the sake of a review instead of a trigger.

  3. We request this SDT consider if these vendor controls (mitigations) belong in CIP-013.

  4. We request clarification of physical security - will Part 2.2 be difficult to implement where the custodian and the person with the key are the same?

David Rivera, New York Power Authority, 3, 2/3/2020

- 0 - 0

To avoid confusion and the splitting of requirements, vendor risk management, including risk assessments of vendors, should be included in CIP-013.  Additionally, the concept of assessing the risk of cloud-providers is good, but the execution within the requirements needs more work.  For instance, the requirement is unclear on what constitutes a vendor “storing” an entity’s BCSI, and an auditor could make the assumption that this requirement applies to all vendors and systems and not just to cloud providers.  Another example is the timeframe described in Part 1.4.2.  This timeline implies that BCSI is more important than the actual BES Cyber Assets themselves (as CIP-013 has no timeframe for reassessments). 

PPL NERC Registered Affiliates, Segment(s) 1, 3, 5, 6, 9/6/2018

- 0 - 0

Support MRO comments.

Wayne Guttormson, SaskPower, 1, 2/3/2020

- 0 - 0

Steve Toosevich, NiSource - Northern Indiana Public Service Co., 1, 2/3/2020

- 0 - 0

See Steven Toosevich's comments.  

Kathryn Tackett, NiSource - Northern Indiana Public Service Co., 5, 2/3/2020

- 0 - 0

If the SDT’s intent is to address security risks associated with vendors, then that should be specifically expressed in the requirements.  The current language is vague and needs further clarification.  Part 1.4 states “in cases where vendors store” but Part 2.1 and Part 2.2 do not.  In Part 2.1, the statement “where applicable” needs to be expanded to clearly provide when a key management program must be implemented.  As written, the proposed requirements are too broad and could add an undue burden if auditors take the broadest possible meaning.  Part 2.2 is not clear due to the vagueness of Part 2.1.  The following changes are suggested;

“Part 2.1 When BCSI is stored in environments owned or managed by vendors, develop a key management process(es) …”

“Part 2.2 When BCSI is stored in environments owned or managed by vendors, implement controls to separate …”

Also in reference to Part 2.2,  the phrase “BCSI custodial entities duties” is not clear and open to broad interpretation.

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

- 0 - 0

There are other more appropriate methods to “promote better understanding” of issues and topics than through the standards drafting process.  Perhaps such issues and topics could be included as part of a Technical Rationale, supporting white paper, or using other available mechanisms.

With regard to CIP-011-3, Requirement R1, Part 1.4, the requirements appear to duplicate CIP-013 Requirements.  As such, we would encourage the SDT to address a perceived security gap of BCSI stored at third party facilities within the CIP-013-1 Standard.

Regarding CIP-011-3, Requirement R2, Parts 2.1 and 2.2; EEI offers the following comments:

The SDT is prescribing requirements that do not appear to conform to NERC guidance regarding development of results-based Reliability Standards.  While encryption and key management would be an acceptable method for ensuring the security of BSCI at third party facilities, specifying this solution within requirements may be overly prescriptive and potentially limit entities from using other methods to secure BCSI, if future technology advancements offer such solutions.  For this reason, the language should be broader with less prescription.  If the SDT believes that the requirements as described in R2 must be pursued, EEI suggests the following:

Part 2.1: “Where applicable” should be more clearly defined in order to avoid any confusion as to when key management processes are required, otherwise the list of processes appears to be sufficiently comprehensive to ensure the security of BSCI.

 

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

- 0 - 0

If the intent of the proposed changes to CIP-011-3, requirement R1, Part 1.4 is to better understand and mitigate assessed risks to BCSI being stored within a vendor-managed environment, NYISO believes the proposed changes are potentially overly broad and administratively burdensome in comparison to risks currently assessed under CIP-013-1. 

As stated in our response to question #3, NYISO would recommend eliminating Part 1.4 of requirement R1 from CIP-011-3.  The issue of risk assessments for vendors could be addressed as part of Project 2019-03: Cyber Security Supply Chain Risks (i.e. CIP-013-2), this would have the benefit of accounting for all vendor requirements (BCS and BCSI) within the same standard.

Regarding examples contained within CIP-011-3, requirement R2, Parts 2.1 and 2.2, a key management process is an example of one method that could be applied to prevent unauthorized access.  NYISO feels that this example would be better included under requirement R1. NYISO proposes requirement R2 be removed from the current draft.

Another suggested consideration would be include protections of BCSI stored in environments owned or managed by third parties into a separate requirement.  For example, combine the requirements into “R4”, which could reference R2 (Key management) as a stated requirement (not optional) for BCSI stored in environments owned or managed by third parties.

Gregory Campoli, On Behalf of: New York Independent System Operator, , Segments 2

- 0 - 0

1)      We have strong apprehensions on “mitigate” in Part 1.4 and possibly push some to vote NO on this project. See #2 for more feedback.

2)      We agree with that Part 1.4 will promote a better understanding the security risks involved. We have serious concerns with these controls. Entities have little control of vendors OR the vendors of the primary vendors. We recommend the path laid out by CIP-013 – a) have a plan and b) implement that plan. The potential costs of these controls may not produce an effective result. Plus the submitted feedback to Standards Efficiency Review tends to question the value of annual reviews for the sake of a review instead of a trigger.

3)      We request this SDT consider if these vendor controls (mitigations) belong in CIP-013.

4)      No consensus on Part 2.1

5)      We request clarification of physical security - will Part 2.2 be difficult to implement where the custodian and the person with the key are the same?

RSC no NextEra, Segment(s) 10, 2, 4, 5, 7, 3, 1, 6, 2/3/2020

- 0 - 0

SNPD supports the fundamental requirements and reasoning behind the proposed additions but believe it would be better placed within the context of CIP-013 vendor and supply chain risk management.  CIP-011 should be limited to information handling and protection.  Vendor vetting and management would appear to fit better within the overall context of CIP-013.

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

- 1 - 0

Alliant Energy agrees with NSRF and EEI’s comments.

Specifically, if key management is not a requirement (due to the “where applicable” language in 2.1), then it is not appropriate to have this language in the requirements section and would be better suited to guidance. The requirements should only state what is required.

Jenifer Holmes, On Behalf of: Alliant Energy Corporation Services, Inc. - MRO, RF - Segments 4

- 0 - 0

Jamie Monette, Allete - Minnesota Power, Inc., 1, 2/3/2020

- 0 - 0

Dmitriy Bazylyuk, 2/3/2020

- 0 - 0

No – if the intent of the proposed changes to CIP-011-3, requirement R1, Part 1.4 is to mitigate risks particular to BCSI stored in a vendor managed environment, MISO believes the proposed changes are overly broad and administratively burdensome in comparison to those risks currently assessed under CIP-013-1 and the small amount of incremental benefit gained in relation to the level of effort required to produce it.

MISO recommends eliminating Part 1.4 of requirement R1 from CIP-011-3 and recommends the issue of risk assessments for vendors be addressed as part of Project 2019-03: Cyber Security Supply Chain Risks (i.e. CIP-013-2), thereby covering all vendor requirements (BCS and BCSI) in the same standard.

Regarding proposed CIP-011-3, requirement R2, Parts 2.1 and 2.2, a key management process is an example of one method to prevent unauthorized access and would be better included as an example under requirement R1. MISO proposes requirement R2 be eliminated altogether.

 

Bobbi Welch, On Behalf of: Midcontinent ISO, Inc., , Segments 2

- 0 - 0

Regarding Part 1.4, this requirement appears to be better addressed through CIP-013. Please see comments to question #3. Recommend to exclude applicability of all requirements for cloud service providers and include the minimum requirements in the cloud vendor risk assessments of R1.4.

James Brown, On Behalf of: California ISO, WECC, Segments 2

- 0 - 0