FERC will approve CIP-013 on Thursday

The first item on the just-released agenda for FERC’s monthly Sunshine Meeting this Thursday reads “RM17-13-000 Supply Chain Rise Management Reliability Standards”. You probably are surprised that FERC seems to be moving in a direction nobody had predicted: Rise Management. And I have to admit that I am fairly surprised at this, although I’m not sure exactly what “rise” refers to and why it needs to be managed. However, the more likely explanation for this neologism is that it’s actually a misspelling of “risk management”. And then it makes perfect sense: FERC has CIP-013 on their agenda for Thursday.

And now I’m going to go way out on a limb: I predict that FERC will approve CIP-013 (along with the new versions of CIP-005 and CIP-010, which are part of the CIP-013 “package”), not remand it (of course, they’ve never remanded a CIP standard that was presented to them, no matter how many problems they found with it – so saying this isn’t much of a stretch). But the big question is what else they will include in the order. I’m not going to predict exactly what they’ll include (a fool’s errand, if there ever was one!), but I will tell you some of the things I’m looking at:

1. EACMS

First, what will they say about Electronic Access Control or Monitoring Systems (EACMS)? In FERC’s Notice of Proposed Rulemaking (NOPR) on CIP-013 this January, they evinced a lot of concern that these aren’t included in CIP-013 now (as approved by NERC, CIP-013-1 only applies to Medium and High impact BES Cyber Systems). I would guess they will order that EACMS be included, but the question is when they will need to be included.

FERC’s normal procedure is to state that the standard they’re approving needs to be changed in a certain way, but not to provide a particular deadline for doing this. Because NERC’s Rules of Procedure don’t allow a standard that has been approved by the NERC Board of Trustees to be changed, this in fact means that this item will go on the agenda for the next version of the standard being approved. But FERC does have the ability to order a “compliance filing” (I may not have the terminology right), providing a short deadline for something to be done. If they do that for EACMS, there would have to be a) a quick drafting/balloting/approval process for version CIP-013-2, which includes EACMS in scope, followed by b) the start of development of CIP-013-3, to include everything else that FERC orders.[I]

2. Low impact BCS

What will they do about Low impact BES Cyber Systems? Should they be included in CIP-013? When FERC ordered NERC to develop a standard for supply chain cyber security risk management, they stated that it should apply to BCS, but they didn’t mention anything about impact ratings. The first draft of CIP-013 included a separate requirement for Low impact BCS, which was perhaps one of the reasons why that draft received 9% approval. Not too surprisingly, Lows were removed from the subsequent drafts.

In their NOPR, FERC didn’t say whether or not they wanted Lows included in CIP-013, but they did order NERC to look at the issue. NERC’s report (really written by EPRI) came out in September. Not too surprisingly, NERC/EPRI didn’t directly weigh in on whether Lows should be included in CIP-013, but it seemed to me that they think it wouldn’t be a terrible idea (of course, nobody thinks that Lows should have to comply at the same level as Mediums and Highs do). So I think it’s likely that FERC will order that Lows be included, but since they won’t order this as a compliance filing, it will be done at the normal NERC standards development and approval pace – meaning the earliest that Lows would have to comply with CIP-013 would be 2 ½ - 3 years from now.

Implementation period

In their NOPR, FERC also suggested that the proposed implementation period for CIP-013, eighteen months, was too long; they suggested that twelve months would be more appropriate. For those keeping score at home, if FERC approves CIP-013 this week, the implementation date will be July 1, 2020. So if the implementation period were shortened to twelve months, the date would be January 1, 2020.

However, I think it’s unlikely that FERC will do this, since they can’t just wave their magic wand and change the CIP-013 implementation plan. In order for the plan to be changed, there will need to be a number of steps, including drafting a Standards Authorization Request, impaneling a Standards Drafting Team (although it’s very likely the team that drafted CIP-013-1 will be assigned this task), drafting the changes (and if FERC orders a compliance filing for EACMS as well, that would also probably be included in the SAR), balloting the first draft, revising the draft after the first ballot doesn’t get the required 67% approval…all the way up to FERC review and approval. As long as this whole process takes less than 90 days (which is like saying “As long as Congress can pass a new budget within a week of introduction…”), the implementation date will still be April 1, 2020. And if it takes more than 90 days, the date will be July 1, 2020 – so FERC will have advanced the implementation date by exactly 0 months, 0 weeks and 0 days, and put through a huge amount of grief in the process. Seems like a lot to go through to achieve nothing.

The big one

