Managing privileged accounts is a lot of work. In the old days everyone knew the password of the root and administrator accounts and logged on as such whenever they needed to get some work done. But that introduces all kinds of risks and problems including:
- Keeping track of who knows each password
- Handling password change and distribution when someone is terminated or changes jobs
- Keeping passwords secret when that many people know it
- Accountability between admins
So, to deal with that, best practice dictated that we stop using built-in accounts like root and administrator and instead give each admin authority to each administrator, using their own personal account.
That lead to other problems, because admins do a lot work (like everyone else) that doesn’t require admin authority. And those activities (e.g. web browsing, email, opening documents) are dangerous no matter what – much less if you are logged in with unnecessary privilege.
So best practice came to dictate that each admin have two accounts – one with normal end-user authority – and the other privileged. The unprivileged account to be used for everything by default – and the privileged account only to perform actions requiring that authority level. Rather than logging in and out all day, we encouraged admins to use tools like RunAs on Windows and different ssh client sessions or su/sudo on Linux.
But as attackers became more focused on the endpoint and developed more effective ways to harvest credential artifacts (think pass-the-hash, Mimikatz), it became clear that more separation was needed than simply different accounts. Endpoints likewise need to be kept separate between end-user and privileged activities.
All of these factors really combined to make privileged account and session management (PAM/PSM) technology a requirement for enterprise security. PAM & PSM though make it easy to securely share built-in accounts like root and administrator. This is valuable for 2 reasons:
- facilitates secure administration of systems and devices that don’t support individual admin accounts
- allows fast and easy implementation because you can quickly provision devices with their built-in admin account and then simply entitle the appropriate admins with access
But at the end of the day, you really want to avoid using shared accounts wherever possible – even when they are under the protection and management of PAM/PSM. In this webinar, we’ll explore all the reasons why this is true but the biggest reason is to preserve attribution in system logs. That becomes increasingly important when you analyze privileged activity with user entity behavior analysis (UEBA) and all the other security analytics gaining momentum right now.
In this real training for free session, we will explore all the different methods of privileged account management and show why it’s so important to reach the top of the maturity model: dual accounts for each admin with full attribution across the entire stack of logs. We will look at how to accomplish this and potential pitfalls. For instance, how can you ensure that only Bob has access to Bob’s admin account? And how do you implement dual accounts without all the provisioning and maintenance burdens commonly associated with this privileged account model?
BeyondTrust is our sponsor for this real training for free session and Martin Cannard will show you how their PowerBroker technology helps you implement dual accounts without all the pain and work.
Please join us for this real training for free event.