8
February 2019
Privileged Access Management – Common Use Cases
Andy Harris
It’s a simple axiom that misuse of Privileged Accounts leads to data breaches and system downtime. Therefore, PAM (Privileged Access Management) solutions are built to control access to Privileged Accounts to drive security. Here, we will outline some of the common use cases:
ISO27001 – Auditing who had access to critical systems and data
If administrators can only get to systems via a PAM solution, then the PAM solution naturally becomes the point of audit. There is a difference between a solution that allows access to the credentials compared, to a solution that provides single-sign-on. Credentials that are checked-out from a vault are valid for both legitimate and other potentially malicious connections. Remember, out-of-band and unrecorded access is a failure with respect to ISO27001 principles. Identity is key here, we need to know who had access to the privileged sessions. Should the credentials enter the ‘wild’ via compromised end points or staff, then Identity cannot be proven.
Osirium PAM is a credential injecting proxy PAM solution; which guarantees that a known identity has been mapped to a role-based session, thus delivering on individual accountability.
Controlling Third Party access
Sharing credentials with third parties is fraught with risk, although organisations will always benefit from their services. Therefore the goal is to grant and record access without sharing credentials.
Not all third parties are equal. Some consultants you’ll only see for a day, but some outsourced functions will see the same staff accessing your systems for years. Never forget, outsourcers actually outsource, just as you do, so your shared credentials may disperse further than your organisation would like.
A simple, but potentially risky, approach is to use ‘generic accounts’, for example helpdesk1 helpdesk2 etc. The issue with these accounts is that they hide the real identity of the user. It’s pretty obvious, that in today’s world, anonymity leads to misuse and worse.
For example, some large vendors are their own identity providers, which leads to some interesting possibilities. For example, you could say: today I will allow any identity from the SAN support group at Hewlett Packard to access this particular SAN device for maintenance. Your audit trail would then trace to an individual who did what and when, even though they are a supplier rather than a direct employee.
Your own employees using a dual account model
It has often been considered good practice for SysAdmin and DevOps/SecOps users to have two accounts – one for general use, the other for administrative actions. The dual account model helps to address accountability – knowing who did what on which systems. However, there are security issues here:
- This increases the overall number of Privileged Accounts and therefore increase the overall attack surface.
- There is the cognitive overload of staff having to remember yet more passwords.
A Privileged Access Management Solution addresses these by separating the SysAdmin users from their (own) privileged credentials. In this case, only their identity can unlock their personalised privileged accounts
Implementing a Role-Based Account model
In the role-based account model, Applications, Systems and Devices have only the minimum number of Privileged Accounts needed to manage them. For each role, an account with the minimum necessary privileges is created. This account is given strong credentials in terms of passwords or keys.
The PAM solution then maps Identities to Roles, while auditing access on the way through. This delivers the following advantages:
- The attack surface is kept to the absolute minimum.
- Enterprise Class Credential Lifecycle Management within the Privileged Access Management solution keeps all the credentials long, strong and regularly changed.
- There is no possibility to access systems outside of the remit of the PAM solution
- All access is logged and recorded.
Single Account devices
There are many devices that only support one administrator account. Often these systems are overlooked and the compromise of these devices/applications will eventually lead to a data breach.
Here are a few common examples:
- Logging network traffic at a switch or router.
- Having access to iSCSI accounts on a SAN (Storage Area Network) and therefore having direct access to data and virtual machine estates.
- Having direct access to system backups – so systems can be copies and run in single user mode on the attacker’s hardware.
- Having access to service accounts used by anti-malware and vulnerability scanning software.
- Having access to IoT devices then changing software/firmware to scan network, tunnel connections or launch attacks.
- Having access to Hypervisors.
These devices are also the most likely to have passwords that get shared around teams and not changed regularly.
It is important to on-board these systems to your PAM solution as soon as possible – remember your enemy knows all the default passwords (including the variations on MAC address). This use case neatly maps to third party access – for example, if you need a vendor to update your SAN.
Summing Up
Privileged Access Management is a major contribution delivering an airtight cybersecurity policy. Osirium PAM can deliver on these use cases and a lot more.
…and one more thing…
Privileged Access Management is an important line of defence, however organisations may find more security and better efficiency using Privileged Task Management and Privileged Robotic Process Automation.