How NOT to comply with CIP-013, part I

I will admit that I’ve emphasized a little too much that there are many possible ways to comply with CIP-013 R1, and I need to swing the pendulum back in the other direction a little. While it’s true that the standard gives you very little to go on regarding what should be in your R1 plan, it’s also true that there are some things that definitely are required. This is especially true since NERC provided good information in their most recent Evidence Request Tool about what audits will focus on. If something will be audited on, you need to do it – at least that’s what my parents raised me to believe.

This post (and part II to follow very shortly) describes mistakes you can make, that can lead to your being non-compliant with CIP-013.

I. You don’t address both R1.1 and R1.2 in your plan

I’m sure that, even a year after FERC approved CIP-013, many long-time NERC compliance professionals look at R1 and have the following reactions:

1. Their eyes glaze over when they read 1.1. All this talk about identifying and assessing risks, without telling you any concrete steps that you need to undertake, sounds like some sort of mystic writing from the Upanishads, not a NERC requirement. Every other NERC requirement they’ve seen tells you exactly what you need to do and when you need to do it, period.
2. When their eyes fall on R1.2, they grab onto it like an old friend, even though it’s a friend that’s changed since the last time they saw him. The six items in R1.2 don’t tell you exactly what you need to do and when, but they at least do tell you particular objectives you need to meet, such as “Disclosure by vendors of known vulnerabilities related to the products or services provided to the Responsible Entity”.

It’s inevitable that many of these people will decide that R1.2 is the whole of R1, meaning that as long as their plan covers these six risks (there are actually eight, since R1.2.5 and R1.2.6 address two risks each), they’re fine. In fact, when a vendor of a software tool to aid in CIP-013 compliance spoke at GridSecCon, it was clear that he thought R1.2 was all that was required to be in the entity’s supply chain cyber security risk management plan.

Well, it’s not. R1.1 isn’t there just for the fun of it, but because the CIP-013 drafting team was taking FERC seriously when they said in Order 829 that NERC entities should identify supply chain risks to mitigate. True, FERC did require all of the specific items in R1.2 at various points in their Order – and the SDT helpfully gathered them all into one place in the standard – but these are in no way intended to be the only supply chain risks that NERC entities face, or even the most important ones. It’s still up to the entity to identify (in complying with R1.1) other risks that are important and mitigate those, along with the risks in R1.2.

And if you don’t believe me, take a look at NERC’s Evidence Request Spreadsheet 3.0, discussed in the last item below.

II. You don’t address the five risk categories in R1.1

Although it’s not too obvious, R1.1 identifies five categories of supply chain risk that need to be “identified and assessed” in your plan. They are[i]:

1. Product risks from procurement of equipment and software;
2. Risks from procurement of services applying to BCS equipment and software;
3. Product risks from installation of equipment and software;
4. Risks from use of services for BCS (Note: This applies to services on all of your Medium and High impact BCS, not just those you procure after 7/1/20); and
5. Transitions between vendors.

Of course, each of these risk categories can include many different risks. I’ll provide one example for each category:

1. The risk that a supplier’s software development environment will be compromised, and someone will plant a backdoor in software destined for one of your BES Cyber Systems, which they’ll later exploit (as happened with Delta Airlines last year, although in their case it was 800,000 credit card numbers that were stolen).
2. The risk that a utility will contract with a vendor of services for BCS who doesn’t vet their new hires properly. A person with malicious intent will inadvertently be hired and allowed to access – remotely or onsite – some of your BCS.
3. The risk that a software product you install on one of your BCS won’t have the most recent patches applied to it and will be compromised after you install it.
4. The risk that a vendor will fire an employee who has onsite access to your BCS and won’t immediately tell you about it. The fired employee will come to your site and take revenge on the vendor by disabling one of your BCS (of course, this is the risk behind R1.2.3. The risk behind R1.2.6 – actually two risks – also falls in this category. The other four items in R1.2 fall into category a).
5. The risk that, when you leave one vendor and start purchasing from a different one, the first vendor won’t destroy all of the data they have stored about your BES Cyber Systems. Someone will hack into their network and steal the data.

