What will the “Cloud CIP” standards protect?

While it might seem like the NERC CIP Reliability Standards are constantly going through major changes, in fact there has only been one major change since the CIP version 1 standards came into effect starting in 2008. That was the implementation of CIP versions 5 and 6 on a single day: July 1, 2016. In other words, there have so far been just two major “phases” of NERC CIP: versions 1 through 3 in 2008 through 2016, and versions 5[i] and later, starting in 2016 and continuing through today.[ii]

What distinguishes the first two phases of CIP, and how will we know when we’ve entered a new phase? It’s simple: You need to look at the “Purpose” statement at the beginning of each CIP standard and see what the standard is there to protect. You’ll know we’re in a new phase if the statement has changed since the previous version of the standard.

For example, the Purpose statement of CIP-002-1 (which came into effect in 2009) reads, “NERC Standards CIP-002 through CIP-009 provide a cyber security framework for the identification and protection of Critical Cyber Assets to support reliable operation of the Bulk Electric System (my emphasis).” Versions 1-4 of the NERC CIP standards were all designed to protect Critical Cyber Assets; these were defined as cyber assets that are “essential to the operation of” a Critical Asset (Critical Assets were certain Control Centers, generating stations and transmission substations that played a special role in the BES).

Starting with the CIP version 5 standards in 2016 and continuing today, the Purpose statements have referred to BES Cyber Systems[iii]. For example, the Purpose statement of CIP-007-6 (the current version of CIP-007) reads, “To minimize the risk against compromise that could lead to misoperation or instability in the Bulk Electric System (BES) from individuals accessing BES Cyber Systems by requiring an appropriate level of personnel risk assessment, training, security awareness, and access management in support of protecting BES Cyber Systems.”

However, when what I call the “Cloud CIP” standards, which are being developed by the current Project 2023-09 Risk Management for Third-Party Cloud Services Standards Drafting Team, come into effect, that will mark the beginning of a third phase; the new or revised standards will undoubtedly require new Purpose statements, as well as new applicable asset types.

For example, BES Cyber Systems are defined as groupings of BES Cyber Assets[iv], which are themselves a type of Cyber Asset. Because both BES Cyber Asset and Cyber Asset refer to physical devices, and because it’s not possible to track usage of physical devices in the cloud for compliance purposes, this means that BES Cyber Systems, as currently defined, cannot be the basis for CIP compliance in the cloud.

However, this doesn’t mean the term BES Cyber System will disappear when the Cloud CIP standards are implemented. Instead, it’s likely that the Cloud CIP standards will have two “tracks”: one for “on premises” BCS and the other for BCS implemented in the cloud. It’s safe to say that all NERC entities that operate on premises BCS today will continue to have them after the Cloud CIP standards come into effect, since there is no way that any electric utility (or generator, for that matter) could outsource their entire physical operations to the cloud.

In fact, it’s possible that, once the Cloud CIP standards come into effect, the Purpose statements of standards CIP-003 through CIP-011 and CIP-013 (the standards that are in place today and refer to BES Cyber Systems) will refer to protection of “On Premises BES Cyber Systems”, while the Purpose statements of one or more new standards (starting with CIP-016) will refer to protection of “Cloud BCS”.

But there’s something else that the current CIP standards protect, even though it’s not mentioned in any of the Purpose statements: BES Cyber System Information (BCSI). There are only three CIP Requirements and seven Requirement Parts that refer to BCSI: CIP-004-7 Requirement R6 Parts 6.1, 6.2 and 6.3; CIP-011-3 Requirement R1 Parts 1.1 and 1.2, and CIP-011-3 Requirement R2 Parts 2.1 and 2.2.

The BCSI concept has been around since CIP version 5 came into effect in 2016 (in fact, the definition is unchanged since then), but it was only when the current versions of CIP-004 and CIP-011 came into effect on January 1, 2024 that it became possible to store or utilize BCSI in the cloud, without fear of violating one or more of the BCSI requirements. Unfortunately, very few NERC entities have taken advantage of this development yet. 

