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.

Information Technology Laboratory

Executive Order 14028, Improving the Nation's Cybersecurity

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

Share

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.

EO-Critical Software Definition

NIST’s publication on the definition of critical software enhances traditional notions of context-based criticality with function-based definitions. Table 1 identifies the points at which criticality considerations in SP 800-161r1 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-161r1 guidance for federal agencies

Section IdentifierSection TitleEO-Critical Definition Impact
2Integration 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.3Multilevel 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.1C-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.4C-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 AC-SCRM Security Controls
  • Extend EO-critical definition considerations to ICT/OT-related service providers, where applicable.
Appendix CRisk 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 DC-SCRM Templates
  • Account for EO-critical definitions when considering the automated generation of C-SCRM plan elements, such as supply chain component criticality.
Appendix EFASCSA
  • Account for risk factors associated with EO-critical definitions when identifying, assessing, and responding to supply chain risks.
Appendix GC-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 EO 14028” in July 2021. Software supply chain security measures are essential for internal decision-making and supplier oversight. Federal agencies must recognize their roles as critical players in the software supply chain and should, at a minimum, internally implement the same security controls 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.

Table 2 outlines the mappings and coverage of the EO’s security measures across SP 800-161r1 controls, control enhancements, and supplemental guidance. Many of these are included in the C-SCRM controls baseline.

EO Security Measures and their associated SP 800-161r1 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 with SP 800-161r1 controls should use Table 2 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 controls and security measures crosswalk

Control IdentifierControl NameC-SCRM BaselineEO Security Measure
AC-2Account Managementx1.1, 1.2, 1.3, 2.2
AC-3Access Enforcementx2.2
AC-4Information Flow Enforcement 2.4
AC-5Separation of Duties 3.3
AC-6Least Privilege2x22.2, 3.3
AC-17Remote Accessx2.4
AT-2Literacy Training and Awareness2x25.1
AT-3Role-based Trainingx4.5, 5.1, 5.2, 5.3
AU-2Event Loggingx4.1
AU-3Content of Audit Recordsx4.1
AU-12Audit Record Generationx4.1
AU-13Monitoring for Information Disclosure 4.4
AU-14Session Audit 4.4
CA-7Continuous Monitoring2x23.2, 3.3, 4.1
CM-2Baseline Configurationx3.3
CM-3Configuration Change Control 3.3
CM-6Configuration Settingsx3.3
CM-7Least Functionalityx3.3
CM-8System Component Inventoryx2.1, 3.1
CP-3Contingency Trainingx5.2
IA-2Identification and Authentication (Organizational Users)x1.1, 1.2
IA-4Identifier Managementx1.1
IA-5Authenticator Managementx1.1
IA-9Service Identification and Authentication 1.2
IR-2Incident Response Trainingx4.5
PM-5System Inventory 2.1, 3.1
RA-5Vulnerability Monitoring and Scanningx3.2, 3.3
RA-9Criticality Analysis 3.1
SC-7Boundary Protectionx1.4, 4.4
SC-8Transmission Confidentiality and Integrity 2.4
SC-28Protection of Information at Rest 2.3
SI-2Flaw Remediationx3.2
SI-3Malicious Code Protectionx4.3, 4.4
SI-4System Monitoringx4.2, 4.3
SI-5Security Alerts, Advisories, and Directivesx3.2, 3.3, 4.3
SI-7Software, Firmware, and Information Integrity 4.3
SR-8Notification Agreementsx3.2

 

The measures are intended to secure the use of deployed EO-critical software in the operational environments of federal agencies. 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 EO 14028” falls outside of the scope of SP 800-161r1. 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-161r1 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 Table 3. 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 EO 14028.”

Table F-3. C-SCRM Control and Security Measure Crosswalk

Control IdentifierControl (or Control Enhancement) NameC-SCRM BaselineEO Security Measure
AU-4Audit Log Storage CapacityN/A4.1
AU-5Response to Audit Logging Process FailuresN/A4.1
AU-8TimestampsN/A4.1
AU-11Audit Record RetentionN/A4.1
CA-7Continuous MonitoringN/A3.2, 3.3, 4.1
CP-9System BackupN/A2.5
CP-10System Recovery and ReconstitutionN/A2.5
SC-2Separation of System and User FunctionalityN/A1.3
SC-7(15)Boundary Protection | Networked Privileged AccessesN/A1.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 in SP 800-161r1, the topic at large is addressed through supplemental guidance provided for control enhancements to the base control.

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

 

Content:

Information technology and Cybersecurity
Created May 3, 2022, Updated November 1, 2024