Lew on CIP 13: Your plan and how it will be audited – part I

Note: part II of this post (part 4 of the series) will be out later this month. Lew told me he's writing a new article on CIP-013, which will appear in this month's newsletter - I will wait for that before I do this post. If you want to receive that before I do my post, you can sign up on the first page of RF's web site.

This is the third of four posts discussing what Lew Folkerth of the RF NERC Region has written about CIP-013 in RF’s December and February newsletters. The first two parts of this series (both written in January) are here and here; they deal with the December article, since that was the only one published at the time. In this post and the next one, I will focus on the February article, while still pointing out a couple items from December that I haven’t discussed yet.

As I said earlier, I believe Lew understands CIP-013 better than anyone else at NERC or the Regions. In fact, I’ll go so far as to say that he understands it better than anyone else on the planet, although I don’t want to extend that to the Solar System or the Milky Way – that would be going a bit too far, since some distant planet may well harbor someone who knows CIP-013 better than Lew!

I also want to point out that this post, like the previous two in this series, doesn’t confine itself to just repeating what Lew said in his articles. In some cases I disagree with him, although these are regarding details, not his fundamental approach to CIP 13. More often, I expand one or two sentences of his into one or two pages, both because I’m much more verbose than he is, but also because he’s constrained to a small amount of space in the newsletter – whereas I can bloviate as much as I want.

You can retrieve the December newsletter here and the February one here. You find Lew’s articles, as always, by going to the left side of the first page of the newsletter and clicking on “The Lighthouse”. I also recommend you sign up to receive the newsletter regularly (it comes out six times a year), by going to RF’s home page and signing up about two thirds of the way down the page. Lew writes an article in every newsletter, and they are always worth reading.

Lew’s February article is entitled “A Structure for CIP Risk Management Plans”, and it is clearly intended to apply to all NERC CIP standards or requirements that mandate risk management plans. But as he points out, CIP-013 will be “the first explicitly risk-based CIP Standard” – so it’s currently the only standard that requires a risk management plan[i]. He points to some of the new requirements now being discussed by the CIP Modifications drafting team as probably being future examples of risk-based CIP standards or requirements, but of course they are a long way from becoming standards.[ii] So this article could just as well have been called “A Structure for CIP-013 Risk Management Plans”.

I like CIP-013 a lot and I consider it the future of all CIP standards, but I’ll admit it gives the NERC entity just about no information about what should be in their supply chain cyber security risk management plan (or CIP-013 plan, which is easier to say). And there has been no official guidance on this subject published by NERC or any other organization (there is the Implementation Guidance published by the drafting team, but it still exists only in draft form and I don’t believe it will ever be finalized, for reasons that are too depressing to recount here). So I think it’s a huge help that Lew was willing to lay out what he thinks should be in your plan (and since what he thinks carries a lot of weight with CIP auditors in all of the NERC regions, it certainly behooves any NERC entity to pay attention to this).

Lew says the following sections should be in your plan. He breaks them into four areas, based on NIST 800-30’s four phases of the risk assessment process: Frame, Assess, Monitor and Respond.

I. FRAME

Scope

I’ll admit I hadn’t thought of explicitly including a scope section in the plan, but it makes sense. However, I’m not sure I agree with everything he says in this section of his article. He says your plan should “include an inventory of Cyber Assets that are covered by your plan, as well as a list of vendors that may be affected by implementation of the plan”. While I think it’s a good idea to list vendors (of course, it’s also good to keep in mind that that list will change over time), I don’t think Cyber Assets is the right category of assets to list. CIP-013 applies to Medium and High impact BES Cyber Systems. True, BCS are usually implemented on Cyber Assets, but the software they run often isn’t confined to one of the Cyber Assets – and sometimes, of course, the software runs on virtualized hardware, which doesn’t meet the definition of Cyber Asset at all.

Also, I would qualify his use of the term “inventory”. What CIP-013 is definitely not about is the BCS that you already have – it’s about the ones you will purchase once the standard is in place. I think Lew might have meant to say that the inventory is of the types of BCS that you expect to purchase in the future (again, with the caveat that these will change as well). So I would reword what he says and write “Your plan should include an inventory of types of Medium and High impact BES Cyber Systems that are covered by your plan, as well as a list of vendors that may be affected by implementation of the plan.”

