| CIP-012-1 | | For a GO that does not operate a Control Center or a GOP that only receives data directly from generating facilities without passing it on to another Control Center, what is expected as evidence of compliance? | The ERO Enterprise recommends reviewing the definition of Control Center per the NERC Glossary of Terms and the purpose of CIP-012-1 for applicability. Additionally, the CIP Evidence Request Tool (ERT) can provide useful information on what may be asked for in evidence requests. |
| CIP-012-1 | | Do entities have to do outage notification with far-end stakeholders? | The ERO Enterprise recommends coordination with any Control Center that is transmitting Real-time Assessment and Real-time monitoring data. |
| CIP-012-1 | Agreements | Do we need to include clauses for failure within our Requirement R1 Part 1.3 agreements? | No, however the ERO Enterprise recommends documenting and implementing internal controls to address failures within agreements, if applicable. |
| CIP-012-1 | Agreements | In the instance of EINET where members cross regions and each had to sign an agreement with EINET itself, the coordination already occurred and responsibilities are defined by EINET. Some entities are requesting additional agreements. Are these needed? | Requirement R1.3 requires the responsibilities to be identified and applied, so the agreement may be one way to demonstrate compliance. Numerous Responsible Entities during the Small Group Advisory Sessions implemented agreements to help memorialize the identification of responsibilities of each Responsible Entity. Agreements may be forms of evidence that could help demonstrate coordination on security protection(s). The agreement’s terms and conditions, including how granular it may be, is subjective to the Responsible Entities.
|
| CIP-012-1 | Agreements | If an agreement is used for the purpose of Part 1.3., does the agreement have to be legally binding? Also, how detailed does the agreement need to be? | No, an agreement does not have to be legally binding. However, it is the Responsible Entity's responsibility to comply with CIP-012 and to coordinate with others. Documenting agreements and ensuring those agreements outline each Responsible Entity’s responsibilities are key in demonstrating compliance with Part 1.3. Documentation, such as lists, diagrams, etc., may provide reasonable assurance of implementation of Part 1.3. Without such documentation, situational awareness and implementation of security protection(s) could be challenging. While not specifically required in the Standard, periodic reviews of those overarching policies and agreements is recommended. In addition, Responsible Entities should consider documenting the process or procedures to address when others may not comply with established agreements.
|
| CIP-012-1 | Audit Approach | What is the expectation for oversight? | The ERO Enterprise will be leveraging the CIP Evidence Request Tool (ERT), specifically the Level 1 and Level 2 evidence requests. |
| CIP-012-1 | CIP Exceptional Circumstances (CEC) | Could you explain further the CEC? | The ERO Enterprise recommends reviewing the definition of CIP Exceptional Circumstances (CEC) per the NERC Glossary of Terms. The SDT's intent for including CIP Exceptional Circumstances within CIP-012 is to allow for scenarios where, for reliability reasons, restoration of availability of the data flowing between Control Centers may need to take precedence over temporarily unavailable security controls. For example, if two Control Centers are using encryption that is offloaded onto hardware cards and that encryption hardware fails, or if a key management system fails, and numerous entities lose communication, the entities may need to restore the data flow as soon as possible for reliability purposes even if the encryption cannot be restored at the same time. Responsible Entities should document and record any CEC that applies to CIP-012-1. Additionally, the ERO Enterprise notes the connection to CIP-003-8 Requirement R1 for CEC. |
| CIP-013-1 | Contracts | Is the intent of Requirement R1 of CIP-013-1 to require new or renewed contracts to include contract language that supports CIP-013? If so, that implies that our plan should be in place as of the effective date. Is this accurate? | The intent of CIP-013-1 is to require entities to develop and implement processes that consider supply chain risks when procuring products and services. Entities are required to include specified security concepts in their procurement activities for high and medium impact BES Cyber Systems but does not mandate the inclusion of any specific provisions in new or renewed contracts to comply with CIP-013. The required process should be integrated into a registered entity’s procurement practices by the effective date of CIP-013-1, if approved by the Commission.
|
| CIP-013-1 | Contracts | The standard obliquely addresses situations where an entity cannot get a vendor to comply and may have no other options. What evidence will be sufficient to show our attempt to contract with a resistant vendor? | The Cyber Security Supply Chain Risk Management Plans Implementation Guidance for CIP-013-1
provides guidance in this area. Entities should develop and implement a solid procurement plan and document anomalies. |
| CIP-013-1 | Contracts | While we are comfortable that we will be able to show the starting point (contract templates), beyond that there could be confidentiality issues relating to the contract and associated communications. What evidence will be sufficient? Does an executed con | Yes, an executed contract demonstrating that the requirements of CIP-013-1 were addressed would be sufficient to demonstrate compliance if the registered entity also provides its CIP-013-1 process(es). Attestations, internal procedures, and all relevant email communications should be documented and maintained as evidence of compliance. There should be no need to reveal sensitive/proprietary information to demonstrate compliance. An entity may choose to provide documents with redacted information as audit artifacts. |
| CIP-013-1 | Contracts | R2 – Each Responsible Entity shall implement its supply chain cyber security risk management plan(s) specified in Requirement R1: The Standard does not specify a timeline for implementation. Is there any guidance on when entities will be expected to have | Review the implementation guidance document and the implementation plan for Initial performance. Once the standard is in effect, all new/renegotiated contracts are subject to the standard. |
| CIP-013-1 | Contracts | Can a registered entity provide redlined contracts, demonstrating contract negotiations, as a part of our evidence to prove compliance with CIP-013-1 R1 and R2? Is this a common way to show compliance and are there other considerations we should take into | The audit team will sample all R2 implementations, so the initial evidence request will ask for a complete list of applicable procurement(s). The audit team will sample the list in accordance with the ERO Sampling Handbook and request complete implementation documentation for the sampled procurements. Keep in mind the R1 plan should provide processes and procedures to indicate how the registered entity will meet the security objectives of CIP-013-1 and address each component of R1 Part 1.1 and Part1.2. While redlined contracts may serve as evidence of R2 implementations, the R1 plans should describe the registered entity’s methodology for identifying and assessing risks associated with applicable procurements. Contracts may be a component of the R1 plan, but the registered entity should ensure the procurement documents support the development of a contract that meets the CIP-013-1 security
objectives. |
| CIP-013-1 | Contracts | What if a registered entity has a master agreement effective before the effective date of CIP-013-1 (October 1, 2020) which does not include terms associated with CIP-013-1 R1 Part 1.2 and its sub-parts, and purchase products or services after October 1, | The risk assessment should be performed on the vendor, product, and/or service as dictated by the SCRM plan. The registered entity’s SCRM plan determines where and how the risk assessment is performed. Regarding R1 Part 1.2 and its sub-parts, while the action to renegotiate or abrogate existing contracts is not required, it is expected that mitigations are implemented to address the risks of these elements not being contractually binding on the vendor. All procurements of products or services applicable to high or medium impact BES Cyber Systems after October 1, 2020 would be applicable, under the R1 SCRM plan and R2 implementation. |
| CIP-013-1 | Contracts | How much focus will be on the contracts during my audit? | Both contract language and vendor performance to a contract are explicitly taken out of scope for these Requirements by the Note to Requirement R2. As dictated in the R2 note, entities are not expected to renegotiate their contracts; however, the supply chain risk standard would apply to the procurements associated with these agreements. It is recommended that entities do not solely rely on contract language to demonstrate implementation of this Requirement. Instead, it is suggested the implementation of the processes include documentation that you have followed the processes step-by-step. Contracts will only be considered if entities voluntarily submit them as evidence. Procurements, including those under existing contracts, performed on or after October 1, 2020 are subject to CIP-013-1 and should be considered applicable to the Supply Chain Risk Management plan(s). Entities are expected to demonstrate implementation of the SCRM plan on or after the effective date. Dated documentation should demonstrate the process/procedures identified in the SCRM plan were implemented and afforded the required R1 controls to assess and identify cyber security risks and mitigating identified risks as applicable. |
| CIP-013-1 | Contracts | Will auditors look at language within contracts or will their focus be on only the risk assessments? | Both contract language and vendor performance to a contract are explicitly taken out of scope for these Requirements by the Note to Requirement R2. It is recommended that entities do not solely rely on contract language to demonstrate implementation of this Requirement. Instead, it is suggested the implementation of the processes include documentation that you have followed the processes step-bystep. Contracts will only be considered if entities voluntarily submit them as evidence. Procurements, including those under existing contracts, performed on or after October 1, 2020 are subject to CIP-013-1 and should be considered applicable to the Supply Chain Risk Management plan(s).
Entities are expected to demonstrate implementation of the SCRM plan on or after the effective date. Dated documentation should demonstrate the process/procedures identified in the SCRM plan were implemented and afforded the required R1 controls to assess and identify cyber security risks (Part 1.1) and mitigating identified risks as applicable (Part 1.2). |
| CIP-013-1 | Contracts | While quite a bit of this content is captured in contractual agreements with vendors, does the ERO believe that contracts will be considered evidence material in audits? | The entity determines which evidentiary artifacts are appropriate to demonstrate adherence to the Standard Requirements. These elements should be documented within the SCRM Plan and/or presented during an audit engagement. These artifacts individually or collectively should be able to demonstrate reasonable assurance of adherence to the applicable Standard Requirements. However, a contract itself does not show compliance. Evidence should show that controls in the SCRM plan are implemented that meet the requirements of the Standard. |
| CIP-013-1 | Contracts | If contracts are considered as evidence, will the ERO be looking for specific clauses and would the absence of any clause be deemed a noncompliance? | The entity determines which evidentiary artifacts are appropriate to demonstrate adherence to the Standard. These elements may be documented within the SCRM Plan and/or presented during an audit engagement. These artifacts individually or collectively should be able to demonstrate reasonable assurance of adherence to the applicable Standard Requirements. The absence of a contractual clause may present more risk and the CEA could test for Standard adherence. |
| CIP-013-1 | Contracts | Could a registered entity provide a redacted (due to confidentiality issues relating to the contract and associated communications) executed contract, attestation(s) from vendor and internal supply chain personnel, and internal processes/procedures as evi | An executed contract demonstrating Part 1.2 was addressed could be sufficient to demonstrate compliance if the registered entity also provides additional supporting evidence such as processes/procedures, email communications, and attestations. The registered entity should not reveal any sensitive or proprietary information that would cause a breach of contract. |
| CIP-012-1 | Contracts | What data is in scope? | The data in scope is Real-time Assessment and Real-time monitoring data in accordance with NERC Reliability Standards TOP-003 and IRO-010, and is agnostic to the protocol or medium. Security protection(s) to protect from unauthorized disclosure and unauthorized modification must be implemented for Real-time Assessment and Real-time monitoring data transmitted between Control Centers. Please note that if the end connection does not meet the definition of a Control Center, it is out of scope. |
| CIP-012-1 | Control Center | If you are using a third-party to monitor and control a site with data links for telemetry, are they considered a part of sites control center? Note, that the site control center would be communicating with the TOP, RC, etc. | The ERO Enterprise recommends reviewing the definition of Control Center per the NERC Glossary of Terms. Additionally, evaluate the details of whether RTA/RTM is being transmitted and how RTA/RTM is being utilized at the third-party site, as the facts and circumstances of the specific case will determine whether the third-party is part of the Control Center or an associated data center. |
| CIP-012-1 | Control Center | Do we have Control Center(s) or not? | The ERO Enterprise recommends reviewing the definition of Control Center per the NERC Glossary of Terms and the purpose of CIP-012-1 for applicability. Criteria based on definition of Control Center include: 1) Do you have a facility? 2) Does it host operating personnel that: 2a) Monitor and Control? 3) Does it have an associated data center? 4) Are you NERC registered as a RC, BA, TOP, TO, GOP, or GO? 5) Do you perform reliability tasks at two or more transmission or generation Facilities? Lastly, the ERO Enterprise recommends implementing internal controls that ensures Responsible Entities identify all applicable Control Centers. |
| CIP-012-1 | Control Center | What if a remote entity is currently not a Control Center but changes in the future without coordination for CIP-012? | It is the Responsible Entity's responsibility to comply with CIP-012 and to coordinate with other Responsible Entities. The ERO Enterprise recommends a periodic review as an internal control for CIP-012-1 to potentially identify the change of Control Center status. Lastly, some internal controls might be utilized within agreements between Responsible Entities to ensure coordination. |
| CIP-012-1 | Control Center | What is meant by "Responsible Entities should note that 'associated data centers' are included in the Control Center definition"? | Please see the general session recording and slide deck for additional information. The ERO Enterprise notes that associated data centers are included in the Control Center definition. Review for CIP-012-1 applicability per the definition associated data centers for Real-time Assessment and Real-time monitoring data security protection(s). Lastly, the ERO Enterprise recommends reviewing the definition of Control Center per the NERC Glossary of Terms. |
| CIP-012-1 | Control Center | If an associated data center is not located with a Control Center, what degree of protection is required between the data center and the Control Center? | As associated data centers are included within the Control Center definition and if a Responsible Entity is transmitting Real-time Assessment and Real-time monitoring data between two Control Centers, then CIP-012 security protection(s) must be implemented to protect from unauthorized disclosure and unauthorized modification of Real-time Assessment and Real-time monitoring data. The security protection(s) method implemented is subjective to the Responsible Entity based on risk(s). |
| CIP-012-1 | Control Center | Would communication between Transmission and Distribution Control Centers be applicable? | The ERO Enterprise noted that in Section 4, Applicability,of CIP-012-1, DP’s are not listed as an applicable functional entity. However, the ERO Enterprise noted that security protection(s) may need to be used to mitigate the risks posed by unauthorized disclosure and unauthorized modification of Real-time Assessment and Real-time monitoring data if the Real-time Assessment and Real-time monitoring data is being transmitted between the Control Centers. Particularly, Part 1.3 would need to be documented and implemented for the Responsible Entity that is registered as an applicable functional entity. The ERO Enterprise recommends the Responsible Entity that is a DP also implement security protection(s) and also contact the applicable Region’s registration group; this is a security recommendation. Lastly, the ERO Enterprise recommends reviewing the definition of Control Center per the NERC Glossary of Terms. |
| CIP-012-1 | Controls | Does redundancy alone provide integrity protections? | The Responsible Entity will need to address both unauthorized disclosure and unauthorized modification of Real-time Assessment and Real-time monitoring data while being transmitted between the Control Centers. Redundancy does not provide integrity protections. |
| CIP-012-1 | Controls | How would an entity physically protect the link between two different entities? | As an example, ensuring the Cyber Asset that is establishing the communication link has physical protections around that Cyber Asset. Additional possibilities include monitoring, alerting, and responding to the status of the communication link. |
| CIP-012-1 | Controls | Is there any documentation of security controls other than encryption being utilized? | Examples could include physical access controls, demarcation of the protections, and armored cable protections. Owning, operating and managing the lines are other types of protections. Additionally, the ERO Enterprise recommends additional controls found in NIST Special Publication 800-53, Revision 5. |
| CIP-012-1 | Controls | Would a reference to other programs, such as outage coordination and incident response, subject them to more scrutiny when we are merely citing them for controls? | The ERO Enterprise would encourage robust documentation in the R1 plan including identification of additional internal controls, as this could lead to positive observations. Additionally, the ERO Enterprise is evaluating internal controls and any risks identified are subject to additional requests for clarification. However, the ERO Enterprise would recommend clearly documenting what the primary implementation methods are for compliance purposes and what internal controls are implemented to reduce risk(s). |
| CIP-012-1 | Controls | If another entity is taking responsibility from a router that is on-site, and our entity has agreed to physically protect the router and the communication link to the router, are we required to do anything additional to protect the data? | Documentation and evidence that security protection(s) to protect from unauthorized disclosure and unauthorized modification are implemented for Real-time Assessment and Real-time monitoring data transmitted between Control Centers is required. The ERO Enterprise recommends including documentation describing what is actually happening as part of the R1 plan. Include the security protection(s) and any internal controls used to mitigate the risk. For example, physical access controls such as placing the routers within the Physical Security Perimeter or applying logical controls to the Real-time Assessment and Real-time monitoring data. Additional, internal controls that could be implemented include monitoring, alarming, and responding to the communication links. |
| CIP-012-1 | Controls | Can you please explain when there is a new CIP-012 applicable connection and when the protections need to be in place? | The ERO Enterprise’s expectation is that on or before the commissioning of the new connection, a Responsible Entity must be compliant with CIP-012-1. This expectation would also be the same for future created Control Centers. |
| CIP-012-1 | Controls | Should we document what internal controls we have in place? | Yes, the ERO Enterprise encourages the identification and documentation of controls within the R1 plan. The ERO Enterprise also recommends identification and documentation within the R1 plan if other CIP Standards and Requirements are leveraged to mitigate risk(s) posed by unauthorized disclosure and unauthorized modification of Real-time Assessment and Real-time monitoring data. For example, a Responsible Entity could leverage CIP-006-6 PSP controls; even though there is no PSP construct within CIP-012-1, the protections in place from CIP-006-6 could be utilized as an internal control for mitigating risk(s). |
| CIP-012-1 | Controls | We own the link between our two Control Centers and will be utilizing that as a secondary control. If one of the main controls drops, are we still good with utilizing the secondary control? | Professional judgment will be used to decide based on facts and circumstances. If underlying controls are strong enough then it's possible a self-report may not be needed. However, ownership of the communication link(s) alone may not be a sufficient control. The ERO Enterprise recommends considering other logical and/or physical access controls that could be implemented. Lastly, the ERO Enterprise recommends reviewing the definition of CIP Exceptional Circumstances (CEC) per the NERC Glossary of Terms. |
| CIP-012-1 | Controls | What is meant by "The application of security in accordance with CIP-012 requirements does not add additional assets to the scope of the CIP Reliability Standards"? | This means CIP-012-1 does not go beyond the boundaries of CIP-002 and add additional Cyber Assets/assets into CIP scope. A Cyber Asset that may be affording the protection for CIP-012 does not necessarily mean it is an applicable Cyber Asset if it is not already considered one. |
| CIP-012-1 | Controls | Does the ERO Enterprise expect to see personnel with responsibility dealing with human elements and threats? | If the Responsible Entity has identified human elements and threats to the confidentiality and integrity of Real-time Assessment and Real-time monitoring data as a risk(s), then Responsible Entity’s should address those risks within the R1 plan. |
| CIP-012-1 | Controls | Our connection to the RC/BA is secured HTTPS and OATI certificates for authentication. Then encryption is applied and is then sent to the RC/BA. Is this a good approach for our controls? | The ERO Enterprise believes this could be a reasonable approach if this approach meets the security objective of Requirement R1. The ERO Enterprise recommends considering the implementation of security protection(s) that mitigate the risk(s) associated with the confidentiality and integrity of the Real-time Assessment and Real-time monitoring data as documented in the Purpose of CIP-012-1. |
| CIP-012-1 | Controls | Does transmitting the data with the SSH protocol suffice as "protecting" the data? | Secure Socket Shell (SSH) protocol may suffice depending on implementation (e.g. version, configuration, etc.). Responsible Entities must ensure their SSH implementation is documented within their plan(s), including how SSH mitigates the risks posed by unauthorized disclosure and unauthorized modification of RTA/RTm data while being transmitted between Control Centers.
|
| CIP-012-1 | Controls | Does our CIP-012 Plan have to be reviewed and approved by our CIP Senior Manager at least once every 15 calendar months similar to CIP-003? | The ERO Enterprise recommends the documented plan(s) are reviewed and approved on a periodic basis as an internal control, however it is not within the requirements of the Standard.
|
| CIP-012-1 | Controls | In the Implementation Guidance, for Part 1.1, it is worded "...if two Control Centers are in close physical proximity....” what is considered "close physical proximity"? Is there a range of distance that fits this? | The Cyber Security – Communications Between Control Centers Implementation Guidance[1] is referring to use of cabling as a form of physical protection to mitigate the risks posed by unauthorized disclosure and unauthorized modification of RTA/RTm data while being transmitted between Control Centers. The range of distance is subjective to the Responsible Entity’s assessment of risks and the security protection(s) to mitigate those risks.
|
| CIP-012-1 | EIDSN | What evidence of protections applied by Eastern Interconnect Data Sharing Network, Inc. (EIDSN) is necessary? | The Responsible Entity should start by producing evidence that EIDSN is providing and implementing the security protection(s). The Responsible Entity’s R1 plan should include the identification of where these security protection(s) are implemented. Documentation such as agreements, user manuals, and diagrams could be helpful to demonstrate compliance. Specifically, Responsible Entities would need evidence of the security protection(s) from EIDSN. |
| CIP-012-1 | Enforcement | Inter-jurisdictional communications between entities that are subject to CIP-012-1 Requirements, entities that are not subject to CIP-012-1 Requirements, or have different enforcement dates, how is compliance enforcement expected to be handled in such scenarios?
| If the Responsible Entity is subject to CIP-012-1 Requirements that are in effect and enforceable, and the Responsible Entity cannot demonstrate it has implemented a documented plan to mitigate the risks posed by unauthorized disclosure and unauthorized modification of Real-time Assessment and Real-time monitoring data while being transmitted between Control Centers, then the Responsible Entity could have a potential noncompliance. |
| CIP-012-1 | Enforcement | R1 uses the verbiage, "...to mitigate the risks posed by unauthorized disclosure and unauthorized modification …" Are these risks left to the Responsible Entity to define? | The Standard is focused on protecting the confidentiality and integrity of RTA/RTm data, and the Responsible Entity is required to protect against the risks posed by unauthorized disclosure and unauthorized modification. Each Responsible Entity should identify those risks based on their environment (transmitting RTA/RTm) and implement the security protection(s) to address those risks and met the objective of the Reliability Standard.
|
| CIP-012-1 | Evidence | What would that evidence review consist of, network diagrams? | Diagrams would be helpful to identify physical access controls, internal controls, demarcations, Cyber Assets that are applying the security controls, and communication links. Also, the ERO Enterprise may leverage live demonstrations and physical walkthroughs for security protection(s) reviews. |
| CIP-012-1 | Evidence | What would be appropriate evidence for entity internal Control Center to Control Center RTA/RTm? | Documentation and evidence that security protection(s) to protect from unauthorized disclosure and unauthorized modification are implemented for Real-time Assessment and Real-time monitoring data transmitted between Control Centers is required. Ensure the R1 plan addresses the applicable Control Centers, the Real-time Assessment and Real-time monitoring data, and the security protection(s) implemented to protect the Real-time Assessment and Real-time monitoring data. Evidence artifacts such as a diagram showing the applicable Control Centers, methods to protect the communication link, etc. would also be helpful. |
| CIP-012-1 | Evidence | What would be appropriate evidence for entity external Control Center to Control Center RTA/RTm? | It is the Responsible Entity's responsibility to comply with CIP-012 and to coordinate with other Responsible Entities. With that said, documentation and evidence that security protection(s) to protect from unauthorized disclosure and unauthorized modification are implemented for Real-time Assessment and Real-time monitoring data transmitted between Control Centers is required, even if it is a third-party that is implementing the security protection(s). Ensure the R1 plan addresses the applicable Control Centers, the Real-time Assessment and Real-time monitoring data, and the security protection(s) implemented to protect the Real-time Assessment and Real-time monitoring data. Evidence artifacts such as a diagram showing the applicable Control Centers, methods to protect the communication link, etc. would also be helpful. |
| CIP-012-1 | Evidence | If we request the third-party communications carrier for output that shows that the Cyber Asset's logical or physical ports along with the method of encryption, would that be sufficient evidence? | This type of evidence would be acceptable as a form of evidence but would need to be combined with other types of evidence to demonstrate compliance with CIP-012-1. The ERO Enterprise recommends stacking as much evidence as possible to provide reasonable assurance of implementation. Evidence must be able to sufficiently demonstrate implementation of the Responsible Entity’s R1 plan. |
| CIP-012-1 | Evidence | Diagram and IPSEC configuration are doable, but IDS/IPS (or other tools detecting unauthorized access/modification might be tough, especially because most will be terminated (encryption) at gateway level... IDS/IPS may not do deep inspections due to laten | Security protection(s) used to mitigate the risks posed by unauthorized disclosure and unauthorized modification of RTA/RTm data should have evidence to confirm the security objective of Requirement R1 has been met. Depending on the facts and circumstances of a Responsible Entity’s implementation, diagrams and IPSEC configurations may not be enough evidence to show compliance.
|
| CIP-012-1 | Evidence | What evidence will be needed to demonstrate compliance for an ICCP link between two entities that is not applicable to CIP-012? | The Responsible Entities must be prepared to demonstrate the assessment determining how the Responsible Entity’s Inter-Control Center Communication Protocol (ICCP) communication link(s) are not transmitting RTA/RTm between Control Centers and therefore not applicable to CIP-012-1.
|
| CIP-012-1 | Evidence | The measure in R1 states, "Evidence may include, but is not limited to, documented plan(s) that meet the security objective of Requirement R1 and documentation demonstrating the implementation of the plan(s)." What is the ERO Enterprise's expectation in | The CIP-012-1 Purpose states, "To protect the confidentiality and integrity of Real-time Assessment and Real-time monitoring data transmitted between Control Centers." From an evidentiary perspective, the ERO Enterprise recommends detailed R1 plans that include, but are not limited to: the risks identified; type of security protection(s), and where the security protections are applied; responsible party for security protection(s) implementation; and how the implemented security protection(s) mitigate the risks posed by unauthorized disclosure and unauthorized modification of RTA/RTm data. Diagrams may be helpful to show physical access controls, demarcations, Cyber Assets that are applying the security protection(s), and/or communication links. Responsible Entities may also consider providing configurations, logs, etc. of those devices implementing the security protection(s). In addition, detailed agreements outlining each Responsible Entity’s controls and responsibilities have also helped demonstrate meeting the security objective.
|
| CIP-013-1 | General / Applicability | Will NERC audit the vendors to ensure they are in compliance with CIP-013-1? | No, the requirements of CIP-013-1 apply only to registered entities, consistent with NERC’s jurisdiction. The registered entity is responsible for complying with CIP-013-1 and for ensuring the vendor is performing in accordance to any contract/agreement. Vendor performance and adherence to a contract is outside the scope of CIP-013-1. |
| CIP-013-1 | General / Applicability | What additional frameworks did registered entities consider in development of Supply Chain Risk Management Programs? Furthermore, are entities developing one or more risk assessment questionnaires? | Entities considered NIST, NAGF guidance, NATF guidance, EEI guidance, SOC2, and ISO 27001 in developing their SCRM programs. In most cases, registered entities used two risk assessment questionnaires, one for vendors and one for products or services. |
| CIP-013-1 | General / Applicability | Is a registered entity a vendor if they are providing non-reliability services for another registered entity (i.e., relay technician, substation maintenance work)? | In this situation, the registered entity providing the non-reliability service could be considered a vendor providing related services. The Supplemental Material on page 12 of CIP-013-1, states, “The term vendor(s) as used in the standard is limited to those persons, companies, or other organizations with whom the registered entity, or its affiliates, contract with to supply BES Cyber Systems and related services. It does not include other NERC registered entities providing reliability services (e.g., Balancing Authority (BA) or Reliability Coordinator (RC) services pursuant to NERC Reliability Standards). 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.” |
| CIP-013-1 | General / Applicability | What if a registered entity does not allow active vendor remote access to applicable BES Cyber Systems and associated Cyber Assets, does a registered entity still have to provide anything for CIP-005-6 R2 Part 2.4 and R2 Part 2.5? | Yes, a registered entity would be required to document that it does not allow any active vendor remote access. A registered entity would include one or more methods for determining and disabling active vendor remote access sessions in the event such sessions become necessary. |
| CIP-013-1 | General / Applicability | Is a registered entity a vendor if they are providing products such as hardware or software (BES CyberSystems)? <br> | Yes, in the Supplemental Material on page 12 of CIP-013-1, states, “The term vendor(s) as used in the standard is limited to those persons, companies, or other organizations with whom the registered entity, or its affiliates, contract with to supply BES Cyber Systems and related services. It does not include other NERC registered entities providing reliability services (e.g., Balancing Authority or Reliability Coordinator services pursuant to NERC Reliability Standards). 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.” The definition does not exclude registered entities as vendors if they are providing products such as hardware or software. |
| CIP-013-1 | General / Applicability | Is it necessary to implement CIP-013-1 R1 Part 1.1 for resellers? | Product resellers are cited in the CIP-013-1 Supplemental Material section as potential vendors, “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 [emphasis added]; or (iii) system integrators” (p. 12). Depending on the specific reseller and the item(s) procured through the reseller, there may be additional cybersecurity risks associated with such procurements beyond those identified and assessed for the product manufacturer(s) or the product type(s) in the Part 1.1 cybersecurity risk identification and assessment (i.e., hardware and/or software obtained through a reseller). A registered entity would identify and assess any cybersecurity risks that may be involved in purchasing such applicable hardware or software from resellers. |
| CIP-013-1 | General / Applicability | What obligations for CIP-013 would the co-op be responsible for if any? Who would be responsible for performing the Risk Assessment, the co-op or the other company? | Under CIP-013-1, 4. Applicability, 4.2 Facilities, it states, “For the purpose of the requirements contained herein, the following Facilities, systems, and equipment owned by each Responsible Entity in 4.1 above are those to which these requirements are applicable.” Additionally, R1. Is applicable to all procurements associated with high and medium impact BES Cyber Systems. As written, the compliance obligations ultimately reside with the Responsible Entity who owns the Facilities with identified high or medium impact BES Cyber Systems. It would be expected that the Responsible Entity perform the risk assessment according to their documented plan to include analyzing risks posed by the vendor, equipment, and services provided, if applicable. These risks are then to be mitigated accordingly. In the scenario where there is joint or shared ownership, it is expected that both Responsible Entities coordinate or perform joint or separate risk assessments. |
| CIP-013-1 | General / Applicability | Will auditors have visibility to a registered entity's audits on vendors? | The entity dictates what artifacts of evidence best demonstrates compliance with the Standard
Requirements. If prescribed by the SCRM plan, entities could provide the results of their audit on vendors
to show due diligence in identifying and assessing cyber security risks.
|
| CIP-013-1 | General / Applicability | Prior to October 1, 2020, what if a registered entity has Cyber Assets that were purchased in bulk and stored as inventory, then after July 1, 2020, some or all are commissioned as a BCA? Does the registered entity have to implement CIP-013-1 R2? | Any procurement on and after October 1, 2020, of BES Cyber Systems from vendor products or services resulting from: (i) procuring and installing vendor equipment and software; and (ii) transitions from one vendor(s) to another vendor(s) are subject to CIP-013-1. |
| CIP-012-1 | Hops and Skips | If you have communications between two entities, it is clear that each needs to have controls between the two entities. But, if an entity has CIP-012 control center communications to an RC control center, does the entity's responsibility end there or is the entity responsible for verifying the communications between the RC and other entities that are utilizing data that is being used by your control center from other entities?
| The ERO Enterprise notes that security protection(s) would need to be used to mitigate the risks posed by unauthorized disclosure and unauthorized modification of Real-time Assessment and Real-time monitoring data while being transmitted between Control Centers. Responsible Entities are responsible for their own Control Centers and the security protection(s) implemented. However, per Requirement R1 Part 1.3, Responsible Entities are responsible for the identification of the responsibilities of each Responsible Entity for applying security protections to the transmission of Real-time Assessment and Real-time monitoring data between those Control Centers that are owned or operated by different Responsible Entities. |
| CIP-012-1 | Implementation | We are struggling with our partner entities to implement the technical controls that meet the security protections requirement. How can we encourage or incentivize entities to complete their technical implementations? | Some Responsible Entities will be moving in the direction to self-report. Other Responsible Entities are taking the approach to meet the security objectives through physical access control and change management on the other end of the communication link. Both sides of the communication link need to be aware, identified, and documented within their own R1 plan. |
| CIP-012-1 | Plan | Do we need to document in our R1 plan what the entity on the other end of the communication link is doing for protections? | Yes, Requirement R1 Part 1.3 indicates the need to collaborate with each other and document accordingly each of the responsibilities as part of that collaboration. |
| CIP-012-1 | Plan | Is there an expectation of maintaining the list of all connections, the entity on the other end and what protections are in place? | The ERO Enterprise would recommend maintaining documentation that demonstrates all Responsible Entities include identification of the responsibilities of each Responsible Entity. Documentation such as lists, diagrams, etc. would help provide reasonable assurance of implementation of Part 1.3. Without such documentation, situational awareness and implementation of security protection(s) could be challenging. |
| CIP-013-1 | Risk Mitigation | What if an asset is purchased in bulk and stored as inventory, then later commissioned as a BCA? | When purchasing cyber assets in bulk, it is suggested that an entity have a plan for tracking assets in case they end up being used in CIP-applicable roles. Such an approach would provide a means to assess/mitigate risks as necessary. |
| CIP-013-1 | Risk Mitigation | R1.1 requires: "One or more process(es) used in planning for the procurement of BES Cyber Systems to identify and assess cyber security risk(s) to the Bulk Electric System":<br>Can risks be accepted, instead of mitigated, after they have been as | The assessment, acceptance, mitigation, and transfer of risk is part of what the entity will work through in developing the supply chain cyber security risk management plan(s). Categorizing risk (e.g. high, medium, low) and then performing the risk management processes is a good path forward. |
| CIP-013-1 | Risk Mitigation | R1.2.2 – Coordination of responses to vendor-identified incidents related to the products or services provided to the Responsible Entity that pose cyber security risk to the Responsible Entity What type of coordination is expected? How is coordination to | Whatever the notification mechanism is (e.g., email), the entity should show the processes by which the coordination takes place. Any expectations (time frame, levels of severity, etc.) should be consistent with an entity’s overall incident response plan(s). |
| CIP-013-1 | Risk Mitigation | What should a registered entity do if a vendor is purchased by another vendor? | One approach is to ensure the registered entity’s SCRM plan details the process to re-evaluate or reassess the vendor(s). This should include the controls the registered entity deploys to maintain awareness of possible vendor acquisitions. |
| CIP-013-1 | Risk Mitigation | Would a registered entity be found non-compliant if their SCRM plan included a provision for an after the fact risk assessment to be conducted for applicable medium and high impact BES Cyber Systems implemented under emergency situations? | CIP-013-1 is applicable to any procurement regardless of the scenario, including an emergency. CIP-013-1 is silent to any special provisions such as emergency procurements. A registered entity may identify certain hardware, software or services that may be used during emergencies and perform risk assessments in planning for these situations to mitigate the supply chain risk.
Although the CIP-013-1 Standard does not directly address emergency procurements, the registered entity
could consider including language in its R1 SCRM procurement plan that addresses the potential for the
use of purchasing cards in emergency situations. The registered entity should document the emergency
procurement process in the R1 SCRM procurement plan, along with documentation that registered entity
personnel or approved contractors verified after-the-fact risks and mitigations of the procurement. |
| CIP-013-1 | Risk Mitigation | What if my vendor cannot adhere to one or more sub-parts (1.2.1-1.2.6) in Part 1.2 for CIP-013-1? | The registered entities are still responsible for implementation of Part 1.2 in R1. Registered entities should have documented and implemented controls for Part 1.2 in the absence of vendor adherence. For example, if the registered entity’s vendor is not notifying it of vendor-identified incidents, then it may implement a control that monitors US-CERT, ICS-CERT, E-ISAC, and NERC Alerts. |
| CIP-013-1 | Risk Mitigation | What is the registered entity’s obligation to mitigate an identified risk, if the vendor does not agree under the contract, for example, shipping and delivery? | A vendor’s intentional or unintentional ability to adhere to the conditions of an agreement as it relates to CIP-013-1 should be identified and assessed as a risk. As with all of the risks, it is the responsibility of the registered entity to mitigate them accordingly. As an example, the registered entity may address this risk by the implementation of internal controls and processes such as using reputable shippers, tracking shipments, and requiring signatures on delivery. |
| CIP-013-1 | Risk Mitigation | What is sufficient evidence to document cases in which vendors refuse to meet the CIP-013 R1 Part 1.2 Requirement Parts? | In this case, the procurement documents (e.g., RFP and vendor response evaluation matrices) used for a specific applicable procurement, along with any contract language connected to the procurement can serve as primary evidence the registered entity pursued its due diligence for the R1 Part 1.2 Requirement Parts, when the vendor failed or refused to comply. As stated in R2, vendor performance and adherence to a contract is beyond the scope of R2, so the responsibility of compliance rests on the registered entity to demonstrate it implemented its Part1.2 processes as far as it could reasonably go without negating the procurement. Since the registered entity identified risk, it is incumbent on the registered entity to enact mitigating measures that would address the vendor’s refusal to meet the Requirement Parts. |
| CIP-013-1 | Risk Mitigation | What if your process(es) in CIP-013-1 R1 Part 1.1 identified cyber security risk(s) with a vendor and you still proceed with products or services from that vendor? | Any identified security risks should have some form of mitigation to reduce risk(s); simply accepting the risks is not adequate, unless the analysis performed demonstrates no other reasonable mitigations are available. |
| CIP-013-1 | Risk Mitigation | What level of the organization is appropriate to accept security risk from a vendor? | The entity-defined SCRM plan documents what level within the organization determines if a risk is acceptable. Furthermore, in instances in which risk must be accepted, entities are expected to document and implement other mitigating controls to minimize the accepted risk, as documented in the SCRM plan. It is incumbent that if a vendor exceeds your organization’s risk threshold, a thorough review and approval should be conducted to ensure a solid understanding of the risk and the mitigating controls afforded or needed to be implemented. Particularly if the risk is identified as having a high probability of causing adverse effects.
Further, entities may want to consider including a process to frequently review and discuss these types of
risk approvals. |
| CIP-013-1 | Risk Mitigation | What should registered entitles expect regarding effectiveness and efficiency of third party assessments<br>(Known vs. Unknown)? Overall risk management, Evidence Materials.<br> | It is incumbent on entities to understand the effectiveness and efficiency of third party assessments within their environment. Based on what is documented in the SCRM plan, entities determine if these files are appropriate as evidentiary files. |
| CIP-013-1 | Risk Mitigation | Should a registered entity identify and assess cyber security risks related to the vendor and/or product or service? | Both should be done to conduct an accurate cybersecurity risk identification and assessment.
-Vendor questionnaire
-Product or service questionnaire |
| CIP-013-1 | Risk Mitigation | Does a registered entity need to mitigate identified and assessed cyber security risks? | FERC Order No. 829
The security objective is to ensure entities consider cyber security risks to the BES from vendor products or services resulting from: (i) procuring and installing vendor equipment and software; and (ii) transitions from one vendor(s) to another vendor(s); and options for mitigating these risks when planning for BES Cyber Systems. |
| CIP-013-1 | Risk Mitigation | Should a registered entity include a provision for an after-the-fact cyber security risk identification and assessment under emergency situations? | CIP-013-1 is applicable to any procurement regardless of the scenario, including an emergency.
The registered entity should consider including language in its plan to address the potential for the use of purchasing cards in emergency situations.
The registered entity should consider conducting an after-the-fact cybersecurity risk identification and assessment and implement any mitigations of the procurement.
|
| CIP-013-1 | Risk Mitigation | How often should a registered entity re-assess a vendor? | Based on a given registered entity’s plan
-With every procurement
-Existing assessments could be leveraged
-When certain “triggers” are met such as being bought and sold
-Annually, bi-annually, etc. |
| CIP-013-1 | Risk Mitigation | Can a registered entity use a third-party service to conduct a vendor cyber security risk identification and assessment? | Third-party services could be used to complement a registered entity’s own cyber security identification and risk assessment.
|
| CIP-013-1 | Risk Mitigation | What if the registered entity’s vendor cannot adhere to one or more sub-parts (1.2.1-1.2.6)? | Registered entities should document and implement controls for Part 1.2 in the absence of vendor adherence.
For example, if the registered entity’s vendor is not notifying it of vendor-identified incidents, then a control that monitors US-CERT, ICS-CERT, E-ISAC, and NERC Alerts could be implemented. |
| CIP-012-1 | Risk Mitigation | We are to determine the risk, do we need to list the risks that we've identified? Do we need to specifically identify the risks and how we address them? | The Standard is focused on risks posed by unauthorized disclosure and modification. The ERO Enterprise recommends addressing any risk(s) identified within the R1 plan. However, a list is not required. |
| CIP-012-1 | Scope | What data is in scope? | The data in scope is Real-time Assessment and Real-time monitoring data in accordance with NERC Reliability Standards TOP-003 and IRO-010, and is agnostic to the protocol or medium. Security protection(s) to protect from unauthorized disclosure and unauthorized modification must be implemented for Real-time Assessment and Real-time monitoring data transmitted between Control Centers. Please note that if the end connection does not meet the definition of a Control Center, it is out of scope. |
| CIP-012-1 | Scope | One of our connections is to a DP; is that out of scope? | The ERO Enterprise observed an example where Real-time Assessment and Real-time monitoring data is being transmitted by communications between two Control Centers where one of the Control Centers belonging to an entity registered only as a DP. The ERO Enterprise noted that in Section 4, Applicability, of CIP-012, DPs are not listed as applicable functional entities. However, the ERO Enterprise noted that security protection(s) would be needed to mitigate the risks posed by unauthorized disclosure and unauthorized modification of Real-time Assessment and Real-time monitoring data while being transmitted between the Control Centers. Particularly, Part 1.3 would need to be documented and implemented for the Responsible Entity that is registered as an applicable functional entity. The ERO Enterprise recommends the Responsible Entities that are registered DPs also implement security protection(s) and also contact the applicable Region’s registration group; this is a security recommendation. |
| CIP-012-1 | Scope | What if we are transmitting RTA/RTM by communications between Control Centers via third-party owned and managed WAN Cyber Assets? | The ERO Enterprise noted that security protection(s) would be needed to mitigate the risks posed by unauthorized disclosure and unauthorized modification of Real-time Assessment and Real-time monitoring data while being transmitted between the Control Centers. The ERO Enterprise recommended collaboration, security protection(s) identification, and documentation with the third party to ensure the security objective of Requirement R1 is met and that there is evidence that demonstrates the implementation of the security protection(s). |
| CIP-012-1 | Scope | What if we are transmitting RTA/RTM by communications between Control Centers via Generation Facility Cyber Assets utilizing different protocols and methods? | The ERO Enterprise noted that security protection(s) would be needed to mitigate the risks posed by unauthorized disclosure and unauthorized modification of Real-time Assessment and Real-time monitoring data while being transmitted between the Control Centers. Although the Generation Facility did not meet the definition of Control Center per the NERC Glossary of Terms, and is not an applicable facility under CIP-012, the Generation Facility is being used to send Real-time Assessment and Real-time monitoring data to a Control Center owned by another Responsible Entity. Therefore, the Generation Facility is used for communications between the Control Centers regardless of the protocols and methods implemented. The ERO Enterprise recommended that both Control Centers and Responsible Entities collaborate, identify security protection(s), and document to ensure the security objective of Requirement R1 is met and that there is evidence that demonstrates the implementation of the security protection(s). |
| CIP-012-1 | Scope | What if we are transmitting RTA/RTM by communications between Control Centers via Generation Facility Cyber Assets identified as front end processors (FEP) and/or data aggregators that collect RTA/RTM data from two or more Generation Facilities? | The Responsible Entity identified the Generation Facilities that aggregate the Real-time Assessment and Real-time monitoring data from two or more Generation Facilities as data centers associated with the Responsible Entity’s Control Centers. The ERO Enterprise agreed with the Responsible Entity’s approach and noted that security protection(s) would be needed to mitigate the risks posed by unauthorized disclosure and unauthorized modification of Real-time Assessment and Real-time monitoring data while being transmitted between the Control Centers. Although the Generation Facility did not meet the definition of Control Center per the NERC Glossary of Terms, and is not an applicable facility under CIP-012, the Generation Facility is being used to send Real-time Assessment and Real-time monitoring data to Control Centers owned by the Responsible Entity. Therefore, the Generation Facility is used for communications between the Control Centers. The ERO Enterprise recommended that the Responsible Entity collaborate, identify security protection(s), and document to ensure the security objective of Requirement R1 is met and that there is evidence that demonstrates the implementation of the security protection(s). Last, the ERO Enterprise noted that this example could be applicable for Transmission Facilities. |
| CIP-012-1 | Scope | Is TOP-003 and IRO data the limitations of scope? | No, there may be other Real-time Assessment and Real-time monitoring data specifications that a Responsible Entity may identify. For example, PMU data may be used for a real-time State Estimator. The ERO Enterprise also recommends focusing on the interchange of data between Control Centers and implementation of internal controls. |
| CIP-012-1 | Scope | Is preparing for operation and restoration time horizon a suitable approach? | This seems to be a methodology to scope applicable data. The data in scope of CIP-012-1 is Real-time Assessment and Real-time monitoring data in accordance with NERC Reliability Standards TOP-003 and IRO-010. However, there may be other Real-time Assessment and Real-time monitoring data specifications that a Responsible Entity may identify. For example, PMU data may be used for a real-time State Estimator. This methodology seems reasonable to discover additional Real-time Assessment and Real-time monitoring data outside of TOP-003 and IRO-010. |
| CIP-012-1 | Scope | Our Control Centers have a router that is being utilized as a media converter. Are there concerns regarding the media converter? | There are no applicable systems in CIP-012-1 only applicable facilities and data. Applicable Control Centers are agnostic to the Control Center BES Cyber System impact rating. However, identification of the security protection(s) used to mitigate the risks posed by unauthorized disclosure and unauthorized modification of Real-time Assessment and Real-time monitoring data while being transmitted between Control Centers is applicable. The ERO Enterprise recommends including the Cyber Assets used to transmit the Real-time Assessment and Real-time monitoring data and Cyber Assets that implement the security protections within the Responsible Entity’s R1 plan. |
| CIP-012-1 | Scope | Would you consider the manned Control Center in one building and the data center on the same campus but different building as separate? | The NERC Glossary of Terms defines Controls Center, which includes the associated data centers. The ERO Enterprise would consider those as separate facilities.
|
| CIP-012-1 | Scope | How does Western Interconnection Synchrophasor Program (WISP) fit into CIP-012, especially if one entity considers its Synchrophasor system in-scope for CIP-012 and the other entity does not? | RTA/RTm data identification assessments may not always be aligned between Responsible Entities. However, Responsible Entities that identify those devices within their CIP-012 program may protect the communication path, not just the RTA/RTm data on the communication path to ensure appropriate controls are deployed.
|
| CIP-012-1 | Scope | If RTA/RTm data is stored in a data center and being sent to a remote data center, would that be considered in scope? | The ERO Enterprise recommends reviewing the definition of Control Center per the NERC Glossary of Terms. The definition includes associated data centers. A data center is considered a part of a Control Center.
|
| CIP-012-1 | Scope | Are after-the-fact (ATF) data regarded as RTA/RTm? Some entities have servers outside Control Center (i.e., a dmz) and intend to exchange ATF (close to real time) data dmz to dmz. | The ERO Enterprise does not view ATF data as RTA/RTm. However, this does not preclude each Responsible Entity from protecting ATF data in the same manner as RTA/RTm data, especially if it is being communicated on the same pathway.
|
| CIP-012-1 | Scope | How do I identify what data is applicable? | RTA/RTm data is defined in NERC Reliability Standards TOP-003 and IRO-010. Also, the data is agnostic to the protocol or media used. However, Responsible Entities may identify other RTA/RTm data specifications. For example, Responsible Entities may identify PMU data used for the State Estimator as RTA/RTm.
|
| CIP-012-1 | Scope | Can you elaborate on the definition of a Control Center? | The term Control Center is defined in the NERC Glossary of Terms. The ERO Enterprise has no further definition or criteria for Control Centers.
|
| CIP-013-1 | Software Source/Integrity | What about training and/or educating field operations personnel to verify the identity and integrity of the software source and software prior to installation? | Organizational processes can (and should) be created to ensure software is validated at a higher (centralized) organizational units (e.g. using a central repository), rather than relying on numerous field operations groups. One suggestion is to include the verification and integrity verifications in the patch management process, if possible. |
| CIP-013-1 | Software Source/Integrity | Can a registered entity provide signed software or hashes when possible but rely on attestations in some cases for both software source verification and software integrity verification (CIP-010-3 R1 Part 1.6)? | No, in general, ERO Enterprise audit teams do not accept attestations as primary evidence for performance-based Standards. Some vendors do not have the tools for end users to verify the software integrity obtained. If this were the case, the audit team likely would examine applicable mitigating measures taken for these exceptions. As CIP-010-3 R1 Part 1.6 states, “when the method to do so is available to the registered entity from the software source,” the ERO Enterprise recommends registered entities consider how vendor capability may impact the development of potential internal or external mitigation controls in lieu of vendor support for Part 1.6. The ERO Enterprise also recognizes not all software sources have secure methods for verifying the integrity of the software, so suggests the registered entity document these exceptions in the SCRM plan. If there is an instance where a method is not available to verify the integrity and authenticity of software, it is recommended to document the exception and any mitigating measures internally to reduce the supply chain risk of introduction of malware or counterfeit software. While not required, it
is a best practice to retain artifacts of the vendor’s available methods or lack thereof for the verification of software integrity and authenticity of all software and patches. This will provide an internal audit trail for the registered entity’s records to allow easy reference and may save research time in the event any of those methods should change in the future. For third parties performing the Part 1.6 controls, the audit team likely would expect the registered entity to demonstrate that it obtained the software update/install from the third party performing these services. |
| CIP-013-1 | Software Source/Integrity | Are existing deployed BES Cyber Systems grandfathered in under CIP-010-3 and CIP-005-6? | Only procurements for applicable BES Cyber Systems that occur on or after the effective date (October 1, 2020) are in scope for the CIP-013-1 procurement planning processes. However, CIP-005-6 (R2 Parts 2.4 and 2.5), and CIP-010-3 (R1 Part 1.6) become effective on October 1, 2020 and apply to all high and medium impact BES Cyber Systems, including existing applicable BES Cyber Systems. |
| CIP-013-1 | Software Source/Integrity | A registered entity buys equipment from a vendor with third-party software installed. What are your recommendations for showing evidence of due diligence? | The registered entity should use its SCRM plan to identify and assess the risks associated with the third party software installed. The results of this analysis would dictate what mitigations are appropriate to address the risks related to the third party software. Some common forms of evidence include, but are not limited to, checklists or the contents of a change ticket that documents the due diligence performed. |
| CIP-013-1 | Software Source/Integrity | Is open source software in scope for CIP-013-1 and CIP-010-3? | The Supply Chain Standards are silent on terms and conditions for procured products or services that registered entities may install. A registered entity should implement its risk identification and assessment methodology for all procurements and installations of open-source software on applicable BES Cyber Systems. |
| CIP-013-1 | Software Source/Integrity | What compliance documentation and evidence should a registered entity create and maintain to comply with CIP-013-1 R1 Part 1.2 and its sub-parts for software that has no associated vendor, such as open source software? | The registered entity may address Part 1.2.1 and Part 1.2.4 by developing one or more internal processes to identify and monitor reputable third-party sources for assessments and reports of applicable open source software incidents or vulnerabilities. The registered entity may consider developing a modified Part 1.2.5 process for acquiring, verifying, and authenticating such software and applicable patches, as released by reputable sources (e.g., for software upgrades or security patches for identified vulnerabilities). An example of this could be a completed evaluation that specifically addresses open source technology. |
