Your Vote Counts!

As I write this, the whole country is anxiously awaiting the upcoming vote. It can be said without exaggeration that the fate of the country’s infrastructure – indeed, its entire economy - rests on the outcome of this crucial ballot…..Of course, I’m talking about the upcoming NERC ballot on the second draft of CIP-003-7, which incorporates changes made to address FERC’s directive that NERC clarify the meaning of the word “direct” in the LERC definition.[i]

Briefly, the current draft of CIP-003-7, which will be balloted soon, is the second draft. The first was soundly voted down, and I am concerned the second one may be as well. This bothers me because I believe the opposition to both drafts is based on widespread misunderstanding of what they say, and because this opposition could lead to one of several serious outcomes, none of which is positive.

First, if this draft is voted down, the SDT – feeling the cold wind of FERC’s March 2017 deadline on their faces - may feel obliged to accommodate this misunderstanding and produce a new requirement that will be a big step backwards from the current draft, but which is likely to pass. The requirement will probably end up being prescriptive rather than non-prescriptive, as it is in the current draft. It is also very possible that the new requirement will effectively require an inventory of all BES Cyber Systems at Low impact sites, something that most in the industry have so far opposed as too big a burden on them – but which may end up to be necessary in order to produce a requirement that people understand.  

However, it is also very possible that this will be the last ballot on this issue. Remember, NERC faces a deadline of next March to present to FERC a revision to the LERC definition (and if required, to the requirement itself) that clarifies the meaning of the word “direct”. NERC doesn’t have the option of saying next March, “Sorry, FERC. We just couldn’t come up with something that the membership liked. Better luck next time.”

Section 321 of NERC’s Rules of Procedure states in effect that, if the NERC Board of Trustees decides that the balloting process has failed to produce a standard or definition that is required to meet a FERC directive, they can order the Standards Committee to develop one on their own (with input from stakeholders, but not requiring a ballot). Given that the ballot results won’t be known until December, if it doesn't pass this time it is likely that the BoT will take this step right away, since going through the normal process of producing a third draft and balloting it would very likely mean NERC would miss the deadline. And if this happens, who knows what will be produced? Perhaps we’ll go back to what is in CIP-003-6, along with simply tweaking the LERC definition to clarify the word “direct”.[ii] That would presumably satisfy FERC’s directive, but it would result in the requirement losing the big advantage it now has over the v6 version, as I’ll discuss below.

This post – one of the longest I’ve written (which is saying a lot!), if not the longest – will make the case that what an entity needs to do to comply with Section 3.1 of Attachment 1 of CIP-003 has not changed at all from version 6 through the current second draft of version 7. In fact, there have been two big improvements: making the requirement non-prescriptive and clarifying the meaning of “direct” per FERC’s directive. There is no downside that I can see. This is why I think the current opposition to the new draft is based simply on misunderstanding of what it says. If you want to take what I have just said on faith that it is true, then you don’t have to read the rest of this post. If for some reason you obstinately refuse to take my word as gold and require proof of what I say, read on.

I will discuss how the Low impact access control requirement works, first in CIP-003-6, then in the first and second drafts of CIP-003-7. I need to go into some detail to explain these things, so you might want to get a sandwich before you read the rest of this post.

LERC in CIP-003-6

