What I said at GridSecCon: Don’t be your own jailer!

As I described last week, I was moderator for a panel on supply chain security last Wednesday at GridSecCon 2019, which went very well. Like the five panelists, I’d prepared beforehand a four-minute discussion of a relevant topic – the one I chose was the important role that vendor questionnaires can play in a utility’s supply chain cyber security risk management program. However, based on conversations I’d had so far during the conference (which echoed some I’d had previously), I decided there was a more important topic I’d like to address – so that was what I talked about. I published my prepared remarks in the last post, and now I’d like to discuss what I actually said.

This topic is about CIP-013 compliance. What do you need to do to comply? The standard is very clear. You need to:

1. For R1, develop a supply chain cyber security risk management plan, which includes “identifying and assessing” supply chain cyber risks to BES Cyber Systems (the plan must include the six mitigations listed in R1.2, but of course they’re not the only risks you need to identify);
2. For R2, implement that plan; and
3. For R3, review and if necessary revise the plan every 15 months.

This is all CIP-013 says, and since the only official guidance document (the Implementation Guidance drawn up by the SDT) is simply a summary of good practices but doesn’t prescribe anything, these three items are all that’s prescribed by CIP-013.

Since I started writing about CIP-013, I’ve noted that it’s very nice to have a standard whose requirements don’t prescribe any particular actions at all, but only set out an objective – supply chain cyber security risk management – and require the entity to decide for itself the best plan for achieving that objective. However, I realized early on that this was probably giving entities and auditors too much freedom; it would be better if there were some “criteria” for what should be in the plan, baked into the standard itself.

And by “criteria”, I mean a set of areas of risk that the plan must address – for example, the risk areas of insecure equipment delivery, unpatched vulnerabilities in procured software, compromised vendor remote access, etc. If CIP-013 just included the eight or ten most important of these areas and required the entity to address important risks in each area (or document why there aren’t any risks that are important to them, in a particular area), this would give the entity something to hang their hat on when developing their plan. And just as importantly, it would give the auditors something to hang their hats on when auditing the plans – i.e. did the entity address each of the risk areas?

However, there aren’t any criteria like this in CIP-013-1. Maybe the new SDT drafting CIP-013-2 will decide to include these (I hope they do, and I intend to talk with them about doing so) in that version; but that’s at least three years away from implementation.

Which brings me to the subject of my talk at GridSecCon: In the absence of any prescribed content for the plan developed in R1.1, many entities seem to be talking themselves into the idea that there must be some hidden agenda in CIP-013 that probably only auditors know. They expect that the auditors will descend like zombies on Halloween to distribute PNC findings for CIP-013 to NERC entities when audits come around. The entity may protest “Hey, that’s not in the standard!” But the auditor will cackle fiendishly and say “You may not think so, but look here…if you take every other word of R1.1 and read them backwards and upside down, you’ll get the clear meaning of R1.1. It’s too bad you didn’t know that…” as they smile broadly and malevolently.

The problem is that NERC entities are so used to being beaten over the head with the need to detect all of the open and hidden meanings in prescriptive requirements like CIP-007 R2, they can’t believe that CIP-013 R1.1 really allows them to identify and mitigate whatever risks they think are important; as long as they don't decide that there are no supply chain risks that they need to address (or just one or two), they'll be compliant. Meanwhile, the utility down the street will identify and mitigate a different set of risks and guess what? They’ll be compliant, too. Telling an experienced (and battle-scarred) CIP compliance person that they really have this freedom now is something like telling a civil engineer that all the equations he/she has learned are wrong, and any bridge he tries to build will be fine, no matter what formula he/she uses. It's disconcerting, to say the least.

I believe this is why so many entities have said to me things like “I think we’ll actually end up having to comply with (name the standard, such as NIST 800-161 or 800-171), and our vendors will have to comply with (say, NIST 800-53, ISO 27001, etc.)” or “I’m sure the next version of CIP-013 will have a lot of prescriptive requirements in it.” They just can’t believe that R1.1 really means what it says.

A number of years ago in Illinois, there was a case of a man who had been put in prison as a teenager and more or less forgotten about – and then was released in his 70’s or something like that. He took one look at this great world of freedom that he’d never really lived in, and he asked to be put back in prison. He just couldn’t handle the freedom he was being given (I am sure there have been cases like this elsewhere).