Objectives

Lew’s paragraph on Objectives reads “The objectives of the risk management plan should be clearly identified. For example, your CIP-013-1 risk management plan should include the four objectives from FERC Order 850 P2, as well as any additional objectives that are appropriate for supply chain risk management at your organization.”

Lew listed FERC’s four objectives in his December article. They were originally stated in Order 829, in which FERC ordered NERC to develop the standard in 2016, and in Order 850, in which FERC approved CIP-013 (and the revised CIP-005 and CIP-010 that go with it) in October of last year.

In my first post in this series, I pointed out that, while it’s obviously a good idea to show how your plan meets FERC’s four objectives, the real objective of CIP-013 is found in the statement of purpose at the beginning of the standard: “To mitigate cyber security risks to the reliable operation of the Bulk Electric System (BES) by implementing security controls for supply chain risk management of BES Cyber Systems.” What does this mean in practice? R1.1 answers that question: The plan needs 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).”

Lew did state that, besides showing that your plan meets FERC’s four objectives, you should show it meets “any additional objectives that are appropriate for supply chain risk management at your organization.” This does go beyond what’s in FERC’s list of objectives, but I don’t think it goes far enough. I would rewrite Lew’s paragraph on Objectives to say:

The objectives of the risk management plan should be clearly identified. The objectives of your CIP-013-1 risk management plan should include the four objectives from FERC Order 850 P2, as well as the objectives stated in R1.1.”

Of course, I’ll admit that the objectives of R1.1 don’t necessarily jump out of the page in well-ordered ranks, so here’s what I think they are:

1. Identify important supply chain cyber security risks to the BES, resulting from:
1. Procuring vendor equipment and software;
2. Procuring vendor services;
3. Installing vendor equipment and software;
4. Using vendor services; and
5. Transitions between vendors.
2. Determine the degree of each risk[iii] identified, by determining its likelihood and impact.
3. Rank risks by their degree, and choose the highest risks for mitigation.
4. Rank the risks that underlie the six mitigations in R1.2 at the top of the list.[iv]
5. Using appropriate policies, procedures and technologies, mitigate[v] those risks.

These are all implicitly included in R1.1, even though that might not be obvious. I don’t have time to explain my reasoning for this here, but if you disagree I’m willing to fight you to see who’s right (you’d have to pay your travel to Chicago, of course).

Risk assessment methodologies

Lew’s words for this section are: “The methods you use to assess risk should be spelled out in this section. Each methodology (you can use more than one) will lay out the steps you will need to take to assess the risks you identify.  These steps should take into account the inputs to the process (e.g., threat sources, threat events, vulnerabilities, predisposing conditions, etc.).   Simpler may be better here, but you will need to select the methodologies that you determine are best suited to your organization. If you create a complex methodology to assess your risks, then you will need to be able to explain that methodology to an audit team.”

Of course, Lew isn’t telling you here what your risk assessment methodology should be. In his December article, he did give a broad suggestion of this: It should be based on NIST 800-30, NIST’s “Guide for conducting risk assessments”. Lew said regarding 800-30: “I expect developing a plan by implementing this document and approach would work well for CIP-013-1.” I agree with him on that, and I’ll add that 800-30 has played a big role in the methodology I’ve developed with my clients. However, I would add that you shouldn’t think all of 800-30 will be applicable to CIP-013 compliance. As with other NIST documents, it is aimed at a very wide audience (basically, any organization in the US, although all NIST 800 series document are in theory aimed only at Federal government agencies), and you always have to separate what applies in your case from what doesn’t.

Definitions

Lew says “Any terms used in risk management that may be ambiguous and that are not defined in the Standard should be defined here. Try to keep to generally accepted definitions. Unusual definitions will probably be questioned.” Once again, this is very good advice. You should define the terms you’re using in your risk analysis – including risk, vulnerability, impact, likelihood, etc. And you should make sure you’re following those definitions.