1. LERC (Low impact External Routable Connectivity) first appeared in CIP v6. The main part of the definition of LERC in CIP v6 reads “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 bi-directional routable protocol connection.” This definition was illustrated by a set of “reference models” in the Guidance and Technical Basis for CIP-003-6. The reference models illustrate particular cases where there would or wouldn’t be LERC.
2. This definition was coupled with the “requirement” found in section 3.1 of Attachment 1, which reads “For LERC, if any, implement a LEAP to permit only necessary inbound and outbound bi-directional routable protocol access..” Of course, LEAP means Low impact Electronic Access Point.
3. The definition explicitly provides two ways that LERC can be “broken”. First, the fact that the connection must be bi-directional means that use of a data diode (or “unidirectional gateway”) will break LERC, since that leads to unidirectional communications. Second, the word “direct” means that any indirect communications with a Low-impact BCS will break LERC.
4. Combining this with the LERC definition, the requirement effectively reads “In cases where LERC is not ‘broken’ by one of the conditions contained (even implicitly) in the definition, implement a LEAP.” The reference models help the entity to decide whether LERC is or isn’t broken in a particular case, as well as discuss different ways to deploy LEAPs.
5. To go back to the two conditions that break LERC, “bi-directional” is straightforward, but the word “direct” is not. How does an entity distinguish direct from indirect communications? The reference models in the CIP-003-6 Guidance and Technical Basis provide the v6 SDT’s opinions on this question. Reference Model 4 (page 34) provides one example of what does not break LERC: a device that converts the routable protocol to serial, within the boundary of the asset. The caption says this device merely “(extends) the communication between the business network and the Low impact BES Cyber System”. Moreover, the LIBCS is “directly accessible from outside the asset”. So the diagram shows there is LERC, and a LEAP is installed.
6. Reference Model 5 provides an example of a case where LERC is in fact broken. In this model, there is a “non-BES Cyber Asset” which features “non-routed, application layer separation of routable protocol sessions”; in other words, this is a device like what is called an Intermediate System in CIP-005-5 R2 (e.g. a proxy server or terminal server). Because it breaks the communications session with the external device and establishes a completely separate session with a device within the ESP, there is no “direct” communication.
7. Reference Model 6 (page 36) is most likely what caused FERC (in Order 822) to order that NERC clarify the meaning of “direct”. In the caption for the diagram, the SDT said “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.” There are two concepts here, both of which the SDT indicates can break LERC. The first is if re-authentication is required before the external device can access a BES Cyber System, and if a new session is established to the LIBCS. The second is the “layer 7 application layer break”.[iii] I believe the first is straightforward, but I admit to being as confused as FERC was about the second.
8. In addition to the above conditions that break LERC, that are “explicitly” called out in the LERC definition, there are two other conditions that aren’t explicitly called out, but which simple logic indicates will also “break” LERC. One is separation of the IT and OT networks within the asset, with the external routable connectivity only coming into the IT network (this is a common arrangement in some generating plants and substations). In this case, there can clearly never be any direct communication between an outside system and a LIBCS.
9. The other implicit condition that breaks LERC is if the external routable connection is not in effect at the boundary of the asset. From the v7 SDT meetings where this was discussed, I know that the team members were concerned about the case where there is a short routable communications segment leaving a control center, with the remainder of the communications being serial – including the communications that crosses into the Low impact asset, on its way to one or more LIBCS within the asset. The LERC definition in v6 simply says that LERC exists if there is routable connectivity between a Cyber Asset outside of the Low asset and a LIBCS within it; it doesn’t say anything about whether that connection is serial or routable when it comes into the Low asset. The v7 SDT decided to fix that omission by stating that a connection that is LERC must be routable when it crosses into the asset.
10. So let’s summarize what happens with respect to LERC in CIP-003-6: a) LERC exists if there is a “direct” bi-directional routable connection between an external device and a BCS within a low asset; if LERC exists, the entity must implement a LEAP – there is no other option. b) The LERC definition implicitly assumes that the external connection is routable when it crosses into the asset. c) The following conditions can “break” LERC, meaning no LEAP is required: a data diode; an “intermediate system” that establishes a new communications session with the LIBCS; a device that requires re-authentication of the remote user or system and also establishes a new communication session with the LIBCS; a separation of the IT and OT networks within the Low impact asset; and finally a “layer 7 protocol break”. It is the last of these conditions that FERC seems to have had in mind when they asked for clarification of what the term “direct” means in the LERC definition.

First Draft of CIP-003-7

The SDT published their first draft of the revised CIP-003-7 in July; I attended the meeting in Chicago where they finalized this draft in principle and wrote about it in this post.  Here are the major changes they made in this draft:

