Best Practices for privileged account on laptops

[Ramon]

At our company we've implemented a new security policy for our engineers. The engineers use their laptop as a Swiss army knife, the develop code install software and read their company mail on the device.

In the days where the domain account of the engineer was also a local admin, our engineers where happy and content with the policy. Due to mal- and ransomware we started a proof of concept where we changed to a local named admin account to do the programming and installing, and a domain account to access e-mail, ERPand office via Citrix.

In my opinion this is an acceptable solution, this is our normal 'modus operandi' at the IT department, if we need to install something we use the 'runs as...' command.

But you guessed it: Our engineers are not happy with the new policy. So what do you recommend? Have you encountered the same issues and how did you resolve those?

[Shannon]

Restricting rights to a local administrative account may reduce the risk to the system due to compromise at the domain level, but it definitely has its drawbacks, including: -

1. Decentralized control and management
2. Management of multiple local accounts

Assuming the benefits aren't justified, wouldn't it make more sense to implement / enforce adequate controls in an existing system & its constituents --- rather than change the architecture?

[Early_Adopter]

Turning this around.

You might consider turning that around and having your Engineers remote onto an environment that was a secured sandbox with some systems types had permissions on for developing their code.

Thn have them use their laptop effectively as an appliance that they use without permissions to access corporate email, do their admin etc and if essential scour the internet for lolcats...

It would probably make them even less happy, but would allow you to secure a lot of aspects of the dev systems more thoroughly, bubble them up in a few layers, monitor well,  and you could always sweeten the deal by providing them some powerful dev platforms that are quick to compile etc.

there are a host of  solutions and work rounds such as PAM, 2FA, jump boxen, isolation and hardening (Developers really like tthis last one...) that you can employ as well as restricting accounts.

To riff on @Shannon It does seem to me that by using a local account on a laptop you lose a lot of context on user behaviour and if it’s compromised you don’t have as much visibility into its authentication centrally so by running it like this you might give an attacker a system they can persist on Long tiers while studying and waiting to pivot to some new credentials.

[HackneyB78]

I've seen your approach used and I consider it a good compromise.  Non privileged daily use account and a separate local admin (or admin of a set of systems) for software installs and configuration changes.  

Many benefits .. entering a new password is quick, admin account is never left logged in.  Email and primary tools on one system which helps productivity.  PCI DSS requires this type of setup and this fact could be motivation for end users.  

Offering users separate terminal servers / jump servers works too but then you run into having to provide the same custom hardware they would enjoy on their PC.  

[mgoblue93]

As a software developer, and someone who has led teams of software developers, I wouldn't be happy about this either.  Ha!

My laptop is indeed my swiss army knife.

But I do have to say, in my experience, I haven't had problems with staff and malware because they had admin rights.  Generally, they're doing legit work and visiting legit sites on their laptops.

1.  Are you sure this is a technical problem?  If someone is downloading crap on their work resources, I would say that's a performance management problem -- they're violating their EULA and/or SLA.

2.  A good technical solution is to virtualize the development environment.  Have a development environment template which the developer deploys based upon their needs.  They have root access to only the guest (which makes them happy) but not the host (which makes YOU happy).  If the guest ever gets hosed, you just delete it and the developer redeploys from template.

[Early_Adopter]

@mgoblue93

Yeah it’s poor to lose capability - not nice... but you can better control what people can do from virtuliaed/ constrained HW. On the compliance  it think quite often the dev will be targeted from a site they legitimately use - waterholing/ phishing etc. Social engineering is much easier if they are an admin.

[Deyan]

I believe that here again you need to compare security vs performance and comfort of staff.

In my opinion which is mostly leaning towards security - I would not allow local admin accounts on laptops that are known and usable by the personnel. Network accounts should be used for both administrative and user functions - separated and provided to the relevant employees based on their role.

Assuming a company has policy towards acceptable IT use, internet/mail usage, desktop/laptop computing - I would say that the admin privileges on the laptops for the normal users (developers or whoever) could only introduce risks for them to breach any of the policies.

I am not sure why a developer is "happy" when they have privileges to modify the registry keys under Windows for example... but I definitely see risk in having privileged beyond your job requirements.

My opinion is that company's policies should be enforced to the most possible extend via the technology and if for example - compliance to the acceptable use policy requires that admin rights are removed from employees - then do it - explain to them that even if they had admin rights - the would be breaching company policy if they perform prohibited functions. Sorry if this sounds unrealistic to you but I believe that's how it should work...

[Shannon]

I agree with @Deyan, about an organization's policies being the deciding factor --- If what you're doing isn't an exception, it's a violation...

@mgoblue93 virtualization would be a good solution so long as the host doesn't have processor vulnerabilities like Spectre & Meltdown, which allow compromise of a host from its virtual systems, else a lot of VMs might be be impacted if the host itself gets affected...

[Ramon]

See if understand both comments.

Don't take technical measures but translate those measures into a Policy and steer on behavior.

Do not hide the cookie jar, but tell them it's not allowed to eat cookies, and leave the cookie jar on the shelf. Correct?

[Deyan]

Hey Ramon,

Actually it is - have your policies and use the technology you have to enforce them. If you do not allow eating of cookies - hide them.... if that makes sense...

Looking at your comment - I'd say that the positioning is wrong.

1st is the law - "dont eat cookies" then it the distribution of controls to ensure that wont happen - hide the cookies, lock the jar, put a guard to stay next to them..... whatever

in this case - the developers have the cookies right in front of them - if the company does not allow eating them - it should hide them.... not leave the cookies right in front of them and rely only on the policy.... - hope that makes sense.... Security Technology is only there to help organizations enforce their policies (written or not)