Lew Folkerth’s new article on CIP-013, part I

Lew Folkerth of RF has followed up his two previous articles on CIP-013 (which I wrote about in four posts, found here, here, here, and here) with a third one in the RF newsletter that came out a week or two ago. You can read the article by downloading the newsletter and clicking on The Lighthouse in the bar on the left, or you can go here to RF’s new CIP web page and click the plus sign after “Standards and Compliance.

When you do that, you will see a set of PDF’s of all 30 of Lew’s Lighthouse articles on CIP and cyber security since 2014. Having the articles separate from the rest of the newsletter is a huge help, since a) in order to see one article, you don’t have to download a 13 or so MB file of the entire newsletter, but a <1 MB file of Lew’s article; and b) since he’s titled each article, you don’t have to download every newsletter to even find about what he’s written about. I recommend you look at the whole list and download the ones that interest you; they’re all good, I can assure you.

Articles 29 and 30 are the first two that Lew wrote on CIP-013. As of today (Sunday), the third article isn’t up yet, but Lew thinks it will be up in a day or two. If you don’t want to wait that long, you can download the newsletter itself.

I noticed that rather than being billed as the third article on CIP 13, the article is called “CIP Supply Chain Cyber Security Requirements in Depth (Part 1 of 2)” – so there will be another one after this (I assume it will be in the newsletter issued in June). Of course, this is great news for both Lew and me, since we’re each paid $1 a word to write about CIP 13, and I easily write three words for every one of his – so both of us may get rich just writing about CIP 13! J

Now to the article itself.  As always with Lew’s articles, it’s very good – and I want to emphasize that Lew is the only person in the entire NERC ERO that actually publishes articles about CIP compliance, so that makes the articles especially valuable. I recommend you read it carefully if you’re involved in CIP-013 compliance. In contrast to his first two articles, which focused more on supply chain security risk management in general rather than CIP 13 in particular, this article (and presumably its successor) is laser focused on complying with CIP 13. He goes through it requirement part by requirement part.

However, I do have some differences with Lew on various points. I’ll list them in the order they appear in the article.

My first objection applies to his paragraph on the first page of the article (p. 8 of the newsletter), which states that

“You will have fulfilled the security objectives of CIP-013-1:

·         If you integrate vendor and product security considerations into your vendor selection process,

·         If your future acquisition contracts work to mitigate the cyber security risks posed by your selected vendor, and

·         If you manage the relationship with each of your vendors, present and future, to mitigate risks you identify as applicable to the vendor.”

I really don’t understand this. Yes, these are three important objectives of CIP-013, but there are many more – and you can find a good discussion of all of them if you start reading at the next paragraph about R1 and continue through the end of the article on the third page, with the discussion of R3. Everything in the rest of the article is a “security objective of CIP-013-1”. I suggest you use this wider list as your statement of the objectives for CIP-013.

Another point from the first page: Right below the section I just quoted, Lew states that it would be a good idea to include Medium and High impact EACMS along with BES Cyber Systems, in your scope for CIP-013; he says this because FERC ordered that EACMS be included in the next version when it approved CIP-013 last October. However, in a paper on “Cyber Security Supply Chain Risks” that NERC is currently drafting, they say they would like to see PACS included in the next version as well, meaning it’s highly likely the new SAR will include both EACMS and PACS. So rather than wait the two years or so before the next version becomes mandatory to include EACMS and PACS in your CIP-013 program, I recommend you include it now and not have to worry about retrofitting these later on.

At the top of the second page of the article (p. 9 in the newsletter), Lew says “Addressing your identified risks will probably include some additions to the terms of any contract you use for acquiring BES Cyber Systems and systems or services related to BES Cyber Systems.” He goes on to list two documents on procurement language, the first from DHS in 2009, the second from DoE in 2014 (and it was really the NERC CIPC that developed this document. Ed Goff of Progress Energy led the development for the CIPC and did an excellent job. I regard his departure for the banking industry a few years ago as a significant loss to grid cyber security in general. After all, what do banks have to protect that’s as important as electric power? Oh right…money. But where would banks be without power? Answer: nowhere). I would also add the EEI procurement language document released in March.

However, I have a problem with recommending any pre-drawn set of procurement language provisions. To simply require a vendor to include any language in a contract is putting the cart before the horse. This is because the right way to address supply chain security (and CIP 13 compliance) is to first identify the risks you want to mitigate. There’s close to an infinite number of risks, so you certainly can’t mitigate any but a small number of them. You should identify the biggest risks that apply to your organization’s BES assets (remember CIP-013 is all about risks to the BES, not to your organization), and mitigate those.

This is why Lew says at least a couple times in this article (and has said in his previous articles) that the NERC entity needs to “identify and assess” supply chain risks. It’s also why Lew includes a great sidebar in blue on the last two pages of the article that describes 13 risks you should consider including in your CIP 13 plan. He carefully says this list is a “starting point” – the final list is for you and you alone to determine, although you need to consider a lot of possible risks as you decide which ones you’ll mitigate.

