The market is showing great interest in network virtualization and Software Defined Networking (SDN) as of late and their potential to reduce costs and improve stability, scalability and performance of networks. As with any emerging new technology, it's important to explore how it affects the security stance for organizations, including new concerns and benefits not previously understood.
A definition of SDN separates the control and data planes of the network to control the topology and behavior independently of data forwarding, providing flexibility not found in traditional network devices. An application of SDN capability, called network virtualization, enables the creation of virtualized network atop a physical network, not unlike virtualized servers atop physical servers.
The benefits for SDN include lowering the cost of ownership by reducing the capital and operational expenditures (CapEx & OpEx). Many of the OpEx benefits stem from a centralized control, alleviating the need to access network devices physically to configure them, and the CapEx reduction comes from not deploying physical switches, routers or even middle-boxes virtualized or simulated in software.
SDN systems also have a centralized controller to enable software-defined control over the network, but IT managers must realize that central control systems create a new attack surface and vulnerabilities. If a central network controller is breached, it can give a “one-stop” access to configuration of virtualized devices under its control, which can lead to data loss, or loss of network security. By network security, I'm not talking about IDS or firewalling, but providing security for the network configuration and operations. It's not that the non-SDN world is more secure, since improperly managed devices are also vulnerable. SDN systems with centralized control system just need to secured properly and network security needs to be examined in a new light.
Now that we understand some of the challenges, we can examine some of the security benefits of SDN and network virtualization.
One difficulties in creating a secure network is to validate a variety of configurations and topology. This is problematic where there is a separation of responsibility between the physical infrastructure managers and the tenants that control the applications. Some test and development cloud environments have rapid turnover of virtual machines (VM), and central physical network infrastructure owners cannot keep up with change requests, and which may lead to overly permissive network security defaults. Per-tenant virtual network control over a network enables tenants to create their own network topologies, set access control lists (ACLs), or chain services such as application delivery controllers. In production use-cases, it may be necessary to configure physical devices, but gaining agility to configure them in a test-and-development environment is valuable and enables a broader range of security tests before going into production.
SDN systems are better capable of using centralized policy control to configure the network in which systems policy, such as security or performance requirements, are defined and declared in a manner meaningful for application owners, as opposed to infrastructure owners. For example, an application owner is concerned with declaring what type of controls are placed on the network, as opposed to how they are done. There has traditionally been a gap between the intent of the application owners and infrastructure owners. If the desires are not expressed clearly, they are often misinterpreted by the infrastructure owners. Another example is whether or not a user acceptance test (UAT) version of a multi-tier application ought to have access to “live” data in a customer database in order to test it under production scenarios. We realize that it is difficult to construct a realistic test replica of a customer database, so although that may be undesirable, it may be necessary to resort to connect to live data during off-hours to validate the UAT system before switching into production. Having an automated policy system to manage this will make it much simpler for application and test teams to administer. SDN systems such as Cisco's ACI, as well as the open source Group Policy project under the OpenDaylight or OpenStack's Neutron projects, are working on these capabilities.