Not Dead Yet

A number of my posts have started with a mention of something I read in EnergySec’s weekly newsletter. This isn’t because I’m being paid to promote the organization (although I think very highly of them), but because the newsletter often sees things that nobody else does (including me).

One feature of the newsletter is the Blog Roll, where Brandon Workentin, the very knowledgeable EnergySec staff member who edits the newsletter, discusses recent blog posts of interest to the ICS security audience. Two weeks ago, Brandon wrote about my post on the issue of whether VOIP phones should be considered BES Cyber Systems. He pointed out that, while nominally about VOIP, the post “is really about the need, in some cases, for entities and auditors to interpret a requirement ‘as if it had been written differently.’" As usual when Brandon writes about my posts, he hit the nail on the head; in fact, I don’t think I could have summarized the post any better than he did. This is why I always look forward to reading what he says about my posts: so I can learn what I meant when I wrote them!

In the penultimate paragraph of that post, I concluded (in reference to how VOIP systems should be treated under CIP-002 R1) that “…both the entity and the auditor need to insert two words into the (BES Cyber Asset) definition (Note: I could have gone on to say “in order to have a BCA definition that properly addresses VOIP phones and other ‘support systems’”).” I continued, “In other cases (and I will illustrate one case in another post that is coming soon), both the entity and the auditor need to ignore some of the wording in the requirements.” Well, the post that is “coming soon” is here! I will now discuss how one particular requirement in CIP v5/v6 – specifically, CIP-002-5.1 R1 with Attachment 1 – can only be properly followed by an entity or an auditor if part of the wording is ignored. But first some background.

In late April 2013, FERC surprised most in the industry (and certainly me), when they issued their NOPR saying they intended to approve CIP version 5 and have it supersede CIP v4, which was due to come into effect on April 1, 2014. Since they had approved v4 in April 2012 (which was also a surprise to most of us in the industry), I had been focusing on v4 in my blog posts, because after all v4 was now the law of the land, and v5 was still struggling to get the votes it needed to get approved (and there was a serious question whether it would ever be approved).

After the NOPR came out, I decided to write a series of posts on the CIP v5 standards, starting at the beginning with CIP-002-5.1. In this first post, I sat down with CIP-002 R1 and Attachment 1 and tried to piece together exactly how a NERC entity was to identify its BES Cyber Systems and then classify them as High, Medium or Low impact, along with identifying its assets that contain Low impact BCS.

But a funny thing happened as I worked on this post; no matter how much I scrutinized the wording of R1 and Attachment 1, I simply couldn’t put together a logical chain of steps that would produce the required result. I came to a point where no amount of logic could bridge the wide chasm caused by the contradictory nature of the wording I found in R1 and Attachment 1. I concluded that this chasm needed to be closed, in order for CIP v5 to be a set of standards that NERC entities could comply with and that NERC auditors could audit.

The primary problem[i] I identified in this post was in the wording of Attachment 1. This seems to be written under the implicit assumption that the entity has already identified BES Cyber Systems at all of its BES Assets – High, Medium and Low impact – before it even starts to classify them. In Sections 1 and 2 of Attachment 1, the entity is told to identify those BCS that meet the High and Medium impact criteria, respectively. And Section 3, where Lows are identified, seems to follow suit when it tells the entity to identify “BES Cyber Systems not included in Sections 1 or 2 above…” This clearly implies that the entity had a comprehensive BCS list at the beginning of this process. But there’s only one problem with this: The entity isn’t required to identify BCS at Low assets, so it never had a comprehensive list to start from (and therefore it can’t identify BCS “not included in Sections 1 or 2”). In fact, Requirement Part 1.3 of CIP-002 R1 (which “sends” the entity to Section 3 of Attachment 1 to figure out how to identify Low impact assets) says “A discrete list of low impact BES Cyber Systems is not required.”  

