What does Capital One mean for NERC CIP and the cloud?

I’ve been intending to write two posts on CIP and the cloud, since that topic is much in the air nowadays. I want to do two separate posts because there are two very different questions: 1) what it will take to officially allow BES Cyber System Information (BCSI) to be put in the cloud, and 2) what it will take to allow NERC entities to put BES Cyber Systems themselves in the cloud. The Capital One incident announced last week provides a perfect excuse to write the first of these posts.

Here’s where we stand now on BCSI in the cloud:

1. There is nothing in the current NERC CIP requirements themselves that prevents putting BCSI in the cloud for High, Medium and Low impact BCS; in fact a number of entities are doing that now, including many using a cloud-based configuration management service.
2. I wrote a series of posts (starting with this one in early 2017) that described what needed to be done to comply. These were based in large part on input from an auditor, who I can finally reveal is Kevin Perry, former Chief CIP Auditor of SPP-RE, now retired (in fact, he was quoted in many of my posts, especially during the difficult years of the CIP v5 rollout). Kevin wants me to point out that “the comments (in the post) are a couple of years old and might not reflect current thinking on the part of NERC, the Regions, or the Standards Development Team.”
3. The most important point was that the entity needs to include provision for cloud service providers in their CIP-011 R1 information protection plan – they need to write reasonable requirements for the CSP and make sure the CSP is following them; this shouldn’t be hard to do.
4. But the entity also needs to comply with four requirement parts in CIP-004, all having to do with things the CSP needs to do. Of course, there’s no question that any CSP isn’t already doing all four of these things, but the problem is evidence. With the prescriptive NERC CIP requirements like those in CIP-004 (as opposed to objectives-based ones like CIP-007 R3), the NERC entity is required to have evidence that each of these things was done every time it was required. This means that the CSP will need to have evidence that any of their perhaps thousands of employees who had access to the room (which could be huge) where the servers that contained the entity’s BCSI were located, and was terminated, had their access to that room revoked within 24 hours. Asking the CSP to maintain this evidence would obviously be the same thing as asking them to give up their whole business model in order to please a few electric utilities. Good luck with that.
5. Nevertheless, until recently I believed that all of the NERC Regions were OK with BCSI in the cloud, although I was told a couple weeks ago that one Region still says it isn’t allowed (despite the fact that I heard one of this Region’s most-respected auditors describe at a compliance workshop in 2016 how to comply with CIP for BCSI in the cloud! Of course, I was shocked – Shocked! – to learn there is inconsistency in statements by the NERC Regions, even within one Region. Who would have thought this was possible? J ).
6. And speaking of consistency, NERC is now working on a project called Align, which will consolidate the standards enforcement process across all of the Regions. And guess where that system – including tons of data that is without doubt BCSI – will reside? I’ll give you three choices: 1) NERC headquarters. 2) My basement. 3) The cloud. If you guessed 3), you’re a winner! I sure hope NERC’s able to pass their CIP audit next time.

To make it clear that BCSI can be stored in the cloud, and to determine how NERC entities can provide evidence that it’s secure, a new Standards Drafting Team was created and has already started meeting. I haven’t been able to attend their meetings, although I hope to at least review drafts when they start producing them.

The SAR for this team makes it look like their job will be pretty simple (and up until last week I thought it was): Modify CIP-004 so that the focus is on the cloud provider’s controls for electronic and physical access to BCSI and the devices on which it is stored. In practice, everyone was anticipating that it was a certainty the team would identify one or two certifications – with FedRAMP the far more likely one – that would constitute evidence for compliance with the modestly revised CIP-004 requirements (although the SAR also points out the need to revisit CIP-011 R1. Since that’s a completely objectives-based and risk-based requirement, I can’t see too much need to revise it, although explicit mention of data services like cloud providers – rather than just referring to “third parties” – would be a help).

Of course, determining what FedRAMP “compliance” means (and how it relates to the CIP-004 requirements) isn’t simple at all, since different audits cover different things. And it might be hard to get AWS or MS Azure to just hand you their latest FedRAMP audit report in toto. There’s a lot to be negotiated here. But until last week, I – and others – was saying “There’s no question that no utility can have a level of security on their own network that remotely approaches the average cloud provider’s security level. This will work out fine. What could possibly go wrong?”

And now there’s the Capital One breach. I’m sure some will jump up and say “The breach was Capital One’s fault, and they’ve admitted it. Amazon provided a secure infrastructure like they promised. The fact that C1 didn’t configure their firewalls correctly is their problem – they had total control of them, even though they resided on Amazon’s network.”

From a legal point of view, that’s probably true; I wouldn’t sell all of your Amazon stock right now, if you were thinking of doing that. But the big fly in this ointment, from a pure security point of view, is that Paige Thompson had worked for AWS until recently, and seems to have exploited the knowledge she gained there to breach Capital One’s systems on AWS. In fact, she hinted at having penetrated a couple other AWS customers as well.

Since she wasn’t an employee at the time of the breach, this wasn’t an inside job – yet to pretend that this is something that any competent hacker anywhere could have done, and her former-employee status had absolutely nothing to do with the fact that she was able to hack C1, seems to me to be bending over backwards to make all of this go away. She had inside knowledge (including of likely mistakes that customers would make in configuring their firewalls on AWS), and that played a big part in her breaking into C1.

But let’s get back to the CIP issue: Amazon was FedRAMP certified, yet this happened. Suppose the SDT waits until they have good information on what happened and knows how Amazon could have prevented it, then writes that down as a procedure. We’ll call this Procedure X (it might be a new technology to erase from the person’s brain all memory of anything technical they’ve learned while working at AWS, something benign and non-intrusive like that). The team then adds some sort of provision in the Measures section of CIP-004 that says a FedRAMP certification, plus evidence that Procedure X is in place, is all that’s required to show that the entity is compliant with the four requirement parts in CIP-004. Would that be sufficient?

