Privileged Account Management is a major concern to large organisations trying to control the ever growing threat of the insider. Privileged accounts generally relate to super user accounts such as root on Unix, or Administrator within Windows, as well as service accounts and accounts used for account administration tasks. These elevated users have greater object access including circumventing audit and accounting processes.
The Risks
The biggest risk associated with PAM is that these accounts are often built into the underlying infrastructure, created at installation time. The non-practical option is often to disable as many of the high permission accounts as possible without impacting service. The second biggest risk with privileged accounts is that many are used programatically, hard-coded into scripts and code. This can make finding the password a lot easier. These accounts will often have permissions covering account CRUD activities, audit configuration and other meta-data related tasks.
The Users
Privileged account users are generally part of the system or security administration functions reporting into the CISO or CTO. Whilst the permissions are required for the owners to be able to perform their jobs, working in teams that configure and manage the auditing and reporting infrastructure, makes identifying and managing anomalous access issues time consuming, complex and at times political.
Basic Management
The accounts that are required, need to be managed effectively. That means strict correlation between the account and a tangible user record for accountability. Firstly, though, you need to be able to identify and analyse the privileged accounts and understand what accounts have access to which systems. The following is an example of a basic PAM policy:
- Infrastructure level complex password policies in place
- Expiring passwords, lockout and restricted time logons
- Accounts should be disabled when not in use
- Service accounts should be managed with generated passwords where ever possible or longer length pass-phrases
- Associated entitlements must be documented via access control and subsequent approval
- Account names should be renamed from defaults and well described in secure documentation
Anomalous Detection
Privileged accounts by association are internal to the corporate network. Their use is expected and activities by the accounts is not in itself cause for concern. However, due to the ‘keys to the castle’ nature of the permissions associated with these accounts, detecting anomalous and malicious use needs to be done quickly with an effective response. Anomalous use doesn’t always have to be done by users outside to the organisation. Anomalous use could also arise from an employee with authorised access to use the account, but using the account to view data, change processes and perform operations at a time or location that could lead to a security breach. Identifying any potential use requires detailed and accurate logging either via the proprietary system accounting or via a centralised System Information & Event Management solution. A centralised view is important, but also removing the potential for false positives is also key.
Behaviour Profiling
The use of behavioural profilers can assist in identifying how privileged accounts are being used and which activities are deemed to be anomalous or malicious. Behaviour can include which workstation is using the account, which network segment, the time of day, against which network device, file, object or process the account is being used. All of which help develop a picture of expected account behaviour, which helps to reduce the noise often created by viewing the logs of every account transaction. Spikes of suspicious use are then easier to spot and can be managed via the appropriate case workflow, notification and escalation processes to quickly track and resolve the potential breach.
Privileged accounts are here to stay so better ways of managing and reducing the risk their can pose is imperative if compliance and security efficiencies are to be achieved.