The News from WECC, Part I: When a Patch isn’t called a Patch

I’m attending the semi-annual WECC CIPUG (CIP Users Group) meeting in Denver this week – just me and 350 of my closest friends (and attendance is down from some other CIPUG meetings, which have at least one reached 500 attendees). As has been the case previously at these meetings, I have come away with some interesting observations, so consider yourself warned. This is part I of what may be several posts.

In today’s meeting, Eric Weston, one of the WECC CIP auditors, did a good presentation about various pitfalls in CIP-007. I agreed with everything he said, except what he said about CIP-007 R2, Patch Management. The point of this part of his discussion (and you can find his slides, along with all of the other presentations, by going to this page and looking for the slides with his name on them) was that there can be some security patches that aren’t actually called that – they’re referred to as firmware upgrades, driver upgrades, etc.

OK, so far so good – I don’t have any problem with that.[i] However, what I was confused about was that he quoted from the CIP-007 Guidelines and Technical Basis (slide 6) where it says “The intent (my italics) of Requirement R2 is to require entities to know, track, and mitigate the known software vulnerabilities associated with their BES Cyber Assets.” Then he followed that up on slide 8 with the statement that

“Entities should include in their patch management program

• Hardware Drivers

• Device Firmware (that can be updated by end user)

• OS updates for devices that provide revisions to the OS to address vulnerabilities (Cisco IOS, Ruggedcom ROS, etc.)”

This set off a red flag in me for the following reason: CIP-007 R2 itself doesn’t state an objective (or intent, if you will) to be attained, even though the guidance (which isn’t part of the requirement) does. And there is a good reason why R2 doesn’t state an objective: It is a prescriptive requirement. In fact, as the two of you who have been reading my posts closely for the past few months probably realize, CIP-007 R2 is my poster child for a prescriptive requirement (you should really hiss at this point, since the villain has just made his appearance onstage).

Prescriptive requirements don’t state an objective and let you figure out how to attain it, like non-prescriptive (or objective-based) requirements do. Instead, a prescriptive requirement sets out a specified set of steps that must be taken by all NERC entities that are subject to the requirement. While the steps are obviously meant to lead to attaining a particular objective (in this case, mitigating known software vulnerabilities), compliance with the requirement doesn’t entail attaining the objective. Rather, to comply with the requirement, the entity needs to follow the steps, period. So to speak truthfully, the objective of a prescriptive requirement is just to follow the steps listed in the requirement. If you haven’t done that, you haven’t complied with the requirement, even though you may have obtained the final objective through some other means.

To illustrate what I just said, suppose you had decided that you could mitigate software vulnerabilities in your BCS, PACS, etc. simply by scanning them every month and letting the scanner tell you what vulnerabilities it found; then you would find the patches that addressed those vulnerabilities. I'll stipulate for now that this is as good a way - or perhaps even better - to attain the objective of software vulnerability mitigation as the set of steps prescribed in CIP-007 R2. But don't try to tell this to your auditor. You haven't complied with R2 because the objective of R2 is simply to follow the steps listed in the different requirement parts, nothing more, nothing less.

Contrast this with CIP-007 R3, Malicious Code Prevention. This is a truly non-prescriptive, objective-based requirement. Part 3.1 simply reads “Deploy method(s) to deter, detect, or prevent malicious code.” This is a true objective, and it clearly leaves the choice of methods up to the entity. Part 3.2 reads “Mitigate the threat of detected malicious code.” Again, this is the objective; the methods are up to you.

However, the main reason a red flag went up in me is that I was worried Eric was implying that, because the “objective” of R2 was software vulnerability mitigation, and because there are indisputably some software updates released by vendors that mitigate vulnerabilities but aren’t specifically called security patches, the entity is required to search through every update from its vendors to identify those that are really security patches in disguise.