I shudder to think there are a few people who might think that is sufficient, so I’ll answer this question myself. Of course it wouldn’t be. People are endlessly creative. If they want to wreak havoc and they already have a good knowledge of cloud systems, they’ll figure out another way to do it if they can’t emulate Paige Thompson. And don’t say the answer lies in better training on cloud security for the NERC entity that’s storing information in the cloud. Yes, that’s required, but to say that’s the answer is to say that if only people were perfect and never made mistakes, we wouldn’t have any problems like this.

IMHO, the SDT needs to start looking at a risk-based approach to securing BCSI in the cloud. CIP already has at least four risk-based requirements (including CIP-010 R1, as well as CIP-007 R3, CIP-010 R4 and CIP-003-8 R2) and one risk-based standard (CIP-013)[i]. The requirement that I think best illustrates what this requirement should look like is CIP-010 R4, which mandates that the NERC entity develop a plan to manage the risks of Transient Cyber Assets and Removable Media. Granted, the words “manage the risks of” are nowhere to be found in R1, but effectively that’s what is required.

The plan’s objective is to protect BES assets from risks posed by TCAs and RM. While CIP-010 R1 Attachment 1 (which is part of the requirement) provides guidelines on areas of risk that should be addressed in the plan, there are no prescriptive requirements saying “You either do X within Y days or you get your head cut off.” When you’re making a plan to do something and you’re not told exactly what to do, you need to make trade-offs. You consider roughly the amount of spending (and staff time) that you can get away with in achieving the objective of the plan, and you try to allocate that so that you mitigate the most risk possible given your available resources.

Of course, CIP-013 uses the word “risk” freely; there’s no question it’s risk-based. However, the biggest problem with CIP-013 is that it doesn’t give you any guidance on the types of risks you should look at mitigating – e.g. risks of vendor-caused software vulnerabilities, risks due to provenance, etc. I like CIP-010 R4 Attachment 1 because it does list areas of risk to address: TCA Authorization, Software Vulnerability Mitigation, Introduction of Malicious Code Mitigation, etc.

So I think whatever the SDT develops should require the NERC entity to develop a plan to mitigate risks attendant on putting BCSI in the cloud; then it should suggest particular areas of risk that should be addressed. Of course, most of them will be areas of risk addressed now by FedRAMP, e.g. authentication, vulnerability management, etc. You shouldn’t have to do any extra documentation – and you certainly shouldn’t have to require Amazon to negotiate a separate contract with you if they want your business! – if the SDT decides that whatever FedRAMP requires is adequate to address these areas.

But clearly FedRAMP doesn’t address all areas of risk! So I think the SDT needs to put their thinking caps on and identify risks it doesn’t address. Here’s an idea: What about risks due to ex-employees utilizing their knowledge of likely vulnerabilities caused by customers not completely understanding the inner workings of AWS systems to hack into those customers? My guess is the SDT could come up with other risks like that through talking with experts and just thinking through these things logically.

I’m actually doing a lot of work like that right now. My CIP-013 clients – and all NERC entities who have to comply with CIP-013 – are facing the challenge that R1.1 requires them to “identify and assess” supply chain cyber security risks to the BES, yet it provides no further guidance on where to find those risks. So we’re looking through lots of NIST documents, guidance papers, procurement language from other utilities, etc. And we’re participating in the discussions of the NERC CIPC Supply Chain Working Group, which are excellent. The goal is to put together a list of what my customers consider the supply chain cyber threats that pose the highest level of risk to their BES assets, and figure out how to mitigate those risks within the utility’s own structure and limitations (especially its resource limitations!). The goal is to achieve the most mitigation of BES supply chain security risk possible, given the fact that these utilities don’t have unlimited budgets for cyber security (or anything else, of course).

But I came to realize early on in this process that, as far as risk identification and assessment go, there is just about nothing that’s specific to any particular utility. The areas of risk could and should be identified on a national level, with the entities then being free to decide how much emphasis to put on mitigating risks in each of those areas, depending on their particular environment. This is essentially the approach used in CIP-010 R4.

It would be even better if the new cloud SDT could actually produce a list of threats within each of those risk areas (which is what I’m doing with my clients for CIP-013). Using this list, the entity could then a) add other threats that the SDT didn’t identify, b) assign a risk score (presumably high/medium/low) to each threat, based on their own estimates of probability and impact, c) rank all of the threats by risk score and choose the highest-risk threats to mitigate, then d) develop plans to mitigate the selected risks.

But it would be a huge deal for the SDT to get to the level of identifying individual threats, so I’ll settle for just identifying the risk areas. This will itself be a big help for NERC entities, since they will at least have a starting point for risk identification. Even more importantly, it would give the auditors something to hang their hats on: They could go through each area of risk to make sure the entity understands a) the threats involved in that area, b) the vulnerabilities that enable those threats to be realized, and c) the mitigations for those vulnerabilities. If the entity doesn’t seem to understand something, they certainly won’t give them a Potential non-Compliance finding (those will be reserved for entities that just blow off this whole process), but they are likely to issue an Area of Concern, so that the entity will address the identified problems by their next audit.

My bottom line observation on BCSI in the cloud in CIP is that it’s a moderately hard problem to address, but certainly can be done. In one of my next posts (I no longer say “my next post”, since every time I do that it ends up being 3 or 4 posts later, and sometimes never), I’ll get into the question of BCS themselves in the cloud. That’s nowhere near such a nice picture.

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] Some people say that CIP-014 is a risk-based standard, but I still haven’t made up my mind on that. Whether it’s risk-based or not, it’s been sometimes audited as a prescriptive standard.