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

2016-02 Modifications to CIP Standards | CIP-012-1

Description:

Start Date: 07/27/2017
End Date: 09/11/2017

Associated Ballots:

Ballot Name Project Standard Pool Open Pool Close Voting Start Voting End
2016-02 Modifications to CIP Standards CIP-012-1 IN 1 ST 2016-02 Modifications to CIP Standards CIP-012-1 07/27/2017 08/25/2017 09/01/2017 09/11/2017

Filter:

Hot Answers

CHPD requests clarification be added to the Technical Rationale for acceptable means of physically protecting communications links and identifying equally effective methods to mitigate risk.

CHPD requests that the exclusion for oral communications be extended to electronic mail.

Janis Weddle, 9/11/2017

- 0 - 0

Douglas Webb, 9/11/2017

- 0 - 0

Other Answers

RoLynda Shumpert, On Behalf of: SCANA - South Carolina Electric and Gas Co., SERC, Segments 1, 3, 5, 6

- 0 - 0

The California ISO supports the comments of the Security Working Group (SWG).

- 0 - 0

Nicholas Lauriat, On Behalf of: Network and Security Technologies, , Segments 1

- 0 - 0

Duke Energy , Segment(s) 1, 5, 6, 4/10/2014

- 0 - 0

TVA agrees, providing the proposed definition of Control Center is adopted.

TVA notes that in many cases some types of operational planning analysis data is housed in systems not classified as BES Cyber Systems and may not reside within an ESP.   A documented plan provides a mechanism to identify and document flows of BES sensitive data that do not originate from within an ESP nor pass through an EAP.

Tennessee Valley Authority, Segment(s) 1, 3, 5, 6, 9/1/2016

- 0 - 0

IPC does not agree with the need for mandatory requirements. IPC evaluates risks and develops strategies to mitigates those risks, including those associated with communication infrastructure and data transmission. Risks can change, and the implementation of static regulatory obligations that are not flexibly written can make it more difficult to adapt.

Laura Nelson, 9/1/2017

- 0 - 0

The term “transmitted between Control Centers” is not clear.  Dominion is concerned that the demarcation point between Control Centers is unclear and could cause confusion?  A second concern is the potential reliability gap created by the lack of a clarification on whether internal Control Center communications networks are considered to be part of the transmission of data, or if only external communications between entities qualify as transmission data?

Dominion, Segment(s) 3, 5, 1, 4/6/2017

- 0 - 0

Sergio Banuelos, On Behalf of: Tri-State G and T Association, Inc., MRO, WECC, Segments 1, 3, 5

- 0 - 0

Even though ReliabilityFirst votes in the affirmative, ReliabilityFirst provides the following comments for consideration:

 

  1. Requirement R1 –

    1. CIP-012-1 refers to data as outlined in NERC standards TOP-003-3 and IRO-010-2 that are required to be protected.  ReliabilityFirst understands these types of data can vary based on entity function and what data is needed. From a compliance monitoring perspective, it may be difficult to verify what the entity is protecting versus what actually should be protected.  ReliabilityFirst requests the SDT to consider putting a list of typical data that should be protected per the standard and include it in a guideline document or rationale section.

    2. The standard, as written, states  “Risk mitigation shall be accomplished by one or more of the following actions: Physically protecting the communication links transmitting the data; Logically protecting the data during transmission; or Using an equally effective method to mitigate the risk of unauthorized disclosure or modification of the data.”  Since this is data in transit (over the “air”) ReliabilityFirst inquires on how one provides physical protections?  In addition to this, the selection of encryption cyphers, and key lengths are not required.  ReliabilityFirst suggests to place some language about encryption in a “technical basis”, explaining that there are different cyphers, some better than others, and after weighing the pros and cons of different cyphers and key lengths recommend the use of site-to-site IPV6 encapsulation with a specific cypher and key length.

Anthony Jablonski, ReliabilityFirst , 10, 9/5/2017

- 0 - 0

The term “plan” is misleading in this context.  A “plan” is more analogous to the development of a project that has actions to achieve a result by specific date; similar to an implementation plan for a NERC Reliability Standard. 

If it was the intention of the SDT to require a Responsible Entity to have a documented set of requirements to protect the sensitive BES data transmitted between the Control Centers then the term “policy” would be more appropriate.  A policy is interpreted to be more dynamic and ongoing throughout the lifetime of the requirement.   Additionally, as cyber security technology is constantly changing and evolving, a policy would allow for a definite course of action for a Responsible Entity to protect sensitive BES data transmitted between the Control Centers.

George Brown, Acciona Energy North America, 5, 9/6/2017

- 0 - 0

It is an overwhelming task to differentiate what is or what isn’t confidential communication data over data links between Control Centers.  As such, it is recommended that ALL data transmitted between Control Center be protected. The standards should just address all data communication between control centers.  Technologies such as encryption are generally implemented by link, not communication type.

- 0 - 0

The IESO agrees with the creation of a new standard, rather than expanding CIP-003, CIP-005 and/or CIP-006 requirements to provide new controls over physical communication links.  Specifically, the IESO commends the SDT for recognizing that not all utilities own or control their own physical communications links.

The IESO offers the following comments and recommendations.

  • R1. For data used for Operational Planning Analysis, Real-time Assessments, and Real-time monitoring, as documented by a Reliability Coordinator, Transmission Operator, or Balancing Authority, the Responsible Entity shall develop one or more documented plan(s) to mitigate the risk of the unauthorized disclosure or modification of the data while it is being transmitted between Control Centers. This excludes oral communications, regardless of transport means.

  • The note to R1 concerning the existence of a Control Center or specified data should be a dealt with in Section 4 – Applicability part of the Standard.    This would eliminate the need for this to be discussed as part of the RSAW.

  • Recommend that it be clarified whether this is a standalone Standard similar to CIP-014 or if it is intended to define the scope of applicable systems to be protected under CIP-003 thru CIP-011.

  • In order to evaluate the extent and kind of obligation involved, the definition of between control centers needs to be clearer with regard to the communication link. The Standard should address the proper demarcation points for obligation to show implementation and compliance. To clearly define the obligation of Responsible Entities, the required plan should include identification of the demarcation points. Information is also needed on the explicit agreements required on each end of the physical communication link to arrange and identify such demarcation. Where there is disagreement on how protections are to be applied between two or more Responsible Entities, what is the arbitration process to resolve these disagreements?

  • How is the situation handled where a Responsible Entity (e.g., an RC) is receiving information from a third-party provider that is aggregating and submitting data on behalf of one or more Responsible Entities (e.g., a TOP)? What is the identification of the demarcation points? In reading the standard, it does not appear that the connection to the third-party provider is in scope since they are not a Responsible Entity or even registered with NERC. The same situation may be present for entities that use an outsourced data center provider. The question is also relevant for the data that is provided to regulatory agencies that are not bound by CIP Standards.

Leonard Kula, Independent Electricity System Operator, 2, 9/7/2017

- 2 - 0

The scope of the term “data” is unclear.  Does “data” apply to all data or just machine to machine (e.g. automated) communications? If it is all data would emails/ftp/etc. be in scope?

Con Edison, Segment(s) 1, 3, 5, 6, 6/24/2016

- 0 - 0

FMPA does not agree with the revision of Requirement 1 (R1) because the obligation is not clear. The R1 note - “If the Responsible Entity does not have a Control Center or it does not transmit the type of data specified in Requirement R1 of CIP-012-1 between two Control Centers, the requirements in CIP-012-1 would not apply to that entity.”- should be in the Section 4 Applicability. This would eliminate the need for this to be discussed as part of the RSAW.

In order to evaluate the extent and kind of obligation involved with R1, the phrase “transmitted between two control centers,” needs to be clearer.  FMPA believes that there should be more clarity or identification on the demarcation points of the link being protected.

Both TOP-003 and IRO-010 have a requirement that there be a mutually agreeable security protocol.  It is not clear why a new standard needs to be developed to address this same issue. The SDT should consider modifying TOP-003 and IRO-010 if these standards do not provide adequate language to meet Order No. 822’s concerns.

FMPA, Segment(s) , 8/2/2017

- 0 - 0

There is a lack of language within the Requirement that specifies the demarcation point for compliance between applicable Control Centers.

Frank Pace, Central Hudson Gas & Electric Corp., 1, 9/7/2017

- 0 - 0

The applicability of the expression, “between Control Centers,” does not appear to be restricted to transmittals between Control Centers owned by a single entity; exchanges between GO and TO/TOP Control Centers would be covered also, for example.  This makes sense as regards achieving a high degree of security, but could create confusion regarding who is responsible for inter-entity transmittals.  CIP-012-1 should state that GO/GOP obligations for inter-entity exchanges between Control Centers are fulfilled if they follow the data specifications provided by the other party (ref. IRO-010-2 and TOP-003-3).

Donald Lock, 9/8/2017

- 0 - 0

  1. The Note to R1 concerning the existence of a Control Center or specified data should be a dealt with in Section 4 – Applicability. This would eliminate the need for this to be discussed as part of the RSAW.
  2. In order to evaluate the extent and kind of obligation involved, the definition of between control centers needs to be more clear with regard to the communication link. What are the demarcation points for obligation to show compliance? 
  3. Request clarification does the 15 minute impact CIP-002 identification of BES Cyber Systems affect the applicability of CIP-012?

David Rivera, New York Power Authority, 3, 9/8/2017

- 0 - 0

The Requirement should only permit the option to logically protect the data during transmission or at least remove the explicit options to physically protect the data. We understand the Requirement is consistent with CIP-006 R1.10, but this Requirement addresses communication lines within the same facility, and for which physical protection is possible. Cryptography is the only mechanism available to protect data across geographically dispersed Control Centers. Stating other options is confusing and has a strong potential to guide the industry toward ineffective solutions.

However, if the intent is to allow physical protection of communications of Control Centers in the same geographical location, then make it clear in the Technical Guidelines the scenarios and alternative solutions the drafters had in mind.

Philip Huff, 9/8/2017

- 0 - 0

Kristine Ward, On Behalf of: Seminole Electric Cooperative, Inc., FRCC, Segments 1, 2, 4, 5, 6

- 0 - 0

The applicability of the expression, “between Control Centers,” does not appear to be restricted to transmittals between Control Centers owned by a single entity; exchanges between GO and TO/TOP Control Centers would be covered also, for example.  This makes sense as regards achieving a high degree of security, but could create confusion regarding who is responsible for inter-entity transmittals.  CIP-012-1 should state that GO/GOP obligations for inter-entity exchanges between Control Centers are fulfilled if they follow the data specifications provided by the other party (ref. IRO-010-2 and TOP-003-3).

Jennifer Hohenshilt, Talen Energy Marketing, LLC, 6, 9/8/2017

- 0 - 0

Colorado Springs Utilities, Segment(s) 5, 3, 1, 6, 5/6/2015

- 0 - 0

As mentioned by the SDT, FERC directs that “…require responsible entities to implement controls to protect, at a minimum, communication links and sensitive bulk electric system data communicated between bulk electric system Control Centers…”.  First, having a plan does not add to the reliability of protecting said data.  This is an unwarranted layer of compliance that is not needed.  Everything does not need a plan in order to be protected.   Recommend that R1 be written in parallel to the FERC directive, which does not require a plan (per the SDTs Consideration of Issues and Directives).   

If “Plan” is maintained in CIP-012-1 then, the SDT should explain what is meant by having a Plan?  Per CIP-003-6 it states, The terms program and plan are sometimes used in place of documented processes where it makes sense and is commonly understood. For example, documented processes describing a response are typically referred to as plans (i.e., incident response plans and recovery plans). Likewise, a security plan can describe an approach involving multiple procedures to address a broad subject matter.  Is a plan the template document which is used throughout our Standards or is it a set of controls that show that the data is being protected per R1?  The NSRF does not understand why a Plan is needed when the data is being protected by physical or electronic means.  If a Plan is required, then all the Plan is going to say is that the cabling that transfers data is in a protected conduit (or other means) between Control Centers.

Secondly, The NSRF questions why the SDT is not in line with the FERC Order to “…protect …data…” but the proposed R1 states to “…mitigate the risk of unauthorized disclosure or modification of data…”? 

R1 should be rewritten to state: “The responsible entity shall have controls (or other understandable words) in place to protect against the unauthorized disclosure or modification of BES data used for Operational Planning Analysis, Real-time Assessments, and Real-time monitoring while being transmitted between BES Control Centers. This excludes oral communications”.   Please note that the word “BES” is needed within R1 regardless of it our proposed rewrite is accepted or not.

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

- 0 - 0

See attachment

Alice Wright, Arkansas Electric Cooperative Corporation, 4, 9/8/2017

2016-02_CIP-012-1_Comment_Form_07272017-AECC Comments.pdf

- 0 - 0

Texas RE appreciates the Standard Drafting Team’s (SDT) efforts to develop a workable approach to mitigate the risk of unauthorized disclosure or modification of certain categories of Control Center communications.  However, Texas RE is concerned that the proposed CIP-012-1 R1 does not fully satisfy the directives established by the Federal Energy Regulatory Commission (FERC) in FERC Order No. 822.  Texas RE is likewise concerned that the proposed CIP-012-1 may not adequately address third-party entities handling sensitive data between Control Centers in the Texas RE region.

 

First, throughout its discussion concerning new requirements for protecting Control Center communications, FERC emphasized that additional protections were required to protect both the “integrity and availability of sensitive bulk electric system data.”  FERC Order No. 822, P. 54.  FERC made clear that this involved, at a minimum, two discrete actions.  First, FERC stressed that entities should implement controls to protect the physical communications links transmitting sensitive data between Control Centers.  Second, FERC noted that the sensitive data itself needed to be protected to ensure its accuracy and consistency.  In issuing the directive underpinning this rulemaking, FERC stated:  “we adopt the NOPR proposal and direct that NERC . . . develop modifications to the CIP Reliability Standards to require responsible entities to implement controls to protect, at a minimum, communications links and sensitive bulk electric system data communicated between bulk electric system Control Centers . . . FERC Order No. 822, P. 53 (emphasis added). 

 

FERC made it clear that protections should apply to both communication links and sensitive data.  However, the proposed draft of CIP-012-1 R1 potentially applies only to physical protections for communications links or to logical protections for data during its transmission.  That is, responsible entities could simply elect to plan and implement physical protections for communications links.  This would “mitigate” the risk of an unauthorized disclosure or modification of data using one of the delineated methods.  As such, the responsible entity would potentially be compliant with the Standard without proposing or implementing any logical protections for sensitive data during its transmission.  This appears counter to FERC’s intent to protect “both the integrity and availability of sensitive bulk electric system data.”  FERC Order No. 822, P. 54. 

 

Second, Texas RE is concerned that the proposed CIP-012-1 standard may result in confusion, particularly among Generation Operators with Control Centers subject to the standard regarding the scope of their compliance obligations or, alternatively, may inadvertently result in a significant reliability gap given the structure of the ERCOT market.  In ERCOT, generators do not communicate directly with the regional Reliability Coordinator (ERCOT).  Instead, generators are required to communicate through designated entities known as Qualified Scheduling Entities (QSEs).  In many instances, these QSEs are third-party entities.  Within the NERC regulatory construct, Generator Operators have delegated certain NERC compliance functions to these entities, including providing data used for Operational Planning Analysis, Real-time Assessments, and Real-time monitoring.  Critically, Generator Operators remain responsible for all compliance obligations associated with QSE activities in the ERCOT region. 

 

In light of this market and regulatory framework, Texas RE interprets the proposed draft of CIP-012-1 to likewise require Generator Operators possessing Control Centers to take steps to mitigate the risk of unauthorized data disclosures at every step along the communication chain between its Control Center and the ERCOT Control Center, including steps to protect this data at third-party intermediary QSEs.  Otherwise, the proposed draft of CIP-012-1 would result in a significant reliability gap as QSE communications links and data passing from the QSE to ERCOT could be potentially unsecure.  Given this fact, Generator Operators will likely need to take steps to ensure that their third-party QSEs have accorded designated sensitive data appropriate protections, which could in turn require incorporating such requirements into QSE agreements or other steps.  Texas RE requests the SDT clarify that communications between QSEs (or equivalent in other Regions) and the RC are subject to CIP-012-1 requirements and that Responsible Entities must take steps to address mitigate the risk of unauthorized data disclosures for these communications as well in order to ensure that Responsible Entities have sufficient notice of these compliance obligations. 

Rachel Coyne, Texas Reliability Entity, Inc., 10, 9/8/2017

- 0 - 0

See APPA Comments.

Seattle City Light Ballot Body, Segment(s) 1, 4, 6, 5, 3, 12/2/2016

- 0 - 0

Exelon agrees with the approach of the latest revision, which provides latitude to protect the communication links, the data, or both, to satisfy the security objective consistent with the capabilities of the Responsible Entity’s operational environment.

We do, however, question the placement of the “Note” portion within R1.  The Note applies not just to R1, but to CIP-012-1 as a whole.  Is there a reason for not including this under Section 4 Applicability, as an exemption? 

Daniel Gacek, Exelon, 1, 9/8/2017

- 0 - 0

Recommend removing “Operational Planning Analysis” from this requirement.  Operational Planning Analysis is not Real-time data and would not affect the BES within 15 minutes.  The TOP-003-3 Standard currently requires a mutually agreeable security protocol for sharing of data required for Operational Planning Analyses.

Santee Cooper, Segment(s) 1, 9/8/2017

- 0 - 0

NCPA does not feel CIP-012-1 is needed as both TOP-003 R5 and IRO-010 R3 require Registered Entities (REs) to use a mutually agreeable security protocol.  The SDT should consider modifying TOP-003 and IRO-010 if these standards do not provide adequate language to meet Order No. 822’s concerns.  Also please refer to other APPA, TAPs, and Utility Services comments.

Marty Hostler, Northern California Power Agency, 4, 9/8/2017

- 0 - 0

Steven Mavis, 9/8/2017

- 0 - 0

See comments submitted by Robert Blackney on NERC’s proposed modifications to the definition of Control Center

Thomas Rafferty, 9/8/2017

- 0 - 0

NCPA does not feel CIP-012-1 is needed as both TOP-003 R5 and IRO-010 R3 require Registered Entities (REs) to use a mutually agreeable security protocol.  The SDT should consider modifying TOP-003 and IRO-010 if these standards do not provide adequate language to meet Order No. 822’s concerns.  Also please refer to other APPA, TAPs, and Utility Services comments.

Dennis Sismaet, Northern California Power Agency, 6, 9/8/2017

- 0 - 0

Please see the attached document for Arizona Public Service Co.'s answer to Question 1. 

Vivian Moser, 9/10/2017

2016-02 Modifications to CIP Standards CIP-012-1 - Answer to Question 1.docx

- 0 - 0

The applicability section of the Standard should specify that the requirements only apply to entities with Control Centers. This would allow the elimination of the note to R1 and would simplify the ERO monitoring process.

David Gordon, 9/11/2017

- 0 - 0

FirstEnergy Corporation, Segment(s) 4, 1, 3, 5, 6, 4/11/2017

- 0 - 0

What does, “Physically protecting the communication links transmitting the data,” mean? A Registered Entity is able to physically protect its end point, but is not able to physically protect the communication link for the entire communication link. Please define “logical protection” to provide clarification for entities for implementation and compliance oversight.

 

