Democratizing the Principle of Least Privilege in Collaboration Tools

In security circles, we are all familiar with the concept of the principle of least privilege or “need to know” – assigning users the minimum access rights they need to do their jobs. If they don’t need access to something, they don’t get it. But while this discipline is widely recognized as the right thing to do, it is still often a challenge for organizations to get right. And when it comes to collaboration tools, a new approach is needed.

‍

The purpose of implementing the principle of least privilege is to reduce the risk of a malicious actor (both internal and external) abusing high level privileges to cause real harm to the organization. The principle of least privilege aims to reduce the attack surface by limiting the number of users for each system, and the number of users with high level permissions (for example admins), thereby reducing the number of people who can be hacked.

‍

But collaboration tools introduce more fluid concepts of privilege, where access is determined at the file level, not the system level, and privilege can change from one project to another, and the power is in the hands of individual business owners and users, not centralized IT teams. As a result, the principle of least privilege must also be democratized across the organization.

‍

The Impact of Collaboration Tools on the Principle of Least Privilege

Collaboration tools aim to bring users together on platforms. They can be free, easy to set up, and are designed to integrate with other platforms. Collaborative working through these tools has been widely adopted by organizations, and as a result, the average organization’s SaaS portfolio now comprises 254 applications, many of which may not be centrally owned or managed by IT, and they may not have any control over who uses them and at what level.

‍

Just as management of collaboration tools is decentralized, so is their usage. Users can share or access the information in a particular tool through their integration within another tool. For example, a Google Doc can be shared and even worked on through a Slack channel. This changes how people access the tool, complicating the privilege management process.

‍

Collaboration tools encourage users to work together on projects in order to facilitate the business. As a result, “need to know” and privilege” are constantly changing as different users become involved in a project, sometimes even on a temporary basis. Traditional privilege management methods have struggled when a user leaves a role, and they certainly can’t keep up with the constant flux of collaboration tools.

‍

Collaboration tools challenge the concept of an organization-only perimeter. They recognize that employees may work with partners in other organizations, and as a result have made it easy for users to share projects on tools with someone outside their organization. But what happens to those privileges when the project is over? Or when an external user is given privileges for a certain document shared in a Slack channel they are part of, but absolutely should not have access to another document shared in the same channel?

‍

Collaboration tools have also changed how data is created. Data is no longer created in huge databases accessed by a privileged few. Now anyone can create and share data just by tapping a few keys, and with the help of a collaboration tool, it can be spread far and wide in minutes, with no consideration of who needs to access it, or what should happen if the wrong person gets sent it.

‍

Building the Principle of Least Privilege for SaaS Security

So, what is needed to enable effective management of the principle of least privilege in SaaS security?

‍

First up, as with more traditional tools, it is important to know who has which privileges to which systems and at what level they can use it. However, static asset audits are simply not going to be effective with collaboration tools, as changes take place too quickly. Instead, collaboration tools need a security tool that can automate the mapping and logging of assets and their users in real time.

‍

That map will constantly change as the tools in use, and system users change. IT teams therefore need the support of a system that can understand the context within which the user operates. And by understanding the context of the access, it is possible to take appropriate action – namely either allowing the user to access the tool or file, or to remove that access. In a more democratic privilege management framework, this can be automated, or it can be decentralized to a business owner who is responsible for that tool.

‍

Enforcement also has to be in real time, and preferably automated. In collaboration tools access and privilege are much more fluid, and groups on one tool may contain members with different privilege levels for another tool, making enforcing privilege and protecting against data leakage more complex.

Manage Privilege in SaaS Security

At Reco, privilege management is central to our vision of SaaS security. It is the principle of least privilege that guides the decision of whether an action is justified or not – does the user accessing this file, or the user with whom this document is shared have the privileges to access it?

‍

The AI-led business context justification engine creates an understanding of context to understand who should be granted access to systems and files, helping to mitigate privilege violations such as when a file is shared with the wrong person, or when a file is shared with the expired account of an employee who has left the organization, or where every user in a Slack Channel has access to something they should not. And with Reco, any business owner can understand who should have privileges to their tools, and who in fact does.

‍