Today, NPR ran this
story about the upcoming Executive Order on software security. And it looks
even better than it did when I first wrote
about it. Here is what I learned from this article:
1.
I especially like the
idea of a cyber NTSB (National Transportation Safety Board). The article points
out that there’s currently no agency whose job includes investigating cyber
events to find out the causes and recommend remedies. Having this group will be
a huge help, although even better would be if CISA were given this power (the
article says CISA doesn’t have investigative powers, but I think what they
really meant is CISA isn’t currently given explicit responsibility for
investigating all major cyber incidents). If CISA had that, they’d build up a
body of cross-industry and cross-discipline expertise like the NTSB has –
although I hope the new agency doesn’t conduct investigations at the same speed
as the NTSB, which seems to investigate on geologic time).
2.
Make no mistake about
it: The EO will order regulation of software suppliers. It says “The
administration is trying to change the way we all think of code: It isn't just
zeroes and ones — it is critical infrastructure.” Those last two words are dear
to my heart. I’ve been saying
since after the SolarWinds attack that at least some software suppliers need to
be regulated
as critical infrastructure.
3.
Of course, the
administration can’t impose requirements on software suppliers in an Executive
Order; that requires legislation. But they can impose requirements on suppliers
to the federal government. And I think this amounts to effectively regulating
all suppliers, since any supplier that sells to – or wants to sell to – the Feds
will need to follow these requirements. And if a supplier follows these
regulations for one part of their business, they’ll follow them for the whole
business. After all, it would probably be much more expensive to have two
different software development organizations, both developing the same software
but for different end users, than to just have one, no matter how regulated it
is.
4.
What will the feds require
of their software suppliers? The only clue from the article is that the EO will
define “a set of requirements for the way software is built. Federal
contractors will have to prove that they have secure practices like separating
where they develop software from the internet, and things like requiring proof
of multifactor authentication.”
5.
This doesn’t exactly
tell you a lot, but I hope this turns out to be something like the IoT
Cybersecurity Improvement Act of 2020, which similarly regulates suppliers
of IoT devices to the Feds. It doesn’t do this by imposing prescriptive requirements,
but by directing NIST to develop “standards and guidelines” for “use and
management” of IoT devices.
6.
The guidelines will
fall into four areas: “(i) Secure Development, (ii) Identity management, (iii)
Patching, and (iv) Configuration management.”
7.
Note that only the
first of these areas applies to suppliers, and even then the regulations won’t
apply directly to those suppliers (as the ones contemplated under the EO will,
although they won’t apply to any supplier who doesn’t plan to sell anything
more to the Feds, even if they’ve sold software to them in the past). But what
I like about this is the fact that the “guidelines” will probably turn into
something like a framework for IoT suppliers.
8.
Similarly, I hope the
requirements in the EO will also be developed by NIST and will be more guidelines
than prescriptive requirements. But they need to be come down heavily on the
need for secure software development. The fact that the Russians were inside
the SolarWinds network for about 16 months, and weren’t discovered until somebody
at FireEye noticed a new device had showed up on their account unknown
to them, shows that there’s – ahem! – room for improvement there.
9.
However, there’s
one thing I hope the new standards don’t mandate, and that’s software bills of
materials. I’m told it’s 100% certain that the EO will strongly encourage software
suppliers to produce SBOMs, which is good. But actually trying to regulate them
now would be a disaster, just as would be an attempt to regulate say solar sails
for travel to other solar systems. First let the technology get off the ground (no
pun intended) and become widely used, then regulate it. But by all means, do
everything possible to encourage SBOMs – maybe even set a date for rulemaking
to begin, perhaps three years from now. That will get people’s attention,
without suffocating the baby.
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.
No comments:
Post a Comment