How can CIP be amended to allow BCSI in the cloud?

After Monday’s post appeared, I had extended email conversations with three people who are very involved with NERC CIP at their organizations (one is a retired CIP auditor – but he’s still very involved with CIP!). The conversations all centered around the recommendations that I provided for changes to the current CIP standards to accommodate BES Cyber System Information (BCSI) in the cloud (I made it clear at the start of Monday’s post that the question of BES Cyber Systems themselves being allowed to be put in the cloud – e.g. outsourced SCADA – is very different).

On Monday, I stated that I thought the best way to make sure all important cloud risks are addressed by CIP was for the drafting team to do two things:

1.       Develop a risk-based standard or requirement like CIP-013 that requires the entity to develop a plan to identify, assess and mitigate[i] cloud risks.

2.       In the standard, provide a list of areas of risk that need to be addressed in the plan, while leaving it up to the entity to identify the particular threats in each area (a term I prefer to “risks” in this context, although risks will work almost as well) that apply to them (this is something that wasn’t done for CIP-013. This makes it flawed, but it’s still the closest thing to a model for all other CIP standards that I know of).

3.       For the four existing CIP requirement parts where this is needed, develop language for the Measures that would allow entities to cite a cloud provider’s certification under FedRAMP (and possibly other certifications) as evidence that they have complied.

I believed previously that FedRAMP would most likely address any possible threat that applies to data stored in the cloud, but – and this was the main point of my post – the Capital One breach points to a threat that clearly isn’t covered by FedRAMP. Since I never completely stated that threat, here it is now (or at least, what I understand of it), broken down into logical steps:

a)      Each organization’s level of security within the cloud service provider’s network is usually their responsibility, not the CSP’s.

b)      That level of security is usually dependent on the organization understanding the differences between – say – configuring a firewall in the cloud and configuring a firewall on a separate standalone network, like their own.

c)       It seems many organizations don’t completely understand those differences. In particular, according to the Wall Street Journal, understanding Amazon’s “metadata” service is particularly important.

d)      Paige Thompson, the Capital One hacker, mentioned in online forums that a lot of Amazon clients don’t understand this well, so they have misconfigurations.

e)      After she left Amazon, she exploited this knowledge to hack into C1 and – by her admission – at least two other firms.

So the threat is that a CSP employee will utilize his or her knowledge of likely customer misconfigurations to penetrate a customer’s systems at the CSP and obtain BCSI that way.

What are the mitigations for this threat? On the utility’s part, the most important mitigation is to make sure they understand all the nuances of the CSP’s network that could affect their security configuration, and if that is just too difficult for them, they should pay the CSP itself (I assume this is always an option) to configure their firewalls – and other cloud-based security devices – for them.

But the CSP also has a mitigation they need to implement: They need to do a much better job of explaining these nuances to their customers, since it seems that Amazon (at least) hasn’t done this well enough. However, if C1 is really the only AWS customer who has made these mistakes, then I’d put all of the blame for the breach on them. But until I know whether or not C1 was unique, I have to assign equal blame to Amazon and C1.

This is where things stood for me on Monday regarding required changes to CIP to accommodate BCSI in the cloud. However, on Tuesday (as I’ve mentioned), three individuals told me several things that caused me to change my position (since one of the three – the ex-auditor – focused on a different issue than the one in this post, I’ll put his short comments up tomorrow night).

The most important of these was pointed out to me by a longtime friend who is in charge of CIP compliance for a mid-sized NERC entity, and who has some knowledge of discussions on the BCSI-cloud question in the NERC community. He said that the main thrust of the discussion within NERC circles appears  for the time being to have shifted away from an administrative approach of allowing or accepting FedRAMP as the primary evidence of the vendor’s compliance (which of course had been my assumption. When I last participated in those discussions, that was definitely the idea) to a revised Standard language approch focused on making encryption of BCSI in the cloud (and perhaps in transit to and from the cloud) the main means of compliance with CIP-004 R4.1.3, CIP-004 R4.4, CIP-004 R5.3 and CIP-011 R2 (both parts). These are the requirements that cause all of the problems for BCSI in the current CIP standards. This could be done by changing the wording of these Requirement parts (as well as their Measures), so that encryption of the data is an option for compliance. In fact, my friend thinks that this is now being talked about as the only means of compliance – that is, the only thing that would be needed to show compliance is encryption; FedRAMP wouldn’t necessarily come into the picture at all.

To be honest, I find this idea pretty sub-optimal from a security point of view. Sure, encryption will solve almost every cloud risk I can think of (it definitely covers confidentiality and integrity. Availability would presumably be covered by having duplicate BCSI repositories elsewhere, either at the entity itself or at a different cloud provider). But I’m a firm believer in defense in depth, and putting all of your security eggs in the encryption basket seems to be like depending on the Maginot Line to protect you. Yes, it will protect you fine until something changes about your assumptions (the keys aren’t protected properly and are stolen, quantum computers become available that can make mincemeat of any conventional encryption, or something else), and then it doesn’t protect you at all.