This discovery led to my writing a series of posts over the summer of 2013, advocating that CIP-002-5.1 R1 and Attachment 1 be rewritten to bridge this chasm. Since I knew that NERC wouldn’t undertake this task on their own, I put my hopes in FERC – that they would order NERC to do this when they approved CIP v5. In fact, I even wrote out my proposed revised wording, and submitted that to FERC during the comment period on v5.

Of course, FERC didn’t take me up on my suggestion when they approved v5 in Order 791 on November 22, 2013 (50 years to the day – in fact, almost to the hour - after the assassination of President Kennedy in 1963. Just coincidence, you say? Well….). Instead, they ordered the four changes that led to CIP v6, none of which addressed this issue. I then pinned my hopes on the idea that NERC would find some way to “interpret” CIP-002 so that it would make sense, even though the actual wording wouldn’t change.

NERC did issue some “Lessons Learned” in 2014 and 2015 that tried to resolve ambiguities (although not the big one I was concerned about), but these were all withdrawn. But NERC came up against the reality that the Rules of Procedure only allow one way to change a standard: write a Standards Authorization Request, seat a Standards Drafting Team, and get to work drafting the new standard (which takes easily 3-4 years to produce results). And there is only one official way to interpret a standard: go through the Request for Interpretation process (which takes easily 2-3 years, with no guarantee of ultimate success. FERC remanded the last two CIP RFIs that were presented to it in 2012, although there may be a test soon when EnergySec’s RFI on Criterion 2.1 in Attachment 1 of CIP-002-5.1 is presented to them).

In the end, NERC admitted there needed to be a new version of CIP (although the fact that it is a new version seems never to be stated publicly. Instead, the drafting team to this day is called the “CIP Revisions” SDT, presumably to demonstrate that NERC has a great sense of humor), and indeed the new SDT started work last spring. The results of their work will be implemented in pieces over probably the next 2-6 years, although the fundamental problem I’m concerned with will most likely never be addressed at all.[ii]

You may wonder why, if there is such a basic contradiction in the wording of CIP-002-5.1 R1, the whole edifice of CIP v5 hasn’t come crashing down. After all, R1 can very easily be said to be the fundamental requirement in CIP v5 and v6 (and it will be in v7 as well). This is the requirement where the entity figures out what all the other requirements apply to. If the entity is lucky, their list of applicable assets and cyber assets is very small. If they’re not lucky, there is a huge list, and the entity had better figure on spending some significant portion of their total annual budget on CIP compliance for at least the next 5-10 years (a number of entities are doing exactly this. In fact, I know of one medium-sized entity that has allocated over ten percent of their entire annual revenues to cyber security and NERC CIP compliance, at least for this year).

So why didn’t CIP v5 collapse? There is certainly a lot of confusion over this requirement, and there continues to be confusion today; in my opinion, this confusion alone probably delayed many entities’ implementation of v5 for at least a year. But NERC entities and NERC auditors seem to be in fairly broad agreement now on how to comply with R1, as well as on what constitutes non-compliance with the requirement.

How did this agreement come about, given that applying strict logic doesn’t allow a single consistent interpretation of the wording of CIP-002 R1 and Attachment 1? It’s actually very simple: people reverted back to the overall framework for the asset identification process in CIP v1 – v4, even though that wasn’t directly supported by the language in CIP-002-5.1. To briefly (briefly for me, anyway!) summarize what happened:

