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 three-part series, my colleagues and I identify strategies and safeguards organizations can employ to reduce the risks posed by users with elevated permissions. Part 1 deals with planning.
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 an Office document this, simply go to the Office Menu, then choose Prepare->Encrypt Document, and choose a strong password. Now your SharePoint administrator will be able to see the file, but without the password its contents remain invisible.