Wednesday, September 26, 2018

When will FERC approve CIP-013?

I must admit that I expected FERC to approve CIP-013 by now. I thought it was close to certain that they would approve it in September, since a) NERC turned it in for their approval at the end of September 2017, and b) September was the last month they could approve CIP-013 in time for it to come into effect on April Fool’s Day 2020. Now the compliance date will be July 1, 2020, unless FERC doesn’t approve CIP-013 until after Q4 – in which case the date will be October 1, 2020.

The next possible date for FERC to approve CIP-013-1 is at their monthly Sunshine Meeting the third Thursday of October. FERC issued their Notice of Proposed Rulemaking (NOPR), which said they intend to approve CIP-013-1, in January. This means it will be at least nine months between the NOPR and the Order approving the standard.

This is definitely on the long side, although not unprecedented. FERC issued their NOPR saying they would approve CIP version 5 in April 2013 and they approved it in Order 791 on November 22, 2013[i], which is seven months. CIP v5 was a complete rewrite of all of CIP, including adding two new standards. While CIP-013-1 is a very different kind of standard from any of the currently enforced CIP standards and therefore requires a lot of scrutiny, it would be hard to argue that it needs as much as did CIP v5. In any case, this is why I don’t think FERC will continue their pondering beyond Q4, so I believe it is likely the compliance date will be 7/1/2020.

What’s ironic about this is that FERC, in their Order 829 mandating that NERC develop a supply chain security standard, gave NERC only a year to a) write a Standards Authorization Request and get it approved by the ballot body; b) form a drafting team and set them to work developing the first draft; c) submit the first draft to the ballot body and have it roundly voted down (I believe it received nine percent positive ballots - not exactly good enough, given that 68% is required for approval); d) redraft and re-submit the standard (which the drafting team had to do three times); e) have it approved at the next quarterly NERC Board of Trustees meeting after final approval by the ballot body; f) have the lawyers put on their final touches; then finally g) submit the standard to FERC for them to approve.

The amazing thing is that NERC was able to do all of this and still meet the one-year deadline. And guess what happened? FERC will now have taken at least 13 months to approve CIP-013, and maybe more than that. Hurry up and wait, it seems.

I do need to point out that there is only one FERC Commissioner still in office from when Order 829 was issued. And that Commissioner, Cheryl LaFleur, actually dissented from the Order because she thought that FERC should give NERC more time (to read her elegant six-page dissent, go to page 67 of the PDF of the Order).

I totally agreed with her position in my post on the Order. Now I am even more sure that she was right, for this reason: While I think that CIP-013 is very well-written, and is the closest approach yet to how I would rewrite all of CIP if given the chance, it suffers from the near-fatal flaw of being fundamentally un-auditable under NERC’s current prescriptive compliance enforcement process. I have discussed that problem in a number of different posts already, most recently here. Since the problem of making plan-based requirements (which is what the requirements of CIP-013 are) auditable by NERC had already been solved by the CIP v6 drafting team when they drafted CIP-010 R4 (as I explained in the post just linked), I think the CIP-013 drafting team would probably have discovered the same solution if they had had more time to develop the standard. As it is, they had a million fires to deal with just to get CIP-013 passed, and perfection wasn’t something they could afford to aim for.[ii]

In the NOPR, Commissioner LaFleur clearly identified this problem. She issued a statement with the NOPR that included this passage: ““The proposed standards would provide significant flexibility to registered entities to determine how best to comply with their requirements. In my view, that flexibility presents both potential risks and benefits. It could allow effective, adaptable approaches to flourish, or allow compliance plans that meet the letter of the standards but do not effectively address supply chain threats. I hope that we will see more of the former, but I believe the Commission, NERC, and the Regional Entities should closely monitor implementation if the standards are ultimately approved” (my emphasis). In my opinion, this is exactly the big problem with CIP-013.

