When Interop gears up tomorrow in New York, you can bet your trade-show tchotchkes that software defined networking (SDN) will dominate airtime as one of the prevalent themes. Many vendors and pundits will push the performance and operational boosts from SDN as the most obvious benefits of SDN strategies. But as organizations roll up their sleeves and dig into the technology and architecture of SDN, they could find that the biggest opportunity for improving IT through it may actually be in security.

SDN could act as a natural technological extension of the accelerating trend toward segmentation, says Reuven Harrison, CTO of Tufin Technologies.

"Security used to be perimeter-based, and now it is becoming based on multiple zone layers within an enterprise network -- the trend is to have more and more smaller zones for improved control," he says, saying that this has increased security complexity as it has brought with it increasingly more network security devices to control those zones. "Using software-defined networks, rather than going into a specific device and writing command lines when you want to change anything on the network, you can write software that pulls APIs on devices to allow traffic, deny traffic, look at traffic, and report traffic. You can orchestrate security across your network."

According to Tom Nolle, president of CIMI Corp., a strategic IT consultancy, one of the greatest advantages of SDN is that connectivity within that model can be explicit as compared to the traditional implicit model.

"You establish an IP network, and it is designed to route traffic between addressed endpoints promiscuously, which means that if you know somebody else's address, then you can send them something," Nolle says. "In any permissive network environment like that, security has to be based on a combination of the requirement for authentication and on the notion that you are going to interpose a barrier to those connections you don't want, which is to say a firewall."

Contrast that with SDN, which, in theory, provides only a routing path between those places that an architect wants it to communicate, Nolle says -- for example, if an organization was to segment the data center into a dozen application-specific enclaves, with each enclave containing all of the components necessary to run a given application. Meanwhile, at a branch office the organization might create four worker-class user groups into which people are placed based on their job descriptions, which contains several user groups based on individual's job classes.

"Now what I do is use SDN to drive a path between an application group and each of the worker groups that that application is allowed to be accessed from," Nolle says, explaining that each group is connected to only those application enclaves they're authorized to use. "By joining the worker to a worker group in the branch, which I can also do with SDN, I can provide a mechanism that absolutely prevents somebody from accessing an application they're not entitled to because they can't even send traffic to it."

While a combination of existing security technology could offer similar types of role-based control, the difference with SDN is the flexibility and elegance the architecture, says Christofer Hoff, vice president of strategic planning for the security business group at Juniper Networks.

"If you think about how we deploy a good majority of our security controls, it hinges on a brittle network," Hoff says. "What SDN is prompting is the adaptation of security into much more decomposable, atomic units, and then you're going to be able to deliver those services in combination where and when needed, rather than think of security as these monolithic edge devices you plunk somewhere and try to then make sure that traffic is unnaturally routed through them."

In the long term, SDN will allow for greater automation due to improved integration.

"SDN gives us the ability to have these kinds of dynamic feedback loops between what would be considered today as independent pieces of the security stack, allowing them to interoperate in the same way application software does in terms of API," Hoff says.

While there are many moving parts necessary to deploy and policies to develop before the industry gets to that point, Hoff believes that the trend of virtualization in other parts of IT infrastructure have been a sort of a dress rehearsal for SDN.

"We have been iterating on this theme where we've taken physical appliances and started to think about how we virtualize them," he says. "So it depends on how mature the organization is relative to other types of virtualization. If the security teams have not embraced and understood the impact of virtualization, they are going to be potentially rendered even less impactful in their ability to contribute as a functional portion of the SDN life cycle of deployment."

At this point, it is hard for anyone to come to a consensus on how soon SDN will gain widespread popularity. But one point that Nolle mentioned as a potential stumbling block is the very same security benefit he and the others have explained here.

"The SDN space could be a serious problem for the incumbent security vendors. Increasingly, security vendors are also network equipment vendors who have to support the SDN connection technology, and they would look at SDN models that threaten their security business as models that were revenue-reducing. Consequently, they're not going to be tremendously interested in moving them forward," Nolle says. "So it's very possible that the major advantages of SDN with respect to security could never be exploited."

Regardless of when or if, though, Harrison says that IT can at least take an immediate-term lesson from the SDN philosophy.

"We believe that security needs to be a top-down approach," he says. "So you need to see what your business applications are and kind of build your security defenses around that, not the other way around. It's important to manage or to engage the application owners into the security process."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.