NIST’s Supply-Chain Security Guidance Tells Agencies: Look to FedRAMP First
John Fedele/Getty Images
By
Mariam Baksh
The agency has spent years revising guidance for organizations to address vulnerabilities presented by vendors of software and other enterprise suppliers.
Revised guidance issued by the National Institute of Standards and Technology—released to comply with President Joe Biden’s executive order on cybersecurity—points agencies to existing measures run by the General Services Administration’s office of Federal Risk and Authorization Management Program, or FedRAMP.
All presidential administrations going back to President Barack Obama have pushed federal agencies to make greater use of cloud service providers in order to reduce costs, and FedRAMP has been their way of checking that security isn’t sacrificed in the process. It involves third-party certification of cloud providers’ security practices and is a required step for any agency looking to purchase cloud services. However, the program is not fully enforced or monitored for compliance by the Office of Management and Budget, according to GAO.
“The external system service providers discussed in this publication include cloud service providers,” NIST’s revised guidance reads. “This publication does not replace the guidance provided with respect to federal agency assessments of cloud service providers’ security. When applying this publication to cloud service providers, federal agencies should first use Federal Risk and Authorization Program cloud services security guidelines and then apply this document for those processes and controls that are not addressed by FedRAMP.”
FedRAMP presents its own challenges, but the issue of third-party certification versus self-attestation by vendors seems to be rising to the fore and the administration may soon be issuing follow up instructions for agencies on software supply-chain security.
The guidance released Thursday is aimed at organizations buying and implementing software, and other supply-chain elements, into their environments.
“The primary audience for the revised publication is acquirers and end users of products, software and services,” NIST wrote in a press release. “The guidance helps organizations build cybersecurity supply chain risk considerations and requirements into their acquisition processes and highlights the importance of monitoring for risks. Because cybersecurity risks can arise at any point in the life cycle or any link in the supply chain, the guidance now considers potential vulnerabilities, such as the sources of code within a product, for example, or retailers that carry it.”
At a recent event flagging the document’s release, NIST’s Angela Smith said the document starts to look at those foundation elements themselves and that more such guidance—focussed less on what incorporating enterprises should be doing and more on what the supply-chain providers serving them should be doing—is on NIST’s to-do list.
NIST’s focus on the procurement process is due to the Biden administration’s approach to cybersecurity after what has become the poster child for supply-chain attacks: SolarWinds.
The perpetrators of the attack, which kicked off a storm of policymaking at the White House and in Congress, also leveraged Microsoft’s Active Directory Federation Services to move laterally across victim networks. But reports of weak security in SolarWinds development and delivery environment—use of the password ‘SolarWinds123,’ for example—raised more eyebrows about the responsibility of the government’s software vendors. SolarWinds has acknowledged use of the password as a mistake but says it was unrelated to the attackers' success.
Executive Order 14028 requires agencies to ask prospective suppliers for a Software Bill of Materials—this can be thought of as an ingredients list of code libraries that might allow buyers greater insight into any vulnerabilities that have been integrated into the products.
It also lays out specific elements of cybersecurity that should go into software development, such as properly securing build environments with tools like multifactor authentication. Those elements are covered in NIST’s Secure Software Development Framework, which NIST also released as a special publication in accordance with the executive order.
Except for the most critical systems, which should do as they see fit, NIST said agencies should err on the side of accepting the word—versus requiring artifacts that would act as evidence—of its software vendors regarding their implementation of such security measures.