Good Press Article on CIP v5

The article below is literally the best press article I’ve ever seen on NERC CIP – and not just because I’m quoted! A subject like CIP requires a reporter to invest a lot of time to learn it, as well as have a good background on FERC and NERC. Peter Behr has both invested the time and has the background.

This article is reproduced in its entirety, with the permission of the publisher. To see the article online, you can go here.

REGULATION: Grid companies face complex cybersecurity audits

Peter Behr, E&E reporter

Published: Monday, January 11, 2016

An official audit of cybersecurity defenses on the nation's high-voltage power grid begins in April, testing power companies' compliance with new, exacting federal cyber regulations in an ongoing campaign to stay ahead of would-be attackers. The federal rules are mandatory, backed by substantial fines for serious violations. However, grid operators typically will not be graded on a strict pass-fail, zero-tolerance compliance scorecard, according to guidance from the North American Electric Reliability Corp., the federally designated grid security monitor. Instead, auditors will use considerable judgment in assessing how well grid companies have complied with the fifth version of the federal Critical Infrastructure Protection standards (CIP Version 5). The leeway is a consequence of having to write and enforce risk-based rules to ward off constantly evolving cyberthreats against a high-voltage network that is itself in the throes of change, including more digital controls and exposure to the Internet, officials said. And it reflects NERC's goal of gaining cooperation with the industry over the standards, the organization's statements indicate. "We want to show that we don't necessarily have a cookie-cutter approach," said Tobias Whitney, NERC's manager of CIP compliance, speaking in a NERC webinar last month. "Facts and circumstances will dictate how we monitor those entities," he added, referring to the largest grid companies. NERC turned down requests for interviews with compliance officials about the audit process, referring instead to Whitney's comments on the webinar and to guidance documents on its website. "How strictly will NERC CIP 5 be applied? It cuts to the core of the matter," said Lew Folkerth, principal reliability consultant for ReliabilityFirst, one of eight regional industry organizations that NERC has delegated to enforce its cyber rules enforcement responsibilities. "If you cannot strictly apply security standards, then what good are they?" he asked in an interview. "If you apply them too strictly, that is also a problem. "The way things seem to be going is, we are trying to chart a course right down the middle," he added. "We talk a lot about risk-based compliance, risk-based security, risk-based everything. Part of that risk assessment process is, what do the entities truly need to do to protect their systems, without having to dot every i?" Auditors will start with the operating companies whose facilities are most critical to the security of the high-voltage grid and will tailor their inspections to each company's situation, Folkerth said. For example, grid operators that show they are on top of updating software patches to deal with vulnerabilities may get the benefit of the doubt on some other issues, he said. "The audit teams can always go deeper if they need to determine compliance," he said. If a grid company has "a history of not doing their patching properly -- not on time or missing a patch -- I would expect those would be thoroughly reviewed." The CIP Version 5 rules, approved in November 2013 by FERC in its Order 791, markedly expand security requirements over the prior version, which took effect in 2010. FERC has announced it will make its own spot audits of the new rules, an unusual intervention by the agency. FERC staff were not made available to discuss the reasons for the decision (EnergyWire, Nov. 4, 2015). NERC officials have labored for more than 18 months with industry representatives to pin down guidance on how companies can comply. The task has proved so difficult that NERC pulled back compliance guidance that it had issued in April last year on several key issues. "NERC became aware that industry continued to have concerns over the issues after it issued CIP Version 5 Memoranda dated April 21, 2015," a NERC memo recounted. "On July 1, 2015, NERC hosted a small, executive-focused face-to-face meeting to discuss the issues in the CIP Version 5 Memoranda," NERC reported. The meeting included NERC and industry leaders and FERC staff. NERC said there was "convergence on several issues and application of guidance, in addition to identifying areas that need increased guidance or clarity." Wrestling with ambiguity A significant case of ambiguity in the rules involves cyber regulation of communications channels that carry vital data between control rooms to a data collector device (a remote terminal unit, or RTU) in a substation, and then to relays that protect power lines from overloading and overheating, NERC documents show. In a much simplified example, when data or commands travel over "routable" or programmable communication channels controlled by software, there is a risk that attackers could gain access via an Internet breach and block or corrupt the data stream. The CIP regulations generally require cyber protection of such routable channels in strategically vital grid facilities. If, however, data travels over a non-programmable "serial" path such as a traditional telephone line or wireless channel with point-to-point connections, the same cybersecurity requirements don't apply under CIP Version 5. "But there is a gray area," said Tom Alrich, manager for enterprise risk service for Deloitte Advisory in Chicago, Ill., who regularly writes about the CIP process in his personal energy blog. Data may travel over a routable connection from the control center to a RTU but move from there to relays via serial connections. Is that data flow routable or serial? Is it covered by CIP Version 5 or not? "Well, the standards drafting team didn't really address this particular issue, and it turned out to be absolutely huge," he added. "Companies could have to spend millions of dollars if the interpretation is one way or another" to protect thousands of relays on the grid if they fell under CIP regulations, he said. This was one of the issues on which NERC pulled back guidance issued last April. The uncertainty over interpreting this will deter auditors from issuing proposed violations against grid companies, he said. "NERC has said now -- which I agree with -- that the only way to fix the problem is to write new standards to elaborate on the definitions. It needs to be revised. And that is the same thing as revising the standard itself," Alrich said. Alrich said a revision of the standard takes three to five years to complete. He was asked whether cyber risks would persist during that time. "It would be a problem if the entities were just going to blow it off and say, 'You know what, we're just going to declare everything we have to not be externally routable.'" NERC won't be able to issue violations on ambiguous issues while the standards are being rewritten, Alrich said, adding that he expects grid companies to continue interpreting the standards on their own. "My guess is that 99 percent of NERC entities are still going to try to comply to the best of their ability," he said. Folkerth agreed. He advises companies that face uncertainty in the new regulations to make prudent decisions on safeguards. "If they take a reasonable, middle-of-the-road approach, so they're not spending money without good reason, but they are also minimizing their compliance risk, they should be in pretty good shape for the audit," Folkerth said. "I suspect that if any entity is truly not meeting the requirements of the language and standard -- and they should know better -- they are going to get a possible violation written with a fine attached." Alrich said interpreting the regulatory guidance is critical. "I call it 'roll your own.' You basically have to look at all the guidance that comes out," he said. "You have to make a good-faith effort and to learn everything you can. Then, if you make your decision and thoroughly document it, you should be fine. "If you don't bother to do that and say, 'I know you're not going to enforce it, so why don't you take a hike' -- if they do that, they're going to get a violation."

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

