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

2018-02 Modifications to CIP-008 | Standard Authorization Request

Description:

Start Date: 08/10/2018
End Date: 09/10/2018

Associated Ballots:

Ballot Name Project Standard Pool Open Pool Close Voting Start Voting End

Filter:

Hot Answers

Tacoma Power supports comments provided by APPA.

John Merrell, On Behalf of: Tacoma Public Utilities (Tacoma, WA), , Segments 1, 3, 4, 5, 6

- 0 - 0

If SAR is working towards a must report requirement of Cyber Security Incidents that compromise, or attempt to compromise ESP and/or associated EACMS, they need to clearly define the Severity Level for the incident which must be a reportable incident. This should be based on the impact to critical functions as determined by responsible entity.

William Sanders, On Behalf of: William Sanders, , Segments 1, 5

- 0 - 0

Other Answers

The proposed is unnecessary.

Marty Hostler, On Behalf of: Northern California Power Agency, , Segments 5, 6

- 0 - 0

The proposed is unnecessary.

Dennis Sismaet, On Behalf of: Northern California Power Agency, , Segments 5, 6

- 0 - 0

Sandra Shaffer, On Behalf of: Sandra Shaffer, , Segments 6

- 0 - 0

 

AEP believes the scope of the SAR should be restricted to detected Cyber Security Incidents.  One cannot report or act on an incident that has not yet been detected.

 

 

For many entities, it is very likely that governmental entities alone would be able to determine intent. To truly know the motivations, one would also have to know the actor, and that information would not necessarily be known by most responsible entities.

 

 

 

We dissagree with pursuing an entirely new standard to meet the directives, and believe that option should be struck from the SAR. Instead, the concerns should be met by revising CIP-008-5 alone.

Thomas Foltz, On Behalf of: AEP, , Segments 3, 5

- 0 - 0

Debra Boothe, On Behalf of: Western Area Power Administration, NA - Not Applicable, Segments NA - Not Applicable

- 0 - 0

Vivian Moser, On Behalf of: Vivian Moser, , Segments 1, 3, 5, 6

- 0 - 0

MEC agrees with SAR regarding the scope of “attempted compromise” to include unauthorized access attempts (which excludes employees mis-entering their passwords) or other confirmed suspicious activity.

Darnez Gresham, On Behalf of: Berkshire Hathaway Energy - MidAmerican Energy Co., MRO, Segments 1, 3

- 0 - 0

Leonard Kula, On Behalf of: Independent Electricity System Operator, , Segments 2

- 0 - 0

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

- 0 - 0

FirstEnergy, Segment(s) 4, 3, 5, 6, 9/5/2018

- 0 - 0

Tho Tran, On Behalf of: Oncor Electric Delivery - Texas RE - Segments 1

- 0 - 0

Our SMES found this to be tougher than they thought as it is difficult to tell what is implied by the first 4 items.  The highlighted comment below is what City Light believes needs to be explicitly added to the SAR or the Standard will be incomplete.  Note that most of this sentence is actually straight from the FERC Order and discussed in Chatterjee’s memo supporting this order.

 

  1. Develop a definition of an “attempt to compromise”, and include criteria to identify the appropriate assets and the level of attempted compromise that warrants reporting

 

We believe it is important to push for very good definitions of what constitutes a compromise, and more importantly, what constitutes an “attempt to compromise”.  There are numerous attempts to compromise our IT networks every day, much of which is simply automated scanning looking for weaknesses – not a targeted attack.  Even more difficult, would be to determine which of these are attempts to compromise an ESP or EACMS.  Someone failing to get through to the IT network may indeed be attempting to compromise an ESP – but we won’t see this at the ESP level.  Conversely, someone may have compromised the IT network and is now scanning the rest of the internal network looking for targets.  We may detect this activity at the ESP level, but it is not necessarily an attempt to compromise the ESP…  Hence, the need to have clear definitions.

Thank you for giving us the opportunity to comment and for listening to our suggestion.

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

- 0 - 0

Our CIP Working Group met and we would like more clarification on the first element that is outlined by FERC, specifically around the clause, “or attempt to compromise.”  We would like to know more what an “attempt” is.  Is there a definition for this?

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

- 0 - 0

None

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

- 0 - 0

  In general, SRP agrees the SAR captures the directive from FERC Order 848. However, SRP contends the item regarding timelines in the Order was not explicitly included and should be identified within the scope.

