Until I wrote this post
in August, I had always thought there was no problem if a NERC entity utilizes cloud
workloads that meet the definition of low impact BES Cyber System – for example,
a renewables producer that utilizes cloud-based SCADA software to perform some
or all of the functions of their low impact Control Center, even though this
same operation would be literally impossible (from a CIP compliance point of
view) for a medium or high impact Control Center.
However, in that post, I looked at the most important (in
fact, the only) CIP Requirement that applies to low impact BCS: CIP-003-8 Requirement
R2. R2 requires the entity with low impact BCS to “…implement one or more
documented cyber security plan(s) for its low impact BES Cyber Systems that
include the sections in Attachment 1.”
Attachment 1 is found on pages 23-25 of CIP-003-8. It
includes five Sections; the Responsible Entity needs to document a plan to
address each of those Sections. Using primarily Sections 1 and 3 as examples
(although the same argument would apply to Sections 2, 4 and 5 as well), I
showed in the post that it would be almost impossible for a NERC entity that
utilizes cloud-based low impact BCS to provide the required evidence of
compliance at an audit.
The reason I stated for this is the same one I’ve stated for
medium and high impact BES Cyber Systems: Since the current NERC CIP requirements
were written under the assumption that they would apply to on-premises systems
(or else systems located on a third party’s premises that are under the complete
control of the Responsible Entity), the required evidence could never be
provided by the Cloud Service Provider (or SaaS provider). I concluded that technically,
utilizing cloud-based workloads is no more “legal” for low impact BCS than it
is for medium or high impact BCS, although I also opined that an auditor was
much more likely to give the entity a “pass” for low BCS in the cloud than for mediums
or highs. Therefore, I didn’t recommend that anybody rip their low BCS out of
the cloud, at least for the time being.
However, on further reflection recently, I realized that
this argument doesn’t take into account the unique way in which CIP compliance for
low impact BCS differs from compliance for high and medium impact BCS. I’ll
warn you that my explanation below requires diving into the deepest and darkest
recesses of CIP-002-5.1a:
1.
CIP-002-5.1a Requirement R1 starts by listing
six types of “assets” (a term which has never been defined, even though it has
played a fundamental role in CIP since version 5 came into effect in 2016. Essentially,
it refers to locations in which BES Cyber Systems might be deployed. Any
system deployed outside of one of those locations will never be a BCS). R1
states that the Responsible Entity should consider each asset that falls into
one of those types “…for purposes of parts 1.1 through 1.3”.
2.
Requirement Part R1.1 mandates that the entity “Identify
each of the high impact BES Cyber Systems according to Attachment 1, Section 1,
if any, at each asset”. R1.2 mandates the same for medium impact BCS.
3.
However, R1.3 reads quite differently from R1.1
and R1.2. It requires the entity to “Identify each asset that contains a low
impact BES Cyber System according to Attachment 1, Section 3, if any (a
discrete list of low impact BES Cyber Systems is not required).” In other
words, the entity isn’t required to identify low impact BCS at all – just the
assets that contain them. In fact, the parenthetical expression warns the auditor
not to even ask to see a list of low impact BCS.
4.
Clearly, we need to run down to Section 3 of Attachment
1 (page 16 of the standard) to figure out what’s going on here. However, when
we get there, we learn that we’re really identifying BES Cyber Systems after
all, not assets, as we were just told. Specifically, we need to identify “BES
Cyber Systems not included in Sections 1 or 2 above that are associated with
any of the following assets and that meet the applicability qualifications in
Section 4 - Applicability, part 4.2 – Facilities, of this standard”. This is
followed by the same list of six asset types we saw in R1.
Perhaps the above steps seem confusing to you. They
certainly are to me, and they have been since I first studied
the language of CIP-002-5 immediately after FERC announced in April 2013
that they were going to approve the CIP version 5 standards and “de-approve” the
CIP v4 standards (which they had approved almost exactly a year earlier – that’s
another story). Here is what I currently understand regarding identification of
low impact BCS and the assets that contain them:
As already noted, Requirement R1 Part 1.3 doesn’t mandate
that the entity identify low impact BCS, as R1.1 and R1.2 do for medium and
high impact BCS respectively. Instead, it requires that they identify “assets that
contain low impact BCS”. It refers them to Section 3 of Attachment 1 for
information on how to identify those assets.
But Section 3 starts with the words “BES Cyber Systems not
included in Sections 1 or 2 above…” That seems to indicate that the entity needs
to start the asset identification process by identifying all the BCS they own
or operate, regardless of impact level. Then, they subtract from that universe
the high impact BCS they identified in Section 1 and the medium impact BCS they
identified in Section 2. The BCS that are left are low impact. That sounds simple.
What’s the matter with that?
Of course, the problem here is that R1.1 has already stated that
“a discrete list of low impact BES Cyber Systems is not required”. So, it seems
we didn’t really start by identifying BCS of all impact levels; instead,
we started with the universe of BES assets owned or operated by the Responsible
Entity. We subtracted the high and medium impact assets identified in the
Section 1 and Section 2 criteria. The remaining assets are low impact.
However, R1.1 indicates clearly that there are no low impact
assets (it doesn’t refer to medium or high impact assets either, of course);
there are only “assets containing low impact BCS”. It seems clear that a low
impact BCS is simply a BCS contained in a low impact asset.
We’re now at the point where we can answer the question of
how to determine when a BES Cyber System is low impact. The answer is that a low
impact BCS is one that’s contained in a low impact asset. However, a low impact
asset is defined as one that contains a low impact BCS. Of course, this is a
perfectly circular argument: A low impact asset is one that contains a low
impact BCS, and a low impact BCS is one that is contained in a low impact
asset.
Of course, this post is about low impact BCS in the cloud.
Even though I said in August that I don’t think low BCS are “legal” in the cloud,
I started this post by implying that I’ve changed my mind again: I now believe there
is no impediment to deploying low impact BCS in the cloud. I say this because
of the “definition” of low impact BCS that I’ve just derived: a BCS that is
contained in a low impact asset.
Can “the cloud” ever be a BES asset – low, medium or high
impact? Since it’s not on the list of BES assets in CIP-002-5.1a R1.1, it
clearly can’t be a BES asset now. It might be in the future, but the important
thing to know about the future is that it hasn’t happened yet.[i]
The point is, since a low impact BCS is always deployed in a low impact asset
and the cloud isn’t a low impact asset, a workload that would meet the definition
of low impact BCS, if it were deployed in one of the six BES asset types, has
no meaning for CIP compliance if deployed in the cloud.
Therefore, there is no such entity as a low impact BCS deployed
in the cloud, any more than there are entities like Bigfoot or LGMs (little
green men) from Mars. None of these entities is subject to compliance with the NERC
CIP standards.
Q.E.D.
Are you a vendor of current or
future cloud-based services or software that would like to figure out an
appropriate strategy for selling to customers subject to NERC CIP compliance? Or
are you a NERC entity that is struggling to understand what your current
options are regarding cloud-based software and services? Please drop me an
email so we can set up a time to discuss this!
Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. 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] I
don’t think Yogi Berra ever said that, but it certainly sounds like a “Berrism”.
Can I patent it?
No comments:
Post a Comment