Taking Your Position(s)

In the fall of 2014, I wrote a series of posts entitled “Roll Your Own”.[i] I wrote them because I had been despairing earlier that year due to my fear that NERC would never come up with guidance on the many ambiguities, inconsistencies and missing definitions in CIP version 5. That guidance never came (or if it did come, it was withdrawn), but of course NERC entities still had to press on with their v5 compliance programs, since the compliance date was (at that time) April 1, 2016.

At the time, the NERC entities who were most impacted by this uncertainty were owners of generation stations, especially large plants subject to Criterion 2.1 (i.e. greater than 1500 MW). Those plants can have literally thousands of devices that might or might not be determined to be Cyber Assets, and potentially BES Cyber Assets. They couldn’t wait until sometime in 2015[ii] for guidance. Their biggest concern was the meaning of the word “Programmable” in the definition of Cyber Asset. This is nowhere defined by NERC, and it turns out that different ideas for what this word meant could cause huge differences in what would be in scope for CIP v5 in large plants.

The NERC CIP compliance manager for a generation entity with several of these large plants – who is a personal friend of mine, and is now retired – wrote in to tell me what he was doing about this problem. Since he couldn’t wait any longer to identify Cyber Assets in these plants (which is of course the first step in the CIP v5 compliance process, along with identifying Medium and High impact assets in scope under the criteria of Attachment 1 of CIP-002-5.1), he had simply “rolled his own”  definition[iii] of Programmable.

When I asked his justification for doing this, he asked what choice he had. If he waited for NERC to come up with their own definition[iv], he would probably miss the compliance deadline. What was important was that he documented a) the definition itself, b) his reasoning for arriving at that definition, and c) the fact that he had looked through whatever guidance was available from NERC and his region on his issue, and his reasons for following or not following that guidance.

Of course, this approach to ambiguity in CIP v5 – which was independently “discovered” by others in the industry – was ultimately adopted by many entities, for many different interpretation issues: the meaning of “affect the BES” in the BES Cyber Asset definition, the meaning of “Facilities” in some of the Attachment 1 criteria, the entire methodology  for identifying BES Cyber Systems, etc. For all of these issues and many more, the only good approach I know of[v] is to take the three steps listed above. As Lew Folkerth of RF, along with a CIP auditor with another region, confirmed  a couple of months after that post, it would be very difficult for a future auditor to argue that you had done something wrong in this process (e.g. used the “wrong” definition of Programmable), even if they don’t agree with the interpretation you made. As long as your definition is reasonable and well documented, it is very hard to understand how you could fall into any compliance trap with this approach.

However, what is critical is that your position be documented. If you haven’t done that, and a future auditor disagrees with how you interpreted an ambiguity or an undefined term, you won’t be able to show that you used good reasoning to arrive at your position, and that you had considered any other official guidance that might be available. The moral of this short history lesson is: Whenever you encounter an ambiguous definition or requirement or a missing definition, you need to “roll your own” interpretation or definition, following the three documentation steps listed above.

You may ask what relevance this has now, for entities with High and/or Medium impact assets. After all, the compliance date for those was last July 1. What good will it do you if you can’t show that you had developed these “position papers” before that date? And the answer to that is simple: Position papers are nowhere required in CIP v5 (or v6), so you aren’t out of compliance if you didn’t develop them by last July. When you do have an audit, you will be in a much better position regarding these issues if you have these papers available than if you don’t. So you should develop them now.

But suppose you didn’t necessarily use a particular position, even undocumented, as you came into compliance with v5? What if your substation people, your Control Center people, and your generation people all used slightly different definitions of Programmable, or worse didn’t use any particular definition at all, just relying on “gut feel”?

Even if this was the case, I don’t believe you’re out of compliance since – once again – CIP is either ambiguous or silent on this and a host of other issues. So it’s not too late to develop positions. What you also have to do, though, is rerun the processes – especially for BES Cyber System and ESP identification – that are dependent on the interpretation of these issues, once you have developed your position on them.

For example, if you decide one group of people (say, your relay group) used a definition of Programmable that is at odds with the one you have now documented in your position paper on that topic, you will need to go back through all the devices that they reviewed to determine if some of those should now be identified as meeting the definition of Cyber Asset (based on your new definition of Programmable). You will then have to document that you have done this (you will also have to document that the devices whose classification hasn’t changed were also determined to meet this new definition). And if you have just now developed a definition of Programmable that was never used by anybody in your organization before this, you will have to go through every electronic device to see if this definition applies to it; those that do meet the definition will be Cyber Assets. Of course, this is a lot of work, but it’s worth doing it now rather than a year from now when you’re ordered to because you’re found to be in massive violation of CIP-002 R1.

