NERC CIP: Will FedRAMP save us?

One of the most important current questions in the NERC CIP community is how and when it will be “legal” to deploy medium and high impact BES Cyber Systems (BCS) in the cloud. It’s important to note that there is no CIP requirement that explicitly forbids a NERC entity from deploying high or medium impact BCS in the cloud. Rather, the problem is that a cloud service provider (CSP) would never be able to provide the evidence required for the entity to prove their compliance with some of the most important CIP requirements in an audit.

There have been many suggestions on how a CSP could provide such evidence. Perhaps the suggestion that comes up most often is something to the effect of, “Why don’t the auditors just allow the cloud service provider’s FedRAMP (or SOC 2) certification to constitute evidence that they maintain an equivalent or better level of security practices to what is required by the CIP requirements that apply to medium and/or high BCS?”

Of course, there isn’t much dispute whether the overall level of security maintained by the large CSPs, especially in the portion of their cloud infrastructure that is compliant with FedRAMP, is better than the level of security required by the NERC CIP requirements that apply to medium and/or high impact BCS: without much doubt, it is better. But, as everyone involved with NERC CIP compliance knows all too well, what matters is whether the entity – or in this case, the CSP acting on their behalf – has complied with the exact wording of each requirement. For prescriptive requirements like CIP-007 R2 (patch management) and CIP-010 R1 (configuration management), it would simply be impossible for a CSP to do that.

However, there are some requirements for which it might be possible for a CSP to provide compliance evidence. These are what I call risk-based requirements, although they don’t all use the word “risk”. Examples of this are CIP-007 R3 (malware prevention), CIP-010 R4 (Transient Cyber Assets), and CIP-011 R1 (information protection program). If the evidence were designed to show that the NERC entity has developed a plan with the CSP how to address the risks applicable to the requirement in question and the CSP has carried out the plan, then my guess is it might be accepted, without having to change the CIP requirements at all.

But the fact that there are some requirements for which it might be possible to provide appropriate compliance evidence is irrelevant in the big picture. There is simply no way the NERC entity would be found compliant with the prescriptive requirements if they deployed medium and/or high impact BCS in the cloud. And no NERC entity is going to agree to do something that is guaranteed to make them non-compliant with even one requirement.

So is the solution to rewrite all the CIP requirements so they are all risk-based and can easily be “made to fit” with the cloud? This is essentially what the CIP Modifications Standards Drafting Team started to do in 2018 (although they were targeting virtualization at the time, not the cloud) – that is, until some large NERC entities made it clear they didn’t want to have to toss their entire CIP compliance programs – with all of the software, training, etc. they had invested in for CIP compliance – and start over. I described this sad story in this post in 2020. Thus, it’s safe to say that requiring all NERC entities to rewrite their CIP compliance programs is a non-starter.

However, a recent SAR (standards authorization request) that was submitted to the NERC Standards Committee proposed a way around this problem: What if there were two CIP “tracks”? Track 1 would consist of exactly the same requirements that are in place today, but it would be made clear that they only apply to on-premises systems, not to systems deployed in the cloud. NERC entities that have any systems deployed on premises would follow that track for those systems.

Any entity that doesn’t want to place any BCS in the cloud would just follow the first track – so literally nothing would have to change in their CIP compliance program.  However, if an entity deploys any BCS in the cloud, they would follow a second compliance track for those systems (and also follow the first track for their on-premises systems). That track might start with a requirement that the CSP has an appropriate certification. There would then be requirements that aren’t found in the first CIP track because they only apply to CSPs, for example:

1.      The entity needs to demonstrate that the CSP has developed a plan to comply with the “Paige Thompson problem” – namely, the fact that a technical person who had recently been fired by their CSP was able to utilize her knowledge of a common customer misconfiguration to penetrate the cloud accounts of at least 30 customers of the CSP (by her reckoning), one of which was Capital One.

2.      The entity needs to demonstrate that the CSP adequately verifies the level of cybersecurity of third parties that sell services that run in the CSP’s cloud (the fact that one such access broker didn’t have good security may have led to the Russian attackers being able to penetrate the SolarWinds infrastructure and plant their malware in seven updates of the Orion platform in 2019 and 2020).

There are probably a lot more “uniquely cloud” risks that should be addressed in CIP requirements, which only apply to cloud based BCS. It’s not likely that FedRAMP has requirements that deal with these risks, but if it does, then the FedRAMP audit report might possibly be used as evidence of the entity’s compliance with these requirements. All of these questions would need to be addressed by a standards drafting team tasked with examining the risks of deploying medium and high impact BCS in the cloud and designing appropriate CIP requirements to mitigate those risks. This would be the new second track for NERC CIP.

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.