(less than) Three months!

In case you forgot (like I did), July 1 was the day compliance with CIP-013-1 was due. Everybody did that, right? Of course you didn’t, because October 1 is now the compliance date. Will the date get pushed back again, since the pandemic isn’t over yet? I’d say it’s highly unlikely. There was a lot of sniping at NERC and FERC in some circles (the Professional CIP Snipers Association, I believe they’re called. You know who I mean…) for even pushing it back once; I doubt anyone at NERC or FERC is eager to see that sniping renewed.

This is especially true since the Executive Order is now out. That’s alleged to show there’s a serious foreign campaign against the US power grid, although the details of that remain to be filled in. I’ll agree there are serious supply chain risks to the electric power grid, but they have very little to do with foreign attackers and everything to do with poor cybersecurity practices at suppliers of OT systems, as well as in some cases lack of appropriate good cyber practices at electric utilities. We’d be much better off paying attention to the threat in our back yard, not just the hypothesized one in China.

I’m sure every NERC Entity who has to comply has made some progress on their CIP 13 program, so hopefully it’s not like you have to start from scratch today. And even if you do have to start from scratch (you don’t have to raise your hand if that’s the case), you certainly have time to put together a good program by October 1. I’ve been working on CIP-013 compliance for a year and a half with a number of electric utilities, and I’m now writing a book with Steve Briggs on it (if you ever want to find out how much you still need to learn about a subject you thought you were an expert in, I recommend writing a book about it!), so I think I can now give you a pretty complete picture of what you have to do, from start to finish.

