Rewriting CIP-002, Part III: An Interesting Conversation with RF

My previous post discussed various interesting things I’d learned at RF’s CIP v5 workshop in Cleveland on October 1 and 2, 2015. In that post, I mentioned there had been a good conversation at the meeting that I would discuss in my next post. Well, now it’s the next post, and here’s the story of that conversation.

On the second day of the meeting, Ron Ross and Frank Kapuscinski of RF gave a presentation entitled “CIP-002-5.1 Audit Approach”. The presentation was very similar to presentations on this topic by other NERC Regional Entities; I doubt any CIP compliance person from any region would have thought there was anything wrong with it. The bulk of the presentation was dedicated to displaying and discussing a very large and interesting spreadsheet that constitutes Attachment C for the CIP-002-5.1 RSAW (this file is available on this page, in the CIP Document Library section). It allows the entity to collect a wealth of detail on its assets and cyber assets – everything that’s needed to comply with v5.[i]

After the presentation, I asked Ray Sefchik, who leads RF’s CIP auditors (his title is Manager, CIP Compliance Monitoring), whether RF would be putting out any document to clarify the wording in CIP-002-5.1. Ray answered as I thought he would: “No”. He implied (I can’t remember his exact wording) that it really wasn’t RF’s job to try to clarify the wording in any NERC standard– and I totally agree with this. The Regional Entity’s job is to audit compliance with the wording of the requirement.

However, if you have happened to read any of the 70-80 (perhaps more) posts I’ve written on issues with the wording in CIP-002-5.1 over the past two and a half years, or in particular the first two posts (Part I and Part II) in this series on Rewriting CIP-002, you will know I think there are a huge number of ambiguities and contradictions in this standard (especially in R1 and Attachment 1). So the question arises, is it actually possible to audit to the strict wording of this requirement? And if so, what would “the strict wording of the requirement” mean?

Fortunately, I don’t need to spell out now what it would mean to audit to the strict wording of R1; I did that in Part II of this series. There, I started by laying out the fairly simple five-step process that is how almost all of the regional auditors, and close to 100% of the compliance people at NERC entities, understand R1 to work. It was certainly the methodology that lay behind the RF presentation. But there’s just one problem with this methodology: It isn’t the actual wording of the requirement.

Further on in that post, I listed a very complicated 15-step process for compliance with R1 that is as close to the actual wording as I can get. And I pointed out that this was just the down payment; to be correct, there is no finite set of steps that could be written down that would be compliant with the actual wording. You could write 15 steps or 15,000, and still not have addressed all of the ambiguities and lacunae in R1 (including its missing definitions, like “programmable”). But if RF, or any entity, is going to audit to the "strict wording" of CIP-002-5.1 R1, they need to audit based on this complicated methodology, not the simple five-step one. Of course, no NERC entity is going to follow the complicated methodology as they comply with CIP v5, and certainly none of the regions are going to audit based on it; if you don’t believe me, just read the post.

Since the discussion so far has been fairly abstract, let me point out a few areas where the presentation and the spreadsheet differ from the strict wording of CIP-002-5.1 R1:

1. First, Todd talked about “assets” being classified as High, Medium and Low impact. Of course, this is how virtually all NERC entities started their R1 compliance process, and it’s how all of the Regions understand the process as well.[ii] However, nowhere in R1 (or Attachment 1) is the entity told to do this. What the entity is told to classify are BES Cyber Systems, not assets. R1 sends the user to Attachment 1 to determine the classification of each BCS, depending on whether the BCS meets the High, Medium or Low impact criteria. There is nothing about classifying High or Medium impact assets themselves, only Lows (and even that is indirect – see the next item). Of course, virtually all entities and all regions but one (or maybe two) are assuming the first step in R1 compliance is to classify “assets” as High, Medium or Low impact; but this implicit requirement isn’t found anywhere in the actual wording.
2. R1 does tell the user to identify “assets containing Low impact” BCS – of course, Todd’s presentation used the same wording. Looking just at that wording, it seems quite clear there is only one way to do this: a) inventory cyber assets at every asset (High, Medium and Low impact) owned by the entity; b) identify Cyber Assets among those; c) identify Cyber Assets that meet the BCA definition; and d) finally aggregate these into BCS. At that point, the entity will be able to determine whether an asset – that has not already been identified as High or Medium impact – “contains” Low BCS. But there’s a problem with this, since both R1 and Attachment 1 state that no list of BCS is required for Low assets. So how is the entity going to identify assets containing Low BCS without identifying BCS? Of course, virtually all entities and regions are interpreting “assets containing Low BCS” to mean “BES assets not already identified as High or Medium impact”; with this adjustment, the meaning is perfectly understandable and doesn’t require a list of Low BCS. This is fine – but it’s not what the requirement says, or Attachment 1 either.
3. Just about all of the regions are telling their members that they need to identify all of their assets that correspond to one of the list of six asset types in R1, then “run these through” the Attachment 1 criteria to determine which are High, Medium and Low impact; Todd’s methodology also started that way. Again, this is a fine idea. But what do the actual criteria apply to? Let’s see…Criterion 2 applies to “reactive resources”. I don’t see that on the list of six assets. Criterion 2.3 applies to “Generation Facilities”. Since Facilities is a defined term, this must be a single unit in a generating plant, not the plant itself; again, not on the list. Criteria 2.4, 2.5, 2.7 and 2.8 apply to “Transmission Facilities”; these are lines, buses, transformers, etc. – but not substations, so the list of six doesn’t apply to these criteria either. I could go on…The point is that very few of the criteria actually apply to one of the six asset types – in fact, the only criteria that do actually apply to one of those six asset types are those that deal with control centers. Yet NERC entities are being told by their regions that the criteria do apply to these six asset types, directly contradicting what’s actually in black and white in CIP-002-5.1. Once again, this isn’t a problem in the short term, since the entities and the regions are in agreement on this point. Also once again, the problem is this is not what the requirement says, and having this disconnect will lead to longer-term problems (see below).

