Thursday, April 29, 2021

Finally, some information on the upcoming software EO

 

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