Check your privilege: The critical principle for keeping your SaaS data safe

While breaches of the kind disclosed by Okta recently can never be entirely prevented, the Principle of Least Privilege (PoLP) is a simple but powerful mitigation that can dramatically reduce the severity of incidents. Yet, a robust PoLP approach can only be implemented if the tools and products we use support the required capabilities. The widely reported breach is a great opportunity to take a closer look at what SaaS products must do to keep their customers and end users safe in 2022.

Wait, what happened?

Okta experienced a breach in late January by the Lapsus$ hacker group, which went undetected for almost a week and was eventually made public on March 22. The weak link that was exploited by Lapsus$ was reportedly Sitel’s Sykes Enterprises, a third-party customer support vendor.

A laptop belonging to a Sitel support engineer was accessed by attackers, after which Lapsus$ started a Remote Desktop Protocol (RDP) session with Okta. While, according to Okta, the attackers didn’t manage to achieve an account takeover thanks to multifactor authentication (MFA), the company acknowledged that over 300 customers could have been affected and some user data was harvested by the hackers.

Unlike traditional hacking groups that exploit vulnerabilities in code or misconfigurations, Lapsus$ preferred approach is to bribe company insiders or third parties who have been granted access. With unconventional tactics like these, as well as the ever-present risk of social engineering attacks and simple human error, it isn’t feasible for any organization to be 100% secure. That’s why it’s crucial that we take measures that minimize the “blast radius” from a breach. This is exactly where the PoLP comes into play.

The Principle of Least Privilege mindset 

PoLP is a best practice that minimizes the severity of potential attacks by limiting permissions allowed for a given user to the lowest level necessary for them to do their job.

This approach ensures that even in the case an attacker gains access, this doesn’t automatically grant them god-like superuser powers to extract or manipulate users’ data at will. The capabilities that an attacker can unlock are limited according to the job requirements of the employee whose account is used. When PoLP is properly implemented, the majority of employee accounts will have strict limitations, so most breaches will result in little to no damage.

Okta stated in their post on the incident that the application the attackers gained access to was “built with least privilege in mind.” While the details on the capabilities granted to a third-party support engineer raise some questions about this assertion, the reference to PoLP is appropriate as this approach is central to mitigating these kinds of attacks.

The growing number of privileged

The Okta-Sitel relationship isn’t unusual. Digital transformation initiatives have accelerated the adoption of a large number of SaaS tools, increased the integration between platforms and have driven the outsourcing of services to external vendors. Allowing third parties access to SaaS product accounts has become very common for many companies. But due to the nature of the services provided, third-party vendors are often granted access to a large number of customer accounts. If a supporting vendor gets hacked, the impact can be huge if PoLP isn’t followed. 

Shifting your company to a PoLP mindset requires participation of the entire organization. Like all transformation efforts, this involves people, processes and tools. But SaaS products today often lack the capabilities that are required to support people and processes in adopting PoLP.

The current norm is providing minimal if any role segregation. Most apps today only have a super admin role, one that can perform any action within the product. The more advanced ones will also add a read-only role at later stages of their evolution. But this is not nearly enough to prevent one unscrupulous employee or one misplaced laptop from having devastating consequences.

As SaaS builders and consumers, we must ensure that the products we build and use support the strict PoLP enforcement that can help keep our customers’ data safe. 

SaaS product requirements for PoLP

The following PoLP fundamentals must be implemented within any modern app:

Minimal privilege for new users

The default role of a new user should have the minimal amount of permissions. This ensures that upon creation, users’ accounts adhere to PoLP automatically, without requiring any action. A new user should be created with limited read-only rights and elevated as an opt-in choice as is appropriate for the user’s position.

Granular permissions for maximum control 

Having only admin and read-only access oversimplifies things. The reality is that most users will require some level of access in the middle, which will result in everyone getting admin access. The ability to have granular control over the permissions given to users is key for the more dynamic approach of PoLP.

Temporary access for permanent security

PoLP dictates not only granting the lowest level of access, but also allowing it for the shortest possible amount of time. Promoting the use of temporary access protocols addresses the risk of forgetting to withdraw access granted to an account for a one-off need. Additionally, temporary access protocols can enable automatically granting access on a regular schedule; for example, limiting a third-party support vendor to only have access during operating hours, further minimizing damage.

Auditing activity on an ongoing basis

Products should be audited on an ongoing basis so that suspicious activity can be discovered in a timely manner. This requires that the team develop the practice of auditing and that an appropriate process be put in place, but must also be supported in the product through an easy-to-control audit log mechanism.

Frictionless UX for permission management

For a robust PoLP approach, you need to have a frictionless user experience (UX) allowing users to easily manage their roles and permissions. Revoking, changing and granting access should be easy — making these operations difficult encourages giving excess permissions to avoid needing to deal with it down the road. These capabilities should be given to clients and end users, who can then take full control over their accounts and reduce the attack surface.

RBAC: A key requirement for large organizations

In addition to the basic minimal requirements mentioned, large organizations need additional capabilities to allow permissions to be managed at scale. With thousands or tens of thousands of employees, and complex products with hundreds or thousands of individual permissions that can be granted, it’s no longer feasible to manage permissions on the individual employee level.

For companies of this size, role-based access control (RBAC) is a crucial capability in SaaS applications. RBAC allows you to define roles within a product that match functions within the organization. Each role is granted the permissions necessary for its function within the product, and users are assigned roles according to their function.

Principle of Most Secure

With the changing nature of threats and the growing attack surface driven by trends that will only strengthen over time, breaches are an inevitability. Therefore, businesses need to shift to an approach that prioritizes mitigation strategies; the Principle of Least Privilege is central to this. SaaS products today often fall short in providing the core capabilities for PoLP. As SaaS creators and consumers, we need to do better and demand better in order to keep our users’ accounts safe.

Sagi Rodin is CEO and cofounder of Frontegg.