NIST Releases 'Critical Software' Definition for US AgenciesAgency Begins Fulfilling Requirements for Biden's Cybersecurity Executive Order
The National Institute of Standards and Technology has published its definition of what "critical software" means for the U.S. federal government, as the standards agency begins fulfilling some of the requirements laid out in President Joe Biden's executive order on cybersecurity.
As part of Biden's executive order published on May 12, federal agencies are now required to reexamine their approach to cybersecurity, which includes developing new ways to evaluate the software that departments buy and deploy as well as embracing modern approaches to security such as embracing "zero trust" and using multifactor authentication and encryption (see: Biden's Cybersecurity Executive Order: 4 Key Takeaways).
As one of the first deliverables to fulfill the executive order, NIST was required to develop a definition of critical software within 45 days of the order being issued. From this point on, the U.S. Cybersecurity and Infrastructure Agency will use the definition to publish a list of software products that fall under the new definition, which will then allow CISA to create new security rules for how government agencies buy and deploy software within federal networks.
By focusing first on what critical software means for federal government agencies, the executive order is looking to curtail the type of supply chain threats that organizations face, such as the attack that targeted SolarWinds and users of the company's Orion network monitoring tool.
"The security and integrity of 'critical software' - software that performs functions critical to trust (such as affording or requiring elevated system privileges or direct access to networking and computing resources) - is a particular concern," according to Biden's executive order. "Accordingly, 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."
Defining Critical Software
Over the past 30 days, NIST solicited input from private industry and the public as well as several government agencies - including CISA, the Office of Management and Budget, the Office of the Director of National Intelligence and the National Security Agency - to help define what critical software means.
What NIST then published on Friday as a definition of critical software is: Software or software dependencies that contain at least one of the following attributes:
- Software that is designed to run with elevated privilege or manage privileges;
- Software that has direct or privileged access to networking or computing resources;
- Software that is designed to control access to data or operational technology;
- Software that performs a function critical to trust;
- Or software that operates outside of normal trust boundaries with privileged access.
This definition includes operating systems, web browsers, hypervisors, endpoint security tools, identity and access management applications, network monitoring tools and other products, according to NIST.
"The definition applies to software of all forms (e.g., stand-alone software, software integral to specific devices or hardware components, cloud-based software) purchased for, or deployed in, production systems and used for operational purposes. Other use cases, such as software solely used for research or testing that is not deployed in production systems, are outside of the scope of this definition," according to a NIST white paper.
NIST notes that this definition of critical software can be applied to both software created by private companies and sold to federal agencies or software developed by government agencies and used within federal networks, such as government off-the-shelf software.
John Dickson, vice president at security consulting firm Coalfire, says that while NIST's definition is a good starting point, the agency's view of what is critical software might be too expansive.
"I get it that software performing network monitoring, control and protection is on the critical list, but when you pull in browsers and operating systems, you start to have a list that is potentially so large and complex as to be potentially unmanageable," Dickson says. "I didn't see, however, any mention of mission-critical software built internally. I know the executive order is focused on supply chain software security with an emphasis on commercial off-the-shelf software, but this is a potential miss. Organizations 'buying' custom software developed for internal use can create catastrophic vulnerabilities, too."
And while the NIST definition was created to define critical software for U.S. government agencies, Tim Wade, a former network and security technical manager with the U.S. Air Force who is now a technical director at the security firm Vectra AI, says that almost any organization can use it as a starting-off point to improve its security.
"Organizations could potentially use this guidance to prioritize security resources and activities," Wade says. "The risk, of course, of solely relying on such a list is that the reality on the ground is that each organization has some environmental factors that will make one item on this list more impactful than another. For this reason, organizations should never confuse the compasslike utility of such guidance as an exhaustive map that precludes the need to practice local risk assessment."
Padraic O'Reilly, co-founder and chief product officer of CyberSaint Security, says the way NIST has defined critical software looks to address the vulnerabilities that attackers leverage as a point of entry into networks.
"It is a key step in the process of garnering systems and requirements for software vendors," O'Reilly says. "Identity and access management software has been a big part of the story around the most significant attacks in the last year. Upping the vendor requirements for procurement will incentivize improvements to such software products."
While the definition of critical software will help guide the federal agencies' approach to software purchasing and supply chain security, NIST recommends that the U.S. government start slowly to fulfill the executive order.
For instance, NIST recommends that agencies first apply the executive order for on-premises software within their networks and infrastructure that "has security-critical functions or poses similar significant potential for harm if compromised." After that, government agencies can look at cloud-based software, the software utilized in operation technology systems and also development tools such as code repositories.
Now that NIST has published the definition of critical software, CISA and the Department of Homeland Security will have 30 days to publish a list of software products that meet this definition and are used within federal government networks. Following that, NIST, CISA and OMB will publish guidelines for securing these critical software products, according to the executive order.