My CIP-013 Presentation at GridSecCon

As usual, NERC’s annual GridSecCon conference, which was held last week in beautiful St. Paul, Minnesota, was a great success. Every year I say this was the best one ever (I’ve only missed two since it began seven years ago), and this was no exception, both for the great programming and for the very competent organization. This year, attendance passed 500 for the first time. Congratulations to Bill Lawrence and the great team that organized the conference.

I had been asked to be part of a panel on supply chain security. Of course, this being a NERC conference (and the panel being led by Howard Gugel, who is in charge of standards development for NERC), most of the focus of the panel was CIP-013. I was certainly no exception to that rule! In starting my presentation (which I tried to hold to seven minutes – I think I succeeded), I admitted that I would be covering a lot of ground in a short time, and rather than forcing people to take a lot of notes I said I’d write up my presentation (and perhaps embellish it) in a post this week. So here it is!

I didn’t have the time or the inclination to do some sort of general disquisition on CIP-013: how it came about, what’s in it, etc. – I assumed the audience would have some idea of this. I also didn’t go into why I like the standard so much and why it’s so important that it is risk-based, since I’ve already discussed these topics. Rather, I just titled the presentation “Important Observations on CIP-013”, and I discussed ten observations that I thought would be of interest to the audience.  Here are the observations (in boldface), and my discussion of them (which definitely goes far beyond what I had time to say at GridSecCon).

CIP-013 is very simple. R1: You develop a plan. R2: You implement it. R3: You review it every 15 months. So the big question is: What should be in your plan? I believe all cyber security requirements should be objectives-based, and the requirements in CIP-013 are certainly that. So the whole question becomes, what is a good plan? Of course, this is where the real work comes in. Because there’s nothing in the requirements themselves – except for the six mandatory items listed in R1.2 – that tells you what needs to be in the plan, or even how to put the plan together in the first place. There’s the excellent – but far too short – Implementation Guidance developed by the drafting team, and I’m sure there will be a lot of other documents written that provide some form of guidance (including my posts, of course), but in the end your organization is going to have to decide for itself how you will put together your plan.

You need a supply chain cyber security risk management plan. It must address risks (threats) from a) procuring hardware and software; b) installing hardware and software; and c) transitions between vendors. Note there are three areas of risk that must be addressed in CIP-013, not just one; FERC specified that the standard needs to address all three. Just about everything I’ve read about the standard (including most of what I’ve written) focuses exclusively on the first area, vendor risk. But the other two areas are just as important, and they are focused much more on what the asset owner does, not the vendor. Since the requirement says all three areas must be addressed, you probably could receive a PNC if you simply omit either b) or c).

Even though R1.2 lists six particular items that need to be in your plan, you will make a big mistake if you confine your plan to those items. I wrote in a post recently that it’s very possible the only way you can get a Potential Non-Compliance finding from a CIP-013 auditor – other than simply blowing the whole standard off as unimportant – is if you omit one of these six items from your plan.

But this doesn’t mean the auditors won’t look at the rest of the plan at all. They will take a comprehensive look at your plan, and if they believe you’ve missed something, they’ll issue an Area of Concern. You would be well advised to address that AoC, even though strictly speaking you can’t be found in violation if you don’t. There are two reasons for this: 1) It’s The Right Thing to Do; and 2) You don’t want to get on the bad side of your auditor. Remember, even though your auditor’s baby is ugly, it’s not a wonderful idea to say that to him or her. The same goes for ignoring an AoC.

CIP-013 is risk-based: You should classify vendors and systems by risk, and apply controls based on the risk level. This is very different from the other CIP standards. The emphasis here is of course on risk management. If you define risk as threat times impact, you can see the difference between the CIP-013 requirements and most (although thankfully not all) of the existing requirements in CIP-002 through CIP-011, which I’ll call prescriptive requirements.

