Good ideas on CIP-013 compliance from the SCWG head

On Tuesday morning in Orlando, the Supply Chain Working group of the NERC CIP Committee presented a “training” on supply chain cyber security risk management and CIP-013 compliance for people attending the CIPC meeting. The meeting included presentations of five draft white papers (all short!) on different aspects of supply chain security risk management.

Each paper was developed by a subgroup of the SCWG, and they were presented on Tuesday by the leaders of those subgroups. The papers were all the product of a lot of work by SCWG members, and they were all very good – including, as I say in all modesty (or at least as much as I’m capable of. Modesty has never been my strong suit), two papers for which I led the development, Supply Chain Cyber Security Risk Management Lifecycle and Vendor Risk Management Lifecycle. The topics of the other three papers are Provenance, Open Source Software, and Secure Equipment Delivery.

The papers will be reviewed and (hopefully) approved by the CIPC in the near future, at which point they’ll be posted on NERC’s SCRM/CIP-013 portal, which I recommend you bookmark (it happens to be one very useful and very easy-to-access feature of the NERC website. In general, I’ve always thought of the NERC website as a great place to hide critical infrastructure information – al Qaeda and ISIS will never find it there! – but maybe I’ll need to revise that opinion).

The SCWG is working on three other white papers, on Cloud Service Provider risks, Threat-Informed Procurement Language, and Vendor Identified Incident Response Measures. These aren’t finished yet, but they will also be posted on the portal. And it’s possible that the SCWG will continue to develop other white papers, since in the process of developing these white papers, we identified lots of other topics that should be addressed (for example, in developing the Vendor Risk Management Lifecycle paper, my group identified at least 5-10 other white papers that would be helpful for NERC entities as they develop their CIP-013 plans). The papers were limited in length (three pages was the target, although both of mine spilled onto a fourth page), so they all needed to focus on one idea, and one idea only. But it was felt (and I agree with this), that if the papers went beyond what could be digested in one sitting, people wouldn’t read them. Better to have lots of short papers that people read, rather than a few long ones that they don’t read.

However, the SCWG will post some items to the NERC portal before the papers are approved (hopefully within a couple of weeks), including the slide decks used by the five presenters on Tuesday; a recording of the entire set of presentations (along with the slides); and the slides used by Tony Eddleman, the head of the SCWG (I think his title is Chairman. I heard that he would have preferred Grand Exalted Leader, but I believe NERC shot that down J), as he discussed CIP-013 compliance.

I didn’t take notes on Tony’s entire presentation, so I don’t want to try to summarize it, except to say that this was by far the best presentation on CIP-013 that I’ve seen yet from anybody associated with the NERC ERO (and Tony of course isn’t a NERC staff member. His day job is NERC Compliance Manager for the Nebraska Public Power District). Since I didn’t take enough notes to produce a summary of what he said, I’ll just list the points that struck me as very interesting (and I’ll admit that I filled out a few of Tony’s ideas with related ideas of my own. If you want to hear exactly what Tony said, listen to the recording!).

• He emphasized that CIP-013 R1.1 is a real requirement. Many people have just focused on the six items in R1.2, and consider those the totality of what CIP-013 “requires” an entity to do. But as I’ve said many times before, while those six items all constitute very important controls that address serious supply chain security risks to the BES, they are only listed because FERC mentioned, at different places in Order 829 in 2016, that they wanted them included in the new standard. So the drafting team dutifully included them.
• R1.1 requires the NERC entity to develop a supply chain cyber security risk management plan. To develop that plan, the entity needs to identify the supply chain security risks that it considers most important, as well as identify mitigations for those (although the drafting team left out the word “mitigate” in R1.1, there’s no doubt that they need to mitigate risks, not just identify them and call it a day).
• Because each entity will identify different risks as important to it, the plans will definitely differ from entity to entity (although they will undoubtedly have many common elements).
• If your entity is compliant with another standard that addresses supply chain security (e.g. NIST 800-53), you still need to develop an R1.1 plan. Similarly, if a vendor tells you they have a certification like ISO 27001, you still need to make sure the certification addresses the particular risks that you think are important. Different certifications address different risks, and of course there is currently no certification that specifically addresses supply chain cybersecurity risks to the BES (although Howard Gugel of NERC said at the CIPC meeting that afternoon that NERC will work with EPRI to develop one).
• NERC entities don’t need to have an RFP on the table, in order to ask security questions of vendors. They should do it when needed, although of course they shouldn’t ask the questions so often that they impose a significant additional cost on the vendor – that they presumably never anticipated when they quoted their prices, in an RFP response or otherwise. There is more discussion of this topic in the Vendor Risk Management Lifecycle paper that I presented. Anyone wishing to see the draft that I discussed on Tuesday should email me at the address below.
• While contract language is usually a good way to mitigate risks posed by vendors, this isn’t an option for purchases made by credit card, purchases through dealers (as is often or usually the case with large suppliers like Cisco and Microsoft), or purchases made using a standard PO. Tony’s point was that the vendor risks, which the entity might otherwise mitigate through contract language, need to be mitigated in any case. The Vendor Risk Management Lifecycle white paper discusses other ways to document that a vendor has committed to do something, besides security language. And that paper also briefly mentions other steps the NERC entity can take on its own, if the vendor simply refuses to cooperate, but is too important to terminate. The risks identified in the entity’s supply chain cyber security risk management plan need to be mitigated, regardless of whether or not the vendor cooperates – although they can usually be more effectively mitigated if the vendor does cooperate.

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. To discuss this, you can email me at the same address.