Is open source software in scope for CIP-013?

If you're looking for my pandemic posts, go here.

NATF sponsored an excellent webinar recently, at which representatives from Exelon discussed their CIP-013 compliance program. Even though the presentation was quite interesting and helpful, the best part of the webinar was that it devoted by far the greater amount of time to Q&A. If you missed it, the slides will be posted here, but there’s unfortunately no recording. However, there were two question topics for which I thought the speakers could have given better answers. One of those (actually, it was more like three questions) was regarding open source software (I’ll hope to address the other topic soon).

It was clear from the answers this morning that the speakers hadn’t thought too much about open source risks for CIP-013 compliance, perhaps because the organization has deployed technical controls that they say would prevent downloading of open source software. Of course, just saying you have technical controls in place – and not being able to show your documented policy, as well as evidence that it is enforced – is probably not going to satisfy the auditors in a CIP-013-1 audit. However, since the speakers hadn’t planned on discussing open source, this doesn’t mean that Exelon doesn’t have the policy in place. But I suggest they make sure they’ve documented their policy and communicated it clearly to staff before October 1.

First, is open source software even in scope for CIP-013? In short, the answer is yes. NERC says this in their February FAQ: “The Supply Chain Standards are silent on terms and conditions for procured products or services that registered entities may install. A registered entity should implement its risk identification and assessment methodology for all procurements and installations of open-source software on applicable BES Cyber Systems.” In other words, even though you don’t technically “procure” open source software, you definitely install it; and R1.1 makes it clear that installation risks are as much in scope as procurement risks are.

But there's another reason why you should include risks due to use of open source software in your CIP-013 supply chain cybersecurity risk management plan: If anything, open source risks are greater in magnitude than those that apply to commercial software. For example, consider the risk that your supplier doesn't follow a secure software development program. In the case of a commercial supplier, you can assess their risk by asking them questions about their program, and then require mitigations based on their answers.

But in the case of the online community that develops and maintains an open source product, there's nobody you can even send a questionnaire to, and there's certainly no "single throat to choke" if you decide the community has security problems and you want them to mitigate them. But the risk remains, and you need to mitigate it to the best of your ability.

There are two types of risks from open source software; you need to address both types in your CIP-013 plan. The first, and the one that’s easier to deal with, is risks from open source software that’s included in a product you buy from a supplier; these apply whether or not the supplier requires you to download the open source code separately. What are those risks? Here are a few of them:

1.      The risk that your supplier might not fully support open source software modules included in their product, including promptly downloading and testing patches before releasing them to you.

2.      The risk that your supplier might not have validated authenticity and integrity of the open source software before incorporating it into their product.

3.      The risk that your supplier might not realize that the online community that supports an open source product, which is included in your supplier’s product, has dwindled to the point that it’s unlikely any new patches will be forthcoming.

You might note that risks 2 and 3 are equivalent to the two risks I discussed in my last post, although in this case they’re risks from an open source component of a software product, not a component that is developed and sold by an identifiable third party.

How can you mitigate these risks? Since there’s an identifiable supplier, you deal with them as you would any other risk that applies to the supplier: You ask them questions based on these risks, and you require them to mitigate any risks for which they gave unsatisfactory responses. Note that the same reasoning applies to suppliers like Red Hat™, whose entire business model is distributing and supporting software that at heart is open source; they need to (and do) support everything they sell you, regardless of whether or not they wrote the actual lines of code that may be causing an issue for you.

But how about risks that arise from the organization that provides your paycheck? In other words, if your organization allows open source software to be downloaded and used within your ESP(s), what are the risks that apply to that, vs. say software that you buy from Oracle™? And the answer is very simple: every one of the risks that apply to a product from Oracle applies to an open source package that you download, although the fact that there’s now no identifiable vendor makes the mitigations different. Here are four examples:

1.      There are two risks behind CIP-013 R1.2.5. The first is that you might be fooled into downloading a patch for an open source product, that was in fact created by a malicious third party.

2.      The second is that you might download a legitimate patch for an open source product, but it might be intercepted midstream and replaced with a patch containing malware.

3.      The risk behind R1.2.1 is that you might not be notified of a security incident affecting an open source software product that you have installed in an ESP.

4.      There is a risk that any software you install – including an open source package – might remain on your network after it has gone out of support, whether because you didn’t realize this was going to happen, or because you didn’t take action quickly enough.

To get an idea of how to mitigate open source software risks in general, I refer you to “Risk Considerations for Open Source Software” from the NERC SCWG, available at this site.

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 hot at work – or should be – on getting ready for CIP-013-1 compliance on October 1? Here is my summary of what you need to do between now and then.