What does CIP-013 R1.2 tell us?

In a recent post, I pointed out that CIP-013 R1.1 is close to un-auditable. This is because it requires the entity to develop (and implement) a supply chain cyber security risk management plan, but it gives very little information about what should be in the plan. Specifically, it should include a list of risks that should be addressed in the plan, but it doesn’t do that – meaning the entity is on their own to draw up that list[i]. However, R1.1 does provide some high-level information on what the plan should cover; I discussed that in the post.

Now I want to turn to R1.2. What does this requirement tell us? As you know if you’ve read CIP-013, R1.2 provides a list of six “things” that the entity needs to do. What are these things, and how do they relate to the supply chain cyber security risk management plan that’s mandated in R1.1?

Let’s look at the first thing, numbered R1.2.1: “Notification by the vendor of vendor-identified incidents related to the products or services provided to the Responsible Entity that pose cyber security risk to the Responsible Entity”. Let’s pull this apart. It’s essentially saying that a vendor needs to notify you (i.e. the NERC entity responsible for compliance with CIP-013) when they identify a security incident related to products or services you buy from them.

How does this relate to the R1.1 plan? R1.1 says the Responsible Entity needs to identify supply chain cyber security risks. It doesn’t also say you also have to mitigate those risks, but that is clearly implied. What would be the purpose of CIP-013 if you were just required to identify a bunch of big, hairy risks you face, then you could simply declare your job done? It would obviously make no sense to do that, and I predict that anyone who omits risk mitigation in their actual CIP-013 R1.1 plan will not fare well at the hands of their auditor.[ii]

So the six things in R1.2 must be either risks or mitigations. They clearly aren’t risks, so they must be mitigations. In other words, each one lists a high-level mitigation for a particular supply chain cyber security risk. The entity is required to implement all six of these mitigations. While the risks that are being mitigated aren’t explicitly stated, it isn’t too hard to state them:

1. R1.2.1 (quoted above) describes mitigation of the risk that a security breach at a vendor won’t be reported in a timely fashion to users of the vendor’s products, leading to cyber security incidents involving the vendor’s systems installed on user networks.
2. R1.2.2 reads “Coordination of responses to vendor-identified incidents related to the products or services provided to the Responsible Entity that pose cyber security risk to the Responsible Entity”. This is mitigation of the risk that a vendor whose products are found to have a serious vulnerability won’t provide adequate assistance to their users in mitigating that vulnerability, leading again to security incidents at users, caused by the vendor’s products.
3. R1.2.3 reads “Notification by vendors when remote or onsite access should no longer be granted to vendor representatives”. This is a mitigation of the risk that a vendor will terminate an employee who had electronic and/or physical access to users’ systems, and that ex-employee will take out their resentment for this action on those systems.
4. The mitigation described by R1.2.4 is “Disclosure by vendors of known vulnerabilities related to the products or services provided to the Responsible Entity”.  This mitigates the risk that users will experience cyber security incidents that could have been avoided had they been notified of the vulnerabilities.
5. R1.2.5 reads “Verification of software integrity and authenticity of all software and patches provided by the vendor for use in the BES Cyber System”. Of course, this is really two mitigations, addressing two risks. Verification of software integrity mitigates the risk that a malicious actor will tamper with a vendor’s software or firmware during the process of delivery (electronic or on physical media) to the user. Verification of software authenticity mitigates the risk that a malicious actor will set up a fake web site or otherwise impersonate the vendor, so that the user obtains software or firmware that is damaging to their systems.
6. Finally, R1.2.6 describes this mitigation: “Coordination of controls for (i) vendor-initiated Interactive Remote Access, and (ii) system-to-system remote access with a vendor(s)”. The risk here is the one behind the recent (but ongoing) Russian attempts to compromise grid control systems by first compromising vendors and then hijacking their ability to access their products remotely for maintenance and troubleshooting purposes.