The Ukrainian Attack

Today at the S4x16 conference, Sean McBride of iSight Partners (which recently bought his company, Critical Intelligence. I have known Sean for a long time and have great respect for him. I’ve written about him in this and this posts) did an impromptu presentation on the Ukrainian cyber attack on the grid. He immediately answered what was my biggest question: Was the loss of load actually a result of the attack, and not just an excuse for an outage caused by something else?

His answer: Yes it was, although there still is a lot that’s not known about the attack. I won’t go into the details of what he said, especially since they’re evolving. However, I was impressed by one very interesting detail: The loss of load resulted from attacks (perhaps combining physical as well as cyber means) on several Distribution substations.

This gets back to something I just discussed in the previous post: Since NERC and FERC just have jurisdiction over the Bulk Electric System, NERC CIP can never provide a comprehensive solution to the problem of the cyber security of the North American power grid – unless some way is found to incorporate Distribution in there. That will require an act of Congress (not easy to come by nowadays, in case you haven’t noticed) as well as a lot of negotiation with the state Public Utility Commissions, who consider the Distribution grid to be their domain.

I’m sure I’ll have multiple posts on this issue as we go forward (and I’d welcome any comments). But I refer you back to the Maginot Line analogy in the previous post: Ultimately, any effort just to protect the BES will be futile when attackers can simply go around the BES and come in through the Distribution grid. When I wrote this just three days ago, I didn’t think confirmation would come so quickly.

Note 1/15: This news article provides more information on Sean's talk, as well as comments by several other S4 attendees or speakers.

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

S4

If you’re just coming to this blog after my presentation yesterday at Digital Bond’s S4 conference, welcome! I promised at the end of the presentation (actually, all presenters were called “performers” this year, mainly because the new location at the Jackie Gleason Theatre in South Miami Beach allowed a very different experience. I tried to take advantage of this) that you could come to my blog for more information on the ideas I had presented.

I must say that the presentation is ahead of my blog. The presentation lays out at a high level how I think NERC CIP should be rewritten, and in my blog I’m still finishing up my case for why it should be rewritten in the first place (I came to the conclusion that this has to happen only a few weeks ago). But my previous post kind of sets a coda to that, although I’m sure I’ll have more to say about that topic, even while I’m laying out how I think the new CIP should work (which I’m sure will take months, since I do have a day job and I’m trying to have as many conversations with as many people as possible about what the new CIP should look like).

For anyone interested, I’ll be glad to send you my slides if you email me at talrich@deloitte.com. The “performances” were videotaped and will be posted on Digital Bond’s web site, although it may take a few weeks for that to happen. I’ll put up the link here when it is posted. I do think this may have been the first cyber security presentation ever that was accompanied by a gospel trio, but I’ll need to check my book of world records to confirm that.