In the FERC Order 848, FERC states “NERC should develop reporting timelines for Cyber Security Incidents that are commensurate with the adverse or attempted adverse impact to the BES that loss, compromise, or misuse of those BES Cyber Systems could have on the reliable operation of the BES.” However, the SAR only documents the directive for deadlines, as stated in page 12 of the Order, but SRP believes NERC should also create guidance for timelines.

SRP also asserts NERC should define or provide guidance for determining access attempts and suspicious activity. The FERC Order simply eluded that access attempts meant failed login attempts, but was never formally defined.

    

Russell Martin II, On Behalf of: Salt River Project, WECC, Segments 1, 3, 5

- 0 - 0

Douglas Johnson, On Behalf of: Douglas Johnson, , Segments 1

- 0 - 0

NV Energy agrees with the scope proposed for modifying CIP-008-5 to augment reporting of Cyber Security Incidents. NV Energy request that NERC maintain that the new reporting requirements will be tailored to provide better information on cyber security threats and vulnerabilities, without imposing an undue burden on responsible entities.

Kevin Salsbury, On Behalf of: Berkshire Hathaway - NV Energy, , Segments 5

- 0 - 0

Texas RE agrees with the project and the SAR. 

 

Since Project 2016-02 is also potentially revising the definitions of ESP and PSP, Texas RE cautions the drafting teams of both projects to coordinate and adhere to the FERC description of EACMs in Order No. 848.  Texas RE also notes that if the drafting team includes EACMs in CIP-008, the definitions of Cyber Security Incident and Reportable Cyber Security Incident will need to be expanded as they are currently limited to ESP, PSP, and BCS.

Rachel Coyne, On Behalf of: Texas Reliability Entity, Inc., , Segments 10

- 0 - 0

The Standard Drafting Team (SDT) nomination form for this Project states, “A significant time commitment is expected of SDT members to meet the six-month regulatory deadline established in Order No. 848”. Later the nomination form states “Due to the expedited timeline on this project”.   NPPD realizes that this is a FERC order, however giving drafting teams limited time frames for Standard Development leads to Standards that are hurried along  to address a FERC deadline, which can result in a poorly written Standard. Standards that are not well written lead to industry application inconsistencies upon the effective date, then consistency issues across regions including in-consistent application of Enforcement .

This project appears to include a new Standard, a Standard revision as well as having impact to the Glossary terms. There will be little time for the drafting team to consider alternatives to meet the FERC Order, to draft a well thought-through Standard  and implications, and to consider industry comments to their work. In fact, Industry can expect answers to comments that will simply reference the FERC order and the timeline.

We would recommend that NERC request an extension of the six month period, from FERC, to bring this Standard to FERC.

Don Schmit, On Behalf of: Don Schmit, , Segments 1, 3, 5

- 0 - 0

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

- 0 - 0

We agree with the scope of the SAR, however we would like the drafting team to consider the following points:

  • When drafting the standard, a matrix for identifying incidents and reporting requirements similar to EOP-004 is requested such as the one below to help provide clarity and consistency:

Incident                            Scope                                  Initial Reporting Timeframe          Updated Reporting Timeframe

Malware detected             BCSs, BCAs, ESPs,             Within X hour of detection               Within Y hours of initial report 
that was not resolved       EACMS 
with antimalware

