What I Mean when I Say “Enforceable”

A few discussions I’ve had recently with people who commented on my posts have revealed to me that I’m not being completely clear or consistent when I assert that some of the CIP v5/v6 requirements will probably not be “enforceable in the strict sense”.  I’d like to clear that up now, since I expect this theme to continue in future posts (and I’ll refer back to this post so I don’t have to explain this every time).

One of the main reasons there is confusion is that I haven’t been consistent in my wording. I have in some cases omitted the words “in the strict sense”. And I have in some cases asserted that all the requirements of v5 and v6 aren’t enforceable in the strict sense. I believe that could actually prove to be the case, but I am far less certain of the truth of that statement than I am of the narrower statement that some of the important requirements – especially CIP-002-5.1 R1 and CIP-005-5 R1 as it has to do with External Routable Connectivity – are not enforceable in the strict sense. I’m going to stick with the latter assertion for now.

What do I mean by “enforceable” in the strict sense? I mean that, if an entity receives a violation and fine due to alleged lack of compliance with a particular v5/v6 requirement and decides to appeal that violation to the US civil court system (which is allowed since CIP, like all FERC-approved NERC standards, is regulatory law), there is a substantial likelihood that the violation and fine will be thrown out.

For example, suppose you receive a violation and fine due to not having identified all the Cyber Assets that your auditor thinks you should have identified (presumably this led to your also not identifying all the BES Cyber Assets they thought you should have identified). The reasoning given is that you didn’t use an appropriate definition of “programmable” – of course, a Cyber Asset is defined by NERC as a “Programmable electronic device”. When you appear before the judge, you simply point out that there is no FERC-approved definition of “programmable”; therefore this violation is due to a mere difference of opinion between you and the auditor. I find it very hard to believe that any such case wouldn’t be dismissed.

The result of this lack of strict enforceability is that some PVs will probably never be written in the first place – one example being a PV for not using the “right” definition of programmable. No Regional Entity is interested in wasting their time writing up PVs, if there is no chance at all they will stand up if challenged in court. Thus, certain requirements are unenforceable in the strict sense.[i]

Now, what do I mean by enforceability in the general sense? This sense has nothing to do with the court system. In this sense, there is something like general agreement between NERC entities and the NERC regions about how to comply with a particular requirement. This will be evidenced by the fact that an auditor will feel comfortable writing a Potential Violation for a particular requirement, and the entity receiving it is likely to agree that the PV is legitimate – or at least to conclude that they should fight it through the normal NERC channels, not wait for it to become final and then appeal to the courts. So the question whether a requirement is enforceable in the general sense isn’t a legal one, it’s a sociological one. It’s simply a question whether there is broad agreement – perhaps in one region, perhaps across the NERC community – about the meaning of a particular requirement, regardless of whether parts of that requirement may be lacking needed definitions or may be ambiguous or contradictory in their wording.

And I further stipulate that certain violations will be unenforceable in the strict sense, but enforceable in the general sense. For an example of this, consider the fact that CIP-002-5.1 R1 never requires the entity to document a methodology for identifying BES Cyber Systems. In fact, it never requires the entity to identify BCS in the first place, although that requirement is certainly implied by the fact that all the other requirements apply to BCS. You obviously couldn’t comply with them unless you had already identified your BCS.

However, if you don’t develop and document such a methodology, you are going to have a pretty tough time at audit even though it is never explicitly required, if the auditor believes that you haven’t identified all of the BCS that you should have identified. You will have to be able to demonstrate that a) you did develop this methodology and b) you applied it consistently in your BCS identification process. The methodology you develop may differ from what the auditor would personally prefer, but as long as you can show that you put a lot of thought into developing and documenting it and that it is a reasonable interpretation of CIP-002-5.1 R1, I find it very hard to believe you will be issued a PV.

On the other hand, if you haven’t documented a methodology, or if you documented one but didn’t require that all groups within your organization use that methodology when identifying their BCS, you probably will be issued a PV. Since I believe that, if that PV became a violation and you appealed to the courts, it would be thrown out (since you haven’t actually violated any written requirement), you might be tempted to simply let the violation become final and then appeal to the courts.

However, I believe that 99.9% of NERC entities wouldn’t allow a violation to happen even if the “penalty” were a two-week vacation in France. The last thing they want is to become known as a serial NERC violator, regardless of what the actual penalties may be. Plus entities spend an enormous amount of time and money getting their legal teams involved whenever a PV appears headed to being a violation; they will do almost anything to avoid a long drawn-out fight with NERC and FERC, no matter what their ultimate chance of success will be in the courts.

