What Ails Enterprise Authorization

Awesome. So great to have you here. Thanks for spending your time with in this session. And what I'd like to talk about today is just sort of talk about the issues we see in enterprise authorization and how we are trying to address them in our, in our brand new company. So let me tell you a little bit about signal, right? So you probably haven't heard the name. You've probably just seen us with the t-shirts upstairs and the other keynotes. And we are a brand new company. We got started in October last year.

And you know, the early team members are from these companies and our sole focus is to solve the problem of enterprise authorization by that, I mean, that today's enterprises seem to be operating in a very sort of overprivileged kind of environment where users have more access than they, you know, should be having at any given point of time. And what we are trying to do is, you know, figure out a different approach, an innovative approach to solving this problem so that you can actually have a least privileged kind of access within your enterprise.

And the stage of the company is that we are currently working with some design partners and we are happy to consider more, but we are already having a bunch that we are working with and with a view to releasing our product in Q3. So you can visit us at, at the booth, if you have any questions or would like to know more right, little bit about myself. I was at Google before I started at signal and there I was working on the beyond Corp API. So if you are familiar with zero trust, you probably know what beyond Corp is.

It's it was sort of Google's implementation of zero trust way before zero trust actually became a thing. And I was happy to be leading the API part of it, which integrated with some of the third party, you know, device information providers.

And I, what I also did was I wrote a blog in February, 2019, which envisioned a thing called a continuous access evaluation protocol called Cape. And that has since sort of taken life of its own. And it's merged within effort in the open ID standards body, which is now called the shared signals and events framework.

And, you know, I'm, I'm, co-chairing that with, with Tim here in the audience, and we'll be talking about that in the next session previously, I was, I was involved in the development of the Liberty Alliance and the, the Samuel standards. So that's me.

And let's, let's talk a little bit about how this signal sort of came about, right? So as we were working with, you know, Google's internal systems or with customers, we are realizing, we realized that, you know, data is obviously no enterprise can exist without data. It's sort of the operational backbone of every enterprise, right? But customer data specifically is a category that a lot of people need access to at the same time, it is highly critical, right?

So you have a conflict where something that everybody needs to access, but you know, you still want to be very careful about how it can be accessed and to solve this problem. You know, you, you need a innovative thinking because the current situation is getting out of hand, your, your workforce is more diverse.

You have, you know, fulltime employees, you have partner employees, you temps, you've contractors, all of these need access to the customer data. You have a large number of applications, internal third party, SAS apps, everything that needs to access this data. And then you have regulatory requirements because you, you have, you know, whatever industry you are in, you need to produce audits that, that specify, you know, that you can prove that you're complying with your policy. So together, this, this situation makes it really difficult to address the problem of enterprise authorization.

And so what are, you know, the strategies that people use today, you know, include basic things like ACLS. I'm sure all of you have, have seen those. Then you have our back, which is like an ACL, but sort of the entry is a group. And then the group can have a membership and you can dynamically change the membership of the group. You don't actually have to change the ACL in that case. Right?

And then more recently you have AAC, which adds a little bit of dynamicism, which is sort of, you can dynamically assign attributes to individuals and resources, and you can have policies that kind match these attributes. And that brings in some dynamicism. So you can say things like, you know, location jurisdiction thing, which matches between the resource that is being accessed and the, the, you know, the user that is accessing this. The other thing is that because systems are not just within your enterprise anymore, right? Your company may be using third worry SAS apps.

And so you need to have propagation of these roles from your enterprise directory, into these SAS apps that your company may be using, right? So there's, there's sort of role propagation also going on. So all this makes for a very complicated environment today. And so here are the problems that, that occur and, you know, it's not animated, but let's go one by one. And I'd like to get your participation here.

As I, as I talk about a particular problem, let's have a show of hands as to who has seen this problem in your enterprise, right? So the first problem is named named permissions. So named permissions means, I'm sure everybody has done this, where you have an ACL with, with explicitly named users, regardless of their role. And you know, that user may have been in, in a position that required access three years ago, but that user still has access because they're named, you know, permission. So how many people have this problem in your enterprise? There you go. Right? Almost everybody.

Now, the second problem, which is maybe a little rare, but also very prevalent is rolls Q. So what rolls queue means is that you, you have created roles right. In an rback system, but the roles do not match your enterprises current organization, right? So let's say a user was in the customer service department and therefore was included in a group in a role that said, this is a customer service user. Now that user has moved on to something else.

Let's say they've moved on to the health desk, or they've moved on, you know, internal it or something like that, that user's permissions are still there in that role. And so the, the rules that you have defined in your organization do not match your organizational structure, right? So this is called rule skew. And you also have a proliferation of rules because you have like hundreds of rules in your organization that, you know, may not make sense outside of that role based management system. So how many people have this problem in your organization? There you go. Right?

