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

2016-03 Cyber Security Supply Chain Risk Management | CIP-005-6, CIP-010-3, CIP-013-1

Description:

Start Date: 05/02/2017
End Date: 06/15/2017

Associated Ballots:

Ballot Name Project Standard Pool Open Pool Close Voting Start Voting End
2016-03 Cyber Security Supply Chain Risk Management CIP-013-1 AB 2 ST 2016-03 Cyber Security Supply Chain Risk Management CIP-013-1 01/19/2017 02/17/2017 06/06/2017 06/15/2017
2016-03 Cyber Security Supply Chain Risk Management CIP-005-6 IN 1 ST 2016-03 Cyber Security Supply Chain Risk Management CIP-005-6 01/19/2017 05/31/2017 06/06/2017 06/15/2017
2016-03 Cyber Security Supply Chain Risk Management CIP-010-3 IN 1 ST 2016-03 Cyber Security Supply Chain Risk Management CIP-010-3 01/19/2017 05/31/2017 06/06/2017 06/15/2017

Filter:

Hot Answers

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

Richard Vine, 6/15/2017

- 0 - 0

- 0 - 0

Other Answers

Request re-wording of R1 Part 1.2.1 and 1.2.4 to easily understand what is expected. These Parts appear to be duplicative. Guidance does not adequately distinguish between the Parts. One interpretation is that Part 1.2.1 is for products/services and that Part 1.2.4 is for vulnerabilities in the product. It is not clear if these Parts expect information sharing at the time of procurement or on-going? 

Randy Buswell, 5/31/2017

- 0 - 0

Bill Watson, On Behalf of: Bill Watson, , Segments 3

- 0 - 0

The Registered Entity suggests consider revising Section 1.2.3 to clarify under what circumstances vendors would be expected to notify the Registered Entity that vendor remotes access should be revoked.  Regarding Section 1.2.4, suggest revising to clarify what type of vulnerabilities would be included in this disclosure.

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

- 0 - 0

Sandra Pacheco, On Behalf of: Silicon Valley Power - City of Santa Clara, , Segments 3, 5

- 0 - 0

Val Ridad, On Behalf of: Silicon Valley Power - City of Santa Clara, , Segments 3, 5

- 0 - 0

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

- 0 - 0

Illinois Municipal Electric Agency supports comments submitted by the American Public Power Association.

Bob Thomas, 6/9/2017

- 0 - 0

Chelan PUD appreciates the efforts of the drafting team to revise CIP-013 in response to comments and recommendations provided previously. Although there are significant improvements in this version of the Draft Standard, CHPD believes that the Standard should not be approved for the following reasons:

  • Is not performance based and therefore not auditable

  • Creates risk for the responsible entities due to lack of auditability

  • Likely to be costly to vendors due to having to respond to various entity contract requests

CHPD has concerns about language related to procurement contracts, in particular use of master agreements, piggyback agreements, and evergreen agreements. To address these concerns and position CIP-013 as a performance based Standard, CHPD recommends that all references to “contracts” and most references to “procurement” be struck from CIP-013. However; the note in R2 should be maintained that states:

Note: Implementation of the plan does not require the Responsible Entity to renegotiate or abrogate existing contracts (including amendments to master agreements and purchase orders). Additionally, the following issues are beyond the scope of Requirement R2: (1) the actual terms and conditions of a procurement contract; and (2) vendor performance and adherence to a contract.

CHPD’s reasoning is that there are means other than vendor contract negotiations, contract language, and procurement processes to address and achieve the protections required by R1.2. It is immaterial how these protections are achieved. Focusing thinking and audit approach on contracts and procurement (even if specific contract terms are not in scope) limits flexibility, is unnecessarily prescriptive, and does not reflect performance-based principles. As such CHPD asks that R1.2 be revised as follows:

1.2. One or more process(es) for its newly procured BES Cyber Systems that address the following elements, as applicable:

(“new” meaning obtained after the implementation of CIP-013).

Note also that CHPD asks that the term “elements” be included in R1.2, as shown above, to clearly align with the VSLs for this requirement.

Associated guidance in the “Rationale for R1” and in the separate implementation guidance should be revised to reflect the change to a performance-based requirement in which contract terms and contract negotiations play no function in auditing. Contract terms might be used by an entity as evidence of performance, but there should be no expectation by audits in the Standard or implementation guidance that anything having to do with contracts or procurement processes is required. Ultimately, there should be no expectation that the protections be achieved solely through the procurement process. The objective is achieving each protection, not in how it is achieved.

The performance-based assessment requirements would be improved if worded in a way that allows the acceptance of any outcome reached by each Responsible Entity (e.g., “Each Responsible Entity shall <insert performance activity> and document the results of the assessment.”). The intent should be to create a dialog between the entities and vendors on these topics rather than just documented within contractual language.

Haley Sousa, 6/9/2017

- 0 - 0

Chelan PUD appreciates the efforts of the drafting team to revise CIP-013 in response to comments and recommendations provided previously. Although there are significant improvements in this version of the Draft Standard, CHPD believes that the Standard should not be approved for the following reasons:

  • Is not performance based and therefore not auditable

  • Creates risk for the responsible entities due to lack of auditability

  • Likely to be costly to vendors due to having to respond to various entity contract requests

CHPD has concerns about language related to procurement contracts, in particular use of master agreements, piggyback agreements, and evergreen agreements. To address these concerns and position CIP-013 as a performance based Standard, CHPD recommends that all references to “contracts” and most references to “procurement” be struck from CIP-013. However; the note in R2 should be maintained that states:

Note: Implementation of the plan does not require the Responsible Entity to renegotiate or abrogate existing contracts (including amendments to master agreements and purchase orders). Additionally, the following issues are beyond the scope of Requirement R2: (1) the actual terms and conditions of a procurement contract; and (2) vendor performance and adherence to a contract.

CHPD’s reasoning is that there are means other than vendor contract negotiations, contract language, and procurement processes to address and achieve the protections required by R1.2. It is immaterial how these protections are achieved. Focusing thinking and audit approach on contracts and procurement (even if specific contract terms are not in scope) limits flexibility, is unnecessarily prescriptive, and does not reflect performance-based principles. As such CHPD asks that R1.2 be revised as follows:

1.2. One or more process(es) for its newly procured BES Cyber Systems that address the following elements, as applicable:  

(“new” meaning obtained after the implementation of CIP-013).

Note also that CHPD asks that the term “elements” be included in R1.2, as shown above, to clearly align with the VSLs for this requirement.

Associated guidance in the “Rationale for R1” and in the separate implementation guidance should be revised to reflect the change to a performance-based requirement in which contract terms and contract negotiations play no function in auditing. Contract terms might be used by an entity as evidence of performance, but there should be no expectation by audits in the Standard or implementation guidance that anything having to do with contracts or procurement processes is required. Ultimately, there should be no expectation that the protections be achieved solely through the procurement process. The objective is achieving each protection, not in how it is achieved.

The performance-based assessment requirements would be improved if worded in a way that allows the acceptance of any outcome reached by each Responsible Entity (e.g., “Each Responsible Entity shall and document the results of the assessment.”). The intent should be to create a dialog between the entities and vendors on these topics rather than just documented within contractual language.

Janis Weddle, 6/9/2017

- 0 - 0

R1-R2 are clearly stated and provide for the development and implementation of the required CIP-013-1 cyber security plans. R3 sets a clear expectation for periodic reviews and approvals. From an auditor's perspective, requiring the first review and approval of the R1 plan on or before the effective date of CIP-013-1 (Implementation  Plan, Initial Performance of Periodic Requirements section,  p. 3) provides clear guidance to industry on implementation expectations.   

Steven Rueckert, Western Electricity Coordinating Council, 10, 6/9/2017

- 0 - 0

Chelan PUD appreciates the efforts of the drafting team to revise CIP-013 in response to comments and recommendations provided previously. Although there are significant improvements in this version of the Draft Standard, CHPD believes that the Standard should not be approved for the following reasons:

  • Is not performance based and therefore not auditable

  • Creates risk for the responsible entities due to lack of auditability

  • Likely to be costly to vendors due to having to respond to various entity contract requests

 

CHPD has concerns about language related to procurement contracts, in particular use of master agreements, piggyback agreements, and evergreen agreements. To address these concerns and position CIP-013 as a performance based Standard, CHPD recommends that all references to “contracts” and most references to “procurement” be struck from CIP-013. However; the note in R2 should be maintained that states:

 

Note: Implementation of the plan does not require the Responsible Entity to renegotiate or abrogate existing contracts (including amendments to master agreements and purchase orders). Additionally, the following issues are beyond the scope of Requirement R2: (1) the actual terms and conditions of a procurement contract; and (2) vendor performance and adherence to a contract.

 

CHPD’s reasoning is that there are means other than vendor contract negotiations, contract language, and procurement processes to address and achieve the protections required by R1.2. It is immaterial how these protections are achieved. Focusing thinking and audit approach on contracts and procurement (even if specific contract terms are not in scope) limits flexibility, is unnecessarily prescriptive, and does not reflect performance-based principles. As such CHPD asks that R1.2 be revised as follows:

 

1.2. One or more process(es) for its newly procured BES Cyber Systems that address the following elements, as applicable:  

 

(“new” meaning obtained after the implementation of CIP-013).

 

Note also that CHPD asks that the term “elements” be included in R1.2, as shown above, to clearly align with the VSLs for this requirement.

 

Associated guidance in the “Rationale for R1” and in the separate implementation guidance should be revised to reflect the change to a performance-based requirement in which contract terms and contract negotiations play no function in auditing. Contract terms might be used by an entity as evidence of performance, but there should be no expectation by audits in the Standard or implementation guidance that anything having to do with contracts or procurement processes is required. Ultimately, there should be no expectation that the protections be achieved solely through the procurement process. The objective is achieving each protection, not in how it is achieved.

 

The performance-based assessment requirements would be improved if worded in a way that allows the acceptance of any outcome reached by each Responsible Entity (e.g., “Each Responsible Entity shall <insert performance activity> and document the results of the assessment.”). The intent should be to create a dialog between the entities and vendors on these topics rather than just documented within contractual language.

Chad Bowman, 6/9/2017

- 0 - 0

In the Response to Comments the SDT asserts “Identifying and assessing cyber security risks in BES Cyber System planning.  The SDT revised CIP-013-1 Requirement R1 Part 1.1 to “specify risks that Responsible Entities shall consider in planning for procurement of BES Cyber Systems“.  Previously, commenters indicated that “the scope of cyber security risks being addressed in R1 is unclear.  The SDT removed unnecessary and unclear wording from Requirement R1s main requirement and revised Requirement R1 Part 1.1 to clarify the supply chain cyber security risks that must be addressed by the Responsible Entity in planning for the procurement of BES Cyber Systems.” 

This change does not clearly identify the risks as previously noted by commenters. 

Dominion recommends the following language change for CIP-013-1, R1 Part 1.1:

“Include one or more process(es) used in planning for the procurement of BES Cyber Systems to identify and assess, if applicable, the cyber security risk(s) of (i) procuring and installing vendor equipment and software; (ii) network architecture security; and (iii) transitions between vendor”

Dominion also recommends the following proposed language change for CIP-013-1 R1 Part 1.2:

“One or more process(es) used during procurement of BES Cyber Systems that address the following, as applicable:”

R3 needs to contain the caveat found in R2 that “[Revision] of the plan does not require the Responsible Entity to renegotiate or abrogate existing contracts (including amendments to master agreements and purchase orders).”

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

- 0 - 0

Comments: Chelan PUD appreciates the efforts of the drafting team to revise CIP-013 in response to comments and recommendations provided previously. Although there are significant improvements in this version of the Draft Standard, CHPD believes that the Standard should not be approved for the following reasons:

  • Is not performance based and therefore not auditable

  • Creates risk for the responsible entities due to lack of auditability

  • Likely to be costly to vendors due to having to respond to various entity contract requests

CHPD has concerns about language related to procurement contracts, in particular use of master agreements, piggyback agreements, and evergreen agreements. To address these concerns and position CIP-013 as a performance based Standard, CHPD recommends that all references to “contracts” and most references to “procurement” be struck from CIP-013. However; the note in R2 should be maintained that states:

Note: Implementation of the plan does not require the Responsible Entity to renegotiate or abrogate existing contracts (including amendments to master agreements and purchase orders). Additionally, the following issues are beyond the scope of Requirement R2: (1) the actual terms and conditions of a procurement contract; and (2) vendor performance and adherence to a contract.

CHPD’s reasoning is that there are means other than vendor contract negotiations, contract language, and procurement processes to address and achieve the protections required by R1.2. It is immaterial how these protections are achieved. Focusing thinking and audit approach on contracts and procurement (even if specific contract terms are not in scope) limits flexibility, is unnecessarily prescriptive, and does not reflect performance-based principles. As such CHPD asks that R1.2 be revised as follows:

1.2. One or more process(es) for its newly procured BES Cyber Systems that address the following elements, as applicable:  

(“new” meaning obtained after the implementation of CIP-013).

Note also that CHPD asks that the term “elements” be included in R1.2, as shown above, to clearly align with the VSLs for this requirement.

Associated guidance in the “Rationale for R1” and in the separate implementation guidance should be revised to reflect the change to a performance-based requirement in which contract terms and contract negotiations play no function in auditing. Contract terms might be used by an entity as evidence of performance, but there should be no expectation by audits in the Standard or implementation guidance that anything having to do with contracts or procurement processes is required. Ultimately, there should be no expectation that the protections be achieved solely through the procurement process. The objective is achieving each protection, not in how it is achieved.

The performance-based assessment requirements would be improved if worded in a way that allows the acceptance of any outcome reached by each Responsible Entity (e.g., “Each Responsible Entity shall <insert performance activity> and document the results of the assessment.”). The intent should be to create a dialog between the entities and vendors on these topics rather than just documented within contractual language.

Mick Neshem, 6/12/2017

- 0 - 0

Colorado Springs Utilities supports the comments provided by APPA

Jeff Icke, Colorado Springs Utilities, 5, 6/12/2017

- 0 - 0

Regarding the use of the term “vendor,” as described in the “Rationale for Requirement R1” section of CIP-013-1:  the SDT may want to clarify that staff augmentation contractors are not considered to be “vendors” in the context of the standard.

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

- 0 - 0

What is the difference between 1.2.1 and 1.2.4?

Why is the scope of 1.2.2 limited to vendor-identified incidents? What if a third party identifies an incident?

Is there an expectation of the vendor to disclose non-public information in 1.2.4? Is this only during contracting or is there an expectation of new vulnerabilities to be disclosed?

1.1 – Delete “planning for”. Or if the use of “planning for” in R1 creates a necessary distinction between 1.1 and 1.2, what is it?
- What is implied by (ii) transitions from one vendor(s) to another vendor(s)? Why is this distinction necessary? Wouldn’t a vendor transition require a new contract? Does this refer to the act of severing existing remote access permissions? Subcontracting?
- R1.2.2: “Coordination of responses to vendor-identified incidents….”, it is not clear who should be doing the coordinating and why this is necessary.  Suggest deleting.


 

Daniel Grinkevich, 6/12/2017

- 0 - 0

Patrick Hughes, On Behalf of: National Electrical Manufacturers Association, NA - Not Applicable, Segments NA - Not Applicable

- 0 - 0

The intent and purpose of CIP-013 is very dependent upon the Implementation Guidance document.  We appreciate the hard work of the SDT to provide this document to industry and it has valuable information.  A concern is that auditors can only audit to the requirements within the standard so some of the comments are based on needing more clarification within the standard itself.

Language should be included in the standard (not just in the Rationale) that allows for inclusion of a clause in a procurement agreement stating that CIP-013 compliance must be met by the supplier unless it is either not offered or would significantly increase the cost of the agreement. (See CIP-013-1, Section B, Rationale for Requirement R1).  This language in a procurement agreement, along with the supplier’s stipulation that this compliance is either unavailable or will increase costs should constitute proof that CIP-013 compliance was considered by the Registered Entity but waived due to the supplier’s inability to accommodate the requirement in a reasonable manner.

The standard should make clear that, as long as evidence demonstrates that all items expressly identified in CIP-013, R1 are contained in a supply chain cyber security risk management plan or plans, and are implemented pursuant to R2, entities will not be found out of compliance.  More specifically, entities should not be subjected to CIP-013 noncompliance findings resulting from a difference of opinion concerning security adequacy.

Santee Cooper is concerned about compliance obligations for procurement activities associated with multi-party wide-area contracts, master agreements and piggyback agreements.  An exception, comparable to a CIP Exceptional Circumstance, should be included in the standard for these kinds of procurement activities. 

This standard will create the need for entities to have an inventory tracking mechanism of products that are purchased under the supply chain risk management plan.  For example, switches could be purchased for use in an IT department, not under the supply chain cyber security risk management plan, and this would preclude it from being used in a BES Cyber System.  A CIP Exceptional circumstance or something similar should be added to the standard to allow an entity to use a piece of equipment not procured under the supply chain cyber security risk management plan rather than risk reliability of the BES.

Please add some wording to the requirement in the standard to address how far up the supply chain the plan applies to.  If a laptop is purchased from a vendor is there an expectation that the cyber security risk management plan stop with that vendor or is there an expectation that the associated parts of the laptop fall under the plan?  It’s currently included in the rationale language but the rationale language cannot be audited.

What happens when a vendor is bought out by another vendor?  Are you compliant until you have to negotiate a contract with the new vendor?

In R1 Parts 1.2.1 and 1.2.2, the term “vendor-identified incident” is unclear.  It could mean incidents that were identified by another party, specific to the products of a specific vendor. It could mean only incidents identified by the vendor. Suggest changing “identified to “acknowledged” or “confirmed.”

Shawn Abrams, 6/13/2017

- 0 - 0

With respect to the proposed Requirement 1 Part 1.2.1, compliance requires the vendor to be responsive to vendor-identified incidents. We can only be compliant if the vendor releases such information. We can’t be held responsible for a vendor that does not provide incident related information. This verbiage has to be deemed acceptable when developing the plan(s).

 

With respect to the proposed Requirement 1 Part 1.2.4, compliance requires the vendor to be responsive to disclosing vulnerabilities. We can only be compliant if the vendor releases such information. We can’t be held responsible for a vendor that does not disclose vulnerabilities. This verbiage has to be deemed acceptable when developing the plan(s).

 

With respect to the proposed Requirement 1 Part 1.2.5, compliance requires cooperation by the vendor to participate in such a program. We will give procurement preference to vendors willing to participate however we are still at relying on vendor cooperation. We can’t be held responsible for a vendor that does not provide accurate verification of software integrity and authenticity. This verbiage has to be deemed acceptable when developing the plan(s).

Steven Sconce, On Behalf of: EDF Renewable Energy, , Segments 5

- 0 - 0

- 0 - 0

Thomas Foltz, AEP, 5, 6/13/2017

- 0 - 0

Recommend modifying CIP-007 and CIP-010 to include the proposed risk management elements proposed in CIP-013, or take the corresponding elements out of CIP-007 and CIP-010 to make CIP-013 more than just having a plan.  There are no quantifiable measures in CIP-013 that really justify it as a stand-alone standard.

Michael Haff, On Behalf of: Seminole Electric Cooperative, Inc., FRCC, Segments 1, 3, 4, 5, 6

- 0 - 0

We support the comments submitted by APPA, including the following recommendations:

 

Re-word R1, Parts 1.2.1 and 1.2.4 to better describe what is expected.  The endorsed Guidance does not adequately distinguish between the two parts.

"Vendor" is not a NERC-defined term and contributes ambiguity.

Those items (CIP-013 R1, Parts 1.2.5 and 1.2.6) covered in CIP-005 adn CIP-010 should be removed from CIP-013 to avoid duplication.

The Compliance and/or Implementation Guidance should make clear that, when evidence demonstrates that all items expressly identified in CIP-013 R1 are contained in a Supply Chain Cyber Security Management Plan or Plans, and are implemented pursuant to R2, entities will not be found out of compliance.

There is concern about language related to procurement contracts, specifically the use of master agreements, piggyback agreements, and evergreen agreements.  All references to "contracts" and most references to 'procurement" should be struck from CIP-013, except the note in R2.

Allan Long, Memphis Light, Gas and Water Division, 1, 6/13/2017

- 0 - 0

Even though ReliabilityFirst believes the CIP-013-1 draft standard address directives from Federal Energy Regulatory Commission (FERC) Order No. 829 and is a positive step in addressing cyber supply chain management, ReliabilityFirst Abstains mainly due to Requirement R1 missing Electronic Access Control or Monitoring Systems (EACMS), Physical Access Control Systems (PACS), and Protected Cyber Assets (PCAs).  ReliabilityFirst offers the following specific comments for consideration. 

  1. Requirement R1

    1. Even though Electronic Access Control or Monitoring Systems (EACMS), Physical Access Control Systems (PACS), and Protected Cyber Assets (PCAs) were not specifically called out specifically in FERC Order 829, ReliabilityFirst believes the SDT needs to examine the possible risk of not including EACMS, PACS and PCA as part of Requirement R1 and go beyond what was stated in FERC Order 829.  EACMs and PACS are critical cyber assets that control access and monitoring into the entities’ ESPs and PSPs and should follow the Supply Chain standard/requirements as do the High and Medium Impact Cyber Systems.  As for the PCAs, if they are compromised due to a vulnerability in the vendors supplied hardware or software, they can possibly affect high and medium impact BES Cyber Systems.  ReliabilityFirst offers the following modifications for consideration:

      1. Each Responsible Entity shall develop one or more documented supply chain cyber security risk management plan(s) for high and medium impact BES Cyber System and, [if applicable, associated Electronic Access Control and Monitoring (EACM), Physical Access Control Systems (PACS) and Protected Cyber Assets (PCA)]. The plan(s) shall include:

Anthony Jablonski, ReliabilityFirst , 10, 6/13/2017

- 0 - 0

: Platte River Power Authority (PRPA) continues to be a strong supporter of efforts to ensure the security of the Bulk Electric System and appreciates the time and effort that the SDT has put into considering industry feedback and incorporating it into the current drafts of CIP-005, CIP-010 and CIP-013.

PRPA agrees with limiting the requirement to high and medium assets only. 

R1: PRPA generally agrees with the proposed Requirement 1 but is concerned about compliance obligations for procurement activities associated with multi-party wide-area contracts, master agreements and piggyback agreements.  An exception, comparable to a CIP Exceptional Circumstance, should be included in the standard for these kinds of procurement activities. 

PRPA recommends removing those items (CIP-013 R1 parts 1.2.5 and 1.2.6) covered in CIP-005 and CIP-010 from CIP-013 to avoid duplication.  The revised CIP-013 parts 1.2.5 and 1.2.6 appear to apply to software source and identity verification (now required “when the method to do so is available” by CIP-010) and determining active vendor remote access sessions (now required by CIP-005).  Having CIP-013 parts that require entities to perform the underlying function and to take those functions into account during the procurement process is needless duplication that does not increase security or reliability and could result in compliance “double jeopardy.”

R2: PRPA agrees with the requirement to implement the supply chain cyber security risk management plan as outlined in Requirement 1.

R3: PRPA agrees that a 15-month review period is appropriate to review the supply chain cyber security risk management plan in Requirement 1.

Additionally, PRPA proposes that the regional entities voluntarily assess CIP-013 programs for entities who have audits in the period between standard approval and the effective date.  This is similar to when the regional entities performed transition period audits of CIP v5 programs.

Tyson Archie, Platte River Power Authority, 5, 6/14/2017

- 0 - 0

For Requirement R 1, Part 1.2.4, CenterPoint Energy Houston Electric, LLC (“CenterPoint Energy”) recommends the following modification to help clarify the type of disclosed vulnerabilities:

“Disclosure by vendors of known security vulnerabilities involving the procured product or its supply chain that impact the availability or reliability of the Responsible Entity’s BES Cyber System.”   

Amelia Sawyer Anderson, On Behalf of: CenterPoint Energy Houston Electric, LLC, Texas RE, Segments 1

- 0 - 0

Even though the second proposed version of this standard has been simplified, SDG&E believes compliance with CIP-013-1 is potentially difficult and costly to demonstrate compliance.

- 0 - 0

I would support the comments of Andrew Gallo Austin Energy for all questions.

W. Dwayne Preston, Austin Energy, 3, 6/14/2017

- 0 - 0

Lauren Price, 6/14/2017

- 0 - 0

 

SMUD continues to be a strong supporter of efforts to ensure the security of the Bulk Electric System and appreciates the time and effort that the SDT has put into considering industry feedback and incorporating it into the current drafts of CIP-005, CIP-010 and CIP-013.

 

 

 

SMUD agrees with limiting the requirement to high and medium assets only. 

 

 

 

R1: SMUD generally agrees with the proposed Requirement 1 but is concerned about compliance obligations for procurement activities associated with multi-party wide-area contracts, master agreements and piggyback agreements.  An exception, comparable to a Technical Feasibility Exception (TFE) or Asset Capability Exception, should be included in the standard for these kinds of procurement activities.  An additional consideration is to allow agreements between the vendor and entity that will not cause a financial impact, such as a letter of understanding, commitment to a plan of action or other agreement.

 

 

 

SMUD recommends removing those items (CIP-013 R1 parts 1.2.5 and 1.2.6) covered in CIP-005 and CIP-010 from CIP-013 to avoid duplication.  The revised CIP-013 parts 1.2.5 and 1.2.6 appear to apply to software source and identity verification (now required “when the method to do so is available” by CIP-010) and determining active vendor remote access sessions (now required by CIP-005).  Having CIP-013 parts that require entities to perform the underlying function and to take those functions into account during the procurement process is needless duplication that does not increase security or reliability and could result in compliance “double jeopardy.”

 

- 0 - 0

Austin Energy (AE) supports efforts to ensure the security of the Bulk Electric System and appreciates the time and effort the SDT put into considering industry feedback and incorporating it into the current drafts of CIP-005, CIP-010 and CIP-013.

AE agrees with limiting the requirement to high and medium assets. 

R1: AE generally agrees with the proposed R1 but has concerns about compliance obligations for procurement activities associated with multi-party wide-area contracts, master agreements and "piggyback" agreements.  NERC should include an exception, comparable to a CIP Exceptional Circumstance, for such procurement activities. 

AE recommends removing those items (CIP-013 R1 parts 1.2.5 and 1.2.6) covered in CIP-005 and CIP-010 from CIP-013 to avoid duplication.  The revised CIP-013 parts 1.2.5 and 1.2.6 appear to apply to software source and identity verification (now required “when the method to do so is available” by CIP-010) and determining active vendor remote access sessions (now required by CIP-005).  Having CIP-013 parts which require entities to perform the underlying function and take those functions into account during the procurement process is needless duplication which does not increase security or reliability and could result in compliance “double jeopardy.”

R2: AE agrees with the requirement to implement the supply chain cyber security risk management plan as outlined in R1.

R3: AE agrees a 15-month review period is appropriate to review the supply chain cyber security risk management plan in R1.

Additionally, AE proposes the regional entities voluntarily assess CIP-013 programs for entities who have audits in the period between standard approval and the effective date, similar to when the regional entities performed transition period audits of CIP v5 programs.

Andrew Gallo, 6/14/2017

- 0 - 0

  • BC Hydro appreciates the direction of the revisions ie to remove enforcement actions against responsible entities that have limited ability to influence vendors.  However, BC Hydro still believes some aspects of R1 will be difficult to manage / enforce, especially given the breadth of vendors many responsible entities have associated with their BCAs.  Not all vendors are going to be able to accommodate the asks of the requirement. 

  • “Notification by the vendor…” suggests the vendor is expected to reach out to the responsible entity, and communication / transparency is endorsed through potential inclusion of terms in RFP’s / contracts. This relies on the vendor honesty / transparency and there is no way to verify their attestations.  The requirement focuses on entities reviewing vendor processes which may have limited impact on reliability.

BC Hydro, Segment(s) 1, 2, 3, 5, 5/6/2015

- 0 - 0

R1 states that each RE must have a plan with one or more processes that address ....as applicable. Applicability is in the eye-of-beholder, however the requirement does not specifically say as identified by the Responsibility Entity, which auditors may take as a deliberate act not to include, interpreting that it is not up to the Responsibilty Entity to determin which are applicable. 

 

Richard Kinas, 6/14/2017

- 0 - 0

See attached comments

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

2016-03_Unofficial_Comment_Form_SCL_2017-6-14 Final to NERC.docx

- 0 - 0

Concerned that the R1 guidance provides details which are beyond the scope of R1

Definition of vendor is not a NERC defined term. The term “vendor” is also used in the proposed CIP-005.

Request more guidance for the term “vendor” and use cases. Guidance should prompt Entities to include their definition of “vendor” in their plan(s).

Request re-wording of R1 Part 1.2.1 and 1.2.4 to easily understand what is expected.

In R1 Parts 1.2.1 and 1.2.2, the term “vendor-identified incident” is unclear.

Request to merge R1 Part 1.2.1 and 1.2.2 for the notification and the coordination related to vendor-identified incidents.

Request to merge R1 Part 1.2.3 and Part 1.2.6 for the notification and the coordination of controls when remote or on site access are required and granted for (i) vendor-initiated interactive remote access, and (ii) system-to-system remote access with a vendor(s).

The Compliance and/or Implementation Guidance should make clear that, as long as evidence demonstrates that all items expressly identified in CIP-013, R1 are contained in a Supply Chain Cyber Security Management Plan or Plans, and are implemented pursuant to R2, entities will not be found out of compliance.  More specifically, entities should not be subjected to CIP-013 noncompliance findings resulting from a difference of opinion concerning security adequacy.

Normande Bouffard, 6/14/2017

- 0 - 0

Entergy/NERC Compliance, Segment(s) 1, 5, 3/1/2017

- 0 - 0

See MRO NSRF comments.

Theresa Allard, Minnkota Power Cooperative Inc., 1, 6/14/2017

- 0 - 0

SRP continues to be a strong supporter of efforts to ensure the security of the Bulk Electric System and appreciates the time and effort that the SDT has put into considering industry feedback and incorporating it into the current drafts of CIP-005, CIP-010 and CIP-013.

SRP agrees with limiting the requirement to high and medium assets only. 

R1: SRP generally agrees with the proposed Requirement 1 but is concerned about compliance obligations for procurement activities associated with multi-party wide-area contracts, master agreements and piggyback agreements.  An exception, comparable to a CIP Exceptional Circumstance, should be included in the standard for these kinds of procurement activities. 

SRP recommends removing those items (CIP-013 R1 parts 1.2.5 and 1.2.6) covered in CIP-005 and CIP-010 from CIP-013 to avoid duplication.  The revised CIP-013 parts 1.2.5 and 1.2.6 appear to apply to software source and identity verification (now required “when the method to do so is available” by CIP-010) and determining active vendor remote access sessions (now required by CIP-005).  Having CIP-013 parts that require entities to perform the underlying function and to take those functions into account during the procurement process is needless duplication that does not increase security or reliability and could result in compliance “double jeopardy.”

R2: SRP agrees with the requirement to implement the supply chain cyber security risk management plan as outlined in Requirement 1.

R3: SRP agrees that a 15-month review period is appropriate to review the supply chain cyber security risk management plan in Requirement 1.

Additionally, SRP proposes that the regional entities voluntarily assess CIP-013 programs for entities who have audits in the period between standard approval and the effective date.  This is similar to when the regional entities performed transition period audits of CIP v5 programs.

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

- 0 - 0

The clarification that we don’t have and would like from NERC/WECC is the intent of the following statement in CIP-013  R1.2.5 “Verification of software integrity and authenticity of all software and patches provided by the vendor for use in the BES Cyber System”.   There is no Guidelines and technical basis at the end of the standard for this

 This has a very large implication as this says all software  provided by a vendor has to perform an integrity and authenticity verification.

 This could implicate a dedicated channel from the vendor validating  through software certificates which would imply entities forcing software vendors to provide this mechanism, which the likelihood of meeting this for MS, Symantec, (non-control system software) is slim.  MD5 checksums can not validate the integrity of the software as this hashing mechanism was broken in 2005 (although a lot of software vendors still use it). 

Alex Ybarra, 6/14/2017

- 0 - 0

Reclamation recommends the proposed standard differentiate between contractual and non-contractual purchases, such as commercial off-the-shelf (COTS) products or other purchases made without using a contract vehicle (e.g., credit card purchases or using repurposed equipment).

Wendy Center, U.S. Bureau of Reclamation, 5, 6/14/2017

- 0 - 0

Requirement R1.

Oncor agrees with the concept; however, Oncor believes the language for R1.1 should be revised as follows, “(i) Responsible Entity procures and installs vendor equipment and software”; and “(ii) Responsible Entity transitions from one vendor(s) product or service to another vendor(s) product or service”.

 

For Requirement 1.2.1., the current wording suggests that the vendor has sufficient knowledge of Oncor’s environment to know that a particular vulnerability does in fact pose a security risk to Oncor. We offer a recommendation on the language, “Notification by the vendor of vendor-identified incidents related to the products or services provided to the Responsible Entity that could pose cyber security risk to the Responsible Entity;”

 

Requirement 1.2.2. The current phrase “coordination of response” is not clear as to what is intended by “coordination”. We offer a recommendation on the language, “Coordination of response activities by the vendor and the Responsible Entity to address vendor-identified incidents related to the products or services provided to the Responsible Entity that pose cyber security risk to the Responsible Entity;”

 

Requirement 1.2.3. The current wording suggests that the vendor has sufficient knowledge of Oncor to determine whether or not an individual should no longer be granted access. Oncor is the only party to an agreement that has the ability to determine who should or should not have access. We offer a recommendation on the language, “Circumstances where vendors should notify the Responsible Entity that access requirements of the vendor or third party personnel has changed, based on CIP-004, R5.” 

 

Requirement 1.2.4. The current wording is not clear as to which vulnerabilities are applicable. We offer a recommendation on the language, “Disclosure by vendors of known vulnerabilities in the procured product or service that follows a responsible disclosure process”; Guidance should also be added to reference US-CERT, NIST, or other industry sources.

 

Requirement 1.2.6. Oncor suggests the following wording change as the use of the phrase “Coordination of controls” is confusing. We offer a recommendation on the language, “Controls for; (i) vendor-initiated Interactive Remote Access, and (ii) system-to-system remote access with a vendor(s).”

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

- 0 - 0

BPA disagrees with the language in Requirement R3 requiring the CIP Senior Manager or delegate approve the supply chain cyber security risk management plans.  Other CIP standards, such as CIP-003-6, Requirement R1, require CIP Senior Manager approval of “policies,” not “plans.”  In Order No. 829, the Federal Energy Regulatory Commission stated, “Consistent with or similar to the requirement in Reliability Standard CIP-003-6, Requirement R1, the Reliability Standard should require the responsible entity’s CIP Senior Manager to review and approve the controls adopted to meet the specific security objectives identified in the Reliability Standard at least every 15 months.”  Order No. 829 at P46 (emphasis added).  Requiring CIP Senior Manager approval of plans is not consistent or similar to requiring approval of policies because plans are more tactical and numerous than policies.  CIP Senior Manager approval should apply only to overarching strategic documents, and not to approval of highly detailed plans for implementation of processes.  Instead, CIP-013 should be added to the list of policies requiring CIP Senior Manager approval in CIP-003-6, Requirement R1. 

