Matthias Reinwarth: Beyond Static Access - Leveraging Access Policies To Deal With The Increasing Complexity Of Access Governance

Great. Thank you very much. So let's start with my opening keynote. And first of all, I don't have anything to sell. There is no product behind that. There is no great new, fascinating idea behind that. Then rather just a suggestion, how to do things maybe more smoothly, more efficient within organizations. So I'm looking at beyond static access. So leveraging access policies to deal with the increasing complexity of access governance. And my agenda for this 20 minutes session is very simple.

So we will have a look at traditional access governance, at least as I perceive it within many organizations, then I add some complexity by putting this access governance thing into, into perspective with other activities and areas within an organization. Then I add more complexity by adding some more dimensions of access governance, where we should look at where we sometimes don't.

And finally, I try to introduce and convince the audience that access policies might be a good way to go forward with the, with managing access governance in general, at least at, as for when it comes to communicating access governance. So access governance are still common and widespread perception. This is what I see in many organizations.

And yeah, of course this is by personal perception, but maybe that is true for many organizations. So still access management and access governance is still largely based on traditional authorization concepts. And these traditional authorization concepts is roles or groups. So it's about defining and maintaining rules. It's about assigning rules, re-certifying removing roles, and it's using these roles to understand what users are actually doing within their applications, their systems within their devices. And it's also about auditing.

And that is usually the, the core perception of what access governance does. But in the meantime, things have changed role definitions and business are often, far apart. So the roles are defined, usually not by the people who actually need to use them large role concepts, the larger the organization, and the more systems are involved.

The more you get into the danger of having large role concepts that tend to explode and explode means you maybe ending up with more roles than people, but in general, all these processes that are given above assigning recertifying removing really are lengthy and hinder flexibility. So if you get a role from definition to deployment, to assignment, to actual use, that might take some time.

And finally, there is a lack of insight combined with the administrative processes and all that ends up with a burden to the businesses I promised I add more complexity and I do that by adding some definitions because access governance cannot be seen isolated. It needs to be put into context with other terms with other yeah, concepts with other teams. We start with the term of governance and that is something that is not only related to access, but it's general governance and within many organizations should be in all organizations.

So it's the really the establishment of guidelines and the monitoring of their proper implementation. So access governance, taking governance as the second word from that is embedded into an overall governance approach.

Second, of course, access first part of the, of the term access governance. We look at any access, any user, any device, any network under the control of the organization and to all systems application services and data, then we end up with access governance. So it's really the governance for access. So we really make, make sure that the policies, the rules, the guidelines as defined within a generic governance approach also are well applied to, to this, to access to systems, to, to access and authorization.

And that all systems, applications and services are really enforcing these rules closely related to identity governance. It's the, the governance rules and policies as applied to identities and accounts to me as Matthias. And all my accounts are used within systems that there are only valid current and active identities and accounts.

So again, that is close related of course, to access governance, but is defined in within the rules as defined in, in general enterprise governance approach. Second part of definitions, data governance. We all currently usually think of governance when it comes to databases or directory services, or, but, but there is structure and there's quite easy to apply access management because you can say, okay, this role is allowed, and this is just read only, and this is masks and this is not visible.

This changes when you move to more unstructured data to big data, to SharePoint file servers, whatever. So you really have to have the ability to analyze and track and know where data is located just right now, when it moves from a to B and how it flows and how it is protected also in transit. So data governance is an important part as well.

When you, especially when data is leaving its original source system closely related to what we've seen before is access risk management. And this is really a part of applying risk assessment and understanding the criticality of access and authorization to use this information, to use this assessment also in the authorization process, maybe also in the authentication process when it comes to step up authentication. So really understanding, defining, and mitigating access related risks, but because in the end access related risk is a business risk and that's, this is what we see right now.

We go up one step in the hierarchy. Access risk is part of it. Risk and I access risk management is of course, part of it risk management. So we have a generic approach to controlling, managing and mitigating it risks with access, risk being, part of that. And one layer up, we have to look at enterprise risk management and the more we digitalize our processes, the closer access risk, and it risk moves towards enterprise risk management because in the end, an access risk is an it risk is an enterprise risk is a business risk. So you need to make sure that you involve it risk management.

And as that also access risk management into an overall enterprise risk management. So this was the first level of complexity because I just wanted to take the step back and understand that access governance is really something that should be seen in a more global approach within an organization. And that it is based on the governance as defined for the overall enterprise for the overall organization. So that was the first level. I promise two levels of complexity to add them.

So access governance has many facets and we don't look necessarily at all, but access governance serves some or maybe even all depending on the scope organizations define. And you will see that that goes beyond what we usually see and what I've mentioned in my first slide, when it comes to this traditional view, the traditional view is this static access, the entitlements and systems service and applications defined as roles, groups, whatever that is, what we currently, what we usually look at. But we also have to have a look at runtime access to these systems services and applications.

So access methods that are identified, defined, assessed, and granted, or, or not at run time based on, on, on authentication, maybe on attributes, but also on context. So this is something that is really different from this static access that we talked before. We need to look at authentication versus authorization in run time access sometimes authentication is enough because just having an account might be enough for accessing the system as a whole. Sometimes we have fine grained authorization in runtime access based on much more.

So we need to understand how a decision for granting or denying access is really executed at runtime. I've mentioned that before we need to look at all dimensions when it comes to structured data databases, big data, data lakes, and unstructured data, lots of them SharePoint as an example of file service. So in every form where data is stored, it needs to be protected.

