SolarWinds Attack Reinforces Importance of Principle of Least Privilege

The SolarWinds attack is historic for its multidimensional sophistication. As we continue to learn of new victims, techniques, and implications, it's important that chief information security officers (CISOs) and security professionals take stock of their defense-in-depth strategies. One critical element of the approach is the principle of least privilege (POLP). Based on what we've learned from the SolarWinds attack so far, there are a few valuable lessons to unpack.

Before we do so, here's a quick POLP primer. Implementing least privilege is one of the 33 IT security principles outlined by NIST, which it defines as:

"The concept of limiting access, or 'least privilege,' is simply to provide no more authorizations than necessary to perform required functions. This is perhaps most often applied in the administration of the system. … Best practice suggests it is better to have several administrators with limited access to security resources rather than one person with 'super user' permissions."

In an activity alert published Dec. 17, the Department of Homeland Security's Cybersecurity & Infrastructure Security Agency described how the advanced persistent threat (APT) behind the SolarWinds attack used forged "authentication tokens and credentials to highly privileged Active Directory domain accounts as a persistence and escalation mechanism." In essence, this allows the actor to gain access to administrative accounts and add their own credentials to existing service principals for elevated access to applications and data across the organization.

Based on this knowledge, here are three important lessons about how to think about and follow the principle of least privilege.

1. Work Toward Zero-Trust Maturity
Zero trust is based on the premise that no one has standing privilege, not even administrators. For it to work, users or applications submit access requests that are evaluated based on all the attributes associated with that user or application, including role, position, duties, usage behaviors, and more. To assess risk, the security system either auto-grants access or flags the risk for further review with the full spectrum of identity determining access.

Two pillars of zero trust are time-limited access and just-enough access. When a user or application's identity is evaluated, a decision is made about what access is granted and how long it will persist.

The SolarWinds APT took advantage of standing administrative privileges once it established a foothold on the network to gain administrator access. Reducing the number of users with highly privileged directory roles to zero is a good place to start.

Moving toward a zero-trust model demands a shift in the mindset of an organization's security architect. At its core, identity must be the new security perimeter. All identities — including and beyond human users — must be addressed. There must also be a recognition that zero standing privilege is the path to a real zero-trust model.

Zero standing privilege in and of itself is not zero trust. Instead, it's the application of the principles of zero trust to privileged access management. Zero standing privilege eliminates the abstract concept of an administrative account that has permanent access to privileged data. Access rights get determined on an as-needed basis, so no identity has a default access level. This forces privileged access to be requested, evaluated, granted, or denied — then logged and monitored.

2. Consider Humans and Machines
Limiting access within an infrastructure should take humans and non-humans alike into consideration. The SolarWinds attack shined a light on one specific type of non-human identity: service accounts. Ex-NSA hacker Jake Williams astutely shared the view that, in light of the attack, every organization should look to change its service account passwords. He also said most "don't do this regularly (or ever) because it's hard."

Machine identities also include cloud resources, which is important given that evidence has shown that the threat actors sought access to cloud resources. The Capital One hack suggests why this is so critical. In that case, the hacker was able to exfiltrate the personal information of 100 million consumers because she took advantage of an over-permissioned machine identity role in the form of an EC2 instance. Once the credentials were compromised, so were all the privileges assigned to it.

Similarly, the SolarWinds Orion software is used by many customers for monitoring Azure and AWS environments, which require administrator-level permissions to be used when configuring access to cloud resources. That's why it's so important to implement least-privilege policies for all identities, but especially for machine identities.

3. Apply POLP in Product Design and Development
When thinking about where to apply the principle of least privilege, DevOps should be high on the priority list. The SolarWinds attack started with a compromised software build process that allowed the APT to insert malicious code into an Orion software update. Given the imperative for software development and release speed, many organizations provide access to accounts along the DevOps toolchain that are overprovisioned from a privileges standpoint.

It's critical to provide just enough privileges so that the DevOps process works, but not so much that the entire process can be compromised. This also requires factoring in role-based access into the design and control of operations at a granular level and ensuring that default roles packaged with the software also follow the POLP.

Take Stock of Your POLP
As one of the most sophisticated and far-reaching attacks of the last decade, the SolarWinds campaign requires every security organization to review and refine its defense-in-depth strategy.

The principle of least privilege is one key layer of this strategy, but it will not completely mitigate the risk of such a sophisticated attack. Users that truly need privileged access to infrastructure or software build tools can be targeted directly — for example, through spear-phishing. But given what we've learned about the SolarWinds-related attacks so far, taking stock of least-privilege policies will go a long way toward hardening an organization's posture.