A Break in the Cloud(s)? – Part I

At the beginning of January, I wrote a post stating that entities that utilize the cloud to store BES Cyber System Information are on shaky ground, and need to talk to their region before doing this (this problem only applies to NERC entities with High or Medium BES Cyber Systems, since they are the only ones that have to keep track of BCSI; I’ll say something about entities with only Low BCS in a future post). Since then I have come to realize that a number of entities are already storing BCSI in the cloud.

A typical scenario for how this situation comes to pass seems to be that a) the entity has engaged a cloud provider of a service like configuration management for all of their OT cyber systems (and maybe IT ones as well); b) either the decision to engage this provider was made without considering the CIP compliance implications, or those implications were simply ignored since the cost savings and improved ease of ownership were so huge; and c) whenever the CIP compliance people weighed in on this issue, they had to admit that CIP v5/v6 do not mention the cloud, so CIP’s position on storing BCSI in the cloud is very uncertain – if there even is any position at all. The result of all this is that the cost and ease of ownership reasons for using a cloud provider of a service like configuration management can far outweigh any reasons that may be adduced for not using a cloud-based service.

I must admit I have been in a kind of intellectual slumber on this issue, primarily because in CIP v3 there was no question that Critical Cyber Asset information could never be stored in the cloud. This is because CIP-003-3 R5 – which covered access to CCAI – required that the entity explicitly authorize all access to CCAI, and review all access annually to make sure it was still appropriate.

This requirement all but prohibited storage of CCAI in the cloud. Cloud providers usually have massive data centers with many thousands of servers (mostly virtual); hundreds of people walk into and out of these data centers every day or even every hour. Since any one of these people could potentially have at least physical access to the server where a particular piece of CCAI resides, it would require a huge effort to try to track who has access to that CCAI, let alone to authorize it and validate that authorization annually – plus, of course, removing access when the person leaves the organization. It is very unlikely that any cloud provider would agree with that.

But CIP v5 is quite different.   CIP-011-2 R1.2, Information Protection, simply requires the entity to document and implement an Information Protection Program that includes “Procedure(s) for protecting and securely handling BES Cyber System Information, including storage, transit, and use.”[i]

The Guidance for this requirement explains what the Standards Drafting Team had in mind when they drafted it. They made it clear that they weren’t ruling out the possibility that BCSI could be “shared with or used by” a third party (page 14 of CIP-011-2). Specifically, “The entity’s Information Protection Program should specify circumstances for sharing of BES Cyber System Information with and use by third parties, for example, use of a non-disclosure agreement.”

Since a cloud provider is definitely a “third party”, this quote seems to be saying that all a NERC entity needs to do, in order to store BCSI with a cloud provider, is to have an NDA in place. But most of the NDAs that I have seen are really focused on preventing employees of one organization, or the organization itself, from disclosing data belonging to another organization; this is important, but this is really just a small part of what we think of when we talk about protecting data. Is this really all that is required?

As I often do when I have questions like this, I emailed an auditor who understands CIP very well, and who has taught me a lot of what I claim to know about these standards. It turns out that CIP v5/v6 does have more to say about storing BCSI at third parties than what is found in CIP-011-2 R1. I will quote what he said almost verbatim:

“The crux of the matter is CIP-011-2, Requirement R1, Part 1.2, which requires the Registered Entity to have “Procedure(s) for protecting and securely handling BES Cyber System Information, including storage, transit, and use” for BES Cyber System Information associated with High and Medium Impact BCS and associated EACMS and PACS (it is interesting that PCA were left out of the applicability section.  I would be interested to know how often information about a PCA could be leveraged to craft an attack against the “protected” systems).

“So, I think there needs to be more than just an NDA.  If the Registered Entity is going to entrust their BCSI to a third party, I would expect the Registered Entity to have obtained, reviewed, and accepted the third-party’s protection controls, not just a signed boilerplate agreement to protect the information.  The Registered Entity cannot assign the risk and liability to the third party providing the information storage service.

You are correct, the Standard does not mandate anyone who has access shall undergo a PRA and training.  But there must be an “authorization for access” process.  Look at CIP-004-6, Requirement R4, Part 4.1.3 (“Process to authorize based on need, as determined by the Responsible Entity, except for CIP Exceptional Circumstances:  Access to designated storage locations, whether physical or electronic, for BES Cyber System Information”) and Part 4.4 (“Verify at least once every 15 calendar months that access to the designated storage locations for BES Cyber System Information, whether physical or electronic, are correct and are those that the Responsible Entity determines are necessary for performing assigned work functions”). 

