The SolarWinds breach was perpetrated by advanced attackers using complex and difficult-to-detect techniques. In its aftermath, organizations are searching for actions to help try and prevent another software supply chain attack, or at a minimum to detect one. While there are no silver bullets for preventing
or detecting software supply chain attacks, this piece explains some limited-, mid- and high-return strategies organizations may find useful.
Supply Chain Risk Prevention Strategies
Low-Return Supply Chain Prevention Recommendations
Scanning installation packages. An installation package, such as an MSI file, contains the files that will ultimately be unpacked and copied to the target system. Because these files are typically compressed inside the installation package,
it is unlikely anti-malware scans will successfully detect malicious code inserted in them through a supply chain attack. Additionally, it is unlikely anti-malware software would have a signature for the backdoor inserted. In both the Solarigate and
NotPetya attacks, backdoors inserted by the attackers were not detected by anti-malware software due to lack of signatures.
However, there is still some value in scanning installation packages to detect a supply chain attack. In most build environments, the compilation of software is performed separately from assembling the installer package. In addition to the installed files,
the installer package also contains setup directives that create registry keys and values, register DLLs, and a host of other functions – all of which are useful to an attacker. If attackers cannot compromise a supplier’s development environment,
but can successfully compromise the environment in which the installer package is assembled, they can backdoor the installation packages themselves. In this limited case, anti-malware software is more likely to be effective. However, this would likely
only apply if all executable files in the installation package are already digitally signed. Otherwise, the attacker may simply modify one of these files.
Scanning installed files. Scanning files after installation is more likely to be effective than scanning the installation package. However, as noted above, signatures for any inserted backdoors are unlikely to be available.
Third-party risk assessments. Third-party risk assessments are a useful tool for mitigating some types of risk. However, there are no documented cases of an organization using third-party risk assessment to successfully prevent a software
supply chain attack. The U.S. Department of Defense (DoD) has the most stringent third-party risk management program for selecting suppliers. DoD expends orders of magnitude more resources on this activity than any commercial organization IANS is
aware of. Despite this, it failed to prevent installing the backdoored SolarWinds Orion code in its own environments. While the U.S. government has published multiple advisories on the Solarigate compromise since its detection in December 2020, none have addressed lessons learned. This suggests third-party risk assessments are ill-suited to the task of detecting integrity attacks on external software (e.g., software supply
chain attacks).
Vulnerability scanning. Because the attacker is inserting a backdoor, scanning installed software for vulnerabilities is not likely to provide any value in detecting software supply chain attacks. It is prudent to conclude that any attacker
with the sophistication to insert a backdoor into the code would do so in a way that would not be detected by a vulnerability scanner.
Mid-Return Supply Chain Prevention Recommendations
Binary composition analysis. By using a tool that can scan binaries and discover their internal composition, analysts have a much easier time identifying anomalies, especially if a baseline has already been established for the software
package under review. Such tools are often implemented as decompilers. By analyzing the code, analysts can establish whether the functionality discovered is consistent with the stated purpose of the software.
Note that this method differs a bit from traditional software composition analysis (SCA), which is primarily focused on discovering open source libraries used in a program. While SCA is useful in preventing vulnerabilities due to open source software,
it is not useful for discovering software supply chain attacks. In this case, we are decompiling code to inspect it for unexpected functionality. This has a much higher overhead than traditional SCA, but offers some protection against software supply
chain attacks.
While this technique is effective, it requires substantial effort to complete. First, the analyst must find a tool that can successfully decompose the software and present it for analysis. Second, the analyst must determine whether the code present is
expected. In the Solarigate compromise, the attackers took great care to ensure their code blended into the existing DLL by matching function names, variable names and calling conventions. However, had analysts possessed a baseline of the decomposed
software before the backdoor was inserted, the backdoor would likely have been detected through this method.
The largest challenge with this activity is not technical. Most software licenses prevent reverse-engineering, usually due to intellectual property (IP) concerns. Organizations will need to work with vendors to obtain legal authorization to perform decomposition
analysis. Working with a third-party to perform the analysis may be a more attractive option for the vendor.
Zero trust networking architecture (ZTNA). While it won’t prevent an attack from occurring, ZTNA will help with the detection of most attacks. Further, when properly implemented, ZTNA will limit the damage from a successful software
supply chain attack. By adopting the ZTNA mantra of “deny all, permit by exception,” organizations limit network connections to only those expected. Assuming the backdoored software performs unexpected network connections, ZTNA will detect
these (as they are blocked). By monitoring the alerts, security personnel can detect the issue.
Maximum-Return Supply Chain Prevention Recommendations
Perhaps the only activity that offers maximum return on investment for detecting a code integrity compromise is using a scanning tool that doesn’t rely on signatures or runtime activity.
Deep Instinct is a malicious code detection and prevention tool that is based on deep learning. The power of Deep Instinct is that it detects anomalies in compiled code that appear similar to known malware or dissimilar to legitimate software. Rather
than classifying a file as safe or malicious, Deep Instinct can return a score showing that a particular file is 98 percent consistent with a given application, but 2 percent consistent with a network backdoor.
It must be stated we are unaware of anyone who was running Deep Instinct on Orion servers, so it is unknown if this would have caught the Solarigate compromise. However, Deep Instinct can detect other software packages that have been infected with malware,
even when traditional antivirus failed. While, there are some false positives with this approach, it offers a level of visibility not replicated in other products.
Takeaways for Preventing Supply Chain Attacks
Organizations have multiple options for potentially detecting a compromise to the integrity of third-party software. However, none of the methods discussed are proven to be successful in preventing another Solarigate.
- ZTNA at least offers the promise of detection when the backdoor is activated.
- Deep Instinct offers a novel approach that may be successful, although it’s unproven in this case.
- While binary decomposition analysis may prove successful, it is unlikely to be acceptable in most cases due to licensing issues.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.