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]

Let me correct / clarify both of your statements @Ramon

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

Correction: Don't take extreme technical measures if costs outweigh benefits, but ensure that your control measures comply with the organisation's policy, and adequately enforce the policy.

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

Correction: Continue to eat cookies, but also ensure the following: -

1. The cookie jar is kept tightly closed
2. The cookie jar is kept in a locked cabinet
3. There's a curtain covering the cabinet
4. There's a sign on the cookie jar warning people not to take the cookies
5. The cookie jar is regularly checked to make sure the cookies aren't touched
6. There's a pet dog that growls when anyone goes for the cookies

As controls, there are preventive controls (1, 2 & 3), deterrent controls (4) and detective controls (5 & 6)

[mgoblue93]

> 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

I hear this kind of reply a lot.

I respectfully shake my head.  That's a process or management-type response. 

A dev is not targeted any more or any less than any other role in the organization.  And the notion of being an admin is a straw man argument.  Why? Two words:  Microsoft Outlook.  Anyone in the organization can open a link, other than the devs, and potentially do just as much damage as the devs.

Before reading on though, please note, I AM NOT advocating for a lack of controls or a development environment that is a free-for-all.

I disagree because people are losing sight of and the understanding of the difference between supported and supporting roles.

1.  A business is in business to make money.

2.  Q.  Does the software product or does the system administration bring in the money?  A.  Of course the software development end product is the revenue source.

Therefore, software developers are the supported role and system administration is supporting of the software developers.  NOT the other way around.

Now, if a software developer is loading malware on the system, they should be taken out back and flogged.  Especially doing something like that in this day and age. 

But that's a personnel control and not a technical one.

For the technical, that's why I provided my idea.  I'm sure there are many other ways to help the OP out.  But developers need to have the freedom to download and install stuff for prototyping and testing purposes.  Submitting baseline change requests to SAs all the time is not efficient nor a practical way of doing business.

The SAs need to have some control over the enterprise so they can manage and protect it.  That's why isolating an environment is a win-win for everyone.

[mgoblue93]

@Shannon

> virtualization would be a good solution so long as the host

> doesn't have processor vulnerabilities like Spectre &

> Meltdown, which allow compromise

That's a separate issue unrelated to the original post

The OP asked for strategies on how to keep the developers from compromising his/her network while still providing the developers the capability they say they need.

Your reply outlines a vulnerability which is taken care of by patching.  Not the differences between development and administration.  I'm sure the OP keeps his/her systems patched. 

[Shannon]

Actually, there is a relationship. The whole reason was to reduce the risks of systems impacted due to a domain account getting compromised by malware, right?

Malware can be engineered to exploit these vulnerabilities, and impact a system. Both Spectre & Meltdown are hardware vulnerabilities, and so can't be properly patched at the system level.

No doubt isolation is the best bet, but you may not be able to achieve this only through virtualization (unless the hardware isn't vulnerable) in which case network isolation is also an option.

[DanPeterson]

Hi Ramon,

You're even more generous than I would be!  😄

The code development should be done in a separate test and development network that's segregated from your production network.  The engineers and developers can RDP to the dev network and do whatever they want there to their heart's content. 

In prod network, all the techies (the engineers, developers, even system admins) should use a standard account with no special privileges, including no ability to install software other than what your company has already whitelisted, for all their daily activity like emails, writing documents, so forth.  Those with a need for elevated privileges should have a separate privileged account with privileges appropriate for their responsibilities.  Highly privileged accounts (domain admins, root) should be secured in some way, such as a privileged account management system like CyberArk or Balabit, or use of split passwords for 4-eye checks.

Any engineers who object should attend security awareness training.

My recommendation is to stand tough - and if you need to, get senior management to stand tough along side you - and tell the engineers the wild west days are over.

[Flyslinger2]

@DanPeterson nailed it.  In addition all auth should be multifactor.

All production admin accounts should be virtual and and those virtual sessions should be blown away DAILY.

Dev teams have no business in prod.

Laptops should be eliminated as they are risks.  Every developer should have a dumb terminal.  

[vt100]

This webinar from Beyond Trust specific to Privileged Accounts for Developers may be of interest to you. They are generally pretty good at starting those with problem analysis, general solutions and only then moving to the promotion of their own products addressing the problem:

[metasploit]

Hi Ramon,

If I understand correct,you want to both least privilege and productivity on employee laptops. CyberArk EPM can easily fit your needs.

Here comes short brief for EPM, if you want to get more details, please let me know.

CyberArk Endpoint Privilege Manager helps remove the barriers to enforcing least privilege and allows
organizations to block and contain attacks at the endpoint, reducing the risk of information being stolen or
encrypted and held for ransom. A combination of privilege management, application control and targeted
credential theft protection stops and contains damaging attacks at the endpoint of entry. Unknown
applications run in a restricted mode to contain threats and credential theft protection blocks credential
theft attempts. These critical protection technologies are deployed as a single agent to strengthen and
harden all desktops, laptops and servers.
CyberArk Endpoint Privilege Manager also enables security teams to enforce granular least privilege
policies for IT administrators, helping organizations effectively segregate duties on Windows servers.
Complementing these privilege controls, the solution also delivers application controls designed to manage
and control which applications are permitted to run on endpoints and servers

Thanks,

Sam Lu,  CISSP, CISM, CISA, CCIE#9892

Email: sam.lu@cyberark.com

[Ramon]

Hi Sam, Thanks for your answer, I've downloaded the spec sheet just now. Will definitely look into this.

Ramon

[metasploit]

Good, drop me email if you need more help.