Thursday, February 14, 2013

Is CIP Version 5 "Un-Auditable"?

All opinions expressed herein are mine, not necessarily those of Honeywell International, Inc.

NESCO recently posted a paper written by Stephen Flanagan of FERC entitled “Self‐Correcting Cyber Policies: Pathway to Convergence of Compliance and Security?”  Stephen’s primary point is this: NERC CIP Version 5 contains a number of requirements that would be impossible to audit.  He is presumably recommending that the FERC commissioners either reject CIP Version 5 entirely or require NERC to make substantial changes.

Stephen is a wonderful writer, but his prose is quite dense – he never uses five sentences when one well-crafted sentence will do (I have a vision of him toiling over each sentence like a jeweler over a diamond ring).  So I’ll warn you: you’ll need a couple readings to understand this well.  I won’t even pretend to follow everything he says, but here is a statement of at least the problem he addresses:

The language he objects to is used in seventeen requirements in CIP Version 5.  It reads “Each Responsible Entity…shall implement, in a manner that identifies, assesses, and corrects deficiencies…” (followed by one or more programs or policies for whatever the requirement addresses).  This is one of the big innovations in Version 5: the idea that, for these 17 requirements, the entity doesn’t have to report every single mistake they make (for example, not getting senior manager approval by exactly the date it is required), but rather has to have a program or policy to identify all shortfalls and correct whatever caused them to happen.  This has been much touted in the SDT’s webinars and written discussions of V5.[i]

I’ll let you read his arguments, but one of his main points is very clear: He doesn’t see how these seventeen requirements can be audited.  Is he right?  I have no idea.  Will the FERC Commissioners agree with him when they weigh all of their staff’s comments on Version 5?  Only God knows. 

Stephen doesn’t think this “identify, assess and correct” approach is a bad idea, though.  He does say it would be a good way to extend NERC oversight into areas not currently addressed by the CIP standards.  In other words, this would be the right approach for NERC to start addressing areas like application security that are simply not addressed by CIP now.  However, he clearly believes that the security domains currently included in CIP are much better addressed in the “traditional” manner of CIP Versions 1-4.[ii]

So what’s the point of this post, given that I admit I don’t know whether the Commissioners will listen to Stephen or not?  It is that this is a very clear and substantial objection to CIP Version 5, by a senior FERC staff member.  To think – as many seem to, including many at NERC - that the FERC commissioners will simply ignore this objection (and others raised by other FERC staff members) and quickly approve V5 is to engage in very wishful thinking (See my other post from today about another big issue with V5).  What is the moral of our story?  Don’t expect V5 approval anytime soon, as NERC is clearly hoping for in the filing for V5).  If you haven’t started already, move at full speed toward full compliance with CIP Version 4 (which is already approved by FERC) on April 1, 2014.

Extra Credit Section
This next part is speculative, but I’d like to ask, “What will FERC do if the Commissioners agree with Stephen?”  I see two possibilities:

  1. They’ll conditionally approve Version 5, but also send it back to NERC and require changes in a short time, such as 90 days (I think they’ll require other changes as well – see this post).
  2. They’ll simply disapprove V5 and the whole standards development process will have to start again.
 The first possibility is much preferable, from NERC’s point of view.  Of course, it will be a stretch to make all the changes that will be required (and hopefully get them approved by the membership, although if need be the NERC Board of Trustees will be able to submit a revised CIP V5 to FERC without membership approval.  See Section 321 paragraph 5 of the NERC Rules of Procedure).  But the NERC staff is used to working hard.

The second possibility is a lot less desirable, (again, from NERC’s point of view).  My reason for saying so is that I don’t think FERC is going to give NERC much discretion if it tells them to start over.  FERC is likely to simply dictate the standards it wants.  I really don’t think FERC has the stomach to wait while NERC develops the SAR, forms a new SDT, drafts the standards, goes through 3 or 4 ballots (as with V5), etc.   That will take 3-4 years, and FERC wants something much sooner than that (plus assurance that what comes out of the process will be something it likes).

FERC has authority to dictate the new standards to NERC, and stated so in paragraph 417 of Order 672 (which established the rules for their dealings with NERC).  And they certainly have the capability to write their own CIP standards.  Last fall, they formed their Office of Energy Infrastructure Security, which in my opinion is waiting in the wings for exactly this situation. I know the office is staffed by some very good and very experienced electric sector cyber security professionals.

To summarize, do I want FERC to change Version 5 in the way implied by Stephen’s paper?  Certainly not – I agree with NERC that the “identify, assess and correct” approach in V5 is a much better way to write cyber security standards.  But the only people whose opinions matter are the five FERC commissioners.  And they’re not going to be rushed to a decision by NERC’s desire to have one quickly.

[i] NERC justifies this approach on pages 31-34 of the Version 5 filing, already linked above.
[ii] I do want to note that these seventeen requirements were only changed to reflect the new approach after the July 2012 SDT meeting in Minneapolis.  Before that, they were like the current CIP requirements, where every lapse is a new violation.  You can see this by looking at the first and second drafts of CIP Version 5, which were written before July.

No comments:

Post a Comment