Verify Your Eligibility: The Critical Principle for Keeping Your SaaS Data Secure

While breaches like those recently uncovered by Okta can never be completely prevented, the principle of least privilege (PoLP) is a simple but powerful countermeasure that can drastically reduce the severity of incidents. However, 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 need to do to protect their customers and end users in 2022.

wait what happened

Okta experienced an attack by the hacking group Lapsus$ in late January, which went undetected for almost a week and was finally released on March 22nd. The vulnerability exploited by Lapsus$ was allegedly Sitels Sykes Enterprises, a third-party customer support provider.

A Sitel support engineer’s laptop was accessed by attackers, prompting Lapsus$ to launch a Remote Desktop Protocol (RDP) session with Okta. While the attackers were unable to achieve account takeover thanks to multi-factor authentication (MFA), according to Okta, the company acknowledged that over 300 customers could be affected and some user data was harvested by the hackers.

Unlike traditional hacking groups that exploit code vulnerabilities or misconfigurations, Lapsus$’s preferred approach is to bribe company insiders or third parties who have been granted access. With unconventional tactics like these, plus the ever-present risk of social engineering attacks and simple human error, it’s impossible for any organization to be 100% secure. Therefore, it is critical that we take steps to minimize the ‘blast radius’ of an injury. This is exactly where the PoLP comes in.

The principle of least privilege

PoLP is a proven technique that minimizes the severity of potential attacks by restricting a given user’s privileges to the lowest level required to perform their tasks.

This approach ensures that even if an attacker gains access, they won’t automatically be granted godlike superuser power to extract or manipulate user data at will. The opportunities an attacker can unlock are limited according to the professional needs of the employee whose account is being used. If PoLP is properly implemented, the majority of employee accounts will be severely restricted, so most breaches will cause little to no harm.

In her post on the incident, Okta explained that the application the attackers gained access to was “built with the least privilege in mind.” While the details of the capabilities granted to a third-party support engineer raise some questions about this claim, the reference to PoLP is appropriate as this approach is central to mitigating this type of attack.

The growing number of the privileged

The Okta-Sitel relationship is not uncommon. Digital transformation initiatives have accelerated the adoption of a large number of SaaS tools, improved integration between platforms, and driven the outsourcing of services to external providers. Granting third party access to SaaS product accounts is a common practice for many companies. However, due to the nature of the services provided, third parties often gain access to a large number of customer accounts. If a supporting provider is hacked, the impact can be huge if PoLP is not followed.

Shifting your organization to a PoLP mindset requires the involvement of the entire organization. As with all transformation efforts, there are people, processes and tools involved. But today’s SaaS products often lack the capabilities needed to support people and processes in adopting PoLP.

The current standard provides for minimal, if any, role separation. Most apps today only have a super admin role that can perform all actions within the product. The advanced ones will also add a read-only role in later stages of their development. However, this is far from enough to prevent an unscrupulous employee or a misplaced laptop from wreaking havoc.

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

SaaS product requirements for PoLP

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

Minimum permission for new users

A new user’s default role should have the minimum set of permissions. This ensures that user accounts automatically adhere to PoLP upon creation, with no action required. A new user should be created with limited read-only rights and elevated as an opt-in option according to the user’s position.

Granular permissions for maximum control

Only having admin and read access simplifies things too much. The reality is that most users need some level of access in the middle, resulting in everyone gaining admin access. The ability to finely control the permissions granted to users is key to PoLP’s more dynamic approach.

Temporary access for permanent security

PoLP dictates not only granting the lowest level of access, but allowing it for the shortest amount of time possible. Encouraging the use of temporary access logs addresses the risk of forgetting to revoke access granted to an account for a one-off need. In addition, temporary access logs can allow access to be automatically granted on a regular schedule; B. Restricting an external support provider to access only during business hours, further minimizing damage.

Ongoing revision activity

Products should be checked on an ongoing basis so that suspicious activity can be detected in good time. This requires the team to develop auditing practices and put in place an appropriate process, but also supported in product by an easily controlled audit log mechanism.

Frictionless UX for permissions management

For a robust PoLP approach, you need a frictionless user experience (UX) that allows users to easily manage their roles and permissions. Revoking, changing, and granting access should be easy – making these operations harder encourages over-granting permissions to avoid having to deal with them later. These features should be made available to customers and end users who can then take full control of their accounts and reduce the attack surface.

RBAC: A key requirement for large organizations

In addition to the basic minimum requirements mentioned, large organizations need additional features to enable the management of permissions 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 is no longer possible to manage permissions at the individual employee level.

For organizations of this size, role-based access control (RBAC) is a critical feature in SaaS applications. RBAC allows you to define roles within a product that correspond to functions within the organization. Each role is granted the permissions required for its function within the product, and users are assigned roles based on their function.

principle of the safest

With the changing nature of threats and the expanding attack surface fueled by trends that will only intensify over time, security breaches are inevitable. Therefore, companies need to shift to an approach that prioritizes mitigation strategies; the principle of least privilege is central to this. Today’s SaaS products often do not offer the core functions for PoLP. As SaaS developers and consumers, we must do better and demand more to protect our users’ accounts.

Sagi Rodin is CEO and co-founder of Frontegg.