Two more supply chain security guidelines from the SCWG

I’ve written a number of times about the Supply Chain Working Group of the NERC CIP Committee, a group of which I’m proud to say I’m a member in good standing (at least I think I am. Tom Hofstetter, you did receive my check for my 2020 dues, right? I promise this one won’t bounce like the last one did). In September, they published five short (3-4 page) Guidelines that are available on the NERC web site; you can find out how to get them by going to this post and reading the first paragraph (nothing on the NERC site is ever just a single click away, and if you can’t find it by digging through the fairly opaque menu system, then you should search. But whatever you do, don’t use NERC’s search function! Just Google it. I’ve often said I know the perfect way to protect critical infrastructure information from terrorists: just post it on the NERC website. ISIS will never find it there!).

Now, the SCWG has posted two more Guidelines (which is NERC’s term of art. Guidelines are meant to be best practice information, and not provide compliance guidance. But the Guidance documents that NERC posts are also not compliance guidance, since they scrupulously avoid telling entities how to comply with the requirements, or telling auditors how to audit them. They’re something in between real compliance guidance and best practices. And if you can figure out what this means, let me know. I stopped trying long ago).

You can find these two new Guidelines on the same page as the other SCWG Guidelines. Both of these documents are quite good, having been developed (and revised, in response to comments) over a period of at least six months, with many people (including me) having input on them. This is why the SCWG’s Guidelines are so valuable: they’re truly crowd-sourced (there are over 150 SCWG members, and they’re all free to attend all of the meetings to develop a document, as well as comment on drafts).

The first of these papers (in alphabetical order) is “Risks Related to Cloud Service Providers”. One point: While none of the Guidelines so far has even mentioned CIP-013 (at least, we’ve tried to avoid it, so there’s no question the documents aren’t Guidance), they have all been useful for putting together the supply chain cyber security risk management plan, which is required by CIP-013 R1.1. This is because R1.1 tells you nothing about what should be in your plan, other than that it should “identify and assess” risks arising from procurement and installation/use of BCS hardware, software and services (as well as risks from transitions between vendors – something that happens about once every 100 years in some utilities).[i]

But this paper definitely can’t give you any CIP-013 guidance, because the standard only applies to BES Cyber Systems, not to BES Cyber System Information. And right now, putting BCS in the cloud would put you in violation of just about every CIP requirement; although a number of NERC entities now have some BCSI in the cloud. Nevertheless, I think the paper provides a very good discussion of some of the main risks that come with putting other systems and information in the cloud - i.e. your IT systems or data. But I’ll note that my last post referenced three risks (one old, two new) that aren’t addressed in this paper at all.

I especially like the second paper, “Vendor Identified Incident Response Measures”. I like this so much because it literally came out of the blue. The topics of all of the other papers had been suggested by the CIPC, but they didn’t suggest this one. In fact, it had never even occurred to me that a vendor’s incident response plan needs to be different from any other organization’s plan, but of course it is, when you think about it. 

The idea for this came from Steve Briggs of TVA. One day this spring, he just quietly announced to the SCWG that he would like to write this paper (maybe he asked for permission first, I can’t remember. If he did ask for permission, I wouldn't think any less of him for doing so. I've always been somewhat challenged in the asking-for-permission area, which is perhaps why I work for myself now), and asked for people to help in writing it (I was involved with the earlier drafts, but had to leave off later because of other commitments). And what came out of this effort was really excellent.

Unlike the cloud paper, this one can definitely help you in putting together your CIP-013 R1.1 plan. It would be a good idea (although not mandatory, of course) to require your vendors to do this (perhaps through contract language, although there’s no particular reason to use that sledgehammer, when a simple phone conversation will probably produce a better result). And why wouldn’t they? If they don’t respond well to a cyber incident that affects their customers (e.g. a serious vulnerability being identified, for which no patch is immediately available), they know they could lose a lot of business, and perhaps be on the hook financially for losses. They should be very interested in working with you in putting together a plan that can work for your utility as well as their other customers.

And by the way, this paper may provide you some ideas on how you might address compliance with CIP-013 R1.2.1, R1.2.2 and R1.2.4. But it's not guidance, mind you!

Nice job, Steve!

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] And mitigate those risks, although that word was left out by the v1 drafting team. It also seems likely to be left out by the team currently working on v2 – although I blame FERC for that, for setting a one-year deadline that is a mere blink of an eye for a NERC standards drafting effort, which is usually better measured in geologic eras. FERC gave NERC one year to develop and approve v1, which wasn’t at all adequate. This is why the standard is so sparse. I count no more than seven sentences in all three requirements, and even that’s being generous. The SDT had no choice but to leave the standard as detail-free as possible, in order to get it passed in time to meet FERC's deadline.

And by the way, after giving NERC one year to develop and approve the standard, how long did FERC take to approve the standard once it hit their desks? Oh, 13 months.