Implementing Privilege Access Management - Stop Users from Revolting

Any time that a company wishes to begin implementing a product that is perceived as taking away rights, privileges or access, people have an emotional reaction to it. Some people react because of “change,” but others react out of a more visceral “trust” emotion. The concept of privilege management has been around a long time in the physical world. You obviously do not trust everyone to have the master key to your building, nor do you trust every employee to have access to every file cabinet in the human resources department. Using these comparisons, why do humans have a problem with applying these same sorts of concepts to the technical world when faced with a privileged access management (PAM) project that attempts to lock down their desktop, rotate their passwords, or start to record their daily activity? I want to walk you through some ways in which you can get the users on your side when you must be the one to implement a PAM effort throughout your company. We will go through a couple of standard use cases along with some talking points which I have found have helped. Different things work for different companies, and only you can determine which method will work.

Simple Analogies to Explain Why Privileged Access Management is Necessary

One thing is true: humans love analogies and stories. You’ll want to be ready with non-technical comparisons for people when they object to the change. Companies have been implementing PAM for 10+ years now, and at this point, nearly every use case has been identified and solved no matter what your users think. Their use case is likely not 100% unique. Here are some simple examples and stories to be ready with:

• Enterprise password management is like changing your locker combination or safe combination, or occasionally re-keying your house.

• You remember those stories about people using CD drawers as cup holders on their computer? Would you want them deciding which software belongs on your computers and network?

• Recording activity on a computer accessing credit cards is the same as putting a camera pointed at the bank tellers handling the money.

• Use a hotel example. With doors, locks, key cards, real time access, shared rooms.

• You don’t set your ATM card PIN to 1111, so why would you set your password to “password?” This software is going to make sure that people cannot default to that behavior.

• It’s very important to have different types of keys and different types of doors to control people being able to get to critical information in your building, or human resources files, or diamonds. The same is true for IT systems. You don’t want everyone to go everywhere simply because they work there. Only authorized people should be able to get to the things that the job says they can get to.

• The Sony, Target and eBay breaches all started with phishing or password reuse. Do you want to be the point of entry for a breach like that?

You get the idea with some of those examples. People want to know that you have thought about them and they are not trying something for the first time. Leave them with the impression that lots of people have done this and yes, there might be pain and turmoil, but it will be limited to edge cases.

Understanding Resistance – Knowing How People Work

As I discussed in my non-vendor-speak white paper about privileged management, there are four different types of people you will run into when you try and do a project like this. You can read that entire white paper, but I’ll describe these people again here so that we can talk about the conversational side of doing business with these four categories. Layer 1 - The “Front Office” People In the “Front Office” there are folks who often provide customer service, answer the telephones, or provide a set of services that change only when you want a business process to change. These folks follow a defined set of processes and procedures and if they service customer data, they likely only touch one or two records at a time. Sometimes these folks run reports, but the data is in a read-only form and in almost every case large data extracts are not allowed. To be successful with this set of users, I recommend the following:

• Make sure that you have the team managers on board with what you are doing, and make sure that if there are obstacles created by the new software that their employees should not be punished for it while you work out the kinks.

• Make sure that they understand that they work here because they are good at their job and you trust them to execute in a world class manner, but regulatory and legal things require the installation and tracking of this information.

• If people are concerned that their activity will be used “against them” you have to remember that this is already the case – their calls and system activity are already monitored – so you are not introducing anything new (unless you have never done this before) and then you really need to remind people that because they work for a company in this capacity, they have no right to privacy.

When you explain what is happening, being simple is best: “Some new security software is being installed on your computer this evening that will enhance our ability to manage corporate workstations and protect our organization from malicious activity. This software will not impact you in any way, but if there are programs that do not function like before, or if you are prohibited from doing things that you need to work with customers, please contact the help desk.” Layer 2 - The “Back Office” People In the “Back Office” there are folks who often provide more advanced financial analysis, perform business process work, perform money transfers, write checks, or work with large data sets. These employees might not have access to the systems themselves, but they likely have access within applications or are the application administrators you trust enough to give them rights within that application and to supervise others who have access to the data or financial transactions that can impact your company. To be successful with this set of users, I recommend the following:

• Give them examples of how back-office people have been compromised in the past to do fraudulent wire transfers, etc.

• If someone throws out the trust question, remind them that they are some of the most trusted in the company to work with company data or money – but what their job isn’t, is that it isn’t to be an IT person or work on their own computer. One of the biggest paths to compromise of critical systems are from the most trusted people and this user group is one of the high-risk user groups.

• This user group is probably subject to some of the most stringent legal and compliance requirements around the world, so reminding them of obligations legally helps them accept that they are about to be locked down, monitored, and recorded.

