The NERC Project
2023-09 Risk Management for Third-Party Cloud Services Standards Drafting Team
(SDT) is currently finalizing a revised Standards Authorization Request (SAR)
that will guide their effort to revise the NERC CIP Reliability Standards going
forward. It will be submitted to the NERC Standards Committee soon, and it will
very probably be approved by them in December. In January, the SDT will set
about the business of revising the standards themselves. As I wrote recently,
I expect this to be a long process, but it’s always better to take the first
step, rather than never take it.
While the draft version of the SAR that was distributed to
the “plus list” for the project last week lacks a lot of detail, it does emphasize
twice an idea from the original SAR (approved by the Standards Committee last December)
that I previously thought was exactly what the doctor ordered:
And
Notice that both excerpts contain the
identical phrase, “first revising the standards to allow for EACMS use of cloud
services”. Perhaps you perceive – as I do – that the SDT really, really wants to
address what I call the “EACMS
problem” first. If so, you’re correct! The SDT knows that, of the perhaps 5
or 6 separate problems that compose the “cloud CIP problem”, without much doubt
the most serious is the problem of EACMS not being deployable in the cloud.
What is the problem? It’s simple.
If a system meets 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”,
it is subject to compliance with well over 100 NERC CIP Requirements and Requirement
Parts.
The NERC entity must furnish
evidence that they were in continuous compliance with each Requirement and
Requirement Part during the entire audit period (usually three years). The same
evidence is required, whether the system is deployed on-premises or in the
cloud. The main difference between the two is that the cloud service provider
(CSP) needs to gather evidence for cloud-based systems, since the NERC entity cannot
do that on its own.
For the majority of CIP Requirements
and Requirement Parts, the evidence will be relatively easy to gather, whether
it is gathered from on-premises or cloud-based systems. For example, CIP-004-7 Requirement
3 Part 3.5 mandates that the NERC entity’s Personnel Risk Assessment program include
a “Process to ensure that individuals with authorized electronic or authorized
unescorted physical access have had a personnel risk assessment completed
according to Parts 3.1 to 3.4 within the last seven years.”
For their on-premises systems, the
NERC entity will show the documentation for their PRA program to the auditor.
Since that program does not directly apply to the CSP, the CSP will need to
provide some sort of “equivalent” evidence to the auditor, such as a certain
section from their ISO 27001 certification audit, or perhaps their FedRAMP
authorization audit.[i]
However, there are a small number of very prescriptive NERC
CIP requirements for which it is simply impossible for the CSP to provide evidence.
Consider CIP-010-4 R1.1. It requires the Responsible Entity to:
Develop a baseline configuration, individually or by group,
which shall include the following items:
1.1.1. Operating system(s) (including version) or firmware
where no independent operating system exists;
1.1.2. Any commercially available or open-source application
software (including version) intentionally installed;
1.1.3. Any custom software installed;
1.1.4. Any logical network accessible ports; and
1.1.5. Any security patches applied.
This requires the entity to develop
a baseline configuration for every device on which any part of the system in
scope - (a BES Cyber System, EACMS, Physical Access Control System (PACS), or a
Protected Cyber Asset (PCA) – resides. This applies to physical devices today,
although it will apply to both physical and virtual devices in perhaps a couple
of years. Since on-premises systems normally reside on a small number of
devices and do not often switch from device to device, this is not a
particularly onerous requirement.
However, what about a system that
is deployed in the cloud? To quote Google Cloud, “To maintain availability and
provide redundancy, cloud providers will often spread data to multiple virtual
machines in data centers located across the world.” In other words, a system in
the cloud will often be spread over multiple VMs, which might be located on multiple
physical servers that are themselves located in multiple data centers worldwide
(although a CSP will usually offer the option for a NERC entity to restrict
their systems to being deployed on servers in the US or North America). But
that isn’t all: These pieces of systems will regularly jump around from
physical server to physical server, VM to VM, data center to data center, etc. They
may do this multiple times in a day or even in an hour.
Given that, how will a CSP provide
evidence to a NERC entity that all the component parts of their EACMS always
resided on a physical or virtual device that had an up-to-date baseline
configuration? After all, NERC CIP compliance requires the entity to be able to
provide a copy of each baseline configuration, not simply attest that it
exists.
Of course, no CSP could ever
provide that sort of evidence, without locking all of the servers holding the
EACMS in a single enclosed space with an ESP and PSP, protected by physical access
control devices controlled by the NERC entity. Could a CSP ever do that without
breaking the cloud business model?
The answer is that no CSP could
ever provide this evidence, meaning the NERC entity would possibly be found in
violation of CIP-010-4 R1 during every day of the (usually three-year) audit
period. That would also apply to CIP-007-6 R2, CIP-005-7 R1, and at least a few
more CIP requirements that apply on an individual device basis.
This is why deployment in the cloud
is not “permitted” for medium and high impact BCS, EACMS, PACS and PCA. The
problem has nothing to do with concerns about the security of the cloud or any explicit
prohibition of cloud use (the current CIP standards say nothing about the
cloud). Rather, it has everything to do with the fact that the CSP could never
provide the required compliance evidence to a NERC entity.
Given that this problem applies to
BCS, EACMS, PACS and PCA, why is the SDT singling out EACMS as the most urgent
problem, which might require the SDT to develop one new version of the CIP
standards to fix the EACMS problem, then another to fix the BCS, PACS and PCA
problems? They’re doing this because there isn’t much doubt that the fact that
EACMS can’t be deployed in the cloud today is the most serious of the five or
six what I call “CIP cloud problems”.
The EACMS problem is the most
serious because it affects security services and software. Think of SIEM, dual
factor authentication, etc. These are all EACMS because they “perform
electronic access control or electronic access monitoring of the Electronic
Security Perimeter(s) or BES Cyber Systems.” When one of these services moves
from an on-premises version to the cloud, their NERC entity customers won’t be
able to follow them. Even more importantly, there are many cloud-based security
service providers (e.g., SecureWorks) that have been off limits to NERC entities
with high and medium impact CIP environments all along. Wouldn’t it be nice if NERC
entities could take advantage of every available cloud service, rather than
have to content themselves with the dwindling number of on-premises security
services?
Of course, it would. However, even though the EACMS problem
is more serious than the problems with BCS, PACS and PCA, will it do any good for
the SDT to go through the large extra time and effort required to develop one
set of standards that fixes EACMS alone – especially since this will delay the
delivery of the final version by at least 1-2 more years? If fixing EACMS were
going to be very different from fixing the other asset types, this might be
worthwhile.
But it won’t be. Whether the goal is just to make EACMS
deployable in the cloud or to make all four asset types deployable, the same
steps will need to be taken. That is, the SDT will need to rethink the CIP
standards and develop two different sets of standards: one for on-premises systems
- almost exactly what is in place today - and one for cloud-based systems. I
described one way to do that in this
post more than a year ago (there are some things I would like to change in
that post, but in principle there’s nothing wrong with it).
Of course, given the importance of fixing the EACMS problem as
soon as possible, it would be comforting to think there is a way it could be fixed
separately from how the other CIP/cloud problems are fixed; but that simply is
not going to happen. All the problems will be fixed at once or none of them
will. Thus, if the NERC community wants to completely fix any of the CIP/cloud
problems, we will have to completely fix all of them. And that
optimistically looks like 2031.
Are there interim or partial solutions available? Yes, there
are. Will the NERC community take advantage of them? Dunno.
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]
Neither the ISO certification nor the FedRAMP authorization would be accepted
as evidence in a NERC CIP audit today. However, at some point in the
not-too-distant future, a CMEP Practice Guide or some other document might indicate
that this is acceptable evidence.
No comments:
Post a Comment