SolarWinds was targeted in one of the most sophisticated supply chain attacks of all time. And we recently heard from the source about precisely what happened.
Sudhakar Ramakrishna, the CEO of SolarWinds, headlined the keynote lineup at the annual RSA Conference, discussing in the greatest detail to date how attackers were able to compromise the update process of a widely used piece of SolarWinds software. Learning how one of the world’s largest software suppliers fell victim will go a long way in preventing a similar attack.
Supply chain attacks have grown especially pernicious in recent years as the accelerated rate of digitization, cloud adoption and high-profile cyber-threats have created new opportunities around existing vulnerabilities.
One of the major challenges in managing supply chain attacks is that they start from the trusted assets in your enterprise environment. These include third-party vendors and products, open-source components or contractors/subcontractors.
Enterprise teams have no visibility into the software development lifecycle of these supply chain attack vectors. The integrity (digital signature) of the third-party or open-source product cannot ensure security or whether the vendor used secure development practices.
As well as the insight we recently gained from SolarWinds, there are steps you can take right now to protect against the majority of supply chain attacks. Doing so will help avoid breaches and better enable you to pursue digital business without disruption, giving you more room to grow and compete.
Start by Demanding More from Third-Party Vendors
You can probably count many third-party vendors in your IT environment vital in storing, securing and analyzing your data. Most times, however, companies only assess the security of these third-party products when they’re onboarded. There’s no continuous security analysis or assessment.
There’s little help elsewhere, as most security standards set for internal applications are not applied to third-party vendor applications. You have to wait for third-party vendors to offer patches or automatic updates. This is practically an invitation for trouble.
The only solution is to take matters into your own hands. Demand a monthly security risk assessment report from all third-party vendors to glean details on all known issues in their product and infrastructure. When it’s time for a major code change or software update for third-party vendors, consistently use DevSecOps – especially when it comes to production and operational security.
Open-Source Vulnerabilities Are the Weakest Link
Open-source components offer more challenging scenarios. The security practitioner knows that fixing all the open-source vulnerabilities from applications, containers or operating systems is just not possible.
While more than 90% of vulnerabilities are not exploitable in runtime (often due to reachability from an external network or a lack of system-level access), those that can be exploited are not easy to detect and are isolated from the vast number of open source vulnerabilities in your production environment.
According to the 2020 Verizon data breach report, the majority of data breaches come through chained attack paths, which can involve combinations of two to 30 attack paths. Many medium and low security-rated vulnerabilities can become severe and dangerous when combined with medium and high-severity issues.
Worse, new attacks take advantage of how companies use open-source code. Security researcher Alex Birsan was able to hack into Apple, Microsoft and dozens of other major companies via a novel supply chain attack — the dependency confusion technique. This method exploits application dependencies using public code libraries. By uploading code libraries with the same name and higher version numbers, Birsan got dozens of major companies to download, incorporate and execute his code automatically.
As Sonatype explained, this dependency confusion is a design flaw in native installation tools that makes it impossible for an organization’s development environment to tell the difference between a private, internally created package in its software build, and a similarly named package in a public software repository.
This highlights the importance of configuring your tools to pull from private repositories over public ones. It also shows the need for open-source repositories to verify who contributes, especially when they’re doing so under established names. In addition, it’s up to DevSecOps to demand an open-source binary composition tool that enables them to better assess vulnerabilities exposed in runtime.
We didn’t have to be at the RSA Conference to know one of the big takeaways from SolarWinds is more involvement between our IT and security teams in trying to level set and answer the question: “What risk are we taking on these Network Management Systems?”
With disciplined attention, supply chain vulnerabilities don’t have to put your organization on the hot seat.