As I stated in this recent post, one of the biggest problems in the NERC community today is the fact that most NERC entities with high or medium impact Bulk Electric System (BES) environments don’t feel they can utilize the cloud without running into CIP compliance problems. When it comes to systems deployed in the cloud, including BES Cyber Systems, Electronic Access Control or Monitoring Systems and Physical Access Control Systems, that feeling is correct.
However, it isn’t correct when it comes to BES Cyber System Information (BCSI) stored and utilized in the cloud. The wording problems that previously prevented compliant use of BCSI in the cloud (primarily by SaaS – software as a service – applications) were fixed when two revised standards, CIP-004-7 and CIP-011-3, came into effect in 2024.
Yet, today there isn’t significantly more use of BCSI in the cloud than there was five years ago. Here’s the history:
1. NERC CIP version 5 – which completely rewrote the CIP standards and introduced new terms like BES Cyber System and BCSI – came into effect on July 1, 2016. Because of an unintended quirk in the wording of several Requirement Parts in CIP-004,[i] NERC entities could not store or utilize BCSI in the cloud.
2. In 2019, a Standards Drafting Team (SDT) started working on new versions of CIP-004 and CIP-011 that fixed this problem in an elegant way that required just a few changes to the existing requirements, plus one new requirement: CIP-004-7 R6. CIP-004-7 and CIP-011-3 were approved by NERC and FERC; they became enforceable on January 1, 2024.
3. Throughout the period during which it was impossible to compliantly use BCSI in the cloud, customers of a popular SaaS product continued to use it as a tool to maintain compliance with the requirements that mentioned BCSI. Moreover, they continued to pass CIP audits. I didn’t (and still don’t) have any objection to this, since the CIP-004 language that caused the problems was not put in there to prevent cloud usage of BCSI. That language was in place because in 2011-2012, when CIP version 5 was being drafted, the cloud was considered by most NERC entities to be an experimental technology that would never be used for important systems. There was no need even to consider it as a use case for CIP compliance.
4. Of course, since the two revised standards became enforceable and BCSI in the cloud was “permitted”, NERC entities have continued to use the popular SaaS product for CIP-010 R1 and R2 compliance. I have heard no reports of NERC entities being cited for violation of the three new or revised BCSI requirements, either before or after January 2024.
However, since the two revised standards became enforceable, it appears there has been little (if any) use of BCSI in the cloud by NERC entities with high or medium impact BES environments, outside of the exception noted above. This is almost certainly because neither NERC nor the NERC Regional Entities have provided any useful guidance on compliance with CIP-004-7 and CIP-011-3.[ii] NERC has only provided one webinar and endorsed one document – prepared for another purpose – as “Implementation Guidance”. However, neither the webinar nor the document came close to providing actual guidance; I discussed both the webinar and the document in this blog post.
If there were to be a true guidance document on CIP compliant use of BCSI in the cloud, what would it include? It would be fairly simple. After all, there are only three requirements in scope here: CIP-004-7 R6 (introduced in version 7 of CIP-004), CIP-011-3 R1 (minimally revised in version 3 of CIP-011), and CIP-011-3 R2 (unchanged since CIP-011-1 was introduced as part of CIP version 5 in 2016, although it’s also relevant when BCSI is stored in the cloud).
CIP-011-3 R1
The guidance should start with CIP-011-3 R1, which starts with the wording, “Each Responsible Entity shall implement one or more documented information protection program(s) for BES Cyber System Information (BCSI) pertaining to “Applicable Systems” identified in CIP-011-(2 or)3 Table R1…” Requirement R1 has two Requirement Parts.
Part R1.1 requires the NERC entity to identify BCSI; BCSI is BCSI no matter where it is stored or used. Therefore, the SDT that drafted the BCSI changes didn’t change that Requirement Part at all.
However, the team did change the last of the four Measures listed for R1.1. In CIP-011-2 (the version that was replaced when CIP-011-3 became enforceable), that Measure read, “Repository or electronic and physical location designated for housing BES Cyber System Information in the entity’s information protection program” (emphasis is mine).
In CIP-011-3, that Measure reads, “Storage locations identified for housing BCSI in the entity’s information protection program.” Since the wording is close to identical, I don’t think this change should have any effect on what you do (especially because the Measures section of any CIP Requirement is not auditable)[iii].
In CIP-011-2, the wording of Requirement Part R1.2 was “Procedure(s) for protecting and securely handling BES Cyber System Information, including storage, transit, and use”. However, this changed to “Method(s) to “protect and securely handle BCSI to mitigate risks of compromising confidentiality” (my emphasis) in CIP-011-3.
Both versions of CIP-011 Requirement Part R1.2 are objective based[iv]. However, in the CIP-011-2 version, the objective is to have “Procedures for protecting and securely handling BES Cyber System Information”. In the CIP-011-3 version, the objective is to “protect and securely handle BCSI to mitigate risks of compromising confidentiality.”
As long as you state the objective as it is described in CIP-011-3, I don’t think you need to change or remove anything else in your existing Information Protection Program (IPP) regarding BCSI stored and used on premises. However, you will need to add to your plan procedures for “protecting and securely handling” BCSI in storage, transit and use in the cloud. In practice, the most likely case in which you will store and/or use BCSI in the cloud, or transmit it to the cloud, will be in a SaaS application that requires BCSI access.[v]
This means you need to include in your IPP information on how both you and the SaaS provider protect and securely handle your BCSI. If the provider will not provide that information (which they should do for all their customers, since BCSI does not require any special protection that would not also be needed for other sensitive information), then you need to piece it together yourself. To do that, you can use information available on their web site or in recent ISO 27001 or SOC 2 Type 2 audit reports (which should be provided to all customers on request).
Of course, you will need to provide this information for each SaaS provider that utilizes BCSI (or any other cloud-based service provider, such as a managed security service provider). The information needs to be included in your Information Protection Plan. Like all the other measures described in your IPP, you will need to provide proof during audits that each SaaS provider has implemented and is following those measures (which does not mean you need evidence the provider followed them every minute of every day).
There is another type of information that needs to be in your IPP, that also was not required before January 2024. That is information on how the SaaS provider, Platform Cloud Services Provider (PCSP), or Cloud-based Managed Security Service Provider (CMSSP) – which I collectively refer to as Cloud Service Providers (CSP) - will manage “provisioned access” to BCSI, as described in CIP-004-7 Requirement R6. See the discussion of that Requirement below.
The most important change between CIP-011-2 Requirement Part R1.2 and CIP-011-3 R1.2 is found in the Measures section (which is not in itself auditable, but is something that NERC entities pay close attention to). In CIP-011-2, the Measures section reads:
Examples of acceptable evidence include, but are not limited to:
· Procedures for protecting and securely handling, which include topics such as storage, security during transit, and use of BES Cyber System Information; or
· Records indicating that BES Cyber System Information is handled in a manner consistent with the entity’s documented procedure(s).
In CIP-011-3, the Measures section for R1.2 includes the above virtually unchanged. However, it also includes the following:
Examples of evidence for off-premise BCSI may include, but are not limited to, the following:
· Implementation of electronic technical method(s) to protect electronic BCSI (e.g., data masking, encryption, hashing, tokenization, cipher, electronic key management); or
· Implementation of physical technical method(s) to protect physical BCSI (e.g., physical lock and key management, physical badge management, biometrics, alarm system); or
· Implementation of administrative method(s) to protect BCSI (e.g., vendor service risk assessments, business agreements).
These new Measures are to accommodate BCSI stored and/or used in the cloud, although the word “cloud” is never mentioned. In practice, only the first bullet point should be taken seriously. Within the first bullet point, it seems to me that the only two options that should be seriously considered are encryption and electronic key management; of course, these are both needed when BCSI is stored in used or stored in the cloud.
The second bullet point has to do with hard-copy BCSI, which obviously should not be an issue in the cloud. The last point is a real head-scratcher. Did whoever drafted it really believe that requiring the SaaS provider to sign a non-disclosure agreement constitutes adequate protection of BCSI? I can’t imagine that any CIP auditor would accept that as adequate protection for BCSI.
CIP-011-3 R2[vi]
As I already stated, this requirement has not changed since it was implemented as part of CIP-011-1 R2 in 2016. However, what has changed in CIP-011-3 is that the requirement now also applies to BCSI stored by a cloud service provider (CSP), not just BCSI stored on premises. Just as the NERC entity needs to provide evidence that, before “release for reuse” or “disposal” of storage media containing BCSI, they “take action to prevent the unauthorized retrieval of BCSI from the Cyber Asset or the data storage media”, the NERC entity is now also required to provide similar evidence regarding a cloud service provider that stores their BCSI (usually as part of a SaaS application).
Of course, it is unlikely that most CSPs will be willing to provide any evidence about a specific practice like this, other than to point the NERC entity to general information on their security practices available on their website, or to ISO 27001 or SOC 2 Type 2 audit reports that are made available to all customers on request. The NERC entity will need to find the relevant information in those documents and reformat it so that, as closely as possible, it describes how the CSP’s practices comply with the requirement.
Note that compliance with CIP-011-3 Requirement R2 does not require the NERC entity to retain evidence that, in every instance in which a Cyber Asset or data storage medium (e.g., a hard drive) was released for reuse or disposed of, either the entity itself or a CSP utilized by the entity took actions to “prevent unauthorized retrieval of BCSI from the Cyber Asset or the data storage media.” Instead, they will need to provide evidence, to the best of their ability, that both they and the CSP had in place a policy that complies with both parts of this requirement, and that this policy was implemented.
CIP-004-7 Requirement R6
Neither CIP-011-3 Requirement R1 nor R2 marks a departure from the previous versions of the standard. However, the third “BCSI requirement”, CIP-004-7 Requirement R6, introduces a new concept, “provisioned access”. This concept addresses a concern that is unique to storage or utilization of BCSI in the cloud. It will probably be the biggest source of questions from NERC entities that utilize SaaS applications that require BCSI access.
The term “provisioned access” is not defined in the NERC Glossary, but Requirement R6 states:
To be considered access to BCSI in the context of this requirement, an individual has both the ability to obtain and use BCSI (my emphasis). Provisioned access is to be considered the result of the specific actions taken to provide an individual(s) the means to access BCSI (e.g., may include physical keys or access cards, user accounts and associated rights and privileges, encryption keys).
CIP-004-7 Requirement R6 Parts 1, 2 and 3 respectively address authorization, periodic verification of, and revocation of provisioned access to BCSI. Why was a new term required for BCSI access, since the previous versions of CIP-004 had similar Requirement Parts that applied to “access” to BCSI, not “provisioned access”?
Lew Folkerth of the RF Region wrote the best (and perhaps the only) interpretation of the new BCSI requirements that I’ve seen in one of his “The Lighthouse” columns in 2022, shortly after FERC approved the two revised standards in December 2021. (BTW, if you’re at all interested in NERC CIP, you should read Lew’s columns regularly. They are in RF’s bi-monthly newsletter, which you can subscribe to at rfirst.org. There is also a Resources page that has PDFs of his old columns, going back to at least 2015).
In that column, Lew provided this great metaphor explaining provisioned access:
Think of BCSI as a car parked in your locked garage. Only you and your family may obtain (be able to touch) the car. However, this level of access is worthless without the ability to get into the car and drive away.
That requires that you can both obtain the car and have the keys to unlock and drive (use) the car. You might park the car on a street (cloud environment) so that an unauthorized individual could obtain the car, but if you lock (encrypt) the car, no unauthorized individual can use the car.
The car might be towed away, denying you the ability to obtain the car, but whoever towed the car still cannot use the car without the keys.
For BCSI stored unencrypted on the NERC entity’s premises, provisioned access is no different from normal access. If someone has physical access to the device on which the BCSI is stored and electronic access to the data store that contains the BCSI, they have access to the data – i.e., they can both obtain and use the BCSI. This is because BCSI stored on premises is usually not encrypted.
However, in the cloud, where BCSI is (hopefully) always encrypted, many CSP employees may have physical and electronic access to the devices and data stores that contain BCSI, but if they don’t also have provisioned access (i.e. to the decryption keys), they can’t utilize the data.
Of course, you might wonder why a cloud employee would ever need provisioned access. After all, since the NERC entity will usually require control of the decryption keys and since the BCSI needs to remain encrypted at all times, both in motion and at rest, the CSP staff should never need to decrypt the data, right?
No, that’s not right. It might normally be the case that they will never need to utilize the decrypted data, but there could be emergencies like a data dump due to a system crash, in which a CSP employee will need to be able to look at unencrypted data to fix the problem. Therefore, they will need to have provisioned access to recover the data and re-encrypt it. There may not be time to ask someone at the NERC entity to do this work remotely, even if that is possible. Someone at the CSP will need to have provisioned access, or at least be given it immediately when needed, without first asking the NERC entity to authorize them.
Another problem is that at least some SaaS products cannot utilize encrypted data, meaning that BCSI needs to be decrypted before being “fed in” to the product. The person that does that will need to have provisioned access to the BCSI.
CIP-004-7 R6.1 requires that provisioned access be authorized “based on need”. Moreover, need is “determined by the Responsible Entity”. To authorize provisioned access to a NERC entity’s BCSI in an emergency, the NERC entity will need to perform some action like:
1. Authorize John Jones, Suzie Smith, Bill Brown, Tina Thomas, and Jay Jacobs to receive short-term provisioned access to BCSI in an emergency; the CSP will need to record who was given provisioned access and share this information periodically with the NERC entity.
2. Negotiate a delegation agreement with the CSP, authorizing management to provision temporary BCSI access during an emergency, for any employee who meets certain agreed-upon criteria. Periodically, the CSP will need to report to the NERC entity who has been given provisioned access during that period, as well as how they met the criteria.
3. If the CSP will not sign a special contract with one customer, the entity might authorize the CSP to use a tool in which the NERC entity can store their key(s) without revealing them to the CSP. Those keys are then encrypted using a key known to both the NERC entity and a certain group of employees at the CSP, who meet criteria approved by the entity. Should an event occur in which BCSI needs to be decrypted (e.g., so it can be fed into a SaaS product that only accepts decrypted data), one of the group of CSP employees would enter the shared key into the tool. This would allow the tool to decrypt the NERC entity’s key and use that to decrypt the BCSI – all the while preventing any CSP employee from seeing or possessing the NERC entity’s key.[vii]
Of course, there are other means by which BCSI access can be provisioned by a CSP when necessary, without granting long-term access to the NERC entity’s decryption keys. The entity needs to decide with the CSP the best means of doing this. If they can’t reach agreement, the NERC entity may need to find a different CSP, or else not store or utilize BCSI in the cloud.
If you would like to comment on what you have read here, I would love to hear from you. Please email me at [email protected] or comment on this blog’s Substack community chat.
Tom Alrich’s Blog, too is a reader-supported publication. You can view new posts for one month after they come out by becoming a free subscriber. You can also access my 1300 existing posts dating back to 2013, as well as support my work, by becoming a paid subscriber for $30 for one year.
[i] Until 2024, CIP-004 effectively required that anyone with “physical access” to BCSI needed to have a “personnel risk assessment” (PRA) conducted by the NERC entity, along with CIP training provided by the entity. However, “physical access” didn’t take account of encryption. This meant that, even if the BCSI in the server was encrypted, anyone who could just walk by that server had physical access to the BCSI. Thus, if a cloud service provider (CSP) – often a SaaS provider - used or stored BCSI from for example ten NERC entity customers, most people who worked in any data center where any of that BCSI was stored, even very briefly, needed to have a PRA and training carried out by each of the ten NERC entities whose BCSI was stored or used by the CSP. Of course, this was impossible.
[ii] Of course, the root of this problem is that neither NERC nor the Regions are permitted to provide actual compliance guidance; they’re limited to endorsing guidance produced by other groups. However, that policy hasn’t worked in the case of BCSI.
The document that NERC endorsed was produced by a NERC committee composed of NERC staff members and staff members from NERC entities (the Reliability and Security Technical Committee or RSTC). It’s a good document, but it was not written to be guidance. Thus, most of it does not have anything to do with compliance.
This is just another example of something I’ve been saying a lot recently: The only way for CIP to move forward (even for on premises systems, let alone the cloud) is to revise the NERC Rules of Procedure to finally allow NERC and Regional staff members, including auditors, to provide compliance guidance (other changes are needed as well). However, that will not be anywhere as easy as it might sound.
[iii] It’s possible that the change from “Repository or electronic and physical location designated for housing BES Cyber System Information” in CIP-011-2 to “Storage locations identified for housing BCSI” in CIP-011-3 has to do with the fact that the R1.2 Measures in CIP-011-3 distinguish between physical and electronic BCSI, whereas the R1.2 Measures in CIP-011-2 do not. In any case, it seems the meanings of those two phrases are close to identical. Since the Measures are not auditable, this is not a question that anyone should lose sleep over.
[iv] “Objective based” is the preferred form of CIP requirements nowadays. To comply with such a requirement, the Responsible Entity needs to achieve the objective, not perform specific tasks. The means to achieve the objective are mostly left up to the entity.
[v] If you utilize a cloud-based security monitoring service that needs BCSI access, that is another case of storing and utilizing BCSI in the cloud. However, you need to be careful about using any cloud based service that monitors (or controls) “electronic access” to your ESP or any of your medium or high impact BES Cyber Systems. A CIP auditor may determine that the cloud-based service constitutes an Electronic Access Control or Monitoring System (EACMS). Because of this, the service provider will need to furnish compliance evidence for around 70 CIP Requirements and Requirement Parts. I can promise that no provider of any cloud-based service will do that (in fact, I doubt SaaS providers and platform Cloud Service Providers will furnish any compliance evidence at all, other than let you see their most recent ISO 27001 or SOC 2 Type 2 audit report).
[vi] In the very limited guidance that NERC has put out on compliance with the new BCSI requirements, I have seen no mention of compliance with CIP-011-3 Requirement R2, although there is extensive discussion of Requirement R1. However, it seems to me (and to a well-known former NERC CIP auditor with whom I’ve had a lot of discussions regarding BCSI in the cloud) that R2 is just as much in scope for BCSI-in-the-cloud as is R1, since there is nothing in R2 that would restrict the scope of the requirement to on premises BCSI.
[vii] I was told that one large SaaS provider has a tool that operates like this.