• Ensure that this group of users has direct access to the help desk at first, with specialists that understand their processes and custom software, because they will have some custom stuff that doesn’t exist anywhere else.

Layer 3 - the Security, Systems, and Network People Your systems and network people provide a specific function. They perform critical administrative functions against your computer systems, desktops, networks, and data centers. They have the “keys” to your data center and must have the ability to obtain the highest level of administrative rights on the technology they are supporting during build operations, break-fix operations, and for your security team, forensic operations. These users are nearly always the “most problematic” and likely might have the biggest vocal attitude about being locked down. They have always had the “root password” to the “most important things,” so when you approach them about taking away passwords, or locking their system down, they immediately feel violated. To deal with this type of person, I recommend the following approach:

• Remind them that you trust them, and tell them how important it is that they work there and that they continue to have access to the systems when they need it, and they will have a way to get in if something is an emergency.

• Explain to them that you need their help working through this complicated process – because they know how the systems work better than anyone else – get them on your side.

• Remind them that because they work at this company, they are considered “high value”/ “high risk” employees and are some of the most attacked, and it is your job to protect the company, and ensure that audits and compliance are met – these users are in scope for PCI and HIPAA because they manage in-scope payment systems and deal with patient data.

• If these users need a “playground,” find a way to have them not work on their primary support laptop, and make sure that you take their custom management host and “leave it alone,” but put it behind the session recording portal on the network. For instance, they shouldn’t log into their management host directly anymore, they should log into the session proxy first, and then they can keep using their management host as if you weren’t even there. Make sure you turn on logging, and then let them keep doing their job.

• Build trust, and ask for their help to get it installed in a way that works for them.

• Worst case, if they just won’t get on your side, find the member of management that they trust the most and start a conversation there. Convincing a trusted entity is sometimes your only way into the stodgiest people.

• Remind them that most things can be automated, technology has improved immensely and nearly everything that protects them can be used in similar manner to what they do today with automation, scripts, and web browsers.

Layer 4 – Developers, Data and Application People Developers, Data, and Application staff provide administrative functions to your business software, and almost always need direct access to real customer data or program source code. In general, developer conversations start with them wanting the world:

• Users will react that they are important development resources, and you can’t possibly lock their machine down. They need the ability to get modules, download open source, and use tools that make them more productive. You want to focus this attention back on them and either ask for a list, or ask which things they shouldn’t be able to do. “Yes, I know you need open source, but is it okay if I stop you from installing malware.”

• When users start to wonder why they can’t do anything they want to their corporate owned asset, remind them that they are professional developers, and in the name of productivity, you need to build them a production environment capable of being used for development of their important function. If they mess up the machine – or if others mess it up – not only can you not prove compliance anymore, they might not be able to do their job with the tools that you have put in place for them.

• Nearly all developers have the role as production support people too, so reminding them that that they may be called into action to log into production, and unless they are running the software that makes them compliant, they won’t be able to help.

• Developers are the type where they will want to know that this doesn’t impact performance of their computer, doesn’t conflict with compiling, and doesn’t get in the way. Studies show that PAM software does not negatively impact computers anymore as soon as some basic settings are entered, so do not let this be a compelling argument anymore.

YOUR Actions Matter, Too You play a critical role in encouraging adoption of privileged access management, so please understand who NOT to be

• The Dictator: Don’t care how you feel.The CEO says we must do this. Take the “it’s not me that’s doing this to you” ground and blame the CEO, the Auditor, or the regulator. Tell them that you must do this no matter what and it is out of your hands. Then ask for their help to get it done in the least painful way possible. Don’t be this person.

• The Manipulator: Take the path of, “How about you help me get this done, so that you don’t get screwed over when someone who doesn’t care about you comes by.” Don’t be this person either.

• The Realist: Be this person. Every project will cause a little pain – be up front about the pain to the users. You are touching their desktop, acknowledge this and show that you understand. “Hey, this might suck a little bit, but I’ll give you heads up. I’ll need you to work with me so that we can find everything that you do every day. We have no choice in doing this, so let’s find out what you do every day, every 30 days so that I can make this pleasant. Why don’t you start by showing me how you do your job.”

You can't just dictate that someone do PAM and you can't install the product on people’s environments without them knowing. When you cause an outage, the product will come to a halt, so it is very important that you notify, communicate, and let everyone know when pushes are going to happen. Get the security team and management on board and be ready to react, and then react in the language that is important to the people. Do not let your project get derailed by emotion.

Engage Your Users in Solving the Problem of Excessive Privileges

With each of these user groups, it is very important to talk their language and find out about the root of their objections. Getting them to help you and remove the problems up front is important to getting wins in and making progress. For more strategies on implementing privileged access management in your environment, check out our white paper, “7 Steps to Complete Privileged Access Management.”