1. They revised the definition of LERC to read “Routable protocol communication that crosses the boundary of an asset containing one or more low impact BES Cyber System(s)…”[iv] Note that the three conditions that “break” LERC – data diodes, network segmentation, and “indirect” communications – were removed from the definition; but have no fear, they were still addressed, as discussed below.
2. Another condition that results in LERC not being present – which was implicit in the wording of the v6 definition – is that there is no LERC if the connection from the outside device to a LIBCS is non-routable when it comes into the asset. The SDT made this explicit in the new LERC definition. In doing this, the SDT used the new term “asset boundary”, in order that the entity would be able to determine unambiguously whether or not this condition was met. However, they didn’t define the term, which led to a lot of suspicion that auditors might cite entities for not properly declaring their asset boundary, even though the Guidance and Technical Basis (pp 31-32) tried to make clear that there was no “correct” definition of an asset boundary – it will vary depending on the circumstances.[v]
3. The SDT decided to remove the three conditions that break LERC from the definition because they realized that these are actually controls that mitigate the risk posed by LERC. So instead of saying that the existence of LERC, if not broken, requires a LEAP (and no other controls), they decided to say that, if there is LERC as per the new “control-free” definition, the entity will have a choice of controls to apply. The control could be a LEAP[vi], but it could also be one of the three controls that were removed from the definition. So the SDT drew up a new set of Reference Models that illustrated the different types of controls that could be applied.
4. At the meeting I attended in June, the SDT first tried to put all of the possible controls for LERC in the “requirement” itself (I use the quotation marks because the actual requirement CIP-003-7 R2 simply refers the reader to the details in Attachment 1. The section that deals with electronic access control is 3.1, so it is in effect the electronic access control “requirement”); they were in a bulleted list – which means they were separate options that could be applied. In very short order, the team realized this wouldn’t work – there were all sorts of shadings and variations that couldn’t be captured in a simple bulleted list. So they decided to make the requirement a non-prescriptive one. They changed it to read “Implement electronic access control(s) for LERC, if any, to permit only necessary electronic access to low impact BES Cyber System(s).”
5. I was quite pleased to see the SDT do this, since I have come to believe that all of the CIP requirements should be made non-prescriptive; assuming this is the form of the requirement finally approved, it will be the third non-prescriptive requirement in CIP (along with CIP-007-6 R3 and CIP-010-2 R4). With the new requirement language, the different controls shown in the reference models (starting on page 32) now became simply suggestions on how to mitigate the risk posed by LERC. If the entity has an equivalent control (perhaps encryption) they want to apply, and if they can convince their auditor that it is as effective as the ones listed in the Guidance, they will be deemed in compliance with this requirement.
6. In the first draft of CIP-003-7, the conditions that “broke” LERC in CIP-003-6 all became controls that can be used to mitigate the risk posed by the presence of LERC. These and other possible controls were described in the reference models found in the Guidance and Technical Basis, starting on page 33. I will discuss each of these reference models, in order to show that the end result of this requirement is the same as the end result of the v6 requirement, with the exception that the v7 requirement is non-prescriptive.
7. The first reference model shows a Low asset in which the IT and OT networks are physically separated, and the external routable connection comes into the IT network. This is the condition that was only implicitly assumed in the v6 definition. It is now explicitly listed as a control: If your Low impact asset is set up this way, you won’t have to do anything else to comply with “requirement” 3.1. So the result is exactly the same in v7 as in v6: if you have separation like what is shown in the concept diagram, you don’t have to do anything else to be in compliance.
8. I do want to dwell on this point further, because one of the big misunderstandings that arose about the first draft of CIP-003-7 (and seems to have continued in the reaction to the second draft) is that non-OT (i.e. IT) cyber assets could somehow be brought “into scope” for CIP. This is simply not the case. While it’s true that LERC would exist even if only IT assets participated in external routable connectivity, the fact that their network is separated from that of the OT assets would be an ironclad assurance that the entity would be in compliance, without having to implement any other controls. As you'll see below, the v7 SDT tried to eliminate this problem by dropping the LERC definition and incorporating a new one into the requirement. The new "definition" goes back to only addressing routable communications that goes to a LIBCS; so any other communications can be totally ignored.
9. Reference Model 2 illustrates logical network separation, but the result is the same as in the first model: If the IT and OT networks are separated, this mitigates the risk posed by LERC, and the entity has complied with “requirement” 3.1.
10. Reference Model 3 illustrates use of a host-based firewall to mitigate risk posed by LERC. In CIP-003-6, this was one example of a LEAP, which no longer exists in v7. But the result is the same: The entity doesn’t have to do anything more to comply with the requirement.
11. Reference Model 4 illustrates a security device that enforces inbound and outbound electronic access permissions – in other words, a firewall. Again, this would be called a LEAP in v6, but the result is the same in this draft of the v7 requirement – the entity doesn’t have to do anything more to comply with the requirement.
12. Reference Model 5 shows a centralized security device that controls electronic access to multiple Low impact assets. Once again, this would be called a LEAP in v6, but the result is the same.
13. Reference Model 6 shows a unidirectional gateway (data diode) that mitigates the risk posed by LERC. In v6, this was one of the two conditions that would break LERC that were explicitly included in the LERC definition. So the result is the same here (perhaps you’re noticing that, in each of the reference models, I’m demonstrating that the result of applying that model is exactly the same in v7 as in v6. As I’ve said, the whole point of this post is to show that nothing that you could do to comply with “requirement” 3.1 in v6 is taken away in v7; plus you can do a lot more, since the requirement is now a non-prescriptive one).
14. Reference Model 7 shows a Cyber Asset (not a BCA) that performs authentication on inbound traffic. The caption points out that simply requiring new authentication won’t in itself always be sufficient to mitigate the risk posed by the presence of LERC. This corresponds to one of the two conditions shown as “breaking” LERC in Reference Model 6 in CIP-003-6 (the other is the Layer 7 protocol break). In that reference model, the caption states explicitly that simply requiring re-authentication is not enough to break LERC; there needs to be a new connection to the BCS as well. Once again, the two cases are the same, except that in v7 the entity isn’t necessarily constrained to combining a new session with re-authentication. In some cases, re-authentication may be enough, and in other cases something else might be combined with re-authentication to satisfy the requirement. So in this case, not only can the entity do exactly what they could do to comply in v6, but they have much more flexibility (of course, this is because the v7 requirement is non-prescriptive).
15. Reference Model 8 illustrates the case where a Cyber Asset (not a BCA/BCS) terminates the incoming routable communications session and establishes a new one with the Low impact BCS. This is equivalent to Reference Model 5 in CIP-003-6, although in that case the Cyber Asset “breaks” LERC, while in this case it is one of the many controls that can be applied to meet the requirement. Once again, in the v7 requirement the entity can do exactly the same thing to comply as they would have in the v6 requirement; but they have other options as well.
16. Reference Model 9 simply shows that one security device can provide both an EAP to “break” External Routable Connectivity (for Medium or High impact BCS) and a LEAP to “break” LERC. It corresponds exactly to Reference Model 7 in CIP-003-6.
17. Of course, this whole exercise was necessary because FERC wanted NERC to clarify what the word “direct” means in the LERC definition. How exactly did the SDT do this? Reference Models 7 and 8 (paragraphs 14 and 15 above) constitute the SDT’s new “definition” of “direct”. But note that the words “Layer 7 application layer break” don’t appear anywhere in CIP-003-7, as they do in Reference Model 6 in CIP-003-6. I believe these words are what gave FERC all the heartburn in v6, and are why they ordered the clarification of "direct". I predict FERC will find this satisfies their directive.[vii]

