In theory, software defined network (SDN) technology should result in more secure networks. By virtualizing the network into a programmable stack, it will be more nimble, operations should be more automated and less tedious, and that should mean fewer fat-finger disasters.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
But as with any interconnected system, when we delegate essential operations to software we also introduce new risk. When we put servers online, we know some will be compromised so we do our best to mitigate the effects. But what happens then when the network itself can be compromised? What does an SDN rootkit look like? What will comprehensive, effective SDN security look like, and how do we avoid SDN vulnerabilities?
Stuxnet dreams of electric sheep
SDN has become shorthand for network programmability. Whether it's a standards-based solution or proprietary technology from a single vendor -- a roll-your-own OpenDaylight solution or a VMware charmed SDN environment -- they all create the same dilemma: You will be forced to trust software that is new and relatively complicated with the keys to your kingdom. This "solution" will have more reach and will change authority and capacity more than any senior admin. It will also control the reality of its logs.
The sky isn't exactly falling just yet, but consider some of the implications of poor SDN security -- or worse, zero-day vulnerability exploits. One of the reasons Stuxnet was so difficult to create was the broad variety of challenges it needed to overcome. It had to navigate multiple versions of proprietary industrial controllers and operating systems using a basket of protocols and application program interfaces (APIs). That could all be different in an SDN environment.
With SDN, new network security vulnerability arises
More on SDN and security
SDN security challenges emerge
Can SDN be used for NAC?
With a programmable network, worms won't have to slither through existing cracks; they may grab a weak control point and create a golden archway of their choosing, then cloak it from view. Unlike Stuxnet, SDN worms won't have to manage hundreds of different attack vectors. Even in proprietary vendor implementations, SDN offers control via well-documented, easy-to-navigate APIs.
There's an additional threat as we move away from CLI, SNMP and other "old world" interfaces -- we'll connect our performance monitoring and security policy scan systems via the SDN fabric. If an attacker compromises the SDN control layer, they'll be in a position to hide their activity from monitoring and management subscribers. As the technology matures and we become more reliant on automation, we should also expect to see the same changes in admin profiles we see in systems, certainly on the SMB side. Smaller, less experienced teams may be less likely to discover security issues than the green-screen admins they replaced.
How to avoid SDN security nightmares
The future of SDN is bright, and we shouldn't jump to the conclusion that it's going to enable a universal National Security Agency backdoor. The technology will present a host of new challenges, but we can address the problems using our considerable experience with that other programmable platform: servers. Whether you're interacting with vendors or building you own SDN solution, ask the following questions when it comes to implementing secure SDN:
- What percentage of the documentation (or marketing materials) is devoted to security? Does security seem like an afterthought, or is it part of the solution architecture?
- Does the solution make unsupported assumptions about security inside the firewall? Too many products assume that non-Internet-facing systems enjoy magic protection.
- With composite solutions like federated SDN (admit it, you know that's down the road), how will conjoined networks manage delegated trust relationships between controllers? Where will you implement demarcation points to limit the scope of multi-level delegated change?
- How does the solution manage distributed policy context? Do all controlled devices trust change requests from arbitrarily long command chains? Do they have awareness of inheritance, impersonation or requestor role?
- How do you trust but verify? Will the solution include at least a little "Stone Age" technology to keep an eye on the SDN controllers outside of their dominion?
Network programmability will have teething problems like any other new technology, but by staying ahead of it, asking questions and putting it under a microscope in the lab, it will be a good thing indeed.
About the author:
Patrick Hubbard is a head geek and senior technical-product marketing manager at SolarWinds. With 20 years of technical expertise and IT customer perspective, his networking management experience includes work with campus, data center, storage networks, VoIP and virtualization with a focus on application and service delivery in both Fortune 500 companies and startups in high tech, transportation, financial services and telecom industries. He can be reached at Patrick.Hubbard@solarwinds.com.