
What is Privileged Management and Why is it Important?
Ever heard of a data breach? Ever heard of a data breach associated with your bank, a store you shop at, or in the government perhaps? Does it strike fear into your heart? It should. One of the culprits behind like 80% of data breaches these days is someone abusing (on purpose or accidentally) their special rights or privileges on a computer network. And here’s the secret: It’s avoidable! That’s what privileged access management is all about – limiting what can be done by powerful accounts or people on your computers. As an IT professional, treat access to the most important systems in your organization (or the special secrets you don’t want anyone to know about), like you would treat access to your personal details, your money, or your home. To protect access to those secrets, answer these questions:- What is my stuff worth protection?
- Who do I trust to have special/privileged access to my company’s stuff?
- Why should I trust them?
- How do I make sure that they can maintain my trust?
- What action should I take if that trust is broken?
Who’s Who in the Zoo? Four Types of People in Nearly Every Organization.
Once you have identified what’s worth protecting, you have to know who in your organization needs access to that stuff. There are jobs people are supposed to do, jobs that people have the ability to do--but shouldn’t, and special roles and responsibilities that have “special purpose” to your business or computer operations. Those are the privileged roles, and example include:- Your security guards have privileged access to every room in the building for monitoring purposes.
- Your HR department has privileged access to employee data so that they can help employees with their life events, such as getting paid, having a child, or obtaining insurance.
- Your server team has privileged access to create, destroy, and make servers function.
- Your data/database team has privileged access to your most sensitive data.
- Your finance team has privileged access to your banking application to execute wire transfers to other people or companies.
- The “Front Office” people. For the front office, your goal is to provide a set of standard computer systems and applications allowing people to do their jobs. These workers should never have permissions to change their systems or applications, or to install software. This group follows a defined set of processes and procedures, and if they access customer data, they likely only touch one or two records at a time.
- The “Back Office” people. Folks who may provide advanced financial analysis, perform business process work, conduct money transfers, write checks, or work with large data sets. These are the experts in business processes, and the people and application administrators you trust enough to give them rights within that application, as well as to supervise others who have access to the data or financial transactions that can impact your company.
- The Systems and Network people. They perform critical administrative functions against your computer systems, desktops, networks, and data centers. These workers possess the “keys” to your data center and must 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. Even though these users have full access to system resources, they very likely should never need to look at the actual data.
- The 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. They need access to this data to provide business reports, write better systems, update incorrect data fields, or write software.

Always do These Things
The final step in the process is to implement consistent controls applicable to each of these groups of folks. At a high level, controls like:- Remove administrative rights from user accounts on operating systems
- Change default passwords – ALWAYS
- Require administrative users to use a second account to access privileged systems or privileged applications
- Use a jump host or session recorder that users rely on to access privileged environments to remove the ability for an attack or malware to compromise your whole company
- Record behavior against a highly privileged application, database, or system
- Prohibit the installation of software that hasn’t been certified, especially on critical systems, or systems of staff that perform critical business operations
- Use a password safe to store the password to your critical systems
- Remove access to systems or applications when the user does not need it
- Limit the commands that can be typed on highly sensitive/critical systems, especially when multiple types of users need to directly access the system
- Centralize administration of all of this!
How Do You Know if This is Working?
One of the biggest concerns I’ve had when designing and deploying privileged access management tools is the impact to IT. You MUST be more secure. You MUST use these controls to help you meet your compliance mandates. But you MUST ALSO not get in the way of the folks who are doing the work in your business. Selling privileged access management is more than quantifying a reduction in data breaches. It’s also about reducing help desk calls for goofy tasks, automating formerly manual business processes, making it easier to manage new systems and get stuff up and running faster with fewer problems. All that translates into money. It’s a consideration, for sure. I hope this has been a relatively informative look at how to start your PAM initiative. I believe in this framework and truly hope it helps you get started. Download the white paper for all the details, including the checklist to mark your progress. Once you’ve gone through this process, the logical next step is to start an implementation plan. We have a paper that can help you get started there too. It’s called, 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.