Assessing Risk in the Government’s Software Supply Chain

Critical elements of a risk assessment.

In 2020, hackers found their way into the back door of an IT performance monitoring solution called Orion, made by SolarWinds. And through this breach, the 30,000 organizations that used the Orion solution became vulnerable. More than 18,000 customers ultimately installed the malware, impacting private industry as well as government agencies such as the Department of Homeland Security, Department of Commerce and Department of State.

We may never know the who, why, and full impact of the SolarWinds attack. But we do know that it raised awareness of supply chain security and prompted new requirements in the government supply chain via Executive Order (EO) 14028. The responsibility to keep the federal software supply chain secure lies with developers, suppliers, and customers alike. To ensure you’re doing your part to keep cracks out of the chain, start by conducting a risk assessment of your own vulnerabilities.

The basics of conducting a supply chain risk assessment.

The first step toward securing your supply chain includes looking at your own practices and the practices of those you do business with, then assessing your risk in relation to established best practices. It sounds simple enough, but the road toward identifying potential threats and vulnerabilities in the supply chain is greater than what meets the eye. This process should consider the entire supply chain, including all suppliers, vendors and partners. And it should also consider all potential sources of risk, including natural disasters, cyber threats, geopolitical factors, and other disruptions.

Some preliminary questions to ask:

• How many vendors (from developers to janitorial services to third-party suppliers) are we associated with? This gives you an idea of potential sources of risk.
• How strong are their physical security and cybersecurity practices? The strength of their practices will impact the strength of your own.
• Do your own cybersecurity practices measure up? See if there are best practices you are missing and what can you learn from the choices others have made.
• Have we or our vendors ever experienced a major breach? Has it been fully remedied? Do we know what caused the breach? Without strong policy and documentation, it can be hard to learn from mistakes.

Standards and practices the supply chain should adhere to.

After identifying potential threats and vulnerabilities, the next step is establishing a risk management framework that outlines the policies, procedures and controls required to mitigate these risks. Secure configuration management is essential to mitigating risk, and the government has many tools and guides to choose from in that regard. NIST 800-53, version 5 is one of these guides. It outlines mandated security and privacy controls organizations within the supply chain must adhere to.

In addition to coming into alignment with NIST 800-53, members of the supply chain also need to create and maintain a software bill of materials (SBOM), as required by EO 14028. This Executive Order outlines how government suppliers should inventory and keep the lineage of all the software components they use, including open source software. This helps evaluate the risk in a product and secure it in the system.

Determining the criticality of critical software.

As of now, the government is less concerned with securing “all software” and more concerned about securing “critical software”. “Critical software” is not defined as essential software, enterprise software or any other moniker that sounds “critical”. Rather it is the software that is most critical to secure—software that has a trusted, interactive relationship with other software in the system. This includes software that:

• Is designed to run with elevated privilege or manage privileges
• Has direct or privileged access to networking or computing resources
• Is designed to control access to data or operational technology
• Performs a function critical to trust
• Operates outside of normal trust boundaries with privileged access

So, really, the most essential question to answer is if you develop or handle critical software. If you do, you are subject to NIST 800-53 and SBOM mandates. If not, you should be tightening your risk management practices nonetheless to show customers and potential hackers that you’re committed to following cybersecurity best practices.

Supply chain security is a group effort.

On one hand, securing the software supply chain requires you to do your part as a supplier. But on the other, it requires you to work with everyone up and down the chain to present a united and secure front. This is a participation sport that needs to be continually and actively tended to.

At the heart of the challenge is configuration management, which is the part SteelCloud knows best. It’s also the part that is the most frustrating and time intensive. Learn how we automate the hard parts to make supply chain security and government compliance more manageable.