The point of this long discussion of reference models is to show that everything an entity ccould do to comply with “requirement” 3.1 in CIP-003-7 can still be done to comply with the same requirement in the first draft of CIP-003-7; however, the wording is different. There is no longer the idea of “breaking” LERC, but simply different controls that can be applied to mitigate the risk posed by the presence of LERC. In addition, there is a big change from v6, in that the requirement is now non-prescriptive. This means the entity isn’t limited to the controls shown in the v7 reference models. If they want to apply a different control, and if they can convince their auditor that it does a good job of mitigating the risk posed by LERC, they are in compliance with the requirement.

Second Draft of CIP-003-7

This is the draft that is up for balloting now. Fortunately for you, my discussion of this draft will be much shorter than for the first draft, since there is much less to discuss! The primary change from the first draft is that the SDT decided to jettison the separate definition of LERC altogether, and incorporate the important parts of the definition into the “requirement” itself. Accordingly, CIP-003-7 Attachment 1 Section 3.1 now reads:

Electronic Access Controls: For each asset containing low impact BES Cyber System(s) identified pursuant to CIP‐002, the Responsible Entity shall implement electronic access controls to:

3.1 Permit only necessary inbound and outbound electronic access as determined by the Responsible Entity for any communications that are:

i. between a low impact BES Cyber System(s) and a Cyber Asset(s) outside the asset containing low impact BES Cyber System(s);

ii. using a routable protocol when entering or leaving the asset containing the low impact BES Cyber System(s); and,

iii. not used for time‐sensitive protection or control functions between intelligent electronic devices (e.g. communications using protocol IEC TR‐61850‐90‐5 R‐GOOSE).

The most important result of this is that the big change that was made in the first draft – making LERC a property of the asset rather than specifically of the Low impact BCS at the asset – has now been reversed. Now, there is no obligation for the entity to do anything unless there is routable communication coming into a LIBCS from outside the asset.

However, the practical effect of this change is the same: If routable communications comes into the asset but only goes into a network that doesn’t contain LIBCS (i.e. an “IT network”), and which is physically or logically isolated from any network that does contain LIBCS, then the entity has no further compliance obligation for this requirement; the only difference is that network separation is called a control in the first draft, whereas in the second draft it is a condition of the entity’s having external routable connectivity to low BCS in the first place. As I discussed in paragraph 8 above, the fact that in the first draft any routable connectivity into an asset was called LERC was a big issue – even though it didn’t place any more compliance burden on the entity than in v6. Hopefully, the people who were worried about this will sleep easier now.