1. The bright-line criteria in Attachment 1 made their first appearance in CIP-002 version 4. If you read the v4 criteria, you will recognize the predecessors to most of the High and Medium impact criteria in v5. In v4, the criteria applied directly to assets, not cyber assets or BCS. BES assets that met one of the v4 criteria were Critical Assets and thus in scope for CIP v4; those assets that didn’t were out of scope for CIP v4 altogether (of course, there was no distinction between High and Medium impact assets. An asset was either critical or it wasn’t in scope for CIP v4 at all). Naturally, there were no criteria applying to Low impact assets, although some assets that would have been Critical Assets under v4 ended up as Lows under v5 (notably blackstart assets and Facilities).
2. When the SDT started work on CIP v5 after completing v4 (the same SDT developed v2, v3, v4 and v5, although there were a number of personnel changes over the four years the team was in existence), they more or less imported the criteria directly from v4, even though in theory the whole purpose of Attachment 1 had changed. In CIP-002 version 5, Attachment 1 in theory provides criteria for identifying BES Cyber Systems, not Critical Assets as in v4. But instead of finding new criteria that applied to cyber systems, the SDT decided essentially to reuse the asset-based criteria from v4 for the High and Medium criteria in v5. However, they “front-ended” the criteria with language that tried to make them conform with the new purpose of Attachment 1 – to classify BES Cyber Systems.
3. In retrospect, doing this was a big mistake. The SDT was using asset-based criteria to classify BCS, but the wording of Attachment 1 (and some of the wording of R1) sounded like the BCS were really being classified on their intrinsic BES impact. Question: How could the SDT have developed meaningful, measurable criteria that actually applied to BCS, not assets/Facilities? Answer: They would have had to bring in some measure of how important each BCS was to the BES.

In CIP v1-4, a Critical Cyber Asset was defined as one that is “essential to the operation of” a Critical Asset – so it was the impact on the asset that was important, not on the BES itself. In order to achieve the stated goal of CIP-002-5.1 R1, the v5 criteria (in Attachment 1) should have ranked the intrinsic “essentialness” of each BCS to the BES itself, not to an asset. I admit this would have been very hard to do. But of course, the fact that it would have been hard simply reflects a point that I argued with SDT members in 2011 and 2012: It doesn’t make much sense to talk about the intrinsic impact of a BCS on the BES.[iii] Rather, the impact of a BCS is almost always only through the asset or Facility it controls or supports. It is those assets or Facilities, not the BCS themselves, that should be classified, as was the case in v1-4. As it is, I will demonstrate below that literally the entire NERC community has reverted to the v1-4 method of classifying assets, not BCS, even though this involves ignoring a lot of the wording in CIP-002-5.1 R1 and Attachment 1.

4. I think the SDT made this mistake because they knew it was now verboten[iv] to require entities to identify BCS at Low impact assets[v]; so they had to let the entity simply identify Low assets, not Low BCS. This meant they had to make all the Attachment 1 criteria (High, Medium and Low) apply to assets, not BCS. If they didn’t do this, how could an entity possibly identify its Low assets, since it hasn’t previously identified its High and Medium assets? Unfortunately, the SDT at the same time tried to maintain the fiction that Attachment 1 was really about classifying BCS, not assets, which is why the literal wording of Attachment 1 is in direct contradiction to the way that 99% of NERC entities and auditors are interpreting it (and the way that IMHO the SDT members intended it to be interpreted).
5. What the SDT should have done was go back to the CIP v1-4 model: First the entity identifies its most important assets in scope. These were Critical Assets in v1-4, but High or Medium assets/Facilities in v5 (and in v5, the entity uses the criteria in Attachment 1 to classify High vs. Medium assets). Next, the entity identifies the Critical Cyber Assets (in v1-4) or Medium or High BES Cyber Systems (in v5) associated with those assets (with High or Medium BCS defined as those associated with/located at High or Medium assets/Facilities respectively). Finally, the entity subtracts its Medium and High assets from its total list of BES assets; the remaining assets are Lows (of course, there is no requirement to identify BCS at Lows). This wouldn’t have been terribly elegant, but it would have been logically consistent.
6. However, even though the sequence I just described in the previous paragraph isn’t in the actual wording of CIP-002-5.1, it is in fact how literally every entity (that I know of) is complying with CIP v5/v6, and it is how literally every auditor (again, that I know of) is auditing CIP-002-5.1 R1. Many, if not most, of the entities, and probably more than a few auditors, are quite unaware that the compliance methodology they are following (or auditing against) isn’t in the actual wording of the standard. But that doesn’t really matter. There isn’t much confusion over this issue now, since this consensus has developed in spite of the wording of R1 and Attachment 1 (although there was a lot of confusion over these and other parts of CIP v5 in 2014, when many entities lost part or all of a year in their v5 compliance efforts, as they tried to figure out what the requirements actually meant, and waited for definitive guidance from NERC, which never came).