So a lot of people still have this problem. The third problem is interesting because it's what we call broken class. So what happens is there is some urgent requirement. There's some firefighting going on. There there's some deadline because of which you have to give permission to somebody or some role in order to sort of do their job. And within the time required.

Now, once that permission has been granted, you rarely sort of review that permission afterwards, or even if that review comes up, you have no idea as to why that permission was granted. And because you don't wanna break things, you kind of renew that permission anyway, right? So this is what we call broken class. And you know, this is also very prevalent in enterprises. So how many have seen this? There you go. Right?

So it's, it's still a big problem. Now, when you are using aback, right, you have created these policies and you have them sort of fragmented in various applications. And the trying to answer the question as to which user has access to which data becomes a problem, because there is these, all these fragmented policies, which are hard to understand, you know, the, the policy language is not very clear. And so as a result, what happens is there is this what we call as a policy ticket, because it's hard to understand where the policies have been specified by reading those, those policies.

It's not clear, you know, who has access. And so there's fragmentation. And then there is lack of clarity, right? So how many have this problem? A fewer people, because not a lot of people actually have implemented AAP, right? So that's one of the problem. And the last one, which is also a very important thing, which is opacity to audit right now, if you, your organization may have defined policies based on your compliance requirements or, you know, other reasons, but now you want to Cate that into an audit that proves that in fact, those policies have been followed, right?

All the users that you know, were granted access, you know, were granted an access in conformance with some policy developing, such an audit or reading, such an audit out of the large number of applications that you might be managing is very difficult today. Right? So what that creates is an opacity to audit. So the compliance report cannot be very easily generated as a result of this. So I'm sure a lot of you have this problem in your organizations, right? Show of hands, please. There you go. Right?

So it's, you, you see that this is not a very good situation to be in, right? There's all kinds of issues going on with authorization and what's happening is because of the transformation to zero trust.

Now, everybody is gonna be in a model where they're not trusting the en environment that the access is being granted from. And so anybody from anywhere around the world will be able to access whatever applications they want as a result of their sort of authentication into the system. Right?

And so, because there is no physical parameter, the only way in which people are gated from accessing their assets is by user authentication. And if you don't have good control on your privileges, like your, what a user can do once they're authenticated, then you are setting yourself up for a, for a potential issue that if there is a compromise, or if there is a malicious insider activity, the damage can be pretty big because everybody has a lot of access. Right? And that is what we are trying to do is to make sure that your authorization system enables you to prevent a large scale damage.

Now, there are some very high profile attacks that happened recently where a customer support agent of a, of a prominent technology company was able to access hundreds of customers, you know, data. Right. And that happened because that, that customer service agent, as a result of their role, was able to actually get access to all the data that they wanted to. And we want to avoid that. So what do we want, really? We want to be able to ensure that, you know, the customer data can be accessed only by the right people at the right time.

So working hours, locations, things like that, and in the right context, right? So you have various things in the context, it could be your sort of location. It could be things like, what are you actually working on right now? And things like that. So you want to be able to design a system that gives you this in, you know, this ability, right. To reduce the amount of privilege you just, you cannot give blanket permissions to anyone to AC you know, do anything that they want. So let's take some concrete examples, right?

So the first example is, you know, a customer service representative can only access data if they're assigned to a particular case of that customer. Right. So they can assign, they can access that particular customer's data only if they're assigned to a case that relates to that customer. Right. And they can do so only during business hours. Right? So these are the kinds of rules that you would want to have in your own organization. The next use cases that let's say you have requirement that any person accessing customer data in the EU needs to be based in the EU, right?

And so that is sort of a jurisdictional limitation that you want to enforce. So this is another example of where you want to limit access to customer data. And then let's say you have a system where customers are able to give, get refunds or discounts or things like that. But you want to have a very solid process around who can issue those discounts or who can issue those refunds, right. Only when there is a manager approval.

And, and they're also an assigned account owner of that particular customer, right? So I shouldn't be as a account management executive, just going to any customer, any issue, refunds, or issue, you know, discounts and things like that. Right? So this is, these are the kinds of things that we would like to have in our system, right? And so this is sort of what is guiding us in, in signal is, you know, these are the principles that we would like to abide by. We want to be able to give the right people access at the right time.

We wanna make sure that whatever policies are defined are readily readable, understandable so that the problem is not being able to understand policies. And as a result, being reluctant to actually change those policies doesn't arise. The third thing is we wanna make sure that users only get privilege based on what activity they're doing and not blanket privileges that give them access to a lot of data. We want to be able to apply this consistently across all the applications, right?

So we, whether those applications are your internal applications, whether they're third party, SAS apps, and it should also be easy, right? It shouldn't mean that it would change a lot of things about your application, right. Or there's a heavy integration involved and all that.

