Sunday, January 28, 2018

Complying with CIP-013, Part 2: Lost in R1.1

This is the second in a series of posts on NERC CIP-013, the upcoming supply chain security management standard. In the first post, I tried to empty my head of everything I already knew (or had opinions on) about CIP-013, and tried to focus on just what was written in the standard itself. I started with the statement of the standard’s purpose, and tried to tease out of that some good pointers on what will be required to comply with the standard. Just analyzing this single sentence showed that complying with CIP-013 will be very different from complying with any previous CIP standard.

In this post, I will look at the requirements of CIP-013 (and they’re all pretty short!). Again, I’ll try to forget anything I know about the requirements or what has been said about them, since in the end all that matters is what is written in the requirements themselves.

Let’s start with R1, which reads:

R1. Each Responsible Entity shall develop one or more documented supply chain cyber security risk management plan(s) for high and medium impact BES Cyber Systems. The plan(s) shall include:

Of course, this is very different from almost all of the other CIP requirements, which require the entity to put in place specific security controls – configuration management, patch management, personnel risk assessments, etc. R1 requires the entity to develop a plan, period. Sure, the plan will need to include certain items to be listed later, but those items aren’t themselves the point of the requirement; the plan is. This isn’t new; there are two currently-enforced CIP requirements that are written in exactly the same way: CIP-003-6 R2 and CIP-010-2 R4. These are also plan-based requirements.[i]

And what is the purpose of the plan required in CIP 13 R1? It is “supply chain cyber security risk management”. In the first post in this series, I already emphasized the fact that the purpose of CIP 13 is risk management, not implementation of particular controls – so the fact that R1.2 lists six particular controls that need to be in place shouldn’t be taken to mean that your plan just needs to address these controls. Your plan needs to address the mitigation of supply chain cyber security risk in general, which is a much broader topic than these six controls.

Let’s continue with the two parts of R1. R1.1 reads:

1.1. One or more process(es) used in planning for the procurement of BES Cyber Systems to identify and assess cyber security risk(s) to the Bulk Electric System from vendor products or services resulting from: (i) procuring and installing vendor equipment and software; and (ii) transitions from one vendor(s) to another vendor(s).

Note that this is pretty curious wording. R1 left off with the words “The plans shall include:” This means that 1.1 should lay out something that must be included in the plan. Instead, 1.1 requires “one or more processes used in planning for the procurement of BES Cyber Systems to…” What does this mean? Concatenating these words with the end of R1 leads to:

“The plan shall include one or more processes used in planning for the procurement…”

Why should a plan include “processes used in planning”? This means that the plan should be for developing further plans. A plan should be for taking particular steps to achieve a particular goal, not for simply developing more plans. Wouldn’t it be simpler just to say the plan should include identification and assessment of cyber security risks to the BES from the two areas of risk listed? Why does there need to be this intermediate step of having “One or more process(es) used in planning…”?

To be honest, I’m not sure at the moment why these words are there; maybe a drafting team member (or someone else) can enlighten me on this.[ii] I recommend you ignore those words. In other words, I suggest you interpret this requirement part as if it were written:

1.1. Identification and assessment of cyber security risk(s) to the Bulk Electric System from vendor products or services resulting from: (i) procuring and installing vendor equipment and software; and (ii) transitions from one vendor(s) to another vendor(s).

If R1.1 were worded this way, what would an entity need to include in its plan in order to be compliant with this requirement? The plan would need to include steps to a) identify and b) assess risks to the BES from vendor products or services resulting from risk areas (i) and (ii).

What does this mean? First of all, I want to point out that item (i) really includes two risk areas, not one. Risks from procuring vendor equipment and software are very different from risks from installing vendor equipment and software. This means I would rewrite the part of the sentence after the colon as “(i) procuring vendor equipment and software; (ii) installing vendor equipment and software; and (iii) transitions from one vendor(s) to another vendor(s).”