Like non-prescriptive requirements, prescriptive requirements are designed to address a particular threat (or set of threats). However, prescriptive requirements assume the impact of the threat is equal to 1 – the maximum. They also assume that the impact doesn’t vary according to the importance of the cyber asset(s) being protected. With the impact always being one, this means the risk corresponding to each threat is always the same. It also means that no BES Cyber System can be treated any differently from any other BCS in the facility, since each one is assumed to carry the same level of risk (and please don’t tell me that this is what the High/Medium/Low impact rating does in the other CIP standards. Even though CIP-002 R1 and Attachment 1 are written - although not consistently - to make you believe that the impact rating is an attribute of the BES Cyber System, in fact the rating is treated literally 100% of the time as an attribute of the asset itself. Once the asset is designated High, Medium or Low impact, every BES Cyber System within it is treated exactly the same as every other BCS within it, both by NERC entities and by auditors).

Unlike NIST and other cyber standards, “risk” in CIP-013 doesn’t mean risk to the organization. It means risk to the Bulk Electric System. But you also shouldn’t use the H/M/L classifications from CIP-002. You won’t be helping yourself if you do. Some organizations – including all owned by the federal government – are used to ranking risks posed by computer systems, for compliance with FISMA, NIST CSF, and other frameworks and standards. But the risk considered in these other frameworks is almost always risk to the organization itself.

NERC CIP – indeed, all the NERC standards – treats of risks to the Bulk Electric System; that is what NERC standards are designed to protect. So a payroll server for a utility could be hacked and they couldn’t pay their employees for months, causing many of them to quit. This would of course be a terrible thing for the organization, but as long as there isn’t any direct BES impact, it doesn’t mean anything to NERC CIP. This is why CIP only applies to OT systems, and not all of those, either.

And you shouldn’t classify your BCS using the impact level from CIP-002 R1. There’s a good reason for this. Since CIP-013 only applies to High or Medium BCS (although your plan can cover Lows as well. In fact, I can think of reasons why it would require very little additional work to include them in your plan now. I’ll have a post on this sooner or later), you will then have all high or medium risk BCS for CIP-013! So if your plan says you need to do X for high risk BCS, Y for medium risk, and Z for low risk, you will have to follow that and treat every Medium impact BCS from CIP-002 as a medium risk CIP-013 BCS. You won’t be able to put the set of controls Z on any BCS, since you’re not allowing for there to be any lows!

Of course, you don’t have to rank your BCS for CIP-013 purposes as high, medium and low risk. You can rank them as 1,2,3,4 or high/low risk, for example. It’s probably better if you adopt a different nomenclature for risk in CIP-013 than High/Medium/Low, to avoid the inevitable confusion with CIP-002 R1.

CIP-013 is also threat-based: You should make sure that your plan in principle addresses every threat, based on its level of impact (i.e. the risk). You should rate each threat according to its risk, then determine the appropriate level of controls – if any – based on the risk.

You might well ask, “How can I possibly address every threat to a BES Cyber System? There is literally an infinite number of them. There’s probably a small risk that a truck carrying a BCS to our facility will be overrun by a herd of elephants and the BCS will be crushed. How can I even identify all the threats, let alone mitigate them?” And this is where risk comes in; remember, risk is your friend in CIP-013 compliance! You need to consider all the threats (in each of the three risk areas discussed in the previous slide) and determine both the likelihood and impact of each threat; this yields the risk, of course.

Then you need to rank the threats by the risk that corresponds to each one (of course, you don’t have to rank them highest to lowest; you just need to group them in whatever number of risk levels you’ve decided is appropriate). This gives you your prioritized list of threats you need to address. And you can not only prioritize the threats, you can draw a line somewhere in the list and say “Below this line, the risk is so small that I don’t have to do anything more to mitigate it.” You then don’t have to even consider those small risks, although you have to document you are doing this consistently (not arbitrarily saying “Hey, I really don’t think this threat poses much of a risk. I won’t do anything about it). For example, I think it’s safe to say that no NERC auditor will every find you in violation of CIP-013 because you didn’t even consider the threat that a hurricane would pose in Nebraska!

