A Positive Development

This blog’s ultimate genesis was when I attended my first NERC Standards Drafting Team meeting at Exelon’s headquarters in Chicago (where I live) in the summer of 2010. I attended a meeting of the CSO 706 SDT, the team that drafted CIP versions 2, 3, 4, and 5. This meeting was quite interesting, since the SDT had just pivoted from developing what would become CIP v5 to developing what would be v4[i] (of course, they pivoted back to v5 after v4 was developed). I thought this was very interesting, and wrote a white paper which got the attention of a large number of NERC entities. This ultimately led to my current blog.

So it was kind of a return to the beginning when I attended the second meeting of the current SDT, also at Exelon in Chicago, last week. Of course, this is a different SDT, the one that is developing CIP version 7 (more specifically, the “Modifications to CIP” SDT). I must admit I really enjoy being able to participate in these meetings (not being an SDT member I can’t vote, but I am able to participate – and I certainly wasn’t shy about doing so!). In fact, I recommend that every NERC CIP compliance professional try to attend at least one of these, even if you don’t plan to participate. It is incredibly interesting to see how the sausage is made, not just to have to eat it.

I must admit that I had somewhat conflicting opinions on how important would be the work of this drafting team. Anyone who has read almost any of my blog posts since May of 2013 knows that I have a lot of problems with the wording of many of the requirements in CIP v5 (not too much with v6, but that is of course based on v5). So on the one hand, I should be very eager to work with the new SDT to address some of those problems.

On the other hand, since the beginning of this year I have put out a few posts - such as this one and this one - that take a different tack. They don’t criticize the v5 wording, but do criticize the whole idea of what I call “prescriptive standards” – which is what all the CIP versions have been. It may be clear from these two posts that I think the prescriptive approach doesn’t work for cyber security standards, even though it might be fine for the other NERC standards. And since the requirements of CIP v5 and v6 are prescriptive ones (with two exceptions, which I’ll discuss below), it seemed certain that v7 will be prescriptive as well.

Given that, why should I be concerned with v7, when I think the whole prescriptive approach to CIP should be thrown out? My answer was always – until this week – that it was worthwhile to clean up some of the problems in CIP v5 and v6, which is what the SDT is tasked with doing. But I wanted v7 to be the last set of prescriptive CIP standards. As I said at the time, maybe in a couple years there will be enough consensus that NERC can start working on a completely new CIP version, which would be the first “non-prescriptive CIP”.

In other words, I wasn’t expecting any big developments at the SDT meeting last week. The meeting was almost entirely focused on a single item in the SDT’s “agenda”: developing a new definition of LERC, as directed by FERC. The team was focusing on this item because it is the only agenda item that needs to be accomplished by a designated date, since FERC set a deadline for this one item. It needs to be drafted, balloted (almost certainly multiple times), approved by NERC and sent to FERC for approval by March of 2017. Given what has to occur before that date, the team decided they needed to approve the first draft by the week of July 4^th. And to do that, they had to dedicate almost the entire meeting in Chicago to LERC.

I was very impressed with the meeting in general (it was approximately 20 hours over two and a half days). It was well organized and accomplished a tremendous amount – which included not only rewriting the definition of LERC (Low impact External Routable Connectivity), but also rewriting the two requirement parts associated with it, as well as the associated VSLs and Guidance and Technical Basis.[ii] However, the most interesting part for me was how the discussion went in a different direction from what I expected, or probably from what anybody in the room expected. What was drafted was a non-prescriptive requirement! I will recount here how this development came about. In doing so, I’m not trying to be chronologically accurate, but I am trying to recreate the logic that led the discussion to this surprising conclusion.

In Order 822 in January, FERC ordered NERC to revise the definition of LERC, the main part of which 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.”

FERC’s main concern with the definition was the word “Direct”. This concern was not due to FERC’s being worried that there was some contradiction between the way the word was used in the definition and the dictionary definition of the word. Rather, it was due to the fact that, in two of the “Reference Models” (numbers 5 and 6) that the SDT had inserted in the Guidance and Technical Basis section to explain LERC, the SDT had concluded that there was no LERC - even though there was a routable connection coming into the asset. Something had happened to cause that connection to no longer constitute LERC – and the only way that would be allowed by the definition (assuming it was a bi-directional routable connection) would be that some intermediate device or other measures was making this no longer a “direct” connection. FERC said they wanted to know what that “something” was – in other words, what can “break” LERC within the Low impact asset.

