For years we've all been preaching that to protect admin accounts (and other privileged users) you
- Need 2 accounts: one with privileged authority (e.g. rsmith_admin) and one without (e.g. rsmith).
- Should only use their privileged account for actual operations requiring such authority
- Should perform all other “end-user” activities to their non-privileged account especially things like email, web browsing, opening document and any other content from the web
And we've recommended different options for complying with those requirements
- Cruel and unusual: log in and out each time you need to switch between privileged and unprivileged
- Also painfully impractical: carry 2 laptops around and use each laptop for one of those accounts
- Logon to Windows with your non-privileged account and then use RunAs whenever you need to perform a privileged operation, or
- Designate a Terminal Services computer as an admin “jump box”. Logon to your workstation with your end-user account and RDP into the jump box with your privileged account
The problem is, other than method B, these measures don't protect you from modern attacks. But how many of us can walk around with 2 laptops? Even if you are tied to your desk it's an unproductive pain having to swivel or switch between 2 different PCs.
In this webinar I will explain why A, C and D don't protect you. It's all because of endpoint malware and the fact that there is no way to guarantee an endpoint used for any of the end-user activities mentioned above in #3 is free of malware. And if there's malware on that PC at the time the admin logs on or even malware installed after the admin logs on, there are ways to steal the admin's credentials directly or harvest derivatives thereof with the same result. Some of the attacks include:
- Good ole key stroke logging
- Pass-the-hash
- Background RDP/SSH session
- Harvesting of other credential derivatives such as cached logons, saved credentials
- The list goes on
So what can you do besides having 2 dedicated PCs? I will show you 2-ways.
- DIY 1: My first DIY method requires a jump box where RDP is protected by the right-2-factor authentication and logon restrictions are implemented for each privileged access method. There are number of pieces involved to get this right but it does work. We'll look at authentication silos, logon rights, IP Security policies and more.
- DIY 2 and 3: My other DIY methods leverage HyperV, BitLocker and WindowsToGo
- One Identity: This is far more elegant and secure solution combines Privileged Session Manager with Defender strong authentication. You'll see how the admin can open privileged sessions via RDP, SSH, etc very quickly without the privileged accounts password ever being revealed to the workstation or admin.
This is going to be very technical webinar packed with “how-to”. Don't miss this real training for free ™. Please register now.