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:
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 |
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
Databases
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
Directories
Microsoft, Sun, Novell
Remote Control and/Monitoring
IBM, HP iLO, Sun, Digi
Generic Interfaces – any SSH/Telnet device, Windows registry
References:
Privileged Identity Management - Make those with the most access, accountable for their activities!
Security Musings: Risk reduction through Jump Servers
http://www.cyberark.com/resource/isolation-control-monitoring-next-generation-jump-servers/ http://en.wikipedia.org/wiki/Privileged_Identity_Management
ESG: Validating Privileged Account Security While Validating CyberArk
http://lp.cyberark.com/rs/cyberarksoftware/images/br-privileged-account-security-solution-9-26-13-en.pdf
No comments:
Post a Comment