Reducing the risk of data theft

Any organisation that uses computers bears the risk of remote data theft - rather than try to maintain the security of the entire company to the level of the most secure project, a more manageable and practical approach is to create a segregated development and test environment specifically for the build - security on this subnet can be considerably higher than that of the normal day to day staff's network.

Constructing a dedicated network of development, QA, staging and live servers would have been prohibitively expensive, but modern virtualisation techniques makes this now a practical and cost-effective reality.

Here, virtual machines can exist in entirely separate networks within one dedicated machine, completely oblivious and invisible to any other machines on that or any other machine.

Network Architecture for Secure Development

We suggest the following elements and workflow be used to securely develop a website.

External Physical Machines

Laptops, Desktops and Servers used by the organisation to carry out its day to day business, all adhering to the general company security policy. In this particular workflow, the graphical designers would be using external machines.

Hardware Firewalling

A dedicated piece of hardware that is able to protect unused ports on the development environment, and allow secure access to used ones.

Transfer Server

This sits behind the hardware firewall and maintains the VPN connections. Internal and external users connect to this machine to upload data and download the finished product securely, but they are unable to connect from it into the development environment.

Development Host

The physical server that hosts the development Virtual Machines (VMs).

Development Server[s]

The Development VMs are able to access the Transfer Server to read and write data, but are unable to access the outside world. Developers are able to access the development VMs only if they are physically connected to the same network (i.e. they have to be in the building, and have the right IP address).

Typically, the website generation system that creates the finished site will be run on this sever.

Typical users are Front-End Developers (HTML/CSS/JavaScript/JQuery etc) and Build Managers.

QA Host

The physical server that hosts the QA Virtual Machines (VMs).

QA Server[s]

These servers have no ability to connect to the Development Servers, only to the Transfer Server. When the completed website it is ready to be tested, it is zipped and copied back to the Transfer Server whereupon the QA Server[s] can collect it and unzip it ready for testing.

This complete dislocation of the Development and QA servers ensure that the completed website being tested is not in any way reliant upon resources that remain in the Development Server's environment - i.e. that the deployment was successful.

Typically, the QA Server will closely resemble the target operating system (for example Windows 2008 running IIS) plus it will provide the following testing facilities:

• Cross-browser testing (IE, Firefox, Chrome, Safaris etc)

• Compliance testing tools (e.g. AA)

• Load testing tools

• Proof reading/markup tools

• Website security tools

• Bug tracking tool (e.g. Trac) to allow the testers to report errors to the developers, and account managers to track those errors

Typical users would be QA, Account Managers and in-house Proof Readers

Staging Server Host

The physical server that hosts the Staging Virtual Machines (VMs).

Staging Server[s]

These VMs are protected by a hardware firewall but are on a separate network, and are switched off until the website is ready to be shown to the client. Once the site has been approved by the relevant member of the QA team, the zip file is physically transferred to the Staging Server and the Client is able to login to view the site via a VPN.

Typical users of the staging server are the Account Manager, the Client and any external proof readers (for example at the Client's location).

The approved site is then made available to the Client as a zip file located on the Staging Server for eventual deployment on their own systems, and the servers are then rolled back to their pre-build condition.

Reasons for this Approach

Adopting this approach to development and testing has the following security advantages:

1. Data arrives, and the completed site leaves, only by VPN, an extremely secure form of data transfer.

2. If the Transfer Server is turned off, no-one in the outside world has access to the Development Environment, so the data is secure for the duration of the build.

3. The Development Environment is not exposed to viruses and Trojans etc. that might be on employee's physical machines.

Workflow is simplified as follows:

1. The Development, QA testing and demo processes do not conflict, and can therefore continue independently, with the Account Manager confident that the Client will see a stable demo.

2. Feedback between QA and the Developers is simplified and automated, and clearly visible to the Account Manager.

3. Deployment is inherently tested; first between the Development and QA server and again between the QA and Staging Server, so you can be sure that the zip file will contain everything needed for deployment.

Additionally, the use of VMs provides the following advantages:

1. It is simple to start from a clean 'standard' build for each new job, simply by rolling back to a previous snapshot

2. For complex builds that require a great deal of server setup, there is the option to deliver the entire server as a live machine - all that needs to be set are the IP addresses for the site to go live. The server can easily be hosted in the client's Private Cloud or in a commercial Cloud in this manner.

3. Disaster Recovery and backup are vastly simplified, as the VMs are simply switched off and copied to an external hard drive that is placed in a fire safe either locally or offsite, depending on policy.

Phil Hanchet, OTG