Andrew Meyers, Bonneville Power Administration, 6, 6/14/2017

- 0 - 0

Even though the second proposed version of this standard has been simplified, SDG&E believes compliance with CIP-013-1 is potentially difficult and costly to demonstrate compliance.

- 0 - 0

While in overall agreement with Requirements 1 through 3, ACEC does have the following concern:

The R1 and R2 requirements in the draft split the development of one or more documented supply chain cyber security risk management plan(s) (R1) and the implementation of those supply chain cyber security risk management plan(s) specified in Requirement R1 (R2). By splitting these the potential for violations have been increased from one (1) to two (2) – one for each requirement. It is recommended that R1 and R2 be combined to reduce the potential of multiple violations for what should be a single Requirement.

To illustrate, a majority of the Standards have their development of plans, processes, or procedures and implementation of those plans, processes, or procedures in the same requirement:

CIP-002-5.1 R1; CIP-003-6 R2, R4; CIP-004-6 R1, R2, R3, R4, R5; CIP-005-5 R1, R2; CIP-006-6 R1, R2, R3; CIP-007-6 R1, R2, R3, R4, R5; CIP-010-2 R1, R2, R3, R4; CIP-011-2 R1, R2

Alan Farmer, On Behalf of: ACEC, FRCC, MRO, WECC, Texas RE, NPCC, SERC, SPP RE, RF, Segments NA - Not Applicable

- 0 - 0

In R1, NRECA recommends that the SDT reiterate “high and medium impact” each time BES Cyber System is used in the requirement parts.  (This would be added to part 1.1, 1.2, and 1.2.5.)  We also question why 1.2.1 and 1.2.2 is specific to “products or services provided to the Responsible Entity,” but 1.2.4 is not.  We recommend adding this phrase to 1.2.4: “Disclosure by vendors of known vulnerabilities related to products or services provided to the Responsible Entity.”

Further, we recommend further clarification to the term “vendor.”  We recommend explaining this term in the Guidelines and Technical Basis (GTB) section rather than the Rationale.  The intent of the term “vendor” is not a Rationale for the standard.  Additionally, there are a number of potential vendor scenarios which should be clarified in the GTB.  The vendor explanation excludes other NERC Registered Entities, but it is not clear whether this exclusion also applies to other utilities not registered with NERC.  It is also not clear whether the term vendor is intended to apply to contract employees, particularly those who may be using company issued computer equipment and receiving company developed security training.  It would seem that the Transient Cyber Asset requirements already sufficiently mitigate this risk and additional requirements are not necessary.  We also find that the term “system integrators” is not well understood and request further clarification.

Barry Lawson, 6/14/2017

- 0 - 0

John Williams, 6/15/2017

- 1 - 0

Requirements R1 and R2 essentially shift the burden for ensuring that BES Cyber System hardware and software vendors, resellers, and integrators follow sound security management practices onto individual Responsible Entities, which N&ST considers both unfair and unreasonable, for small entities in particular. The just-endorsed (by NERC) CIP-013 Implementation Guidance document suggests an entity could address R1.1’s requirement to “identify and assess cyber security risk(s) to the Bulk Electric System from vendor products or services” by means of a series of interactions with prospective vendors that comprise, for all intents and purposes, a risk assessment of the vendor, conducted by the entity. What recourse would a small entity have if a prospective supplier, perhaps the only one available, declined to cooperate with such an in-depth examination of its internal processes? R2, which requires the implementation of the entity’s R1 plan(s), acknowledges a vendor may be disinclined to agree to contractual obligations to support one or more specific elements of an entity’s R1 risk management plan. However, it contains no language that acknowledges this could make it difficult, if not impossible, for the entity to fully implement its R1 plan. N&ST believes this creates significant compliance risks for entities that may have few if any other options in some procurement situations. N&ST therefore recommends the addition of language similar to existing technical feasibility language in CIP-002 through CIP-011.

 

N&ST recommends that R2 be modified to state that a Responsible Entity has the option of describing its implementation of R1 Part 1.2.3 (revocation of vendor remote access privileges) in its CIP-004 Access Management and/or Access Revocation documentation.

 

N&ST recommends that R2 be modified to state that a Responsible Entity has the option of describing its implementation of R1 Part 1.2.6 (vendor remote access) in its CIP-005 ESP and Interactive Remote Access documentation.

 

N&ST recommends that R2 be modified to state that a Responsible Entity has the option of describing its implementation of R1 Part 1.2.5 (vendor software authenticity and integrity) in its CIP-010 Configuration Change Management documentation.

 

Initial CIP Senior Manager or delegate approval of risk management plan(s) should be added to R1. N&ST notes the initial implementation of R3 specified in the draft Implementation Plan is on or before the Effective Date. If that language is retained, there will be no need to add CIP Sr Manager or delegate approval to R1.

 

CIP-013 R2 and/or the Implementation Plan should contain “trigger” language for R2 that clarifies an entity must implement its R1 risk management plan(s) for new procurement contracts signed on or after the Effective Date of CIP-013. Entities with no new procurement contracts or no new in-progress procurements on the Effective Date should not be expected to be able to demonstrate compliance with R2 at that time.   

Nicholas Lauriat, Network and Security Technologies, 1, 6/15/2017

- 0 - 0

Melanie Seader, On Behalf of: Edison Electric Institute, NA - Not Applicable, Segments NA - Not Applicable

- 0 - 0

NYPA supports the comments submitted by Salt River Project (WECC) and NPCC.

David Rivera, New York Power Authority, 3, 6/15/2017

- 0 - 0

During the CIP-013-1 webinar on Feb 2, the SDT indicated several times that it is not the intention of R1 to force vendors to perform actions so that entities can comply with the standard.  R1.2.1, R1.2.2, R1.2.3, R1.2.4 would force vendors to develop internal processes to notify entities of any changes relating to the requirements which would force vendors to take independent action to notify entities of any changes.  Also, during the procurement phase, why would vendors reveal potential security flaws in their product above and beyond normal security patch notifications while they are competing against other vendors for the entities business?  Also, entities have processes in place already for other CIP requirements to fully prepare an asset for deployment into the ESP.  We don’t grab equipment off of the back of the delivery truck and deploy it into the ESP immediately so what is the point of knowing about security flaws in their products during procurement?  Any security flaws are probably already addressed with patches that will be downloaded and installed when preparing the asset for deployment.  Also, a vulnerability assessment has to be performed against the asset and CIP-007/CIP-005 security controls have to be checked prior to deployment.  1.2.1, 1.2.2, 1.2.4, 1.2.5 appear to be redundant with CIP-007 R2 security patch management.  Is the SDT expecting vendors to provide information about security/design flaws above and beyond the normal security patch notifications?  If so, what kind of information would that be?

1.2.5 is troublesome as well (and it seems to be a duplicate of CIP-010-3 R1.6).  Entities typically use update or proxy servers to discover and identify applicable security patches.  For example, some use Windows Update Server Services to identify patches and roll them out once testing and approvals are complete.  Do we need to check the check sums of the identified patches or can we trust that the update servers are authenticating the software?

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

- 0 - 0

NPPD supports the comments submitted by the MRO NSRF for CIP-013. In addition:

NPPD is concerned that this Standard is not sufficiently represented to be auditable. First, the Standard is not performance based, which leads to auditor discretion, which leads to inconsistency among the Regional Entities across the NERC footprint. Second, the Implementation Guidance document has words that protect the entities from interpretation risk, however are not part of the Standard; which leaves the auditor to determine the intent of the drafting team. This is true in the rationale section for R1 which has wording which would minimize interpretation risk to entities, however are not reflected in the Standard. The Rationale states that the supplier must meet CIP-013 unless it is either not offered by the supplier or would significantly increase the cost of the agreement. This needs to be included in the Standard or as a footnote in the Standard. This would be very important to clarity in audit practices.  In addition, the Standard should specifically state that as long as evidence demonstrates that all items expressly identified in R1 are contained in the “plan” and are implemented via R2 that entities shall not be out of compliance (there should be no findings for opinion on intent or security).

As with other recently produced CIP Standards, this Standard is being “rushed” to satisfy a FERC directive and without concise and clear wording, implementation considerations of all impacted parties, and the means for auditors to audit to a performance based Standard and understood audit practices. An extended comment/balloting period should be requested of NERC/FERC in order to produce an auditable Standard.

Other comments:

There are no parameters for Standard applicability. If a piece of equipment is purchased and the vendor and entity meet the Standard, do subsequent purchases of associated parts relative to the equipment or replacement parts of the equipment from other vendors need to also meet the Standard?

R1 Parts 1.2.1 and 1.2.2 “vendor-identified incident” is not clear. This needs to have clarity added in the Standard. In addition “identified” should be changed to “confirmed”.

CIP-013 R1 parts 1.2.5 and 1.2.6 are covered in CIP-005 and CIP-010. CIP-013 parts 1.2.5 and 1.2.6 should be removed to avoid duplication.  The revised CIP-013 parts 1.2.5 and 1.2.6 appear to apply to software source and identity verification (now required “when the method to do so is available” by CIP-010) and determining active vendor remote access sessions (now required by CIP-005).  Having CIP-013 parts that require entities to perform the underlying function and to take those functions into account during the procurement process is needless duplication that does not increase security or reliability and could result in compliance “double jeopardy.”

Don Schmit, 6/15/2017

- 0 - 0

Daniel Gacek, Exelon, 1, 6/15/2017

- 0 - 0

There is a lack of consistency between R1 parts 1.2.1 and 1.2.4 with respect to the use of the terms. While part 1.2.1 uses the “vendor equipment” and “software,” part 1.2.4 uses the term “products.”  The SDT should clarify if it intends “products” to be broader in scope than equipment and software.  USI recommends that the SDT be consistent and use “vendor equipment” and “software” throughout, or provide additional clarification about the scope of the term “products.”

 

In R1 parts 1.2.1 and 1.2.2, the term “vendor-identified incident” is unclear.  It could mean incidents that were identified by another party, specific to the products of a specific vendor. It could mean only incidents identified by the vendor.  USI suggests changing “identified to “acknowledged” or “confirmed.”

 

Definition of vendor is not a NERC defined term. The term “vendor” is also used in the proposed CIP-005.

USI believes the SDT should provide  guidance regarding the use of the term “vendor.”  If “Vendor” is not defined by NERC, the Guidance should recommend that Entities  include their definition of “vendor” in their plan(s).

 

Associated guidance in the “Rationale for R1” and in the separate implementation guidance should be revised to reflect the change to a performance-based requirement in which contract terms and contract negotiations play no function in auditing. Contract terms might be used by an entity as evidence of performance, but there should be no expectation by audits or subtext in the Standard or implementation guidance that anything having to do with contracts or procurement processes is required. There should be no expectation of what might or should be included within Requests for Proposals, no expectation of when contracts might or should be renegotiated, no expectations of what terms might or should be included or requested, and no expectations of what terms might or should be found in a prudent and proper contract. Ultimately there should be no expectation that such protections be achieved solely through the procurement process. Consistent with performance-based standards the objective is achieving each protection, not in how it is achieved.

 

Brian Evans-Mongeon, Utility Services, Inc., 4, 6/15/2017

- 1 - 0

GSOC supports NRECA's Comments of:

In R1, NRECA recommends that the SDT reiterate “high and medium impact” each time BES Cyber System is used in the requirement parts.  (This would be added to part 1.1, 1.2, and 1.2.5.)  We also question why 1.2.1 and 1.2.2 is specific to “products or services provided to the Responsible Entity,” but 1.2.4 is not.  We recommend adding this phrase to 1.2.4: “Disclosure by vendors of known vulnerabilities related to products or services provided to the Responsible Entity.”

Further, we recommend further clarification to the term “vendor.”  We recommend explaining this term in the Guidelines and Technical Basis (GTB) section rather than the Rationale.  The intent of the term “vendor” is not a Rationale for the standard.  Additionally, there are a number of potential vendor scenarios which should be clarified in the GTB.  The vendor explanation excludes other NERC Registered Entities, but it is not clear whether this exclusion also applies to other utilities not registered with NERC.  It is also not clear whether the term vendor is intended to apply to contract employees, particularly those who may be using company issued computer equipment and receiving company developed security training.  It would seem that the Transient Cyber Asset requirements already sufficiently mitigate this risk and additional requirements are not necessary.  We also find that the term “system integrators” is not well understood and request further clarification.

Guy Andrews, 6/15/2017

- 0 - 0

Requirements 1.2 through 1.2.4. are extremely difficult to negotiate and implement with vendors, especially across such a diverse industry and diverse set of vendors.  As written, the requirements make the vendor responsible for providing notifications to the Responsibility Entity.  This puts the burden on the Responsible Entity to enforce these requirements through contractual obligations.  The rationale states that “such contract enforcement is not subject to this Reliability Standard;” however, the performance of these requirements belongs solely to entities that are outside the jurisdiction of NERC and the Commission and can be held accountable only through contraction enforcement.  As written, these specific reliability requirements put the Responsible Entities in a precarious position of acting as a surrogate regulator on a secondary industry. 

If the intent is not to make the Responsible Entity accountable from a compliance stand point for the actions of vendors or other parties, the language should be written into the requirement wording.  The clause in R2.2 states this exception, but does not then clarify what the Responsible Entity is obligated to do.  The Responsible Entity is supposed to negotiate those terms, try to obtain that information, but if they can’t then is it still not a violation?  Will the auditors also look at it from this perspective? 

Furthermore, the language of the R1.2 to R1.2.4 should be changed to meet the SDT’s objectives while relying solely on the actions of the Responsible Entity and not those of any other party.  However, if the intent is to include the items in R1.2 in the process for consideration of risk when selecting a vendor or product during the procurement process as the draft guidance seems to indicate, then those intentions should be explicit in the requirement language.

There is no issue with Requirement 3 requiring a periodic assessment of the supply chain cyber security risk management controls in order to update plans, etc.  However, a recurring review by business unit stakeholders should be sufficient.  The requirement to have the CIP Senior Manager or delegate approve the plan is simply a formality and is administrative in nature and provides no further security value.

Laura Nelson, 6/15/2017

- 0 - 0

  •  Please provide clarification on what a “contract” is. For instance, is an annual software license a contract?

  • Please provide feedback as to what Registered Entities should do if vendors refuse to the specifications within the CIP-013 requirements.

  • Please provide further clarifications and expectations within Measure 2 to ensure entities are prepared for compliance oversight expectations.

Heather Morgan, EDP Renewables North America LLC, 5, 6/15/2017

- 0 - 0

MMWEC supports comments submitted by APPA.

David Gordon, 6/15/2017

- 0 - 0

MEAG supports the answers and comments of Salt River Project.

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

- 0 - 0

SPP offers comments on the subrequirements of R1, as follows:

R1.1 – SPP recommends that subpart (i) be modified to accommodate the procurement “and/or” installation of vendor equipment “and/or” software and, further, requests clarification as to the intended meaning of the “transitions from one vendor(s) to another vendor(s)” concept within the context of subpart (ii).

1.2.1 – SPP recommends that “products or services” be modified to reference “products and/or services.”

1.2.2 – SPP requests clarification as to the “coordination” intended to be imposed, suggesting that the requirement may stand alone with any coordination component removed.

1.2.4 – SPP recommends that the 1.2.4 be modified to appropriately limit vendor disclosure of known vulnerabilities to the products and/or services provided to the Responsible Entity, consistent with 1.2.1.  In addition, SPP notes that there is a lack of consistency between 1.2.1 and 1.2.4 with the use of the terms “vendor equipment” and “software” in 1.2.1, but uses the term “products” in subrequirement 1.2.4.  SPP seeks clarification on whether the SDT intends “products” to be broader than equipment and software.  SPP recommends that the SDT be consistent and use “vendor equipment” and “software” throughout, or provide additional clarification about the scope of the term “products.”

1.2.6- SPP requests clarification as to the “coordination” intended to be imposed, suggesting that the requirement may stand alone with the coordination component removed.  SPP believes the “coordination of controls” may be interpreted as requiring the Responsible Entity and vendor to jointly develop and/or coordinate controls, rather than simply requiring the Responsible Entity to address the requisite remote access controls in its supply chain cyber security risk management plan(s).  As drafted, SPP is concerned that it is unclear what is required for “coordination,” as well as how such coordination would be evidenced at audit.

 

SPP Standards Review Group, Segment(s) 0, 6/15/2017

- 0 - 0

NRG offers comments on the sub requirements of R1, as follows:

 

R1.1 – NRG recommends that subpart (i) be modified to accommodate the procurement “and/or” installation of vendor equipment “and/or” software and, further, requests clarification as to the intended meaning of the “transitions from one vendor(s) to another vendor(s)” concept within the context of subpart (ii).

 

1.2.1 – NRG recommends that “products or services” be modified to reference “products and/or services.”

 

1.2.2 – NRG requests clarification as to the “coordination” intended to be imposed, suggesting that the requirement may stand alone with any coordination component removed.

 

1.2.4 – NRG recommends that the 1.2.4 be modified to appropriately limit vendor disclosure of known vulnerabilities to the products and/or services provided to the Responsible Entity, consistent with 1.2.1.  In addition, NRG notes that there is a lack of consistency between 1.2.1 and 1.2.4 with the use of the terms “vendor equipment” and “software” in 1.2.1, but uses the term “products” in sub requirement 1.2.4.  NRG seeks clarification on whether the SDT intends “products” to be broader than equipment and software.  NRG recommends that the SDT be consistent and use “vendor equipment” and “software” throughout, or provide additional clarification about the scope of the term “products.”

 

1.2.6- NRG requests clarification as to the “coordination” intended to be imposed, suggesting that the requirement may stand alone with the coordination component removed.  NRG believes the “coordination of controls” may be interpreted as requiring the Responsible Entity and vendor to jointly develop and/or coordinate controls, rather than simply requiring the Responsible Entity to address the requisite remote access controls in its supply chain cyber security risk management plan(s).  As drafted, NRG is concerned that it is unclear what is required for “coordination,” as well as how such coordination would be evidenced at audit.

 

Additionally: NRG is concerned that the R1 guidance provides details which are beyond the scope of R1.

 

NRG requests that the NERC SDT consider re-wording of R1 Part 1.2.1 and 1.2.4 to easily understand what is expected. These Parts appear to be duplicative. The Guidance does not adequately distinguish between the Parts. One interpretation is that Part 1.2.1 is for products/services and that Part 1.2.4 is for vulnerabilities in the product. It is not clear if these Parts expect information sharing at the time of procurement or on-going?

 

In R1 Parts 1.2.1 and 1.2.2, the term “vendor-identified incident” is unclear.  It could mean incidents that were identified by another party, specific to the products of a specific vendor. It could mean only incidents identified by the vendor. Suggest changing “identified to “acknowledged” or “confirmed.”

 

Definition of vendor is not a NERC defined term. The term “vendor” is also used in the proposed CIP-005.

 

Request more guidance for the term “vendor” and use cases. Guidance should prompt Entities to include their definition of “vendor” in their plan(s).

 

NRG recommends removing those items (CIP-013 R1 subparts 1.2.5 and 1.2.6) that are covered in CIP-005 and CIP-010 from CIP-013.  There are substantive requirements being incorporated into CIP standards to perform functions for all BES Cyber Systems (to the extent possible), it is not clear that there is a remaining need for a separate standard requiring that those items be addressed during the procurement process.  This appears to apply to software source and identity verification (now required “when the method to do so is available” by CIP-010) and determining active vendor remote access sessions (now required by CIP-005).  Having a standard that requires you to perform the underlying function and also to take those functions into account during the procurement process is needless duplication that does not increase security or reliability and could result in compliance “double jeopardy.”

 

NRG requests SDT consideration that: The Compliance and/or Implementation Guidance should make clear that, as long as evidence demonstrates that all items expressly identified in CIP-013, R1 are contained in a Supply Chain Cyber Security Management Plan or Plans, and are implemented pursuant to R2, entities will not be found out of compliance.  More specifically, NRG requests NERC SDT consideration of the assertion that Registered Entities should not be subjected to CIP-013 noncompliance findings resulting from a difference of opinion concerning security adequacy.

 

CIP-013-1 R1.2 – “One or more process(es) used in procuring BES Cyber Systems that address the following, as applicable: “  The term “as applicable” implies it is optional.  Who determines whether something is applicable or not?  NRG suggests that NERC SDT remove it or provide additional clarity.

 

CIP-013-1 R1.2.3, NRG has concerns that it is not clear when vendors have to notify if remote or onsite access should no longer be granted to vendor representatives. 2 hrs, 24 hrs, or 3 months?

 

 

 

Is there an expectation of the vendor to disclose non-public information in 1.2.4? Is this only during contracting or is there an expectation of new vulnerabilities to be disclosed?

 

1.1  – Delete “planning for”. Or if the use of “planning for” in R1 creates a necessary distinction between 1.1 and 1.2, what is it?

-          What is implied by (ii) transitions from one vendor(s) to another vendor(s)? Why is this distinction necessary? Wouldn’t a vendor transition require a new contract? Does this refer to the act of severing existing remote access permissions? Subcontracting?

-         

-          R1.2.2: “Coordination of responses to vendor-identified incidents….”, it is not clear who should be doing the coordinating and why this is necessary.  NRG requests SDT consideration of suggestion to delete.

 

Furthermore, NRG requests NERC SDT consideration of the following comments:

·         On page 6 of CIP-013 draft:

NRG requests that the NERC standard drafting team consider providing additional clarification to the following paragraph:

For example, entities can implement the plan by including applicable procurement items from their plan in Requests for Proposals (RFPs) and in negotiations with vendors. Obtaining specific controls in the negotiated contract may not be feasible and is not considered failure to implement an entity's plan. Although the expectation is that Responsible Entities would enforce the security-related provisions in the contract based on the terms and conditions of that contract, such contract enforcement and vendor performance or adherence to the negotiated contract is not subject to this Reliability Standard.

 

NRG requests that industry have the ability to accept a level of risk through internal risk assessment processes if a supplier is unwilling to negotiate and accept the cyber security terms into negotiated contracts.

 

·         On page 6 of CIP-013 draft:

NRG requests that the NERC standard drafting team consider providing additional clarification to the following paragraph:

A vendor, as used in the standard, may include: (i) developers or manufacturers of information systems, system components, or information system services; (ii) product resellers; or (iii) system integrators.

 

NRG requests that the term vendor be further clarified to specify if meaning developers, product resellers or system integrators of “third-party” software, system components, or information system services, etc (versus internal company developers).

 

·         On page 8 of CIP-013 draft (under R2):

NRG requests that the NERC standard drafting team consider providing additional clarification to the following paragraph:

 

Note: Implementation of the plan does not require the Responsible Entity to renegotiate or abrogate existing contracts (including amendments to master agreements and purchase orders). Additionally, the following issues are beyond the scope of Requirement R2: (1) the actual terms and conditions of a procurement contract; and (2) vendor performance and adherence to a contract.

 

NRG requests further understanding of what, if any expectations are to be included in T&Cs and what are the expectations of how the vendor will be expected to perform as the term “expectations” is listed on page 6 of the standard?

 

Kara White, On Behalf of: NRG - NRG Energy, Inc., FRCC, MRO, WECC, Texas RE, NPCC, SERC, SPP RE, RF, Segments 3, 4, 5, 6

- 0 - 0

CIP-005 has had R2.4 and R2.5 added as they pertain to interactive user access and remote system to system access tracking.  These were previously in the CIP-013 standard as part of the Supply Chain requirement.  Due to CIP-005 R2 already dealing with an Intermediate system for Interactive Remote access, it seems logical that this requirement be expanded to include these.

 

The clarification that we don’t have and would like from NERC/WECC is the intent of the following statement in CIP-013  R1.2.5 “Verification of software integrity and authenticity of all software and patches provided by the vendor for use in the BES Cyber System”.   There is no Guidelines and technical basis at the end of the standard for this

 

This has a very large implication as this says all software  provided by a vendor has to perform an integrity and authenticity verification.

 

This could implicate a dedicated channel from the vendor validating  through software certificates which would imply entities forcing software vendors to provide this mechanism, which the likelihood of meeting this for MS, Symantec, (non-control system software) is slim.  MD5 checksums can not validate the integrity of the software as this hashing mechanism was broken in 2005 (although a lot of software vendors still use it). 

 

So we need clarification on this before a vote recommendation can be established for CIP-013 R1. 

LeRoy Patterson, Public Utility District No. 2 of Grant County, Washington, 6, 6/15/2017

- 0 - 0

PJM agrees, with the following suggested edits:

 

Within 1.2.1 and 1.2.2, PJM feels that “incident” need further clarification as it is a bit broad (i.e. could be interpreted as anything from a phishing attempt to an actual breach).  PJM suggests it be narrowed down to actual breaches.  Additionally, “security risk to the Responsible Entity” should be “security risk to the BES.”  Lastly, we like how the notification and coordination pieces are split out.

 

Within 1.2.3, PJM suggests changing “no longer be granted” to “should be revoked” to strengthen the language.

 

Within 1.2.5, PJM suggests adding in “firmware” and “where the method to do so is available” as to match the CIP-010 language.

Mark Holman, 6/15/2017

- 0 - 0

BPA disagrees with the language in Requirement R3 requiring the CIP Senior Manager or delegate approve the supply chain cyber security risk management plans.  Other CIP standards, such as CIP-003-6, Requirement R1, require CIP Senior Manager approval of “policies,” not “plans.”  In Order No. 829, the Federal Energy Regulatory Commission stated, “Consistent with or similar to the requirement in Reliability Standard CIP-003-6, Requirement R1, the Reliability Standard should require the responsible entity’s CIP Senior Manager to review and approve the controls adopted to meet the specific security objectives identified in the Reliability Standard at least every 15 months.”  Order No. 829 at P46 (emphasis added).  Requiring CIP Senior Manager approval of plans is not consistent or similar to requiring approval of policies because plans are more tactical and numerous than policies.  CIP Senior Manager approval should apply only to overarching strategic documents, and not to approval of highly detailed plans for implementation of processes.  Instead, CIP-013 should be added to the list of policies requiring CIP Senior Manager approval in CIP-003-6, Requirement R1. 

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

- 0 - 0

The understanding of the intent and purpose of CIP-013 is very dependent on the Implementation Guidance document.  There is no guarantee that this document will be approved by NERC even if CIP-013 is approved.

Request clarification on whether the SDT intends “products” to be broader than equipment and software.  Recommend that the SDT be consistent and use “vendor equipment” and “software” throughout, or provide additional clarification about the scope of the term “products.”

There are concerns about language related to procurement contracts, in particular use of master agreements, piggyback agreements, and evergreen agreements. To address these concerns and position CIP-013 as a performance based Standard, we recommend that all references to “contracts” and most references to “procurement” be struck from CIP-013, except the note in R2 that states:

Note: Implementation of the plan does not require the Responsible Entity to renegotiate or abrogate existing contracts (including amendments to master agreements and purchase orders). Additionally, the following issues are beyond the scope of Requirement R2: (1) the actual terms and conditions of a procurement contract; and (2) vendor performance and adherence to a contract.

Our reasoning is that there are means other than vendor contract negotiations, contract language, and procurement processes to address and achieve the protections required by R1.2. It is immaterial how these protections are achieved. Focusing thinking and audit approach on contracts and procurement (even if specific contract terms are not in scope) limits flexibility, is unnecessarily prescriptive, and does not reflect performance-based principles. As such we ask that R1.2 be revised as follows:

1.2. One or more process(es) used in procuring for its newly procured BES Cyber Systems that address the following elements, as applicable:  

(“new” meaning obtained after the implementation of CIP-013).

Request that the term “elements” be included in R1.2, as shown above, to clearly align with the VSLs for this requirement.

Associated guidance in the “Rationale for R1” and in the separate implementation guidance should be revised to reflect the change to a performance-based requirement in which contract terms and contract negotiations play no function in auditing. Contract terms might be used by an entity as evidence of performance, but there should be no expectation by audits or subtext in the Standard or implementation guidance that anything having to do with contracts or procurement processes is required. There should be no expectation of what might or should be included within Requests for Proposals, no expectation of when contracts might or should be renegotiated, no expectations of what terms might or should be included or requested, and no expectations of what terms might or should be found in a prudent and proper contract. Ultimately, there should be no expectation that such protections be achieved solely through the procurement process. The objective is achieving each protection, not in how it is achieved.

In the absence of such a change, we requests substantial additional clarification about how, without contract terms and contract negotiations being auditable, performance of R2 implementation will be audited and assessed.

 

Jesus Sammy Alcaraz, Imperial Irrigation District, 1, 6/15/2017

- 0 - 0

AZPS agrees with the proposed requirements in CIP-013-1 subject to the below requests for clarification and recommended revisions/additions.

· AZPS requests that the SDT consider and provide guidance regarding the applicability of the requirements of CIP-013-1 where the traditional procurement process is not applicable to a particular purchase.  For example,  software that is purchased from a retail source rather than a vendor is often purchased subject to existing retail terms and conditions and without the opportunity to negotiate additional terms and conditions around the procurement.

· AZPS further recommends the following changes/additions:

·         Requirement 1.2.4 - “Disclosure by vendors of known vulnerabilities when they become known to the vendor.

·         Requirement 1.2.5 as written is duplicative with CIP-010; hence, AZPS recommends this Requirement be deleted or revised to address the process for software integrity and authenticity, rather than actual verification of those.

·         Requirement 1.2.6 – AZPS recommends removal of the word “coordination” and on the insertion of the term “identification” to address a process for identifying how a vendor handles controls.

·         Requirement R2 – evidence may not be available for items that are purchased form a retail source, as noted above.  AZPS recommends an exception be identified for this purpose.

- 0 - 0

Modify R1.2.5 as follows: "Verification of software integrity and authenticity of all software and patches provided by the vendor for use in the BES Cyber System when technically feasible; and". This will help address concerns with vendors such as Microsoft that pushes patches when they identify a need.  

Add language to address allowable exception in the event of CIP Exceptional Circumstances for R2 (e.g. patches issued with ransomware attack in-progress needed immediate action to be taken).

Luminant would prefer that the CIP-013 standard be formatted similar to other CIP standards with the use of tables (e.g.CIP-004-6 Table R1).

 

 

Luminant, Segment(s) 6, 7, 5, 1/24/2017

- 0 - 0

Recommend removing those items covered in CIP-005 and CIP-010 from CIP-013.  There are substantive requirements being incorporated into CIP standards to perform functions for all BES Cyber Systems (to the extent possible), it is not clear there is a remaining need to for a separate standard requiring that those items be addressed during the procurement process.  This appears to apply to software source and identity verification (now required “when the method to do so is available” by CIP-010) and determining active vendor remote access sessions (now required by CIP-005).  Having a standard that requires you to perform the underlying function and also to take those functions into account during the procurement process is needless duplication that does not increase security or reliability and could result in compliance “double jeopardy.”

The Compliance and/or Implementation Guidance should make clear that, as long as evidence demonstrates that all items expressly identified in CIP-013, R1 are contained in a Supply Chain Cyber Security Management Plan or Plans, and are implemented pursuant to R2, entities will not be found out of compliance.  More specifically, entities should not be subjected to CIP-013 noncompliance findings resulting from a difference of opinion concerning security adequacy

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

- 0 - 0

FEUS supports the comments submitted by APPA

Linda Jacobson-Quinn, City of Farmington, 3, 6/15/2017

- 0 - 0

Scott Downey, 6/15/2017

- 0 - 0

ITC Holdings agrees with the proposed requirements, however, we believe the wording of CIP-013 leaves a lot of room for interpretation. We recommend being more prescriptive in the wording of CIP-013 as well as providing detailed guidance in the Technical Guidance document.

Additionally, ITC Holdings agrees with the below comment submitted by SPP regarding the use of “coordination”:

1.2.6- SPP requests clarification as to the “coordination” intended to be imposed, suggesting that the requirement may stand alone with the coordination component removed.  SPP believes the “coordination of controls” may be interpreted as requiring the Responsible Entity and vendor to jointly develop and/or coordinate controls, rather than simply requiring the Responsible Entity to address the requisite remote access controls in its supply chain cyber security risk management plan(s).  As drafted, SPP is concerned that it is unclear what is required for “coordination,” as well as how such coordination would be evidenced at audit.

- 0 - 0

No comment

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

- 0 - 0

- 0 - 0

GRE supports the NRECA comments. 

In R1, NRECA recommends that the SDT reiterate “high and medium impact” each time BES Cyber System is used in the requirement parts.  (This would be added to part 1.1, 1.2, and 1.2.5.)  We also question why 1.2.1 and 1.2.2 is specific to “products or services provided to the Responsible Entity,” but 1.2.4 is not.  We recommend adding this phrase to 1.2.4: “Disclosure by vendors of known vulnerabilities related to products or services provided to the Responsible Entity.”

Further, we recommend further clarification to the term “vendor.”  We recommend explaining this term in the Guidelines and Technical Basis (GTB) section rather than the Rationale.  The intent of the term “vendor” is not a Rationale for the standard.  Additionally, there are a number of potential vendor scenarios which should be clarified in the GTB.  The vendor explanation excludes other NERC Registered Entities, but it is not clear whether this exclusion also applies to other utilities not registered with NERC.  It is also not clear whether the term vendor is intended to apply to contract employees, particularly those who may be using company issued computer equipment and receiving company developed security training.  It would seem that the Transient Cyber Asset requirements already sufficiently mitigate this risk and additional requirements are not necessary.  We also find that the term “system integrators” is not well understood and request further clarification.

Michael Brytowski, Great River Energy, 3, 6/15/2017

- 0 - 0

OPG request clarification, regarding R1.2.4, of whom the vulnerability must be known by to require disclosure and that it only be for the vendor’s own products and only those supplied to the Responsible Entity. As stands, it might be interpreted that vulnerabilities might not need to be disclosed until publicly known, for products the Responsible Entity doesn’t have, or for vulnerabilities the vendor might know in products other than its own. Suggest changing to “Disclosure by the vendor of vulnerabilities known to the vendor concerning products and services supplied by the vendor to the Responsible entity.

Requirement R1 Part 1.2.4 requires additional clarification for the type of “known vulnerabilities”

Vendor definition is required to avoid ambiguity; does the term vendor apply for contract employees/augmented staff/outsourcers?

Are the requirements R1-R3 enforceable in exceptional circumstances?

David Ramkalawan, 6/15/2017

- 0 - 0

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

- 0 - 0

Comments:

Concerned that the R1 guidance provides details which are beyond the scope of R1

 

Request re-wording of R1 Part 1.2.1 and 1.2.4 to easily understand what is expected. These Parts appear to be duplicative. Guidance does not adequately distinguish between the Parts. One interpretation is that Part 1.2.1 is for products/services and that Part 1.2.4 is for vulnerabilities in the product. It is not clear if these Parts expect information sharing at the time of procurement or on-going?

 

In R1 Parts 1.2.1 and 1.2.2, the term “vendor-identified incident” is unclear.  It could mean incidents that were identified by another party, specific to the products of a specific vendor. It could mean only incidents identified by the vendor. Suggest changing “identified to “acknowledged” or “confirmed.”

 

Definition of vendor is not a NERC defined term. The term “vendor” is also used in the proposed CIP-005.

 

Request more guidance for the term “vendor” and use cases. Guidance should prompt Entities to include their definition of “vendor” in their plan(s).

 

 

