Date: On demand
Duration: 1 hour
Cost: No Fee

Description

For the State Department, the discovery late last year of the Log4j cyber vulnerability was a wake-up call. The security flaw earned its reputation as one of the most serious vulnerabilities in history not just because it’s easy for hackers to exploit, but because the flaw is in a wildly popular open source library that’s embedded in a number of software programs that’s almost too numerous to count.

And State certainly wasn’t alone among large public and private sector organizations. Another cabinet agency told the Homeland Security department’s Cyber Safety Review Board last month that patching Log4j and expunging the vulnerability took 33,000 work hours over the course of several months.

And since Log4j won’t be the last zero-day vulnerability federal agencies encounter, it’s time to adjust cyber scanning protocols so they’re not just scratching the surface of their systems, said Donna Bennett, State’s chief information security officer.

“As we were going through, we started finding that Log4j was embedded in every single aspect of every application that resides on the network,” she said. “You have your regular scanner that scans the network, but you also have to have your application scanner that actually goes into the code itself. It really taught us that you have to look a lot deeper as we start to build out the supply chain risk management program within the State Department.”

Beyond code scanning tools, another way to get a better handle on what vulnerabilities might be lurking deep within an agency’s systems is to demand – or at least strongly encourage – that vendors disclose the components of their products before contracts are signed.

“We’re definitely looking at trying to build processes and procedures that would assess cybersecurity practices for hardware and software suppliers across the board,” said Mike Derrios, the State Department’s chief procurement executive. “We’re considering developing evaluation factors in our IT solicitations that would require contractors to provide software bills of material (SBOMs) so that we can do license analysis, vulnerability analysis, look at all the different components that are involved in software and get greater visibility. We’re asking contractors to share that with us. And if a company has a good track record of managing those vulnerabilities, that might be something that we take into consideration – it could be a distinguishing factor and who gets an award and who doesn’t. So we’re looking at requiring contractors to start offering a greater degree of transparency into their supply chains during the procurement process itself.”

In its cybersecurity executive order last May, the Biden administration highlighted SBOMs as one specific way to give agencies more insight into the provenance of their software, likening them to a food ingredients label. The same order tasked the National Telecommunications and Information Administration and the National Institute of Standards and Technology with creating new guidelines for SBOMs and other aspects of software supply chain security.

But SBOMs aren’t a silver bullet, said John Miller, a senior vice president at the Information Technology Industry Council.

“I would say they’re not quite ready for prime time in the sense that there still are very active discussions in terms of what the minimum elements should be. I don’t think there’s complete agreement in the practitioner community on that,” said Miller, who also serves on DHS’s Information and Communications Technology Supply Chain Risk Management Task Force. “One of the other things that’s very important is there are no standards yet. It’s not going to be as useful to the State Department or other federal agencies if they’re getting SBOMs that that deal with different things. So the efforts at standardization that are happening at places like NIST are really important.”

Once there are more commonly-accepted standards around the kinds of information an SBOM should contain and how they should be formatted, they’ll certainly be helpful, said Dave Lindner, the chief information security officer at Contrast Security.

He said they’ll be most useful for mitigating the “known knowns” in the cyber vulnerability landscape.

“Our internal data says 50% of Java applications still haven’t been updated to remediate Log4j, so SBOMs will help dramatically with that. What they’re not going to touch are the known unknowns,” he said. “We all know we’re running vulnerable software in our environment, and there are going to be more zero days at some point. That’s where it’s really difficult to figure out the actual risk of the software you’re looking to procure. What data is it touching? What interfaces does it have? What does it integrate with?”

In general, Lindner said the software industry could to a lot to raise the cybersecurity waterline by being more transparent with its customers, both in the government and in the private sector.

“I’ve just seen way too many times where we’re looking to procure something, and they’re holding back security documentation or holding it hostage behind a paywall, saying, ‘Hey, if you pay for the enterprise edition, we’ll give you the info,” he said. “It just it creates this level of frustration, and as someone who’s been asked to assess the risk, I look at that and I’m like, ‘Well, they’re not going to share that with us.’ And that makes me start to think twice about that product.”

Although NIST and NTIA have laid the groundwork for improving the security of the software supply chain, when it comes to what federal agencies need to specifically insist on, the ball is at least partially in the Federal Acquisition Regulation Council’s court. The cyber EO directed the FAR Council to translate the guidance into federal contract clauses, including by creating new procurement requirements for “critical software.”

But that doesn’t mean agencies need to wait to make improvements, Derrios said. Among other measures, the State Department has already started to build its own catalog of known exploited vulnerabilities so that it can match them against products known to be using exploitable software.

“We do have the ability to craft departmental clauses and guidance to the contractor community, and those are some of the things that we’re partnering with our Bureau of Information Resource Management on,” he said. “So we’re already putting tools in place, and I don’t think that what we’re deploying is going to be out of alignment with where the FAR Council takes us. They are, I think, best practices … we’re paying very close attention to the risks around where the components of the software are coming from. We’re also looking at mergers and acquisitions of companies. In some cases, that can lead to companies having ties with certain countries that didn’t exist previously, and those lines of affiliation can sometimes become diluted. We’re looking at the financial health of the companies, because that informs whether they can potentially be at risk to fall under the influence of bad actors. But we’re also looking at regulatory risk, and how that might have first, second and third-order impacts on the companies that we’re doing business with.”

Learning Objectives:

• Software Supply Chain Security Challenge
• Tools and Approaches to Understand the Software Environment Security Posture
• Ensuring the Workforce is Equipped to Secure Software

Complimentary Registration:

Please register using the form on this page or call (202) 895-5023.

This program is sponsored by