Software defined networking security enables granular policy control

Software defined networking introduces network programmability and granular traffic management, which could contribute to enhanced SDN security.

Editor's note: This article is the second in a two-part series that compares the benefits and challenges of software-defined networking security. In this piece we examine how the granular traffic engineering and programmability that SDN enables can enhance network security. In the sister article, we explore the dark side of software-defined networking security.

Software-defined networking promises network programmability and dynamic network virtualization. To some, the ability to spin up zillions of distinct virtual network segments on demand sends up security red flags. Yet many experts believe that SDN technology is just as likely to enhance network security as it is to pose new challenges.

At a 10,000-foot level, SDN decouples the control plane from the data plane so that signaling is separately routed, explains Akshay K. Sharma, a research director at Gartner. This makes possible network programmability and load or resource sharing on the physical network. Ultimately, SDN will mean that the network will be aware of and reactive to virtual machines the same way that hypervisors are, said Sharma. That will allow for granular traffic management and security.

Within this context, enterprise network managers or service providers could programmatically insert a wide range of customized security services into the network on a per-flow, per-application or per-user basis. They can also implement security dynamically, allowing for Security as a Service.

"Applications will be made better by information from the network, and networks will be made better with information from applications regarding bandwidth and resource optimization, new service topologies, security identification and service-specific packet treatments," Sharma said.

New policy strategies needed for software-defined networking security

That flexibility, Sharma warned, comes with challenges. Network managers and admins must learn how to set security levels appropriately in a new and dynamic environment.

SDN could better leverage network telemetry data or flow-capture data that can be used to spot anomalies; then specific flow rules could be dynamically established that divert flows to a centralized or multiple enforcement points.

Ideally, there will be pre-provisioned security policy logic inside a policy management system. This approach would define the rules of what is to be denied or allowed with certain subscribers, applications, devices, locations, network access methods and network characteristics on each network segment. For example, Sharma said, "some applications or documents may be restricted in public locations." On the other hand, they might be allowed initially on a tablet within the enterprise, but restricted as the user walks out the door or into a public setting. Conversely, some applications, such as video streaming, may be allowed within the public setting on a device, but restricted within the enterprise. "These [policies] will be enforced dynamically within the new software-defined networks of the future," Sharma said.

Using SDN traffic engineering to direct flows to security devices

SDN can also be used for traffic engineering to direct network flows to specific security services or devices, such as firewalls, intrusion detection systems/intrusion prevention systems (IDS/IPS), and Web application firewalls (WAFs), said Jon Oltsik, senior principal analyst at Enterprise Strategy Group.

"This may be an important advance for network security since it would use software in place of physical routers, switches and appliances," he explained. The approach could also help minimize the performance impact of "bump in the wire" [external] security devices.

The goal of SDN would be to align the right security service with the right flows.

"This is difficult to do today and gets more difficult when virtual machines move from server to server. Security operations teams could use software to modify traffic patterns or integrate SDN with something like OpenStack or vCenter to automate security," Oltsik explained.

Software-defined networking security sets new boundaries for perimeter control

SDN could also potentially alleviate the current question of where to place enforcement points in the network, said Mat Mathews, co-founder and vice president of product management at SDN firm Plexxi. "With the increased accessibility of corporate assets -- mobile, wireless hot spots -- and increased demand for easier access to applications and services, the corporate network no longer has a single point of entry or exit," he explained. This has sometimes been called deperimiterization.

More on software-defined networking security

SDN goes beyond the data center … and into network security

OpenFlow's role on the campus LAN (think security)

Paraphrasing Chris Hoff of the Rational Survivability blog, Mathews said, "The perimeter isn't disappearing, it's multiplying and its diameter is shrinking -- if you think of every enterprise laptop with Wi-Fi as a perimeter." However, putting enforcement points at every perimeter is cost prohibitive and almost impossible to manage. The hope "is that SDN could be used to better leverage network telemetry data or flow-capture data that can be used to spot anomalies, and then specific flow rules could be dynamically established that divert flows to a centralized or multiple enforcement points."

Plexxi has been working on the concept of "affinities" in the data center, or the ability to leverage relationships between resources that comprise applications, in order to better manage and control the underlying network. "In the context of security, affinities (or maybe more aptly anti-affinities) define relationships between different resources or classes of resources that require more security inspection," he said. SDN can potentially be tuned to match business risk based on the classes of information assets, he added.

This was last published in March 2013

Dig Deeper on Network Security