Recommend removing those items (CIP-013 R1 subparts 1.2.5 and 1.2.6) covered in CIP-005 and CIP-010 from CIP-013.  There are substantive requirements being incorporated into CIP standards to perform functions for all BES Cyber Systems (to the extent possible), it is not clear there is a remaining need to for a separate standard requiring that those items be addressed during the procurement process.  This appears to apply to software source and identity verification (now required “when the method to do so is available” by CIP-010) and determining active vendor remote access sessions (now required by CIP-005).  Having a standard that requires you to perform the underlying function and also to take those functions into account during the procurement process is needless duplication that does not increase security or reliability and could result in compliance “double jeopardy.”

 

The Compliance and/or Implementation Guidance should make clear that, as long as evidence demonstrates that all items expressly identified in CIP-013, R1 are contained in a Supply Chain Cyber Security Management Plan or Plans, and are implemented pursuant to R2, entities will not be found out of compliance.  More specifically, entities should not be subjected to CIP-013 noncompliance findings resulting from a difference of opinion concerning security adequacy.

 

Is there an expectation of the vendor to disclose non-public information in 1.2.4? Is this only during contracting or is there an expectation of new vulnerabilities to be disclosed?

 

{C}1.1  – Delete “planning for”. Or if the use of “planning for” in R1 creates a necessary distinction between 1.1 and 1.2, what is it?

-          What is implied by (ii) transitions from one vendor(s) to another vendor(s)? Why is this distinction necessary? Wouldn’t a vendor transition require a new contract? Does this refer to the act of severing existing remote access permissions? Subcontracting?

-           

-          R1.2.2: “Coordination of responses to vendor-identified incidents….”, it is not clear who should be doing the coordinating and why this is necessary.  Suggest deleting.

 

Timothy Reyher, 6/15/2017

- 0 - 0

Request re-wording of R1 Part 1.2.1 and 1.2.4 to easily understand what is expected. These Parts appear to be duplicative. Guidance does not adequately distinguish between the Parts. One interpretation is that Part 1.2.1 is for products/services and that Part 1.2.4 is for vulnerabilities in the product. It is not clear if these Parts expect information sharing at the time of procurement or on-going?

In R1 Parts 1.2.1 and 1.2.2, the term “vendor-identified incident” is unclear.  It could mean incidents that were identified by another party, specific to the products of a specific vendor. It could mean only incidents identified by the vendor. Suggest changing “identified to “acknowledged” or “confirmed.

Recommend removing CIP-013 R1 subparts 1.2.5 and 1.2.6 from CIP-013 since these are covered in CIP-005 and CIP-010. There are substantive requirements being incorporated into CIP standards to perform functions for all BES Cyber Systems (to the extent possible), it is not clear there is a remaining need to for a separate standard requiring that those items be addressed during the procurement process.  This appears to apply to software source and identity verification (now required “when the method to do so is available” by CIP-010) and determining active vendor remote access sessions (now required by CIP-005).  Having a standard that requires you to perform the underlying function and also to take those functions into account during the procurement process is needless duplication that does not increase security or reliability and could result in compliance “double jeopardy.”

The Compliance and/or Implementation Guidance should make clear that, as long as evidence demonstrates that all items expressly identified in CIP-013, R1 are contained in a Supply Chain Cyber Security Management Plan or Plans, and are implemented pursuant to R2, entities will not be found out of compliance.  More specifically, entities should not be subjected to CIP-013 noncompliance findings resulting from a difference of opinion concerning security adequacy.

Is there an expectation of the vendor to disclose non-public information in 1.2.4? Is this only during contracting or is there an expectation of new vulnerabilities to be disclosed?

 

{C}1.1  – Delete “planning for”. Or if the use of “planning for” in R1 creates a necessary distinction between 1.1 and 1.2, what is it?

-          What is implied by (ii) transitions from one vendor(s) to another vendor(s)? Why is this distinction necessary? Wouldn’t a vendor transition require a new contract? Does this refer to the act of severing existing remote access permissions? Subcontracting?

-          R1.2.2: “Coordination of responses to vendor-identified incidents….”, it is not clear who should be doing the coordinating and why this is necessary.  Suggest deleting.

 

Quintin Lee, Eversource Energy, 1, 6/15/2017

- 0 - 0

ACES supports the requirements to reduce the risk of remote access management. Using the CIP Applicability Section reduces the previous confusion of what BES Cyber Assets are in scope.

 

ACES Standards Collaborators, Segment(s) 1, 3, 4, 5, 6/15/2017

- 0 - 0

Texas RE notes that the proposed standard is not responsive to the FERC directive.  FERC Order No. 829 P. 59 specifically states “The new or modified Reliability Standard must address the provision and verification of relevant security concepts in future contracts for industrial control system hardware, software, and computing and networking services associated with bulk electric system operations.”  The Note in Requirement R2, however, states: “Additionally, the following issues are beyond the scope of Requirement R2: (1) the actual terms and conditions of a procurement contract; and (2) vendor performance and adherence to a contract.”  Texas RE agrees that it is unreasonable to hold a registered entity accountable for a vendor’s adherence to (or lack of adherence to) a contract.  Texas RE agrees as the standard drafting team (SDT) claims obtaining specific controls in the negotiated contract may not be feasible at all times but Texas RE believes this is best practice. In fact, in most cases contracts for these types of systems typically include security provisions and set similar expectations as described in the standard. The proposed standards would prohibit the compliance monitor from verifying the registered entity implemented part 1.1 and sub-parts 1.2.1 through 1.2.7. Moreover, this verification is to ensure that the registered entities’ plans are consistent with the contract’s expectations and obligations of the parties.

Admittedly, there will be circumstances in which a contracts may not be consistent or silent as it pertains to the responsible entity’s security management plans (e.g. existing contacts or contracts in which the responsible entity was unable to negotiate the appropriate terms into the contract.) In those circumstances, other evidence should be provided demonstrating that the responsible entity has processes to ensure the vendor is expected/obligated to act consistently with the responsible entity’s cyber security risk management plans as it relates to the vendor’s products or services. Therefore, the contracts should remain in scope as to demonstrate the mapping of expectations from the plan to the contract as far as vendor interactions for those specific items included in the standard and to advance best practices leading to a more reliable BES.

 

Additionally, Texas RE has the following concerns:

  • In the current CIP-013-1 version, the SDT elected to restrict the scope of the Supply Chain process to Medium and High Impact Bulk Electric System (BES) Cyber Systems, as well as exclude Physical Access Controls (PACS), Electronic Access Control and Monitoring Systems (EACMS), and Protected Cyber Assets (PCAs) from the scope of the Standard.  In doing so, the SDT appeared to rely on a number of commenters that suggested that FERC Order No. 829, P. 59 excluded these types of devices.  Specifically, these commenters pointed to the following language in the FERC Order: “The new or modified Reliability Standard must address the provision and verification of relevant security concepts in future contracts for industrial control system hardware, software, and computing and networking services associated with bulk electric system operations.”  FERC Order No. 829, P. 59.  Accordingly, it appears that the SDT has concluded that PACS, EACMS, and PCAs collectively do not fall within the scope of “industrial control system hardware” or “computing and networking services associated with bulk electric system operations.” 

     

    Texas RE is concerned PACS, EACMS, and PCAs do fall within the scope of “industrial control system hardware” and “computing and networking services associated with bulk electric system operations” as those terms are used in FERC Order No. 829.  PACS, EACMS, and PCAs are foundational equipment within a network’s architecture.  Moreover, these devices are vendor supported and exposed to the precise vulnerabilities identified in FERC’s supply chain directive.  Given these facts, Texas RE does not believe there is either a basis in FERC Order No. 829 or, more importantly, a reliability-based rationale for excluding them from the scope of CIP-013-1.

     

  • Page 7, Part 1.1:  While FERC Order No. 829 specifically uses the term “hardware”, Texas RE notes the word “hardware” is not used in the standard language.  Texas RE recommends replacing the word equipment with the term hardware in order to be consistent with the FERC Order. 

     

  • Page 8, Section 1.2.6:  Texas RE recommends the SDT define or provide examples of the term “system-to-system remote access” as this is a broad term which can be interpreted in many different ways.

Rachel Coyne, Texas Reliability Entity, Inc., 10, 6/15/2017

- 0 - 0

Theresa Rakowsky, 6/15/2017

- 0 - 0

AECI supports NRECA's comments provided below:

In R1, NRECA recommends that the SDT reiterate “high and medium impact” each time BES Cyber System is used in the requirement parts.  (This would be added to part 1.1, 1.2, and 1.2.5.)  We also question why 1.2.1 and 1.2.2 is specific to “products or services provided to the Responsible Entity,” but 1.2.4 is not.  We recommend adding this phrase to 1.2.4: “Disclosure by vendors of known vulnerabilities related to products or services provided to the Responsible Entity.”

 

Further, we recommend further clarification to the term “vendor.”  We recommend explaining this term in the Guidelines and Technical Basis (GTB) section rather than the Rationale.  The intent of the term “vendor” is not a Rationale for the standard.  Additionally, there are a number of potential vendor scenarios which should be clarified in the GTB.  The vendor explanation excludes other NERC Registered Entities, but it is not clear whether this exclusion also applies to other utilities not registered with NERC.  It is also not clear whether the term vendor is intended to apply to contract employees, particularly those who may be using company issued computer equipment and receiving company developed security training.  It would seem that the Transient Cyber Asset requirements already sufficiently mitigate this risk and additional requirements are not necessary.  We also find that the term “system integrators” is not well understood and request further clarification.

AECI & Member G&Ts, Segment(s) 1, 6, 5, 3, 4/11/2017

- 0 - 0

Concerned that the R1 guidance provides details which are beyond the scope of R1

 

Request re-wording of R1 Part 1.2.1 and 1.2.4 to easily understand what is expected. These Parts appear to be duplicative. Guidance does not adequately distinguish between the Parts. One interpretation is that Part 1.2.1 is for products/services and that Part 1.2.4 is for vulnerabilities in the product. It is not clear if these Parts expect information sharing at the time of procurement or on-going?

 

In R1 Parts 1.2.1 and 1.2.2, the term “vendor-identified incident” is unclear.  It could mean incidents that were identified by another party, specific to the products of a specific vendor. It could mean only incidents identified by the vendor. Suggest changing “identified to “acknowledged” or “confirmed.”

 

Definition of vendor is not a NERC defined term. The term “vendor” is also used in the proposed CIP-005.

 

Request more guidance for the term “vendor” and use cases. Guidance should prompt Entities to include their definition of “vendor” in their plan(s).

 

 

Recommend removing those items (CIP-013 R1 subparts 1.2.5 and 1.2.6) covered in CIP-005 and CIP-010 from CIP-013.  There are substantive requirements being incorporated into CIP standards to perform functions for all BES Cyber Systems (to the extent possible), it is not clear there is a remaining need to for a separate standard requiring that those items be addressed during the procurement process.  This appears to apply to software source and identity verification (now required “when the method to do so is available” by CIP-010) and determining active vendor remote access sessions (now required by CIP-005).  Having a standard that requires you to perform the underlying function and also to take those functions into account during the procurement process is needless duplication that does not increase security or reliability and could result in compliance “double jeopardy.”

 

The Compliance and/or Implementation Guidance should make clear that, as long as evidence demonstrates that all items expressly identified in CIP-013, R1 are contained in a Supply Chain Cyber Security Management Plan or Plans, and are implemented pursuant to R2, entities will not be found out of compliance.  More specifically, entities should not be subjected to CIP-013 noncompliance findings resulting from a difference of opinion concerning security adequacy.

 

Is there an expectation of the vendor to disclose non-public information in 1.2.4? Is this only during contracting or is there an expectation of new vulnerabilities to be disclosed?

 

1.1  – Delete “planning for”. Or if the use of “planning for” in R1 creates a necessary distinction between 1.1 and 1.2, what is it?

-          What is implied by (ii) transitions from one vendor(s) to another vendor(s)? Why is this distinction necessary? Wouldn’t a vendor transition require a new contract? Does this refer to the act of severing existing remote access permissions? Subcontracting?

-           

R1.2.2: “Coordination of responses to vendor-identified incidents….”, it is not clear who should be doing the coordinating and why this is necessary.  Suggest deleting.

RSC no Dominion, Segment(s) 1, 0, 2, 4, 5, 6, 7, 3, 6/15/2017

- 1 - 0

GTC supports NRECA comments:

In R1, NRECA recommends that the SDT reiterate “high and medium impact” each time BES Cyber System is used in the requirement parts.  (This would be added to part 1.1, 1.2, and 1.2.5.)  We also question why 1.2.1 and 1.2.2 is specific to “products or services provided to the Responsible Entity,” but 1.2.4 is not.  We recommend adding this phrase to 1.2.4: “Disclosure by vendors of known vulnerabilities related to products or services provided to the Responsible Entity.”

 

Further, we recommend further clarification to the term “vendor.”  We recommend explaining this term in the Guidelines and Technical Basis (GTB) section rather than the Rationale.  The intent of the term “vendor” is not a Rationale for the standard.  Additionally, there are a number of potential vendor scenarios which should be clarified in the GTB.  The vendor explanation excludes other NERC Registered Entities, but it is not clear whether this exclusion also applies to other utilities not registered with NERC.  It is also not clear whether the term vendor is intended to apply to contract employees, particularly those who may be using company issued computer equipment and receiving company developed security training.  It would seem that the Transient Cyber Asset requirements already sufficiently mitigate this risk and additional requirements are not necessary.  We also find that the term “system integrators” is not well understood and request further clarification.

Jason Snodgrass, 6/15/2017

- 0 - 0

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

- 0 - 0

Requirement R1. The IRC has no issues with the concept. We offer a recommendation on the language, “(i) Responsible Entity procures and installs vendor equipment and software; and (ii) Responsible Entity transitions from one vendor(s) product or service to another vendor(s) product or service”.

Note: ERCOT does not support the above comment.

Requirement 1.2.1. The current wording suggests that the vendor has sufficient knowledge of the Responsible Entities’ environment to know that a particular vulnerability does in fact pose a security risk to the Responsible Entity. We offer a recommendation on the language, Notification by the vendor of vendor-identified incidents related to the products or services provided to the Responsible Entity that could pose cyber security risk to the Responsible Entity;”

Requirement 1.2.2. The current phrase “coordination of response” is not clear as to what is intended by “coordination”. We offer a recommendation on the language, Coordination of response activities by the vendor and the Responsible Entity to address vendor-identified incidents related to the products or services provided to the Responsible Entity that pose cyber security risk to the Responsible Entity;”

Requirement 1.2.4. The current wording is not clear as to which vulnerabilities are applicable. We offer a recommendation on the language, Disclosure by vendors of known vulnerabilities in the procured product or service following a responsible disclosure process”.”  

Requirement 1.2.6. The use of the phrase “Coordination of controls” is confusing. We offer a recommendation on the language, “Controls for; (i) vendor-initiated Interactive Remote Access, and (ii) system-to-system remote access with a vendor(s).”

SRC + SWG , Segment(s) 2, 3, 1, 0, 6/15/2017

- 0 - 0

Victor Garzon, 6/15/2017

- 0 - 0

Pablo Onate, El Paso Electric Company, 1, 6/15/2017

- 0 - 0

Rhonda Bryant, El Paso Electric Company, 3, 6/15/2017

- 0 - 0

See below comments.

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

- 0 - 0

Glen Farmer, Avista - Avista Corporation, 5, 6/15/2017

- 0 - 0

Oxy, Segment(s) 7, 5, 9/6/2016

- 0 - 0

No comment.

Teresa Krabe, Lower Colorado River Authority, 5, 6/15/2017

- 0 - 0

The following comment covers several of the questions in one comment, submitted by the Foundation for Resilient Societies, Nashua, NH.

William Harris, Foundation for Resilient Societies, 8, 6/15/2017

Resilient Societies Comments - NERC Cyber Supply Chain Risk Management 2016-03.docx

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

John Martinsen, Public Utility District No. 1 of Snohomish County, 4, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Long Duong, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Mark Oens, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Sam Nietfeld, Public Utility District No. 1 of Snohomish County, 5, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Franklin Lu, 6/15/2017

- 0 - 0

ERCOT joins the comments of the IRC with the exception of the comment on Requirement R1, Part 1.1. 

Elizabeth Axson, 6/15/2017

- 0 - 0

Hot Answers

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

Richard Vine, 6/15/2017

- 0 - 0

- 0 - 0

Other Answers

Randy Buswell, 5/31/2017

- 0 - 0

Bill Watson, On Behalf of: Bill Watson, , Segments 3

- 0 - 0

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

- 0 - 0

Sandra Pacheco, On Behalf of: Silicon Valley Power - City of Santa Clara, , Segments 3, 5

- 0 - 0

Val Ridad, On Behalf of: Silicon Valley Power - City of Santa Clara, , Segments 3, 5

- 0 - 0

We request clarification on whether “system-to-system” access applies to access that is “one-way” where the remote end conducts only monitoring activity and no control is possible, or whether the SDT intent is that any system-to-system access be included.   We would suggest that the SDT add verbiage to the Guidelines and Technical Basis making the distinction for each type of “active vendor remote access sessions” that are included in this requirement (Interactive Remote Access, system-to-system remote access with control, and/or system-to-system remote access for monitoring only).  Another suggestion would be to create a formal NERC definition of system-to-system access.

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

- 0 - 0

Illinois Municipal Electric Agency supports comments submitted by the American Public Power Association.

Bob Thomas, 6/9/2017

- 0 - 0

CHPD supports these changes.

Haley Sousa, 6/9/2017

- 0 - 0

CHPD supports these changes.

Janis Weddle, 6/9/2017

- 0 - 0

The inclusion of (including Interactive Remote Access and system-to-system remote access) is problematic as the NERC defined term of Interactive Remote Access (IRA) explicitly excludes system-to-system process communication. Additionally, IRA already includes the concept of vendors (see 3) below).

“User-initiated access by a person employing a remote access client or other remote access technology using a routable protocol. Remote access originates from a Cyber Asset that is not an Intermediate System and not located within any of the Responsible Entity’s Electronic Security Perimeter(s) or at a defined Electronic Access Point (EAP). Remote access may be initiated from: 1) Cyber Assets used or owned by the Responsible Entity, 2) Cyber Assets used or owned by employees, and 3) Cyber Assets used or owned by vendors, contractors, or consultants. Interactive remote access does not include system-to-system process communications.”

The SDT should consider removing this system-to-system exclusion from the IRA defined term and stating Part 2.4 as –

Have one or more methods for determining active vendor Interactive Remote Access sessions.

And Part 2.5 as –

Have one or more method(s) to disable active vendor Interactive Remote Access sessions.

(note: the addition of ‘sessions’ in this Part to be consistent with Part 2.4.)

Lastly, from an SCRM perspective, the SDT should consider at least including some indication of when vendor remote access could or should be disrupted, but that may be better addressed in the CIP-013-1 R1.2.2 and/or R1.2.6 processes of the SCRM plan(s).

Steven Rueckert, Western Electricity Coordinating Council, 10, 6/9/2017

- 0 - 0

CHPD supports these changes.

Chad Bowman, 6/9/2017

- 0 - 0

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

- 0 - 0

CHPD supports these changes.

Mick Neshem, 6/12/2017

- 0 - 0

Colorado Springs Utilities supports the comments provided by APPA

Jeff Icke, Colorado Springs Utilities, 5, 6/12/2017

- 0 - 0

As in Question 1, regarding the use of the term “vendor,” as described in the “Rationale for Requirement R2” section of CIP-005-6:  the SDT may want to clarify that staff augmentation contractors are not considered to be “vendors” in the context of the standard.

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

- 0 - 0

No comment.

Daniel Grinkevich, 6/12/2017

- 0 - 0

Patrick Hughes, On Behalf of: National Electrical Manufacturers Association, NA - Not Applicable, Segments NA - Not Applicable

- 0 - 0

Shawn Abrams, 6/13/2017

- 0 - 0

A definition of “vendor” is necessary. This should be interpreted as any third-party that initiates a remote access session. Not every third-party is necessarily considered a “vendor” based on generally accepted definitions.

 

With respect to the proposed Requirement 2 Part 2.4, additional details need to be provided on the expectations of “determining active vendor remote access sessions”. Two of the proposed measures state, “Methods for monitoring activity (e.g. connection tables or rule hit counters in a firewall, or user activity monitoring) or open ports (e.g. netstat or related commands to display currently active ports) to determine active system to system remote access sessions; or Methods that control vendor initiation of remote access such as vendors calling and requesting a second factor in order to initiate remote access.” The former will be difficult to actively monitor for remote access. Remote access can be monitored, but this activity is too resource intensive to monitor in real-time. If it is necessary to actively monitor remote access in real-time then additional guidance is necessary. The latter is easily implemented. It is uncertain whether this requirement is expecting constant monitoring during the remote access session or just controlling access and logging the access. A more detailed expectation on the use of the reference tools is necessary.

Steven Sconce, On Behalf of: EDF Renewable Energy, , Segments 5

- 0 - 0

- 0 - 0

R2 part 2.4 should read: Have one or more methods for determining when vendor Interactive Remote Access and/or vendor system-to-system remote access sessions are active.

 

Part 2.5 should read: Have one or more methods to disable active vendor Interactive Remote Access and/or vendor system-to-system remote access sessions).

Thomas Foltz, AEP, 5, 6/13/2017

- 0 - 0

With the deletion of the language in R2, it now appears that every Responsible Entity needs to have a documented process for Interactive Remote Access, even if the Responsible Entity does not allow it.  Why did the team delete this exemption language from R2 as it seemed to lessen the burden for those entities that do not allow Interactive Remote Access?

Michael Haff, On Behalf of: Seminole Electric Cooperative, Inc., FRCC, Segments 1, 3, 4, 5, 6

- 0 - 0

Because the term "vendor" is not a NERC-defined term, the SDT should provide guidance regarding its use.

A "CIP Exceptional Circumstance" clause should be added to R2, Parts 2.4 and 2.5.

Allan Long, Memphis Light, Gas and Water Division, 1, 6/13/2017

- 0 - 0

ReliabilityFirst agrees the changes to CIP-005-6 address directives from Federal Energy Regulatory Commission (FERC) Order No. 829 to develop a new or modified standard to address “supply chain risk management for industrial control system hardware, software, and computing and networking services associated with bulk electric system operations.”  ReliabilityFirst offers the following specific comments for consideration. 

  1. Requirement R2 Part 2.3

    1. To be consistent with Parts 2.1 and 2.2 in the Standard, ReliabilityFirst offers the following modifications for consideration:

      1. [For all Interactive Remote Access sessions, require] multi-factor authentication.

  2. Requirement R2 Part 2.4

    1. ReliabilityFirst believes more context should be placed around the term “determining”.  ReliabilityFirst offers the following modifications for consideration:

      1. Have one or more method(s) for [authorizing, monitoring, and logging] active vendor remote access sessions (including Interactive Remote Access and system-to-system remote access).

Anthony Jablonski, ReliabilityFirst , 10, 6/13/2017

- 0 - 0

PRPA agrees with R2 Part 2.4 but requests clarification of the term “determining.”

PRPA generally agrees with Proposed R2 Part 2.5 but requests revisions to the Rationale for R2. The last sentence of paragraph 2 of the rationale states the objective “is for entities to have the ability to rapidly disable active remote access sessions…” The Responsible Entity may not have the capability to disable access during an “active” remote access session. PRPA requests changing the language to “upon detected unauthorized activity.”

Tyson Archie, Platte River Power Authority, 5, 6/14/2017

- 0 - 0

Amelia Sawyer Anderson, On Behalf of: CenterPoint Energy Houston Electric, LLC, Texas RE, Segments 1

- 0 - 0

- 0 - 0

W. Dwayne Preston, Austin Energy, 3, 6/14/2017

- 0 - 0

Lauren Price, 6/14/2017

- 0 - 0

 

SMUD agrees with R2 Part 2.4 but requests clarification of the term “determining.”

 

 

 

SMUD generally agrees with Proposed R2 Part 2.5 but requests revisions to the Rationale for R2. The last sentence of paragraph 2 of the rationale states the objective “is for entities to have the ability to rapidly disable active remote access sessions…” The Responsible Entity may not have the capability to disable access during an “active” remote access session. SMUD requests changing the language to “upon detected unauthorized activity.”  Clarification or formal definition of the term ‘vendor’ should be considered.  ICCP and DNP3 traffic is routine system-to-system remote access between utilities, Operation and Maintenance vendors and other partners to provide reliability, without the term ‘vendor’ clarified, these protocols may fall into scope unnecessarily. 

 

- 0 - 0

AE agrees with R2 Part 2.4 but requests clarification of the term “determining.”

AE generally agrees with Proposed R2 Part 2.5, but requests revisions to the rationale for R2. The last sentence of paragraph 2 states the objective “is for entities to have the ability to rapidly disable active remote access sessions…” The Responsible Entity may not have the capability to disable access during an “active” remote access session. AE requests changing the language to “upon detected unauthorized activity.”

Andrew Gallo, 6/14/2017

- 0 - 0

BC Hydro sees value in adding the machine to machine vendor remote access component.

BC Hydro, Segment(s) 1, 2, 3, 5, 5/6/2015

- 0 - 0

I fully support the concept of monitoring and being able to terminate all remote acccess sessions, however as written the additional requirements have no timing aspects associated with them, have no component for notification or alerting on active sessions, are atrifically limited to vendor access only, (lower case vendor) so may not include contractors, service providers, etc. Cannot support the requirement as written.

Richard Kinas, 6/14/2017

- 0 - 0

See atttached comments.

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

2016-03_Unofficial_Comment_Form_SCL_2017-6-14 Final to NERC.docx

- 0 - 0

Request to defined the scope of the requirements  “for new contracts only”

With no defined scope, if the standard become effective in same time of the standard CIP-013-1, no terms will existed beetween entities and vendor in effective contracts. How the entities will comply to requirements ?

Definition of vendor is not a NERC defined term. The term “vendor” is also used in the proposed CIP-005.

Request more guidance for the term “active vendor remote access sessions” and use cases. Guidance should prompt Entities to include their definition of “vendor” in their plan(s).

Guideline & Technical Basis for R2 should be included in this update. Supplemental materials may be out of date – see page 21 of 24 in the posted redline version. Include reference to FERC Order 829 for Parts 2.4 and 2.5

Consider adding a CIP Exceptional Circumstance clause to R2 Parts 2.4 and 2.5

Normande Bouffard, 6/14/2017

- 0 - 0

CIP-005-6 R2 Part 2.4 as drafted does not identify the “direction” of how system-to-system remote access is initiated. Interactive Remote Access specifies that it originates “from a Cyber Asset that is not an Intermediate System and not located within any of the Responsible Entity’s Electronic Security Perimeters”. Without defining the system of origin or other defining controls, similar to the definition of Interactive Remote Access, any connection from a CIP Cyber Asset to a vendor system, even if one-way and simply for data acquisition/submission, could be interpreted as subject to this requirement. Additional clarification is requested.

Additionally, the Supplemental Material for the requirement points to a separate document without an official link. It appears this document has not been updated in six (6) years, and mostly targets securing Interactive Remote Access. It is requested that updated relevant material be placed in the Standard’s Supplemental Material section, similar to other CIP standards, and that the Supplemental Material section also attempt to provide guidance on the securing of system-to-system remote access.

Entergy/NERC Compliance, Segment(s) 1, 5, 3/1/2017

- 0 - 0

Theresa Allard, Minnkota Power Cooperative Inc., 1, 6/14/2017

- 0 - 0

SRP agrees with R2 Part 2.4 but requests clarification of the term “determining.”

SRP generally agrees with Proposed R2 Part 2.5 but requests revisions to the Rationale for R2. The last sentence of paragraph 2 of the rationale states the objective “…is for entities to have the ability to rapidly disable active remote access sessions…” The Responsible Entity may not have the capability to disable access during an “active” remote access session. SRP requests changing the language to “upon detected unauthorized activity.”

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

- 0 - 0

Alex Ybarra, 6/14/2017

- 0 - 0

Reclamation recommends that CIP-005-6 Requirement R2 Part 2.4 Requirements be changed to state, “Have one or more methods for determining and logging active vendor remote access sessions (including Interactive Remote Access and system-to-system remote access).”

 

Reclamation recommends that the first bullet in CIP-005-6 Requirement R2 Part 2.4 Measures be changed to state, “Methods for accessing logged and actively monitored information to determine active vendor remote access sessions;”

 

Reclamation also recommends that CIP-005-6 R2.3 be changed to "Where technically feasible, require multi-factor authentication for all Interactive Remote Access sessions" to align with CIP-007 R5, dealing with authentication requirements to help with consistency within the standards.

Wendy Center, U.S. Bureau of Reclamation, 5, 6/14/2017

- 0 - 0

The definition of “vendor” is important for defining and carrying out its compliance objectives for the requirements parts 2.4 and 2.5.  The drafting team should add a part of one or both requirements to include a specific definition of vendor to support the related compliance procedures and evidence required of an entity.

 

For Part 2.4, it is not clear if the requirement applies to contractors and service vendors that are provided authorized access under CIP-004. Additionally, more information is needed on the meaning of “active”. Most of this is captured in logs after the fact. Does the drafting team intend for “active” to imply real-time information? Please clarify if the requirement only applies to a connection from the vendor directly to a system within the ESP or does it apply to connections from a vendor to a system outside the ESP that updates one inside the ESP. 

 

For Part 2.5, Oncor would like clarification of the action, or examples, for when access should be disabled.

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

- 0 - 0

Andrew Meyers, Bonneville Power Administration, 6, 6/14/2017

- 0 - 0

- 0 - 0

No Comments

Alan Farmer, On Behalf of: ACEC, FRCC, MRO, WECC, Texas RE, NPCC, SERC, SPP RE, RF, Segments NA - Not Applicable

- 0 - 0

NRECA requests that the SDT clarify in the requirements and GTB that applicable entities that do not allow Remote Access, do not have to create a process for Remote Access or terminating Remote Access.

Barry Lawson, 6/14/2017

- 0 - 0

John Williams, 6/15/2017

- 1 - 0

Suggest rewording 2.4 to read, “Have one or more methods for determining when vendor remote access sessions (including Interactive Remote Access and system-to-system remote access) are active.” Alternative wording would be, “Have one or more methods for identifying active vendor remote access sessions (including Interactive Remote Access and system-to-system remote access).”   

Nicholas Lauriat, Network and Security Technologies, 1, 6/15/2017

- 0 - 0

Melanie Seader, On Behalf of: Edison Electric Institute, NA - Not Applicable, Segments NA - Not Applicable

- 0 - 0

NYPA supports the comments submitted by Salt River Project (WECC) and NPCC.

David Rivera, New York Power Authority, 3, 6/15/2017

- 0 - 0

The NSRF question the use of “…active vendor…” in part 2.4 and 2.5 Requirements.  The word “active” could mean either “the vendor is currently allowed electronic access and is currently within a BES Cyber Asset” OR “the vendor is idle and but has electronic access to a BES Cyber Asset”.  The NSRF recommends that “active” be removed as this will provide clarity to applicable entities.  If active sessions was the SDT thought process, please state that within the proposed part.

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

- 0 - 0

NPPD supports the comments for the MRO NSRF for this question.

Don Schmit, 6/15/2017

- 0 - 0

As stated, this requirement seems to start with the base assumption that the Registered Entity allows vendors to have Remote Access to the Registered Entity’s  BES Cyber Assets with External Routable Connectivity (ERC), and therefore must implement a method to detect active vendor remote access session and have a method for disabling vendor access. Many Registered Entities do not allow vendors to have Remote Access to substation medium BES Cyber Assets. Would this relieve such REs from having to then develop a method to detect and disable active vendor remote access session and would documentation demonstrating that Vendor Remote Access was not allowed be sufficient?

Daniel Gacek, Exelon, 1, 6/15/2017

- 0 - 0

The proposed CIP-005-6 uses vendor.  Definition of vendor is not a NERC defined term.  USI believes the SDT should provide  guidance regarding the use of the term “vendor.”  If “Vendor” is not defined by NERC, the Guidance should recommend that Entities  include their definition of “vendor” in their plan(s).

The SDT should consider adding a CIP Exceptional Circumstance clause to R2 Parts 2.4 and 2.5

Brian Evans-Mongeon, Utility Services, Inc., 4, 6/15/2017

- 1 - 0

GSOC supports NRECA's Comments of:

NRECA requests that the SDT clarify in the requirements and GTB that applicable entities that do not allow Remote Access, do not have to create a process for Remote Access or terminating Remote Access.

Guy Andrews, 6/15/2017

- 0 - 0

Does system to system remote access include “read-only” access or all forms of external access from vendors?

Laura Nelson, 6/15/2017

- 0 - 0

Heather Morgan, EDP Renewables North America LLC, 5, 6/15/2017

- 0 - 0

MMWEC supports comments submitted by APPA.

David Gordon, 6/15/2017

- 0 - 0

MEAG supports the answers and comments of Salt River Project.

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

- 0 - 0

SPP Standards Review Group, Segment(s) 0, 6/15/2017

- 0 - 0

The definition of vendor is crucial to an entity defining and carrying out its compliance objectives for the requirements in question.

 

The definition of vendor is not a NERC defined term. The term “vendor” is also used in the proposed CIP-013.

 

Request more guidance for the term “vendor” and use cases. Guidance should prompt Entities to include their definition of “vendor” in their plan(s).

 

Regarding CIP-005-6, R2.4 & R2.5; NRG requests that the NERC SDT define or further clarify the meaning of “system-to-system” remote access.

 

NRG asserts that Guideline & Technical Basis for R2 should be included in this update. Supplemental materials may be out of date – see page 21 of 24 in the posted redline version. Please include a reference to FERC Order 829 for Parts 2.4 and 2.5.

Please consider adding a CIP Exceptional Circumstance clause to R2 Parts 2.4 and 2.5.

 

Kara White, On Behalf of: NRG - NRG Energy, Inc., FRCC, MRO, WECC, Texas RE, NPCC, SERC, SPP RE, RF, Segments 3, 4, 5, 6

- 0 - 0

LeRoy Patterson, Public Utility District No. 2 of Grant County, Washington, 6, 6/15/2017

- 0 - 0

As currently written, it is ambiguous in 2.4 as to why an entity needs to “determine” vendor access, especially in conjunction with the logging, monitoring and control activities described within the measures.  PJM suggests combining 2.4 and 2.5 together (“Have one or more method(s) to determine and disable active vendor remote access sessions…”).

Mark Holman, 6/15/2017

- 0 - 0

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

- 0 - 0

Request more guidance for the term “vendor” and use cases. If “Vendor” is not defined by NERC, the guidance should prompt Entities to include their definition of “vendor” in their plan(s).

Guideline & Technical Basis for R2 should be included in this update. Supplemental materials may be out of date – see page 21 of 24 in the posted redline version. Include reference to FERC Order 829 for Parts 2.4 and 2.5

Consider adding a CIP Exceptional Circumstance clause to R2 Parts 2.4 and 2.5

 

Jesus Sammy Alcaraz, Imperial Irrigation District, 1, 6/15/2017

- 0 - 0

