Software-defined networking security requires IT teams to ensure data confidentiality, the integrity of the network and the availability of network services, along with compliance.
Using SDN to secure the enterprise network is not the end of the story for software-defined networking and security. It's important to consider how the software-defined network itself is secured, as well as any compliance implications of using SDN architecture.
The specifics will vary with the SDN offering, but the principles for software-defined networking security remain the same. To secure the SDN platform, IT teams must do the following:
protect the confidentiality of the data flowing in the software-defined network;
protect the integrity of the SDN system; and
ensure the continued availability of network services.
To fully protect confidentiality, it's necessary to encrypt network traffic. IT teams should also consider encrypting the control channel in the environment, which includes the communications between an SDN controller and the data plane devices that actually move packets.
Moreover, if an SDN system includes any ability to cache data -- e.g., as part of a network flight recorder feature -- or if it has data compression features, it may be necessary to encrypt data stored in memory, or even on a disk, in data plane devices or the controller.
Integrity is foundational
SDN systems can defend themselves from attack, but this requires hardened platforms for both controllers and data plane devices. If the SDN controller is running on a poorly secured Linux server, for example, it doesn't matter how secure the SDN system riding on the nodes is at a high level.
Any off-the-shelf SDN system should have a secured base -- whether Linux, CentOS or something else -- when it comes out of the box. Likewise, data plane devices -- if built on a layered model, like a low-level switch OS with an SDN stack on top of it -- must be secure at both the underlying and upper levels of the stack.
The software-defined network can, of course, be enlisted in its own defense at higher levels. For example, it should be configured to only allow control traffic to flow from the correct location -- the controller -- and not from any random server, laptop or smartphone on the network.
Availability for the software-defined network
IT teams must take the time to learn the new paradigm and make sure SDN infrastructure is as compliant, secure and reliable as the traditional one.
Network teams regularly use redundant switches and cabling routes to protect the availability of network services. The same applies to data plane devices with software-defined networking security, but the presence of the SDN controller requires additional planning.
Redundancy is necessary for true continuity, although the data plane will, in most cases, continue to run its existing programming in the temporary absence of a controller. IT teams can't modify behavior until a controller is back online, but systems using the network wouldn't lose service.
In some SDN offerings, the controller is a dedicated appliance. In those cases, IT teams can acquire a redundant unit.
In other cases, the controller is software running on commodity hardware. IT can spin up a new copy in minutes, and live migration may also be possible. To provide continuity, IT might also run a second copy of the controller, in either a hot-cold failover or hot-hot distributed fashion, depending on the SDN system's design and cost structure. IT also needs to understand and plan for any time the data plane needs to adjust to the loss of a controller or shifting from one controller to another.
Compliance in software-defined networking security
Lastly, IT teams need to make sure they continue to meet the organization's compliance requirements, whether it's the General Data Protection Regulation or anything else within the SDN paradigm. IT must be ready to find protected data cached by an SDN system when asked, to verify protections on it or to definitively confirm the network is not holding data.
Likewise, IT must be able to keep data out of places in the network infrastructure where it shouldn't go, keep it in places it's required to be and be able to delete it. This will require knowing what information the software-defined network retains and for how long. In a WAN use case, it also entails controlling where that information is retained geographically.
GDPR includes a user's name, location and IP address as personal data.
It is early days in enterprise SDN deployment and, subsequently, in software-defined networking security. IT teams must take the time to learn the new paradigm and make sure SDN infrastructure is as compliant, secure and reliable as the traditional one.