Unexplained accounts      BCSs, BCAs, ESPs,             Within X hour of determination        Within Y hours of initial report
or escalation                     EACMS

 

  • The above matrix is not all inclusive; however, a format of this type would provide Entities with guidance on what is in scope and how the standard applies to each asset type.  It is also requested that ‘Compromise’ and ‘Attempted Compromise’ be defined and added to the NERC Glossary of Terms.
     
  • The scope should focus solely on the BCSs, BCAs, ESPs, and the EACMS protecting those networks and not include corporate network compromises that do not impact NERC CIP Cyber Assets (e.g. EACM  Cyber Assets on a Corporate Network would require reporting, as a server for internal news page on the corporate network would not require reporting.)  Specifically, a scope column in the requested matrix above could address this.
     
  • The SDT also needs to consider FERC’s comments as it relates to timing of reporting.  While in paragraph 89 of the order FERC states the timelines should be based on a risk impact assessment, it is important to note that, while reporting must be timely, it is also those higher risk scenarios which require extensive resources to resolve.  The new standard must allow the Entities to balance reporting versus resolving the issue to prevent further damage to the BPS.  In regards to the specific details of reporting, the SDT should consider a process that contemplates multiple filings.  First, an initial report could be filed, stating that something has occurred and providing a set of high level details.  This would be followed by a second, more detailed report that provides the specific information FERC has asked for in Paragraph 91 of their order.  This would allow the Entity to make industry aware of an issue, allow time to remediate their systems, and then report the details as FERC has requested, thus helping to protect the BPS, while also allowing time for “working the issue”.  Each of these reports could be given deadlines on filing.
     
  • NERC has always stated that E-ISAC would notify other agencies (DHS, ICS-CERT, DOE, etc.) of issues reported.  It would seem those government agencies should be able to share information without adding burden to the Entities.  If the new rule will require multiple reporting, the form that is required should be standardized.  The SDT should be sensitive to keeping resolution of the issue as the top priority and not prescribe reporting that results in the Entity’s emphasis shifting to complying with reporting as opposed to remediation and resolution of an issue.
     
  • The SDT also needs to consider information protection with respect to how reports will be submitted in a secure manner (i.e. use of encrypted attachments via email and password management could become problematic).

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

- 0 - 0

Overall Exelon feels the project scope of this SAR is appropriate if the specific areas identified below will be addressed.

Specific comments on the 4 elements as outlined by FERC:

1. Responsible entities must report Cyber Security Incidents that compromise, or attempt to compromise, a responsible entity’s ESP or associated EACMS;

 COMMENT:

 Within the scope of this work, we would expect to see the following addressed:

  1. Clearly state the full intent of the new modifications.

  2. How does FERC/NERC classify an “attempt” (i.e. dropped packets, actual firewall breach, etc.) and what is an “Incident”? Is it defined by the utilities own determination?  This question arose because utilities could potentially be overreporting events that aren’t necessarily considered or classified as incidents.  If what is considered an internal incident doesn’t rise to that level, are we required to report those incidents? 

  3. Include a clear definition of what qualifies as a “Reportable Cybersecurity Incident.”

  4. Include some form of document or technical basis, which determines specifically what is needed would be beneficial to the utilities. 

2. Required information in Cyber Security Incident reports should include certain minimum information to improve the quality of reporting and allow for ease of comparison by ensuring that each report includes specified fields of information;

COMMENT:

Yes, this is appropriate to be included in the project scope, to identify the minimum reporting field requirements.

3. Establish deadlines for filing Cyber Security Incidents that are commensurate with incident severity; and

COMMENT:

Yes, this is appropriate to be included in the project scope.  It will be critical to first clearly define “Reportable Cyber Security Incidents” that require reporting deadlines.

4. Cyber Security Incident reports should be sent to the Electricity Information Sharing and Analysis Center (E-ISAC) and the Department of Homeland Security (DHS) Industrial Control Systems Cyber Emergency Response Team (ICS-CERT).

COMMENT:

  • The scope should also address what happens once the incident information is shared and reported to the E-ISAC, DHS?

  • The scope should address minimizing duplication of effort, i.e. avoiding the sending of multiple reports to multiple reporting entities.

Daniel Gacek, On Behalf of: Exelon, , Segments 1, 3, 5, 6

- 0 - 0

Kimberly Van Brimer, On Behalf of: Southwest Power Pool, Inc. (RTO), MRO, Segments 2

- 0 - 0

APPA believes that the scope of Project 2018-02 is appropriate, but feels that additional specificity would provide the future standard drafting team (SDT) a clearer picture on what is desired.  Balancing new requirements without imposing undue burdens on responsible reporting entities is indeed a key concept that needs to be adhered to for a successful standard to be drafted. The SAR however, remains broad, leaving the SDT with the significant task of deciding on what terms need to be defined and attempting to set the “real” scope of the standard.  

For example, it is stated the SDT will “provide better information on cyber security threats and vulnerabilities.” By providing information on threats and vulnerabilities, does this mean that the SDT will have to discern what rises to the the level of an incident and thereby what constitutes a compromise of entities’ Electronic Security Perimeter (ESP) or associated Electronic Acess Control or Monitoring System (EACMS)?   

