Plugging an identity-related compliance hole
I just got off the phone (off the Skype Out doesn't have the same ring to it ;-) ) from a briefing with
Cyber-Ark Software . The company has been around since 1999, with headquarters in Massachusetts - the founder actually originates from Israel - and has received $23M in funding. It has more than 200 customers, including the likes of ABN Amro, citigroup, ING, Lehman Brothers, Pfizer and Wells Fargo.
Cyber-Ark's business is based around what it refers to as
secure Vaulting Technology, for the storage and exchange of sensitive information. What on earth has that got to do with compliance holes? I posed myself the same question at the beginning of the call. In fact it appears from my discussion that the link to identity and compliance is only something that Cyber-Ark has made in the last 12-18 months as more and more companies have come under the scrutiny of auditors as result of regulatory compliance. The link between identity and compliance is nothing new (and something I discuss in our recent identity management report) so what's the story?
At its heart it relates to privileged accounts: Unix root; Oracle's inbuilt system and sys accounts (as a former Oracle DBA it bought back memories of customers looking aghast as I sat at the SQL Plus prompt and informed them that I was in a position to delete their entire database even though they hadn't give me the passwords); Cisco's IOS enable; accounts embedded in batch and admin scripts and so forth.
These accounts pose, quite rightly, a problem for auditors. By virtue of the privileged status, users of those accounts have significant power to potentially bypass audit controls. This makes it difficult to prove - and that's what auditors want - that power has not been abused. This is where the Secure Vaulting technology comes in. The privileged account details are treated as sensitive information, stored in an encrypted form in an Enterprise Password Vault. If an administrator requires privileged access, they first have to go via the vault which maintains an audit trail of all such accesses. Obviously, it can't control what's done once logged on as an administrator and so has to be implemented as part of a broader auditable security framework, with access control and audit. But it ensures accountability - and also periodically regenerates passwords. It also overcomes the challenge of the forgotten administrator password scenario (I remember being shown a hack on a SunOS 4 workstation to recover the root password 30 minutes before a critical product demonstration where rebuilding the system wasn't an option!); the DBA's been run over by the proverbial bus problem; and disaster recovery situations.
This is not something that is acknowledged, at least in my research, by current identity management players, and it's therefore no surprise that Cyber-Ark has established partnerships with the likes of IBM with Tivoli Identity Manager.
Although Cyber-Ark seems to address a very real issue, it seems to me that the company faces a couple of challenges. First, there's the fact that they don't fit well with into the product/technology buckets of the big analyst firms (but perhaps should have a place in
Compliance Oriented Architectures - hint to our friends at
RedMonk). Second, and more significant, is that the compliance risks associated with privileged user accounts are not well understood - until after an audit.
Whether or not organisations need an off-the-shelf solution to this problem, it seems to me that Cyber-Ark raises an important issue that can not be ignored in planning for compliance.
