Five Blind Spots That Leave You Open to Supply Chain Vulnerabilities

Software supply chain attacks have received increased attention over the past year with high-profile examples such as the SolarWinds SUNBURST attack, the Kaseya VSA (REvil) attack, or the Log4j vulnerability making headlines and impacting thousands of enterprises. It isn't that a handful of examples happen to make the news: Supply chain attacks are growing more common. Gartner predicts that by 2025, 45% of organizations worldwide will have experienced attacks on their software supply chain.

Furthermore, the sheer variety in how software supply chain attacks can be executed adds complexity to the process of risk mitigation, detection, response, and resilience against them. From intentionally introduced malware in enterprise software to accidental vulnerabilities in ubiquitous open-source code, the software supply chain is dark and full of terrors.

We'll explore five real-world examples of supply chain attacks and third-party risk introduced through the software supply chain. We'll provide advice on how to improve your security posture against these attacks. You'll learn how to:

• Improve your readiness and security hygiene to reduce the likelihood of a supply chain attack working against you
• Increase your ability to detect early indicators of a supply chain attack in progress
• Accelerate your response capabilities against both sophisticated and basic supply chain attacks
• Boost your overall ability to monitor and manage third-party risk from software vendors

What is a Software Supply Chain Attack and Why Are Businesses Uniquely Vulnerable

According to the U.S. Cybersecurity and Infrastructure Security Agency (CISA), "a software supply chain attack occurs when a cyber threat actor infiltrates a software vendor's network and employs malicious code to compromise the software before the vendor sends it to their customers. The compromised software then compromises the customer's data or system."

Your organization's software supply chain consists of all the companies you buy software from, all of the open-source repositories their developers pull code from, all the service organizations you allow into your environment, and more. All of these sources represent an enormous and difficult-to-secure cyber attack surface.

Even in cases where an attacker exploits a vulnerability in a supply-chain dependency, rather than introducing their own malicious code, the software supply chain serves as an amplifier. This enables attackers to stay stealthy while breaking into a wider range of targets, making third-party risk introduced through the software supply chain above and beyond sophisticated attacks such as SUNBURST. The overlapping blind spots inside the enterprise contribute to the enormity of this challenge for defenders.

CISA says that organizations are uniquely vulnerable to software supply chain attacks for two major reasons:

1. Many third-party software products require privileged access.
2. Third-party software products require frequent communication between the vendor's network and the vendor's software product located on customer networks.

Supply chain attacks exploit this privileged access and open communication channels between vendor and customer as an initial intrusion path. Some supply chain attacks simultaneously target many devices or workloads within target organizations at once.

As a preventive measure, most organizations conduct due-diligence security assessments of software they plan to use. This is important for weeding out basic security holes but is insufficient for catching and stopping more advanced adversaries. By monitoring network behavior, particularly inside of your environment, organizations can catch the advanced attackers that sneak through.

Enterprise Software Supply Chain Attacks: The SUNBURST Model

The Attack: The SolarWinds SUNBURST attack is the biggest supply chain attack in recent memory to exploit a major, well-established software provider. The attackers first compromised SolarWinds, then inserted malicious code into the build server for the SolarWinds Orion infrastructure monitoring and management software. From that moment, SolarWinds customers who updated their software received the malicious code. All told, 18,000 customers were potentially impacted.

Far beyond SolarWinds, the software supply chain attack surface is getting bigger. There was a 24% increase in the number of applications used by enterprises from 2016 to 2022, according to Okta, an identity and access management provider. On average, Okta reports that their large customers (over 2,000 employees) use an average of 187 applications, each of which represents a potential intrusion pathway for supply chain attackers. It must be noted here that Okta itself was the victim of a software supply chain attack that was disclosed in March, 2022.

The Blind Spot: Application Servers and Software Update Pathways
Enterprise software-based supply chain attacks are very likely to use the update mechanism as a delivery pathway. This was the case in SUNBURST as well as in the legendary NotPetya attack which abused the update servers of Ukrainian productivity software MeDocs to deliver ransomware that nearly destroyed global shipping giant Maersk.

The Solution: Behavioral Analysis of Application Servers
After a device downloads a malicious software update, it is likely to start behaving differently than normal. Sophisticated attackers may build in a period of dormancy so that defenders have a harder time attributing the new malicious behavior to the software update. If the first compromised device is a dedicated server for enterprise software such as SolarWinds Orion, then it likely has a fairly narrow range of expected behaviors, at least compared to a workstation. Any aberration would stick out like a sore thumb to a sufficiently sophisticated behavioral analysis system.