APPA would recommend that the SAR explicitly state that the SDT develop a definition of what constitutes an “attempt to compromise.” Moreover, in providing such a definition, that there also be criteria included that would identify the appropriate assets and the level of attempted compromise that warrants reporting.

The key to such specificity regarding the definition of “attempt to compromise” and associating that definition to defined assets will avoid potential confusion going forward.  Attempts are numerous, while specific targeted attacks are not.  The SAR needs to provide direction to the SDT about the compromise term for complying entities to be able to distinguish between attempts and attacks.   

Jack Cashin, On Behalf of: American Public Power Association, , Segments 4

- 0 - 0

If the SAR is working towards a must report requirement of Cyber Security Incidents that compromise, or attempt to compromise ESP and/or associated EACMS, they need to clearly define the Severity Level for the incident which must be a reportable incident. This should be based on the impact to critical functions as determined by responsible entity.

Teresa Krabe, On Behalf of: Lower Colorado River Authority, , Segments 1, 5

- 0 - 0

  Remove element #4, so that the reporting remains with E-ISAC.    

Anton Vu, On Behalf of: Los Angeles Department of Water and Power, , Segments 1, 3, 5, 6

- 0 - 0

RSC no Dominion and Hydro One, Segment(s) 10, 2, 4, 5, 7, 1, 3, 6, 0, 9/10/2018

- 0 - 0

We fully support any reporting requirements that provide better information on cyber security threats and vulnerabilities without imposing an undue burden on responsible entities.

Payam Farahbakhsh, On Behalf of: Hydro One Networks, Inc., , Segments 1, 3

- 0 - 0

Southern Company does have broad concerns regarding the proposed scope in the FERC Final Rule and addressed in the SAR.

 

  1. Our organization works within an understanding that the purpose of CIP-008 is to mitigate the risk to the reliable operation of the BES as the result of a Cyber Security Incident by specifying incident response requirements. Thus, any work which focuses on requiring a datamining effort to facilitate industry awareness of cyber security risk and scope of cyber-related threats facing the Bulk-Power System is not consistent with the stated purpose or scope of CIP-008.  However, given no other alternative, Southern feels the SDT should put forth concerted effort to ensure any modified CIP-008 requirements minimize the impact and undue burden to responsible entities in the wake of response and recovery efforts. 

     

  2. Southern Company asserts that the reporting requirements described in the SAR create a double-reporting burden for responsible entities. It is our position that the current process of voluntary reporting to E-ISAC has been effective and efficient in capturing and distributing cyber risk information and information on incidents and potential incidents to asset owners and operators. Additional and duplicative involuntary reporting requirements place unnecessary administrative burden on a responsible entity during times where focus must be squarely on responding to an incident and maintaining reliability.

    Further, dual reporting to the ICS-CERT breeches important “firewall” and physical separations between voluntary reporting to the E-ISAC and required, involuntary reporting and recording that is to be placed under compliance scrutiny. Significant administrative burden is involved in the latter category while also risking the placement of such information into public record that may ultimately assist those who may conduct cyber-related attacks on responsible entities. It would be ideal for E-ISAC to create an incident reporting relationship with ICS-CERT to facilitate the streamlining of reporting rather than the SDT proposing modified CIP-008 requirements mandating dual reporting burdens on responsible entities. Required reporting of cyber security risk and cyber-related threat information should be a function of the E-ISAC.

    Southern Company is also concerned regarding readiness of the E-ISAC and ICS-CERT to receive and securely handle a potentially vast increase of information being supplied by utilities across the country and protections of responsible entity BCSI or CEII from FOIA or other requests.

     

  3. Southern Company sees unintended negative consequences of ambiguous requirements regarding incidents which “compromise or attempt to compromise” a responsible entity’s ESP or associated EACMS. As has been discussed in other forums, changing the Reportable Cyber Security Incident definition to “attempts to compromise” could conceivably involve reporting of many additional innocuous events each day, flooding the E-ISAC and ICS-CERT with information that would be of minimal benefit to any party. Additionally, determining an “attempt to compromise” would, by definition, require an understanding of intent of any unsuccessful incident – an unlikely, if not impossible, task.  Absent other alternatives, the SDT should put forth concerted effort to establish a precise, industry approved definition of “attempts to compromise” that is not left to broad interpretation by entities or regional auditors. If defined too broadly, this can result in a large amount of unnecessary reporting and undue burden.

     

