I recently realized that, except
for two low impact Control Centers that are deployed in the cloud, NERC
entities are not using the cloud for any systems or information subject to CIP compliance.
I have known for a long time that
there isn’t much use of the cloud for BES systems. However, I also believed
that, because storage and use of BCSI (BES Cyber System Information) in the cloud
became “legal” for medium and high impact environments on January 1, 2024 (when
the revised standards CIP-004-7 and CIP-011-3 came into effect), at least some
NERC entities had jumped at the opportunity this provided. Specifically, they
could now freely utilize SaaS applications that require BCSI access. These
applications are already heavily used on the IT sides of their organizations:
for example, multi-factor authentication and configuration management.
In fact, I believed there was already
one SaaS application that utilizes BCSI, that many NERC entities were using
freely in medium and high impact environments. However, it turns out I was mistaken.
Even though many NERC entities utilize this application heavily in their IT
environments, for their OT environments, the SaaS provider has been supporting use
of an on-premises version of their software. I’m sure that neither the
SaaS provider nor the NERC customers are completely happy with that arrangement,
but it seems the lack of clear guidance on how to comply with the two revised BCSI
standards has discouraged
NERC entities from even taking a chance on using SaaS with BCSI now.
So how are NERC entities using the
cloud for systems subject to CIP compliance today? At NERC’s GridSecCon
conference in October, it was stated (by someone in a position to know) that
there are a grand total of two low impact Control Centers located in the cloud
today (I assume they’re renewables generation Control Centers, since those are probably
the easiest to locate in the cloud).
As I discussed in this
post, it’s possible to maintain a low impact Control Center (which consists
of BES Cyber Systems, of course) in the cloud while remaining completely CIP
compliant. This is because for low impact BCS, there should not be any need for
the SaaS provider to deliver compliance evidence to the operator of the Control
Center. The minimal amount of CIP compliance evidence that is required for lows
(mainly, evidence for CIP-003 R2 Attachment 1 compliance) can be generated
entirely by the NERC entity itself.
Of course, that would definitely
not be the case for a high or medium impact Control Center. Implementing one of
those in the cloud today would require the platform Cloud Service Provider to
furnish a mountain of compliance evidence; moreover, some of the required evidence
would be literally
impossible for the CSP to provide, even if they were inclined to do so.
When you think of all the advantages that the cloud provides
(for example, a much more robust way of backing up systems or even entire facilities),
it’s a shame that most NERC entities are not able to take advantage of them for
their OT systems.
What’s even worse is that, by my estimate, it will be at least
2031 before this situation is fixed, meaning that new or revised CIP standards
(and perhaps changes to the NERC Rules of Procedure) have been drafted and
balloted by NERC entities at least three or four times, approved by the NERC
Board of Trustees, approved by FERC (which will almost certainly take more than
one year by itself), and gone through at least a two-year implementation period.
If you think I’m exaggerating, please read this post
and let me know where I went wrong.
Now, let’s address the last part of the title of this post,
where the boy or girl asks their father how they can reach the destination
faster than seven years. It would be nice if there were a magic wand answer like,
“We just need to draft the changes we want in the CIP standards and get Mr/MS Jones
to approve them.” However, I’ve never seen a magic wand in the NERC CIP world,
nor do I expect ever to see one. What other options do we have? In other words,
since we can’t modify the CIP standards in much less than seven years, what
else can we do to ensure at least partial use of the cloud for NERC entities
within say a couple of years?
People I’ve talked with, both NERC ERO staff members and
staff members with NERC entities, seem to agree that the best alternative to
waiting for the standards themselves to be changed is CMEP Practice
Guides (CMEP stands for “Compliance Monitoring and Enforcement Program”). These
are documents prepared by auditors from the NERC Regional Entities, who agree
on how they will interpret certain unclear wording in a standard or a NERC
Glossary definition during audits. The Practice Guides are not binding on auditors,
but an auditor who ignores the guidance in a CMEP Practice Guide will need to
explain why they did that.
Unlike changes to the NERC standards, which can originate
with any party including a NERC entity, these documents need to originate with
the auditors, not with NERC entities. However, there is nothing to prevent a NERC
entity from suggesting a CMEP Practice Guide to the auditors. Two that I know
have been suggested are:
1.
A Practice Guide to clarify how the word “monitoring”
in the definition of Electronic Access Control or Monitoring Systems (EACMS) is
interpreted. The person who suggested this feels that “monitoring” may be
interpreted too broadly by CIP auditors. Narrowing the meaning down (there is
no NERC definition of monitoring, nor is one being proposed now) would mean
that some security monitoring services that are delivered through the cloud now,
or will be in the future, will not be interpreted as an EACMS. This is important,
since an EACMS in the cloud is subject to compliance with all the 29 CIP requirements
(which include 92 Requirement Parts) that an on-premises EACMS needs to comply
with. Needless to say, no CSP is ever going to provide that amount of evidence to
a NERC entity, even disregarding the fact that requirements like CIP-007 R2 (patch
management) and CIP-010 R1 (configuration management) are literally impossible for
a CSP to comply with.
2.
A Practice Guide to clarify how a SaaS provider
can maintain their customers’ compliance with CIP-004-7 R6.1’s requirement for the
NERC entity to “authorize… Provisioned electronic access to electronic BCSI”,
without having to get the permission of every NERC entity customer whenever the
provider grants even temporary provisioned access to BCSI to a person who does
not currently have provisioned access. This might require allowing the CSP to
sign delegation
agreements with their NERC CIP customers. Hopefully, this Practice Guide will
finally clarify the BCSI compliance requirements enough to make both NERC
entities and SaaS providers comfortable with utilizing BCSI in SaaS products.
Here is my idea for a Practice Guide that I believe will at
least partially address problems inhibiting cloud use by NERC entities. It will
do this by mapping particular NERC CIP requirements to requirements of ISO
27001/2, based perhaps on whether a committee of auditors has determined that the
ISO requirement hews closely to the CIP requirement.
Of course, there are many differences between CIP
requirements and requirements in ISO 27001/2, so the correspondence will never be
perfect. However, the team that approves these mappings should be encouraged
not to let the perfect be the enemy of the good, especially since in many cases
the ISO 27001 requirement will be stronger than the CIP requirement.
I believe that probably 90% of the current NERC CIP requirements
can be mapped to ISO 27001 requirements in this way. This is because, believe
it or not, most of the NERC CIP requirements are objectives-based. This means they
require the NERC entity to achieve a particular objective, not perform a prescribed
set of tasks, as does a prescriptive requirement. Of course, how a cloud
service provider achieves an objective will always be very different from how a
NERC entity achieves the same objective in their on-premises environment. But
they can certainly both achieve the objective of any cybersecurity requirement if
it’s reasonable (i.e., not something like “Secure your systems so that no
attacker will ever be able to penetrate them”).
However, there are two NERC CIP requirements that are highly
prescriptive: CIP-007 R2 for patch management and CIP-010 R1 for configuration
management. These two requirements are easily the biggest source of headaches
for CIP compliance professionals. In fact, one NERC entity with high impact
Control Centers told me a number of years ago that, of all the documentation
they compiled in their Control Centers for all the NERC requirements (not just
the CIP requirements), half of that documentation was due to just CIP-007 R2
and CIP-010 R1.
However, there’s a much bigger problem with these
requirements than just the fact that they’re prescriptive: Both requirements must
be complied with on the level of individual cyber assets (i.e., individual
devices like servers). This means, for example, that the CSP would need to track
every device on which any part of a system resided, even for a second, during
the three year audit period. No CSP will be willing to track systems on that
level, even if they happen to have that data available.
What do we do about these two requirements? Their problems
can’t be fixed with just a CMEP Practice Guide; they need to be completely
rewritten. Will that take seven years, like with the “cloud CIP” requirements?
No, but we need to assume it will require 3-4 years, since just fixing these
two requirements will be no easy task.
For one thing, both requirements need to be rewritten as objectives-based
requirements. However, for CIP-007 R2, doing that requires changing
it from a patch management requirement to a vulnerability management requirement.
There are a number of issues that need to be considered before we do that,
which I will address in a new post soon.
In other words, trying to fix CIP-007 R2 and CIP-010 R1 to
allow them to work in the cloud will be a real slog (and it should be done by a
different Standards Drafting Team, since I don’t want to add another four years
to the current “Risk
Management for Third-Party Cloud Services” SDT’s agenda; they’ll probably
kill me if I do that, and frankly I wouldn’t blame them). But this has to be
done. Ever since CIP version 5 (which introduced both of these requirements)
came into effect in 2017, I’ve heard constant complaints about these two requirements.
Cloud or no cloud, they finally need to be fixed.
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.
No comments:
Post a Comment