NERC CIP: What is “legal” in the cloud today?

If you have been following this blog for – say – the last eight years or so, you probably know that a big problem in the world of NERC CIP compliance is the fact that NERC entities are severely limited in what kinds of workloads they can implement or utilize in the cloud. While this has been the case for many years, the problem is becoming more acute all the time, as software products and security services announce that henceforth they will only be available in the cloud, or else most of their upgrades and enhancements will only be available in the cloud.

As you may also know, a new NERC Standards Drafting Team (SDT) is now meeting to consider what changes may be required to the CIP standards in order to fix this problem. However, they have a long road ahead of them, as I described in this post in January. I doubt that the final set of new or revised CIP standards will become mandatory for at least 5-6 years from today. This isn’t because NERC is dilatory, but because the NERC standards development process includes many steps designed to ensure that NERC members (as well as members of the public) are able to participate in the standards development process at all stages.

So, the good news is the new (or revised) “cloud CIP” standards are guaranteed to be well thought out. The bad news is this will take a long time. I’m sure many NERC entities want to make more use of the cloud now, but are being held back by uncertainty over what exactly is “legal” today - and especially how they will prove at their next audit that they are still compliant.

I must admit that I can only find two use cases in which I am sure that a NERC entity will be found compliant if they utilize the cloud today (although in both cases there’s a catch, which I’ll describe below).

The first of these is low impact BES Cyber Systems in the cloud, and especially low impact Control Centers.[i] This post describes how – after I was initially skeptical that it’s possible for a CSP to provide evidence of compliance with Requirement CIP-003-8 Requirement R2, especially Section 3 of Attachment 1 - a retired CIP auditor convinced me that in fact this is possible[ii]. However, just because it’s possible doesn’t mean that NERC entities with a low impact Control Center are going to rush to redeploy it in the cloud today. See below.

The second use case is BCSI (BES Cyber System Information) in the cloud. Since BCSI is only defined for information regarding medium and high impact BCS, EACMS (Electronic Access Control or Monitoring Systems) and PACS (Physical Access Control Systems), this isn’t a low impact problem. BCSI in the cloud was effectively verboten before January of this year, but the “BCSI-in-the-cloud” problem was in theory solved when CIP-004-7 and CIP-011-3 came into effect on January 1. Why do we need to discuss this now?

It's because, unfortunately, the single new BCSI requirement, CIP-004-7 Requirement R6, was not written with the most important use case for BCSI-in-the-cloud in mind: SaaS that needs access to BCSI. Instead, the requirement was written for simple storage of BCSI in the cloud. However, why would any NERC entity bother to store their BCSI in the cloud? BCSI is almost never voluminous, and usually, on-premises BCSI can be easily (and inexpensively) enclosed within the NERC entity’s ESP and PSP, with zero compliance risk.

However, if a SaaS application for say configuration or vulnerability management requires access to BCSI, the wording of the new CIP-004-7 Requirement R6 Part 6.1.1 poses a problem. Here’s a little background:

The first sentence of Requirement R6 reads, “Each Responsible Entity shall implement one or more documented access management program(s) to authorize, verify, and revoke provisioned access to BCSI…”

The second and third sentences read, “To be considered access to BCSI in the context of this requirement, an individual has both the ability to obtain and use BCSI. Provisioned access is to be considered the result of the specific actions taken to provide an individual(s) the means to access BCSI (e.g., may include physical keys or access cards, user accounts and associated rights and privileges, encryption keys).”

In other words, an individual is considered to have “provisioned access” to BCSI when it is possible for them to view the unencrypted data, regardless of whether or not they actually do so. Therefore, if the person has access to encrypted BCSI but also has access, however briefly, to the decryption key(s), they have provisioned access to BCSI, even if they never view the unencrypted data.

Requirement 6 Part 6.1.1 requires that the NERC entity’s access management program must “Prior to provisioning, authorize…based on need, as determined by the Responsible Entity…Provisioned electronic access to electronic BCSI.” In other words, the entity’s BCSI access management program needs to specifically address how individuals will be granted provisioned access.

Note that, if the case for BCSI in the cloud were simply storage of the encrypted BCSI, there wouldn’t be any question regarding provisioned access. No CSP employee should ever need access to the decryption keys for data that is merely stored in the cloud; the NERC entity would retain full control over the keys the entire time that the BCSI was stored in the cloud.

However, if a SaaS application needs to process BCSI, it will normally require that the BCSI be decrypted first. There is a technology called “homomorphic encryption” that enables an application to utilize encrypted data without decrypting it, but unless the application already supports this, it is unlikely to be available. Thus, an employee of the SaaS provider (or perhaps of the platform CSP on which the SaaS resides) will need provisioned access to BCSI, if only for a few seconds.

If the NERC entity needs to authorize provisioned access for the cloud employees, that’s a problem, since that would probably require the SaaS provider to get the permission of every NERC CIP customer whenever they want a new or existing employee to receive provisioned access to BCSI. In fact, each customer would need to give authorization for each individual employee that receives provisioned access; it can’t be granted to for example every CSP employee that meets certain criteria.

Last winter, there was some panic over this issue among NERC Regional Entity (ERO) staff members, along with suggestions that this issue needs to be kicked back to the new “cloud” SDT – which would mean years before it is resolved. However, it now seems that, if a NERC entity has signed a delegation agreement with the SaaS provider (or the CSP), that might be considered sufficient evidence of compliance.

But how can the NERC entity be sure this is the case? Currently, they can’t, since even NERC ERO-endorsed “Implementation Guidance” isn’t binding on auditors (officially, they have to “give deference” to it, whatever that means). However, the closest thing to a document that commits the auditors to supporting a particular interpretation of a requirement is a “CMEP Practice Guide”. This must be developed by a committee of Regional auditors, although they are allowed to take input from the wider NERC CIP community. It is possible that such a Guide might be developed for BCSI in the cloud, and th guide might call for a delegation agreement.

