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:
They do, for a price: https://shop.oracle.com/apex/product?p1=MySQL
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