This change is now reflected in the reference models. Since physical and logical network separation are no longer controls, the first two RMs have been removed. RM 1 is now host-based firewall, which was RM 3 in the first draft. The remaining reference models in the first draft are all in the second draft, unchanged except for perhaps one or two small changes; however, they are all numbered “n-2”, if n is their number in the first draft. The physical and logical network separation reference models are resurrected as RMs 8 and 9. However, they are no longer described as controls but rather conditions which would prevent “routable communication between a low impact BES Cyber System and a Cyber Asset outside the asset” (the phrase which now takes the place of LERC). A tenth Reference Model has been added which illustrates how, if the only communications coming in to LIBCS is serial, there is no compliance obligation, either.[viii]

Summing it up

To repeat what I said at the beginning of this post, there has been no change in what an entity has to do to comply with the requirement for Low impact electronic access controls in CIP-003, from version 6 through both drafts of version 7; in addition, the v7 requirement is non-prescriptive (some would say “risk-based”), affording the entity much more flexibility in how to comply than the v6 version did.[ix] I see no way that NERC entities can lose if this draft is approved.

I hope the above discussion has satisfied any concerns you have about the second draft, or at least that it has bludgeoned you over the head enough that you’re numb and will agree to anything outrageous that I say (at this point at night, either outcome is fine with me).[x] It’s not my job to tell you how to vote in the upcoming ballot, but I hope you will keep what I have said in mind.

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

---

[i] I have also heard some talk about another upcoming vote that occurs on November 8. I think the best commentary on that contest was written – very presciently - almost 100 years ago in a poem by William Butler Yeats. I quoted from that poem at the beginning of this post in early 2015.

[ii] It is also possible that the Standards Committee will decide not to change the LERC definition or the requirement, but simply add wording to the Guidance to clarify what “direct” means.

[iii] I believe this phrase was developed by the Department of Redundancy Department. Layer 7 is the application layer in the OSI model.

[iv] In quoting both this definition of LERC and the original one in CIP v6, I have omitted the language exempting time-sensitive communications, since that didn’t change substantially (if at all) between the two definitions.

[v] From having attended the SDT meeting where “asset boundary” was discussed, I know that the SDT had in mind the idea that all BCS within the Low impact asset need to be included within the boundary – this is a clear criterion for deciding whether or not an asset boundary is correct. In retrospect, it was a mistake for the SDT not to write a definition of asset boundary that stated this criterion. It would have provided relief to the many entities who were worried about having no ability to counter an auditor who might try to nail them on not determining an asset boundary correctly; they could simply point out that all of their Low impact BCS were within the boundary they had declared, and that met the definition. I notice that the Guidance for the second draft of CIP-003-7 does mention this idea.

[vi] In the first draft, the SDT decided the term LEAP could be retired, since the firewall (or whatever would otherwise be used as a LEAP) no longer had a special status as the only control that could be applied to LERC.

[vii] In early 2015, there was a lot of discussion about the meaning of ERC; a lot of it referred to Reference Model 6 in CIP-003-6, especially the “layer 7 application layer break”. This was despite the fact that ERC and LERC are in theory two different things. I know there was a lot of controversy over whether a protocol converter alone could break ERC. I think FERC wanted to kill two birds with one stone when they ordered NERC to clarify the meaning of “direct”. They of course didn’t want the same controversy to come up with respect to LERC; but they also knew that whatever solution the v7 SDT came up with for LERC would end up influencing how the ERC definition was interpreted (even though the v7 SDT probably won’t decide to change ERC. It isn’t in their mandate, but more importantly they have a couple of real tigers by the tail and the last thing they want is to have a couple more of them. I hope to have a post out on their predicament soon).

[viii] The undefined term “asset boundary” has now been dropped from the requirement altogether, to quell fears that entities would be dinged for not “properly” identifying their asset boundaries.

[ix] I am beginning to realize that some CIP compliance professionals are actually worried about non-prescriptive requirements, since they will no longer have a rigid requirement to comply with but will instead have to exercise judgment (which judgment the auditor may not agree with!). I realize this is a concern for entities that have had bad experience with auditors that exercise poor judgment (since a lot of judgment is required for complying with and auditing the current CIP requirements, even though they are almost all prescriptive). I hope to have a post on this syndrome soon, but I liken it to the case of some longtime prisoners who reach the end of their sentences and want to return to prison, because they know no other way of life.

[x] Now that I think of it, each of the two main Presidential candidates embodies one of these two alternatives. I will leave it as an exercise for the reader to decide which one tries to convince rationally and which one bludgeons.