An August memo from the White House represents another missed opportunity for transformational change in cybersecurity. The memo from the interim director of the office of management and budget was sent to the heads of all executive departments and agencies. In a nutshell, the memo directs all agencies to implement the National Institute of Standards and Technology (NIST) guidelines in July — and that is precisely the problem. These guidelines fall short in recognizing the breadth of modern software and how applications are developed in large federal agencies and global enterprises.
Missing the Mark on “Bold Changes” to Cybersecurity
The origin of the guidelines was the White House executive order (EO) on cybersecurity that was issued on May 12. The EO called for “bold changes and significant investments in order to defend the vital institutions that underpin the American way of life.” The action was in response to a growing volume of cyber-attacks, including the devastating SolarWinds breach that impacted 17,000 organizations, including multiple federal agencies.
Among other things, the EO directed that, within 60 days, NIST would collaborate with the National Security Agency (NSA) to “publish guidelines recommending minimum standards for vendors’ testing of their software source code, including identifying recommended types of manual or automated testing.”
But when the NIST guidelines were released in July, they were anything but bold in my opinion — and therefore violated the spirit of the original EO. As I noted at the time, the guideline contains no specifics as to what qualifies as a threat model, what qualifies as application security verification and which vulnerabilities must be fixed. Moreover, NIST did not even provide a usable definition of “critical software,” deciding to focus on security software instead of systems with a critical mission.
Understanding What Is Critical
Defining “critical” is not my specialty. Still, I think the definition of critical infrastructure found in a 2013 EO is a good start: “[S]ystems and assets, whether physical or virtual, so vital to the United States that the incapacity or destruction of such systems and assets would have a debilitating impact on security, national economic security, national public health or safety, or any combination of those matters.”
"By focusing only on a small subset of the universe of all software, we failed to ensure the security of all types of systems"
Compare that definition to the list of software categories covered by the August memo, which amount to an agency’s infrastructure software and security tools. Focusing narrowly on security software is the wrong approach. What about the applications that run a nuclear power plant, a dam, or other critical physical infrastructure?
What about the software that manages elections, analyzes data from COVID-19 vaccine trials or processes social security checks? Are these applications not considered critical? It seems to me that the narrow definition incentivizes agencies to avoid the standards whenever possible.
Creating an Accurate Definition of Software
Defining “software” is more in my area of expertise, and I think that NIST has missed the mark here too. By focusing only on a small subset of the universe of all software, we failed to ensure the security of all types of systems. Instead, we need to cover all aspects of the software supply chain — all the different code that affects the security of the final product.
A good starting point for a broad definition of software is the following categories that I have elaborated upon extensively in recent months. Indeed, the definition is incomplete without all four of these elements:
- Software you write:
Custom code of all types, including web and desktop applications and APIs. Also, serverless, batch jobs, customizations to existing software and configuration files. - Software you import:
Code drawn from open-source libraries, frameworks and modules. - Software you run:
Off-the-shelf applications acquired from third parties if they are used for critical purposes. Generally, the buyer has little insight into the security of these applications. - Software you build with:
Developer tools used to build, package, test and deploy code.
The Need for Bold Action
With a more expansive definition of critical software — and an objective way to quantify the security of an application — NIST could have seized on a once-in-a-generation opportunity to truly transform application security and make software more secure for users. Unfortunately, these new guidelines will simply be another checkbox that agencies will strive to avoid whenever possible in their present form. First, they’ll dodge the definition of critical software. Then, if they are deemed “EO critical,” they’ll choose the easiest possible path through the security testing standard, which could be almost none at all.
In their current form, I believe these guidelines will fall far short of the positive impact that the White House envisioned in the original EO. Therefore, I encourage the administration to take another look at NIST’s new standards and seize the opportunity to make a real difference.