It needs to be governed by the same policies as defined within the enterprise governance and trickling down to the access governance rules, that guidelines that need to be applied next dimension, privileged user access versus non-privileged user access. People usually think of the admin versus the business user. We prefer to think of high risk versus not that high risk when it comes to a privileged access because a highly privileged user end user business user might also be something that should be subject to privileged access management.

So we need to have a look at, with access governance also to privileged users and non-privileged users. So this dimension is important. We need to have a look at, at which layer of protection we are looking at. So if we are really looking at the data, which is actually the core of what we usually want to protect all applications and services as something that has its own access management and control in place, the system access the really the login, and maybe even the connection, the cable, the pipe that leads you to the system network, access and device access.

These are different dimensions to look at when we talk about access governance, we need to make sure that all the rules that we define apply also there. And finally, of course, with this digitalization and this move towards cloud towards hybrid, we need to make sure that access governance looks at all systems wherever they are, wherever they are located. So we need to make sure that we look at on-premises and cloud and hybrid and containers and whatever we want to look at and we need to look at.

So when we look at this complexity that we, that I've just described, we need to make sure that we do not miss the, the way how we can actually define and implement these policies, these rules, these guidelines, to providing access and to controlling and monitoring access. And what is often forgotten in access governance is that we need to make sure that we have a common language for defining and maintaining rules for access. We've seen that in governance, we've seen that in corporate policies that they are well defined.

Usually they are more or less actionable, or they can at least be used for defining the subsequent guidelines derived from them. But when it comes to providing for defining access governance and access management rules, there is often a lack of a common language. And in our opinion, as coping a code, we think that such a common language a should exist for defining and maintaining rules for access that should be independent of the actual implementation of access controls. I will talk about policies, but I do not necessarily talk about policy based authentication and authorization.

We need to have some place where we can find the rules, a common process for maintaining rules, a central repository for retrieving rules, for access, and a common source for creating the individual access control mechanisms across all systems, whether it be roles, groups, or anything else that is available on the market very quickly defining access policies. It's just adding four simple components. It's a subject it's me, or for example, wanting to do something in action. For example, reading or modifying a document, the resource would be the document within a system.

And we add context information. So the environment and all attributes defining it based on these four simple components, you can very easily define for different stakeholder groups. You can define the access policies that you require.

So the, the sales clerk needs to have the following access to the following resource at usual business hours. This is a simple access policy. That is something that can be communicated across an organization, no matter whom you're talking to. And that is something that can then later be mapped into a technical implementation when it comes to yeah, providing access within a system, we are keeping a call we think, and we have presented that in, in the previous sessions as well. We are thinking of identity and access governance as being a identity fabric.

So all the services that we need to give access to the individual identities, to the systems involved via their provided identities and via their actual access path towards the system, through a central identity fabric, a set of services that provides all these services that are required with being access governance, obviously IGA here in the, in the picture being a part of that. And of course we think that policy management should be something to include here as well. So policy management would be one service that is available as part of an identity fabric. It can scale up.

It is available for leveraging this as the source for defining access control mechanisms for the individual assistance. Be they in the cloud, be they federated or be they legacy on-prem or managed service providers solutions. So if we think of policy management, as one of these components, we can then easily end up with this following picture, starting with the policy management in the middle. And that is actually this central repository in the middle as one service, as part of the identity fabric and is aiming at translating between stakeholders and systems.

And I have mentioned also in the sub-headline extending the reach of policies. I think there it goes some quite, quite some benefit with this approach.

If we say, for example, we have the business providing their policies for applications, for their business processes, for their systems. And at the same time, it as one example, additional example for a stakeholder, providing their policies and their describing and maintaining their access management guidelines and rules. And all of this then is well documented, versioned maintained and, and reviewed within a policy management system. And then of course, policies don't make sense if you don't enforce them, then you do you move them towards the target systems.

And again, these are the ones that we talked about. It's cloud it's hybrid, it's federated it's on-prem, so that you really map these policies once well defined, then derived the right access control mechanisms from that towards the system. So we have one single point of administration and hopefully a highly automated process transferring that into the real life.

And I mentioned extending the reach of policies that is of course, very important as well then, because once we have defined these policies and do not define roles and assignment rules within individual systems where they are locked into a silo, we can use these policies and use them for different purposes. And that is where it really makes sense and where the benefit comes from when you use these policies also in systems that are related to this policy management AB, but at a different system with, with a, at a different level of protection.

So if there are policies that can be and should be implemented also within a firewall within an enterprise mobility management, within network security, fraud detection, data governance, sometimes it's part. Sometimes it's not part of, I am, depending on the scoping, we can then of course use this, these policies also in these systems once defined and multiply used. And of course, that can also be leveraged for going towards zero trust architectures. So policy management is really an important building block and it should be considered that we move that direction.

And I think I have four more minutes. So that leads me to the summary very quickly. It's very simple to say, think policies, but I hope I could convey the message that access governance at its core is about establishing, maintaining, and governing access policies, not roles, not technical mechanisms, but by defining, establishing, maintaining, and governing access policies.

So once they are understood as that, you can define, maintain and apply them and also implement them through, for example, role based access control, attribute based access or dynamic authorization, manage management, whatever you have in place, of course, automate that, make sure that this is done as easily as possible. So we have best of both worlds, central administration and central implementation. And all of this gives you a better insight and control into your rules, into your policies, and you can provide also evidence of what you are actually doing. And that's it from me.

I'm happy to answer your questions also in my session, in my speakers room, after this session,