In Part II of my recent series of posts on FERC’s NOPR from July, I discussed at some length the section of the NOPR (pages 43 and 44) that deals with Low impact External Routable Connectivity – or LERC. To summarize what I said:
1. FERC doesn’t have a problem with NERC’s definition of LERC: “Direct user-initiated interactive access or a direct device-to-device connection to a low impact BES Cyber System(s) from a Cyber Asset outside the asset containing those low impact BES Cyber System(s) via a bidirectional routable protocol connection.”
2. However, they do have a problem with how NERC is interpreting the word “Direct”. FERC states on page 44 that “We seek comment on the implementation of the ‘layer 7 application layer break’ contained in certain reference diagrams in the Guidelines and Technical Basis section of proposed Reliability Standard CIP-003-6.”
3. A footnote at the end of this phrase points to Reference Model 6 on page 36 of CIP-003-6, in which it is stated that there is no LERC because “There is a Layer 7 application layer break or the Cyber Asset requires authentication and then establishes a new connection to the Low impact BES Cyber System.” FERC clearly doesn’t understand what an “application layer break” is, and how it results in the external routable connectivity no longer being “direct” – i.e. it has been “broken”.
4. FERC states that, depending on the comments received, they may require a revised definition of LERC, presumably to make clear that, whatever an “application layer break” is, it shouldn’t be seen as breaking the “direct” routable connection.[i]
5. In the above-linked post, I didn’t comment directly on FERC’s issue, because I saw another one that overrides it, which is specific to the Low impact environment: NERC has of course taken great pains to emphasize at every turn of the road that an inventory of Low impact cyber assets isn’t required for compliance with any of the requirements. In order to do this, of course, they need to write the requirements so that they can be audited simply on an asset-level basis, not by requiring the auditors to look at individual cyber assets. If auditors do have to look at individual cyber assets, it’s almost inevitable that a complete cyber asset inventory will end up being an “implied” requirement for Lows.[ii]
6. Unfortunately, it appears to me that the CIP v6 SDT went too far when they tried to point out a condition under which, even though there would be external routable connectivity coming into a Low asset, this ERC would be “broken”. And it doesn’t really matter what that condition is: it could be an application layer break, it could be a cyber asset requiring new authentication, it could be that cyber assets painted blue are considered to break the ERC, etc. In my opinion, any condition that NERC might point to as leading to a break in direct ERC will have to be on the cyber asset level, since it is only on that level that such a break would be possible. Ergo, creating such a condition will inevitably require some inspection of individual cyber assets – and therefore lead to the implicit requirement that all Low cyber assets be inventoried, at least at any Low asset for which it is claimed that an external routable connection is “broken” by some condition or other.
7. In the post, I therefore suggested that NERC give up the idea that LERC could be “broken”. I suggested they simply state that a Low impact asset that has any external routable connection (except for the exceptions listed in the last sentence of the LERC definition, such as IEC 61850 GOOSE) has LERC, period.
8. However, in taking this tack I was in a sense evading the question whether FERC’s unhappiness with the idea of an “application layer break” was justified. For Lows, this is no longer an issue as far as I’m concerned, since I think trying to state any condition for breaking LERC is tantamount to requiring an inventory of Low impact cyber assets (and might also require designating an ESP).
But how about for Highs and Mediums? Does FERC’s concern shed any light on the questions regarding the definition of External Routable Connectivity (which of course only applies to High and Medium assets or Facilities)? The caveat I described in items 6 and 7 above doesn’t apply to Highs and Mediums, since there is no question that a cyber asset inventory is required for them.
Nevertheless, it really seems to me that FERC’s objection does apply to the ERC discussion. I have been spending a lot of time on the question of the meaning of ERC recently, as evidenced in this blog post and this webinar recording. The one thing I have been quite sure about is that “application layer break” is a valid concept, and that it does “break” ERC.
As described in the blog post just referenced, I came to this idea originally after seeing Morgan King of WECC do a presentation on this at WECC’s winter CIP User Group meeting. Morgan didn’t use the same term for this; instead, he called it a “protocol break”. But he did at least try to flesh out what “protocol break” means[iii]; in the CIP-003-6 Guidance and Technical Basis (where the infamous Reference Model 6 is found), there is no elaboration of what the phrase means.
I know NERC is working on guidance on the meaning of ERC. Had I been asked to help them on this before the NOPR came out, I would have reiterated what I said in my ERC post (and the June webinar I did with EnergySec): a protocol layer break (roughly, terminating a routable session and initiating a serial session, using the normal example of a substation RTU connected routably to a control center, with a relay connected serially to it) does constitute a “break” in ERC. But now I have to change my opinion on this. FERC clearly doesn’t think that anything short of requiring re-authentication constitutes a break in ERC.[iv] I suggest NERC consider following suit.[v]
However, you may ask, “Why does it matter what FERC thinks at this point? ERC was one of the definitions developed for CIP v5, and FERC didn’t state they had any problems with it when they approved all of the v5 definitions in Order 791.” This is true, but their problem with LERC isn’t with the definition itself, but how it is being interpreted; my guess is they feel the same way about ERC – namely, that any interpretation that says a “protocol break” terminates ERC is wrong.
Nevertheless, it is true that FERC can’t directly affect how NERC interprets a requirement or a definition once it has been approved (were a NERC entity to submit a Request for Interpretation on this issue, then FERC could weigh in. Other than that, they don’t have any venue for doing so). However, I’m not sure it’s a good idea for NERC, at this point, to go against a principle that has been clearly enunciated by FERC. Even if NERC (i.e. the CIP v5 Transition Advisory Group, which I believe is working on this issue) wants to endorse the idea of a protocol break, I’m not at all sure they should move forward with that idea.
It’s especially not a good idea to go against FERC if, come October or whenever FERC issues their Order addressing the issues in the NOPR, they order NERC to change the LERC definition to make clear that nothing short of requiring re-authentication will “break” it. Even though that wouldn’t have any direct impact on ERC, I don’t see any real difference between the LERC and ERC situations; if FERC doesn’t like the protocol break concept in the former case, they clearly don’t like it in the latter case either. It just wouldn’t be a wonderful idea for NERC to ignore their opinion on this matter.
So I’ve changed my mind on how ERC should be interpreted – not because of some technical argument but simply because I think it is bad politics not to do so.
The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte Advisory.
[i] The “application layer break” was only one of two conditions NERC identified that would break the direct connection; the other was the condition where a cyber asset requires authentication and establishes a new connection to the Low BCS. FERC didn’t comment on this second condition.
[ii] Speaking of implied requirements, I and Matt Light of Deloitte will be doing a workshop on exactly this topic – implicit requirements in CIP v5 – during EnergySec’s Security and Compliance Summit in Washington, DC in September. See this blog post for more information.
[iii] See my post on ERC, already referenced above.
[iv] As mentioned in the first footnote above, FERC was silent on whether requiring re-authentication causes a break in ERC (this was the second cause of “broken” ERC pointed to by the CIP v6 SDT in Reference Model 6, after the application layer break itself). So I can’t even be certain that FERC approves of this idea.
[v] Ironically, NERC did take a position much like FERC’s in their April Memorandum on “Network and Externally Accessible Devices”. I and others criticized their position as being overly restrictive, but my position seems much less defensible now that FERC has spoken out on this subject. Of course, that Memorandum has been withdrawn, along with the other Memoranda that were issued with it. I’m told NERC is working on a new Lesson Learned addressing ERC.