Will the BCSI concept still be around when the Cloud CIP standards come into effect – i.e., when the third NERC CIP phase begins (which will likely be 3-6 years from now)? Yes. This is because, as far as CIP compliance is concerned, there are two types of services that need to be enabled in the cloud:

1.      “Systems in the Cloud”. These include cloud based BES Cyber Systems (“Cloud BCS”), cloud based Electronic Control or Access Monitoring Systems (“Cloud EACMS”), and cloud based Physical Access Control Systems (“Cloud PACS”).

2.      SaaS that uses BCSI.[v] I don’t believe that, when the Cloud CIP standards are implemented, any change will be needed, either to the definition of BCSI or to the three requirements that deal with BCSI today: CIP-004-7 R6, CIP-011-3 R1 and CIP-011-3 R2.

In discussions of the cloud and CIP, including discussions of the Standards Drafting Team now considering how Cloud CIP will work, the question often comes up about the difference between a cloud-based BES Cyber System and a SaaS application that performs the same function as a BCS. The best example of this question is a SCADA system. In other words, what’s the difference between transferring the software running on an on premises SCADA system to the cloud and utilizing the same SCADA software in the cloud as SaaS?

In my opinion, this is an easy question to answer. The defining characteristic of a BES Cyber System is that “if rendered unavailable, degraded, or misused”, it “would, within 15 minutes of its required operation, misoperation, or non-operation, adversely impact one or more Facilities, systems, or equipment, which, if destroyed, degraded, or otherwise rendered unavailable when needed, would affect the reliable operation of the Bulk Electric System.”[vi]

This means that a BCS installed in the cloud would need to be directly connected to some device in the “real world”, like a relay; that is the only way it could have a 15 minute impact. However, if the same SCADA software were installed in the cloud but didn’t have any direct connection to a device that can affect the BES (for example, if the software in the cloud doesn’t send a command to the relay, but instead advises the operator to send the command), it would be SaaS.

As I mentioned above, the two revised CIP standards that deal with BCSI, CIP-004-7 and CIP-011-3, were designed to make storage and use of BCSI in the cloud completely “legal”. While there are certainly other reasons to store and use BCSI in the cloud, the most important use is in SaaS applications that require use of BCSI, including configuration management, identity and access management, etc.

Even though the two revised standards came into effect on January 1, 2024, there has been a lot of confusion about how to comply with them. Probably because of this confusion, NERC entities are currently only using a small number of SaaS applications that require BCSI access.

Since it is now “legal” to store and utilize BCSI in the cloud, what’s the status of cloud based BCS? The compliance obligations for the two types of services are very different. There are only ten CIP Requirements and Requirement Parts that apply to SaaS use of BCSI, whereas there are over 100 Requirements and Requirement Parts that apply to cloud-based BCS (there are fewer than 100 Requirements and Parts that apply to EACMS or PACS in the cloud, but in both of these cases, there are many more Requirements and Parts than there are for SaaS that uses BCSI).

In other words, use of BCSI in SaaS is quite possible today, but use of cloud-based BCS, EACMS and PACS is still close to impossible – not because implementing these systems in the cloud directly violates any CIP requirement, but because it is highly unlikely that any CSP could ever produce the evidence required for a NERC entity to prove compliance with even a few of the 100+ currently applicable CIP Requirements and Requirement Parts[vii].

This is why NERC entities wishing to utilize cloud-based BCS, EACMS and PACS will need to wait for the “Cloud CIP” requirements to be implemented. However, that isn’t all that’s required. Because enforcing cloud-based CIP standards will likely require changes to the NERC Rules of Procedure, there might need to be a separate process to draft and ballot those RoP changes.

In other words, unless NERC takes some extraordinary measures soon (which is possible but not likely), implementation of medium and/or high impact BCS, EACMS or PACS in the cloud is still many years away; however, use of SaaS applications that require BCSI access is “legal” now. I plan to discuss how that can be done very soon.

My blog is more popular than ever, but I need more than popularity to keep it going. I’ve often been told that I should either accept advertising or put up a paywall and charge a subscription fee, or both. However, I really don’t want to do either of these things. It would be great if everyone who appreciates my posts could donate a $20-$25 (or more) “subscription fee” once a year. Will you do that today?

If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.

---