AZPS agrees with the inclusion of Parts 2.4 and 2.5 within CIP-005-6 R2; however, requests the statement “active vendor remote access sessions” be changed to “active vendor remote connection.”  A vendor may sustain an active remote connection for longer than an individual active remote access session.  Thus, a revision to the language would clarify the intent of this requirement, which is to monitor any time a vendor is connecting to and accessing sensitive cyber assets remotely.  Thus, AZPS encourages the SDT to consider this revision as it will better ensure that active remote connections by vendors are monitored and addressed.

- 0 - 0

Luminant, Segment(s) 6, 7, 5, 1/24/2017

- 0 - 0

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

- 0 - 0

FEUS supports the comments submitted by APPA

Linda Jacobson-Quinn, City of Farmington, 3, 6/15/2017

- 0 - 0

Scott Downey, 6/15/2017

- 0 - 0

ITC Holdings agrees with the below comment submitted by MRO’s NSRF:

The NSRF question the use of “…active vendor…” in part 2.4 and 2.5 Requirements.  The word “active” could mean either “the vendor is currently allowed electronic access and is currently within a BES Cyber Asset” OR “the vendor is idle and but has electronic access to a BES Cyber Asset”.  The NSRF recommends that “active” be removed as this will provide clarity to applicable entities.  If active sessions was the SDT thought process, please state that within the proposed part.

- 0 - 0

Please clarify definition of system-system communications

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

- 0 - 0

- 0 - 0

GRE requests that the SDT clarify in the requirements and GTB that applicable entities that do not allow Remote Access, do not have to create a process for Remote Access or terminating Remote Access.

Michael Brytowski, Great River Energy, 3, 6/15/2017

- 0 - 0

OPG suggest the term “vendor” be defined to exclude outsourcers that manage most aspects of a BES Cyber System. Normally they are contractually obligated to act in the Responsible Entities interests and fulfill or accommodate all compliance requirements. As such, this is a much closer relationship than is typically associated with the term “vendor”. Because in many such cases they would be principle maintainer or operator of said systems would often not technically feasible to disable the outsourcer’s access, remote or otherwise. 

Requirement 2.4 mentions ability to determine “sessions”, not just “access”. Requirement 2.5 is ambiguous on whether it requires the ability to disable “active sessions” as opposed to merely disabling “active accounts”. Suggest replacing “access” in R2.5 with either “sessions” or “accounts” depending on what was intended or otherwise elaborating. 

David Ramkalawan, 6/15/2017

- 0 - 0

Duke Energy requests additional clarity pertaining to the use of the term “active” in Requirement 2 Parts 2.4 and 2.5. As written, it could be interpreted that an entity would be required to monitor the remote access sessions of a vendor in real-time. Was this the drafting team’s intent with this language? If the drafting team’s intent was that an entity only be able to identify which vendor’s have remote access, we suggest revising the standard to more closely reflect said intent. If it is the drafting team’s intent that an entity must monitor in real-time the remote access of a vendor, additional guidance as to acceptable methods to achieve compliance with this intent is necessary.

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

- 0 - 0

Comments:

The definition of vendor is crucial to an entity defining and carrying out its compliance objectives for the requirements in question.

 

Definition of vendor is not a NERC defined term. The term “vendor” is also used in the proposed CIP-013.

 

Request more guidance for the term “vendor” and use cases. Guidance should prompt Entities to include their definition of “vendor” in their plan(s).

 

Guideline & Technical Basis for R2 should be included in this update. Supplemental materials may be out of date – see page 21 of 24 in the posted redline version. Include reference to FERC Order 829 for Parts 2.4 and 2.5

Consider adding a CIP Exceptional Circumstance clause to R2 Parts 2.4 and 2.5

Timothy Reyher, 6/15/2017

- 0 - 0

Recommend creating a CIP-005-6 and CIP-010-3 ‘Guidance document’ similar to the one for CIP-013-1.

Request that the narrative for the term 'Vendor' that is in the CIP-005-6 R2 Rationale box be added to the already Endorsed Guidance document for CIP-013-1 and to the Guidance documents for CIP-005-6 if it is created.

Request that a narrative for the term 'System-to-System’ be added to the already Endorsed Guidance document for CIP-013-1 and to the Guidance documents for CIP-005-6 if it is created.

Recommend removing CIP-013 R1 subparts 1.2.6 from CIP-013 since it is covered in the proposed CIP-005-6.

Guideline & Technical Basis for R2 should be included in this update. Supplemental materials may be out of date – see page 21 of 24 in the posted redline version. Include reference to FERC Order 829 for Parts 2.4 and 2.5

Consider adding a CIP Exceptional Circumstance clause to R2 Parts 2.4 and 2.5

Quintin Lee, Eversource Energy, 1, 6/15/2017

- 0 - 0

The requirement in CIP-005-5 6 Table R2.4 states that an entity must have one or more processes to determine active vendor session. We would recommend adding ‘Active and Passive’ to the requirement since the Measures point to passive initiation in having the vendor call or receive permission before their remote access is granted. Additional guidance on what is ‘Active’ and whether the monitoring session requires tracking the entire session or initiation of the session would provide more clarity to industry.

ACES Standards Collaborators, Segment(s) 1, 3, 4, 5, 6/15/2017

- 0 - 0

Texas RE agrees with the proposed requirements and has the following comments.

 

  • Question 2 above uses the term “machine-to-machine vendor remote access”. CIP-013-1 and CIP-005-6 use the term ““system-to-system remote access”.  Since these are two different terms, Texas RE recommends these terms be defined or examples provided to increase clarity and to avoid multiple interpretations.

  • Section 4.2.3.5 – The language, “Each Responsible Entity shall implement develop one or more documented supply chain cyber security risk management plan(s) for high and medium impact BES Cyber Systems.” is redundant with the requirement language.  Also, neither CIP-013-1 nor CIP-010-3 contain this language in the Exemptions section.

  • Page 1 Section 4.1.2.2 and Page 2 Section 4.2.1.2:  Texas RE noted the term “Special Protection System” was removed. Texas RE recommends removing this term in all CIP standards.

Rachel Coyne, Texas Reliability Entity, Inc., 10, 6/15/2017

- 0 - 0

Theresa Rakowsky, 6/15/2017

- 0 - 0

AECI supports NRECA's comments provided below:

NRECA requests that the SDT clarify in the requirements and GTB that applicable entities that do not allow Remote Access, do not have to create a process for Remote Access or terminating Remote Access.

AECI & Member G&Ts, Segment(s) 1, 6, 5, 3, 4/11/2017

- 0 - 0

The definition of vendor is crucial to an entity defining and carrying out its compliance objectives for the requirements in question.

 

Definition of vendor is not a NERC defined term. The term “vendor” is also used in the proposed CIP-013.

 

Request more guidance for the term “vendor” and use cases. Guidance should prompt Entities to include their definition of “vendor” in their plan(s).

 

Guideline & Technical Basis for R2 should be included in this update. Supplemental materials may be out of date – see page 21 of 24 in the posted redline version. Include reference to FERC Order 829 for Parts 2.4 and 2.5

Consider adding a CIP Exceptional Circumstance clause to R2 Parts 2.4 and 2.5

RSC no Dominion, Segment(s) 1, 0, 2, 4, 5, 6, 7, 3, 6/15/2017

- 1 - 0

GTC supports NRECA comments:

 

NRECA requests that the SDT clarify in the requirements and GTB that applicable entities that do not allow Remote Access, do not have to create a process for Remote Access or terminating Remote Access.

Jason Snodgrass, 6/15/2017

- 0 - 0

It remains unclear to us as to what the phrase “system-to-system” is meant to include. Please define or provide examples of what would be considered vendor “system-to-system” remote access. 

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

- 0 - 0

The IRC agree with the new CIP-005-6 Requirement R2 Parts 2.4 and 2.5 however we note there is no corresponding “Guidance and Technical Basis” or “Rationale”. We also suggest that guidance be drafted to help entities understand what is intended by the term “Vendor” in relation to parts 2.4 and 2.5. 

Regarding Part 2.4, the IRC is concerned that the meaning of “determining” in the phrase “have one or more methods for determining active vendor remote access sessions” is unclear.  If the SDT’s intent is to require identification of instances of active vendor remote access, the IRC suggests rewording to “have one or more methods of identifying instances of active vendor remote access (including Interactive Remote Access and system-to-system remote access).”

SRC + SWG , Segment(s) 2, 3, 1, 0, 6/15/2017

- 0 - 0

Victor Garzon, 6/15/2017

- 0 - 0

Pablo Onate, El Paso Electric Company, 1, 6/15/2017

- 0 - 0

Rhonda Bryant, El Paso Electric Company, 3, 6/15/2017

- 0 - 0

There needs to be a clear explanation of “machine-to-machine” and “system-to-system” remote access in the Guidelines & Technical Basis to provide the necessary understanding and scoping of these concepts for industry.

For example – “Machine-to-machine” or “system-to-system” remote access would include a logical connection between a High or Medium Impact BES Cyber System or it’s associated PCAs into or out of the associated ESP with a vendor-maintained Cyber Asset, and that connection does not have an interactive user access capability.

Additionally, under the Measures of R2.4, the statement of examples needs to have “such as” following “(including Interactive Remote Access and system-to-system remote access), such as:” to make it clearer that the below bulleted items are options an entity may choose from, and to be consistent with the formatting of R2.5.

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

- 0 - 0

Glen Farmer, Avista - Avista Corporation, 5, 6/15/2017

- 0 - 0

Oxy, Segment(s) 7, 5, 9/6/2016

- 0 - 0

Please clarify definition of system-system communications.

Teresa Krabe, Lower Colorado River Authority, 5, 6/15/2017

- 0 - 0

See comments in attached file

William Harris, Foundation for Resilient Societies, 8, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

John Martinsen, Public Utility District No. 1 of Snohomish County, 4, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Long Duong, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Mark Oens, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Sam Nietfeld, Public Utility District No. 1 of Snohomish County, 5, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Franklin Lu, 6/15/2017

- 0 - 0

ERCOT joins the comments of the IRC and offers the following additional comments:

 

Regarding Part 2.4, ERCOT is concerned that the meaning of “determining” in the phrase “have one or more methods for determining active vendor remote access sessions” is unclear. If the SDT’s intent is to require identification of instances of active vendor remote access, ERCOT suggests rewording to “have one or more methods of identifying instances of active vendor remote access (including Interactive Remote Access and system-to-system remote access).”

ERCOT also requests clarification on the meaning of “system-to-system remote access.”  Interpreted broadly, this requirement could mean all ingress/egress network connections to the security zone. Identifying each instance of connection could become extremely burdensome, without providing any meaningful reliability benefit. 

ERCOT recommends that the meaning of system-to-system remote access be qualified as vendor remote access which can do harm to the BES Cyber System (BCS) and recommends the following language:

“Have one or more methods for determining active vendor remote access sessions (including Interactive Remote Access and system-to-system remote access).  This is limited to sessions which have the ability to harm the BCS.”

If the SDT declines to adopt this language, the SDT should consider defining “system-to-system remote access” or further clarifying the meaning of this term in the “Guideline and Technical Basis” section or in the Implementation Guidance.

Elizabeth Axson, 6/15/2017

- 0 - 0

Hot Answers

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

Richard Vine, 6/15/2017

- 0 - 0

- 0 - 0

Other Answers

Randy Buswell, 5/31/2017

- 0 - 0

Bill Watson, On Behalf of: Bill Watson, , Segments 3

- 0 - 0

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

- 0 - 0

Sandra Pacheco, On Behalf of: Silicon Valley Power - City of Santa Clara, , Segments 3, 5

- 0 - 0

Val Ridad, On Behalf of: Silicon Valley Power - City of Santa Clara, , Segments 3, 5

- 0 - 0

We request clarification on the timing of requirement 1.6; specifically, on whether 1.6 must be completed before being placed in operation on a BES Cyber System.  This distinction was made in the previous draft (“one or more documented process(es) for verifying the integrity and authenticity of the following software and firmware before being placed in operation on high and medium impact BES Cyber Systems”).  Under the current language, it appears sub-requirement 1.6 could be done before or after the software is placed on a BES Cyber System.  We suggest the SDT add a timeframe similar to the other CIP-010 R1 sub-requirements.  For example, 1.3 states “within 30 days” while 1.4.1 states “prior to the change”.  Additionally, we request adding 1.1.3 (any custom software installed) to 1.6, as custom software could be internally or externally provided, and needs to be verified for integrity and authenticity.

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

- 0 - 0

Illinois Municipal Electric Agency supports comments submitted by the American Public Power Association.

Bob Thomas, 6/9/2017

- 0 - 0

CHPD believes the R1.6 “Note:” within the Applicable Systems section (shown below) must be removed to be consistent with the CHPD response to question 1; “CHPD has concerns about language related to procurement contracts, in particular use of master agreements, piggyback agreements, and evergreen agreements. To address these concerns and position CIP-013 as a performance based Standard, CHPD recommends that all references to “contracts” and most references to “procurement” be struck from CIP-013.”

CIP-010 R1.6 – Applicable System Note

“Note: Implementation does not require the Responsible Entity to renegotiate or abrogate existing contracts (including amendments to master agreements and purchase orders). Additionally, the following issues are beyond the scope of Part 1.6: (1) the actual terms and conditions of a procurement contract; and (2) vendor performance and adherence to a contract.”

Haley Sousa, 6/9/2017

- 0 - 0

CHPD believes the R1.6 “Note:” within the Applicable Systems section (shown below) must be removed to be consistent with the CHPD response to question 1; “CHPD has concerns about language related to procurement contracts, in particular use of master agreements, piggyback agreements, and evergreen agreements. To address these concerns and position CIP-013 as a performance based Standard, CHPD recommends that all references to “contracts” and most references to “procurement” be struck from CIP-013.”

CIP-010 R1.6 – Applicable System Note

“Note: Implementation does not require the Responsible Entity to renegotiate or abrogate existing contracts (including amendments to master agreements and purchase orders). Additionally, the following issues are beyond the scope of Part 1.6: (1) the actual terms and conditions of a procurement contract; and (2) vendor performance and adherence to a contract.”

Janis Weddle, 6/9/2017

- 0 - 0

No issues from an SCRM perspective. Part 1.6 is generic and can be considered a good idea for all changes from baseline configurations described in Parts 1.1.1, 1.1.2, and 1.1.5.

Steven Rueckert, Western Electricity Coordinating Council, 10, 6/9/2017

- 0 - 0

CHPD believes the R1.6 “Note:” within the Applicable Systems section (shown below) must be removed to be consistent with the CHPD response to question 1; “CHPD has concerns about language related to procurement contracts, in particular use of master agreements, piggyback agreements, and evergreen agreements. To address these concerns and position CIP-013 as a performance based Standard, CHPD recommends that all references to “contracts” and most references to “procurement” be struck from CIP-013.”

 

CIP-010 R1.6 – Applicable System Note

“Note: Implementation does not require the Responsible Entity to renegotiate or abrogate existing contracts (including amendments to master agreements and purchase orders). Additionally, the following issues are beyond the scope of Part 1.6: (1) the actual terms and conditions of a procurement contract; and (2) vendor performance and adherence to a contract.”

Chad Bowman, 6/9/2017

- 0 - 0

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

- 0 - 0

CHPD believes the R1.6 “Note:” within the Applicable Systems section (shown below) must be removed to be consistent with the CHPD response to question 1; “CHPD has concerns about language related to procurement contracts, in particular use of master agreements, piggyback agreements, and evergreen agreements. To address these concerns and position CIP-013 as a performance based Standard, CHPD recommends that all references to “contracts” and most references to “procurement” be struck from CIP-013.”

CIP-010 R1.6 – Applicable System Note

“Note: Implementation does not require the Responsible Entity to renegotiate or abrogate existing contracts (including amendments to master agreements and purchase orders). Additionally, the following issues are beyond the scope of Part 1.6: (1) the actual terms and conditions of a procurement contract; and (2) vendor performance and adherence to a contract.”

Mick Neshem, 6/12/2017

- 0 - 0

Colorado Springs Utilities supports the comments provided by APPA

Jeff Icke, Colorado Springs Utilities, 5, 6/12/2017

- 0 - 0

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

- 0 - 0

The language should make clear that verification is required for the software intake process, but not for each subsequent installation.

We suggest rephrasing “when the method to do so is available to the Responsible Entity from the software source” to “when the vendor supplied method to do so is available to Responsible Entity”. Otherwise the “method to do so” is ambiguous and leaves the following questions:

- How does one prove that a method is not available?
- What is the line between available/unavailable? How far do you have to go?

We are concerned with double jeopardy potential with CIP-007 R2. We feel that if it is impossible to validate the source or verify authenticity of the patch itself we would not consider that patch to be available.

Daniel Grinkevich, 6/12/2017

- 0 - 0

Patrick Hughes, On Behalf of: National Electrical Manufacturers Association, NA - Not Applicable, Segments NA - Not Applicable

- 0 - 0

Need clarification about how the addition of R1.6 applies only to BES Cyber Systems that are newly implemented and thus did not previously have a baseline and as such do not have an existing baseline to deviate from.  Please clarify that this is for new BES Cyber Systems to avoid confusion and challenges during an aduit.

Need some additional examples of what constitutes evidence to meet compliance to this standard.  Some systems are not connected to the internet purposefully and as such patches are installed utilizing a CD/DVD provided by the vendor.  What would constitute appropriate evidence for a case such as this?

This requirement is not clear whether an entity has to duplicate efforts for every case for which such verification has to be undertaken (i.e. the cases of multiple installations of a given piece of software across many similar applicable Cyber Assets).  This does not seem consistent with the intent of the protection and could present an undue compliance burden without providing the intended protection. Request guidance on using trusted internal repositories as a software source so that an entity can verify once and apply to many assets.

Shawn Abrams, 6/13/2017

- 0 - 0

Need to emphasize the phrase “and when the method to do so is available to the Responsible Entity for the software source”. Since this is a non-prescriptive requirement it is expected that we will be demonstrating compliance by implementing the plan(s) required in CIP-013. Since it may not be possible to hold the software resource directly responsible it is expected that the demonstration of “best effort” will be sufficient and not subject to interpretation by the Compliance Enforcement Authority.

 

Recommend providing more examples of suitable evidence that should be gathered to verify identity and integrity.  The Measure as currently written is too vague.

Steven Sconce, On Behalf of: EDF Renewable Energy, , Segments 5

- 0 - 0

- 0 - 0

 

Since the intent of CIP-010-3 R1.6 is a proactive verification of software integrity, R1.6 should focus on a single verification prior to introducing vendor software into the production environment.  The current language of R1.6 utilizes a retroactive focus via baseline deviations.  Please see the suggested wording - “Prior to introducing software not resident in baseline items (per 1.1.1, 1.1.2, and 1.1.5), and when the method to do so is available to the Responsible Entity from the software source:

 

1.6.1. Verify the identity of the software source; and

 

1.6.2. Verify the integrity of the software obtained from the software source.”

 

Thomas Foltz, AEP, 5, 6/13/2017

- 0 - 0

Proposed Requirement R1 Part 1.6 appears to require verification of identity and integrity of applicable changes to the baseline.  However, the measure for this requirement gives an example of having a process, e.g., a change request record, instead of a specific example of verification.  Can the team clarify the measure for this Requirement as an entity can have a change ticket process that merely requires the user to click a button that states that the software has been verified, however, if the team believes proof of such check, such as a screenshot of the vendor site, is required, please state such as an example.

Additionally, the example of evidence does not demonstrate how a software source or the software integrity is verified.  An internal change ticket is not a verification of the software source.  If they are going to push for source verification then modify CIP-007 R2.1 to include it.  Specifically, what is expected as evidence -- a hash, screenshot, attestation, digital signature?

Michael Haff, On Behalf of: Seminole Electric Cooperative, Inc., FRCC, Segments 1, 3, 4, 5, 6

- 0 - 0

We support APPA's submitted comments, including:

 

This requirement would possibly involve entitites duplicating effort for every case for which such verification had to be undertaken.

More examples of evidence should be provided.

Clarification is needed about how new R1.6 applies to entirely new BES Cyber Systems.

Allan Long, Memphis Light, Gas and Water Division, 1, 6/13/2017

- 0 - 0

Even though ReliabilityFirst believes the changes to CIP-010-3 draft standard address directives from Federal Energy Regulatory Commission (FERC) Order No. 829 and is a positive step in addressing cyber supply chain management, ReliabilityFirst Abstains mainly due to Requirement R1 missing Electronic Access Control or Monitoring Systems (EACMS), Physical Access Control Systems (PACS), and Protected Cyber Assets (PCAs).  ReliabilityFirst offers the following specific comments for consideration. 

  1. Requirement R1 Part 1.6

    1. ReliabilityFirst believes the “Applicable Systems” under Requirement R1 Part 1.6 should be consistent with “Applicable Systems” under parts 1.1, since sub-parts (Part 1.1.1, 1.1.2, & 1.1.5) are called out under the “Requirements” section for Part 1.6.  EACMs and PACS are critical cyber assets that control access and monitoring into the entities’ ESPs and PSPs and should follow the Supply Chain standard/requirements as do the High and Medium Impact Cyber Systems.  As for the PCAs, if they are compromised due to a vulnerability in the vendors supplied hardware or software, they can possibly affect high and medium impact BES Cyber Systems.  ReliabilityFirst offers the following modifications for consideration for the “Applicable Systems” column in Requirement R1 Part 1.6:

      1. High Impact BES Cyber Systems and their associated: 1. EACMS; 2. PACS; and 3. PCA

      2. Medium Impact BES Cyber Systems and their associated: 1. EACMS; 2. PACS; and 3. PCA

  1. Requirement R1 Part 1.6.3 (new sub-part)

    1. ReliabilityFirst believes a new sub-part 1.6.3 should be added to address the verification of the baseline configuration.  ReliabilityFirst offers the following new sub-part 1.6.3 for consideration:

      1. Verify the deviations from the baseline configuration.

Anthony Jablonski, ReliabilityFirst , 10, 6/13/2017

- 0 - 0

PRPA agrees this requirement belongs in CIP-010 R1. PRPA generally agrees with Proposed R1 Part 1.6, but request the following items be addressed by the SDT:

  • PRPA recommends the Guidelines and Technical Basis section is updated to reflect current information.

    • The requirement states “For a change that deviates from the existing baseline configuration associated with baseline items in Parts 1.1.1, 1.1.2, and 1.1.5…,” indicating the authenticity and integrity of the specified parts need to be verified each time there is a change to a baseline for those parts. The proposed requirement would possibly involve entities duplicating effort for every case for which such verification had to be undertaken (i.e., in the cases of multiple installations of software across many applicable Cyber Assets).  This does not seem consistent with the intent of the protection and could present an undue compliance burden without providing the intended protection. We believe that the existing statement in the GTB provides clarity on this issue and request that it not be removed.  From the GTB: “It is not the intent of the SDT to require a verification of each source or software update at the time it is obtained. It is sufficient to establish the reliable source and software update once. This will allow automated solutions to be implemented to obtain frequent updates such as patches.”

    • PRPA also recommends the language of the requirement be re-worded to reflect the intent of the GTB, as an auditor audits to the requirement, not the GTB. Doing a verification of authenticity and integrity for each change to the baseline for the specified parts would be tedious and require entities to acquire additional resources to perform the work.

  • There is no guidance on how to verify the identity (authenticity). Performing this verification could be difficult if the software/patch comes from a third party tool. Guidance on how this can be done needs to be made available to entities in order to perform an evaluation of the work and resources involved to achieve this requirement. Hashing was given as an example during an industry webinar, but this is not realistic for each type of system.

  • Additional examples of acceptable measures should to be listed. Additionally, PRPA requests examples of acceptable evidence when there is not a method available to verify the identity of the software source.

  • While PRPA supports these changes, clarification is required about how new R1.6 applies to entirely new BES Cyber Systems (BCS), i.e., BCS that are newly implemented, have not previously had a baseline, and thus do not have an existing baseline for a change to deviate from. We expect that R1.6 is intended to apply to new BCS as well as to existing BCS, but as written the requirement does not. Please clarify to avoid implementation confusion and audit challenges.

Tyson Archie, Platte River Power Authority, 5, 6/14/2017

- 0 - 0

The Guidelines and Technical Basis of CIP-010-3 states:  “It is not the intent of the SDT to require a verification of each source or software update at the time it is obtained. It is sufficient to establish the reliable source and software update once.  This will allow automated solutions to be implemented to obtain frequent updates such as patches.” 

CenterPoint Energy recommends incorporating this concept in the R2 requirement language in order to clarify that integrity and authenticity do not need to be verified for every source or software update, and that the download once and install on many approach is acceptable if the integrity and authenticity of the downloaded software are validated.  CenterPoint Energy recommends adding the following language to Requirement R2:

Upon validation of the integrity and authenticity of software, a Responsible Entity does not need to verify the integrity and authenticity for subsequent updates of such software.

Amelia Sawyer Anderson, On Behalf of: CenterPoint Energy Houston Electric, LLC, Texas RE, Segments 1

- 0 - 0

- 0 - 0

W. Dwayne Preston, Austin Energy, 3, 6/14/2017

- 0 - 0

Lauren Price, 6/14/2017

- 0 - 0

 

SMUD agrees this requirement belongs in CIP-010 R1. SMUD generally agrees with Proposed R1 Part 1.6, but request the following items be addressed by the SDT:

 

  • SMUD recommends the Guidelines and Technical Basis section is updated to reflect current information.

      • The requirement states “For a change that deviates from the existing baseline configuration associated with baseline items in Parts 1.1.1, 1.1.2, and 1.1.5…,” indicating the authenticity and integrity of the specified parts need to be verified each time there is a change to a baseline for those parts. The proposed requirement would possibly involve entities duplicating effort for every case for which such verification had to be undertaken (i.e., in the cases of multiple installations of software across many applicable Cyber Assets).  This does not seem consistent with the intent of the protection and could present an undue compliance burden without providing the intended protection. We believe that the existing statement in the GTB provides clarity on this issue and request that it not be removed.  From the GTB: “It is not the intent of the SDT to require a verification of each source or software update at the time it is obtained. It is sufficient to establish the reliable source and software update once. This will allow automated solutions to be implemented to obtain frequent updates such as patches.”

      • SMUD also recommends the language of the requirement be re-worded to reflect the intent of the GTB, as an auditor audits to the requirement, not the GTB. Doing a verification of authenticity and integrity for each change to the baseline for the specified parts would be tedious and require entities to acquire additional resources to perform the work.

    • There is no guidance on how to verify the identity (authenticity). Performing this verification could be difficult if the software/patch comes from a third party tool. Guidance on how this can be done needs to be made available to entities in order to perform an evaluation of the work and resources involved to achieve this requirement. Hashing was given as an example during an industry webinar, but this is not realistic for each type of system.

    • Additional examples of acceptable measures should to be listed. Additionally, SMUD requests examples of acceptable evidence when there is not a method available to verify the identity of the software source.

     

    • While SMUD supports these changes, clarification is required about how new R1.6 applies to entirely new BES Cyber Systems (BCS), i.e., BCS that are newly implemented, have not previously had a baseline, and thus do not have an existing baseline for a change to deviate from. We expect that R1.6 is intended to apply to new BCS as well as to existing BCS, but as written the requirement does not. Please clarify to avoid implementation confusion and audit challenges.

     

     

     

  •  

 

- 0 - 0

AE agrees this requirement belongs in CIP-010 R1 and generally agrees with Proposed R1 Part 1.6, but request the SDT address the following items:

AE recommends the Guidelines and Technical Basis section be updated to reflect current information.

The requirement states “For a change that deviates from the existing baseline configuration associated with baseline items in Parts 1.1.1, 1.1.2, and 1.1.5…,” indicating the authenticity and integrity of the specified parts must be verified each time a baseline changes for those parts. The proposed requirement would possibly involve entities duplicating effort for every case for which such verification had to occur (e.g., in the cases of multiple installations of software across many applicable Cyber Assets).  This requirement does not seem consistent with the intent of the protection and could present an undue compliance burden without providing the intended protection. We believe the existing statement in the GTB provides clarity on this issue and request it not be removed.  From the GTB: “It is not the intent of the SDT to require a verification of each source or software update at the time it is obtained. It is sufficient to establish the reliable source and software update once. This will allow automated solutions to be implemented to obtain frequent updates such as patches.”

o   AE also recommends rewording the language of the requirement be re-worded to reflect the intent of the GTB, as an auditor audits to the requirement, not the GTB. Doing a verification of authenticity and integrity for each change to the baseline for the specified parts would be tedious and require entities to acquire additional resources to perform the work.

o   There is no guidance on how to verify the identity (authenticity). Performing this verification could be difficult if the software/patch comes from a third party tool. Guidance on how this can be done needs to be made available in order to perform an evaluation of the work and resources involved to achieve this requirement. Hashing was given as an example during an industry webinar, but this is not realistic for each type of system.

o   Additional examples of acceptable measures should to be listed. Additionally, AE requests examples of acceptable evidence when there is no method available to verify the identity of the software source.

While AE supports these changes, clarification is required about how R1.6 applies to entirely new BES Cyber Systems (BCS), i.e., BCS newly implemented and which have no previous baseline, and thus do not have an existing baseline from which a change can occur.  We expect R1.6 is intended to apply to new BCS as well as to existing BCS but, as written, the requirement does not. Please clarify to avoid implementation confusion and audit challenges.

Andrew Gallo, 6/14/2017

- 0 - 0

BC Hydro does not agree with value-add of this standard requirement.  Under current CIP requirements, CIP controls around testing of changes and ongoing monitoring of systems would mitigate any risk associated with software identity or integrity.

BC Hydro, Segment(s) 1, 2, 3, 5, 5/6/2015

- 0 - 0

Ther is nothing wrong with the concept of the requiment however the language of the requirement is not supportable. The term available could me technically available, procedurally available, contracturaly available, freely available (no support purchase required). As written this requirement by its nature will be implemented and assessed drastically differently by different Responsible Entities. One could argue that only if all the available methods listed above exist in unison is software actually available.

Richard Kinas, 6/14/2017

- 0 - 0

See attached comments

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

2016-03_Unofficial_Comment_Form_SCL_2017-6-14 Final to NERC.docx

- 0 - 0

Request to defined the scope of the requirements “for new contracts only”

With no defined scope, if the standard become effective in same time of the standard CIP-013-1, no terms will existed beetween entities and vendor for effective contracts. How the entities will be conformed to requirements ?

The proposed requirement would possibly involve entities duplicating effort for every case for which such verification had to be undertaken (i.e. the cases of multiple installations of a given piece of software across many similar applicable Cyber Assets).  This does not seem consistent with the intent of the protection and could present an undue compliance burden without providing the intended protection.

VSL does not cover the failure to implement the process.  Does not include all of the combinations.

Concerns with 1.6.1 and 1.6.2 as written --- how to provide evidence?  Request more examples of evidence.

Normande Bouffard, 6/14/2017

- 0 - 0

Entergy/NERC Compliance, Segment(s) 1, 5, 3/1/2017

- 0 - 0

Theresa Allard, Minnkota Power Cooperative Inc., 1, 6/14/2017

- 0 - 0

SRP agrees this requirement belongs in CIP-010 R1. SRP generally agrees with Proposed R1 Part 1.6, but request the following items be addressed by the SDT:

  • SRP recommends the Guidelines and Technical Basis section is updated to reflect current information.

    • The requirement states “For a change that deviates from the existing baseline configuration associated with baseline items in Parts 1.1.1, 1.1.2, and 1.1.5…,” indicating the authenticity and integrity of the specified parts need to be verified each time there is a change to a baseline for those parts. The proposed requirement would possibly involve entities duplicating effort for every case for which such verification had to be undertaken (i.e., in the cases of multiple installations of software across many applicable Cyber Assets).  This does not seem consistent with the intent of the protection and could present an undue compliance burden without providing the intended protection. We believe that the existing statement in the GTB provides clarity on this issue and request that it not be removed.  From the GTB: “It is not the intent of the SDT to require a verification of each source or software update at the time it is obtained. It is sufficient to establish the reliable source and software update once. This will allow automated solutions to be implemented to obtain frequent updates such as patches.”
    • SRP also recommends the language of the requirement be re-worded to reflect the intent of the GTB, as an auditor audits to the requirement, not the GTB. Doing a verification of authenticity and integrity for each change to the baseline for the specified parts would be tedious and require entities to acquire additional resources to perform the work.

  • There is no guidance on how to verify the identity (authenticity). Performing this verification could be difficult if the software/patch comes from a third party tool. Guidance on how this can be done needs to be made available to entities in order to perform an evaluation of the work and resources involved to achieve this requirement. Hashing was given as an example during an industry webinar, but this is not realistic for each type of system.

  • Additional examples of acceptable measures should to be listed. Additionally, SRP requests examples of acceptable evidence when there is not a method available to verify the identity of the software source.

  • While SRP supports these changes, clarification is required about how new R1.6 applies to entirely new BES Cyber Systems (BCS), i.e., BCS that are newly implemented, have not previously had a baseline, and thus do not have an existing baseline for a change to deviate from. We expect that R1.6 is intended to apply to new BCS as well as to existing BCS, but as written the requirement does not. Please clarify to avoid implementation confusion and audit challenges.

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

- 0 - 0

Alex Ybarra, 6/14/2017

- 0 - 0

Wendy Center, U.S. Bureau of Reclamation, 5, 6/14/2017

- 0 - 0

There are auditing challenges around the phrase “when the method to do so is available to the Responsible Entity from the software source” as it is hard to prove a negative. Oncor believes that verification of software source and integrity can take many forms. To take into consideration legacy software, Oncor believes the wording should be adjusted, to reflect FERC intentions that the requirements are forward looking, by replacing the phrase “and when the method to do so is available to the Responsible Entity from the software source”  with “and, at a minimum, for the portion of the software that has changed:”

 

Second, the proposed requirement would possibly involve entities duplicating effort for every case for which such verification had to be undertaken (i.e. the cases of multiple installations of a given piece of software across many similar applicable Cyber Assets).  We offer a recommendation on the language, “Document and implement a software source management process to address source identity verification and media integrity controls on the software repository used for changes that deviate from the existing baseline configuration associated with items in parts 1.1.1, 1.1.2, and 1.1.5.”  

This process must include steps:

•             To verify the identity of the software source when the method to do so is available; and

•             To verify the integrity of the software obtained when the method to do so is available.

Evidence may include verification of identity of the software source and integrity of the software was performed for repository updates.”

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

- 0 - 0

Andrew Meyers, Bonneville Power Administration, 6, 6/14/2017

- 0 - 0

- 0 - 0

No Comments

Alan Farmer, On Behalf of: ACEC, FRCC, MRO, WECC, Texas RE, NPCC, SERC, SPP RE, RF, Segments NA - Not Applicable

- 0 - 0

NRECA supports the revisions to CIP-010-2.  However, in the GTB the SDT should clarify the meaning of this sentence: “For example, in the System and Information Integrity (SI) control family, control SI-7 suggests that the integrity of information systems and obtaining software directly from the developer.”  This sentence seems to be incomplete and further words are needed to complete it.

Barry Lawson, 6/14/2017

- 0 - 0

John Williams, 6/15/2017

- 1 - 0

N&ST believes the “if you can, you must” qualifying language in this proposed requirement part should be added to at least some parts of CIP-013 R1 and R2.   

Nicholas Lauriat, Network and Security Technologies, 1, 6/15/2017

- 0 - 0

