Still a long road to the cloud

 If you're looking for my pandemic posts, go here.

A little more than a month ago, I wrote a post about the fact that it’s currently highly “illegal” for NERC entities to implement BES Cyber Systems in the cloud, e.g. using outsourced SCADA. I described what would need to be done with the CIP standards to change this – essentially, rewrite them entirely as risk-based. I provided one example of how this could be done: by replacing the patch management requirement (CIP-007 R2) with a requirement to address risks due to unpatched software vulnerabilities (since patch management is the most important mitigation for unpatched software vulnerabilities, but only in cases when a patch has been released).

I was essentially saying in this post that all of the existing CIP requirements should be pulled apart to see which risks they address, and a risk-based requirement could be written to replace each one. And how would that point the way for NERC entities to place BES Cyber Systems in the cloud? Because once the requirements are all risk based, there are many ways to prove compliance, rather than just the single way specified in the requirement. And that opens up the way for the NERC entity to point to a cloud provider’s FedRAMP certification (or perhaps another like SOC II) as evidence that they are taking appropriate steps to mitigate each of the risks addressed in the existing CIP requirements.

I discussed the idea of using the FedRAMP certification as compliance evidence in this post, but I closed with a hard question that still needs to be answered, before even cloud providers with FedRAMP certification should be considered safe:

Are there any serious cyber risks that apply to cloud providers, that aren’t addressed either by CIP or by FedRAMP? If so, doesn’t that mean there might need to be some new CIP requirements before the Good Housekeeping Seal of Approval is bestowed on the cloud providers, FedRAMP or no FedRAMP?

The answer to both of these questions is yes, of course. I discussed one of those risks – the risk that led to the Capital One breach in 2019 – in this post a few weeks ago. Now I’d like to point out one very big risk I identified in this post at the end of last year, based on a great article in the Wall Street Journal.

I just reread the article, and it’s quite impressive. It describes in great detail how the Cloud Hopper attacks discovered in 2016 were actually much larger than originally known. Essentially, a Chinese team (two members of which were indicted by the US in 2016, but of course remained at large in China) had penetrated more than a dozen cloud providers and far more than the 14 companies named in the indictment. They had stolen lots of data from some very big companies.

Most importantly, they didn’t break into all of these companies from the internet, like Paige Thompson did with Capital One. They were able to hop from one company to another within a single cloud provider. As the article says, “Once they got in, they could freely and anonymously hop from client to client, and defied investigators’ attempts to kick them out for years.”

This is clearly not a problem with cloud customers not configuring their systems properly, as AWS had alleged about the Capital One breach; it seems the “walls” between cloud customers were like Swiss cheese, as far as the Chinese attackers were concerned. And once again, this is clearly a problem that isn’t addressed in FedRAMP, since so many cloud providers proved vulnerable to the attackers.

The bottom line is that allowing BES Cyber Systems to be placed safely in the cloud will require more thought than “just” rewriting the CIP standards or making it easy for a cloud provider to prove compliance based on their FedRAMP certification. It will require a careful examination of the real risks to be found in the cloud.

 

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.