What’s needed in the "cloud version” of NERC CIP?

Today (August 16) marks the first virtual meeting of the Standards Drafting Team called “Project 2023-09 Risk Management for Third-Party Cloud Services”. This team will draft the changes to the NERC CIP standards (and perhaps the NERC Rules of Procedure as well) that are required to finally make full use of the cloud completely “legal” for all NERC entities subject to compliance with the CIP standards. I plan to attend that meeting (which is very unlikely to get into any details regarding what will be proposed), but here – for the record – are the changes that I think are most needed:

First, it’s vital that CIP compliance for on-premises systems be as unaffected as possible by these changes. Of course, CIP for cloud systems will have to be very different from the CIP standards that are in place today, but if we try to create a single compliance program for both environments, we will probably end up with a debacle like what occurred in 2018, when a different SDT started down the road of radically revising CIP for everybody and got slapped down hard for doing so.

I fully supported that team’s efforts, and I still believe it’s necessary that all of CIP be “reformed” - although not today. However, the pushback the 2018 team (which is still in operation today – CIP Modifications SDT) received from the large IOUs (who understandably were reluctant to throw out compliance programs in which they’d already invested millions of dollars) forced the SDT to retreat. Let’s not repeat the 2018 experience. Been there, done that, got the T-shirt.

Instead, this new effort needs to result in two “tiers” of CIP compliance (as I discussed in this post) - one almost exactly like the existing CIP standards and only applicable to on-premises systems, and one that applies only to cloud-based systems. Fortunately, the Standards Authorization Request (SAR) on which the group is operating recommends this system, although the SDT is always allowed to do something differently from what the SAR recommends.

Second, it’s vital that any new requirements for cloud-based systems be risk-based, not prescriptive. Compliance with prescriptive requirements like CIP-005 R1, CIP-007 R2, and CIP-010 R1 would literally be impossible for systems based in the cloud. There are far too many ways in which cloud systems can be implemented than could possibly be accounted for in prescriptive requirements.

Third, and probably most important (as well as hopefully most obvious), any requirements that apply to cloud-based systems cannot be device-based. There is simply no way that a cloud service provider can keep track of individual devices (whether physical or virtual or both) on which a cloud-based system like a BES Cyber System is installed, especially since the BCS (or more accurately, parts of the BCS) could be installed on different devices, in different data centers, the next minute. The concepts of Cyber Asset, BES Cyber Asset and Protected Cyber Asset have no place in the cloud; the “cloud track” CIP requirements need to start with identification of BES Cyber Systems, independently of the hardware or VMs on which they may be installed at any particular moment.

Fourth, any requirements that apply only to cloud systems need to take into account the fact that CSPs, given the slew of heavy compliance regimes they need to follow all the time, have almost certainly covered the basics of cybersecurity much better than any electric utility, no matter how large, could ever do. Let’s not worry about whether Humongous CSP no. 1 has applied every O/S patch released in the last 35 days, or whether Gargantuan CSP no. 2 is constantly verifying that only ports and services that are required to be open in fact are open. Let’s assume that the FedRAMP and ISO 27001 auditors have taken care of those issues (although it’s important to at least check the audit results made available to customers by the CSP).

Instead, how about asking these questions?

1.      Does the user database in a SaaS application include users from every country and industry, as well as every security level – an issue called multi-tenancy?

2.      Does the CSP adequately vet its third party access brokers?

3.      Does the CSP take adequate steps to ensure its customers understand how securing infrastructure in the cloud is different from securing it on-premises?

My guess is none of these questions (or many others like them) is even asked in a FedRAMP or ISO 27001 audit. These are questions that the drafting team should focus on.

Fifth, it can’t be up to each NERC entity to judge the level of security of a CSP. For one thing, the CSPs would never accept being “audited” by every entity; for another, most entities are likely to do a very superficial assessment of a CSP whose services they use, since they depend as much on the CSP’s good graces as the CSP depends on theirs.

Instead, NERC – or a third party engaged by NERC – needs to do an assessment of each platform CSP (and perhaps larger SaaS providers as well), based on questions like the ones immediately above, as well as inspection of their FedRAMP and/or ISO 27001 audit results (and penetration tests, in the case of FedRAMP). They then need to share this assessment with any NERC entity that asks to see it.

NERC’s assessment shouldn’t be up-or-down; instead, it should simply describe the information the assessors received from the CSP, including answers to questions and any audit results. The NERC entities are all free to contract with anyone they want.

I am going to follow the SDT’s deliberations as much as I have time for and will be posting on what I learn (and other recommendations, I’m sure). Stay tuned!

Are you a vendor of current or future cloud-based services or software that would like to figure out an appropriate strategy for selling to customers subject to NERC CIP compliance? Or are you a NERC entity that is struggling to understand what your current options are regarding cloud-based software and services? Please drop me an email so we can set up a time to discuss this!

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.