Of course, for any newly-identified Cyber Assets, you will next have to run them through the BES Cyber Asset definition to determine whether they meet that[vi]; if they do, you then have to incorporate them into one or more BES Cyber Systems and apply all the protections of all the CIP v5 and v6 requirements that apply to them.

But what if your organization did develop and document positions regarding every significant area of ambiguity or missing definitions already, and you can prove they were applied wherever applicable? Does that mean this whole discussion doesn’t impact you? No, it doesn’t. You still have to document positions whenever you are going beyond the current wording of the CIP v5 and v6 standards and definitions.

For example, suppose you have virtualization – even just a little – within any of your ESPs. You will need to document how you are protecting virtual assets (e.g. VMs within an ESP, an ESP implemented as a VLAN on a physical switch that incorporates non-ESP VLANs as well, a SAN that stores data both from inside and outside an ESP). Since CIP doesn’t say anything about these topics, you have to develop your own guidelines on how to protect these virtual assets. NERC tried to develop guidelines two years ago, and ended up withdrawing whatever they did develop. The issue of virtualization is now on the table for the CIP v7 Standards Drafting Team, but it will be at best a very long time before the CIP standards address virtualization. If you’re able to wait years, great. But a lot of companies feel the savings from virtualization are too large to wait any longer to implement it. If you are one of those, you need to start writing your positions.

And then there’s the cloud. CIP is silent on that, and I know of no written guidance from NERC or the regions[vii]. Yet I have recently come to realize that some large and medium-sized entities are using cloud-based asset management software for both ESP and non-ESP devices. I will write a post soon on this issue, but if you are one of these entities, I strongly suggest you document how the information from within your ESP that is being stored in the cloud is protected.

  

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

---

[i] The first was this one. There were six more after that, which you can find by dropping down the month listings at the side of this page for September through December, 2014.

[ii] NERC’s self-imposed deadline for providing fairly comprehensive guidance (Lessons Learned and FAQ responses) kept getting pushed back, but I know that in January of 2015 the date of April 1, 2015 was stated at a WECC meeting. Of course, that date came and went without comprehensive guidance showing up. A few months after that date, NERC abandoned  the whole idea of providing comprehensive guidance and withdrew a number of the Lessons Learned. Some of these had actually clarified a few important issues, like how virtualization should be addressed and the meaning of “Programmable” in the Cyber Asset definition. But they all faced the same problem: Any “interpretation” of an ambiguous requirement or a missing definition requires either a Request for Interpretation or a SAR. And both of these take years to produce results.

[iii] You wouldn’t call what he did a definition, but rather a procedure for determining whether a device was programmable or not. I know some other entities also adopted that procedure.

[iv] NERC actually put out a Lesson Learned in early 2015 that provided what seemed to be a fairly reasonable definition of Programmable. But that was later withdrawn, along with all of the other Lessons Learned that tried to fill in gaps or clarify ambiguities in the CIP v5 requirements or definitions. NERC finally admitted that there was no way to fix these problems short of redrafting requirements or definitions, and they started the drafting process by writing a Standards Authorization Request and constituting a new CIP drafting team. That team is currently working on the items in their SAR; however, I am now very skeptical that they will ever be able to complete work on those items.

And as it turned out, the list of items in the SAR fell far short of the number that would be needed to address all of the very serious interpretation issues in CIP v5.  But the SAR would have been even more unachievable than it is, had all those items been included. I now believe that we’ve reached the limit for meaningful changes that can be accomplished given the current prescriptive format of NERC CIP. Only a non-prescriptive format will allow CIP to be updated in a timely manner, to address new threats and technologies.

[v] Short of asking your region for a definitive “ruling”, which you will never get, at least not in writing.

[vi] Of course, the BCA definition itself has at least one hole in it: the meaning of “adversely impact the BES”. You need to document how you determine whether the loss, misuse, etc. of a Cyber Asset will adversely impact the BES. Then you have to identify those Cyber Assets whose loss, misuse, etc. would have that adverse impact within 15 minutes.

[vii] Tobias Whitney of NERC said at the last CIPC meeting that NERC was going to come out with some sort of guidance document on the cloud. If I were you, I wouldn’t hold my breath waiting for that to happen. NERC simply can’t do this while still following the Rules of Procedure, unless they convene a new Standards Drafting Team to address the issue by modifying the CIP standards (i.e. CIP version 8). And just as with virtualization, the time required to do this – within the current prescriptive CIP framework - will be not much less than the lifetime of the observable universe, if that.