What does, “Using an equally effective method to mitigate the risk of unauthorized disclosure or modification of the data” mean?

Heather Morgan, EDP Renewables North America LLC, 5, 9/11/2017

- 0 - 0

The Purpose section of CIP-012-1 adds the need to protect the confidentiality of data which is out of Scope of FERC order 822. Although it is recognized that the SDT is not limited to just FERC orders, adding need to protect the confidentiality of data does not add reliability if the data is being protected per CIP-012-1 R1.

 

Eversource Group, Segment(s) 5, 3, 9/11/2017

- 0 - 0

AEP suggests that a new requirement(s) be added to establish a hierarchy for REs that requires entities at the top with the most risk to set the communications security protocols.  And, modify the existing R1 to require REs to have plans that follow the protocols set by the entities identified in the new requirement(s).

Aaron Austin, 9/11/2017

- 0 - 0

NRECA agrees with the construct of the standard and its requirements, but not the scope of sensitive BES data as detailed in the response to question 2.

Barry Lawson, 9/11/2017

- 0 - 0

  1. The Note to R1 concerning the existence of a Control Center or specified data should be a dealt with in Section 4 – Applicability. This would eliminate the need for this to be discussed as part of the RSAW.

  2. In order to evaluate the extent and kind of obligation involved, the definition of between control centers needs to be more clear with regard to the communication link. What are the demarcation points for obligation to show compliance? 

  3. Request clarification does the 15 minute impact CIP-002 identification of BES Cyber Systems affect the applicability of CIP-012?

  4. Concerns exist with the relationships regarding implementation of CIP-012 with other NERC Standards such as IRO, TOP, CIP-006 R1 Part1.10

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

- 0 - 0

SRP requests the SDT consider differentiating requirements for Control Center communications within an entity from those for Control Center communications between entities. Because data being sent for TOP-003 and IRO-010 traverses over the ICCP network maintained by a carrier, entities cannot provide physical protections for communication of this data from end to end. In this case, protecting the confidentiality and integrity can only be done through encryption. However, since no one utility owns the hardware end to end on the ICCP network, site to site encryption cannot be implemented. The only options available would be application layer encryption or transport layer encryption utilizing IEC 62351-4 Secure ICCP.

For IRO-010 data, the RC in the Western Interconnect requires real-time data to be sent every 10 seconds. Likewise, For TOP-003 data, SRP is required to send and receive real-time data every 10 seconds to and from various other entities on the ICCP network within the Western Interconnect. It is unclear the amount of latency that may be added or amount of computing resources required to encrypt and decrypt this data every 10 seconds. Additionally, the RC would be receiving this data from all applicable utilities in the Western Interconnect. If all entities encrypt and send data every 10 seconds, it is unclear how much latency would be added and computing resources would be required by the RC to decrypt the large amount data. It is also unclear how the added latency would affect the real-time operations of the Bulk Electric System. IRO and TOP data specification changes may be necessary to address delays in data due to latency, or process/procedure changes to mitigate effects on real-time operations. SRP suggests performing a study or survey to determine how much data is being sent and received and what the effects would be from the added latency and the amount of extra computing resources required.

SRP requests clarification on the exclusion of oral communications. Additionally, SRP suggests the exclusion for oral communications be expanded to also exclude electronic mail.

SRP requests clarification for what would be accepted as physical security either in the measures or Technical Rationale and Justification. SRP also requests clarification of what equally effective methods are in the measures or Technical Rationale and Justification.

Lona Calderon, On Behalf of: Salt River Project, WECC, Segments 1, 3, 5, 6

- 0 - 0

As mentioned by the SDT, FERC directs that “…require responsible entities to implement controls to protect, at a minimum, communication links and sensitive bulk electric system data communicated between bulk electric system Control Centers…”.  First, having a plan does not add to the reliability of protecting said data.  This is an unwarranted layer of compliance that is not needed.  Everything does not need a plan in order to be protected.   Recommend that R1 be written in parallel to the FERC directive, which does not require a plan (per the SDTs Consideration of Issues and Directives).   

 

If “Plan” is maintained in CIP-012-1 then, the SDT should explain what is meant by having a Plan?  Per CIP-003-6 it states, The terms program and plan are sometimes used in place of documented processes where it makes sense and is commonly understood. For example, documented processes describing a response are typically referred to as plans (i.e., incident response plans and recovery plans). Likewise, a security plan can describe an approach involving multiple procedures to address a broad subject matter.  Is a plan the template document which is used throughout our Standards or is it a set of controls that show that the data is being protected per R1?  We do not understand why a Plan is needed when the data is being protected by physical or electronic means.  If a Plan is required, then all the Plan is going to say is that the cabling that transfers data is in a protected conduit (or other means) between Control Centers.

 

Secondly, we question why the SDT is not in line with the FERC Order to “…protect …data…” but the proposed R1 states to “…mitigate the risk of unauthorized discloser or modification of data…”? 

 

R1 should be rewritten to state: “The responsible entity shall have controls (or other understandable words) in place to protect against the unauthorized disclosure or modification of BES data used for Operational Planning Analysis, Real-time Assessments, and Real-time monitoring while being transmitted between BES Control Centers. This excludes oral communications”.   Please note that the word “BES” is needed within R1 regardless of it our proposed rewrite is accepted or not.

Thomas Breene, WEC Energy Group, Inc., 3, 9/11/2017

- 0 - 0

Xcel Energy agrees with and support the comments submitted by the MRO Standards Review Forum (NSRF) in regards to this question.

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

- 0 - 0

Cowlitz PUD supports the comments submitted by APPA.

Russell Noble, Cowlitz County PUD, 3, 9/11/2017

- 0 - 0

Jesus Sammy Alcaraz, Imperial Irrigation District, 1, 9/11/2017

- 0 - 0

·         The Note to R1 concerning the existence of a Control Center or specified data should be a dealt with in Section 4 – Applicability. This would eliminate the need for this to be discussed as part of the RSAW.

 

·         In order to evaluate the extent and kind of obligation involved, the definition of between control centers needs to be clearer with regard to the communication link. What are the demarcation points for obligation to show compliance? 

 

·         Request clarification does the 15 minutes impact CIP-002 identification of BES Cyber Systems affect the applicability of CIP-012?

RSC no Con-Edison and Dominion, Segment(s) 10, 2, 4, 5, 6, 7, 1, 3, 9/11/2017

- 0 - 0

ERCOT ISO signs on to the ITC SWG comments:

The ITC SWG agrees with the creation of a new standard, rather than expanding CIP-003, CIP-005 and/or CIP-006 requirements to provide new controls over physical communication links.  Specifically, the ITC SWG commends the SDT for recognizing that not all utilities own or control their own physical communications links.

The ITC SWG offers the following comments and recommendations.

  • R1. For data used for Operational Planning Analysis, Real-time Assessments, and Real-time monitoring, as documented by a Reliability Coordinator, Transmission Operator, or Balancing Authority, the Responsible Entity shall develop one or more documented plan(s) to mitigate the risk of the unauthorized disclosure or modification of the data while it is being transmitted between Control Centers. This excludes oral communications, regardless of transport means.

  • The note to R1 concerning the existence of a Control Center or specified data should be a dealt with in Section 4 – Applicability part of the Standard.    This would eliminate the need for this to be discussed as part of the RSAW.

  • Recommend that it be clarified whether this is a standalone Standard similar to CIP-014 or if it is intended to define the scope of applicable systems to be protected under CIP-003 thru CIP-011.

  • In order to evaluate the extent and kind of obligation involved, the definition of between control centers needs to be clearer with regard to the communication link. The Standard should address the proper demarcation points for obligation to show implementation and compliance. To clearly define the obligation of Responsible Entities, the required plan should include identification of the demarcation points. Information is also needed on the explicit agreements required on each end of the physical communication link to arrange and identify such demarcation. Where there is disagreement on how protections are to be applied between two or more Responsible Entities, what is the arbitration process to resolve these disagreements?

  • How is the situation handled where a Responsible Entity (e.g., an RC) is receiving information from a third-party provider that is aggregating and submitting data on behalf of one or more Responsible Entities (e.g., a TOP)? What is the identification of the demarcation points? In reading the standard, it does not appear that the connection to the third-party provider is in scope since they are not a Responsible Entity or even registered with NERC. The same situation may be present for entities that use an outsourced data center provider. The question is also relevant for the data that is provided to regulatory agencies that are not bound by CIP Standards.

 

Elizabeth Axson, 9/11/2017

- 0 - 0

We support SERC's comments.

Louisville Gas and Electric Company and Kentucky Utilities Company, Segment(s) 3, 5, 6, 4/13/2017

- 0 - 0

Tacoma Power suuports the commetns of APPA

Marc Donaldson, Tacoma Public Utilities (Tacoma, WA), 3, 9/11/2017

- 0 - 0

WAPA agrees with the comments submitted by the NSRF (attached)

sean erickson, Western Area Power Administration, 1, 9/11/2017

Project 2016-02_CIP-012-1_NSRF Final.docx

- 0 - 0

See APPA Comments.

Theresa Rakowsky, 9/11/2017

- 0 - 0

APPA does not agree with the revision of Requirement 1 (R1) because the obligation is not clear. The R1 note - “If the Responsible Entity does not have a Control Center or it does not transmit the type of data specified in Requirement R1 of CIP-012-1 between two Control Centers, the requirements in CIP-012-1 would not apply to that entity.”- should be in the Section 4 Applicability. This would eliminate the need for this to be discussed as part of the RSAW.

Evaluation of the extent and kind of obligation involved with R1, requires a clearer phrase than, “transmitted between two control centers.” Public power believes that there should be more clarity or identification on the demarcation points of the link being protected.

Both TOP-003 and IRO-010 have a requirement that there be a mutually agreeable security protocol. It is not clear why a new standard needs to be developed to address this same issue. The SDT should consider modifying TOP-003 and IRO-010 if these standards do not provide adequate language to meet Order No. 822’s concerns.

Jack Cashin, American Public Power Association, 4, 9/11/2017

- 0 - 0

CenterPoint Energy Houston Electric, LLC (“CenterPoint Energy”) recommends adding more clarification on the scope of the term “communication links.”  Data used for Operational Planning Analysis (OPA), Real-time Assessments (RTA), and Real-time monitoring (RTM) is collected based on an Entity-issued data specification, per TOP-003-3 and IRO-010-2.  This data is collected through a medium referred to as “data exchange capability,” as required by TOP-001-4 (Requirements R19 and R20) as well as IRO-002-5 (Requirements R1 and R2). 

OPA data is typically not transmitted via a communication link, and OPA data presents lower risk to operations than real-time telemetry data exchanged via ICCP communication links between Control Centers.  The systems used to transmit the OPA data can be located outside Control Centers and are not considered BES Cyber Systems since they do not impact the Bulk Electric System within 15 minutes.  Thus, CenterPoint Energy believes OPA data should not be within the scope of Requirement R1.

In addition to removing OPA from Requirement R1, CenterPoint Energy recommends revising Requirement R1 to include the term “inter and intra Control Center communication links.”  This revision aligns with the language in Federal Energy Regulatory Commission (“FERC”) Order No. 822.  The proposed revised language is below:

“The Responsible Entity shall develop one or more documented plan(s) to mitigate the risk of the unauthorized disclosure or modification of data used for Real-time Assessments and Real-time monitoring while being transmitted between inter and intra Control Centers communication links. This excludes oral communications.”

Lan Nguyen, On Behalf of: CenterPoint Energy Houston Electric, LLC, Texas RE, Segments 1

- 0 - 0

SERC CIPC, Segment(s) 10, 1, 2, 5, 9, 8/19/2016

3B-2016-02_CIP-012-1_Unofficial_Comment_Form_CIPC.docx

- 0 - 0

(1)  We agree with the direction of the requirement, however, the wording of the “one of more of” phrase seems to be in conflict with the intention of physical and logical protection.  How can you protect the data without physical security, and how can you ensure data integrity without logical protection?  The “one or more of” reference should be stricken.

 

(2)   We recommend the addition of wording that clearly excludes Low impact Entities from compliance with this requirement. Would a low impact control room which communicates with a Control Center be out of scope?

 

(3)   We propose moving the compliance applicability note that follows Requirement R1 to the applicability section of the standard, particularly Section 4.2 Exemptions.

ACES Standards Collaborators, Segment(s) 1, 3, 4, 5, 9/11/2017

- 0 - 0

See comments submitted by Robert Blackney on NERC’s proposed modifications to the definition of Control Center.

Kenya Streeter, Edison International - Southern California Edison Company, 6, 9/11/2017

- 0 - 0

PSEG REs, Segment(s) 5, 6, 3, 1, 3/6/2017

- 1 - 0

In order to evaluate the extent and kind of obligation involved, the definition of between control centers needs to be clearer with regard to the communication link.  What are the demarcation points for obligation to show compliance?  Should there be explicit agreements with each end of the communication link to arrange such demarcation?  How should responsible entities deal with third parties involved with trust relationships in communication links (i.e. telecommunications providers managing routers)?

Michael Puscas, ISO New England, Inc., 2, 9/11/2017

- 0 - 0

The requirement as written does not provide clear definition on what type of data needs to be protected, and how exactly the physical/logical protection approach should be accomplished.

David Greyerbiehl, CMS Energy - Consumers Energy Company, 5, 9/11/2017

- 0 - 0

BPA appreciates the revisions that the SDT has made based on industry feedback on the SAR.

BPA reiterates its position as documented in our SAR comments that CIP-012-1 is not necessary.

Alternate proposal #1:  The objectives can be met by coordinating with existing standards such as CIP-003 and CIP-005.

If CIP-012-1 moves forward, there are areas requiring clarification.  FERC Order No. 822 requires implementation of controls to protect, at a minimum, communication links AND sensitive BES data communicated between BES Control Centers.  However, the SDT is providing latitude to protect communication links, data or both.  If it is an “AND” as stated in Order No. 822, it is not always technically feasible to implement both controls to protect communication links and sensitive BES data communicated between BES Control Centers.

Points of discussion:

Implementation of controls to protect the data:

  • Encryption may not be feasible due to availability concerns. (e.g., failure of encryption keys or latency problems with encryption for availability requirements.)

Implementation of controls on communication links:

  • The use of the term communication links may be broadly interpreted and difficult to audit.

  • It may not be technically feasible to implement physical controls, for example:

    • on fiber optic cable on power lines

    • on a common carrier system where the links are unknown

    • for wireless communications - how does an entity physically protect the air between endpoints?

Additionally, entities and common carriers use a variety of media to carry traffic, and will undoubtedly use traffic shaping to maintain service levels: routing becomes unpredictable; each packet could take a different route from point A to B. 

If an entity owns the communication network from end to end, this is still a problem. Modern routing protocols will try to deliver packets over a system with inoperable equipment, severed links, etc.  The only remedy is to physically protect the entire communication system in advance of system faults to satisfy CIP-012.  If one packet traverses a link due to a system fault that is not protected – it would be a violation.

If FERC agrees with the SDT’s proposal of allowing the entity the latitude to protect the data, communication links or both, BPA believes the security objective will not be met.  BPA recommends placing controls on the data AND end points where technically feasible.  However BPA recommends moving R1.1 to a Technical Guidance, considering there are multiple implementation methods for controls on data and end points.

Aaron Cavanaugh, On Behalf of: Bonneville Power Administration, WECC, Segments 1, 3, 5, 6

- 0 - 0

The requirement as written does not provide clear definition on what type of data need to be protected, and how exactly the physical/logical protection approach should be accomplished by an entity.

James Anderson, 9/11/2017

- 0 - 0

Utility Services does not agree with the revision of Requirement 1 (R1) because the obligation is not clear. The R1 note - “If the Responsible Entity does not have a Control Center or it does not transmit the type of data specified in Requirement R1 of CIP-012-1 between two Control Centers, the requirements in CIP-012-1 would not apply to that entity.”- should be in the Section 4 Applicability. This would eliminate the need for this to be discussed as part of the RSAW.

 

In order to evaluate the extent and kind of obligation involved with R1, the phrase “transmitted between two control centers”, needs to be clearer.  Public power believes that there should be more clarity or identification on the demarcation points of the link being protected. 

 

 

Both TOP-003 and IRO-010 have a requirement that there be a mutually agreeable security protocol.  It is not clear why a new standard needs to be developed to address this same issue. The SDT should consider modifying TOP-003 and IRO-010 if these standards do not provide adequate language to meet Order No. 822’s concerns.

 

Brian Evans-Mongeon, Utility Services, Inc., 4, 9/11/2017

- 0 - 0

Robert Blackney, On Behalf of: Edison International - Southern California Edison Company, WECC, Segments 1, 3, 5, 6

- 0 - 0

Southern Company has concerns with the phrase “data used for Operational Planning Analysis, Real-time Assessments, and Real-time monitoring” in CIP-012 R1.   We understand this is a direct quote from TOP-003 R1 and IRO-010 R1 and the intent is for this phrase to point to the data specification required by those standards.  We understand there is a paragraph to this effect in the Technical Rationale document which is not a binding document.  Our concern is that the requirement says “data used for…” and without a stronger bind to the IRO and TOP standards we believe this opens the scope of CIP-012 to yet another data definition exercise rather than a specific requirement to protect an already defined data specification while that data is being transferred between Control Centers. 

 The draft RSAW for R1 puts this concern in writing.  It does not instruct the auditor to use the specifications from TOP-003/IRO-010 Requirement 1 and verify that this previously defined data is protected while being transferred between Control Centers.  Instead it requires the auditor to verify

“The documented plan(s) collectively address all data used for Operational Planning Analysis, Real-time Assessments, and Real-time monitoring transmitted between Control Centers”  

It then includes glossary definitions for two of those terms.  The auditor is instructed to look at two definitions, determine a definition of the undefined “Real-time monitoring”, and then verify that all such data is protected.  This effort alone dwarfs the true purpose of the standard which is protecting those communications links over which BES Control Centers communicate system status with each other in real time.

 We suggest an alternative to resolve this issue.  First, we suggest that a data centric approach is problematic for these and other reasons and we strongly suggest a more technical approach that focuses CIP-012 on securing communication sessions and/or links based on their destination.  For example, data that is leaving the ESP or LEAP of a Control Center that has a destination address of an ESP or LEAP at another Control Center should be encrypted.   That is very distinct and concrete and much simpler to implement and demonstrate and we believe is in line with FERC Order 822, paragraph 60 where the Commission outlines the reliability gap to be addressed.

 If this alternative is not acceptable, we suggest that R1 be modified to make the previously defined data specification the noun rather than “data used for…”.  Additionally, we suggest removing “Operational Planning Analysis” from the first paragraph of R1 as Operational Planning Analysis data does not impact the BES within 15 minutes.

 For example:  “The Responsible Entity shall develop one or more documented plan(s) to mitigate the risk of the unauthorized disclosure or modification of data used for Real-time Assessments and Real-time monitoring as specified by the Reliability Coordinator or Transmission Operator while such data is being transmitted between Control Centers. This excludes oral communications.”

 We also strongly suggest, based on questions in the draft RSAW, that the SDT consider moving any language relating to applicability to the Applicability section of the standard rather than having a note in the requirement language.  With the inclusion of the note in the requirement, we notice the draft RSAW starts with questions for all the responsible entities that do not have Control Centers to prove the negative, which should instead defer any auditor to the compliance auditing process of CIP-002-5.1.

