Privileged Access Management (PAM) is a field of growing concern for IT security professionals as the threat posed by trusted insiders is on the rise. When granting privileged access, we’re effectively opening the door to our most sensitive infrastructure and data, and the potential for data breaches, espionage, and accidental damage can be tremendous. Privileged access is a vital requirement for any IT system as there must be users with the ability to troubleshoot, maintain, and deploy new hardware and software. Rather than accept the risk of insiders with elevated access, a successful PAM strategy can provide your administrators the access they need without exposing your organization to undue risk. In this article, my colleagues and I identify strategies and safeguards organizations can employ to reduce the risks posed by users with elevated permissions.
1. Least Privilege Principle
The basis of PAM is the principle of least privilege, which is defined as the practice of reducing the rights of an agent – whether a human user or non-human account. These rights within the system should be the absolute minimum necessary for the system to operate and the agent to complete its tasks. This principle requires the designers and managers of a system to determine an appropriate level of access for each user and to only adjust the access as absolutely necessary. Enforcing this principle, however, requires a careful balance between operational efficiency and security.
Consider that granting an individual full administrative rights or root access would allow the individual to operate at peak efficiency but with unlimited access to the system. Then consider revoking all privileges and requiring that individual to request access on a case-by-case basis. The first case demonstrates a complete lack of the least privilege principle, while the latter is the most restrictive case of no privilege. A high level of scrutiny is required to find a place between these two extreme cases to allow for operational efficiency while maintaining an acceptable level of risk. This scrutiny would involve a risk assessment of the privileges, the data, code, files, and resources being accessed, as well as the frequency of use. The assessment must also consider the impact of the privileges on the operation of the system. As an example, if an individual needs to update a file daily, it may be cumbersome to require a daily request for access. Alternative solutions could include giving the user the ability to change the file without approval if the risk from changes is sufficiently low, assigning the update task to someone else with a more privileged account, or redesigning the system.
Common industry solutions for least privilege include implementing Role-Based Access Control, which is the grouping of individuals who share the same logical access attributes based on a common role or responsibility. Another solution is to incorporate a privileged access tool to allow decisions about privileged and privileged access to be made in a partially- or fully-automated manner, based on predetermined criteria (see Password Vaulting & Emergency Access Procedures).
2. Planning for Privileged Access Management at the Enterprise Platform Level
Companies often find it advantageous to centralize responsibility for the management of their servers and databases into one internal infrastructure operations team rather than several stove-piped teams spread around the organization. Creating a central team encourages consistency in the configurations of these resources and fosters consistency in the level of service that is delivered. This can also increase the risk from privileged access violations as administrators now can have privileged access across an entire enterprise rather than just within an individual business unit.
A successful PAM program needs to understand the potential risks of this increase in access by classifying the types of agents that exist within the enterprise, the scope of their access, the operational processes used to manage the accounts for these agents, and the potential impact if their accounts should be compromised. This holistic view of the privileged accounts on an enterprise’s application-hosting platforms can help the organization determine the best places to apply corporate resources and implement security controls.
3. Planning for Privileged Access Management at the Application Level
Consideration for how privileged access will be granted, revoked, and monitored should be done as early as possible in the design phase of the SDLC. The benefit is most easily recognized by observing the maintenance phase for applications and software that failed to do so. Extensive redevelopment and sometimes complete re-engineering of the application is often required if privileged access controls are applied too late.
Consider as an example an application that requires users to manually drop files into a common share location, which in turn requires the user to have update permission (write/change/full, etc.). From a development perspective this may be the easiest method for the application to function, but after risk assessing the privileged access, it may be determined that a more restrictive process is required. This process might entail building a method for uploading files into the application via a web front end. This requires an extended level of development but reduces the ability of application users to purposefully or accidentally misuses their privileges. Clearly, it is much easier to explore these logical access controls in pre-production, as building a web-enabled application GUI requires drastically more effort than leveraging existing OS filesystem abilities but may be required to meet the organization’s risk management goals.
There are many alternatives that can be explored to reduce the requirement for privileged access. Examples include:
- Use of Emergency Access procedures instead of permanent update access for non-administrators.
- Use of a Production Turnover/Promotion Management program to move changes, patches, and updates into production without granting developers permanent update access to production.
- Using service accounts with restricted access or disabled direct login ability to automate tasks like data transfers and scheduled tasks.
- Building functions into the Front End or User Interface of the application, allowing for privileges to be controlled at the Application layer and removing any user interaction at the OS layer or infrastructure backend.
4. Control Selection and Layering
The defense-in-depth model is commonly used when choosing security controls at an enterprise level and can be applied for PAM as well, since controls can be applied at both the platform and application levels. Access management does not have to be all or nothing affair, but many organizations assume access must be binary: privileged or non-privileged. Administrators may need elevated access to do their jobs, but they likely don’t need unlimited access to all the information stored on the systems for which they are responsible. Hence some partitioning is necessary to keep administrative duties and information processed separate.
To achieve layered security in your access management model, consider the value of the information privileged users might be able to access and the potential risk if this information were compromised. If the risk of a breach is too high, additional technical or operational controls can be added, such as more frequent activity monitoring, use of a rights management system, or even file-level encryption. As an example, organizations using SharePoint as a collaboration platform might consider Microsoft’s Information Rights Management (IRM) to provide this second level of control. Administrators can be given elevated permission on the Windows servers supporting SharePoint but should not be in an IRM group which grants them the ability to see document content.
File-level encryption is even simpler and provides an easy way to obfuscate the contents of documents even if a user has the ability to download them. To encrypt a Microsoft Office 365 document simply click the File tab at the top left of the page, then choose Info –> Protect –> Encrypt with Password. Now your SharePoint administrator will be able to see the file, but without the password its contents remain invisible.
5. Account Provisioning
It is important that all of the preparation during the planning phase is properly implemented on an organization’s systems to ensure access controls operate as intended. In less controlled environments, users are often given privileges on an ad hoc basis. The user may start out in an overly general user role and then have additional rights and privileges added to their account over time. Unfortunately, when privileges are granted in this fashion they are rarely removed; individual users can accumulate nearly administrator-level access over time without anyone being aware.
To combat this issue, account provisioning must be conducted in a regimented process:
- Roles must be clearly defined at the platform and application level to help determine appropriate privileges for users within those roles. The roles should clearly align with major functions within the system, with an understanding that some duties may also need to be spread across multiple roles for security reasons.
- A management authority should be notified of all new user requests and provide an approval for those requests. These approvals are necessary to ensure all requests are properly vetted and are a key artifact for auditors governing the PAM process.
- Users should be assigned only to appropriate roles. If a user’s privileges need to change, they should be moved to the role that grants those privileges only with the proper approvals (management, system owner, etc.).
- Users and system managers should be required to review access privileges and attest to the need for access so that unnecessary access does not linger and accumulate.
The preceding steps can all be conducted through manual processes, but as the complexity of an organization increases it can also be increasingly hard to keep track of access requests and necessary privileges across the enterprise. Privileged identity management (PIM) tools can aid in the provisioning and management of accounts in complex environments by providing automated mechanisms for correctly provisioning access. The tools can be integrated with the organization’s platforms and applications so that new accounts are created consistently and uniformly. Workflows can be generated to automatically compile access requests and collect necessary approvals. Finally, these tools can provide metrics for analysis. A manual audit of accounts provisioned is still necessary, though it can be done on a sample of systems just to verify the PIM tool is properly configured and working consistently.
6. Implement Password Vaulting
Password management can be a chore for complicated environments and can motivate some users to circumvent rules by writing down their passwords or sharing them with others. This is of particular concern for privileged users as they may have privileged access to numerous systems. In this situation a password manager/vault may be necessary. The password manager tool can simplify user interaction by holding the password for target systems and issuing some type of token/ticket for the target system when administrative duties need to be performed. The user may or may not even see the password, as some tools can login on behalf of the user. Either way, this places a gate between users and their use of elevated permissions on a system, which can reduce unintended actions and provide another hurdle to a malicious user.
To further control the use of privileged access the password vault may integrate with a work ticketing system and require a cross reference or pre-authorization from that ticketing system before granting a user access. The vault could also be the method of implementing an emergency access procedure; if no work ticket exists, users could be presented an option to gain emergency access that would trigger alerts that emergency privileged access has been used.
A password vault can also have the added benefit of reducing user complexity by eliminating the disparate passwords required for various platforms. The vault is a single point of sign on that handles authentication to the various backend systems without requiring the user to memorize multiple passwords. Less passwords to remember means less chance of passwords being written down, enhancing overall password security.
7. Utilize an Emergency Access Process
Always-on privileged access poses two threats. First, a user could accidentally perform an action without realizing they’ve logged in using their privileged credentials. Second, and more dangerous, a privileged user could be taking malicious action on a system such as downloading copies of important documents for exfiltration, and this action likely wouldn’t raise any type of alarm.
An emergency access process can be helpful in addressing this threat. A break-the-glass style procedure where users must formally request access to privileged credentials provides a useful gate for controlling privileged access. The formal request can be used as an alert trigger: when a user initiates the procedure (breaks the glass, so to speak) an email is automatically generated to the user’s manager, relevant IT support department, etc. If the access is part of planned maintenance or known issue troubleshooting/support, the worst that’s happened is an unneeded email. If the access is not legitimate, the alert is a useful tool to kickstart an incident response and hopefully limit the impact of a malicious inside user.
8. Managing Production Code Promotion
Production promotion is the process of moving changes to an application or software into the operational environment and is often the source of unrealized privileged access to applications. A developer does their coding in an offline version of the application or software that resides in a test or quality assurance environment. In these environments, developers require the highest level of privilege, and rightfully so. Considering that developers can build into the application almost any function or process imaginable, it is extremely important to manage the process of promoting their code to production. A disgruntled employee could build logic bombs or backdoors or build processes that quietly steal information or even fraudulently change data.
A properly implemented Secure Development Life-Cycle is the first line of defense against this type of threat, and properly implemented procedures for promoting code into the production environment are an important component.
The first step in Production Promotion Management is to ensure that developers do not retain their level of privileged access in the production environment. Any and all privileged access for developers in the production environment should be heavily scrutinized and eliminated where possible. Code reviews should also be conducted to specifically target the “service hooks” which developers often use to legitimately test their own code but can act as backdoors if not removed when testing is complete.
Promoting code, like all other IT system duties, should be properly separated among multiple users/roles. This might involve requiring system administrators to implement new code or run promotion scripts, rather than granting developers privileges in the production environment. It could also be implemented via temporary privileged access for members of a dedicated Application Support/Development team to promote the code or implement the changes, provided the access is removed immediately after use.
The important principle is that the person who developed the change should not be the same person who promotes this code to production.
9. Audit, Audit, Audit
Access controls are only as good as the oversight you have to ensure they’re working properly. Periodic reviews or audits are an essential part of any organization’s security governance; because proper access management is crucial to safeguarding data, it should be an integral part of your audit program. The scope of audits should include the following at a minimum:
- Review a random sample of access authorizations: To ensure users’ access is being properly reviewed and approved, pull the access request forms/tickets that were submitted to gain access. Improperly authorized users can present a serious risk if they’re given access beyond what’s required for their job duties.
- Review all access to critical infrastructure: It can be an arduous task, but it’s crucial that key servers and network devices get a full access review to ensure all users still have a valid access need and that they’ve got appropriate permissions.
- For large environments using groups can help to cut down the administrative and audit burden (e.g. creating a “Windows Production Support” group would allow you to review the users in the group just once and then review that group’s permissions on various servers). Truly complex environments with a heterogeneous infrastructure could benefit from an automated access management tool capable of generating audit reports or even possibly performing automated checks such as identifying users whose accounts are deactivated but still have access provisioned.
- Review a sample of privileged access to non-critical infrastructure: Given limited resources, auditing every server or network device could be an impossible task. Prepare a representative sample to review and look for any trends that could be extrapolated back to your infrastructure as a whole.
10. Integrating PAM Into Other Parts of Enterprise Operations
PAM is vital in combating insider threat as well as reducing the impact of intrusive malware, system infiltration, and account compromise. Looking at the big picture of an organization’s cyber security program there are many areas where Privileged Access Management should be integrated or at least considered:
- Configuration Management: The goal of configuration management is to reduce known vulnerabilities in an information system by implementing a standard set of controls, ensuring security patches are implemented, and ensuring all changes to hardware and software conform to these standards. By monitoring compliance and conducting vulnerability testing, this process results in a relatively accurate picture of the vulnerabilities present in a given information system
- Incident Response: It is vital to any forensic endeavor that access at any level to logs, monitoring software, and forensic software resides solely with authorized personnel. Any administrator having access to these logs and software could partially or completely hamper an incident response or investigation, so privileged access to log files or logging functions should receive extra scrutiny.
- Awareness and Training: As mentioned before, training and awareness on the topic of PAM can be vital. A developer who is aware of the driving policies behind their organization’s Privileged Access Management program can engineer applications or software to comply with the program’s mandates. Managers and information owners should be aware of their responsibilities with regards to authorizing different levels of access.
- Risk Assessment: The PAM program needs to address the subset of risks related to access controls, but it should also be aware of other risks to the organization as they are all interconnected. Business impacts of greater or lesser levels of access control should be evaluated as part of the overall assessment. An internet-based retailer has a greater need for rapid response to production application issues, and therefore requires a larger administrative team, than does a consulting company with an internal collaboration platform with highly confidential client data.