If a CMEP Practice Guide is developed for BCSI in the cloud, it is likely (in my opinion) that it would recommend that a NERC entity sign a delegation agreement with the SaaS provider, if they wish to utilize a SaaS product that utilizes BCSI. Of course, they would do this to demonstrate their compliance with CIP-004-7 Requirement R1 Part 6.1.

I’ve just described the two use cases in which I think cloud use for NERC CIP workloads is “legal” for NERC entities today. However, being legal doesn’t mean the NERC entity’s work is done. To prove compliance in either of these cases, the entity will need to get the CSP to cooperate with them and provide certain evidence of actions they have taken regarding the CIP requirements in scope for that use case.

In the case of a low impact Control Center in the cloud, the CSP will need to provide evidence that:

1.      The CSP has documented security policies that cover the topics in CIP-003-8 Requirement R1 Part R1.2.

2.      The CSP has documented security plans for low impact BCS that include each of the five sections of CIP-003-8 Requirement R2 Attachment 1 (found on pages 23-25 of CIP-003-8). Since sections 1, 2, 4 and 5 all require policies or procedures, and since it is likely that most CSPs will already have these in place as part of their compliance with a standard like ISO 27001/2, proving compliance in those cases should not be difficult.[iii]

3.      The NERC entity's cloud environment permits “only necessary inbound and outbound electronic access as determined by the Responsible Entity for any communications that are…between a low impact BES Cyber System(s) and a Cyber Asset(s) outside the asset containing low impact BES Cyber System(s)” as required by Section 3 of Attachment 1. This section is a little more difficult, since it is a technical requirement, not a policy or procedure. On the other hand, demonstrating compliance with it should be quite simple. Kevin Perry pointed out to me that the NERC entity will normally control electronic access in their environment, so they won't need the CSP to provide them this evidence; they can gather it themselves.

In the use case of BCSI in the cloud, the NERC entity will need to provide evidence that they signed a delegation agreement for authorization of provisioned access to BCSI with the SaaS provider. The entity will also need to provide evidence that the SaaS provider complied with the terms of the agreement whenever they authorized provisioned access to the entity’s BCSI (which will hopefully not be a very frequent occurrence). I believe that evidence will need to include the name of each individual authorized, as well as when they were authorized.

In both use cases, it should not be difficult for the SaaS provider to furnish this evidence, although this will most likely require negotiating contract terms to ensure they do this. Will a SaaS provider agree to this? I hope so.

I’ve identified two cloud use cases that are “legal” today. Are there any others? I really don’t think so, although if anybody knows of one, I’d be pleased to hear about it. It seems to me that all other cloud use cases won’t work today, mainly because they require deploying or utilizing high or medium impact systems in the cloud.

If a CSP did that, they would need to provide the NERC entity with evidence of most of the CIP requirements and requirement parts that apply to high or medium impact systems. For example, they would need to implement a Physical Security Perimeter and an Electronic Security Perimeter in their cloud. Implementing either of those is impossible for a CSP, unless they’re willing to break the cloud model and constrain your data to reside on a single set of systems in a locked room with access controlled and documented.

If they’re going to do that, most of the advantages of cloud use go away, which raises the question why any NERC entity would pay the higher cost they would likely incur for using the cloud for these systems. I don’t think any would do that, which is of course why I doubt there are any high or medium impact BCS, EACMS or PACS deployed in the cloud today.

However, there may be some hope regarding EACMS in the cloud, which may be the most serious of the CIP/cloud problems. Some well-known cloud-based security monitoring services are effectively off limits to NERC entities with high or medium BCS, because their service is considered to meet the definition of EACMS: “Cyber Assets that perform electronic access control or electronic access monitoring of the Electronic Security Perimeter(s) or BES Cyber Systems. This includes Intermediate Devices.” In other words, these services are considered cloud-based EACMS, making them subject to almost all of the medium and high impact CIP requirements.

Some current and former NERC CIP auditors are wondering whether the term “monitoring” in the EACMS definition is currently being too broadly interpreted by auditors. If the standard interpretation of that term (which doesn’t have a NERC Glossary definition) were narrowed, those auditors believe there would be no impact on on-premises security monitoring systems, while cloud-based monitoring systems would have less likelihood of being identified by auditors as EACMS.

If this could be accomplished (perhaps with another CMEP Practice Guide), this would be a significant achievement, since it would allow NERC entities to start using cloud-based security services they currently cannot use. This would increase security of the Bulk Electric System and would not require that NERC entities wait 5-6 years for the full set of “cloud CIP” requirements to come into effect.

“CIP in the cloud” is one of the most important issues facing the NERC CIP community today, and its importance is increasing every day. If your organization is a NERC entity or a provider/potential provider of software or cloud services to NERC entities, I would love to discuss this topic with you. Please email me to set up a time for 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 it is likely that NERC entities will deploy loads from either substations or synchronous generating stations in the cloud. This is because both of those environments require a very low level of latency. I believe most NERC entities won’t want to deploy those workloads in the cloud. 

[ii] Of course, low impact systems are subject to compliance with other CIP requirements and requirement parts as well (e.g., having an incident response plan and physical security controls), but most CSPs should have no problem providing evidence for those. 

[iii] There is currently no NERC policy in place that, for “policies or procedures” requirements like these, it is sufficient evidence of compliance to point to where the substance of the requirement is addressed in ISO 27001 (or any other certification. Note that FedRAMP is an authorization for certain federal agencies to utilize the service in question; it is not a certification). However, I would hope it would not be a heavy lift for NERC to create such a policy, perhaps in a CMEP Practice Guide.