What’s the Deal with all these “Plans”, anyway?

You may have noticed that I have been writing a lot about how CIP-013 R1 and CIP-014 R5 have been and will be audited lately. And guess what? I see problems ahead for both standards. The two requirements differ in important ways, but there is one common element to both of them: They require that the entity develop and implement a “plan” to achieve the objective of the standard.

There are four currently enforced CIP requirements that mandate the entity to develop (and implement) a plan. One is CIP-014 R5, which requires a physical security plan. The second is CIP-003 R2, which requires that an entity that owns Low impact BES Cyber Systems shall “implement one or more documented cyber security plan(s) for its low impact BES Cyber Systems that include the sections in Attachment 1.” The third requirement is CIP-010 R4, which says that an entity with High or Medium impact BCS “shall implement, except under CIP Exceptional Circumstances, one or more documented plan(s) for Transient Cyber Assets and Removable Media that include the sections in Attachment 1.”

The fourth requirement is CIP-011 R1, which mandates that “Each Responsible Entity shall implement one or more documented information protection program(s) that collectively includes each of the applicable requirement parts in CIP-011-2 Table R1 – Information Protection.” I don’t see much difference between how the word “program” is used in this requirement and how “plan” is used in the other two requirements, as well as how it is used in CIP-013 and -014. So I’m also going to anoint CIP-11 R1 a “plan” requirement. 

Why has there been this proliferation of “plan” requirements? And what is common to them all? The most important common trait of all of these standards and requirements is that they’re objectives-based (I used to call them “non-prescriptive”. However, I think a non-prescriptive requirement inherently has to be objectives-based, and vice versa. So I will use the terms interchangeably, even though their dictionary definitions would be different).

Just to make sure everybody understands what I’m talking about, an objectives-based requirement is one that simply states an objective and allows the entity complying with it to determine the best means to achieve that objective. The entity is then audited on whether or not they have achieved the objective. This contrasts with a prescriptive requirement, which prescribes a certain set of steps that must be taken (often within a certain timeframe). The entity is audited on whether they have executed that set of steps by the required times; they aren’t judged on whether they have achieved some specific objective (in fact, IMHO the “objective” of a prescriptive requirement can only be truthfully described as the set of steps prescribed in the requirement, even though the requirement may well have a stated objective).

Note (July 18, 2018): Since I'm about to link this post in one I'm going to put up today, I want to point out something I didn't realize when I wrote this post: An objectives-based requirement has to have a measurable objective to be auditable. For the NERC 693 requirements, this isn't usually a problem (for example, in FAC-003 the required minimum clearances with trees can be calculated and measured). Unfortunately, I know of no way to have a measurable cybersecurity objective - unless the "objective" is something like checking for new patches every 35 days, in which case the requirement is prescriptive.

Why does CIP sometimes require a plan?

But where does “plan” come in with all this? If you want to write an objectives-based requirement or standard, do you always have to write it so that it requires a plan? For that matter, do all objectives-based requirements require a plan?

I can confidently answer no to both of these questions. In fact, there are currently objectives-based requirements in the CIP standards that don’t require a plan. For example, CIP-007 R3, anti-malware, is often my poster child for an objectives-based requirement; it simply requires that the entity “Deploy method(s) to deter, detect, or prevent malicious code.” This is about as non-prescriptive as you can get. But CIP-007 R3 doesn’t mandate a “plan” or even a “program”.[i]

Note 7/18/18: I now consider CIP-007 R3 to be a plan-based requirement. If it were really a pure objectives-based requirement, it would say something like "Deter, detect or prevent malicious code." And since that isn't measurable, this wouldn't be a real objectives-based requirement. But the fact that what it really requires is "methods" to deter, etc, it is measurable since the entity can be judged on whether or not it has or hasn't done that. 

However, I don't see any real difference between requiring methods and requiring a plan, which will of course dictate what the methods should be for each BES Cyber System in scope. Of course, the whole idea of this requirement is the method used can vary from one system to the next. In order to know how your organization will deter, detect or prevent malicious code for each system in scope, you need to have a plan.

Given that mere logic doesn’t require that an objectives-based requirement be based on a plan, why do the four requirements above mandate a plan? Was it that a particular Standards Drafting Team went “plan”-crazy and decided to make everything a plan? That definitely isn’t the case, since these five standards or requirements were drafted by four different teams![ii] There must be some reason why these four different groups of people all thought that it was preferable for their objectives-based requirements (or standards) to mandate that the entity have a plan, not just that they should achieve a particular objective.

