Privileged Password Management: Cloakware & Cyber-Ark

Over the last few months, I've been involved in a project to help address concerns over the end-to-end management of privileged passwords (root/administrator), with a particular focus on embedded passwords used by applications to connect to databases. It's very common today for applications to have embedded passwords, such as in configuration files, for accessing databases, including apps that need to access credit card data. While some tools, such as WebLogic Server, address this concern by encrypting the passwords in the configuration files at load time, this is not necessarily a universal solution. Additionally, the distribution of passwords to these systems is generally performed in a less-than-optimal manner.

To that end, I've found a couple products that seem to provide reasonable solutions to these problems. Following is a quick synopsis of those products and my quick thoughts on them. Please note that these comments are not compensated by either vendor. If you'd like to compensate me, buy a kettlebell! :)

Understand the Problem
Before I launch into each vendor and their capabilities, allow me to first level-set the problems, because there are a couple.
1) Superuser Passwords. There are several ways of dealing with root and administrator passwords, and so one would not normally think of this as a problem. AD handles Windows Administrator accounts, LDAP or Kerberos can help with root passwords. TACACS can help with the enable and exec passwords on network devices. But what if you want to manage all of them through a single interface, and you don't have the time or energy to implement a comprehensive identity and access management solutions? Moreover, what if you don't really want your sysadmins to know the true root and administrator passwords, except when absolutely necessary, and in an auditable fashion?

2) Embedded Passwords. An even more challenging problem than managing superuser passwords is dealing with the myriad of embedded passwords within applications used to access data on back-end database systems. If any of that data is sensitive, then you want to be extremely cautious about where those passwords are stored or loaded by apps. However, developers don't always think about these concerns. Wouldn't it be nice if you could just never give the developers the passwords in the first place and still manage to have improved access control around those database calls, beyond use of stored procedures?

Solving the Problems: Cloakware & Cyber-Ark
I'll go into each vendor in more depth below, but I thought it would be best to start with the common capabilities that these two solutions have. Both vendors have an encrypted vault within which passwords are stored. Both vendors provide APIs and local agents to query and retrieve passwords from the vaults as needed. Both vendors make those calls over secured network transport. And both have some capabilities in authenticating, via attributes, the process or application that is requesting a password. For superuser passwords, both require a logged login to a console to reveal the superuser password before using it on the system in question. Both vendors are also able to dynamically change passwords, both in databases and on systems and network devices, either at the push of a button, or on a schedule. And, lastly, both vendors also have application plugins/wrappers, such as for WebLogic, that will intercept database calls to substitute the correct credentials, eliminating the need to provide passwords to developers.

As described, either vendor is a viable option for management of superuser and embedded credentials. There are, however, a few key differences, which may sway you one way or the other as you consider them.

Cloakware
Cloakware is based out of Vienna, VA, which is just up the road from where I'm working these days. Their product is available either as software or as an appliance, and is supported on Linux, Solaris, or Windows. Their solution is very flexible from a scalability perspective in that it leverages existing technologies for load-balancing and high-availability, rather than locking into proprietary solutions. From a load-balancing perspective, you simply need to ensure that sticky sessions are enable to ensure proper performance. An external database can be used for the storage of encrypted data. You can configure the DB in a standard HA configuration to achieve your uptime requirements.

Cloakware is in direct competition with Cyber-Ark, and as such is in a bit of a catch-up mode in terms of full features. They are, for example, releasing new features to integrate with WebLogic this Spring, and they are also not as adept at integrating with Windows AD thus far. This is all changing as they continue to grow and mature, but it may be a concern, particularly if you run a heavy Windows environment.

One of my favorite unique features of Cloakware is the "panic button." Cloakware's client agents, running on the servers using the service, can be configured to check several attributes of the calling process or application to ensure that it's authorized to retrieve a given credential. However, in a disaster recovery scenario, this authorization check may not be desirable. To get around it, you login to the console and hit the panic button, which allows all credentials to be retrieved without going through the attribute check. In this way, you can get your services restored asap, and then worry about locking things back down after the fact.

The other thing that I personally like about Cloakware is that they very well targeted to Linux environments. Where they fall short in AD integration, they more than make it up in being easily managed by your existing Linux infrastructure staff. If you're running a heavy Linux/UNIX shop, or if you distrust relying on Windows, then you'll want to check out this solution.

Cyber-Ark
On the other side of the spectrum, we have Cyber-Ark. This product is more mature by Cloakware, though the gap seems to be narrowing. They only run on Windows and have a slightly more complex architecture. Whereas Cloakware supports an external database over a network connection, Cyber-Ark currently only supports direct-connected storage, with the exception of iSCSI.

From a scalability standpoint, they rely on the built-in Windows Clustering solution. Given their Windows base, they integrate very well with Windows AD. Additionally, they have strong integration with Oracle environments due to a partnership with them. If you're running a heavy Windows/Oracle shop, then you'll likely find that your sysadmin are far more comfortable with this solution.

As an added bonus, Cyber-Ark also has the capability to provide secure file storage within their vault. Whereas Cloakware just stores passwords, Cyber-Ark allows users to login via the console or web interface and store files, which are then stored encrypted in the back-end system.

If you're concerned about the system security of this Windows-based solution, you should put those fears aside. According to their top SE, you would be hard-pressed to recognize the OS as being Windows when they get done with an installation because they strip it down to a bare bones state. They implement their own communication protocols that encrypt data as it's transmitted over the network. This varies from Cloakware, which generally relies on the industry standard HTTPS as a standard network protocol.

Conclusions
If you're looking for interim solution for superuser and application password management, then either one of these would likely suit your needs. From a feature perspective, they are very close, though Cyber-Ark still has a slight edge in product maturity. Cloakware was acquired by Irdeto late last year and is now starting to the feel the benefits of that transaction, allowing them to begin catching up.

Ultimately, it will come down to what base technologies your techies are most comfortable with, and what you want to integrate with. Both companies seem to be moving toward future integration or partnership with larger identity management solutions. Today they are both good interim steps, but in the not-too-distant future I would expect to see them grow into fully integrated IdM solutions.

About this Entry

This page contains a single entry by Ben Tomhave published on May 13, 2008 9:42 AM.

Reflections on the 2008 RSA Conference was the previous entry in this blog.

A High-End Sniffer/Analyzer/Recorder: NetWitness is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Monthly Archives

Pages

  • about
Powered by Movable Type 6.3.7