Friday, May 1, 2020

A conversation regarding open source software



Note from Tom: If you’re only looking for today’s pandemic post, go to my new blog (and if you’re not subscribing to that blog, sign up for it. This blog will increasingly be devoted to cybersecurity/NERC CIP discussions, although I’ll continue to post the pandemic posts here as well – but they won’t get picked up by the email feed on days when I post on both topics). If you’re looking for my cyber/NERC CIP posts, you’re come to the right place.

Note from Tom on May 1: I’ve read – and reread – today’s Executive Order, but I still don’t understand what prompted it (although I have a suspicion, of course). I’d love to hear if anybody knows more about this, especially if there was some recent event that hasn’t been publicized. More to come on this, to be sure.

The day after I put up this post on verifying authenticity and integrity for open source software, I received an email from a person involved with cybersecurity and CIP enforcement with one of the NERC regions, who has communicated with me a few times in the past – and whose arguments have always been very insightful and well-reasoned.  We had an exchange that got into a couple good topics regarding open source software. Rather than try to summarize the conversation, I’m going to reproduce every word of it (since it’s not that long). Note: I did in a couple places change the wording a little to clarify what one of us wrote in the emails. This is one of the (few) privileges of being a blogger!

Regional person:
Wanted to comment regarding open source software, integrity verification, and risk mitigation.

One thing I’ve noticed is people tend to interchangeably use open source software when they mean free software or free software with a collaborative and distributed development base.

To throw out the Wikipedia definition…

Open-source software (OSS) is a type of computer software in which source code is released under a license in which the copyright holder grants users the rights to study, change, and distribute the software to anyone and for any purpose.

The license and subsequent release of the source code is what makes the software open source or not.  This may seem a bit pedantic, but when applied to a few examples from your recent blog post it can make a difference. Specifically, you said:

In the case of open source software, there is no vendor.
To use the current example, you might say “Well, we don’t allow open source software to be installed on BCS in the first place, so this risk doesn’t apply to us.” I always respond “This risk applies to you, but you’re saying that you have already mitigated it – in this case, by not allowing open source software to be installed in the first place.

Examples of vendors or groups and their open source products…

Red Hat, Inc – Red Hat Enterprise Linux
Oracle Corporation – MySQL
Mozilla – Firefox
Apache Software Foundation – Apache HTTP Server
The OpenBSD Project – OpenSSH

Now, intellectually I know what was meant.  Companies are effectively saying they’re not going to do something like go to SourceForge or some random website and download and install an unvetted application because it seems like it might serve their needs.  Whether or not this bit of nuance will become an actionable issue I can’t say, but I did want to point it out.

Tom:
Thanks. But even though Oracle releases MySQL, do they actually support it like their other products? That's what I mean when I say there's no vendor - there's no support.

Regional person:

Looks like they package their support contracts with independently created tools (which may or may not be open source) and then price their support based on number of servers and sockets. Similar concept as what Red Hat does.  Red Hat releases their source code via the CentOS project, but then sell support contracts for Red Hat.

Tom:
Ok, fair enough. I'll put a note on the post that the issue is really more that the software doesn't have support available, rather than that it's open source per se. Does this sound like the correct statement of the problem?

Regional person:
I would say yes.  It’s fairly easy to draw a line between lack of support and a lack of being able to verify authenticity.

That phrasing also sidesteps other issues, such as when the entity’s vendor bundles open source software into their deployment.

Tom:
Regarding your second point: If a vendor includes open source software in their deployment, they should be responsible for everything that comes in their package, whether it’s their code, code of some third-party supplier (some would call them a fourth party), or open source code. There should be no question that they should provide the entity the means to verify authenticity and integrity of everything they download that’s part of their software installation (and of course, they should also provide or apply all third-party or open source patches). And if they don't, the entity should ask themselves why they're buying anything from these guys in the first place.

I decided I'm going to make this discussion into a regular post tomorrow. This hit one of my hot buttons!

Regional person:
100% agree with you here.

However, and this is me speaking for me, if I were to document something such as “We do not allow open source software in our environment.” I would want that to be an accurate statement.  When the situation is more akin to “We do not allow open source software, except for the open source software that we do”, then the plan and the environment start to match less and less.

Tom again:
I hope you notice the very good CIP-013 compliance point in the last paragraph. A reinforcement of a point I’ve made at least a few times before: The big source of compliance risk in CIP-013 isn’t that your R1 plan won’t be “compliant”, but that your R2 implementation of that plan won’t exactly match what’s in your plan. Once you’ve written your plan, consider it to be a prescriptive requirement like…shudder…CIP-007 R2.

On the other hand, as I’ve also written (and had it confirmed by Kevin Perry), you can change your plan at any point – you don’t have to wait until you comply with R3 to do it. But you need to document why you changed it, and you also need to make sure you make appropriate changes in your procedures (and train people on them, of course), so that you’re not violating the wording of your revised plan. 


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 working on your CIP-013 plan and you would like some help on it? Or would you like me to review what you’ve written so far and let you know what could be improved? Just drop me an email!



No comments:

Post a Comment