“Additionally, look at CIP-004-6, Requirement R5, Part 5.3 (“For termination actions, revoke the individual’s access to the designated storage locations for BES Cyber System Information, whether physical or electronic (unless already revoked according to Requirement R5.1), by the end of the next calendar day following the effective date of the termination action”).  Just because the information is in the cloud does not relieve the Registered Entity of the responsibility to demonstrate compliance with these three Requirement Parts.  The third party will need to implement these controls and submit evidence of compliance to the Registered Entity (either direct evidence or an acceptable audit of the controls by a third party other than the service provider).”

To summarize, an entity with Medium and/or High impact BES Cyber Systems can store BCSI with a cloud provider. Per CIP-011-2 R1.2, the entity must have an Information Protection Plan that includes discussion of how BCSI stored at third parties will be protected. Since CIP-011 R1 is a non-prescriptive requirement, there are no prescribed contents for the IPP; it will be up to the entity and their auditor to determine whether the plan is reasonable or not. However, at a minimum:

1. The provisions for third parties in the plan cannot simply require an NDA; there must be some provision for reviewing the controls put in place by the cloud provider (which isn’t the same as requiring the NERC entity to “audit” the cloud provider!);
2. Per CIP-004-6 R4.1.3, the cloud provider will need to demonstrate to the entity that it has a process for authorizing access – perhaps not to the entity’s BCSI itself, but at least to the servers and physical locations where the BCSI is stored;
3. Per CIP-004-6 R4.4, the provider must demonstrate that at least every 15 months it reviews this access to make sure it is appropriate; and
4. Per CIP-004-6 R5.3, the provider must demonstrate that, for termination actions, access to the servers and physical locations storing the BCSI is removed by the end of the next calendar day.

So it seems I was far too pessimistic about NERC entities being able to store BCSI in the cloud when I wrote the post on this topic at the beginning of January. In fact, unlike almost all of the other questions of interpretation that I write about in this blog, I consider this to be actually a settled question – in this case, the CIP standards as currently written do provide an answer to the question whether NERC entities can store BCSI in the cloud. The answer is yes, as long as the above requirement parts are satisfied.

If you have a different opinion on this question, I’d like to hear it. I’d especially like to hear if there is something about cloud providers that makes them different from other third parties – meaning that taking the four steps just listed wouldn’t be sufficient to ensure CIP compliance.

However (there’s always a “however” in my posts, in case you never noticed that), this isn’t the full story regarding the cloud and CIP. There are at least four other questions that I know of:

First, there’s the question of outsourcing actual BES Cyber Systems to the cloud, as in the case of cloud-based SCADA. My opinion on this issue hasn’t changed since January: While I can’t say with absolute certainty that this will never be allowed under any circumstances for NERC entities with High and/or Medium BCS, I will say that any entity that wants to try this should without fail talk with their Region before moving ahead with the project.

Second, there’s the question of what constitutes BCSI. Is it possible that the NERC entity can store some information about its BCS, without storing actual BCSI? Third, there’s the question about assets containing Low impact BCS (and there are some scurrilous individuals that meet in dark corners and actually have the effrontery to refer to these as “Low impact assets”. Can you believe their chutzpah?). Since entities aren’t required to have a list of Low BCS, it seems they can’t identify Low BCSI either. Does that mean they’re off the hook, and they can take any steps they want in storing BCSI in the cloud?

Lastly, just because I’m a mean-spirited individual and don’t want to end a post on a positive note (after all, I have a reputation to uphold!), I do want to point out that there is an interesting loophole in the way CIP-002-5.1a R1 is written, that technically could mean that entities could outsource High and/or Medium impact BCS (i.e. the Cyber Assets themselves, not BCSI) to any third party they want – ISIS, al Qaeda, etc. – and not have to take any provision at all to protect them. I don’t particularly recommend you try this at home, kids, but I think it does show how the wording of R1 can lead to some strange situations.

I will try to address the second through last points in separate blog posts in the near future. Stay tuned to this channel! 

The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte.

---

[i] This is a great example of a non-prescriptive requirement (CIP-007 R3 and CIP-010 R4 are two others). It would be wonderful if all of the CIP v5 and v6 requirements were written this way, although I believe more than that is needed to fix CIP.