Mobile Device Management (MDM) & VM based development

DISCLAIMER: I am in no way an authority on this topic, this is simply a write up of my idea for a solution given the requirements I have heard and read up about for what an MDM solution should provide (specifically for the desktop.)


Inside an organisation which requires an MDM solution I still want to have complete (root) control of my development environment(s). Here is an example solution which I feel would be suitable and also agreeable for me:

The corporation would:

  • Install and configure any and all monitoring and management software on the host.
  • Install a virtualisation tool e.g. Virtualbox, VMWare etc... on the host.
  • Install vagrant on the host.
  • Make a forwarding proxy available for outbound requests (including TLS proxying).
  • Issue the development machine with one or more trusted internal certificates for the forwarding outbound proxy.
  • Manage, Monitor and Report on whatever they want!!

The developer would:

  • Do all development inside one or more virtual machines.
  • Install the relevant internal certificates in their virtual machine(s).
  • Configure their virtual machine with the outbound proxy details.
  • Install what ever they want!!

Recently I was in a conversation where certain parties wanted to lock down the software which the developers could use. The scope was everything including IDEs to specific libraries (and versions of) to what language they were using to develop in. This all started from a conversation regarding how the Mobile Device Management strategy would be implemented for the developers.

What is Mobile Device Management (MDM)

in my own words...

The basic idea of MDM is to control, monitor and report on the installations, activity and external network IO on corporate devices or BYOD inside corporate networks to increase security by limiting the actions which can be taken.

Some examples of the things being controlled and monitored for include:

  • visiting a website which is not whitelisted.
  • accessing a local device or drive with invalid permissions.
  • opening extra ports on the machine.
  • transferring types of files based on their type, content or destination.
  • unusual local activity based on historic trends or timing.
  • VPN configurations.
  • proxy configurations.
  • Anti Virus checks and updates.
  • Intrusion detection updates.

What does the developer want?

To use whatever tool, OS, IDE, language, library, framework etc... they deem most suitable (or most comfortable!) to achieve the task[s] they have to deliver.

I think you would get a similar reaction in both the following cases:

Case 1: Ask a developer who favours Eclipse to stop and use VIM only.

Case 2: Ask a developer who favours VIM to stop and use IntelliJ.

Now consider the following:

Case 3: Inform the developer of the style, quality and coverage constraints which you expect from their code, enforce in the build pipelines and let them go on and use whatever IDE they want e.g. VIM, emacs, spacemacs, sublime, atom, intellij, kimodo, eclipse, notepad (ok too far);

How can the corporation be assured the installations are safe?

Some may say the answer to this question is to lock down what programs the developer can install i.e. what IDE they can install.

This would severely limit the capacity of certain individuals who may be most productive with a certain set of tools which are not very well known or relatively new or relatively specialised; or what ever reason. They may also be of the mindset that there may be a better tool out there to solve the problem more efficiently and go to look for it. The point is that there are so many tools out there it is impractical to try and create a restricted product set that will appeal to the masses.

there is another way to allow the corporation to stay safe and the developer happy...

How can the corporation be assured of the libraries which the developers are using?

Some may say the answer to this question is to use a central package/library repository where only the corporation approved libraries and packages can be found and installed.

Whether this is acceptable or not really depends on the size of the organisation. In a large corporation it is extremely prohibitive to the development process if every time the developer wants to use a different or upgraded version of a specific library or package they have to go through a change control and possible review process before it may be permitted.

Scenario *You request a specific ORM library be made available, follow the process, wait three days and get an approval through from the team who manage these requests. You then get back to development and realise you also need a specific library for the ORM dialect which you didn't realise at the time and most importantly didn't request. Let's say you wait another three days. That is six days just to start consuming a new database technology which you think is better suited to the problem you have AND which you have just realised you have not submitted a request for to install locally. ARRGGHHH

there is another way to allow the corporation to stay safe and the developer happy...

We are developers and we break things!!

Security want to ensure that a stable environment is maintained to maximise the control they have over it. Yet the development process by its very nature is one of exploration, destruction, creation, mutation, disaster, communication, encryption etc...

To combine these two things inside a single context is not an easy thing to achieve, manage or get buy-in from the developers who are hopefully driven by the value they deliver.

The more value we deliver the more productive we feel and the more productive we feel the more value we will deliver!!

Here is an example solution I feel would be more than suitable.

The corporation would:

a) Install and configure any and all monitoring and management software on the host.

Attack Surface Analysis is about mapping out what parts of a system need to be reviewed and tested for security vulnerabilities. The point of Attack Surface Analysis is to understand the risk areas in an application, to make developers and security specialists aware of what parts of the application are open to attack, to find ways of minimizing this, and to notice when and how the Attack Surface changes and what this means from a risk perspective.

