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.
