How SDN Reduces Network Risks in Campus Settings
Software defined networking (SDN) promises more agility, security and savings when it comes to managing campus infrastructure. But to maximize those benefits, IT departments first have to figure out where and how SDN addresses their organization’s goals and pain points – a step many overlook.
SDN replaces switching, security and other network hardware with software. This virtualization makes it quicker and easier to reconfigure the network for any number of reasons: to accommodate changing demand and use cases, for example, or to fend off hacks. In the process, SDN also can lay the foundation for automated configuration management, saving time and money by freeing the tech staff from manually changing dozens or hundreds of switches every time changes are required.
For example, suppose your organization is hosting a conference with dozens of visitors who will need temporary network access. Instead of giving them carte blanche access to your network, SDN allows IT managers to stand up a network when the event opens and immediately shut it down when it ends. The visitors have access to the Internet during their stay, but without risk of letting their traffic mingle with internal data.
“That’s a great use of SDN,” says Randy Cross, Avaya senior director of fabric networking.
For example, IoT devices that monitor and manage the energy consumption of HVAC or lighting systems send and receive only small amounts of data over the course of a day, but because they lack the processing power and memory to support security mechanisms, they are easily co-opted by hackers to be backdoors into IT networks.
SDN gives IT departments new options for configuring networks capable of addressing IoT’s requirements and risks.
SDN can support such a wide variety of applications, in fact, that its flexibility can become a distraction that keeps IT managers from getting the most out of the technology.
“SDN, while an interesting capability, is a tool that can help address specific business problems,” says Bill Lemons, Juniper Networks director of federal systems engineering. “The most overlooked aspect is the problem they wish to solve.
“It is more important for agencies, enterprises and organizations to focus on what challenges they face in delivering the services, meeting the missions and addressing key business issues first. When those concerns are well understood, the benefits of SDN can be implemented and leveraged to address those concerns head-on.”
Implementing SDN doesn’t necessarily require ripping and replacing the whole network. In many cases, it makes more sense to deploy it as an overlay to support a specific project. Such applications provide valuable hands-on experience that can help determine whether and where to expand SDN use elsewhere in an organization.
“Most of the SDN use cases focus on data center and WAN environments,” Lemons says. “It is, however, conceivable that the provisioning of services and applications to the desktop would be a logical extension to the various use cases in play today. The idea of reserving bandwidth or capacity for one-time or recurring events could benefit from SDN. There are usually less constraints within the LAN that constitute this level of control.”
Savings at Scale
Although operational savings is a major reason why organizations consider SDN, vendors caution that the amount varies significantly by the network’s size.
“There’s a lot of cost savings that larger customers will get out of it,” says Dan Kent, Cisco’s chief technology officer and director of systems engineering for public sector. “The larger you are, the [more] savings will show up in configuration management.”
But for smaller organizations where change is less frequent and staffing levels less flexible, the savings potential is far smaller.
SDN also can be attractive for organizations that define “campus” as including branch facilities.
“We’re seeing more SDN in the branch because they can do a lot more touch and control remotely,” Kent says. “That’s where we’re deploying a lot more SDN than we are in campuses right now.” The more work that can be done remotely, the less staff is needed at branch locations.
New Security Tools
Another big part of SDN’s appeal is that it provides new ways to improve security and neutralize attacks. For example, SDN makes it easier and quicker to reroute traffic away from a node that’s under attack.
“A lot of our customers are looking at campus SDN primarily from the security perspective,” Kent says.
Consider two common applications of SDN:
- Supporting IoT devices
- Supporting employee-owned smartphones, tablets and wearables under a bring-your-own-device (BYOD) policy (BYOD devices can pose security risks because they run personal applications and data that may contain malware)
In both cases, SDN makes it easier to create and enforce highly nuanced security policies for specific categories of devices. For example, Texas A&M researchers suggest giving employee-owned smartphones access to servers and other network-based resources only from specific locations, such as on a floor accessible only to staff with higher security clearances.
The same concept could be applied to limit personal use of BYOD devices on the job, such as allowing wireless network access only from lobbies and cafeterias, but not from workspaces, or to manage bandwidth available to IoT devices. For example, a surveillance camera might be dormant and its available bandwidth constricted until an alarm signals it to turn on, at which point the network could be set to ensure both bandwidth and traffic priority to transmit video.
“IoT devices are prime candidates to be hijacked by botnets and used in Denial of Service [cyber] attacks,” says Stan Tyliszczak, chief engineer at General Dynamics Information Technology and head of the company’s Cyber Security Working Group. “Imagine thousands of hacked IoT sensors all flooding the network with malicious traffic at the same time, choking off other users. If we leverage SDN to create a separate virtual network for those IoT sensors, we can protect the other assets on the network from that malicious traffic. IoT operations might be compromised, but other mission-critical applications can continue unabated.”
SDN setups can be programmed to proactively defend the network. For example, when the network detects that a printer is sending data, it could automatically quarantine that port and alert network security. But that requires a cultural change in the network operations staff: The organization must be comfortable allowing the network to make such decisions on its own.
“When we talk about doing that, most of our customers are a little wary because it’s giving the machine control of the system,” Kent says. “So most of our customers today have the ability to put a person in the middle to look at the analytics and push a button to make that happen. But there’s no reason why that can’t be automated.”
GDIT’s Tyliszczak agrees. “We need to move toward automated security tools and mechanisms. The volume and frequency of attacks is too great for humans to respond effectively. We have to start letting the machines protect themselves.”
Automation provides at least three benefits. It:
- Shortens an attack’s window of opportunity by eliminating the need for a human in the decision loop
- Reduces staff costs because fewer people are needed to monitor security
- Reduces the chance of human error, such as when staff is fatigued from responding to alert after alert after alert
Indeed, Kent says, “Some people would say it’s more secure to have SDN do it because most of the negative impacts on the network are typically caused by human error.”
New Security Risks
No technology is risk free. While SDN provides more flexibility and automation and a smaller attack surface overall, it has its own unique vulnerabilities that IT departments must defend. The biggest of these: The SDN controller itself presents a massive “potential single point of attack and failure,” according to a white paper by the Open Networking Foundation, creator of the OpenFlow SDN standard. Another potential weakness that paper cites: the southbound interface between the controller and networking devices, which “is vulnerable to threats that could degrade the availability, performance and integrity of the network.”
Recognizing those concerns, vendors are rallying to add security to their SDN products.
“There’s definitely the concern that the controllers can be hacked, so we put a lot of effort into securing those systems,” Kent says. “Where we typically worried about the data channel [in the past], now we’re worried about the control channel as we go to the SDN environment.”
But when it comes to security, some things don’t change: Whether your network is virtual or built in hardware, it’s key to create security policies for each part of the network.
“As is the case with any network element—whether it be a switch, router, security device, management system or higher-level orchestrator—ensuring the appropriate security posture of each network element is a key component of an organization’s security policy,” Lemons says. “The orchestrator’s influence over the network – and potentially IT infrastructure, as a whole – makes this part of the policy that much more important.
“Mitigation techniques should be considered to ensure that a compromise or disabling of an orchestration system does not have a negative effect on ongoing operations of the network. There should be a certain amount of capability inherent in the network itself to both operate and self-heal if an orchestration failure were to occur.”
Here again, SDN may offer its own benefits. “Just like SDN can create a separate virtual environment for IoT traffic, we can use it to create a separate virtual environment for a network control element – an out-of-band management network that’s isolated from external access and connections,” says GDIT’s Tyliszczak. “That provides an additional level of protection, not just for SDN controllers, but for all network management activities. The real question is making sure the added capability is worth the added cost and complexity.”