Ensuring the host is kept stable by restricting what software is installed means that the risk can be managed a lot more effectively than if the host was used as the development environment as opposed to using a virtual machine on the host.

b) Install a virtualisation tool e.g. Virtualbox, VMWare etc... on the host.

This will allow the developers to do what they need to without getting hung up on restrictions that are present on the host which is being managed. This benefits both the corporation and the developer. The corporation keeps a stable host and the developer can focus on the task at hand.

Scenario A specific package may need super user privileges in order to be installed. It would be counter intuitive to give the developer super user privileges to the managed host device and subsequently it would be counter intuitive for the developer not to have super user privileges to a virtual machine which they create themselves.

A short note I would like to make here is that although I really, really, really don't like windows and would never, ever choose to develop on it or use it as my own OS, I would not have any cause for complaint if the corporation I was inside gave me a Windows Managed Device which contained Vagrant and Virtual Box. I would and have had to do in the past simply go ahead and create my development environment on a linux based virtual machine. Simple as that, done!1

c) Install vagrant on the host.

On top of all the benefits gained from developing inside a virtual machine, it is also extremely important to have a repeatable environment so that they can be destroyed and re-created on demand.

Vagrant is one example of a super useful tool to script, share and store your virtual machines.

d) Make a forwarding proxy available for outbound requests (including TLS proxying).

There will be a requirement to inspect the inbound and outbound traffic to the development machine. In order to do this with TLS connections, the traffic will first need to be decrypted in order to be inspected.

An outbound forwarding proxy will be required which decrypts the outbound connection and then re-encrypts it with the public certificate of the destination (if the destination is permitted by the whitelist). The same process applies with the inbound connections.

For this to work correctly the development machine and any virtual machines on it will have to trust the public certificate of the outbound proxy.

The developer would:

a) Do all development inside one or more virtual machines.

I personally feel that even inside an organisation which does not use a mobile device management process, developing inside virtual machines rather than on the host is the most efficient way to develop considering all the factors and the points which I have put in this post.

Saying that, in an organisation with MDM and following this solution there is no choice and the developer will have to do all the development inside a virtual machine.

b) Install the relevant internal certificates in their virtual machine(s).

The developer would not have access to do this on the host and should not need to either. They would have to install the corporate certificates on their virtual machines so that they do not get security warnings due to untrusted certificates.

c) Configure their virtual machine with the outbound proxy details.

An obvious but important point, your virtual machines will have to be configured to use the outbound proxy. Here is some sample code showing how to do this with vagrant:

    config.proxy.http     = "http://<outbound-proxy-host>:<port>/"
    config.proxy.https    = "https://<outbound-proxy-host>:<port>/"

Further thoughts about developing inside a VM

The following are some more thoughts I have on this which further assert the fact that there are more benefits to developing in a VM than directly on the host.

An organisational standard development VM

I remember a project I was on for a brief period where, in order to get up and running to develop on the project, I had to follow a hefty set of instructions on the wiki, distributed over multiple pages and in total taking roughly three days to complete with the help from several of the existing team members. The help I needed was general but also after I had followed the instructions to the letter, checked and double checked I had done as stated, the instructions turned out to be stale. So we then had to solve the issue and obviously update the wiki to help the next person.

The point here is that the creation of a standard base virtual machine setup for the project would have saved a lot of time both in provisioning a new environment and also removing the need to document the process inside a wiki. The wiki would simply be a short, short guide to installing vagrant, virtualbox and some configuration to suit. It would also be repeatable!

Use of docker

I have seen a few colleagues now use Docker instead of virtual machines to create their development environments. This definitely has other benefits including a truly composable environment using things like docker-compose.

Lets say we want to develop in Python, host with Flask, use RabbitMQ and Postgres. We could simply create a docker-compose.yml file which had our development environment inside, another container for Flask, one for RabbitMQ and one for PostgresDB.

Versioning your development environment

Given that we are dealing with simple yaml files or the like we can easily store inside of source control, alter and version. This increases our efficiencies in many, many areas!


We need to ensure we comply with Security and Security need to ensure their solution is useable. I believe the above high level solution would be acceptable if some of the finer details were sorted out. The main point for me is that the experience would be no different as I already develop inside virtual machines. This approach is also supportive of separation of concerns.

  1. You could argue about the performance characteristics of using Windows, Mac or Linux as the host OS. Depending on your corporation you may be offered more options for your development machine e.g. they could offer a managed Linux or Mac or Windows machine.