Previously I wrote a blog talking about what ISPM could mean for the future of Identity by comparing it to other *SPM platforms and the features that are established in Security Posture Management so far. Today I’d like to take it a step further and talk about specifically how Authorization maps into this new world of ISPM and what pieces Policy Based Access Control tools such as SaaS Authorization Management and Dynamic Authorization can solve.
For those of you who aren’t aware of Policy Based Access Control (PBAC), its the idea or strategy that puts forth all authorization or access control should be centrally managed in a tool that makes authorization easy to understand, as well as, enforced locally in the tools where the digital assets exist. What this strategy or technology grants the organization implementing it is visibility and control of HOW identity attributes or groups or roles controlled by IGA tools are actually used by applications or services to allow users to perform tasks or see data. For instance lets say that IGA provisions a user inside a group and because a user is in this group they can see client account information. There are two sides of IAM at work here. One is IGA deciding who gets to be in that group controlling which users have access to client data. The other is a policy, or rule, or ACL inside the client account management tool that basically says IF USER isMemberOf group then allow access to client data. All the different tools, applications and services have these rules or policies embedded in them and PBAC allow organizations to get a full view of all of those. So IGA controls WHO gets in the Group Authorization determines HOW that piece of identity is used for security.
Let’s expand this train of thought because the goal of Policy Based Access Control isn’t to see how the identities are being used for security in 1 application but all applications and services throughout an organization. Letting you see the tangled web of how multiple applications use the same pieces of identity to grant different authorizations and permissions. This map of how identity is being used starts to sound a lot like what data lineage maps do for data, which is an important piece of DSPM. Now the question comes what insights could we gain from this? And what parts of our security posture may be improved upon from these insights?
For starters let’s take an example built of three different technologies that often work together in an organization. An Identity Provider (IDP), a SASE like Zscaler, and any application are together in a technology stack. In general the IDP enforces authentication then will create a token of some sort for the user and forward them to the application they wanted to go to. Zscaler is usually there hiding in the middle making sure that that device/user should even be able to connect to the application at the network layer then once the user hits the application with the token the application goes “I now know who are you are let me look at my policies to determine what you should be able to do”. With that in our minds let’s throw some wrenches into the works, issues that happen at every organization. let’s say that when the user hits the application the application goes hello user1 I know who you are but you have nothing you are allowed to do within my ecosystem. In this case we have bad security posture. If the user has no authorization inside the app or over the digital assets the application exposes then why did the IDP provide the users identity to that application? Why did Zscaler allow the user/device to even connect to the application or its endpoints at a network layer? To be honest the why is easy and a tale as old as IAM itself. Disparate controls over authorization and security without any central over-site or management. Time to circle back to our Authorization strategy of utilizing PBAC in an organization with a strong PBAC tool/strategy the PBAC product would have been able to keep all authorization in alignment. Through centralized management, the security team would have been able to see I have no policies that allow these types of users to view/manage digital assets exposed through this applications and would have been able to tweak policies in Zscaler to block the user at the network layer. It’s cracks like these in which Identity related breaches occur. Just like your back if your posture is out of alignment you’re at risk to injure your back and other parts of your body or ecosystem.
There are other ways to look at an Identity Map without focusing on access such as looking at an IDP and user accounts themselves to see where identities are being provided to to see where identities are going and decide if they should be allowed to go there should be allowed single sign on into applications. This will also be an important piece of ISPM going forward as well, but in this case we are focusing on the authorizations side of how the identities are being used so that we may see what parts of our Security Posture we can gain insights on and fix. In the future a good ISPM tool will be able to look at both where my identities are going, how are they used once they get there and what isn’t in alignment between the two.