Note: This is the second in a series of featured articles dealing with PAM strategies, passwords, and secured credentials.
In the first article of this series, we discussed what a proactive PAM strategy should look like. We noted that it should start with a strategic plan and include three steps for securely managing privileged accounts. In this second part of the series, we’ll take a deeper look at each one of those steps.
Privileged accounts represent the “keys to the kingdom” for every organization. Nearly every device, system, application and database has a privileged account, and organizations cannot exist without them. Administrators must have access to these accounts to install software updates, reset passwords, set up or deactivate an account, and perform various other administrative tasks. Privileged accounts provide unlimited access to systems and data, however, and, if they are not controlled, anyone who gains access to them can do pretty much whatever they want with virtually no accountability or view into what they are actually doing.
Successful privileged account management (PAM) projects start with a plan that outlines the key stakeholders, requirements, and milestones. Once your plan is in place, there are three key controls you need to implement. These include providing secured and controlled access to privileged accounts, implementing least privileged access, and logging and monitoring of privileged accounts. Let’s take a deeper look at each of these steps.
Secure and control access to privileged accounts
You can’t mitigate the risks of privileged accounts if you don’t know how many accounts you have or who needs access to them, so start by taking a careful inventory. Also, remember that privileged passwords often are hard-coded in many scripts and applications. Once you have a comprehensive list of all privileged accounts ‒ and the people and systems that need access to them ‒ your organization can assess where it is most vulnerable to internal or external security breaches, and focus on those areas first.
If you’re still unsure where to start, we recommend starting with third-party or vendor access. Trusting your employees with the keys to the kingdom is one thing, but trusting those outside the organization to secure these valuable credentials can be extremely risky. If your organization enlists vendors and consultants to provide specialized solutions and services requiring remote and privileged access to your infrastructure, you need to have a distinct set of access requirements for them. If you neglect to treat remote vendor privileged access differently from traditional employee privileged access, you can introduce security risks such as virus infection, unauthorized access and non-compliance.
The next step is to determine a secure place ‒ ideally with encryption and multiple layers of authentication ‒ to store those credentials. Then, you need to eliminate the sharing of them and ensure individual accountability by implementing a password-request process. Doing this manually can be time-consuming and error-prone. That’s why many organizations that place a high priority on privileged account security use privileged password safe technology. A privileged password safe secures privileged credentials using multiple security and authentication layers and generally provides some workflow for gaining access to them.
Before you take action, it’s important to understand the impact removing credentials will have on the productivity of the broader organization. At all times, even during this project, you’ve got to keep business processes running at nearly any cost.
Implement Least Privileged Rights
Good security ‒ and many compliance regulations ‒ require both individual accountability and least-privileged access. Organizations must know exactly who has access to what, and when and only grant the appropriate access level a user needs to perform the task at hand. Doing so limits harmful actions, whether unintentional or malicious.
To implement a least-privileged operating model, first, determine all key roles and responsibilities within your organization. There are three common ways you can go about determining roles or role mining ‒ top-down, bottom-up and by-example. In top-down role mining, users are given roles based on the job functions they perform. In bottom-up role mining, users are given roles based on a common set of resources to which they need access. In by-example role mining, roles are determined by managers identifying users who perform the same job, and if the users have the same privileges, you create a role for it.
All of this is a large challenge, as roles and access rights change as people move to new roles or leave the organization. It’s critical to constantly re-evaluate and make adjustments. Typically, we recommend doing this at least annually; however, if your organization is growing fast, either organically or through mergers and acquisition, you may want to review more often.
Be careful not to get too granular when implementing least-privileged access, as there comes a point of diminishing returns. If you carve out too small a role for each individual, your systems can become so locked down that it makes getting access to individuals very inefficient.
As you can see, implementing least-privileged access can be quite complex, and not all systems provide native ways to do it. Organizations use third-party delegation solutions to assist them with the challenge, particularly with systems where delegation is not natively available, like Unix and Linux.
Audit Privileged Access with Monitoring and Logging
It’s not enough to simply control what privileged users are allowed to do. You also need to audit what they are doing, and the first step is to determine the types of activities on which you want to audit and report. Depending on your compliance and security requirements, your auditors will want specific reports that answer questions around privileged access including:
- Who has access to privileged accounts, when did they have access, and which systems do they access?
- What systems have compliance (PII, PCI, HIPAA, etc.) data on them, who has access to those systems, and what did they do with that access?
- What systems had denied-access requests, and who was trying to access them?
- What potentially harmful commands were run on each system, and by whom?
The next step is to determine how you will provide that report. Which logs do you need to collect to ensure you can provide a complete and accurate report, and how do you correlate that with an individual user? Natively correlating logs with specific individuals can be very difficult. Using information from a password safe solution can help ‒ but, to know exactly what a user did with privileged access, you will need to use a session management solution.
Solutions that can help
As mentioned previously, using a password safe, along with delegation and session management solutions, can simplify the three-step process for securely managing privileged accounts. In the next article, I will dive deeper into each of these solution areas, describing how they can help and what you should expect from them. I’ll also discuss privileged account governance and why no PAM project is truly complete without it.
About the Author:
Bill Evans is the senior director of product marketing for the Identity and Access Management businesses within Dell Security. In this role, Bill drives the strategic direction for the team which includes setting product and solution positioning, creating the global direction for demand gen and other sales support efforts as well as providing content for sales enablement activities.
Prior to his current role, Bill served as product marketing director for Dell’s Windows and SharePoint businesses as well as general manager of the SharePoint and Notes transition business unit at Quest Software. He joined Quest in 2004 with the acquisition of Aelita Software.
