Unleashing the Power of Automation in PAM

Hello everyone. So my name is Ivan, though you'll see a Baja but you can pronounce me a P and I am working as an I am Lead for Delivery Hero. The title for today's topic is Unleashing the Power of Automation in pam. And before even starting, I would like to know how many are already having or using a PAM solution already in the organization. If you could just raise your hands.

Oh, so many. That's good. That's really nice. And so let's start. So when we say what is pamm? So PAMM is a discipline which deals with the management of privileged access. And when it comes to privileged access, generally people say as per their convenience. So the definition could be really varies from organization to organization and from individual to individual. And the easiest way to understand is that any permission, which is more than a standard or regular permission and when compromised can lead to breaches.

You know, critical systems outages, revenue lost reputation damage, E-T-C-E-T-C-E-T-C, that can be termed as privileged access. And PAM plays a crucial role in managing and controlling access to the mission critical systems of the organization, sensitive data and the assets. So today we are going to explore how traditional approaches have shaped our past and how modern challenges are now going to redefine our future for pam. So here we have, yeah, I made it. So we have traditional approach versus modern challenge in terms of four different aspects.

And if we take a look at the aspects, the first and foremost is processes. We know that traditional PAM processes all solutions. They rely heavily on manual processes for managing the privileged access. And now the challenge we have that most, most of the modern IT environments, they require more dynamic processes. And in terms of scalability, also we have noticed that the traditional approaches may struggle to scale efficiently, especially when there's a, you know, large IT environments or complex IT environments comes into the picture.

And the problem with need is that we need to adapt to the scalability demands of the cloud services. Everyone is using cloud and then a lot of apps, be it internal or other stuff. And then the dynamic infrastructures concept that we have and the next one is agility. Now the traditional approaches, they relies heavily on the manual processes. It's pretty difficult to be agile and because of the static controls as well and what we require, we require more dynamic and flexible approaches to adapt to really to the changing rapidly changing IT environments.

And last but not the least is automation. Since we are heavily relying on manual processes, we cannot expect too much automation in the traditional approaches, which is leading to operational inefficiencies. And what we need is we need an extensive automation so that we can streamline our PAM processes and can go ahead with the operational efficiencies. So now we can see that traditional approaches were amazing, they worked really well for us in the past. But for these modern challenges we need modern thoughts, we need modern approaches and what one of them would be Pam as a code.

So Pam as a code basically is a phenomenon for managing privileged access management as a code across environments and what it says. So we can then achieve consistency, reliability, scalability, and auditability, all those flavors which is backed by a version control system and what exactly PAM as a code involves. So it involves, we can really define any different kind of privileged access policies. We can define any number of target system.

We can define account onboarding of boardings, configurations, all kind of workflows and that too as a code artifact that can be versioned tested and deployed. So this is the journal idea and funder behind what exactly is a PAM as a code. And let's go into some of the benefit which offers in terms in place of traditional approaches. So here you can see there are numerous benefits. First of all, you might have been aware of using I-A-C-C-S-E, Pam C, so all those more or less the same benefits.

But if we'll take a look into this, as soon as with a PAM as a code, we can have all the configuration in the code repositories like it. And we know that this serves as an amazing version control system. So we can really see, we can really track whatever the changes has been happening and if we want to revert to any previous change, we have all the history, it's just two clicks revert back. So we do not need to go on the UI and do all those changes and try to remember the mind or take out some of the confluence documented. So what was the change?

And it allows us to be really more consistent across all the environments. So now we can no longer give the excuse, oh my production environment is not a replica of staging or my staging has different stuff than the production, the configuration changes. So it might take some time for me to do all the things. So we can easily remove that. And with this we can really use extensively use the automation to get rid of the all the manual overhead manual tasks that we are having.

And it allows us to be more scalable and flexible with the growing needs depending upon whatever the scenarios or use cases we can just simply scale it. It's that flexible and having all the configuration as a code within your repository serve as a much better self-serving document artifacts. Then go in the UI and try to find something, oh what is in my organization? What are the policies I have, what are the configurations I have, what kind of accounts I'm having? It's much easier, you see it in the code.

And then there are too many open source codes or tools which can allow you to even expand this in a documentation form with Pam as a code. Now we can put all the security controls and compliance requirements directly into the code. So whatever we want to have, it'll be straight away shipped right from the code, not something afterwards. Now we can rapidly deploy depending upon whoever and whenever somebody want to deploy the changes. And another benefit is that we are having enhanced collaboration.

So now instead of one team or the team members inside who are focusing on this, we can have now another different teams, different departments all over the world, all over the place. The organization can really work towards the same goal in this case. So there's no dependency, it's much more cost efficient. We can either the resources, we can utilize it effectively and then it provides, it proves to be more resilient. So if something bad happens, hopefully that shouldn't happen.