If R2 were an objectives-based requirement like R3 is, you could certainly argue that one way to achieve that objective might be to make a point of applying not only vendor-identified security patches, but upgrades that contained security patches but weren’t called that. But R2 isn’t objectives-based. It specifically says that entities must look for every “cyber security patch” available from a vendor, and they must do this every 35 days. It would be a big stretch to say that this includes every upgrade that mitigates software vulnerabilities, whether or not it is called a security patch.

I brought this question up to Eric at the end of his presentation. He assured me that he wasn’t saying that entities were required to find all security patches, whether or not they’re called that; rather he only said that finding non-security patches (when possible) should be part of the entity’s patch management program. He further said that a Potential Non-Compliance (which replaces "Potential Violation") finding might be assessed if an entity hadn’t done this.

I'll have more to say on this later.

As it turns out, yesterday I had started working on a more comprehensive post on what I find to be an unfortunate (but understandable) suspicion that many NERC entities have of non-prescriptive requirements. The exchange I’ve just described fits in very well with that post, as you will discover – if you’re not already sick of the subject, and of me for constantly harping on it – when I put out that post, hopefully next week.

Note 5/26/17: I just revised this post, as part of writing a new post on security patches. When I wrote this, I didn't understand exactly what Potential Non-Compliance meant, so a few sentences I wrote toward the end didn't make sense.

The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte.

---

[i] You do need to keep in mind the difference between an actual security patch and a functionality upgrade that provides better security capabilities. An example of the latter would be an upgrade that extended the acceptable password length on a device. While this would of course be a great improvement for securing the device, it wouldn’t be a security patch, which is intended to mitigate a software vulnerability. Therefore, functionality upgrades aren't in scope for CIP-007 R2. For a good discussion of this topic, see this post.

Wrapping up the Cloud

Before I started the series of four posts on the cloud and NERC CIP in February, I had assumed that the question of how NERC entities (with Medium or High impact assets) could safely navigate CIP compliance while utilizing the cloud within their ESPs (given that CIP is completely silent on the cloud) was like just about every CIP problem I’ve written about: a story with no conclusion.[i] In other words, almost every CIP problem I’ve looked at has come down to saying this: “The only answer to this question will be specific to your entity, and it will have to come from your Regional Entity. Even the answer you get from your RE will vary according to the person answering, as well as when they answered. Have a nice day.”

But I was pleasantly surprised as I wrote the first post (linked above), when an auditor confirmed to me that entities could safely utilize the cloud and remain CIP compliant. And this wasn’t some opinion of his, but was based on the actual wording of requirements in CIP versions 5 and 6. In other words, it does actually seem like the question of whether NERC entities can utilize the cloud and how they can utilize it – while remaining compliant with CIP – is subject to a definite answer.

In this post, I’d like to summarize what I said in the previous four posts in this series, as well as address a few points I hadn’t discussed, including whether and how Lows can use the cloud. Here is what I think are the “known knowns” (to quote the great scholar and philologist Donald Rumsfeld) about this subject:

1. There are two fundamental questions about the cloud with regard to CIP: First, can an entity remain CIP compliant if some of their BES Cyber System Information (BCSI) is stored in the cloud? Second, what if an entity actually outsources some of their BES Cyber Systems to the cloud (e.g. outsourced SCADA)?
2. Since the situation is very different for owners of High and Medium impact BCS vs Lows, I will separate the two discussions. First is the Highs and Mediums.
3. For Highs and Mediums, the answer to the first fundamental question is yes – they can store BCSI in the cloud. Of course, they have to follow the CIP requirements that apply. In the first post, I listed four requirement parts that an auditor pointed out were applicable to the cloud. NERC entities that follow these four requirement parts should be found compliant.
4. In the second post, I discussed encryption of BCSI data in the cloud. The point of that post is that yes, encryption is a good control to use in complying with the four requirement parts. However, encrypted data is still BCSI. The entity still has to document how they have complied with the four parts.
5. In the third post, I pointed out that the need to provide evidence of compliance with the four requirement parts doesn’t go away just because the BCSI is in the cloud. In fact, it is possible that some entities who utilize the cloud will be found non-compliant just because they were unable to obtain adequate documentation from their cloud provider. In other words, you need to bring up CIP compliance before you sign on the dotted line with your provider; if you wait until afterwards, it may be too late.
6. In the fourth post, I wrote that there is one way for an owner of Medium or High impact assets to store information about their BCS in the cloud but not have to take any special steps to comply with the four requirement parts as a result: that is to read the BCSI definition carefully and take steps to make sure what is stored in the cloud doesn’t meet that definition.
7. Regarding the second fundamental question, whether High or Medium impact BCS themselves (not just information about them) can be stored in the cloud, the answer is: Not if you want to have any friends at NERC or your Regional Entity. Regardless of whether this is compliant or not, I know that both NERC and FERC are very much against “real-time operations in the cloud” – as I pointed out in this post in January (however, on the question of whether this is compliant, see the last three paragraphs below).

Now for three more topics I haven’t addressed yet:

First, what about Lows? Regarding the question of storing BCSI in the cloud, the answer is very easy: Lows don’t have BCSI, or more specifically they don’t have any requirements that apply to it. I assume that the auditors won’t object if an entity with Low assets tells them they’ve stored information about their Low BCS in the cloud – and if they do object, they can’t do anything about it.

Regarding whether Lows can outsource their Low BCS to the cloud, one again I think the answer is the same as for Highs and Mediums: Doing this will be met with a lot of skepticism on the part of your Regional Entity, whether or not it actually is compliant.

Second, what about certifications? If a cloud provider has a SOC 2 certification – or another cert like FedRAMP – is that good enough? The answer to this question is a lot like the one for encryption. If your cloud provider has a certification, this will certainly go a long way toward establishing that your BCSI is safe there. However, you still have to comply with the four requirement parts. It is possible that your Regional Entity will accept the certification as compliance evidence, but you certainly can’t just point to the cert and say “Here, that’s all you need to know.” You still have to document why the cert should be used as evidence of compliance with each of the four requirement parts.

My third new topic is, I’ll admit, a little arcane. But I do want to point out that a strict reading of CIP-002 R1 seems to indicate that the entity is free to outsource their BCS themselves to the cloud or to any other third party, completely consequence-free (ironically, this doesn’t apply to BCSI. So as far as CIP compliance goes, it’s fine if you outsource your entire SCADA system to Al Quaeda, just as long as you don’t store any of the BCSI with them).

The reason for this is found in how CIP-002-5.1a R1 works. The requirement begins by providing a list of six types of “assets” that need to be considered – Control Centers, Transmission substations, etc. The meat of the requirement is found in R1.1 through R1.3. R1.1 tells the entity to identify any High impact BCS at each asset, meaning any of the six types just listed. R1.2 does the same for Medium BCS, while R1.3 says the entity needs to identify assets that contain Low impact BCS. In all three cases, the universe of assets is confined to the six types. Any BCS not located at one of those assets aren’t in scope for CIP (even though they meet the definition of BCS).

So what if an entity has outsourced their BCS to the cloud (or any other third party, for that matter)? It is a safe bet that the BCS aren’t located at one of the six asset types listed in R1 (I don’t know too many cloud providers that locate their data centers at generating plants, for example). What is their status for CIP? They’re completely out of scope. As I said, you can locate BCS anywhere you want, with whomever you want, but they are only in scope if they’re physically located at one of the six asset types.

However, I also refer you back to bullet point 7 above – especially the part about not making any friends at NERC or your Region. Don’t try this at home, kids!

The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte.

---

[i] My poster child for a CIP problem is the problem of what CIP-002 R1 (and Attachment 1) means. I first discovered that the wording was flat-out contradictory when I wrote this post in 2013. I have since written over 50 posts addressing this question from one angle or another – but of course there simply is no definitive answer to it. 