To finish my long sermon, this is another case where both entities and auditors cannot simply follow the strict wording of the CIP v5/v6 standards in order to comply with and audit them. In the VOIP case in my earlier post, I stated that what almost all entities and auditors are doing is implicitly inserting two words into the BES Cyber Asset definition – when they do that, confusion over how to classify VOIP and other “support systems” melts away. In the case of CIP-002 R1 and Attachment 1, I have just tried to show that the only way to overcome the logical inconsistency of the wording is for entities and auditors to ignore a lot of the actual wording and substitute alternate wording – and they have done that with a remarkable degree of unanimity.

So what’s the big deal with all of this? Since neither of these issues is causing entities to be out of CIP compliance (or to devote a lot of resources to something which they have mistakenly identified as required for compliance), what’s the problem? Aren’t these both simply dead issues?

One problem is that – in my opinion – the need to either supplement or ignore some of the wording of CIP v5 (and especially in CIP-002 R1, the fundamental requirement of CIP v5 and v6) makes the standards unenforceable in what I call the strict sense: If an entity is fined for not properly identifying BCS and challenges that fine on the grounds that the wording of CIP-002-5.1 R1 is contradictory, I think the fine will be thrown out by any judge who spends ten minutes reading the requirement. But since no NERC entity has actually ever challenged a CIP fine in court, I admit this is a fairly theoretical issue.[vi]

The real problem is that sometimes entities take the words of CIP-002 R1 and Attachment 1 literally, and end up mis-identifying BCS and assets for that reason. In my next post, I will provide an example that I recently came across, where this is exactly what happened.

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

---

[i] I actually pointed out two fundamental problems with CIP-002-5.1 R1 in the post. The first (which I said was of lesser importance) had to do with what I thought at the time was inconsistent use of the terms “asset” and “Facility”. I later learned that this wording is actually not inconsistent, although it is terribly confusing. In practice, very few entities – and perhaps very few auditors – understand that these two terms actually refer to different things. This without doubt has led many entities to over-identify Medium BCS at Transmission substations, although a few large Transmission entities have told me that the greatly increased effort that would be required, to properly take the word “Facilities” into account to reduce the number of BCS, outweighs the benefit that would be derived from having fewer Medium BCS in the first place.

[ii] I haven’t even advocated that the SDT take up the issue discussed in this post. It would require a huge effort and multiple ballots, and this effort alone would probably push the final implementation of v7 back another year or so. I have the greatest admiration for this SDT, but they have a huge amount on their plate as it is, and I am becoming convinced that they will never succeed in addressing one of the biggest items on that plate (as long as the CIP standards remain basically prescriptive). More on that topic coming soon to a blog near you.

[iii] In fact, I remember a discussion on an SDT call in 2012, when I asked the chairman of the SDT to name a cyber asset that directly impacted the BES - not indirectly through an asset or Facility. He came up with “leak detectors”, a device I hadn’t heard of. Evidently, these sit directly on a line and are not located within a substation or other asset. However, to require that all cyber assets be evaluated for their BES impact, not their impact on an asset/Facility, solely because there are one or two BCS that actually do directly impact the BES, is the textbook example of the tail wagging the dog. Yet this is in fact the stated purpose of CIP-002 R1:  identify and classify BES Cyber Systems based on their impact on the BES. Ironically, those leak detectors wouldn’t be in scope for CIP v5/v6 anyway, since the only BCS that are in scope are those located at one of the six asset types listed in R1.

[iv] Here is why it was forbidden: In 2009, the SDT put out a “concept paper” that first introduced the ideas of BES Cyber System and the BES Reliability Operating Services (although the latter were called “BES Reliability Functions” in the paper). While I think both of these are good concepts, I think that pretending that the impact of a BCS on an asset has nothing to do with whether a Cyber Asset impacts the BES – while at the same time including criteria in Attachment 1 that are entirely asset (or Facility)-based – is the Fundamental Sin of CIP v5, and is the reason it will never be enforceable in the strong sense.

