In order to continue providing the quality of posts my readers have come to expect, I am now putting up most of my new posts for paid subscribers only on Substack, although I am also putting up some new posts for both paid and free Substack subscribers; this post is one of the latter. All 1200+ posts that I have written since 2013 are available to paid subscribers on Substack.
A paid subscription to this blog costs only $30 per year or $5 per month; it includes access to all new and legacy posts. Anyone who can’t pay that much should email me, so I can set you up with a free one-year subscription. Enjoy!
 In two recent posts, I identified cybersecurity risks that only arise for users of the cloud. Near the end of the first post, I described three risks that were revealed in widely-publicized incidents, all of which caused significant damage to their victims (in fact, two of those attacks had devastating consequences). In the second post, I linked to a blog post written by a security researcher about a significant cloud vulnerability that he had discovered (and received a $40,000 bug bounty for reporting). The instance of the vulnerability that he found was immediately patched, but he pointed out that there are probably slightly different variants of this vulnerability that are still in the wild, which could potentially be exploited for attacks, if discovered.
I wrote those two posts not because I’m trying to scare people away from using the cloud, but because I want to make sure that the NERC Standards Drafting Team (SDT), that is now considering changes or additions to the NERC CIP standards to enable full cloud use by all NERC entities, pays attention not only to serious risks that arise from use of on-premises systems (most of which are addressed in the current CIP standards), but also to risks that arise only from cloud use.
Of course, the latter risks aren’t addressed in the current CIP standards. Moreover, they will never be addressed, unless some group first makes the effort to identify important cloud risks that might facilitate an attack on the Bulk Electric System (BES), once all NERC entities are free to use the cloud for their assets that are subject to CIP compliance.
In the two posts I referenced, I was implicitly lumping all cloud risks into one type: risks to BES Cyber Systems deployed in the cloud. However, today Chris Hughes’ excellent newsletter linked to a Dark Reading article about a cloud-based supply chain attack (I realize now that supply chain attacks are much easier in the cloud. Get ready for many more of these). It compromised a SaaS provider, Salesloft Drift, and through it two technology companies: Zscaler and Palo Alto Networks.
If you substitute some company names, you can see how this cloud risk could impact the BES. Let’s pretend that Salesloft is a SaaS provider whose software utilizes BCSI, and Zscaler and PAN are electric utilities that use Salesloft in their high or medium impact BES environments (i.e., systems within the ESP were utilizing Salesloft for some sort of grid activities). The compromised Salesloft tokens could have been used to penetrate the ESPs of both companies (they might have been blocked by other controls, although I’m not sure what those controls would be. I know the current CIP requirements wouldn’t have blocked them).
This is a different type of cloud attack than the type I was originally envisioning: an attack on a BES Cyber System deployed in the cloud. SaaS isn’t a BCS, since I don’t see any way that compromise of a SaaS service could inevitably cause a 15-minute impact on the BES. However, if the SaaS service utilizes BCSI, the compromise of the SaaS provider would likely compromise the BCSI as well, so that unauthorized actors have access to it. Even though those actors might utilize the information they learn to attack the BES, they won’t inevitably[i] do this within 15 minutes; therefore, this is a different kind of BES risk than what I discussed in the two previous posts I linked above.
The lesson I learned can be summarized this way: There are two types of cloud risks to the BES:
1. Risks to the BES if BES Cyber Systems are deployed in the cloud, e.g. if systems that would normally be in an on-premises Control Center were deployed in the cloud. Low impact BCS, and even entire low impact Control Centers, have always been completely “legal†in the cloud (although there were only two low impact Control Centers in the cloud about a year ago), but high and medium impact BCS have never been legal.
I think there should be a definition for a “Cloud BCSâ€, which would incorporate the 15-minute language from the definition of BES Cyber Asset. Of course, none of the current CIP requirements that apply to BCS will automatically apply to Cloud BCS, since a BCS by definition is composed of BES Cyber Assets, which are physical devices; no CSP is going to provide compliance evidence on the level of individual physical or virtual devices.
2. Risks to the BES through use of SaaS by systems deployed within a high or medium impact ESP. SaaS systems by definition don’t have a 15 minute BES impact, and if they do, they’re Cloud BCS, not SaaS. If an attack compromises a SaaS system, it won’t have a BES impact unless the BCSI used or stored by the system is accessed by the attackers and used to plan a successful attack.
A separate SDT already addressed the SaaS risk question. Their solution was quite elegant, and I don’t think it needs to be changed at all. The definition of BCSI didn’t change from what it was when CIP version 5 came into effect in 2017. However, there are now only three CIP requirements that apply to BCSI:
c.     CIP-011-3 R2 is unchanged from its original form, but now applies to BCSI found in systems being recycled or disposed of by the CSP, as well as to on-premises systems.
The two new standards, CIP-004-7 and CIP-011-3, came into effect on January 1, 2024. However, since there has been very little guidance from NERC on how to follow the three above requirements when using BCSI with SaaS, there has been almost no use of SaaS by NERC entities with medium and/or high impact BES environments (or at least there has been almost no reported use).
In both posts that I linked at the top of this blog, I mentioned that I want to start a working group to examine risks to the BES arising from cloud use by NERC entities with high or medium impact BES assets. I’m pleased to announce that the group has been formed and will hold its first meeting at 11AM Eastern Time on Monday, September 8. If you would like to join us or at least join future meetings, please drop me an email.Â
If you would like to comment on what you have read here, I would love to hear from you. Please email me at [email protected] or comment on this blog’s Substack community chat. If you would like to join my CIP Cloud Risks Working Group described in the italicized paragraphs at the end of this post, please email me. The group’s first meeting is already scheduled.
[i] In blog posts I wrote during the period in 2014 and 2015 when the NERC CIP community was in heavy debates (and perhaps one or two fistfights) over the meaning of important new terms in CIP version 5 like BES Cyber Asset, I realized that the definition of BCA would have been much more understandable if the word “inevitably†had been inserted to describe the impact that a compromise of the BCA would have on the BES. If the current SDT decides to define a “Cloud BCS†â€" which I think would be a good idea â€" I would recommend that the word be used in that definition.