Patrick Parker, innovation-driven entrepreneur as well as founder and CEO at Identity Management and Cloud Security firm EmpowerID, will deliver a keynote presentation entitled Complexity Has Reached a Tipping Point in IT – What Can We Do About It? at the European Identity and Cloud Conference 2021.
To give you a sneak preview of what to expect, we asked Patrick some questions about his planned presentation.
From our experience, large customers typically have 3,000 to 5,000 different applications that the IT staff have to manage, provision, control access. And end-users in these organizations interact with hundreds of these applications. So really 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 staff in other countries, that 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. For each of these systems, they have to have native permissions, which is a huge risk as they are going into these systems as a superuser. 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 in these systems. It has really become an impossible task. The turnaround time has become extremely slow. The frustration for end-users and often at errors 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 are prevented 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. They are 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 – there is too much data for it to be humanly possible for them to accurately assess risk compliance and to keep this all in check. It is just becoming overwhelming and it's 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.
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 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 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 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 avoid 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.
I think the one thing we can assume is that 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 have abstracted it out so that 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. 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 perform in all these various systems, whether they're cloud or on-premise, we really need a mapping layer, a 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, creating a purchase order in various systems, Microsoft Dynamics, SAP, and others, would be delivered by technical entitlements, granting complex and cryptic low-level transactions. If we are dealing at that level, 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 IAM system is what translates that last-mile delivery of the 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 terminology down to the system-specific is hidden from us because we shouldn't have to learn that because it is 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 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. So in AI, there is something called intention analysis and intention mappings, where for a user 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 prevent the low-level information it has to bubble 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 it needs to perform.
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 if you have a multi-cloud environment, you have Google GCP, which has a very different security model, very complex, that takes someone a long time to learn, which is very different than AWS that has a Jason policy-based model, which is even very different from Azure's role-based and scope based model that the users that 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 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 unproxied 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.
Yes. We've been working on it for about a year and a half now, so we have the mapping layer. One of the key trends is that 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 perform, where they have access to, but 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 do. It can also propose new rules based upon activities of similar cohorts. And if the activities 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 a person and see that this user can create a Kubernetes cluster.
And that if I look at that, I could also see if they could create it in Google or AWS, 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 across our enterprise landscape, how they're getting it and also activity usage tracking. So 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 rise of the platforms, as far as ServiceNow 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, what isn't within their scope, is fulfillment. So we have customers right now, like one example that is fully ServiceNow. They have access requests processes for SAP and other systems, but just to fulfill the access request for SAP, and they have 800 staff in India, which is an extremely huge expense, because ServiceNow 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 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-grained permission. So it knows who can do which of these human activities. It can track this, but then in the platform system, that semantic layer would ease the process for them. So when users are remaking access requests in 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. If 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.