Melanie Seader, On Behalf of: Edison Electric Institute, NA - Not Applicable, Segments NA - Not Applicable

- 0 - 0

NYPA supports the comments submitted by Salt River Project (WECC) and NPCC.

David Rivera, New York Power Authority, 3, 6/15/2017

- 0 - 0

The NSRF has the same comment from CIP-013-1 R1:  CIP-010-3 R1.6 is troublesome as well.  Entities typically use update or proxy servers to discover and identify applicable security patches.  For example, we use Windows Update Server Services to identify patches and roll them out once testing and approvals are complete.  Do we need to check the check sums of the identified patches or can we trust that the update servers are authenticating the software?

 

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

- 0 - 0

NPPD supports the comments of the MRO NSRF, in addition:

Auditors will have too much discretion as to what is or is not enough for a validation check of each vendor, which will lead to inconsistencies across the NERC RE footprint.  It is up to entities to document what the vendor is willing to do and hope the auditors agree it is enough to continue doing business with the vendor.  Also, the language of the requirement says “…when the method to do so is available…”.  If a vendor does not have a method to do so, but does in the next year or so, the entity may have a possible violation if it did not realize there was a change in the vendor’s available methods.  This would force entities to periodically check to see if the vendor capabilities have changed.  What is the period that would not make this a violation?  The requirement is very vague.

Don Schmit, 6/15/2017

- 0 - 0

Daniel Gacek, Exelon, 1, 6/15/2017

- 0 - 0

The proposed requirement would possibly involve entities duplicating effort for every case for which such verification had to be undertaken (i.e., in the cases of multiple installations  of software across many applicable Cyber Assets).  This does not seem consistent with the intent of the protection and could present an undue compliance burden without providing the intended protection. We believe that the existing statement in the GTB provides clarity on this issue and request that it not be removed.  From the GTB: “It is not the intent of the SDT to require a verification of each source or software update at the time it is obtained. It is sufficient to establish the reliable source and software update once. This will allow automated solutions to be implemented to obtain frequent updates such as patches.”

USI has concerns with R 1.6.1 and 1.6.2 as written about how to provide evidence? Therefore, we believe more  examples of evidence should be provided.

While we support these changes,  clarification is required about how new R1.6 applies to entirely new BES Cyber Systems (BCS), i.e., BCS that are newly implemented, have not previously had a baseline, and thus do not have an existing baseline for a change to deviate from. We expect that R1.6 is intended to apply to new BCS as well as to existing BCS, but as written the requirement does not. Please clarify to avoid implementation confusion and audit challenges.

Brian Evans-Mongeon, Utility Services, Inc., 4, 6/15/2017

- 1 - 0

GSOC supports NRECA's Comments of:

NRECA supports the revisions to CIP-010-2.  However, in the GTB the SDT should clarify the meaning of this sentence: “For example, in the System and Information Integrity (SI) control family, control SI-7 suggests that the integrity of information systems and obtaining software directly from the developer.”  This sentence seems to be incomplete and further words are needed to complete it.

Guy Andrews, 6/15/2017

- 0 - 0

R1.6 brings to mind several challenges.  The intent appears to be to ensure that software is validated, which is not the issue.  The issue is the auditability of the requirement and its existing language.  The wording “when the method to do so is available” puts additional obligations on the Responsible Entity to prove whether the methods were available or not, when the methods were available, if it was appropriate to utilize the available methods in a given circumstance.  It adds additional nuance when the methods are often obtained from third parties.  If it is a legacy contract and has not been updated and the method is available to other entities but not to the Responsible Entity due to the legacy contract, is the method considered available?  The intent of this requirement is good but the auditability of the language is challenging at best and should be adjusted to consider how entities will be able to document and comply with the requirement language.

Laura Nelson, 6/15/2017

- 0 - 0

  • Please provide clarification to what, “verification of identity of the software source and integrity of the software” means. Please provide more examples within the Measures to ensure entities are prepared for compliance oversight expectations.

Heather Morgan, EDP Renewables North America LLC, 5, 6/15/2017

- 0 - 0

MMWEC supports comments submitted by APPA.

David Gordon, 6/15/2017

- 0 - 0

MEAG supports the answers and comments of Salt River Project.

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

- 0 - 0

SPP recommends that the drafting team provide examples to provide clarity on control design to meet the intent of the standard.

SPP Standards Review Group, Segment(s) 0, 6/15/2017

- 0 - 0

NRG recommends that the drafting team provide examples to provide clarity on control design to meet the intent of the standard.

 

The proposed requirement would possibly involve entities duplicating effort for every case for which such verification had to be undertaken (i.e. the cases of multiple installations of a given piece of software across many similar applicable Cyber Assets).  This does not seem consistent with the intent of the protection and could present an undue compliance burden without providing the intended protection. NRG requests guidance on using trusted internal repositories as a software source so that Entity can verify once and use many

 

The VSL as currently written may not cover the failure to implement the process. The VSL may not include all of the combinations.

 

NRG has concerns with Parts: 1.6.1 and 1.6.2 as written --- For example, how would a Registered Entity be expected to provide evidence? NRG request additional examples of evidence in the Measures section of the requirement.

 

NRG suggests rephrasing “when the method to do so is available to the Responsible Entity from the software source” to “when the vendor supplied method to do so is available to Responsible Entity”. Otherwise the “method to do so” may be ambiguous and leaving the following questions:

 

How does one prove that a method is not available?

What is the line between available/unavailable? How far do you have to go?

 

NRG is concerned with double jeopardy potential with CIP-007 R2. NRG is concerned that it may be difficult or impossible to validate the source or verify authenticity of the patch itself which may cause the industry to not consider that patch to be available.

Kara White, On Behalf of: NRG - NRG Energy, Inc., FRCC, MRO, WECC, Texas RE, NPCC, SERC, SPP RE, RF, Segments 3, 4, 5, 6

- 0 - 0

LeRoy Patterson, Public Utility District No. 2 of Grant County, Washington, 6, 6/15/2017

- 0 - 0

As currently written, “verify the identity” is too vague. PJM suggests adding examples of “identify” into the measure.  PJM also suggests removing the word “software” from 1.6.1 and 1.6.2 as it is already stated within parts 1.1.1, 1.1.2 and 1.1.5 (firmware should be within the scope of 1.6).

Mark Holman, 6/15/2017

- 0 - 0

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

- 0 - 0

The proposed requirement would possibly involve entities duplicating effort for every case for which such verification had to be undertaken (i.e. the cases of multiple installations of a given piece of software across many similar applicable Cyber Assets).  This does not seem consistent with the intent of the protection and could present an undue compliance burden without providing the intended protection. Request guidance on using trusted internal repositories as a software source so that Entity can verify once and use many.

Concerns with 1.6.1 and 1.6.2 as written --- how to provide evidence? Request more examples of evidence.

We support these changes, but requests clarification about how new R1.6 applies to entirely new BES Cyber Systems (BCS), i.e., BCS that are newly implemented, have not previously had a baseline, and thus do not have an existing baseline for a change to deviate from. We expect that R1.6 is intended to apply to new BCS as well as to existing BCS, but as written the requirement does not. Please clarify to avoid implementation confusion and audit challenges.

Jesus Sammy Alcaraz, Imperial Irrigation District, 1, 6/15/2017

- 0 - 0

To ensure that resources are appropriately focused on changes to be applied, AZPS recommends clarifying that verification should be completed “prior to application of a change.”   Such a clarification will signal to entities that verification only needs to be performed where a change will be applied and avoid circumstances where a change is being evaluated for application and verification occurs, but the change is not applied.  Under the current obligation, it is likely that verifications and associated evidence would be prepared regardless of whether the change is or is not applied and would therefore result in the dedication of resources to efforts that would have no benefit to reliability or security. 

Additionally, AZPS requests clarification regarding the continued need for verification evidence where such is not available from the vendor.  Specifically, AZPS notes that, where a vendor’s policy does not provide the necessary evidence associated with verification, this Requirement may frequently represent null evidence for areas where items are reviewed each time a change occurs, but no data is available due to the vendor’s policies.  Such efforts would be redundant and of little or no value to security and reliability.

- 0 - 0

Add language to address CIP Exceptional Circumstances.

Luminant, Segment(s) 6, 7, 5, 1/24/2017

- 0 - 0

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

- 0 - 0

FEUS supports the comments submitted by APPA

Linda Jacobson-Quinn, City of Farmington, 3, 6/15/2017

- 0 - 0

Scott Downey, 6/15/2017

- 0 - 0

ITC Holdings believes the wording of CIP-010-3 leaves a lot of room for interpretation and needs to be more prescriptive. The measures should define technical examples (e.g., denote MD5 fingerprint or hashing as being an acceptable method). Additionally, ITC recommends including Remedy in the Technical Guidance document if you can’t use the file integrity method.

- 0 - 0

Disagree with the revisions on CIP-010-3, would like to see guideline language of verifying once be moved to the requirement/measure

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

- 0 - 0

Need additional information regarding how to verify integrity of software.

- 0 - 0

GRE and NRECA supports the revisions to CIP-010-2.  However, in the GTB the SDT should clarify the meaning of this sentence: “For example, in the System and Information Integrity (SI) control family, control SI-7 suggests that the integrity of information systems and obtaining software directly from the developer.”  This sentence seems to be incomplete and further words are needed to complete it.

Michael Brytowski, Great River Energy, 3, 6/15/2017

- 0 - 0

OPG suggest that 1.6.1 state “Verify the software originated from the vendor’s official source(s)”. In the current text, even if a source has an “identity”, it should also state the “identity” is the one that is expected. Similarly we can change the word “identity” with “correct identity” in R1 Part 1.6.1.

David Ramkalawan, 6/15/2017

- 0 - 0

Duke Energy requests additional guidance as to what constitutes acceptable verification of integrity as required by R1.6.2. The measure indicates that a change request record could demonstrate that source identity and integrity verification took place, but doesn’t go into further detail as to what an acceptable check into source identity and software would be. Is there specific language that should be stated in the change request record that would clearly state the verification took place? More guidance on this aspect is requested.

Also, Duke Energy requests that the Note under Applicable Systems in Part 1.6 should remain there once the standard is approved. The Note provides valuable details as to the true scope of the Requirement, and aids entities in knowing what will be the compliance expectation.

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

- 0 - 0

Comments:  

The proposed requirement would possibly involve entities duplicating effort for every case for which such verification had to be undertaken (i.e. the cases of multiple installations of a given piece of software across many similar applicable Cyber Assets).  This does not seem consistent with the intent of the protection and could present an undue compliance burden without providing the intended protection. Request guidance on using trusted internal repositories as a software source so that Entity can verify once and use many

 

VSL does not cover the failure to implement the process. Does not include all of the combinations.

 

Concerns with 1.6.1 and 1.6.2 as written --- how to provide evidence? Request more examples of evidence

 

We suggest rephrasing “when the method to do so is available to the Responsible Entity from the software source” to “when the vendor supplied method to do so is available to Responsible Entity”. Otherwise the “method to do so” is ambiguous and leaves the following questions:

 

How does one prove that a method is not available?

What is the line between available/unavailable? How far do you have to go?

 

We are concerned with double jeopardy potential with CIP-007 R2. We feel that if it is impossible to validate the source or verify authenticity of the patch itself we would not consider that patch to be available.

 

 

Timothy Reyher, 6/15/2017

- 0 - 0

Request clarification on how an Entity can verify the ‘integrity and authenticity’ one time and then be able to install on multiple devices.

Recommend removing CIP-013 R1 subparts 1.2.5 from CIP-013 since it is covered in the proposed CIP-010-3

The proposed requirement would possibly involve entities duplicating effort for every case for which such verification had to be undertaken (i.e. the cases of multiple installations of a given piece of software across many similar applicable Cyber Assets).  This does not seem consistent with the intent of the protection and could present an undue compliance burden without providing the intended protection. Request guidance on using trusted internal repositories as a software source so that Entity can verify once and use many

VSL does not cover the failure to implement the process. Does not include all of the combinations.

Concerns with 1.6.1 and 1.6.2 as written --- how to provide evidence? Request more examples of evidence

We suggest rephrasing “when the method to do so is available to the Responsible Entity from the software source” to “when the vendor supplied method to do so is available to Responsible Entity”. Otherwise the “method to do so” is ambiguous and leaves the following questions:

How does one prove that a method is not available?

What is the line between available/unavailable? How far do you have to go?

We are concerned with double jeopardy potential with CIP-007 R2. We feel that if it is impossible to validate the source or verify authenticity of the patch itself we would not consider that patch to be available. 

Quintin Lee, Eversource Energy, 1, 6/15/2017

- 0 - 0

By adding the “when the method to do so is available to the Entity from the software source” does this require the entity to document and detail what method is available of not available? How does that entity prove and document this condition? Does the entity have to document and prove that it was tested and verified for software integrity and authenticity? If so, what are those requirements, documentation, testing environment required and timeline for testing the software? 

ACES Standards Collaborators, Segment(s) 1, 3, 4, 5, 6/15/2017

- 0 - 0

Texas RE notes that the proposed standard is not responsive to the FERC directive.  FERC Order No. 829 P. 59 specifically states “The new or modified Reliability Standard must address the provision and verification of relevant security concepts in future contracts for industrial control system hardware, software, and computing and networking services associated with bulk electric system operations.”  The Note in Part 1.6, however, states: “Additionally, the following issues are beyond the scope of Part 1.6: (1) the actual terms and conditions of a procurement contract; and (2) vendor performance and adherence to a contract.”  Texas RE agrees that it is unreasonable to hold a registered entity accountable for a vendor’s adherence to (or lack of adherence to) a contract.  Texas RE agrees as the SDT claims obtaining specific controls in the negotiated contract may not be feasible at all times but Texas RE believes this is best practice. In fact, in most cases contracts for these types of systems typically include security provisions and set similar expectations as described in the standard. The proposed standards would prohibit the compliance monitor from verifying the registered entity implemented part 1.6. Moreover, this verification is to ensure that the registered entities’ plans are consistent with the contract’s expectations and obligations of the parties.

Admittedly, there will be circumstances in which a contracts may not be consistent or silent as it pertains to the responsible entity’s security management plans (e.g. existing contacts or contracts in which the responsible entity was unable to negotiate the appropriate terms into the contract.) In those circumstances, other evidence should be provided demonstrating that the responsible entity has processes to ensure the vendor is expected/obligated to act consistent with the responsible entity’s cyber security risk management plans as it relates to the vendor’s products or services. Therefore, the contracts should remain in scope as to demonstrate the mapping of expectations from the plan to the contract as far as vendor interactions for those specific items included in the standard and to advance best practices leading to a more reliable BES.

 

Texas RE also recommends the SDT remove or provide clarity on the verbiage that reads, “and when the method to do so is available to the Responsible Entity from the software source”. A potential scenario exists now where vendors will attest that identity and integrity methods are not available therefore Part 1.6 is not applicable.

 

Texas RE notes that the words “integrity” and “authenticity” are used in the Guidelines and Technical Basis however Part 1.6 uses the words “identity” and “integrity”.  Are these intended to be the same?

Rachel Coyne, Texas Reliability Entity, Inc., 10, 6/15/2017

- 0 - 0

Theresa Rakowsky, 6/15/2017

- 0 - 0

AECI supports NRECA's comments provided below:

NRECA supports the revisions to CIP-010-2.  However, in the GTB the SDT should clarify the meaning of this sentence: “For example, in the System and Information Integrity (SI) control family, control SI-7 suggests that the integrity of information systems and obtaining software directly from the developer.”  This sentence seems to be incomplete and further words are needed to complete it.

AECI & Member G&Ts, Segment(s) 1, 6, 5, 3, 4/11/2017

- 0 - 0

The proposed requirement would possibly involve entities duplicating effort for every case for which such verification had to be undertaken (i.e. the cases of multiple installations of a given piece of software across many similar applicable Cyber Assets).  This does not seem consistent with the intent of the protection and could present an undue compliance burden without providing the intended protection. Request guidance on using trusted internal repositories as a software source so that Entity can verify once and use many

 

VSL does not cover the failure to implement the process. Does not include all of the combinations.

 

Concerns with 1.6.1 and 1.6.2 as written --- how to provide evidence? Request more examples of evidence

 

We suggest rephrasing “when the method to do so is available to the Responsible Entity from the software source” to “when the vendor supplied method to do so is available to Responsible Entity”. Otherwise the “method to do so” is ambiguous and leaves the following questions:

 

How does one prove that a method is not available?

What is the line between available/unavailable? How far do you have to go?

 

We are concerned with double jeopardy potential with CIP-007 R2. We feel that if it is impossible to validate the source or verify authenticity of the patch itself we would not consider that patch to be available.

RSC no Dominion, Segment(s) 1, 0, 2, 4, 5, 6, 7, 3, 6/15/2017

- 1 - 0

GTC supports NRECA comments:

 

NRECA supports the revisions to CIP-010-2.  However, in the GTB the SDT should clarify the meaning of this sentence: “For example, in the System and Information Integrity (SI) control family, control SI-7 suggests that the integrity of information systems and obtaining software directly from the developer.”  This sentence seems to be incomplete and further words are needed to complete it.

Jason Snodgrass, 6/15/2017

- 0 - 0

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

- 0 - 0

The proposed requirement would possibly involve entities duplicating effort for every case for which such verification had to be undertaken (i.e. the cases of multiple installations of a given piece of software across many similar applicable Cyber Assets).  This does not seem consistent with the intent of the protection and could present an undue compliance burden without providing the intended protection. 

SRC + SWG , Segment(s) 2, 3, 1, 0, 6/15/2017

- 0 - 0

EPE understands the need for software integrity and authenticity; however, the proposed wording of the standard is not sufficiently clear with respect to the action/conduct being sought by the Registered Entity in order to achieve compliance.  In Order No. 829, FERC offered clarity that the proposed requirement does not capture.  There, FERC stated:

 

For example, in the System and Information Integrity (SI) control family, control SI-7 suggests that the integrity of information systems and components should be tested and verified using controls such as digital signatures and obtaining software directly from the developer.  In the Configuration Management (CM) control family, control CM-5(3) requires that the information system prevent the installation of firmware or software without verification that the component has been digitally signed to ensure that hardware and software components are genuine and valid.  NIST SP-800-161, while not meant to be definitive, provides examples of controls for addressing the Commission’s directive regarding this first objective.  Other security controls also could meet this objective.   Order No 829 at P 50 (emphasis added).

Requirement 1.6 should be adjusted to provide the type of clarity FERC provided in the Order.  An additional sentence or parenthetical should be included within the requirement, to read (“Verification that a patch or other software component has been digitally signed is one way to meet this requirement; other security controls could also meet this requirement, such as having the vendor state in writing that it will verify the integrity and authenticity of all software, including patches, in advance of releasing it to the Registered Entity during the life of its service contract with the Registered Entity”). 

 

The addition of such language in the requirement itself is consistent with the feedback offered by NERC Staff in recent months, and would eliminate the false impression that would otherwise be given that a Registered Entity must secure a verification letter from its software vendor each and every single time it seeks to download a patch.  For example, during the NERC webinar held on May 18, 2017, examples were provided to the attendees on information that would be considered sufficient evidence to fulfill this requirement, and such examples included a letter from the vendor indicating that the vendor is verifying integrity and authenticity of its software before releasing its software (including patches) to its clients. 

Victor Garzon, 6/15/2017

- 0 - 0

EPE understands the need for software integrity and authenticity; however, the proposed wording of the standard is not sufficiently clear with respect to the action/conduct being sought by the Registered Entity in order to achieve compliance.  In Order No. 829, FERC offered clarity that the proposed requirement does not capture.  There, FERC stated:

 

For example, in the System and Information Integrity (SI) control family, control SI-7 suggests that the integrity of information systems and components should be tested and verified using controls such as digital signatures and obtaining software directly from the developer.  In the Configuration Management (CM) control family, control CM-5(3) requires that the information system prevent the installation of firmware or software without verification that the component has been digitally signed to ensure that hardware and software components are genuine and valid.  NIST SP-800-161, while not meant to be definitive, provides examples of controls for addressing the Commission’s directive regarding this first objective.  Other security controls also could meet this objective.   Order No 829 at P 50 (emphasis added).

Requirement 1.6 should be adjusted to provide the type of clarity FERC provided in the Order.  An additional sentence or parenthetical should be included within the requirement, to read (“Verification that a patch or other software component has been digitally signed is one way to meet this requirement; other security controls could also meet this requirement, such as having the vendor state in writing that it will verify the integrity and authenticity of all software, including patches, in advance of releasing it to the Registered Entity during the life of its service contract with the Registered Entity”). 

 

The addition of such language in the requirement itself is consistent with the feedback offered by NERC Staff in recent months, and would eliminate the false impression that would otherwise be given that a Registered Entity must secure a verification letter from its software vendor each and every single time it seeks to download a patch.  For example, during the NERC webinar held on May 18, 2017, examples were provided to the attendees on information that would be considered sufficient evidence to fulfill this requirement, and such examples included a letter from the vendor indicating that the vendor is verifying integrity and authenticity of its software before releasing its software (including patches) to its clients. 

Pablo Onate, El Paso Electric Company, 1, 6/15/2017

- 0 - 0

EPE understands the need for software integrity and authenticity; however, the proposed wording of the standard is not sufficiently clear with respect to the action/conduct being sought by the Registered Entity in order to achieve compliance.  In Order No. 829, FERC offered clarity that the proposed requirement does not capture.  There, FERC stated:

 

For example, in the System and Information Integrity (SI) control family, control SI-7 suggests that the integrity of information systems and components should be tested and verified using controls such as digital signatures and obtaining software directly from the developer.  In the Configuration Management (CM) control family, control CM-5(3) requires that the information system prevent the installation of firmware or software without verification that the component has been digitally signed to ensure that hardware and software components are genuine and valid.  NIST SP-800-161, while not meant to be definitive, provides examples of controls for addressing the Commission’s directive regarding this first objective.  Other security controls also could meet this objective.   Order No 829 at P 50 (emphasis added).

 

Requirement 1.6 should be adjusted to provide the type of clarity FERC provided in the Order.  An additional sentence or parenthetical should be included within the requirement, to read (“Verification that a patch or other software component has been digitally signed is one way to meet this requirement; other security controls could also meet this requirement, such as having the vendor state in writing that it will verify the integrity and authenticity of all software, including patches, in advance of releasing it to the Registered Entity during the life of its service contract with the Registered Entity”). 

 

The addition of such language in the requirement itself is consistent with the feedback offered by NERC Staff in recent months, and would eliminate the false impression that would otherwise be given that a Registered Entity must secure a verification letter from its software vendor each and every single time it seeks to download a patch.  For example, during the NERC webinar held on May 18, 2017, examples were provided to the attendees on information that would be considered sufficient evidence to fulfill this requirement, and such examples included a letter from the vendor indicating that the vendor is verifying integrity and authenticity of its software before releasing its software (including patches) to its clients.

Rhonda Bryant, El Paso Electric Company, 3, 6/15/2017

- 0 - 0

Additional examples of acceptable evidence would be helpful under the Measures column of the requirement.

Change the statement in the Guidelines and Technical Basis, Section Software Integrity and Authenticity, paragraph 1, third sentence: “The intent of the SDT is to provide controls for verifying the baseline elements that are updated by vendors.” to say “… provided by vendors.”

Additional clarity is needed regarding the following in the Guidelines and Technical Basis: “It is not the intent of the SDT to require a verification of each source or software update at the time it is obtained. It is sufficient to establish the reliable source and software update once. This will allow automated solutions to be implemented to obtain frequent updates such as patches.”  This is confusing because saying “each source or software update” is not required to be validated at the time it is obtained could be interpreted to mean continuous patch updates provided by a single vendor are only required to be verified once for the lifetime of the supply of patches from that vendor. 

Additional examples of acceptable methods and evidence are needed in the Guidelines and Technical Basis for performing software integrity and authenticity. 

For example – Consider having the measures for R1.6 be similar to R1.1.

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

- 0 - 0

Glen Farmer, Avista - Avista Corporation, 5, 6/15/2017

- 0 - 0

Oxy, Segment(s) 7, 5, 9/6/2016

- 0 - 0

Disagree with the revisions on CIP-010-3. We would like to see guideline language of verifying once be moved to the requirement/measure.

Teresa Krabe, Lower Colorado River Authority, 5, 6/15/2017

- 0 - 0

See attached integrated comments.

William Harris, Foundation for Resilient Societies, 8, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

John Martinsen, Public Utility District No. 1 of Snohomish County, 4, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Long Duong, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Mark Oens, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Sam Nietfeld, Public Utility District No. 1 of Snohomish County, 5, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Franklin Lu, 6/15/2017

- 0 - 0

To avoid an interpretation of this requirement that may be overly burdensome, ERCOT suggests the following clarifications to the language in the requirement and measure of CIP-010-3 R1 Part 1.6.  This would ensure a more holistic and less prescriptive approach to changes that deviate from the baseline.

 

In the first sentence of Requirement R1.6, revise “For a change that deviates” to “Where technically feasible, for changes that deviate…”

 

Revise the R1.6 Measure to read “An example of evidence may include, but is not limited to, a change request record that demonstrates the verification of identity of the software source and integrity of the software was performed during the baseline change, or a process which documents the mechanisms in place that would automatically ensure the authenticity and integrity of the software.”

Elizabeth Axson, 6/15/2017

- 0 - 0

Hot Answers

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

Richard Vine, 6/15/2017

- 0 - 0

- 0 - 0

Other Answers

Randy Buswell, 5/31/2017

- 0 - 0

Bill Watson, On Behalf of: Bill Watson, , Segments 3

- 0 - 0

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

- 0 - 0

Sandra Pacheco, On Behalf of: Silicon Valley Power - City of Santa Clara, , Segments 3, 5

- 0 - 0

Val Ridad, On Behalf of: Silicon Valley Power - City of Santa Clara, , Segments 3, 5

- 0 - 0

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

- 0 - 0

Illinois Municipal Electric Agency supports comments submitted by the American Public Power Association.

Bob Thomas, 6/9/2017

- 0 - 0

CHPD supports these changes.

Haley Sousa, 6/9/2017

- 0 - 0

CHPD supports these changes.

Janis Weddle, 6/9/2017

- 0 - 0

While the initial direction of CIP-013-1 is good and provides protection for High BCS and Medium BCS, similar Cyber Assets associated with Low impact BES Cyber Systems may represent vectors for attack to High BCS or Medium BCS if left unprotected. WECC understands the reluctance of industry to incorporate Low impact BCS and their component BCA and other Cyber Assets under the CIP-013-1 purview and supports remanding SCRM issues associated with Low impact BCS to the CIP-003 Standard Drafting Team for integration into R1.2 and R2 of that Standard to ensure SCRM is integrated into those BCS at a level commensurate with the risk posed to the reliability of the BES.  

Steven Rueckert, Western Electricity Coordinating Council, 10, 6/9/2017

- 0 - 0

CHPD supports these changes.

Chad Bowman, 6/9/2017

- 0 - 0

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

- 0 - 0

CHPD supports these changes.

Mick Neshem, 6/12/2017

- 0 - 0

Colorado Springs Utilities supports the comments provided by APPA

Jeff Icke, Colorado Springs Utilities, 5, 6/12/2017

- 0 - 0

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

- 0 - 0

None.

Daniel Grinkevich, 6/12/2017

- 0 - 0

Patrick Hughes, On Behalf of: National Electrical Manufacturers Association, NA - Not Applicable, Segments NA - Not Applicable

- 0 - 0

Santee Cooper agrees with the removal of low-impact BES Cyber Systems from CIP-013-1.  Including low-impact BES Cyber Systems will require substantial resources by a Responsible Entity it identify and maintain an inventory list of items.

Shawn Abrams, 6/13/2017

- 0 - 0

No comment.

Steven Sconce, On Behalf of: EDF Renewable Energy, , Segments 5

- 0 - 0

- 0 - 0

Thomas Foltz, AEP, 5, 6/13/2017

- 0 - 0

Michael Haff, On Behalf of: Seminole Electric Cooperative, Inc., FRCC, Segments 1, 3, 4, 5, 6

- 0 - 0

Allan Long, Memphis Light, Gas and Water Division, 1, 6/13/2017

- 0 - 0

Anthony Jablonski, ReliabilityFirst , 10, 6/13/2017

- 0 - 0

PRPA agrees with the removal of low-impact BES Cyber Systems from CIP-013-1 and agrees that the current standard as written appropriately addresses the Commission’s concerns as specified in Order No. 829.  PRPA believes that for entities that have a mixture of High, Medium and Low assets, the Low assets would inherently benefit from the additional requirements of Medium and Low requirements as a matter of normal business practices. Additionally, many Contracts and Master Agreements are developed for all products and services purchased from a vendor.   For Entities that have Low assets only, there would not be additional requirements based on CIP-002 risk based approach.

PRPA believes that including Lows will require substantial resources by each Responsible Entity to identify and maintain an inventory list of these items. Also, controls inherent to CIP-013 and previous CIP Standards that reduce the risk associated with Lows.

Tyson Archie, Platte River Power Authority, 5, 6/14/2017

- 0 - 0

Amelia Sawyer Anderson, On Behalf of: CenterPoint Energy Houston Electric, LLC, Texas RE, Segments 1

- 0 - 0

- 0 - 0

W. Dwayne Preston, Austin Energy, 3, 6/14/2017

- 0 - 0

Lauren Price, 6/14/2017

- 0 - 0

 

SMUD agrees with the removal of low-impact BES Cyber Systems from CIP-013-1 and agrees that the current standard as written appropriately addresses the Commission’s concerns as specified in Order No. 829.  SMUD believes that for entities that have a mixture of High, Medium and Low assets, the Low assets would inherently benefit from the additional requirements of Medium and Low requirements as a matter of normal business practices. Additionally, many Contracts and Master Agreements are developed for all products and services purchased from a vendor.   For Entities that have Low assets only, there would not be additional requirements based on CIP-002 risk based approach.

 

 

SMUD believes that including Lows will require substantial resources by each Responsible Entity to identify and maintain an inventory list of these items. Also, controls inherent to CIP-013 and previous CIP Standards that reduce the risk associated with Lows.

- 0 - 0

AE agrees with removing low-impact BCS from CIP-013-1 and agrees the current standard, as written, appropriately addresses the Commission’s concerns as specified in Order No. 829.  AE believes, for entities with a mixture of High, Medium and Low Impact BCS, the Low Impact B CA would inherently benefit from the additional requirements of Medium and Low requirements as a matter of normal business practices. Additionally, many contracts and master agreements are developed for all products and services purchased from a vendor.   For entities with Low Impact BCS only, there would not be additional requirements based on the CIP-002 risk-based approach.

AE believes including Low Impact BCS will require substantial resources by each Responsible Entity to identify and maintain an inventory list of these devices. Also, controls inherent to CIP-013 and previous CIP Standards reduce the risk associated with Low Impact BCS.

Andrew Gallo, 6/14/2017

- 0 - 0

BC Hydro believes that focussing on Medium and High Impact BCS instead of Low Impact is a good place to start. If insufficient risk mitigation is found to be provided here, it can always be expanded later.  However, BC Hydro does not believe CIP-013-1 itself is necessary given what entities will already be doing under the other CIP v5 standards

BC Hydro, Segment(s) 1, 2, 3, 5, 5/6/2015

- 0 - 0

Richard Kinas, 6/14/2017

- 0 - 0

See Attached Comments.

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

2016-03_Unofficial_Comment_Form_SCL_2017-6-14 Final to NERC.docx

- 0 - 0

No comments

Normande Bouffard, 6/14/2017

- 0 - 0

Entergy/NERC Compliance, Segment(s) 1, 5, 3/1/2017

- 0 - 0

Theresa Allard, Minnkota Power Cooperative Inc., 1, 6/14/2017

- 0 - 0

SRP agrees with the removal of low impact BCS from CIP-013-1 and agrees that the current standard as written appropriately addresses the Commission’s concerns as specified in Order No. 829.  SRP believes that for entities that have a mixture of high, medium and low assets, the low assets would inherently benefit from the additional requirements of medium and low requirements as a matter of normal business practices. Additionally, many Contracts and Master Agreements are developed for all products and services purchased from a vendor.   For Entities that have low assets only, there would not be additional requirements based on CIP-002 risk based approach.

SRP believes that including lows will require substantial resources by each Responsible Entity to identify and maintain an inventory list of these items. Also, controls inherent to CIP-013 and previous CIP Standards that reduce the risk associated with lows.

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

- 0 - 0

Alex Ybarra, 6/14/2017

- 0 - 0

Wendy Center, U.S. Bureau of Reclamation, 5, 6/14/2017

- 0 - 0

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

- 0 - 0

Andrew Meyers, Bonneville Power Administration, 6, 6/14/2017

- 0 - 0

- 0 - 0

No Comments

Alan Farmer, On Behalf of: ACEC, FRCC, MRO, WECC, Texas RE, NPCC, SERC, SPP RE, RF, Segments NA - Not Applicable

- 0 - 0

NRECA appreciates the SDT’s efforts to develop the supply chain requirements under a risk-based lens.

Barry Lawson, 6/14/2017

- 0 - 0

John Williams, 6/15/2017

- 1 - 0

Nicholas Lauriat, Network and Security Technologies, 1, 6/15/2017

- 0 - 0

Melanie Seader, On Behalf of: Edison Electric Institute, NA - Not Applicable, Segments NA - Not Applicable

- 0 - 0

NYPA supports the comments submitted by Salt River Project (WECC) and NPCC.

David Rivera, New York Power Authority, 3, 6/15/2017

- 0 - 0

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

- 0 - 0

NPPD supports the position of the MRO NSRF.

Don Schmit, 6/15/2017

- 0 - 0

Daniel Gacek, Exelon, 1, 6/15/2017

- 0 - 0

USI agrees with the removal of low-impact BES Cyber Systems from CIP-013-1 and agree that the current standard as written appropriately addresses the Commission’s concerns as specified in Order No. 829.

Brian Evans-Mongeon, Utility Services, Inc., 4, 6/15/2017

- 1 - 0

GSOC supports NRECA's Comments of:

NRECA appreciates the SDT’s efforts to develop the supply chain requirements under a risk-based lens.

Guy Andrews, 6/15/2017

- 0 - 0

IPC agrees that the applicability to Lows should be removed.

Laura Nelson, 6/15/2017

- 0 - 0

Heather Morgan, EDP Renewables North America LLC, 5, 6/15/2017

- 0 - 0

David Gordon, 6/15/2017

- 0 - 0

MEAG supports the answers and comments of Salt River Project.

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

- 0 - 0

SPP Standards Review Group, Segment(s) 0, 6/15/2017

- 0 - 0

None

Kara White, On Behalf of: NRG - NRG Energy, Inc., FRCC, MRO, WECC, Texas RE, NPCC, SERC, SPP RE, RF, Segments 3, 4, 5, 6

- 0 - 0

LeRoy Patterson, Public Utility District No. 2 of Grant County, Washington, 6, 6/15/2017

- 0 - 0

PJM chooses to abstain from this question as we have no low impact assets.

Mark Holman, 6/15/2017

- 0 - 0

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

- 0 - 0

Jesus Sammy Alcaraz, Imperial Irrigation District, 1, 6/15/2017

- 0 - 0

- 0 - 0

