The SDT Breaks new Ground – Part 1

As most of you hopefully know, there is a NERC Standards Drafting Team that is currently drafting modifications to the CIP standards in the “post CIP v6” world; they are known as – get ready now – the Modifications to CIP Standards Drafting Team. I won’t use the term CIP v7, since as I’ve pointed out previously, after CIP v5 there won’t be any more comprehensive changes to the CIP standards as a whole (“CIP v6” wasn’t really a new version of the CIP standards as a whole, but small changes – or none at all – to some of the CIP standards, along with new requirements in two of the standards). The changes the SDT is drafting will appear in new versions of some of the standards, such as CIP-003-7 (which includes the new “LERC” requirement approved by FERC in April) and CIP-002-6 (which will include the new criterion 2.12 for Control Centers run by a GO on behalf of a GO), as well as CIP-012 (the upcoming standard protecting communications between Control Centers). The CIP Mods SDT has drafted or will draft all changes to the CIP standards since version 6, with the exception of CIP-013, which had its own SDT.

Like all NERC SDTs, this one is guided by a Standards Authorization Request (SAR) that describes the tasks it must accomplish (I don’t think there’s any provision in any NERC SAR saying that the SDT members have to accomplish the tasks in their SAR or die in the attempt, but they nevertheless take their jobs very seriously). These fall into two types: tasks mandated by FERC and those mandated by NERC. Of course, the former tasks have to be done – some have a specific deadline from FERC, others don’t – while the latter are important, but it’s not inconceivable that an SDT wouldn’t be able to finish all of their tasks (although this has never happened previously with an SDT working on the CIP standards, as far as I know).

I described the SDT’s SAR when it was approved in early 2016. Since I had previously discussed FERC’s mandates when I wrote about Order 822, I didn’t spend much time discussing those in this post; instead, I wrote lengthily on the seven items that were put on the SDT’s plate by NERC itself (and specifically the CIP version 5 Transition Advisory Group, which of course has now finished its work). The seventh of these was virtualization. I didn’t assign it the number seven because of some spiritual significance, but I’m now beginning to believe that might not be too far off the mark.

My original idea of what the SDT would have to do in order to include virtualization in the CIP standards was twofold:

1. They would need to change the definitions of Cyber Asset and BES Cyber Asset to allow for “virtual” cyber assets.
2. They would have to change prescriptive CIP requirements like CIP-007 R2 and CIP-010 R1. Because these requirements are so prescriptive, they couldn’t easily be adapted to accommodate a widened scope, including virtualized cyber assets. 

When the SDT started meeting, they focused immediately on the most urgent item in the SAR: FERC’s mandate to clarify the meaning of the word “direct” in the definition of Low impact External Routable Connectivity (LERC), which had a one-year deadline (of course, this is what led to the revised electronic access control requirement in CIP-003-7). The next time I wrote about virtualization (and the last time before this post) was in January 2017, when I wrote a post comparing the CIP Mods and the CIP-013 drafting teams. At the end of that post, I calculated (and not really with tongue in cheek) that, based on the number of changes to CIP requirements and definitions that the head of the sub-team addressing virtualization had said were needed to implement virtualization, the SDT would be working on just this one issue for the next ten years (meaning, of course, they would never finish it, since no SDT is going to remain in existence for ten years, especially working on one particular topic like virtualization).

My skepticism about whether the SDT would ever complete the virtualization task in their SAR was only heightened a few months later, when the SDT put on a couple of good webinars discussing where they were on this topic. I found the webinars very interesting because of the ground-breaking concepts they had developed, especially the concept of an Electronic Security Zone, which generalized the ESP concept to include virtual cyber assets. On the other hand, I never understood the ESZ concept – which is very abstract – and I found it very hard to believe that the SDT would ever be able to get the NERC membership to approve this and put their lives in the hands of auditors who won’t understand the ESZ concept any better than they do.

So my advice to the SDT at that point – which I communicated in private a couple times but I don’t believe I ever did in this blog – was to essentially follow the advice that Senator George Aiken was reputed to have provided about the Vietnam War: that the US should “declare victory and go home”. I suggested that the work the sub-team on virtualization had done, including especially the ESZ concept, could be put into a pretty nifty white paper, which could have a wide application for almost any organization that was trying to figure out how to secure its virtual systems – not just for electric utilities. But trying to go ahead and translate all of these nifty ideas into concrete changes in the prescriptive NERC CIP requirements, as well as in the Cyber Asset and BES Cyber Asset definitions, was simply inviting huge, and likely losing, battles with the NERC membership.