Southern Company, Segment(s) 1, 3, 5, 6, 10/30/2017

- 0 - 0

The scope is not clear because the definition of “attempted compromise” is not clear with regard to unauthorized access attempts. Reclamation recommends the SDT add definitions for “Compromise” and “Attempted Compromise” to the NERC Glossary of Terms, and provide specific examples in a CIP-008 Implementation Guidance document.

Reclamation supports the work E-ISAC does and supports a lower threshold for reporting (resulting in sending more reports to E-ISAC, including reports for lower level incidents that are not currently required to be submitted). Reclamation recognizes that a larger sample size will assist E-ISAC in activities that will ultimately benefit registered entities and the general public.

If many new items are brought within scope to be reported as Cyber Security Incidents, the cost for entities to implement compliance with the revised CIP-008 standard could increase due to the increased reporting requirements proposed. This level of reporting may create undue burden on registered entities; however, increased costs experienced by registered entities due to the increased reporting volume may be offset by the increased value E-ISAC will be able to provide in return. A lower reporting threshold could mean simply adding another address to existing email reports, which would not increase costs in a meaningful way.

Richard Jackson, On Behalf of: U.S. Bureau of Reclamation, , Segments 1, 5

- 0 - 0

FMPA disagrees with the current wording of the SAR as it opens the door for a new standard.  The SAR should be limited to revising CIP-008.

FMPA, Segment(s) , 10/23/2017

- 0 - 0

Hot Answers

John Merrell, On Behalf of: Tacoma Public Utilities (Tacoma, WA), , Segments 1, 3, 4, 5, 6

- 0 - 0

As a system owner, you want alerting set up  for the scenarios that you have thought of and you should have the ability to define those scenarios. The use of IDS/IPS will also add another layer of protection. The other piece is post-event. You want to be reviewing logs to catch any activity that you did not get alerted on. Currently only the High Impact systems have a CIP-007 requirement to review logs which gives the High impact system owners an opportunity to flag an event after the fact ( Review of SIEM logs is not required for Mediums and for Lows where we do not even have to send logs to SIEM)

---

Content:
With regard to content to be included in each report, the Commission stated that the minimum set of attributes to be reported must include:
1. The functional impact, where possible to determine, that the Cyber Security Incident achieved or attempted to achieve;
2. the attack vector that was used to achieve or attempted to achieve the Cyber Security Incident; and
3. the level of intrusion that was achieved or attempted as a result of the Cyber Security Incident.

Comment:
An attribute should be added for attack source.

---

Content:
3. establish deadlines for filing Cyber Security Incidents that are commensurate with incident severity;

Comment:
The current required deadline for reporting cyber security incidents is 1 hour based on CIP-008-5 R1.2.  This timeline is an adequate minimum requirement for information sharing.  Revisions should be made to CIP-008-5 to require more detail to be included in the cyber security incident report, as is addressed in the section above. 

---

Content:
With regard to identifying EACMS for reporting purposes, the Commission stated that the reporting threshold should encompass the functions that various electronic access control and monitoring technologies provide. The Commission specified that, at a minimum, those functions must include:
1. authentication;
2. monitoring and logging;
3. access control;
4. interactive remote access; and
5. alerting.

Comment:
Incident reporting requirements for EACMS should be determined by the systems that the responsible entity has defined as EACMS.  There should be no difference in identifying EACMS for incident reporting purposes vs systems already identified as EACMS.

William Sanders, On Behalf of: William Sanders, , Segments 1, 5

- 0 - 0

Other Answers

Please provide specific examples of how reliability would have been improved had the proposed been in effect over the past 10-years?

Marty Hostler, On Behalf of: Northern California Power Agency, , Segments 5, 6

- 0 - 0

  1. Please provide specific examples of how reliability would have been improved had the proposed been in effect over the past 10-years?

Dennis Sismaet, On Behalf of: Northern California Power Agency, , Segments 5, 6

