I (and a few others involved in the NERC CIP compliance space) have been puzzled by a strange situation. It has to do with the fact that, after multiple years in which BES Cyber System Information (BCSI) could not be stored or manipulated in the cloud, two revised CIP standards, CIP-004-7 and CIP-011-3, came into effect on Jan. 1. They are designed to finally make BCSI in the cloud “legal” for NERC entities with high and/or medium impact BES assets.
When an important change like this has happened in the past, my
experience has always been that, both before and after the effective date, there
has been a lot of outreach by NERC and the Regional Entities and often the
trade associations, aimed at helping NERC entities understand their obligations
under the new standard(s). After all, changes in the CIP Reliability Standards
are intended to make the Bulk Electric System (BES) more reliable; it is in
literally nobody’s interest if NERC entities don’t understand the new standards
and as a result, either don’t implement them at all or implement them badly.
However, I guess there’s a first time for everything. So far, I
have not seen written or oral efforts (such as white papers or webinars) to
explain how to comply with the two revised standards.
The one exception to this is the document called “Usage of Cloud
Solutions for BES Cyber System Information (BCSI)”. This
was prepared by the NERC Reliability and Security Technical Committee last
June. It was approved by NERC last December as Implementation Guidance, which means
that NERC auditors are supposed to give “deference” to its contents.
This is a good document and of course it’s worth reading, but,
like most NERC CIP Guidance documents that I’ve read, it steers clear of
providing any definite recommendations for compliance procedures; instead, it provides
“examples or approaches to illustrate how registered entities could comply with
a standard” (as stated in the Introduction). This makes it useful for identifying
steps a NERC entity might take as they implement compliance. However, it
doesn’t even try to recommend components of an effective compliance program.
A good example of this is found on page 13 in Scenario 2. There,
we read:
Scenario
2: The Responsible Entity authorizes CSP personnel to have persistent access to
BCSI. This could consist of access to BCSI in clear text or where the
individual has access to the encrypted BCSI and the key(s) to unencrypt it. Compliance
evidence examples could include but are not limited to:
a.
Documented process for how CSP personnel provisioned access is authorized based
on need, whether authorized directly by the Responsible Entity or indirectly by a contractual agreement with the CSP…
(my emphasis)
This says:
1.
If a NERC entity entrusts their BCSI to a third party service
provider (it might be a cloud-based security service provider or a SaaS
provider), they also must make it possible for the service provider’s employees
to have “provisioned access” to BCSI. This means not just that the employee can
see and manipulate the encrypted data, but that they will in some cases need
either to have access to the decryption key at least briefly, or to see and
manipulate the decrypted data before re-encrypting it. The fact is that a SaaS
application can’t utilize encrypted data; the data must first be decrypted.
2.
CIP-004-7 Requirement 6 Part 6.1 (where the concept of provisioned
access comes into play) requires that the Responsible Entity authorize “provisioned
access to BCSI”. For the entity’s own employees, that is quite understandable;
when a new employee needs provisioned access, they follow the entity’s standard
procedures for requesting and receiving provisioned access.
3.
However, if the CSP has responsibility for some of the entity’s
BCSI and they wish to authorize provisioned access for a new employee, strict
compliance with R6.1 requires that they first contact the NERC entity whenever
they need to do this, even if the situation can be considered an emergency.
Some (or even most?) cloud-based security and SaaS providers will consider this
requirement to be impossible to fulfill.
4.
The words “by a contractual agreement with the CSP” in the
guidance document indicate that it should be acceptable (to the auditors) for NERC
entities with medium and/or high impact systems to contractually delegate to
the third party the authority to provision BCSI access for individual employees.
5.
There’s another gem hidden in these words: Not only will the NERC
entity need to document that they have this contract term in place, but they
will need to obtain from the SaaS provider documentation showing every
instance in which they provisioned access to the entity’s BCSI for one of
their employees. The entity will require both types of evidence for their next
audit.
Why am I making such a point of this? It’s because, even though the
seven words “by a contractual agreement with the CSP” seem to be almost a
throwaway phrase in just one of many scenarios listed in the guidance document,
the words turn out to be tremendously significant for CIP-004-7 compliance (in
fact, they helped resolve what seemed in early December to be a showstopper
issue for SaaS that utilizes BCSI, which I described in this post).
A NERC entity shouldn’t have to perform in-depth analysis like the
above, just to learn what they need to require of their CSP or SaaS provider
for compliance with CIP-004-7 Requirement 6 Part 6.1. Instead, they ought to
have a white paper that lays these things out in black and white, or at least
access to a webinar recording that describes them.
I’ll be honest: I find it disturbing that, more than six months
after the compliance date for the two revised standards, CSPs and SaaS
providers are probably not collecting the documentation required for NERC
entities (with medium and/or high impact BCS) to prove compliance with Requirement
CIP-004-7 R6 (as well as Requirement CIP-011-3 Part R1.2, which will also require
documentation from the service provider). In other words, in theory those
entities are out of compliance with one or more of the BCSI requirements.
Yet, at the same time, nobody seems very concerned about this. In
fact, the only reason I know about it is because Kevin Perry, vice chair of the
“CSO706” team that drafted CIP versions 2 and 3, as well as the Chief CIP
Auditor for the SPP Regional Entity for eight years until he retired in 2018, told
me about it. Being a friend of Kevin’s[i]
shouldn’t be a requirement for knowing what’s required by the new BCSI
requirements – both what’s required of the NERC entity and what the entity needs
to require of their security service and/or SaaS provider(s). But that seems to
be the case.
Are you a vendor of current or
future cloud-based services or software that would like to figure out an
appropriate strategy for selling to customers subject to NERC CIP compliance? Or
are you a NERC entity that is struggling to understand what your current
options are regarding cloud-based software and services? Please drop me an
email so we can set up a time to discuss 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]
Kevin has written a good paper on compliance with the new and revised BCSI
requirements. If you would like to have it, email me and I’ll send it to you.
No comments:
Post a Comment