You definitely shouldn’t assume that everyone knows what a risk or a threat is. It’s true that everyone knows what they are – but everyone has a different idea! More importantly, the auditors will almost inevitably have a different idea of what these terms mean than you do, and I can absolutely guarantee that different auditors will define them differently.  This of course creates a lot of problems in the NERC Operations and Planning standards, as well as in the prescriptive requirements in CIP-003 through CIP-011. However, it isn’t really a problem in CIP-013. As long as everyone – NERC entity and auditor - knows what the terms in their methodology mean, it’s fine if their definitions don’t agree.

I also want to point out that you can “define” a term without coming up with a Webster’s-style definition. What’s much more important is showing how each term fits into your methodology. For example, NIST 800-30 uses “threat” as its fundamental term (as do I). The risk assessment process starts with identifying threats, and builds from there. However, the authors point out that you could just as legitimately start with vulnerabilities as your fundamental term (in fact, the Recommendations section of every security vulnerability assessment that I’ve ever seen – including NERC CIP-010 R3 SVA’s – uses this approach). I think trying to base your CIP-013 risk assessment on vulnerabilities rather than threats would make the approach more cumbersome (although I don’t have time or space to tell you why I think this). But making vulnerabilities fundamental would certainly be doable, if you saw some big advantage.

II. ASSESS

Identify possible risks

The first step in the Assess phase of your plan should be risk identification, since R1.1 starts out with “identify and assess” risks. From the work I’m now doing with clients on CIP-013, I believe risk identification (although I prefer “threat identification”. See end note ii below) may well be the hardest part of the CIP-013 compliance process – or at least it’s the one that requires the most creativity.

Why do I say creativity is needed? Because CIP-013 doesn’t provide a list of risks that you should consider for mitigation in your plan. It would be great if NERC developed such a list, but I know it won’t happen. Other organizations will hopefully recommend risks to be considered, including one I’m part of, the Supply Chain Working Group of the NERC CIPC. The SCWG is currently developing six short papers on supply chain risk management (and – in a momentary lapse of good judgment – I have volunteered to lead one of those groups, which is tasked with writing a paper on supply chain risk management lifecycle. Since the SCWG is open to everybody, if you would like to participate in the web meetings for drafting this paper, please drop me an email at the address at the end of this post); these papers will certainly provide suggestions for risks you should consider for mitigation in your CIP-013 plan.

But there are lots of other sources of risk information as well. Lew lists four of them in his article, but other good ones include:

1.       The 2018 NRECA/APPA white paper on supply chain risks for small entities (although I don’t see anything in there that doesn’t apply to large entities as well. I think it’s a very good document for any electric utility, whether subject to CIP-013-1 or not);

2.       The 2015 UTC white paper on cyber supply chain risk management for utilities (also very good);

3.       The 2014 DoE/NERC CIPC (ESCSWG) document on cybersecurity procurement language (really excellent);

4.       The 2018 North American Generator Forum white paper on supply chain security management;

5.       The 2018 NERC/EPRI report on supply chain risk assessment;

6.       The 2019 NERC draft report on cyber supply chain risks;

7.       NIST800-53 r4 Appendix F-SA; and

8.       NIST 800-161.

There is a big difference between the sources Lew cites and the ones above. Lew’s are sources primarily of technical vulnerability information (like DHS NCCIC or the E-ISAC), while mine are sources of mitigations for supply chain risks. While neither Lew’s sources nor mine can be used without restating what is provided, I believe that in general particular technical vulnerabilities aren’t directly related to supply chain risks; rather, they are related to more general cyber risks that apply to the systems directly. In my opinion, supply chain risks have much more to do with processes and procedures (executed at utilities or vendors) that are used in procurement and installation of procured products, than they do with particular technical vulnerabilities in those products. In other words, I prefer the sources I’ve listed over Lew’s.

But even using my sources, you have to “restate” the mitigation to identify the risk “behind” it. For example, one of the mitigations listed in the APPA/NRECA document is “Limiting the systems that can be accessed remotely”. What’s the risk that this mitigates? You could state it as “The risk that systems that don’t need to be accessed remotely will nevertheless be accessible.”

Of course, even limiting your search for supply chain security risks to the sources I’ve stated, there are a huge number of risks to consider! The next step will be assessing each risk to determine its magnitude, which will probably be low, medium or high. It would probably be a good idea at this point not to even assess any risk which you are sure is low (i.e. you would only assess high or medium risks, which means high or medium likelihood and/or high or medium impact). If even that seems to be too many – and I’ll stipulate that anything above 50 is too many – then you might just select high risks for assessment).

