That’s quite a bold statement to open with, particularly given how many different security technologies there are today. Holding one single technology control up above all the others requires quite some justification.
The simple truth however is that almost every single successful security breach will involve some sort of abuse of privilege. Whether you are hit by some low and slow attack sponsored by some foreign power or you have data stolen by one of your own employees, the chances are that somewhere in the kill-chain was an escalation of privilege which allowed the attacker to compromise a system, bypass another control or access the sensitive data. I recently worked with a large telco which had repeatedly been hit by ransomware and on one occasion had lost six filers worth of data because the compromised account had far too much privilege.
Security professionals look at threats and tend to focus on the head of the kill-chain, trying to prevent or detect the initial penetration. More recently the emphasis has begun to move to user behaviour analytics to try to detect things like lateral movement which might indicate an unidentified compromise, but if every kill-chain is different except for the commonality of privilege escalation then that surely has to be the best choke point to stall any attack?
Privilege Access Management (PAM for short) is based upon one of the earliest and simplest premises in information security – Least Privilege, the concept that you should always have the least privilege required to perform whatever function you are currently engaged in. If you need more then you take it on temporarily but relinquish it as soon as possible. A sound principle, but one we abuse every day. How often do you see system administrators login as root on unix systems or Administrator on windows systems and keep it all day? The same is true for DBA’s and application support people; everyone does it.
It’s a very common story across even the most sophisticated of enterprises. I have even seen a bank with almost twenty thousand unix servers all with the same root password, known to every unix system admin person as well as probably very many other people, and changed only sporadically due to the challenge of doing that. Organizations frequently hand out local admin to both servers and desktops because applications require it or because users need it to get through their day. And the wonderful world of Devops has ensured that developers now often have too much privilege on production systems of all sorts.
Privilege Access Management makes all these problems go away. At its core it provides a mechanism which supports least privilege by allowing authorized users to take on just as much privilege as they need and for as long as they need it. As a bonus, it will also fully manage those privileged accounts on all of your systems allowing every one of those unix systems to have a different, strong password which is automatically changed on a regular basis. PAM systems will also provide secure audit trails so you can see who is using privilege and even correlate its use with trouble tickets or outages, but most of all they provide a robust workflow framework which allows you to define and manage how privilege is acquired and used.
And it is this last point which is probably the most significant; privileged accounts are there for a reason. You need to be able to access them to install or change software for instance or to start and stop some secure services; create new accounts or to do a multitude of other things which normal users should not be allowed to do. A good PAM system must be like any other good security control. It should stop the bad people and make life no harder for the good ones. Actually, PAM can make life somewhat easier for the good ones when implemented well. It can make systems easier to access and audits less onerous. It can help to reduce outages and help to pinpoint the cause of outages when they do happen.
The challenge when implementing a PAM solution is seldom the implementation of the PAM system itself. The real challenge lies with understanding your existing operational model and how the use of privilege overlays that. Then you need to understand which parts of that model are like that because they need to be and which parts are like that because there was no other way. This is a great chance to understand your organisation in a lot of detail, which for a security team is always useful. Your first PAM project is likely to throw up all sorts of things like how your break-glass processes work or the extent of developer access to production you have. A successful PAM project needs to take all of these existing processes into account because it is these processes, the ones that already utilise privilege accounts, which need to be on-boarded into your new PAM solution.
This may sound like a lot of work and indeed it is. Work that normal security teams may be unfamiliar with as it is BA skills, which are most important here. The more effort and engagement you put into understanding the existing operational processes and what drives them, the better, as you are about to own those elements which touch privileged accounts. But this is also the point where you can improve the lot of the operational teams just as they are expecting another control which makes their lives harder. Building an automated process which takes away some of the pain of getting pre-approval for instance may significantly increase a support team’s effectiveness. Building integration with trouble ticketing systems for instance which short-circuits approvals where a high severity tick is open for a particular server may meet your compliance needs whilst helping operational efficiency.
The privilege release area is not the only place where considerable work on the process model and integrations may be important. Deciding who can access which privileged accounts, gaining auditable approvals and performing periodic recertifications of those rights is a vital part of any PAM system. Here integration with IAM systems can make a huge difference in terms of automation and light weigh compliance. As with so many things a little up-front thought and planning can have significant impact in terms of operational efficiency and effectiveness.
Organisations with a pervasive, effective PAM system are far less likely to suffer loss due to a breach and any loss is far lower than in organisations without such controls. In terms of return on security investment there is no better value for money than a well implemented PAM system. It may not have the glamour of something like a big data user analytics system or a threat intelligence framework but in a green field environment it is undoubtedly the first thing I’d implement. That way I might survive to implement other controls too!
Want to learn more about implementing a PAM solution?
Watch our webinar here and find out how SPHERE can help you!