However, in case you’re wondering, I’m not going to lose my focus on CIP versions 5 and 6, since these will undoubtedly be with us for at least 2-3 years (my fear is it will be longer than that, but I hope that’s not the case). NERC entities still need to do their best to comply with these standards, and I will still do my best to pass on whatever good advice I hear from others or think of myself. Even though I’m still in Miami Beach, it doesn’t mean I have my head in the clouds.

Meanwhile, I’d certainly welcome hearing from anyone who wants to write me (or to post comments on the blog) about how you think NERC CIP can be rewritten. Of course, I would never post what you say, even anonymously, without your permission.

  

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

Getting to the Root of the Problem

Harvard dropout Henry David Thoreau, when told “They teach all the branches of knowledge at Harvard”, famously replied “Yes, but none of the roots.” In a similar fashion, I feel I have been dealing with the branches of the problems with NERC CIP; I now wish to get to the root. 

Up until now, when I have referred to the “fundamental issues” in CIP v5, I am talking mainly about the ambiguities and contradictions in the asset identification process, namely CIP-002-5.1 R1 (and Attachment 1) and the definition of External Routable Connectivity (which is tied to CIP-005-5 R1). I have written fairly recently that these fundamental issues can be fixed through rewriting CIP-002 R1 and Attachment 1 (including definitions associated with them, primarily the Cyber Asset and BES Cyber Asset definitions); in addition, the ERC definition needs to be rewritten.

However, I no longer believe the real fundamental problems with NERC CIP can be fixed through the above changes; in fact, I don’t believe any rewrite of CIP-002-5.1 R1 and the ERC definition could fix these problems. Even if NERC followed my previous suggestions and constituted a new drafting team to rewrite these items, and even if the team were composed of the greatest minds of the century, I no longer believe this would address the root of v5’s problems, or for that matter of NERC CIP’s problems in general. I believe that only a complete rewrite, in a completely different format, will fix those problems.

What are the problems in CIP v5? I have written close to 100 posts (maybe even more) on this issue; the first was this one and the most recent was this one. To briefly summarize, the problems include:

• There are ambiguities and outright contradictions in CIP-002-5.1 R1, the “fundamental requirement” of CIP v5. Until fairly recently, I thought that the solution to this problem was to rewrite the requirement, as well as Attachment 1 of CIP-002. I no longer believe this will help. I have come to believe that any attempt to have some sort of purely objective process for determining what needs to be protected by NERC CIP is bound to fail. There is far too much variability in the electric power industry for NERC or any other organization ever to develop such a process.
• The concept of External Routable Connectivity is essentially part of the CIP v5 asset identification process, but I think it’s been well proven[i] by now that this is a black hole. Just as in CIP-002 R1, I don’t think there is any way to come up with a definition of ERC that will magically solve the problem: namely, how to treat cyber assets (primarily relays in substations) that are serially connected to a device like an RTU that is itself routably connected to a control center. Since about ten requirements in v5 only apply to devices with ERC, this leaves a big hole in the standards. And by the way, I've also come to the conclusion that "programmable" is a black hole. No amount of meetings could ever identify a "definition" of this term that would satisfy most of the NERC community.
• Because the standards development process is so long (the Standards Drafting Team that developed CIP version 5 first met in 2008, so it will be eight years before their effort reaches fruition this April. What they were originally aiming at was what became CIP v5, although they ended up having to develop CIPs v2, v3 and v4 before they could get to v5), the threats that scare everybody at the beginning of the process are no longer as important as those at the end of the process; on the other hand, there are newer threats that were not considered important originally, but are now huge. One example of this is the threat of phishing, which was never considered to be a big threat by the SDT (and I would have agreed on that point if asked at the time), but – as shown by the very recent cyber attack on the Ukraine power grid, which seems to have been facilitated by malware spread through phishing – now needs to be one of the top threats to the grid, in my ever-so-humble opinion.
• Another big problem is that the Distribution grid is completely out of scope for NERC CIP, while it clearly constitutes a huge percentage of the number of power sector assets in the US.[ii] This brings to mind the Maginot Line, the seemingly impregnable line of fortresses that France built along their border with Germany after World War I. The problem wasn’t that the line itself was vulnerable – the Germans never even tried to break through it. Rather, the problem was that it stopped at the Belgium border. So guess how Germany invaded France? And if you were a cyber attacker, how would you “invade” the US grid? Would you attempt a frontal assault on the Transmission grid, knowing that it has been subject to NERC CIP for some time? Or would you attack the Distribution grid, which currently is subject to few if any cyber security regulations? [iii]
• The biggest problem I now see with CIP – and this problem existed in the previous CIP versions, although it has been greatly compounded in CIP v5 – is the fact that, of the large amount that most NERC entities need to spend on compliance, a significant percentage of that goes to compliance paperwork, not cyber security.[iv] Admittedly, a lot of documentation is needed for cyber security purposes, such as documentation of security procedures. But there’s also a lot of documentation that is there simply so an entity can prove it did something. If CIP had been proven to be the ideal set of cyber security standards for all BES asset owners, there might be some justification for this. However, don’t be shocked if I tell you that I don’t think CIP constitutes that ideal; nor do I think that an ideal set of standards could ever be developed, even if we gathered all of the Founding Fathers – along with Abraham Lincoln, Mahatma Gandhi and Mother Theresa - together to write it.