So if you don’t know which risks you’re going to mitigate in your CIP-013 plan, how can you say that a particular set of procurement language is good for you? Each provision in each of the two documents that Lew lists (and the EEI one I linked above) is based on a particular supply chain risk – in other words, procurement language is one way (but only one way) to mitigate particular procurement risks. If you choose one procurement language document as the basis for your contract language, you’re outsourcing the job of deciding what risks you’ll address to whoever prepared that document. First decide what risks you’ll address, then look for procurement language that will properly mitigate those risks.

My next objection is really for the CIP-013 drafting team. It seems they really tripped over themselves in wording R1, and Lew’s summary of the two parts of R1 doesn’t clear that up. On the second page of the article, under “Part 1.2”, Lew says “Your supply chain cyber security risk management plan must also include a process for procurement of BES Cyber Systems. Note that Part 1.1 requires processes to be used in planning for procurement and transitions; Part 1.2 requires a process to be used in actually procuring systems. These will probably be different but related processes.”

I have heard this said before – that R1.1 is for planning, while R1.2 is for actual procurement. It’s understandable that people should believe this, because R1.1 starts out with “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 …” But that’s not the beginning of the sentence. The sentence begins at the end of the “preamble” section of R1, which says “The plan(s) shall include…” If you stick these two together (which of course is how they’re meant to be read), you get “The plan(s) shall include 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 …”

In other words, you need to prepare a plan to include a process for planning. But that doesn’t make sense; you don’t plan a process for planning something, you plan something. This is why I proposed in one of my first posts analyzing CIP-013 in 2018 that R1.1 be read as “The plan(s) shall include one or more process(es) 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 …” followed by the rest of R1.1.

If you read R1.1 this way, you no longer get the idea that R1.1 is just about planning, while R1.2 is about actual procurement. The preamble to R1 makes clear that the whole requirement (R1.1 and R1.2) is about planning; the implementation of the plan doesn’t happen until R2. R1.1 requires your plan to include identification and assessment of risks. But then what does R1.2 do?

It’s a waste of time to try to ponder why the drafting team wrote R1.2. R1.2 includes six particular items that FERC, in their Order 829 in 2016 (which ordered the standard to be drafted), specifically said need to be included in the standard (they mentioned these in different places in the Order). The SDT included them because FERC said to do so; that’s the only reason why R1.2 is there. While, to be sure, these are all worthwhile things to do to mitigate supply chain risk, it’s not like they have some sort of special status over all other things you need to do to mitigate supply chain risk.

So how you do I understand R1.2? I read it as a list of six classes of mitigations (actually seven, since R1.2.6 includes two parts). Each of these mitigates a particular supply chain security risk. For example, R1.2.4 reads “Disclosure by vendors of known vulnerabilities related to the products or services provided to the Responsible Entity”.  This mitigates the risk that “The entity isn't told about a product vulnerability that is known to the vendor. An attacker takes advantage of that vulnerability to take control of a BCS and damage the BES.”

In other words, R1.2.1 through R1.2.6 describe seven risks that need to be included in your plan. But these are different from other risks. As I’ve already said (and as Lew has said repeatedly), there’s no way any organization can mitigate all the risks it faces; it has to choose the small number that are most important and mitigate those. But these seven risks have to be mitigated, because FERC said they have to be. Essentially, you need to push all of these to the top of your list for mitigation. You should include other risks in your plan as well (otherwise, R1.1 wouldn’t be there at all), but these seven aren’t optional.

So R1.1 and R1.2 aren’t doing different things – they’re both about identifying risks. The risks you identify in R1.1 need to be assessed for magnitude of risk, then listed by magnitude; the highest-magnitude risks should be mitigated. But the seven risks in R1.2 don’t get assessed because they’ve already “made the cut” for mitigation. They automatically go to the head of the line. Something like an election where you’re free to choose any 12 candidates from a bunch of names, but you must choose a particular seven candidates because they’re part of the ruling party, which wants to maintain its power no matter what. As we say in Chicago, the fix is in.

There’s one other big point that I discovered in 2018 when I started digging into CIP-013: R1.1 left out an important word – “mitigate”. Yes, folks, you’re told in R1 to develop a plan to identify and assess risks – and in R2 you’re told to implement that plan. But what do you do after you’ve identified and assessed the risks? Nothing. It’s like you’re supposed to say “Yeah, we found some big, hairy risks out there – and they’ll probably cause some real problems for us in the future. But now we’re all done with CIP-013 and we can go about our business as we did before.” Because the drafting team forgot to say you should mitigate those risks.

But don’t try this at home, kids. If you develop an R1 plan that requires you just to identify and assess risks, and you implement that plan in R2, don’t smugly push your list of risks in the face of your auditor and point out that the word “mitigate” isn’t in the requirement (in fact, it’s not in the whole standard). CIP-013 makes no sense unless the risks you identify are mitigated – and everything ever written about it assumes the standard is about risk mitigation. You need to read “identify and assess” in R1.1 as “identify, assess and mitigate”.

As has been the case whenever I’ve written about one of Lew’s articles (but especially the CIP-013 ones), I can see now that it will take multiple posts to say everything I want to say. I’ll break off now, and hope to come back with part II in a week or two. But there are a few other things I’d like to write about in the next few posts. I’m sorry to leave you in a state of suspense. You’ll have to survive until part II comes out somehow…

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. Please keep in mind that if you’re a N the same address.