Did you know this?

If you have Low impact assets, you probably know the deadline for compliance with Sections 1 and 4 of Attachment 1 of CIP-003-6 R2 is this April 1. However, you may not know that you are required to have your first exercise of your incident response plan (under Section 4) completed by April 1. To be honest, I didn’t know that until today either; I had thought it was simply an area of ambiguity, so the regions would be on their own to say what they wanted their entities to do – and they couldn’t issue a PV if the entity hasn’t exercised its plan before that date.

However, today a longtime NERC compliance professional emailed me to ask me this question. I took this quite seriously since this is someone who has been working closely with the CIP standards since version 1; if he wasn’t sure, I knew I needed to investigate this. So I checked with two regional CIP auditors (from different regions) and with Lew Folkerth of RF, who was a CIP auditor but now provides great insight on CIP to RF members (and to the whole NERC community, through the RF newsletter and frequent posts by me, such as this one).

All of them said the same thing: A NERC entity with one or more Low impact BES assets (more specifically, one or more assets that contain a Low impact BES Cyber System) needs to complete their first incident response plan exercise before April 1. Moreover, this isn’t some arbitrary decision made by NERC or the regions; it’s baked into the implementation plans for CIP v5 and v6 (but it’s a complicated story to figure out – hence the fact that there is so much confusion on this question). Here is what Lew said by email:

Lew said: “Where the ERO is coming from on this is that the V5 Implementation Plan (October 26, 2012) states that the initial performance for CIP-003-5 R2 is “on or before the effective date of CIP-003-5 R2…”

The V5 Revisions Implementation Plan (January 23, 2015) states “The following sections of the Implementation Plan for Version 5 CIP Cyber Security Standards (Version 5 Plan) remain the same: Initial Performance of Certain Periodic Requirements – For those requirements with recurring periodic obligations, refer to the Version 5 Plan for compliance dates. – These compliance dates are not extended by the effective date of CIP Version 5 Revisions[i].”

However, Lew did send another email that said “If an entity is not going to complete testing of its Cyber Security Incident response plan as required by CIP-003-6 R2 Attachment 1 Section 4.5, then the entity should self-report this issue to its Region as soon as possible. The entity will have an opportunity to work with the Region’s Enforcement Group and to explain the misunderstanding, and that the testing was completed as soon as practical after the issue was identified.”

A word to the wise – as well as to the merely tardy.

The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte.

---

[i] What the two quotes say together is that the CIP v5 initial performance dates for periodic requirements (those that have to be done periodically, like every 15 months) apply to v6 as well. Since the initial performance date specified for CIP-003 R2 in v5 was April 1, 2017, and since that date is unchanged in v6, there shouldn’t be any question that entities with Low assets need to exercise their response plans by April 1.

But this ignores an important fact: What was CIP-003 R2 in CIP v5 is now CIP-003 R1.2 in v6 (and there was no R1.2 in v5, only R1). So I would really read the two quotes as saying that the initial performance date for CIP-003 R1.2 in v6 is the same as that for CIP-003 R2 in v5. And what about CIP-003-6 R2? That really should have been addressed separately in the v6 implementation plan – i.e. the SDT should have specifically listed the initial performance date for R2 as April 1.

I do think this is a legitimate problem, but not one that’s likely to be addressed before April 1. So I just suggest we all put it down on the List of Unfair Things in NERC CIP – by my latest count, this is number 4,527 - and work on getting the CSIRP exercised by that date. For the last word on this subject, I quote my favorite philosopher, Jimmy Carter, who said “Life is unfair”.

How will CIP-010 R4 and other Non-Prescriptive Requirements be Audited?

