NERC, FERC, LERC, ERC

My most recent post dealt (in part) with Felek Abbas’ response to the question whether a “jungle mux” should have an ESP around it. The day after I posted it, I realized there was an error in my footnote, which read “Of course, this isn’t to say that the serial devices that connect to the mux don’t have external routable connectivity; they still do, since the external routable communications stream crosses the asset boundary. If the mux controls electronic access, as does the device in Reference Model 5, then no further measures should be required for the entity to comply with the Low impact electronic access control requirement part in CIP-003 R2. If it doesn’t, then some further step will be needed, like a firewall or data diode.”

I replaced the footnote with the one quoted below, but the email feed had already gone out to the 500+ feed subscribers (whose names I can never see, in case you wondered). I thought it would be interesting to see how many of them caught the error, so I didn’t otherwise acknowledge it. I waited and waited and…guess what? Nobody seems to have caught the error. This means one of two things:

1.       None of my readers realize that a device that can be in an ESP is Medium or High impact, not Low (and therefore what I wrote in the footnote about ERC crossing the asset boundary and Reference Model 5 is irrelevant, since these concepts only apply to Lows); or

2.       Nobody reads my footnotes.

Since I know that I have a lot of readers who would spot this error very quickly if they read it, I have to conclude that number 2 is the case. That’s OK – I’m not complaining because nobody reads footnotes. It just means I need to avoid putting important information in footnotes (and I’ve already started doing that. I used to have posts with 8-10 footnotes, but lately I’ve hardly ever gone above two. I’ll try to bring that down to zero).

So here is the new footnote that I inserted in place of the erroneous one. I’m making all of this into a separate post because a lot of people have kind of forgotten the difference between LERC and ERC, and – while a lot of people know that “LERC” has been retired and the definition is now built into the requirement part in CIP-003-7 R2 – probably most (including me) have forgotten what the issues are with ERC, and where things stand in fixing that definition.

“Of course, this isn’t to say that the serial devices that connect to the mux don’t have external routable connectivity. Whether they do or don’t depends on what happens at the jungle mux. The definition of ERC is “The ability to access a BES Cyber System from a Cyber Asset that is outside of its associated Electronic Security Perimeter via a bi-directional routable protocol connection.” If all the jungle mux does is convert the routable communications stream to serial and send it to the proper device, then there is ERC. If the mux performs some sort of authentication, then this probably removes that ability, and there is no ERC.

“However, I’ll admit this is still an ambiguous area, and that points to an interesting irony. That is because FERC’s qualms about the ERC definition (discussed above in this post) led to a change; but the change was in the LERC definition, not ERC. When FERC ordered NERC to clarify the meaning of “Direct” in the LERC definition – in Order 822 approving CIP v6 in January 2016 – they weren’t reacting to problems with LERC since it wasn’t in effect yet. They were really responding to the discussions about ERC in 2014 and 2015 that I described above (I linked above to just one of the posts I wrote on this issue. Others include this one, this one, and this one (in the order I wrote them). I believe FERC was especially concerned about the idea that mere protocol conversion “breaks” ERC.

“If you want to plow through these three posts, you will see that, by the third one, I had concluded (in conjunction with Morgan King, a WECC auditor who has weighed in a lot on technical issues like this) that mere protocol conversion didn’t break ERC, but requiring re-authentication would. I thought when I wrote the third post that this was the last word on the subject. However, in this post, which was written a few days after the third one, I reported that another auditor said this wasn’t enough to break ERC – that there had to also be ‘reformulation of the user’s commands and the acting as a proxy for the user’.

“At this point, I threw up my hands and decided ERC was a black hole – I could write 100 posts and never get to the bottom of the problem, which was that the definition needs to be rewritten. This is one of the tasks on the CIP Modifications SDT’s agenda. I think they should build on the very good work they did with the LERC issue last year and base their new definition of ERC on use cases similar to the Reference Models they developed for CIP-003-7 (although some of those models won’t apply because the new Section 3.1 “defines” what used to be LERC in terms of the asset’s boundary, in order to avoid requiring a list of BCS at Lows). I think any attempt to write a dictionary-style definition will fail. They just need to say ‘In these particular cases, there is ERC. In these particular cases, there isn’t ERC.’”

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