But what if we do both? Along with the encryption requirement, what if the SDT also changed the Measures section for each of those four requirement parts, so that an entity could use their CSP’s FedRAMP certification (or encryption) to show they are compliant with that requirement part? That would help, but it’s not going to cover all cloud risks.

Here, I want to add something another friend of mine – Brent Sessions of  the Western Area Power Administration – pointed out to me yesterday: There’s another whole area of threats that I’ve been ignoring regarding BCSI in the cloud, which should have been clear as day after the C1 breach. These are threats due to the fact that the cloud customer usually is responsible for their own security and – believe it or not – even customers can make mistakes.

As I said, I consider Capital One to be half responsible for their breach, because they hadn’t properly configured their firewall or firewalls – which were virtualized on the AWS network; the fact that AWS probably didn’t provide C1 with enough of a tutorial on the metadata service doesn’t mean
 C1 is off the hook morally. At the least, they could have pressed AWS for more information until they did understand the service. Of course, C1 has taken responsibility on their part, but if lawsuits against C1 start flying around later on, I wouldn’t rule out the possibility that C1 might invite (ever so nicely, of course) AWS to share the defendant’s table with them.

I believe there need to be three major elements in a new requirement part, which should be part of CIP-011 R1 (this is of course the current CIP requirement for information protection, and it’s risk-based to boot): 1) encryption of BCSI (including key protection and encryption of BCSI in transit to or from the cloud), 2) certification of the CSP, and 3) mitigating risks caused by the fact that the entity is most likely responsible for its own cloud security, while at the same time it’s operating in a new environment that’s in many ways very different from that of standalone networks and standalone firewalls.

I suggest that the drafting team draft a new CIP-011 requirement part R1.3, which would contain wording something like this:

“Measures to protect BCSI stored with a Cloud Service, including:

• Methods to encrypt data in storage
• Methods to encrypt data in transit between the Responsible Entity and the CSP (I went back and forth with my friends on the question of data in transit. We all ended up agreeing that a) data in transit definitely poses a risk to using cloud services to store BCSI, and b) if the entity doesn’t want to mitigate that risk, then they should keep all of their BCSI inhouse).
• Methods for protecting the encryption keys, so that only the Responsible Entity's full-time employees or contractors who have BCS access have access to them
• Assurance of the quality of the CSP’s security practices, evidenced through certification under FedRAMP (or other certs like SOC II, ISO 27001/2, etc. Of course, there's a lot more to it than just having a "FedRAMP certificate", if one even exists. There would need to be an explanation of what actually constitutes acceptable certification) - or through another acceptable certification process (this would cover the case where the entity – especially a government one - has no choice except to use a private cloud operated by themselves or another organization. This cloud might possibly have some other certification. The entity would need to show evidence that this was of similar quality to FedRAMP).
• Methods to secure the physical or virtual security devices that protect the Responsible Entity's data in the CSP's cloud environment, if those measures are by contract the responsibility of the RE, not the CSP.” (and the SDT should do a risk analysis, perhaps with one or two security experts who really understand the cloud environment. In fact, maybe Paige Thompson would be available! :)  )

Besides this, there would need to be changes to the Measures sections (and possibly the Requirements themselves) of CIP-004 R4.1.3, CIP-004 R4.4, CIP-004 R5.3 and CIP-011 R2 (both parts) that would allow encryption, CSP certification[ii], or both to be used as evidence for compliance.

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. To discuss this, you can email me at the same address.

---

[i] Although I hope the SDT doesn’t make the same mistake the CIP-013 drafting team made, namely leaving the word “mitigate” out of R1.1, meaning the entity could legally call it a day if they just identified and assessed risks, but didn’t do anything about them! I actually had one person – from a software vendor to the power industry, although one that I doubt actually sells software for BCS so CIP-013 doesn’t apply to their customers – try to tell me this omission was intentional, so the entity really doesn’t need to mitigate supply chain risks once they’ve identified and assessed them. I pointed out to him that none of the guidance or anything else that’s been written on CIP-013 makes sense if he’s right. I don’t know if he still takes that point of view or not.

[ii] I learned today that FedRAMP has different levels of certification, and the medium level includes encryption. Since Capital One shows that at least some AWS customers don’t have encryption, this means that FedRAMP needs to be looked at as as much of a marketing concept as a certification. In particular, if the SDT decides that both encryption and FedRAMP certification will be required, NERC entities will need to make sure their CSP is FedRAMP certified and offers services at the medium level. Of course, fries are extra.