Thursday, December 26, 2019

Is CIP-013 prescriptive or non-prescriptive? Yes, definitely



Since the beginning of 2019, I’ve been working almost exclusively on helping clients prepare for compliance with NERC CIP-013. I’ve had a number of “Aha!” moments, when I realized something important that in retrospect should have been obvious from the beginning. For example, I’ve known for a long time that three things are true:

  1. CIP-013 R1 is a non-prescriptive requirement. It tells the entity to develop a supply chain cyber security risk management plan (which I once christened SCCSRMP, taking the idea from Kevin Perry. Since this is the only logical acronym, I’ve been surprised not to hear anyone use it besides me. This may be because the most logical pronunciation of it – “Scuzzy Rump” – sounds vaguely obscene). However, other than saying that the six items in R1.2 need to be included in the plan, it provides no other direct information, other than that the plan must address the five areas of 1) procurement of hardware and software components of BES Cyber Systems; 2) installation of those components; 3) procurement of services for BCS; 4) use of those services (I’ll admit this one is a little hard to discern in the wording, but I promise you it’s there, and R1.2 confirms the SDT had this in mind); and 5) transitions between vendors of BCS components.
  2. CIP-013 R2 requires the entity to implement the SCCSRMP. In fact, that is literally all the requirements says.
  3. Many NERC entities have had unfortunate audit experiences with other plan-based CIP requirements, such as CIP-008 R1, CIP-009 R1, CIP-011 R1, CIP-007 R3 and CIP-010 R4. These entities have found out the hard way that it’s important to make sure you implement everything in your plan, regardless of whether something in the plan is directly stated in the requirement or not. If something is in the plan, you need to carry it out, or at least document why you can’t carry it out in a particular instance.
If you had asked me three months ago whether R2 was also a non-prescriptive requirement, I would probably have said yes, since it seems logical to say that a requirement to implement a plan that isn’t prescriptive is non-prescriptive in itself. However, in combining the above three pieces of information, it dawned on me that this really makes R2 a prescriptive requirement.

Of course, at first this seems strange (and it would have seemed strange to me even three months ago). After all, when you compare CIP-013 R2 to my poster child for a prescriptive requirement, CIP-007 R2 (with CIP-010 R1 a close number two for that coveted title), there’s a huge difference. CIP-007 R2 tells the entity exactly what they need to do, exactly when they need to do it, and exactly what systems they need to do it to, for a set of perhaps ten different actions (some of which aren’t directly stated, but are implicit when you start looking at the language closely). But CIP-013 R2 just tells you to implement the plan from R1, while R1 tells you nothing about what actions should be required in that plan, and nothing about the timing of those actions).

But as I thought about this, I realized there’s no way R2 could be anything but prescriptive. Since it tells you to implement the plan, this means the plan itself provides the set of prescriptive requirements that you have to follow in R2. In other words, rather than just follow the current wording of R2 (which rivals the great haiku masters in conciseness), NERC entities are well advised to effectively “replace” that sparse wording with the “requirements” included in your SCCSRMP! Then you should comply with that wording in the same way you comply with other plan-based CIP requirements, like the five I cited above (BTW, a sixth plan-based requirement is CIP-003-7, which comes into effect 1/1/20).

But note that I said you need to comply with R2 as you would with other plan-based CIP requirements. This was a term I used to use a lot, but now I mostly use the term ‘risk-based’. At first I thought these referred to two different things, but in the last couple years I came to realize they’re actually the same thing, for the following reason:

A plan always has an objective (which is why I also consider ‘objective-based’ to be synonymous with ‘plan-based’). Unless your organization has unlimited resources to throw at BES security and NERC CIP, you’ll always need to choose between measures you will take and measures you won’t take - because you feel the results achieved by the latter won’t justify the resources required to achieve them.

And how will you decide which measures you’ll take and which you won’t? You will either explicitly or implicitly look at risk – there’s no other way to do it. For each measure, you’ll determine (perhaps without explicitly considering it) the degree of risk it mitigates. You’ll choose to implement the measures that mitigate the most risk and not implement those that implement the least risk (in fact, this pretty neatly describes the first half of the CIP-013 compliance methodology that I’ve developed with my clients this year). Because why would you want to spend your resources (money and time) conducting activities that are less effective, when you could spend the same amount of resources and mitigate much more risk? Unless you don’t care whether or not you waste money, of course.

Since risk-based, plan-based and objective-based requirements are one and the same, where does the prescriptive/non-prescriptive dichotomy fit in? I think a non-prescriptive requirement is the same thing as a risk-based, plan-based or objective-based one. I simply can’t think of a case where it might be otherwise (although if anyone can, I’d like to hear about it). And it’s without a doubt true that a prescriptive requirement could never also be one of these four categories.

What’s the difference between complying with plan-based requirements like CIP-011 R1 and true prescriptive requirements like CIP-007 R2? In case you didn’t know this, NERC has a very prescriptive auditing regime. The reason CIP-007 R2 is so burdensome (it’s by far the most-complained-about CIP requirement) is that the NERC entity needs to have documentation of a) every step that was taken, b) for every piece of software in the ESP(s), and c) every time it was taken, over the entire audit period. So if an entity has 200 separate software packages in their ESP, and they have to comply with CIP-007 R2 eleven times a year over the three-year audit period, this means they need to have 6600 pieces of documentation.

And every NERC compliance professional can state, while hanging upside down with their hands tied behind their back in their sleep, the iron rule of NERC compliance: If you didn’t document it, you didn’t do it. Woe betide the unfortunate person who misses one of those 6600 pieces of documentation and then is asked to produce exactly that at audit! Yea verily, all the furies of Hell couldn’t match the anger of that person’s boss, when told the entity has received a PNC finding because of this![i]

And how do you comply with a plan-based requirement, especially CIP-013 R2 (since that’s what this post is about)? In general, you need to decide what are the important elements of your plan and document that you have a program in place to comply with each element. While you will certainly have to retain some documentation of individual instances of compliance, you definitely don’t have to document every instance in which you complied and every system you complied for.

And if you’ll wake up our NERC compliance professional, cut them down from the ceiling and untie their hands, they’ll agree with you that there’s a big difference between complying with a prescriptive requirement and a non-prescriptive one, even if they both require you to take the same set of actions on the same set of systems. So this is one big advantage of the way CIP-013 R1 and R2 are written.

The second advantage is even bigger: After all, you are the one that writes your plan. If you think there’s something in your plan that might be hard for you to comply with (for example, you stated that a particular action needs to be done every month for every system, regardless of the risk posed by that system), what you should do is very simple: Take it out. This is perfectly “legal”, although if you do it after the compliance date, you will need to document why you did that.

Just try that with CIP-007 R2!


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. My offer of a free webinar on CIP-013, specifically for your organization, remains open to NERC entities and vendors of hardware or software components for BES Cyber Systems. To discuss this, you can email me at the same address.

[i] In case you’re going to point out that the solution for having to produce so much audit documentation is to sign on to the Risk-based CMEP program, you can save your breath. I find it hard to believe this cure isn’t almost as damaging – in terms of gallons of stomach acid produced while worrying about compliance (the key measure, IMHO) - as the disease itself.

No comments:

Post a Comment