Before I started
the series of four posts on the cloud and NERC CIP in February, I had assumed
that the question of how NERC entities (with Medium or High impact assets)
could safely navigate CIP compliance while utilizing the cloud within their ESPs
(given that CIP is completely silent on the cloud) was like just about every
CIP problem I’ve written about: a story with no conclusion.[i] In other
words, almost every CIP problem I’ve looked at has come down to saying this: “The
only answer to this question will be specific to your entity, and it will have
to come from your Regional Entity. Even the answer you get from your RE will
vary according to the person answering, as well as when they answered. Have a
nice day.”
But I was
pleasantly surprised as I wrote the first post (linked above), when an auditor
confirmed to me that entities could safely utilize the cloud and remain CIP
compliant. And this wasn’t some opinion of his, but was based on the actual
wording of requirements in CIP versions 5 and 6. In other words, it does
actually seem like the question of whether NERC entities can utilize the cloud
and how they can utilize it – while remaining compliant with CIP – is subject
to a definite answer.
In this
post, I’d like to summarize what I said in the previous four posts in this
series, as well as address a few points I hadn’t discussed, including whether
and how Lows can use the cloud. Here is what I think are the “known knowns” (to
quote the great scholar and philologist Donald Rumsfeld) about this subject:
- There are two fundamental questions about the cloud with
regard to CIP: First, can an entity remain CIP compliant if some of their
BES Cyber System Information (BCSI) is stored in the cloud? Second, what
if an entity actually outsources some of their BES Cyber Systems to the
cloud (e.g. outsourced SCADA)?
- Since the situation is very different for owners of High
and Medium impact BCS vs Lows, I will separate the two discussions. First
is the Highs and Mediums.
- For Highs and Mediums, the answer to the first fundamental
question is yes – they can store BCSI in the cloud. Of course, they have
to follow the CIP requirements that apply. In the first post, I listed
four requirement parts that an auditor pointed out were applicable to the
cloud. NERC entities that follow these four requirement parts should be
found compliant.
- In the second
post, I discussed encryption of BCSI data in the cloud. The point of that
post is that yes, encryption is a good control to use in complying with
the four requirement parts. However, encrypted data is still BCSI. The entity
still has to document how they have complied with the four parts.
- In the third
post, I pointed out that the need to provide evidence of compliance with the
four requirement parts doesn’t go away just because the BCSI is in the
cloud. In fact, it is possible that some entities who utilize the cloud
will be found non-compliant just because they were unable to obtain
adequate documentation from their cloud provider. In other words, you need
to bring up CIP compliance before you sign on the dotted line with your
provider; if you wait until afterwards, it may be too late.
- In the fourth
post, I wrote that there is one way for an owner of Medium or High impact
assets to store information about their BCS in the cloud but not have to
take any special steps to comply with the four requirement parts as a
result: that is to read the BCSI definition carefully and take steps to
make sure what is stored in the cloud doesn’t meet that definition.
- Regarding the second fundamental question, whether High or
Medium impact BCS themselves (not just information about them) can be
stored in the cloud, the answer is: Not if you want to have any friends at
NERC or your Regional Entity. Regardless of whether this is compliant or
not, I know that both NERC and FERC are very much against “real-time
operations in the cloud” – as I pointed out in this
post in January (however, on the question of whether this is compliant,
see the last three paragraphs below).
Now for
three more topics I haven’t addressed yet:
First, what
about Lows? Regarding the question of storing BCSI in the cloud, the answer is
very easy: Lows don’t have BCSI, or more specifically they don’t have any
requirements that apply to it. I assume that the auditors won’t object if an
entity with Low assets tells them they’ve stored information about their Low BCS
in the cloud – and if they do object, they can’t do anything about it.
Regarding
whether Lows can outsource their Low BCS to the cloud, one again I think the
answer is the same as for Highs and Mediums: Doing this will be met with a lot
of skepticism on the part of your Regional Entity, whether or not it actually
is compliant.
Second, what
about certifications? If a cloud provider has a SOC 2 certification – or another
cert like FedRAMP – is that good enough? The answer to this question is a lot
like the one for encryption. If your cloud provider has a certification, this
will certainly go a long way toward establishing that your BCSI is safe there.
However, you still have to comply with the four requirement parts. It is
possible that your Regional Entity will accept the certification as compliance
evidence, but you certainly can’t just point to the cert and say “Here, that’s
all you need to know.” You still have to document why the cert should be used
as evidence of compliance with each of the four requirement parts.
My third new
topic is, I’ll admit, a little arcane. But I do want to point out that a strict
reading of CIP-002 R1 seems to indicate that the entity is free to outsource
their BCS themselves to the cloud or to any other third party, completely
consequence-free (ironically, this doesn’t apply to BCSI. So as far as CIP compliance
goes, it’s fine if you outsource your entire SCADA system to Al Quaeda, just as
long as you don’t store any of the BCSI with them).
The reason
for this is found in how CIP-002-5.1a R1 works. The requirement begins by
providing a list of six types of “assets” that need to be considered – Control
Centers, Transmission substations, etc. The meat of the requirement is found in
R1.1 through R1.3. R1.1 tells the entity to identify any High impact BCS at
each asset, meaning any of the six types just listed. R1.2 does the same for
Medium BCS, while R1.3 says the entity needs to identify assets that contain
Low impact BCS. In all three cases, the universe of assets is confined to the
six types. Any BCS not located at one of those assets aren’t in scope for CIP
(even though they meet the definition of BCS).
So what if
an entity has outsourced their BCS to the cloud (or any other third party, for
that matter)? It is a safe bet that the BCS aren’t located at one of the six
asset types listed in R1 (I don’t know too many cloud providers that locate
their data centers at generating plants, for example). What is their status for
CIP? They’re completely out of scope. As I said, you can locate BCS anywhere
you want, with whomever you want, but they are only in scope if they’re
physically located at one of the six asset types.
However, I also
refer you back to bullet point 7 above – especially the part about not making
any friends at NERC or your Region. Don’t try this at home, kids!
The views and opinions expressed here are my own and don’t
necessarily represent the views or opinions of Deloitte.
[i]
My poster child for a CIP problem is the problem of what CIP-002 R1 (and Attachment
1) means. I first discovered that the wording was flat-out contradictory when I
wrote this
post in 2013. I have since written over 50 posts addressing this question from
one angle or another – but of course there simply is no definitive answer to
it.
No comments:
Post a Comment