Unfortunately, dedicated servers are also less likely to be monitored effectively by endpoint detection and response agents or activity logging processes. Even devices that are being monitored may yield threat signals that are difficult to interpret without the appropriate context. Security teams and security tool developers need to develop greater understanding of the types of observable behavior that are most likely to indicate a threat.

Furthermore, watching for behavioral changes in devices that receive software updates from outside your organization can reveal other risks that may not be related to intentional supply chain attacks. Since third-party software often requires frequent communication back to the vendor and regular updates, it is vital to monitor these communications and other behavior of the app servers to detect the early signs of malicious behavior indicating a supply chain attack.

Software makers sometimes publish a software bill of materials (SBOM) to disclose components and open source packages that are present in commercial software. It would be valuable for security teams to also request disclosure of any commercial software's expected network behavior.

Open Source Software Vulnerability: The Log4Shell Model

The Vulnerability: Log4Shell (CVE-2021-44228) is a vulnerability in a widely used piece of open-source software called Log4j. The vulnerability allows attackers to gain remote code execution capabilities on any device where the Log4j library is being used by an internet-accessible server in a way that allows an attacker to transmit values to the Log4j library. For example, Minecraft used Log4j in such a way that chat messages within Minecraft servers might be ingested by Log4j, leaving a pathway open for attackers.

This open-source library may be present on any of the three billion or more devices that run Java. When the vulnerability was first disclosed, low-sophistication attackers immediately started exploiting it to install cryptocurrency miners. As time went on, more sophisticated attacks began using Log4Shell for everything from ransomware to distribution of DDOS malware.

Open-source software is also a common target for attackers to intentionally introduce malicious code. Attackers may simply submit code to open source projects and hope that it is not caught by code reviewers. They may also use a technique called "dependency confusion" to publish open-source software.

The Blind Spot: Unknown, Unmanaged Hardware and Software Components
If you have unmanaged devices or shadow IT in your environment that runs Java with the Log4j package, you may be vulnerable. Unless you have a complete inventory of all networked devices in your environment, you may be exposed. Because Log4j is such a widely used open-source component, it may be present in innumerable devices and applications. To effectively secure your organization, you need a mechanism for discovering every device in your environment, and for detecting Log4Shell activity to and from that device, indicating that it is actively under attack or already compromised.

The Solution: Real-time inventory of all software running in your environment
Most organizations conduct some level of due diligence before bringing new third-party software into their environment. Often, this involves getting a SBOM from the software vendor. In theory, this allows defenders to keep an inventory of all software running in the environment, including potentially vulnerable open source components such as Log4j.

In practice, an SBOM can go out of date quickly, or may not be supplied by the vendor at all. A continuously updated asset inventory driven by real-time visibility into the devices and workloads operating on your network gives you a better chance of discovering vulnerable or compromised devices on your network, so you can stop the attack from successfully exfiltrating or encrypting your data for ransom.

Managed Services and Software Ransomware Attack: The Kaseya VSA Model

The Attack: In the highly publicized Kaseya VSA attack of 2021, conducted by the REvil ransomware group, a remote monitoring and management software was hijacked with the intent of attacking downstream targets. Kaseya VSA software is used by managed service providers (MSPs) who remotely maintain and monitor IT systems for their own customers. By exploiting a vulnerability in Kaseya VSA, the REvil ransomware group was able to distribute ransomware two steps downstream in the IT environments of customers of MSPs using Kaseya's VSA software. The attack is thought to have impacted up to 1,500 companies.

The Blind Spot: Internet-Facing Devices, Devices Under Remote Management, and Communication Pathways with Remote Managed Service Providers
In order to employ MSPs for services such as remote IT monitoring, businesses need to give the MSP access to internal IT systems. This requires a certain level of trust and risk acceptance. No matter how much vendor assessment due diligence you do ahead of time, it is impossible to verify with 100% certainty that an MSP will not expose you to a cyberattack.

The Solution: Monitor Network Behavior of Devices and Data Flows Accessed by MSPs
Beyond the due diligence, you should also actively monitor any channels that the MSP can use to communicate in and out of your environment. Devices that an MSP has access to should have their behavior observed and analyzed, particularly if the devices have privileged access to sensitive data. This may be a challenge, as the reason that many companies onboard MSPs is that they don't have the staffing or resources to manage their own systems in house.