These are the problems with CIP v5[v] – i.e. the branches. What is the root of these problems? I think it’s fairly simple: The NERC standards format is a very prescriptive one. I don’t think cyber security standards can ever be successful when written in such a format. This is because cyber security protection is a statistical process. For example, if you don’t update antivirus signatures on one system for one day, it’s not very likely that anything bad will happen. If you never update antivirus on that system, or even more on any system at all, it is almost inevitable that something bad will happen.

Why are NERC standards prescriptive? Because that is how NERC standards work.  They are written to prevent entities from either taking or not taking particular acts, the consequences of any one of which may lead to a catastrophic outage of the Bulk Electric System. If there is a misunderstanding between control centers due to a failure to follow the COM standards, there could well be an immediate grid event. But as I’ve just said, cyber security protection is statistical, not deterministic like most of the other NERC standards. It is highly improbable that a grid event will be caused by an electric utility not applying a particular patch, within 35 days of its release, to one system. However, it is certainly possible that the same utility’s failure to apply a patch to any of its systems for say three months after the patch’s release could lead to a grid event.

Over the next few months, I will be discussing how I think NERC CIP should be rewritten to address these problems. Before I leave, I do want to make the point that rewriting CIP the right way isn’t likely to happen anytime soon – there is right now no constituency for this move that I know of. Nevertheless, while I've been a big advocate of having NERC rewrite at least CIP-002, I now don't think that is worth the effort. I honestly think the best approach is for NERC to write a SAR to put the CIP v5 standards on a risk-based basis, like CIP-014 is now. Anything else is a waste of time.

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

---

[i] My last post, of the maybe ten that I’ve done on ERC in various forms, was this one. I want to put together a post summarizing where I think things now stand on this topic, but I now feel the discussion has gone way beyond usefulness. If you look at the very fine-tuned “definition” of ERC in the post just linked, you may agree with me that there’s no way this could actually be enforced on a wide scale. Bottom line: In cases where there is a mixture of routable and serial connections in one communications stream, it is up to the entity to decide whether this constitutes ERC or not, period. I’m fine if NERC wants to try to rewrite the definition to try to address these cases, but I predict that whatever they come out with will never be more enforceable than the current definition is.

[ii] A paper by the California Public Utilities Commission in 2012 estimated that 90% of the grid assets in California at the time were Distribution assets, not Transmission ones. This is a very good paper – primarily discussing how a set of risk-based standards for cyber security could be applied to the distribution grid - and is still quite relevant. But it seems to have been removed from the CPUC’s website. If you would like me to send you a copy, email me at talrich@deloitte.com.

[iii] I will readily admit that this particular problem can’t be addressed by NERC at all. There would need to be literally an act of Congress to bring all of the Distribution grid under cyber security regulations – regulations that would perhaps still be developed by NERC, or perhaps by DHS or DoE, or maybe some other entity entirely. But in the end, it won’t do any good simply to throw up our hands and say, “NERC doesn’t have any authority over the Distribution grid”, just like one wishes with hindsight that the developers of the Maginot line had tried to figure out a way to protect Belgium despite the fact that it was a different country.

[iv] I haven’t done any sort of scientific study, but when I’ve asked some CIP compliance professionals what percentage of their organization’s CIP v5 expenditure actually goes to cyber security, the highest number I’ve received is 70%; the lowest is 30%.

[v] I’m sure there are a few others that aren’t coming to mind at the moment. In case you haven’t realized it yet, this will be the first of many posts discussing how to (once and for all) solve the problems of NERC CIP.

S4X16

For those of you who don’t know, Digital Bond’s S4X16 Week is considered by many to be the leading Industrial Cyber Security conference in the world. This year’s conference will be held Jan. 12-14 in Miami Beach, and I’m told you can still sign up for it.

I bring this up because I will be one of the presenters – although the official word this year is “performers” - at their Main Stage event at the Jackie Gleason Theatre on Jan. 12. I got into this because Dale Peterson, the founder and president of Digital Bond, asked me last summer if I would discuss an interesting topic: how I would rewrite NERC CIP if I had carte blanche to do so.

When Dale asked me this, I thought it was a very intriguing subject, although of not much practical interest because the idea of rewriting CIP from scratch was a) wildly improbable and b) not really necessary. In other words, I thought that what was needed to make CIP a workable set of standards was just to rewrite a few parts of it (primarily CIP-002); a wholesale rewrite wasn’t needed and would be very unlikely in any case.