So, and the last thing is it should be auditable. So you should be able to easily generate an audit that require that, you know, meets your compliance requirements, right? So you should be able to easily say why any user was granted access to any particular set of customer data and what was the reasoning, or, you know, when that access happened and what was the reason that they were granted that access, right? So all of these things can be achieved with what we are proposing, which is a slightly different approach than, than what you, you may have seen. Right?

So we are calling this approach just in time access, right? So what we are doing is we are not trying to define a new sort of authoritative source of information or anything like that. We are trying to unify the data that already exists in your organization, right? So we'll integrate with your existing identity management system, your existing HR, your CRM system, your ticketing system. So notice that, you know, we are also including dynamic data in this unification, right? So it's not just static data, like role data, or identity data.

It's, it's more dynamic data like ticket assignments or, or, or case management and things like that. And then based on this UNFI unified data that we create, we are able to generate just in time privileges for the applications. And then all of these things can be audited in real time. So you are the lucky people who will get to see the signal solution for the first time, because we are a new company and we have really not talked about it outside so far. Except if you have visited the booth, we, we have talked about it there, but yeah. So here's how the platform works, right?

So on the left hand side, you'll see the data sources that we are ingesting data with data from. So we are ingesting data from the identity provider, the CRM system. This could be your Salesforce or similar your HR system. This could be like your Workday, your it service management system. This could be like your ticketing system, like ServiceNow or Atlassian and, you know, various other systems. And what we do is we create this dynamic graph directory.

Now this is a little more powerful than your normal attribute based access control, because it's not just about assigning attributes to individual notes. It's about also the graph traverse, right? So if something, you can define policies in which you can say, Hey, a user has been assigned to a certain case. That course case belongs to a certain customer. So that user or their manager should be able to access that customer data. Right. So it's not just about assigning a little tag to that user for that period of time. Right.

And then what we have is a, a policy engine and I'll get into the, the, how a policy looks, very simple, understandable English language kind of policies. And then we are able to integrate using an SDK or a reverse proxy or a filter to your internal applications. Or we are able to use, you know, one of the standard integrations that we have with your sales force or your third party, SAS apps like that. So together, what we are able to do here is builder dynamic picture of your, of your enterprise, what the activities of your enterprise and based the permissions based on that. Right?

So not give blanket permissions to any users. Right. All right.

So, like I said, this dynamic graph directory sort of embodies the activity of your enterprise, and it's based on ingestion from various data sources that already exist in your enterprise. The real time policy engine uses, you know, understandable policies. I'm gonna skip over this slide because I just talked about it. So let's take a look at the UI actually.

So here, what you see is, sorry, what you see is, you know, your data sources and how they're behaving. You also see the application activity, like how, which app, and this, for example, customer billing is an internal app. Whereas Salesforce is a third party SAS. And so you can see the actual enforcement actions that are going on across your internal apps, as well as your third party SaaS apps. Right. And then you're also able to see which policies are you being used the most in your enterprise in order to enforce access control. Right? And so here's what a policy looks like, right?

So for example, what we have is these policy snippets that can be reused across various policies, but like customer service support users can access all customer data. If these conditions are met. Right. And the last one is interesting is what is access is justified. So this is a snippet from another policy of created, where if you hover over it, you're gonna see the user is an assignee on a ServiceNow case where the customer is the assigned account, right? So only that user can get access to that particular customer data. Right?

And so all this sort of information is captured in this dynamic graph. And then you can do some querying on the graph itself to understand the relationships within your enterprise at any, any given point of time.

So here, you'll see this user powers, they have an Azure ad kind of entry, which, you know, has all these attributes. They have a ServiceNow entry and, you know, they have this phone number in Workday information and all those things. So it's very easy to sort of understand in one place, you know, all the relationships within your organization. So at a glance we provide just in time access, we are able to enforce it on internal and external applications. We are able to give list, lease privilege access.

We are basing that based on a graph directory, super fast, you know, where you get, you know, millisecond time response to any query that you ask. And then we are, we provide a graphical policy builder, like we showed you so very easy to understand, very easy to maintain, and it's very easy to integrate across all the existing systems.

And so going back to the principles that we talked about, about how, you know, how ideal authorization should be, so you, you get this, so you are not going to be able to have any named permissions or rolls queue because whatever your existing R back system or your name permissions are, this is gonna be a layer over it, right? So you can selectively have certain applications that leverage this just in time access. I'm almost done.

So that leverage this just in time access, and then your you're able to coexist with your existing systems, but at the same, same time provide, you know, fine grained, dynamic access control. And then, you know, policy evaluation makes sure that your sort of privilege fraud gets, gets contained and your, because the policies are very understandable and maintainable, you, you don't get into the policy ticket kind of issue.

And because every action is checked against the directory, the graph, the graph directory, you're not, you're able to generate an audit and compliance report very easily, right? So you get all the, all the different things that, that you would expect from a good authorization system. So would love to chat with you, understand, you know, how you would like to use this, or, you know, if you have any questions, please stop by our booth. It's on the keynote level, right by the stairs. Whoa.