Identity security is the discipline of ensuring that when a user logs into an app or a database, they are,indeed, who they say they are and can only access the data they require to do their job. Thus, to optimize identity security, one must optimize authentication – understanding who a user is -, and authorization – what they can do. Having the ability to restrict each user’s access only to the apps and data that are necessary for that user’s job (or better yet for the immediate task) – is the key to effective identity security – and, the greatest defense of all, least privilege.
In today’s world, it’s typical for employees to work together from across the globe while using multiple devices to access dozens of different SaaS apps and databases from multiple vendors. An average enterprise runs 130 SaaS apps and an average employee has 30 digital identities, meaning the number of identities to manage gets exponentially greater as companies scale. This poses 3 fundamental challenges to identity security: (1) How to manage multiple digital identities, (2) how to manage authorization for each identity, and (3) how to secure enterprise data within hundreds of applications.
How to manage multiple digital identities
To manage multiple digital identities, enterprises turn to Identity Providers (IdP) like Okta, Azure AD, Ping, Duo, and others. These tools make it convenient for IT teams to provision access to dozens of SaaS apps across hundreds or thousands of users, while making it easy for those users to log into every app. Thanks to Single Sign-On (SSO) functionality, employees no longer need to remember dozens of credentials. However, despite these benefits, Identity Providers still offer extremely weak identity security.
Why? Many apps are managed outside of Identity Providers. It is sometimes easier for an app admin to configure access directly within the app rather than through an Identity Provider, resulting in what is known as “Shadow IT” (apps and platforms outside of the scope of an IdP). Business units often buy productivity apps outside of the usual IT and procurement processes and provision and administer those apps outside of IT protocols. For the apps that are managed through Identity Providers, organizations have visibility on associated identities (usually), but they still can not see what data those users can access, edit, delete, and share within those apps. In short, Identity Providers have tons of dangerous identity security blindspots.
How to manage authorization for each identity
Permissions are the basic mechanism to manage what a user is able to do within an app or with a specific resource like a document or a data table. For example, when you create a Google doc or a Word doc, only you have access to it. But, when you share it with colleagues, you grant permissions for them to view, comment on, or edit that doc. The problem with this is: every application and platform has its own set of permissions and oftentimes those permissions cannot be readily understood by someone who has limited experience with that particular system. Hence, for security teams to have a comprehensive understanding of the permissions within each of their organization’s systems, they would need to have a system expert for each application. This would be neither efficient nor scalable.
For example, only a Snowflake expert can understand what the permission, “Evolve Schema,” actually allows someone to do. And only an AWS expert can understand what is meant by PutBucketAccelerate – a permission in “AWS language.” Cloud apps and databases often have hundreds or even thousands of granular permissions, and most of them require app-specific expertise to understand. Apps and databases usually use roles or profiles to pool together dozens or hundreds of granular permissions and those roles or profiles are then assigned to users.
Using roles and profiles to pool together individual permissions weakens identity security because it encourages overpermissioning – or, granting too much access to users. When someone asks for access to a Snowflake report to do an urgent project, the easiest way to fulfill that request is to simply assign that user a role that has access to that report. However, that role also likely grants the person access to many more resources that aren’t at all necessary for the user to do their job. According to Microsoft, 99% of permissions never get used!
Pooling permissions together into roles and profiles also makes it really difficult for security teams to manage who can do what with which data. For example, even if we know that someone has a “Revenue Analyst” role in Snowflake, we have no idea which tables that person can actually read, create, edit, or delete. It also is incredibly difficult to gather the entire list of identities who can access a particular Snowflake table, forcing security teams to guess – or, worse, hope.
Securing enterprise data
In order to secure their data, enterprises turn to multifactor authentication (MFA) techniques (like one-time SMS codes or challenge questions) and endpoint security systems like Crowdstrike, SentinelOne, and others. While using these kinds of tools and techniques is certainly a must, they are not enough to provide identity security in the modern threat landscape. Threat actors can often trick users to reveal their login credentials, even when MFA is enabled.
For example Twillio was recently breached when hundreds of their employees received an SMS text addressing them by their first name and asking them to click a link to update their Twilio passwords in Okta. Most users ignored these texts, but a few users did click on those links. The links lead to landing pages that impersonated their usual Okta login pages where they duly entered their passwords. The attackers then used those credentials to log into those employees’ real Twilio accounts. This resulted in the employees receiving real one-time, second-factor authentication codes which, of course, they entered into the fake login pages, giving the threat actors unhindered access to all apps and data that those employees were authorized to access.
Achieving identity security
The only way to truly achieve identity security is to (1) actually achieve and maintain least privilege and (2) be able to control who can have access to which data across all applications and databases. Then, when a breach occurs, only a limited amount of data gets compromised and IT teams can quickly shut off all attack vectors while figuring out exactly what got compromised.
Lucky for the modern enterprise, implementing effective identity security and achieving least privilege require nearly the same steps. Two birds! Want to learn how? Watch our short demos to learn how Veza can help you implement rigorous access controls and visualize who can do what with which data. Or, schedule a call with us to explore in more detail.
