A Zero trust least privilege model could have potentially prevented one of the largest-scale cyber security attacks of all time. It sounds like something out of a Mission Impossible movie script. Imagine that a state sponsored hacking organization devises a plan to infiltrate a software company. It’s not just any software company, however. It’s a company that provides software to more than 300,000 customers worldwide. Its customer list includes all five branches of the U.S. military. It includes the NSA, the IRS, the U.S. Postal Service, and the Department of Homeland Security. It includes all of the top 10 telecommunication companies as well as nearly every single company listed in the Fortune 500. In other words, by establishing a backdoor into a single software vendor, a malicious party leverages a single breach to invade the supply chains of this illustrious target list.

That hypothetical plan alone would make heck of a movie plot. But now consider the fact that this list of high value targets uses the company’s software to manage their own networks. That’s right. The same software that is being used to infiltrate these targets, is used by the victimized organizations themselves to monitor, diagnose, and resolve network performance problems and outages.

That would make a stupendous plot. Except it wasn’t fictitious—it really happened. And the consequences of this highly leveraged, devastating attack will probably not be known for years.

The Latest Updated Government Directive

On April 15, 2021, the Department of Homeland Security (DHS) issued an update to its emergency directive concerning the SolarWinds Orion code compromise. Of its 300,000+ customers, some 33,000 used its Orion software. It is estimated that 18,000 of them were compromised. According to DHS, the SolarWinds Orion products have been, and currently are being, exploited by malicious actors who are believed to be directed by a state sponsored intelligence service. The directive calls for the disconnection of any affected device as the potential impact of this compromise is considered grave. The SolarWinds attack is more than a tragic example of the ultimate leveraging of a cyberattack, it is an issue of national security.

How Could This Have Happened?

As all of these government agencies and Fortune 500 companies scramble to determine if their enterprises now contain backdoors into their systems, the predominant question remains: how could his have happened? Unfortunately, it is one of the oldest stories told in the brief history of cybersecurity. It happened because of two primary reasons:

• failure to adhere to the principle of zero trust least privilege
• flagrant inattention to the vulnerability of allotting blanket admin rights

The fact is that network admins from some of the most prestigious firms and critical government agencies failed to confine administrative access to their Orion server. It is believed that some even used the default Windows administrative account to administer their Orion server. Many gave needless Internet access to it or allotted it privileged access and abilities to do things such as delegate tokens on domain controllers. The local Orion server along with its services and accounts were granted blanket rights that they didn’t need. Why? There are two reasons: it was trusted and it simplified administration.

Trust Nothing on Your Network; Implement Zero trust least privilege

If the SolarWinds attack teaches us anything it should be this: trust nothing on your network and implement zero trust least privilege. Nearly everyone across the board trusted the SolarWinds code. Why wouldn’t they? After all, its code updates were digitally signed by SolarWinds. Its code was allowed through by firewalls and antivirus applications. The IT industry emphatically trusted any and all code released by SolarWinds. Yet, it was reported back in late 2019 that this same company used the password “solarwinds123”  for their update server. That’s why perhaps no one should be trusted.

It is time for enterprises to incorporate the concept of zero trust least privilege throughout their architectures. Zero-trust is a security concept that is based on the principle that nothing should be automatically trusted inside or outside of the company’s perimeters. Instead, everything must be verified before access is granted. This approach is also referred to as the “always breached” model, in which enterprises should always assume that their networks contain active hostile threats. As a result, IT admins need to minimize the access of all accounts on a per host basis across their entire IT estate. This includes absolving the practice of allocating local admin rights to standard users on their desktop machines.

How PolicyPak Can Help with Zero trust least privilege

While PolicyPak may not have protected you from the SolarWinds attack itself, it can protect your desktops from threats originating from both untrusted and trusted code sources. Every day, users on your network download code that they trust (but that they shouldn’t necessarily trust). Think of this downloaded code as mini adaptations of the SolarWinds scenario. If your users have local admin rights, then the code they download inherits those same rights and privileges as well. Then, just as the state sponsored agency leveraged the SolarWinds compromise to infiltrate thousands of other organizations, attackers can leverage that single desktop to access thousands of other desktops, nodes, and digital assets scattered throughout your enterprise architecture. That’s how it happens, every day.

But it doesn’t have to. With PolicyPak Least Privilege Security Pak you can stop distributing local admin rights to the masses once and for all. You can also ensure that users can only run the software code that YOU trust. Traditionally, the only way to block unwanted software was through the use of allow lists which are burdensome to maintain over time. With PolicyPak, allow lists are completely automated with SecureRun^TM, one of the included features with PolicyPak Least Privilege Security Manager. The premise behind SecureRun^TM is simple. If an application wasn’t installed by an administrator or someone on the SecureRun^TM member list, it will not run. When users download files off the Internet or copy them from a USB drive, they own the file, as seen in the example below, making it easy to prevent these specific files from running.

In other words, any file, script, MSI, or application that wasn’t installed, downloaded, or created by anyone on the SecureRun^TM member list, will not run. To create a SecureRun^TM policy, use PolicyPak Least Privilege Manager. Below is the default SecureRun^TM membership list. You can add or delete members according to your individual security needs. Typically, the PolicyPak SecureRun^TM defaults are sufficient for most organizations’ needs.

A SecureRun^TM policy is created using the file ownership condition. Now, whenever a user attempts to open an executable or application that wasn’t installed by an authorized admin, they see the blocked message shown below.

You can watch this video demonstration on our website to learn how to stop ransomware and other types of zero day attacks using PolicyPak SecureRun^TM.

Now let’s talk about local admin rights. With PolicyPak Least Privilege Security Pak, you can both simplify administration and abolish the risky practice of doling out local admin to standard users. Let’s say a standard user needs access to Device Manager. Like SecureRun^TM, Security Pak requires the one-time creation of a policy, and because PolicyPak editors are built inside the Group Policy Management Editor, admins are already familiar with its policy creation process, as shown below.

Next, choose the applet that you want to run with elevated privileges (see image below). The result is that standard users will gain uninhibited access to any Control Panel applet you choose.

Of course, this is only one example of the many granular admin rights you can assign to standard users. Some of the others include the following:

• Click here to see a video demonstration of this capability
• Overcome network card, printer, and add/remove programs UAC prompts (Click here to see a video demonstration of this capability.)
• Perform approval for elevation over the phone (Click here to see a video demonstration.)
• enable online and offline users to overcome UAC prompts

Minimal Privilege Is the Answer

In many ways, the SolarWinds attack has forced companies to recognize the need for the strategies that security practitioners have been expounding for years. Network segmentation and minimal privileges for all accounts is the best practice that must be implemented. At PolicyPak, we didn’t create these best practices, we just made them easier to implement and deploy.