Among other things, Biden’s Cybersecurity Order is looking to introduce regulation for the development process of Software Vendors and to require more access to data from Service Providers.
As cyber attacks continue to hit both private companies and federal government networks, the White House has issued an “Executive Order on Improving the Nation’s Cybersecurity”, directed towards creating a trustworthy and transparent infrastructure, focused on the prevention, detection, assessment and remediation of cyber incidents.
In the last year, we’ve had at least two major hacking attacks: SolarWinds was breached, hackers gaining access to communications and data from several government agencies, and the most recent Colonial Pipeline ransomware attack that has led to fuel shortages along the East Coast.
source: InfoSec Insights citing CSIS.
It's clear that something needs to be done and that the direction of action must be changed. The White House seems to believe this as well:
"Incremental improvements will not give us the security we need; instead, the Federal Government needs to make bold changes [...]"
Biden’s Order comes with a series of changes, the most important one focusing on removing the contractual barriers that are currently limiting the sharing of threats or incident information between service providers, and the executive departments and agencies responsible for investigating or remediating cyber incidents.
By removing the contractual barriers when contracting an IT or OT service provider, and increasing the flow of information regarding potential threats, risks and incidents, the White House believes it will hasten both the process of obtaining the information and the appropriate response to the potential threat.
What does this mean for the Service Providers?
According to the new regulations, the service providers will have to:
· Collect data, information and reporting that may prove to be relevant to cybersecurity prevention, detection, response and investigation.
· Share such data, information and reporting that may relate to cyber incidents and potential incidents.
· Collaborate with Federal cybersecurity or investigative agencies in their investigations and responses to incidents, even by implementing technical capabilities to support the agency endeavors.
· Share cyber threat and incident information with agencies in industry-recognized formats.
The type of contractors and associated services providers covered by the proposed contract language are yet to be determined.
Security Enhancing Guidelines in Biden’s Order
The Executive Order on Improving the Nation’s Cybersecurity cites lack of transparency from Software Vendors.
"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."
In an effort to change that, the order asks for guidance to be issued, to identify the practices that can enhance the security of the software supply chain.
The guidance solicited by Biden includes standards, procedures, or criteria regarding:
(i) secure software development environments, including such actions as:
(A) using administratively separate build environments;
(B) auditing trust relationships;
(C) establishing multi-factor, risk-based authentication and conditional access across the enterprise;
(D) documenting and minimizing dependencies on enterprise products that are part of the environments used to develop, build, and edit software;
(E) employing encryption for data; and
(F) monitoring operations and alerts and responding to attempted and actual cyber incidents;
(ii) generating and, when requested by a purchaser, providing artifacts that demonstrate conformance to the processes set forth in subsection (e)(i) of this section;
(iii) employing automated tools, or comparable processes, to maintain trusted source code supply chains, thereby ensuring the integrity of the code;
(iv) 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;
(v) providing, when requested by a purchaser, artifacts of the execution of the tools and processes described in subsection (e)(iii) and (iv) of this section, and making publicly available summary information on completion of these actions, to include a summary description of the risks assessed and mitigated;
(vi) maintaining accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes, and performing audits and enforcement of these controls on a recurring basis;
(vii) providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website;
(viii) participating in a vulnerability disclosure program that includes a reporting and disclosure process;
(ix) attesting to conformity with secure software development practices; and
(x) ensuring and attesting, to the extent practicable, to the integrity and provenance of open source software used within any portion of a product.
Other relevant paragraphs speak of specific practices during design and implementation stages of the software.
[…] shall publish guidance outlining security measures for critical software as defined in subsection (g) of this section, including applying practices of least privilege, network segmentation, and proper configuration.
[…] shall publish guidelines recommending minimum standards for vendors’ testing of their software source code, including identifying recommended types of manual or automated testing (such as code review tools, static and dynamic analysis, software composition tools, and penetration testing).
This part will only apply to "critical software", a term that is yet to be defined but shall reflect:
[...] the level of privilege or access required to function, integration and dependencies with other software, direct access to networking and computing resources, performance of a function critical to trust, and potential for harm if compromised.
What does this mean for the "Critical Software" Vendors?
Companies such as MetalSoft will need to ensure that their development processes is designed in such a way that it mitigates as many of the risks related to the software as possible:
1. Use code review
This applies even for experienced developers, to identify vulnerabilities that might be introduced by new code.
2. Use zero trust security model for micro services
You can do that by authenticating your other micro services with certificates, using whitelists for micro services that must have access to certain data.
We are moving to a perimeter-less security. It is a major shift, from the perimeter type security where the developer assumes that there is an impenetrable fence around the app, to a sort of check-point type security, designed to contain breaches if they do happen.
3. Use RBAC
This implies giving permissions based on authorization, responsibility and job competency, as to protect against rogue users - or users whose accounts have been lost.
4. Use proven security frameworks (or libraries)
Vulnerabilities in your proprietary code might be harder to find due to lack of source code. The attacker will be able to exploit that vulnerability that can stay undetected for years.
5. Reduce the number of libraries
As mentioned before, a vulnerability in one of these libraries will only lead to vulnerability in your own software.
6. Have a robust update process
By having a robust update process set in place, you will be able to update the libraries as soon as a vulnerability is found.
7. Take your time to write good code.
Commit to only what is realistically doable, because good, clean code, with unit tests and proper design takes time to write. Make a good estimate of the time needed and of the resources involved so that you can fully commit to the task.
How does the new measures compare with other standards?
Our friends at Bigstep have published a very good review of what ISO and SOC type2 standards are and how to get them from a Service Provider perspective and why it matters to end-users purchasing services from cloud providers. They talk about:
ISO 27001
ISO 27017
ISO 27018
ISO 20000
Those standards are process standards as well. They do not specify which tool to use or how to use it, they instead state what needs to happen and you need to prove that it does with documentation.
Will higher standards lead to higher software costs?
The more complex the processes, the higher the software costs. If developers will spend more time doing code review they will spend less time writing code. However, on the grand scheme of things this rigorousness will increase the quality as well, and while it might slow us down to some degree, it will mean a safer world for everybody.
Will the Biden measures be enough?
A short overview of similar measures in the past.
Looking at the aviation industry, there has been clear progress since 1965 when Federal Aviation Regulation part 23 and part 25 came in effect:
Source: Aviation Safety Network
In the automobile industry we also see that following the introduction of the NCAP standards around 1995, most developed nations have experienced a decline in per capita road traffic injuries and fatalities over the past several decades. Sources: WHO
Of course, correlation does not mean causality. There are often more complex factors at play. For example both the aviation industry and the automobile industries are highly consolidated thus more likely to have the economic strength required to implement these standards and less incentive to innovate quickly.
There are also counter examples of course such as the the Boeing 737 MAX issues that show us that even with the clearest standards it is still up to the vendor to actually follow the guidelines.
Regarding Biden’s Order on Cybersecurity, we’ll have a clearer image on how effective the measures were and how the agencies involved complied with the new guidelines, a year from now, when the pilot programs will be reviewed and the Director of NIST will consult with the private sector and with relevant agencies.