Due to their natural coupling, SDN and virtual networking are often confused, but are not the same thing. Virtual networking is the ability for networks to exist in a virtual state – removing hardware, as with SDN. This already happens in the majority of networks, VLANs being used as a logical separation control.
Virtual networking still combines the control and management planes and doesn’t change the implementation however. SDN splits out the control plane and makes it simpler to manipulate the underlying traffic, enabling control of the data without access to it.
SDN and virtual networking can exist completely separately from each other, but are a powerful combination when combined. SDN giving control over virtual networks as they expand, enabling fast elastic scaling and movement, which gives benefits for fast Cloud/IaaS deployments, but what about security?
There are three high-level security areas to look at:
- Can SDN help us implement better security than virtual networks alone?
- Can we solve other (non-network) security issues with SDN?
- Can we ensure SDN is secure as it develops?
SDN can certainly help implement better security than virtual networks alone. Its appeal is the flexibility it affords over the underlying network. Network security is no longer just about creating VLANs; other protection can be applied at the networking level with a little extra effort.
For example, Juniper Networks are making use of the open source Contrail software to drive their development strategy. Other vendors such as Bluecat Networks are looking at integration with HP’s SDN controller as HP aligns its SDN technology with Enterprise Networks. The Open Networking Forum (ONF) is creating standards rapidly, and advises on the use of OpenFlow as the underlying protocol for SDN control. Radware have introduced DDoS protection in their SDN application stack, Tufin are talking about SDN in the press and have taken the lead with their own implementation of the application centric control approach.
At this point, we need to look further than SDN to the bigger picture, Software Defined Computing Infrastructure, SDCI. There are new opportunities for security vendors to address issues ranging from dynamic access control to globalised key management and encryption. SDCI can control access to unpatched hardware such as SCADA, printers and individual network components where organizations and vendors have failed to patch. Real IAM integration could be achieved with fine-grained authorization at runtime as opposed to the pseudo-integration of authN typically found in today’s network devices.
This is, and will be, a busy and confusing space for vendors and customers alike at the moment, and the question remains as to whether this is the right focus for our attentions, as many vulnerabilities open up in the networking space, these may, and indeed will be controlled at another layer of abstraction – we need to be looking at Software Defined Computing Infrastructure as a whole.
To say that security is a driver for SDCI would be an understatement; security companies are setting their marketing and development strategies by SDCI. Undoubtedly SDN can, and will, be secured as it develops, but there are wider implications for SDCI, which increases the attack surface considerably. There are few security vendors talking about SDCI currently, but that rarely stops progress in markets as disruptive as the software-defined space is shaping up to be. Expect to see as much security scaremongering as progress around SDCI as it develops quicker than the security market can keep up with it initially.
Just as networking was the simplest place for modern computing to diverge into individual devices to take the load away from computing infrastructure, SDN is just the tip of the SDCI iceberg, and this change of control has a long way to mature. What we are seeing now may be the cutting edge, or it may just be good marketing.