EIC Speaker Spotlight: Patrick Parker

Okay. From, from our experiences with our large customers, they're the typical large customer has about 3000 to 5,000 different applications that, that the it staff have to manage provision control, access, and end users in these organizations interact with hundreds of applications. So really that the it staff being able to be properly trained and understand the security models and how to grant and manage security in these thousands of applications has become overwhelming. Most of these organizations have outsourced this role to other countries, to staff in other countries.

And these staff in other countries have a high turnover rate. So it's always a new employee and the new employees coming in and they're managing access requests for hundreds of systems, for which they're not trained each of these systems. They have to have native permissions, which is a huge risk where they're going into these systems as a super user. They're not very well trained. They may not be in this job for very long, and they have to make sense of these access requests to try to grant the user permission to need systems. It's really become an impossible task grant.

The turnaround time has become extremely slow. The frustration for end users, and often it airs on the side of just over permissioning and giving the users too much access to try to just close the ticket. It also makes it extremely difficult for managers because managers are business users. They know what the users should be able to do as part of their job, but translating that into the technical entitlements that they're presented from these systems and enabling them to make a decision is often just a guessing game.

The technical entitlements have no real relation or meaning as to how they, what they grant the user, the ability to do on a day-to-day basis and what would be the risk of that and whether it's appropriate. And the same thing goes for auditors. Auditor's investigating to see our people within our risk policies. Do they just have the access they need? What have they been doing again, looking at low level technical audit logs of transactions, looking at these technical entitlements is there's too much data for it to be humanly possible for them to accurately assess risk compliance.

And to keep this all in check, it's just becoming overwhelming. And it's only, only growing more complex as we move to the cloud. As digital transformation causes an outsourcing of best of breed for each area of the enterprise to different applications. This is an ever expanding universe of complexity. So one of the major risks of the over ever-growing complexity within our it organizations is over permissioning. This has become dramatically worse.

As we've moved to the cloud cloud platforms are, have extremely elaborate and idiosyncratic security models, which are specific to each of the platforms. Google GCP has a different model than AWS than Azure. And then the various systems like SAP, each one has an ever expanding set of services they offer. So the typical cloud administrator for these platforms only actually utilizes less than 1% of the permissions, which they hold at all times. This creates a very large population of super users, which are always on always armed and open to attack.

So this large amount of standing privileges is a huge security risk for organizations who are hackers have access to these publicly available systems, where if they compromise any of these accounts, they have God-like permissions and could do very destructive actions. Also another major risk is just end user frustration. What might lead to something called the great it slowdown where end users and managers are overwhelmed by the complexity of dealing with it systems.

They really want to do the business work in their job, but they're the percentage of their time that they spend interacting with it. Making requests, dealing with permissions recertifying access is only increasing. So the end user frustration will lead to rubber stamping, which will Boyd and bypass all of our organization's compliance and security policies. And at some point the complexity will just reach a limit to where it's really impossible for certain roles to understand as many systems as they're being required to manage, which will lead to breakdowns human error and vulnerability.

The one thing we can assume is it, the it infrastructure is only going to increasingly grow complex and to continue its velocity or its path.

So the solution to that is really the solution that's been used in many other industries over time, developers no longer deal with machine level code they've abstracted it out toured they're dealing with higher level objects functions, the low code movement, allowing users who are less technical to automate processes without actually writing code that if we borrow a term used in business intelligence and data analytics, what we really need is a semantic layer in business intelligence, a semantic layer is the mapping for your complex data in different heterogeneous systems into a single set of easily understandable business concepts for users.

So it really transforms data into meaning and insight. The same thing could be applied here for it and identity and access management, specifically the complex permissions and actions and activities that users performing all these various systems, whether they're cloud or on premise, we really need a mapping layer of semantic layer so that the business users, the help desk users, the operational staff and the auditors can deal with a single set of recognizable terminologies so that you can see what a user wants to do. And who has access on understandable terms.

As an example, create purchase order in various systems, Microsoft dynamics, SAP, and others would be delivered by technical entitlements, granting complex and cryptic low-level transactions. But if we're inventory and dealing at that level, then the auditors and the users will have to understand the low-level complexity. But if we're dealing with a semantic layer, then you'll be able to see, I want to create a purchase order and that's all you interact with. Or if I'm at help desk, I can see in grant the ability to create a purchase order.

And then the I am system is what translates that last mile delivery of the technical technical entitlement. So we're dealing with business terms that are readily understandable, that we can categorize the risk that we can recertify. Everything makes sense. And the actual technical mapping of these semantics of these terminologies down to the system specific is hidden from us because we shouldn't have to learn that it's not really a value add for our job.

