Security Think Tank: How to use SDN, containers and encryption – and some warnings

Now that the Christmas and New Year festivities are finished, it is time take a serious look at the networks that underpin your company’s activities and how to prevent rogue code (malware, ransomware, viruses) from running amok. Can software-defined networks and containerisation of services provide a valuable helping hand?

If you are running virtualised servers in your network, you have probably found that it is easier to create a new virtual server running a dedicated application than running multiple applications on one server.

For many companies, this virtualisation of servers is a goal in itself, bringing with it a number of advantages, including the potential for power and space saving and the ability to interconnect virtual servers within the VM (virtual machine) hypervisor environment.

Also, there are a number of VM hypervisor products that can operate across a cluster of hardware hosts, rather than a single host. Couple this hypervisor interconnection of servers with VLAN (virtual local area network) technology to allow connections to services on different platforms and to the user base, and you have a software defined network.

Admittedly, you still need the physical LAN cabling to interconnect the various host systems, services and users to the network hardware, but the actual networks and their termination points are all defined in software, be it in the VM hypervisor configuration or the configuration of a network device (switch, load balancer, firewall, VoIP telephone, and so on). 

Where does containerisation come into play? Containerisation, as currently described, is Linux-based and so only runs applications designed for the Linux environment. So, for companies that are heavily vested in Microsoft, the Microsoft environment can only be virtualised via traditional hypervisor technology.

In a traditional VM environment, the hypervisor, in effect, replicates the host hardware to a number of defined “virtual” hosts, each of which supports its own operating system (OS), such as Microsoft Windows and Linux. In containerisation, the host hardware runs a single Linux OS that supports LXD (Linux container hypervisor) extensions and a containerisation engine is then run on top of this Linux OS. 

This engine, in turn, replicates the Linux OS into multiple containers. Each container can then run a Linux application. As with the more traditional hypervisor approach to VMs, it should be possible to interconnect the various containers via configuration of the containerisation engine and the underlying LXD-compliant Linux OS. 

The advantage of running dedicated service VMs and containerised applications is that should one application become compromised by rogue software, the underlying VM or Linux kernel and associated containerisation engine (LXD) should protect the other VMs or containers.

When combined with the use of VLAN technology, as described above, multiple networks can be created, effectively segregating data flows and so reducing or eliminating the potential of malicious software to gain a hold over the whole network. An example would be a multi-tiered network design with a data storage tier, an application-to-application tier, a front-end user access tier and a DMZ (demilitarised zone) tier.

The addition of encryption to the mix of VMs/containerisation and software-defined networks can improve the security of a data flow by preventing effective eavesdropping on a data flow.  Encrypting data stores can prevent the leakage of usable data by malicious software, but caution is advised because encryption is not a silver bullet as far as security goes.

Ransomware that encrypts files will still encrypt a file, irrespective of whether it is in plain text or not, and at this stage of IT technology, data will have to be decrypted in order to be processed by an application. 

A final caution. Employing VM and/or containerisation technologies in combination with the use of VLANs with or without encryption can only improve the security of an organisation’s IT, providing that:

• Any software and hardware (including network devices) used is within the manufacturer’s support and maintained to the current manufacturer’s software/firmware release level.
• All security patches are applied in a timely fashion.
• All systems, services, OSs and network devices are properly configured (not default out of the box).
• The whole IT environment is subject to a full IT security health check at least annually and whenever a major change is implemented.