Lew Folkerth’s latest article on CIP-013, part II

Three weeks ago, I wrote a post on Lew Folkerth’s latest article (i.e. his third) on supply chain cybersecurity risk management/CIP-013. When I set out to write it, I thought I could do this in a single article. This was silly, since for each of the first two articles in Lew’s series, I’ve written two posts. This one turned out to be the same, so here is my eagerly-awaited second post on Lew’s third article.

I want to point out that, in the first post, I gave directions for downloading Lew’s third article from the RF site, and said it would be a day or two before you’d be able to do that. Instead, it turned out to be a few weeks (Lew had been overly optimistic when he told me it would be up that soon; the process for putting it up includes legal review and…well, you know how that can be sometimes). In any case, you can download the article now. It is item 31 on the list you’ll see (i.e. the last one).

Lew did point out in this article that it won’t be his last on the subject, since there will be a fourth (presumably in the next issue of RF’s newsletter, which will be out in June). That one will be on the new versions of CIP-005 and CIP-010, which will come into effect when CIP-013 does (7/1/20, in case you don’t have that tattooed on your arm yet).

I prefaced the first post by saying that I think what Lew said in this article is all very good, but I do have some disagreements. I went on to list four of these disagreements, although I admitted that the last of them was really a criticism of the drafting team for being unclear. Regarding the last one, my interpretation of R1 differs from Lew’s, but neither of us can be said to be right or wrong, given the ambiguity in the requirement itself (although if you really want to go to the root of the problem, you need to blame FERC. They very unrealistically gave NERC only one year to a) develop the new standard; b) submit it to a vote by the NERC ballot body multiple times; c) get it approved by the NERC Board of Trustees; and finally d) submit it to them for their approval. The drafting team accomplished this, but they naturally didn’t have much time to ask themselves whether the wording was completely clear. Of course, once NERC submitted CIP-013 to FERC, the Commission then took 13 months just to approve it! So much for the big rush…).

My next disagreement with Lew is also at heart a complaint about the drafting team, since this is about another question for which there’s no right or wrong answer: What are the primary elements that need to be in your supply chain cyber security risk management plan, which is mandated by R1.1? Lew’s article lists three elements (which he calls “required processes”):

1. “Planning for procuring and installing” (it would be clearer if this were followed by something like “systems in scope” - which are currently BES Cyber Systems, but will include EACMS and PACS in a couple of years. There also seems to be a big movement by FERC at the moment to include Low impact BCS in some way; it seems they’re being driven by Congress in this matter. However, the NERC ballot body will first need to approve a SAR, and before one can even be drawn up, NERC wants to submit a Data Request to the membership on Low BCS and analyze the results. So this isn’t any near-term likelihood).
2. “Planning for transitions” (i.e. transitions between vendors. This is specifically referred to in R1.1).
3. “Procuring BES Cyber Systems”

Lew says in his article that he thinks the first item (i.e. “Planning”) is the goal of R1.1 and the third (“Procurement”) is the goal of R1.2. In my first post, I explained one reason why I think he’s wrong on this: R1.2 doesn’t have any special purpose. It’s there simply because FERC, at random places in their Order 829, said that these six items should all be included in the new standard; the drafting team decided to group them all together in R1.2. My interpretation of the purpose of R1.1 is that it requires identification and assessment of five types of supply chain cybersecurity risks, which I’ll list in a moment. My interpretation of the purpose of R1.2 is that it simply lists six mitigations that must be included in the plan, but they are far from being the only mitigations in your plan! As Lew makes clear in his article, which concludes with a list of 13 important risks that he thinks NERC entities should consider in their plans, there are a lot of other important risks and mitigations to consider – not just the six (actually eight, since two of these have two parts) in R1.2.

But there’s another reason why I don’t think R1.1 is about planning and R1.2 is about procuring. Lew forgot that both R1.1 and R1.2 are simply callouts from R1 itself, which reads “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…”.

In other words, your R1 plan must include two things. The first is a process for identifying and assessing supply chain risks to the BES (R1.1), while the second is the six specific items (mitigations) that FERC said must be included in your plan (R1.2). I think it’s a mistake to read anything more than this into R1.1 and R1.2.

As I said earlier, I believe there are five areas of supply chain security risk that need to be included in your R1.1 plan. They are all mentioned in R1.1, but I’ll admit that a couple of them are very well hidden:

1. Procurement of BCS hardware and software. This is of course the one that everyone talks about; in fact, I’m sure most people now think that CIP-013 is all about this one area of risk. I agree it’s by far the most important of the five areas, but the entity needs to address the other four areas as well – although, since this is a risk-based standard, there’s no obligation for the entity to devote the same amount of effort to each of these five areas, if they don’t think the other four pose the same degree of risk as this one.
2. Procurement of BCS services. R1.1 says your plan must identify and assess risks to the BES arising from “vendor products or services”. I’m surprised Lew doesn’t specifically mention services in his three required processes, but he certainly does so elsewhere in his article.
3. Installation of BCS hardware and software. FERC made it very clear in Order 829 that they were almost as worried about insecure installation of BCS as they were about insecure procurement of them in the first place (they had the first Ukraine attacks in mind, which had happened seven months earlier. In those, a big contributing factor was that the HMI’s were installed directly on the IT network, which shouldn’t have happened had there been a proper assessment of installation risks). So R1.1 specifically states the entity should assess risks of “procuring and installing vendor equipment and software”.
4. Use of BCS services. This isn’t specifically stated in R1.1, but I think it’s directly required by the words “procuring and installing”. You don’t “install” services, but you do use them. And I think it’s clear that FERC wanted this, since they mandated three items in R1.2 that involve risks from vendor services after they have been procured. R1.2.3 deals with vendor service employees who leave the company. R1.2.5 deals with patches provided by vendors, which is a service (although not one that most software vendors charge for). And R1.2.6 deals with vendor remote access, which is of course also a post-procurement vendor service. So these are three examples of using BES services.
5. Transition between vendors. This is explicitly called out in R1.1, and it’s also on Lew’s list.

This next item isn’t a disagreement with Lew at all: I was very interested that he made a point of saying that, even though you have lots of freedom in drawing up your risk management plan in R1.1, when you get to R2, that freedom goes away. You must implement your plan as written, and if you don’t, you’ll potentially be in violation of R2. So, while you should certainly do your best to identify, assess and mitigate risks in R1.1 and R1.2, you do need to be careful not to promise to mitigate more risks than you will be able to handle. For this reason, I’ve advised my clients to be conservative in committing to mitigate risks in their R1.1 plans - e.g. they might just commit to mitigate those they rank as high, on a low/medium/high scale. If it turns out later that they decide there are other risks they should mitigate as well, they can always add them to the plan and not risk being in violation.

Side note: Someone who hasn’t already been put to sleep by this post (I’m sure that applies to one or two people at least, maybe three or four) will jump up and yell (loud enough for me to hear in Chicago) “You inserted the word ‘mitigate’! But that isn’t in R1.1!” And that person would be absolutely right. R1.1 doesn’t say anything at all about having to mitigate the risks you “identify and assess”. It’s as if the drafting team were saying “All we care about is that you know what your risks are. But no matter how big and hairy they are, rest assured that we don’t expect you to do anything about them. Once you’ve identified and assessed your supply chain cyber risks, you can forget all about supply chain security, throw that list in the trash can, and go back to your normal activities (perhaps CIP-002 through CIP-011 compliance, or perhaps just lying on the beach).”

However, this would make absolutely no sense. FERC didn’t order NERC to develop a supply chain standard just because they thought it would be a really interesting intellectual exercise for NERC entities to identify their supply chain risks; they did it because they thought (and still think) that supply chain is one of the most critical sources of cybersecurity risk worldwide and across all industries (although especially for the power industry, with the Russian attacks being exhibits A, B and C), and those risks need to be mitigated. They even ordered six specific mitigations be included in the supply chain security plans, which the SDT collected into R1.2. And literally every document that’s been written about CIP-013 (e.g. the SDT’s own Implementation Guidance) focuses on mitigating risks, not just on identifying risks in the first place.

So even though the word “mitigate” isn’t in R1.1, I definitely think you should read it in after the words “identify and assess” – i.e. the entity’s plan needs to identify, assess and then mitigate supply chain cyber risks to the BES, not just identify and assess them. I don’t think your CIP-013 plan will fare very well at audit, if it just list risks but says nothing about mitigating them!

Lew also points out that the advice to implement your plan exactly as written doesn’t apply in the case of prescriptive requirements, like most of those in CIP-002 through CIP-011.  He gives this illustration: “..if your personnel risk assessment process created by CIP-004-6 Requirement R3 says that you will perform personnel risk assessments every five years, but you miss that target by a year for some personnel, then that should not be a violation as you are still within the timeframe prescribed by the Standard.” (of course, that timeframe is seven years)

However, since your CIP-013 R1 plan is itself what you are required to implement in R2, this means that any significant shortfall in implementing it might be considered a possible violation of R2. My guess is a moderate shortfall won’t be considered a possible violation, but the auditors could issue an Area of Concern, asking you to fix this problem by the next audit. Either way, it’s better to simply do for R2 exactly what you said you’d do in R1. And the converse of this is that you shouldn’t commit to doing more in your R1 plan than you are sure you can accomplish in R2. I think this is the biggest source of potential compliance risk in CIP-013-1.