[v] To comply with the first draft of CIP-002 v5, which was posted for comment in November 2011, the entity would literally have had to start their BCS classification effort by identifying BCS at all BES assets – High, Medium and Low impact. Then they would go through Attachment 1 and classify each BCS as High, Medium or Low impact. Of course, NERC entities weren’t too excited about this since it meant identifying all Low BCS. The first draft went down to resounding defeat, with none of the standards receiving much more than a 20% positive vote (I wrote a post pointing this out in December 2011. It was posted on a Honeywell blog that is no longer available online. If you would like to see that post, send me an email at talrich@deloitte.com). At this point, the SDT realized they had to make it explicit that BCS didn’t have to be identified at Lows. Unfortunately, rather than completely rewriting CIP-002 R1 and Attachment 1 so that they took account of that new reality, the SDT kind of tinkered around the edges but left the basic structure in place. The result was the logically inconsistent R1 and Attachment 1 that we know and love so dearly today.

[vi] Although I do believe that if this ever happens, the result will be disastrous. Think of what would happen if a judge suddenly invalidated CIP-002-5.1 R1, and there was no longer a legally-approved way to identify and classify BES Cyber Systems. In my opinion, this would effectively invalidate all of CIP v5 and v6 (and, by the time that happens, probably v7). What would NERC do then? Go back to v3? Throw in the towel on regulating cyber security? Beats me.

Supply Chain Security Webinar Recording Posted!

Last Friday, Larry Kivett and I from Deloitte, and Edna Conway of Cisco, participated in a webinar under UTC's auspices on supply chain security; my topic was CIP-013, the supply chain security standard currently under development. The webinar was very well received with lots of questions, and I think you'll find it interesting.

The recording can be found here. Note that you can also find the recording of the previous Deloitte-Cisco webinar on Virtualization and NERC CIP at the same link.

If you have any comments or questions on the webinar, please email me them at talrich@deloitte.com.

Hold the (VOIP) Phones!

In April of 2015, I was trying to write some “Tom’s Lessons Learned” to address CIP v5 “interpretation” concerns that NERC was clearly not going to address itself – mostly ambiguities in the standards. There are many of these. As of today, I count 4,357, but there are still a few hours left in the day and that number might increase.

My third LL had to do with VOIP phone systems. This became a big issue in one of the NERC regions, where the region was saying that VOIP systems that served Control Centers need to be evaluated as BES Cyber Assets. This in itself wouldn’t have caused a lot of consternation if the region hadn’t also said – or at least a number of entities in the region believed they said it – that the burden of proof would be on the entity to show why the VOIP system should not be a BCA.

There is no dispute that phones play a crucial role at Control Centers. Take the example of a Control Center that controls a crucial peaker plant. On a hot day in the summer, if the RTO or ISO called to order that the plant be brought up and couldn’t get through to anybody because the phones were down, there could conceivably be a very serious BES impact.

Let me say at the outset that, if the VOIP system is networked with BES Cyber Systems within the ESP (which I would call a deplorable security practice, if that word hadn’t been overused lately), this whole discussion is moot. It is a PCA and therefore subject to almost all of the requirements that BCS are. The rest of this post assumes this is not the case.

Of course, the question whether a Cyber Asset is a BCA depends on whether it meets the BCA definition, the heart of which reads “A Cyber Asset that if rendered unavailable, degraded, or misused would, within 15 minutes of its required operation, misoperation, or non-operation, adversely impact one or more Facilities, systems, or equipment, which, if destroyed, degraded, or otherwise rendered unavailable when needed, would affect the reliable operation of the Bulk Electric System. Redundancy of affected Facilities, systems, and equipment shall not be considered when determining adverse impact.”