Organizations that cannot closely monitor the access paths of an MSP need to be aware of the risk that they are accepting by giving a third party privileged access to the network. This risk represented by MSP connections grows rapidly as advanced attackers get better at accessing and misusing these connections, and as MSP usage increases. These shifts must be taken into account in risk calculations by security teams at companies of all sizes.

Cloud Infrastructure and Malicious Insiders (IaaS, PaaS, SaaS): The Capital One Model

The Attack: An Amazon employee used insider knowledge of Amazon Web Services (AWS) vulnerabilities in specific AWS products being used by Capital One. The Amazon employee stole an estimated 100 million credit card applications containing private, personally identifiable information from the bank.

The Blind Spots: Cloud Infrastructure & User Behavior
Any business that uses a public cloud provider such as AWS, Google Cloud Platform, or Microsoft Azure is placing a great deal of trust in their cloud provider and accepting the risk that, should their cloud provider be compromised, their own data may be as well. In the case of the Capital One hack, an insider from Amazon understood both the holes in AWS, and how they could be exploited against AWS customers.

The Solution: Monitor Network Behavior in IaaS, PaaS, and SaaS Solutions
Whether a malicious insider is using legitimate credentials to steal data, or an outsider has gained access to credentials, the fact remains that behavioral analysis is the best, and often the only way to catch them.

When a legitimate service in a dynamic, growing business starts doing something malicious, it can be difficult to catch—it isn't as if an intruder has loudly broken in and started smashing things. The behaviors in such an attack may be much more subtle, but can still lead to enormous damage.

One of CISA's recommendations for defending against supply chain attacks is to develop baselines for business-critical devices and data flows, and to use AI/ML behavior analysis to detect anomalous deviations from those baselines. When a user logs in from an unusual location, at an unusual time, or accesses a data set they don't normally access, that can serve as an early warning that your enterprise is under attack.

Malicious employees are not always thought of in the context of supply chain attacks. However, if an employee of a contractor or software vendor chooses to attack you, as happened to CapitalOne, your ability to detect their behavior early could enable you to prevent them from stealing data, which averts an extended incident response and public disclosure. Behavioral monitoring of IaaS, PaaS, and SaaS systems is a vital component of a defense in depth strategy against supply chain attacks that attempt to use the cloud as an intrusion vector.

Bring Your Own Device: The Pre-loaded Malware Problem

The Attack: The move to remote work caused a spike in the use of employee personal devices for work purposes. That means more personal smartphones and laptops connecting to sensitive company resources.

Android devices have been discovered to contain pre-loaded malware straight from the manufacturer many times over the past several years. The Chinese technology company Huawei, known for producing budget Android phones, is banned from getting network equipment licenses in the U.S. due to security concerns. The same phenomenon has been observed in cheap IoT devices.

It's also true that many devices include software used to harvest information about user behavior and send it back to the parent company for use in advertising targeting. From malicious attackers to data-hungry advertisers, the software and hardware supply chain is rife with individuals and businesses looking for ways to gather monetizable data. Enterprises hoping to keep control of their own data face a growing challenge in their own technology supply chain.

The Blind Spot: BYOD and unmanaged, unsanctioned devices
One of the biggest challenges in keeping devices with pre-loaded malware out of your environment is knowing that they're there in the first place. Most organizations do not have a complete inventory of devices connected to their network, nor the software they are running.

The Solution: Network intelligence driven asset inventory
When a new supply chain attack is disclosed, the first step to secure your organization is to find out if any of the affected devices are present in your environment. This can be an incredibly difficult and drawn-out process, during which attackers can expand their access in your environment and cause real harm.

How to Reduce Your Supply Chain Risk

No matter how effective your prevention strategy may seem, it is always necessary to have steps in place to detect and respond to the presence and exploitation of vulnerable software in your environment. Some steps recommended by CISA to mitigate and stay resilient in the case of a successful exploit in your environment include:

CISA Recommendations:

• Maintain an information system component inventory
• Identify your critical data and baseline how that data flows between processes or systems.
• Deploy analytics based on artificial intelligence and machine learning to detect anomalies in data flows which may be early indicators of a threat.
• Apply basic network segmentation to isolate different parts of the enterprise.
• Monitor endpoints and/or servers for unexplained deviations from your software inventory.