There are lots of other ways in which the widely-accepted methodology for complying with CIP-002-5.1 R1 directly contradicts the wording of R1 and Attachment 1; in fact, of the five steps listed in the previous post in this series, all but the first are either not stated in R1 or are directly contradicted by its wording (I’ll have more to say on all of these issues as I put out more posts in this series on Rewriting CIP-002). Again, I’m not criticizing RF or any of the other regions, or any NERC entities, for using this simple interpretation of R1; indeed, I think it’s the only way that one can make sense of that requirement.  But it is important that everyone throw away the idea that this interpretation is based on the requirement itself; it just isn’t. It is literally true that the only practical methodology for complying with CIP-002-5.1 R1 requires the entity to "rewrite" the wording of the requirement itself.

So what’s to be done? Should RF and the other regions stop whatever they’re doing and bring all the auditors together for a month or more, so they can try to figure out what the wording of R1 actually means and come up with a common audit methodology – one that conforms as closely as possible to the actual wording of R1 and Attachment 1? Or should they continue following the fairly simple methodology that all the entities and regions (and NERC itself) currently understand to be the correct methodology for R1 – even though this doesn’t conform to the wording of the requirement?

Obviously, the latter is the only course to take – the former is completely unworkable. However, at the same time, I believe someone needs to draft a SAR to rewrite CIP-002, and the process of rewriting it must begin. But that process will take probably three years. In the meantime, there needs to be a consensus among NERC, the regions, and the entities that the simple methodology is the one to follow (or something close to it – there would actually be a few more steps required, but they’re all also being followed today).

This also means that no region, including RF, can truly say it’s auditing to the strict wording of CIP-002-5.1 R1. There is simply no way to audit R1, other than by coming up with a workable “interpretation” of how to comply with the requirement. As I said, the NERC community has actually done that without knowing it. They just need to acknowledge that this is an interpretation, not the strict wording of the requirement. And the community needs to start working on the only real fix to this problem – rewriting CIP-002.

In the meantime, I hope it’s clear why I’ve been saying for a while that CIP-002-5.1 R1 will never be enforceable until it is rewritten (other than in the case of an entity that more or less blows it off and doesn’t even try to comply - I'm sure they will still be issued PVs. I don’t know any like this, but I’m sure a few exist.). How would any auditor write up an entity for not following a compliance procedure that isn’t even in the requirement? The only question in my mind is whether this non-enforceability of R1 (which is after all the fundamental requirement in CIP v5 and v6) will spread to all of the other requirements.

For the moment, I’m thinking it won’t – that is, that the other requirements can be enforced, as long as the stipulation is made that whatever list of BCS the entity came up with in CIP-002 R1 is valid. But I’m not sure even that will work in the long run, especially once an entity challenges a large fine by going to court. And this is the worst part: as long as CIP-002-5.1 R1 remains the current version of the standard, it is very possible that four or five years from now, the entire v5/v6 edifice will be invalidated by some legal ruling. And what does the industry do then? Go back to v3? Decide the NERC CIP experiment has failed and turn cyber regulation over to DoE or DHS? Just give up on CIP and hope Congress doesn’t notice? Lots of great choices!

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

---

[i] Of course, there is the slight problem that this is probably a year too late to help most entities. With about five months remaining before the compliance date, it’s a little late for entities to be identifying cyber assets in scope for the first time. When available, it will of course help in getting evidence together for an audit.

[ii] There are one or two regions that will most likely call the three asset types “assets likely to contain a High BCS”, “assets likely to contain a Medium BCS” and “assets likely to contain a Low BCS”. This fits a little better with the wording of R1, but the fact remains that R1 (or Attachment 1) never tells the entity to classify assets or “assets that contain High or Medium BCS” (it does require identification of assets containing Low BCS). The entity is told to “consider” six asset types, but those are possible locations where BCS can be found, not a list of assets to be classified H/M/L. It is the BCS that are classified H/M/L, not the assets – according to the wording of R1 and Attachment 1. This is because the criteria apply to BCS, not assets. Of course, the fact that it is impossible to classify BCS without basing that classification on the asset it’s associated with was overlooked when R1 was drafted. This is the primary problem in CIP-002 R1, although certainly not the only one.