And not only does the risk level help you prioritize the threats you face, it helps you determine the level of controls required. The riskiest BCS and vendors need to have the most stringent controls; the least risky should have the least stringent controls. Of course, this is very different from the other CIP standards!

The above has covered the six points in my first two slides. My final slide listed four points, and was titled “Some Lessons from Healthcare…” This was because I had been talking with a group of cyber security consultants at Deloitte who had been working for four years in the area of medical device security – working both with the vendors and with the hospitals (which are of course the equivalent of electric utilities in “our” space).

The medical device industry has been complying for four years with mandatory cyber security regulations from the Food and Drug Administration. These apply to the vendors, not to the hospitals. However, the hospitals are just as concerned about the vendors’ compliance as are the vendors themselves, so you could say that the hospitals are also subject to the regulations. Since this is a lot like the CIP-013 situation, it is informative to hear about this industry’s experience with mandatory cyber standards.

Utilities and vendors need to partner to secure purchased BCS. Dealing in a hands-off way doesn’t do much to advance security. One way to “cooperate” with a vendor is to throw some contract language over the wall to them and say “Here, Mr. Vendor. Put this language in your contract or else!” The vendor’s lawyers will then review the language, edit it to their taste and throw it back over the wall to you. Your lawyers will edit that document to their taste and throw it back…etc, etc. Of course, this is all great fun and ensures full employment for the lawyers. But it has nothing to do with making the BES more secure.

How about this approach: Your cyber and supply chain people sit down with the vendor’s cyber and sales people and say “How are we going to solve this problem – i.e. the product security and CIP-013 compliance problem – together? Let’s explore the different options….” You look at how the vendor could change their processes, how they could get you better information about their security and the security of their products, how they handle post-implementation support, etc. Sure, you can also discuss contract language and agree on language you both can live with. But that shouldn’t be the main focus of the discussion. It should be cyber security, and there are much better ways to achieve that besides contract language.

Of these two approaches, which do you think will actually increase cyber security? I’m going to go out on a limb and say number two. And by the way, I’m not saying you need to do this with every vendor. Remember the thing about risk? You will want to do this with the riskiest vendors – i.e. those who sell the systems whose loss would have the biggest impact on the BES; for other vendors, maybe contract language and a questionnaire would be enough. Or maybe just contract language, for the least-risky vendors. But if you’re dealing with your EMS vendor in the paper-over-the-wall manner I just described, I think you should seriously rethink how you’re treating supply chain security.

Legacy devices also need to be secured, even though CIP-013 is silent about this. Again, utilities and vendors need to work together to secure legacy devices. CIP-013 only covers BCS purchased after the standard comes into effect. But there are lots of legacy devices in the field, and it’s almost axiomatic that they don’t have as good a level of security as new systems. What should you do about those?

Fortunately, your discussions with vendors on how you’ll cooperate for CIP-013 compliance are the perfect opportunity to discuss legacy systems. What are ways that both of you can cooperate to improve security in those systems? Don’t wait for the next serious vulnerability to make the headlines.

Incident response is the biggest test of cooperation. There’s nothing like a good ol’ hair-on-fire cyber incident to test how well you and your vendor can work together. But guess what? It’s much better not to wait for an incident to find out how well you cooperate, or whether you can cooperate at all. When you have the meeting with your vendor to discuss CIP-013 compliance, bring this up as well.

Procurement needs to lead the conversation; vendors are much more likely to listen to the people who write the PO’s! I realize this may shock you, but vendors tend to pay the most attention to the people who actually issue the PO’s. If you (Mr/Ms cyber/CIP person) want your vendor to do something important, don’t just bring this up to them yourself. Get your procurement people to make the actual call.

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.