So CIP-013 R1.1 calls for a supply chain cyber security risk management plan, but doesn’t identify the risks that need to be addressed in that plan. On the other hand, R1.2 simply lists six supply chain risks (and their mitigations) and tells the entity to “address” them. So how are the two parts of R1 related to each other? Is this an either/or requirement, where you have to comply with R1.1 or R1.2, but not both? My interpretation is that the six risks in R1.2 must without question be included in the R1.1 plan, but they in no way are intended to be the only risks that are identified and mitigated in the plan.

It would be very hard to argue that the six risks are all that need to be included in the plan, since R1.1 calls on the entity to “identify and assess 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)”. It certainly doesn’t just say “Develop a plan to implement the six risk mitigations in R1.2.”

Yet if you look at almost any of the guidance on, and discussion of, CIP-013 that has come out from NERC or the Regions as well as other organizations like NATF, you’ll see close to no discussion of anything but these six things^[iii]. I haven’t seen any discussion from NERC or anyone else (other than myself) about what should go into a CIP-013 R1.1 supply chain cyber security risk management plan.  Is this because the six risks (and their mitigations) that I’ve just enumerated are far more important than all other supply chain cyber security risks? Is that why the drafting team specifically called them out in R1.2?

I certainly won’t deny that these are important risks. However, they are called out in R1.2 because FERC specifically required that these six mitigations be included in the new standard, when they ordered that it be developed in July 2016[iv].

But there are certainly lots of other supply chain cyber security risks that should be addressed as well. Last week, I was fortunate to be able to attend the Software and Supply Chain Assurance Fall Forum, held at the offices of the MITRE Corporation in McLean, Virginia. This is a quarterly event that has been going on for a couple of years, although I just recently heard about it. It is a gathering of cyber security professionals working at various U.S. Departments (including DoD) and the “Three-letter Agencies”, who are very concerned about supply chain security. I will write a post on some things I learned at this meeting in the near future.

The group now includes attendees from private industry, and this meeting’s theme was the energy industry. There was some discussion of CIP-013, and Howard Gugel of NERC gave a very good presentation on the standard and all the activities going on around it. However, Howard unsurprisingly didn’t dwell on the idea of the R1.1 plan (frankly, I’m not sure he even mentioned it) and spent more time discussing the six mitigations in R1.2, and especially the question of the role of contract language in obtaining vendor participation for addressing those six mitigations (since they are all vendor risks).[v]

In the Q&A period, two audience members brought up risks they thought were very important, that they were surprised weren’t mentioned by Howard. One questioner brought up[vi] the risk of malicious code and back doors being embedded in chips purchased by a vendor in Asian markets because they are low cost – which has been discussed a lot in the past few years.

The other was the risk of unpatched vulnerabilities in software that was developed by the NERC entity itself, or was custom-developed for it. Both CIP-007 R2 and CIP-013 R1.2.5 only deal with patches released by vendors for their software. The gentleman who asked the question (who was the main organizer of the conference) was incredulous that this risk was nowhere addressed in CIP. I pointed out that this was the whole idea of the R1.1 plan – that the entity needed to consider all of the important risks in their plan, not just the six from R1.2. Of course, there are lots of other supply chain risks we could discuss as well – some of which you’ll find in the NERC/EPRI Supply Chain Risk Assessment report from September.

And folks, here’s the point of this post: Supply chain is by far the biggest cyber threat area for most industries now, and without doubt it’s the most serious for the power industry – just look at the Russian attacks. If the industry treats CIP-013 as just being about the six risks in R1.2 and nothing else, CIP-013 won’t mark a watershed in grid security (as well as supply chain security in general) – which it could be if implemented properly. Even more importantly, you will be leaving your OT network completely open to a lot of serious supply chain security risks, just because they didn’t happen to be one of the six listed in R1.2. I certainly hope NERC will wake up and realize they have to make an effort to help the entities understand the need for developing a comprehensive supply chain cyber security risk management plan. And maybe FERC can nudge them a little in that direction when they approve CIP-013.

