Security Experts:

Security Challenges of SDN and Cloud: The Critical Role of Visibility

What is SDN and Why Is Traffic Visibility Important to Security?

Software Defined Networking (SDN) stands to transform our modern networks and data centers, turning them into highly agile frameworks that can be quickly reconfigured for changing business needs. While SDN rollouts are far from common, practically all organizations are making plans to accommodate this eventual architectural shift that promises to extend the efficiencies of server virtualization and cloud computing to unprecedented heights through on-demand provisioning of every network service including bandwidth allocation.

Security for Software Defined Networking

Still, many organizations recognize that highly mobile workloads and auto-configured applications and services mean loss of visibility to traffic and consequently loss of both performance optimization capabilities and weakened security. While proceeding with caution is necessary, like cloud computing, migration to SDN is inevitable because of its overwhelming benefits for efficiency and scale. To make migration as smooth as possible, and ensure that security is not minimized, it is important to take some basic steps of which a facility for total and continuous visibility to network traffic is central.

What is SDN?

SDN architecture separates or decouples the control (i.e administrative plane) from the data (i.e forwarding plane). The resulting architecture is a highly programmable and scalable one, where the control framework can view and provision the network as a single logical abstraction. In this kind of architecture, the orchestration and provisioning of services is easier to manage with desired configurations applied consistently and automatically. This unlocks whole new levels of scale and agility as well as choice in underlying hardware infrastructure. Beyond significant savings in CapEX and OpEx, the SDN architecture spurs innovation and accommodates change quickly and to the benefit of those it serves with little disruption and overhead.

SDN architecture

Figure 1: SDN architecture by the Open Networking Foundation and made available by SDXCentral

How Cloud Security and SDN Security Differ

Cloud and SDN security concerns can be conflated because server and storage virtualization, a key underpinning to cloud computing frameworks, shares some concepts with Software Defined Networks. The fact is that there are unique security challenges to clouds that differ from SDNs so a quick discussion of the concerns is worth summarizing here.

Cloud Security Concerns

First, it is important to note that clouds often have virtualized compute and storage at their core. Virtualized workloads or virtual machines replace physical servers in this design and can be provisioned on a mouse click. VMWare’s ESX, Citrix XEN and Microsoft’s Hyper-V are examples of hypervisors which underpin server virtualization. Cloud computing frameworks span three different configurations: private, public and hybrid.

Private clouds employ server and storage virtualization entirely within the confines and controls of the organization. That means the organization or company owns the cloud framework and is responsible for its security. The security concerns here are that a VM may become infected with malware and as the VM moves or motions throughout the data center(s) it infects other VMs which share its host. Traditional security devices will not “see” the infection as it spreads from VM to VM because that traffic stays largely within the confines of the virtualized network segments. Security options in this scenario include giving security devices on the terrestrial network visibility to virtualized traffic as well as implementing virtualization specific or purpose built access controls.

Public clouds are owned by firms offering leased access to this shared framework (ex. AWS, Microsoft Azure). The security concerns here are about tenant isolation. Since the provider hosts the workloads and assets of many organizations, any inadvertent connectivity from one cloud tenant to the others constitutes risk. Security controls here are really about two things: control access to the workloads hosted by the provider, and asking for service level agreements that require the provider to furnish options for traffic visibility and security controls to the hosted resources.

Hybrid clouds are perhaps the most common frameworks. Most organizations and businesses have some workloads hosted on-premises and implemented as virtual machines, and they also host some workloads in a public cloud or access resources and applications there, making the framework a public/private “hybrid”. Security regimes here are about adhering to the advice above but also closely monitoring market options here as they are evolving rather quickly. Right now the visibility and security control frameworks of hybrid clouds require piecing together a few technologies. There is bound to be some unification and single pane of glass management as vendor relationships evolve to serve this large market need. There are also some overlay technology options which are an interesting emerging area. Hybrid cloud stakeholders need to stay vigilant of market news here particularly as they migrate to SDN.