At that point, I pretty much decided that the SDT would sooner or later follow my advice on virtualization and abandon the idea of ever passing a ballot with all the needed changes to the CIP requirements; I focused more on the other things the SDT was working on, like developing the electronic access control requirement in CIP-003-7. So I was quite surprised when, a few months ago, I started getting mailings from the SDT about a lot of phone meetings they were starting to have to discuss changes to the CIP standards to incorporate virtualization.[i]

Unfortunately, I couldn’t attend more than a couple of these meetings, and while I found them very interesting, I didn’t get the whole picture of what the SDT was doing. Instead, I concluded the entire group had embarked on a lemming-like migration over a cliff, determined to force a whole slew of difficult changes down the throat of a NERC membership that would probably simply regurgitate the whole thing back at them; this would leave the SDT with nothing to show for two or three years’ effort. I saluted them for their doggedness, but I hoped they weren’t really serious about this.

So I was quite interested when the SDT put out a draft white paper a few weeks ago that described their new approach to the virtualization problem, and followed that up with a good webinar on Friday (the slides and recording of the webinar will be posted on NERC’s website soon. If you would like to see the white paper, you should email me at tom@tomalrich.com, since this isn’t posted on the SDT’s web page).

In a nutshell, the SDT has decided there are two ways (they call them “forks”) to get to the goal of incorporating virtualization into the NERC CIP standards. One is the brute force approach that seemed to be the only one available to them a year ago: make changes to the Cyber Asset and BES Cyber Asset definitions to accommodate virtual systems, get approval for the Electronic Security Zone concept and perhaps one or two other new definitions, then finally make the many needed changes to the CIP requirements themselves, so that the various requirements will accommodate virtual cyber assets and networks.

It was quite clear in the webinar that the SDT no longer considers the first fork a serious option. Instead, they have come up with two great ideas which may (it’s certainly far too early to say “will”) bring two great benefits:

1. Incorporating virtualization into the CIP standards will be much quicker than I had thought possible. The drafting team has set the goal of having a first draft available for comment and subsequent ballot in September, and final approval by the NERC Board of Trustees (meaning the usual multiple ballots will culminate in passage of all the required changes by then) next August. I am going to add another year to this process and say BoT approval by August 2020 is possible, but even that is still much earlier than what I previously thought was the earliest date for final approval (i.e. never).
2. One of the two ideas will not only allow virtualization to be included in CIP, it will make CIP compliance much easier for entities with non-virtualized cyber assets as well (i.e. every entity with High or Medium impact assets). 

So what are these two great ideas (and I honestly wish I’d thought of both these things myself)? In my own words:

1. All of the current CIP requirements apply to BES Cyber Systems, which are defined as simply groupings of one or more BES Cyber Assets. BCAs are the fundamental assets in scope for CIP (i.e. all of the elements of what makes a BCS more than just any old system are found in the BCA definition, especially the 15-minute impact on the BES). Why not simply do away with Cyber Assets and BES Cyber Assets altogether, and simply require the entity to identify its BES Cyber Systems to begin with? The 15-minute impact language will now be included in the BCS definition, eliminating the need to even consider what’s a Cyber Asset and what’s a BES Cyber Asset. And since a system, not a device, is now fundamental, the problem that I fixated on, of how you extend the Cyber Asset and BCA definitions to include virtualized assets, disappears altogether. It is very easy to designate a particular set of VMs (or even a mixture of VMs and non-virtualized devices) as a system, just as easy as it is to designate one or more physical devices as a system.
2. Instead of beating their head against the wall, trying to figure out the many changes to prescriptive requirements like CIP-007 R2 and CIP-010 R1 that would be required to accommodate virtualized cyber assets, the SDT will simply rewrite those requirements so they are non-prescriptive (and they use the example of CIP-007 R3 as a non-prescriptive requirement they would like to emulate). Then it’s up to the entity to decide what’s the best way to mitigate the risk addressed by the requirement (risk of malicious code in the case of CIP-007 R2, and risk of malicious configuration changes in the case of CIP-010 R1), based in part on whether the BCS in question are physical, virtual or both. 

For the first idea, I see a few potential problems but no potential show-stoppers – although I won’t rule out the idea that show-stoppers may come up later. For the second idea, I definitely see some potential show-stoppers, although none of them wouldn’t be surmountable by the SDT.

The next post in this series (presumably within a week), will discuss my issues with the second idea, which are much more fundamental. I will probably have to do a third post discussing my issues with the first idea, which aren’t quite so fundamental.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC.

If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com. Please keep in mind that if you’re a NERC entity, Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed in this post – especially on compliance with CIP-013. And if you’re a security vendor to the power industry, TALLC can help you by developing marketing materials, delivering webinars, etc. To discuss any of this, you can email me at the same address.    

   

---

[i] If you want to get emails about what the CIP Mods SDT is doing, as well as invitations to phone and in-person meetings, email Jordan.mallory@nerc.net.