NERC CIP: When you move your BCS to the cloud, don’t expect a lot of love from the CSP

The NERC “Project 2023-09 Risk Management for Third-Party Cloud Services” Standards Drafting Team has been meeting for more than a year. They spent the first six months revising their Standards Authorization Request (SAR), which is essentially the “charter” under which the SDT operates. They are now discussing new requirements applicable to cloud use by NERC entities.

I think it’s a little early for them to be doing this, since there are still some important issues they need to decide before they can make real progress on requirements. One of the most important of those issues is the question of what evidence a cloud service provider (CSP) will be able to provide to a NERC entity to show that the CSP is in compliance with a CIP requirement or requirement part. This isn’t a trivial question. In fact, this is the question that has prevented almost all cloud use for OT purposes by NERC entities since cloud computing ceased to be considered an experimental technology 10-15 years ago.

The biggest problem with the current CIP requirements, as far as cloud computing is concerned, is that there are multiple requirements – e.g., CIP-005 R1 Electronic Security Perimeter, CIP-007 R2 Patch Management, and CIP-010 R1 Configuration Management – that apply to individual devices (primarily BES Cyber Assets). If a NERC entity deploys high or medium impact BES Cyber Systems in the cloud under today’s requirements, the platform CSP will have to provide the entity with evidence of compliance with the wording of all applicable requirements and requirement parts, including these.

Since systems deployed in the cloud continually flit from device to device and data center to data center, no platform CSP will be able to provide compliance evidence for any of the above requirements. Doing this would require evidence that every device on which any part of the system was deployed, even for a brief period, was compliant with every one of the applicable requirements and requirement parts during the entire audit period (usually three years, although the Cloud CIP requirements might have a shorter period). Moreover, even if a CSP might be able to provide that evidence, without a doubt they will refuse to do so, since compiling it would require a huge effort. Thus, no “Cloud CIP” requirement should apply to individual devices.

There are other CIP requirements, such as most of the requirements in standards CIP-004, CIP-006, CIP-008, CIP-009, CIP-012, and CIP-013, that don’t require compliance on the individual device level; in theory, the platform CSP should be able to provide compliance evidence for these. For example, CIP-004-7 Requirement R4 Part 4.2 requires the NERC entity to “Verify at least once each calendar quarter that individuals with active electronic access or unescorted physical access have authorization records.”

Of course, it’s likely that CSPs always have information available that shows which staff members have been working on which devices at which times within the last 90 days. However, it’s not likely that CSPs can continually track all staff members that have worked on a given NERC entity’s systems during any given calendar quarter – and even if they can, they almost certainly will refuse to do that. This is especially true since the evidence would have to be tailored for each CIP customer individually. Thus, even though this second group of CIP requirements doesn’t apply on an individual device level, the CSP’s are very unlikely to be willing to provide the required evidence – even though it might in principle be possible to do so.

In other words, while the electric power industry is used to having some service provider organizations, like SaaS providers, bend over backwards to provide them with non-standard services to build their customer foothold in the industry, it would be a big mistake to assume that the large platform CSPs will follow that pattern. Those CSPs have built their whole business model on the idea that they perform certain standard services for huge numbers of customers very efficiently and cost-effectively. They’re not going to jeopardize that model, just to have the privilege of bragging that they serve a critical – but actually quite small – industry.

It is important to keep in mind that, even though the power industry is already a big user of cloud services, those are mostly services for the IT side of the industry. Even though the CSPs would love to have more business from the OT side of the industry as well, they know quite well that breaking their low-cost business model is the wrong way to get that business. In contrast with SaaS providers, which have a different business model and are much more focused on serving particular industries like power, nobody should expect platform CSPs to go out of their way to help NERC entities comply with NERC CIP requirements that require a customized response for each entity.

This presents a problem: On one hand, there need to be cybersecurity requirements for CSPs (although they need to be enforced through their NERC entity customers, since neither NERC nor FERC has the authority to directly regulate suppliers to the power industry). Neither the public nor the power industry will consider it safe if NERC entities are allowed to deploy workloads in the cloud without any regulation whatsoever, when the same workloads would be subject to compliance with the CIP standards if deployed onsite. For example, there will need to be requirements for configuration management, patch management, ports and services management, etc.

On the other hand, I’ve just pointed out that CSPs aren’t going to agree to provide compliance evidence that needs to be tailored to individual NERC entities; yet the great majority of CIP requirements and requirement parts mandate exactly that.

However, the power industry isn’t the first industry to face this problem, with respect to use of the cloud: This is why comprehensive certifications like ISO27001 exist. The certification audit is undoubtedly arduous, but it only needs to be done once a year. The CSP’s customers have (usually implicitly) agreed to accept the audit findings and not to demand a separate assessment against the customer’s preferred set of requirements – which would obviously be much more expensive for the CSP.

Two sets of controls – first set

I suggest that the Standards Drafting Team identify two sets of controls they want a CSP audited to be audited on. One set is controls that are likely to be addressed in ISO 27001 (patch management, vulnerability management, configuration management, etc.); these are usually controls that apply to both on-premises and cloud environments. The second set is controls that only apply in cloud environments.

To identify the first set of controls, I suggest that the drafting team go through the certification and identify the controls it thinks are most important for NERC entities; these will become the “requirements” that the CSP must comply with. The evidence required for each control will be any findings identified in the audit report for any of the controls in the drafting team’s list. Presumably, the CSP has already addressed any findings from the audit; however, if they haven’t, a registered entity customer (or NERC itself) is justified in harassing the CSP about open audit findings.

Both NERC entities and NERC auditors need to keep in mind that the purpose of reviewing a CSP’s audit report isn’t to decide whether to use the CSP at all. Unless the CSP has some particularly serious finding in the certification audit report, they will almost certainly continue to be the NERC entity’s cloud provider. However, individual audit findings should always be taken as action items by the NERC entity. The entity (or perhaps NERC itself) needs to follow up with the CSP to find out when they will fix any findings; they also need to keep following up until they are fixed. If the entity doesn’t bother to follow up with the CSP about a finding, IMO they should be assessed an NPV (notice of potential violation) at their next CIP audit.

The second set of controls

The second set consists of controls that only apply in cloud environments, and thus aren’t likely to be addressed in certifications like ISO 27001. While there are now several certifications available for cloud environments[i], I recommend that the drafting team take an eclectic approach and identify controls whose non-observance has led to serious breaches, controls taught in cloud security classes like SANS, etc. The point is to identify controls that might be especially important for NERC entities.

One such control is partial segregation of SaaS customer accounts to address the multi-tenancy problem; I discussed that problem in this 2024 post, but I plan to discuss it again soon. Other controls are inadequate cloud customer training on required security procedures (which probably led to the Capital One breach in 2019), as well as a CSP’s improper vetting of third party cloud access providers, which may have led to the SolarWinds breach.

I suggest that the SDT compile a list of controls that they think should be required of CSPs. In fact, it would probably be a good idea to have a one-day video conference on cloud risks that could be addressed in the Cloud CIP standards. It would be open to everyone, but especially NERC entities, vendors and ERO staff members.

How will this second set of controls be audited? I think NERC (or some third party they designate) will need to audit them. My reasons for saying that are in this post.

My blog is more popular than ever, but I need more than popularity to keep it going. I’ve often been told that I should either accept advertising or put up a paywall and charge a subscription fee, or both. However, I really don’t want to do either of these things. It would be great if everyone who appreciates my posts could donate a $20-$25 (or more) “subscription fee” once a year. Will you do that today?

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] FedRAMP is often cited as a certification, but it is in fact an authorization for federal agencies to use a particular cloud service or cloud provider.