A Contradiction in CIP-013

I have recently been talking with NERC entities about how they will actually implement CIP-013, the supply chain security management standard. This standard is close to final approval by NERC, and it’s almost certain it - and the three related new requirement parts added to existing standards: CIP-005 R2.4 and 2.5 and CIP-010 R1.6 - will be delivered to FERC for approval in September. Then there will be a wait for FERC to approve the standard (I’m guessing around 9 months), followed by an 18-month implementation period.

This means that implementation of CIP-013 is still around 3 years away. This might seem like a lot of time, but I’ve come to realize that for most NERC entities – especially the very large ones – coming into compliance with CIP-013 will require a huge effort. This is because it will bring in departments that have never had to deal with CIP – or indeed any other NERC standard – before, especially Supply Chain and Legal. So a number of larger NERC entities are already starting to think about what they will have to do to comply, especially the organizational changes that are needed.

I was preparing for a CIP-013 workshop for one of these large NERC entities recently, when I came across a significant contradiction – specifically, a contradiction between how an entity needs to comply with CIP-013-1 R1.2.5, vs. with CIP-010-3 R1.6. And, depending on how this contradiction is resolved (and if it’s resolved, which isn’t at all certain), NERC entities might be forced to spend large amounts of time and money every year on compliance with CIP-010 R1.6.

Let’s start with CIP-013 R1. I won’t reprint the entire requirement but only R1.2.5 itself, along with R1 and R1.2, since they “govern” it[i]:

• 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:”
• R1.2: “One or more process(es) used in procuring BES Cyber Systems that address the following, as applicable:”
• R1.2.5: “Verification of software integrity and authenticity of all software and patches provided by the vendor for use in the BES Cyber System…”

To summarize these three items:

1. The entity needs to develop a supply chain cyber security risk management plan(s) for high and medium impact BCS.
2. The plan needs to include a process(es) to procure BCS that addresses…
3. Verification of integrity and authenticity of all software and patches provided by the vendor for use in the BES Cyber System.

What I’m interested in here is what this applies to. Specifically, is the plan developed in R1 required to apply to every piece of software on every BES Cyber System, or can the plan be risk-based, meaning that the entity might be able to make exceptions for some systems or software packages deemed to be lower risk – or even for certain vendors for which the risk of loss of integrity or authenticity in software and patches is deemed low?

If you look in the strict wording of R1 itself, you will find nothing that clearly indicates the answer to the above question is Yes. But if you look in the CIP-013-1 Implementation Guidance[ii] (and even in FERC Order 829, which ordered NERC to develop this standard), you will see pretty clear evidence that Yes is indeed the answer.

Specifically, on page 2 of the Implementation Guidance, you’ll find (in the discussion of R1 itself): “To achieve the flexibility needed for supply chain cyber security risk management, Responsible Entities can use a “risk-based approach”. One element of, or approach to, a risk-based cyber security risk management plan is system-based, focusing on specific controls for high and medium impact BES Cyber Systems to address the risks presented in procuring those systems or services for those systems. A risk-based approach could also be vendor-based, focusing on the risks posed by various vendors of its BES Cyber Systems. Entities may combine both of these approaches into their plans. This flexibility is important to account for the varying ‘needs and characteristics of responsible entities and the diversity of BES Cyber System environments, technologies, and risk (FERC Order No. 829 P 44)’.” This passage indicates fairly clearly that the entity’s approach should be “risk-based” and “flexible”, meaning systems and/or vendors of different risk levels can be treated in different ways.

Now let’s go to CIP-010-3 R1.6, which is part of the “package” that implements CIP-013. For those of you familiar with the other CIP standards, this will seem very familiar. There is a box with three columns. The first column shows that High and Medium BCS are the applicable systems. The second column shows the actual requirement part, which reads

“Prior to a change that deviates from the existing baseline configuration associated with baseline items in Parts 1.1.1, 1.1.2, and 1.1.5, and when the method to do so is available to the Responsible Entity from the software source:

1.6.1.  Verify the identity of the software source; and

1.6.2.  Verify the integrity of the software obtained from the software source.”

This means that the Responsible Entity needs to verify the identity and integrity of every piece of software or patch installed on every Medium or High impact BES Cyber System; and of course this needs to be done every time a new patch is installed. The only exceptions to this rule are when – for whatever reason – the “method to do so” (i.e. do the verification) isn’t available.

Then what happened to the “risk-based” and “flexible” approach that the Implementation Guidance advocates for CIP-013 R1? There is no mention of that in CIP-010 R1.6 itself, but there is also no mention of it in the draft Guidance and Technical Basis at the bottom of the standard.[iii] So it seems that, even though the entity can take risk (of systems and vendors) into account in the plan it draws up to comply with CIP-013 R1, it can’t do the same when it comes to actually applying patches every month. To apply the patches (and other software), they need to verify identity and integrity of every patch, for every piece of software installed on a BCS, as long as the means to perform this verification are available. And this to be done every month, if patching is done every month.

I have often heard from larger NERC entities that compliance with CIP-007 R2, the patch management requirement, is by far more burdensome than compliance with any of the other CIP requirements[iv] – and that is because the patch management steps need to be performed every month, for every piece of software installed on every Medium and High impact BCS[v]. It now seems that these entities will have another step – and another very burdensome one - added to this process for many if not most systems, regardless of risk of the system or the vendor. And this is in spite of whatever risk-based language the entity may have in their supply chain risk management plan developed in CIP-013 R1.

I know the SDT didn’t intend to have this contradiction between two parts of the supply chain standards, but I don’t see a way around it. Do you?

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

---

[i] These quotations come from the SDT’s draft of June 28, the most recent that I’ve seen.

[ii] The Guidance is also being revised, although I doubt the particular passages I quote here will be substantially changed. You can find the last (and so far only) official draft of the Implementation Guidance at the SDT’s page in the NERC website (you can also find the second official drafts of CIP-013-1, CIP-005-6 and CIP-010-3, although not the unofficial drafts developed by the SDT since then).

[iii] The Guidance and Technical Basis for CIP-010 R1.6 wasn’t included in the second draft (i.e. the most recent draft posted on the web site). I’m referring here to the most recent “unofficial” draft version of CIP-010-3, which was mailed out to the SDT’s Plus List recently.

[iv] One medium-sized entity told me that half of all the NERC compliance documentation they produce in their control centers is due to this one requirement.

[v] CIP-007 R2 also applies to Protected Cyber Assets, unlike CIP-010 R1.6, so there is that difference. As my former boss used to say, “Thank God for small favors.”