Well, things have changed since then. I will soon be writing at length (the only way I know how to write, of course) about why there is no point in simply trying to fix a few parts of CIP v5. In my opinion, the whole current CIP framework needs to be rewritten; my presentation will lay out how I would rewrite it, from a high level. The details will come in future blog posts. Whether it’s probable this will happen…that’s something I will work on – in my presentation, blog posts, etc.

Dale’s mandate to all of the performers is that our presentations be entertaining, and he has provided the talent resources to us to make this happen. I won’t reveal more details, but I venture to say that my “performance” – and probably the others that day – will be very entertaining. Come if you can.

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

Lew Folkerth Discusses Implicit Requirements in CIP v5

I have mentioned in at least a few posts the idea of “implicit requirements” in CIP v5 – that is, things an entity needs to do to comply with the written requirements, that aren’t actually stated as requirements. I believe I have also acknowledged (at least I hope I have) that this idea wasn’t mine but that of Lew Folkerth, Principal Reliability Consultant with RF.

Even though I may not always have identified them as such, my posts on CIP v5 have been loaded with implicit requirements – to identify Cyber Assets, BES Cyber Assets and BES Cyber Systems in CIP-005-5.1 R1; to develop and document a methodology for determining whether there is External Routable Connectivity for substation relays that are connected to a device like an RTU which is then connected through IP to a control center; etc. I have even put together a document listing all of the implicit requirements I have so far identified in v5 (it is growing all the time, of course).[i]

At RF’s CIP v5 workshop in Cleveland on October 1, 2015, Lew – in response to a question – said he would “look into” preparing a list of implicit requirements in v5. He published an article in the most recent RF newsletter (pages 8 and 9) in which he discusses what he found when he did look into this. As with everything else Lew writes on CIP, I strongly recommend you read this article, whether or not you’re in RF (there is nothing in it that just pertains to RF. In fact, I don’t recall anything he’s written on v5 that doesn’t apply to all NERC entities, no matter which Regional Entity they’re part of. I believe you can find the archived newsletters on the RF site; Lew’s articles are always under the heading “The Lighthouse”).

Lew admits up front that he doesn’t have a list of implicit requirements to provide. Moreover, he admits he will not be providing one in the future, either. This is because “My opinion is that we may never be able to achieve a complete list of implied requirements; the more we mature in our understanding of CIP Version 5, the more implied requirements we will find.”

You may wonder why Lew can’t provide at least an incomplete list – after all, wouldn’t it be better to have a partial list of implied requirements than no list at all? I believe the answer to this question (although I haven’t discussed it with Lew) is that, if someone in NERC (and of course, the Regional Entities are all part of NERC, or the “ERO Enterprise”) provides a partial list of implied requirements, entities will complain if they are later cited for missing an implied requirement that isn’t on that list. There is really no way he can provide this list, given his current job responsibilities.

I find the above statement of Lew’s to be very significant for another reason: I think it raises serious doubts about whether NERC CIP version 5 can ever be “enforceable” in the strict sense of being upheld in the US court system. I will have more to say on this point (a lot more, in fact) in one of my next posts. However, I also do have a few comments on Lew’s article, which I’ll discuss now.

Lew states close to the beginning of his article that “Implied requirements are a consequence of writing CIP Version 5 as results-based Standards.” This is an interesting idea, but I believe it’s contradicted in the section titled “Sources of Implied Requirements”. In that section, he lists four cases in which implied requirements can arise. I agree with everything he says in this section, but note that the second of these four cases is “Results-Based Specification”. If this is only one of four ways in which implied requirements arise, how can Lew’s initial statement that implied requirements arise from “results-based standards” be true, since it clearly is meant to apply to all implicit requirements? My personal opinion is that the only general statement that can be made about all implicit requirements in CIP v5 is what I said in the first sentence of this post - they are things an entity must do to comply with one or more v5 requirements, which are not themselves stated in a requirement.[ii]

As I said, I do completely agree with the section entitled “Sources of Implied Requirements”. Lew wrote this section to give entities a way to identify implied requirements on their own. Since he can’t provide them with his own list, this is obviously the next best thing that he can do. I think all of the four “sources of implied requirements” he lists can definitely lead to implicit requirements, although I would think there are some implicit requirements that don’t spring from one of these sources.[iii]

However, I don’t agree with the next section of the article, “Failure to Comply with an Implied Requirement”. It states in part “If an implied requirement is violated, an audit team will return a finding for the Requirement that is supported by the implied requirement. Since an implied requirement may support multiple Requirements, a violation of the implied requirement may result in multiple audit findings. An example of this would be the failure to identify and protect an EACMS associated with a high impact BES Cyber System. Failure to identify and protect each EACMS could potentially result in an audit finding in 64 Parts of 18 different Requirements.”