Once you have a list of risks that you have selected for assessment, you can go on to the next steps of assessing and prioritizing risks. However – and I hate to disappoint you – I’m going to save that discussion for Part II of this post, coming soon to a blog near you! That part will not only finish the discussion of Lew’s February article; it will also go on to discuss how CIP-013 will be audited.

­

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. My offer to NERC entities of a free webinar workshop on CIP-013, described in this post, is still open! Let me know if you would like to discuss that, so we can arrange a time to talk.

---

[i] I know some would argue that CIP-014 is a risk management standard. CIP-014 R4 requires the owner of a Transmission substation or Control Center that is in scope to perform a physical “threat and vulnerability assessment”, while R5 requires them to develop a physical security plan to address the threats and vulnerabilities identified in the assessment. Of course, the physical security plan is risk-based, but it isn’t a risk management plan – since it doesn’t allow the entity to identify and assess other risks, and mitigate those. I’m not dogmatic about this, but I just don’t think it’s the same thing as CIP-013 R1.

[ii] I also consider the existing “plan-based” CIP requirements to be implicitly risk-based – this includes CIP-003-7 R2, CIP-007-6 R3, CIP-010-2 R4 and CIP-011-2 R1. These all require the entity to have a plan or program (although even that is just implicit in CIP-007-6 R3) to achieve a certain objective, but IMHO there is no way to do that without considering risk. The objective you are achieving is always risk mitigation, e.g. risk from malware in CIP-007-6 R2 or from use of TCAs or RM in CIP-010 R4.

[iii] You may have noticed that it’s awkward to talk about the “degree of risk” of a risk. I would prefer that my step 1 required the entity to identify threats to the BES, not “risks to the BES”; then step 2 would require the entity to determine the degree of risk posed by each threat. This is the terminology used by NIST 800-30, and it also makes sense to me. I think of risk as a magnitude, whereas a threat is simply a statement of something that poses danger, such as “A software vendor won’t have good internal security, and a malicious third party will plant malware in one of their products while in development.” However, CIP-013 uses the term risk in both cases – and this follows FERC Order 829, which does the same thing. I don’t want to confuse my readers too much by introducing a different terminology at this point, although I’m strongly suggesting my clients should follow 800-30’s example in this regard.

[iv] R1.2 lists six mitigations that are mandatory – and they’re mandatory because FERC said (in Order 829) that they need to be included in the risk management plans. Like any mitigations, these six mitigations are all based on particular risks. However, unlike all of the other risks you identify and assess for your CIP-013 plan, you essentially need to rank these six risks as the highest and place them at the top of your list; this way, they’ll definitely “make the cut” to be mitigated. But these six risks are in no way intended to be the only ones you mitigate in your plan, although I know some people – including at least one or two CIP-013 drafting team members – who believe that CIP-013 is pretty much just R1.2, while R1.1 is simply some flight of fancy that can be ignored. I certainly can’t say that auditors will consider doing this a violation, but I can say that this strategy will strip away most of the benefits that would come from correctly complying with CIP-013.

Think about it. I don’t think there should be much doubt that supply chain is the most important area of cyber threats in the world today (if not the most important), for just about any industry and any organization. So why wouldn’t you want to identify all important risks and mitigate the most important of these (which includes the six R1.2 risks, of course), since you’re allowed to choose the risks you want to mitigate in CIP-013? In CIP-002 through CIP-011, you aren’t given the chance to look for important threats and mitigate them, using dollars allocated to you because of management’s fear of NERC/FERC noncompliance – so if you decide that phishing or ransomware should get a lot more attention than patch management in CIP-007 R2, you have to do that using another budget, not your NERC CIP budget. You have to implement the mitigations described in the CIP 2-11 requirements, and you don’t have any power to make substitutions. In CIP-013, these choices are all up to you.

[v] You may notice that the word “mitigate” isn’t in R1.1. Even though the drafting team included that in the purpose statement, they left it out of the main requirement! Of course, there’s no question at all that your CIP-013 plan should include mitigation of risks, not just identification and assessment.