I have written a lot about the problems caused by prescriptive requirements in NERC CIP, and the need to replace them with non-prescriptive requirements. What I haven’t written anything about – frankly, because it had never occurred to me to do so – is how the non-prescriptive requirements will be audited. This might seem like a question that can safely be addressed later, but that’s wrong. There are already a number of non-prescriptive requirements in the NERC CIP standards[i], and audits have already started on at least one of them, CIP-007-6 R3.

With his usual great sense of timing, Lew Folkerth of RF has published a very good article on this topic in the January-February issue of RF’s newsletter (click on Archives under Newsletters and choose 2017. The article is on pages 9-10). While the title of the article is “Transient Cyber Assets and Removable Media”, what it actually addresses is what kind of evidence NERC entities will need to produce to demonstrate compliance with CIP-010-2 R4, which Lew calls “the epitome of a non-prescriptive, results-based standard” (and I agree with this statement).

However, I will take what Lew says a step further (and he has given me permission to say this): Similar evidence is likely to be required for all “non-prescriptive, results-based” requirements, both existing ones like CIP-007-6 R2 and future ones. So it’s worth paying attention to what he says, even if your organization doesn’t have High or Medium impact BES Cyber Systems and thus doesn’t have to comply with this requirement[ii].

What does Lew say about this question? I’ll let you read the article, but Lew lists four components of a good evidence package for CIP-010-2 R4 compliance:

1.        First, you need “A documented plan to protect the Transient Cyber Asset” (or Removable Media) according to “the R4 base requirement”. The base requirement mandates implementation of “one or more documented plan(s) for Transient Cyber Assets and Removable Media that include the sections in Attachment 1.” So you first have to document the plan itself.

2.       Second “The plan must include the methods you employ to protect the Transient Cyber Asset” from the risk introduced by one of the five objectives identified for TCAs in the requirement. These are found in Attachment 1 of CIP-010-2. For example Section 1.2 is titled “Transient Cyber Asset Authorization”, and lists three “sub-objectives”: User, Locations and Uses. This means your plan needs to include methods to authorize users, locations and uses of TCAs. Similarly, the plan must include methods to protect Removable Media against the two threats listed for those devices: Software Vulnerabilities Mitigation and Malicious Code Mitigation.

3.       Third, the plan must show “how methods documented in the plan achieve the objectives.” For some of the objectives listed in Attachment 1, it is left completely up to the entity to determine a method to achieve the objective (although there is very good guidance provided in the Guidance and Technical Basis included with the standard). For other objectives, there are several suggestions for methods that can be used, but there is also the option of using “Other methods”.

4.       Last, there must be “Evidence that these methods are applied consistently and reliably for each applicable Transient Cyber Asset.”

Of course, even though Lew was writing specifically about CIP-010 R4 in the article, you should be able to easily apply his guidelines to other non-prescriptive requirements like CIP-007 R3 – or any other requirement or requirement part that simply states an objective without telling the entity how to achieve it.

So as an exercise, I turned to CIP-007 R3 to see how easy this was. And I sent my work to Lew to review, to make sure I was on the right track. Here is what I came up with, with revisions suggested by Lew (the numbered bullets below correspond to their counterparts above):