I agree that there are some implied requirements – like the implied requirement to identify all EACMS associated with high BCS – which are quite evident. If you’re not required to identify your EACMS, how could you possibly comply with all the requirements that apply to EACMS? If you don’t identify your EACMS out of pure stubbornness, I can see a PV is justified. But there are other implicit requirements that are not clearly implied at all.

For example, I think every Regional Entity will require that an entity being audited present a list of “Medium impact” substations, or more correctly “substations that contain at least one Medium impact BES Cyber System”. This is an implied requirement, but it is also not one that can be easily identified from the wording of CIP-002-5.1 R1 or Attachment 1 (in fact, I believe it can’t be identified from that wording[iv]).

In a case like this, I think it would be very hard for an auditor to actually issue a PV for violating that implicit requirement. My guess is, if the entity doesn’t have the list of Medium substations, the auditor will simply ask them to draw one up.

And going back to Lew’s example of an entity that failed to identify one or more EACMS and thus didn’t comply with 64 parts of 18 requirements, I find it very hard to believe they would receive any PVs at all because of this – unless they had simply pretended that they didn’t have to identify any EACMS and therefore none of the requirements that apply to EACMS applied to them. Except in that extreme case, I think most failures to identify EACMS will be caused by confusion over what exactly the definition applies to (or perhaps whether or not ERC is present); and as I’ve said in several posts including this recent one, I don’t think any PVs will be issued for these cases until there is general agreement in the NERC community on the many areas of ambiguity in v5 – which will probably be at least a year after April 1, 2016.[v]

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

---

[i] Deloitte Advisory provides this document to entities that decide to take advantage of the free CIP v5 Quick Check, described in this post.

[ii] I also disagree with the example Lew uses to illustrate a “results-based specification”. It is CIP-002-5.1 R1. I disagree that this requirement is “results-based”. As I discussed in this post from 2014 (in the section labelled “Issue 4”), because of the ambiguities and missing definitions in R1, there can never be a definitive statement of what results are required by R1, other than to get into a curious argument: a) R1 requires the entity to properly identify and classify its BES Cyber Systems. How does the auditor determine whether or not the entity has done this properly?; b) The auditor needs to determine whether they have properly followed the procedure described in the requirement; c) But Lew has just said that much of what is required by R1 is implicit – how can the auditor possibly say they have followed the correct procedure or not, other than to use his or her own personal judgment?

I followed up the 2014 post with this post, which made the point that calling CIP-002-5.1 R1 a “results-based” requirement leads to a completely circular argument, where a correct “result” of the requirement can only be determined by whether or not the requirement has been “properly” followed – and the only way to determine whether it has been properly followed is to know what the result should be!

[iii] My guess is some implicit requirements are implicit simply because the Standards Drafting Team didn’t think to include them; there is simply no further reason. Someday I would like to go through my list to see which implicit requirements are due to one of Lew’s “sources of implied requirements”, and which ones are simply there because of SDT error.

[iv] The reason this is the case is that the criteria that apply to substations – 2.4 through 2.8 – all use the word Facilities as their subject. A Facility is a line, transformer, etc. – but not the substation itself. Literally every entity or auditor that I have talked to either a) thinks “Facility” means the substation or b) knows that it doesn’t, but is choosing to treat it that way because of the complications of trying to classify BCS in a substation according to the Facility they’re associated with, not the substation itself. Effectively, these criteria do apply to substations, and a list of Medium substations is implicitly required. On the other hand, this isn’t what the wording says.

[v] There is another consideration here: I believe there has been some sort of unofficial doctrine in place among the CIP auditors since CIP v3, to the effect that a failure to identify a particular cyber asset in scope (e.g. a Critical Cyber Asset under v3 or a BCS under v5) will at most lead to a PV for violating the original identification requirement (CIP-002-3 R3 or CIP-002-5.1 R1), but not to PV’s for missing other requirements due to not having identified that cyber asset as in scope. If that is the case, then at worst the entity would receive a single PV for not having identified an EACMS – and frankly, even that is hard to support since there is no requirement that even implies EACMS need to be identified. If a PV is issued for not identifying an EACMS, what requirement would it apply to?

NERC Interprets CIP v5 (and 6)!

I have been saying for close to two years that NERC (or perhaps the regions) needs to come up with an informal “interpretation” of the many ambiguous (or contradictory) areas in the wording of CIP v5. It can’t be an official Interpretation, since that can only be triggered by a Request for Interpretation and that process takes a couple years at least.[i] So NERC can’t produce anything that’s binding, but I have always wanted them – or somebody – to provide some non-binding interpretations of the ambiguous areas in the v5 wording.