Let’s concede right away that the above example shows that a VOIP system failure in a Control Center could indeed have a very serious BES impact within 15 minutes. So if this is indeed what the BCA definition says, there is no question the VOIP system would have to be a BCA. But note the word “could” here. Does that appear in the definition? No, it doesn’t; instead the word “would” appears, which I translate loosely as meaning “inevitably”. In other words, I interpret the BCA definition to require that there would inevitably be a BES impact if the Cyber Asset were to fail, be misused, etc.

Now, I freely admit that the word “inevitably” is not in the BCA definition. But neither is the word “could” or “possibly”, so it can’t be said that the meaning is that there only has to be a possibility of BES damage for the Cyber Asset to meet the definition. I interpret “would” to mean inevitably, but others may not. This is just one of the 4,357 ambiguities in CIP v5. And, like all the other ambiguities, it can’t be removed by a closer reading of the words. It is just there, period.

If you read “inevitably” into the BCA definition, IMHO, there should be no question that VOIP systems are not BCAs. Sure, the system may go down on a hot day and the initial call from the RTO won’t go through. But will the RTO just give up and say, “Oh well, I guess we’ll just have to accept a cascading outage”? Of course not. They will be prepared for this eventuality, and there will be a number of other ways they can get through. They can call another phone at the same organization (perhaps the Finance department) and ask that they bring the message to the Control Center immediately. Or they will have stored some cell phone numbers of Control Center personnel that they can call in just this situation. Or they can get in via a satellite phone. Or they can use smoke signals or carrier pigeons. The message will get through, one way or the other.

So it seemed clear to me that there would not inevitably be a BES impact if the VOIP system in our hypothetical Control Center went down; given that I interpreted “would” to imply inevitability, it seemed reasonable to say that VOIP systems could never be BCAs. But in response to assertions about alternative communications pathways, I am told (and I heard this once with my own ears) that the region would say something to the effect of “Aha, but as the BCA definition says, the fact that there is some sort of redundant method of getting through can’t be used to ‘excuse’ the VOIP system from being a BCA.”

In other words, the region seemed to be arguing that the fact that there were so many alternative communications pathways couldn’t be used to excuse the VOIP system from being a BCA. This assumed that the fact that the cellular communications systems, satellite systems, etc. effectively back up the VOIP system in the Control Center fell under what was meant by “Redundancy” in the BCA definition.

If this were true, then my insertion of the word “inevitably” in the BCA definition has no effect since, if all of those alternative systems can’t be considered, then the VOIP being down in the Control Center will inevitably have a huge impact on the BES; therefore, the VOIP system will be a BCA. But the fact is that there are all of these alternative methods of communication, and there assuredly won’t be a BES impact.

This always struck me as not at all what the CIP v5 drafting team had in mind when they talked about redundancy.[i] It seemed that they meant identical systems, configured identically, deployed in such a manner that if one failed, the other would immediately pick up where the other left off – think redundant servers. But the local cellular system and the Control Center’s VOIP system are hardly identical. If the VOIP goes down, the cellular system (or another like the satellite phone system) will indeed provide an alternative communications vehicle, but the converse isn’t true: If the cellular system goes down in say a city, the utility’s VOIP won’t instantly back it up. So there is no symmetry here.

While my original post on VOIP didn’t mention it, there is another good argument why the word “inevitably” should be inserted in the BCA definition: If a Cyber Asset should be declared a BCA even if its loss, misuse, etc. wouldn’t inevitably impact the BES, then other systems at BES assets – especially including HVAC and lighting – need to be treated the same. If the heat goes off in a power plant in northern Ontario in January, there might be a need to shut it down – but it certainly isn’t inevitable, given that people might be able to just put on their coats, hats and gloves and keep working. So if the magic word “inevitable” isn’t inserted in the BCA definition, all of these systems would have to be declared BCAs as well.

At this point, you might bring up NERC’s FAQ document from early 2015, which I wrote about in this  post. That document stated that “support systems” should be excluded from consideration as BES Cyber Assets; the two examples provided were HVAC and lighting systems, although I know some of the NERC regions consider VOIP systems to fall in the same category. Because of this, I believe almost all of the regions haven’t required their entities even to consider whether VOIP systems are BCAs.