I freely admit that, if you omit one of these categories in your plan (e.g. transitions between vendors), you might not be cited for a potential violation. When most people talk about CIP-013 (including people at NERC and the Regions), they usually discuss risks that fall into categories a and d. However, all five of these categories are called out in R1.1. You need to at least consider all of them. If you decide there aren’t any risks that are likely to apply to you in one of the categories, you should document why you made this decision, but you don’t need to try to dream up risks just for the sake of having at least one in each category.

III. Your procedures don’t match you plan

Whatever is in your R1 plan, there is one thing that is very certain: In R2, you need to do what you said you would do in R1. But what if your procedures don’t match what’s in your plan? CIP-013 isn’t that different from the other CIP standards, in that what really counts is the procedures you write to comply with it. The big difference is that, with say CIP-007 R2, you have to write patch management procedures that match what the different parts of that requirement mandate. With CIP-013 R2, you need to write supply chain security risk management procedures that match the plan that you developed in R1. So in R1.1, you’re literally writing the “requirements” that you have to have procedures for in R1.2!

So how do you avoid being non-compliant in this way? Simple (at least in theory): when you write your plan, you need to make sure there’s nothing in it that you aren’t positive you can do in practice. And if there’s something you’re not sure about, take it out of the plan. You can always add it back later.

