I attended the NERC CIPC meeting in Atlanta this week, and it was one of the best I’ve attended. I was looking forward to it as a way to get clarification – both through official pronouncements and unofficial conversations – on some of the questions that remain about FERC Order 791. I can say without hesitation that some questions were clarified – while at least one very important question remains unanswered.
This post is an update to my previous close-to-book-length post on Order 791 itself. I recommend you read that (although it may require a can or two of Red Bull to get through it), but it won’t be included in the quiz at the end.
What Happens Now?
FERC ordered NERC to do five important things in Order 791:
- Remove the “Identify, Assess and Correct” language from 17 requirements in CIP Version 5;
- Develop standard(s) for communications networks;
- Conduct a survey to determine the impact of possibly removing the “within 15 minutes” language from the definition of BES Cyber Asset;
- Require specific controls for Low impact assets; and
- Develop separate requirements for “transient” devices.
The first three items have a specific due date: one year from the effective date of CIP Version 5. Since we now know that date will be February 3, 2014, this means these items are due on February 3, 2015 (I don’t know whether there’s any significance to the fact that this is the day after Groundhog Day. With all the different CIP versions coming and going, NERC and FERC staff members may have felt they were in that movie).
However, the fourth and fifth items don’t have any due date attached to them. I at first thought this was a pure mistake (although I didn’t notice it until a couple people pointed this out to me), but that doesn’t seem to be the case. It seems FERC knows these two items may take longer than the other two, so they’re allowing NERC a little more time if needed (I personally don’t think item 2 is going to be any piece of cake, either. But it has its deadline all set in stone now).
How does NERC address these five directives? Through the standards development process, of course (although this doesn’t apply to the survey. NERC staff members will conduct that). Here is some information on what will happen:
- I had wondered if the CSO706 SDT – which developed CIP versions 2 through 5 – would be called back one last time, but the answer is no; a new SDT will be constituted (and I hereby guess it may be called the CSO791 SDT. Remember, you heard it here first). This isn’t too surprising since many of the CSO706 team are no longer available to serve, and those that are probably feel that toiling four years in the vineyards of CIP standards development is enough punishment to expiate whatever sins led them to be selected in the first place.
- I didn’t quite catch what was said, but it seems there’s a NERC direction now to shrink the size of SDT’s. The new SDT will have between six and ten members (as opposed to around 15-18 on the old one).
- Most importantly, it is possible there will be two SDT’s, not one, since meeting these directives (especially 2, 4 and 5) will require a huge effort. It would make sense to have two teams – one to address the two items with the one-year deadline, the other for items 4 and 5, which don’t have a fixed deadline.
- However, Scott Mix made it clear that NERC really wants to have all four standards drafting efforts done in a year, so they can present them all in a nice package for FERC (in fact, he really said he hoped they could be done by the end of next summer. I think this isn’t realistic). I really can’t see this happening without two SDT’s (given that more than half the year will be taken up by getting the drafting team in place, balloting, legal review, BoT approval, etc. Remember, we’re talking about developing what will probably be three new standards[i], plus doing major surgery – removing IAC – on 5 or 6 of the other standards in CIP V5). NERC will soon be soliciting nominations for the SDT members.
FERC really ordered two things regarding communications. The first was the new standard(s) for “non-programmable aspects of communications networks”. Does this strike you as odd? Why would they focus on the “non-programmable” parts – i.e. the physical hardware and cabling? That’s because the programmable parts – i.e. the switches, routers, etc. that are subject to cyber attacks – are already covered by CIP. FERC is really asking for a physical network protection standard here.
Consider how this directive came about. In the NOPR, FERC expressed surprise that NERC had taken “communications networks” out of the definition of Cyber Asset, when it had been in that definition up until that point. They pointed out that Paragraph 215 of the 2005 Federal Power Act (which set the whole FERC/NERC regulatory apparatus in motion, for better or worse) implies that communications networks pose as much of a risk as the cyber assets themselves. They sounded like they might require NERC to develop standards for securing these networks (although I honestly didn’t think they would).
While the comments FERC received on the NOPR were mostly against requiring standards for communications networks, FERC obviously wasn’t persuaded they shouldn’t do this. Accordingly, NERC has a year to develop these requirements (I presume they will cover things like conduit for cabling, appropriate shielding, etc).
So now the physical network infrastructure is being protected, along with the network devices (which have been protected since CIP Version 1). What’s left? How about the data being transferred on those networks? What about protecting it? Of course, if we’re talking about protecting data, we’re often talking about encryption.
FERC also addressed that question in their NOPR, and has re-addressed it in order 791, in the “Other Technical Issues” section starting with paragraph 211. While they don’t require that NERC develop requirements for protecting “data in motion”, this is one of three topics that will be addressed in a technical conference that FERC staff will organize within the next 180 days
What new was said about this at the CIPC meeting? I was quite surprised to hear Scott Mix say that we “shouldn’t be surprised” if, after the conference, FERC orders a new standard be developed to protect data in motion; this is worth noting. This conference should be quite interesting, with probably a lot of heated – but principled - discussion on both sides. I suggest that FERC invite members of Congress, since it’s been a long time since they had a principled debate, as opposed to a recitation of media talking points. But in any case, I hope they get a big room for it.
There has been some speculation on LinkedIn recently that FERC really wants NERC to develop requirements applicable to individual Low impact BES Cyber Systems[ii] - which would then also require an inventory of all Low impact cyber assets. The speakers from NERC at the CIPC were unanimous that a) FERC isn’t requiring this (and I agree with that statement, as discussed in my post on Order 791) and b) the Low impact requirements NERC develops will not apply to specific cyber assets.
What will be the Low requirements? You can look at my 791 post for a discussion of that. You can also plan on attending the new SDT meetings, or perhaps even joining the team if you’re employed by a NERC asset owner. Scott Mix said NERC will make sure the SDT meetings are held in rooms large enough to handle a big crowd of observers (and of course they will be webcast).
One note about the compliance date for the new Low requirements (which I think will be contained in a separate standard, perhaps called CIP-012-1): several people have asked me whether compliance with these new requirements will be due on the date that the Lows need to comply with CIP-003-5 R2 (the one requirement in the current Version 5 that applies to Lows), namely April 1, 2017.
The answer to that question is almost surely no. The new standard(s) that NERC presents to FERC for Lows (as well as the new standards for protecting communications networks and transient devices) will almost surely have separate implementation timelines. I’m fairly sure Lows will have three years to implement whatever requirements are decided on, starting from the date of FERC approval (which I’m guessing will be mid-2015). FERC has already conceded that is a good timeline for Lows (the rationale being that few if any Low impact assets were Critical Assets under CIP v1-3, so they will all be starting from scratch in implementing whatever is required).
Regarding the transition to CIP Version 5, there was unanimous agreement from the NERC speakers that this needs to be a real transition – nobody is going to be able to remain completely CIP Version 3 compliant up until midnight on March 31, 2016, then be V5 compliant a second later. I expect there will be a lot of guidance published on how this can be effected. And I’m sure FERC agrees with this.
Regarding FERC’s directive to remove “Identify, Assess and Correct” language from 17 requirements in V5, NERC seems to have no appetite for challenging that directive by providing alternative language that would meet their objections. The reason for this is pretty simple: there is no language NERC could propose for CIP V5 that would meet FERC’s objections. FERC is objecting to the very idea of trying to implement an internal controls-based compliance approach in the standards themselves. Rather, they make it clear that NERC’s Reliability Assurance Initiative is probably the right way to do this. So expect NERC to keep pursuing that approach.[iii]
Being who I am, I asked the question that I think is as important as any other regarding CIP Version 5: Will the new SDT be addressing the many serious wording problems in CIP-002-5, which I believe can ultimately result in the standards being invalidated by a court? And guess what? Steve Noess (the NERC staff member who directed the last two years of the V5 development effort) gave a long answer – which I confirmed with him meant “No”.
I can’t say I was surprised by this. The new SDT will have a big job on its hands just complying with FERC’s Order 791 directives; it would be a huge effort to add this can of worms to the mix. Of course, if FERC had actually made fixing this problem one of their directives, there would be no question that NERC needed to address it. But they didn’t, and the SDT won’t address this.
Those of you who have been reading this blog for a while (and if you haven’t, the posts are all out there to read) know that I have been pursuing the wording problems in CIP-002-5 with all the gusto of Captain Ahab pursuing Moby Dick. I’m sure I’ve written well over 100 pages on the subject, and I’m not done, because I keep finding new problems. I would like to put out an uber post summarizing all of these problems, but I can’t do that until I’ve reached the bottom. It’s like trying to dig a new building foundation in Rome: with every few feet of digging, you come on a new set of ancient ruins you have to excavate.
Comparing myself to Ahab isn’t entirely facetious; I’m sure there are some that consider this a similar case of monomania (although hopefully not one that will result in my death and those of my colleagues, as in the case of Ahab). All I can say to them is that I simply don’t see how CIP Version 5 can be a success – or ultimately survive as regulatory law – when perfectly rational people (entities and auditors) can come up with completely opposite conclusions on a number of aspects of the asset identification process (which of course is what is addressed in CIP-002-5). And if the asset identification process isn’t clear and agreed on, nothing else in CIP V5 will be clear and agreed on either.
In replying to my questions at the CIPC meeting, Scott Mix said something that I’m sure he now regrets, since he is a very intelligent person. He tried to make the diversity of possible interpretations of CIP-002-5 into a virtue, saying that one of the goals of the CIP process is not to have requirements that rigidly dictate one way of complying with them.
I agree this is a worthwhile goal. However, it assumes that the meaning of the requirements is clear. It is precisely the fact that there can be no univocal interpretation of CIP-002-5 R1 (i.e. there can be no interpretation that isn’t contradicted by some of the wording in that requirement or in Attachment 1, which is called by R1) that is the problem here. And the fact that this is the asset identification requirement – rather than one of the control requirements, such as CIP-007-5 R1 for Ports and Services – means that this ambiguity threatens the entire CIP V5 structure.
I will say that, with the help of a couple readers, I have identified at least one very clear contradiction in CIP-002-5, whose interpretation one way or the other will mean a big discrepancy in the number of BES Cyber Systems some entities will identify; I will describe it in one of my next few posts. I know that one of the readers is already planning on using the narrower interpretation as justification for greatly minimizing their CIP V5 compliance footprint. And who can blame them? Will NERC and FERC automatically accept the fact that this entity will have far fewer BES Cyber Systems than an entity that took the other interpretation? No harm, no foul? I tend to doubt it.[iv]
All opinions expressed herein are mine, not necessarily those of Honeywell International, Inc.
[i] I’m guessing that the requirements for Low impact assets, transient devices, and communications networks will be in separate new CIP standards, perhaps called CIP-012 through CIP-014.
[ii] I regard the phrase “Low impact BCS” as an oxymoron, like “Jewish Pope” or “British cuisine”. Of course, CIP-002-5 specifically refers in one or two places to Low impact BCS – and this has led some people to conclude that an inventory of Lows is required. Otherwise, how could you distinguish your Low impact BCS from other cyber assets at Low facilities? And those people are absolutely right, of course. This is just another example of the serious wording problems in CIP-002-5.
[iii] There was a lot of discussion of RAI at the CIPC meeting, and this is really moving ahead at NERC. I can fairly confidently predict that, by the time CIP V5 compliance comes due on April 1, 2016, RAI will be in place in all NERC regions. This means that entities will essentially get the benefits of IAC – perhaps more – when they have to comply with V5. In addition, they’ll get those same benefits for all of the other NERC standards as well, since RAI will apply to all of them, not just the CIP family.
I was very surprised to find, when I attended MRO’s compliance workshop in St. Paul, MN two weeks ago, that MRO has essentially already implemented RAI for their whole footprint. They have already conducted a successful test with one entity, and are now rolling it out to everyone else. They didn’t exactly stand up and announce this fact, but once I heard about the new procedure changes they were implementing, it became quite clear this is what they are doing (they appear to be phasing it in, so that the difference is not huge for an MRO entity being audited today). I would like to write a whole post on RAI and the death of IAC (I even thought of a catchy title: “IAC, RAI…Is NERC SOL?”), but I’m afraid that isn’t at the top of the queue.
[iv] Part of the answer to my question at the CIPC was that NERC’s transition guidance, which will be updated based on the experiences of the six (no longer seven, for some reason) entities that are participating in the V5 transition pilot, will provide some sort of guidance on whatever methodologies these entities have come up with for asset identification.
Let me be clear: I have absolutely no doubt that entities can come up with a methodology for CIP V5 asset identification (one NERC CIP manager for a large generation entity told me, “I’m an engineer. Figuring out a way to make things work is what I do”). I could, too. In fact, I could come up with 5-10 pretty good methodologies, all different but all supported by some of the wording of CIP-002-5 (I may do that in a future post). But how do you know which is the right one?
And don’t tell me that NERC’s transition guidance – or any other guidance document they may write – is the way to deal with this problem. None of these documents has the legal standing of the wording of the standards themselves. The only way there can be a clear interpretation of a standard is through the Request for Interpretation process, in which an entity requests an interpretation, NERC provides it, and FERC ratifies it (or doesn’t, as was the case with two NERC Interpretations earlier this year). This process takes at least two years, so even if an RFI were filed on Feb. 3 (when Order 791 comes into effect), this isn't exactly going to provide a lot of help to entities as they struggle to comply now with V5. More importantly, an interpretation is over a narrow question on the meaning of wording. Given the problems with the wording in CIP-002-5, and the fact that they're very intertwined, I don't think 10 or 15 interpretations could clear up that standard; it needs to be rewritten, and there's still opportunity to do it with the new SDT(s).
I’m guessing that, if CIP-002-5 isn’t changed, the way this problem will be finally dealt with (not solved) is through the Regional Entities taking it upon themselves to develop their own interpretations. These won’t have any more force than a NERC interpretation, but since the RE’s are the ones who do the auditing, it is far more likely the registered entities will follow the lead of their region. However, were a registered entity to take this to court, the regional interpretations would still have no legal force. And, given the discrepancies I see in the number of BES Cyber Systems identified with different interpretations, it isn't at all likely that NERC entities will choose one interpretation - sanctioned by their RE - over another one that might literally save them millions of dollars in compliance costs.
Regardless of all this, it is clear (to me anyway) that, if the wording in CIP-002-5 isn’t corrected while there is still time to do so, it will be finally "corrected" at huge cost through Potential Violations, fines, recrimination, lawsuits, etc. Sounds like a great way to deal with the problem to me.