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.
No comments:
Post a Comment