We’re excited to bring Transform 2022 back in person on July 19 and pretty much July 20-28. Join AI and data leaders for insightful conversations and exciting networking opportunities. Register today!
While breaches of the kind recently disclosed by Okta can never be completely prevented, the principle of least privilege (PoLP) is a simple yet powerful solution that can dramatically 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 keep their customers and end users safe in 2022.
Wait, what happened?
Okta suffered a breach by the Lapsus$ hacker group at the end of January, which went undetected for almost a week and was eventually made public on March 22. The weak link exploited by Lapsus$ was reportedly Sykes Enterprises of Sitel, a third-party customer support provider.
A laptop belonging to a Sitel support engineer was approached by attackers, after which Lapsus$ a Remote Desktop Protocol (RDP) session with Okta. Although the attackers failed to pull off an account takeover thanks to multi-factor authentication (MFA), Okta said the company acknowledged that more than 300 customers could have been affected and that some user data had been collected by the hackers.
Unlike traditional hacking groups that exploit code vulnerabilities or misconfigurations, Lapsus$ is the preferred approach to bribing company insiders or third parties who have been given access. With unconventional tactics like these, as well as the ever-present risk of social engineering attacks and simple human error, it is not feasible for any organization to be 100% secure. That’s why it’s critical that we take measures that minimize the “radius of the blast” of a breakthrough. This is exactly where the PoLP comes into play.
The principle of least privilege mentality
PoLP is a best practice that minimizes the severity of potential attacks by limiting the permissions for a given user to the lowest level necessary to do their job.
This approach ensures that even in the event that an attacker gains access, it does not automatically grant them divine superuser privileges to extract or manipulate user data at will. The capabilities an attacker can unlock are limited according to the job requirements of the employee whose account is being used. When properly implemented, most employee accounts will have strict restrictions, so most breaches will cause little to no harm.
Okta stated in their report on the incident that the application that the attackers accessed was “built with the least privilege in mind”. While the details of the capabilities granted to a remote support engineer raise questions about this claim, the reference to PoLP is appropriate because this approach is central to mitigating these types of attacks.
The growing number of privileged
The relationship between Okta and Site is not unusual. Digital transformation initiatives have accelerated adoption of many SaaS tools, increased integration across platforms, and outsourcing of services to external suppliers. It has become very common for many companies to give third parties access to SaaS product accounts. But due to the nature of the services provided, third-party vendors often gain access to a large number of customer accounts. If a supporting supplier is hacked, the impact can be huge if PoLP is not followed.
Shifting your business to a PoLP mindset requires participation from the entire organization. As with all transformation efforts, this involves people, processes and tools. But SaaS products today often lack the capabilities needed to support people and processes in adopting PoLP.
The current standard provides for minimal or no role separation. Most apps these days only have a super admin role, one that can perform any action within the product. The more advanced will also add a read-only role in later stages of their evolution. But this isn’t nearly enough to prevent one unscrupulous employee or one lost laptop from having devastating consequences.
As SaaS builders and consumers, we must ensure that the products we build and use support strict PoLP enforcement that can help keep our customers’ data safe.
SaaS product requirements for PoLP
The following PoLP fundamentals should be implemented in any modern app:
Minimal privilege for new users
A new user’s default role must have the minimum number of permissions. This ensures that user accounts automatically adhere to PoLP when created, with no action required. A new user must be created with limited read-only rights and elevated as an opt-in choice as appropriate for the user’s position.
Detailed permissions for maximum control
Having only admin and read-only access simplifies things. The reality is that most users need 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 to PoLP’s more dynamic approach.
Temporary access for permanent security
PoLP dictates not only granting the lowest level of access, but also for the shortest time possible. Promoting the use of temporary access protocols eliminates the risk of forgetting to revoke access granted for a one-time need for an account. In addition, temporary access protocols can allow automatic granting of access on a regular schedule; for example, restricting a third-party support provider to access only during business hours, further minimizing damage.
Ongoing Control Activities
Products must be continuously monitored so that suspicious activity can be detected in a timely manner. This requires the team to develop the auditing practice and put in place an appropriate process, but also needs to be supported in the product through an easily auditable audit log mechanism.
Frictionless UX for permission management
A robust PoLP approach requires a frictionless user experience (UX) that allows users to easily manage their roles and permissions. Revoking, modifying, and granting access should be easy – making these operations difficult encourages giving too many permissions to avoid dealing with them later. These capabilities should be given to customers and end users, who can then take full control of their accounts and reduce the attack surface.
RBAC: an important requirement for large organizations
In addition to the stated minimum basic requirements, large organizations need additional capabilities to manage 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 feasible to manage permissions at the individual employee level.
For companies of this size, role-based access control (RBAC) is a critical capability in SaaS applications. RBAC allows you to define roles within a product that match functions within the organization. Each role is given the permissions necessary for its role within the product, and users are assigned roles based on their role.
Principle of the most secure
With the changing nature of threats and the growing attack surface, driven by trends that will only grow stronger over time, breaches are inevitable. Therefore, companies must move to an approach that prioritizes mitigation strategies; the principle of least privilege is central to this. SaaS products today often fall short of delivering the core capabilities for PoLP. As SaaS creators and consumers, we need to do better and demand better to keep our users’ accounts safe.
Sagi Rodin is CEO and co-founder of frontegg†
Welcome to the VentureBeat Community!
DataDecisionMakers is where experts, including the technical people who do data work, can share data-related insights and innovation.
If you want to read about the latest ideas and up-to-date information, best practices and the future of data and data technology, join us at DataDecisionMakers.
You might even consider contributing an article yourself!
Read more from DataDecisionMakers