Once we’ve made that change, I interpret R1.1 – if written as it is directly above – to require the following steps:

  1. For each of the three risk areas, identify particular risks included in each one. For example, in the area of “procuring vendor equipment and software”, an entity might identify risks such as “the risk that a piece of third-party software included with the product will be infected with malware”; “the risk that the software will include known vulnerabilities that haven’t been mitigated”; etc. This is, of course, potentially a long list. However, IMHO the entity doesn’t have any choice but to list all of the risks[iii] that might be part of procuring vendor equipment and software. As we’ll see in one of the upcoming parts of this series of posts, just the fact that an entity needs to develop a complete list of risks doesn’t mean they will have to spend a lot of time and money mitigating each one; in fact, the entity might determine (and document) that some of those risks are so small that no mitigation at all is required. This is permitted, of course, due to the fact that CIP 13 is the first NERC risk-based requirement.
  2. “Assess” each of these risks. What does this mean? Obviously, there are many aspects of each threat that we might assess. For example, we might assess each threat based on whether it targets our particular department or not; those that don’t affect our department can be ignored.[iv] However, what I think needs to be assessed here is the level of risk in each case.[v] I think that the entity needs to classify each of these risks according to some scheme: high/medium/low; high/low; 1 to 5; etc.

Once the entity has included in the plan each of the above steps (and of course each of these has quite a few implied sub-steps), I think they have properly addressed R1.1 as written. But wait! Haven’t we forgotten something here? We’re going to include in our plan steps to a) identify risks and b) assess those risks. Why are we doing this? Are we going to be satisfied if we simply produce a nice list of risks, each one ranked as – for example - high, medium or low? What else could be needed?

Here’s something else: How about mitigating those risks? After all, isn’t that the whole idea of CIP 13? To actually lower the overall risk to the BES by mitigating supply chain security risks? Yet R1.1 doesn’t require the entity to include anything about mitigation in their plan.[vi]

To be honest, I think it is simply a mistake that mitigation isn’t mentioned in R1.1. It doesn’t make any sense just to identify each risk, assess it, then call it a day and go home. You need to interpret R1.1 as if it included mitigation. In other words, there needs to be a third step in the list above, reading something like:

  1. For each identified risk, mitigate the risk according to the risk level assigned to it in step 2.

Of course, there is a lot more that could be said about this step, and I’ll hope to do that in some future post.

I must admit that, when I started to write this post a few hours ago, I thought I was just going to go over the words of R1 and R1.1 and tease out all of their meaning. Instead, I’ve found that R1.1 doesn’t make much sense unless two changes are made to it (the change incorporated in my revised R1.1 above, as well as adding mitigation to R1.1, as just discussed). So, with greatest respect, I suggest that NERC entities interpret R1.1 to read this way:

1.1. Identification, assessment, and mitigation of cyber security risk(s) to the Bulk Electric System from vendor products or services resulting from: (i) procuring vendor equipment and software; (ii) installing vendor equipment and software; and (iii) transitions from one vendor(s) to another vendor(s).

I’m having a déjà vu moment here. A little less than five years ago, in late April 2013, I set out to write the first of what was going to be a series of posts on how to comply with the CIP version 5 standards; I did this because FERC had about two weeks previously issued a NOPR saying they intended to approve v5 (just as FERC did with CIP-013 less than two weeks ago). Since CIP-002-5.1 was the first standard in order, I started with that.

In that post, as in this one, I tried to work through the steps that would be required to comply with CIP-002-5.1 R1 (including Attachment 1), and I came to a “you can’t get there from here” point – where the logic in the requirement completely broke down. That is a serious flaw in CIP 2 R1 that has never been fixed. At the time, I thought the only solution was to rewrite the requirement (and Attachment 1); I wrote perhaps ten to fifteen posts on this particular topic over the next couple of years (plus many more on other problems in CIP 2 R1), of course without success.

However, it turns out that this flaw didn’t prove to be very harmful as CIP v5 was implemented and then enforced. This is because NERC entities and auditors all came to a common interpretation of CIP 2 R1. The interpretation wasn’t based on the actual wording of the requirement and Attachment 1, but since there was unanimity among entities and auditors, everyone came to believe that this interpretation was actually the correct one.[vii]

Now I believe I’ve found a serious problem with CIP 13 R1.1 (namely the lack of mention of mitigation. The first problem I discussed is more of an annoyance than anything else), but this time I’m not even going to suggest that R1.1 be rewritten. It would easily set back implementation of CIP 13 by more than a year, and I think the solution will be the same as it was with the problem I found in CIP-002-5.1: There will just need to be a common interpretation[viii] of R1.1 that includes mitigation. In fact, I humbly[ix] suggest that my version shown above could be used as that common interpretation – I’ll even make it available royalty-free!