For example, suppose you commit in your plan to conducting full security audits of say your top five suppliers. However, when it comes time to do the supplier audits (say, within a year of CIP-013 becoming enforceable), you realize how much staff time and money these will require, and you begin to think of all the other things you could do to mitigate supply chain security risks if you hadn’t committed the time and money to audits. You should certainly be able to change your mind at this point, but you will need to revise your plan so that it will match your new course of action. When you’re audited, you will need to provide both plans, as well as explain why you made the change between them (and emphasize how it will result in greater supply chain security risk mitigation, since you'll use your resources more efficiently).

This isn’t a new development in CIP. Since CIP v1, it has always been clear that you must show that you complied in full with any plan or program that you develop as part of the compliance process. For example, if in your CIP-008 R1 cyber security incident response plan you indicate that you will take a certain step in your incident response, yet your record of a CSIRP tabletop exercise doesn’t indicate you took that step, you can be (and entities have been) cited for this omission.

IV. You don’t have evidence that you fulfilled your plan

CIP-013 R2 is also like most of the other CIP requirements, in that it requires that you have documentation to show you did what you said you would do in your R1 plan. But it differs from most of the other CIP requirements, in that you’re not required – with one exception, discussed in the next section - to have documentation of every instance when you did something that was called out in the plan.

The Measures section of R2 says you must have “documentation to demonstrate implementation of the supply chain cyber security risk management plan(s), which could include, but is not limited to, correspondence, policy documents, or working documents that demonstrate use of the supply chain cyber security risk management plan.” In other words, you must not only show the auditors that you developed a good R1 plan, but that you implemented the plan – yet at the same time, you don’t have to show that you followed it without fail in every instance.

For example, suppose your plan says you will send out a security questionnaire to vendors and suppliers every year. If the answers reveal that a vendor’s controls are weak in a particular area, you will talk with them to point out that you really need them to implement these controls, and to ask if they need your help or advice in implementing those controls (e.g., maybe a vendor really needs a SIEM, but has no experience or understanding of how to go about implementing and maintaining that).

Do you need to show documentation of every questionnaire you sent out and received, as well as of every phone call or email you sent to your vendors to follow up on deficiencies? No, but you do need to provide enough evidence to convince the auditor that you followed up on a deficiency pointed out in a vendor's questionnaire response. The evidence can be emails, records of phone calls, notes of an in-person meeting, etc.

However, there is one part of your plan that does require evidence of every instance in which it was applied. I’ll talk about that in the next section.

V. You don’t execute and document procurement risk assessments (PRAs)

NERC’s most recent Evidence Request Spreadsheet v3.0 shows what evidence will be required in audit Data Requests:

1. In the Level 1 DR, you will be required to “Provide each documented plan(s) that addresses the applicable requirement parts in CIP-013 R1.” In other words, you have to provide your plan and show it addressed both R1.1 and R1.2.
2. In the Level 1 DR, you will also have to list all of the “procurements” that were planned or in effect for high/medium impact BCS during the audit period. If you’re not sure exactly what a procurement is and when it starts and ends, see this recent post.
3. In the Level 2 DR, the auditors will take a random sample of procurements from the list you provided, and ask you to provide the following for each selected procurement:
1. “..evidence of the identification and assessment of cyber security risk(s) to the Bulk Electric System from vendor products or services resulting from: (i) procuring and installing vendor equipment and software; and (ii) transitions from one vendor(s) to another vendor(s).” In other words, evidence that you complied with R1.1 in your PRA.
2. “..the following evidence:

                                                               i.      Notification by the vendor of vendor-identified incidents;

                                                             ii.      Coordination of responses to vendor-identified incidents;

                                                            iii.      Notification by vendors when remote or onsite access should no longer be granted to vendor representatives;

                                                           iv.      Disclosure by vendors of known vulnerabilities;

                                                             v.      Verification of software integrity and authenticity of all software and patches provided by the vendor for use in the BES Cyber System; and

                                                           vi.      Coordination of controls for (i) vendor-initiated Interactive Remote Access, and (ii) system-to-system remote access with a vendor(s).

In other words, evidence that you complied with R1.2 in your PRA.

I think items 1 and 2 above are fairly self-explanatory at this point. However, what does item 3 mean? In other words, what should your PRA evidence contain, and what documentation will you need for it? At a high level, I think it should contain the following:

1. The list of risks (although I use the term threats here) that you considered in the PRA. Do you remember the set of threats that you identified for mitigation in R1.1? You should consider a subset of these, namely those that apply to the vendor or supplier in question. And how do you determine what these are? Well, that’s magic, but if you’re interested in more information on it, see the last paragraph below.
2. How you assessed those threats, to determine which were already mitigated (either by the supplier or vendor or by your organization itself) and which still need to be mitigated (at this point, that usually means your organization has to mitigate them, but there is still time to ask the supplier or vendor to help you – e.g. require that the vendor provide a security vulnerability assessment before shipping the product(s) to you). You do this using the vendor or supplier risk score (which should be calculated for each threat, not just an overall score for the vendor or supplier), combined with the product or service risk score (which would be a single overall score for that product or service) to get a “procurement risk score”. If that score is low, then this risk is mitigated for this procurement and no further action is needed on it. If it’s high or medium (or perhaps just high, if you’re being conservative), then you do need to determine what additional mitigations are required during the procurement to bring it to low. In my way of seeing things, a low risk score means the risk is mitigated - in fact, that's my definition of mitigation.
3. How you determined the mitigations required in this procurement, based on the risks you considered in the first step above (and that’s magic, too! Again, see the last paragraph below).

Even though you don’t need to provide instance-by-instance evidence for all other items in your R1.1 plan, for procurements you do, since the auditors will randomly sample the procurements and require evidence for certain ones - so you obviously need evidence for all of them before the audit. The spreadsheets, etc. that you create and utilitize as part of the PRA should be retained, and if they're properly designed, will provide compliance evidence without any further changes.

Would you like a little more explanation of some of the things I’ve just said? I’d be glad to do that – for your organization alone. I’m still offering a free two-hour (or less, if you prefer) webinar on CIP-013 compliance, for anybody in your organization who will be involved in the program. This includes people in procurement, legal, cybersecurity, and – oh, yes! – NERC compliance. The agenda is very flexible, so we’ll develop it in a discussion before the webinar. If you’re interested in this offer, please drop me an email at tom@tomalrich.com, and I’ll send you more information.

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] I’m not going to go through the reasoning I used to arrive at this list, but I hope it won’t be too hard to discern. If you question how I got anything on this list, drop me an email and I’ll tell you.