Freely subscribe to our NEWSLETTER

In the context of Privileged Access Management (PAM), it is a matter of controlling who has the ability to gain access, when and why. One of the first steps in this security project will be to identify which solution you will choose to manage these accesses. There are many solutions on the market, such as CyberArk’s Enterprise Password Vault, Wallix’s Bastion and HashiCorp’s Vault.
Once you have selected the solution that meets your needs (in terms of functionality, cost, etc.), you will face a new challenge: what do you need to protect? While the answer to this question may seem obvious (all privileged access), the practicalities are much less so. How do you identify the exhaustive list of accounts to protect? Who is responsible for these accounts? What is the impact of a password rotation on a given account? Who are the actors authorized to use privileged access?

Prioritize the actions

Before mobilizing all the teams, you need to have a relatively clear idea of the elements you want to include in your PAM solution: type of account (system, database, application, etc.), type of owner (generic accounts used by several people, named accounts, service accounts). Without this structure, you will get partial or exotic results!

Does your first analysis present you with too long a list of accesses to control? Prioritize! You will have to identify the priority perimeters according to your context. For example, prioritize the most critical infrastructures (which would put your company at risk if they were compromised) or prioritize a particular technical perimeter that you know how to easily put under control ("quick win").
The key is not to launch all the projects at the same time: you risk facing all the obstacles at once (technical problems, user problems, change management).
A proven management strategy is to use a Kanban board.

You group/associate your accounts to be onboarded into a "onboarding perimeter". This scope should be large enough to be representative (it wouldn’t make sense to have one scope per account), but not too large to be able to track its progress from week to week: the scope "All application accounts" for example would be far too large, and would remain in the "Onboarding" column for months or even years.

Then, you prioritize the scopes to be onboarded against each other by taking into account your criteria (criticality, difficulty, availability of resources and contacts, etc.).

You start the task that is at the top of the list, and then you focus on solving that onboarding. The challenge here is to get to the end of an onboarding before thinking about industrialization. It is always easier, more interesting and more exciting to start tasks rather than complete those that are in progress and facing some difficulties. However, this is counterproductive: all the tasks are in the "In progress" column, none of them are completed, you have to manage all the difficulties at once. This brings us back to the point "don’t start all the tasks at the same time", which could be extended here to "don’t have all the tasks open at the same time".

For each scope, your first task will be to identify a contact that you will involve in the project.

Delegate, involve

The team in charge of controlling privileged accounts (let’s call it the "PAM team") cannot act alone. No matter what tools you put in place, you will need the support of those responsible for the privileged accounts you want to control. For example, to know who will be allowed to manipulate them. Or to know the scope of an account (local on a machine? On an application? On a domain?).

Identifying the contact: is it that simple?

Associate a privilege account with a manager. The challenge seems simple, but it should not be taken lightly. You will need to find the right contact, the one who can both list the privileged accounts used in a functional context, but also give you the operating constraints related to these accounts, and give you a green light for the accounts to be put under control in your PAM solution.
Do you already have a referential that lists who is responsible? It’s a good start, but be careful about when it is updated! Feedback shows that these tools are not always up to date in large groups, and therefore you should expect to spend time investigating to find the current manager.

Trust the teams (partially).

To get the most exhaustive list of accounts to onboard, you can cross-reference information from two sources: managers on one side, an automated system on the other.

There are account scanning tools on the market: either by log analysis or by installing an agent. These tools will give you a list of accounts used at least once during the analysis period, or the list of local accounts. The drawbacks: you will get a heterogeneous list of accounts, without knowing who is responsible for them. And above all, you won’t have any information about the accounts that were not used during your analysis!

To complete this list, you can ask the functional perimeter managers (infrastructure, applications, etc.) to list the privileged accounts used for their activities, specifying the type of accounts to be listed (which you did in the "prioritize actions" step).

Cross-referencing the two pieces of information should give you an exhaustive list of accounts linked to a scope.

Now that you have lists of accounts to onboard and the associated managers, involve them in your deployment strategy: these managers must become your ambassadors to their teams. Inform them about the project objectives, train them on the basics of privileged account management. Show them the benefits of your solution (no more passwords stored in a notepad, no more questions about which accesses to give to new employees, etc.).

Finally, make them accountable: for example, you can ask them to give you a green light to onboard their privileged accounts (which implies that they have trained their team, that they have made sure there will be no side effects, etc.). Or, put the management of who will have access to privileged accounts (their team members) in their hands.

Automate / Systematize

As soon as you have the opportunity, automate the control of your privileged accounts: both onboarding and decommissioning. One of the major challenges of your PAM project will be to keep the list of protected accounts up to date. Your environment will evolve, both during your project launch and after.
New machines will be commissioned, new applications will be deployed, machines will be retired or reassigned. This can slow down your progress, or even make it obsolete in some cases (the accounts you identified no longer exist, the managers have changed positions, etc.).

Automated onboarding will allow you to ensure, on a given perimeter, a continuous synchronization between your environment and your PAM solution.
The main difficulty will be to find the right repository. Is your CMDB reliable and up to date to the point that you can trust it when a machine leaves the inventory to remove accounts from your PAM solution?

Once you have found the right authoritative source, the one that reliably represents reality, you can set up automated onboarding strategies. For example, when a "Windows 10" machine appears in the CMDB, automatically embed the "Administrator" account in your PAM solution, forcing the password change via a domain account. When a server is decommissioned, remove all local accounts of this machine embedded in the PAM solution.

If you don’t have a tool, or too many technical restrictions to implement this automation, consider systemization. Use existing workflows. For example, the workflow for creating a machine for a collaborator; or the workflow for ordering a new server. Add a "privileged account onboarding" step. Ask for a "proof" that the on-boarding has been done to go to the next step (on-boarded account id, screen print, ...).

The ticket cannot be closed until the accounts are declared as "onboarded", and this onboarding can be taken into account in the SLAs.
The idea is that managing privileged accounts through a dedicated solution should be part of the component management process and not a "side" process.
Get the right tools

Whatever onboarding strategy you adopt, you will need to measure progress. A "natural" way to move forward is to use Excel. You have your lists of accounts to onboard, the list of contacts (and their backups), the status of each scope (contact made, first exchanges, onboarding started...).

You can even create your own dashboards to monitor your activity. But quickly, you will have a complex and loaded Excel sheet, that only you will know how to use, and therefore only you will maintain. Above all, your team/management will only have visibility on the project by asking you.

Another point, how will you exchange information with your contributors? Whether by email or shared file, the risk is to quickly reach user problems ("I didn’t use the right template", "I have a local backup with other information", "my colleague sent the email during my vacations without copying me", ...).
The technical challenge of getting privileged accounts under control is great enough to not be burdened with minor irritating problems.

As early as possible in your PAM project, equip yourself with a solution that will make the project run more smoothly: data exchange with contributors, progress tracking, focus on ongoing tasks, etc.

If you are going for a specific development, beware of the long-term temporary. If the idea of having a tool to start the project seems obvious, it should - either - be designed for long-term use or have an expiration date. The risk here is to process confidential data (which you are trying to manage via the PAM solution) in a tool that would not be secure or that would not be maintained.

If possible, also think about a tool that will allow you to industrialize your onboarding.