The NERC
CIPC Supply
Chain Working Group is now preparing six white papers on supply chain cyber
security risk management, that will be presented to the CIPC members (and
anyone else who wants to attend) before the next CIPC meeting, the morning of
June 4 in Orlando. As I anticipated when I joined the committee, the white
papers will be nice to read in their final versions, but the best benefit of
participating in developing them is the meetings themselves, at which some very
knowledgeable people (along with me!) have very good discussions that usually
go far beyond the subject matter of the white papers.
The papers
are constrained to be around three pages long, meaning their purpose is mostly
to point out issues in general terms, rather than to solve them. However, I can
promise they’ll all be excellent. The SCWG will be meeting on the afternoon of
June 3 to discuss the way forward, including whether it should continue
developing more papers, since – surprisingly enough – there are far more than six
topics that can be discussed in the area of supply chain security for the BES!
One of those
groups, which is developing a white paper on risks associated with open source
software, is led by George Masters of SEL. Last week he said he’d just read a
very good paper
on software security and recommended we all take a look at it. I did, and I
completely agree with him that it’s excellent.
Of course,
you can decide for yourself what you think of the paper, but I highly recommend
you at least look at it. You’ll notice that the authors are quite critical of
the software industry in general. In my opinion, they overstate their case in
implying that software consumers are being duped by software developers who don’t
make much effort to find vulnerabilities in their software before shipping it
out, since they can always find them later and patch them.
Even if it’s
really that bad, I – speaking as a software consumer who has approved many EULA’s
that I haven’t even looked at – don’t at all feel I’m being misled. I know
quite well that there will be various vulnerabilities in the software, and new
ones will be found all the time. I also know that a bigger diligence effort by
the developers would probably be able to make a big dent in the problem. However,
I also know that this will probably have a sizable impact on the price of the
software. Am I willing to make that trade-off? Fortunately, I have no other
option. The market as a whole has already made the choice for cheaper software
with more potential vulnerabilities. They can either buy it or not. But they’re
not being totally misled in making that choice.
I also feel
the authors are exaggerating the duplicity of the developers. Take Microsoft. I
can remember in the 90’s and early 00’s when their security level was somewhere
around zero, if not less – Windows 95 comes to mind. But they made a very
concerted effort to change that, and I don’t feel at all insecure using Windows
10.
In any case,
this is definitely a paper you should look at, and hopefully read.
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.
Hi Tom,
ReplyDeleteThanks for referral to the ICIT paper
"Software Security is National Security"
Why the U.S. Must Replace Irresponsible Practices with a Culture of Institutionalized Security
With respect to authors the paper opens with a strong problem statement for critical infrastructure and then pivots to consumer EULA. This obvious misstep is off putting. Admittedly it would be a challenge to engage with critical infrastructure community about common liability terms and conditions for industrial technology.
It's still worth promoting software security by design. Eradication of insecure by design industrial communication protocols is perhaps the elephant in the room. Authors favoring regulation might consider phasing in bans on unsafe protocols. Its ironic the industry is quicker to ban weak ciphers than to address protocols with no ciphers.
-Bryan
Good comments, Bryan! I love your last sentence.
ReplyDelete