NIST Will Build on Existing Software Development Framework to Meet Executive Order

The National Institute of Standards and Technology is planning to take advantage of a year-long head start it’s had toward fulfilling obligations outlined in a recent executive order to improve the government’s cybersecurity.

Executive Order 14028 is the Biden Administration’s response to a set of breaches affecting federal agencies after adversaries infiltrated SolarWinds, a U.S. contractor that provides IT management services. The hackers were able to access SolarWinds’ development environment to distribute trojanized software updates to tens of thousands of the company’s customers.

NIST was instructed to identify or develop best practices in software development which would then inform guidance the Office of Management and Budget would issue for agencies to purchase their software going forward. 

The agency invited stakeholders to submit position statements to inform their work and on Wednesday hosted a virtual workshop to kick off discussions. The window for submissions is now closed, but the workshop will continue through Thursday and officials encouraged participants to keep sharing their feedback as part of what they expect will be an iterative process. 

But last April the agency published its own white paper on the issue and plans to use that as a starting point for satisfying a meaty portion of its obligations under the executive order: section 4 on “enhancing software supply chain security.”  

“I think for this section and really a lot of the guidance, preliminary and other guidance that we'll develop along the way, we are going to try to leverage and expand where appropriate the NIST secure software development framework, which has strong relationships and pointers and leverages many of the great existing industry practices in secure software development,” Kevin Stine, chief of NIST’s Applied Cybersecurity Division, said during the workshop. 

NIST is planning to revise the framework following the workshop currently underway. 

The Information Technology Industry Council also referenced the document in a position paper it submitted to the agency on the executive order as one of a number of “effective frameworks.” 

“We emphasize that ‘best practices’ are not one-size-fits-all,” wrote ITI, which represents a number of large government contractors. “A reference list of useful practices mapped to standards is a helpful tool, but companies should ultimately be afforded the latitude to determine which mix is most appropriate.”

NIST’s secure software development framework suggests it will allow such flexibility. 

“This white paper expresses secure software development practices but does not prescribe exactly how to implement them,” it reads. “The focus is on implementing the practices rather than on the tools, techniques, and mechanisms used to do so. For example, one organization might automate a particular step, while another might use manual processes instead.”

ITI also weighed in on how NIST should define “critical software.” Under the executive order, “The Federal Government must take action to rapidly improve the security and integrity of the software supply chain, with a priority on addressing critical software.” 

The tech industry trade association said this should be narrowly focused and avoid a scenario where every software element that could pose a security risk by containing a vulnerability is included. 

During the first day of the workshop other participants agreed with this sentiment, noting, “if everything is critical, nothing is critical.”

The NIST official leading a discussion on the question acknowledged this is something the agency has struggled with, but disclosed initial thoughts on how NIST might approach the definition.

“In short we were simply overwhelmed,” said Barbara Guttman, the leader of NIST’s Software Quality Group. “Then we made a plan.” 

Guttman said NIST would take a phased approach and only define critical software in the first leg as that which is “designed to run with elevated privilege across an IT enterprise or which actually defines privilege itself or it performs a function critical to trust, or it operates outside the normal trust boundaries with privilege access, or it has direct or privilege access to the network and the internet.” 

Guttman said “in practical terms, this means software such as operating systems, browsers, network control software, network monitoring and configuration tools, identity credential access management tools and remote access and configuration management tools.” 

The critical software definition is due from NIST on June 26 under the executive order.