So this morning, morning, afternoon, evening, I'm going to be talking about some of the best practices for a Pam deployment. My name's Sean Kennedy, and I'm currently the director of enterprise identity access management strategy at the Royal bank of Canada. So without further ado, I will get started. We're gonna talk about some of the decision drivers. What is the why, how and what you would be considering if you were looking to add Pam as a control within your environment, or if you're looking at changing the current Pam control that you have, there's, there's a lot of things to consider in that space. Obviously, if you're going to look on the market for a new tool
To protect within your organization and, and, and how you're going to go through that, obviously the, the subject of the conversation is best
Things to look for with the product evaluation. And then once you've completed your, we go through a number of best practices. We would be talking to looking at things to consider as you move forward and then wrapping it all up and, and leaving a little bit of time for questions. So before you're looking at moving forward with any Pam project, you often, you, you need to consider the biggest three questions as why, why do we need Pam within our environment? It could be regulatory security or operational, or all of them it's going to be an environment are very complex. And one of the things that we need to make sure that we are looking at is the things that we're trying to use Pam for. So operating systems, network, devices, databases, and applications. There are now a, a huge prolific disbursement of web-based and bin interfaces.
And as well as system to system calls, as mentioned in previous discussions today, looking at the DevOps world, it's a different world out there. And how is Pam going to adapt and help you in that space? The thing the other thing to consider too, is what capabilities are you looking for or features there, there are a number of features and most of the Pam products out there supply a similar line of features, but there going to be, have their own specific little differences. So are you looking for specifically credential management? Do you need session management to make sure that you're not exposing credentials? Is it to help with change management? Can you integrate with change management to ensure that those are, are just in time, sort of access is provisioned for those accounts? And then what specific technologies do you have within your organization that are critical and need to be protected?
So looking in a little more detail into the why. So we were, we're looking at reasons for implementing Pam. They could be regulatory in organizations that are operating globally. There is a number of regulatory requirements that are going to be affecting you, not only in your home location for your business, but wherever you have operations around the world, they may be different requirements that you need to adhere to. So those are things that are very important to consider what you're looking at this. And it's often a major reason why you would be implementing Pam to protect those critical assets and data from cyber attacks. The other reason strictly speaking is security. It sort of ties into the regulatory requirements. You wanna protect different areas within the organization with different levels of security. You wanna make sure that you're maintaining an agile environment where the people that are doing the day-to-day work can indeed do that work well at the same time, you're protecting the things that matter most the other area to think about is operationally.
If you need to ensure strict change management for what's happening within your organization, app, applying Pam and access to privilege credentials is often a very good way to make sure that you are maintaining your change management controls. How are you going to use Pam organizations both big and small will have a large number of, of different technologies that they're using to deploy services for both their employees, as well as for their clients. Those will all have some sort of infrastructure. There's always likely a database and then applications. So we look at the three tiers of what it takes to provide services, both for your employees and your clients and seeing which ones of those are the most important. And, and often, oftentimes you have a single application that will require all three of these in order to run properly.
What is it that you're looking to implement, or what capabilities are you looking to add to the environment? The number one obviously is credential management. Being able to have a system that will change of credential after it's been used, or after a period of time where it hasn't been used, but it's onboarded to your Pam tool. You want to be able to have that ability to demonstrate that to both auditors regulators, et cetera, or even just your operations team. You want to be able to show that your passwords are secure because they're being rotated on a regular basis. The second capability that's often high on the list is session management. This, this enables you to make sure that you're not going to be exposing those critical credentials to users, and they're getting connected directly to the assets in which they're trying to manage that ties closely with credential management. You usually have both enabled at the same time, and finally is the integration. So what are the different technologies within your organization that you would consider critical? And I'm gonna get into this in, in a few other, a few future slides, but it's very important to understand what technologies are within your landscape and to ensure that you're looking at those when you're out assessing different vendors or different technologies to use for Pam.
So understanding the why, how, and what we can start to understand where the gaps are and what it is that you're really trying to address. And this is very critical. And it's been mentioned by another, a few of the other speakers to understand what your landscape is. I is really foundational to moving forward with any type of implementation of Pam inventory of applications. It's often large organizations will, if you don't have a centralized inventory of applications, you're not even sure what it is that you're trying to protect. So it's, it's very important to gather that inventory of applications within the applications, you have infrastructure that's supporting those, being able, allowing those applications to run. And even further is the processes that are associated with running those applications. How are people accessing systems? How are they supposed to be requesting access? How is that access managed?
And finally, you know, very key to understand what you would look to onboard is understanding which privilege accounts are out there. So that's very hard to find. And often it's subject to interpretation. Some person somebody might call one account privileged, and the other person says, no, that's just what I need to do my job. So it's really important to have the, that conversation and sit down with the SMS and understand a, a real definition of what it is that's considered privileged as you're moving forward, taking that inventory. The next phase is you're gonna do an analysis against it, make sure that you, you use that inventory to understand what is critical and prioritize, what needs to be included in different phases of your program, implementing a Pam solution. Isn't something that you're gonna do in 30, 60, 90 days. It's usually going to be run over a two to three year period and having an actual strategy for that is going to be very critical. But, and that first part of that is making sure that you're classifying assets and accounts in terms of how and when they should be included in that and onboarded. And then, excuse me, lastly, understanding the requirements to map the capabilities that are required to implement the solution.
Sometimes one of the things that gets left out or missed is an understanding a again, going back to your inventory of processes is you may have a group of administrators that are doing a da a task or their job on a daily basis, out of a group of 10, you may have 10 or 15 different tools that they use. So understanding how to include those in the plan or to rationalize those. So that you're streamlined again, I'll, I'll talk about that in some of the best practices later, the do's and don't, but understanding how you're going to do this with a, a very big focus on not disrupting the operation. It it's very critical. And I've heard this in, in the other speakers speak about this is that you don't want to be disrupting the operation, and you also wanna make sure that you're using the benefits of Pam to ensure that you're going to have a valid result and a successful program. If you implement a Pam program and nobody's on board to onboarding any of the accounts for this reason or that reason, you basically won't have any success.
This is just a very small number of things to consider. When you're looking at vendors. I, I highly suggest that if you are looking for either a replacement Pam solution or a net new Pam solution, that you can conduct an RFP, the one that we had put together included over 234 questions, I believe, and you know, it from all aspects, all sides of the business, we wanted to make sure that the privileged users themselves were able to supply questions and get answers to ensure that the product that we were choosing was going to be the best fit for our needs. It's not gonna be right for everybody. But so one of the things, obviously from your inventory supported technologies that are part of your ecosystem. If, if you have a vendor that only supports one out of seven of your main platforms, it's li likely not going to be a valid choice.
I'm not gonna go through all of these in detail, but the depth of capability supported again for each technology, there's going to be a level of support provided by the vendor. And there's a list of these here, vendor alignment to organizational roadmap. So we've seen the conversation about DevOps. The look at zero trust is becoming a very big component, especially now with remote workers and remote access. We can't necessarily think that all of our administrators are going to be able to be on the network at the time they need to solve a problem or get on and solve a critical issue. So those are different capabilities on the vendors, roadmap that you need to see, how is it aligning with what we have in our plan? So this is not just the identity people working together, but it's often BCP as well as network, as well as security, making sure that the capabilities are going to align and mesh together, high availability, architecture, and performance.
Obviously, if you are protecting the keys to the kingdom, that that solution needs to make sure that it's going to be as available as the most required application on your, in your portfolio. So if you have a four nines portfolio of applications, you need to make sure that you're going to have an implementation. That's going to be able to support that integration with other security tools. Again, most organizations have some other set of security tools. You are gonna wanna make sure that you're not going to put the, the white duck in a room full of brown ducks, and it's not going to connect or, or join with anything. So looking at your IGA tools, any MFA service that you're looking to implement, because it's highly suggested that you use MFA when accessing Pam, and then again, as well, any authorization services that you have within the organization that are enterprise level, you'd want to be able to integrate with that as well.
So the other thing that I always found interesting to look at too, is a history of patching and releases and, and the, the volume and size, the patches that are being released and the schedule for which those are being done. That's going to affect your, your operational teams, because if they're getting a security patch on a weekly basis, and it's, that's the only time you can deploy it, you're gonna have to continuously have an operational team that's deploying these single updates as opposed to bulk updates that perhaps are released on a quarterly basis. But again, as I mentioned, there's, there's a good 200 or so questions that you can put together to make sure that your vendors are, are answering them and meeting what you're looking for.
One of the things that's very key and it it'll come up again in the conclusion is, is when you're planning your Pam implementation. There's really two different ways that you can look at it. You can look at all of the applications, I'm gonna start at the bottom here. You can look at every application within your database, your, your application database and say, these ones, these top five are top 500 are critical, and we need to onboard them. If you were to go and dig down and look at all of the privileged credentials that are associated to that, those individual applications, you're gonna be touching thousands of pieces of technology or thousands of database instances. And, and it basically becomes a very high effort for very little result, because you could still have another 5,000 applications that, you know, you want to onboard eventually, but simply because you focused on an application level, you're, you're really gonna have a hard time getting there.
The opposite of that is looking at an, from an infrastructure perspective, is can we cover off if you're majority of your platform is running on windows or majority is running on Unix. If you were to take those privileged accounts associated with the platforms, what you're gonna end up doing is you're gonna have a little bit of coverage for every application that runs on those platforms. That's why, when you're looking at, you know, the there's two different methodologies, one of them is go wide, which is what we're talking about with look at the infrastructure, the platforms, the networks, the databases. If you can incorporate those quickly, you're going to have a large amount of coverage across all your applications. If you go deep, which means you're gonna look at individual applications and you're gonna cover off all the privileged accounts associated with each one of those, it's gonna take you a long time to do it. And at the end of the day, you're likely gonna have minimal coverage.
So a few the lessons learned, or the dos and don'ts that I've seen in a few implementations, access control is the key to getting your privileged users board and, and giving them access to the credentials. One of the things that you want to make sure you have is for, for two reasons is you have an authentication una authorization service. That's very specific to Pam. If you are using a authentication service that is dedicated or used as an enterprise service, let's use active directory, for instance, any compromise of accounts or compromise of that platform itself can inevitably give access to privilege credentials within your solutions. So from a security perspective, you want to have a dedicated, authentication authorization service for Pam. And secondly, if you have a enterprise level platform being used for authentication and authorization of your Pam solution, a lot of the critical accounts that are in that or onboarded in or held within that platform are going to be difficult to onboard because if it's not available, those accounts aren't available.
So it gets into this cycle of, of, you know, it, it's not gonna work well. So it's, it's often recommended that you segregate those with respect to onboarding and migration. Make sure again, going back to your, your, how and whys, understand what the criteria is as to why you're onboarding accounts to Pam. There are so many different pieces of technology within an organization that do not necessarily require the same level. So you, you're not gonna measure everything with the same stick. You need to make sure that the critical accounts associated with your critical infrastructure, your critical applications, your applications that are governed by regulatory and compliance requirements are all covered within your criteria for onboarding. And after you've taken care of the major ones, then you can extend your onboarding strategy to include the less secure or less, I guess, important. It's hard to say less important, but the lower security applications, making sure that you're creating policies that are not constricting your operations teams.
So understanding who does what, when, how they do it, including a list of the tools that they're using to implement and, and secure the environment, as well as maintain, update, and resolve issues. That's very important in understanding, making sure that you you're implementing things in the capabilities and tools in the right way. You, we can't just assume from an identity perspective, if you're coming from the identity plane that you understand how the Unix or the windows or the mainframe or the database teams operate, you need to get in there with them and understand what their requirements are. It will also help you when it comes to the adoption side of things at the same time, understanding what they're doing. You can also explain to them what the benefits are and how this is actually going to protect them from issues related to outage or investigations related to any type of attack or, or leakage tools used for supporting the systems and applications.
This sort of ties again, into what I was saying about the policy design, many different operating teams will have their favorite tools and how they're going to operate and use things. This is going to be a bit of a struggle because you, what you're gonna want to do is consolidate that if you use every single tool that every administrator is using, and you're enabling session management, those, those types of integrations would all need to be updated. Every time there is a new release or there's a new tool, a, a new version of the tool, and it becomes very operationally and efficient. So working closely with those deployment or operational teams to, to consolidate the list of tools that are gonna be supported is, is a key thing to start focusing on early in the program, without a doubt, MFA is a requirement of using privileged access using a single credential, whether it's username and password or, or something else is not going to be secure enough, using MFA is always required because you wanna make sure that the person is who they say they are, and you can't just rely on credentials for that.
And then the last thing is planning for what's next in your roadmap. So we, you have to, as, as a Pam team or a, a, you know, the ones responsible for implementing Pam, you're going to need to make sure that you are talking to the lines of business. You're talking to, you know, the strategy teams across other areas within your organization to make sure that the capabilities that you are planning on your roadmap are going to align to that, that overall business strategy. And the, you know, the reason is that if you get to a certain point and the, a good example is adoption of cloud. If the organization is, is really moving towards a cloud platform for service delivery, you wanna make sure that your implementation is gonna support that. And if it's happening in two years, it needs to be on your roadmap. Instead of having them come to you, you know, and say in a week, we're gonna be doing this and can you support it? And we say, no, and now all of a sudden there's a gap and it, it can lead to issues down the road.
So just in conclusion, you know, again, understanding, making sure before you start, whether it's new or, or, or to update your existing infrastructure, understanding the why, how and what it's going to really give you the benefit of smooth deployment, tying into your roadmap, understanding why it'll also let you explain to your stakeholders the value of what it is you're doing gathering requirements, including the inventory of the applications, updating architectural patterns, making sure that you have a list of privileged accounts is also key. As I had mentioned, going wide, starting with platforms and, and large use technologies that are supporting many critical applications is a great way to get your program off the, off the ground. Making sure that adoption is high, as well as providing at least some level of security for those critical assets and making sure that they're not out there for available for cyber attack. And then lastly, well, I, sorry. I went go wide first. Before you do that, before you start implementing, do an RFP, making sure that you've met with all of your stakeholders, you understand exactly what their needs are, so that you can get into everything that you need within the product and ensure that the vendors are supplying the answers that are going to make and suit the needs for everybody within the organization.
