In my three recent posts on how NERC entities can store information about High and Medium impact BES Cyber Systems in the cloud[i] while remaining compliant with CIP, I haven’t yet mentioned what is perhaps the easiest way to do this: Make sure that whatever information you’re storing doesn’t constitute BES Cyber System Information (BCSI). If it isn’t BCSI, then you don’t have to take any particular compliance steps, although you do need to make sure the information is well protected (which I’m sure is usually the case with cloud providers. In fact, I imagine there are few utilities that go to as great lengths to protect information as the cloud providers routinely do).
Of course, to understand what is and isn’t BCSI you have to go to the NERC definition. You can read the BCSI definition for yourself, but the important sentence at the moment is this one: “BES Cyber System Information does not include individual pieces of information that by themselves do not pose a threat or could not be used to allow unauthorized access to BES Cyber Systems, such as, but not limited to, device names, individual IP addresses without context, ESP names, or policy statements.”
This sentence does a good job of describing the purpose of protecting BCSI: It is to prevent unauthorized access to it. So there is nothing wrong with storing information about a BES Cyber System that can’t be used to access the BCS itself. And since even an IP address – when stored “without context”[ii] – doesn’t by itself constitute BCSI, this implies that no single piece of information meets the definition. It is only the whole package of information about a BCS that would constitute BCSI. Ergo, to determine whether a particular package is BCSI, the entire package must be judged against the definition.
But there’s more. Since we’re now talking about the whole package, it also follows that removing any one piece of information (or even two or three pieces) doesn’t necessarily change the whole package from being BCSI to not being BCSI. Let’s use the example of CIP-010 R1 device configuration data – and I use this example because I believe that configuration management is currently perhaps the most widely-used cloud application that stores BCS.
Let’s say your config management application currently stores information on BCS that includes vendor, model and IP address (and nothing else like subnet that could be used to locate the device on the network); I think most of us would agree this probably meets the definition of BCSI. Now let’s remove the IP address, so there is now no good way to locate the device on the network; I think most of us would agree this is no longer BCSI.
But let’s say your package of data also includes detailed information on the physical location of the device. When you remove the IP address, it’s still possible for someone who already has physical access to the site to find it. And if they’re a malicious insider – or a malicious outsider who slipped through the PSP, perhaps through tailgating – they could do as much or more damage to the device as could an external attacker relying solely on electronic means. In this case, I would say you have to remove both the physical and IP addresses in order for this package of information not to constitute BCSI.
But having said all of this, it seems clear to me that, once you have removed all information that would allow the device to be located, the package of information wouldn’t constitute BCSI, and you wouldn’t be subject to any CIP requirements – no matter whether the information is stored in the cloud, with another third party (like a vendor), or within the four (or more) walls of one of your organization’s facilities. So the best way to store information about BES Cyber Systems in the cloud – or anywhere else – is to remove any pieces of information that could be used to locate it.
However, you may have already slammed this post down in disgust (I recommend you only do that if you’re reading it in hard copy, not while you’re reading it on your expensive company-provided laptop!) while exclaiming “What good does it do to store a bunch of information about a device in the cloud if you can’t find the device to make changes, check on a potential problem, etc?”
Of course, this is a good point. And I’ll admit that there may be some cases where you have no choice other than to leave the location information with the rest of the package and comply with the four CIP requirements listed in the first post in this series. But I think there are a number of means by which the information in the cloud could be made to no longer meet the BCSI definition.[iii]
One means would be to simply remove any address data. Perhaps the information in the cloud is being stored there just for analysis purposes, e.g. to ask questions like “How many Windows vs. Linux devices are there?” You shouldn’t need address information to answer questions like that, so it could be removed.
Another example would be if no address information were stored in the cloud. Instead, there was a special key that in itself was meaningless, but that could be used to retrieve the information from a database stored entirely on the entity’s premises (and that database requires a separate authentication). A technician reviewing the configuration information in the cloud, and deciding to look at the device itself, would log in to the internal database and enter the key, thus getting the required address information. This does of course require extra work on the part of the technician, but it then removes the need to comply with any CIP requirements regarding the information about BCSI stored in the cloud, since what is in the cloud isn’t BCSI.
One final note: I’ve already had it suggested to me that encrypting all of the information that is stored in the cloud - or at least location information like IP address – would make it no longer BCSI. That is wrong, and I addressed this idea – with help from an auditor – in this post. It is still BCSI, whether or not it is encrypted. Encryption is a control that can be applied to mitigate the risk of storing BCSI in the cloud. Encrypting the data can probably help with compliace with one part of CIP-011-2 R1.2, although it doesn’t help with compliance with the other three requirement parts listed in that post.
The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte.
[i] I haven’t always said it, but what I said in those posts doesn’t necessarily apply to information about Low impact BCS. I will do a post on that soon. And, as I’ve previously mentioned, what I’m saying in these posts doesn’t apply to cloud services like outsourced SCADA, where the BCS themselves are put into the cloud. That is a very different situation, and any entity with High or Medium BCS that contemplates doing that needs to talk with their Regional Entity before they take any steps in that direction.
[ii] I admit I don’t know exactly what “without context” means. If it means just storing a bunch of random IP addresses without reference to what is at that address, I have a problem with that. If I were an attacker and I found such a bunch of addresses, I would assume they were the addresses of devices on this organization’s network. I would immediately scan them all to try to find out what they were. So I hope it means more than that.
[iii] One person suggested to me that simply removing any reference to a device being part of a BES Cyber System would make the information stored about it no longer BCSI, even if it included location information; in other words, there is no way an attacker could determine whether a device was a BCS component or not. I believe I considered this seriously for about one second, but I had to tell this person I didn’t recommend he use that argument on an auditor. It is highly unlikely that an attacker will be specifically looking for BCS to attack. He or she will be looking for devices that are likely to be important to the entity’s operations (especially BES operations). These are his or her most likely targets, regardless of their CIP status.