1. CIP-007 R3 doesn’t specifically require that you “develop a plan” for malicious code prevention, as CIP-010 R4 does for TCAs and RM security. However, R3 does require “one or more documented process(es)”, which amounts to almost the same thing. So you need to document the processes you will follow for malicious code prevention. Lew points out “The documented processes will be audited to ensure they contain the minimally required provisions. Audit teams will also look at the effectiveness of the processes.”
2. The plan will need to include the methods you use to prevent malicious code. And the methods will most likely vary according to the BCS, PCA, EACMS or PACS being protected. Of course, that was the whole idea of making the anti-malware requirement non-prescriptive in CIP v5 – that you wouldn’t need to use the same method for every device. The CIP v3 anti-malware requirement, CIP-007-3 R4, required the entity to use antivirus or another anti-malware tool to “detect, prevent, deter and mitigate” the threat of malware attacks (or take a Technical Feasibility Exception if the device wouldn’t support antivirus. This of course led to a lot of late nights as CIP compliance professionals painstakingly documented that their nice new switch or router wouldn’t support loading antivirus software. They also had to let their region know at regular intervals after this that the switch still didn’t support A/V. My guess is most people who lived through this have repressed all these painful memories. They may not even remember that there was a CIP v3 at all, or even where they worked from 2010 to 2016).
3. Next, the entity needs to show how the methods documented in the plan achieve the objective. This objective is ideally malicious code prevention. If that isn’t possible in the case of a particular cyber asset or assets, Lew points out that the methods should include detection (Part 3.1), threat mitigation if detected (Part 3.2) and signature updates if applicable (Part 3.3).
4. Finally, the entity needs to document that the methods have been applied “consistently and reliably” for every cyber asset in scope. Note that this doesn’t mean you need to show that one method was applied to each of those cyber assets. As I just said, the main reason this requirement was written non-prescriptively was that there is likely no single anti-malware method that will apply to all of your cyber assets in scope. The methods will differ according to the cyber asset[iii], but you will need to document that you have applied one of the methods identified in the second part to each of those cyber assets (and, as Lew points out, it is preferable if you’ve applied multiple layers of defense to some or all of the cyber assets in scope).

I predict that, once you compare your workload for complying with these non-prescriptive requirements with the workload for complying with the highly prescriptive ones (and CIP-007 R2 is my poster child for those!), you might begin to see why I’m advocating that all the requirements be made non-prescriptive.

The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte.

---

[i] I used to just list three non-prescriptive requirements: CIP-003-7 R2 (still not in effect, of course), CIP-007-6 R3, and CIP-010-2 R4. However, I know there are more than that. In writing a recent post about CIP and cloud security, I discussed four requirement parts that are relevant to that topic, and realized that three of the four are non-prescriptive. I am sure that if I looked I’d find other non-prescriptive requirements and requirement parts, and I hope to soon have time to categorize all the requirements in CIP v5 and v6 as either prescriptive or not. This may seem like an easy task and perhaps it is, but almost nothing I’ve ever undertaken regarding CIP has ever proved easy, and my guess is this won’t either. First I have to get my taxes done.

[ii] If you just have Low impact assets, you should note that the main requirement that applies to Lows, CIP-003 R2, is non-prescriptive.

[iii] Lew points out that he discussed this in his column (called “The Lighthouse”, as always) in the RF March 2016 newsletter. You can find it at the same link I provided near the beginning of this post.

Another Way to Store Information about BCS in the Cloud

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.

A Break in the Cloud(s), Part III: A Word of Caution

I have gone back and forth on the cloud and NERC CIP. I used to say that, even though the CIP requirements probably forbid use of the cloud, I thought that the auditors would permit it with certain precautions. But right after New Year’s I got a scare and went through a couple months of fearing that any entity storing BES Cyber System Information in the cloud was going to be found in violation of NERC CIP (as discussed in footnote 1 in this post from early January). However, I recently posted that it should be fine to store BCSI in the cloud (according to at least one CIP auditor) as long as you comply with four requirement parts, discussed in the post.

I am still of that opinion. However, I was reminded this week that getting the evidence required for compliance isn’t a trivial pursuit. If you aren’t storing the proper evidence now, you should probably reach out to your cloud provider and get it; plus you may need to self-report non-compliance for the period that you stored BCSI in the cloud without having this evidence.[i]

What is this evidence? You will need to have[ii]:

• CIP-011 R1.2:  Evidence that your cloud provider is following the requirements of your Information Protection Plan (which at a minimum should address the three requirement parts listed below, but should in general include everything that you believe is important for protecting BCSI. In fact, my guess is your IPP should require the same steps of the cloud provider as you require of your own organization. It will probably be difficult to justify to the auditor an IPP that says certain steps are necessary for your organization, but they’re not necessary for a third party that is storing your BCSI).
• CIP-004-6 R4.1.3:  Evidence that your cloud provider has restricted access to designated storage locations, physical or electronic, for BCSI.
• CIP-004-6 R4.4:  Evidence that the access your cloud provider allows to designated storage locations, physical or electronic, is restricted to individuals for whom it is necessary to perform assigned work functions.
• CIP-004-6 R5.3:  Evidence that access for individuals who have been terminated has been revoked by the end of the next calendar day following the effective date of their termination.

Of course, for suggestions on how you can produce evidence of the above requirement parts, you should look at the Measures column in the requirements table, as well as the Guidance and Technical Basis. Even more importantly, you should look at whatever guidance your Regional Entity has provided regarding evidence.

However, keep in mind that simply providing an attestation from your cloud provider that they are complying with the provisions in your IPP, as well as with the three CIP-004 requirement parts listed above, will probably not be acceptable. Your provider will need to provide you evidence similar to what you (the NERC entity) would have to provide for compliance with the same requirement parts.

If you look at the Measures for CIP-011 R1.2, CIP-004 R4.1.3 and CIP-004 R4.4, I think you’ll agree that it shouldn’t be too hard for the cloud provider to comply with those. The provider basically needs to show you that they have implemented certain procedures that are compliant with either your IPP (for CIP-011 R1.2) or with the applicable requirement part (CIP-004 R4.1.3 and R4.4). In my opinion, this shouldn’t be too difficult.[iii]

However, CIP-004 R5.3 is a different story. While the other three requirement parts are what I call non-prescriptive (or at least minimally prescriptive), R5.3 is quite prescriptive. At least in some regions, to show you are complying with that requirement part, you have to be prepared to provide evidence that you have complied in every instance to which it applies. That is, for every termination action, you will need to have evidence that access was removed before the end of the next calendar day.

Let’s see a show of hands. How many people think their cloud provider is going to provide that evidence? I didn’t think I’d see any…. Yes, folks, there’s going to have to be another way to provide evidence that your cloud provider is complying with CIP-004 R5.3 with respect to your BCSI.

Regarding evidence, the auditor said “The Regions are not going to go onsite to the third-party provider and audit their compliance with the CIP Standards.  It is up to the Registered Entity to demonstrate compliance.  They can do so by either requiring the third-party to submit sufficient, appropriate, and applicable evidence to provide a reasonable assurance that they are complying with the applicable requirements, or to require the third-party to undergo an external audit by a reputable unrelated third-party audit firm and provide the detailed report of the third-party audit.  The audit report will need to be sufficiently detailed to demonstrate the applicable controls conform to the requirements of the CIP standards and that they are effectively implemented.”

When I pressed the auditor on the question of whether the entity would need to get evidence of every termination from their cloud provider for compliance with R5.3, he didn’t rule out that there might be another way to provide evidence. One way would of course be an audit report (such as a SOC 2 audit) showing that the provider promptly removes access in the case of terminations. When I asked him if that was the only way, he said “As an auditor, especially under V5, I must keep an open mind and evaluate whatever evidence is submitted to see if I can rely on it to reach a reasonable determination of compliance or not.”

So there you have it.

The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte.

---

[i] As any NERC compliance professional knows, “If you didn’t document it, you didn’t do it.”

[ii] In what I write below, I’m not providing any new information on how to comply with CIP if you have BCSI stored in the cloud. I’m only rephrasing what is shown in the standards, and what an auditor has said to me in recent emails. If you go back to the post I just referenced, you’ll see that these four bullet points correspond to the four requirement parts listed in the post (CIP-011 R1.2 and three requirement parts from CIP-004).

[iii] Although it’s conceivable your cloud provider may absolutely refuse to do any of these things. If so, you may need to start looking for another provider, or figure out a way to keep actual BCSI out of the cloud (see another post coming soon that will discuss this idea).