The SDT’s discussion of LERC had actually started several weeks earlier in weekly phone conversations, several of which I listened to. One thing that SDT members noticed, as they studied the existing LERC definition, was that it actually included at least two implicit “requirements” (or perhaps more accurately, “measures”) in it. First, the word “direct” effectively meant that the previous SDT (that had drafted the definition) was saying that one way to “break” LERC was to make some change (such as inserting a device) in the communications stream that made it no longer direct. Second, the word “bi-directional” meant that, if an entity implemented a unidirectional device like a data diode, LERC would also be broken.

Effectively, the CIP v6 SDT (which drafted the current LERC definition) was saying that the risk presented by the presence of LERC could be mitigated in at least three ways. One was to implement a LEAP (Low impact External Access Point), as stated in CIP-003-6 R2 Attachment 1. Another was to break LERC by implementing a device – like a data diode – that made the connection unidirectional, as implied by the definition. A third way was to break the “direct” connection with some sort of device, as also implied by the definition. In Order 822, FERC essentially said they wanted clarity on what a device could do that would break LERC.

While the SDT wasn’t at this stage disagreeing with the substance of either of the two implicit “requirements” in the current LERC definition, they decided they wanted to have a definition that was free of any requirements. After a lot of discussion, they came up with a new definition (which isn’t finalized yet, so I can’t provide any wording) that essentially says there is LERC if a routable connection from anywhere outside of the Low impact asset crosses the boundary of that asset. It doesn’t make any mention of “bi-directional” or “direct”. The intention was to specifically address these two items in the requirement.

Having decided this, the question then came down to what should be required of an entity that has LERC at a Low impact asset, beyond the three options discussed above. In other words, given the new simplified LERC definition, what should be in the requirement for Low assets that have LERC, in order effectively to mitigate the risk posed by having LERC?

The three options above pointed the way to at least two things that need to be in the new requirement. First, the option to implement a LEAP should still be offered as one way to address the risks posed by LERC.[iii] Also, since “bi-directional” will no longer be in the LERC definition, the entity should be offered the option of implementing a device (like a data diode, although there are equally suitable devices that aren’t called by that term) that eliminates this bi-directionality.

But how can the entity address the third option: doing something to break the “direct” connection? Of course, whatever wording the SDT uses to describe this, it can’t use the word “direct” again, or even similar wording, such as “end-to-end”. However the replacement for “direct” is described[iv], it has to be explained. This led to suggestions for other actions that could be taken by the entity that has LERC, including:

1. “Air-gapping” any Low impact BES Cyber Systems from contact with LERC;
2. Requiring re-authentication before the external user can communicate with a Low impact BES Cyber System; and
3. Requiring an intermediate system[v] in the communications stream that will terminate the session with the external user or device, and open a new session.

At this point, the SDT tried to come up with a requirement that would incorporate all of these actions. The general form would be to say something like, “If there is LERC, the entity must take one of the following actions…” However, as they tried to do this, they realized it wouldn’t be easy to do this at all. For one thing, they realized that not all of the actions they had listed would result in LERC being completely mitigated in all cases. For example, requiring re-authentication would not adequately address the case of machine-to-machine communications. They also realized that one or more of these actions might actually be a special case of another, such as a data diode being a special case of a LEAP. And, of course, there could certainly be other actions that would mitigate LERC, as well.

At this point[vi], the SDT had two main options. The first was to admit that they needed to spend a lot of time (perhaps multiple days) discussing the different mitigations of LERC that would be permitted in the new requirement. But the second, suggested by another observer at the meeting, was to rewrite the requirement so that it simply stated that an entity with LERC needed to take steps to mitigate the risk posed by LERC, and discuss different options for doing this in the Guidelines and Technical Basis section.

My initial reaction to this suggestion was “Great, that completely changes the situation. Now none of these actions can be enforced.” Of course, I said this (to myself) because the statements in the Guidance and Technical Basis section that is included with each of the CIP v5 and v6 standards are only guidance, not enforceable. In other words, this new suggestion would mean there would no longer be any way for an auditor to state definitively whether the steps the entity took to mitigate the risk posed by LERC were “permissible” or not. One SDT member emphasized this concern by asking how compliance with this requirement would be measured, implying that it couldn’t be.

