2

We're a medium-sized enterprise with many different IT administrators (e.g. domain admins, Azure admins, DB admins, ...). We're worried that hackers can easily breach an admin's laptop and through that steal data / do serious harm.

We thought about using VDI / jump server so that an admin would connect from his personal laptop to that remote machine and administer the network through that. However, it doesn't seem to really solve the problem as if an attacker owns the admin's personal laptop, he can simply control the remote machine. We also read about Privileged Access Workstations (PAW). While the approach seems safer, it's too cumbersome for our users and requires discipline.

What's the best (practical) way to protect IT administrators?

  • I have a PAW--sort of, I had to modify the concept a little for our environment--and don't find it particularly cumbersome. I can't speak to your users and what they find cumbersome, however. – Katherine Villyard Oct 23 '18 at 21:19
  • 2
    What about a PAW is cumbersome to your users? Maybe there's a modification to what you've read that would work. I think a PAW is by far the best solution, and if we can work out the sticking points that could be your best bet. – Daisetsu Oct 23 '18 at 21:44
  • I think it is important to clarify - even for yourself - which threats you want to mitigate. A compromized laptop a.k.a. stolen? Malware like keyloggers on the laptop? Password compromize? Then it should be an easy step to identify the necessary actions. If you do not want to take certain actions, you are at least clear what remaining risks you need to accept. If using a jump server, you should protect the access, like 2FA. Then the remaining risk would be malware on the laptop... – cornelinux Oct 25 '18 at 6:47
  • Thanks for the comments @Daisetsu . The complaints we've got are around the use of two separate desktops that you need to jump back and forth between and the chance of mistakenly using the wrong desktop for the wrong activity. – Tom Alexander Oct 28 '18 at 8:37
  • Tom, one interesting solution could be to use a KVM switch, so that you could use a single monitor, keyboard, and mouse for both systems. To differentiate between the two, you could enable high contrast mode in windows, which will make the PAW obvious to anyone the second they see it. – Daisetsu Oct 28 '18 at 14:59
4

I agree with and would like to expand on Odo's answer. I know for our organization the idea of a dedicated PAW was great, but the practicality of implementing one based on actual STIG guidelines wasn't there. Especially for SMBs, having a dedicated access VLAN with that machine with only specific admin accounts it's a little more than most can handle. We ended up implementing an environment akin to what odo suggested. We have multiple administrators who perform various tasks across multiple sites, and so the threat vector for someone to gain admin access to our DCs was significant. I think you'll find though if you really consider your roles, there are only a handful of admins who actually require full domain admin permissions on your DCs. We ended up creating (for lack of a better word) an elevation admin group that our everyday IT admins used on everyday workstations. These accounts have no administrative privileges on the servers, and have actually been denied logon privileges through GPOs. Due to restrictions in our environment we aren't able to use any mobile devices in our building, and don't have the budget for tokens, so MFA wasn't really an option. We ended up using Terminal Service GPOs (I think they're called RDS now though) to allow or deny remote access to accounts depending on their privilege level. For example the elevate admins aren't able to remotely log into any workstation, and domain admins aren't able to remotely login to any servers (should also mention any members of DA/EA are also denied from login on everyday workstations). This significantly helps prevent an attacker from stealing credentials that are used on a daily basis and wreaking havoc on your system. There's some pretty useful guidelines on this from a number of different sources, I (we) generally use STIG templates to create our baseline. Some important ones to note which touch on the stuff above are Deny Log on for highly privileged domain accounts (V-63877) and deny log on through RDS for highly privileged domain accounts (V-63879). Your administrators would need to elevate in a UAC prompt using their privileged accounts, but it ensures that if their laptop or workstation is broken into, the attacker would need multiple sets of credentials really accomplish anything.

  • Thanks @Gansheim, but would you still let users use the same machine both for non-privileged and privileged work? How is your machine set up (regardless of user accounts and authentication mechanism)? – Tom Alexander Oct 28 '18 at 8:42
  • Our privileged users use the same machines for administrative tasks, as they do for everday use. The key to our model is the use of separate privileged accounts, the level of access of each privileged accounts on varying machines, and which accounts have remote access rights. Obviously this doesn't help if a machine is infected with a certain type of malware and you have network shares on there to your server, but honestly that's a completely different threat vector/topic. – Gansheim Oct 29 '18 at 12:41
2

Using a VDI/Jump Server isn't such a terrible idea, it's a pretty common technique - if you set it up with some sort of multi-factor authentication (which isn't on the laptop) then at least a compromised laptop can't just connect into your management network.

  • 2
    Thanks, Liam! However, if an attacker is on my laptop, can't he just wait until I authenticate and then impersonate me and fully control the remote desktop (e.g. send keystrokes/mouse movements to the remote desktop to launch a script on the remote desktop)? I think that a compromised laptop that has access to VDI/Jump Server practically lets attackers control the VDI desktop/Jump Server, no? – Tom Alexander Oct 23 '18 at 20:21
  • That's certainly not untrue, but there's a certain point you have to accept it's always possible to be compromised in some way - at the end of the day it's all about risk mitigation. You can apply stronger controls to the jump box, like having the admin log in as a standard user rather than an admin, follow some good hardening guides etc. Also consider if you can do any proactive monitoring of both the laptop and the jump box to spot any compromise or anyone doing something they shouldn't. – Liam Stevenson Oct 23 '18 at 20:27
1

I'd separate administartors' less-privileged operational accounts (for day-to-day duties) from more privileged accounts like domain/db admin (which are used during changes in domain/database architecture - a much rarer tasks).

Yes it could require fine-tuning, custom roles and so on, but during it you'll better understand your RBAC-related landscape.

For most privileged accounts I'd recommend shared passwords (i.e. half of password stored in warbox) combined with 2FA.

  • Thanks @odo, but would you still have users doing both non-privileged work and privileged work on the same laptop? – Tom Alexander Oct 28 '18 at 8:41
  • @TomAlexander of course it's better to arrange a separate restricted workstation for privileged tasks, but final solution depends on many factors like threat model, company's maturity level and so on. – odo Oct 28 '18 at 13:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.