Developers must follow security rules, too

We live in a least-privilege, role-based security world where no company should have full-time admins with full rights. Instead, you should distribute responsibilities where possible and rotate admins in and out of privileged groups. This is one of the most effective ways to stop malicious hackers from getting the keys to the kingdom.

But what about software developers? Because developers need to perform administrative tasks and have full control of their environment, it’s difficult to restrain and harden their workstations. They need to install software and drivers on a fairly regular basis, as well as debug programs. To a developer, denying full control over a workstation is akin to preventing them from doing their job.

I don’t buy that argument. In exchange for a little developer inconvenience, you can prevent attackers from hijacking elevated privileges that aren’t truly necessary for developers to do their jobs.

Isolation from the Internet

First of all, developers should not have elevated privileges in production environments.

There are few legitimate reasons why a developer should have those privileges; the ones I can think of should be given out sparingly and temporarily. In fact, I don’t think developers should have permanent, elevated permissions in a test environment. If they need elevated permissions, they should request them for a particular task and time period.

I’m fine with developers having full-time, local admin credentials on a computer that stands alone or is hooked to a test domain, but with significant caveats.

The most important is that developers should not program using the same computer with which they access the Internet and pick up email. It’s too high-risk. I know this flies in the face of the GitHub generation, where sharing code and dev tools on the Internet has become part of the culture. Fine — but don’t do that on the same machine where you’re writing code.

I even think adding popular programming websites to an “allowed list” on a programming workstation is asking for trouble. The last few years have been replete with watering-hole attacks that targeted developers who hang out at popular programming websites.

If Web browsing must be allowed, developer workstations should be reset to an original, trusted state after the end of each session. Again, I know this is a pain, but you’re giving developers highly privileged, permanent accounts, so there need to be security mitigation trade-offs.

Rights and responsibilities

If developers want permanent local admin rights, give them a virtual machine (running on their local desktop or a host server) dedicated to programming. It should be thoroughly hardened and perfectly patched, with judicious monitoring and alerting. The workstations should run up-to-date antimalware and host-intrusion detection programs. Reports should be automatically generated each morning to show what changed on the workstations from the previous day.

Optimally, I would use a whitelisting application control program to define what programs can run on developer computers. They’ll hate this and say it restricts them in doing their job. So what? That’s the price you pay for getting local admin rights. Unfortunately, developers are not so great at ensuring they don’t download Trojans that masquerade as shared code or cool programming tools.

All local accounts, including the developer’s local admin account, should be prevented from logging on over the network. Developers definitely shouldn’t have the ability to log on to high-risk computers like domain controllers or other servers on the production network. All accounts should have unique names and unique passwords. That way, if a bad guy gets a hold of the developer’s local admin credentials, lateral or vertical movement attacks will be that much more difficult.

It’s important to remember that no matter how you handle developer access, a developer’s logon credentials should absolutely be unique between the test and production environments. That means no shared passwords or digital certificates. Failing to do this defeats the purpose of having separate environments — and hackers love companies that violate these credentials.

If developers balk at these risk mitigations, see if you can come up with your own off-setting controls. If you have to loosen a few, be sure at the very least to implement a specialized, hardened programming workstation where developers cannot do their normal Internet browsing and email. This is the only control I would absolutely insist on as a deal breaker.

Most developers won’t like my advice. But we live in a world of high risk, where letting any group indulge in bad security behavior can only lead to more Sony-style hacks. Browsing simply should not be done on the same computer (or image) as the one being used to develop software. This advice is no different than what we have been recommending for any infrastructure administrator for years.