Before I go, I want to bring up one concern that a lot of people may have – especially when they hear me bringing up the need to “comprehensively” treat all supply chain security risks. Does this mean that, instead of just worrying about six risks, you’ll have to worry about say five times that number? The six risks are already looking like a good amount of work. Do you really have the bandwidth and the resources to address all important supply chain security risks in your plan?

I want to remind you that this isn’t a supply chain cyber security plan; it’s a supply chain cyber security risk management plan. The essence of risk management is that you consider the degree of risk posed by each threat you face, and then allocate your resources toward mitigating the most serious threats. For threats that pose less risk, you allocate fewer resources or perhaps none at all.

Whatever the amount of dollars or hours you have available to spend on risk mitigation, you will always mitigate the most risk – i.e. get the most bang for your buck – if you allocate those toward the greatest risks. With prescriptive requirements – like most of the “legacy” CIP requirements, and like CIP-013 R1.2 – you don’t get any choice on how you allocate your resources. You have to spend whatever it takes to comply with the prescriptive requirements, and if you have a few nickels left over you might try to mitigate a couple other risks to a small degree – even though you may think these other risks are much greater than the ones addressed by the prescriptive requirements. When it is up to you to identify threats, rank them, and mitigate them according to the risk each one poses, your entity will be more secure – and the BES will be, too. What’s to lose by doing this?

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. And if you’re a security vendor to the power industry, TALLC can help you by developing marketing materials, delivering webinars, etc. To discuss any of this, you can email me at the same address.                   

---

[i] To speak more accurately, the problem isn’t exactly that R1.1 doesn’t provide information about what should be in the plan. The real problem is that NERC’s very prescriptive enforcement format (based on auditing, of course), simply isn’t suited for plan-based requirements like CIP-013 R1. If there were a collaborative format in which the Regions could freely work with an entity to make sure they developed a good plan, then worked with them to make sure the plan was implemented well, the fact that R1.1 doesn’t provide much guidance on what should be in the plan wouldn’t matter so much.  

But because NERC only knows how to do strict auditing-based enforcement, it simply isn’t possible for them to officially work with the entity to understand what they need to do to develop a good plan – because of auditor independence concerns, of course. To some degree, all of the Regions actually do work with their member entities as they come into compliance – and some more than others. But it is always a kind of don’t ask/don’t tell sort of enterprise. I hope someday NERC can have a different enforcement model for the CIP standards, since cybersecurity is completely different from electrical engineering – which is ultimately what the 693 standards are based on. Prescriptive requirements and audits just don’t work for cyber. 

[ii] However, this is a pretty amazing omission. It would be like an ordinance for obeying stop signs spending a lot of time describing the different types of stop signs, but never actually requiring that you stop for one! As I said, I don’t think there’s any possibility that this omission will invalidate CIP-013-1, but I certainly hope FERC adds this to their to-do list for NERC for CIP-013-2, as they develop their Order approving CIP-013-1. I can think of a few other things I would like to see on that to-do list as well, so if one of the Commissioners wants to call me or invite me over for beers (I would come, even though I live in Chicago! – although I wish they’d invited me when I was in DC and McLean, VA last week), I’ll be glad to describe my ideas to them. These have all been stated in my posts at various times, but who has time to read through all of those things? I certainly don’t. 

[iii] The one exception to this rule that I know of is the recent NERC Supply Chain Risk Assessment report, which was prepared by EPRI. It is a good document, and does list some different supply chain risks that have nothing to do with the six things. However, it also doesn’t even pretend to provide guidance for CIP-013 compliance. 

[iv] The six mitigations appear at different points in the order, but they all were directly ordered by FERC. The drafting team had the good idea to gather them all in one place in the new standard, rather than have six separate prescriptive requirements for them. 

[v] As much as I think it’s a big mistake just to focus on the “six things” in developing your R1.1 plan, I think it’s an even bigger mistake to believe that the only real way to mitigate the six risks is to use contract language, as I discussed in this post. 

[vi] I admit this person brought up his question during a different discussion of CIP-013 on the first day of the conference (Howard spoke on the second day). My response discussed below was also given on the first day.