How Do You Protect Against Supply Chain Attacks? Assume You're Breached

The recent news of the SolarWinds and FireEye breaches has left some IT managers wondering how they can better protect against supply chain attacks. The short answer is to assume you're already breached and use a defense-in-depth strategy to limit your exposure to an attack. (Also referred to as a Zero Trust strategy.) Before we dive into explaining those buzzwords, let's take a brief look at the recent Supply Chain Attack against SolarWinds.

What is a Supply Chain Attack?

A Supply Chain Attack occurs when one of your trusted vendors is compromised, and that vendor has access to your environment, either directly (user account) or via a service they provide (software). This is similar to the Target breach several years ago where a refrigeration contractor was compromised and the attacker was able to move laterally into Target's server network. Except the Solarigate attack is on a massive scale and has likely breached every regulatory compliance framework on the planet.

Many compliance frameworks require you to make sure that your vendors follow similar regulatory compliance policies too. While this is important for things like limiting legal liability and purchasing cybersecurity insurance, it's important to remember that compliance does not equal security.

Just because your vendor is SOC2 / SOC3 / ISO27001 compliant, it does not mean that they are requiring MFA to sign on to a machine that has access to their codebase. Your vendors may be using a SIEM product to aggregate threat logs, but if those alerts aren't being reviewed by qualified cybersecurity professionals, then the tool is useless. PCI-DSS requires anti-virus, but it doesn't require next-gen AV that can detect fileless attacks or monitor for UEBA anomalies.

When there is a supply chain incident on a vehicle, there is a recall issued by the manufacturer and you have to bring the car to the dealer to repair it. But imagine that you live in a mansion, and a serial killer had total access to the building for months--could you ever feel safe in that house without burning it down and building a new one? How confident are you that you can locate every backdoor and trap?

What is SolarWinds Orion?

SolarWinds Orion is (was?) an enterprise-grade network monitoring tool. You can use it to monitor network traffic or backup all of your network configurations for a quick restore if a network appliance fails. OR an attacker can use it to restore malicious code to all of your networking appliances.

If you are using SNMP v3 with Read/Write permissions or any form of SNMP v2 with your network monitoring tool, an attacker can exploit your entire network once they have access to your monitoring tools.

This isn't limited to just SolarWinds. Many MSPs use similar tools, such as PRTG, Auvik, Connectwise, or Datto to monitor client systems and client health. Can you imagine if Cisco Meraki was compromised and malicious firmware was automatically deployed to hundreds of thousands of cloud-connected devices? If any of these platforms were breached by nation-state attackers, it would have been just as effective at compromising thousands of networks.

Modern cybersecurity practices demand a zero trust model where you assume every device and identity is compromised until proven otherwise.

Why is Solarigate / SUNBURST so dangerous?

The extent of the Solarigate attack is still being investigated and refers to the supply chain attack on the SolarWinds Orion platform. By inserting a few lines of malicious code into the SolarWinds.Orion.Core.BusinessLayer.dll the attacker was able to use that "trusted" file to deploy nearly 4,000 lines of code as a backdoor onto over 18,000 networks. These networks include government agencies, the US Nuclear arsenal, energy providers, and many of the largest Internet Service Providers (ISP).

When the USA and Israel launched the Stuxnet attack on Iran in 2010, the two countries were able to cripple the Iranian Nuclear program and cause physical damage to centrifuges and other SCADA devices. With the Solarigate attack, it's alarming to think of the extent of damage that Russia could inflict on the USA.

The Solarigate attack chain is illustrated below.

The best summary I've read of the SolarWinds attack can be found here, written by the Microsoft 365 Defender Research Team: Analyzing Solorigate, the compromised DLL file that started a sophisticated cyberattack, and how Microsoft Defender helps protect customers - Microsoft Security

You can also use these links for remediation guidance and threat hunting queries with Azure Sentinel.

Using a Zero Trust Approach to Protect Against Supply Chain Attacks

