Before the NERC “Risk Management for Third-Party Cloud Services” Standards Drafting Team can start drafting new or revised standards to make full use of the cloud available for NERC entities subject to compliance with the CIP cybersecurity standards, there are some fundamental questions they need to address. The most fundamental of these is what assets are in scope for compliance with those new or revised standards. It goes without saying that, if you can’t identify what you’re protecting, you can’t determine what protections are necessary.
Each of the current CIP standards states that it applies to BES Cyber Systems (BCS) “and their associated BES Cyber Assets” (BCA). A BCS is defined simply as a grouping of BES Cyber Assets (BCA), which are in turn defined as a special type of Cyber Asset that meets a long definition. A Cyber Asset is a “programmable electronic device”, which means a physical device, not a virtual one. Because a BCS is defined by the Cyber Assets that comprise it, this means the term can only apply to on-premises systems, not systems based in the cloud. There is no way that an individual NERC entity can track, let alone protect, individual devices in cloud data centers.
The SDT’s first step (and one I believe they have already taken) is to determine whether they want their new or revised CIP standards to address protection of both on-premises and cloud-based systems, or just the latter. Fortunately, I believe the SDT has already decided to have two “tracks” in the new CIP standards: one for on-premises assets and one for cloud-based assets.
That is a wise decision, since the 2018 experience of the CIP Modifications drafting team (at least one member of which is also on the Cloud CIP team) demonstrated that it is important not to change the CIP requirements for existing systems unless there is some good reason to do so. There isn’t a good reason in this case. While there are problems with the existing CIP standards, some of them are already being addressed by other drafting teams. The rest should be dealt with separately, not as part of the cloud effort.
Given that the new or revised standards will address only cloud-based assets, the question becomes what those assets should be. Just as in the current CIP standards, there will need to be multiple types of assets, but they will all be cloud-based. While I don’t think it would be a good idea to simply make “cloud versions” of each current CIP asset type (BCS, EACMS, PACS, PCA, etc.), I do think the best place to start would be with BES Cyber System, since that concept has been the foundation of the standards since CIP version 5 came into effect in 2016.
As I’ve just said, the current BCS definition implicitly refers to physical assets, so it can’t be used as the basis for requirements for cloud-based assets. How can we abstract physical assets (specifically, Cyber Assets) from the BCS definition, so we are left with something like “Cloud BCS”?
A BES Cyber System is defined as “One or more BES Cyber Assets logically grouped by a responsible entity to perform one or more reliability tasks for a functional entity.” This means that the essence of BCS is to be found in the BCA definition. I won’t repeat that whole definition here, but its most important component is the “15-minute rule”, which states that a BCA’s loss or compromise must “adversely impact” the Bulk Electric System within 15 minutes. Any Cyber Asset that doesn’t meet that criterion is not a BES Cyber Asset.
This means that, to track with the meaning of BCS as closely as possible without falling into the trap of referring to physical devices, a Cloud BCS needs to be defined as something like “A cloud-based system that if rendered unavailable, degraded, or misused 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. Redundancy of affected Facilities, systems, and equipment shall not be considered when determining adverse impact.”
While Cloud BCS isn’t the only type of asset that should be in scope for the Cloud CIP requirements, I believe it should be one of them. After all, if cloud-based assets are going to monitor and/or control the BES, they need to be in scope for at least some CIP standards. And, if cloud-based assets aren’t going to be permitted to monitor or control the BES, why is this drafting team even bothering to meet? They might as well say there’s no reason to change the current situation, in which cloud-based assets that monitor and/or control the BES are effectively forbidden, at least at the medium and high impact levels.
To produce this blog, I rely on support from people like you. If you appreciate my posts, please make that known by donating here. Any amount is welcome, but I consider anyone who donates $25 or more per year to be a subscriber. Thanks!
However, there is another type of asset that is only found in the cloud, that also needs to be defined for Cloud CIP (including having requirements that apply only to it); that is SaaS (software-as-a-service). Of course, not all SaaS is in scope for CIP, but I think any SaaS that is used in the processes of monitoring or controlling the BES should be in scope for Cloud CIP[i]. Perhaps the term might be “BES SaaS”.
Now the question becomes, “What is the difference between BES SaaS and Cloud BCS, since they’re both used in the processes of monitoring or controlling the BES?” I think the difference should be sub-15-minute impact. For example, let’s say a SaaS product analyzes power flows on the grid. When it notices a serious issue, it can change a relay setting without human intervention. Since that change will take effect immediately, the SaaS product clearly has a sub-15-minute impact on the BES; therefore, the SaaS product is a Cloud BES Cyber System.
Now, let’s say the same SaaS product has no connection to a relay. Instead, when it notices a serious issue, it suggests a new relay setting for an engineer working in a Control Center. It will be up to the engineer to decide whether to implement the suggested setting. In this case, there is no 15-minute impact. The SaaS is BES SaaS and should be subject to whatever requirements for BES SaaS are included in Cloud CIP.
Why should we even be concerned about BES SaaS, since it doesn’t have a 15-minute impact? We’re concerned because if someone fed bad information into the SaaS, it might suggest that the engineer do something harmful to the BES, like needlessly opening a circuit breaker and de-energizing a line. In other words, the BES SaaS systems themselves do not require special protection, but the information they receive does need to be protected.
Of course, the information in this case is BCSI – BES Cyber System Information. In fact, I believe that the current requirements that apply to BCSI, namely CIP-004-7 R6, CIP-011-3 R1, and CIP-011-3 R2, should continue in effect when the cloud CIP requirements are implemented. This is because the current BCSI requirements, which came into effect at the beginning of 2024, were developed specifically to make storage and use of BCSI in the cloud possible. Most (if not all) BCSI used in the cloud is utilized by SaaS.
A good example of BES SaaS is a cloud-based historian. Usually, historians are not considered BES Cyber Assets. This is because they are not usually used for real-time monitoring or control of the BES, but rather for after-the-fact review of processes that took place in a plant or other industrial environment.
What other asset types are likely to be in scope for the cloud CIP requirements? Besides BCS, there are two other current CIP asset types, Electronic Access Control or Monitoring Systems (EACMS) and Physical Access Control Systems (PACS). Like high and medium impact BCS, EACMS and PACS are not currently usable in the cloud. This is because the CSP would have to furnish their NERC entity customer with device-level compliance evidence for many CIP requirements. That evidence would be very costly and time-consuming to provide.
However, it is safe to assume that the new and revised Cloud CIP requirements, when finally drafted, approved and implemented, will enable medium and high impact BES Cyber Systems to be implemented in the cloud without an undue compliance burden. Since the CIP requirements that apply to EACMS and PACS are a subset of those that apply to BCS, it is also safe to assume that implementation of EACMS and PACS will be enabled by the new and revised Cloud CIP requirements.
EACMS and PACS are built on the concepts of Electronic Security Perimeter (ESP) and Physical Security Perimeter (PSP) respectively, neither of which is applicable in the cloud. So even though both of these asset types may in the future be implemented in the cloud, it will always be for the purpose of controlling and monitoring ESPs and PSPs.
When the SDT gets to the point of considering requirements for controls applicable to cloud environments, they may identify systems that are required to monitor and implement those controls, such as Cloud Access Security Brokers (CASB). Thus, there are likely to be other asset types in Cloud CIP, besides the ones I have just described.
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]. And while you’re at it, please donate as well!
[i] An alternative way of stating this might be that any SaaS product that performs one of the BES Reliability Operating Services (BROS) is BES SaaS. While the BROS long ago ceased to have any direct compliance impact in CIP, they are still a very useful concept for deciding whether or not a Cyber Asset is a BES Cyber Asset. For a description of the BROS, see pages 17ff of this old version of CIP-002. For a long explanation of how the BROS can be used, see this post.