Today, we catch up with Adam Forch, co-chair of the ONUG Software-Defined Security Services (SDSS) Working Group, to drill down on some of the implications software-defined networking will have for enterprise security. Forch is the Network Security Information Security Advisor at FedEx, and involved in the planning and implementation of new SDN technologies at FedEx.

There are a lot of ONUG Working Groups, why get involved with this one?

My background is primarily in the security space, so I naturally gravitated toward this group. Aside from that, many of the groups, while they address incredibly interesting topics in their own right, still consider security as either an afterthought or more like the traditional perimeter model, which doesn’t necessarily mesh with many of the SDN technologies that are coming on scene now.

Interesting. How do you see SDN technologies meshing with today’s enterprise?

SDN is introducing an aspect of mobility that we don’t see in a traditional network. Traditional security models have built a secure zone around data center and everything inside of that is let go. But with SDN, you may not have a physical separation between a PCI zone and non-PCI zone.

We are seeing technologies that allow workloads to be instantiated virtually anywhere and moved dynamically. This mobility is going to require us to bring security controls closer to the workloads themselves. An internet-facing workload zone, for example, is not supposed to have access to anything but the internet and the relevant app severs. When you move such a workload, you risk breaking that security policy. So the underlying network needs to adapt. This means that the network infrastructure needs to be tied to the virtualization layer and the two must be able to speak with one another.

Enterprises will need this functionality as we seek to unify our data centers. At FedEx, we have many data centers and may very well need to move a workload from Colorado to some other location, for example. When we do that we’d like to have all of these policies and controls move with the workload to the other location.

But it’s not just security that’s an issue. We also aim to address how we measure the confidentiality, availability, and integrity of workloads, and technologies we can use at the physical layer to facilitate these measurements. The overlay piece needs to contain that logic that says, “You can only talk from here to there” and do that with service contract and service chaining. This capability will need to be extensible and move out across the SD-WAN.

How do you see work being done in the SDSS working group impacting security operations centers (SOCs)?

For security analysts in the SOC, not too much should change. We will give them the visibility they will need, but that will tie into the overlays that are controlling access policies and how those move. Equally important will be how to audit them, and that will have to be tied into the SOC of the future.

Are there SDN security areas not being addressed by the group?

Quite a few, really. We had to make a conscious decision to limit our scope initially to the enterprise datacenter space and not concentrate, at least in the initial phases, on SD-WAN or public/private cloud implementations.

What kinds of tools do you see having to be developed to support SDSS?

We’ll need tools that can give us the ability to dynamically capture traffic from physical and virtual switches, as well as tools to trace traffic through an SDN fabric and validate that the appropriate security controls are being applied. Additionally, we’ll need tools that will allow us to create these policies and push them out wherever they may need to be applied, and likewise to then audit those controls to ensure that they are properly applied.

Why can’t we just use traditional security tools?

Traditional tools generally focus around defined security zones. It’s like they build a hard candy shell leaving you with the soft gooey core of largely unprotected hosts (minus, perhaps, some detective controls). When workloads and networks can be created on demand, anywhere, you no longer have a static perimeter to which you can apply security controls.

Will SDSS require changes to the security information and event management (SIEM) platform? 

At a basic level, I don’t think so. We’ll see an increased demand for correlation abilities and the requirement to be able to adjust on-demand as resources are spun up and then disappear.

Finally, what are your bold predictions for SDSS and the next 12 months?

I’m predicting that as SDN technologies mature, we’re going to see many SDN companies turning focus to security policy and enforcement on those SDN networks. Walking through an expo floor at a security conference today you’ll see a glut of endpoint products; I think in the future we’ll start to see some of those companies beginning to focus on virtual technologies.