- 0 - 0

  1. Comments:  Timeframe of reporting unsuccessful cyber-attacks have a reasonable time frame and not come under the same scrutiny as an actual attack that affects the BES or one or more of our CIP cyber assets.  This category needs to be defined unless it is meant to be subjective.

  2. We should report to one entity whether it be E-ISAC or the DOE.  With the OE-417 we have one stop shopping but it is only used if we think the BES will be disrupted.  Most cyber-attacks would use EOP-004 and the filing would go the E-ISAC.  If NERC wants to maintain E-ISAC as our reporting agency then E-ISAC should be responsible for sending information to DHS and ICS-CERT.

Sandra Shaffer, On Behalf of: Sandra Shaffer, , Segments 6

- 1 - 0

 

AEP believes that only boxes associated with Reliability Principles #7 and #8 should be checked, as the others which have been checked (#’s 1, 3, 4, and 5) do not apply in this case and should be unchecked.

Thomas Foltz, On Behalf of: AEP, , Segments 3, 5

- 0 - 0

Debra Boothe, On Behalf of: Western Area Power Administration, NA - Not Applicable, Segments NA - Not Applicable

- 0 - 0

Vivian Moser, On Behalf of: Vivian Moser, , Segments 1, 3, 5, 6

- 0 - 0

The scope of “attempted compromise” should not be expanded beyond CIP-007-6 R4.1 security-related computer logs. Six times in the Order, FERC notes that responsible entities currently are required to monitor and log successful login attempts, detected failed access attempts, and failed login attempts that would lead to a reportable Cyber Security Incident pursuant to Reliability Standard CIP-007-6. CIP-005-6 R1.3 denied by default inbound or outbound access should not be in scope as “attempted compromise.” MEC does not support changing the NERC Glossary definition for Cyber Security Incident. The current definition is alligned with the Section 215 definition for Cyber Security Incident.

Darnez Gresham, On Behalf of: Berkshire Hathaway Energy - MidAmerican Energy Co., MRO, Segments 1, 3

- 0 - 0

 

It is essential that the SDT establish a functional definition of a “confirmed suspicious activity” to avoid ambiguity in compliance with the Standard

 

Very difficult to confirm “suspicious” and “attempted” since each is a subjective evaluation. Suggest “anomalous” instead of “suspicious.” Concerned that “suspicious” or “malicious” requires determining intent.

 

We suggest that there will be a jurisdictional reporting concerns. We should not expect Canadians to report to a US federal agency. The Canadian equivalent to DHS’s ICS-CERT is the Canadian Cyber Incident Response Center.

 

Reporting to more than one group is an industry burden (duplication of effort). One of the original E-ISAC goals was communicating with various US federal agencies. Why can’t the E-ISAC share with ICS-CERT?

 

We are concerned that different people interpret existing language differently, resulting in inconsistent reporting. For consistent reporting, there is another avenue. The updated Standard could provide a list of must report incidents. This list would need to be specific to achieve consistent reporting. One possibility is different reporting levels based on (High – Medium – Low) Impact Rating.

 

Request clarification on how fast reporting is expected. Could reporting time frames be based on Impact Level?

Leonard Kula, On Behalf of: Independent Electricity System Operator, , Segments 2

- 0 - 0

Given the broad nature of the directives in FERC Order 848, specifically elements No. 1 and No. 2, we are concerned with the 6-month timeline to deliver a revised standard to FERC.  Additional time may be warranted to thoroughly evaluate the causes of current lower levels of reporting and develop meaningful improvements to the existing requirements.

The scope of “attempted compromise” should not be expanded beyond CIP-007-6 R4.1 security-related computer logs. Six times in the Order, FERC notes that responsible entities currently are required to monitor and log successful login attempts, detected failed access attempts, and failed login attempts that would lead to a reportable Cyber Security Incident pursuant to Reliability Standard CIP-007-6. CIP-005-6 R1.3 denied by default inbound or outbound access should not be in scope as “attempted compromise.”

We do not support changing the NERC Glossary definition for Cyber Security Incident. The current definition is alligned with the Section 215 definition for Cyber Security Incident.

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

- 0 - 0

FirstEnergy, Segment(s) 4, 3, 5, 6, 9/5/2018

- 0 - 0

Tho Tran, On Behalf of: Oncor Electric Delivery - Texas RE - Segments 1

- 0 - 0

See above.

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

- 0 - 0

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

- 0 - 0

None

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

- 0 - 0

 In the FERC Order 848, BPA states "any new reporting requirement 'must ensure that the information reported is useful and does not result in under and over reporting of information.'" SRP requests the Standards Drafting Team take this mentality when forumating the changes to the reporting requirement. SRP appreciates your efforts and thanks you for your considation.

 