Using a Zero Trust Framework will limit your exposure post-breach. When you are compromised, the Zero Trust model should limit exposure to a user's role, device, or access tier, and will block lateral traversal if you are using Virtualization Based Security. (One of many reasons macOS devices should be limited to Tier 2 resources only.)

Making sure you select security products that support continuous evaluation during a user session is also important. If you grant a 30-day authentication token that is only evaluated for risks at the initial time of authentication, you're exposing your environment to unnecessary risk. With many applications moving to a SaaS model, having a Cloud App Security Broker that supports session control policies via a reverse proxy is sacrosanct.

Assumed Breach

An assumed breach mentality simply means to expect that your network or identity perimeter will fail at some point. Even if you have MFA enabled, and 802.1x certificate authentication on your devices, assume that a SIM swap attack will happen or your root CA will get stolen. In the Solarigate attack, an on-premises Exchange server was compromised so that an MFA challenge could be spoofed in the token, completely bypassing what has long been considered an effective defense mechanism. (Exchange Online would have been several magnitudes more difficult to compromise, as Microsoft has already confirmed that the Solarigate attacks on their network did not result in a supply chain attack.)

Once your perimeter is breached, what is your next line of defense? Which leads us to...

Defense-in-Depth

A Defense-in-Depth approach to security uses multiple layers of protection to limit the impact of breaches. A potential attack chain would look like:

1. The Identity being protected by MFA, but if that is bypassed then...
2. The Device must be corporate-owned, but if an attacker has access to the machine...
3. Data Loss Prevention policies will block the data from leaving the corporate sandbox, but if it doesn't...
4. File-level encryption will make the data inaccessible outside of the organization.

The idea is that any one of those compromises will probably happen at some point, but the likelihood of all of them happening is drastically lower.

Honeytokens

A honeytoken is a type of honeypot that can be used by Intrusion Detection Systems to detect abuse. It is typically a privileged account that remains dormant, waiting for an attacker to attempt to access it. When an attacker attempts to access the honeytoken account, it will trigger an alert in your IDS system, indicating that your environment has been breached.

Least Privileged Access and Access Tiers

By using Roles Based Access Control (RBAC) and Privileged Identity Management (PIM), you limit the amount of lateral movement an attacker can traverse. In plain English: your privileged developer accounts (Tier 1) should not be able to access your networking or authentication infrastructure (Tier 0). By segmenting your infrastructure into access tiers, you block attackers from moving beyond their current Access Tier.

Bring Your Own Key / Hold Your Own Key (BYOK / HYOK)

As a CISO, I have a tendency to favor security over productivity. However, I typically avoid recommending Bring Your Own Key / Hold Your Own Key scenarios due to the complexity it adds in managing your security stack, and the limitations it introduces in collaborating with partner organizations. BYOK / HYOK allows you to use your own private key certificate with cloud services. That way, even if a cloud vendor is compromised, your data is still encrypted and can't be read without access to your on-premises Hardware Service Module (HSM) such as a Thales HSM.

Again, I would only suggest using BYOK/HYOK for sensitive information that is not shared outside of your organization. For instance, Controlled Unclassified Information (CUI) or Impact Level 4/5 data.

Limit Post Breach Damage by Protecting Against Supply Chain Attacks

Despite the scale of the Solarigate attack, don't let it discourage you into thinking there is no way to protect against these types of attacks. By taking the time to create monitoring accounts that don't have read/write privileges and making sure that your data is encrypted, even if it's on a "trusted" network, would have limited the exposure for many organizations.

Incident response is just as important as incident prevention. While the federal government is eroding trust in their response by providing inconsistent messaging about the origin of the attackers (it was Russia), the transparency from SolarWinds and FireEye has served as a master class in transparency and disclosing breaches quickly. Security Operations Centers have been working 24x7 to quickly isolate and remove any advanced persistent threats on their networks. And if you've read this far, you'll likely be making proposals to your board on how to protect against supply chain attacks in the future.

The traditional network perimeter is dead. Now you just need to get your board to sign off on approving the budget for deploying a Zero Trust framework.