OT vs. IT risks in CIP-013

If you’re looking for today’s pandemic post, go to my new blog. If you’re looking for my cyber/NERC CIP post, you’ve come to the right place.

The webinar on Vendor Risk Management Lifecycle that I presented on Monday for the NERC RSTC Supply Chain Working Group was well attended. I was most pleased about the questions at the end, which showed people had been paying attention to the presentation and were already thinking about how it applied in their situations.

In the presentation (which should be available as a recording shortly – I’ll let you know when it’s available. If you’d like to see the slides now, send me an email), I emphasized one of the most important aspects of my approach to supply chain cyber risk management and CIP-013: the difference between IT and OT risks. There ended up being a lot of discussion of this topic in the Q&A session.

Since I didn’t spend a huge amount of time on this topic during the presentation - and of course in the Q&A session there wasn’t time to do much more than answer the specific question – I would like to elaborate on that topic now. I think understanding this topic is very important, since not understanding it could lead to your wasting a lot of time; more importantly, it might lead to compliance risk for CIP-013 (and I couldn’t discuss the latter point at all in the webinar, since in the webinar we’re just supposed to talk about supply chain security, not CIP-013 compliance).

I think having an efficient and effective supply chain cyber risk management plan requires addressing as many risks as possible. If you just address a small number of risks, I think you’re misusing resources. Over the last 15 months of working on CIP-013, one thing I’ve come to realize is that once you have the mechanism in place to identify, assess and mitigate supply chain cyber risks, the incremental cost for addressing each risk is very small.

This is because just about no risks that a NERC entity could address in its CIP-013 plan will require you to spend a lot of money or time putting in some big new system, training a lot of staff members to do something perfectly, etc. Literally all of the risks that I’ve identified, that apply to the entity itself, can be mitigated by putting in place a policy or procedure. There are a few risks that apply to vendors, for which the vendor might have to implement a new system (such as MFA for their remote access system), but none that I can see for NERC entities with High or Medium impact BES Cyber Systems (since controls you put in place for CIP-004, -005, -007, -010 and maybe one or two other standards will mitigate a lot of supply chain risks in CIP-013 as well. Now, doesn’t that make you feel good?).

So on the one hand it’s good to identify as many risks as possible in your CIP-013 plan. On the other hand, you can waste time and money, and perhaps cause unnecessary CIP-013 compliance risk, if you’re not careful to just focus on risks that can have a more-than-negligible impact on the BES. If the risk has very little to do with the BES, don’t include it.

I see potential risks for CIP-013 as divided into “pure” IT risks, “pure” OT risks and mixed IT/OT risks. You need to focus on the latter two, not the former. Let’s look at the NATF Criteria, which I think are quite good. I’ve spent a lot of time recently incorporating all of the Criteria into the set of Vulnerabilities that my clients and I have decided are important to consider (although not necessarily mitigate – maybe I’ll discuss that point in another post) in CIP-013. They cover a range of pure OT and mixed IT/OT risks, but they don’t include any pure IT risks.

Here are two mixed IT/OT risks from the Criteria:

• Criterion 5 reads “Supplier requires approval for access based on need for all employees and contractors with access to supplier’s assets and facilities.” Obviously, this is just as important for OT as it is for IT.
• Criterion 22 reads “Supplier has processes to notify entity of any mergers and acquisitions as soon as legally permissible.” Again, there’s no argument that this is important in both domains.

What about pure IT risks? As I said, I haven’t identified any of these in the Criteria, but I know they show up a lot in questionnaires and contract language, when those are borrowed from some organization’s IT procurement function. My example comes from the EEI procurement language document v2, which includes a section (on page 13) titled “Cryptographic Requirements”. This starts with the sentence “Contractor shall document how the cryptographic system protects the confidentiality, data integrity, authentication, and non-repudiation of devices and data flows in the underlying system as specified by Company.”

Let’s see a show of hands: How many run control systems – say, your EMS – that encrypt their data? I didn’t think I’d see any hands. Generally, encrypting data isn’t much of a concern for data within a control center or substation, whereas not introducing latency and making sure data are always accessible immediately are big concerns. Yet, if a NERC entity were to include this section in contract language they ask their vendors to accept, there could be a lot of hair-pulling and back-and-forth between lawyers, all over a section that doesn’t even address a BES concern.

Of course, encryption is a big concern for many IT systems holding payroll, health records, etc. When procuring those systems, it makes lots of sense to make sure appropriate encryption is provided, if that’s a requirement for the system. And this is why it’s not a good idea to recycle IT vendor questionnaires, contract language, RFPs, etc. for OT purposes. Keep the IT and OT procurement worlds separate, even though many individual IT questions, etc. can be used for OT or BES purposes. There’s nothing illegal, immoral or fattening about mixing IT and OT vendor questions and contract language – but it is a big diversion of attention and resources from areas where they can be put to much better use.

However, there’s a bigger problem with mixing IT and OT when it comes to CIP-013 compliance. Keep in mind that, even though you have great freedom in developing your supply chain cyber risk management plan in CIP-013 R1, the situation changes drastically when you implement the plan in R2. At that point, you need to consider your R1 plan to be just like an extremely prescriptive requirement in the CIP 2-11 standards – perhaps even like..shudder…CIP-007 R2.

In other words, once you have written your plan, you need to make sure you live up to it word for word. This means that, if your plan requires you to take a bunch of steps to mitigate a set of pure IT risks (through contract language, RFPs, etc), you have to make sure you do that. So if you have identified encryption (more exactly, data privacy) as a risk that you’ll mitigate, you’ll need to include language in your contracts, questions in your questionnaires, etc. that address encryption. And if you slip up and leave it out at some point, you might be found in violation, since you didn’t faithfully implement your R1 plan in R2.

So just focus on risks that are important for OT. That will be work enough!

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. Are you working on your CIP-013 plan and you would like some help on it? Or would you like me to review what you’ve written so far and let you know what could be improved? Just drop me an email!