Russell Martin II, On Behalf of: Salt River Project, WECC, Segments 1, 3, 5

- 0 - 0

The SDT must assure a balanced solution such that the FERC objectives can be met without creating administratively burdensome regulations that serves to distract threat intelligence agencies from the ultimate intent to secure the bulk power system. The regulation must be clear, free of ambiguity, and without unintended consequences, such that, it is measurable and does not place registered entities in a position of impossibility of compliance.

Douglas Johnson, On Behalf of: Douglas Johnson, , Segments 1

- 0 - 0

NV Energy would request that the CIP SDT focus their efforts on maintaining consistency between the CIP Standards suite’s existing monitoring requirements for unauthorized access, and any proposed definitions for “attempted compromise”. Inconsistency between these items, will cause interpretation concerns for existing CIP Standards (i.e. CIP-007-6 R4, CIP-005-6) . Additionally, when addressing timelines on reporting based on severity, the CIP SDT will need to create the severity criterion, as leaving this up to utilities will create too much confusion, as one’s cyber security posture will dictate internal severity levels that may differ from what NERC defines. NV Energy does not support changing the NERC Glossary definition for Cyber Security Incident, as this aligns with the Section 215 definition for Cyber Security Incident.

Kevin Salsbury, On Behalf of: Berkshire Hathaway - NV Energy, , Segments 5

- 0 - 0

Rachel Coyne, On Behalf of: Texas Reliability Entity, Inc., , Segments 10

- 0 - 0

Don Schmit, On Behalf of: Don Schmit, , Segments 1, 3, 5

- 0 - 0

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

- 0 - 0

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

- 0 - 0

N/A

Daniel Gacek, On Behalf of: Exelon, , Segments 1, 3, 5, 6

- 0 - 0

Kimberly Van Brimer, On Behalf of: Southwest Power Pool, Inc. (RTO), MRO, Segments 2

- 0 - 0

Jack Cashin, On Behalf of: American Public Power Association, , Segments 4

- 0 - 0

None.

Teresa Krabe, On Behalf of: Lower Colorado River Authority, , Segments 1, 5

- 0 - 0

Anton Vu, On Behalf of: Los Angeles Department of Water and Power, , Segments 1, 3, 5, 6

- 0 - 0

It is essential that the SDT establish a functional definition of a “confirmed suspicious activity” to avoid ambiguity in compliance with the Standard

 

Very difficult to confirm “suspicious” and “attempted” since each is a subjective evaluation. Suggest “anomalous” instead of “suspicious.” Concerned that “suspicious” or “malicious” requires determining intent.

 

We suggest that there will be a jurisdictional reporting concerns. We should not expect Canadians to report to a US federal agency. The Canadian equivalent to DHS’s ICS-CERT is the Canadian Cyber Incident Response Center.

 

Reporting to more than one group is an industry burden (duplication of effort). One of the original E-ISAC goals was communicating with various US federal agencies. Why can’t the E-ISAC share with ICS-CERT?

 

We are concerned that different people interpret existing language differently, resulting in inconsistent reporting. For consistent reporting, there is another avenue. The updated Standard could provide a list of must report incidents. This list would need to be specific to achieve consistent reporting. One possibility is different reporting levels based on (High – Medium – Low) Impact Rating.

 

Request clarification on how fast reporting is expected. Could reporting time frames be based on Impact Level?

RSC no Dominion and Hydro One, Segment(s) 10, 2, 4, 5, 7, 1, 3, 6, 0, 9/10/2018

- 0 - 0

We would like to point out that the current definition of Cyber Security Incident in NERC Glossary of Terms does include attempts to compromise ESPs and PSPs.  There appears to be no need to modify the standard to address the reporting of “attempted compromise”.  Unauthorized access attempts are attempts to compromise the PSP/ESP or other confirmed suspicious activities can be also considered as attempts.

We do not disagree with establishing a certain minimum information as long as it is useful information and not burdensome.  We recommend that a minimum set of information for reporting must be set but it should not bound the reporting entities to a template.  Also, the timing regarding availability of such information must be considered.

If we are to establish deadlines (or refine those) for reporting and filing Cyber Security Incidents that are commensurate with incident severity, it will need to be clarified how severity is established.  