Southern Company, Segment(s) 1, 3, 5, 6, 8/3/2016

- 0 - 0

OPG has concerns with potential issues arising from communication links not owned by entity.

Potential issues can also occur when the communication is performed between the CC belonging to different entities; how is the demarcation point determined.

David Ramkalawan, 9/11/2017

- 0 - 0

Tampa Electric Company suggests that the SDT provide additional instruction within the standard to address the requirements and implications for BA’s that serve as the BA for other entities in the BA’s service area. It would be helpful to understand the BA’s responsibility to mitigate the risk of unauthorized disclosure or modification of data used for the analysis, assessment and monitoring.  In addition, does this standard extend to communications between a Registered Entities and the Reliability Coordinators such as FRCC’s RC in relation to communication between Control Centers?

Ronald Donahey, TECO - Tampa Electric Co., 3, 9/11/2017

- 0 - 0

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

- 0 - 0

The SPP Standards Review Group has reviewed documentation and have developed some concerns in reference to Requirement R1. The CIP Version 5 Transition Advisory Group (V5TAG) identified specific issues with the CIP Version 5 standard language that caused difficulty in implementation of the requirements.  This requirement or a supplemental to CIP-005 needs to clarify the 4.2.3.2 exemption phrase “between discrete Electronic Security Perimeters.” When there is not an ESP at the location, consider clarity that the communication equipment considered out of scope is the same communication equipment that would be considered out of scope if it were between two ESPs or a single ESP.  This should be address either in this standard, as an Exemption added or requirement added to CIP-005-6. 

Here is proposed language for the Exemption: 

4.2.3. Exemptions: The following are exempt from Standard CIP‐002‐5.1:

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

Commission.

4.2.3.2. Exemption of Communication Equipment that is owned and operated by a Third Party Communication Carrier or its equivalent is exempted from the CIP standards that is communicating between system end points

Cyber Assets associated with communication networks and data (striking this information)

communication links between discrete Electronic Security Perimeters. (striking this information)

Or added to CIP-005-6 R1

 

CIP-005-5 Table R1 – Electronic Security Perimeter

Part

1.6

Applicable

 

High Impact BES Cyber Systems and their associated:

  • PCA

Medium Impact BES Cyber Systems with External Routable Connectivity and their associated:

  • PCA

Requirements

For defined ESPs that use wide-area communications networks (e.g. ESPs that span multiple geographic locations), Cyber Assets associated with communication networks and data communication links used to facilitate the ESP and owned by a third party are exempt from the CIP Reliability Standards provided that the communications traversing across these Cyber Assets are encrypted. The Cyber Assets that encrypt and decrypt the communications are EACMS.

Measures

An example of evidence may include, but is not limited to, network diagrams showing all communication networks, vendor owned equipment, and encryption/decryption Cyber Assets.

There are two major reasons for addressing this issue listed above.  1) This was identified by the V5TAG group and can be easily fixed with one of the two suggestions listed above.    Reason 2) is because Registered Entities may expand their ESP’s to cover both control centers to handle R1.1 in regards of:

  • Logically protecting the data during transmission; or (Provide example or measures)

  • Using a measurements to mitigate the risk of unauthorized disclosure or modification of the data.

     

SPP Standards Review Group, Segment(s) , 9/11/2017

- 0 - 0

Reclamation recommends the SDT use the term “documented processes” consistently throughout the CIP standards. Pursuant to CIP-003-6,

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

 

Reclamation disagrees that having a plan adds to the reliability of protecting data used for Operational Planning Analysis, Real-time Assessment, and Real-time monitoring. A plan is an unwarranted layer of compliance that is not needed. Reclamation recommends that R1 be written in parallel with the FERC Order 822, which directed the development of controls to protect communication links and data. Reclamation recommends R1 could be rewritten to state: “The responsible entity shall have documented processes in place to mitigate the risk of the unauthorized disclosure or modification of BES data used for Operational Planning Analysis, Real-time Assessments, and Real-time monitoring while being transmitted between BES Control Centers. This excludes oral communications.” Reclamation recommends that the word “BES” be added to R1 regardless of whether the SDT accepts the rest of the above proposed language.

 

If the requirement for a plan is retained, Reclamation recommends the SDT clarify what is meant by having a plan and how a plan is different from a documented process.

 

Reclamation recommends using the following definitions of “plan” and “process:”

Plan: Written account of intended future course of action (scheme) aimed at achieving specific goal(s) or objective(s) within a specific timeframe. It explains in detail what needs to be done, when, how, and by whom, and often includes best case, expected case, and worst case scenarios. See also planning.

 

Process: Sequence of interdependent and linked procedures which, at every stage, consume one or more resources (employee time, energy, machines, money) to convert inputs (data, material, parts, etc.) into outputs. These outputs then serve as inputs for the next stage until a known goal or end result is reached.

Wendy Center, U.S. Bureau of Reclamation, 5, 9/11/2017

- 0 - 0

We have attached our comments in the last question for the definition of Control Center.  We are recommending changes to this definition.

- 0 - 0

ATC believes the language should be in better alignment with the directives of the FERC order to establish a plan and implement controls to address the risks posed to the BES.  ATC also believes the requirement language should be less prescriptive as it relates to data types. ATC believes the Requirement language must allow an appropriate level of flexibility for Registered Entities to identify and document the risks posed to the BES and the corresponding data to assure implemented controls are (and remain) commensurate with risk. The requirement should be focused on the achievement and ongoing sustainability of the security objective in order to permit adaption of their plan(s) and the associated implemented controls such that they are designed to effectively address the current and emerging risks posed to BES Control Center assets and information as the threat landscape changes.  Some potential language for consideration is:

“R1. For sensitive Bulk Electric System (BES) data communicated between BES Control Centers, Responsible Entities shall establish and implement one or more documented plans that collectively identifies and addresses:

R1.1. the communication links capable and purposed for the transport of BES data between BES Control Centers

R1.2. the risks posed to the BES from the transport of the BES data between BES Control Centers

R1.2. the BES data subject to the risk

R1.3. the protective measures and security practices designed and implemented to mitigate the identified risks.

R1.4. the process and cycle to review and update the plan(s) to maintain alignment with risks posed

BES data excludes oral communications.”   

Lauren Price, 9/11/2017

- 0 - 0

AECI agrees with the construct of the standard and its requirements, but not the scope of sensitive BES data as detailed in the response to question 2.

Mark Riley, Associated Electric Cooperative, Inc., 1, 9/11/2017

- 0 - 0

  • GSOC (Georgia Systems Operations Corporation) requests that the Standards Drafting team provide formal CIP-012 Guidance and Technical Basis (GTB) or Implementation Guidance, either within the Standard or as separate documentation.  This is crucial for an entity’s understanding of how to meet the compliance objective of a new Standard.
  • GSOC requests clarification regarding:
  • he applicability of the Standard to TOs.  This Standard should apply only TOs who own or operate Control Centers.  An example of modifying the applicability can be found in MOD-025-2.
  • the precise nature of Operator-to-Operator communications. “Oral Communications” are excluded.  However, EOP-008 (Emergency Operating) Plans often specify using cell/text/email while in mid-failover to the backup site.  Would these types of communications also be excluded?
  • The Rationale talks about “CIP-012-1 Requirements R1 and R2 protections for applicable data during transmission between two geographically separate Control Centers.”  However, the requirements themselves don’t seem to make that same distinction.  Since the definition of a “Control Center” includes associated data centers, this could lead to the application of this Standard, for example, to a facility that houses 2 control centers side-by-side (one with a data center downstairs).  GSOC requests that the Drafting Team provide more information about the Rationale, as it relates to geographical location and proximity of Control Centers, and corresponding language of the Requirements.
  • CIP-012 includes protections for data while being transmitted between Control Centers.  However, Control Centers are facilities and do not transmit data.  Does this include only data transmitted between BES Cyber Systems associated with a Control Center or data transmitted by certified System Operators?  

Guy Andrews, 9/11/2017

- 0 - 0

TOP-003/IRO-010 both require applicable entities have mutual agreement on security protocols. This mutual agreement requirement text of TOP-003/IRO-010 may limit or prevent an entity from following its documented plans of CIP-012-1 R1 should, as an example, either entity change its security protocols.  

One approach is to also include the requirement for mutual agreement within CIP-12-1 and/or be more prescriptive in how an entity complies with CIP-012-1 R1 including coordination between entities. 

Laura McLeod, 9/11/2017

- 0 - 0

The standard as drafted explicitly excludes oral communications, but does not consider forms of written communication (email, chat, etc) that could communicate the same type of information that an oral communication could. These written instructions are commonly outside of SCADA systems and are on corporate systems, and this standard would require physical or logical controls on those systems for communications that may traverse these systems. The standard should specify the protection of “operational data”, “BCS Data”, or some other term to clarify protection of data outside of instructions, or provide data validation (i.e verify emails by phone) as an acceptable control.

 

Additionally, Entergy has concerns over expanding the scope of protection from “real-time” as defined in other CIP standards and through existing CIP definitions, to require the protection of Operational Planning Analysis data that is outside of the “real-time” horizon. Requests additional clarity regarding whether the protection is required for data that is used to an input to Operational Planning Analysis, or also includes Operational Planning Analysis data outputs. The Technical Justification and Rationale document seems to imply it is data inputs as it calls out data believed to already be within BES Cyber Systems.

James Gower, On Behalf of: Entergy, SERC, Segments NA - Not Applicable

- 0 - 0

We do not agree with two separate requirements, one for a plan and one to implement. We recommend following precedent in the other CIP standards, for example, CIP-004-011. The obligation can be accomplished with one requirement, such as follows, with the caveat of concerns expressed in question 1 about what data is covered.

The Responsible Entity shall implement one or more documented processes(s) to mitigate the risk of the unauthorized disclosure or modification of data used for Operational Planning Analysis, Real-time Assessments, and Real-time monitoring while being transmitted between Control Centers, except under CIP Exceptional Circumstances . This excludes oral communications. Risk mitigation shall be accomplished by one or more of the following actions:  (follow with the four bullets).

Delete R2.

With one requirement, the note could be simpler by not referencing "R1 of CIP-012-1" and "CIP-012-1."  See following.

Note: If the Responsible Entity does not have a Control Center or it does not transmit the type of data specified in this Requirement between two Control Centers, this Requirement  would not apply to that entity.

 

 

 

Annette Johnston, 9/11/2017

- 0 - 0

See MidAmerican Energy Company comments.

Terry Harbour, Berkshire Hathaway Energy - MidAmerican Energy Co., 1, 9/11/2017

- 0 - 0

The requirement is too general and would likely not yield consistent compliance among entities and would result in inconsistent auditing of compliance. 

Laurie Williams, 9/11/2017

- 0 - 0

The requirement is too general and would likely not yield consistent compliance among entities and would result in inconsistent auditing of compliance

Lynn Goldstein, PNM Resources - Public Service Company of New Mexico, 1, 9/11/2017

- 0 - 0

CHPD requests clarification be added to the Technical Rationale for acceptable means of physically protecting communications links and identifying equally effective methods to mitigate risk.

CHPD requests that the exclusion for oral communications be extended to electronic mail.

Haley Sousa, 9/11/2017

- 0 - 0

Hot Answers

Janis Weddle, 9/11/2017

- 0 - 0

Douglas Webb, 9/11/2017

- 0 - 0

Other Answers

If there is the need to scope sensitive BES data as it applies to Operational Planning Analysis, Real-time Assessment, and Real-time monitoring, it should all be scoped as data of the High Impact BES Cyber Systems.

RoLynda Shumpert, On Behalf of: SCANA - South Carolina Electric and Gas Co., SERC, Segments 1, 3, 5, 6

- 0 - 0

The California ISO supports the comments of the Security Working Group (SWG).

- 0 - 0

Nicholas Lauriat, On Behalf of: Network and Security Technologies, , Segments 1

- 0 - 0

Duke Energy has concerns about the decision to add Operational Planning Analysis information to the scope of the data protected by this standard. Currently, the scope of the CIP standards primarily focuses on real-time data, and bringing in Operational Planning Analysis pushes the scope of CIP standards to include Day Ahead. Also, in some instances, Operational Planning Analyses can be performed by a 3rd party or require data transmitted between entities via 3rd party tools. How would these affect be impacted by the applicability of the standard? Extending the CIP scope to apply to Day Ahead data is a departure, and could broaden the view of what tools (possibly including web-based tools?) could fall under CIP scope.

Duke Energy , Segment(s) 1, 5, 6, 4/10/2014

- 0 - 0

TVA agrees that the entity needs to know what information is classified as BES sensitive data as it relates to operational planning analysis, real-time assessment, and real-time monitoring.  In many cases some types of operational planning analysis data is housed in systems not classified as BES Cyber Systems and may not reside within an ESP.

Tennessee Valley Authority, Segment(s) 1, 3, 5, 6, 9/1/2016

- 0 - 0

In the event mandatory standards are imposed, the scope should be limited to data that have well-defined terms.

Laura Nelson, 9/1/2017

- 0 - 0

Dominion asserts that data used for Operational Planning Analysis is often an ad-hoc report by exception (e.g., this line will be out or this unit will be de-rated) and because this data is often collected by a stand-alone system it can often be entered by several people within an organization and from several locations.  Dominion is unclear on whether the entity expected to track which data is specifically entered from within a Control Center as opposed to from an office external to the Control Center.  Many stand-alone systems are web-based and use https for all transactions. It is unclear what would qulaify as adequate evidence and that tracking locations and persons entering the information is not necessary.

Dominion, Segment(s) 3, 5, 1, 4/6/2017

- 0 - 0

Sergio Banuelos, On Behalf of: Tri-State G and T Association, Inc., MRO, WECC, Segments 1, 3, 5

- 0 - 0

Anthony Jablonski, ReliabilityFirst , 10, 9/5/2017

- 0 - 0

The requirement as written does not meet the criteria as outlined in the document titled “Ten Benchmarks of an Excellent Reliability Standard”, benchmark 8. Clear Language.   As the SDT stated in the rationale, the data in scope is the data as specified in TOP-003-3 and IRO-010-2.  If this is in fact the case then the SDT should draw a clear and unambiguous line to these standards within the requirement.  The addition of such language will also prevent unintentional scope reach.

Suggested language should be something to the following effect:

R1.2 The Responsible Entity, as applicable to its registered function, shall consider the data used for Operational Planning Analysis, Real-time Assessments, and Real-time monitoring to be the data as specified in:

  • NERC Reliability Standard IRO-010-2, Requirement R1 and,

  • NERC Reliability Standard TOP-003-3 — Operational Reliability Data, Requirement R1 and Requirement R2.

George Brown, Acciona Energy North America, 5, 9/6/2017

- 0 - 0

We are concerned because unauthorized alteration of Operational Planning Analysis data does not pose a threat to the BES. This more appropriately addressed by TOP 010-1 reliability standard regarding the quality of the data.  We note that Operational Planning Data is not real time data, as such we ask the STD to treat communicating Operational Planning Data Email exempt similar to the oral communication.   

- 0 - 0

Leonard Kula, Independent Electricity System Operator, 2, 9/7/2017

- 0 - 0

Same comment as question #1 above.

Con Edison, Segment(s) 1, 3, 5, 6, 6/24/2016

- 0 - 0

APPA does not agree with the scope of the CIP-012-1 R1 as it applies to Operational Planning Analysis, Real-time Assessment, and Real-time monitoring.  Since Operational Planning Analysis data would not meet the 15-minute impact criteria used in the identification of BES Cyber Systems, this data would only be required to be protected as it is being transmitted between Control Centers. This inconsistency between the data systems identified by CIP-012-1 and those identified in other CIP standards may cause the unintended expansion of scope of the CIP Standards.

FMPA believes applying controls to the Operational Planning Analysis data may reduce the current ability of entities to share this data which may cause a reduction in BES reliability.  Not all of this data goes from Control Center to Control Center but may go to (or from) a location outside of a Control Center and therefore would not be in scope of the drafted CIP-012 standard.  APPA suggests removing the Operational Planning and Analysis data from the scope of this standard.

If the Operational Planning and Analysis data must be retained in the Standard, then APPA believes that an exemption for the communication of Operational Planning and Analysis data by email should be put in place.  This would be similar to the exemption that exists for voice communication. 

 

FMPA, Segment(s) , 8/2/2017

- 0 - 0

Frank Pace, Central Hudson Gas & Electric Corp., 1, 9/7/2017

- 0 - 0

The question is unclear.

Donald Lock, 9/8/2017

- 0 - 0

No Comment

David Rivera, New York Power Authority, 3, 9/8/2017

- 0 - 0

Please provide additional guidance on the scope of the information. The Standards from which the scope derives does not provide guidance, and the expansion of scope in CIP-012-1 to all Control Centers necessitates the need for more specific guidance.

Philip Huff, 9/8/2017

- 0 - 0

Kristine Ward, On Behalf of: Seminole Electric Cooperative, Inc., FRCC, Segments 1, 2, 4, 5, 6

- 0 - 0

The question is unclear.

Jennifer Hohenshilt, Talen Energy Marketing, LLC, 6, 9/8/2017

- 0 - 0

Colorado Springs Utilities, Segment(s) 5, 3, 1, 6, 5/6/2015

- 0 - 0

The SDT needs to add “BES” data into the language as recommended above in question 1.

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

- 0 - 0

See attachment

Alice Wright, Arkansas Electric Cooperative Corporation, 4, 9/8/2017

- 0 - 0

Texas RE does not have comments on this question.

Rachel Coyne, Texas Reliability Entity, Inc., 10, 9/8/2017

- 0 - 0

See APPA Comments.

Seattle City Light Ballot Body, Segment(s) 1, 4, 6, 5, 3, 12/2/2016

- 0 - 0

Exelon agrees that aligning with TOP-003-3 and IRO-010-2 is helpful for scoping CIP-012-1, and promotes consistent application of the NERC Standards.

Daniel Gacek, Exelon, 1, 9/8/2017

- 0 - 0

Recommend removing “Operational Planning Analysis” from this requirement.  Operational Planning Analysis is not Real-time data and would not affect the BES within 15 minutes.  The TOP-003-3 Standard currently requires a mutually agreeable security protocol for sharing of data required for Operational Planning Analyses.

Santee Cooper, Segment(s) 1, 9/8/2017

- 0 - 0

NCPA does not agree with the scope of the CIP-012-1 as it applies to Operational Planning Analysis, Real-time Assessment, and Real-time monitoring.  Since Operational Planning Analysis data would not meet the 15-minute impact criteria used in the identification of BES Cyber Systems, this data would only be required to be protected as it is being transmitted between Control Centers. This inconsistency between the data systems identified by CIP-012-1 and those identified in other CIP standards may cause the unintended expansion of scope of the CIP Standards.  Also see other APPA and Utility Services/TAPs comments.

Marty Hostler, Northern California Power Agency, 4, 9/8/2017

- 0 - 0

Steven Mavis, 9/8/2017

- 0 - 0

See comments submitted by Robert Blackney on NERC’s proposed modifications to the definition of Control Center

Thomas Rafferty, 9/8/2017

- 0 - 0

NCPA does not agree with the scope of the CIP-012-1 as it applies to Operational Planning Analysis, Real-time Assessment, and Real-time monitoring.  Since Operational Planning Analysis data would not meet the 15-minute impact criteria used in the identification of BES Cyber Systems, this data would only be required to be protected as it is being transmitted between Control Centers. This inconsistency between the data systems identified by CIP-012-1 and those identified in other CIP standards may cause the unintended expansion of scope of the CIP Standards.  Also see other APPA and Utility Services/TAPs comments.