Now, this is also a good from a zero trust perspective because you're pulling users out of having direct interaction with those systems and native permissions and granting them access to a single interface, which hides that complexity. So it reduces the training time. It drastically reduces the amount of information and trend knowledge that a user has to have to perform their day-to-day duties, which reduces the cost to an organization. It helps on turnover and re-education, and it lowers risk. Yes.

So, so that's another point I had on here, but so in AI, yeah, there's a, there's something called intention analysis and intention mapping, where for users to be able to talk to AI, it has to be able to say human recognizable terms. Like I would like this, or if the AI is analyzing activities, it can't prevent the low level information. It has to bubble it up into something that means something to the user.

So it's the same type of mapping that happens on the AI to produce intelligible results and for AI assistance, to understand that human recognizable terms and translate that into the action that needs to provide Yes, actually, since it is a layer that's outside of anyone's system, it's really what is even more needed for multi-cloud. So that even if you have a multi-cloud environment, you have Google GCP, which has very, very different security model.

Very complex, takes someone a long time to learn, which is very different than AWS has Jason policy-based model, which is even very different from Azure is a role-based and scope based model that the users are on the front line requesting access, delivering access, fulfilling access, auditing access. They shouldn't have to be an expert in every system.

So this layer for a multi-cloud is really even more important to bubble it up into an intelligible understandable results, and also to hide the complexity so that users are doing these tasks in the native interfaces, where they would require extensive training and have native direct unproctored permissions. You're giving them a zero trust interface where they can perform their activities without having native access and with having a monitoring layer in the middle, which makes it easier for them. But it also adds security for the organization. Yeah. Yes.

We've been working on it for about a year and a half now, so we have the mapping layer. So, so one of the, one of the key important trends is that really organizations are trying to get down to activity-based access. So monitoring activities, understanding who's actually using privileges, what are the activities they perform? What are the activities they could, they have access to do, but they actually never do that way. You can have more of an autonomous access system, which is decreasing the risk profile by trimming out automatically activities that you actually don't you. And it don't do.

It can also propose new rules based upon activities of similar cohorts. And if the activities map, map to technical entitlements that can propose new roles or reshaping of the access policies. So we have the layer in place to be able to have the finest fine-grain permissions, the SAPT codes, authorization object, field values, the Azure rights and role assignments, everything at the fine grain, to be able to map that up into this semantic layer so that you can immediately look at it at a person and see that this user can create a Kubernetes cluster in insurer.

And that if I look at that, I could also see if they could create it in Google or AWS and set of these instead of these being distinct technical entitlements that have no relationship. Now I can see an activity, create Kubernetes cluster and see exactly who has it in across our enterprise landscape, how they're getting it and also activity usage tracking. So if they're, if they're executing transactions using those fine grain permissions, it has meaning now that they are creating it, that meant they created a Kubernetes cluster. And here's the risk associated with that.

So, yes, we have that mapping layer built into the product right now. So the, the rise of the platforms, as far as service now extending into identity and access management functions, Salesforce and others, these platforms are great general purpose platforms. They're great for workflow processes for human to human automation and approvals and tracking for compliance, change requests, et cetera, but where they typically fall short, are they really isn't within their, their scope is fulfillment. So we have customers right now, like one example of the customer is fully service.

Now they have access request processes for SAP and other systems, but just to fulfill the access request for SAP, and they have 800 staff in India, which is extremely huge expense because service now can automate the approvals. It can go through different levels, but these systems typically don't handle fulfillment of the technical access. So once it goes to the system owners or these outsource staff, then they have to deal with the complexity of what did the user really mean? Because users don't know the entitlements. They don't really know what they need.

They don't understand the technical aspect and they shouldn't. So this person is responsible for somehow fulfilling this request. And most of that is manual where they have super privileged access. And so the platform vendors aren't extending down to where they really automate fulfillment. Typically they, that that's something they leave out. So you still have the risk. You still have the human factor. And I see these platform products being probably the biggest consumer of the semantic layer, because you need a system that's specialized that can understand and get the fine green permission.

So it knows who can do which of these human activities. It can track this, but then in the platform system, the semantic layer would ease the process for them. So when users are making access requests and a semantic layer, integrated approach, they would be able to request the things they want to do and not just service catalog items. They'd be able to tell the system what they want to do. Tell the virtual assistant or the AI, what they're trying to do, ask the AI, ask them who shows them users who have the same job function.

It could show them not technical entitlements, but the activities these users perform. And they can say, that's what they're trying to get access to do. And then the mapping layer would translate that after the access request was fulfilled into that last mile fulfillment, which the platform products typically do not provide and which increases complexity and costs. So I see a synergy here where they will be major consumers of this new technology.