Today we welcome cloud cybersecurity expert Chris Hughes to TestifySec in the role of Board Advisor. Chris brings over a …
On May 12, 2021, President Biden issued Executive Order (EO) 14028 on “Improving the Nation’s Cybersecurity.” This EO presents a range of requirements across the gamut of cybersecurity:
- Improving transparency across government and private sector
- Establishing a cybersecurity safety board
- Creating a timeline to Zero Trust adoption
- Building an SOP for Incident response
- Implementing a new EDR system
- Improving event logging
- Securing the software supply chain
The focus of this blog is the last item, Software Supply Chain security.
The most powerful tool in the government toolbox lies in acquisition. The EO in particular directs the government to only purchase software that is developed securely, and directs the National Institute of Standards and Technology (NIST) to “issue guidance identifying practices that enhance the security of the software supply chain.”
The EO stipulates the improvement of the security of the software supply chain (Section 4) by
- Establishing baseline security standards for development of software sold to the government, including requiring developers to maintain greater visibility into their software and making security data publicly available.
- Creating a pilot program to quickly determine whether software was developed securely.
- Using the purchasing power of the Federal Government to drive the market to build security into all software from the ground up.
The executive order also created a 360-day timeline for federal agencies and their vendors to follow, and the deadline for adoption is quickly approaching.
The cybersecurity imperatives embodied in the Executive Order are all laudable and necessary, and the agencies implicated in the order, including CISA, NIST, the [NSA]](https://www.nsa.gov/), the DHS, FAR, DARS, and the Commerce Department, did not hesitate to begin the march toward implementation and have made significant progress.
The executive order is styled as a cybersecurity imperative that (among other things) addresses the Federal and DoD acquisition processes. In particular, the requirement for “minimum” Software Bills of Material (SBOMs) is a strong step towards securing the supply chain, along with other requirements for interagency threat information sharing, cloud security architecture, zero trust, software testing, establishing a cyber safety review board, creating a cyber playbook, and improving incident detection and remediation.
In all the above areas, there is a “trickle down” effect. Implementation begins with programs at the affected agencies, and most immediately extends to the major government contractors who service them.
Bloomberg Government BGOV200 Top Contractors
Those “prime” contractors work with their peers and also with a chain of sub-contractors (“subs”) in a goods and services supply chain that crosses ecosystems of thousands of companies, extending a dozen deep or more. Add open source projects and library code dependencies and the supply chain pyramid becomes fathomless.
The Executive Order and programs it instigates go a long way towards improving cyber-awareness and taking concrete steps to protect the nation’s assets. But like most government initiatives, the Order also presents the cybersecurity and IT ecosystems with non-trivial challenges: Scalability In an ideal world, supply of “minimal” (read comprehensive) SBOMs would be de rigger, standard operating procedure (SOP) up and down the supply chain. But given the current state of affairs, where trustworthy SBOMs are still a novelty and burdensome requirement for organizations small and large, it will likely take years before compliance is SOP. And unless the entire supply chain can vouch for the content of its software, the turtle at the top is just a paper tiger.
Compliance to the specifics of EO covers a lot of ground. Regarding the software supply chain, the industry has mostly focused on SBOM creation/supply, as an artifact, but not specially on the how and when creation. Yes, an SBOM lists the included software modules, calls out dependencies on other software outside the actual bill of materials (e.g., operating system libraries, common shared libraries, code pulled directly from project sites, etc.), and hopefully implies some level of diligence applied to these items to ascertain provenance, licensing and security status In reality, even with powerful Software Composition Analysis (SCA) tools, an SBOM is just a list of ingredients. Most software and hardware suppliers don’t have the resources to remediate red flags discovered in SCA scans. Importantly, scanning tools are too often applied very late in the software lifecycle, in some cases merely as a prelude to final packaging, to meet customer requirements as a checkbox.
NIST, fortunately, anticipated the limits of an SBOM-centered approach with the [Secure Software Development Framework])https://csrc.nist.gov/Projects/ssdf) (SSDF). The SSDF, more holistically, lays out four practice areas for organizations to pursue:
- Prepare the Organization
- Protect the Software
- Produce Well-Secured Software
- Respond to Vulnerabilities
and provides structure for each of those practices:
- Practice - explanation and benefits of a practice
- Task - action(s) needed to perform that practice.
- Implementation Example - notional example of types of tools, processes, and method that could be used to help implement a task.
- Reference - A pointer to an established secure development practice mappings to a particular task.
As it turns out, TestifySec Witness is the ideal tool for helping organizations follow NIST SSDF. We even wrote a blog about it.
The main economic beneficiaries of the EO are the primes and subs, who can charge compliance costs to their customers - the U.S. Government and consequently tax payers. Compliance for these gargantuan companies represents a huge opportunity and a potential ongoing operational profit center. For most subs, compliance represents a cost of doing business with the primes, a line item on still-profitable SOWs. But for the rest of the ecosystem - smaller contractors and even companies that do zero business with the government, compliance can represent an unfunded mandate[a], especially burdensome when the right IT staff and developers are hard to hire.
A Life-cycle Approach is Critical
And even if an organization is in a position to generate an SBOM for its delivered products, those organizations lack visibility into the entire lifecycle, from code design, creation, test, integration and QA for their own code, and discovery, ingress, customization, test and integration for 3rd party code, including open source.
So, while last year’s Executive Order goes a long way towards making America more secure by raising awareness and encouraging better practices, in the short term it will only serve to highlight and exacerbate disparities in the supply chain .
To help companies of all sizes and all tiers in the government IT supply chain (turtles large and small) implement best practices, we are launching TestifySec Witness. Learn more about it today.