Security Think Tank: The security role of SDN, containers, encryption and SDP

In the days when all users were trusted, air gaps were real and unicorns roamed the earth, and perimeter security using impenetrable firewalls could be relied upon to protect our data and systems. But as use of, and reliance on, the internet has grown, firewalls have to be opened up to enable external services.

Also, we have introduced remote access from bring your own devices (BYOD) and connections to partners, and have now moved much of our processing and data storage into the cloud.

All this means that a perimeter defence can no longer be relied upon to protect data and the systems inside, or outside the perimeter.

There are measures that can be taken within the perimeter to minimise the risk through network design, such as zoning, internal monitoring, two-factor authentication and monitoring of virtual private networks (VPNs). However, remote access still usually provides greater access to the system and control for data access and running applications than is necessary, while relying on relatively coarse controls.

Other solutions, such as software defined networking (SDN) and containerisation, although not developed for security, can be used together with end-to-end encryption to provide more visibility and control within the network and more control of applications.

As the perimeter defence is weakened, it becomes more important to monitor inside the network. This can be difficult and costly, particularly in large flat networks. Zoning can also add cost and reduce flexibility in a fixed network infrastructure.

However, SDN separates the forwarding and control planes, essentially turning routers into basic switches forwarding traffic in accordance with rules defined by a central controller. Packet-by-packet statistics are also sent back to the centre from each forwarding element. This can allow IDS-like functionality to be applied in every forwarding element and gathering “data flow” information for analysis.

This can include east-west (server-to-server) and north-south (client-to-server) traffic and gives much more comprehensive monitoring than would normally be available in a fixed network. SDN could remove the need for routing solutions such as MPLS (multiprotocol label switching), which will make monitoring very difficult.

Also, because the routing control defines rules based on packet headers including the service type (port) as well as the address, it is possible to set up effective network zoning that can be changed dynamically in response to an incident or attack.

Containers were developed to reduce resource requirements by avoiding the large footprint of a full operating system (OS) in a traditional virtual machine (VM) while increasing portability of applications. They do this by running on top of an OS, providing only the specific libraries and functions needed for the specific app. Applications can also be decomposed into several containers which need not run on the same host, but are interconnected by encrypted links.

Although containers were not developed for security and their security features are not generally mature, they can provide isolation between applications and between applications and the OS. Containers can also be given permissions to control their execution and can be easier to update and roll back. This reduces the attack surface because the applications only have the services they need and no more. Also, more fine-grained permissions are possible.

Containerisation and SDN can be used together to limit data flows to only those needed, and to protect access to, and execution of, applications. However, I would not recommend deploying them for security alone, but to exploit them for the security enhancements that can be gained.

It must be remembered, however, that as neither technology was developed for security, deployment must be considered carefully to mitigate issues inherent in these technologies. These include potential denial of service (DoS) attacks on SDN forwarders and making sure packaged apps are properly signed and available only from a controlled registry.

However, the biggest common risk is probably misconfiguration. Container and SDN suppliers now tend to include security features and have default configurations that address security, but as they are not security products in their own right, but are primarily deployed to increase efficiency and availability, it can be very easy to reconfigure them to an insecure state.

Just starting to emerge are products implementing a so-called software-defined perimeter (SDP), which will, in the future, give a better level of control across cloud, hybrid cloud and enterprise networks. These provide a security overlay using a central controller and authentication service to authenticate hosts (user and server) and services and allow the creation of end-to-end encrypted tunnels between consenting hosts.

This controls which hosts can connect to each other and which hosts can offer and consume a particular service. Sometimes called VPN replacements because it can be used to control partner interfaces, SDP should be much more than that.