A significant part of the Biden administration’s wide-ranging cybersecurity executive order (EO) mandates that the National Institute of Standards and Technology (NIST) define what constitutes “critical software,” a deliverable that is central to the wider effort of securing software supply chains. Last week NIST made good on this assignment when it released a preliminary list of software categories within the scope of this definition.
The EO stipulates that NIST’s definition “shall reflect the level of privilege or access required to function, integration and dependencies with other software, direct access to networking and computing resources, performance of a function critical to trust, and potential for harm if compromised.” Thus, the goal of the definition is to drive several additional activities required under the EO to shape how the federal government purchases and manages deployed critical software.
One driving principle behind the critical software definition is that when combined with other aspects of the EO, software acquisition by the federal government would tilt over time toward only those products that have met reasonable security measures. The hope is that the federal government’s “power of the purse” would spill over to the private sector because most major software suppliers sell to both public and private sector customers and would find it more efficient to create a single secure product for both sectors.
Attributes of critical software or software dependencies
After consulting with other government agencies, soliciting position papers from the software community, and hosting a virtual workshop to develop the definition, NIST has determined that “EO-critical software is defined as any software that has, or has direct software dependencies upon, one or more components with at least one of these attributes:”
- Is designed to run with elevated privilege or manage privileges
- Has direct or privileged access to networking or computing resources
- Is designed to control access to data or operational technology
- Performs a function critical to trust
- Operates outside of normal trust boundaries with privileged access
NIST said that the definition applies to all software forms, “including standalone software, software integral to specific devices or hardware components, and cloud-based software purchased for, or deployed in, production systems and used for operational purposes.” Later phases of the EO’s implementation may also include other categories of software, including:
- Software that controls access to data
- Cloud-based and hybrid software
- Software development tools such as code repository systems, development tools, testing software, integration software, packaging software, and deployment software
- Software components in boot-level firmware
- Software components in operational technology (OT)
Categories reflect network control, endpoint security and network protection
NIST has produced a table that spells out the specific categories of software used for security functions, such as those affecting network control, endpoint security, and network protection. The preliminary critical software categories in the table include:
- Identity, credential, and access management (ICAM)
- Operating systems, hypervisors, container environments
- Web browsers
- Endpoint security
- Network control
- Network protection
- Network monitoring and configuration
- Operational monitoring and analysis
- Remote scanning
- Remote access and configuration management
- Backup/recovery and remote storage
“This is absolutely nothing new at all,” software security veteran Chris Wysopal, co-founder and CTO of Veracode, tells CSO. “People have been talking about this kind of concept for decades.” Nevertheless, he says, “It’s great that there is sort of a line in black and white. Finally, something is going to be done about this critical software to make sure it’s not putting undue risks on national security.”
The hack of SolarWinds network management software by Russian intelligence is a central impetus for developing this security baseline for critical software products, as NIST itself notes. Stating that recent incidents demonstrate the need for the federal government to improve its defense against malicious cyber actions, NIST pointed out that “threat actors are exploiting the pervasive use of software and the complexity of the underlying code and software development and distribution practices.”
Can’t wait for the next SolarWinds
“We just can’t just keep letting this happen,” Wysopal says. “We can’t just wait for the next SolarWinds to happen, even if it takes six months or a year or the next one.”
Wysopal thinks that NIST has done an excellent job covering the necessary bases in coming up with its preliminary parameters of critical software. “If you look at the different software they’ve come up with, it’s software that shares the same kind of privileged position in the network and identity [as SolarWinds], but it is a whole different range of software,” he says. “I think they’ve broadened it out enough.”
Despite the comprehensive nature of its definition, NIST hasn’t included some software that can serve as an attack vector. “You could say, well, even the least privileged piece of software on your network could eventually end up [compromising] your crown jewels because of the whole concept of lateral movements and privilege escalation and chaining vulnerabilities together,” Wysopal says, adding that you have to start somewhere and that over time, “I fully think that they need to move to lower risk software, too.” It’s only when the government and the security industry get good at handling the highest-risk critical software that the software definitions can broaden.
“This is where you start,” Wysopal says. “I hope it isn’t an endpoint. It is going to take a couple of years to get this up and running smoothly before anyone would think of any kind of expansion.”
The next steps include CISA guidance, OMB requirements
NIST said that CISA and the Office of Management and Budget (OMB) “will monitor the implementation of the program in the initial phase and decide when to include additional software categories.” In the meantime, the following near-term EO directives will flow from NIST’s preliminary definition of critical software:
- Around July 12, OMB and CISA will publish guidance outlining security measures for critical software.
- Around July 25, DHS through CISA will “identify and make available to agencies a list of categories of software and software products in use or in the acquisition process meeting the definition of critical software.”
- Around August 24, the director of OMB, acting through the Administrator of the Office of Electronic Government within OMB, will take appropriate steps to require that agencies comply with the guidance outlining critical software security measures.
In the long run, the actions in the EO surrounding software security should make supply chain attacks “much, much, much harder because right now nothing is stopping that from happening,” Wysopal says. “The government isn’t scrutinizing any of this critical software through this lens.”
Moreover, tightening critical software security through the federal acquisition process could bolster software security by reducing the need to patch software products as frequently. “Applying requirements on this type of software from the vendor to do more security testing should also mean that there are more vulnerabilities that are found in the development process and not found after the fact,” Wysopal says. “I think there will be that secondary effect that the software will actually become more secure.”
Copyright © 2021 IDG Communications, Inc.