Near the end of his discussion of R2, Lew says “Both contract language and vendor performance to a contract are explicitly taken out of scope for these Requirements by the Note to Requirement R2. I recommend that you do not rely on contract language to demonstrate your implementation of this Requirement.” I both agree and disagree with these statements, but that takes a bit of explaining:

1. I disagree that contract language and vendor performance (although that should really be “non-performance”. There’s definitely no risk that you’ll be held in violation if your vendor performs what they said they’d do!) are “taken out of scope” by the note to R2. You should still try your best to get a vendor to agree to contract language that you request, and you should still try to get them to do what they said they’d do.
2. The note in R2 is really saying that neither the actual contract terms and conditions, nor the fact that a vendor didn’t do what they promised, can be the subject of required evidence for compliance; and if your auditor asks you to provide this evidence, you are within your rights to refuse.
3. I doubt that Lew would disagree with the above two statements, but I think he’d still be missing the real point: It doesn’t matter how you document the fact that your vendor has agreed to do something. They might do this in contract language, they might give you a letter or an email, or they might just state it verbally. The big question is, did you verify whether they kept their promise or not?
4. You do need to have evidence about what you did to verify that the vendor did what they promised. Maybe it will be a letter or emails you’ve saved. Maybe it will be notes regarding phone calls. Maybe it will be documentary evidence, like screen shots showing that the vendor digitally signed their software patches, or a vendor’s documentation of their procedures for system-to-system access to your Medium BCS. The best evidence will vary according to the particular promise the vendor made, but there will always be some evidence you can gather.
5. Of course, if the vendor simply refuses to let you know whether they’ve kept their promises, you’re certainly not in violation because of that. But you very well may be in violation if you haven’t even tried to verify whether or not they kept their promises in the first place.
6. Another point that goes beyond what Lew said: What happens if the vendor refuses to promise to do anything? Do you just throw up your hands and say “Oh well, we tried”, and move on to the next challenge? No. If you’ve identified a risk as being important enough to mitigate, you have to take some steps to mitigate it. If the vendor refuses to notify you when they’ve terminated someone who had access to your BCS, you can deny their employees any unescorted physical access to your BCS – which will raise costs for the vendor (and also for you, of course). If the vendor refuses to promise to improve their security practices in their software development environment, you can put their systems on the bench and scan and test them for a month or two before you install them – or better yet, you can stop buying that vendor’s software! There’s always something you can do to mitigate the risk in question, even absent any cooperation from the vendor.

But I do agree with Lew that there is far too much emphasis on contract language as being the best way to mitigate supply chain risks. For one thing, contract language just isn’t a good option for some entities (especially Federal government ones), who have little to no control over contract terms. For another, how many of you have a contract directly with Cisco? I would guess the answer is few to none, since almost nobody buys their Cisco gear directly from Cisco. You buy it through a dealer or integrator, and you probably have some sort of contract directly with them. But the dealer isn’t going to make any commitments on behalf of Cisco – and it’s Cisco that needs to give you a means of for example verifying patch integrity and authenticity, not the dealer.

A third example: If you ever buy something from Best Buy or eBay, I can promise that you’re not signing a contract guaranteeing the manufacturer has certain cybersecurity controls in place (there is a good discussion of contract language in the white paper on “Vendor Risk Management Lifecycle”, currently being drafted by the Supply Chain Working Group. These papers will be presented to the CIPC at their meeting in Orlando next week, and sometime after that, if approved by the CIPC, will be available on NERC’s website. If you want a preview of the argument in that document, you can send me an email).

So I was quite happy to see that Lew doesn’t subscribe to this mistaken view of contract language as the be-all-and-end-all of CIP-013 compliance. But I’m sorry to say that his reasons are wrong. If an entity wants to rely on contract language as their preferred means of documenting the fact that their vendors have agreed to implement certain security controls, that’s fine. Of course, the auditor won’t be able to  compel the entity to show the contract itself, but the evidence that’s really needed is the evidence that the entity made some effort to verify whether the vendor was keeping its promises, no matter whether they were inscribed on golden tablets and stored in Fort Knox or whether they were written in disappearing ink on a scrap of parchment in a bottle buried on the beach of a desert island. That is the evidence that’s important.

This concludes my analysis of Lew’s third article on supply chain cyber risk management and CIP-013 compliance. As soon as the fourth article on this topic comes out in June, you can be sure I’ll have something to say about that as well!

And by the way, Lew, I hope this won’t be the end of your articles on CIP-013, since there’s much more to be said. I know what, let’s make a deal…You can stop writing your articles when I stop writing blog posts about CIP-013. I think that will be around 2030. By that time, I figure everything will have been said that needs to be said.

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 NERC entity, Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed in this post – especially on compliance with CIP-013. To discuss this, you can email me at the same address.