NERC has produced some Lessons Learned, but they are deliberately not interpretations of the wording – rather, they provide helpful guidance on how other NERC entities are addressing different CIP v5 challenges. Whenever NERC has tried to take a stand on what particular wording means, this hasn't worked (as was the case with the five Memoranda that they released in April and withdrew in July).

I decided a while ago that NERC would never provide little-“i” interpretations, and therefore it was completely up to the entities to come up with (and document) their interpretation of each of the ambiguous areas in v5 – “programmable”, ERC, “adverse impact on the BES”, etc.

I still believe this is the case. However, I was pleasantly surprised to see that NERC has identified one vehicle by which they can provide some little-“i” interpretations. I’m referring to their “CIP Version 5 Evidence Request User Guide” that was published on December 15, 2015.[ii] Of course, NERC doesn’t tout this document as one that interprets ambiguities in v5; instead, it is meant as a supplement to the RSAWs, which – according to the document – have been described as lacking in detail by “industry representatives”.

The actual Evidence Request is an online tool; the Guide is simply that – a guide to using the tool. However, I find it provides some useful interpretation information, since there is no way anyone could write evidence requests for requirements in v5 that are ambiguously worded, without in the process taking some position on what that wording actually means.

This post tries to “reverse engineer” the questions in the Guide to identify the interpretations that were used to generate them. This is a pretty roundabout way to glean NERC’s interpretations, but – hey, you can’t be choosy when it comes to finding interpretations of CIP version 5! The Guide is divided into sections with short acronyms; my post is divided the same way (although I don’t address all of the sections in the Guide; just the ones where I found something interesting that should be reported).

I do want to say that my main criticism of this document is that it doesn’t address more than maybe 1/10^th of the major interpretation issues in v5. However, at least it does something, and that’s a help. Its biggest achievement is acknowledging for the first time that virtualization needs to be accommodated by the v5 standards, even though it is nowhere mentioned in the standards themselves.

BES Assets

As with almost all presentations on CIP-002-5.1 R1 (that I have seen or read), the first section of the Guide deals with the “big iron” – the assets that house the Cyber Assets in scope for CIP v5. What I say in this section will be more understandable if you reread this post.

1.       The first item in this section is “Asset Type” (page 4). This means the entity should start by identifying its assets in scope for CIP v5, confining their list to assets that meet one of the six types listed in R1. As I said in the above-referenced post, this is how virtually all auditors and entities understand R1 to read; so it should be followed. However, this isn’t how the requirement (or Attachment 1) actually reads.

2.       Two items at the bottom of page 4 read “Contains BES Cyber System – High Impact” and “Contains BES Cyber System – Medium Impact”. As I discussed in footnote ii of the previous post, using this wording rather than “High Impact Asset” and “Medium Impact Asset” fits a little more closely with the wording of R1 and Attachment 1, but less closely with how NERC entities and auditors actually understand the R1 process. Virtually every entity (and every auditor) that I have ever heard present or talked with starts with classifying their assets, not their BCS; it would be better not to pretend this isn’t really what they’re doing, and just refer to High and Medium impact assets – which then lead to High and Medium BCS.[iii]

CA

This is the first official NERC document I’ve seen that recognizes that virtualization is now a big part of many computing environments subject to NERC CIP. The paragraph titled “Cyber Asset Function” on page 7 allows for identifying a Cyber Asset as a “Virtual Host”.

VM

Even more striking than the mention of Virtual Hosts is the fact that there is an entire section on Virtual Machines (VMs). In this section, you identify and provide information on your VMs in a similar (although not identical) manner to how you had to enter your Cyber Assets in the previous section (that section makes clear that only physical devices can be Cyber Assets, which is why VMs have to be handled separately).

The first paragraph of this section (page 9) immediately recognizes an important fact: that there can be multiple hosts capable of running a particular VM. This means that each host should be protected appropriately for all VMs that are capable of running on it (for example, if all the VMs capable of running on a host are Low impact, the host itself only needs to be protected by the Low requirements. But if one High VM could potentially be run on this host, then it has to be treated as a High from the start – not just when that high VM is actually moved to it. This is not stated in the Guide itself, but I believe this is a reasonable inference from it).

BCS

I’ve stated in a couple of posts (here and here) that CIP v5 allows entities to group BES Cyber Assets differently into BES Cyber Systems for different requirements. However, this conclusion just came from the fact that this isn’t actually prohibited in CIP-002-5.1 R1.

Now NERC has provided a positive acknowledgement of this idea in the second paragraph of the BCS section (page 10), which states “If all BES Cyber Systems are used to meet the obligations of all CIP Standards, Requirements, Parts, and Attachment Sections, then the ‘BCS’ tab should be used.” Furthermore, there is another tab - “BCSdetail” - that can be used to enter information on BES Cyber Assets that are included in more than one BCS, depending on the requirement.

CABCS