[i] You may notice I didn’t mention CIP version 4. CIP v4 was approved by FERC in 2012, but never came into effect. This was because FERC surprised many people (including me) by approving CIP version 5 in April 2013, and announcing that v4 would never come into effect.

[ii] Until CIP versions 5 and 6 were implemented in 2016, all the CIP standards were revised at the same time, even when only one or two of them had changed. For example, when FERC approved the CIP version 2 standards, they ordered a change that just applied to CIP-006-2: adding a Requirement R2, for escorted access of visitors inside a Physical Security Perimeter.

However, instead of just developing and balloting a new version of CIP-006 (CIP-006-3), the Standards Drafting Team had to revise each of the other standards, just to change the version number of the standard from 2 to 3. Not only did the SDT have to do that, but they had to submit all the standards to each of the three or four ballots that were required for NERC entities to approve the new version of CIP-006 (few if any new or revised CIP standards have required fewer than four ballots, before they were finally approved by the NERC ballot body). Thus, instead of just having to submit one standard for each of four ballots, the drafting team had to submit eight standards (CIP-002 through CIP-009. Note that CIP-010 and CIP-011 were added to the CIP standards with CIP version 5) for each of four ballots.

After that experience, the decision was made not to try to “rev” all the standards at once. Unless the wording of a standard has changed, its version number does not need to change. Of course, at that point the concept of a version number for the CIP standards as a whole (e.g., “CIP version XX”) no longer made sense. Instead, the individual CIP standards now carry version numbers from 2 through (soon) 9; they rev independently of each other. This doesn’t seem to be causing confusion, if it’s even noticed at all today.

[iii] I’ve always said that no statement can ever be made about NERC CIP that doesn’t have at least one exception. That’s certainly the case with this sentence. There are now three CIP standards that furnish exceptions to the rule that all new or revised CIP standards since 2016 are designed to protect BES Cyber Systems (BCS). First, CIP-012’s Purpose statement says that it protects “data transmitted between Control Centers”; it doesn’t mention BES Cyber Systems at all. Second, CIP-014’s purpose is to protect “Transmission stations and Transmission substations, and their associated primary control centers…”; again, there’s no mention of BCS. Finally, the recently approved CIP-015-1’s Purpose is “To improve the probability of detecting anomalous or unauthorized network activity in order to facilitate improved response and recovery from an attack.” Once again, BCS aren’t mentioned.

The reason these three standards don’t refer to BES Cyber Systems is so they can continue to be enforced even when BCS are replaced with another type of system (in other words, the requirements in these standards don’t apply to individual systems, so there’s no need to mention systems in the Purpose statements). On the other hand, standards CIP-002 through CIP-011 (as well as CIP-013) all apply to BCS; therefore, the Purpose statements will need to be rewritten when the concept of BCS is replaced with a new concept, or at least when the meaning of BCS is changed. As discussed later in this post, the meaning of “BES Cyber System” might change when the “Cloud CIP” standards are implemented.

[iv] The NERC Glossary definition is “One or more BES Cyber Assets logically grouped by a responsible entity to perform one or more reliability tasks for a functional entity.”

[v] Note that low impact cloud BCS have always been “legal” under CIP, although only a small number of low impact BCS have been implemented in the cloud, mainly in cloud-based low impact Control Centers.

[vi] Of course, this language is from the definition of BES Cyber Asset, not BES Cyber System. Since BCS is defined as a group of BCAs, a BCS “inherits” this property from its component BCAs.

[vii] For example, how could a CSP ever prove to a NERC entity that it had complied with CIP-007 Requirement R2 (patch management), since that requires tracking every device on which any part of a BES Cyber System has been installed at any moment throughout the three-year audit period - and since at any time, a single BCS might be split among 100 different servers in multiple data centers and might jump from server to server or data center to data center every minute of every day?

Note that, when it comes to SaaS providers, the story may be quite different, since no device-level information is required for compliance with the three BCSI requirements. Moreover, SaaS applications are often focused on particular industries, and their providers are usually accustomed to working with individual customers to meet their special needs. They are much more likely to bend over backwards to accommodate an electric utility customer than will a platform CSP.