On May 12, 2021, President Biden signed the 2021 Cybersecurity Executive Order (EO). Since then, I've thought a lot about what it really means for federally focused sellers and buyers of software and how it might practically improve the security of applications and strengthen our nation's cyber defenses.
During this time of reflection, I've had many conversations with industry CISOs, government technologists and everyone in between. So far, the consensus is that "the EO is potentially an important step in the right direction, but the ultimate proof will be in the pudding."
Well, as everyone knows, when it comes to public policy, cyber security, and industry standards, it can take quite a while (and many cooks) to complete a batch of pudding. Notwithstanding, this past Friday witnessed an important milestone in the effort to implement core directives contained within the EO. Specifically, the National Institute of Standards and Technology (NIST) released their much anticipated definition of "critical software." To me, this is an early glimpse at the complicated dish being made; and it left me realizing that we have a long way to go before anything will be finished.
How does NIST define critical software?
According to NIST, the newly minted definition of "critical software," is:
EO-critical software is defined as any software that has, or has direct software dependencies upon, one or more components with at least one of these attributes:
- is designed to run with elevated privilege or manage privileges;
- has direct or privileged access to networking or computing resources;
- is designed to control access to data or operational technology;
- performs a function critical to trust; or,
- operates outside of normal trust boundaries with privileged access.
The definition applies to software of all forms (e.g., standalone software, software integral to specific devices or hardware components, cloud-based software) purchased for, or deployed in, production systems and used for operational purposes.
OK, but what does that mean?
In my case, I had to read, and re-read, the definition a handful of times before I could even begin to wrap my head around it. I found myself saying, "wait, what?" I thought all software under the sun has a direct dependency upon one or more components with at least one of the following attributes: supports users differently based on privileges, touches a network or other computing resource, interacts with data or operational technology, performs any function critical to trust, and requires privileged access when operating outside of trusted boundaries.
If that's the definition of critical, is any software not critical?
Breadth of definition vs depth of implementation
As I reflect on Friday's communication from NIST, it seems important to separate their definition of "critical software" (broad) from their recommendation for the initial implementation of EO directives (narrow).
Indeed, NIST's narrow recommendation regarding the initial implementation of EO directives stands in stark contrast to their broad definition of critical software. Specifically, NIST recommends that phase one implementation of the EO focus ONLY on standalone, on-premises, software that has security-critical functions or poses similar significant potential for harm if compromised.
Further, NIST states that subsequent and future phases of the EO implementation would go beyond just on-premise software providing security critical functions. Notably, NIST stated that future phases of EO implementation would address other categories including: software that controls access to data; cloud-based and hybrid software; software development tools such as code repository systems, development tools, testing software, integration software, packaging software, and deployment software; software components in boot-level firmware; or software components in operational technology (OT).
What's next in defining critical software?
I don't know about you, but I am going to continue to follow this conversation closely, and will be eagerly anticipating my next peek at the pudding, e.g. NIST's first set of standards aimed at what critical software suppliers need to do to adhere to the EO, as well as CISAs additional clarification on what's actually considered critical software. I'm also going to continue talking to the industry and seeing if we can figure out what this all means together.
If you're interested, please join the conversation this Wednesday (June 30th) at 1:00 PM ET. Together with Steve Springett, Founder of the OWASP CycloneDX SBOM project, and Mike Wilkes, CISO at Security Scorecard, we will be discussing more about what critical software means, and what else to expect as the process of making EO pudding continues.
