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.
No comments:
Post a Comment