One of NIST’s first orders of business was to define critical software by June 26, 2021. According to the executive order, the definition of critical software needs to “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.” In other words, the definition must be specific enough to help the federal government with purchase decisions and deployment of critical software.
NIST met the due date, releasing its definition of critical software. “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; or,
Operates outside of normal trust boundaries with privileged access.
NIST states, “the definition applies to software of all forms (e.g., standalone software, software integral to specific devices or hardware components, cloud-based software) purchased for, or deployed in, production systems and used for operational purposes.”
As the executive order implementation matures, the definition may expand to include additional forms of software, such as:
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)
NIST’s second initiative – also achieved – was to “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.”
The categories in the preliminary list include:
Identity, credential, and access management (ICAM)
Operating systems, hypervisors, container environments
Network monitoring and configuration
Operational monitoring and analysis
Remote access and configuration management
Backup/recovery and remote storage
Having attended NIST’s virtual workshop – one of its many methods for soliciting feedback about its plans to develop software-related standards and guidelines – the definition of critical software was not surprising. NIST could have extended the definition to include software that interacts with critical software, but – understandably – the line had to be drawn somewhere. A black and white definition of critical software is an excellent first step in protecting the federal government from security risk.
Just days ago, NIST also released an outline of security measures for critical software – an initiative that was due by July 11, 2021. The security measures include minimum standards for vendors’ testing of their software source code, calling for threat modeling using automated testing, static and dynamic analysis, remediation of “must fix” bugs, and the use of secure coding techniques.
Hopefully, the new security measures will shake up the way software vendors test their code – even vendors that are not directly impacted by the executive order.
If you are looking to get a head start on implementing security measures, now is a good time to start looking at application security (AppSec) solutions. Even if you are only able to meet the minimum requirements, you can always expand on your AppSec program down the road.
Software customers, especially government agencies, are going to want to know what AppSec solutions your organization has in place. Being able to verify your solutions and show clean scan results will help set you apart.
For more information on the executive order and ways to start preparing your organization for the new requirements, check out the Veracode Executive Order page.