Overcoming Developer Security Risks

Developers pose a unique cybersecurity risk for enterprises. Their need to install and test software and have full internet access exposes organizations to a range of attack vectors. Although organizations use a variety of technologies to mitigate these risks, most of them are inadequate. Many IT leaders are now turning to isolation approaches to provide the heightened security developers need, without impeding their productivity.

Why Developers Are Risky

Developers are typically granted local administrator rights to be able to install dev-related applications, packages, extensions, drivers, etc. Malware that infiltrates their machines usually runs with local administrator rights and can modify settings, harvest additional user credentials and have full network access.

In addition, developers require full access to the internet to download code samples, third party source code packages and libraries, new tools, etc. As the development tool stack rapidly changes, these internet resources cannot be easily whitelisted and often do not work well with web proxies. This full internet access increases the chances of downloading malware, which would probably be able to access its C&C server. Developers can also mistakenly or intentionally upload sensitive data to any internet server.

The software that developers build and run on their machines can have bugs that can have catastrophic consequences on corporate resources that are accessible from the developer’s machine (e.g. deleting all files on a network share, or doing mass wrong modifications to a database).

Equally important, developers have access to the enterprise’s crown jewels, including proprietary source code, sensitive customer information that is provided for testing purposes, sensitive customer environments for support/troubleshooting software issues on the customer site, mission-critical production servers that contain private customer information and domain resources, e.g. root passwords to sensitive servers, data center resources, etc.

Traditional Security Mitigation Often Falls Short

To mitigate these risks, enterprises try a number of traditional approaches. They may limit or control local admin rights, although doing so triggers app compatibility issues. Some provide each developer with either a second device or a guest virtual machine (VM) on their existing device for experimentation purposes. While the former approach provides physical air gap security, it’s expensive for the company, inconvenient and frustrating for developers who must carry two machines, and negatively impacts productivity. The latter approach lacks seamless experience, introduces manageability complexities and exposes the network to risk if not handled properly.

Isolation Approaches Are Gaining Traction

Many companies are turning to isolation technologies to secure developer environments. Here, too, there are a number of options. You can provide internet access through a browser isolation solution. This secures browser activity, but not the device OS or applications, and often degrades browser performance. You can also use application sandboxing technologies for particular apps – just be aware that other applications on the device as well as the OS, browser, etc. are still exposed to risk.

Some organizations require developers to access privileged resources through virtual desktop infrastructure (VDI), privileged access management (PAM) or Jump boxes. The challenge with these approaches is that they can be expensive, introduce performance degradation and perhaps most importantly, they don’t fully solve the problem. Malware on the developer’s machine can still impersonate the user after s/he authenticates.

One promising approach is endpoint isolation, in which a single physical device is transformed into multiple, fully separate virtual endpoint environments/VMs. These endpoints are built on top of a bare-metal hypervisor platform that sits below the device OS. No environment has control over, or unlimited access to, the others.

In a typical developer use case, there may be two VMs on the end-user device:

  • Developer – an unlocked VM with wide internet access and local admin rights. In this VM, the developer will do most of the development and testing, install applications. Due to its nature, this machine is the most exposed
  • Corporate – a locked down VM with access to typical corporate applications (e.g. email, Office), customer data and customer environments

With endpoint isolation, developers get the freedom needed to be productive, while IT and CISOs get the security they require.

Developers benefit from a one-device solution that provides full internet access and a safe playground for experimentation with full local admin rights. This approach also ensures developers only access production/customer data from a trusted environment.

IT leaders and CISOs eliminate the need for local admin rights on corporate/sensitive environments and don’t have to open the entire corporate network to the internet. They also limit the scope of software bugs/experimentation and restrict access to sensitive systems/data, boosting insider threat protection.

It’s clear that existing security solutions aren’t adequate for protecting enterprises from the inherent cyber-risks associated with developers. Isolation approaches are promising – just make sure you evaluate them for comprehensiveness, impact on user productivity and best fit with your business.

What’s Hot on Infosecurity Magazine?