The biggest thing I’m looking for in FERC’s Order approving CIP-013 – but I’ll admit I’m not at all expecting to find it – is a discussion of what I see as the fundamental problem with CIP-013:

1. R1.1 is really the guts of the standard. It requires the entity to look over all of the supply chain cyber security risks they face and develop a plan to mitigate the most important of those risks.
2. R1.2 lists six particular mitigations that must be included in the plan (each of which corresponds to a particular risk, which isn’t stated but is definitely implied). These are listed because FERC ordered that those six mitigations be included in the standard.
3. While these six mitigations all address important risks, they are far from being the six most important supply chain cyber security risks facing the participants in the Bulk Electric System. It’s easy to find others.
4. One risk that jumped into the news a couple weeks ago (but has always been in the background), was that of compromise of hardware by a nation-state. Of course, I’m referring to the Chinese motherboard compromise reported by Bloomberg.
5. Another important risk not addressed in R1.2 is the risk that software developed by the NERC entity itself will contain vulnerabilities that aren’t patched. CIP-013 R1.2.4 and R1.2.5, along with the much-loved CIP-007 R2, do a very good job of addressing the risk that software developed by a vendor will contain unpatched vulnerabilities – but obviously they are no help when it comes to software developed by the entity itself.
6. A third serious risk, again not addressed in R1.2, was outlined in a sidebar to the October 8 Bloomberg Business Week article on the Chinese attack. The sidebar recounts how “at least two…customers downloaded firmware…meant to update..network cards. The code had been altered, allowing the attackers to secretly take over a server’s communications…” R1.2.5 wouldn’t have addressed this problem, since it just requires that the end user verify that the patch they’ve downloaded actually came from the vendor. If the vendor itself has been compromised, the user is just SOL (which I believe refers to a new designation in the NERC Functional Model).
7. And when you think about it, if the vendor’s network has been compromised (and DHS recently indicated that the Russians compromised lots and lots of vendors to the power industry, although they seem to have some problems distinguishing vendors from utilities and control centers from generating plants. Another post on this problem is coming to a blog near you soon), this leads to an almost infinite number of risks. For example, what if you get a correctly-formatted technical bulletin from your relay vendor, telling you that they need remote access to five relays immediately, to check to see if they have a vulnerability they’ve just discovered – and when you give them that access, they use all of them to open circuit breakers on key transmission lines? After one such incident, you would realize what was going on, but the damage would have been done (especially if they did that to five other large utilities for say 25 other lines).

The moral of this story is that, if the entity just focuses their CIP-013 compliance effort on R1.2, they will be just as susceptible to the risks described above as if they hadn’t complied at all. And yet I have yet to hear anything from NERC, including the Implementation Guidance for CIP-013 itself, that focuses on anything other than R1.2 – or that even mentions the idea of developing an R1.1 plan that carefully considers all important supply chain cyber security risks.[ii]

Of course, the big problem here is that NERC only officially knows how to audit prescriptive requirements. A non-prescriptive, plan-based requirement like R1.1 just falls off the radar screen – when all you have is a hammer, everything looks like a nail.

So I’m hoping that FERC will make some mention in their Order that they want NERC to work with the entities to develop good supply chain cyber security risk management plans that consider all important supply chain threats (and maybe give them a list of threats they should consider). But I ain’t holding my breath. In other words, I think true supply chain cyber security risk management will likely remain an elusive goal for the power industry even after CIP-013 is fully implemented, even though without doubt (at least in my mind) one of the two biggest sets of cyber risks to all industries now are supply chain risks (think Target, NotPetya, etc).[iii]

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; we also work with security product or service vendors that need help articulating their message to the power industry. To discuss this, you can email me at the same address.

---

[i] FERC’s NOPR not only questioned why EACMS weren’t covered by CIP-013, but also Physical Access Control Systems (PACS) and Protected Cyber Assets (PCAs). However, they obviously think the lack of EACMS in CIP-013 poses a much bigger BES risk than does the lack of PACS and PCAs, which is why they raised the idea of ordering they be added immediately.

[ii] I readily admit that the big problem with R1.1 is it doesn’t provide any list of risks that need to be considered for inclusion in the plan, so it’s a lot to expect an overstressed NERC CIP staff at any but one of the largest utilities to do a good job of that for themselves. At one point, I hoped that some group like NATF or the trade associations would produce a list of threats that should be considered (not an enforceable requirement of course, but at least a starting point for most utilities). However, the very disappointing guidance that NATF recently put out led me to honestly wonder whether the author(s) had even read R1.1.

[iii] The other biggest risk is that posed by phishing. Which by the way is another risk not addressed at all by NERC CIP.