Dennis Sismaet, Northern California Power Agency, 6, 9/8/2017

- 0 - 0

AZPS respectfully submits that achieving a consensus regarding categorization of data as sensitive across all three interconnections will be difficult – if not impossible – to achieve.  The sensitivity of the same data can vary drastically between interconnections and entities within each interconnections.  For example, a piece of information that AZPS considers critical and sensitive to its real-time assessments may be viewed as insignificant to another entity.  Additionally, certain markets require publication of data that other markets would consider sensitive.  Hence, any attempted categorization may conflict with regulatory requirements in Open Access Transmission Tariffs, Market Protocols, state and federal regulations, etc. that obligate entities to disclose and/or that require confidentiality and that are already effective.

Furthermore, such a classification may not matter in practice.  The reality is that data flows to Control Centers across a limited number of communication channels.  Consider a simplified control center that uses only ICCP for real-time monitoring and assessment, with only half of the data transmitted across that channel being considered “sensitive.”  It is unlikely that any entity would reasonably determine that it should separate out the sensitive data for protection and leave the non-sensitive data unprotected. It is more likely that they would, instead, protect the entire communication channel.  Consequently, AZPS does not support the need or see any benefit to an effort focused on scoping sensitive BES data.  Instead, it recommends that responsible entities retain the authority to designate specific data or communication links as “sensitive.”

Finally, in the event that the SDT determines a need to scope sensitive BES data, AZPS suggests striking the term “Operational Planning Analysis” from the requirement and limiting the data considered as sensitive to that data which is subject to the NERC Operating Reliability Data (ORD) Agreement.  The NERC ORD Agreement is intended to ensure the confidentiality of sensitive data and the definition of Operating Reliability Data and associated obligations included therein are clear, well-established, and well-understood by industry.  Importantly, the definition of ORD excludes “Operational Planning Analysis,” signaling that such data has not, historically, been considered as “sensitive.”  Moreover, the Operational Planning Analysis occurs in the next day horizon, providing entities with time to receive and review data prior to use and, where data is suspect, request verification of data or, where data is not timely received, request that such data be re-transmitted.  For these reasons, the data utilized in Operational Planning Analyses has extremely limited impact on reliability, which is highly dependent on accurate, appropriate real-time data.  Hence, protecting data used in real-time assessment and monitoring as has been required by the NERC ORD Agreement for years is appropriate and the scope of such data has already been evaluated for sensitivity and confidentiality.  In summary, if the SDT is compelled to scope sensitive data, to ensure consistency, AZPS recommends that the SDT interpret “sensitive BES data” as encompassing data used in Real-time Assessment and Real-time monitoring only and utilize the NERC ORD Agreement as its primary reference.  

Vivian Moser, 9/10/2017

- 0 - 0

David Gordon, 9/11/2017

- 0 - 0

FirstEnergy Corporation, Segment(s) 4, 1, 3, 5, 6, 4/11/2017

- 0 - 0

Heather Morgan, EDP Renewables North America LLC, 5, 9/11/2017

- 0 - 0

The Purpose section of CIP-012-1 adds the need to protect the confidentiality of data which is out of Scope of FERC order 822. Although it is recognized that the SDT is not limited to just FERC orders, adding need to protect the confidentiality of data does not add reliability if the data is being protected per CIP-012-1 R1.

 

Eversource Group, Segment(s) 5, 3, 9/11/2017

- 0 - 0

AEP suggests that “Operational Planning and Analysis” be removed from R1.

Aaron Austin, 9/11/2017

- 0 - 0

NRECA contends that data used for Operational Planning Analysis (OPA) is not sensitive BES data and does not have a 15 minute impact on the reliable operation of the BES.  The CIP standards focus on span of control of BES Cyber Systems and their impact to the reliable operation of the BES.  Data used for Real-time Assessments and Real-time monitoring can immediately impact the reliable operation of the BES, but data used for OPA has no such impact.  We request that the SDT remove OPA from R1 due to not impacting the reliable operation of the BES.

Barry Lawson, 9/11/2017

- 0 - 0

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

- 0 - 0

SRP agrees this data should be protected. However, after further discussions within SRP and with other entities in the industry, it is clear no one in the industry can state or has an understanding of the implications encryption would have on reliable operation of the BES and the data within this scope. Until a survey or evaluation is performed to understand the amount of data this scope applies to and the impact of encryption on latency and computing resources, the scope may be over-reaching. As such, the manner used for scoping does not adequately take these factors into account.

Lona Calderon, On Behalf of: Salt River Project, WECC, Segments 1, 3, 5, 6

- 0 - 0

The SDT needs to add “BES” data into the language as recommended above in question 1.  The “BES data” to be protected should be identified as that “BES data” which can have an impact via high and medium BES Cyber Systems within 15 minutes. In other words, this level of protection should be limited to High and Medium Control Centers and only that data which could put Real-time operations at risk.

Thomas Breene, WEC Energy Group, Inc., 3, 9/11/2017

- 0 - 0

Xcel Energy is concerned with the inclusion of BES data used for Operation Planning Analysis that does not have a 15 minute impact on the Bulk Electric System.  The inclusion of Operational Planning Assessment data would bring corporate communication links, such as corporate email, into the scope of NERC Standards. 

We are also concerned with the language in Requirement R1.1 which states that a method of risk mitigation could be done by "Physically protecting the communication links transmitting data."  Xcel Energy believes that the proposed standard does not define what physical controls would be sufficient to mitigate the undefined risk of "unauthorized disclosure of modification of data." Many communication devices owned by Xcel Energy reside in company facilities that have several layers of physical protection.  However, once communication links leave our enclosures and ownership purview, physical protection would be difficult at best, largely unknown, and impossible to enforce.  The implementation of physical controls only covers a small section of the medium for the data and does not actually protect the data itself.  As one of three options; if an organization elects to impement physical controls it would still leave a gap in data integrity and add little benefit with excessive administrative burden. 

Xcel Energy respectfully proposes the recommendation for physcial protection to be removed and require logical controls such as encryption, firewalls, information protection release standards and password requirements.  Logical controls would more sufficiently protect the data itself end-to-end. We suggest the following edits to R1;

The Responsible Entity shall develop and implement controls [strikethrough: one or more documented plan(s)] to mitigate the risk of the unauthorized disclosure of or modification to BES data used for Operational Planning Analysis, Real-time Assessments, and Real-time monitoring while being transmitted between Control Centers and which could have an adverse impact on the BES within 15 minutes. This excludes verbal communications. [Violation Risk Factor: Medium] [Time Horizon: Operations Planning]

1.1. Risk mitigation shall be accomplished by one or more of the following actions:

  • [strikethrough: Physically protecting the communication links transmitting the data;]

  • Logically protect[strikethrough:ing] the data during transmission; or

  • Use[strikethrough:ing] an equally effective method to mitigate the risk of unauthorized disclosure or modification of the data.

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

- 0 - 0

Cowlitz PUD supports the comments submitted by APPA.

Russell Noble, Cowlitz County PUD, 3, 9/11/2017

- 0 - 0

While we agree with the SDTs approach to align with TOP-003 and IRO-010, we feel that technologies such as encryption or physical protection are generally implemented by link, not communication type.

Jesus Sammy Alcaraz, Imperial Irrigation District, 1, 9/11/2017

- 0 - 0

RSC no Con-Edison and Dominion, Segment(s) 10, 2, 4, 5, 6, 7, 1, 3, 9/11/2017

- 0 - 0

Elizabeth Axson, 9/11/2017

- 0 - 0

Louisville Gas and Electric Company and Kentucky Utilities Company, Segment(s) 3, 5, 6, 4/13/2017

- 0 - 0

Tacoma Power supports the comments of APPA

Marc Donaldson, Tacoma Public Utilities (Tacoma, WA), 3, 9/11/2017

- 0 - 0

sean erickson, Western Area Power Administration, 1, 9/11/2017

- 0 - 0

See APPA Comments.

Theresa Rakowsky, 9/11/2017

- 0 - 0

APPA does not agree with the scope of the CIP-012-1 R1 as it applies to Operational Planning Analysis, Real-time Assessment, and Real-time monitoring. Since Operational Planning Analysis data would not meet the 15-minute impact criteria used in the identification of BES Cyber Systems, this data would only be required to be protected as it is being transmitted between Control Centers. This inconsistency between the data systems identified by CIP-012-1 and those identified in other CIP standards may cause the unintended expansion of scope of the CIP Standards.

Public power believes applying controls to the Operational Planning Analysis data may reduce the current ability of entities to share this data which may cause a reduction in BES reliability. Not all of this data goes from Control Center to Control Center but may go to (or from) a location outside of a Control Center and therefore would not be in scope of the drafted CIP-012 standard. APPA suggests removing the Operational Planning and Analysis data from the scope of this standard.

If the Operational Planning and Analysis data must be retained in the Standard, then APPA believes that an exemption for the communication of Operational Planning and Analysis data by email should be put in place. This would be similar to the exemption that exists for voice communication.  

An important consideration with respect to scope and data protection, is the impact encryption may have on the data being considered within the scope of the standard. As SRP communicates in their comments: until the implications are understood about the amount of data being considered for the standard and the impact of encryption on latency and computing resources, the scope may be over-reaching. Therefore, APPA believes that the scoping for the standard does not sufficiently take these factors into account.

Jack Cashin, American Public Power Association, 4, 9/11/2017

- 0 - 0

CenterPoint Energy believes not all data included in OPA, RTA, and RTM is sensitive BES data.  CenterPoint Energy recommends the SDT narrow the scope further to only sensitive BES data. Some inputs into OPAs, RTAs, and RTMs (e.g. forecast type data, modeling data such as Facility Ratings, phase angle limitations, etc.) should not be included in the scope of this project.  On a situational basis, some telemetry and outage information would also not be considered sensitive BES data.

CenterPoint Energy further recommends that OPA data be completely removed from the scope of CIP-012-1.  CenterPoint Energy does not deem this data to be considered sensitive BES data, nor does this data carry the significance of actual Real-time data used for RTAs and RTM. 

Lan Nguyen, On Behalf of: CenterPoint Energy Houston Electric, LLC, Texas RE, Segments 1

- 0 - 0

SERC CIPC, Segment(s) 10, 1, 2, 5, 9, 8/19/2016

3B-2016-02_CIP-012-1_Unofficial_Comment_Form_CIPC.docx

- 0 - 0

We disagree with the inclusion of Operational Planning Analysis (OPA) based on its NERC definition, as these evaluations are assessed on anticipated and potential conditions for next-day operations and outside the 15-minute impact on the reliable BES operations.   The inclusion of OPA is unnecessary and the technical basis does not support it being in scope because it is not impacting the BES in real time.

ACES Standards Collaborators, Segment(s) 1, 3, 4, 5, 9/11/2017

- 0 - 0

See comments submitted by Robert Blackney on NERC’s proposed modifications to the definition of Control Center.

Kenya Streeter, Edison International - Southern California Edison Company, 6, 9/11/2017

- 0 - 0

RC, TOP and BA functional entities develop and disseminate specifications for the BES data they need to conduct Operational Planning Analysis, Real-time Assessment, and Real-time monitoring, in NERC ‘693’ reliability standards TOP-003 and IRO-010. Relevant peer RCs/TOPs/BAs and others (GOs; GOPs; TOs; LSEs; DPs) are required by these standards to meet these data specifications. The scope of data subject to R1 is (or should be) thereby understood to be the data that entities both (i) specify in observance of these standards and (ii) transmit between the entity’s and others’ Control Centers.

PSEG REs, Segment(s) 5, 6, 3, 1, 3/6/2017

- 1 - 0

Michael Puscas, ISO New England, Inc., 2, 9/11/2017

- 0 - 0

The requirement suggested data are different from those protected in other CIP standards.  This may cause confusion in the future by calling it a CIP standard.

David Greyerbiehl, CMS Energy - Consumers Energy Company, 5, 9/11/2017

- 0 - 0

However, BPA questions the inclusion of Operational Planning Analysis.

Aaron Cavanaugh, On Behalf of: Bonneville Power Administration, WECC, Segments 1, 3, 5, 6

- 0 - 0

The requirement suggested data are different from those protected in other CIP standards. This may cause confusion in the future by calling it a CIP standard.

James Anderson, 9/11/2017

- 0 - 0

Utility Services does not agree with the scope of the CIP-012-1 R1 as it applies to Operational Planning Analysis, Real-time Assessment, and Real-time monitoring.  Since Operational Planning Analysis data would not meet the 15-minute impact criteria used in the identification of BES Cyber Systems, this data would only be required to be protected as it is being transmitted between Control Centers. This inconsistency between the data systems identified by CIP-012-1 and those identified in other CIP standards may cause the unintended expansion of scope of the CIP Standards.

 

Public power believes applying controls to the Operational Planning Analysis data may reduce the current ability of entities to share this data which may cause a reduction in BES reliability.  Not all of this data goes from Control Center to Control Center but may go to (or from) a location outside of a Control Center and therefore would not be in scope of the drafted CIP-012 standard.  USI suggests removing the Operational Planning and Analysis data from the scope of this standard.

 

If the Operational Planning and Analysis data must be retained in the Standard, then USI believes that an exemption for the communication of Operational Planning and Analysis data by email should be put in place.  This would be similar to the exemption that exists for voice communication. 

Brian Evans-Mongeon, Utility Services, Inc., 4, 9/11/2017

- 0 - 0

-- ANSWER HAS BEEN REDACTED BY A SYSTEM ADMINISTRATOR --

Robert Blackney, On Behalf of: Edison International - Southern California Edison Company, WECC, Segments 1, 3, 5, 6

- 0 - 0

As per the concern noted in response to question 1, we agree that either further clarification on the scope of the data is needed so it is clear the data in question has already been scoped and is in specifications that are required by IRO-010 and TOP-003, or the SDT should consider setting aside a “data-centric” approach and focus protections on a more technical solution regardless of the data being transmitted between Control Center ESPs and LEAPs.

Southern Company, Segment(s) 1, 3, 5, 6, 8/3/2016

- 0 - 0

David Ramkalawan, 9/11/2017

- 0 - 0

Please provide additional clarification on the protection of load forecasting data as it may not consistently be included as a separate BES Cyber System.

Ronald Donahey, TECO - Tampa Electric Co., 3, 9/11/2017

- 0 - 0

Please provide guidance on whether or not email is in scope as a communication medium.

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

- 0 - 0

The SPP Standards Review Group has a concern that the scope doesn’t provide the appropriate coverage of the BES data. We would like to propose some new language to address those potential concerns. First of all, a “plan” does not necessarily mean the data is protected. According to the Rationale section FERC is looking for controls to protect these communication links. It should also be clarified that this is “BES” data.

The SDT, in the Technical Rationale and Justification document acknowledges TOP-003-3 and IRO-010-2 “provides consistent scoping of identified data” [R1 section: Alignment with IRO and TOP Standards”]. We believe that the data specifications under TOP-003-3 R1 and IRO-010-2 R1 correctly scope the data to be protected; however the current R1 only leaves us with three defined terms for scoping. These 3 defined terms were already used to scope the data specifications under TOP-003-3 R1 and IRO-010-2 R1. CIP-012-1 R1 should reference to TOP-003-1 R1 and IRO-010-2 R1. We realize that it is not the preferred method to reference another Standard; however since CIP-012 is classified as a CIP Standard, and not an Operations and Planning Standard which would be the correct classification, CIP auditors may expand the data to be protected based solely on definitions. In order to properly scope CIP-012, it should reference the TOP-003 and IRO-010 Standards.

R1 should be re-written: “The Responsible Entity shall have controls in place to mitigate the risk of the unauthorized disclosure or modification of BES data identified under entity developed data specifications in TOP-003-3 R1 for applicable entities and IRO-010-2 R1 for applicable entities; while such data is being transmitted between BES Control Centers. This excludes oral communications.”

SPP Standards Review Group, Segment(s) , 9/11/2017

- 0 - 0

Reclamation recommends adding “BES” data to the language as stated above in question 1.

Wendy Center, U.S. Bureau of Reclamation, 5, 9/11/2017

- 0 - 0

- 0 - 0

Lauren Price, 9/11/2017

- 0 - 0

AECI contends that data used for Operational Planning Analysis (OPA) is not sensitive BES data and does not have a 15 minute impact on the reliable operation of the BES.  The CIP standards focus on span of control of BES Cyber Systems and their impact to the reliable operation of the BES.  Data used for Real-time Assessments and Real-time monitoring can immediately impact the reliable operation of the BES, but data used for OPA has no such impact.  AECI requests that the SDT remove OPA from R1 due to not impacting the reliable operation of the BES.

Mark Riley, Associated Electric Cooperative, Inc., 1, 9/11/2017

- 0 - 0

We request clarification on the inclusion of data used for Operational Planning Analysis.  This data does not have a 15 minute impact on the Bulk Electric System.  This data is also typically exchanged between operations engineering staff who would not be considered to be a Control Center.  

Guy Andrews, 9/11/2017

- 0 - 0

Since Operational Planning Analysis is not real-time data and since planning data/information is generally scrutinized when performing analysis the risk of acting on corrupted data (entry error or unauthorized disclosure/modification) is low.

Laura McLeod, 9/11/2017

- 0 - 0

Entergy has concerns over expanding the scope of protection from “real-time” as defined in other CIP standards and through existing CIP definitions, to require the protection of Operational Planning Analysis data that is outside of the “real-time” horizon.

James Gower, On Behalf of: Entergy, SERC, Segments NA - Not Applicable

- 0 - 0

The FERC directive refers to "sensitive bulk electric system data" and directs NERC to "identify the scope of sensitive build electric system data." The FERC directive also acknowledges that certain entities are already required to exchange necessary real-time and operational planning data through secured networks using mutually agreeable security protocol.

Draft Requirement 1 refers to "data used for Operational Planning Analysis, Real-time Assessments, and Real-time monitoring." We agree with other commenters that these references require revision. Further, we ask the SDT to consider scoping sensitive data explicitly to information exchanged between Control Centers' BES Cyber Systems. This corresponds to SDT's assertation that "this data resides within BES Cyber Systems, and while at rest is protected by CIP-003 through CIP-011." It also corresponds to FERC's recognition of mutually agreeable security protocol networks referenced above.

Annette Johnston, 9/11/2017

- 0 - 0

See MidAmerican Energy Company comments.

Terry Harbour, Berkshire Hathaway Energy - MidAmerican Energy Co., 1, 9/11/2017

- 0 - 0

Laurie Williams, 9/11/2017

- 0 - 0

Lynn Goldstein, PNM Resources - Public Service Company of New Mexico, 1, 9/11/2017

- 0 - 0

Haley Sousa, 9/11/2017

- 0 - 0

Hot Answers

The coordination time required to perform a migration to secure communications protocols is expected to take longer than the schedule presented by the SDT.  CHPD recommends at least twenty-four (24) calendar months to implement communication updates and implement other available protection measures.

Janis Weddle, 9/11/2017

- 0 - 0

The company will review current systems and protections to identify if further action is required to protect the communications links between control centers as set forth in the approved Standard.

Douglas Webb, 9/11/2017

- 0 - 0

Other Answers