This is a good analogy for what some NERC entities are doing: Faced with a vast open field where they can finally decide for themselves what risks they want to address in CIP-013 and which they don’t want to (instead of a vast thicket of prescriptive requirements, like they’re used to for CIP), they have decided (at least for now) to hunker down and construct a prison around themselves. This way, they’ll be back in the old prescriptive NERC CIP compliance environment that they’re used to. They certainly don’t love it, but at least they understand it.

I have two things to say to these people. First, there certainly are concrete steps an entity must take in order to comply with CIP-013. None of them are in any way hidden, although one or two are only visible if you look at NERC’s most recent Evidence Request Spreadsheet. I hope to have a post out on what is actually required for CIP-013 compliance soon.

Second, you have an option you never had with previous CIP standards: Some of the NERC Regions (and I hope it will eventually be all of them) have said they will be glad to review your CIP-013 plan before 7/1/20. I recommend every entity that has to comply with CIP-013-1 (i.e. any entity with High and/or Medium impact assets) take advantage of this opportunity.

However, I certainly don’t recommend you wait until – say – June to submit your plan for review; you’re likely to be told by your Region “Sorry, we’ve had so many CIP-013 plans submitted to us, that we have to turn away any further plans.” And that will be it. I would try to get your plan in by March at the latest, and earlier if you can. I personally think there’s no good reason why the Regions shouldn’t feel comfortable reviewing your plan after 7/1/20, but my guess is a misplaced concern about Auditor Independence will drive most – although maybe not all – of them to stop doing this on the compliance date.

There’s something else that would definitely ease a lot of people’s anxiety about how CIP-013 will be audited: a widely accepted set of criteria for what should be in the plan, which could guide the entities as they develop their plans and the auditors as they audit them. Of course, it would be best if this had been included in CIP-013-1 from the start, but it wasn’t.[i] As I said above, I will suggest to the new SDT that they try to include that in the next version, but that’s three years away at best.

I still have hopes that some industry group will develop a set of criteria for the plan. The model they could follow is CIP-010-2 R4 Attachment 1. This sets forth a set of areas of risk (posed by Transient Cyber Assets and Removable Media) that need to be addressed in the entity’s plan for managing the risk[ii], as well as suggestions for mitigations that might be used in addressing each of these areas. It wouldn’t be that hard.

You could say that the CIPC Supply Chain Working Group is doing this now. We’ve already put out a set of four-page guidelines addressing several areas of risk, including Provenance, Secure Equipment Delivery, Vendor Risk Management, and Open Source Software[iii]. However, I don’t think there’s time or energy enough for the group to address all major areas of supply chain risk in similar detail, which would probably require 10-20 additional documents.

Will anybody step up to do this? I hope so. Stay tuned.

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’d love to say at this point that I’d fiercely advocated for this during the development of CIP-013 (I attended a few of the onsite SDT meetings, and other phone meetings), but I’d be lying if I did so. I had no more idea than anyone else that having criteria for what should be in the plans was a good idea. But even if I had known this, it’s not likely I would have been able to convince the SDT they should do this. Remember, they were under a really strict timeline.

FERC’s Order 829 gave NERC just one year to develop the standard, get it approved by the NERC ballot body and the NERC Board of Trustees, and send it to FERC for their approval. This was over the strenuous objections of Commissioner LaFleur (who recently retired from FERC), who said this wasn’t enough (I agreed with her). And guess what? It wasn’t enough. The SDT just had to concentrate on putting together a draft of CIP-013 (and also additional parts to CIP-005 R2 and CIP-010 R1) that would pass a ballot (I believe that on the first ballot, the draft of CIP-013 received a whopping nine percent yes votes. And since a 2/3 majority is required for passage, this was an indication that this wasn’t going to be easy!). My suggesting that the SDT should really take a step back and think about making the standard more understandable and auditable, even though this might take a couple of ballots to work out, would have been met with gales of laughter, if not outright tar and feathers.

[ii] The word “risk” isn’t used in this requirement or in Attachment 1, but I contend the concept of risk management is inherent in any requirement to develop a “plan” or “program” to achieve a particular objective. For that matter, CIP-007-6 R3 and CIP-011-2 R1 are also risk-based requirements, even though they never use that word, either. CIP-013 is the first NERC standard that states that risk management is required. This isn’t an accident, either. FERC made clear in Order 829 that they wanted the new supply chain standard to be risk-based; they knew that trying to do it in the traditional NERC prescriptive format would be a disaster.

[iii] There’s also a paper on Supply Chain Risk Management Lifecycle, which sets out a general methodology for developing a supply chain cyber security risk management plan, such as the one required by CIP-013 R1.1.