The Trump administration’s recent OMB memo walks back important Secure-by-Design concepts

COMMENTARY: Cyber attackers are out there every day. They want to steal personal information. They want to gain control over infrastructure. They want to disrupt society.

And they don’t care whether it’s a government agency, a titan of industry, or a remote worker sitting at home wasting time looking up recipes for dinner that night on his or her Wi-Fi-enabled fridge.

[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]

These attackers are looking for weaknesses to exploit. Some weaknesses are because of assumptions. Others are caused by inattention. Still more involve misplaced priorities. The best exploitable weakness occurs when attackers can replicate success with one victim against many other potential victims.

Cybercrime has become a big business, so the more victims the better for investors.

Successfully defending against an attacker takes skill, but it’s also contextual and often requires significant resources. When it comes to that Wi-Fi-enabled fridge, consumers implicitly trust the supplier – their only other choice: avoid connected fridges. Consumers place that same trust in banks and IT systems used by government.

It's against this background that a mundane memo by the Office of Management and Budget (OMB) now plays an important role in cybersecurity.

OMB Memo M-26-05 by the Trump administration rescinds two prior OMB memos, M-22-18 and M-23-16. These two memos can draw direct line of sight to President Biden’s May 2021 Executive Order 14028 - Improving the Nation’s Cybersecurity.

This line of sight from the Biden administration requires U.S. government agencies to follow specific guidance from NIST known as the Secure Software Development Framework (SSDF) when using third-party software. Put another way, agencies must use software that’s developed in a secure manner.

Agencies can do this in three ways:  

The Biden-era OMB memo M-22-18 required supplier attestations. These attestations are prone to gamesmanship, but they are the least costly option above “trust me, it’s all good.” Nothing in M-22-18 precluded going deeper in certifications, and in fact, it endorsed 3PAOs. To support transparency, M-22-18 endorsed the use of a software bill of materials (SBOMs) and coordinated vulnerability disclosure programs. M-23-16 added to the mix the concept of a Plan of Actions and Milestones (POA&M) to deal with inconsistencies in adherence to the SSDF by a supplier.

From a very pragmatic point of view, the SSDF, SBOMs, M-22-18, and M23-16 combined to define a baseline for the level of software and product security a supplier needed to count the U.S. government as a customer.

Well, this was true until OMB memo M-26-05 came along and said that this baseline with its low-cost attestation model imposed “unproven and burdensome software accounting processes” that prioritized compliance over genuine security investments.

What’s weird here is that M-26-05 still endorses the use of resources created under M-22-18 and M-23-16. It acknowledges use of the SSDF Attestation Form satisfies OMB requirements as does collection of an SBOM – providing it done via contract. 

So, what’s a supplier wishing to deliver secure software to the government to do? Or a requisition office tasked with identifying the most secure option to meet a mission objective?

One path forward: CISA’s Software Acquisition Guide for Government Enterprise Consumers and its companion web tool.

This guide was developed as part of a public-private partnership with the goal of advancing software assurance outcomes by taking a risk-based approach. It directly complements the CISA Secure-by-Design initiative and establishes the concept of Secure-by-Demand, in which its acknowledged that without demand for more secure products, suppliers will only produce products with just-enough security to make the sale.

The acquisition guide says that suppliers should get credit for the good work they’re already doing. Doing so reduces the burden. For example, if a product has FedRAMP Authorization, that should be sufficient proof of secure cloud deployments.

Since any given software might have differing security requirements based on agency expectations, if there are gaps in security practices, it becomes easy for agency teams to contextually map gaps to requirements and determine if exceptions are warranted or if POA&Ms are needed. And of course, where there’s transparency into development practices, the risk of interconnected systems becomes manageable.

Memos M-22-18 and M-23-16 were products of their time. M-26-05 missed an opportunity to build on the baseline established by its predecessors and took a step backward.

Calling the SSDF into question with statements like “burdensome” does nothing to build trust. Using optional language like “may” offers an exit clause emphasizing just-enough thinking.

When we think about suppliers providing evidence they adhere to a recognized standard for secure development, that evidence becomes a supplier attestation. Some who support the Trump administration’s recent memo may view evidence of conformity as “software accounting,” but we want software providers to remain accountable for what they deliver. Building trust in software means advancing cybersecurity practices whenever possible, and in efficient ways.

We can only hope that the next OMB memo on cybersecurity will raise the bar.

Tim Mackey, head of software supply chain risk strategy, Black Duck

SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.