For the first time, there are now two – count ‘em! – NERC drafting teams working on new or revised CIP standards at the same time; in December I attended meetings of both teams on adjacent weeks. The Supply Chain Security SDT, which is drafting a new standard labeled CIP-013, met near Philadelphia during the first week of December, while the “CIP Modifications” SDT (which I insist on also calling the CIP v7 SDT) met in Orlando the following week. While I didn’t anticipate this, it turns out that the contrast between the two meetings provided a valuable lesson on the future of the CIP standards.
I attended both meetings because I hadn’t been at a meeting of either team since I attended a v7 SDT meeting in August (the v7 SDT has met monthly since the spring of 2016, although the Supply Chain SDT has only had three face-to-face meetings so far, one of which was actually a Technical Conference in November). The two drafting teams are very different, and they have very different agendas. I want to briefly characterize the two teams; then I want to ask you a question.
Our Two Protagonists
I start with Team One, the CIP v7 drafting team: This team is composed of very experienced cyber security and compliance professionals from a cross section of NERC entities (although almost all are from fairly large entities). Close to half the team members have experience on previous CIP drafting teams, and at least two members also served on the two teams that developed CIP versions 2, 3, 4, 5 and 6 – meaning these two individuals have been on CIP drafting teams for close to eight years each. All of the team members seem to understand both cybersecurity and how the NERC standards development process works, and they are keenly aware of what is in their mandate and what isn’t. Their mandate includes a number of weighty items, and the team is well behind their original schedule for having first drafts of all the changes or additions they will be proposing, but I think most team members – as well as most knowledgeable observers in the NERC community – would say this SDT has things well under control. After all, they in theory aren’t required to break any radically new ground in their work (which is why they’re called the “CIP Modifications” team). I have not heard any of the team members say directly that they see any major problems looming that would prevent their being able to fulfill their mandate.
Now Team Two: The Supply Chain drafting team is composed primarily of supply chain professionals from large entities who have little experience in the often inscrutable ways of NERC and FERC, and who don’t all know a lot about the current and previous CIP standards. Besides that, they face some huge obstacles. The first obstacle is the fact that they are developing probably the first non-defense mandatory supply chain security standard ever, and FERC provided fairly minimal guidance on what they wanted to see in it. The second is that FERC gave this SDT only one year to develop the standard, get it approved by the NERC ballot body (which normally seems to always take four ballots with a minimum of 3-4 months per ballot) and the NERC Board of Trustees, and finally put it on FERC’s desk. It is highly unlikely that a request for an extension of time would be granted, absent some unforeseen act of God.
Here’s my question: Which of these two teams do I believe is likely to fulfill the tasks in their Standards Authorization Request (SAR) very easily, and which do I see as probably never finishing a lot of what’s in their SAR? Of course, the answer is….Team Number Two should fulfill their tasks quite easily despite their very short deadline, but I have a serious doubt that Team Number One will ever finish the tasks in their SAR, even though all but one or two of those tasks don’t have any FERC-supplied deadline.
Of course, this assertion seems fairly counter-intuitive, given how I just described the two teams. Why do I say this? I do want to point out up front that this is in no way a reflection on the members of either drafting team. All of the members of both teams seem to me to be very dedicated and hardworking, and ready to do whatever it takes to accomplish the task in front of them. But I’ve come to the conclusion that the CIP v7 team has been given a Sisyphean task that they will never finish, while the Supply Chain team – despite the woefully inadequate time they have been given to draft and finalize the new standard – will almost certainly finish on schedule.
The reason the prognoses for the two teams are so different can be found in the nature of the standards they’re revising or writing. In Order 829, FERC made it clear that they wanted the new supply chain security standard to be non-prescriptive[i]; in other words, it would address just the objectives to be achieved, not the specific means of achieving them (the “what”, not the “how”). For this reason, the requirements of CIP-013 primarily lay out objectives, such as
1.1.1. Identify and assess risk(s) during the procurement and deployment of vendor products and services; and
1.1.2. Evaluate methods to address identified risk(s).[ii]
In contrast, the CIP Modifications SDT has to make changes (and in some cases additions) to the existing requirements of CIP v5 and v6. Many of these existing requirements tell entities how to comply with their objectives, such as this part of CIP-007-6 R2 (patch management):
2.2 At least once every 35 calendar days, evaluate security patches for
applicability that have been released since the last evaluation from the
source or sources identified in Part 2.1.
The result of this difference is that the Supply Chain Security SDT’s job is much simpler than the CIP Modifications SDT’s job. The Supply Chain team doesn’t have to draft and ballot requirements that describe the specific means that must be used to achieve the objectives in their standard[iii], while the CIP Modifications SDT will have to spend a lot of time drafting, balloting and commenting on precisely these issues – that is, which particular means entities will need to use to fulfill the goals of the prescriptive requirements the SDT is writing or revising, and why those particular means were chosen rather than others.
Of course, the Supply Chain SDT will have to provide guidance on means that a NERC entity can use to achieve the objectives in their (non-prescriptive) requirements; they will do this in the Guidance and Technical Basis discussion that will accompany CIP-013. But that’s all this will be – guidance. In the end, it will be up to the entity to determine the best way for it to meet the objectives listed in the requirements of CIP-013, and for the regional auditor to determine how well they have met those objectives.
The CIP-013 requirements themselves won’t tell the entity specifically what they need to do to meet the objectives. As a result, the primary source of debate in the original CIP v5 and v6 drafting teams, and to a large degree in the current v7 team, is for the most part absent in the meetings of the Supply Chain team. There is no need to debate prescriptive requirement language, when FERC itself has said they don’t want prescriptive requirements.
Now let’s go back to Team One, the CIP v7 team. Their job is not to create new standards de novo; it is to modify the existing CIP v5 and v6 standards[iv] to meet a certain set of objectives set out in their Standards Authorization Request (SAR). Three of these objectives were set by FERC in Order 822; the remainder were set by NERC when they finally realized there was no way they could provide binding “interpretation” on ambiguous areas of CIP v5 and v6 other than by either revising the standards, which requires a bare minimum of three years before the revised standards will come into effect, or responding to a Request for Interpretation, which can take almost as long.
So if Team One only has to modify the existing CIP v5 and v6 standards, why is their job so much harder than that of Team Two, which has to create a new standard literally from scratch (and without any previous standards from NERC or any other organization - other than perhaps DoD - to look to for guidance)? It is because almost all of the requirements of CIP v5 and v6 are prescriptive. If they weren’t prescriptive, most of the changes Team One is charged with making could be made just by modifying guidance (and in some cases also adding some new definitions, as in the case of the team’s mandate to incorporate virtualization into CIP). If the v5 and v6 requirements all read like the draft CIP-013 requirement parts quoted above or like CIP-007-6 R3 or CIP-010-2 R4 (both of which are non-prescriptive requirements in CIP v6), Team One’s job would be much easier than it is.
An Example of What I’m Talking About
For example, consider the change the CIP Modifications SDT successfully balloted last year in Section 3.2 of Attachment 1 of CIP-003-6. In Order 822, FERC mandated that NERC clarify the meaning of the word “direct” in the LERC definition. The v6 version of Section 3.2 prescriptively required that, in cases where LERC was present, a LEAP needs to be implemented. FERC was concerned that the ambiguity regarding “direct” was allowing some entities to take an overly broad view of the measures they could adopt to “break” LERC. As it turns out, the SDT incorporated the LERC definition (without the word “direct”) into the requirement itself and made the requirement non-prescriptive, so that it now simply directs the entity to take appropriate measures to mitigate the risk posed by the presence of external routable connectivity to BES Cyber Systems at Low impact assets; the guidance includes many examples of measures that can be taken to accomplish this objective.[v]
Making this change has taken most of the SDT’s attention since at least last May, even though there is a lot more on its plate. The SDT had to initially just focus on LERC because FERC set a deadline of next March for this change to be drafted, balloted, approved by the NERC Board and submitted to FERC. This is the only change ordered by FERC in Order 822 that has a deadline associated with it; naturally, the SDT had to put off everything else until this was done. As a result, I believe almost all of the time spent in the full SDT meetings since about June (and a significant portion of the time spent in the intervening phone meetings) has been devoted to drafting and re-drafting the new requirement, as well as working on guidance and responding to comments.
It isn’t completely true to say that the SDT has spent eight or nine months just addressing the LERC issue and getting the revised requirement approved by the NERC ballot body. There has been some subcommittee work on other areas of their mandate such as virtualization, but all of this is simply in preparation for when the full team can turn their attention back to these topics. It is now very likely that the SDT will not be able to turn to these other topics in earnest until their February meeting.[vi] This is in spite of the fact that the team originally planned to have finished the first draft of the revised standards, addressing all of the items in their SAR, by the end of 2016.
I will freely admit that I found the fact that the SDT had to spend so much time on the LERC issue – including having to draft the new requirement twice and answer a huge set of questions on both drafts – to be discouraging. What was most discouraging about this was that the requirement that was finally approved by the NERC ballot body didn’t require NERC entities to change how they comply with this requirement at all (as I discussed in this post). On the contrary, the revised requirement allows much more flexibility in how entities can comply, without taking away any options they had under the original wording. Yet it still took about eight or nine months of the SDT’s time to draft and sell the new approach to the NERC membership[vii]! How long will it take to sell a revised requirement that actually does require the entity to change what they do to comply, or to sell a new requirement that imposes a whole new compliance obligation on them?
I will discuss that question in a moment. However, please keep in mind that I’m not arguing that the fact that the CIP v7 SDT had to spend much longer than they’d hoped on the LERC issue is why they are unlikely ever to be able to fulfill the full mandate in their SAR. A setback of say 3 or 4 months (assuming that the LERC issue should just have taken about four months of their time, not seven or eight) is unfortunate but certainly no reason to despair. What I am saying is that, if changing one requirement can take this long, changing say 15 or 20 requirements will take something of the order of ten years or more – which is definitely a huge threat to the SDT ever fulfilling their mandate. And I believe that just one of the items on the SDT’s plate – virtualization – could very well take that long.
How Long Will it Take to Address Virtualization?
I’ve written several posts (such as this and this one) on the problem of virtualization and NERC CIP (as well as participated in one webinar on that topic). The big problem is that the CIP standards (and associated definitions) don’t take any account of virtualization now – either server, switch or storage virtualization; that is, they don’t provide any guidance at all on how NERC entities can safely deploy virtualization in their ESPs. This might be interpreted by some as a license to do whatever you want, since technically, for example, a VM isn’t a Cyber Asset (defined as a programmable electronic device) and thus can’t be a BCA/BCS. Since CIP v5/v6/v7 apply only to BES Cyber Systems and related devices, this means that strictly speaking VMs are of no concern at all to CIP[viii], and therefore NERC entities should be able to pretty much do what they want when it comes to implementing virtualization. In practice, entities who are afraid to push the envelope have simply not deployed virtualization within their ESPs, thus depriving themselves (and their ratepayers) of the many benefits that can be gained from the technology.
Recognizing this problem, the CIP v5 Transition Advisory Group included virtualization among a list of 5 or 6 topics that were included in the SAR for the current SDT, developed early in 2016. However, as I discussed in this post, the v5TAG only indicated that revisions would be required for CIP-005 and the definitions of Cyber Asset and ESP. I thought that this was being overly optimistic and suggested one other change that had been suggested by a TRE webinar. But I also believed that it would not require a lot of changes to requirements to properly incorporate virtualization into the current CIP framework. As it turns out, both the v5TAG and I were wrong.
One of the first things the current SDT did when they started meeting last spring was to appoint a sub team to study what needs to be changed in CIP v5 and v6 to accommodate virtualization. This group decided there were potentially a lot of requirements or definitions that either need to be developed from scratch or revised. But rather than just identify these willy-nilly, the group rightfully decided they should go back and review the various security standards and frameworks, as well as probably other sources, to determine what are the security threats that can be posed by the use of virtualization in control system environments. Once they have done that, they will be able to determine what requirements or definitions need to be either developed or modified.
I know this sub team has developed a spreadsheet listing the different threats that virtualization poses, as well as what might be new or modified requirements or definitions that would address those threats; I know they’re eagerly awaiting the full SDT’s attention (after they have finally put LERC to bed), so that they can begin discussing these. I’ve heard they will first need to get the full team’s agreement on certain new concepts, which will have to be drafted – and voted on multiple times, of course - as new NERC Glossary terms. Once there is agreement on those concepts, then the work on the individual requirements – new or revised - can begin.
So here’s the punchline: I saw a preliminary version of this group’s spreadsheet last summer, and I can say there might easily be 15-20 (or even more) new or revised definitions or requirements needed to incorporate server, switch and storage virtualization into NERC CIP. Now let’s go back to the LERC discussion above: As I said, just this issue – i.e. a change to one requirement - took up more than six months of the SDT’s time, and it really didn’t involve any change to what entities need to do to comply with the requirement in question. Given how new the whole virtualization issue is to CIP, it is likely that each of the new or revised definitions and requirements, that will be required to incorporate server, storage and switch virtualization into CIP, will be controversial. Each one could easily take six months or more of the SDT’s time, by the time they are drafted, posted and balloted, redrafted (given that almost nothing is likely to pass on the first ballot, and perhaps not the second ballot, either) and finally submitted for approval.
So let’s do some math. If there are 20 new or revised requirements or definitions needed to accommodate virtualization in CIP, and if each of those takes a minimum of six months to draft, post, respond to comments, re-draft, re-post, respond to new comments – and potentially repeat this cycle one or two more times – we are talking about a minimum of ten years just to deal with virtualization. And by the way, virtualization isn’t the only thing remaining on the SDT’s agenda[ix]!
Something is going to have to give here. One possibility is that the SDT will decide their mandate is just to address the three items that FERC ordered NERC to address in Order 822. Since one of those is LERC (already approved, at least by the membership) and another is transient cyber assets used at Low impact assets (which will also probably be approved soon), this “only” leaves the mandate to develop requirements to protect communications between control centers on the SDT’s agenda (although see end note ix regarding this mandate). That may cut down the time the SDT needs to address its FERC mandate to maybe about three years, but it does pose the problem that virtualization (and the other items that were added to the SAR by the NERC v5TAG) will be left in a kind of CIP no-man’s-land. Virtualization will continue to be a set of technologies that NERC entities would love to implement in their EPSs (especially in control centers), but only the bravest will feel comfortable actually implementing it – i.e. just like things stand now.
And Now, Our Exciting Conclusion
The bottom line of this very long discussion (one of my longest posts, but not the longest) is that I don’t see any way that virtualization will be officially incorporated into NERC CIP. It might be unofficially “incorporated” through some guidance document that NERC might put out, but as I’ve said recently, no guidance document will have the status of actual modifications to the CIP standards.
But I’ll go further: I don’t see any way that the existing CIP standards can be extended to incorporate any new technology from now on; the standards development process is far too cumbersome to allow this. This applies especially to the cloud, which is once again a technology that only the bravest of NERC entities have implemented in their ESPs so far (and NERC entities need to be much more cautious about implementing the cloud than they have been even about implementing virtualization, as discussed in this recent post). It also applies to other new areas for CIP, like phishing (the initial cause of 91% of successful cyber attacks, according to one recent article, yet something that isn’t addressed in CIP at all. Indeed, I don’t think the term was even invented when the SDT that drafted CIP v2 through v5 first met in the fall of 2008).
What’s the way out of this problem? We clearly can’t leave CIP in its current never-never land. NERC entities can become more efficient and save ratepayer dollars if they virtualize, but for now this can only be accomplished through an elaborate system of winks and nods with NERC and your regional entity.
You can find the answer to this question (regarding the way out of this problem) in the phrase “existing CIP standards” in the first line of the second paragraph above this one. The existing CIP standards need to be rewritten so that all requirements are non-prescriptive (rather than just 3 or 4 requirements being non-prescriptive, as is the case now). At that point, extending the standards to accommodate new areas (which will always be required, since both technologies and threats will always change) will be something that can actually be accomplished in a reasonable amount of time. As it stands now, the time that is required for this is completely unreasonable.
The views and opinions expressed here are my own and don’t necessarily represent the views or opinions of Deloitte Advisory.
[i] To quote FERC’s words (Order 829, p. 2), “In making this directive, the Commission does not require NERC to impose any specific controls, nor does the Commission require NERC to propose “one-size-fits-all” requirements. The new or modified Reliability Standard should instead require responsible entities to develop a plan to meet the four objectives, or some equally efficient and effective means to meet these objectives, while providing flexibility to responsible entities as to how to meet those objectives.”
The last time FERC ordered a new standard – which became CIP-014 for physical security at substations – they also required that it not be “one-size-fits-all”. I hereby predict that FERC will never order a new CIP standard that is prescriptive. As you will know if you’ve been reading my posts regularly, I think prescriptive standards just don’t work for security (which is inherently a statistical, not a deterministic, process). It seems FERC came to that conclusion long before I did; I wish NERC would also come to that conclusion, and order that the existing CIP standards be rewritten in a non-prescriptive format (of course, the details of doing that are anything but simple, as I and two co-authors have discovered as we write a book on this topic).
[ii] These requirement parts come from the most recent unofficial draft of CIP-013-1 that has been sent out to the SDT’s Plus List. It is dated December 19, 2016. The official first draft is due to be posted in January and balloted starting in February.
[iii] I do need to point out that probably most of the Supply Chain SDT members – as well as a lot of the observers at the meeting – didn’t quite get what a non-prescriptive standard means, and frequently lapsed back into discussions where someone would ask whether the team should write the requirement so that the Responsible Entity would need to do X to comply. In the December meeting, I found myself frequently pointing out that, in drafting non-prescriptive requirements, discussion of means to achieve the objective of a requirement is strictly to be included in the guidance, not in the requirements themselves. I joked that I should have just recorded that statement and played it every time I felt compelled to make this point. But I will admit I myself fell into the old way of thinking sometimes. When you’ve been dealing with CIP for a while, you sometimes begin to think that prescriptive standards are the only truly “enforceable” ones (in fact, this is a common objection I hear when I expound my idea that CIP should be rewritten non-prescriptively). Fortunately, since FERC ordered that the supply chain standard be non-prescriptive, this shouldn’t be a matter of debate for the Supply Chain team, just as it wasn’t for the team that drafted CIP-014. FERC made it clear in both cases that they wanted a non-prescriptive standard.
[iv]Of course, the modified standards will bear a new version number. This will normally be “-7”, although modifications to CIP-002, -005 or -008 will be numbered “-6”, since those standards were never revised with the other standards when “CIP v6” was created. With the exception, of course, of CIP-010 and -011, which are now both numbered “-2” and will be numbered “-3” when changed and approved. And oh, by the way, one or more of the modified standards may be numbered “-8”, since more than one new version of those standards may be drafted and approved by FERC, before the “v7” team is done. This is likely to be the case for CIP-003. The standard in effect now is numbered “-6”, but a new version numbered “-7”, including the recently-approved changes regarding electronic access controls and (probably) Transient Cyber Assets for Low impact assets will be submitted to FERC by March and presumably come into effect by 2018. But this SDT will very likely have to make further changes in CIP-003 in order to fulfill their other mandates, such as the one regarding virtualization. When those changes are approved by NERC and FERC, CIP-003 will then be numbered “-8”. And by the way, the Supply Chain CIP standard will of course be numbered “-1”. Got all this? I agree; it isn’t confusing at all!
I used to think that the CIP standards should all be “revved” whenever even just one was changed (this was done when FERC ordered a change in just one of the CIP v2 standards, but they all were revved - so that all the standards that were in effect before CIP v5 were numbered “-3” and known as CIP v3, rather than having seven “-2” standards and one “-3” standard). I lost that battle when NERC called the v6 team the “CIP Version 5 Revisions” SDT, and the team deliberately only revved the standards that had been changed, leaving the rest as v5 standards. I suggest the industry just start focusing on the individual standards and make sure they are using the current version of each standard. In other words, it no longer makes a lot of sense to talk about the version number of “CIP” itself, only the version number of each particular CIP standard. This will be harder to do, but hey, it’s now the world we live in.
However, in the best tradition of religious leaders and politicians who exhort their flocks to follow a certain path while themselves doing just the opposite, I don’t intend to stop using the terms v5, v6 and v7 until the CIP standards carry such a hodgepodge of version numbers that these terms no longer have any real meaning at all. We haven’t reached that point yet, thank God for small favors. But we will in a few years.
[v] In other words, the CIP Modifications SDT took a prescriptive requirement – that entities with LERC implement a LEAP – and made it non-prescriptive. Of course, if the requirement had been non-prescriptive to begin with, the modifications could mostly have been made in the guidance, which would have been much easier. It is interesting to note, however, that – almost instinctively – the SDT gravitated toward the non-prescriptive approach when they re-drafted this requirement, since the complexity of doing what they needed to do with a new prescriptive requirement would have been much greater. I was fortunate enough to be at the meeting where they drafted the new requirement, and wrote about the process in this post.
This shows that FERC isn’t the only player in the CIP arena that has recognized that only non-prescriptive requirements will work going forward. In the cases of both FERC and the CIP Modifications SDT, the impetus for going non-prescriptive was the realization that trying to write prescriptive standards or requirements to accomplish the required tasks would take far too much time. That is certainly one important reason for using the non-prescriptive approach, although it is far from the only one. I am willy-nilly bringing up other reasons in various blog posts now, but I and my co-authors will try to comprehensively describe all of those reasons in our upcoming book.
[vi] As an example of how the SDT has had to put everything off to focus on the LERC issue, I was hoping that – since the revised requirement and implementation plan had passed the second ballot (as announced last week) – the SDT would be able to talk about those other areas at the meeting in Orlando in December. But no, they had to devote the entire time to fine-tuning the requirement, the implementation plan and the RSAW, and especially to answering the comments they received along with the second ballot. They had to do this even though the second draft had been approved; NERC’s Rules of Procedure require that the SDT respond to comments, even after approval of the standard.
[vii] Part of the reason this was such a hard “sell” was actually due to that increased flexibility. I have found that a significant number of people in the NERC CIP community are automatically suspicious of any change toward less prescriptive standards, because of fears about how auditors will use their new freedom (since the flip side of not having a prescribed way of meeting an objective is not having a prescribed way for the auditor to determine whether or not the entity met the objective). I hope to have a post out addressing these fears (which I believe are unwarranted for several good reasons) soon.
[viii] This is probably an exaggeration, since the Cyber Asset definition says “Programmable electronic devices, including the hardware, software and data in those devices”. One could certainly make the point that VMs would fall under “software and data”, and thus are themselves Cyber Assets. This was clearly not the intent of the v5 SDT, and even if it were, this one consideration wouldn’t suddenly bring all of virtualization into CIP. For one thing, it would only bring virtual servers into scope, not virtual LANs or virtual storage.
[ix] In fact, I believe the sub team that is looking at FERC’s mandate to write requirements protecting communications between control centers has had to go back to fundamentals, just like the virtualization team has had to do. I don’t think this other sub team will need quite as many changed or new requirements or definitions as the virtualization team will, but – given the fundamental issues involved in their task – I’m sure there will be at least say five items that have to be balloted and approved. So assume this task takes “just” two and a half years, and maybe everything else on the SDT’s agenda takes “just” another 2 ½ years. Adding in at least ten years for virtualization, we’re still talking about over 15 years for the current SDT to accomplish their assigned tasks. Does anyone think it is even remotely likely that the team will be willing to continue meeting for say 6 or 7 years, let alone 15?