Wrapping up the Cloud

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:

1. 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)?
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.