Luminant believes it is appropriate to address the supply chain requirements using a risk-based approach.  Low impact Cyber Systems are categorized as low impact because they inherently have a low ability to negatively impact the Bulk Electric System. We should focus our resources on those systems that have the potential for significant adverse impact on the BES.  In addition, there are many types of low impact Cyber Systems.  If a decision was made to put them back into the standard, there would need to be extensive work on evaluating each of these types of systems in order to determine whether there is adequate benefit to reliability to offset the cost and burden of imposing supply chain requirements for these systems.

Luminant, Segment(s) 6, 7, 5, 1/24/2017

- 0 - 0

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

- 0 - 0

FEUS supports the comments submitted by APPA

Linda Jacobson-Quinn, City of Farmington, 3, 6/15/2017

- 0 - 0

Scott Downey, 6/15/2017

- 0 - 0

- 0 - 0

No comment

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

- 0 - 0

- 0 - 0

GRE appreciates the SDT’s efforts to develop the supply chain requirements under a risk-based lens.

Michael Brytowski, Great River Energy, 3, 6/15/2017

- 0 - 0

David Ramkalawan, 6/15/2017

- 0 - 0

Duke Energy agrees with the removal of low-impact BES Cyber Systems from the applicability of CIP-013-1. Low-impact BES Cyber Systems have been subject to a risk assessment and classified low-impact since they pose a minimal threat to the BES. Also, a Responsible Entity is not required to have an inventory list of its low-impact BES Cyber Systems. If this standard were to apply to low-impact BES Cyber Systems, this would likely create a situation wherein an inventory list is necessary. This would be a significant effort, which would not likely bolster the reliability of the grid, based on the limited impact lows present to the system.

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

- 0 - 0

None

Timothy Reyher, 6/15/2017

- 0 - 0

Quintin Lee, Eversource Energy, 1, 6/15/2017

- 0 - 0

Yes. Industry supply chain management advances that would impact low impact BES Cyber Systems would be addressed by vendors through the requirements for high and medium impact BES Cyber Systems. 

ACES Standards Collaborators, Segment(s) 1, 3, 4, 5, 6/15/2017

- 0 - 0

Texas RE’s opinion is that low impact BES Cyber Systems should be included in CIP-013-1 because industrial control systems monitor and operate BES Cyber Assets located at transmission substations, wind farms, and generation facilities.

 

Texas RE noticed that Question 4 uses the words “hardware, computing and networking services”, which are not found in CIP-013-1.   Should they be used in CIP-013-1 instead of “equipment, products, and services”?

Rachel Coyne, Texas Reliability Entity, Inc., 10, 6/15/2017

- 0 - 0

Theresa Rakowsky, 6/15/2017

- 0 - 0

AECI & Member G&Ts, Segment(s) 1, 6, 5, 3, 4/11/2017

- 0 - 0

None

RSC no Dominion, Segment(s) 1, 0, 2, 4, 5, 6, 7, 3, 6/15/2017

- 1 - 0

GTC supports NRECA comments:

 

NRECA appreciates the SDT’s efforts to develop the supply chain requirements under a risk-based lens.

Jason Snodgrass, 6/15/2017

- 0 - 0

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

- 0 - 0

While the IRC members do not have Low Impact Bes Cyber Systems we have multiple interfaces with our Market Participants that do have Low Impact BES Cyber Systems. This, in turn represents, risk to our BES Cyber Systems. As such we recommend that CIP-013-1 apply to Low Impact BES Cyber Systems to reduce the supply chain risk not only to the Low Impact BES Cyber Systems but to the IRC member organization’s BES Cyber Systems.

Note: PJM does not support this comment.

 

SRC + SWG , Segment(s) 2, 3, 1, 0, 6/15/2017

- 0 - 0

Victor Garzon, 6/15/2017

- 0 - 0

Pablo Onate, El Paso Electric Company, 1, 6/15/2017

- 0 - 0

Rhonda Bryant, El Paso Electric Company, 3, 6/15/2017

- 0 - 0

No additional comments.

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

- 0 - 0

Glen Farmer, Avista - Avista Corporation, 5, 6/15/2017

- 0 - 0

Oxy agrees with the removal of low impact BCS from CIP-013-1 and agrees that the current standard as written appropriately addresses the Commission’s concerns as specified in Order No. 829.  Oxy believes that for entities that have a mixture of high, medium and low impact assets, the low impact assets would inherently benefit from the requirements applicable to high and medium impact assets as a matter of normal business practice, as the high water mark will be applied when purchasing equipment and services.  This will account for a large portion of low impact BES Cyber Systems.  Oxy believes it is appropriate to address the supply chain requirements using this risk-based approach.  Low impact BES Cyber Systems are categorized as low impact because they inherently pose a low risk to negatively impact the Bulk Electric System. Resources should focus on those systems that have the potential for significant adverse impact on the BES.  Additionally, vendors will not differentiate their product as low, medium or high impact, so as vendors address the requirements of high and medium impact entities, low impact entities will acquire the same products and services as medium and high impact entities.  If low impact BES Cyber Systems were included in CIP-013-1, the costs associated with compliance would far outweigh the risk posed to the BES, in both manpower and additional equipment and services. 

Oxy, Segment(s) 7, 5, 9/6/2016

- 0 - 0

No comment.

Teresa Krabe, Lower Colorado River Authority, 5, 6/15/2017

- 0 - 0

Malware inserted into the U.S. electric grid in year 2014 and into the electric grid and other assets in the Ukraine in December 2015 and December 2016 target nominally "low impact" assets producing high impact consequences. See integrated comments that address in part the need to upgrade protections for so-called "low impact" facilities.

William Harris, Foundation for Resilient Societies, 8, 6/15/2017

Resilient Societies Comments - NERC Cyber Supply Chain Risk Management 2016-03.docx

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

John Martinsen, Public Utility District No. 1 of Snohomish County, 4, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Long Duong, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Mark Oens, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Sam Nietfeld, Public Utility District No. 1 of Snohomish County, 5, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Franklin Lu, 6/15/2017

- 0 - 0

ERCOT joins the comments of the IRC.

Elizabeth Axson, 6/15/2017

- 0 - 0

Hot Answers

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

Richard Vine, 6/15/2017

- 0 - 0

- 0 - 0

Other Answers

Randy Buswell, 5/31/2017

- 0 - 0

Bill Watson, On Behalf of: Bill Watson, , Segments 3

- 0 - 0

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

- 0 - 0

Sandra Pacheco, On Behalf of: Silicon Valley Power - City of Santa Clara, , Segments 3, 5

- 0 - 0

Val Ridad, On Behalf of: Silicon Valley Power - City of Santa Clara, , Segments 3, 5

- 0 - 0

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

- 0 - 0

Illinois Municipal Electric Agency supports comments submitted by the American Public Power Association.

Bob Thomas, 6/9/2017

- 0 - 0

CHPD supports these changes.

Haley Sousa, 6/9/2017

- 0 - 0

CHPD supports these changes.

Janis Weddle, 6/9/2017

- 0 - 0

As mentioned above, WECC supports the CIP-013-1 implementation plan, including the expectation for the initial performance of the R3 review and approval on or before the effective date. 

Steven Rueckert, Western Electricity Coordinating Council, 10, 6/9/2017

- 0 - 0

CHPD supports these changes.

Chad Bowman, 6/9/2017

- 0 - 0

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

- 0 - 0

CHPD supports these changes.

Mick Neshem, 6/12/2017

- 0 - 0

Colorado Springs Utilities supports the comments provided by APPA

Jeff Icke, Colorado Springs Utilities, 5, 6/12/2017

- 0 - 0

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

- 0 - 0

Daniel Grinkevich, 6/12/2017

- 0 - 0

Patrick Hughes, On Behalf of: National Electrical Manufacturers Association, NA - Not Applicable, Segments NA - Not Applicable

- 0 - 0

Shawn Abrams, 6/13/2017

- 0 - 0

No comment.

Steven Sconce, On Behalf of: EDF Renewable Energy, , Segments 5

- 0 - 0

- 0 - 0

Thomas Foltz, AEP, 5, 6/13/2017

- 0 - 0

Michael Haff, On Behalf of: Seminole Electric Cooperative, Inc., FRCC, Segments 1, 3, 4, 5, 6

- 0 - 0

We agree with APPA's submitted comments, including:

Suggesting a change in wording to say that the Supply Chain Risk Management Plan must be used on or after the implementation date rather than saying that contracts on or after that date are within scope of CIP-013. 

Clarification should be made about if/when existing contracts or agreements come into scope.

Allan Long, Memphis Light, Gas and Water Division, 1, 6/13/2017

- 0 - 0

Anthony Jablonski, ReliabilityFirst , 10, 6/13/2017

- 0 - 0

PRPA generally agrees with an 18-month implementation plan but, would prefer a 24-month implementation plan.  PRPA feels that a 24-month timeframe is more appropriate and gives the entity additional time to align budgets and develop processes with vendors and suppliers.

Tyson Archie, Platte River Power Authority, 5, 6/14/2017

- 0 - 0

Amelia Sawyer Anderson, On Behalf of: CenterPoint Energy Houston Electric, LLC, Texas RE, Segments 1

- 0 - 0

- 0 - 0

W. Dwayne Preston, Austin Energy, 3, 6/14/2017

- 0 - 0

Lauren Price, 6/14/2017

- 0 - 0

 

SMUD generally agrees with an 18-month implementation plan but, would prefer a 24-month implementation plan.  SMUD feels that a 24-month timeframe is more appropriate and gives the entity additional time to align budgets and develop processes with vendors and suppliers.

 

SMUD is indicating a “no” response as the implementation plan does not include a pilot.  The implementation of TCA CIP 010 R4 was difficult as entities did not have a model implementation to learn practical applications of the standard in operations.  Other standards that had a pilot allowed entities to learn practical implementation decisions that would save money and time. 

 

Please note, SMUD is willing to participate as a pilot participant.

 

- 0 - 0

AE generally agrees with an 18-month implementation plan but, would prefer 24-months. AE feels a 24-month timeframe is more appropriate and gives entities additional time to align budgets and develop processes with vendors and suppliers. As a municipal utility, AE's procurement process is quite long.

Andrew Gallo, 6/14/2017

- 0 - 0

BC Hydro, Segment(s) 1, 2, 3, 5, 5/6/2015

- 0 - 0

Richard Kinas, 6/14/2017

- 0 - 0

See attached comments

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

2016-03_Unofficial_Comment_Form_SCL_2017-6-14 Final to NERC.docx

- 0 - 0

Recommend changing this General Consideration from

Contracts entering the Responsible Entity's procurement process (e.g. through Request for Proposals) on or after the effective date are within scope of CIP-013-1. Contract effective date, commencement date, or other activation dates specified in the contract do not determine whether the contract is within scope of CIP-013-1.

To

Supply Chain Risk Management plan must be used by the procurement processes that begin on or after the implementation date of the CIP-013-1. Make corresponding change to the CIP-013 R2 note.

And      

CIP-005-6 and CIP-010-3 must be implemented 18 months after the implementation date of the CIP-013-1

Implementation Plan does not handle unplanned changes such as IROLs or registration, etc.

Request a 24 month implementation of CIP-013-1 due to budget cycles and technical controls for other CIP Standards

Normande Bouffard, 6/14/2017

- 0 - 0

Entergy/NERC Compliance, Segment(s) 1, 5, 3/1/2017

- 0 - 0

Theresa Allard, Minnkota Power Cooperative Inc., 1, 6/14/2017

- 0 - 0

SRP generally agrees with an 18-month implementation plan but, would prefer a 24-month implementation plan.  SRP feels that a 24-month timeframe is more appropriate and gives the entity additional time to align budgets and develop processes with vendors and suppliers.

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

- 0 - 0

Alex Ybarra, 6/14/2017

- 0 - 0

It is uncertain when purchasing activities become subject to CIP-013-1. The proposed Implementation Plan states: “Contracts entering the Responsible Entity's procurement process (e.g. through Request for Proposals) on or after the effective date are within scope of CIP-013-1. Contract effective date, commencement date, or other activation dates specified in the contract do not determine whether the contract is within scope of CIP-013-1.”

 

Reclamation recommends that the “General Considerations” guidance contained in the Implementation Plan pertaining to purchasing activities be included in the proposed standard.

 

If the “General Considerations” guidance on purchasing activities becomes part of the proposed standard, Reclamation further recommends:

  • A contract becomes within scope when the entity commences its formal contract process such as when a request for proposal or solicitation is issued.

  • Any direct purchase and/or any repurposed equipment is within scope prior to connecting to the Bulk Electric System as a cyber asset.

Wendy Center, U.S. Bureau of Reclamation, 5, 6/14/2017

- 0 - 0

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

- 0 - 0

Andrew Meyers, Bonneville Power Administration, 6, 6/14/2017

- 0 - 0

- 0 - 0

While in overall agreement with the updated Implementation Plan, ACEC does have the following concern:

The second paragraph in the section “General Considerations” states “Contracts entering the Responsible Entity's procurement process (e.g. through Request for Proposals) on or after the effective date are within scope of CIP-013-1. Contract effective date, commencement date, or other activation dates specified in the contract do not determine whether the contract is within scope of CIP-013-1.” Based upon the above wording it could be understood that Master Supply Agreements (MSAs) would need to be changed in the first RFP after implementation of the new standard. The paragraph should state specifically that this is not required, and that the plan can allow MSAs to exist as is until it is time to review in the normal procurement process.

Alan Farmer, On Behalf of: ACEC, FRCC, MRO, WECC, Texas RE, NPCC, SERC, SPP RE, RF, Segments NA - Not Applicable

- 0 - 0

NRECA supports the new implementation plan timeframe.  However, this implementation plan unintentionally removes the provisions for additional time to implement unplanned changes in CIP-005 and CIP-010 that was provided in the V5 and V6 implementation plans.  NRECA strongly requests that the language from the “Planned or Unplanned Changes Resulting in a Higher Categorization” section of the CIP V5 standards implementation plan be re-inserted into the supply chain implementation plan. 

Additionally, the absence of the “Applicable Facilities” section or other language that clearly indicates these standards/requirements do not apply to “low” entities is missing in the Implementation Plan.  NRECA urges the SDT to add this section the Implementation Plan.

Barry Lawson, 6/14/2017

- 0 - 0

John Williams, 6/15/2017

- 1 - 0

CIP-013 R2 and/or the Implementation Plan should contain “trigger” language for R2 that clarifies an entity must implement its R1 risk management plan(s) for new procurement contracts signed on or after the Effective Date of CIP-013. Entities with no new procurement contracts or no new in-progress procurements on the Effective Date should not be expected to be able to demonstrate compliance with R2 at that time.    

Nicholas Lauriat, Network and Security Technologies, 1, 6/15/2017

- 0 - 0

Melanie Seader, On Behalf of: Edison Electric Institute, NA - Not Applicable, Segments NA - Not Applicable

- 0 - 0

NYPA supports the comments submitted by Salt River Project (WECC) and NPCC.

David Rivera, New York Power Authority, 3, 6/15/2017

- 0 - 0

Thank you for your statement under Initial Performance of Periodic Requirements, that the supply chain security risk management plans need to be approved on or before the effective date of CIP-013-1.

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

- 0 - 0

Comments: NPPD supports the position of the MRO NSRF.

NPPD believes a 24-month implementation should be used due to budgeting and tthe technical implementation requirements for the other CIP Standards.

Don Schmit, 6/15/2017

- 0 - 0

Daniel Gacek, Exelon, 1, 6/15/2017

- 0 - 0

Recommend changing this General Consideration from:

Contracts entering the Responsible Entity's procurement process (e.g. through Request for Proposals) on or after the effective date are within scope of CIP-013-1. Contract effective date, commencement date, or other activation dates specified in the contract do not determine whether the contract is within scope of CIP-013-1.

To:

Supply Chain Risk Management plan must be used by appropriate procurement processes that begin on or after the implementation date. Make corresponding change to the CIP-013 R2 note.

Further, USI requests clarification on if/when existing contracts, master contracts, or long-term maintenance agreements that re-opened for renegotiation or put in use, come into the scope of CIP-013.

The implementation Plan does not handle unplanned changes such as IROLs or registration, etc.  Request that the Implementation Plan be modified to handle entities that meet the applicability after the effective date of the standard.

USI believes  a 24-month implementation should be used due to budget cycles and technical controls for other CIP Standards.

Brian Evans-Mongeon, Utility Services, Inc., 4, 6/15/2017

- 1 - 0

GSOC supports NRECA's Comments of:

NRECA supports the new implementation plan timeframe.  However, this implementation plan unintentionally removes the provisions for additional time to implement unplanned changes in CIP-005 and CIP-010 that was provided in the V5 and V6 implementation plans.  NRECA strongly requests that the language from the “Planned or Unplanned Changes Resulting in a Higher Categorization” section of the CIP V5 standards implementation plan be re-inserted into the supply chain implementation plan. 

Additionally, the absence of the “Applicable Facilities” section or other language that clearly indicates these standards/requirements do not apply to “low” entities is missing in the Implementation Plan.  NRECA urges the SDT to add this section the Implementation Plan.

Guy Andrews, 6/15/2017

- 0 - 0

Laura Nelson, 6/15/2017

- 0 - 0

Heather Morgan, EDP Renewables North America LLC, 5, 6/15/2017

- 0 - 0

MMWEC supports comments submitted by APPA.

David Gordon, 6/15/2017

- 0 - 0

MEAG supports the answers and comments of Salt River Project.

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

- 0 - 0

SPP Standards Review Group, Segment(s) 0, 6/15/2017

- 0 - 0

NRG recommends changing this General Consideration from:

Contracts entering the Responsible Entity's procurement process (e.g. through Request for Proposals) on or after the effective date are within scope of CIP-013-1. Contract effective date, commencement date, or other activation dates specified in the contract do not determine whether the contract is within scope of CIP-013-1.

To

Supply Chain Risk Management plan must be used by the procurement processes that begin on or after the implementation date. Please consider making the corresponding change to the CIP-013 R2 note

 

The Implementation Plan does not appear to address unplanned changes such as IROLs or registration, etc.

 

NRG requests consideration of a 24 month implementation due to budget cycles and technical controls for other CIP Standards

Kara White, On Behalf of: NRG - NRG Energy, Inc., FRCC, MRO, WECC, Texas RE, NPCC, SERC, SPP RE, RF, Segments 3, 4, 5, 6

- 0 - 0

LeRoy Patterson, Public Utility District No. 2 of Grant County, Washington, 6, 6/15/2017

- 0 - 0

Mark Holman, 6/15/2017

- 0 - 0

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

- 0 - 0

Implementation Plan does not handle unplanned changes such as IROLs or registration, etc. Request a 24-month implementation due to budget cycles and technical controls for other CIP Standards

 

 

Jesus Sammy Alcaraz, Imperial Irrigation District, 1, 6/15/2017

- 0 - 0

- 0 - 0

Luminant, Segment(s) 6, 7, 5, 1/24/2017

- 0 - 0

Request a 24 month implementation due to budget cycles and technical controls for other CIP Standards.

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

- 0 - 0

FEUS supports the comments submitted by APPA

Linda Jacobson-Quinn, City of Farmington, 3, 6/15/2017

- 0 - 0

Scott Downey, 6/15/2017

- 0 - 0

- 0 - 0

Disagree with the Implementation Plan.  Standard should have language stating whether or not software installed prior to enforcement must have identify/verification completed.

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

- 0 - 0

- 0 - 0

GRE and the NRECA supports the new implementation plan timeframe.  However, this implementation plan unintentionally removes the provisions for additional time to implement unplanned changes in CIP-005 and CIP-010 that was provided in the V5 and V6 implementation plans.  NRECA strongly requests that the language from the “Planned or Unplanned Changes Resulting in a Higher Categorization” section of the CIP V5 standards implementation plan be re-inserted into the supply chain implementation plan. 

Additionally, the absence of the “Applicable Facilities” section or other language that clearly indicates these standards/requirements do not apply to “low” entities is missing in the Implementation Plan.  NRECA urges the SDT to add this section the Implementation Plan.

Michael Brytowski, Great River Energy, 3, 6/15/2017

- 0 - 0

David Ramkalawan, 6/15/2017

- 0 - 0

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

- 0 - 0

Recommend changing this General Consideration from

Contracts entering the Responsible Entity's procurement process (e.g. through Request for Proposals) on or after the effective date are within scope of CIP-013-1. Contract effective date, commencement date, or other activation dates specified in the contract do not determine whether the contract is within scope of CIP-013-1.

To

Supply Chain Risk Management plan must be used by the procurement processes that begin on or after the implementation date. Make corresponding change to the CIP-013 R2 note

 

Implementation Plan does not handle unplanned changes such as IROLs or registration, etc.

 

Request a 24 months implementation due to budget cycles and technical controls for other CIP Standards

 

Timothy Reyher, 6/15/2017

- 0 - 0

Request a 24 months implementation due to budget cycles and technical controls for other CIP Standards

Recommend changing this General Consideration from

Contracts entering the Responsible Entity's procurement process (e.g. through Request for Proposals) on or after the effective date are within scope of CIP-013-1. Contract effective date, commencement date, or other activation dates specified in the contract do not determine whether the contract is within scope of CIP-013-1.

To

Supply Chain Risk Management plan must be used by the procurement processes that begin on or after the implementation date. Make corresponding change to the CIP-013 R2 note

Implementation Plan does not handle unplanned changes such as IROLs or registration, etc.

Quintin Lee, Eversource Energy, 1, 6/15/2017

- 0 - 0

Yes. Moving the implementation date from 12 to 18 months is consistent with the CIP v5 implementation timeline for implementations. Would low impact BES Cyber Assets that might be in scope in the future have similar implementation timeline or longer?

ACES Standards Collaborators, Segment(s) 1, 3, 4, 5, 6/15/2017

- 0 - 0

Texas RE requests that the SDT provide its rationale for extending the effective date from 12 to 18 months.  For example, it is unclear whether the SDT believes more certainty is required regarding the necessary technical deployments for compliance with the Standard as some commenters suggested to justify the extended implementation period.

Rachel Coyne, Texas Reliability Entity, Inc., 10, 6/15/2017

- 0 - 0

Theresa Rakowsky, 6/15/2017

- 0 - 0

AECI supports NRECA's comments provided below:

NRECA supports the new implementation plan timeframe.  However, this implementation plan unintentionally removes the provisions for additional time to implement unplanned changes in CIP-005 and CIP-010 that was provided in the V5 and V6 implementation plans.  NRECA strongly requests that the language from the “Planned or Unplanned Changes Resulting in a Higher Categorization” section of the CIP V5 standards implementation plan be re-inserted into the supply chain implementation plan. 

Additionally, the absence of the “Applicable Facilities” section or other language that clearly indicates these standards/requirements do not apply to “low” entities is missing in the Implementation Plan.  NRECA urges the SDT to add this section the Implementation Plan.

AECI & Member G&Ts, Segment(s) 1, 6, 5, 3, 4/11/2017

- 0 - 0

Recommend changing this General Consideration from

Contracts entering the Responsible Entity's procurement process (e.g. through Request for Proposals) on or after the effective date are within scope of CIP-013-1. Contract effective date, commencement date, or other activation dates specified in the contract do not determine whether the contract is within scope of CIP-013-1.

To

Supply Chain Risk Management plan must be used by the procurement processes that begin on or after the implementation date. Make corresponding change to the CIP-013 R2 note

 

Implementation Plan does not handle unplanned changes such as IROLs or registration, etc.

 

Request a 24 months implementation due to budget cycles and technical controls for other CIP Standards

RSC no Dominion, Segment(s) 1, 0, 2, 4, 5, 6, 7, 3, 6/15/2017

- 1 - 0

GTC supports NRECA comments:

 

NRECA supports the new implementation plan timeframe.  However, this implementation plan unintentionally removes the provisions for additional time to implement unplanned changes in CIP-005 and CIP-010 that was provided in the V5 and V6 implementation plans.  NRECA strongly requests that the language from the “Planned or Unplanned Changes Resulting in a Higher Categorization” section of the CIP V5 standards implementation plan be re-inserted into the supply chain implementation plan. 

Additionally, the absence of the “Applicable Facilities” section or other language that clearly indicates these standards/requirements do not apply to “low” entities is missing in the Implementation Plan.  NRECA urges the SDT to add this section the Implementation Plan.

Jason Snodgrass, 6/15/2017

- 0 - 0

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

- 0 - 0

SRC + SWG , Segment(s) 2, 3, 1, 0, 6/15/2017

- 0 - 0

Victor Garzon, 6/15/2017

- 0 - 0

Pablo Onate, El Paso Electric Company, 1, 6/15/2017

- 0 - 0

Rhonda Bryant, El Paso Electric Company, 3, 6/15/2017

- 0 - 0

Southern recommends that the SDT consider addressing previous issues with the Implementation Plan versions between CIP V5, V6, V7, etc., where Implementation Plans were “chained” together and there was not an Implementation Plan that contained all the necessary requirements in a single source.  Southern strongly recommends producing a consolidated Implementation Plan.

Southern recommends that NERC and the SDT(s) consider addressing issues with the Implementation Plan versions between CIP V5, V6, V7, and Supply Chain, as Implementation Plans are “chained” together and there is no one Implementation Plan that contains all the necessary requirements in a single source.  Implementation Plans for the CIP standards cover several important areas:

Implementation schedules of new or modified CIP standard requirements.

Implementation schedules for newly identified cyber assets brought into scope with current requirements based on planned or unplanned changes in the BES assets, or those from newly registered NERC entities. (previously known as IPFNICANRE – Implementation Plan for Newly Identified Cyber Assets or Newly Registered Entities)

Implementation schedules for BES Cyber Systems already in scope that change impact levels due to planned or unplanned changes in the BES.

 

As an example, the last page of the Implementation Plan for CIP-003-7 states that CIP-003-6 is retired upon approval of CIP-003-7, yet it chains to the CIP-003-6 Implementation Plan to tell entities how to handle cyber systems that change impact categorization.  The CIP-003-6 implementation plan simply says it replaces parts of the V5 implementation plan for the modified standards in that revision.  Only the V5 plan addresses the 2nd bullet point above.   Responsible Entities are left to unravel three different plans with supply chain adding yet another to get one picture of what is due when and knowing how to handle BES changes that affect cyber system identification and impact categorization.

As we go forward, we need a better solution.  Parts of an implementation plan, such as bullets 2 and 3 above, need to live on indefinitely.  Other parts, such as the schedule of new or modified requirements, need to live until those dates have passed.  Chaining all of this together through numerous documents as the CIP standards continue to evolve and grow to cover new areas is not a sustainable solution that promotes clarity in knowing the compliance obligation in a changing environment.

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

- 0 - 0

Glen Farmer, Avista - Avista Corporation, 5, 6/15/2017

- 0 - 0

Oxy, Segment(s) 7, 5, 9/6/2016

- 0 - 0

Disagree with the Implementation Plan. Standard should have language stating whether or not software installed prior to enforcement must have identify/verification completed.

Teresa Krabe, Lower Colorado River Authority, 5, 6/15/2017

- 0 - 0

Performance requirements are too vague to be auditable. See related comments.

William Harris, Foundation for Resilient Societies, 8, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

John Martinsen, Public Utility District No. 1 of Snohomish County, 4, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Long Duong, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Mark Oens, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Sam Nietfeld, Public Utility District No. 1 of Snohomish County, 5, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Franklin Lu, 6/15/2017

- 0 - 0

ERCOT joins the comments of the IRC.

Elizabeth Axson, 6/15/2017

- 0 - 0

Hot Answers

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

Richard Vine, 6/15/2017

- 0 - 0

- 0 - 0

Other Answers

Randy Buswell, 5/31/2017

- 0 - 0

Bill Watson, On Behalf of: Bill Watson, , Segments 3

- 0 - 0

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

- 0 - 0

Sandra Pacheco, On Behalf of: Silicon Valley Power - City of Santa Clara, , Segments 3, 5

- 0 - 0

Val Ridad, On Behalf of: Silicon Valley Power - City of Santa Clara, , Segments 3, 5

- 0 - 0

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

- 0 - 0

Illinois Municipal Electric Agency supports comments submitted by the American Public Power Association.

Bob Thomas, 6/9/2017

- 0 - 0

CHPD asks that that the term “elements” be included in CIP-013 R1.2 to clearly align with the VSLs for this requirement.

1.2. One or more process(es) for its newly procured BES Cyber Systems that address the following elements, as applicable:”

Haley Sousa, 6/9/2017

- 0 - 0

CHPD asks that that the term “elements” be included in CIP-013 R1.2 to clearly align with the VSLs for this requirement.

1.2. One or more process(es) for its newly procured BES Cyber Systems that address the following elements, as applicable:”

Janis Weddle, 6/9/2017

- 0 - 0

WECC has no issues with the VSLs or VRFs from a CIP Auditor perspective.

Steven Rueckert, Western Electricity Coordinating Council, 10, 6/9/2017

- 0 - 0

CHPD asks that that the term “elements” be included in CIP-013 R1.2 to clearly align with the VSLs for this requirement.

1.2. One or more process(es) for its newly procured BES Cyber Systems that address the following elements, as applicable:” 

Chad Bowman, 6/9/2017

- 0 - 0

: For CIP-013-1, R3, Dominion recommends the following alternate VSL values.

  • Low – No change

  • Moderate – 16-18 calendar days

  • High – greater than 18 calendar days

  • Severe – When a review has never been performed

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

- 0 - 0

CHPD asks that that the term “elements” be included in CIP-013 R1.2 to clearly align with the VSLs for this requirement.

1.2. One or more process(es)  for its newly procured BES Cyber Systems that address the following elements, as applicable:” 

Mick Neshem, 6/12/2017

- 0 - 0

Colorado Springs Utilities supports the comments provided by APPA

Jeff Icke, Colorado Springs Utilities, 5, 6/12/2017

- 0 - 0

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

- 0 - 0

Daniel Grinkevich, 6/12/2017

- 0 - 0

Patrick Hughes, On Behalf of: National Electrical Manufacturers Association, NA - Not Applicable, Segments NA - Not Applicable

- 0 - 0

Shawn Abrams, 6/13/2017

- 0 - 0

No Comment.

Steven Sconce, On Behalf of: EDF Renewable Energy, , Segments 5

- 0 - 0

- 0 - 0

While an important topic, at this time AEP does not agree that risks associated with violations of these draft standards is a “Medium” risk to the BES. AEP recommends the Violation Risk Factor for each of the requirements CIP-013-1 R 1-3 be considered “Lower.”

Thomas Foltz, AEP, 5, 6/13/2017

- 0 - 0

Michael Haff, On Behalf of: Seminole Electric Cooperative, Inc., FRCC, Segments 1, 3, 4, 5, 6

- 0 - 0

We support APPA's comments that the original wording is better than the new redline of the VRF justification.

Allan Long, Memphis Light, Gas and Water Division, 1, 6/13/2017

- 0 - 0

Anthony Jablonski, ReliabilityFirst , 10, 6/13/2017

- 0 - 0

PRPA agrees with the VRFs and VSLs for CIP-010 and CIP-013.  PRPA believes that the VRFs and VSLs for CIP-005 should be updated to reflect the same approach that was taken in CIP-010.  The VSL for CIP-005 results in a severe penalty if the entity did not have a method to determine and did not have a method to disable.  PRPA would prefer a High VSL penalty if the entity has a process to determine but does not have a process to disable and vice-versa if the entity did not have a process to determine but does have a process to disable.

PRPA requests that the term “elements” be included in CIP-013 R1.2 (as shown above) to clearly align with the VSLs for this requirement.

Tyson Archie, Platte River Power Authority, 5, 6/14/2017

- 0 - 0

Amelia Sawyer Anderson, On Behalf of: CenterPoint Energy Houston Electric, LLC, Texas RE, Segments 1

- 0 - 0

- 0 - 0

W. Dwayne Preston, Austin Energy, 3, 6/14/2017

- 0 - 0

Lauren Price, 6/14/2017

- 0 - 0

 

SMUD agrees with the VRFs and VSLs for CIP-010 and CIP-013.  SMUD believes that the VRFs and VSLs for CIP-005 should be updated to reflect the same approach that was taken in CIP-010.  The VSL for CIP-005 results in a severe penalty if the entity did not have a method to determine and did not have a method to disable.  SMUD would prefer a High VSL penalty if the entity has a process to determine but does not have a process to disable and vice-versa if the entity did not have a process to determine but does have a process to disable.

 

 

 

SMUD requests that the term “elements” be included in CIP-013 R1.2 (as shown above) to clearly align with the VSLs for this requirement.

 

- 0 - 0

AE agrees with the VRFs and VSLs for CIP-010 and CIP-013.  AE believes the VRFs and VSLs for CIP-005 should be updated to reflect the same approach taken in CIP-010.  The VSL for CIP-005 results in a severe penalty if an entity does not have a method to determine and does not have a method to disable.  AE would prefer a High VSL penalty if the entity has a process to determine but does not have a process to disable and vice-versa if the entity did not have a process to determine but does have a process to disable.

AE requests the term “elements” be included in CIP-013 R1.2 (as shown above) to clearly align with the VSLs for this requirement.

Andrew Gallo, 6/14/2017

- 0 - 0

BC Hydro, Segment(s) 1, 2, 3, 5, 5/6/2015

- 0 - 0

The VSL for R2 only provides for a Severe VLS. It is unclear what is meant by "did not implement". If your plan has 5 areas within it and 4 of the 5 were fully implemented, has the plan been implemented? I contend yes however not fully implemented. The VSL were created to identify how far of the complaince mark an entitiy fell. This VLS completly fails to perform this action. While at the same time the VSL for R3 utilizes arbitrary calendar months for clear VLS seperation between lower and severe. Both of these VLS provide little benefit to industry in assessing the real impact to the BES based on an entity missing the complaince mark.

Richard Kinas, 6/14/2017

- 0 - 0

See attached comments

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

2016-03_Unofficial_Comment_Form_SCL_2017-6-14 Final to NERC.docx

- 0 - 0

Normande Bouffard, 6/14/2017

- 0 - 0

Entergy/NERC Compliance, Segment(s) 1, 5, 3/1/2017

- 0 - 0

Theresa Allard, Minnkota Power Cooperative Inc., 1, 6/14/2017

- 0 - 0

SRP agrees with the VRFs and VSLs for CIP-010 and CIP-013.  SRP believes that the VRFs and VSLs for CIP-005 should be updated to reflect the same approach that was taken in CIP-010.  The VSL for CIP-005 results in a severe penalty if the entity did not have a method to determine and did not have a method to disable.  SRP would prefer a High VSL penalty if the entity has a process to determine but does not have a process to disable and vice-versa if the entity did not have a process to determine but does have a process to disable.

SRP requests that the term “elements” be included in CIP-013 R1.2 (as shown above) to clearly align with the VSLs for this requirement.

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

- 0 - 0

YES for CIP-005-6 and CIP-010-3 only

Alex Ybarra, 6/14/2017

- 0 - 0

Wendy Center, U.S. Bureau of Reclamation, 5, 6/14/2017

- 0 - 0

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

- 0 - 0

Andrew Meyers, Bonneville Power Administration, 6, 6/14/2017

- 0 - 0

- 0 - 0

No Comments

Alan Farmer, On Behalf of: ACEC, FRCC, MRO, WECC, Texas RE, NPCC, SERC, SPP RE, RF, Segments NA - Not Applicable

