weyo - Fotolia
What do the US’s new software security rules mean for UK organisations?
The White House announced recently that all software supplied to the US government and its agencies needs to be secure, so what does this mean for the UK and EU security sectors?
On 14 September 2022, the White House released Memorandum M-22-18, which requires executive departments and agencies of the US government to ensure that all companies providing them with software and services are sufficiently protected against cyber attacks.
“The Executive Order 14028, Improving the nation’s cybersecurity, was released in May 2021,” says Theresa Payton, a member of Conceal’s board of advisers and former White House chief information officer. “The newest memo from September 2022, M-22-18, ensures that federal agencies follow the National Institute for Standards and Technology (NIST) guidance resulting from EO 14028.”
The need for software supply chain security came to the forefront in December 2020, when dozens of US federal agencies were compromised after malicious code was inserted into the IT performance monitoring platform Orion. This started in September 2019, when suspected but unconfirmed nation-state actors breached the security of software development company SolarWinds.
Five months later, the attackers inserted malicious code, known as Sunburst, into Orion. The following month, Sunburst was deployed as part of the regular updates to Orion, creating a backdoor into tens of thousands of organisations and government departments, such as the Department of Homeland Security, which they were able to exploit.
The SolarWinds hack proved that even a robust security posture can be compromised by the weakest link. So, in order to protect itself against future supply chain attacks, the White House has taken the step of mandating that all providers of software to central government and federal agencies must be protected against cyber attack.
Scope and scale
As such, all developers and suppliers to the US government will need to ensure that their software architecture adheres to the NIST’s Secure Software Development Framework and Software Security in Supply Chains guidance, as well as anticipated guidance from the Cybersecurity & Infrastructure Security Agency (CISA).
Memorandum M-22-18, and the associated executive orders, will apply to new and existing companies providing software to the US government, regardless of whether the software is installed locally or through the cloud. In the case of a provider that already has a contract in place with the US government, these security requirements will come into effect once a significant update has been released for the software or service that they provide.
Because of the US government’s widescale usage of software throughout its many departments and agencies, it is expected that the executive order will apply to a significant proportion of software providers.
One potential grey area is that the memorandum states it will only apply to software used in the delivery of critical services. However, the memorandum does not define what are considered “critical services”. For example, it is not clear whether a critical service is something that relates to a government department, or only something that is critical to the overall function of the US government.
Also, it is not clear whether it applies only to software that will directly support critical services or whether it also applies to software used to support the delivery of critical services.
“It will be interesting to see where the definition of ‘critical software’ lands,” says Paul Watts, a distinguished analyst at the Information Security Forum. “The order encourages CISA and NIST to work together to agree this determination.”
Self-attestation
At the core of the memorandum is the requirement that companies will need to perform self-attestation, which means conducting a risk assessment, reviewing their security policies and taking reasonable steps to mitigate the threat of being compromised. Companies would then need to submit a self-attestation form, demonstrating that they meet the minimum necessary security requirements in order to be a software provider to the US government.
However, the exact nature of the security requirements detailed in these self-attestation forms is still to be determined. “We suspect once CISA releases their self-attestation form, there will be more questions raised,” says Curtis Yanko, principal solutions architect for GrammaTech. “We would anticipate application security testing conformance and providing a software bill of materials [SBOM] will be typical requests.”
It is currently unclear what steps would be taken if existing providers are unable to provide self-attestation, and what the repercussions there would be for their contracts with the US government.
The SBOM, an inventory of all constituent components and software dependencies involved in the development of an application, is expected to form a significant part of the required self-attestation process. “The old-school rule of having an SBOM, which includes showing an inventory of the code build, is a best practice,” says Payton. “If you want a competitive advantage, ensure your SBOMs are easily understood and ‘cross-walked’ to the requirements of the executive orders.”
Read more about supply chain security
- Securing the software supply chain, especially open source libraries, was a major theme behind the new products released at the Google Cloud Next '22 conference.
- As the prospect of federally mandated SBOM drives up usage of the software supply chain security tech, the US government's documentation so far adds to risky confusion, experts say.
- It may have hit the headlines as an IT issue, but supply chain security goes far deeper into an organisation than just technology.
The memorandum does not differentiate between foreign (UK, EU and the rest of the world) and domestic (US) suppliers – all will be expected to adhere to the same requirements. Export controls are therefore one key element that will need to be considered for any non-US-based organisations wishing to provide software. This is especially true if the software is designed for military use, or if it may be dual-use software.
Companies will need to check the relevant export control legislation before committing to themselves to self-attestation.
Another potential concern will be if the self-attestation form compels organisations to share commercially sensitive information.
“My main area of concern will be if any of the defined requirements place offshore suppliers in a position where they are obligated to overshare into a foreign state,” says Watts. “Companies may be compelled to expose levels of detail that compromise their intellectual property and/or patent rights.”
Consumer vs corporate responsibilities
Another aspect that is not yet fully covered is how companies can ensure that their software has been securely installed. All too often, it is the people who are the weakest link in a system.
Consider, for example, when people connect IoT devices to a network with the factory settings, including default passwords. There are similar pitfalls with the installation of specialist software, such as access control and network management tools. These require experienced people to carry out the installation, to ensure that security is not compromised.
This risk posed by the human aspect could be somewhat mitigated through clear instructions or rules, mandating secure installation. An example of this could be mandating password changes for restricted software, such as requiring passwords to be a minimum length, with symbols and numbers, and blocking the most common passwords. Suppliers may also offer an installation service as an additional package, thus ensuring that the software is enabled properly and securely.
“There is always the possibility of software being used or configured incorrectly by consumers, so that the security efficacy of the software is compromised,” says Watts. “I hope that the requirements make clear the responsibilities of the supplier versus the responsibilities of the consumer.”
Evolving security to meet escalating threats
As new threats emerge, it is expected that the requirements set out in the memorandum and the associated executive orders will expand and evolve to counter new vulnerabilities. It is anticipated that the requirements will be revised annually. However, there is a concern that this may not be frequent enough, given the rapid pace of emerging threats within the security sphere.
“It should be noted that self-attestation is considered ‘Doing the minimum to comply’,” says Payton. “I anticipate that, over time, self-attestation will be one of many steps to providing software to the US government.”
Given the widespread impact that Memorandum M-22-18 will have, especially with software and services that are widely used, it could pave the way for a potential Energy Star-style programme for identifying products that have a certain level of security built into them.
“I am a fan of the idea to create an Energy Star-type of labelling,” says Watts. “Given how dynamic and volatile software release cycles can be, there will need to be clear and concise reference to the exact versions of software to which the label applies, and some strength around the length of validity of such labelling.”
Memorandum M-22-18 establishes that security, meeting specific minimum requirements, will now need to be demonstrated by any company that wants to provide software or digital services to the US government.
The sharing of sensitive security details might be a hurdle for overseas providers, because care will be required to ensure that export control legislation is complied with. Likewise, companies will need to ensure they do not share commercially sensitive information.
Of course, responsible companies will already have robust security and quality procedures in place to protect themselves and their clients. In this case, it is expected that compliance would need to be demonstrated by relating the existing procedures to the requirements that will be detailed in the forthcoming guidance documents from CISA and NIST.
