There are two types of people in this world: Those who embrace change and the potential benefits, and those who resist change and emphasize the potential negative effects. When operating in the next generation economy, information technology changes can drastically impact productivity to streamline tasks or improve security. Rarely is the intent designed to complicate or slow processes down, but even the best of intentions can add extra steps, mouse clicks, or processes in the name of security. If you take a deep look as to why these changes are necessary, the extra steps benefit the entire environment and should be embraced rather than dismissed as a nuisance.
If you consider the basic security changes we take for granted today like logging into your computer or even using a key to unlock a door, you recognize that additional steps are necessary to secure an asset and the information it contains. When considering and
deploying a privileged access management (PAM) solution, the changes required are analogous to adding a pin to your phone verses always being unlocked. A simple step that almost everyone can embrace as a worthwhile change for the security it provides in the long run. To that end, PAM has a similar impact within an organization.
What is privileged access management, and how do you minimize resistance?
By definition PAM, is comprised of 4 primary disciplines:
When implementing any of them, there will be changes to the environment, a user’s workflow, internal processes, and potentially be met with end user (or administrator) resistance. So how do you adopt the solution and address the concerns of those averse to change?
Appoint an Internal Champion
A key component for any successful project is to have a trusted advisor or internal evangelist promote and champion the project internally. They can train on the benefits, field questions, and help temper any resistance. No one likes changes being forced upon them but having a well-planned deployment, educating on the changes presented to the teams, and soliciting feedback to help teams feel empowered goes a long way to the success of any project that requires a change. While this may seem rudimentary, it is surprising how often these premises are missed and staff is sent a memo with new procedures with no rhyme or reason for the new policy and workflow.
Start with a Pilot
Second, start small and test regularly. Any deployment changes that will impact the masses or key trusted individuals need to be introduced methodically. Start small, demonstrate the benefits and solicit feedback. Many of the changes required for PAM are just a few extra mouse clicks. The security and compliance gained is measurable and should be a part of the education process. For example, the new procedure requires checking out a root password for PCI and SOX compliance using multifactor authentication and a PAM solution. These steps ensure it is done securely, and the session is being recorded for auditors to demonstrate compliance, and to catch hackers that might try the same thing to infiltrate your environment. That makes the extra steps understandable if the teams have the best interests of the company in mind.
Determine What to Focus on First
Third, something that many organizations consider the first step, is determining which PAM project to embrace first and which one will be the most successful with minimal resistance. To aid in this process, BeyondTrust has created a reference document called “
The 7 Steps to Privileged Access Management”. It helps address the privilege problem by recommending solutions in order that maximize success, in minimal time, and ultimately with the least resistance.
Steps to Implementation
Based on these recommendations, the first step in implementing PAM is generally
password management. In order to deploy the solution with minimal friction, consider the most sensitive accounts in your environment, age of passwords, difficulty in managing password changes manually, embedded passwords, etc. This leads to implementing privileged password management in the following order:
- Domain Administrators or Root on non-Windows assets
- Service Accounts
- Infrastructure
- User Administrator Accounts
- Application to Application (API) Coding
As you work down the list, you can theorize which teams will be the most understanding to the change and which will need more educating or need time to implement (i.e. code changes). Operations teams and security analysts will understand the reasons why the changes are best and can become your advocates if they are introduced into the process first
For
least privilege implementation of
Unix, Linux,
Windows, and
Mac – similar to managing passwords – consider your highest risk users that have administrator accounts. This can be everyone from server admins to helpdesk staff all the way through end users that have admin rights or a secondary x-admin account. While
removing admin or root rights away from servers logically seems like the best first step, it is much easier to do on Unix and Linux than Windows. This is simply due to the process changes needed on the different platforms in order to be successful. Therefore, for least privilege consider the following order:
- Removal or root privileges on Unix Linux
- Removal of secondary administrator or root accounts for all end users
- Elimination of needed accounts per department like the helpdesk
- Windows Server administrators
The removal of privileges is generally the highest resistance for any PAM implementation. Team members will try and justify reasons why they still need these privileges and why changing the workflow hurts them. This is where education and feedback are critical for the success of the project and the workflow must be as close to the current process as possible.
Least privilege solutions are designed to do this but users may not be accustomed to two factor authentication or right clicking on an application, verses double clicking, in order to accomplish the same administrative task based on how the policy is configured. This is where education and trusted advocates help the most.
Consider an FAQ Doc for Teams
Finally, consider a Frequently Asked Question (FAQ) document for teams impacted by process changes. As simple as it sounds, it can address many of the common questions like:
- Will I still be able to administer servers while I am working from home or on the road?
- Will I be able to change the clock or add printers on my laptop?
- If a program is no longer working, who should I call?
- Why are you removing my x-admin account?
- I am a developer. How can I compile code or access test servers?
If you need help with this type of document, BeyondTrust has guides for end users, administrators, and even helpdesk staff. These guides are designed to help create a model for a successful PAM implementation with known best practices from years of experience. For more information on how to get started on your PAM project, realize the additional security and compliance that a PAM project can bring to your organization,
contact us today.