However, this problem isn’t insurmountable. The NERC Regions aren’t constrained to pass every CIP-013 supply chain cyber security risk management plan handed to them, simply because it has the correct title at the top. Even in the strictest auditing regime, an auditor would be allowed to use necessary judgment to determine what constitutes a “good” plan.

So I guess the real problem is not that CIP-013 is un-auditable, but that the auditors will be free to use lots of discretion in auditing, with one auditor stamping a plan as acceptable that another auditor – perhaps within the same Region – would deem unacceptable. This can be avoided if there is a serious effort to develop guidance that describes what should be in a good plan (this might be developed by NERC or by a third party. Unfortunately, neither the CIP-013 Implementation Guidance document prepared by the standards drafting team, nor the recent document put out by the North American Transmission Forum, provides any serious guidance on how to put together a good CIP-013 plan).

Of course, such guidance can’t be considered binding either on the auditor or on the entity being audited, but at least it would provide an indication of the level of performance that should be deemed acceptable; the entity wouldn’t have to follow the guidance exactly, but if they turned in a very minimalist plan, they would need to be able to convince the auditor that it provided roughly the same level of protection as does the plan described in the (as yet unwritten) guidance.

CIP-002-5.1a R1 provides a good illustration of what I mean by this. Perhaps the biggest ambiguity in complying with this requirement (and that’s saying a lot) is that the definition of BES Cyber Asset uses the phrase “impact on the Bulk Electric System” without any further description of what that means. Yet an entity needs to have some idea of what BES impact means, in order for them to have any confidence that they have identified their BES Cyber Systems properly in complying with R1. This is because almost any device that uses electricity – my electric toothbrush, for example – could be considered to have some miniscule impact on the BES.

The Guidance and Technical Basis attached to the standard describes the BES Reliability Operating Services. The BROS were an official part of the CIP-002 R1 compliance process in the first draft of CIP v5 (which was soundly voted down in December 2011), since they formed part of the BES Cyber Asset definition itself – a BCA was defined then as a Cyber Asset that fulfilled a BROS. However, the drafting team, when they met to pick through the wreckage of the first draft at ERCOT’s headquarters in January 2012, decided that the BROS weren’t really an auditable concept – so they moved them into the Guidance and Technical Basis. But the important thing is that they didn't throw out the BROS altogether.

To be honest, I didn't think NERC entities would pay much attention to the BROS after this (since it was no longer mandatory to consider them), but I’ve been pleasantly surprised to see that a number of NERC entities still consider whether a Cyber Asset fulfills one or more BROS, as they decide whether or not it’s a BES Cyber Asset. So, while an entity isn’t required to identify any system that fulfills a BROS as a BCS, and while an auditor isn’t allowed to require the entity to perform the BROS analysis in identifying their BCA/BCS, in fact there has been a tacit agreement among entities and auditors that they will do exactly this.

So it’s good news that there is this tacit agreement regarding identifying BCA/BCS using the BROS, but at the same time it’s bad news that the BCA definition is so open-ended that unwritten and unspoken agreement is required to make audits something more than pin-the-tail-on-the-donkey exercises. By the same token, it’s bad news that CIP-013 R1.1 provides close to no guidance on what should be in the entity’s supply chain cyber security risk management plan, but it will be good news if there can be some tacit agreement between entities and auditors that a certain yet unwritten guidance document provides a good description of what should be included in a good plan.

Ya gotta count your blessings where you can find them, I guess.

Please note that the free CIP-013 webinar workshop offer I made this summer is still good! Just drop me an email and we can set up a time to discuss this by phone.

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

[i] Fifty years almost to the hour after the assassination of President Kennedy in 1963. Coincidence, you say? I don’t know…
[ii] And I will admit that, while I did attend some of the on-site and phone-based drafting team meetings, it never occurred to me that this flaw was present, or that CIP-010 R4 exemplified a solution. This realization only came to me this year, as I’ve been working on a book about CIP’s problems and how they can be fixed. Had I realized this, I would certainly have brought it up to the drafting team, although they simply didn’t have the time to deal with it then.

No comments:

Post a Comment