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:

Determine a development plan to define whether revisions will be made to accommodate use of cloud for all CIP defined systems (such as EACMS, PACS, BCS, etc.) or if an incremental revisions approach will be taken to allow use of cloud for individual or groups of CIP-defined systems (such as first revising the standards to allow for EACMS use of cloud services).

And

Holistic or incremental - The DT will evaluate revision approaches and determine whether to develop requirements applicable to use of cloud for all CIP-defined systems (such as EACMS, PACS, BCS, etc.), or to develop incremental revisions to allow use of cloud for individual or groups of CIP-defined systems (for example, first revising the standards to allow for EACMS use of cloud services).

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;

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.