SDN Security Concerns

As explained above, SDNs go well beyond server virtualization to virtualizing every aspect of network infrastructure and management. Security concerns here are about a greatly expanded attack footprint that includes the control plane as well as the data plane.

For example, if attackers are able to take over the control plane or SDN controller they would essentially own the entire network and all its contents, possibly indefinitely. Infections in the data plane layer can in theory spread much more quickly because an SDN will be more pervasive in terms of deployment than server virtualization. It is also possible that communication difficulties and disruption between the control plane and data plane can create vulnerable spots in terms of new ways for attackers to breach the network perimeter.

When it comes to SDN security, a detailed how-to architecture is very early days in part because there are many different ways to implement an SDN with options from established vendors and open-source organizations. The key here is to ensure visibility to all of your networks, including traditional, virtualized and software defined. Understanding traffic flows between these network types will ensure that blind spots are corrected and bottlenecks resolved in the most expeditious manner. This kind of visibility has to span all network and workload types to ensure pervasive and continuous views. This is what a visibility fabric provides and why it is not a point solution but an architectural layer on par with virtualization.

The Role of Visibility In SDN

Network visibility is a foundational element in terrestrial networks and becomes more critical in highly dynamic SDN architectures. Loss of network visibility does not need to hinder firms from moving forward with SDN however. Companies that offer visibility fabrics have taken steps to engage with both the standards community and the leading vendors of SDN architecture to ensure that application performance and security are maintained both during an SDN migration and after its completion.

Accelerating SDN adoption with a Visibility Fabric

A visibility fabric essentially enables network (inclusive of SDN) visibility, as a pervasive layer that unites views of traffic flows in physical and virtualized network segments. Specifically, network visibility gives detailed knowledge of the traffic flows and packets in these networks which is vital for:

1. Monitoring the state of the SDN network itself

2. Monitoring the applications it enables

3. Ensuring security is maintained

Visibility Fabric for Network Security

Figure : Diagram courtesy of Gigamon showing as visibility fabric implemented as a security delivery platform for a private cloud and/or SDN environment. 

Whether the SDN architecture of choice is built on OpenFlow or network virtualization abstractions like VMWare’s NSX and Cisco’s ACI, or some other framework, the key requirements above remain. In SDN, control and forwarding layers are managed independently yet need to function together. Synchronization issues between these layers due to network latency or vendor variance in networking infrastructure can cause bottlenecks and disrupt operations.

When it comes to SDN applications and services, the benefits of on-demand provisioning are undeniable. But this sort of dynamic configuration can result in unpredictable traffic patterns that become hard to troubleshoot via traditional means, which place performance management tools at predictable places in the network. Visibility to such traffic in the SDN realm needs to be constant and the tools centralized so that they can receive all traffic flows and packets. Similar logic applies to the need for security. Whereas security devices could be placed on critical network segments in traditional networks, this is untenable in SDNs. Centralized placement and total access to all inter-SDN traffic gives security and performance management technologies the best statistical chance of surfacing embedded malware and anomalous patterns.

Related: Network Security Considerations for SDN

Related: Practical Deployments of Security for SDN

view counter
Johnnie Konstantas heads Gigamon’s security solutions marketing and business development. With 20+ years in telecommunications, as well as data and cybersecurity, she has done a little bit of everything spanning engineering, product management and marketing for large firms and fledglings. Most recently, she was the VP of Marketing at Dato, a company pioneering large-scale machine learning. She was also VP Marketing at Altor Networks (acquired by Juniper), an early leader in virtualization security and at Varonis Systems. Past roles have included product management and marketing for Check Point, Neoteris, NetScreen and RedSeal Systems. Johnnie started her career at Motorola, designing and implementing large-scale cellular infrastructure. She holds a B.S. in Electrical Engineering from the University of Maryland.