Skip to main content
U.S. flag

An official website of the United States government

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Secure .gov websites use HTTPS
A lock ( ) or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.

Software Security in Supply Chains: EO-Critical Software and Security Measures for EO-Critical Software

Following the EO’s directive, NIST’s definition for critical software reflects “the level of privilege or access required to function” and “integration and dependencies with other software.”[1]

NIST has also published guidance outlining security measures to protect the revised set of designated critical software.

Definition of EO-Critical Software

NIST’s publication on the definition of critical software enhances traditional notions of context-based criticality with function-based definitions. Table F-1 identifies the points at which criticality considerations in SP 800-161, Rev. 1, may be informed but should not be superseded by the new EO-critical software definition.

Table F‑1: Impacts of EO-critical software definition on SP 800-161, Rev. 1, guidance for Federal Agencies

Section Identifier

Section Title

EO-Critical Definition Impact

2

Integration of C-SCRM into Enterprise-wide Risk Management

  • Enhance SP 800-39’s Assess risk step with EO-critical risk definitions when considering software supply chain components and suppliers.

2.3

Multilevel Risk Management

  • Augment C-SCRM Strategy and Implementation Plans and Policies. C-SCRM Plans focus on mission- and business-critical requirements to include EO-critical software supply chain security considerations, where applicable.

3.1

C-SCRM in Acquisition

  • Ensure that groupings accommodate EO-critical suppliers when segmenting the organization’s supplier relationships and contracts.
  • Codify function-based software criticality definitions during the ‘plan procurement’ step, and incorporate EO-critical concepts when justifying the level of criticality.

3.4

C-SCRM Key Practices

  • Integrate context-based criticality concepts within the Foundational Practices’ measurement of supplier criticality and the utilization of supplier risk assessments.
  • Expand Sustaining Practices attestation activities to all net new critical suppliers under the expanded EO criticality definition (e.g., suppliers who develop a software component that performs a function critical to trust, regardless of where that component is used within the organization).

Appendix A

C-SCRM Security Controls

  • Extend EO-critical definition considerations to ICT/OT related service providers, where applicable

Appendix C

Risk Exposure Framework

  • Incorporate EO-critical definition components when determining the organization’s acceptable level of risk, particularly within the context of system criticality assessments.

Appendix D

C-SCRM Templates

  • Account for EO-critical definitions when considering the automated generation of C-SCRM plan elements, such as supply chain component criticality.

Appendix E

FASCSA

  • Account for risk factors associated with EO-critical definitions when identifying, assessing, and responding to supply chain risk.

Appendix G

C-SCRM Activities in the Risk Management Process

  • Incorporate EO-critical component definitions when performing risk management activities that include a reference to criticality as part of (i) framing risk, (ii) assessing risk, (iii) responding to risk once determined, and (iv) monitoring risk (i.e., FARM process).

Security Measures (SM) for EO-Critical Software Use

NIST published “Security Measures for ‘EO-Critical Software’ Use Under Executive Order (EO) 14028” in July 2021. Software supply chain security measures are essential for internal decision-making and for supplier oversight. Federal agencies must recognize their status as critical players in the software supply chain and should, at a minimum, implement the same security controls internally that they require of their software suppliers. All of the EO Security Measures should be considered for all software, not just for EO-critical Software.

The table below outlines the mappings and coverage of the EO’s security measures across SP 800-161, Rev. 1, controls, control enhancements, and supplemental guidance outlined in the main body of this document. Many of these are included in the C-SCRM controls baseline.

EO Security Measures and their associated NIST SP 800-161, Rev. 1, controls (with the exception of AC-6, CA-7, and SR-8) are considered “flow down.” Enterprises should require prime contractors to implement this control and flow down this requirement to relevant sub-tier contractors where feasible.

Federal agencies that align to SP 800-161, Rev. 1, controls should use the below table to aid in conforming with EO Security Measures and to ensure their effective application across the software supply chain and acquisition life cycle.

Table F‑2: C-SCRM Control and Security Measure Crosswalk

Control Identifier

Control Name

C-SCRM Baseline

EO Security Measure

AC-2

Account Management

x

1.1, 1.2, 1.3, 2.2

AC-3

Access Enforcement

x

2.2

AC-4

Information Flow Enforcement

 

2.4

AC-5

Separation of Duties

 

