The US Government is Working Globally to Shift Cyber Duties: New Report Shows Ambitious Goals

As part of the government’s move to “rebalance” responsibilities in cyber, described in the National Cybersecurity Strategy, the United States government on April 13 released a notable document in partnership with several allied governments calling for major changes to the way technology is built and managed. In Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default, CISA, the FBI, and the NSA partner with other national security agencies and regulators to offer recommendations for the private sector. The fifteen page document in some places suggests the private sector is not doing enough and sets out new expectations around deployment of patching and upgrades.

The document begins by critiquing the status quo, in which it finds that “technology manufacturers have relied on fixing vulnerabilities found after the customers have deployed the products, requiring the customers to apply those patches at their own expense.” These governments call for manufacturers to “take ownership of improving the security outcomes of their customers” to “break the vicious cycle of creating and applying fixes.” These governments “strongly encourage every technology manufacturer to build their products in a way that prevents customers from having to constantly perform monitoring, routine updates, and damage control on their systems to mitigate cyber intrusions.” 

The document offers operational and governance recommendations, framed around the notion that “the burden of security should not fall solely on the customer” and that it is time to “embrace radical transparency and accountability.” It is not clear whether these regulators differentiate between retail end user “customers” and large enterprise and commercial customers, as some of their recommendations—particularly in the “secure-by-default” section—seem to apply differently to different types of customers.

“Secure-By-Default” Suggests Providers Should Manage and In Some Instances Override Customers’ Security Choices

Among other things suggested in the document, the agencies identify “Secure-by-Default configurations” that manufacturers should meet in new products and they “should strive to update products to conform to these practices as they are refreshed.” The goal of these practices is to protect users by minimizing the steps that they—as opposed to developers—must take.  A few examples show how much these governments are expecting of suppliers.

• Eliminate default passwords. The authors recommend that “products require administrators to set a strong password during installation and configuration” and that Multifactor Authentication (MFA) be mandated for privileged users.
• Secure Logging. Manufacturers should “Provide high-quality audit logs to customers at no extra charge.”
• Software Authorization Profile. “Software suppliers should provide recommendations on authorized profile roles and their designated use case. Manufacturers should include a visible warning that notifies customers of an increased risk if they deviate from the recommended profile authorization.
• Prioritize “forward looking security over backwards compatibility.” Prioritize security over backwards compatibility, “empowering security teams to remove insecure features even if it means causing breaking changes.”
• Track and reduce “hardening guide” size. “The authoring agencies recognize that shortened hardening guides result from ongoing partnership with existing customers and include efforts by many product teams, including user experience (UX).” But the agencies call for these documents to be shortened and simplified as more things become standard and mandatory.
• Consider the user experience consequences of security settings. “Each new setting increases the cognitive burden on end users and should be assessed in conjunction with the business benefit it derives.”

The agencies recognize that these changes may be disruptive but articulates an expectation that software providers can force or nudge their customers.

“While customer input is important, the authoring agencies have observed important cases where customers have been unwilling or unable to adopt improved standards, often network protocols. It is important for the manufacturers to create meaningful incentives for customers to stay current and not allow them to remain vulnerable indefinitely.”

The document does not address contractual allocations of responsibilities or duties.

Secure-By-Design Moves Incorporate New U.S. Cyber Goals

The document also identifies “Secure-by-Design” tactics, and touts the utility of “the Secure Software Development Framework (SSDF), also known as National Institute of Standards and Technology’s (NIST) SP 800-218, is a core set of high-level secure software development practices that can be integrated into each stage of the software development lifecycle (SDLC).” It provides a “a non-exhaustive list of illustrative roadmap best practices.”

In a notable embrace of ongoing work in the United States, the document calls for developers to “Satisfy Cyber Performance Goals (CPGs)” created by DHS CISA. It calls to “[d]esign products that meet basic security practices. CISA’s Cybersecurity Performance Goals outline fundamental, baseline cybersecurity measures organizations should implement.” This recommendation thus incorporates the CPGs, which were designed for critical infrastructure (CI), have been subject to ongoing comment and revision, and are not yet customized for CI sectors.

The document’s heavy reliance on U.S. publications suggests successful advocacy by the United States to promote harmonization and broader global use of domestic frameworks. This is good news, much like the successful global adoption of the NIST Framework for Improving Critical Infrastructure Cybersecurity.

 A few notable additional examples of “Secure-by-Design” tactics from the document:

• Code review. “Strive to ensure that code submitted into products goes through peer review by other developers to ensure higher quality.”
• Software Bill of Materials (SBOM): “Incorporate the creation ofSBOM3 to provide visibility into the set of software that goes into products.”
• Vulnerability disclosure programs: “Establish vulnerability disclosure programs that allow security researchers to report vulnerabilities and receive legal safe harbor in doing so. As part of this, suppliers should establish processes to determine root causes of discovered vulnerabilities. Such processes should include determining whether adopting any of the Secure-by-Design practices in this document (or other similar practices) would have prevented the introduction of the vulnerability.”
• CVE completeness: “Ensure that published CVEs include root cause or common weakness enumeration (CWE) to enable industry-wide analysis of software security root causes.”
• Memory safe programming languages.
• Secure Software Components: “Acquire and maintain well-secured software components (e.g., software libraries, modules, middleware, frameworks,) from verified commercial, open source, and other third-party developers to ensure robust security in consumer software products.”

To the extent U.S. businesses are prepared to embrace the Secure Software Development Framework (SSDF) in NIST SP 800-218, and the other innovations being promoted across government, this document suggests they may be gaining traction overseas as well.

What Comes Next?

This document is notable for the breadth of its international authors, whose legal and regulatory systems vary. It also appears to have had little public input, despite suggesting dramatic shifts in expectations across the private sector. 

The United States is moving full steam ahead to implement the National Cybersecurity Strategy and to execute on multiple Executive Orders.  The Strategy itself called for changes to software development through imposition of liability. This document does not go so far, but it is likely to be used to call for further regulatory and legal changes.

As the United States government move ahead with policy and legal changes to the cyber status quo, the entire software ecosystem should pay attention. This report comes as the Federal Trade Commission examines security defaults and relationships with cloud providers, among other workstreams. We expect further movements from government on these topics, including software attestation requirements in federal contracts, and efforts to increase mandates on critical infrastructure and others.