President Joe Biden has just released an Executive Order (EO) on improving the nation’s cybersecurity. Starting today, the President has directed several government agencies to begin formulating guidelines and rules to shape an environment where security is verifiably baked into technology products.
This EO directs these agencies to develop new security requirements for software vendors selling into the U.S. government. These requirements will be incorporated into federal contracts for commercial software and hardware with the intent of imposing “more rigorous and predictable mechanisms for ensuring that products function securely, and as intended.” This is a monumental shift that will have an immediate impact on global software development processes and lifecycles.
In addition to a host of new information and operational security measures that government agencies need to implement, the new order establishes a robust approach to supply chain security. The new requirements will include security testing throughout the development process as well as a Software Bill of Materials (SBOM) to address security issues in open source components. This EO will have a significant impact on:
While this EO is targeted at federal procurement, we fully anticipate that other sectors will quickly adopt the requirements as embodying industry best practices – whether as part of their standard contracting language, in security questionnaires, or as prerequisites for cyber insurance coverage. Furthermore, the reach of US federal procurement is so vast, that we expect virtually all device manufacturers and software companies to be impacted directly.
We will continue to track developments under this EO, and we will provide assessments and robust guidance as the guidelines and requirements begin to take shape.
For the moment, here is a summary of the key impacts this EO will have on the technology sector:
Software and hardware vendors will need to start providing more proof of their products’ security, their testing approach, vulnerabilities impacting their products, and their security development lifecycle.
From the EO: “The development of commercial software often lacks transparency, sufficient focus on the ability of the software to resist attack, and adequate controls to prevent tampering by malicious actors. “
What developers and manufacturers need to do: Simply responding to a third-party risk questionnaire about high-level software development practices is no longer enough. Product security and engineering teams now need to provide an accurate and complete SBOM, detailed output from their security testing tools, assurances about their supply chain and development environment security, and detailed reports about the provenance of all of the components in their software.
We recommend that all developers:
Software and device vendors will need to prove that they protect their development environments and software supply chains from potential threats.
From the EO: Guidelines will include standards for “employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code”
What developers and manufacturers need to do: The most important step is to ensure that your engineering teams, development environments, and all source code are being secured in accordance with best practices for network and supply chain security in a comprehensive documented process.
What we can take away from SolarWinds is that software supply chains and development environments are attractive targets for malicious actors. One of the best countermeasures to potential compromise is to ensure that you have traceability from your final software build to the original source code and testing in place on those final builds.
Software and connected device vendors will need to employ automated testing tools to check for vulnerabilities in first- and third-party software, and those tools will need to be run against every product, version, and update release.
From the EO: Guidelines will include standards for “employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at a minimum prior to product, version, or update release”
What developers and manufacturers need to do: Software developers will need to adopt a robust security testing tool suite to ensure that the entirety of their products are being tested. In particular, this can be very challenging for connected device and embedded system development environments.
These devices and their firmware tend to be built using custom build tools and processes that are incompatible with traditional Application Security tools. Additionally, most of the vulnerabilities in these devices manifest at the system level (e.g. misconfigurations of operating system services, embedded credentials, etc.), which requires new approaches for scalable security testing.
Software and connected device vendors will be required to provide a software bill of materials alongside every product that they sell to a Federal entity.
From the EO: Guidelines will include standards for “providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website” “…obtaining an SBOM, and using it to analyze known vulnerabilities are crucial in managing risk.
What developers and manufacturers need to do: Most modern software is composed of numerous third-party and open source components rather than being written line by line, and assuring the security of software increasingly depends upon a developer’s ability to produce an accurate and comprehensive list of all of those components. There are numerous open source and commercial tools available that can help with this problem, but it will also require an investment in people, processes, and training.
For connected devices, software composition analysis (SCA) can be particularly challenging due to the lack of transparency into your suppliers’ software and lack of embedded development environment compatibility from traditional Application Security products. Finite State recommends that you seek an SCA solution that can operate on final firmware builds, identify components and dependencies within code and compiled binaries, and analyze software regardless of its underlying hardware/instruction set architecture. This will ensure that you can stand behind the accuracy and completeness of your SBOM.
Software and connected device vendors will not only need to test their products — they will also need to provide testing results to their customers.
From the EO: Guidelines will include standards for “providing, when requested by a purchaser, artifacts of the execution of the tools and processes [to secure code supply chains, check for vulnerabilities, and remediate them] and making publicly available summary information on completion of these actions, to include a summary description of the risks assessed and mitigated”
What developers and manufacturers need to do: Trust and security require visibility, and this requirement opens up traditionally internal information to external stakeholders. It’s important that software and connected device developers recognize that their security testing tools need to output reporting that’s appropriate for consumption by their customers but proves the execution of a robust security process. It’s important to present this information in a transparent manner that accounts for nuances of the development processes, allows for vendor commentary on any security issues identified, and summarizes the risk against industry benchmarks and standards.
In addition to conducting the required security testing and providing the requested data about your software and supply chains, each vendor will have to attest that their security practices are compliant with key security requirements and that all the data provided is accurate.
From the EO: Guidelines will include standards for “attesting to conformity with secure software development practices [and] ensuring and attesting, to the extent practicable, to the integrity and provenance of open source software used within any portion of a product
What developers and manufacturers need to do: The direction from the EO is to push companies towards demonstrable compliance with security practices. As with other elements of the EO, simply checking a box on a security questionnaire will not be sufficient. Companies will need to affirmatively state that they have met specifically articulated security requirements.
Software and connected device developers will need to have the utmost confidence in their product security program and associated artifacts that they share with their customers. This means that tooling needs to be robust, compatible with your entire product portfolio, and transparent in its processes.
While companies might be inclined to gloss over such requirements, a false attestation could result not only in termination of a specific contract, it could lead to an investigation by the relevant agency’s inspector general and the possibility of being blocked from doing business with the federal government.
Ultimately, this executive order signals a new era for cybersecurity that puts regulators, developers and manufacturers, and the larger cybersecurity community firmly on the same page, speaking the same language. It empowers security professionals to act with confidence and organizations to build out their security infrastructure to support their needs. The end result will be a safer, more secure national ecosystem that holds all of us accountable.