In the federal software world, supply chains are often extensive. How can an agency ensure its risk assessments can adequately gauge potential threats? The Fede...
Across the government, agency IT teams continue working to figure out how best to meet the demands of an executive order from May 2021.
EO 14028 on improving cybersecurity calls for the government to enhance software supply chain security. The operating principle behind the order might be obvious, if long neglected. Namely, that software as delivered to agencies consists of many parts and components, which means knowing the origin of all the pieces is critical to assessing and managing risks and threats. Some elements have been coded by a vendor’s own staff, and some are open source.
That multiplicity of provenance is why the order calls for software bills of material (SBOMs). It also, at least in the short run, requires self-attestation by vendors about the reliability of their code and of the systems on which they developed the code. Therefore, a big challenge for federal buyers of software is visibility into their vendors’ supply chains.
“What it really comes down to is gaining situational awareness of that software supply chain, and maybe that’s sometimes easier said than done,” offered John Ehret, vice president of strategy and risk for RiskRecon, a Mastercard company.
In the security world, we have the idea of ‘trust but verify.’ When it comes to the software supply chain, we do an awful lot of trusting and not much verifying.
Vice President, Strategy and Risk, RiskRecon, a Mastercard Company
“In the security world, we have the idea of ‘trust but verify.’ I think when it comes to the software supply chain, we do an awful lot of trusting and not much verifying,” he added.
It’s a crucial issue because installing software in effect extends an agency’s perimeter to the third parties in the supply chain of the installed application, Ehret said.
“If any one of those [suppliers] is the weak link, all the money we spent and the time and effort to secure that internal network that we cared so much about is really for naught,” he said.
An SBOM is a useful tool as far as it goes, but Ehret advises also implementing third-party risk management tools and techniques used commonly in the business world and adopting them to federal software supply chains. When doing so, he said, agency practitioners must keep in mind that third-party risk assessment in the commercial world focuses on financial and operational risk. In the federal world, agencies often have the added pressure of national security.
Still, “once you know what makes up that software, the different components of it and who those suppliers are, then you can start to take a look at those companies themselves and kind of gain a sense for what their hygiene looks like,” Ehret said.
He cautioned that third-party risk organizations tend to be small and lightly resourced, and it therefore might be difficult for them to take on government software supply chains, which can be extensive.
We asked third-party risk programs if they felt that self-attestation security questionnaires were accurate in depicting the effectiveness of controls in an organization. Only 34% said yes.
Vice President, Strategy and Risk, RiskRecon, a Mastercard Company
“That’s where different tools, and not just solely relying on the humans, really comes into play,” Ehret said.
Even before deploying tools though, it’s wise to take a risk management approach to assessing and prioritizing all the elements in the agency’s supply chain, he said. That way, the security team will be able to concentrate on the most critical applications first, Ehret advised.
After that, the key is gaining visibility into the layers of secondary suppliers beyond the vendors from which the agency acquires software.
Self-attestation of security practices, as noted, is only a start, he said. Ehret cited a RiskRecon survey of clients that asked if they thought self-attestations by vendors were accurate in depicting the effectiveness of an organization’s controls.
“Only 34% said yes,” Ehret said.
So what can an agency do beyond that? He advised having a “Swiss army knife” of tools at the agency’s disposal.
For primes and subcontractors, the agency might ask for documentation of software coding practices, patch policies and disaster recovery plans. In some instances, such as cloud-provided software, the agency might be able to use a continuous monitoring tool to check its security, Ehret said.
Financial monitoring of suppliers, and of suppliers’ suppliers, can also help in mitigating risk. It’s important, Ehret explained, because financially distressed companies might cut back on their cyber or coding hygiene practices unbeknownst to developers or product users. Then, if a cyberattack occurs, they might not be able to respond to the degree needed, he said.
“Maybe that particular software supplier was kind of tenuous when it comes to their financial health,” Ehret said. “So now you must start to wonder, because of this cyber event, are they going to actually go out of business. Then suddenly, we have a hole that we can’t fill because it’s critical application?”
That’s why RiskRecon’s deep assessment approach can fill an agency’s monitoring needs several layers into a vendor supply chain, he said. RiskRecon often can identify and evaluate the potential risk of companies that agencies might not have the privileges or capability to monitor, Ehret said.
Listen to the full show:
Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.
