Welcome to the KuppingerCole Analyst Chat. I'm your host. My name is Matthias Reinwarth. I'm lead advisor and senior analyst with KuppingerCole. My guest today is Martin Kuppinger. He is the founder and the principal analyst here at KuppingerCole. Hi Martin. Good to see you.
Hi, Mathias, pleasure to be back here in this talk.
Great to have you, and we have a, a topic and actually I have to read it out because, because it's too long to remember, and we want to talk about the need for policies and automation to secure your agile and dynamic it environment. There is a strong claim in there. Let's start with this need for automation and policies. How is this reflected and is this a new thing in it? Okay.
I think we can answer with CSM though here. So we see the tendency to automation for decades. We have policies around for decades in that's. I think what a problem starts in many, many areas. So th there are firewall policies. There are whatever automated configurations of system environments. There are a lot of things which are sometimes relying on policies, which are sometimes automated. But I think when we look at what is happening in, in today's, it, we are not consequent and consistent enough in using automation and policies across everything.
But when you look at this automation and the areas that you've mentioned, and that could be something that is an automated rule within identity provisioning, that could be something that a developer creates when creating dev ops environment firing up and shutting down and dynamic environments. These are different people. These are different responsibilities. It's really difficult. And, and really a challenge to get a grasp on what's happening across these areas, especially when you need to keep track of this. When you are a regulated environment, when you are a company that needs to prove in the end, what your systems are doing, where how can we attack or how we can we tackle this challenge.
Yeah, I think that, that leads us to an interesting, too, a couple of interesting points. And I think we need to deconstruct this a little. So, so when we, for instance, say defaults based microservices architectures, so services talking to other services, why API is why application programming, interfaces running on a container platform, such as keeping ADAS that again, runs on an infrastructure as a service environment, then managed by development tools managed. But you know, when you look at the iSTEM ops and then you see, okay, there are so many different tools involved already by a ton of dev ops tools. And with those tools change, then we have a couple of different areas. For instance, when we look at it from a security perspective, so who's allowed to do what in the dev ops tools chain with the various tools, how do we manage the resources or infrastructure as a service?
How do we secure the API based communication? How do we secure what is happening within the application itself and the privileged access to the application? So the entitlement and specific the application, as you said yes, to our various peoples being responsible for parts of the entire actual it, and there are various elements we need to secure. So, so we have to developers and we all know that many developers, maybe most developers are not very keen on putting security at the forefront, in what they are doing. They develop and security quite regularly, more than after salt. We have to infrastructure people and it's that? Well, the infrastructure as a service, it might be your own internal it environment if you're talking about. So it can run in different, different environments. It's not necessarily that you use your, your Coupa data is only in AWS or Azure or Google cloud platform or somewhere else. It might be that you run it in your product cloud or in your data center. So it's even bigger here. And that means, yes, we have quite a range of places where we need to manage and automate. And we have, we have different responsibilities.
The challenge I see is that I believe it would be naive to assume that someone can do everything. So you create the code and you create the scripts or the declarations that I'm sure that the infrastructure is sort of working group the way you need it for the application and you care for security doesn't ever work. And so we need to figure out ways how we can do that. Better. The challenges in a dynamic environment. This can be done manually by three different teams. So we ended up with the need for thinking, how can we do it better? And I see two elements of the answer, which are automation and policies that work hand in hand across everything.
But that also means that, that it organizations have to adapt to this different kind of thinking so that we, that you understand where policies are defined, how they are consumed, how they are enforced later and how these individual building blocks within an organization, not within it play well together that at every time these policies are understood, consumed, enforced, and really executed during the existence of infrastructure during the running of a process. So this really needs to change because everyone needs to be clear that the infrastructure be code, be it Docker container, Cuban leaders network is defined and designed according to the, to the current valid policies. And I think only at that moment, it's possible to get to this level of automation. So really people have to change their way of thinking that that would be one question. And on the other hand, what are we really looking at? I think the, the term entitlements is something that came up again, but an entitlement for me is the combination of identities plus their access. So no matter what kind of identity it is, there's always the combination of somebody, be it, a device, a process, something, and their ability to execute the access rights. And these two combinations on the one hand identity plus access equals entitlement and the management of these entitlements via policies and automation. That is the way we should think of, am I right?
So, so you're definitely ride for entitlements. So something, or someone is titled to do something, which is by the way, the, the foundation of every policy policy is a subject. So to someone or something is entitled the action to, to do something on a certain object. This is the standard structure. There might be 10 constraints edit, but at the end, this is exactly what a policy looks like. Every policy is always about this structure, regardless of if you look at the firewall policy or a dynamic conversation, policy and identity management, or a, I don't know, types of policies, it is always that's structured out different levels of policies. So for PI firewalls, we're talking about Paltz and IP ranges and stuff like that. And I don't know, levels we trust to say, all employees can access whatever this area of our corporate interactivity. So you use the term corporate intranet or something like that. So the level of berries, but the structure of the policies, the same, the interesting thing is I believe that the can in, in many areas we can derive lower level policies in an automated or in a defined manner. So automation based on certain policies drew, so to speak, we can derive lower level policies from higher level policies. We can automate a lot around that if we do it right. And I think this is, this is part of that. The other thing is what you brought up.
If you have a complex challenge here in all these entitlements and across the organization, I think this is, this is what we do in many areas of it over time. A lot of solutions in it came up because we learned doing it manually is cumbersome. It's inefficient, it's error prone. So wait a minute, go back to our, one of our core domains, which was an ID and access management, the identity provisioning girl evolved because creating accounts and assigning entitlements manually appear to be not the right way in large organizations. It was fine when you had one mainframe and very few users, the more applications, the more systems you have, the more you had to move into something which was automated. Unfortunately, maybe not as, at least formally policy-based as it could be. In fact, a role and entitlements are nothing else than some translation of policies into sort of entitlements.
But at the end, the answer was policies. The answer was automation. This is the same. When you look at tools in the network management space, when you look at other areas, it's always done trying to automate when you work with infrastructure as a code, when New York was particular to scripted approaches, in some ways it's, it's the, the try to shift into automation and it's shifting into automation. It might, in that case be more policy based and less scripted, less manual declarations, but that is a relatively simple step to do. So at the end, regardless of fixed areas, we look at it, it goes always to policies and automation are in some way a proven answer, but we didn't do it sort of consequently integrated enough so far. And to your point of organization, I'm not sure whether that, that I don't think this is a freelancer maybe, but I'm, I'm reluctant to say, we need to fundamentally change DIT organization here.
So we will not have people. Usually we only have very few people who understand all areas. So I understand security better than infrastructure management today's development. So my days of development are pretty much in the past. So I'm not a super expert in all three areas, you will rarely find people who are super experts in all areas. And so you can't build an organization that says, okay, people understand everything. So you need to specialists and you need to bring them together and make them work together. The question is, should you create different teams? But then again, how do we ensure that the way you deal with infrastructure, you deal with security as consistently across the entire organization. So, so I believe it's more saying, where can we automate? Where do we maybe even get part, least partial, rid of so certain requirements. So the more we automate the way we consume and view, you may not infrastructure, the less need there is for infrastructure specialists. So it definitely be a change, but I'm not sure it wasn't. We already must fundamentally change the organization.
What I meant with, with changing the organization was making sure that, for example, the dev sec ops does not have to know each of these three aspects, dev sec ops, but it's capable of consuming well-defined for example, security policies, to integrate them, to automate them without having to care too much about them, just to make sure they are there. They are enforced, they are well-defined and they apply to what I create as a, as a developer, as an operations guy or girl. I think that is the important stuff so that we really can make sure that the individual expertise of the individual partners in the game is leveraged at the possible highest level. And that things work together by achieving automation and by defining and making available well-defined policies for automation. I think that that may be a starting point.
Here we are. We are, I think, on a via query. I think the point is when you look at DevSecOps, which is a known term, but not a super well-known term across all the deals people, this definite sec also comes from, it comes probably more from Def sec than from sec offs in-depth terminology. So secure operations, as you curing operations, as to see, which is increasingly a whistle where, where new capabilities such as cloud infrastructure, entitlement management, come in say, we tackled this, this challenge of sort of secure operations in an agile. It S as a capability, which adds to just pick a picture. On the other hand, we have to sing and Def sec done, right? It's not about saying developers become the super experts in security, but it is about saying there are services to our APIs. So in fact, the arrest APS or whatever else, which delivered the security, the identity capabilities to be easily consumed in development.
So that developers trust you to know, okay, if I need to register a user, this is the way I do it. This is the way I also dictate a user. This is the way I asked for an authorization, but I don't care about the details. So, in fact, it's not about saying I, I integrate this, but I have a clear segregation where someone delivers the security and identity services, these poses API, as we have in our identity, February's paradigm, the identity API layer, so that the developer can consume that doesn't need to think much about it and has something that works well. And I think this is the point behind that, that we it's more about segregating at a right point, but policies thing can be something which sort of are a common clue because they affect all areas. And then the specialists are more about one to responsibility to translate where sort of a manual mapping manual translation file level to lower level policies that's required.
Right? And I think the answer to this massively evolving, getting more dynamic, getting more agile, have this it infrastructure that we have today. The answer to, to the issues that come up from that can only be the same level of getting more dynamic and agile when it comes to automating and providing the right policies is necessary to be as fast with creating policies and automation as the infrastructure and the changing areas of infrastructure required. As the, as we mentioned them in the beginning, from on-prem from traditional machines to dynamic dynamical infrastructures, like, like Cuban Nita's and Docker infrastructure up to highly orchestrated and, and really just a femoral infrastructures that exist only for a few minutes to cover some additional workloads. All this needs to be well-defined well automated. And only in that situation, you can deal properly with these kinds of infrastructures.
I would actually disagree with what you just said, because he said we need to be very dynamic creating policies. And at the automation, I think the point is automation helps us to deal with the dynamic nature of RIT. So the policies is relatively stable and at least at a higher level. And that helps us to deal with this. The then, then mimic nature of it. And it is it's the same. We, we have seen an identity. So when you manually manage all the aesthetic entitlements, it's very hard to follow the actual about nutso super actually later of an organization. Even the, the more you go into policy based access, the easier it is to follow a change because changing a policy is relatively simple, changing hundreds of roles and tens of thousands of entitlements is way more complex. So I think it is to, to, to cope with, with the dynamic nature of it was the of today.
And also the that's the other side of the things, the complexity of the environments, we need a higher level of policies and automation, because you're not just talking about infrastructure as a service. You're talking about so many different environments and going back to my analogy of identity management, and you had very few systems where you need to manage a few users, it was simple with every additional application and sort of a growing number of users, the problem of running harassed, because your people aren't able to manage this manually anymore. So there was a need for automation and twists, a decree of policies, maybe not as mature as it is today, or could be, but at the end, it's the same story.
Okay. So now we've come full circle to the beginning of this episode. So we are again at the need for policies and automation to get a grip on the agile and dynamic nature of it infrastructure as of today. So I think that's a great point to stop this episode and to catch up on that again, in a further episode, when it gets to creating more tangible solutions for getting to policies and automation in real life systems. And to talk more about that in a further episode until then, thank you very much marching for being my guest today and looking forward to the next episode coming up soon. Thank you. Bye-bye okay. Thank you.