- 0 - 0

Barry Lawson, 6/14/2017

- 0 - 0

John Williams, 6/15/2017

- 1 - 0

Nicholas Lauriat, Network and Security Technologies, 1, 6/15/2017

- 0 - 0

Melanie Seader, On Behalf of: Edison Electric Institute, NA - Not Applicable, Segments NA - Not Applicable

- 0 - 0

NYPA supports the comments submitted by Salt River Project (WECC) and NPCC.

David Rivera, New York Power Authority, 3, 6/15/2017

- 0 - 0

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

- 0 - 0

Don Schmit, 6/15/2017

- 0 - 0

Daniel Gacek, Exelon, 1, 6/15/2017

- 0 - 0

We do not agree with the VRF Justification for CIP-013-1 R1, FERC VRF G5 with the new redline. Agree with the words that were redline out.

CIP-010 – VSL does not cover the failure to implement the process and therefore does not include all of the combinations.  Consequently, we request that there be lower severity levels when a single aspect of the requirements is missing.

Request that that the term “elements” be included in CIP-013 R1.2 (as shown in comments for question 1) to clearly align with the VSLs for this requirement.

Brian Evans-Mongeon, Utility Services, Inc., 4, 6/15/2017

- 1 - 0

Guy Andrews, 6/15/2017

- 0 - 0

Laura Nelson, 6/15/2017

- 0 - 0

Heather Morgan, EDP Renewables North America LLC, 5, 6/15/2017

- 0 - 0

MMWEC supports comments submitted by APPA.

David Gordon, 6/15/2017

- 0 - 0

MEAG supports the answers and comments of Salt River Project.

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

- 0 - 0

SPP Standards Review Group, Segment(s) 0, 6/15/2017

- 0 - 0

None

Kara White, On Behalf of: NRG - NRG Energy, Inc., FRCC, MRO, WECC, Texas RE, NPCC, SERC, SPP RE, RF, Segments 3, 4, 5, 6

- 0 - 0

Yes for CIP-005-6 and CIP-010-3 only

LeRoy Patterson, Public Utility District No. 2 of Grant County, Washington, 6, 6/15/2017

- 0 - 0

There should be lower, moderate and high VSLs for R2, (not implementing portions of the requirement).  PJM suggests using the language in the lower, moderate and high R1 VSLs as a starting point.

Mark Holman, 6/15/2017

- 0 - 0

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

- 0 - 0

Jesus Sammy Alcaraz, Imperial Irrigation District, 1, 6/15/2017

- 0 - 0

- 0 - 0

Luminant, Segment(s) 6, 7, 5, 1/24/2017

- 0 - 0

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

- 0 - 0

FEUS supports the comments submitted by APPA

Linda Jacobson-Quinn, City of Farmington, 3, 6/15/2017

- 0 - 0

Scott Downey, 6/15/2017

- 0 - 0

- 0 - 0

No comment

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

- 0 - 0

- 0 - 0

Michael Brytowski, Great River Energy, 3, 6/15/2017

- 0 - 0

David Ramkalawan, 6/15/2017

- 0 - 0

Duke Energy suggests the drafting team consider implementing a staggered approach to the VSL(s) specifically to CIP-013-1 R2. As written, an entity could implement all aspects but one sub-part of the risk management plan, and the violation would have a VSL of Severe. We recommend the drafting team consider a more equitable approach and stagger the VSL(s) similar to the approach used in R1 of CIP-003-6.

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

- 0 - 0

None

Timothy Reyher, 6/15/2017

- 0 - 0

Quintin Lee, Eversource Energy, 1, 6/15/2017

- 0 - 0

No comments.

ACES Standards Collaborators, Segment(s) 1, 3, 4, 5, 6/15/2017

- 0 - 0

Rachel Coyne, Texas Reliability Entity, Inc., 10, 6/15/2017

- 0 - 0

Theresa Rakowsky, 6/15/2017

- 0 - 0

AECI & Member G&Ts, Segment(s) 1, 6, 5, 3, 4/11/2017

- 0 - 0

None

RSC no Dominion, Segment(s) 1, 0, 2, 4, 5, 6, 7, 3, 6/15/2017

- 1 - 0

Jason Snodgrass, 6/15/2017

- 0 - 0

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

- 0 - 0

The IRC suggests the drafting team add more thresholds to the VSLs for R2 of CIP-013-1 and that it be aligned more closely with that of R1, rather than making it binary.  The cyber security risk management plan will be fairly large and missing small portions of the plan should not immediately result in a Severe VSL.

SRC + SWG , Segment(s) 2, 3, 1, 0, 6/15/2017

- 0 - 0

Victor Garzon, 6/15/2017

- 0 - 0

Pablo Onate, El Paso Electric Company, 1, 6/15/2017

- 0 - 0

Rhonda Bryant, El Paso Electric Company, 3, 6/15/2017

- 0 - 0

No additional comments.

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

- 0 - 0

Glen Farmer, Avista - Avista Corporation, 5, 6/15/2017

- 0 - 0

Oxy, Segment(s) 7, 5, 9/6/2016

- 0 - 0

No comment.

Teresa Krabe, Lower Colorado River Authority, 5, 6/15/2017

- 0 - 0

William Harris, Foundation for Resilient Societies, 8, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

John Martinsen, Public Utility District No. 1 of Snohomish County, 4, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Long Duong, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Mark Oens, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Sam Nietfeld, Public Utility District No. 1 of Snohomish County, 5, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Franklin Lu, 6/15/2017

- 0 - 0

ERCOT joins the comments of the IRC.

Elizabeth Axson, 6/15/2017

- 0 - 0

Q:

7. The SDT developed draft Implementation Guidance for CIP-013 to provide examples of how a Responsible Entity could comply with the requirements. The draft Implementation Guidance does not prescribe the only approach to compliance. Rather, it describes some approaches the SDT believes would be effective ways to comply with the standard. See NERC’s Compliance Guidance policy for information on Implementation Guidance. Do you agree with the example approaches in the draft Implementation Guidance? If you do not agree, or if you agree but have comments or suggestions for the draft Implementation Guidance, please provide your recommendation and explanation.

Hot Answers

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

Richard Vine, 6/15/2017

- 0 - 0

- 0 - 0

Other Answers

Implementation Guidance for R3

Neither main bullet meets compliance because both only deal with the review and not the approval. Recommend changing “Below are some examples of approaches to comply with this requirement:” to “Below is an example of an approach to comply with the review requirement required by:”

Implementation Guidance for R3 –

Recommend removing this language from the second main bullet, since it is beyond the Requirement

“Upon approval of changes to the supply chain cyber security risk management plan(s), the CIP Senior Manager or approved delegate should provide appropriate communications to the affected organizations or individuals. Additionally, communications or training material may be developed to ensure any organizational areas affected by revisions are informed.”

Randy Buswell, 5/31/2017

- 0 - 0

Bill Watson, On Behalf of: Bill Watson, , Segments 3

- 0 - 0

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

- 0 - 0

Sandra Pacheco, On Behalf of: Silicon Valley Power - City of Santa Clara, , Segments 3, 5

- 0 - 0

Val Ridad, On Behalf of: Silicon Valley Power - City of Santa Clara, , Segments 3, 5

- 0 - 0

For consistency and clarity between sub-requirement 1.2.2. and the CIP-013-1 Implementation Guidance, we suggest that “cyber security incident(s)” be removed from the examples for 1.2.2.  This verbiage should be replaced with either “vendor-identified incidents” or “security event(s)” as referenced in the examples for 1.2.1.

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

- 0 - 0

Illinois Municipal Electric Agency supports comments submitted by the American Public Power Association.

Bob Thomas, 6/9/2017

- 0 - 0

CHPD is uncertain if this new approach best provides assurance and guidance about these new Standards in the absence of the “Guidance and Technical Basis” sections in each Standard and the intentional flexibility of CIP-013 in particular. CHPD is concerned about the possibilities that NERC and the Regions (1) may not endorse the separate implementation guidance at all, (2) may not endorse the guidance in a timely manner with regard to balloting, and (3) may withdraw previously-granted endorsement should FERC request revisions to the Standard. As such, CHPD would prefer to see the new “Implementation Guidance Document” supplemented with “Guidance and Technical Basis” sections in each Standard.

Haley Sousa, 6/9/2017

- 0 - 0

CHPD is uncertain if this new approach best provides assurance and guidance about these new Standards in the absence of the “Guidance and Technical Basis” sections in each Standard and the intentional flexibility of CIP-013 in particular. CHPD is concerned about the possibilities that NERC and the Regions (1) may not endorse the separate implementation guidance at all, (2) may not endorse the guidance in a timely manner with regard to balloting, and (3) may withdraw previously-granted endorsement should FERC request revisions to the Standard. As such, CHPD would prefer to see the new “Implementation Guidance Document” supplemented with “Guidance and Technical Basis” sections in each Standard.

Janis Weddle, 6/9/2017

- 0 - 0

The guidance relative to R1.2.2 and R1.2.6 partially address WECC's concerns as stated in Bullet 2 above. In general, the example approaches provide good guidance to industry on ERO expectations for compliance with the various Requirements and Parts. No other issues noted.  

Steven Rueckert, Western Electricity Coordinating Council, 10, 6/9/2017

- 0 - 0

CHPD is uncertain if this new approach best provides assurance and guidance about these new Standards in the absence of the “Guidance and Technical Basis” sections in each Standard and the intentional flexibility of CIP-013 in particular. CHPD is concerned about the possibilities that NERC and the Regions (1) may not endorse the separate implementation guidance at all, (2) may not endorse the guidance in a timely manner with regard to balloting, and (3) may withdraw previously-granted endorsement should FERC request revisions to the Standard. As such, CHPD would prefer to see the new “Implementation Guidance Document” supplemented with “Guidance and Technical Basis” sections in each Standard.

Chad Bowman, 6/9/2017

- 0 - 0

The existing guidance still provides no scope of cyber security risks that should be considered, and without context, many of the proposed actions have no guidelines or measurements for “success” or “failure” or acceptability; nor are there suggested acceptable mitigations if a criterion is not completely met, since there is no clear objective.  Furthermore, there is no allowance made for a continuous process, where, as a result of products already being used in BES Cyber Systems and subjected to the existing CIP standards, cyber security risks associated with networks, products and vendors are evaluated on an on-going basis.  Detailed changes and additions are outlined in a separate redline Draft Implementation Guidance document that has been forwarded to NERC and the SDT.  A summary of the proposals is as follows:

  1. Throughout the document, the term ‘controls’ should be changed to a term that more closely reflects the language in the proposed standard.  Dominion recommends using ‘terms and conditions’.

  2. On page 2, dominion recommends clarifying that cyber security risks are limited to supply chain with the addition of ‘supply chain’ prior to each use of the term cyber security risks.

  3. In addition to the clarifying language in item #2 above, Dominion recommends adding the following to more clearly define the term ‘supply chain cyber security risk:


(1) procuring and installing un-secure equipment or (2) procuring and installing un-secure software, including purchasing counterfeit software, or software that has been modified by an un-authorized party, (3) unintentionally failing to anticipate security issues that may arise due to network architecture, (4) unintentionally failing to anticipate security issues that may arise during technology and vendor transitions for BES Cyber Systems). The additional bullets could be sub-bullets under the appropriate of these four broad areas as examples rather than individual, isolated items.

 

4. Dominion recommends deleting the third paragraph on page 2.  This paragraph appears to be creating new/different obligations. The language appears to create confusion and calls out Section 1.2.5 specifically for no apparent reason.

5. The language in blue boxes throughout the document should be retained and included in the text of the document.

6. It is unclear what the purpose of including certain language in a blue box is.

7. Section headings should be included with each of the examples. Also, the bulleted format makes it unclear if one, all, or a certain number of bulleted items need to be performed to achieve compliance.

8. Add the following example under R1.1:

Develop an approved vendor/products list.  When planning a BCS, the RE should evaluate the following items:

    • Vendors

    • Products

    • Network Architecture

    • Network Components.

 

The RE should document (which may be limited to the baseline and cyber vulnerability assessment (CVA) required for a new product) any risks (i.e. 1) procuring and installing un-secure equipment or (2) procuring and installing un-secure software, including purchasing counterfeit software, or software that has been modified by an un-authorized party, (3) unintentionally failing to anticipate security issues that may arise due to network architecture, (4) unintentionally failing to anticipate security issues that may arise during technology and vendor transitions for BES Cyber Systems) identified and how the risks are mitigated for any “item” that deviates from those vendors, products, network architecture, and network components already being used within the RE’s BCS infrastructures, which are required to comply with existing CIP standards. 

 

9. The second bullet in Section 1.2.2 should be removed.  It is already addressed under Section 1.2.1.

10. In Section 1.2.3, the end of the first bullet could state be clarified as follows:

Delete ‘within a negotiated period of time of such determination’ and replace with “to allow the RE to remove access within 24 hours of the determination, consistent with existing CIP standards”

Replace ‘breaches’ with ‘vulnerabilities’ for clarity and consistency’.

 

 

 

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

- 0 - 0

CHPD is uncertain if this new approach best provides assurance and guidance about these new Standards in the absence of the “Guidance and Technical Basis” sections in each Standard and the intentional flexibility of CIP-013 in particular. CHPD is concerned about the possibilities that NERC and the Regions (1) may not endorse the separate implementation guidance at all, (2) may not endorse the guidance in a timely manner with regard to balloting, and (3) may withdraw previously-granted endorsement should FERC request revisions to the Standard. As such, CHPD would prefer to see the new “Implementation Guidance Document” supplemented with “Guidance and Technical Basis” sections in each Standard.

Mick Neshem, 6/12/2017

- 0 - 0

Colorado Springs Utilities supports the comments provided by APPA

Jeff Icke, Colorado Springs Utilities, 5, 6/12/2017

- 0 - 0

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

- 0 - 0

Daniel Grinkevich, 6/12/2017

- 0 - 0

Patrick Hughes, On Behalf of: National Electrical Manufacturers Association, NA - Not Applicable, Segments NA - Not Applicable

- 0 - 0

The intent and purpose of CIP-013 is very dependent upon the Implementation Guidance document.  We appreciate the hard work of the SDT to provide this document to industry and it has valuable information.  Additionally, there is no guarantee this document will be approved by NERC.

Shawn Abrams, 6/13/2017

- 0 - 0

No comment.

Steven Sconce, On Behalf of: EDF Renewable Energy, , Segments 5

- 0 - 0

- 0 - 0

Thomas Foltz, AEP, 5, 6/13/2017

- 0 - 0

The Implementation Guidance only identifies items that could be evaluated in developintg a Supply Chain Cyber Security program, but does not provide an example or guidance on how to implement the program.  Without this guidance, it is impossible to understand how to comply with CIP-013-1 in a cost-effective and compliant manner.

Michael Haff, On Behalf of: Seminole Electric Cooperative, Inc., FRCC, Segments 1, 3, 4, 5, 6

- 0 - 0

We agree with APPA's submitted comments concerning "vendor" not being a NERC-defined term and that the Implementation Guidance for R3 does not adequately explain compliance needs.

Allan Long, Memphis Light, Gas and Water Division, 1, 6/13/2017

- 0 - 0

Anthony Jablonski, ReliabilityFirst , 10, 6/13/2017

- 0 - 0

PRPA generally agrees with the Implementation Guidance for CIP-013 and feels that this is a promising new approach but is uncertain if the approach best provides assurance and guidance about these new Standards in the absence of the “Guidance and Technical Basis” sections in each Standard and the intentional flexibility of CIP-013 in particular. PRPA is concerned about the possibilities that NERC and the Regions (1) may not endorse the separate implementation guidance at all, (2) may not endorse the guidance in a timely manner as regards balloting, and (3) may withdraw previously-granted endorsement should FERC request revisions to the Standard. As such, PRPA would prefer to see the new “Implementation Guidance Document” supplemented with “Guidance and Technical Basis” sections in each Standard.

R3: PRPA requests that the following language be removed from the second main bullet, since it is out of scope for this Requirement. “Upon approval of changes to the supply chain cyber security risk management plan(s), the CIP Senior Manager or approved delegate should provide appropriate communications to the affected organizations or individuals. Additionally, communications or training material may be developed to ensure any organizational areas affected by revisions are informed.”

Request that there be corresponding “Guidelines and Technical Basis” or “Rationale” for CIP-005-6 Requirement R2 Parts 2.4 and 2.5 and CIP-010-3 R1.6.

Tyson Archie, Platte River Power Authority, 5, 6/14/2017

- 0 - 0

In the guidance for Requirement R1, Part 1.2.5, CenterPoint Energy believes including all third-party hardware, software, firmware, and services goes beyond the scope of the requirement.  Most systems consist of components or services from numerous third-party companies.  The vendor of such systems may not have direct contact with third-party companies.  The level of third-party components or services that could be expected to be included may be quite extensive and therefore make it impractical for the vendor to commit to such issues in contract provisions.

Amelia Sawyer Anderson, On Behalf of: CenterPoint Energy Houston Electric, LLC, Texas RE, Segments 1

- 0 - 0

- 0 - 0

W. Dwayne Preston, Austin Energy, 3, 6/14/2017

- 0 - 0

Lauren Price, 6/14/2017

- 0 - 0

 

SMUD generally agrees with the Implementation Guidance for CIP-013 and feels that this is a promising new approach but is uncertain if the approach best provides assurance and guidance about these new Standards in the absence of the “Guidance and Technical Basis” sections in each Standard and the intentional flexibility of CIP-013 in particular. SMUD is concerned about the possibilities that NERC and the Regions (1) may not endorse the separate implementation guidance at all, (2) may not endorse the guidance in a timely manner as regards balloting, and (3) may withdraw previously-granted endorsement should FERC request revisions to the Standard. As such, SMUD would prefer to see the new “Implementation Guidance Document” supplemented with “Guidance and Technical Basis” sections in each Standard.

 

 

 

 

 

R3: SMUD requests that the following language be removed from the second main bullet, since it is out of scope for this Requirement. “Upon approval of changes to the supply chain cyber security risk management plan(s), the CIP Senior Manager or approved delegate should provide appropriate communications to the affected organizations or individuals. Additionally, communications or training material may be developed to ensure any organizational areas affected by revisions are informed.”

 

 

 

SMUD also requests that there be corresponding “Guidelines and Technical Basis” or “Rationale” for CIP-005-6 Requirement R2 Parts 2.4 and 2.5 and CIP-010-3 R1.6.

 

- 0 - 0

AE is uncertain if the approach best provides assurance and guidance about these new Standards in the absence of the “Guidance and Technical Basis” sections in each Standard and the intentional flexibility of CIP-013 in particular. AE has concerns about the possibilities NERC and the Regions: (1) may not endorse the separate implementation guidance at all, (2) may not endorse the guidance in a timely manner, and (3) may withdraw previously-granted endorsement should FERC request revisions to the Standard. As such, AE would prefer to see the new “Implementation Guidance Document” supplemented with “Guidance and Technical Basis” sections in each Standard.

R3: AE requests the following language be removed from the second main bullet, because it is out-of-scope for this Requirement:

"Upon approval of changes to the supply chain cyber security risk management plan(s), the CIP Senior Manager or approved delegate should provide appropriate communications to the affected organizations or individuals. Additionally, communications or training material may be developed to ensure any organizational areas affected by revisions are informed.”

AE requests there be corresponding “Guidelines and Technical Basis” or “Rationale” for CIP-005-6 Requirement R2, Parts 2.4 and 2.5 and CIP-010-3 R1.6.

Andrew Gallo, 6/14/2017

- 0 - 0

BC Hydro does not agree with the examples as compliance will be challenging. It would require us to have sufficient authority over the vendor (which will not be the case in most situations). There is also no way to ensure that a vendor is being completely transparent regarding cyber vulnerabilities in their product. Such disclosure could have other impacts on their business with other clients. This would be a dis-incentive for disclosure. BC Hydro does not believes CIP-013 is necessary and cyber control is  already achieved with the rest of the CIP v5 standard requirements around change control, testing and ongoing systems monitoring.

 

BC Hydro, Segment(s) 1, 2, 3, 5, 5/6/2015

- 0 - 0

Richard Kinas, 6/14/2017

- 0 - 0

See attached comments.

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

2016-03_Unofficial_Comment_Form_SCL_2017-6-14 Final to NERC.docx

- 0 - 0

Make sure the Compliance Guidance is in the scope of standards.

Normande Bouffard, 6/14/2017

- 0 - 0

As mentioned in previous comments, this document provides implementation guidance on CIP-013, but additional guidance on implementation of the CIP-010 and CIP-005 controls is requested, perhaps in the Supplemental Material sections.  Particularly CIP-005 R2.

Entergy/NERC Compliance, Segment(s) 1, 5, 3/1/2017

- 0 - 0

Theresa Allard, Minnkota Power Cooperative Inc., 1, 6/14/2017

- 0 - 0

SRP generally agrees with the Implementation Guidance for CIP-013 and feels that this is a promising new approach but is uncertain if the approach best provides assurance and guidance about these new Standards in the absence of the “Guidance and Technical Basis” sections in each Standard and the intentional flexibility of CIP-013 in particular. SRP is concerned about the possibilities that NERC and the Regions (1) may not endorse the separate implementation guidance at all, (2) may not endorse the guidance in a timely manner as regards balloting, and (3) may withdraw previously-granted endorsement should FERC request revisions to the Standard. As such, SRP would prefer to see the new “Implementation Guidance Document” supplemented with “Guidance and Technical Basis” sections in each Standard.

R3: SRP requests that the following language be removed from the second main bullet, since it is out of scope for this Requirement. “Upon approval of changes to the supply chain cyber security risk management plan(s), the CIP Senior Manager or approved delegate should provide appropriate communications to the affected organizations or individuals. Additionally, communications or training material may be developed to ensure any organizational areas affected by revisions are informed.”

Request that there be corresponding “Guidelines and Technical Basis” or “Rationale” for CIP-005-6 Requirement R2 Parts 2.4 and 2.5 and CIP-010-3 R1.6.

 

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

- 0 - 0

Alex Ybarra, 6/14/2017

- 0 - 0

It is uncertain when purchasing activities become subject to CIP-013-1. The proposed Implementation Plan states: “Contracts entering the Responsible Entity's procurement process (e.g. through Request for Proposals) on or after the effective date are within scope of CIP-013-1. Contract effective date, commencement date, or other activation dates specified in the contract do not determine whether the contract is within scope of CIP-013-1.”

 

Reclamation recommends that the “General Considerations” guidance contained in the Implementation Plan pertaining to purchasing activities be included in the proposed standard.

 

If the “General Considerations” guidance on purchasing activities becomes part of the proposed standard, Reclamation further recommends:

  • A contract becomes within scope when the entity commences its formal contract process such as when a request for proposal or solicitation is issued.

  • Any direct purchase and/or any repurposed equipment is within scope prior to connecting to the Bulk Electric System as a cyber asset.

Wendy Center, U.S. Bureau of Reclamation, 5, 6/14/2017

- 0 - 0

There is inconsistency between the Implementation Guidance and CIP-010, R1. The requirement states “For a change that deviates from the existing baseline configuration associated with baseline items in Parts 1.1.1, 1.1.2, and 1.1.5”. The Guidelines and Technical Basis section heading Software and Authenticity, paragraph three on page 39, states: “It is not the intent of the SDT to require a verification of each source or software update at the time it is obtained. It is sufficient to establish the reliable source and software update once. This will allow automated solutions to be implemented to obtain frequent updates such as patches.”

 

The requirement wording suggests it applies for any change but the Guidance suggests that for some changes, such as patches, it would not apply.  Oncor believes that automated patch deployment solutions should be able to verify the identity and integrity of the patch. Therefore, it is believed that the best solution is to modify the Guidance.

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

- 0 - 0

Yes, and BPA disagrees with the language in Requirement R3 requiring the CIP Senior Manager or delegate approve the supply chain cyber security risk management plans.  Other CIP standards, such as CIP-003-6, Requirement R1, require CIP Senior Manager approval of “policies,” not “plans.”  In Order No. 829, the Federal Energy Regulatory Commission stated, “Consistent with or similar to the requirement in Reliability Standard CIP-003-6, Requirement R1, the Reliability Standard should require the responsible entity’s CIP Senior Manager to review and approve the controls adopted to meet the specific security objectives identified in the Reliability Standard at least every 15 months.”  Order No. 829 at P46 (emphasis added).  Requiring CIP Senior Manager approval of plans is not consistent or similar to requiring approval of policies because plans are more tactical and numerous than policies.  CIP Senior Manager approval should apply only to overarching strategic documents, and not to approval of highly detailed plans for implementation of processes.  Instead, CIP-013 should be added to the list of policies requiring CIP Senior Manager approval in CIP-003-6, Requirement R1. 

Andrew Meyers, Bonneville Power Administration, 6, 6/14/2017

- 0 - 0

- 0 - 0

While in overall agreement with the Implementation Guidance for CIP-013, ACEC does have the following concern:

In the Implementation Guidance for R1 Section of the document, the subsections for implementation of Requirement R1 Parts 1.2.1, 1.2.2, 1.2.4 and 1.2.5 use the generic term “vendor(s)” in discussing these Software Authenticity and Integrity issues. To help in ensuring that these requirements are implemented in an effective manner, it is recommended that the SDT add a clarification item, noting that these requirements be addressed by the OEM providing the hardware and/or software, not a third-party such as an integrator.

Alan Farmer, On Behalf of: ACEC, FRCC, MRO, WECC, Texas RE, NPCC, SERC, SPP RE, RF, Segments NA - Not Applicable

- 0 - 0

Barry Lawson, 6/14/2017

- 0 - 0

John Williams, 6/15/2017

- 1 - 0

N&ST has no disagreement with the example approaches contained in the Guidance but believes that while they may represent reasonable courses of action for large entities, they are likely to be far beyond the capabilities of small ones. N&ST believes an entity whose combined BES operations, OT support, and CIP compliance teams comprise fewer than 10 individuals would be hard-pressed to “form a team of subject matter experts from across the organization to participate in the BES Cyber System planning and acquisition process(es).” N&ST also believes, based on experience with CIP V1 – V5 cyber security training requirements, that large vendors with many BES customers will balk, sooner or later, at being asked to respond to a multitude of risk assessment requests, questionnaires, meetings, etc., each one different from the previous ones, and will instead incline towards providing a standardized set of information about their internal risk management programs and how they are applied to their products and services.  

Nicholas Lauriat, Network and Security Technologies, 1, 6/15/2017

- 0 - 0

Melanie Seader, On Behalf of: Edison Electric Institute, NA - Not Applicable, Segments NA - Not Applicable

- 0 - 0

NYPA supports the comments submitted by Salt River Project (WECC) and NPCC.

David Rivera, New York Power Authority, 3, 6/15/2017

- 0 - 0

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

- 0 - 0

Don Schmit, 6/15/2017

- 0 - 0

Exelon thanks the SDT for submitting the draft Implementation Guidance for CIP-013.  Does the SDT also intend the develop draft Implementation Guidance for the revised/added sections of CIP-005 and CIP-010?  If so, is there a timeline that can be shared with Industry participants?

Daniel Gacek, Exelon, 1, 6/15/2017

- 0 - 0

Definition of vendor is not a NERC defined term. The term “vendor” is also used in the proposed CIP-005.

USI believes the SDT should provide guidance regarding the use of the term “vendor.”  If “Vendor” is not defined by NERC, the Guidance should recommend that Entities include their definition of “vendor” in their plan(s).

Implementation Guidance for R3

Neither main bullet meets compliance because both only deal with the review and not the approval. Therefore, USI recommends changing: ”Below are some examples of approaches to comply with this requirement: “ to “Below is an example of an approach to comply with the review requirement required by: “

In addition, we recommend removing this language from the second main bullet, since it is beyond the Requirement:

“Upon approval of changes to the supply chain cyber security risk management plan(s), the CIP Senior Manager or approved delegate should provide appropriate communications to the affected organizations or individuals. Additionally, communications or training material may be developed to ensure any organizational areas affected by revisions are informed.”

Also,  there should be corresponding “Guidelines and Technical Basis” or “Rationale” for CIP-005-6 Requirement R2 Parts 2.4 and 2.5.

Brian Evans-Mongeon, Utility Services, Inc., 4, 6/15/2017

- 1 - 0

Guy Andrews, 6/15/2017

- 0 - 0

Laura Nelson, 6/15/2017

- 0 - 0

  • The language within the Implementation Guidance contradicts the language within CIP-013. (i.e. System-based approach). The Implementation Guidance is not auditable, however, the Standard and Requirements are. EDPR NA suggests that the Implementation Guidance is eliminated and further support are provided within the Measures for a Registered Entity and auditor’s reference.

  • There are numerous items in which vendors will not provide information on unless an entity is willing pay significant increases (risks, training, methodologies, threats, etc.)

  • EDPR NA also suggests that NERC utilize a pilot program to test these requirements prior to enforcing the implementation of CIP-013 to all Registered Entities.

  • Please provide more support with respect to the expectations and possible evidence for Requirement 2.

 

 

Heather Morgan, EDP Renewables North America LLC, 5, 6/15/2017

- 0 - 0

MMWEC supports comments submitted by APPA.

David Gordon, 6/15/2017

- 0 - 0

MEAG supports the answers and comments of Salt River Project.

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

- 0 - 0

There appears to be inconsistency between the requirement and the Guidelines in CIP-010 R1.

The requirement states, in relevant part, “For a change that deviates from the existing baseline configuration associated with baseline items in Parts 1.1.1, 1.1.2, and 1.1.5.”

The Guidelines and Technical Basis section heading “Software and Authenticity,” paragraph three on page 39, states: “It is not the intent of the SDT to require a verification of each source or software update at the time it is obtained. It is sufficient to establish the reliable source and software update once. This will allow automated solutions to be implemented to obtain frequent updates such as patches.” The wording of the CIP-10-3 R1.6 Guidelines and Technical Basis section seems to imply that every time a patch/software is downloaded it does not have to be checked.    Based on how the standard is written, the software source and the software must be verified each time something is downloaded.  Even if that software was previously downloaded, the source must be validated and so must the software before application.

Furthermore, the requirement wording suggests it applies for any change but the Guidelines suggests that for some changes, such as patches, it would not apply. As the requirement is auditable and the Guidelines are not, the Guidelines become superfluous. The Guideline also introduces significant ambiguity that is impossible to audit.  SPP recommends that the SDT review the Guidelines and the draft standard for consistency and resolution.

In addition, SPP recommends that because automated patch deployment solutions should be able to verify the identity and integrity of the patch, the SDT consider allowing for this method of verification in the Measures or Guidelines.

SPP notes that there is no corresponding “Guidelines and Technical Basis” or “Rationale” for CIP-005-6 Requirement R2 Parts 2.4 and 2.5.

 

 

 

SPP Standards Review Group, Segment(s) 0, 6/15/2017

- 0 - 0

NRG has concerns that the Implementation Guidance for R3 (main bullet) may not meet compliance because both only deal with the review and not the approval. NRG recommends that the NERC SDT consider changing “Below are some examples of approaches to comply with this requirement:” to “Below is an example of an approach to comply with the review requirement required by:”

 

NRG has concerns that the Implementation Guidance for R3 – (specifically):

 “Upon approval of changes to the supply chain cyber security risk management plan(s), the CIP Senior Manager or approved delegate should provide appropriate communications to the affected organizations or individuals. Additionally, communications or training material may be developed to ensure any organizational areas affected by revisions are informed.”

Therefore, NRG recommends that the NERC SDT consider removing this language from the second main bullet, since it is beyond the Requirement.

 

 

There appears to be inconsistency between the requirement and the Guidelines in CIP-010 R1.

 

The requirement states, in relevant part, “For a change that deviates from the existing baseline configuration associated with baseline items in Parts 1.1.1, 1.1.2, and 1.1.5.”

 

The Guidelines and Technical Basis section heading “Software and Authenticity,” paragraph three on page 39, states: “It is not the intent of the SDT to require a verification of each source or software update at the time it is obtained. It is sufficient to establish the reliable source and software update once. This will allow automated solutions to be implemented to obtain frequent updates such as patches.” The wording of the CIP-10-3 R1.6 Guidelines and Technical Basis section seems to imply that every time a patch/software is downloaded it does not have to be checked.    Based on how the standard is written, the software source and the software must be verified each time something is downloaded.  Even if that software was previously downloaded, the source must be validated and so must the software before application.

 

Furthermore, the requirement wording suggests it applies for any change but the Guidelines suggests that for some changes, such as patches, it would not apply. As the requirement is auditable and the Guidelines are not, the Guidelines become superfluous. The Guideline also introduces significant ambiguity that is impossible to audit.  NRG recommends that the SDT review the Guidelines and the draft standard for consistency and resolution.

 

In addition, NRG recommends that because automated patch deployment solutions should be able to verify the identity and integrity of the patch, the SDT consider allowing for this method of verification in the Measures or Guidelines.

 

NRG notes that there is no corresponding “Guidelines and Technical Basis” or “Rationale” for CIP-005-6 Requirement R2 Parts 2.4 and 2.5.

Kara White, On Behalf of: NRG - NRG Energy, Inc., FRCC, MRO, WECC, Texas RE, NPCC, SERC, SPP RE, RF, Segments 3, 4, 5, 6

- 0 - 0

The requirements aren’t vetted enough to make a fair judgement.

LeRoy Patterson, Public Utility District No. 2 of Grant County, Washington, 6, 6/15/2017

- 0 - 0

As stated in the CIP-013 comments in question 1 above, the guidance needs to clarify what constitutes an incident (such as only actual breaches).

Mark Holman, 6/15/2017

- 0 - 0

Yes, and BPA disagrees with the language in Requirement R3 requiring the CIP Senior Manager or delegate approve the supply chain cyber security risk management plans.  Other CIP standards, such as CIP-003-6, Requirement R1, require CIP Senior Manager approval of “policies,” not “plans.”  In Order No. 829, the Federal Energy Regulatory Commission stated, “Consistent with or similar to the requirement in Reliability Standard CIP-003-6, Requirement R1, the Reliability Standard should require the responsible entity’s CIP Senior Manager to review and approve the controls adopted to meet the specific security objectives identified in the Reliability Standard at least every 15 months.”  Order No. 829 at P46 (emphasis added).  Requiring CIP Senior Manager approval of plans is not consistent or similar to requiring approval of policies because plans are more tactical and numerous than policies.  CIP Senior Manager approval should apply only to overarching strategic documents, and not to approval of highly detailed plans for implementation of processes.  Instead, CIP-013 should be added to the list of policies requiring CIP Senior Manager approval in CIP-003-6, Requirement R1. 

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

- 0 - 0

The understanding of the intent and purpose of CIP-013 is very dependent on the Implementation Guidance document.  We are concerned about the possibilities that NERC and the Regions (1) may not endorse the separate implementation guidance at all, (2) may not endorse the guidance in a timely manner as regards balloting, and (3) may withdraw previously-granted endorsement should FERC request revisions to the Standard. As such we would prefer to see the new “Implementation Guidance Document” supplemented with “Guidance and Technical Basis” sections in each Standard.

Jesus Sammy Alcaraz, Imperial Irrigation District, 1, 6/15/2017

- 0 - 0

- 0 - 0

