Updates on Executive Order (EO) 14028 on Improving the Nation’s Cybersecurity

Several deliverables have been released as required by Executive Order (EO) 14028 on Improving the Nation’s Cybersecurity. These relate to identifying and classifying ‘critical’ software, minimum standards for developer verification of software, and minimum elements of a Software Bill of Materials (SBOM).

Forthcoming within the EO process are changes to procurement rules for ‘critical’ software, streamlining federal processes information sharing on cyber incidents, and improved public-private incident management.

The main goal of the EO is to address vulnerabilities within a major pathway into Federal systems, software. Software is pervasive and involved in basically every government process, from the mundane to the critical, yet much consideration and concerns about different aspects of security remains undefined and unscrutinized. The EO is to set a baseline of security required for software used by Federal entities.

Too much of our software, including critical software, is shipped with significant vulnerabilities that our adversaries exploit. This is a long-standing, well-known problem, but for too long we have kicked the can down the road.”

This push of activity is aimed towards Federal entities, but there is a high probability that other stakeholders, such as state and local entities, and private sector critical infrastructure owners and operators will adopt or be compelled to adhere to these emerging benchmarks and requirements.

We need to use the purchasing power of the Federal Government to drive the market to build security into all software from the ground up.”

All manufacturers and providers of software to the US federal government level should carefully monitor these emerging standards, processes, and recommendations. There have been and will be future opportunities to engage in this process to make your voice heard through workshops, roundtables, and submissions of White Papers.

At the end of the day, it is in the interest of all parties, private sector, federal users, and society as a whole that software is secure.

1. Definition of Critical Software Under Executive Order by NIST, 25 June

The National Institute of Standards and Technology (NIST) has issued a definition of “Critical” software, which will be used by Cybersecurity and Infrastructure Security Agency (CISA) to establish a list of software categories that fall within that definition.

NIST says “critical” depends on the properties of a software, not the context of how it is used. Software that has, or has direct software dependencies upon, one or more components below with at least one of these attributes is critical:

· 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.

The critical label would apply to various kinds of software usage, 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. Research and testing software is not included in this scope.

NIST recommends that the first wave of implementation should focused on on-premises software, with cloud or hybrid approaches to be included sometime thereafter.

Eleven categories of software are preliminary identified by NIST as critical; three categories are found below. The next step is that CISA will refine and provide a final list of software categories by the end of July. There will likely be substantial room for questions and debate on whether a specific software falls within any of these categories.

The next question will be – so what, what does it mean if software falls within the definition of critical software; what are the consequences for a company selling in the marketplace and what is expected of a federal entity preparing a software procurement?

2. Guidelines on Minimum Standards for Developer Verification of Software, NIST, July 11, 2021

A manufacturer of software within a critical category selling to the federal level will have to follow the recommended minimum standards on software source code testing.

Eleven methods and software verification techniques have been identified by NIST and the National Security Agency (NSA), which are recommended for companies to use as building blocks for their internal testing/verification/software assurance programs. The recommendations are primarily aimed to build-in security practices in the software itself and to ensure that it is built in a secure manner.

It is noted by NIST that these recommendations do not replace any existing specific industry verification standards. The intent is to provide an overview of methods and techniques that companies are assumed to already be using to provide secure software to their customers.

3. The Minimum Elements For a Software Bill of Materials (SBOM), NTIA/DOC, July 12, 2021

Sellers of software to the federal government will also need to provide an SBOM, a Software Bill of Materials, which is to be used as a formal record containing the details and supply chain relationships of various components used in building the software.

The main advantages of transparency will be awareness and the speed of understanding where vulnerabilities and potential dependencies exist. Today it is assumed that customers, and perhaps manufacturers, are not fully aware of the building blocks of software that is in use or used to build software solutions. Not knowing what is included in software, and where it is used presents a difficult challenge for risk assessments or incident response activities.

The Administration has identified SBOM as a priority to drive software assurance and supply chain risk management and starting today is better than waiting for perfection.”

Three main categories of minimum elements are introduced, where additional layers will be added in the future.

The data fields elements are to be machine readable and will form the bases of vulnerability databases and license databases. Software manufacturers will be expected to update SBOM’s with any new build or release.

It may be a heavier lift for manufacturers of long-time existing software to compile a comprehensive and up to date SBOM, compared to more recently produced software.

It is suggested that SBOM requirements are placed on-prem software to begin with and that providers of cloud, or hybrid-based software will come after.

Next steps

Among several forthcoming activities and deliverables, CISA is expected to provide a list of software categories meeting the definition of “critical” software by 26 July and the NSA is expected to provide a framework for cyber incident reporting procedures that ensure that reports are promptly shared among relevant federal agencies.

Stay tuned.

Definition of Critical Software Under Executive Order (EO) 14028 June 25, 2021


Guidelines on Minimum Standards for Developer Verification of Software, NIST, July 11, 2021


The Minimum Elements For a Software Bill of Materials (SBOM), NTIA/DOC, July 12, 2021