But then I thought for a minute, and realized this is exactly what I want to happen with all of the CIP requirements! By moving any discussion of how to mitigate the risk of LERC to the Guidance, the SDT is making the third section of CIP-003 R2/Attachment 1 a non-prescriptive requirement: The entity will have to take measures to mitigate the risk posed by LERC, but it is up to them to determine the best way to do this. And it is up to the auditor to determine whether or not the entity has successfully mitigated the risk.

But this isn’t a new development, since there are already two non-prescriptive requirements in CIP versions 5 and 6. I wrote about one of these requirements, CIP-007-6 R3, in this recent post. Another example is CIP-010-2 R4, which doesn’t prescribe certain actions for Transient Cyber Assets but provides guidelines for dealing with them.[vii] For both of these requirements, it will be up to the auditor to use his or her judgment to determine whether or not the entity has adequately addressed the risks involved.

I’m sure many will point to the fact that auditor judgment will be required as a reason to reject the non-prescriptive approach to CIP requirements. But aren’t we trying to get away from the bad old days of CIP v3, when there was a lot of concern about different regions and even auditors auditing the standards in different ways? My answer to this assertion is that, due to the many ambiguities and contradictions in CIP v5, auditor judgment is going to be inevitable for most of the requirements anyway. And even for those requirements where the wording is clear enough that there in theory should be no judgment needed, I believe that in actuality the auditors are unlikely to take advantage of this fact to nail the entity for even the smallest deviation from that wording. Au contraire, they are going to be much more inclined to use the limited time available for an audit to discuss how the entity could improve their overall cyber security posture. See the post just referenced for more discussion of this idea.

I am going to stop here. There is certainly a lot more to say about the idea of making NERC CIP a set of non-prescriptive requirements. I intend to revisit this topic a lot in future posts, as well as in a book that I and two other people are starting to write on this subject. My point in this post has been that the revised requirement for mitigating the risks of LERC shows that “non-prescriptive CIP” doesn’t have to be implemented as a big bang. It can be implemented one requirement at a time – and indeed, this is happening already! I predict this will happen naturally, since this and future SDTs will be almost inevitably driven to use a non-prescriptive approach to revise existing requirements and implement new ones. In fact, I hope to have a post out soon making the point that a non-prescriptive approach is the only one that could possibly work for possible future requirements for supply chain security.

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

---

[i] I wish I could point you to a blog post that discussed this, but for the first couple years of writing about CIP, I simply wrote some white papers that were distributed through a Honeywell (actually Matrikon) web site. They are no longer available there, so if you are interested in seeing these, please email me at talrich@deloitte.com.

[ii] None of this was finalized, but the remaining work can be done by smaller groups working together online, with final approval by the full SDT. It will be finished this week, though.

[iii] Although I am not sure whether the term LEAP will be retained in CIP v7.

[iv] As I discussed in this post before the SDT meeting, I came to the conclusion last year that there is no single word, phrase, or sentence that encompasses every method that could be said to “break” LERC. I suggested that what would work best in the new definition would be providing some specific use cases (for example, requiring re-authentication before access to the end device is granted) and simply stating that LERC would be broken in these cases. This is more or less what happened, although the “use cases” were only provided in the Guidance and Technical Basis, as will be described below.

[v] Not to be confused with an Intermediate System for Medium and High impact CIP environments, of course. The way I’m using the term here, it doesn’t mean anything more than a device that is found within the communications stream starting from outside the Low impact asset and terminating at a BES Cyber System inside the asset.

[vi] And remember, I’m not speaking of a specific point in time here. I’m talking about the “point” in the chain of logic that led to the realization that a non-prescriptive requirement was needed.

[vii] The formats of these two requirements differ from each other. CIP-007-6 R3 includes three non-prescriptive requirement parts, each of which addresses a different part of the risk posed by malicious code. To understand your options for complying with any one of these, you need to go to the Guidance for suggestions. This is similar to the approach that I believe will be the basis for the revised requirement for mitigating the risks posed by LERC.

CIP-010-2 R4 requires the entity to develop a “plan” for “Transient Cyber Assets and Removable Media” (presumably, for mitigating the risk thereof. However, the requirement is silent about that, which strikes me as a big oversight). The plan has to include each of the applicable sections of Attachment 1. Each of these sections discusses a particular area that needs to be addressed, such as “Transient Cyber Asset Authorization”, and provides some high level suggestions as to how this can be done, without going into any prescriptive details like removing access authorization immediately when an employee is terminated. The Guidance provides more detailed suggestions on how to address each of these areas, but they are of course only suggestions.