3.3

AC-6

Least Privilege2

x2

2.2, 3.3

AC-17

Remote Access

x

2.4

AT-2

Literacy Training and Awareness2

x2

5.1

AT-3

Role-based Training

x

4.5, 5.1, 5.2, 5.3

AU-2

Event Logging

x

4.1

AU-3

Content of Audit Records

x

4.1

AU-12

Audit Record Generation

x

4.1

AU-13

Monitoring for Information Disclosure

 

4.4

AU-14

Session Audit

 

4.4

CA-7

Continuous Monitoring2

x2

3.2, 3.3, 4.1

CM-2

Baseline Configuration

x

3.3

CM-3

Configuration Change Control

 

3.3

CM-6

Configuration Settings

x

3.3

CM-7

Least Functionality

x

3.3

CM-8

System Component Inventory

x

2.1, 3.1

CP-3

Contingency Training

x

5.2

IA-2

Identification and Authentication (Organizational Users)

x

1.1, 1.2

IA-4

Identifier Management

x

1.1

IA-5

Authenticator Management

x

1.1

IA-9

Service Identification and Authentication

 

1.2

IR-2

Incident Response Training

x

4.5

PM-5

System Inventory

 

2.1, 3.1

RA-5

Vulnerability Monitoring and Scanning

x

3.2, 3.3

RA-9

Criticality Analysis

 

3.1

SC-7

Boundary Protection

x

1.4, 4.4

SC-8

Transmission Confidentiality and Integrity

 

2.4

SC-28

Protection of Information at Rest

 

2.3

SI-2

Flaw Remediation

x

3.2

SI-3

Malicious Code Protection

x

4.3, 4.4

SI-4

System Monitoring

x

4.2, 4.3

SI-5

Security Alerts, Advisories, and Directives

x

3.2, 3.3, 4.3

SI-7

Software, Firmware, and Information Integrity

 

4.3

SR-8

Notification Agreements

x

3.2

 

The measures are intended to secure the use of deployed EO-critical software in federal agencies’ operational environments. Security measures for EO-critical software are not intended to be comprehensive, nor do they eliminate the need for other security measures.

One provision in “Security Measures for ‘EO-Critical Software’ Use Under Executive Order (EO) 14028” falls outside of the scope of SP 800-161, Rev. 1. Security Measure 2.5 outlines a requirement to “back up data, exercise backup restoration, and be prepared to recover data used by EO-critical software and EO-critical software platforms at any time from backups.[3]” Though relevant to sound C-SCRM practices, controls related to Security Measure 2.5 are not included in SP 800-161, Rev. 1, because they are not third-party risk-related. Rather, they focus on managing the software within a system.

Mappings to Security Measure 2.5 and partial security measure mappings outside of the scope of this document are outlined in the table below.

Federal agencies that seek to fully conform with all mapped controls across all EO security measures, regardless of whether they are C-SCRM-specific in nature, may use this table to accelerate conformance or refer directly to “Security Measures for ‘EO-Critical Software’ Use Under Executive Order (EO) 14028.”

Table F‑3: C-SCRM Control and Security Measure Crosswalk

Control Identifier

Control (or Control Enhancement) Name

C-SCRM Baseline

EO Security Measure

AU-4

Audit Log Storage Capacity

N/A

4.1

AU-5

Response to Audit Logging Process Failures

N/A

4.1

AU-8

Timestamps

N/A

4.1

AU-11

Audit Record Retention

N/A

4.1

CA-7

Continuous Monitoring

N/A

3.2, 3.3, 4.1

CP-9

System Backup

N/A

2.5

CP-10

System Recovery and Reconstitution

N/A

2.5

SC-2

Separation of System and User Functionality

N/A

1.3

SC-7(15)

Boundary Protection | Networked Privileged Accesses

N/A

1.3

 

--------------

[1] National Institute of Standards and Technology. (2021). Definition of Critical Software Under Executive Order (EO) 14028
 

[2] While the base control is not addressed within SP 800-161, Rev. 1, the topic at large is addressed through supplemental guidance provided for control enhancements to the base control within SP 800-161, Rev.1.
 

[3] National Institute of Standards and Technology. (2021). Security Measures for “EO-Critical Software” Use Under Executive Order (EO) 14028

 

Content:

Created May 3, 2022, Updated May 5, 2022