There should also be a consideration for Canadian entities in their reporting of Cyber Security Incidents as it may not directly get to E-ISAC.

Payam Farahbakhsh, On Behalf of: Hydro One Networks, Inc., , Segments 1, 3

- 0 - 0

Southern Company proposes the following for consideration by the Standards Drafting Team.

 

  1. Additional time – beyond the ambitious FERC timeline for modifications -- is warranted to allow for thorough coordination between responsible entities, NERC and the SDT, as well as the E-ISAC and ICS-CERT. This will allow for alignment on proper reporting and the impacts of additional administrative burdens during the response and recovery processes.

    Although the currently proposed timeframe for standards modifications doesn’t appear to allow for this thorough coordination where multiple existing standards may be impacted by changes to CIP-008, or the definitions of EACMS, Cyber Security Incidents, and Reportable Cyber Security Incidents, the SDT should consider the impacts and undue burden of improperly scoping new requirements to applicable EACMS systems performing only a monitoring function. As NERC pointed out in their response to the FERC NOPR, the unintended inclusion in the scope of modified CIP-008 requirements to systems solely performing an access monitoring function under the existing EACMS definition is unwarranted, and the SDT should consider that the definition, or the scope of applicable systems, should be addressed to properly apply to those EACMS assets used in the protection of ESPs. Given the current timeframe FERC has established, it is unlikely this SDT will be afforded the time necessary to address these scoping concerns as a change to the EACMS definition impacts many standards.

    Southern Company recommends that the SDT consider these impacts and work to establish dialogue involving all of these impacted organizations and systems to determine the best path forward to properly address the scope of applicable systems prior to proposing standards modifications under the current EACMS definition and constrained development timeline.
     

  2. If there is need by other agencies for currently reported information, Southern Company recommends that the SDT consider not precluding or inhibiting the use of technological solutions for sharing anonymized industry data across federal, regional, or state organizations, rather than imposing duplicative regulatory requirements for reporting on responsible entities. Again, Southern Company believes that cyber data-mining and cyber threat awareness is outside the scope and purpose of CIP-008, which should remain focused on incident response. 

     

  3. If the definition of a Reportable Cyber Security Incident is to be expanded to include “attempts to compromise” a responsible entity’s ESP or associated EACMS, Southern Company recommends that the SDT develop a precise definition of “attempts to compromise” that does not allow for broad interpretation by responsible entities or regional auditors and which does not require burdensome, unnecessary reporting.  The drafting team should weigh any changes to an existing definition of Reportable Cyber Security Incident very carefully against unintended consequences of these changes.

    Southern Company also recommends that the SDT clearly delineate judgement as to what is, and what is not, reportable with language used in existing standards, such as “as determined by the Responsible Entity” and avoid requirements that force an entity to continuously work to “prove the negative”.

 

 

Southern Company, Segment(s) 1, 3, 5, 6, 10/30/2017

- 0 - 0

Reclamation recommends the terminology among standards be unified with the terms presently defined in the NERC Glossary of Terms; specifically, “access” and “authentication.”

Reclamation also recommends the attempt to lower the threshold of CIP-008 reporting requirements correspond with the logging requirements of CIP-007 R4, Parts 4.1 P4.2 and the limits defined in CIP-007, R5, Part 5.7 for unauthorized authentication attempts. 

Reclamation also recommends the SDT draft a specific threshold in CIP-007 R5 Part 5.7 to specify the number of unsuccessful authentication attempts that must result in an alert and report to E-ISAC.

Reclamation recommends that when incidents are reportable, all incident reporting should be directed to the NCCIC/DHS US-CERT as reflected on the DHS website at: https://ics-cert-us-cert.gov/Report-Incident. Any additional reports (e.g., to E-ISAC) should be forwarded or made available to the necessary agency by NCCIC/DHS US-CERT.

Item 2 of the FERC requirements (“to allow for ease of comparison by ensuring that each report includes specified fields of information”) indicates the purpose of this requirement is to make auditing the reports easier, which should not be a driver for updating standards.

Richard Jackson, On Behalf of: U.S. Bureau of Reclamation, , Segments 1, 5

- 0 - 0

A definition should be developed for “compromise” and “attempt to compromise” 

FMPA, Segment(s) , 10/23/2017

- 0 - 0