Featured, McAfee Labs

2014 Threats Predictions: Software Defined Networking Promises Greater Control While Increasing Security Risks

0
By on Jan 06, 2014

This post is one in a series of articles that expand on the recently released McAfee Labs 2014 Threats Predictions. In this and related posts, McAfee Labs researchers offer their views of new and evolving threats we expect to see in the coming year. This article was written by Ramnath Venugopalan.

Software Defined Networking was developed in an attempt to simplify networking and make it more secure. By separating the control plane (the controller)—which decides where packets are sent—from the data plane (the physical network)—which forwards traffic to its destination—the creators of SDN hoped to achieve scalability and agility in network management. The application layer (virtual services) is also separate. SDN increasingly uses elastic cloud architectures and dynamic resource allocation to achieve its infrastructure goals.

Network security today primarily aims to increase control over tightly segmented networks. This increases the complexity of the overall network and makes it harder to manage. This trend will continue as the quest to prevent the lateral movement of malware competes with the need to manage all of these networks. SDN can help provide greater security without increasing management headaches for complex virtual networks in data centers.

SDN can boost security by routing traffic, as appropriate, through a central next-generation firewall and intrusion prevention system as well as by dynamically reprogramming and restructuring a network that is suffering a distributed denial-of-service attack. SDN can also provide capabilities such as automatically quarantining an endpoint or network that has been infected with malware.

In spite of these benefits, SDN also opens potential security holes, especially connections between controllers and network elements, through which the SDN stack itself might be the subject of a distributed denial of service attack. Security is not built into the SDN concept; it needs to be designed in from the beginning of development. SDN configuration errors can have more complex consequences than in traditional settings. Thus SDN requires meticulous adherence to the basic principles of information security and proper policy management. This need will become more important as SDN implementations vary with each provider and begin to cover very large virtual networks with several subnetworks, each with its own policy. Furthermore, SDN has a centralized architecture; compromising the central control could give an attacker command of the entire network.

Security zones are not typically built into VPN solutions, so users must annually coordinate network access policies, port locations of security devices, and any exceptions. Because flexibility is a reason for SDN migration, it is likely that a change in the network might not be adequately reflected in the security infrastructure, or vice versa. Further, open APIs for security functions to SDN have not yet appeared and have not begun to standardize, so API incompatibilities may also cause security holes to appear.

In 2014 and beyond, we will begin to see increased adoption of SDN in data centers, not just in university networks, where they began. We also expect to see targeted attacks, which are likely to leverage policy configuration errors for infiltration and lateral movement. We also anticipate DoS attacks that attempt to overwhelm the links between the network controller and the other two sections.

Exploiting human errors will be the first avenue of attack. As SDN management gets stronger and enterprise adoption of these networks grows, targeted attacks will focus on exploiting the SDN central controller to take over the network and completely bypass network protections.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>