I’m certainly not objecting to this practice, since it produces the same result as what I’ve been advocating. However, what is disturbing about this FAQ statement is that there is absolutely no basis for it in CIP v5. Where is the definition of “support system”, and where in the BCA definition does it say that support systems are excluded from consideration? Obviously, the answer is “nowhere”.

But what about the region that had (according to some entities in the region) originally stated that VOIP systems[ii] had to be declared as BCAs? Did they change their position? Since I stopped hearing cries of anguish from that region, I assumed they had. However, at a recent compliance meeting for that region, one of their auditors clearly implied they had not.

He did this when he replied to a question whether, if an entity had in place the Alternative Interpersonal Communications system (AIC) mandated by the NERC COM-001-3 standard (essentially, a backup phone system for control centers), this would negate the need to declare a VOIP system as a BCA. The auditor placed some conditions on his statement, but agreed that this was the case.

Of course, since the result of this statement conforms to what I’ve been advocating, I’m not going to scream and rant about this (there are plenty of other opportunities to do that!). However, I want to point out that the implication of the auditor’s answer is that no, the region has not changed its basic position. Effectively, all they are now saying is that there is one particular type of alternative communications system that does actually lead to the VOIP system not having an inevitable impact on the BES. But the implication of this is that all of the other alternatives I mentioned earlier – cell phones, satellite phones, etc. – do not make the VOIP system’s impact on the BES any less inevitable, and do not make the system any less of a BCA. This was the region’s original position (again, judging by what I was told by some entities, although I myself heard this stated at a compliance meeting for that region earlier this year).

However, the auditor introduced an interesting new word in his reply: “dissimilar”. He used it in referring to the AIC system, meaning it was dissimilar to the VOIP system (which indeed it is). I believe the reason he used this word is he is implicitly advocating that it be inserted in the second sentence of the BCA definition, so that this sentence would now read something like “Redundancy of affected Facilities, systems, and equipment shall not be considered when determining adverse impact, in the case where such Facilities, systems, and equipment[iii] are similar[iv] to the Cyber Asset under consideration.”

This is terrible language from a legal point of view, but it illustrates the idea. If the entity is considering whether a Cyber Asset is a BES Cyber Asset, and if there is a redundant system (e.g. a backup server) that is in a similar configuration, the mere presence of that redundant system does not remove the inevitability of the Cyber Asset’s impact on the BES if lost, misused, etc. This is partly because the same attack that disabled the original Cyber Asset may very well attack the similarly-configured redundanct system. On the other hand, if there are multiple alternatives that remove the inevitability from the impact (in the case of VOIP these are the cell systems, smoke signals, etc), then that redundancy can be considered as removing the inevitability.[v]

And if this is what the auditor is implying, then I am in total agreement with him. In fact, I believe the ambiguity regarding the status of VOIP, HVAC and lighting systems, with respect to their status as BCAs, could be completely eliminated if two words (actually, one word and one phrase) were added to the BCA definition: “inevitably” and “similar”. I would advocate that the current CIP v7 SDT add this to their agenda, were that agenda not already overwhelming (more on this point in a post coming soon).

So why did I write this post? After all, there clearly is no danger that entities will be forced to declare their VOIP systems as BCAs. And even though I’ve just stated how I think the ambiguity regarding VOIP can be cleared up, I’m not even forcefully advocating that this needs to happen.

Well, I’ll tell you why I’m writing this post. I’m writing it because it illustrates an unfortunate fact of life regarding the CIP v5 and v6 standards (and almost certainly the v7 ones as well): Sometimes, the only way to effectively comply with and audit a requirement is to interpret a requirement or definition as if it had been written differently. In this case, both the entity and the auditor need to insert two words into a definition. In other cases (and I will illustrate one in another post that is coming soon), both the entity and the auditor need to ignore some of the wording in the requirements.

