Nearly a year after President Joe Biden signed off on an expansive cybersecurity executive order, officials are grappling with the difficult task of taking secure software standards and applying them to the vast array of software agencies buy.
The Office of Management and Budget plans on releasing new secure software guidance for agencies within the next eight to 12 weeks, according to Chris DeRusha, federal chief information security officer. The guidance is based on a “Secure Software Development Framework” (SSDF), as well as “Software Supply Chain Security Guidance” released by the National Institute of Standards and Technology in February.
“This is about incenting the vendor communities that are serving and selling to the U.S. government to start adopting this framework, and specifically secure development practices,” DeRusha said during a March 23 workshop hosted by NIST. “That means a culture change in agencies and means a culture change in some of the vendor organizations themselves.”
DeRusha said OMB’s goal isn’t to set up a new compliance regime, although part of the effort will involve attestation and verification measures. He said one of OMB’s objectives is ensuring there’s a uniform approach across agencies.
“What we want out of this is a clear, concise and efficient approach to do vendor attestation and federal verification measures,” DeRusha said. “We really want to ensure agencies are doing this in the same way, and that we’re really looking at how we can do things like reciprocity.”
OMB is working in parallel with the Department of Homeland Security, which was tasked under the cybersecurity executive order to deliver recommendations to the Federal Acquisition Regulation Council on contract language that would require companies to comply with and attest to secure development practices. Those recommendations are due on the executive order’s first anniversary on May 12.
“We’re driving fast, and we’re working also to align with the DHS recommendations,” DeRusha said.
The software security requirements were mandated by last year’s executive order, which was partially motivated by the SolarWinds software supply chain hack that affected at least nine federal agencies. The work has been further spurred on by the recently discovered vulnerabilities in Log4j, a widely used open-source software logging utility.
DHS Chief Information Security Officer Kenneth Bible said federal CISOs want to get a better handle on the integrity, composition and provenance of the software their agencies are relying on.
“From my own experience with Log4j, that composition piece kind of weighs heavy, because of the lack of visibility particularly in compiled code of where actually that vulnerability existed,” Bible said during the NIST workshop. “It’s something that we’re going to be looking at and seeing pop up for years … Do we have to continue to have more and more endemic vulnerabilities? Or can we start to understand the composition better?”
NIST’s framework describes “a set of fundamental, sound practices for secure software development.” A key question for companies is to what extent agencies will require them to prove out the security of their software through a process called “attestation.”
“A clear plan is really important,” Henry Young, director of policy for The Software Alliance, said during the workshop. “There’s really no way a party can attest to something, if it’s not clear to what they are attesting.”
Industry representatives at the workshop advocated for the guidance to take into account existing certifications and compliance standards, including the Federal Risk and Authorization Management Program (FedRAMP) that has been used for a decade to certify the security of cloud services.
Industry representatives also advocated for reciprocity and standardization to feature in the OMB guidance so companies won’t have to go through the same process for multiple buying components. Young mentioned the Defense Department’s Supplier Performance Risk System as a potential model.
“I also think that it’s important to think about in this context, kind of the centrality or the consistency of an attestation, so we don’t have a situation where the company is attesting to any of the dozens of departments and agencies, duplicating its work,” Young said.
Another key question is to what extent OMB and agencies will allow software vendors to self-attest to their compliance with the software security standards, or if they will require agency or third-party verification.
Sharon Chand, principal of Deloitte Cyber Risk Services, said it’s likely a self-assessment will be what’s required in most instances.
“I think the scale at which this has to happen necessitates that self-assessment, first party assessment for a wide number of applications and systems,” Chand said. “There will certainly be some that might require a second- or third-party attestation. But just thinking about the scale at which this needs to operate to achieve some of the overarching objectives, I feel like that self-assessment is required.”