Defense is done best in layers

Supply chain attacks are one of the trickier challenges for organizations to defend against since they undermine our trust in otherwise trusted systems that we depend on for running our software and protecting our data.

If an adversary is able to successfully compromise a key component of a popular supply chain product, the impact can be widely felt by many organizations.

So when the news broke in December that SolarWinds, a commonly used product across nearly all types of private and public organizations, had been breached, the reaction was swift and bombastic. 

This attack has highlighted our dependence on security tools, which while highly effective, may leave us exposed if they fail and are not backed up by additional layers of security. It also raises questions about how we can practice Defense at Depth to mitigate future risk. 

Details of the Breach and Methods of Compromise

According to reports, hackers succeeded in compromising the update server for SolarWinds’ Orion product that is used by tens of thousands of organizations. This allowed them to then push their malware through legitimate channels into their targets, bypassing defenses that would normally be capable of preventing such attacks.

In recent weeks, more reports have emerged indicating that they managed to breach major targets such as Microsoft, FireEye, the US Treasury Department, and many more. Interestingly, the attackers appear to have been careful to be selective about who they targeted, minimizing the potential damage that could have occurred, thus preventing another NotPetya situation that wreaked havoc back in 2017. We still do not have a full accounting of the impact of this compromise as new information continues to emerge week to week.

Reports from the US Cybersecurity and Infrastructure Security Agency (CISA) have indicated that old school methods of hacking like password spraying were used as a part of this campaign. 

However, the element that has caught most people’s attention was the compromising of the target’s server, which gave them the ability to forge Security Assertion Markup Language (SAML) tokens, helping them to bypass the otherwise strong protections offered by Multifactor Authentication. 

They also gained access to highly privileged cloud admin accounts that gave them free reign to access cloud resources unnoticed, moving laterally within their victims’ networks to cause unknown damages that likely led to data loss.

Reexamining Best Practices for Data Loss Prevention

By all accounts, this operation is already being talked about as one of the most impressive hacks in quite some time. But beyond the admiration for the adversary, it has many defenders talking about how they can stand up to advanced level operations like this in the future. 

For years, the security industry has been pushing organizations to adopt best practices like updating when new versions become available and using MFA. To be clear, organizations should absolutely continue to follow these guidelines. The odds are still significantly higher that an attacker can leverage an exploit in old software to breach a target than successfully carry out a supply chain attack of this sophistication. MFA can prevent 99.9% of breaches, so please keep using it. 

But what are the extra steps that organizations should take as part of their data loss prevention

Security needs to be designed in layers so that if one layer fails, then there are multiple mitigation mechanisms that can step in to fill the gap. We refer to this as Defense at Depth.

Take how we protect our email from being hacked as an example. The first layer of defense is the password. Ideally only by knowing the password can someone access our account. But sometimes passwords can be compromised. This can happen through a variety of brute force attacks. Perhaps that password was in use somewhere else that was compromised and then reused for your email. If that piece of information falls into the wrong hands, we need a second layer of security to protect our account. If we use MFA, then it erects a significant barrier because the attacker will now either need a code from our device.

In the case of the SolarWinds hack though, we learned that even these best practices were not enough once the attacker was past the gate.

Utilizing Behavior Analytics for Insider Threat Monitoring   

Authenticating users is important, but it is not enough to ensure security. 

A user identity can be compromised in any number of ways. In some instances the user credentials may have been stolen. In other cases, the authenticated user themself might pose an insider threat. 

This is where behavior analytics can add a layer to track user identities even after they have been authenticated and granted access to accounts and resources. We can use behavior analytics tools to track which resources an identity is attempting to access and identify if something is out of the ordinary. 

For example, if someone from R&D attempts to access customer financial information or proprietary IP that is not in their job description, it will be picked up as an anomaly and alert the security team that something unsavory might be afoot. 

The concept of continually monitoring users and reassessing their access even after they are within the perimeter defenses is at the core of the Zero Trust model that has become increasingly popular in recent years. Especially as more work is done outside the confines of the traditional office space that used to define the perimeter. 

Enforcing the Principle of Least Privilege

As noted in the description of the hack, the attackers’ compromising of the SAML tokens and their use of the servers that allowed them to grant themselves access to more valuable resources were impressive and have captured plenty of headlines. 

Given the skill in this attack, it is difficult to come down on the security team that did a lot of things right but were simply up against a really tough opponent. But there was one point where perhaps the defenders could have saved themselves some grief.

In the reports, it appears that the attackers used a cloud admin’s account that had an overly expansive set of privileges. That is unfortunate as far too often we over privilege identities beyond what they could reasonably need for their position. On the one hand it makes sense to give out more access initially so that you can avoid having to constantly go back and request more on an ad hoc basis. The downside is that it widens our threat surface and gives a malicious actor the ability to cause a lot of damage.

Instead, we want to adhere to the Principle of Least Privilege. We need to assess what is the minimal amount of access that an identity needs, and avoid granting them more than that. Similarly, we do not want to under privilege them either. Try to play it like Goldilocks — not too hot, not too cold, but just right to get the job done. 

It can be a tough balancing act to get right, but by limiting user privileges and implementing behavior analytics, as well as following best practices, we can add important layers to make our organization much harder for adversaries to crack.