Security Teams: You Don’t Need to Frustrate Your Developers

by Tal Zamir on September 22, 2021

It’s clear to security and technology managers that unsecured developer endpoints can lead to major problems.

A few years ago, there was a famous LinkedIn breach that all started with a hacker gaining access to a LinkedIn engineer’s endpoint. Unfortunately for LinkedIn, the engineer had a web server listening on an incoming port as well as a client certificate to access the LinkedIn network. Through that engineer’s endpoint, the attacker was able to dump millions of personal LinkedIn records, including passwords.

A more recent example of developer endpoint chaos is the SolarWinds breach. In that case the attackers were able to observe the SolarWinds development process and put a backdoor into the product. Once it was updated, over 18,000 users downloaded compromised versions.

Why are developer endpoints so risky?

Sponsorships Available

It all comes back to ‘mixed usage’. Most endpoints are used for both risky activities like web browsing and downloading applications and repositories, as well as accessing sensitive corporate resources and data. As long as all of these activities are taking place on the same OS, there will always be the chance of compromised endpoints putting enterprise resources at risk.

So how are security teams securing their development teams (especially when so many of them are working remotely?)

There are 3 approaches that I’ve observed:

1. The Frustrated Developer Model

In this model, security has the endpoint totally locked down. Access to risky or uncategorized websites is blocked. Apps need to be whitelisted before installing. Only pre-approved browser extensions are allowed. USB devices are blocked. There’s an EPP/EDR that scans every file on the device, slowing build times. And, of course there’s an ‘always on VPN’ to block access to local home network resources.

As you can imagine, this is every developer’s nightmare setup. They are simply not going to be productive under these constraints. Developers do not want to be speaking with IT every 3 minutes accessing them to whitelist apps and sites. In short, this is the fastest way to annoy your developers.

2. The ‘Unleashed’ Developer

The unleashed developer is almost the opposite of the frustrated developer. They have access to everything – full web access and total admin control over their device. Maybe they’re required to connect via a VPN and install an EDR, but that’s pretty much it.

This approach obviously introduces an unacceptable level of risk for security teams. No one wants anyone accessing corporate resources with such lax controls.

3. The Remote Developer

When it comes to remote developers – especially contractors, a common approach is to let them use an unmanaged endpoint, and connect to the enterprise via a Virtual Desktop (VDI) or Desktop as-a-Service (DaaS). However, if the connection is bad – the resulting high latency can be very frustrating (anyone who has experienced keyboard lag can attest to this).
Also, the Virtual Desktop needs to be very high end to provide developers anything approaching the experience they want.

So is it a lose – lose situation?
Is there no way to make IT happy without driving developers crazy?

Well, the answer to that all comes back to the issue raised at the very beginning of this post – using the same OS for risky and sensitive activities. If those activities took place on an entirely different operating system, much of the risk would be mitigated. This is the reason Microsoft issues separate privileged workstations to its Azure development team.

But giving developers a second laptop has its obvious drawbacks (who wants to carry 2 laptops?). A better approach would be to create a separate OS on the user’s device – allowing them to engage in risky activities in one OS, and their corporate activities in another.

Hysolate: Isolating Threats, Encouraging Productivity

With Hysolate, IT and Security can deploy an isolated OS on their developers’ endpoint devices, and manage them from the cloud. With Hysolate:

Developers can download any application or extension they need for research or testing, including risky applications that would normally be banned by security and IT management.
R&D teams can be given full access to websites like YouTube for technical training and education, in their isolated Workspace.
Developers can have full access to open source code repositories within Workspace, and can play with code using Hysolate as a managed sandbox, without concern of infiltrations into proprietary source code on the host OS.Hysolate can be easily wiped after use, creating a clean sandbox environment.