RoLynda Shumpert, On Behalf of: SCANA - South Carolina Electric and Gas Co., SERC, Segments 1, 3, 5, 6

- 0 - 0

The California ISO supports the comments of the Security Working Group (SWG).

- 0 - 0

Nicholas Lauriat, On Behalf of: Network and Security Technologies, , Segments 1

- 0 - 0

Duke Energy disagrees with the proposed 12 month Implementation Plan. Certain aspects of achieving compliance with this standard (for example, implementing end to end encryption) would, in some instances, take a significant amount of time to put in place to due to the significance of the impact of these changes on critical systems. Further, applying these protections between Control Centers owned by more than one Responsible Entity will involve significant coordination, and additional time would be necessary to develop a shared understanding of existing technical limitations, develop agreements, and implement those new approaches for compliance. Duke Energy suggests that a phased implementation plan would be appropriate given the action necessary. We encourage the drafting team to consider an Implementation Plan of 12 months for R1. This would give time for the Responsible Entity to assess the Control Centers that are in its scope, decide on a method of protection, and involve any additional parties that may be necessary. We suggest a minimum of 24 months for the implementation date for R2 (implementing the plan developed in R1).

Duke Energy , Segment(s) 1, 5, 6, 4/10/2014

- 0 - 0

TVA does not agree that twelve months is sufficient time to coordinate with other entities to agree on and implement protection mechanisms.  Implementation may require coordination of plans across a large and/or diverse group of entities employing a variety of protective measures.  TVA suggests 18-24 months would be a more realistic implementation period.

Tennessee Valley Authority, Segment(s) 1, 3, 5, 6, 9/1/2016

- 0 - 0

Changes take time to evaluate and implement. The communication lines will have to be inventoried and evaluated. The data traveling across these lines will have to be inventoried and evaluated to ensure entities can evidence that they are protecting the itemized list of data included in the wording of R1 (Operational Planning Analysis, Real-time Assessment, and Real-time monitoring). Other activities that would need to occur for successful implementation would include preparation and delivery of guidance by regulatory bodies, communication and coordination with partner entities, configuration, and testing. At minimum, an 18-month implementation plan would be appropriate.

Laura Nelson, 9/1/2017

- 0 - 0

Dominion asserts that budgets, resources, and other events between separate entities may require periods greater than 12 months.  Dominion recommends that the implementation period be revised to 24 months.In addition, the time required to develop (R1), and then successfully implement (R2) would take longer than 12 months from the start date.  24 months should allow sufficient time to accomplish implementation of both requirements. 

Dominion, Segment(s) 3, 5, 1, 4/6/2017

- 0 - 0

A region-wide agreement may be difficult to develop and execute in a year. Tri-State believes 18 months would be more appropriate.

Sergio Banuelos, On Behalf of: Tri-State G and T Association, Inc., MRO, WECC, Segments 1, 3, 5

- 0 - 0

Anthony Jablonski, ReliabilityFirst , 10, 9/5/2017

- 0 - 0

This standard will require a collaborative effort between Control Centers of the various applicable Functional Entities to achieve the securities as required.  As such, it may not feasible for some entities to implement these securities within 12 months.  For example, a Reliability Coordinator (RC) Control Center will have contact with the Control Centers of several Balancing Authorities (BA), Generator Operators (GOP), Transmission Operators (TOP),  Transmission Owners (TO) and other RCs.  If a particular RC is unable to support the implementation of the securities as required in NERC CIP-012-1 then there will be a cascading and unnecessary non-compliance effect among the other Functional Entities that have Control Centers that transmit and receive this sensitive BES data with this particular RC’s Control Center.  A phase-in approach may be more appropriate for NERC CIP-012-1, based on schedules created  using the Function Entity reliability hierarchy structure.

George Brown, Acciona Energy North America, 5, 9/6/2017

- 0 - 0

 

 

For complex entities the identification and agreement on communication protocols and architecture may require extensive testing and learning.  We recommend at least 18 months due to the quantity of details and logistics.

 

- 0 - 0

The IESO also encourages the drafting team to make the requirement forward-looking in regards to contracts currently in place. Provisions should be set for legacy contracts including grandfathering of existing agreements and equipment.  Implementation of controls involving telecommunications providers will require coordination and scheduling to align to the providers’ resource availability and reduce adverse impact on reliability. This should not require renewal and renegotiation of existing contracts until they reach the end of the existing contract period.   

It should be noted that it is difficult to determine suitability of the implementation timeline when there are open questions about the viability of available solutions for adequate protections.

More time is necessary to allow for coordination with a large number of parties. This will require budgeting, planning, and scheduling with external resources for implementation. It will also require significant testing and validation by parties on both ends of a connection.

The IESO recommends a phased implementation with defined milestones similar to CIP-014. Consider the following:

  • For creation of the plan, 12 months should be allowed to (1) conduct an impact assessments, (2) identify the approach to be included in the plan, (3) implementation milestones, and (4) implementation schedule. This could identify the communication links that have protections currently in place. The plan could also include identifying all links and protections requiring changes to address service contracts and related relationships to adjust for new protections. The plan could then be approved by an appropriate entity.

  • For implementation of the plan, additional time should be allowed for budgeting, planning, and scheduling with external resources. This includes planning with other Responsible Entities as well as telecommunications providers.

Leonard Kula, Independent Electricity System Operator, 2, 9/7/2017

- 2 - 0

Con Edison, Segment(s) 1, 3, 5, 6, 6/24/2016

- 0 - 0

FMPA does not agree with the implementation proposal timeline. The time to implement R1 (develop a plan) should be 12 months from the time of the order.

Due to technical complexity, agreements (outsourced and between registered entities), procurement, contracts and coordination between registered entities (and provisioning of private networks), FMPA requests that the SDT consider the following options for R2 implementation:

  • additional 24 months allowed to undertake implementation,

  • using a phased implementation over a five or longer year period, or

  • in recognition that there is the potential for several existing contracts will have to be replaced (and associated equipment) that affected contracts be grandfathered until new and or, replacements can be put in place.

FMPA, Segment(s) , 8/2/2017

- 0 - 0

It would appear that the proposed implementation period is too short; however, it is difficult to determine if a demarcation point for compliance is not specified within the language of the Requirement.

Frank Pace, Central Hudson Gas & Electric Corp., 1, 9/7/2017

- 0 - 0

The 12-month period provided in the implementation plan should be at least doubled.  Developing a clear understanding of what is required could take some time, and to then scope the project, obtain bids and budget approval, receive materials and implement in whatever portion of the year remains may prove impractical.

Donald Lock, 9/8/2017

- 0 - 0

  1. The time to implement R1 (develop plan) could be 12 months from time of order.  For implementation of R2 there should be an additional 24 months allowed to undertake implementation.  This would include identifying all links and protections, with changes needed to address communications service contracts and related relationships to adjust for new protections.  This would also involve inventory of data to comply with identification of all data transmitted between control centers.
  2. Due to technical complexity, agreements (outsourced and between Entities), procurement, contracts and coordination between Entities (and provisioning of private networks), request that the SDT also consider the following option for R2 implementation:
    1. a phased implementation over a five or longer year period, or
    2. to avoid impacting reliability, existing contracts, equipment, etc be grandfathered until new / replacements are in place.

David Rivera, New York Power Authority, 3, 9/8/2017

- 0 - 0

Philip Huff, 9/8/2017

- 0 - 0

SECI would like examples of evidence so we know how to proceed

Kristine Ward, On Behalf of: Seminole Electric Cooperative, Inc., FRCC, Segments 1, 2, 4, 5, 6

- 0 - 0

     The 12-month period provided in the implementation plan should be at least doubled.  Developing a clear understanding of what is required could take some time, and to then scope the project, obtain bids and budget approval, receive materials and implement in whatever portion of the year remains may prove impractical.

Jennifer Hohenshilt, Talen Energy Marketing, LLC, 6, 9/8/2017

- 0 - 0

Colorado Springs Utilities, Segment(s) 5, 3, 1, 6, 5/6/2015

- 0 - 0

The 12 month time period may only work for Entities who are vertically intergraded.  The flow of applicable BES data within CIP-012-1 can be viewed as a “spider web” of data transfer for large RC foot-prints.  With this being said, there may be non-compliance issues when one side of the data transference is protected and the other side is not.  The SDT should propose a phased in approach to protecting data.  A five (5) year implementation plan will allow entities to fund these projects.  This is especially important to small entities.  Per the NERC Guidance concerning “Phase Implementation Plans with Completion Percentages (http://www.nerc.com/pa/comp/guidance/CMEPPracticeGuidesDL/CMEP_Practice_Guide_Phased_Implementation_Completion_Percentages.pdf) please state that the CIP-012-1 does not fall under this guidance.

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

- 0 - 0

Alice Wright, Arkansas Electric Cooperative Corporation, 4, 9/8/2017

- 0 - 0

This question implies there are NERC Glossary terms in the Implementation Plan.  There are no NERC Glossary terms in the CIP-012-1 Implementation Plan.

 

Texas RE does not oppose the enforcement timelines set forth in the proposed Implementation Plan.  However, Texas RE respectfully requests that the SDT provide a specific justification for any proposed implementation timeframes, as well as any revisions to the timeframes as currently proposed.  The goal is to ensure there are no issues with the implementation plan such as not having an initial performance date where one is needed or not including information for new facilities such as the instance that led to an errata change in the PRC-023-4 implementation plan.  These issues cause confusion and ambiguity for both registered entities and Regional Entities upon enforcement of the standard.

Rachel Coyne, Texas Reliability Entity, Inc., 10, 9/8/2017

- 0 - 0

See APPA Comments.

Seattle City Light Ballot Body, Segment(s) 1, 4, 6, 5, 3, 12/2/2016

- 0 - 0

Daniel Gacek, Exelon, 1, 9/8/2017

- 0 - 0

Recommend a 2 year Implementation Plan Period.  For some entities, it may take a significant amount of time to agree on communication protocols and architecture with neighboring systems.  Time is also needed to troubleshoot and test each connection point.

Santee Cooper, Segment(s) 1, 9/8/2017

- 0 - 0

NCPA does not agree with the implementation proposal timeline. Due to technical complexity, agreements (outsourced and between REs), procurement, contracts and coordination between REs (and provisioning of private networks), NCPA requests that the SDT consider the following options for R2 implementation:

 

  • additional 24 months allowed to undertake implementation,

  • using a phased implementation over a five or longer year period, or

  • in recognition that there is the potential for several existing contracts will have to be replaced (and associated equipment) that affected contracts be grandfathered until new and or, replacements can be put in place.

Marty Hostler, Northern California Power Agency, 4, 9/8/2017

- 0 - 0

Steven Mavis, 9/8/2017

- 0 - 0

See comments submitted by Robert Blackney on NERC’s proposed modifications to the definition of Control Center

Thomas Rafferty, 9/8/2017

- 0 - 0

NCPA does not agree with the implementation proposal timeline. Due to technical complexity, agreements (outsourced and between REs), procurement, contracts and coordination between REs (and provisioning of private networks), NCPA requests that the SDT consider the following options for R2 implementation:

 

  • additional 24 months allowed to undertake implementation,

  • using a phased implementation over a five or longer year period, or

  • in recognition that there is the potential for several existing contracts will have to be replaced (and associated equipment) that affected contracts be grandfathered until new and or, replacements can be put in place.

Dennis Sismaet, Northern California Power Agency, 6, 9/8/2017

- 0 - 0

The proposed implementation plan does not consider complexities associated with implementing technical solutions reliant on inter-entity coordination and agreement. The proposed implementation plan does not recognize the prerequisite of mutual agreement between entities regarding a compatible technical solution or the time necessary to complete such prerequisite.  Moreover, it does not appear to contemplate a potential need for dispute resolution when a transmitting entity and receiving entity cannot agree on a solution. Finally, any implementation, testing, etc. can only occur once the mutually agreed-upon solution has been identified, budgeted, and procured.  For these reasons, AZPS proposes extending the implementation plan to at least twenty-four (24) calendar months.  Two years would likely allot adequate time to identify, agree upon, and procure appropriate technical solutions in coordination with other entities. 

Vivian Moser, 9/10/2017

- 0 - 0

The Implementation Plan should be modified to allow 24 months for the implementation phase (R2) due to the potential impact resulting from the necessity of redesigning communications architectures for secure communications between Control Centers.

David Gordon, 9/11/2017

- 0 - 0

FirstEnergy recommends adjusting the Implementation Plan time period to become effective the first day of the first calendar quarter that is eighteen (18) calendar months after the effective date of the applicable governmental authority’s order approving the standard.  The additional time will be needed to ensure that the implementation of any new technology (e.g. encryption) does not impact reliability of the BES.

FirstEnergy Corporation, Segment(s) 4, 1, 3, 5, 6, 4/11/2017

- 0 - 0

Generator Operator Control Centers are required to follow specifications pursuant to the requirements outlined by RCs, ISO,s  RTOs, BAs, and TOPs. To ensure GOP’s are able to properly carry out requirements for all of these parties and CIP-012-2, CIP-012-2’s Implementation Plan should be phased in similar to IRO-010, and TOP-003. Otherwise, GOP Control Centers will not be able to properly plan for any requirements delivered by the interconnecting authorities as a result of this Standard.

 

Heather Morgan, EDP Renewables North America LLC, 5, 9/11/2017

- 0 - 0

Request changing 12 months to 18 months in the implentation plan to allow time to make any required changes including design, procurement, CIP assesment and deployment.

Eversource Group, Segment(s) 5, 3, 9/11/2017

- 0 - 0

AEP suggests that the implementation time frame should be extended to at least 24 months to allow for activities such as coordination, budgeting, procurement, implementation and testing. 

Aaron Austin, 9/11/2017

- 0 - 0

NRECA asserts that smaller entities may need to procure equipment and implement technical controls that are not currently in place.  The implementation of the plan(s) detailed in requirement R1 could be impacted by budget cycles, procurement processes, and third party vendor availability.  NRECA recommends that the implementation plan be revised to allow 12 months for the development of the plan in requirement R1 and 24 months for the implementation.

Barry Lawson, 9/11/2017

- 0 - 0

Hydro Québec is in agreement with TFIST’s comments below in regards to taking into consideration technical complexities and coordination between entities; however we suggest that the documented plan in R1 include an implementation plan with deadlines not exceeding 36 months, rather than a prescribed delay for implementing R2. Furthermore, clarifications are requested in regards to the question“please note the actions you will take that require this amount of time to complete.

  1. The time to implement R1 (develop plan) could be 12 months from time of order.  For implementation of R2 there should be an additional 24 months allowed to undertake implementation.  This would include identifying all links and protections, with changes needed to address communications service contracts and related relationships to adjust for new protections.  This would also involve inventory of data to comply with identification of all data transmitted between control centers.

  2. Due to technical complexity, agreements (outsourced and between Entities), procurement, contracts and coordination between Entities (and provisioning of private networks), request that the SDT consider:

    a )a phased implementation over a five or longer year period, or b) to avoid impacting reliability, that existing contracts, equipment, etc stay in place. New contracts / equipment will need to follow this new Standard.

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

- 0 - 0

SRP requests 24 calendar months due to the complex details and logistics associated with implementation. The Impact from encryption is unknown. Because the data is being sent in real-time, it is difficult to test how encryption will affect reliability.

More research and evaluation is required to understand the implications encryption will have as it may require architecture changes to account for the extra computing resources required. Additionally, time is required to budget for funds in order to support any required infrastructure improvements required.  

Lona Calderon, On Behalf of: Salt River Project, WECC, Segments 1, 3, 5, 6

- 0 - 0

