Search This Blog

Sunday 16 November 2014

CyberArk Privileged Identity Vault - Enterprise Case Study

Cyber-Ark Enterprise Password Vault (EPV) 

Cyber-Ark EPV is a suite of applications to securely manage passwords and other related sensitive objects.  While it typically is used to store and manage privileged account passwords, it has the capability to manage any type of sensitive information including such as database connection strings.

Features include:

  • Granular password object access controls
  • Ability to manage passwords automatically as per a predefined policy (i.e. change password every 90 days, verify password every 30 days, etc.) for many platforms
  • One-time passwords possible
  • Dual control authentication possible
  • API spanning all common languages/development environments to integrate with custom applications facilitating secure storage and retrieval of sensitive application specific credentials and other information (i.e. private keys, database connection strings, etc.)
  • Seven layers of security/access control for vault objects

Privileged Password Management

What is a privileged account?

Privileged accounts are a required part of any software whether it is an operating system, database or application. Most hardware appliances also require privileged accounts for administration.

Similar to the UNIX's root and Windows' administrator accounts, privileged system accounts are required for systems to function and are frequently used by system administrators to do their jobs, granting special system privileges that average users don't need, and that even administrators need only from time to time when making major changes.

However, these privileged accounts have no accountability, as they typically do not belong to any individual user and are commonly shared by many administrative staff.
Alternatively, many organizations bestow excessive privileges onto the accounts of those conducting administrative tasks

So why care about privileged accounts?

These accounts have elevated access rights, meaning that those with access can circumvent the internal controls of the target system.

Once these controls are bypassed, users can breach confidential information, change transactions and delete or alter audit data.
Privileged Account security is at the top of compliance and auditor’s concerns.

The Problem with Privileged Passwords
  • The most common type of hacker breaks into target systems using default lists of Privileged User accounts and can easily crack weak passwords.
  • Compliance audit regulations (such as Sarbanes Oxley and PCI ) require organizations to periodically monitor and prove who has accessed shared accounts, what was done, and whether passwords are managed according to policy

  • With hundreds or more servers and network devices, manually updating and reporting on Privileged Passwords can be extremely time-consuming, in particular, defining individual user access to a shared account, and when the access occurred
  • Most enterprises consist of a multitude of disparate IS platforms (Windows, UNIX, Mainframe, AS/400, Databases, etc…). Each of these platforms pose unique challenges in managing privileged access
  • Too many people have access to passwords for “generic” privileged access accounts (Administrator, DBA, ROOT).
  • Too many people have more access to privileged resources on their own account than is required by their role.  Access tends to accumulate over the course of a user's employment.
  • Most companies have not done a great job in the past in cleaning up user accounts that had privileged access.
  • System or service accounts have been created with significant privileged access, but for technical reasons have not followed password compliance standards.

Case Study:  Large Global Enterprise with multiple outsourced data centers.

 Outsourcing your data center administration has particular challenges when it comes to privileged access management.  In this case, a third part organization has access to the very keys of your critical information assets.  Typically outsource arrangements allow for pools of administrators in off-shore locations, with a high rate of turn over.  Yet we bestow privileges onto their accounts, or give them unfettered access to group accounts that have excessive privileges and little or no monitoring and auditing capabilities. 

In this case study, an organization has implemented Cyber-Ark Enterprise Password Vault redundantly between two data centers.

This implementation will allow the various Business Units to Securely control access to their Privileged System Accounts.  This would include "infrastructure service accounts" like ROOT, Administrator, SYS, and DBA, as well as Business Unit and Application specific account that required privilege for the purposes of administration.


 "Security Policies and Implementation Issues" By Robert Johnson
The new privileged access follows a Best Practice “Firecall Process

Any employee (local or off-shore) with an "Administrator" role in a particular environment would not have these privileges added to their own user account. Nor would they have access to the password of a shared privileged account.  

By virtue of their role, the employee would be granted access to the Enterprise Password Vault, to check out a privileged account for the purpose of administration. 

The easiest way to implement this, is to show them a password for the target system upon checkout, and allow them to cut and paste it into a remote access session, resetting the password immediately upon use. Better yet, hide the password, but log them directly into the target system via remote access proxy.  Again, a one time use password would reset to restrict un-approved use.

Various workflow options can be applied to this process, including but not limited to two-factor authentication (requiring a token as well as your user credentials) or dual authentication (requiring your manager or delegate to approve your access). The Password vault can also integrate into most change/incident management systems, and can require that an appropriate change ticket be in place in order to grant access, and to outline the time frame and target system of access. 

All passwords in the vault are secured with industry standard strong encryption, and replicated to the opposite data center.

There is no single point of failure, and should “both” vaults become unavailable, there is provision for an “out of band” password recovery. 

Within each vault, there is the concept of "safes".  A safe is basically a collection of privileged ids with a common association. Maybe a Business Unit would have all of their privileged ids from various applications within one safe, or a particular third party provider might have all of it's privileged ids within one safe. 

This infrastructure can potentially remove privileged access from thousands of end user and service accounts.

In fact, the company was able to remove a couple hundred individual third party user accounts that had direct Windows Domain Admin access, and replaced them with a small pool of Domain Admin accounts in the vault.  Another pool was created for UNIX root accounts.  By virtue of their role, the Administrators could check out access to perform their duties, but the request was logged and sent to SEIM.  The treat landscape was greatly diminished by this one action.     

They went on to enroll Business unit applications into safes, and saw a significant reduction in the number of unmanaged privileged accounts being reviewed annually.

Future Extensions:

By adding Privileged Session Manager, the company will be able to enforce policies around the actual content of a privileged access session.  Individual commands or processes can be whitelisted/blacklisted by role, and any activity deemed anomalous can be flagged and sent to a manager/audit for review and/or attestation.  

Entire administrative sessions to a target system can be recorded - both for secure remote desktop in the case of windows, or SSH in the case of UNIX or network appliances. These sessions can later be played back, annotated, and approved by managers or audit.

for more detail on this Privileged Session Manager please see my blog 

Supported Managed Devices:

    Operating Systems
      Windows, Linux/UNIX, OS390, AS400

    Windows Applications
      Service accounts, Scheduled Tasks, IIS Application Pools

      Oracle, MSSQL, DB2,Informix, Sybase, sny ODBC compliant

    Security Appliances
      CheckPoint, Nokia, Juniper, Cisco, Blue Coat,Fortinet

    Network Devices
      Cisco, Juniper, F5, Alactel, Quintum,

    Applications –
      SAP, WebSphere, WebLogic, JBOSS, Oracle ERP

      Microsoft, Sun, Novell

    Remote Control and/Monitoring
      IBM, HP iLO, Sun, Digi

    Generic Interfaces – any SSH/Telnet device, Windows registry


Privileged Identity Management - Make those with the most access, accountable for their activities!
Security Musings: Risk reduction through Jump Servers 
ESG: Validating Privileged Account Security While Validating CyberArk

No comments:

Post a Comment