Re-thinking “trust”: Security in software-defined networking

One of the hottest topics in IT today is software-defined networking, or SDN. SDN separates the control layer for the network from the underlying hardware typically associated with networking functionality. Applications that interact with the network are also separate, and can potentially communicate with the control plane via APIs. The control plane and hardware also communicate with emerging protocols and APIs like OpenFlow. A related concept is Network Functions Virtualization (NFV), where network capabilities like NATing, firewalling and access controls, and intrusion detection are all decoupled from the hardware, as well, usually in a virtual machine or software-based implementation.

If this all sounds confusing, it can be, so here’s the short version - hardware is a commodity, and all network controls and functions are now software somewhere else. That “somewhere else” is where things get interesting, and make for some compelling pros and cons related to security.

The first security consideration in a software-based networking model is isolation of different components. An attacker may be targeting networking equipment, only to find that all control functions are driven from elsewhere. More granular access controls may be built around control functions and tools, allowing security teams to more flexibly protect how the entire network operates by protecting the “crown jewels” of the networking domain in one fell swoop. The counter to this is that there may be a new single point of failure in the SDN controller - if an attacker gains control of this, they could cause incredible damage very quickly. Another key aspect to this isolation involves the hypervisor and virtualization components themselves. There are significant tradeoffs for various security options around performance, capabilities, and integration with the hypervisor itself. Physical isolation of a network controller provides a wholly different type of isolation than a virtual machine performing these functions in a multitenant infrastructure.

The second major security consideration involved in SDN environments is context - where can security gain the most context about the environment? There has always been a major debate as to host vs. network security monitoring, for example. In a virtual networking stack, the network virtualization layer may gain some new capabilities when integrated into the virtual environment. Traffic may be parsed more rapidly or efficiently, application inspection and analysis may be more effective, and automated detection, blocking, or quarantine actions may be simpler to accomplish. Does this provide more context than a host-based solution that is fully integrated with the hypervisor and individual VM components? Where can the most context about attacks and events occurring happen, while still effectively isolating systems, data, and the security controls themselves? Fortunately, the hypervisor layer potentially affords some degree of both isolation AND context for both network and VM-centric events. There are some new concerns that have to be considered in SDN networks, however.

First, the SDN controller needs to be locked down extremely well. Whether physical or virtual, the platform running the SDN control mechanism is a major single point of failure, and so the entire stack surrounding the controller needs attention, from the virtualization layer (if applicable) on up through the OS and application stack. Access to the controller needs to be carefully managed, too…which becomes much more difficult if the controller is deployed as a virtual machine. Now, the inherent multitenancy of the virtual infrastructure becomes a liability, and any specific controls at the virtualization layer will become more important to make sure that no side channel attacks against the controller are possible from a co-tenant VM, and that admins working in the virtual environment don’t inadvertently have more access to the SDN controller than needed. This is the age old separation of duties conversation, with emphasis on roles and privileges needed for access to particular parts of the virtual infrastructure.

Availability of SDN controllers is critical, too, and this is an area that may actually be improved in a virtual form factor. Virtualization affords many organizations some advantages in availability and continuity, with simple snapshots, virtual machine copies, and lower risk of a single hardware failure causing an issue in a clustered configuration. Nonetheless, the risk of the SDN controller going down is significant, as it’s a critical piece of the environment.

With network virtualization, and SDN in particular, security teams will likely need to rethink trust paradigms. With a converged infrastructure, and especially with a virtual SDN controller model, there are new interrelationships that have to be factored in:

• Do all network devices need to implicitly trust the hypervisor layer?

• Or is all management in the SDN environment at layers 3 and above? How are the SDN controllers and other components coupled to the hypervisor, storage, and other layers inherent in virtual or private cloud architectures?

• How do patching, configuration management, and vulnerability management practices and processes (not to mention tools) affect the SDN performance and security within a virtual realm?

These are all questions that have to be considered carefully as we begin decoupling the control and data planes for the network. The data plane now has a “dumb terminal” function at each individual network device. The control plane, arguably, has gotten a lot more complicated in some ways. While the promise of centralized control and configuration, coupled with much improved automation tools and controls, makes SDN attractive, we need to be careful. A virtual SDN controller could easily be an Achilles Heel if we’re not thinking about its security from the beginning.

An entirely new way of approaching security in a virtual infrastructure actually has security in its own layer, often called Software Defined Security, or SDSec. Is this the right approach to the Goldilocks Zone dilemma we’ve discussed here recently?

Could virtualization actually improve the ability to isolate security functions and provide more context at the same time, especially with an entirely separate stack layer? In the next blog post, we’ll build on the ideas of SDN to think about how defining different functions as their own layers (security, storage, applications, networking, and more) brings new capabilities, as well as some challenges, to the modern data center.

To learn more about Security for Virtual Environments and protecting your business without sacrificing performance, join me on this webcast on Tuesday November 18th