About five years back I might get one question every month or two on tacking privileged users. Nowadays, its more like one or two every week. I imagine that ten years ago or so the whole product space was about five guys in a garage in Israel. Why the change in uptake and urgency? This is not a new problem, its been a large scale problem for at least two decades. Why is it now top of the agenda? I assume that the CEO of CyberArk (who recently did an IPO) has a picture of Snowden above the bed that they bow to and thank each night.
In 2011, CyberArk has $36M in revenue, in the last 12 months its $134M. That is serious growth for an area that was an IT Security backwater for its entire existence.
The knock on effects are quite important for companies to understand. On the demand side, 5-10 years ago, the only companies that invested in Privileged user stuff were the usual suspects - large financials and the like. Nowadays, the demand is widespread, bog standard Fortune 500 companies who have a tiny fraction of the IT Security staff and budget are barreling down the Privileged user security path.
That brings us to the first problem, the tools were originally developed for deep pocketed institutions with a small set of use cases. Now these tools are aiming to address general Fortune 500 writ large and purport to take on a whole new set of use cases. Can they? Technically, sure. In reality, maybe not.
First problem is people. Sure we can see the revenue tripling in a short amount of time, but does anyone think there are 3x as many Privileged User pros in the market? Probably not. Five years back, the main complaint of Privileged User management systems was - they worked for a small set of use cases, but were expensive. It was rare to hear of failed deployment projects. Now they are being pushed into different kinds of companies, with smaller IT security teams, trying to handle a wider range of use cases, and we are starting to hear about failed deployments.
So how should people tackle this? Its a longstanding problem, so I am very glad to see companies finally getting around to taking a run at solving privileged user security problems. And in fact the tools in teh space are quite capable with an important caveat. The caveat is, like Charlie Munger says "you have to stay within your circle of competence. Its not a competency if you don't know the edge of it."
Too many companies look at privileged user management as a quick win. They pull up ye ol' Magick Quadrant, pick the one that scores the best, and assume that in 2 months their decades of security holes - poof - vanish! Privileged user management is an important problem trying to address and there are good solutions out there, but this is not a quick win space. Its way more a three yards and cloud of dust, incremental win space.
People to deliver are at premium. Internal ownership can be fuzzy - is it a security thing? An ops thing? an identity thing? Do you even have an identity team? Also who watches the watchers?
Rolling it out is cumbersome. I recommend small chunks of use cases and platforms, probably one at a time. The users you are impacting are very busy and critical resources. There is the potential for emergent chaos due to the fact that many users have ids and passwords hard coded into shell scripts and configs. The Old Testament security folks will say "well those deserve to break", maybe they do, but stepping into the void and taking unknown risks on critical systems is not a recipe to handle the Availability A of CIA.
Misconfiguration is a problem, the tools have to speak all manner of arcane protocols. Plus the Privileged user tool itself is a major target. Its not clear that the end deployments are as hardened as they could be.
Some goals - first do not tackle all systems and use cases out of the gate. Be conservative in what you can tackle. Start with a basic jump host, then password management, then session monitoring, then strong auth. This is just an example, but the key point is each should be a mini project and not all attempted at once. Each project should be very tightly scoped and focused with detailed requirements, ownership and solid test cases.
Its a long standing problem, but proceed carefully so that you are reducing not introducing (financial, infosec, or career) risk.
In my travels as a security architect I talk about this all of the time too. Whether it is MS SQL single sign on or Domain admins, my advice is the same… And I equate it to a WWII submarine movie. You should use elevated privileged accounts like periscopes on submarines are used. You get graded on how short a time you are actually logged onto the elevated privileged account. The shorter the better, and everything should be done to make that experience as uncomfortable as possible. And one of the biggies is elevated privileged accounts should not have an EMAIL account associated with them!
Posted by: Sajata | October 04, 2015 at 08:34 AM