I used to get very worked up over the fact that, in my personal opinion, the need to do this makes the CIP v5 and v6 standards unenforceable in the strict sense that a fine that is appealed to the courts by an entity would almost surely be thrown out, due to the ambiguity in key areas (almost all having to do with CIP-002 R1 and asset identification). However, I’ve more lately come to the conclusion that this is not worth worrying about. I say this not because my advancing age makes me more mellow (although it does in my case), but because I’ve found so many other examples where requirements or definitions need to be reinterpreted in order to be followed or audited, and where there is about zero probability that these will be fixed in any of our lifetimes. What’s another one or two ambiguities?

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

---

[i] I had to think long and hard before I used the words “what (the SDT) had in mind”. This is because I have written at least one post pointing out that there is no possible way to verify what the SDT had in mind – or more specifically what they “intended” – when they used or didn’t use any particular words. I excuse myself here because I’m really referring more to common English usage (and specifically IT and engineering usage), rather than conducting a hypothetical inquiry into the state of mind of the SDT members when the BCA definition was approved.

[ii] Actually, this whole discussion applies to a lot more than VOIP systems. Any PBX that relies on Cyber Assets to operate would have to be considered as well, not just those that rely on VOIP. However, this issue has always been discussed as relating to VOIP, so I’ll continue to call it that.

[iii] I would much prefer that “Facilities” and “equipment” be removed from this phrase (as well as from Section 4.2 of all of the CIP standards), so that it just referred to “systems”. I have always considered the use of  this phrase to be a huge mistake.

[iv] In an email discussion on this issue with an auditor from another region, he pointed out to me that, if there is only one dissimilar system that backs up a Cyber Asset, then that should not be considered as removing the inevitability of the impact of the loss of the Cyber Asset on the BES. I agree with this, and thank the auditor for pointing it out to me (I’m not going to add this to my proposed new definition, though. If the v7 SDT asks me to draft the complete language of my proposed changes to the BCA definition, I’d be happy to oblige. I would like to see a number of other changes as well, that have nothing to do with the subject of this post). Of course, VOIP, HVAC etc. all have multiple “systems” backing them up, as I have illustrated above. In other words, if there were really only one other way – say a particular vendor’s cell phone system in that area - to get through to the Control Center if their VOIP system were down, then the message really would not get through, assuming both the VOIP and the cell system were down. But it is very hard to imagine a case where there would be no other way at all to get the message to the control center in 15 minutes.

[v] Of course, the entity should not be able to blithely state that there are a lot of alternatives, without documenting that there are any. In the case of VOIP, this shouldn’t be too hard an exercise.

Reminder: Webinar on Supply Chain Security on Nov. 18

On Friday, November 18 from noon to 1:30 PM EST, please join me and other presenters from Deloitte and Cisco for a webinar on Supply Chain Security and Regulation for the electric power industry. The webinar is presented by Utilities Technology Council (UTC). For a full description and the registration link, please go here.

If you aren’t sure you can make it, please sign up anyway; you’ll be able to view the recording when it is available. See you then!

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

This Post has Absolutely Nothing to do with NERC CIP

Cubs Win! Cubs Win!

This blog isn’t primarily about sports, of course, but I do want to call your attention to the extremely prescient call I made in a post in December 2014:

"What are the chances the date actually will be pushed back?  I’d say they’re slightly better than those of the Cubs winning the World Series next year.  But you never know.  It’s been “Wait ‘til next year” for 106 years here in Chicago; one of these centuries, next year will come.”

Of course, I was off by one year (and I really only predicted that they would win the Series in say the next 3 or 400 years), but hey…I’ll take it. Now, you may point out that I wasn’t actually predicting the Cubs would win the Series, only that there was a non-zero probability that they would (perhaps .00001 percent). This is true, but I want to defend myself by underlining one of the realities of living in Chicago as long as I have (which is 44 years, although 26 of those have been in Evanston, Illinois): You could never survive if you got your hopes up for the Cubs every time they won a few games or engaged a promising pitcher – you would be doomed to repeated disappointment and likely suicide. So even admitting there was a non-zero possibility of their winning the Series took an act of extraordinary courage, if I say so myself J. From now on, such courage won't be required.

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

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.