The views and opinions expressed here are my own, and do not reflect those of any organization I work with or for. If you would like to comment on what you have read here, I would love to hear from you. Please email me at

[i] There is another current requirement that is, in my opinion, functionally plan-based. CIP-011-2 R1 requires an information protection program, not a plan. However, the rest of the requirement closely matches CIP-003-6 and CIP-010-2 in form. This is interesting because CIP-011 R1 was developed as part of the “CIP version 5” effort, while the other two requirements were developed several years later, as part of “CIP version 6”.

You may wonder about two other requirements that were originally part of “CIP version 5” that specifically require “plans”. CIP-008-5 R1 requires the entity to develop a cyber security incident response plan, while CIP-009-6 R1 requires recovery plans. However, I distinguish between these two requirements and the three requirements cited above: The plans referred to in CIP-008-5 R1 and CIP-009-6 R1 are actually controls that need to be implemented to protect against threats that might be realized in the future. In CIP 8 R1, the threat is that of a cyber security incident (or more precisely, the threat is that the entity will not respond in an intelligent fashion to a cyber incident and will end up making things much worse). In CIP 9 R1, the threat is that there will be outages of systems that could impact BES reliability unless quickly restored.

The only way you can deal with these two threats is to put a plan in place to address them when they are realized. So CIP 8 R1 actually requires a control – the CSIRP – to address the threat of improper response to cyber incidents, while CIP 9 R1 requires a control – the recovery plan(s) – to address the threat of inability to restore one or more systems when lost. To compare this with a requirement that doesn’t require a plan, CIP 7 R2 requires a control – a patch management program – that mitigates the threat of malicious code. All three of these are prescriptive requirements requiring one or more controls to be implemented; it’s just that in the first two requirements, the control happens to be a plan. That doesn’t make these plan-based requirements using my definition of the term: a requirement to develop a plan for addressing a particular threat or set of threats.

[ii] And I’m not in any way saying the drafting team did anything wrong here; after all, I attended at least two of their face-to-face meetings and some of the call-in meetings, and I never raised this issue at the time. In fact, I didn’t notice this issue, or other issues noted in this post, at all until I started to write the post.

[iii] I would much prefer if R1.1 referred to threats, not risks. I will hopefully address this issue in an upcoming post (and if not, it will definitely be addressed in the book that I and two co-authors are working on, regarding how the CIP standards could/should be rewritten). Briefly, I think the steps should actually be: 1) identify threats; 2) using estimated impact of each threat and the fact that risk = threat X impact, classify each threat by the relative degree of risk it poses; and 3) develop a mitigation strategy for each risk, based on its classification. This would be much clearer if CIP-013 distinguished between threats and risks.

[iv] Obviously, I’m being facetious here.

[v] And as I said in end note ii above, I think this requirement part would be much clearer if it distinguished between threats and risks.

[vi] And, while it might be tempting to think that R1.2 is the part where mitigation is required, that would be a mistake. As I will discuss in the next post in this series, R1.2 lists a set of six specific risks that FERC required NERC to address in this standard when they ordered its development in Order 829; it was never meant to be any sort of comprehensive list of the risks to be mitigated. R1.2 does require mitigation of these six risks, but not of any other risks.

And don’t think that R2 might save the day here. R2 just requires implementation of whatever is in the plan, nothing more. If the plan only includes identification and assessment of risks, then that’s all that has to be implemented.

[vii] Briefly, the issue is that the wording of CIP 2 R1 and Attachment 1 is contradictory. Some of the wording – especially in Attachment 1 Section 3 – leads one to believe that assets should be classified as high, medium or low impact, while most of the wording says that only BES Cyber Systems are classified, not the assets themselves. However, I’d say there is close to 100% unanimity in the NERC community that it is assets, not BCS, that are being classified in Attachment 1. And since this is working, why mess with it? I think I last raised this issue in late 2015 in this post. I don’t intend to raise it again. There are enough real problems with the current CIP standards to be discussed, without dragging out what has turned out to be a fairly harmless wording problem.

[viii] Of course, since it doesn’t make any sense just to identify and assess risks and not mitigate them, it’s very hard to see how R1.1 could be interpreted any other way.

[ix] OK, not so humbly.

No comments:

Post a Comment