Sunday, June 12, 2016

LERCing in the Shadows

At the SPP and WECC meetings I attended recently, one of the biggest concerns was the meaning of LERC (Low impact External Routable Connectivity). I of course don’t have the answer to that question – and neither did the SPP or WECC auditors – but I’d like to at least get all the facts (that I know of) about this question on the table:

  1. FERC ordered NERC to rewrite the definition of LERC in Order 822; they gave NERC until March of 2017 to do this. Rewriting this definition is now the number one concern of the new Order 822 Standards Drafting Team, since this is the only item on their agenda that has a deadline (although they have an aggressive schedule for all of their work, aiming to finish a first draft of the new standards, that addresses everything on their plate, by the end of this year. I’m somewhat skeptical they can do that, but I wish them well!). They want to have the draft of the LERC definition finished in July of this year, since it will of course have to go through (probably) multiple ballots before it can be approved by the NERC Board of Trustees and sent to FERC.
  2. The question of what constitutes LERC is almost identical to the question of what constitutes ERC (External Routable Connectivity). When there is an answer to the question of what LERC is, the question of what constitutes ERC will (with some small modifications) also be answered.  Since the meaning of ERC is probably an even bigger issue than that of LERC, I was at first concerned that the SDT would address LERC (because they have to) but not ERC. However, I asked this question at the NERC CIPC meeting in St. Louis last week and Scott Mix replied that, while the SDT has to address LERC first because of the FERC deadline, they will address ERC as well, as part of their first draft of the revised CIP standards.[i]
  3. Of course, since both LERC and ERC are on the SDT’s agenda, there are now no “right” or “wrong” answers to the question of what these terms mean. However, when the first draft of the LERC definition is posted (and balloted) this summer, NERC entities will at least have something substantive to look over – and, as I pointed out in my post on the WECC meeting linked above, WECC (and perhaps other regions) is recommending that entities look to the SDT’s work as providing at least a good clue about what may be coming.[ii]
  4. The ERC and LERC questions come down to this: When there is routable communication from a control center to an asset such as a transmission substation or generating station, and some sort of intermediate device, located between the external communication source and one or more BES Cyber Assets located at the asset, does something to the communication stream - such as proxying it and/or converting it to a serial protocol - is there still LERC or ERC, or not? More to the point, in what cases does the routable communications get “broken” by the intermediate device, and in what cases can it be said that LERC or ERC still exists, despite whatever the intermediate device does? I have never heard of any other case in which there is a serious question whether there is LERC or ERC, other than when there is such an intermediate device.[iii] Of course, in the case where no device intervenes in the communication stream, there should be no question about whether there is or isn’t ERC or LERC. If the stream is entirely routable, there is LERC. If it isn't routable, there isn't LERC.
  5. The ERC question first came to my attention as being a serious one in late 2014. This post was the first one I wrote on the topic, and it was quickly followed by at least four more. I then returned to the topic the next year, concluding with these three posts: here, here and here.[iv] After the last post, I concluded that ERC (and by implication LERC) is a black hole. With each of my previous posts, I had breathlessly reported something someone said that seemed to me to be the defining word on ERC; inevitably, I would be back a week or two later with the news that the question was more subtle than I’d realized, but a new pronouncement I’d just received was surely the final word. I finally realized that this process would go on forever; there seems to be no end to the subtleties involved in the concept of ERC. So I stopped writing these posts.
  6. In the last of these posts, I concluded that the best way to “define” ERC (and LERC) would be as a series of use cases. Purely as an example, a use case could be: When the intermediate device does A to the data stream (for example, the device requires authentication), ERC/LERC is broken; when it only does B (for example, merely converts routable communications to a serial protocol), ERC/LERC is not broken. That remains my advice to the SDT today: You will never come up with a pure dictionary-style definition. And if you do, it will be technical enough that it will require someone to have an EE and a PhD in data communications to understand it. Of course, this doesn’t bode well for implementing the definition in the real world, since neither the auditors nor the entities would have either the education or inclination to devote the time required to understand the definition so that they could easily apply it. It is much better to have use cases that can be easily applied to particular situations.

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

[i] At the CIPC meeting, I engaged in a little hyperbole when I suggested in my question to Scott that it would take only 15 minutes to convert the LERC definition to a definition of ERC. Dave Revill of Georgia Transmission – who is on the CIP v7 SDT, as he was on the v5 and v6 ones – pointed out that it won’t be quite that simple, since the ERC definition will need to take account of an ESP, which is not a factor for LERC. Of course, that’s correct. It still should be a much easier job to convert the definition than just about anything else on this SDT’s agenda!

[ii] On the other hand, a draft standard or definition is certainly not mandatory in any way. If you have a good reason for disagreeing with the draft definition of LERC, and you can’t wait until the definition is finalized early next year because you need to start your Low impact work now, you should go ahead and document your definition, as well as the reasoning that led to it. Even if the definition that is ultimately approved by FERC differs from yours, there is no way, in my opinion, that you could ever be held in violation – even four or five years from now – because the final definition wasn’t available when you needed it. You can’t simply put your compliance effort on hold for this.

[iii] And please don’t think that, when I say “intermediate device”, I’m in any way referring to the NERC defined term “Intermediate System” (which is a term that only applies in High or Medium impact environments, of course).  A device that functioned like an IS could in some cases be what I’m calling an intermediate system, but they aren’t equivalent concepts. Mine is much more general: it just means some device that sits in the communication path and makes some sort of change to the communications. That’s all.

[iv] I believe there were at least one or two posts in between these two groups of posts, but who has time to go through all those posts, anyway? The author of this blog obviously loves to talk!

No comments:

Post a Comment