Cybersecurity Executive Order requires new software security standards

On Wednesday, May 12, President Biden signed an extensive Executive Order (E.O.) on Improving the Nation’s Cybersecurity. The E.O. is primarily directed at federal departments and agencies, and federal contractors, but its implementing standards will likely have a much broader impact across critical infrastructure sectors and related technology suppliers.

Key directives include:

• Development of new software security standards, tools, and best practices, prioritizing a yet-to-be defined category of “critical software”
• Maturation of a Software Bill of Materials (SBOM) and participation in vulnerability disclosure programs
• Formalizing software code testing expectations
• Development of standards and best practices for IoT cyber security, including consumer labeling
• Expanded breach notification requirements for technology suppliers, plus the establishment of a Cyber Safety Review Board to investigate significant cyber incidents
• A requirement for federal agencies to implement “zero trust” architectures, accelerating migrations to secure cloud and adopting other data protection capabilities—plus related endpoint detection, response, and logging—to mitigate continuing supply chain risk

Why it matters

The E.O. has been influenced by a series of crippling cyber attacks as well as an acknowledgement that the United States will continue to face unrelenting and increasingly severe cyber threats.

• Recent attacks have been highly disruptive and have exposed significant supply chain vulnerabilities.
  • SolarWinds: Russian intelligence services trojanized a software update that was downloaded by as many as 18,000 SolarWinds government and commercial customers.
  • Colonial Pipeline attack: On May 8, Colonial Pipeline confirmed that it temporarily halted operations across four of its mainlines as a result of a ransomware attack.
  • Attacks on lifeline/critical infrastructure sectors: In just the past few months, authorities have uncovered multiple attempts by bad actors to disrupt other lifeline sectors, for example water facilities and hospitals.
• The E.O. is focused on securing the U.S. government, but implications will be broader. While the standards and best practices will technically only apply to federal departments and agencies and their technology suppliers, it is likely that—where practicable—they will also be adopted by broader categories of buyers and suppliers across critical infrastructure as a “north star” for security expectations. In addition, the E.O. is leveraging the government’s procurement process and contractual language to drive compliance—a model that could be adopted in the commercial sector.
• The E.O. will accelerate efforts to enrich public-private information sharing and reporting. The government and private industry continue to struggle to share accurate and actionable threat intelligence. The E.O. acknowledges the unique visibility that technology providers have into threat activity and seeks to remove barriers for sharing threat intelligence. In addition, the E.O. will also expand breach notification expectations for software product and service providers.
• The E.O. underscores a security strategy migration to threat-informed defense. The requirements for federal agencies to implement “zero trust” architectures, plus related endpoint detection, response, and logging practices, reflect an acknowledgment of continuing supply chain exposure and a direction to “assume compromise.” These same principles apply equally to commercial sector organization targets of supply chain–related threats.

What to do about it: Technology supplier lens

While the standards and best practices mandated in the E.O. have yet to be finalized, technology suppliers can begin to prepare now.

• Map to purpose-built secure software frameworks and tools. In the spirit of not re-inventing the wheel, existing purpose-built secure software frameworks like the NIST Secure Software Development Framework (SSDF) and the Black Duck Building Security in Maturity Model (BSIMM) can serve as useful starting points for future guidance. Suppliers can prepare for future requirements by comparing current practices against these frameworks.
• Achieve greater software transparency. Software producers will be expected to have a greater understanding of how their software is authored, tested, and secured. This includes maintaining an up-to-date understanding of the origin of each software component, attesting to testing outcomes and risks mitigated during testing, and employing automated processes to maintain trusted software supply chains throughout the software life cycle. In addition, a Software Bill of Materials (SBOM), a key component of the E.O., offers a common framework for documenting and communicating an application’s “ingredients” to reduce code opacity, particularly for third-party open source components.
• Adopt threat modeling, control validation, and ATT&CK. Technology providers should anticipate being targeted by threat actors—either for financial gain or as a stepping stone into customer environments—and apply and validate security controls based on anticipated adversary behavior. By understanding the anatomy of recent supply chain attacks and associated tactics, techniques, and procedures (TTPs), defenders can ensure risk-based countermeasures are in place and effective to safeguard software code and other crown jewels. The MITRE Corporation’s Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) framework can help through its library of mappings between TTPs and defensive countermeasure coverage.
• Apply zero trust principles. In a zero-trust model, users are granted access to use a network service for a specific task and must reauthenticate for any new tasks. Security planning should also reflect zero trust principles within the enterprise and software life cycle to eliminate implicit trust in any network node or access point. This complicates an adversary’s effort to identify single points of weakness among interconnected traditional network boundaries, development environments, and cloud-enabled services.

What to do about it: Technology buyer lens

• Align supply chain risk management requirements. Buyers can start reviewing guidance such as SSDF and BSIMM now to consider how to incorporate them—as well as related independent validation and verification testing and breach notification activities—into contractual requirements and SLAs.
• Plan for using a Software Bill of Materials. A Software Bill of Materials will bring transparency into which third-party open source software libraries have been incorporated within a software product—whether commercial, proprietary, or open source. Armed with this information, a buyer can identify risks within each application, such as unpatched vulnerabilities disclosed within the National Vulnerability Database. Since vulnerability disclosures will occur throughout an application’s lifespan, implementing a continuous monitoring process for new disclosures is key to maintaining a fully patched deployment, as is validating that all patches match the origin of the application or its libraries. Buyers should look to suppliers for attestations when there is any question of applicability of any given weakness, vulnerability, patch, or associated mitigations.
• Apply zero trust. Buyers also need to consider zero trust, threat-informed defense approaches to safeguarding their own environments from continuing supply chain risks.