Eric Greenwald, general counsel for Finite State, talks with Mike Vizard about how the executive order for securing software supply chains issued by president Biden will impact DevOps teams. The video is below, followed by a transcript of the conversation.
Announcer: This is Digital Anarchist.
Mike Vizard: Hey, guys. Thanks for the throw again. We’re here with Eric Greenwald who is the General Counsel for Finite State, which specializes in cybersecurity around embedded systems. Eric, welcome to the show.
Eric Greenwald: Thanks very much. Very happy to be here.
Vizard: The Biden administration is going to save us all from ourselves. We’ve got this whole effort around software supply chain going on. NIST is now trying to define what a critical component of a software supply chain exactly is. That has been a mystery to many of us for a long time. So maybe you could sort this out for us a little bit. What exactly do they mean and what are they looking for?
Greenwald: Sure. Well it’s a little bit complicated because I think the conventional understanding of what is critical software is a potentially very broad and malleable concept. What NIST is trying to do is narrow the focus a little bit mostly so that it can phase the implementation of the executive order. I think if you look at some other efforts at imposing standards for software security or security in general that there’s been a rollout and the standards weren’t necessarily drafted in a way that made sense or was easy or low cost to implement, and so what they’re trying to do is avoid those pitfalls and do a rollout that starts with a narrower scope but then eventually expands I suspect eventually to pretty much the majority of the universe of software products that the government buys.
Now where is it going to stand when the executive order actually begins implementation? That’s what this initial definition is meant to establish. But if you look through what NIST has put out so far, it’s not 100 percent clear, and I think we’re going to get some additional guidance both from NIST and also the executive direct some other departments and agencies to put out some additional guidance. The NIST definition that they put out back on the 25th of June includes a proposed set of categories of software that would be defined as critical under the executive order, but it’s not a definitive list.
I believe it’s CISA from DHS that’s charged with putting out a definitive list somewhere down the line in the implementation of the executive order. I can’t remember the exact date. But in another 30 or 60 days we’ll see a definitive list of those categories from CISA.
Vizard: Well, are they doing this out of their concern for us all or are we going to get in trouble at some point? Is somebody going to call me up as a developer and say, “Hey, you’re not protecting these critical components and you’re about to be fined or something bad is going to happen”? So what’s the stick that goes with the carrot.
Greenwald: So the first stick that gets wheeled in is by the Office of Management and Budget, that is going to use it to compel the departments and agencies that are buying software from vendors out there in the private market that they can only buy software that meets the definition of critical software if it has passed the technical requirements that will eventually be promulgated under the executive order. So the first line of people potentially getting in trouble are the departments and agencies for failure to actually implement the EO’s requirements. Now indirectly, what’s going to happen is as the departments and agencies attempt to enforce the standards under the executive order is that they will select software vendors based upon whether those vendors are meeting the technical requirements. So there’s this trickle-down effect that again it’s going to go through those vendors that are selling directly to the government, but then it will also impact all the various companies out there that are providing components to those vendors that sell to the government.
So it’s not just going to impact vendors who sell directly to the government. What’s more, it’s going to go even further beyond that because I think especially if people start to think that the standards promulgated under the EO are sensible, are a good way to actually impose tighter security requirements, you’re going to see them adopted more broadly and made mandatory not just for those companies that are selling to the government. But you might see industry groups adopting them, you might see a lot of companies as they are buying software telling their vendors, “Hey, we want you to meet these requirements that have been promulgated under the EO. They’re not required by law to, but we’re requiring you under our contract to meet them.” And you might even see insurance companies start requiring them as a prerequisite for obtaining cyber insurance coverage.
Vizard: I’m not a lawyer, but sometimes when I do look at these regulations I do notice there’s a common theme between them, almost to the point where I feel like somebody kind of copy and pasted something from one into the other. Is that how things work? People kind of look at one agency and say, “Well thanks for taking the lead on this,” but then they just implement it into their regulatory framework?
Greenwald: So the best analog to offer on that is if outside of the cybersecurity realm is environmental standards, particularly auto emissions standards. You look at California that leads the way in auto emission standards that it imposes on automobiles sold in California. You see a lot of other states adopting those standards as the model. Not all states, by any measure. But the interesting thing is that car manufacturers can’t just meet those standards to sell automobiles in California.
They’re going to meet those standards for all automobiles sold in the United States and probably other parts of the world too. Switching to an analog from the security world, you look at the NIST framework. The NIST framework, all voluntary. Nothing about it is mandatory. It’s also not specific technical requirements. So it’s a rough analog.
But if you look at what happened with the NIST framework you see all sorts of contracts that require compliance with the NIST framework. You see other industry groups or even – and again, in the insurance industry, a lot of insurance companies want to know before providing you with cybersecurity insurance coverage do you meet the basic requirements or the guidelines promulgated under the NIST framework. So I think to your copy and paste point, I think yes, it definitely does happen. And my first hope is that the technical standards promulgated under the EO will be sensible and actually promote better security. My second hope is that if they do they get adopted beyond just procurement for the federal government.
Vizard: Do you think that the compliance process can be automated as we go forward or is this going to be a lot of manual reviews of code? We’re all hoping or looking for – compliance-as-code is kind of the buzzword of the day in the DevOps space. Do you think we can code our way through this?
Greenwald: So I’m going to avoid getting too deep into technical issues because I’m a lawyer first and a technology guy second, but I’m more technology policy than engineering, for example. My feeling is that the only way we’re going to be able to implement the technical requirements under the EO in a manner that is efficient and effective, and not too costly I should add, is by automating the process. I will note that part of the approach that Finite State takes to this is automating those software reviews, the scanning for vulnerabilities and assessments of what is actually in the software because that is – number one, doing it once manually is labor intensive. Under the EO, my expectation is that you’re going to see requirements to do it repeatedly, and I think the ideal is doing it with every update or at least even if the updates have a long periodicity doing it more frequently than the updates.
Or let me just say this – I think that the companies that are able to run their security checks on their software regularly are going to be at a competitive advantage as they approach procurement officers in the federal government to buy their software. And the same thing I think is going to apply more broadly across the industry, that the more frequently you can do these security scans the greater your competitive advantage. And there’s just no way to do it frequently without automating it.
Vizard: We talk a lot about DevSecOps in our world these days. I wonder if this is just going to force that issue where I might as well start biting this bullet now because one way or another the government’s going to kind of drive me towards it whether I like it or not, so maybe now’s the time.
Greenwald: Yes. Absolutely in two things. The first is that the EO specifically calls for the promulgation of technical standards for secure development of software. The second is, to your point, my view, what I advocate for companies that are looking at the EO and saying, “Hm, where’s this going, who is this going to apply to?” that if you sit around and wait for it to become mandatory for your company and/or your products, that you’re going to be way behind the power curve and that these companies that are looking at this need to start developing a plan, an aggressive plan, to develop securer software development ops, to implement a software bill of materials – and again, we’re going to see very soon where the technical standards for the software bill of materials will land.
So people I think will be able to start jumping on that soon. And third, having transparency about your security measures, whether it’s software development or testing, that are accessible to anybody buying your software or using your software. And just to add a last point on there, that being able to do that on a repeated basis where the test results can be validated is going to be very important for companies who, again, want to maintain a competitive advantage in the marketplace.
Vizard: And I suspect that just because I wrote my code before the rules were actually implemented won’t be much of a benefit to me because they’ll expect me to go back and fix stuff that’s in production.
Greenwald: That’s absolutely right. So number one is that for any software that the federal government procures following the date that the EO is promulgated, which was I forgot now, like early May, any software procured after that date forward has to meet the EO’s requirements, again, if it falls under the critical software definition. I’ll say something about that in a moment. But the other is that eventually the EO expects OMB to impose those same requirements on critical software that is legacy, that predates the promulgation of the EO.
As a reference, quick note on if your product meets the definition of critical software. As I noted initially, the definition is being drawn somewhat narrowly. Frankly, I think it’s fairly broad as put out by NIST just a week ago. But again, it’s the initial phase and the definition, the scope, is going to get broader, and I would expect it to end up being quite broad at the end of the day. What day that is, is hard to say. But a key to note is that in the frequently asked questions in the NIST definition that they issued last Friday, they specifically say if a procurement officer wants to apply the EO’s requirements to something that doesn’t meet the definition of EO critical software, they can go ahead.
There’s nothing that prohibits them from doing so. And if I’m a procurement officer and I’m thinking, okay, I’m buying software today. I know that eventually it’s going to have to meet the EO’s requirements. Why am I going to buy something where I’m worried about it meeting the EO requirements? I’m going to buy something today that is going to give me no headaches down the road in terms of whether it actually meets those requirements.
And what’s more, if you’re buying software, you’re looking at 10 different products and three of them meet the EO’s requirements, to me that’s an indication that those products are safer. And so I think that you’re going to see procurement officers for a number of reasons gravitating towards those companies whose products meet the EO’s technical requirements.
Vizard: Yeah. I guess I’m a little more worried about how granular it might get, because we have all these libraries and microservices that people build and then they deploy, and the definition of how that thing may become critical could change over time and what I thought was inconsequential suddenly is critical.
Greenwald: Well again, and as I said at the top, to me if you’re trying to establish a conventional definition of what’s critical, it’s really hard to circumscribe that narrowly. Anything that has access to a system that you might consider critical, should be considered a critical component. If you’re thinking about what’s the conventional understanding of critical, yes, it’s enormously broad. Again, NIST is trying to start a little bit more narrow and expand later, but I don’t think anyone can feel confident if they have a product, unless it’s something that where there’s just no argument that it could ever be construed as critical, that they should be looking at the EO requirements and figuring out a way to comply with them – well I was going to say comply with them now – we don’t have the requirements yet.
The technical requirements haven’t been promulgated. But as we start to see which way the wind is blowing, where these are likely to land, companies should be looking to develop a plan to meet those requirements where we expect them to land. And again, not just those companies that sell software to the federal government. So the granularity of the definition, to me I don’t want to go so far as to say as it’s irrelevant, but I think that software vendors of all stripes, whether it is the obviously most critical component of an operating system or something that’s not so obvious, that they should all be thinking about how they’re going to comply. There’s a separate question about granularity, and that is how granular are the technical requirements themselves?
That remains to be seen. I don’t have a good sense as to how specific and how technical NIST and the other agencies are going to get. But I have a lot of confidence in NIST because they have very good experts in house and they also have spent a lot of time developing relationships with the private sector, making sure they understand what the private sector needs, what really hurts the private sector – and I should say hurts them unnecessary, because there’s no way we get to a more secure software landscape, whether for the federal government or more broadly, without enduring some pain and some cost. You can’t wish your way into better security.
Vizard: Cool. What’s your best advice to folks then right now? What should they be thinking about, what should they be doing, and how do I get ready?
Greenwald: So the first thing I would say is if you don’t already have a software bill of materials for your products, that you should start moving in that direction and quickly. As I said, I think it’s just in another week or so that we’re going to see the standards for an SBOM promulgated. When that happens, it’ll give you a very specific target to go for. But there’s no reason not to start now in moving towards that. So that’s something that I think people can start working on today. I think it’ll be a little farther in the future before we start seeing again the specific technical standards being promulgated.
But I would be, number one, keeping an eye on what’s happening with the various bits of guidance and rules and regulations that are coming out of the EO implementation process, so tracking it closely. Second, if you’re looking to what you can do right now, start looking at generally accepted practices, for example, for secure software development. Because I strongly suspect that where NIST lands is going to be pretty close to what are generally accepted best or very good practices with respect to secure software development, and the same thing for security testing. So we’re a little early in the process to be able to say do A, B, and C specifically.
Again, within a week or two we should have a little bit of that specific A, B, or C with respect to the software bill of materials. It’s going to take a little bit longer before we get those technical specifics for software development and testing. But again, I think that we can expect NIST to hue to what are already generally accepted as good or best practices in those arenas.
Vizard: Alright. Like it or not, secure software is on the way. Eric, thanks for being on the show.
Greenwald: You bet. Thank you for having me.
Vizard: Alright. Back to you guys in the studio.
[End of Audio]
