SD Elements support for EO 14028, “Improving the Nation’s Cybersecurity”

In May 2021, the White House issued Executive Order (EO) 14028, “Improving the Nation’s Cybersecurity.” The order was a response to the growing number of cyberattacks on supply chains and critical infrastructure. These incidents, including a ransomware attack on the Colonial Pipeline, the breach of SolarWinds Orion,  which is used to manage organizations’ IT stacks, and Microsoft Exchange Server hack brought to focus the need to improve software security across the government.

EO 14028 is intended to improve the security of the software used by the US Federal government. “Software” under EO 14028 includes “firmware, operating systems, applications, and application services (e.g., cloud-based software), as well as products containing software.” The EO directed the National Institute on Standards and Technology (NIST) “to identify existing or develop new standards, tools, and best practices for complying with the standards, procedures, or criteria” for EO-critical software use. It further directs the Office of Management and Budget (OMB) to require all federal agencies to comply with the security measures guidance.

Required Security Standards for EO 14028

The Executive Order recognizes that security is not the sole responsibility of development teams. Accordingly, it also provides guidance for verification (testing) of software and best practices for operating critical software.

Software Development

Prior to the issuance of EO 14028, NIST had previously published its Framework for Improving Critical Infrastructure Cybersecurity, as well as  version 1 of the Security Software Development Framework.

However, in response to the directives in the EO, in February 2022 NIST issued an updated version of the latter. Special Publication (SP) 800-218, Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilitiesincludes mappings to other security requirements including NIST SP 800-53R5: Security and Privacy Controls for Information Systems and Organizations.

The SSDF provides high-level secure software activities for integration into an organization’s Software Development Lifecycle (SDLC). The activities or practices are intended to minimize the number of vulnerabilities in software, mitigate the impact of exploits of undetected or unaddressed vulnerabilities, and “address the root causes of vulnerabilities to prevent future recurrences”.

Guidance published by the OMB in September 2022 requires US agencies to start collecting attestation letters from software vendors for critical software by June 2023 and for all other software by September 2023.

Software Verification/Testing

In 2021 the Department of Commerce published NISTIR 8397: Guidelines on Minimum Standards for Developer Verification of Software for vendors or developers of software sold or licensed to the government. The publication provides eleven recommendations for software verification techniques, the first of which is “Threat modeling to look for design-level security issues.”

To ensure consistency in descriptions of controls and best practices, the US Department of Defense published the Control Correlation Identifier (CCI). The CCI “allows a security requirement that is expressed in a high-level policy framework to be decomposed and explicitly associated with the low-level security setting(s) that must be assessed to determine compliance with the objectives of that specific security control.”

Software Usage

In October 2021 NIST published its Security Measures for EO-Critical Software Use. It provides guidance to agencies when using EO-Critical software such as applying practices of least privilege, network segmentation and proper configuration. To assist in compliance, the publication maps each Security Measure to references in the NIST Cybersecurity Framework, SP 800-52R5, and other government publications.

How SD Elements Supports EO 14028

When fully implemented, any organization seeking Authority to Operate (ATO) and provide software to Federal government agencies must comply with the requirements of the EO including the SSDF and SP 800-53R5 for security controls and NISTIR 8397 for threat modeling.

Meeting these requirements at scale requires automation. This is particularly true when assessing software (application) threats and required countermeasures. Building threat models manually can require weeks of effort from senior development, security, operations, and compliance personnel. Further, manual threat modeling can be inconsistent as the teams assessing an application and prescribing controls change. As the regulatory environment and threat landscape changes, so too must the model. In modern DevSecOps environments, where requirements can change weekly and teams can push dozens of releases to production daily, manual threat modeling simply does not scale.

SD Elements solves this problem by automating the threat modeling process and shrinking the time required from weeks to hours. It takes a developer-centric approach to threat modeling that is not  totally reliant on scarce security resources. SD Elements starts with a brief questionnaire to describe the software project including the technology stack and frameworks, deployment environment, and dozens of regulatory standards to which the application may be subject.  From this, SD Elements generates a complete list of known threats, controls, and countermeasures. Integrations with issue trackers like JIRA, ServiceNow, and Microsoft Azure DevOps deliver requirements – including code samples and test plans – directly to those individuals responsible for implementation.

SD Elements newest release covers the regulatory guidelines and requirements of EO 14028. In addition to the SSDF and SP 800-53 and dozens of other standards, it provides new content for the Control Correlation Identifier (CCI),  Security Measures for EO-Critical Software Use, and Guidelines on Minimum Standards for Developer Verification of Software (NISTIR 8397). These map the threat modeling recommended standards in NIST to verification tasks in SD Elements and allow users to generate compliance reports for these just as they would our other supported regulations.

You can learn more about the capabilities of SD Elements and our newest release here.