If you're in the business of architecting a carrier-grade network upgrade or even building a new one, you're almost certainly enhancing it with software-defined networking (SDN). Although just 36% of enterprise organizations are evaluating or planning SDN-based networks, most carriers have already made the leap in some form, at the very least planning to embed a network of SDN controllers and develop a set of SDN applications to manage traffic flows.
These changes are underscored by AT&T's recent announcement of an SDN-based network available in Austin, Texas, and rolling out throughout the rest of the country in 2015. The primary benefit of SDN is agility, as I discussed in my last column. AT&T claims that its SDN-based services will enable business users to provision and modify services in near-real-time, compared to the hours, days or weeks these moves took previously.
But what many architects haven't yet considered --and should --is how such a fundamental paradigm shift in the networking architecture affects other aspects of the network. Securing an SDN-based network requires thinking in terms of software-defined security (SDS).
As most network architects know, the fundamental premise underlying SDN is separating the control plane from the data plane (see figure). This means that the control plane -- which determines routes, service quality and other meta-characteristics -- can be programmed independently from the network infrastructure. Even more significant, network engineers can write applications that manage the control plane -- essentially opening up the possibility of creating customized, software-based traffic-management.
Software-defined security is particularly needed in data centers, where SDN is being deployed initially. Too often, architects are overlooking how security services are provisioned and managed in an SDN environment -- leading to a scenario in which the networking and data center infrastructure is flexible and virtualized, but the security infrastructure is hard-wired.
Hard-wired security and virtualized networks don't mix
As architects and engineers explore the capabilities of SDN-enabled services, they need to ensure that security capabilities are integrated into the SDN infrastructure.
That means the security architecture requires security controllers that are API-equipped, so applications can dynamically provision appropriate security capabilities. That is, as an application rolls out virtual machines (VMs) and configures traffic paths. It needs to be able to associate the virtual components with the appropriate security capabilities, whether IDS; IPS; security information management, or SIM; security information and event management, or SIEM; or the like. As with any other SDN component, a security controller needs to be multiuser so network engineers can support security configurations for multiple customers.
Devices that enable these capabilities are emerging. In 2013, for example, Juniper Networks rolled an integrated security and SDN architecture as part of its Contrail controller, which integrates with open cloud orchestration solutions, including CloudStack and OpenStack, and with most service provider operational support systems and business support systems.
At AT&T's Cybersecurity Conference in early September, Intel showcased its Virtual Security Controller (VSC), a software-defined security solution that was designed to interoperate with VMware NSX, as well as its own McAfee NSP. In 2015, Intel anticipates that the VSC will include support for OpenStack.
Look for additional products to emerge over the coming months. And more importantly, start planning for how you're integrating SDS into your SDN.
Get the service providers' essential guide to SDN planning
Granular is the goal for software-defined networking security
Not a no-brainer: SDN security has challenges too
Can you find security in the SDN stack?