I attended some meetings of all four of the drafting teams in question, and I can’t remember any discussion about this question (although I’m sure there was one in each case). But I think I can guess what may have been the reason why they all did this: Each of the objectives of these five standards or requirements is pretty broad: respectively, physical protection of key substations (CIP-014), supply chain security (CIP-013), electronic and physical access control for Low impact assets (CIP-003 R2), mitigation of the threat posed by Transient Cyber Assets and Removable Media (CIP-010 R4), and BCS information protection (CIP-011 R1).

When you’re drafting a requirement to achieve a broad objective, you want to provide some guidance on what the entity should do to achieve that objective, without listing prescriptive requirements which then become the objective themselves. The best example of this is CIP-010 R4, which requires a plan for securely managing Transient Cyber Assets and Removable Media used with Medium and High impact BCS. However, it doesn’t just require a plan, but it lists in Attachment 1 what needs to be in that plan.

Attachment 1 lists three types of devices that must be in scope for the plan, as well as between two and five “topics” (my term) that must be addressed for each of the three types. For example, under the Removable Media device type, there are two topics: Removable Media Authorization and Malicious Code Mitigation. Each topic lists two criteria that must be included in the plan. For example, under Removable Media Authorization, the entity is required to authorize use of Removable Media (thumb drives) by both user and location. Under Malicious Code Mitigation, the user is required to scan the device for malicious code before using it with a Medium or High impact BES Cyber System.

Note that I use the word “required” here, because that is the case. You might ask “Since these are requirements anyway, why does it matter whether or not there’s a plan involved?” However, in the NERC world there is a very important difference between requiring that certain elements be in a plan (as is the case with this requirement) and actually requiring the entity to perform those activities. If the requirement is for a plan, then the auditors will have to audit the plan itself (and also how well it has been implemented). But if the plan elements discussed above (such as “authorize by user and location”) are direct requirements in themselves, then the entity has to maintain records of every single use of removable media with High or Medium impact BCS, to be able to document that they were compliant with these two requirements. That would be a huge paperwork nightmare, and would do very little to advance the cause of cyber security.

The moral of this story is that it seems clear (to me anyway) that “plans” are here to stay in CIP. If you look at the major standards and requirements that have been developed since CIP v5 (including the two standards and three requirements listed above and in end note ii below), all of them require the entity to develop a plan to achieve a particular objective, rather than to achieve the objective itself. And this isn’t an accident, since in the latter case there would be a huge paperwork burden placed on the entity for maintaining compliance evidence.

In my next post, I will delve into the question of how “plan”-type requirements can be audited.

The views and opinions expressed here are my own, and do not reflect those of any organization I work with. 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.

---

[i] The “preamble” to CIP-007 R3 reads “Each Responsible Entity shall implement one or more documented process(es) that collectively include each of the applicable requirement parts in CIP-007-6 Table R3 – Malicious Code Prevention.” You might ask – and if you might not, I’ll ask it for you! – “How would substituting the word “program” or “plan” for “processes” change the meaning of this sentence? If it wouldn’t change the meaning, then you should include this as one of your “plan” requirements, right?

You’re absolutely right when you say this, but I do think there is a real difference between a process on one hand and a plan or program on the other. A plan or program is inherently a document that lays out an objective and describes how that objective will be achieved. The document can describe different means of achieving the objective, and perhaps conditions that would dictate when one or the other means would be preferred. But a process, in my mind, is a listing of a set of required steps. The process itself doesn’t prescribe a goal, or discuss alternate means of achieving that goal.

Now that I think of it, CIP-007 R3 would probably be better off if it did require a plan or program. The objective of malicious code prevention can be achieved in a number of ways; I doubt there’s any fixed methodology (even with a whole lot of “If…Then…Else” loops) that would be able to encompass all those ways. In any case, in CIP-007 R3 the entity won’t be audited on the basis of a plan or program, but on whether they’ve achieved the objective of mitigating the threat of malicious code. And this post is about how a plan/program can be audited.

[ii] CIP-014 was developed by the team expressly convened to address FERC’s order for substation physical security. CIP-013’s team was assembled to address FERC’s supply chain security management order. CIP-003-6 R2 and CIP-010 R4 were developed by the “CIP v6” drafting team, and CIP-011 R1 was developed by the “CIP v5” team.