Rethinking security for a software-defined world

As Information Age prepares to host the UK’s first software-defined anything (SDx) event, Glen Kemp, enterprise solutions architect at SecureData, tackles the subject of security.

2014 is the year when software defined networking (SDN) will emerge from the test lab and the mega-scale data centre and appear in enterprise networks. Major vendors such Juniper Networks, Cisco Systems, and the virtualisation titan VMware have shipped products to help you build a software defined data centre (SDDC).

This process of adoption won’t happen overnight, and it’ll be months if not years before SDN technologies are widespread; not least of all because there are many answered questions for enterprise users: Where does security fit into the software defined data centre? Should traffic inspection be performed in the overlay or the underlay? And how do I consolidate network security events across multiple network layers and across applications?

The secure SDN dilemma

The traditional approach of installing a monolithic security appliance at the centre of the network just isn’t going to cut it for much longer. Within a SDN the inter-host traffic is encapsulated in GRE, VXLAN or STT tunnels and transported across an underlay network.

This obfuscates network flows and makes traditional Layer 4 stateful firewall policies meaningless. Performing traffic inspection within the virtualised environment (overlay network) also has caveats. For example, inspecting “east-west” traffic by forcing traffic out of the virtual host to a physical firewall is inefficient and a recipe for latency. Attempting layer 3 inspection within the host is not much better; the lack of dedicated hardware blunts throughput and guest-to-guest traffic may cross multiple hosts if resource management is improperly tuned.

What needs to change?

A key benefit of software defined networks is that infrastructure can be stood up much quicker than a traditional hardware-led approach. Perhaps unsurprisingly, the traditional method of traffic inspection with layer 3 gateways is insufficient in the SDDC.

Any barriers between services must be swept away for an SDN deployment to be successful. The need for effective security controls doesn’t change with the introduction of SDN, but the approach must; enterprises will be forced to standardise application services, which has proved difficult in the past.

>See also: SDN: Ask why, not what

Efficiency at layer 2

The most efficient way to perform traffic inspection in a virtualised environment is with direct hypervisor integration. By intercepting traffic flows at the virtual layer 2, security policies for stateful inspection, intrusion detection and anti-virus can be applied at the interface ingress or egress.

The only shipping technologies that have the required kernel access are Juniper Networks’ Firefly Host, Trend Micro’s Deep Security and the native VMware NSX/Edge Firewall. With direct access to the kernel API, inspection at layer 2 allows wire-rate performance and scales much better than a traditional routed layer 3 gateway.

The policies can be intuited by guest introspection (determining a machines classification by examining various aspects) or attached during the service deployment. In either case, the process is highly automated; network security ceases to be a barrier to rollout, and becomes something that is deeply and automatically integrated into the network. To coin a phrase: “Would you like security fries with your application hamburger?”

Changing demands on management

This level of network security automation and integration forces another step-change in behaviour. The next management challenge will be the definition of application templates, rather than the creation and curation of isolated, per-vendor network security policies.

The goal is to centrally define resources such as VLANs, policies, server objects etc, and have all components that touch the network flow reference them. For example, the definition of a web application will be referenced by firewalls, load balancers, IDS, and DDoS mitigation tools. It will include the TCP ports used, intrusion detection policies, and application specific features.

In terms of best practice, essentially this level of standardisation is not new, but the level of automation around it is. If one has a well-maintained central firewall management solution, the process of migrating service to SDN will be more straightforward as there is likely to be significant standardisation in place.

>See also: Cisco stock downgraded over SDN threat

Changing workloads

The workload in network security management is going to shift from the maintenance of isolated security policies into something much more dynamic. The inherent centralisation and standardisation of SDN means that network security has a broader and deeper reach than ever before. This reach will be a double-edged sword; apparently simple changes could have a ripple effect much wider than previously considered.

So where does security fit?

To answer the original question, security is everywhere within the software-defined data centre. It is no longer a single appliance that does everything, but a series of tools linked by a common policy. Security policy is implemented at the core of the network, within the virtualised network and at the edge.

The challenges involved infusing network security into any SDN deployment are not unique to a vendor or technology. The truth id there is much new ground to be broken in both security and software defined networking in 2014, and no single vendor or technology has defined the outer limits of what is possible.

Avatar photo

Ben Rossi

Ben was Vitesse Media's editorial director, leading content creation and editorial strategy across all Vitesse products, including its market-leading B2B and consumer magazines, websites, research and...

Related Topics