National security pundits have been reeling since FireEye discovered that SolarWinds, a popular IT network monitoring tool, had been compromised. The scope of the hack is still unknown, but it’s clear that it has impacted all corners of the public and private sectors, including up to 18,000 of SolarWinds’s 300,000 customers.
As cybersecurity professionals sift through the damage, the most critically important topic is the nature of the hack, which has affected the software supply chains of an almost unbelievable number of federal organizations and large enterprises. Instead of targeting thousands of companies individually, cybercriminals injected malware into a SolarWinds software update. This then impacted the customers that rely on SolarWinds as part of their tech stack.
In this blog, we’ll explore some important takeaways from the SolarWinds hack, with a focus on how to prevent a similar software supply chain attack in your environment. We’ll also discuss the role of software composition analysis (SCA) in strengthening software supply chain security.
But before we tackle these issues, let’s recap the SolarWinds hack and the potentially devastating consequences the companies and government agencies that have been infiltrated may suffer.
SolarWinds Orion Hack Compromises Up To 18,000 Companies
Around 300,000 customers have used SolarWinds security software to monitor and protect their networks.
A couple of weeks ago, the news that SolarWinds’ Orion platform had been compromised hit the headlines. The attackers changed a dynamic link library (DLL) to include a remote access trojan (RAT) — FireEye is calling it SUNBURST) — and the update server was compromised so this DLL would be automatically pushed to customers who requested an update.
An estimated 18,000 customers received the compromised file.
Government agencies were targeted, including the U.S. Treasury and Commerce departments, the Department of Homeland Security, and the State Department. The reach was significant enough for the Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA) to release an emergency directive ordering all federal agencies to disconnect the affected Orion products from their networks.
This attack was very sophisticated; the attackers had a way to bypass multi-factor authentication (MFA) through Cisco’s Duo access security solution. It’s believed a nation-state is behind these attacks.
This attack brings to light a growing concern within the security community.
Threats Within the Software Supply Chain
Companies are becoming more dependent on software every day. And even software vendors themselves have a supply chain. It’s along the lines of how an auto manufacturer might build a car: one vendor builds the engine, while another builds the electronic components.
Internet of Things (IoT) companies could be getting processors from Qualcomm and software from another company (or from open source). Most software today is comprised of many, many components, each representing a different possible avenue of attack.
According to WhatIs.com:
“A supply chain is the network of all the individuals, organizations, resources, activities, and technology involved in the creation and sale of a product.”
In terms of software, it’s the network of all software components your organization uses to build its software product.
Common types of software supply chain attacks include:
- Cybercriminals injecting malicious code into third-party libraries that companies use to build applications
- Cybercriminals compromising a legitimate and trusted application that organizations use as part of their tech stacks
- Cybercriminals successfully targeting software updates or update servers, which would then compromise the end-user; SolarWinds is a worst-case example of this
The SolarWinds hack demonstrates what happens when malicious actors gain a foothold within the company network of your suppliers. The attackers were able to change the code making up one of the DLLs packaged with the software. It went through the build process and was signed with a legitimate certificate.
Two examples of how software supply chain attacks lead to breaches are the Ticketmaster and British Airways attacks in 2018. Attackers were able to inject a compromised version of the Modernizr JavaScript library, often used to allow new JavaScript features to be used on older web browsers. The British Airways attack, in particular, used this altered script to listen for events and grab credit card details whenever a credit card was entered. This attack affected both the website and mobile applications.
Attacks on open source dependencies are increasing. Attackers know it’s practical to infect upstream projects so they can exploit the large number of downstream users.
Clearly, we need to be extra careful when inviting software into our networks. But it appears that did not happen in the months leading up to the SolarWinds hack. The company published a support advisory recommending that customers exempt its product’s working directories from antivirus and group policy object restrictions. Otherwise, SolarWinds’s software may not work. So SolarWinds may have helped the attackers remain undetected as a result of its advice.
When software we use is embedded deep within our systems, and we give it complete control of our secrets and sensitive information, compromises can easily reach the level of catastrophe that we fear may be at hand as a result of this hack.
Mitigating Open Source Security Risks
There are several techniques and tools you can use to give yourself some peace of mind. However, this is an evolving landscape and problem, and the solutions will have to keep up.
An important step is to vet all of the open source software coming into your applications. Developers likely want to have free reign to use any open source libraries they deem to be useful. They are focused on achieving functionality as efficiently as possible.
However, allowing developers to bring any open source libraries into your environment without vetting them is a recipe for disaster. You don’t have to create a massive bureaucratic process around open source, but make sure that there are defined procedures that govern its use.
Step one is to justify the need for the library in the first place. What does the library do? Why do we need it? Do we already have a library in our repository that performs the same function (a common occurrence in large enterprises)?
Once you’ve established the need, make sure that the library is the best choice to fit that need. Does it work well with your development platforms? Is it updated regularly? Is it backed and maintained by a company, such as Mozilla or Google?
Consider using a software composition analysis tool to scan your code and look for all the third-party libraries included within the project. SCA tools inventory the open source software within your applications and identify known vulnerabilities, outdated libraries, and license gaps. They then help you fix any issues.
The point of this process is to reduce risk. Companies often require background checks on prospective employees before hiring them. Some jobs, such as those that work with children, require further checks and clearances before bringing someone on board.
Similarly, perform “background checks” on the open source libraries you use. If possible, stick to well-known and vetted libraries backed by companies who have a vested interest in keeping the libraries safe. For example, think about selecting an established library instead of “Joe Hacker’s Container Operating System” that you found on GitHub.
What About Proprietary Code and Vendor-Supplied Applications?
Software composition analysis can help you keep your supply chain safe. It inventories and scans open source code to look for security vulnerabilities and licensing issues.
But SCA is only one piece of the puzzle in preventing software supply chain attacks. (For example, it wouldn’t have protected a SolarWinds user from being compromised.) A different strategy is required for proprietary code elements and applications. Vendors typically don’t make their proprietary source code available (instead, they ship it in binaries), which means you won’t be able to use an SCA tool to scan it.
So it’s important that you take extra precautions to vet your software vendors. Maintain focus on reducing risk. Is the company well-known and trusted in the security community? Do they update their software regularly? Do they periodically check for tampering within their system? These best practices can also help you safeguard against some of the other attack vectors for supply chain threats.
Encourage your vendors to scan their open source code and provide you with a report of the results. At least you’ll know that they’re serious about keeping their customers safe from supply chain tampering.
Create a list of red flags and limits to what you’ll tolerate. Stick to it. Find vendors that match your criteria for reliability and risk reduction. For example, you could require your vendors to be SOC 2 compliant. FOSSA recently passed our SOC 2 audit, which is evidence of our commitment to upholding the highest security standards.
Even if something happens, you’ll know you did everything you could to protect yourself and that your vendors likely have plans for quick remediation and accountability.
Software Supply Chains: A New Security Frontier
Software supply chains are not new. But attacks like the one against SolarWinds certainly bring them into focus. As reliance on third-party software increases, so too must the rigor with which we test potential vendors and develop and apply standards.
SCA tools are an essential piece of the supply chain security puzzle in that they help users identify and address vulnerabilities in open source software components. They have emerged as a vital part of today’s modern security tech stacks. But we can’t ever entirely rely on software solutions alone to thwart advanced cyber threats. We must also have the right policies and processes in place to help prevent compromise.
