Come to the KuppingerCole Atlas chat. I'm your host. My name is Matthias Reinwarth, I'm an analyst and advisor at KuppingerCole analysts. My guest today is Martin Kuppinger. He is founder and principal analyst here at KuppingerCole. And today we want to talk about policies, access policies, and maybe also about why roles. Aren't really not the way to go high margin. How much? Yes. As I mentioned in my introduction, um, roles are not the way to go. Why is that?
Maybe this is a little over the top, but if we want to use roles, we need to start things differently than we currently do. So, so when we look at the reality and it, it is, I would say a simple fact that most road projects struggle in some ways, some totally fail some take longer than expected. Some don't deliver it to the room. The expectations that have been raised at the beginning, I would say probably all projects I've ever seen. And I've seen a lot were cumbersome in some way. And I believe there's a reason for that. That reason is pretty simple. At the end, we're starting at a wrong point because a rule is a technical artifact and artifact contains artificial. It is something which has a construct and people need to understand that construct and you need to deal very properly with these constructs.
And when you step back, you come to the point, what do we really want to do? And what we really want to do is we want to control this roles. As groups has other artifacts, we want to control who has access to what? So at the end, we're looking at this simpler question, for instance, saying, okay, all employees are allowed to access certain parts of the corporate internet. If they're still an intranet users in the finance department and within the finance department and bookkeeping doing these business tasks are allowed to do that. If for instance, they have a certain shop level and all these things are nothing else than access policies. They're saying someone or a group of people or some something can do certain actions on certain resources under certain constraints. And my perspective is, if we start this access policies, we might then derive roles out of that. You might derive a lot of other things out of that, but we have a very simple to understand, very easy to understand construct, which is understood by business, which is understood by a team, which you can relatively easily normalize as well. And that is what people understand that then you would be successful. And if Rolston are an outcome, that's great, but they are not the starting point. The starting point for, I would say probably everything at least most we do in security are access policies.
So if I understand you correctly, many organizations are looking at managing their access and trying to get a grip on access governance by talking with their business about roles. So this, I have learned in my experience as well. It's really not the right starting point because just talking about roles, this static kind of access is not enough. So how should policies then look like what are the aspects that influence such a such policies? It's more than just a job position.
So let's start. Maybe it was another pod you mentioned. Yes. They're talking about complex artificial concept. And I think talking about roles, it's a little bit like, um, having good doctors, throwing Latin terms on you without explaining what it's really about. So it's, it's really hard, hard to manage. And when I look at access policies really look at it very generic. It is a subject. So you can describe because as an organization, entity, as a individual person, as a group of things, as whatever, so the subject can be a lot of different things. Then that's the action which can be put out our actions required past the firewall access system, delete data in a certain system, access, highly critical information in the finance department, whatever could also be approved and address things. And then there's a resource, something in it from a system to file to whatever and our constraints.
And at the end, yes, there might be for instance, organizational entities for use, there might be dropped descriptions, but there might be also things like constraints such as, okay, approvals only up to 100,000. All of these can be very well expressed and natural language. So policy has a certain structure, which is nothing else than at the end natural language expression. And it is something people can describe it each and every level for what they do. So people who are very familiar with traditional firewalls will probably think in certain IP addresses, passing or not passing through certain ports, this business departments, it will be a different level of description, but it's always the same structure. And this can be very well aligned and you can run conversations at each and every level without people needing to translate complex concepts, artifacts, and terms, but really using their weight to express their domain. Right. And from what I've learned,
Many organizations and many it departments still think when they think of roles as system specific roles, if you think of a large system like an SAP system or any other large business supporting systems, the roles that are in place are usually managed at a system level, which we do not endorse, but which is the case. So these roles are defined specific for a silo. So the information that is spent and invested in defining these roles, and maybe also getting to assignment rules for these roles, it's really within a silo. If we think of policies, I think that is also the opportunity to change this, to have policies in a central place available for more than one system.
It doesn't mean that you can't work with policies for a silo. So at the end, the roles in the SEP silo are based on X policies. Only that no one starts with the list of access policies. And from there derives the roles ever everything, but they start with complex artifacts and, and people need first to understand, oh, what is the role and how do I deal with roles? And that makes things trust more complex at the end of the day. And so you can use policies everywhere and you can also have some hierarchy of policies in some way where you say, okay, this is really my business perspective at any add-on, but they are a unifying concept across everything. My illusion to some extent is that we say, okay, we have this access policies. And then we start deriving sort of technical policies or technical implementations of what the policy says as automated as we can think about having an X policy, which then leads to tactical ACL controls on a windows server file system. Um, think about policies which are about only our employees are allowed to access our wifi internally, which doesn't make much sense, but just as a sample that could lead to automated configuration settings for all the components of your wifi network of other network security components, even of endpoint security. So there's a lot of potential of automating security controls by translating the policies that would be my vision. And that does some, we also our requests to vendors to move forward to that space,
To get to a central common language that is understandable for, for humans and for humans of all, um, profession within an organization from it to business and also for finding, um, access and ma uh, rules for, um, yeah, for devices and, and everything else. So it's really a common language that is then used, as you've mentioned for deriving, ideally in an automated manner, the actual access control mechanisms as they are relevant across all systems,
I would see it a little different, honestly, I would say the, the language to use language to use, so to speak regularly, speak in a certain structure, describe who is allowed to do what so to speak that then can be transferred into a defined structure with sourcers, the action subject or subject to resource that way the constraint that might be done by people supporting them and that's them my personality and should result in sort of a standard structure. But overall they're relatively flexible because they're the sort of the unifying concept is really this. I would say well-established and Wella agreed structure of how does a policy look like with the subtract and on the action and resources, et cetera. And then I think we don't need to put too much effort into this is the standard, because this is easy to translate between various levels between various systems. And we specifically must ensure that we don't say okay, to do access policies. You first need to learn and abstract language such as some tries to do with XHTML LT, extensive Lexus control markup language, which was too complex. And at the end people trust one or to describe who's allowed to do what
Right. And you mentioned that it's also a request towards vendors or at least, um, yeah, making sure that this can work. So we are not yet, there, there is not yet a, a solution that would be capable of storing of maintaining these then translated, um, access policies.
I would say we have a couple of elements. So when you look at the space of dynamic authorization management, so we're excited, same, I will have to later an important role a while ago. We see a couple of vendors. We see a couple of layers who provide some types of policy management. We have well-established, um, tools and concepts around policies when we go down to file walls, et cetera. So I think we have a lot of elements there. We use policies in every web access management product for tens of years and many other elements of security. I think it's an understanding that we need to get out of these technical silos and that we need to sort of the business level of defining such policies and the mapping between these layers, which sounds less. But I believe it's not really a rocket science because it's all around a very simple concept of the policy.
And my recommendation would be the first thing is to end users start your own project and call it something like an access management or access governance project roles are trust an element, or might be an element, not necessary need them, but don't start as roles, starters, X polishes, and that they arrive. If you want to work with roles to arrive to rules out of them, major recommendation would be to do vendors, rethink what you're doing and think about how you could shift to better use of access policies that can be expressed in the language that you users are used to and where they are, which is easy for them ever since close to natural language. That's it right now, fully agree. I, if you, first of all, have to make that step towards abstraction that always hinders the actual input from, from those who know from the stakeholders.
And just a simple sentence that states, uh, HR people are not expected to work Sundays after 10 in the evening, um, that can be easily transferred into a policy which defines working hours. Um, so it's really just getting the input from the people who actually know and translating that into its simple policies that then can be used for defining access control within individual systems. We're getting closer to the, to the end of this episode. Um, I know, and I, um, would recommend that the listeners can go to our website to look for more information about how to do access management properly, any recommendations from your side Martin. So I think there's a very good recording of a keynote you did just for one of our KC life we went through recently, we will publish a updated report of excellence or redefining access governance. Very soon, we have our leadership compass on access governance for us to name, trust a few things. So I think it makes a lot of sense to get a KC plus license, which was very access to all of our research. And there's plenty of stuff around all these topics available, right? So, so that's it for this today's episode about, um, access policies about using more user centric, common language construct for defining and maintaining rules for access. Thank you very much marching for joining me today. And I'm looking forward to having you in an upcoming episode. Thank you for inviting me and welcome. Thank you. Bye-bye