Luminant, Segment(s) 6, 7, 5, 1/24/2017

- 0 - 0

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

- 0 - 0

FEUS supports the comments submitted by APPA

Linda Jacobson-Quinn, City of Farmington, 3, 6/15/2017

- 0 - 0

Scott Downey, 6/15/2017

- 0 - 0

ITC Holdings agrees with the below comment submitted by SPP:

There appears to be inconsistency between the requirement and the Guidelines in CIP-010 R1.

The requirement states, in relevant part, “For a change that deviates from the existing baseline configuration associated with baseline items in Parts 1.1.1, 1.1.2, and 1.1.5.”

The Guidelines and Technical Basis section heading “Software and Authenticity,” paragraph three on page 39, states: “It is not the intent of the SDT to require a verification of each source or software update at the time it is obtained. It is sufficient to establish the reliable source and software update once. This will allow automated solutions to be implemented to obtain frequent updates such as patches.” The wording of the CIP-10-3 R1.6 Guidelines and Technical Basis section seems to imply that every time a patch/software is downloaded it does not have to be checked.    Based on how the standard is written, the software source and the software must be verified each time something is downloaded.  Even if that software was previously downloaded, the source must be validated and so must the software before application.

Furthermore, the requirement wording suggests it applies for any change but the Guidelines suggests that for some changes, such as patches, it would not apply. As the requirement is auditable and the Guidelines are not, the Guidelines become superfluous. The Guideline also introduces significant ambiguity that is impossible to audit.  SPP recommends that the SDT review the Guidelines and the draft standard for consistency and resolution.

In addition, SPP recommends that because automated patch deployment solutions should be able to verify the identity and integrity of the patch, the SDT consider allowing for this method of verification in the Measures or Guidelines.

SPP notes that there is no corresponding “Guidelines and Technical Basis” or “Rationale” for CIP-005-6 Requirement R2 Parts 2.4 and 2.5.

- 0 - 0

No comment

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

- 0 - 0

- 0 - 0

Michael Brytowski, Great River Energy, 3, 6/15/2017

- 0 - 0

David Ramkalawan, 6/15/2017

- 0 - 0

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

- 0 - 0

Implementation Guidance for R3

Neither main bullet meets compliance because both only deal with the review and not the approval. Recommend changing “Below are some examples of approaches to comply with this requirement:” to “Below is an example of an approach to comply with the review requirement required by:”

 

Implementation Guidance for R3 –

Recommend removing this language from the second main bullet, since it is beyond the Requirement

“Upon approval of changes to the supply chain cyber security risk management plan(s), the CIP Senior Manager or approved delegate should provide appropriate communications to the affected organizations or individuals. Additionally, communications or training material may be developed to ensure any organizational areas affected by revisions are informed.”

Timothy Reyher, 6/15/2017

- 0 - 0

The Guidance for CIP-013-1 R3 should include the term ‘approved’ since an Entity wouldn’t comply with the requirement with just a review.

 

Quintin Lee, Eversource Energy, 1, 6/15/2017

- 0 - 0

Yes, the Compliance Guidance policy does provide industry with direction for implementation. However, those guidance details are not written in the requirements, measures or Reliability Standard Audit Worksheet (RSAW) and cannot be relied upon in preparation of an audit. ACES would suggest, at a minimum, that these guidelines be written in the Supply Chain Management RSAWs in the section ‘Notes for an Auditor’. By placing this information in the RSAW, it gives industry additional reassurance that each region will audit Supply Chain Management consistently. 

ACES Standards Collaborators, Segment(s) 1, 3, 4, 5, 6/15/2017

- 0 - 0

Rachel Coyne, Texas Reliability Entity, Inc., 10, 6/15/2017

- 0 - 0

Theresa Rakowsky, 6/15/2017

- 0 - 0

AECI & Member G&Ts, Segment(s) 1, 6, 5, 3, 4/11/2017

- 0 - 0

Implementation Guidance for R3

Neither main bullet meets compliance because both only deal with the review and not the approval. Recommend changing “Below are some examples of approaches to comply with this requirement:” to “Below is an example of an approach to comply with the review requirement required by:”

 

Implementation Guidance for R3 –

Recommend removing this language from the second main bullet, since it is beyond the Requirement

“Upon approval of changes to the supply chain cyber security risk management plan(s), the CIP Senior Manager or approved delegate should provide appropriate communications to the affected organizations or individuals. Additionally, communications or training material may be developed to ensure any organizational areas affected by revisions are informed.”

RSC no Dominion, Segment(s) 1, 0, 2, 4, 5, 6, 7, 3, 6/15/2017

- 1 - 0

Jason Snodgrass, 6/15/2017

- 0 - 0

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

- 0 - 0

SRC + SWG , Segment(s) 2, 3, 1, 0, 6/15/2017

- 0 - 0

Victor Garzon, 6/15/2017

- 0 - 0

Pablo Onate, El Paso Electric Company, 1, 6/15/2017

- 0 - 0

Rhonda Bryant, El Paso Electric Company, 3, 6/15/2017

- 0 - 0

No additional comments.

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

- 0 - 0

Glen Farmer, Avista - Avista Corporation, 5, 6/15/2017

- 0 - 0

Oxy, Segment(s) 7, 5, 9/6/2016

- 0 - 0

No comment.

Teresa Krabe, Lower Colorado River Authority, 5, 6/15/2017

- 0 - 0

William Harris, Foundation for Resilient Societies, 8, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

John Martinsen, Public Utility District No. 1 of Snohomish County, 4, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Long Duong, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Mark Oens, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Sam Nietfeld, Public Utility District No. 1 of Snohomish County, 5, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Franklin Lu, 6/15/2017

- 0 - 0

ERCOT joins the comments of the IRC.

Elizabeth Axson, 6/15/2017

- 0 - 0

Hot Answers

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

Richard Vine, 6/15/2017

- 0 - 0

Avista agrees with the SDT’s belief that the proposed CIP-013-1 and the ERO Enterprise-Endorsed Implementation Guidance provide entities with flexibility to meet the reliability objectives in a cost effective manner.  However, the cost effectiveness of the standard will ultimately depend on how Responsible Entities implement the standard and how NERC and the Regional Entities enforce the requirements. 

In addition to the Implementation Guidance, the policy guidance that NERC staff and the Standards Committee are drafting to clarify the principles, development, and use of the Guidelines and Technical Basis will also be very important to how Responsible Entities implement the requirements.

- 0 - 0

Other Answers

Randy Buswell, 5/31/2017

- 0 - 0

Bill Watson, On Behalf of: Bill Watson, , Segments 3

- 0 - 0

Implementing action plans to meet reliability objectives should be cost effective, but cost effectiveness is different for each entity. Reasonable expectations of what’s determined as “cost effectiveness” should be considered on an individual utility/entity basis.

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

- 0 - 0

Sandra Pacheco, On Behalf of: Silicon Valley Power - City of Santa Clara, , Segments 3, 5

- 0 - 0

Val Ridad, On Behalf of: Silicon Valley Power - City of Santa Clara, , Segments 3, 5

- 0 - 0

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

- 0 - 0

Illinois Municipal Electric Agency supports comments submitted by the American Public Power Association.

Bob Thomas, 6/9/2017

- 0 - 0

CHPD believes that the language proposed in CIP-013-1 Draft 2 will result in vendor costs that outweigh, or possibly reverse, the current security and reliability of the BES. Vendors are likely to (1) significantly increase quoted implementation costs, (2) counter terms with alternate language that may not comply with the Standard, or (3) elect to no longer do business with small-to-medium sized entities due to added contractual complexity.

Vendors are not subject to enforcement and therefore should not be identified in any CIP Standards.  As a result, CHPD proposes that the requirements be written in a less prescriptive manner that enables entities responsible for CIP-013 compliance to have control over the process through the use of performance-based activities.

The performance-based assessment requirements would be improved if worded in a way that allows the acceptance of any outcome reached by each Responsible Entity (e.g., “Each Responsible Entity shall <insert performance activity> and document the results of the assessment.”). The intent should be to create a dialog between the entities and vendors on these topics rather than just documented within contractual language.

Haley Sousa, 6/9/2017

- 0 - 0

CHPD believes that the language proposed in CIP-013-1 Draft 2 will result in vendor costs that outweigh, or possibly reverse, the current security and reliability of the BES. Vendors are likely to (1) significantly increase quoted implementation costs, (2) counter terms with alternate language that may not comply with the Standard, or (3) elect to no longer do business with small-to-medium sized entities due to added contractual complexity.

Vendors are not subject to enforcement and therefore should not be identified in any CIP Standards.  As a result, CHPD proposes that the requirements be written in a less prescriptive manner that enables entities responsible for CIP-013 compliance to have control over the process through the use of performance-based activities.

The performance-based assessment requirements would be improved if worded in a way that allows the acceptance of any outcome reached by each Responsible Entity (e.g., “Each Responsible Entity shall and document the results of the assessment.”). The intent should be to create a dialog between the entities and vendors on these topics rather than just documented within contractual language.

Janis Weddle, 6/9/2017

- 0 - 0

WECC concurs the draft of CIP-013-1 and the draft Implementation Guidance provide the flexibility sought by industry in its collective comments to the first ballot.  

Steven Rueckert, Western Electricity Coordinating Council, 10, 6/9/2017

- 0 - 0

CHPD believes that the language proposed in CIP-013-1 Draft 2 will result in vendor costs that outweigh, or possibly reverse, the current security and reliability of the BES. Vendors are likely to (1) significantly increase quoted implementation costs, (2) counter terms with alternate language that may not comply with the Standard, or (3) elect to no longer do business with small-to-medium sized entities due to added contractual complexity.

 

Vendors are not subject to enforcement and therefore should not be identified in any CIP Standards.  As a result, CHPD proposes that the requirements be written in a less prescriptive manner that enables entities responsible for CIP-013 compliance to have control over the process through the use of performance-based activities.

 

The performance-based assessment requirements would be improved if worded in a way that allows the acceptance of any outcome reached by each Responsible Entity (e.g., “Each Responsible Entity shall <insert performance activity> and document the results of the assessment.”). The intent should be to create a dialog between the entities and vendors on these topics rather than just documented within contractual language.

Chad Bowman, 6/9/2017

- 0 - 0

By not clarifying “cyber security risks” in R1 Part 1.1 the SDT is not providing flexibility, but rather compliance risk to Registered Entities.  See our comments to questions 1 and 7, above, regarding the Implementation Guidance.  As it stands, the document provides no guidance and raises additional, possible compliance risk as to interpretation of what “cyber security risks” are.

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

- 0 - 0

CHPD believes that the language proposed in CIP-013-1 Draft 2 will result in vendor costs that outweigh, or possibly reverse, the current security and reliability of the BES. Vendors are likely to (1) significantly increase quoted implementation costs, (2) counter terms with alternate language that may not comply with the Standard, or (3) elect to no longer do business with small-to-medium sized entities due to added contractual complexity.

Vendors are not subject to enforcement and therefore should not be identified in any CIP Standards.  As a result, CHPD proposes that the requirements be written in a less prescriptive manner that enables entities responsible for CIP-013 compliance to have control over the process through the use of performance-based activities.

The performance-based assessment requirements would be improved if worded in a way that allows the acceptance of any outcome reached by each Responsible Entity (e.g., “Each Responsible Entity shall <insert performance activity> and document the results of the assessment.”). The intent should be to create a dialog between the entities and vendors on these topics rather than just documented within contractual language.

Mick Neshem, 6/12/2017

- 0 - 0

Colorado Springs Utilities supports the comments provided by APPA

Jeff Icke, Colorado Springs Utilities, 5, 6/12/2017

- 0 - 0

Note – Comments from EEI follow: “EEI agrees with the SDT’s belief that the proposed CIP-013-1 and the draft Implementation Guidance provide entities with flexibility to meet the reliability objectives in a cost effective manner.  However, the cost effectiveness of the standard will ultimately depend on how Responsible Entities implement the standard and how NERC and the Regional Entities enforce the requirements. 

In addition to the Implementation Guidance, the policy guidance that NERC staff and the Standards Committee are drafting to clarify the principles, development, and use of the Guidelines and Technical Basis will also be very important to how Responsible Entities implement the requirements. “

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

- 0 - 0

Daniel Grinkevich, 6/12/2017

- 0 - 0

Patrick Hughes, On Behalf of: National Electrical Manufacturers Association, NA - Not Applicable, Segments NA - Not Applicable

- 0 - 0

Santee Cooper believes that this standard will increase the cost of purchasing products from vendors unless the standard effectively addresses the use of regional master contracts, master agreements, and piggyback agreements.  If a Responsible Entity loses the ability to utilize such contracts and agreements the aggregated buying power and large purchase discounts will be lost.

 

Shawn Abrams, 6/13/2017

- 0 - 0

No comment.

Steven Sconce, On Behalf of: EDF Renewable Energy, , Segments 5

- 0 - 0

- 0 - 0

Thomas Foltz, AEP, 5, 6/13/2017

- 0 - 0

The Implementation Guidance only identifies items that could be evaluated in developintg a Supply Chain Cyber Security program, but does not provide an example or guidance on how to implement the program.  Without this guidance, it is impossible to understand how to comply with CIP-013-1 in a cost-effective and compliant manner.

Michael Haff, On Behalf of: Seminole Electric Cooperative, Inc., FRCC, Segments 1, 3, 4, 5, 6

- 0 - 0

We support APPA's submitted comments regarding the cost-effectiveness of CIP-013, pointing out two exceptions.

Allan Long, Memphis Light, Gas and Water Division, 1, 6/13/2017

- 0 - 0

Anthony Jablonski, ReliabilityFirst , 10, 6/13/2017

- 0 - 0

PRPA generally agrees that the entities can meet the reliability objectives in a cost effective manner for CIP-013-1 with two exceptions.

One exception is if the eventually determined audit approach to CIP-013 effectively precludes use of regional master contracts and piggyback agreements, then cyber asset procurement expenses will increase for municipal utilities, smaller entities and co-ops, and other public utilities with little or no benefit. Costs will increase for (i) the procurement process itself, because utilities will need to research specifications and develop contracts individually in place in pre-negotiated master agreements, and for (ii) each purchase, because aggregated buying power and large-purchase discounts will be lost. To minimize these risks, PRPA strongly urges that audit approach language for CIP-013 R2 be clarified as to clearly identify the acceptable use of master agreements rather than leave this determination up to individual regions and auditors.

The other exception is the implementation of CIP-005 R2.4 and R2.5 (methods to detect and disable remote access for vendors and vendor system) for existing BES Cyber Systems. Some legacy cyber systems are inherently structured and configured for vendor access, and reworking them to allow real-time detection and, especially, disabling of such access may prove extremely costly. At the same time, these changes may degrade the performance of these systems. PRPA suggests that the option for a Technical Feasibility Exception be allowed for legacy systems, or that legacy systems be granted an extended implementation period of up to five or ten years (during which such systems likely would be replaced).

Tyson Archie, Platte River Power Authority, 5, 6/14/2017

- 0 - 0

Amelia Sawyer Anderson, On Behalf of: CenterPoint Energy Houston Electric, LLC, Texas RE, Segments 1

- 0 - 0

SDG&E is not able to determine if the proposed CIP-013-1 and the draft Implementation Guidance are cost effective.  Additional changes to existing contracts could incur significant cost increases.

- 0 - 0

W. Dwayne Preston, Austin Energy, 3, 6/14/2017

- 0 - 0

Lauren Price, 6/14/2017

- 0 - 0

 

SMUD generally agrees that the entities can meet the reliability objectives in a cost effective manner for CIP-013-1 with two exceptions.

 

 

 

One exception is if the eventually determined audit approach to CIP-013 effectively precludes use of regional master contracts and piggyback agreements, then cyber asset procurement expenses will increase for municipal utilities, smaller entities and co-ops, and other public utilities with little or no benefit. Costs will increase for (i) the procurement process itself, because utilities will need to research specifications and develop contracts individually in place in pre-negotiated master agreements, and for (ii) each purchase, because aggregated buying power and large-purchase discounts will be lost. To minimize these risks, SMUD strongly urges that audit approach language for CIP-013 R2 be clarified as to clearly identify the acceptable use of master agreements rather than leave this determination up to individual regions and auditors.

 

 

 

The other exception is the implementation of CIP-005 R2.4 and R2.5 (methods to detect and disable remote access for vendors and vendor system) for existing BES Cyber Systems. Some legacy cyber systems are inherently structured and configured for vendor access, and reworking them to allow real-time detection and, especially, disabling of such access may prove extremely costly. At the same time, these changes may degrade the performance of these systems. SMUD suggests that the option for a Technical Feasibility Exception be allowed for legacy systems, or that legacy systems be granted an extended implementation period of up to five or ten years (during which such systems likely would be replaced).

 

- 0 - 0

AE generally agrees the entities can meet the reliability objectives in a cost effective manner with two exceptions:

(1) One exception is if the audit approach to CIP-013 effectively precludes use of regional master contracts and "piggyback" agreements, then cyber asset procurement expenses will increase for municipal utilities, smaller entities and co-ops, and other public utilities with little or no benefit. Costs will increase for: (i) the procurement process itself, because utilities will need to research specifications and develop contracts individually in place of pre-negotiated master agreements, and (ii) each purchase, because aggregated buying power and large-purchase discounts will be lost. To minimize these risks, AE strongly urges that audit approach language for CIP-013 R2 be clarified to clearly identify the acceptable use of master agreements rather than leave this determination up to individual regions and auditors.

(2) Implementation of CIP-005 R2.4 and R2.5 (methods to detect and disable remote access for vendors and vendor system) for existing BCS. Some legacy cyber systems are inherently structured and configured for vendor access and reworking them to allow real-time changes may degrade system performance. AE suggests the option for a Technical Feasibility Exception be allowed for legacy systems or that legacy systems be granted an extended implementation period of up to five or ten years (during which such systems likely would be replaced).

Andrew Gallo, 6/14/2017

- 0 - 0

BC Hydro does not agree  that implementing this standard will be cost effective.  Costs and contract management to enforce CIP-013 on all vendors, in light of the limited authority the responsible entity would have over vendors, are anticipated to be significant. Especially, but not limited too, in situations where there is limited vendor choice for a class of product.

BC Hydro, Segment(s) 1, 2, 3, 5, 5/6/2015

- 0 - 0

Richard Kinas, 6/14/2017

- 0 - 0

See attached comments.

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

2016-03_Unofficial_Comment_Form_SCL_2017-6-14 Final to NERC.docx

- 0 - 0

Normande Bouffard, 6/14/2017

- 0 - 0

Entergy/NERC Compliance, Segment(s) 1, 5, 3/1/2017

- 0 - 0

Theresa Allard, Minnkota Power Cooperative Inc., 1, 6/14/2017

- 0 - 0

SRP generally agrees that the entities can meet the reliability objectives in a cost effective manner for CIP-013-1 with two exceptions.

One exception is if the eventually determined audit approach to CIP-013 effectively precludes use of regional master contracts and piggyback agreements, then cyber asset procurement expenses will increase for municipal utilities, smaller entities and co-ops, and other public utilities with little or no benefit. Costs will increase for (i) the procurement process itself, because utilities will need to research specifications and develop contracts individually in place in pre-negotiated master agreements, and for (ii) each purchase, because aggregated buying power and large-purchase discounts will be lost. To minimize these risks, SRP strongly urges that audit approach language for CIP-013 R2 be clarified as to clearly identify the acceptable use of master agreements rather than leave this determination up to individual regions and auditors.

The other exception is the implementation of CIP-005 R2.4 and R2.5 (methods to detect and disable remote access for vendors and vendor system) for existing BCS. Some legacy cyber systems are inherently structured and configured for vendor access, and reworking them to allow real-time detection and, especially, disabling of such access may prove extremely costly. At the same time, these changes may degrade the performance of these systems. SRP suggests that the option for a Technical Feasibility Exception be allowed for legacy systems, or that legacy systems be granted an extended implementation period of up to five or ten years (during which such systems likely would be replaced).

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

- 0 - 0

There is not enough clarity in the proposed language to make that assessment.

Alex Ybarra, 6/14/2017

- 0 - 0

Reclamation’s position is that the determination of “cost effectiveness” will remain subjective unless a method to determine burden is consistent across the industry.

Wendy Center, U.S. Bureau of Reclamation, 5, 6/14/2017

- 0 - 0

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

- 0 - 0

Andrew Meyers, Bonneville Power Administration, 6, 6/14/2017

- 0 - 0

SDG&E is not able to determine if the proposed CIP-013-1 and the draft Implementation Guidance are cost effective.  Additional changes to existing contracts could incur significant cost increases.

- 0 - 0

In the Draft CIP-013-1 – Cyber Security - Supply Chain Risk Management requirement R2 includes the following: “Note: Implementation of the plan does not require the Responsible Entity to renegotiate or abrogate existing contracts (including amendments to master agreements and purchase orders). Additionally, the following issues are beyond the scope of Requirement R2: (1) the actual terms and conditions of a procurement contract; and (2) vendor performance and adherence to a contract.”

With this note the Responsible Entity is basically directed to develop a plan yet it does not have to change procurement results. If you are not going to require results, there is no reason to add the costs of developing and implementing the program.

Alan Farmer, On Behalf of: ACEC, FRCC, MRO, WECC, Texas RE, NPCC, SERC, SPP RE, RF, Segments NA - Not Applicable

- 0 - 0

Barry Lawson, 6/14/2017

- 0 - 0

John Williams, 6/15/2017

- 1 - 0

N&ST believes the approaches to meeting CIP-013’s reliability objectives described in the Implementation Guidance could easily consume scores, if not hundreds, of staff hours, with the potential to make “vendor risk assessment(s)” a significant cost component of any large-scale procurement. N&ST notes that although most of the documents referenced in the Guidance document are available for download at no charge, the Shared Assessment Program’s Standardized Information Gathering (SIG) questionnaire, referenced in a footnote, must be purchased for $6,000.  The Guidance document does point out that a Responsible Entities are free to pursue different approaches to CIP-013 implementation that “better fit their situation,” but provides no examples of alternatives that might be worth considering. N&ST encourages NERC and the SDT to consider how utilities with very small staffs and very limited budgets might reasonably address their CIP-013 obligations.  

Nicholas Lauriat, Network and Security Technologies, 1, 6/15/2017

- 0 - 0

EEI agrees with the SDT’s belief that the proposed CIP-013-1 and the ERO Enterprise-Endorsed Implementation Guidance provide entities with flexibility to meet the reliability objectives in a cost effective manner.  However, the cost effectiveness of the standard will ultimately depend on how Responsible Entities implement the standard and how NERC and the Regional Entities enforce the requirements. 

In addition to the Implementation Guidance, the policy guidance that NERC staff and the Standards Committee are drafting to clarify the principles, development, and use of the Guidelines and Technical Basis will also be very important to how Responsible Entities implement the requirements.   

Melanie Seader, On Behalf of: Edison Electric Institute, NA - Not Applicable, Segments NA - Not Applicable

- 0 - 0

NYPA supports the comments submitted by Salt River Project (WECC) and NPCC.

David Rivera, New York Power Authority, 3, 6/15/2017

- 0 - 0

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

- 0 - 0

This new standard will put additional burden on entities.  It is going to take considerable time to implement and negotiate new contracts.  It is also up to the entity to provide adequate documentation to prove compliance but it will still be based on the auditor discretion if an entity has done enough. As with similar requirements in the nuclear industry we believe that contract pricing will increase due to the Standard requirements placed on the vendors via industry and may result in reduction of vendor options.

Don Schmit, 6/15/2017

- 0 - 0

At this point of the project, it is too early to comment on cost effectiveness.  Exelon does not predict that the implementation of CIP-013 will require significant investment.  However, implementing tools and processes for the revisions to CIP-005 and CIP-010 may require project management oversight as well as material financial investment.

Daniel Gacek, Exelon, 1, 6/15/2017

- 0 - 0

We support the changes and believes that most aspects of CIP-013 may be achieved cost-effectively (if not necessarily cheaply), with two exceptions.

One exception is if the eventually determined audit approach to CIP-013 effectively precludes use of regional master contracts and piggyback agreements, then cyber asset procurement expenses will increase for municipal utilities, smaller entities and co-ops, and other public utilities with little or no benefit. Costs will increase for (i) the procurement process itself, because utilities will need to research specifications and develop contracts individually in place in pre-negotiated master agreements, and for (ii) each purchase, because aggregated buying power and large-purchase discounts will be lost. To minimize these risks, USI strongly urges that audit approach language for CIP-013 R2 be clarified as to clearly identify the acceptable use of master agreements rather than leave this determination up to individual regions and auditors.

The other exception is the implementation of CIP-005 R2.4 and R2.5 (methods to detect and disable remote access for vendors and vendor system) for existing BES Cyber Systems. Some legacy cyber systems are inherently structured and configured for vendor access, and reworking them to allow real-time detection and, especially, disabling of such access may prove extremely costly. At the same time, these changes may degrade the performance of these systems. USI suggests that the option for a Technical Feasibility Exception be allowed for legacy systems, or that legacy systems be granted an extended implementation period of up to five or ten years (during which such systems likely would be replaced).

Brian Evans-Mongeon, Utility Services, Inc., 4, 6/15/2017

- 1 - 0

Guy Andrews, 6/15/2017

- 0 - 0

Laura Nelson, 6/15/2017

- 0 - 0

By asking vendors to enforce these requirements, service costs will dramatically increase which will put a further strain on the electric industry.  

 

 

 

Heather Morgan, EDP Renewables North America LLC, 5, 6/15/2017

- 0 - 0

David Gordon, 6/15/2017

- 0 - 0

MEAG supports the answers and comments of Salt River Project.

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

- 0 - 0

SPP is cognizant and appreciative of the flexibility provided in proposed CIP-013-1 and the draft Implementation Guidance but at this time cannot speak to whether the implementation of these requirements will be cost effective.  Additional internal analysis is needed to inform SPP’s evaluation as to the cost-effectiveness of the proposal.   

SPP Standards Review Group, Segment(s) 0, 6/15/2017

- 0 - 0

NRG is cognizant and appreciative of the flexibility provided in proposed CIP-013-1 and the draft Implementation Guidance but at this time cannot speak to whether the implementation of these requirements will be cost effective.  Additional internal analysis is needed to inform NRG’s evaluation as to the cost-effectiveness of the proposal.  

Kara White, On Behalf of: NRG - NRG Energy, Inc., FRCC, MRO, WECC, Texas RE, NPCC, SERC, SPP RE, RF, Segments 3, 4, 5, 6

- 0 - 0

There is not enough clarity in the proposed language to make that assessment.

LeRoy Patterson, Public Utility District No. 2 of Grant County, Washington, 6, 6/15/2017

- 0 - 0

Mark Holman, 6/15/2017

- 0 - 0

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

- 0 - 0

Jesus Sammy Alcaraz, Imperial Irrigation District, 1, 6/15/2017

- 0 - 0

- 0 - 0

Luminant, Segment(s) 6, 7, 5, 1/24/2017

- 0 - 0

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

- 0 - 0

FEUS supports the comments submitted by APPA

Linda Jacobson-Quinn, City of Farmington, 3, 6/15/2017

- 0 - 0

Scott Downey, 6/15/2017

- 0 - 0

- 0 - 0

No comment

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

- 0 - 0

- 0 - 0

Michael Brytowski, Great River Energy, 3, 6/15/2017

- 0 - 0

David Ramkalawan, 6/15/2017

- 0 - 0

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

- 0 - 0

No Comment

Timothy Reyher, 6/15/2017

- 0 - 0

Quintin Lee, Eversource Energy, 1, 6/15/2017

- 0 - 0

By placing those comments and guidance in the Implementation Guidance does not provide industry protection during an audit in defining ‘cost effective manner’. If it is important to communicate to industry that Supply Chain Management can be managed in a ‘cost effective manner’, then that should be detailed in the standards. ‘Cost effective manner’ is an undefined term and will be different for each entity, budget and their resources. The focus should be modified to a ‘risk reduction manner’ or ‘risk appropriate manner’. 

ACES Standards Collaborators, Segment(s) 1, 3, 4, 5, 6/15/2017

- 0 - 0

Rachel Coyne, Texas Reliability Entity, Inc., 10, 6/15/2017

- 0 - 0

Theresa Rakowsky, 6/15/2017

- 0 - 0

AECI & Member G&Ts, Segment(s) 1, 6, 5, 3, 4/11/2017

- 0 - 0

No comment

RSC no Dominion, Segment(s) 1, 0, 2, 4, 5, 6, 7, 3, 6/15/2017

- 1 - 0

Jason Snodgrass, 6/15/2017

- 0 - 0

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

- 0 - 0

SRC + SWG , Segment(s) 2, 3, 1, 0, 6/15/2017

- 0 - 0

Victor Garzon, 6/15/2017

- 0 - 0

Pablo Onate, El Paso Electric Company, 1, 6/15/2017

- 0 - 0

Rhonda Bryant, El Paso Electric Company, 3, 6/15/2017

- 0 - 0

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

- 0 - 0

Glen Farmer, Avista - Avista Corporation, 5, 6/15/2017

- 0 - 0

Oxy, Segment(s) 7, 5, 9/6/2016

- 0 - 0

No comment.

Teresa Krabe, Lower Colorado River Authority, 5, 6/15/2017

- 0 - 0

We consider the requirements to be burdensome, and impractical for many or most electric utilities without providing needed protection of the cyber supply chain.  We would suggest at the outset adoptioon of a separate FERC rulemaking to detect, report, mitigate and remove malware from the bulk electric system.

William Harris, Foundation for Resilient Societies, 8, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

John Martinsen, Public Utility District No. 1 of Snohomish County, 4, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Long Duong, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Mark Oens, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Sam Nietfeld, Public Utility District No. 1 of Snohomish County, 5, 6/15/2017

- 0 - 0

Public Utility District No. 1 of Snohomish County supports the comments of Seattle City Light, Salt River Project and New York Power Authority – LPPC members. 

Franklin Lu, 6/15/2017

- 0 - 0

ERCOT joins the comments of the IRC.

Elizabeth Axson, 6/15/2017

- 0 - 0

Hot Answers

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

Richard Vine, 6/15/2017

- 0 - 0

- 0 - 0

Other Answers

Randy Buswell, 5/31/2017

- 0 - 0

Bill Watson, On Behalf of: Bill Watson, , Segments 3

- 0 - 0

Regarding requirement R2, measure M2, suggest consider revising language to state “…demonstrate use of or compliance with the supply chain cyber security risk management plan.”

 

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

- 0 - 0

Sandra Pacheco, On Behalf of: Silicon Valley Power - City of Santa Clara, , Segments 3, 5

- 0 - 0

Val Ridad, On Behalf of: Silicon Valley Power - City of Santa Clara, , Segments 3, 5

- 0 - 0

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

- 0 - 0

Bob Thomas, 6/9/2017

- 0 - 0

CHPD sees value in broader engagement by other governmental authorities, including potentially the Department of Homeland Security and the Department of Energy, in order to address electric sector supply chain security in a manner that fully engages responsible suppliers with whom we do business.  That effort could lead to an articulated set of common practices or protocols to which entities in the electric supply chain may subscribe, and upon which the electric sector may rely to improve the security of the supply chain.

Haley Sousa, 6/9/2017

- 0 - 0

CHPD sees value in broader engagement by other governmental authorities, including potentially the Department of Homeland Security and the Department of Energy, in order to address electric sector supply chain security in a manner that fully engages responsible suppliers with whom we do business.  That effort could lead to an articulated set of common practices or protocols to which entities in the electric supply chain may subscribe, and upon which the electric sector may rely to improve the security of the supply chain.

Janis Weddle, 6/9/2017

- 0 - 0

Steven Rueckert, Western Electricity Coordinating Council, 10, 6/9/2017

- 0 - 0

CHPD sees value in broader engagement by other governmental authorities, including potentially the Department of Homeland Security and the Department of Energy, in order to address electric sector supply chain security in a manner that fully engages responsible suppliers with whom we do business.  That effort could lead to an articulated set of common practices or protocols to which entities in the electric supply chain may subscribe, and upon which the electric sector may rely to improve the security of the supply chain.

 

Chad Bowman, 6/9/2017

- 0 - 0

Dominion recommends the following changes to the RSAWs:

 

  • CIP-005-6, R2, Parts 2.4 and 2.5

    •  Remove the word “all” from the “Compliance Assessment Approach sections. 

  • CIP-010-3, R1, Part 1.6

    • Remove the words “for each” from the “Compliance Assessment Approach section, rows 2 and 4. 

  • CIP-013-1, R1

    • Remove the word “controls”.  The word “processes” is now in uses in the most current draft of CIP-013-1.

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

- 0 - 0

CHPD sees value in broader engagement by other governmental authorities, including potentially the Department of Homeland Security and the Department of Energy, in order to address electric sector supply chain security in a manner that fully engages responsible suppliers with whom we do business.  That effort could lead to an articulated set of common practices or protocols to which entities in the electric supply chain may subscribe, and upon which the electric sector may rely to improve the security of the supply chain.

Mick Neshem, 6/12/2017

- 0 - 0

Jeff Icke, Colorado Springs Utilities, 5, 6/12/2017

- 0 - 0

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

- 0 - 0

Daniel Grinkevich, 6/12/2017

- 0 - 0

On behalf of the National Electrical Manufacturers Association (NEMA)—a trade association and standards developing organization with nearly 350 member companies that manufacture a diverse set of products used in the generation, transmission, distribution, and end-use of electricity—and on behalf of the NEMA Grid Modernization Leadership Council and the NEMA Cybersecurity Committee, I wish to submit for your reference “CPSP 1-2015: Supply Chain Best Practices,” which describes industry best practices for manufacturers to follow regarding cybersecurity supply chain management.

 

“Supply Chain Best Practices” identifies guidelines that electrical equipment manufacturers can implement during product development to minimize the possibility that bugs, malware, viruses or other exploits can be used can be used to negatively impact product operation. It addresses United States supply chain integrity through four phases of a product’s life cycle: manufacturing, delivery, operation, and end-of-life. The report (attached) is available for public download at: http://www.nema.org/Standards/Pages/Supply-Chain-Best-Practices.aspx.

 

The National Electrical Manufacturers Association and its members understand that a secure supply chain is essential to a secure grid and that cybersecurity aspects should be built into, not bolted onto, manufacturers’ products. They also understand that managing cybersecurity supply chain risk requires a collaborative effort and open lines of communication among electric utility companies and the manufacturers of critical electric grid systems and components—both hardware and software. NEMA looks forward to working with and being a resource for NERC, utilities, and other interested stakeholders in addressing supply chain risks and concerns within the energy sector.

 

Should you have any questions, please contact Patrick Hughes, Senior Director of Government Relations and Strategic Initiatives, at 703-841-3205 or patrick.hughes@nema.org.

 

Respectfully,

 

Kyle Pitsor

Vice President, Government Relations

Patrick Hughes, On Behalf of: National Electrical Manufacturers Association, NA - Not Applicable, Segments NA - Not Applicable

NEMA Comments on NERC Supply Chain Risk Management 2017-06-12.pdf

- 0 - 0

Shawn Abrams, 6/13/2017

- 0 - 0

No comment.

Steven Sconce, On Behalf of: EDF Renewable Energy, , Segments 5

- 0 - 0

The Guidance and Techincal Basis section is empty.