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!
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 tom@tomalrich.com. 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.