What’s up with BCSI in the cloud?

Two weeks ago, the standards drafting team that’s addressing the issue of BES Cyber System Information (BCSI) in the cloud held a two-hour webinar, of which I listened to the first hour (the link to the recording and slides can be found by going here and dropping down the “2020 Webinars” list). I’ll admit I haven’t been following what this team is doing closely, so I was surprised by some of what they said.

I had planned to write a post on this in a few weeks. But lately, a number of different people – in very different contexts – have asked me about BCSI in the cloud. Since I haven’t directly addressed the topic of BCSI in the cloud, and why it isn’t allowed by the current CIP requirements, even though a lot of NERC entities are doing this anyway, here’s the way I understand it. Note that this isn’t a complete description of what is in the new draft CIP-011-3, just what I think is important to how the new draft addresses the basic problem of BCSI in the cloud).

Also note that this post is about BCSI in the cloud. BCS in the cloud is a completely different story. Hopefully I can make a full frontal assault on that issue soon, but for the moment keep in mind that if you put BCS in the cloud – e.g. outsourced SCADA for a Medium or High asset – you’re violating just about every requirement of CIP-005, -006, -007 and -010, as well as some others. So this remains completely forbidden, and unfortunately will remain so for some time.

• The big problem with putting BCSI in the cloud is that there are three or four requirement parts in CIP-004 that an entity could never comply with, if they put BCSI in the cloud.
• Let’s take the example of CIP-004-6 R5.3, “For termination actions, revoke the individual’s access to the designated storage locations for BES Cyber System Information, whether physical or electronic…, by the end of the next calendar day following the effective date of the termination action.” You might think this should be almost a no-brainer for a cloud provider. I doubt there’s any major cloud provider that doesn’t remove access to storage locations for any information (BCSI or otherwise) within minutes of an individual being terminated, not one day.
• However, there are actually two big problems, which I wrote about in early 2017. The first is the Measures that apply to this requirement part: “An example of evidence may include, but is not limited to, workflow or signoff form verifying access removal to designated physical areas or cyber systems containing BES Cyber System Information associated with the terminations and dated within the next calendar day of the termination action.”
• This means (in part) that the cloud provider will have to have evidence that shows physical access to systems storing BCSI was removed in the next calendar day for every employee or contractor who has physical access to BCS, once they’re terminated. So if there are say 10,000 people who worked at a cloud data center during a three-year audit period, and the systems that store BCSI aren’t protected by some sort of enclosure with a dedicated card reader, then the cloud provider will have to provide that evidence for every one of the 10,000 employees who was terminated during the audit period. It’s fairly safe to say that no cloud provider could or would provide this.
• But it gets worse. The second problem is that the cloud provider has no way of even knowing – or certainly of documenting – what systems your BCSI was physically stored on during any given day, let alone during a three-year audit period; in fact, they probably aren’t even sure what data centers it was stored in. So even if they could provide the required evidence for particular systems, there’s no way to know which systems to provide it for.
• You might ask “Then why couldn’t the cloud providers do what NERC entities have to do if they store BCS at a data center that they control? They need to show it’s within a Physical Security Perimeter, which typically mean a rack with at least a door and its own card reader. That way, the card reader would provide all the compliance evidence that the entity needs.” Of course, if a cloud provider did that, they would completely break their business model.
• If it does that, the cloud provider becomes an application hosting organization that essentially runs applications for individual customers, saving the latter the muss and fuss of provisioning and running them themselves. This is a valid business model and is now pursued by lots of providers. But it isn’t the cloud – the cloud model only works if the provider is free to move data from system to system and even data center to data center regularly, and even break a particular data set apart as it does that. Asking a cloud provider to do that means you’re really asking them to set up a separate application hosting division (and it’s likely some cloud providers have such a division), and to price its services close to what they would charge for cloud services, meaning lose lots of money.
• Folks, this just ain’t gonna happen. I was told that people at NERC approached two or three major cloud providers early last year and suggested that they could just comply with the NERC CIP requirements and solve not only the problem of BCSI in the cloud, but also the problem of BCS in the cloud. As a carrot, they probably suggested that any cloud provider that did this would be assured of a lot of business from electric utilities. I assume those NERC staff members (and there were probably some asset owners involved) did this as an April Fool’s joke; I certainly hope both they and the cloud providers had a good laugh about it. If all the BCSI and BCS in North America were housed at one cloud provider, this might equal the provider’s revenue from say one medium-sized consumer marketing company. Don’t fool yourself into thinking this would be some sort of prize for the provider; it would be a huge headache, with little if any profit to show for it.
• Again, the problem isn’t the requirement parts themselves, but the Measures associated with them, which can’t be changed without a new standards drafting team being convened, any more than the requirement parts themselves can be changed without that step. And in fact, this is the primary reason why the current SDT exists.
• When the question of BCSI in the cloud started being seriously discussed – mainly in the Compliance Enforcement Working Group, a subcommittee of the NERC CIPC – a couple years ago, it seemed to me then (and it seemed to me until the webinar two weeks ago, when I finally learned what the SDT was proposing) that there are only two ways to fix this problem. One is to allow a NERC entity to point to the fact that their BCSI in the cloud is encrypted, as evidence of compliance with requirement parts like CIP-004 R5.3. The problem with using encryption as evidence now is that it doesn’t get the entity off the hook for compliance with the three requirement parts in CIP-004. Even though it technically makes it close to impossible for anyone unauthorized to see the BCSI, the requirement parts are about restricting access in the first place. The fact that the BCSI is encrypted doesn’t change the question whether access to it has been granted or removed.
• The other way to fix the problem is to allow the cloud provider’s certifications (FedRAMP, SOC II or perhaps others) to constitute the evidence. The only question I had – until two weeks ago -- was which one of these ways the SDT would choose (and I thought I heard John Hansen, the SDT chairman, say at the December NERC CIPC meeting that they were leaning toward the encryption approach. However, I may have misunderstood what he said).
• Fortunately, the SDT hasn’t put themselves in my straitjacket of how to address this problem, but has instead taken a much more comprehensive view of the problem of BCSI in the cloud than I was doing. Their draft solution to this problem can be found in the first draft of CIP-011-3, as well as the Technical Rationale for this; you can find these on the SDT’s web page on NERC’s site.
• The drafting team’s efforts include a) modifying CIP-011 R1, b) creating a new CIP-011 R2 (and moving the current R2 to R3, although it has been revised as well), and c) moving the offending CIP-004 requirement parts into CIP-011, where they are addressed in the context of the new approach.
• The current CIP-011-2 R1 requires the NERC entity to develop an information protection plan. However, it doesn’t require the entity to take any particular measures for cloud providers - that is, it allows entities to store BCSI any place they want, as long as their plan provides some sort of protection (of course it’s the CIP-004 requirement parts that effectively prohibit BCSI in the cloud, as just discussed).
• The draft CIP-011-3 R1.1 reads “Process(es) to identify information that meets the definition of BES Cyber System Information and identify applicable BES Cyber System Information storage locations.” The part that I’ve emphasized is new. The SDT explains its significance in the Technical Rationale, where it says “This identification should be as follows: 1) Defined as a friendly name of the electronic or physical repository (thus protecting the actual storage location); and 2) The description of the storage location (e.g., physical or electronic, off-premises or on premises).”
• In other words, a) You don’t have to show that BCSI is stored in a particular location at a cloud provider (which neither you nor the provider could ever do anyway) - you just have to give it a “friendly name” like perhaps the name of your cloud provider; and b) You have to describe the storage location as “physical or electronic, off-premises or on premises”, such as “electronic off-premises” for a cloud provider. So here’s one step toward making BCSI in the cloud “legal” in CIP.
• The draft CIP-011-3 R1.2 reads “Method(s) to prevent unauthorized access to BES Cyber System Information by eliminating the ability to obtain and use BES Cyber System Information during storage, transit, use, and disposal.” This compares with “Procedure(s) for protecting and securely handling BES Cyber System Information, including storage, transit, and use”, in the current version, CIP-011-2 R1.2. The big change here is that, even if someone can gain access to BCSI stored in the cloud, they won’t be able to use it if it’s encrypted, so encrypting the BCSI (in transit to the cloud provider as well as at rest at the provider) will now be a legitimate method for protecting BCSI in the cloud (although I think the ‘and’ in “obtain and use” should be replaced with ‘or’).
• So encryption is now allowed as evidence of compliance in CIP-011-3 R1. How about pointing to the cloud provider’s certifications? Is that also going to be allowed? Not to keep you in suspense - yes, it will be. The SDT did this in R1.4.
• R1.4 is a risk-based requirement part, which requires the entity to conduct their own risk assessment to decide the best way to protect the BCSI they will store in the cloud, based on the risk that this poses. It reads “Process(es) to identify, assess, and mitigate risks in cases where vendors store Responsible Entity’s BES Cyber System Information.
• 1.4.1 Perform initial risk assessments of vendors that store the Responsible Entity’s BES Cyber System Information; and
• 1.4.2 At least once every 15 calendar months, perform risk assessments of vendors that store the Responsible Entity’s BES Cyber System Information; and
• 1.4.3 Document the results of the risk assessments performed according to Parts 1.4.1 and 1.4.2 and the action plan to remediate or mitigate risk(s) identified in the assessment, including the planned date of completing the action plan and the execution status of any remediation or mitigation action items.”
• In other words, the NERC entity can now perform a risk assessment of the cloud provider (the “vendor”), to determine if they have an appropriate level of security such that the entity is comfortable that any residual risk to BCSI stored with the provider is low. In other words, the entity might decide, based on an analysis of the BCSI they’re planning to store with the cloud provider, as well as the certification(s) held by the provider, that the level of risk of disclosure of the BCSI is low enough that it can safely be stored there – and they don’t also have to encrypt the BCSI, although of course that wouldn’t be a bad additional measure.
• However, I’m sure there will be a lot of caveats to this. For one, just saying a cloud provider has e.g. a FedRAMP certification isn’t enough. The NERC entity needs to first identify what the specific risks are, and then determine whether the certification held by the provider adequately addresses those specific risks. And I also think the entity should consider additional cloud risks probably not covered in FedRAMP now, such as those revealed in last year’s Capital One breach (which I discussed in this initial post and this follow-on), and the two even scarier risks I discussed in this post in December.
• However, I’m glad that the draft CIP-011-3 R1.4 doesn’t specify exactly what risks must be considered by the entity, any more than CIP-013-1 R1.1 does. These risks are too fluid to be baked into a requirement. As with the supply chain security risks in CIP-013, it would be great if there were some central body (NERC, the NERC Regions, NATF, etc.) that provided and regularly updated a comprehensive list of cloud provider risks that entities should consider. However, it would also be great if there were world peace and every child got a pony; don’t look for any of these very soon.[i]

To summarize, I thought originally that the BCSI SDT would have to choose between encryption and provider certification for the magic wand that will make it allowable to put BCSI in the cloud. However, I found out two weeks ago that the SDT – whose work I find very impressive – has figured out how to allow both options (and potentially others as well), through the magic of risk-based requirements. I want to say a little more about CIP-011-3 R1 and other risk-based requirements, but I’ll save that for a post in the near future. It’s coming to a computer or smartphone screen near you!

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] I have stepped into the breach for my CIP-013 clients and developed – with those clients – lists of threats, vulnerabilities and mitigations for supply chain cyber risks to the BES. We’ve developed these from going through documents like NIST 800-161, NIST 800-53 and the NATF Criteria, as well as general random observations from news stories, etc. I’m regularly updating these – again with clients – and providing the updates to my clients, even after I’ve finished my project(s) with them.