The first paragraph of this section (page 12) reads “The ‘CABCS’ tab is used to logically group Cyber Assets into one or more BES Cyber Systems, and to associate supporting Cyber Assets with BES Cyber Systems. For each Cyber Asset, specify the BES Cyber System into which it has been logically grouped or with which it is associated. Provide one row for each Cyber Asset/BES Cyber System grouping or association. Indicate the type of the association (‘Member of BCS’ or ‘Associated with BCS’).”

I must admit that I haven’t previously seen the distinction that is being made here, between a Cyber Asset being a “member of a BCS” and being “associated with a BCS”. Of course, the meaning of membership in a BCS is quite straightforward. The definition of BES Cyber Asset includes this sentence: “Each BES Cyber Asset is included in one or more BES Cyber Systems.” That is what “membership” means.

But what does “associated with a BCS” mean? The only meaning I can think of is that EACMS and PACS are “associated with” BCS in the “Applicability” column of some requirements. If that’s the case, this only applies to those two categories of Cyber Asset, not to all BCAs. Yet this question implies that all BES Cyber Assets are either a member of a BCS or associated with one – but that doesn’t make sense either, since EACMS and PACS aren’t necessarily BCAs, meaning they wouldn’t normally even encounter this question in the first place.

This also doesn’t refer to Protected Cyber Assets, since the user has already identified these in the CA section. Did someone get confused by the fact that Section 2 of Attachment 1 describes Medium impact BCS as those “associated with” one of the Medium impact criteria? This of course refers to an association with an asset, not with another BCS.

Since I don’t see this idea recurring anywhere else in the document, I guess it doesn’t do any harm, other than confuse people. If anybody has an idea what it means for a BES Cyber Asset to be “associated with” a BCS, please let me know, and I’ll share it with my devoted readers.

ESP

One of the paragraphs in this section (page 13) reads “Is External Routable Connectivity Permitted into the ESP? This column contains a pull-down list. TRUE should be selected if this ESP contains a Cyber Asset with External Routable Connectivity. Otherwise leave blank.” This alludes to a point that Lew Folkerth of RFC made in an RFC newsletter, which I reported in this post: If ERC is allowed for at least one Cyber Asset within an ESP, all of the other Cyber Assets (whether they be PCAs, BCAs, or just Cyber Assets) will ipso facto also have ERC.

EAP

One finer point that people often forget about (at least I do!) is that an Electronic Access Point isn’t a device like a firewall, but an interface on that device. This section (page 14) makes that point clear, as well as the fact that the device that contains the EAP will always be an EACMS (but the converse isn’t true. Other devices like AD servers can be EACMS even if they don’t contain an EAP).

TCA and TCA Non-RE

There are good sections describing information required for Transient Cyber Assets (page 15) and TCAs that are managed by a third party and thus treated differently in CIP-010-2 R4 (page 16).

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

---

[i] It has previously taken at least two years for NERC (really, an Interpretations Drafting Team) to develop an Interpretation, submit it to a few votes by the NERC ballot body, get NERC Board approval, submit it to FERC for them to ponder for a while, then wait to see whether or not FERC approves it (they rejected the last two Interpretations for CIP v3 in 2012).

EnergySec reported in their Dec. 23 NERC CIP Newsletter that the NERC Standards Committee Process Subcommittee (SCPS, for those keeping score at home) had decided this process needs to be streamlined. That’s the good news. The bad news is that they will take 12 months just to recommend changes; these will of course have to be debated and voted on by the NERC membership, etc. EnergySec also reported that the full Standards Committee has decided that all work on the two RFIs that were accepted in September should be put off until at least next April 1, and that it should be coordinated with the re-drafting of certain standards that the current Standards Drafting Team is starting to undertake now. Bottom line: Don’t look for finalized CIP v5 Interpretations with a capital “I” for years.

[ii] I learned of this document through EnergySec’s NERC CIP Newsletter of Dec. 23. Would you like to get the newsletter? Join EnergySec!

[iii] You may have noticed that I always capitalize High, Medium and Low in the context of classification of assets and BCS, even though the CIP v5 requirements all use lower case; I have had more than one person point out to me that I shouldn’t capitalize common words that aren’t defined in the NERC Glossary. I do this for a reason: I have seen a number of people (including one who presented on the asset identification process at a regional meeting) misunderstand these terms to mean that the entity should simply make their own judgment on whether the asset or BCS has a high, medium or low impact on the BES. While there is some support for this idea in the wording of CIP-002 (the problem is that there is support for a number of contradictory ideas in that standard!), it is definitely not the case that this is a matter of the entity’s judgment. For better or for worse, it is a matter solely of the meaning of the Attachment 1 criteria. Judgment has nothing to do with it, except that the criteria themselves require a fair amount of judgment to interpret. But that’s another post.