1. You need to identify all of the Products in scope for CIP-013-1 at your organization. Of course, BES Cyber Systems are what’s in scope, but in many if not most cases NERC entities buy hardware and software components of BCS, rather than BCS themselves (e.g. they’ll buy a bunch of different servers, switches, etc. for their EMS, as well as the different software packages that run on them. You have to treat all of these components as different Products, even if they’re from one Supplier). For each component, you should identify Suppliers and Vendors, where the Supplier is the entity that develops or manufactures the Product and the Vendor is the entity that sells it to you. Of course, in many cases they are the same organization. Note that you can group both of these together under the word Vendor in your compliance documentation if you want (I don’t think it’s necessary), but the point is that many risks that apply to Suppliers don’t apply to Vendors at all (e.g. maintaining a secure development environment), and a few Risks that apply to Vendors don’t apply to Suppliers at all. I believe it’s much easier if you treat them separately, even if you end up classifying them as “Vendor type 1” or “Vendor type 2” in the actual documentation.
2. Similarly you need to identify all of the Services in scope; these are Services performed on BCS, either onsite or remotely. The big risk with Services is over-identifying them. The Service must be able to directly affect a BCS, like maintenance or troubleshooting. Even a cleaning contractor who has unescorted physical access to medium and high BCS is performing a Service that should be in scope for CIP-013 (the contractor should be in scope for CIP-004 as well). But consulting advice (including on compliance), engineering services, painting services, etc. don’t directly impact BCS, so they shouldn’t be on your list. Of course, you can always put them on the list, but then you’ll be smacking your head if you end up receiving a PNC for something you did or didn’t do with respect to a contractor that didn’t have to be listed in the first place. Note that there are only Vendors of Services, not Suppliers of Services.
3. For compliance with R1.1, you need to “identify” Risks that apply to Procurement of Products, Procurement of Services, Installation (and Use) of Products, Use of Services and Transitions between Vendors. Four of these five items are required in the language of R1.1, and the need to address the fifth - Use of Services - is implied by the six items in R1.2, since five of those apply to Use of Services). Of course, every Risk you identify should be a Risk to the BES, not for example a purely IT Risk, such as one having to do with encrypted data storage or data privacy (of course, IT risks are important when your organization is buying IT systems. You should consider having a separate supply chain cybersecurity risk management program for your IT systems, in which you could address this type of Risk. But trying to use the same list of Risks – and the same questionnaire questions, as discussed below – for both types of systems puts a lot more burden on you, and even more importantly significantly increases your CIP-013 compliance risk footprint, with no corresponding benefit in terms of supply chain risk reduction).
4. For each Risk in R1.1, you need to “assess” it to determine whether it has anything more than a low likelihood of being present in a Supplier’s or Vendor’s environment, or in your (the NERC entity’s) environment. Since I consider low likelihood to be the same thing as saying a Risk has already been mitigated, this means there’s no point in addressing low likelihood risks in your R1 plan (for example, there’s a Risk that a Supplier might not have a firewall, even though they’re connected to the internet. Since it’s just about impossible to believe that any organization that’s connected to the internet today doesn’t have some sort of firewall, I think this can be safely dismissed as a Risk that’s unlikely ever to have a Likelihood other than low).
5. How many Risks do you need to identify in R1.1? I and my clients have identified a little over 100 Risks, of which about 85 apply to Suppliers and Vendors and the rest apply to the NERC entity itself. These are all Risks that have some Likelihood of being present in a Supplier’s or Vendor’s environment, or in the NERC entity’s environment. Do you have to list this many Risks in R1.1? Certainly not. But what I discovered with my clients is that all of the Risks that apply to the NERC entity, and more than 95% of the Risks that apply to a Supplier or Vendor, require just a policy or procedure to mitigate (either the Supplier’s/Vendor’s policy or procedure/policy, or your organization’s) – not installing an expensive new system, hiring an army of consultants, etc. And given that these are all real Risks to the BES (i.e. they could possibly have a likelihood greater than low), you should really try to address as many as you can, since the whole idea of R1.1 is to find the most important Risks and mitigate them.
6. The six items in R1.2 are mitigations of Risks; these are there because FERC ordered they be included in the NERC entity’s plan, in Order 829 in 2016. It’s not hard to state the Risks behind these - although there are actually eight Risks, since R1.2.5 and R1.2.6 address two Risks each. All of these have to be included in your list of Risks – but since they're all important, you probably would have identified them anyway in R1.1.
7. You need to identify Mitigations for all the Risks on your list (and often, one Mitigation will mitigate multiple Risks, just like one Risk might have multiple Mitigations). These Mitigations are almost entirely the policies or procedures that you or your Suppliers or Vendors will need to implement, to mitigate the Risks you have identified in R1.1 and R1.2.
8. You need to determine how you will assess Vendors and Suppliers for the Risks that apply to them. Essentially, there are two ways to do this. The preferred method is a questionnaire. What questions should you include in your questionnaire? That’s pretty simple: You should include at least one question for each Supplier/Vendor Risk in your list, and you shouldn’t include any questions that are based on Risks that aren’t on your list, as I explained in this recent post. The problem is that, if you throw in a bunch of questions that address Risks you haven’t identified as significant enough to be on your list – which of course often happens if you use another organization’s questionnaire - you’re implicitly adding those Risks to your list and you’ve now increased your compliance risk footprint, with no concomitant benefit to your supply chain risk mitigation program. In other words, if you use someone else's questionnaire that has 200 questions, that means you've identified 200 Risks to mitigate, with all that entails.
9. If the Supplier or Vendor won’t answer your questionnaire, you need to “assess” them using other means, such as reviewing any certifications they have (but you need to see a detailed audit report, since just knowing they have a particular certification provides no information on how they stand with respect to each of the Supplier/Vendor Risks on your list). Or reviewing their web site (where they may have posted documents describing their cybersecurity program in specific areas like secure development lifecycle and security vulnerability policy, as found on Cisco’s website). Or buying a third-party assessment like those offered by Fortress, as long as you don't thereby expand the list of Risks you're committed to mitigating. Or – if there’s no better solution available – relying on news articles, opinions of your peers, etc. to form an overall judgment on the firm’s security, even if you can’t develop Likelihood Scores for particular Risks. If you take the last approach, you still should consider the Supplier or Vendor to pose moderate or high likelihood for any Risks for which you can’t be sure where they stand. In other words, just because they have good overall security doesn't mean they have in place say the remote access protections that you want to see.
10. You need to put all of the above into a supply chain cyber risk management Plan (required by R1, of course) that also shows how you will mitigate supply chain cybersecurity Risks through RFPs, contract language, emergency procurements, open source software controls, “fourth-party” software Risks, the R3 review of the plan, etc.
11. The crucial element of your R1 Plan is the Procurement Risk Assessment (which I abbreviate PRA, even though I realize that has another meaning in CIP compliance). This is both a) the point where all the other elements of your Plan come together, and b) the basis of the CIP-013-1 compliance evidence required by the NERC Evidence Request Tool. In your PRA, you need to show that, in each procurement, you fulfilled R1.1 and R1.2, as requested by the ERT.
12. Once you have your Plan worked out, you need to develop procedures and policies to implement the Plan. As I’ve previously pointed out, CIP-013 provides great freedom in how you draw up your Plan in R1. But when you get to R2 and have to implement it, the Plan becomes a straitjacket. You need to implement it as written, just as you do with prescriptive requirements in the other CIP standards (the big difference in CIP-013 is that you don’t need evidence for every instance of compliance, just evidence that you’ve developed a good plan and implemented it).
13. In case you find the above item pretty scary, you need to keep in mind that, if you decide after the compliance date that you need to make some change to your plan, you can do that at any time. However, you also need to make sure that you change your procedures and policies to reflect the changes in your plan.

Remember, we (OK, I) at Tom Alrich LLC are prepared to help you with any of the above items, from helping develop your plan from scratch, to reviewing what you have now and offering suggestions for improvements, to helping you draw up the procedures you need to implement your plan. Drop me an email if you’d like to discuss 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.