But still then if we have everything in the configuration we can quickly come back to the place we we where we were in case of any disasters. So these are some of the benefits of the payment code. But now let's take a deep dive into our magical recipe, which is PAM as a code. So here we have a PAM solution and generally within the PAM we have a different requirements. We have different requirements coming from different stakeholder, different sources, different personas. So here one of the stakeholder is IT admin. So now IT admin has some requirements. So let's see what are the requirements?

An IT admin has pretty simple. So I say I want to on onboard my servers and databases. So this is the requirement of one of our persona stakeholder, IT admin. And then we have another persona or is compliance and assurance team what compliance and assurance team, what are their requirements?

So they want to ensure that the PAM policies to comply with regulations as an example, they say oh if you have a certain banking license or something, and this is financial data, I wanted anyone who is accessing that account, the password should be immediately changed, but for some others I want after 90 days. So these kind of policies is actually the compliance and assurance team. They are the best persons who knows this. So this is one of the requirement. And then we have a PAM admin.

And the PAM admin really want to have the consistent config across the environment so that no one would come across to him that hey, do this too fast. And then they can say I don't have the same config. So these are just some of the personas or stakeholders we have. And in between we have Pam as a code sitting and now what we can do, so they all can simply go to PAM as a code with their requirements and then Pam as a code will deploy their requirements directly into the pam. So we can see this is much leaner process and how it's helping us.

So if you notice this is completely based on DIY templating approach means do it yourself, we provide you templates, it's simple in English, plain English, just fill it up and then it'll work as it is. And now we are actually empowering teams to manage their ED access scenarios by themselves, unlike the traditional ways where all those requirements will go to the PAMs team and PAM team will take into account, okay, these are your requirements and then they will go into the PAM solution, implement that and let you know. So we have now removed all the bureaucratic process in between.

Why is that bureaucratic? Because it's taking too much time, it has to be lean. So here we are now empowering application honors and because of that it's providing much more flexibility and scalability for managing privileged access.

Now it's, it's goes back to the application honors themselves. And so this is how our magical recipes, but let's take a look into the process which is working into the backend. So in the backend, this PAM is a code process completely works on the change management process.

So we, we have a change management process and it's in this whole change management process it'll have three blocks. So it has a change request block, it has a review process block and it has an apply process block. What would happen in the change request block. So any team, they want to bless you, any team who want to have their scenarios covered, they simply go to GitHub, they open up simply a pull request with their requirements, they submit this and this will go to the review to the PAM team as simple as that. So this is the change request block.

And now once the pull request has been opened and it'll notify the approvals of the PAM team, it'll move to the review process and what comes in the review process. So in the review process now Pam team who was doing all those things earlier by themselves, now they are working as more like an enabler. So they enable the other team. So they will review the pull request and then they will see okay this is the pull request, what is this about? Should I approve this? And if they approve, this will merge to the main branch.

And once this merged to the main branch, then the request will move to the apply process And what is in the apply process. So in the apply process, once the change has been merged, the CICD pipeline will trigger and this CICD pipeline will apply the configuration, verify the changes in PAM and the change will be applied successfully. So this is as lean as process is this. So completely change management process.

So apart from this we also when who are are handling PAM team or PAM requirements, we also come across situations where we need to, you know, onboard and offboard multiple accounts for similar type of applications. And it is a time consuming and repetitive process for each and every application. And this is a problem because time is money. So we need to utilize our time better in those things. So how we can resolve that problem is basically by using automations. So I always say this is a magical pill, it's automation, automation and automation. The more you can, the more we'll do better.

We have also came across similar kind of requirement or challenge. So let's take a look into the landscape complexity. So we had more than 200 plus internal apps and they are similar kind of apps, exactly similar, it's just permissions inside. And each as app has its own set of permissions. And again because they are completely depends upon the application, each app again has its own definition of privileged permission and what is the requirement we have. So the requirement is that we want to enforce spam control only on the privileged permissions. And then where is the problem?

The problem is the dependency because now we have PAM team to onboard and offboard accounts for privileged permission for each app. It's the same repetitive process and how we did this. So we created this solution. So in this you can see, okay, I wanted to create a laser.

Ah, so in this, as you can see there are two scenarios we discovered. So one is tole privilege permission, other is access request and what is tole privilege permission. So in this case what we realized that we have an app. An app has certain permissions and when any permission has been promoted or selected as or maed as a privileged permission, then the automation will trigger and then it'll automatically onboard the accounts for the users having access to that permissions and also provide the access in the pam.

