Monday, December 30, 2019

Second (actually, third) thoughts about the cloud



Up until last summer, I said frequently something to the effect that there’s no good reason – other than the current wording of CIP-004 - why NERC entities shouldn’t be able to store information on their OT systems in the cloud. After all, I reasoned, there isn’t a single electric utility organization, no matter how large, whose level of security isn’t far surpassed by that of any major cloud provider. How could it possibly be otherwise, since cloud providers have to protect thousands of customers and a utility only has to protect itself? The fact that there hadn’t been any major cloud breaches reported at the time was all the evidence I needed for my position.

Another consideration that reinforced my thinking: FedRAMP is much more stringent than NERC CIP or any other cyber regulation that most industries have to deal with (probably including the U.S. military and the U.S. nuclear industry). If a cloud service provider has that certification (and the big ones all do), what could possibly go wrong?

The answer to that question came when the Capitol One breach was revealed last summer to be the work of a terminated ex-employee of AWS who had been able to penetrate at least 30 companies’ environments on Amazon’s cloud – and had bragged online about how no Amazon customer had a particular service configured correctly. This pointed to a big vulnerability at Amazon that was going to require a big effort by Amazon – and also their customers, although much more by Amazon itself – to fix. And it’s a vulnerability that I’m sure FedRAMP doesn’t address now.

However, I have to admit that I continued to believe that the cloud was far safer than any single utility, once AWS and its competitors got the problems that led to Capital One and Paige Thompson taken care of. But now there are two more news stories that have definitely left me wondering about this. This is because both of these stories show that there actually can be cloud-based attacks that impact multiple customers at once – the dreaded common-mode vulnerability.

One of those stories was by Rob Barry and Dustin Volz in today’s Wall Street Journal (note: The link goes to a non-paywall version of the article, but Rob is worried that may not always be available. Here is a link to a PDF of the article on Rob's personal web site, in case that happens). In the article, the reporters describe in great detail how Chinese attackers had conducted a long-term campaign to infiltrate cloud providers and hop from one customer’s cloud environment to many others’ – all the while stealing terabytes of valuable data. This was something I always believed was impossible. Even Paige Thompson didn’t do this – she attacked each of her victims individually, going through the firewalls (which were their responsibility, not AWS’s, of course) in front of their AWS environments. Ever efficient and resourceful, the Chinese seem to have leapfrogged over what she could do.

The other story was forwarded to me about a month ago by Kevin Perry, retired former Chief CIP Auditor of SPP Regional Entity. This one describes how some cloud-based service providers[i], and managed service providers utilizing the cloud as their computing environment (which I would imagine just about all MSPs do now, given how much more efficient that makes them), have become infected with ransomware and have spread it to their customers.

Kevin pointed out in an email “Purportedly, the group of schools hit earlier this year in Texas were attacked through their MSP.” This is quite interesting: A number of members of one particular “industry” (education in this instance) all are attacked through their cloud-based MSP. What would happen if you just substituted “utilities” for “schools” in Kevin’s statement (and maybe “the US” for “Texas”)?

Of course, the solution for Paige Thompson, and these latest two stories, is encrypting the data being stored in the cloud – and the BCSI Access Management standards drafting team is making that the centerpiece[ii] of their revisions to CIP-011 and CIP-004. These will, when enacted, hopefully allow NERC entities to feel safe storing BES Cyber System Information in the cloud (which a number of entities are already doing today).

However, the recent NERC CIPC meeting also made clear that not everybody in the CIP community agrees with the SDT’s approach – and they would like more consideration given to using FedRAMP (or possibly other certifications) as the standard for evidence of the security of a cloud provider. If one of those people wishes to state their position to me, I’ll be glad to publish it, even without mentioning their name.


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. Please keep in mind that if you’re a NERC entity, Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed in this post – especially on compliance with CIP-013. My offer of a free webinar on CIP-013, specifically for your organization, remains open to NERC entities and vendors of hardware or software components for BES Cyber Systems. To discuss this, you can email me at the same address.


[i] Which isn’t the same thing as a cloud service provider, of course. We’re not talking about MS Azure and AWS here.

[ii] Actually, when John Hansen of Exelon, the chairman of this SDT, spoke to the recent NERC CIPC meeting in Atlanta a few weeks ago, he made clear that they’re not requiring encryption per se, but any means of masking the data so that it’s only readable by users equipped with a software key. The new CIP-011 includes a requirement for protection of those keys, which of course is “key” (OK, bad joke) to the success of this effort. You can read their current first draft here.

No comments:

Post a Comment