This is why some requirements are unenforceable in the strict sense, but enforceable in the general sense. An entity would be ill-advised if it decided not to comply with an ambiguous requirement or an aspect of an ambiguous requirement, even though there is general agreement among NERC, the regions and the entities as to its meaning. The entity might be right in assuming it will be thrown out in court, but is it worth going through the big hassle and cost of getting that far, vs. just settling for a small fine and a mitigation plan? In some cases, the answer to this might be yes, in others no. But since no challenge to a NERC CIP fine has ever been adjudicated in the courts, I believe this indicates most entities will not go that far. This constitutes what I call enforceability in the general sense.

Another example of a class of violations that are very likely unenforceable in the strict sense, but enforceable in the general one, is PVs having to do with virtualization. It is my opinion (not universally shared, I’ll admit) that the fact that the definition of Cyber Asset is “programmable electronic device (my emphasis)” means that VMs are not Cyber Assets and thus not BES Cyber Assets (of course, in CIP version 7 I’m fairly sure this omission will be fixed, since virtualization is one of the biggest items on the menu for the new Standards Drafting Team).

So if an entity doesn’t install AV on all of its VMs that are within an ESP, will they be cited for violating CIP-007-6 R3? I believe they will be cited, and moreover they should be - although at the same time I believe that, if the entity appealed a violation to the courts, it would be thrown out. I believe most, if not all, of the regions have made it clear they will consider VMs to be Cyber Assets[ii], and NERC itself has at least once made that clear as well. No entity can argue that they properly identified their Cyber Assets if they ignored what NERC and their region were saying on this issue.

I’ve said what I wanted to about how I’m using the word “enforceability”, but I do want to point out one implication of this for the new SDT (although even if you’re not on the SDT, I’m fine if you listen in while I’m talking to them): As discussed above, there are three types of requirements[iii] in CIP v5:

1. Requirements that are enforceable in both the strict and general senses. For example, I think CIP-005-5 R2 is such a requirement, even though there are certainly cases that could be identified where a violation would be unenforceable in the strict sense. But I doubt there’s any CIP v5 or v6 requirement that wouldn’t be in that same boat.
2. Requirements that are unenforceable in both senses, like the “programmable” definition discussed above.
3. Requirements that are enforceable in the general sense, but unenforceable in the strict sense. In my opinion, any violation having to do with virtualization falls into this category.

Folks on the SDT, I believe your job is to address the second and third categories above. But I’ll also admit that doing this might require five or ten years of debate, so you will have to triage your efforts. What you need to focus on most of all is the second category. If you’re able to clear up some of these items, you will be doing the NERC community a lot of good, since these items are now the Wild West of CIP requirements; every entity is more or less on its own to determine how to comply with them.

I’ve previously provided a list of things that aren’t in the SAR but need to be addressed. I divided this list into things that are easy to address and things that are hard. The “easy” ones were mostly the third category; however, precisely because I think they are easy I still wish you would address them.

So, besides what is in the SAR, I'm recommending the SDT focus on the second category items, as well as the "easy" items in the third category. What are these second category items? The "programmable" example above is one; of course, this is already in the SAR so I know it will be addressed. I would also say items 2-6 under the section "What the V5TAG Requested" are second-category items - and they are also on the SDT's plate since they're in the SAR.

And, SDT members, if you would like to go for extra credit, I recommend you address items 25-29 in this post. These are all "hard" items that aren't included in your SAR. Unless these are addressed, a lot of CIP v5 won't be enforceable in either the strict or general sense. But I'll admit that addressing these might well add six months to a year to your efforts. Essentially, properly resolving these issues requires rewriting CIP-002 R1 and Attachment 1 - the Mt. Everest of drafting tasks.

Why should the SDT consider doing this? Because the fundamental problem in CIP v5 is the fact that the wording in CIP-002 that describes the process for identifying cyber assets in scope for the standards leaves huge gaps - and the wording that is there is confusing and contradictory (if you would like to learn more about this issue, just look at the 100 or more posts I've written on it, starting with this one). The question is whether this fundamental uncertainty about asset identification in CIP v5 and v6 will continue into v7 or not. I recommend it not be continued.

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

---

[i] I do need to point out, as I always do when discussing this subject, that even for requirements that are unenforceable in the strict sense, this unenforceability won’t apply in the case of an entity that has simply blown off compliance with the requirement – in this example CIP-002-5.1 R1 – in the first place. You have to have made a good faith effort to comply, which in this case includes developing and documenting your own definition of “programmable”, and documenting that this definition was applied consistently as your organization identified Cyber Assets.

[ii] It would be very hard for an entity to argue that, even though a VM might be a “device”, it still wouldn’t be a Cyber Asset since it isn’t programmable. How could a piece of software not be programmable?

[iii] When I say “requirements” here, I really mean “aspects of requirements” or something like that. CIP-002-5.1 is enforceable in some of its aspects, like the clearly implied requirement to have a BCS identification methodology. But it is unenforceable in other aspects, like its implied requirement to identify electronic devices that are programmable (i.e. Cyber Assets).