So this is about providing access and automatically creating, but there might be chances, there might be scenarios when a reevaluation of risk happens and then they say, oh, now we realized for this application this privileged permission does not qualify or no longer qualify as a privileged permission. So what would happen in this case, again the same thing. If the permission has been demoted back to standard permission, then we have the automation triggered and this will offboard automatically the accounts consequently of the user having access to that permissions and and from the PAM system.

So this is Google privileged permission scenario and then we have access request scenario. So now we have an app, we have a privileged permission. A user can request the access to a privileged permission either by themself or via a role. Something has been a role has been assigned to them that will give access to that permission. So in this case also automation trigger and it'll onboard the account for that user automatically into the PAM solution gives the access.

And now there is another scenario, what if if now user loses the access and when a user can lose the access, either when a user is changing the department or user is leaving the organization or an access request campaign occurs. And in that access request the certifier say now you do not need to have, you should not have access to this permission anymore. In this case also automation triggers and then this will offboard or remove the account for that user from the PAM solution and consequently the access.

So here we have seen everything is happening automatically without the human intervention and this really allows us to outsource the concept of privileged permission to the application owners. So now instead of in the traditional way, the PAM teams understand and take the knowledge from the application teams, they are the ones, it's now been outsourced. So now they are the one who know about this, what a privileged permission is in their application.

And again here we are empowering application owners again to take control of access within their application owners in their applications because in the end the application owners are the one who knows about the application more than anyone else. So who we are the IMO PAM team.

So we go, we try to take the knowledge from them, but in the the end they are already knowledgeable and qualifiable peoples and and then this process has no dependency on PAM team to onboard and offboard users manually. So everything is happening automatically. And this approach also goes back to the application owners where they can sense, feel the responsibility that you are the one who are ultimately responsible for access control within your applications.

So with that, if we take a look into some of the key takeaways, we know PAMM plays a crucial role in securing organization for managing access to the mission critical systems and data. There is no doubt about this. And we also know as organization involved we need to streamline and automate the PAM processes and adopting pamm as a code approach can really help. So then we can reduce the manual overhead compliance risk.

And we have seen that how automation is essential for modern organization so we can manage our comp complex spam processes scenarios efficiently in this dynamic fast-paced environments. And with that, I want to take out to the one of the most important slide of this session.

It is, thank you very much. Thank you very much for coming. Thank you very much for listening. Well thank You very much Abby. As usual questions from the audience? Yes we have. Hello. Thank you. What vendors support the coding of your pam? We did all the coding.

So what, that's why we said Pam as a code, what you simply need is the API support if the vendor has an API support and even in the really best case scenarios, if they support Terraform, then they are doing your job already. So that's why we're going with the pam because we are just seeing in the end you either needs to have the full APIs from the vendor or you need to, in the best case scenario just needs to have the Terraform modules existing. So we deployed similar kind of thing for Okta already. And this probably I'll give to the next, next QA code presentations.

Yeah, I have one question. As you are communicating through the using of the API, right? The requirement is not always from the application owners, they are the people who knows about the privilege accesses. Definitely right? But over the time you have a like a lot of standards change and a lot of compliance and Yep. And a lot of things that you transform in the, IT doesn't, it creates a lot of technical depth over that time on that automation. And then you have end up managing a monster even using the, with the PAM itself, That is exactly opposite.

We are, we are doing, so in this case it's actually much more simple. So application owner doesn't need to know any, anything about this. A whole business logic actually sits in the repo. So it's like a plugin, plugin approach. Something changes, you just change, you have your YAML template versus why I am saying YAML templates is we are using YAML templates. YAML is much more easier to understand for the, for the end users or people. So these are simple templates just fill in and the process will remain same. It'll be taken out from the backend.

Yeah, But I'm not talking about the template part. Template part is the one that application owners is seeing it, right, but over, over the behind where your developer is doing the, like the whole code, right? Yes. That needs to be modified and even if you're using like the whole CICD pipeline and merge and everything else, right? Yep.

Doesn't it just increase the code over the time because of a lot of changes happening and part of it I, I can just directly use that part to my, since we are already using PAM tool, I can allow PAM tools to automatically identify those things instead of doing the changes in the first in your code and then a through API sending to the PAM solution itself. It's always, you need to understand the changes. It's not the two ways thing. What we want to do, you should not be doing the things on ui. This is what the traditional approach is.

What we want is the, the, the developers I or the PAM teams, they needs to focus on providing the values and where the value is to empower the teams, not by doing the same work over and over and repetitive work again. So this cannot provide the value. The value will always be how we can provide the resources to the end user so that they can feel by themself. Let's do it by ourself. Okay. Awesome. Well thank you very much Abbi. And thank you very much for the sake of the.