Simple Analogies to Explain Why Privileged Access Management is NecessaryOne 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?
Understanding Resistance – Knowing How People WorkAs 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.
- 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.
- 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.
- 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.
- 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.”
Engage Your Users in Solving the Problem of Excessive PrivilegesWith 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.”
Scott Carlson, Technical Fellow
As Technical Fellow, Scott Carlson brings internal technical leadership to BeyondTrust, strategic guidance to our customers, and evangelism to the broader IT security community. He also plays a key role in developing innovative relationships between BeyondTrust and its technical alliance partners. Scott has over 20 years of experience in the banking, education and payment sectors, where his focus areas have included information security, data centers, cloud, virtualization, and systems architecture. He is also a noted thought leader, speaker and contributor to RSA Conference, OpenStack Foundation, Information Week and other industry institutions.
Prior to joining BeyondTrust, Scott served as Director of Information Security Strategy & Integration with PayPal, where he created and executed security strategy for infrastructure across all PayPal properties, including worldwide data centers, office networks, and public cloud deployments. He led several cross-departmental teams to deliver information security strategy, technical architecture, and strategic solutions across enterprise IT environments. As a member of the office of the CISO, CTO and CIO, Scott spoke on behalf of the company at global conferences. In addition, he was responsible for infrastructure budget management, vendor management, and product selection, while also serving as the cloud security strategist for private OpenStack cloud and public cloud (AWS, GCP, Azure). Prior to PayPal, Scott held similar roles with Apollo Education Group and Charles Schwab.