The 12 month time period may only work for Entities who are vertically intergraded.  The flow of applicable BES data within CIP-012-1 can be viewed as a “spider web” of data transfer for large RC foot-prints.  With this being said, there may be non-compliance issues when one side of the data transference is protected and the other side is not.  The SDT should propose a phased in approach to protecting data.  A five (5) year implementation plan will allow entities to fund these projects.  This is especially import to small entities.  Per the NERC Guidance concerning “Phase Implementation Plans with Completion Percentages (http://www.nerc.com/pa/comp/guidance/CMEPPracticeGuidesDL/CMEP_Practice_Guide_Phased_Implementation_Completion_Percentages.pdf) please state that the CIP-012-1 does not fall under this guidance.   

Thomas Breene, WEC Energy Group, Inc., 3, 9/11/2017

- 0 - 0

Xcel Energy believes that the Implementation Plan would allow sufficient time for our operating companies to implement required controls specified in the language of CIP-012-1.  However, Xcel Energy would require coordination from up to 25 other Responsible Entities is communicates BES data with and cannot speak to their abilities.  Any agreements in coordination between entities would need to go through a legal review process, which could take more than 12 months to formalize and implement.  A 24 month implementation period may be more feasible given the legal review challenges that would inevitably occur.

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

- 0 - 0

Cowlitz PUD supports the comments submitted by APPA.

Russell Noble, Cowlitz County PUD, 3, 9/11/2017

- 0 - 0

We recommend at least 18 months due to the quantity of details and logistics.

Jesus Sammy Alcaraz, Imperial Irrigation District, 1, 9/11/2017

- 0 - 0

·         The time to implement R1 (develop plan) could be 12 months from time of order.  For implementation of R2 there should be an additional 24 months allowed to undertake implementation.  This would include identifying all links and protections, with changes needed to address communications service contracts and related relationships to adjust for new protections.  This would also involve inventory of data to comply with identification of all data transmitted between control centers.

·         Due to technical complexity, agreements (outsourced and between Entities), procurement, contracts and coordination between Entities (and provisioning of private networks), request that the SDT also consider the following option for R2 implementation:

 

a.       a phased implementation over a five or longer year period, or

b.      to avoid impacting reliability, existing contracts, equipment, etc. be grandfathered until new / replacements are in place.

RSC no Con-Edison and Dominion, Segment(s) 10, 2, 4, 5, 6, 7, 1, 3, 9/11/2017

- 0 - 0

ERCOT ISO signs on to the ITC SWG comments:

The ITC SWG also encourages the drafting team to make the requirement forward-looking in regards to contracts currently in place. Provisions should be set for legacy contracts including grandfathering of existing agreements and equipment.  Implementation of controls involving telecommunications providers will require coordination and scheduling to align to the providers’ resource availability and reduce adverse impact on reliability. This should not require renewal and renegotiation of existing contracts until they reach the end of the existing contract period.   

It should be noted that it is difficult to determine suitability of the implementation timeline when there are open questions about the viability of available solutions for adequate protections.

More time is necessary to allow for coordination with a large number of parties. This will require budgeting, planning, and scheduling with external resources for implementation. It will also require significant testing and validation by parties on both ends of a connection.

The ITC SWG recommends a phased implementation with defined milestones similar to CIP-014. Consider the following:

  • For creation of the plan, 12 months should be allowed to (1) conduct an impact assessments, (2) identify the approach to be included in the plan, (3) implementation milestones, and (4) implementation schedule. This could identify the communication links that have protections currently in place. The plan could also include identifying all links and protections requiring changes to address service contracts and related relationships to adjust for new protections. The plan could then be approved by an appropriate entity.

  • For implementation of the plan, additional time should be allowed for budgeting, planning, and scheduling with external resources. This includes planning with other Responsible Entities as well as telecommunications providers.

Elizabeth Axson, 9/11/2017

- 0 - 0

We support SERC's comments.

Louisville Gas and Electric Company and Kentucky Utilities Company, Segment(s) 3, 5, 6, 4/13/2017

- 0 - 0

Tacoma Power supports the comments of APPA

Marc Donaldson, Tacoma Public Utilities (Tacoma, WA), 3, 9/11/2017

- 0 - 0

sean erickson, Western Area Power Administration, 1, 9/11/2017

- 0 - 0

PSE believes a 24 month implementation period and/or phased implementation approach is appropriate due to required coordination between registered entities, potential need for renegotiation of contracts and/or agreements with other entities, and potential for significant technical complexity for implementation.

Theresa Rakowsky, 9/11/2017

- 0 - 0

APPA does not agree with the implementation proposal timeline. The time to implement R1 (develop a plan) should be 12 months from the time of the order. 

Due to technical complexity, agreements (outsourced and between registered entities), procurement, contracts and coordination between registered entities (and provisioning of private networks), APPA requests that the SDT consider the following options for R2 implementation:

• additional 24 months allowed to undertake implementation,

• using a phased implementation over a five or longer year period

  • in recognition that there is the potential for several existing contracts will have to be replaced (and associated equipment) that affected contracts be grandfathered until new and or, replacements can be put in place. 

 

Jack Cashin, American Public Power Association, 4, 9/11/2017

- 0 - 0

CenterPoint Energy recommends the effective date for CIP-012-1 to be 24 months after FERC approval.   For instances where applicable data is being transmitted between Control Centers owned by two or more separate Responsible Entities, additional time is needed to coordinate plans and develop agreements to ensure adequate protection is applied.

Lan Nguyen, On Behalf of: CenterPoint Energy Houston Electric, LLC, Texas RE, Segments 1

- 0 - 0

SERC CIPC, Segment(s) 10, 1, 2, 5, 9, 8/19/2016

3B-2016-02_CIP-012-1_Unofficial_Comment_Form_CIPC.docx

- 0 - 0

New entities that are impacted by the new definition should be treated as “newly identified CIP facilities” and should be given the standard 18 month implementation period. Not the proposed 12 month implementation period.  Budgetary cycles would need to be considered and an additional reason for the 18 months.

ACES Standards Collaborators, Segment(s) 1, 3, 4, 5, 9/11/2017

- 0 - 0

See comments submitted by Robert Blackney on NERC’s proposed modifications to the definition of Control Center.

Kenya Streeter, Edison International - Southern California Edison Company, 6, 9/11/2017

- 0 - 0

PSEG Supports the NPCC comments.

PSEG REs, Segment(s) 5, 6, 3, 1, 3/6/2017

- 1 - 0

The time to implement the first requirement (develop plan) could be 12 months from time of order.  For implementation of the plan, however (R2) there should be an additional 12 months allowed to undertake implementation.  This would include identifying all links and protections, with changes needed to address communications service contracts and related relationships to adjust for new protections.

Michael Puscas, ISO New England, Inc., 2, 9/11/2017

- 0 - 0

Twelve calendar months for implementation may not be sufficient, twenty-four calendar months should be recommended.

David Greyerbiehl, CMS Energy - Consumers Energy Company, 5, 9/11/2017

- 0 - 0

BPA requests clarification about what “Physically protecting the communication links transmitting the data” in section 1.1 means. If it means protecting the data at the source (at the Control Center), the implementation period is acceptable. BPA will be required to update customer agreements during the implementation period. 

If it means the data must be protected throughout the transmission, it would seem that could only be accomplished with encryption. For cases where the existing equipment is not capable of encryption, BPA cannot propose an implementation timeline or solution other than technically feasible exception.

Aaron Cavanaugh, On Behalf of: Bonneville Power Administration, WECC, Segments 1, 3, 5, 6

- 0 - 0

Twelve calendar months for implementation may not be sufficient, twenty-four calendar months should be recommended.

James Anderson, 9/11/2017

- 0 - 0

Utility Services does not agree with the implementation proposal timeline. The time to implement R1 (develop a plan) should be 12 months from the time of the order.

 

Due to technical complexity, agreements (outsourced and between registered entities), procurement, contracts and coordination between registered entities (and provisioning of private networks), UTILITY SERVICES requests that the SDT consider the following options for R2 implementation:

 

·         additional 24 months allowed to undertake implementation,

·         using a phased implementation over a five or longer year period, or

·         in recognition that there is the potential for several existing contracts will have to be replaced (and associated equipment) that affected contracts be grandfathered until new and or, replacements can be put in place.

Brian Evans-Mongeon, Utility Services, Inc., 4, 9/11/2017

- 0 - 0

Robert Blackney, On Behalf of: Edison International - Southern California Edison Company, WECC, Segments 1, 3, 5, 6

- 0 - 0

Southern Company feels that 12 months is not enough time to implement the Standard as currently written. Implementation of the proposed methods of compliance could embark entities on budget and procurement processes to acquire new, upgraded, or revamped hardware, software, or other physical components at existing sites, and this can be a lengthy process.  Southern recommends at least a 24 month or greater implementation timeframe.  Southern agrees with comments provided by other commenters that the complexity of the technology solutions to be implemented, the number of interconnecting lines to secure, connection point testing, and coordination requirements with external stakeholders are additional factors supporting a 2 year implementation period.

Southern Company, Segment(s) 1, 3, 5, 6, 8/3/2016

- 0 - 0

OPG has some concerns and recommends a graded approach implementation over a longer period of time. The communications links requiring protections will require inventory; this will be a complex task for the RC.

The recommended 12 months may be sufficient for the inventory, however we also need to determine the applicable solution and agree on the solution with another entities.

David Ramkalawan, 9/11/2017

- 0 - 0

If additional contracts/agreements are required to address a plan for other entities, Registered Entities may need a longer time to implement the plan (Requirement R2).  Tampa Electric Company recommends an 18 month timeframe for Requirement 2.

Ronald Donahey, TECO - Tampa Electric Co., 3, 9/11/2017

- 0 - 0

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

- 0 - 0

The Standard Review Group has a concern that all Implementation needs may not be met in a timely fashion at the twelve (12) calendar month time frame. We would recommend that the drafting team extends the deadline to eighteen (18) calendar months. Due to technological changes needed to secure the data and collaboration between sending and receiving party, we feel more time is needed to implement the standard.

SPP Standards Review Group, Segment(s) , 9/11/2017

- 0 - 0

Eighteen calendar months after the approval of the control center definition and the CIP-012-1 standard to allow entities time to evaluate the impact of the changes effected by the new standard and implement an appropriate response.

Wendy Center, U.S. Bureau of Reclamation, 5, 9/11/2017

- 0 - 0

- 0 - 0

Lauren Price, 9/11/2017

- 0 - 0

AECI asserts that smaller entities may need to procure equipment and implement technical controls that are not currently in place.  The implementation of the plan(s) detailed in requirement R1 could be impacted by budget cycles, procurement processes, and third party vendor availability.  AECI recommends that the implementation plan be revised to allow 12 months for the development of the plan in requirement R1 and 24 months for the implementation

Mark Riley, Associated Electric Cooperative, Inc., 1, 9/11/2017

- 0 - 0

  • Additional time would be required to plan, budget, and implement this Standard.  Further, only allowing 12 months for implementation may limit the technology solutions that may be implemented to only those that can be accomplished with minimal planning and testing.  GSOC requests twenty-four months.

Guy Andrews, 9/11/2017

- 0 - 0

See 1 above.  Note that additional time may be required to reach consensus between entities when establishing security protocols.

Laura McLeod, 9/11/2017

- 0 - 0

Cannot support at this time until additional clarity is given to requirements for written communications outside of operational data and for Operational Planning Analysis data. If corporate systems require protection that could greatly affect implementation timelines. Additionally, the twelve month window may fall outside of yearly budget planning, compressing project planning timelines.

James Gower, On Behalf of: Entergy, SERC, Segments NA - Not Applicable

- 0 - 0

At least three years is needed in order to coordinate with other entities, including specification, design, budgeting, implementation and testing.

Annette Johnston, 9/11/2017

- 0 - 0

See MidAmerican Energy Company comments.

Terry Harbour, Berkshire Hathaway Energy - MidAmerican Energy Co., 1, 9/11/2017

- 0 - 0

Laurie Williams, 9/11/2017

- 0 - 0

Lynn Goldstein, PNM Resources - Public Service Company of New Mexico, 1, 9/11/2017

- 0 - 0

The coordination time required to perform a migration to secure communications protocols is expected to take longer than the schedule presented by the SDT.  CHPD recommends at least twenty-four (24) calendar months to implement communication updates and implement other available protection measures.

Haley Sousa, 9/11/2017

- 0 - 0

Hot Answers

CHPD cannot determine if the objectives may be accomplished in a cost-effective manner until further clarification is provided for physical or other equally effective protection measures and the request for electronic mail exclusion is added.  CHPD also has concerns with vendor availability, with respect to the system software implementation that will be required for all entities industry-wide.  The comments provided by other entities to develop an industry-wide encryption specification is appealing and CHPD believes that would provide a better method for achieving the desired intra-entity security.

Janis Weddle, 9/11/2017

- 0 - 0

Douglas Webb, 9/11/2017

- 0 - 0

Other Answers

RoLynda Shumpert, On Behalf of: SCANA - South Carolina Electric and Gas Co., SERC, Segments 1, 3, 5, 6

- 0 - 0

The California ISO supports the comments of the Security Working Group (SWG).

- 0 - 0

Nicholas Lauriat, On Behalf of: Network and Security Technologies, , Segments 1

- 0 - 0

Duke Energy agrees that the language provided in R1 appears to provide a Responsible Entity flexibility in how it may implement the standard, but concern exists in the amount of protection options given. Additional documentation such as Implementation Guidance including additional suggestions for implementation may give entities more options to consider, while still keeping the flexibility of determining what is the most suitable method of protection for said entity.

Duke Energy , Segment(s) 1, 5, 6, 4/10/2014

- 0 - 0

TVA suggests additional guidance is needed to identify examples of acceptable standard security mechanisms for exchanging data between entities.  Without clearer guidance some entities may out of an abundance of caution spend beyond what is necessary to mitigate this risk, or expend unnecessary effort determining a mutual security mechanism.

Tennessee Valley Authority, Segment(s) 1, 3, 5, 6, 9/1/2016

- 0 - 0

There will likely be additional costs associated with administrative overhead, hardware, and software, as well as costs associated with monitoring the performance of the implemented solutions.

Laura Nelson, 9/1/2017

- 0 - 0

Dominion, Segment(s) 3, 5, 1, 4/6/2017

- 0 - 0

Sergio Banuelos, On Behalf of: Tri-State G and T Association, Inc., MRO, WECC, Segments 1, 3, 5

- 0 - 0

Anthony Jablonski, ReliabilityFirst , 10, 9/5/2017

- 0 - 0

George Brown, Acciona Energy North America, 5, 9/6/2017

- 0 - 0

 

It may be more cost effective if an industry wide initiative is conducted with encryption specifications.

 

- 0 - 0

In addition to the comments provided in response to question 3, the IESO offers these comments regarding cost effectiveness.  Open Source options to satisfy the requirement to protect communication links and sensitive bulk electric system data communicated between bulk electric systems Control Centers are limited.  Few options generally translated to high vendor leverage, which could lead to high implementation costs.  It is unclear how or whether costs could be shared among participants in the network. Architectural changes to support these requirements should be spread out over several years. Plus there will be business impacts.

Leonard Kula, Independent Electricity System Operator, 2, 9/7/2017

- 2 - 0

To fully assess the logistics and costs associated with compliance, some guidance or specification of boundaries of communications links involved should be provided so that entities can perform an assessment of impacts to their operations.

 

Con Edison, Segment(s) 1, 3, 5, 6, 6/24/2016

- 0 - 0

FMPA, Segment(s) , 8/2/2017

- 0 - 0

Frank Pace, Central Hudson Gas & Electric Corp., 1, 9/7/2017

- 0 - 0

Donald Lock, 9/8/2017

- 0 - 0

  1. To fully assess the logistics and costs associated with compliance, some guidance or specification of boundaries of communications links involved would be required for entities to complete assessment of impacts to their operations.
  2. Architectural changes should be spread out over several budget cycles (years). Plus there will be business impacts. See comments to Q3

David Rivera, New York Power Authority, 3, 9/8/2017

- 0 - 0

Please see our comments to Question 1. The additional flexibility in this context has the potential to cause more confusion when selecting a mechanisms to secure the data.

Philip Huff, 9/8/2017

- 0 - 0

Kristine Ward, On Behalf of: Seminole Electric Cooperative, Inc., FRCC, Segments 1, 2, 4, 5, 6

- 0 - 0

Jennifer Hohenshilt, Talen Energy Marketing, LLC, 6, 9/8/2017

- 0 - 0

Colorado Springs Utilities, Segment(s) 5, 3, 1, 6, 5/6/2015

- 0 - 0

Thank you for adding the third bullet of R1

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

- 0 - 0

See attachment

Alice Wright, Arkansas Electric Cooperative Corporation, 4, 9/8/2017

- 0 - 0

Texas RE does not have comments on this questions.

Rachel Coyne, Texas Reliability Entity, Inc., 10, 9/8/2017

- 0 - 0

See APPA Comments.

Seattle City Light Ballot Body, Segment(s) 1, 4, 6, 5, 3, 12/2/2016

- 0 - 0

Exelon agrees with the approach used in CIP-012-1, which allows each Registered Entity to analyze risk and use discretion in determining the best risk mitigation implementation for protecting transmission of applicable data.

Daniel Gacek, Exelon, 1, 9/8/2017

- 0 - 0

Santee Cooper, Segment(s) 1, 9/8/2017

- 0 - 0

NCPA does not agree that the standard provides entities with the flexibility to implement the standard cost-effectively and offers these further suggestions.  To fully assess the logistics and costs associated with compliance, some guidance or specification of boundaries of communications links involved would be required for entities to complete assessment of impacts to their operations. In addition, architectural changes should be spread out over several budget cycles (years).

Marty Hostler, Northern California Power Agency, 4, 9/8/2017

- 0 - 0

Steven Mavis, 9/8/2017

- 0 - 0

See comments submitted by Robert Blackney on NERC’s proposed modifications to the definition of Control Center

Thomas Rafferty, 9/8/2017

- 0 - 0

NCPA does not agree that the standard provides entities with the flexibility to implement the standard cost-effectively and offers these further suggestions.  To fully assess the logistics and costs associated with compliance, some guidance or specification of boundaries of communications links involved would be required for entities to complete assessment of impacts to their operations. In addition, architectural changes should be spread out over several budget cycles (years).

Dennis Sismaet, Northern California Power Agency, 6, 9/8/2017

- 0 - 0

While the Standard is sufficiently flexible for an individual responsible entity, it leaves a potential chasm between different entities’ interpretation of cost-effective approaches.  A top-tier utility’s impression of a cost effective approach may not match a smaller neighbor’s idea of a cost effective approach.  Such a disparity could encumber both large and small entities with disparate concerns that complicate negotiation and agreement on appropriate solutions.  

Vivian Moser, 9/10/2017

- 0 - 0

David Gordon, 9/11/2017

- 0 - 0

FirstEnergy Corporation, Segment(s) 4, 1, 3, 5, 6, 4/11/2017

- 0 - 0

None at this time

Heather Morgan, EDP Renewables North America LLC, 5, 9/11/2017

- 0 - 0

Eversource Group, Segment(s) 5, 3, 9/11/2017

- 0 - 0

AEP believes that most entities are at the mercy of what Balancing Authorities and Reliability Coordinators will require.  This coupled with the fact that data for Operational Planning and Analysis is included, flexibility may lead to variability and as such makes it only a presumption that solutions will be cost effective.

Aaron Austin, 9/11/2017

- 0 - 0

Barry Lawson, 9/11/2017

- 0 - 0

  1. To fully assess the logistics and costs associated with compliance, some guidance or specification of boundaries of communications links involved would be required for entities to complete assessment of impacts to their operations.

  2. Architectural changes should be spread out over several budget cycles (years). Plus there will be business impacts. See comments to Q3.

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

- 0 - 0

SRP needs more detail on what would be acceptable as physical security to determine if the standard provides adequate flexibility. Also, as stated in response to question 3, significant capital may need to be budgeted in order to implement architecture improvements to address the required computing resources for encrypting and decrypting of data. Additionally, SRP agrees with LPPC’s comment that an industry-wide initiative for an encryption specification may be a more cost-effective approach than a new standard.

Lona Calderon, On Behalf of: Salt River Project, WECC, Segments 1, 3, 5, 6

- 0 - 0

Thank you for adding the third bullet of R1.

Thomas Breene, WEC Energy Group, Inc., 3, 9/11/2017

- 0 - 0

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

- 0 - 0

Cowlitz PUD supports the comments submitted by APPA.

Russell Noble, Cowlitz County PUD, 3, 9/11/2017

- 0 - 0

Jesus Sammy Alcaraz, Imperial Irrigation District, 1, 9/11/2017

- 0 - 0

·         To fully assess the logistics and costs associated with compliance, some guidance or specification of boundaries of communications links involved would be required for entities to complete assessment of impacts to their operations.

·         Architectural changes should be spread out over several budget cycles (years), and there will be business impacts. See comments to Q3

RSC no Con-Edison and Dominion, Segment(s) 10, 2, 4, 5, 6, 7, 1, 3, 9/11/2017

- 0 - 0

ERCOT ISO signs on to the ITC SWG comments:

In addition to the comments provided in response to question 3, the SWG offers these comments regarding cost effectiveness.  Open Source options to satisfy the requirement to protect communication links and sensitive bulk electric system data communicated between bulk electric systems Control Centers are limited.  Few options generally translated to high vendor leverage, which could lead to high implementation costs.  It is unclear how or whether costs could be shared among participants in the network. Architectural changes to support these requirements should be spread out over several years. Plus there will be business impacts.

Elizabeth Axson, 9/11/2017

- 0 - 0

Louisville Gas and Electric Company and Kentucky Utilities Company, Segment(s) 3, 5, 6, 4/13/2017

- 0 - 0

Tacoma Power supports the comments of APPA

Marc Donaldson, Tacoma Public Utilities (Tacoma, WA), 3, 9/11/2017

- 0 - 0

sean erickson, Western Area Power Administration, 1, 9/11/2017

- 0 - 0

Theresa Rakowsky, 9/11/2017

- 0 - 0

APPA agrees that the standard provides entities with the flexibility to implement the standard cost-effectively and offers these further suggestions. To fully assess the logistics and costs associated with compliance, some guidance or specification of boundaries of communications links involved would be required for entities to complete assessment of impacts to their operations. In addition, architectural changes should be spread out over several budget cycles (years). 

Jack Cashin, American Public Power Association, 4, 9/11/2017

- 0 - 0

Lan Nguyen, On Behalf of: CenterPoint Energy Houston Electric, LLC, Texas RE, Segments 1

- 0 - 0

SERC CIPC, Segment(s) 10, 1, 2, 5, 9, 8/19/2016

- 0 - 0

(1)   The standard doesn’t directly address the Inter-Control Center Communications Protocol (ICCP) for exchanging data between control centers or utilities. Will those ICCP servers and supportive infrastructure need to be upgraded or replaced with data encryption capabilities to support compliance with this standard?

 

(2)   The standard doesn’t provide any direction as to what is the level of physical and logical protection that is mandatory.  We ask the SDT to develop guidance to clarify this ambiguity and identify how all entities can achieve a minimum level of compliance.

ACES Standards Collaborators, Segment(s) 1, 3, 4, 5, 9/11/2017

- 0 - 0

See comments submitted by Robert Blackney on NERC’s proposed modifications to the definition of Control Center.

Kenya Streeter, Edison International - Southern California Edison Company, 6, 9/11/2017

- 0 - 0

PSEG supports the NPCC comments.

PSEG REs, Segment(s) 5, 6, 3, 1, 3/6/2017

- 1 - 0

To fully assess the logistics and costs associated with compliance, some guidance or specification of boundaries of communications links involved would be required for entities to complete assessment of impacts to their operations.

Michael Puscas, ISO New England, Inc., 2, 9/11/2017

- 0 - 0

More flexibiity and less guidance could lead to inconsistency on requirement implentation among different entities.

David Greyerbiehl, CMS Energy - Consumers Energy Company, 5, 9/11/2017

- 0 - 0

If it means the data must be protected throughout the transmission, it would seem that could only be accomplished with encryption. For cases where the existing equipment is not capable of encryption, replacement will be costly and implementation lengthy.

Aaron Cavanaugh, On Behalf of: Bonneville Power Administration, WECC, Segments 1, 3, 5, 6

- 0 - 0

More flexibility and less guidance could lead to inconsistency on requirement implementation among different entities.

James Anderson, 9/11/2017

- 0 - 0

Utility Services agrees that the standard provides entities with the flexibility to implement the standard cost-effectively and offers these further suggestions. To fully assess the logistics and costs associated with compliance, some guidance or specification of boundaries of communications links involved would be required for entities to complete assessment of impacts to their operations. In addition, architectural changes should be spread out over several budget cycles (years).

Brian Evans-Mongeon, Utility Services, Inc., 4, 9/11/2017

- 0 - 0

-- ANSWER HAS BEEN REDACTED BY A SYSTEM ADMINISTRATOR --

Robert Blackney, On Behalf of: Edison International - Southern California Edison Company, WECC, Segments 1, 3, 5, 6

- 0 - 0

The cost of implementing the intended protections, as they are understood by Southern, will be prohibitive.  See the response to Question 1 as the primary driver for our disagreement with this question, as well as other supporting information provided in response to Question 3.

Southern Company, Segment(s) 1, 3, 5, 6, 8/3/2016

- 0 - 0

OPG recommends further collaboration to further enhance the cost effectiveness. Solution implementation will require collaboration when the communication link is between CC belonging to different entities. There is also the issue of agreed solution; for example the stronger the protection implemented the higher the budgetary costs. If this may not be an issue for the RC it can be an issue for a small entity required to report to the RC via these communication links.

David Ramkalawan, 9/11/2017

- 0 - 0

Until industry is able to determine the extent of information to be protected extends beyond the real-time 15 minute time frame, we are not able to agree with the statement regarding cost-effective manner.

Ronald Donahey, TECO - Tampa Electric Co., 3, 9/11/2017

- 0 - 0

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

- 0 - 0

SPP Standards Review Group, Segment(s) , 9/11/2017

- 0 - 0

Wendy Center, U.S. Bureau of Reclamation, 5, 9/11/2017

- 0 - 0

- 0 - 0

Lauren Price, 9/11/2017

- 0 - 0

Mark Riley, Associated Electric Cooperative, Inc., 1, 9/11/2017

- 0 - 0

no comments

Guy Andrews, 9/11/2017

- 0 - 0

See 2 above.

Laura McLeod, 9/11/2017

- 0 - 0

Cannot agree with the flexibility and cost effectiveness until additional clarity is given to requirements for written communications outside of operational data and Operational Planning Analysis. If corporate systems require protection that could greatly affect potential cost.

James Gower, On Behalf of: Entergy, SERC, Segments NA - Not Applicable

- 0 - 0

The three bullets are constructive.

Annette Johnston, 9/11/2017

- 0 - 0

See MidAmerican Energy Company comments.

Terry Harbour, Berkshire Hathaway Energy - MidAmerican Energy Co., 1, 9/11/2017

- 0 - 0

Laurie Williams, 9/11/2017

- 0 - 0

Lynn Goldstein, PNM Resources - Public Service Company of New Mexico, 1, 9/11/2017

- 0 - 0

CHPD cannot determine if the objectives may be accomplished in a cost-effective manner until further clarification is provided for physical or other equally effective protection measures and the request for electronic mail exclusion is added.  CHPD also has concerns with vendor availability, with respect to the system software implementation that will be required for all entities industry-wide.  The comments provided by other entities to develop an industry-wide encryption specification is appealing and CHPD believes that would provide a better method for achieving the desired intra-entity security.

Haley Sousa, 9/11/2017

- 0 - 0

Hot Answers

Implementing industry-wide secure communication is a significant coordination challenge for entities and their associated vendors.  The increase in security also brings increased complexity, maintenance, and failure potential that may negatively impact the reliable operation of the BES.  As a result, coordination for encryption key management will become an essential activity and CHPD would, similar to other entity comments, appreciate guidance for these activities.

Janis Weddle, 9/11/2017

- 0 - 0

None.

Douglas Webb, 9/11/2017

- 0 - 0

Other Answers

RoLynda Shumpert, On Behalf of: SCANA - South Carolina Electric and Gas Co., SERC, Segments 1, 3, 5, 6

- 0 - 0

The California ISO supports the comments of the Security Working Group (SWG).

- 0 - 0

Nicholas Lauriat, On Behalf of: Network and Security Technologies, , Segments 1

- 0 - 0

Duke Energy , Segment(s) 1, 5, 6, 4/10/2014

- 0 - 0

TVA notes that the requirement language focuses on the risk of unauthorized disclosure or modification of data.  In an operational environment the integrity and availability legs of the CIA triad are more critical than the confidentiality.  TVA suggests consider revising to focus on ensuring the integrity and availability of the data.

Tennessee Valley Authority, Segment(s) 1, 3, 5, 6, 9/1/2016

- 0 - 0

Laura Nelson, 9/1/2017

- 0 - 0

Applicability:

Based on the first 2 questions in the proposed RSAW requiring entities to prove that the standard does not apply to them, could the Applicability section of the standard be modified to indicate that the standard only applies to those specific registered entities (e.g., GOPs and TOs) that maintain Control Centers AND transmit data between Control Centers?

Additionally, the proposed standard does not provide a sufficient level of detail on how entities should work together to handle security concerns across a communication network.  The standard should clearly identify where the obligations for protecting data in a communication network start and end per entity. 

Technical Rationale:

Does the TO field asset box on page # 5 of Technical Rationale and Justification for CIP-012-1 document include TO Control Centers?  If no, where are TO Control Centers represented ?

Implementation Guidance:

CIP-012 R2 requires the Responsible Entity to implement on or more documented plan(s) to mitigate the risk of the unauthorized disclosure or modification of applicable data whish being transmitted between Control Centers.  Without implementation guidance describing how to accomplish this risk mitigation either physically protecting the communication links transmitting the data or logically protecting the data during transmission; or some other equally effective means it is difficult to predict the amount of time that would be required to implement this requirement part and therefore we cannot assume the 12 months prescribed in the proposed implementation plan is adequate. 

Dominion, Segment(s) 3, 5, 1, 4/6/2017

- 0 - 0

If the region is responsible for the system, what does the entity have to do for compliance? All entities would have to coordinate with the region on a solution. The solution may require additional equipment to be installed. A region-wide formal agreement may be difficult to develop and execute in a year.

Sergio Banuelos, On Behalf of: Tri-State G and T Association, Inc., MRO, WECC, Segments 1, 3, 5

- 0 - 0

Even though ReliabilityFirst votes in the affirmative, ReliabilityFirst provides the following comments for consideration:

  1. Requirement R2

    1. Requirement R2 of the Standard does not identify a “reasonable” timeline for implementing the plan identified in R1.  This lack of time determinant could lead to prolonged and needless delay in implementing the required protections.

    2. Requirement R2 uses the phrase “CIP Exceptional Circumstances”.  The intent is “to protect confidentiality and integrity of data transmitted between Control Centers required for reliable operation of the Bulk Electric System (BES).” 

       

      ReliabilityFirst questions if using the phrase “CIP Exceptional Circumstances” is appropriate here.   The definition of CIP Exceptional Circumstance is defined as “A situation that involves or threatens to involve one or more of the following, or similar, conditions that impact safety or BES reliability: a risk of injury or death; a natural disaster; civil unrest; an imminent or existing hardware, software, or equipment failure; a Cyber Security Incident requiring emergency assistance; a response by emergency services; the enactment of a mutual assistance agreement; or an impediment of large scale workforce availability.”  ReliabilityFirst believes CIP Exceptional Circumstances criteria are not relative to data transmission. 

Anthony Jablonski, ReliabilityFirst , 10, 9/5/2017

- 0 - 0

1- Generator Operators within the ERCOT footprint who are not also a Qualified Scheduling Entity (QSE) will not be able to comply with the standard as written if their Control Center transmits and receives the data as specified in Requirement R1. 

Within the ERCOT footprint the sensitive BES data transmitted between the Control Centers of the Balancing Authority (BA), Transmission Operator (TOP), Reliability Coordinator (RC) and Generator Operator (GOP) is submitted through the QSE (Assume that ERCOT is acting as the RC, BA and/or TOP for particular GOP and that GOP is not also a QSE).   The QSE is not a recognized NERC Functional Entity and as such would not be subject to adhering to NERC Reliability Standards.  Therefore it would not be possible for a GOP to protect the sensitive BES data that is transmitted to and from the Control Center of the QSE and ERCOT that ultimately is either being sent or received by the GOP Control Center.  NERC CIP-012-1, as written, does not account for this ERCOT nuance.

2 - Pursuant to NERC CIP-012-1, §4 Applicability, this standard is applicable to the Generator Owner.  However, the proposed definition of Control Center, exempts the Generator Owner as it only speaks to the Generator Operator’s Control Center. NERC CIP-012-1 should not be applicable to the Generator Owner.

George Brown, Acciona Energy North America, 5, 9/6/2017

- 0 - 0

We seek clarification in the standard verbiage that the intent of this standard applies to inter control center communication.  In addition, it would be beneficial to have guidance on key management and inter utility agreements particularly as it pertains to coordination for encryption of data between 3rd parties and compliance impacts on reliability.    

- 0 - 0

The IESO asserts that the proposed standard does not make clear how entities should work together when addressing security concerns across a communication network link.  If both entities work with CIP Standard assumptions on both ends of a communication network, some support for joint handling of issues could be made clear.  However, if only one entity is CIP-compliant for a given link, the current standard draft does not make clear the extent of protection expected for the data.  The Standard should provide more information on the ownership of obligations for protecting the entire link

It is unclear whether the addition of CIP-012 affects the exemptions of communication networks in any of the applicability sections of other standards (CIP-002 through CIP-011). The IESO requests clarification that CIP-012 fills in some of the gap created the CIP-002 – CIP-011 third party telecommunications exemption (4.2.3.2. Cyber Assets associated with communication networks and data communication links between discrete Electronic Security Perimeters.)

It has been ten years since the SANDIA report (“Secure ICCP Considerations and Recommendations”), the only detailed report on this subject which could be considered close having entered mainstream awareness in the industry.  Today, as ten years ago, Secure ICCP is not a viable choice for utilities, if only due to limited community experience and vendor support, not to mention the complexities of key management. The transition strategies that SANDIA discusses – Layer 3 protection using IPsec and Layer 2 protection with hardware encryption – remain today’s target solutions.

IPsec is a viable alternative.  Over MPLS, IPsec could secure GRE tunnels between CE routers.  Challenges with this approach include the possibility of having to hire a third party to manage certificates and IPsec links, especially for ISOs that do not manage their own MPLS networks.

The IESO position on security architecture is that business transactions (such as ICCP) should not be tightly coupled with encryption technologies.  Solutions should prefer network overlays versus security extensions to a protocol (such as Secure ICCP or DNP3 SA).

The security architecture should prefer least-latent encryption solutions at the Ethernet or IP layers of the network stack.  MACsec (802.1AE) models the spirit of an optimal solution within a metro area – could it scale wider?

The IESO’s overall position on Secure ICCP is that it represents too much reliability risk.  The IESO is concerned about the lack of open standards and protocols available to meet the confidentiality and integrity security objectives of CIP-012.  Assuming that a solution involves encryption, the only two open standards and protocols that can meet the CIP-012 security objectives are IPsec and TLS.  The potential for vendor leverage in such a small open solution space is large.  Vendor-managed MPLS networks, typical among utilities, already entrench high annual telecommunication costs in utility budgets.  Security vendors continue to benefit from the expense of establishing layered cyber defenses.  Open Source solutions provide a cost and agility refuge from this lopsided value chain without compromising defense layers.  The trend toward managed services makes the cost problem worse for utilities, especially in the context of insufficiently evaluated risk.  Vendor leverage only grows given the practical consideration that all the communicating parties in a WAN of connected real-time Control Centers would need to adopt a common solution in order to minimize complexity and cost.

Leonard Kula, Independent Electricity System Operator, 2, 9/7/2017

- 2 - 0

CIP-012-1 should be aligned with TOP-003-3. Data security is already required in TOP-003-3 R5.  Only data that is stipulated in the TOP-003-3 R1 data specification for Operational Planning Analysis, Real-time Assessment, and Real-time monitoring should be in scope for CIP-012.

The proposed standard does not make clear how entities should work together when addressing security concerns across a communication network link. Some guidance regarding joint handling of communication links would be helpful. Where does the obligation for protecting a link per entity start and end?

Con Edison, Segment(s) 1, 3, 5, 6, 6/24/2016

- 0 - 0

FMPA believes that the proposed standard does not make clear how entities should work together when addressing security concerns across a communication network link. Some support for joint handling of issues should be made clear.

FMPA believes that an Implementation Guidance document should be developed and include guidance on possible determination of the security method used being developed at the regional or RC level. This may facilitate a more cost-effective approach. Moreover, the Implementation Guidance could also address the entities evidence needed when they are following what was determined by the Region, RC or ISO.

FMPA, Segment(s) , 8/2/2017

- 0 - 0

Frank Pace, Central Hudson Gas & Electric Corp., 1, 9/7/2017

- 0 - 0

Donald Lock, 9/8/2017

- 0 - 0

The proposed standard does not make clear how entities should work together when addressing security concerns across a communication network link. Some support for joint handling of issues could be made clear. Where does the obligation for protecting a link per entity start and end?

Note: These comments are equivalent to those submitted by the NPCC/TFIST group, except for changes in the Yes/No answers.

David Rivera, New York Power Authority, 3, 9/8/2017

- 0 - 0

Philip Huff, 9/8/2017

- 0 - 0

Kristine Ward, On Behalf of: Seminole Electric Cooperative, Inc., FRCC, Segments 1, 2, 4, 5, 6

- 0 - 0

Jennifer Hohenshilt, Talen Energy Marketing, LLC, 6, 9/8/2017

- 0 - 0

Colorado Springs Utilities, Segment(s) 5, 3, 1, 6, 5/6/2015

- 0 - 0

1.  The NSRF questions the use of “Real-time monitoring” as an applicable object within R1.  “Real-time” is defined as “present time as opposed to future time”.  Which our industry understands and without the word “monitoring” being defined, may lead to misinterpretation by responsible entities and CEAs, alike.  The word “monitoring” may mean ALL monitoring of an entity’s entire SCADA system.  It should be the “monitoring” of BES data, only, that is required for Operational Planning Analysis and Real-time Assessments.   

2.  The Applicability section states, “For requirements in this standard where a specific functional entity or subset of functional entities are the applicable entity or entities, the functional entity or entities are specified explicitly”.   This proposed Standard does not specify any specific entities and we recommend that this is removed.

3.  The NSRF has concerns with the proposed definition of Control Center.  The largest issue is the last paragraph concerning a Generating Operator.  The use of the word “capability” is ambiguous and will confuse Registered Entities and CEAs, a like.  The SDT should consider the approved Applicability within PER-005-2 part 4.1.5.1, which reads:

 Dispatch personnel at a centrally located dispatch center who receive direction from the Generator Operator’s Reliability Coordinator, Balancing Authority, Transmission Operator, or Transmission Owner, and may develop specific dispatch instructions for plant operators under their control. This personnel does not include plant operators located at a generator plant site or personnel at a centrally located dispatch center who relay dispatch instructions without making any modifications.

This aligns with current and understood wording of PER-005-2.

4.  Are the noted “Real-time reliability related- tasks” within the proposed definition, the same “Real-time Reliability-related task prescribed in PER-005-2?  If so, please state this in your consideration of comments document and within your guidance document.

5.  The NSRF believes that data associated with Operational Planning Analyses (OPA), Real-time monitoring (RTm), and Real-time Assessments (RTA) are predicated on other Standards and protection of data is required but all three areas (OPA, RTm, and RTA) are not subject equally to the Applicable Entities noted in CIP-012-1.  Per IRO-010-2, R1, the RC is to document its specifications necessary for OPA, RTm, and RTA.  Per TOP-003-3, R1 the TOP is to document its specifications necessary for OPA, RTm, and RTA.  Per TOP-003-3, R2, the BA is to document its specifications necessary for analysis functions and RTm, only.  The SDT, in the Technical Rationale and Justification document, acknowledges TOP-003 and IRO-010 “provides consistent scoping of identified data” [R1 section: Alignment with IRO and TOP Standards”]. The SDT should quantify that the data to be protected is the data associated with the Applicable entities with IRO-010-2 and TOP-003-3. With doing this, the SDT will articulate what the entity is to perform what analysis and what “data” is to be protected, based on already approved NERC Reliability Standards.  By clearly identifying (and linking) the data to be protected from the data specifications developed under Standards TOP-003 and IRO-010, there is no room for interpretation of what “data” is to be protected.  

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

- 0 - 0

Alice Wright, Arkansas Electric Cooperative Corporation, 4, 9/8/2017

- 0 - 0

Although the FERC order specifies data between Control Centers, Texas RE notes that there is OPA, RTA, Real-time monitoring data that is not between control centers.  For example, Distribution Providers provide BES sensitive data but would not be subject the standard.  Also there are numerous GOPs that do not have a control center per the definition that provide BES sensitive data which also would not subject to CIP-012-1.  Texas RE is concerned this creates a reliability gap since these scenarios would not be covered under the proposed draft of CIP-012-1.

 

Although Texas RE does not oppose a CIP Exceptional Circumstances exception from the implementation requirements set forth in CIP-012-1 R2, Texas RE requests that the SDT provide a rationale for why such an exception is appropriate.  In particular, it is unclear why certain CIP exception conditions, such as an imminent hardware failure, should necessarily trigger a relaxation of physical security protections for communications links transmitted sensitive data in all circumstances.

Rachel Coyne, Texas Reliability Entity, Inc., 10, 9/8/2017

- 0 - 0

See APPA Comments.

Seattle City Light Ballot Body, Segment(s) 1, 4, 6, 5, 3, 12/2/2016

- 0 - 0

N/A

Daniel Gacek, Exelon, 1, 9/8/2017

- 0 - 0

Santee Cooper, Segment(s) 1, 9/8/2017

- 0 - 0

Refer to APPA, TAPs, and Utility Services comments.

Marty Hostler, Northern California Power Agency, 4, 9/8/2017

- 0 - 0

“See comments submitted by Robert Blackney on NERC’s proposed modifications to the definition of Control Center”

Steven Mavis, 9/8/2017

- 0 - 0

See comments submitted by Robert Blackney on NERC’s proposed modifications to the definition of Control Center

Thomas Rafferty, 9/8/2017

- 0 - 0

Refer to APPA, TAPs, and Utility Services comments.

Dennis Sismaet, Northern California Power Agency, 6, 9/8/2017

- 0 - 0

AZPS reiterates its comments provided in response to Requirement R1 regarding clear delineation of responsibilities between receiving and transmitting entities.  Because the potential impacts of a receiving entity not appropriately implementing the technology needed for decryption or use of protected data sent by a transmitting entity lie outside of the proposed Requirement R1 in real-time data and assessment obligations, placement of the obligations for Requirement R1 on the transmitting is appropriate and reduces the potential for double jeopardy and/or “waterfall” non-compliance events.  Hence, AZPS suggests that it is appropriate to place the obligation for Requirement R1 on the transmitting entity. 

Finally, AZPS reiterates the NERC ORD as a reference guide and resource regarding the scope of this standard and sensitive data generally.  The NERC ORD Agreement has long maintained an accepted, well-established definition for sensitive reliability data.  That definition does not include data utilized in the Operational Planning Horizon and, for the reasons discussed above, AZPS asserts that the inclusion of Operational Planning Analysis in Requirement R1 extends the scope of BES sensitive data without attendant benefit to reliability.  AZPS recommends the deletion of Operational Planning Analysis from Requirement R1 to allow the Requirement to remain consistent with well-established, well understood precedent as set forth in the NERC ORD Agreement.

 

Vivian Moser, 9/10/2017

- 0 - 0

David Gordon, 9/11/2017

- 0 - 0

FirstEnergy Corporation, Segment(s) 4, 1, 3, 5, 6, 4/11/2017

- 0 - 0

Heather Morgan, EDP Renewables North America LLC, 5, 9/11/2017

- 0 - 0

Clarification needed – Does 'data used for Operational Planning Analysis, Real-time Assessments, and Real-time monitoring ' include Generator Unit Commitment Data and/or transmission and generator outages which are posted publicly?

Eversource Group, Segment(s) 5, 3, 9/11/2017

- 0 - 0

AEP suggests these should be added to the diagram as clearly in scope.

 

 

 

Aaron Austin, 9/11/2017

CIP-012-1 – Cyber Security -Communication Networks Diagram.doc

- 0 - 0

NRECA appreciates the continuing efforts of the SDT.

Barry Lawson, 9/11/2017

- 0 - 0

The proposed standard does not make clear how entities should work together when addressing security concerns across a communication network link. Some support for joint handling of issues could be made clear. Where does the obligation for protecting a link per entity start and end?

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

- 0 - 0

One challenge associated with CIP-012-1 is industry-wide coordination would be necessary to successfully implement encryption.

In addition to adding latency, encryption adds burden for ongoing maintenance and management for an encryption program. SRP agrees with LPPC that guidance is needed on key management and inter utility agreements pertaining to coordination for encryption of data and impacts on real-time operation of the Bulk Electric System.

Lona Calderon, On Behalf of: Salt River Project, WECC, Segments 1, 3, 5, 6

- 0 - 0

1.  We question the use of “Real-time monitoring” as an applicable object within R1.  “Real-time” is defined as “present time as opposed to future time”.  Which our industry understands and without the word “monitoring” being defined, may lead to misinterpretation by responsible entities and CEAs, alike.  The word “monitoring” may mean ALL monitoring of an entity’s entire SCADA system.  It should be the “monitoring” of BES data, only, that is required for Operational Planning Analysis and Real-time Assessments.  

 

2.  The Applicability section states, “For requirements in this standard where a specific functional entity or subset of functional entities are the applicable entity or entities, the functional entity or entities are specified explicitly”.   This proposed Standard does not specify any specific entities and recommend that this be removed.

 

3.  We have concerns with the proposed definition of Control Center.  The largest issue is the last paragraph concerning a Generating Operator.  The use of the word “capability” is ambiguous and will confuse Registered Entities and CEAs, a like.  The SDT should consider the approved Applicability within PER-005-2 part 4.1.5.1, which reads:

 

 Dispatch personnel at a centrally located dispatch center who receive direction from the Generator Operator’s Reliability Coordinator, Balancing Authority, Transmission Operator, or Transmission Owner, and may develop specific dispatch instructions for plant operators under their control. These personnel do not include plant operators located at a generator plant site or personnel at a centrally located dispatch center who relay dispatch instructions without making any modifications.

 

This aligns with current and understood wording of PER-005-2.

 

4.  Are the noted “Real-time reliability related- tasks” within the proposed definition, the same “Real-time Reliability-related task prescribed in PER-005-2?  If so, please state this in your consideration of comments document and within your guidance document.

 

5.  We believe that data associated with Operational Planning Analyses (OPA), Real-time monitoring (RTm), and Real-time Assessments (RTA) are predicated on other Standards and protection of data is required but all three areas (OPA, RTm, and RTA) are not subject equally to the Applicable Entities noted in CIP-012-1.  Per IRO-010-2, R1, the RC is to document its specifications necessary for OPA, RTm, and RTA.  Per TOP-003-3, R1 the TOP is to document its specifications necessary for OPA, RTm, and RTA.  Per TOP-003-3, R2, the BA is to document its specifications necessary for analysis functions and RTm, only.  The SDT, in the Technical Rationale and Justification document acknowledges TOP-003 and IRO-010 “provides consistent scoping of identified data” [R1 section: Alignment with IRO and TOP Standards”]. The SDT should quantify that the data to be protected is the data associated with the Applicable entities with IRO-010-2 and TOP-003-3. With doing this, the SDT will articulate what the entity is to preform what analysis and what “data” is to be protected, based on already approved NERC Reliability Standards.  By clearly identifying (and linking) the data to be protected from the data specifications developed under Standards TOP-003 and IRO-010, there is no room for interpretation of what “data” is to be protected. 

Thomas Breene, WEC Energy Group, Inc., 3, 9/11/2017

- 0 - 0

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

- 0 - 0

Although Cowlitz PUD agrees with the intent of the proposed standard, we are concerned the protective measures developed by entities could have unintended consequences.  In particular, there is concern encryption could unacceptably slow data transmission.

Russell Noble, Cowlitz County PUD, 3, 9/11/2017

- 0 - 0

Jesus Sammy Alcaraz, Imperial Irrigation District, 1, 9/11/2017

- 0 - 0

·         The proposed standard does not make clear how entities should work together when addressing security concerns across a communication network link. Some support for joint handling of issues could be made clear. Where does the obligation for protecting a link per entity start and end?

RSC no Con-Edison and Dominion, Segment(s) 10, 2, 4, 5, 6, 7, 1, 3, 9/11/2017

- 0 - 0

ERCOT ISO signs on to the ITC SWG comments:

The ITC SWG asserts that the proposed standard does not make clear how entities should work together when addressing security concerns across a communication network link.  If both entities work with CIP Standard assumptions on both ends of a communication network, some support for joint handling of issues could be made clear.  However, if only one entity is CIP-compliant for a given link, the current standard draft does not make clear the extent of protection expected for the data.  The Standard should provide more information on the ownership of obligations for protecting the entire link.

It is unclear whether the addition of CIP-012 affects the exemptions of communication networks in any of the applicability sections of other standards (CIP-002 through CIP-011). The SWG requests clarification that CIP-012 fills in some of the gap created the CIP-002 – CIP-011 third party telecommunications exemption (4.2.3.2. Cyber Assets associated with communication networks and data communication links between discrete Electronic Security Perimeters.)

It has been ten years since the SANDIA report (“Secure ICCP Considerations and Recommendations”), the only detailed report on this subject which could be considered close having entered mainstream awareness in the industry.  Today, as ten years ago, Secure ICCP is not a viable choice for utilities, if only due to limited community experience and vendor support, not to mention the complexities of key management. The transition strategies that SANDIA discusses – Layer 3 protection using IPsec and Layer 2 protection with hardware encryption – remain today’s target solutions.

WECC, and specifically the WECC DEMSWG (Data Exchange and EMS Working Group) has been working with Pacific Northwest National Laboratory (PNNL) for some time on a new evaluation of Secure ICCP.  PNNL recently completed their work and presented the results to DEMSWG in 2016.  The PNNL study functionally succeeded but with enough limitations that PNNL was prompted to conclude that it would be difficult to make a business case for implementing Secure ICCP when other solutions are available.

IPsec is a viable alternative.  Over MPLS, IPsec could secure GRE tunnels between CE routers.  Challenges with this approach include the possibility of having to hire a third party to manage certificates and IPsec links, especially for ISOs that do not manage their own MPLS networks.

The ITC SWG position on security architecture is that business transactions (such as ICCP) should not be tightly coupled with encryption technologies.  Solutions should prefer network overlays versus security extensions to a protocol (such as Secure ICCP or DNP3 SA).

The security architecture should prefer least-latent encryption solutions at the Ethernet or IP layers of the network stack.  MACsec (802.1AE) models the spirit of an optimal solution within a metro area – could it scale wider?

The ITC SWG’s overall position on Secure ICCP is that it represents too much reliability risk.  The ITC SWG is concerned about the lack of open standards and protocols available to meet the confidentiality and integrity security objectives of CIP-012.  Assuming that a solution involves encryption, the only two open standards and protocols that can meet the CIP-012 security objectives are IPsec and TLS.  The potential for vendor leverage in such a small open solution space is large.  Vendor-managed MPLS networks, typical among utilities, already entrench high annual telecommunication costs in utility budgets.  Security vendors continue to benefit from the expense of establishing layered cyber defenses.  Open Source solutions provide a cost and agility refuge from this lopsided value chain without compromising defense layers.  The trend toward managed services makes the cost problem worse for utilities, especially in the context of insufficiently evaluated risk.  Vendor leverage only grows given the practical consideration that all the communicating parties in a WAN of connected real-time Control Centers would need to adopt a common solution in order to minimize complexity and cost.

Elizabeth Axson, 9/11/2017

- 0 - 0

Louisville Gas and Electric Company and Kentucky Utilities Company, Segment(s) 3, 5, 6, 4/13/2017

- 0 - 0

Tacoma Power supports the comments of APPA

Marc Donaldson, Tacoma Public Utilities (Tacoma, WA), 3, 9/11/2017

- 0 - 0

sean erickson, Western Area Power Administration, 1, 9/11/2017

- 0 - 0

n/a

Theresa Rakowsky, 9/11/2017

- 0 - 0

APPA believes that the proposed standard does not make clear how entities should work together when addressing security concerns across a communication network link. Some support for joint handling of issues should be made clear.

Public power believes that an Implementation Guidance document should be developed and include guidance on possible determination of the security method used being developed at the regional or RC level. This may facilitate a more cost-effective approach. Moreover, the Implementation Guidance could also address the entities evidence needed when they are following what was determined by the Region, RC or ISO.

 

Jack Cashin, American Public Power Association, 4, 9/11/2017

- 0 - 0

The STD should consider changing the title of the CIP-012-1 requirement to “CIP-012-1-Cyber Security – Control Center Communication Links” to align with the language in FERC Order No. 822 and the language in Requirement R1.  The current use of the term “Networks” may be misleading because it implies a broader scope of communication.

Additionally, the violation severity levels (VSL) for this requirement is limited to “Severe”.  CenterPoint Energy recommends that Requirement R1 VSL be “Moderate” to “High” due to the fact that Requirement R1 is a documentation requirement.

Lan Nguyen, On Behalf of: CenterPoint Energy Houston Electric, LLC, Texas RE, Segments 1

- 0 - 0

NA

SERC CIPC, Segment(s) 10, 1, 2, 5, 9, 8/19/2016

- 0 - 0

We thank you for this opportunity to provide these comments.

ACES Standards Collaborators, Segment(s) 1, 3, 4, 5, 9/11/2017

- 0 - 0

See comments submitted by Robert Blackney on NERC’s proposed modifications to the definition of Control Center.

Kenya Streeter, Edison International - Southern California Edison Company, 6, 9/11/2017

- 0 - 0

PSEG supports the NPCC comments.

PSEG REs, Segment(s) 5, 6, 3, 1, 3/6/2017

- 1 - 0

Comments:  

  • The proposed standard does not make clear how entities should work together when addressing security concerns across a communication network link.  If both entities work with CIP Standard assumptions on both ends of a communication network, some support for joint handling of issues could be made clear.  However, if only one entity is CIP-compliant for a given link, the current standard draft does not make clear the extent of protection expected for the data.  Where does the obligation for protecting a link per entity start and end?

  • Does the addition of CIP-012 affect the exemptions of communication networks in any of the applicability sections of other standards (CIP-002 through CIP-011)?

  • While the CIP standards should emphasize outcomes and allow entities to achieve specific security objectives in many ways, protections applied to communications should be evaluated with due consideration of the context in which people, processes and technology are applied to establish a given security protection.  Demonstration of risk mitigation should include assessment of not just technology and process to provide protection, but also the diversity and severity of threats present in a given context (e.g. the difference between dedicated communication links as opposed to broadly shared communications infrastructure).  Particular technology and process applied in a context with fewer or lower likelihood threats should be preferred over the same technology and process in a context with more or greater likelihood threats (i.e. greater overall risk).  Simply specifying that some (how much?) risk mitigation should be applied by means that include physical, logical and possibly other means leads to insufficient conditions for establishing compliance both for the responsible entity and anyone reviewing compliance for that entity.  Entities should consider not only that risk mitigation should take place, but also the thresholds for residual risk that should be considered acceptable for such communication. 

  • It should be noted that in a recent report from the National Infrastructure Advisory Council (NIAC) to the DHS and President of the United States, the NIAC recommended that separate communication networks be used for critical communications (reference https://www.dhs.gov/publication/niac-securing-cyber-assets-addressing-urgent-cyber-threats-critical-infrastructure-final, report page 3, first recommendation).

Michael Puscas, ISO New England, Inc., 2, 9/11/2017

- 0 - 0

David Greyerbiehl, CMS Energy - Consumers Energy Company, 5, 9/11/2017

- 0 - 0

BPA suggests adding the verbiage “where technically feasible” to the requirements, in order to implement controls where appropriate, based on the technology (as discussed in Q1) and risk.

Aaron Cavanaugh, On Behalf of: Bonneville Power Administration, WECC, Segments 1, 3, 5, 6

- 0 - 0

James Anderson, 9/11/2017

- 0 - 0

Utility Services believes that the proposed standard does not make clear how entities should work together when addressing security concerns across a communication network link. Some support for joint handling of issues should be made clear.

 

Utility Services believes that an Implementation Guidance document should be developed and include guidance on possible determination of the security method used being developed at the regional or RC level. This may facilitate a more cost-effective approach. Moreover, the Implementation Guidance could also address the entities evidence needed when they are following what was determined by the Region, RC or ISO.

 

 

Brian Evans-Mongeon, Utility Services, Inc., 4, 9/11/2017

- 0 - 0

Robert Blackney, On Behalf of: Edison International - Southern California Edison Company, WECC, Segments 1, 3, 5, 6

- 0 - 0

If the SDT retains a data-centric approach, we believe the time element is very important and is correctly captured in the requirement with the phrase “while being transmitted between Control Centers.”  We encourage the SDT to retain this language.  We note the RSAW drops the time element and just says “transmitted between”.  The time element is very important, as data transmitted between Control Centers a year ago is not the focus of this standard.  This will, ideally, be reflected in the Standard itself, as well as the Technical Rationale and the RSAW, for clarity.

Southern Company, Segment(s) 1, 3, 5, 6, 8/3/2016

- 0 - 0

OPG understands the focus is on protection of data communication between control centers but would like to clarify that it is not being required to verify integrity of data from it’s origination points to the point where it’s first aggregated at a control center, as this would be a substantially more difficult and costly requirement to achieve.

David Ramkalawan, 9/11/2017

- 0 - 0

Tampa Electric appreciates the efforts of the Standards Drafting Team in developing protections for Communication Networks. We have concerns that the scope of the standard regarding data protection (based on IRO-010 and TOP-003) extends the requirement to data/information that is not currently required to be protected at the level of a High Impact BES Cyber System.  This approach does not match the intent and protections of all other NERC CIP standards.

Ronald Donahey, TECO - Tampa Electric Co., 3, 9/11/2017

- 0 - 0

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

- 0 - 0

The SPP Standards Review Group recommends the drafting team verifies and confirms that the NERC defined terms ‘Operational Planning Analyses’, ‘Real-time Assessments’, and ‘Real-time’ (mentioned in the Rationale Section in reference to Requirement R1) are defined and  properly aligned with the Rules of Procedure (RoP) documentation. We have a concern that if the terms aren’t properly defined and aligned in both documents that this could lead to potential interpretation issues for future projects. During the verification process, should the drafting team discover that there is supporting evidence to SPP’s concerns, we would recommend the drafting team developing a Standard Authorization Request (SAR) to help ensures that both documents have consistency in the definition of the terms mentioned.

The SPP Standard Review Group would ask the drafting team to provide clarity on why the RoP is not mentioned in the Implementation Plan like the NERC Glossary of Terms. From our perspective, the RoP and the definitions, it contains have the same significance that the Glossary of Terms have in reference to the industry defined terms.

 

SPP Standards Review Group, Segment(s) , 9/11/2017

- 0 - 0

Reclamation recommends the SDT define the term “Real-time monitoring” in the NERC Glossary of Terms.

 

The Applicability section states, “For requirements in this standard where a specific functional entity or subset of functional entities are the applicable entity or entities, the functional entity or entities are specified explicitly.” No Requirements in this proposed Standard explicitly specify a functional entity or entities; therefore, Reclamation also recommends that this sentence be removed.

Wendy Center, U.S. Bureau of Reclamation, 5, 9/11/2017

- 0 - 0

IMPA is attaching its comments for Control Center.  The feedback/survey sheet is not linked to this vote.  Our Control Center survey response is attached.

2016-02_Unofficial_Comment_Form_Control_Center_Definition_08142017.docx

- 0 - 0

Not Applicable

Lauren Price, 9/11/2017

- 0 - 0

Mark Riley, Associated Electric Cooperative, Inc., 1, 9/11/2017

- 0 - 0

Guy Andrews, 9/11/2017

- 0 - 0

No additional comments.

Laura McLeod, 9/11/2017

- 0 - 0

James Gower, On Behalf of: Entergy, SERC, Segments NA - Not Applicable

- 0 - 0

Annette Johnston, 9/11/2017

- 0 - 0

Terry Harbour, Berkshire Hathaway Energy - MidAmerican Energy Co., 1, 9/11/2017

- 0 - 0

Laurie Williams, 9/11/2017

- 0 - 0

Lynn Goldstein, PNM Resources - Public Service Company of New Mexico, 1, 9/11/2017

- 0 - 0

Implementing industry-wide secure communication is a significant coordination challenge for entities and their associated vendors.  The increase in security also brings increased complexity, maintenance, and failure potential that may negatively impact the reliable operation of the BES.  As a result, coordination for encryption key management will become an essential activity and CHPD would, similar to other entity comments, appreciate guidance for these activities.

Haley Sousa, 9/11/2017

- 0 - 0