There is probably no issue in technology that gets as much attention as security. Nobody seems to think it’s good enough (and they’re probably right) which means that you can criticize nearly any technology, product, or vendor on the basis of security issues and get a lot of sympathy and attention. So it is with SDN and NFV, both of which have been declared security black holes by various people. The obvious question is “Are they?” and the answer is that it’s too early to say, so we’ll have to focus on potential here.
Security is a term nearly too broad to be useful and a good starting point is to divide it into two categories—content security that relates to malware, viruses, and things that people download accidentally and then does them harm, and connection security that relates to the ability of a network to connect those it’s supposed to and keep out everyone else.
Content security problems can arise from a number of sources, but the most prevalent by far is the Internet. People go to the Internet for something, which could be information, content, software, whatever, and they get something bad instead. Because content security is compromised by content from insecure sources and because the Internet is and will always be such a source, there’s not much that can be done in new SDN/NFV technology to deal with it.
Some vendors have pitched the idea that a smart software virtual function in the delivery path could on-the-fly explore content to bar the bad stuff, but that doesn’t seem practical. There are already tools that can spot a malicious site, but it’s not realistic to assume we could detect malware on the fly from an ordinarily trusted source. I got a contaminated link from a person I know just this week, but fortunately I’m a suspicious type. The only contribution that network technology can bring to content security is keeping bad things off the network in the first place.
That leaves us with connection security, whose properties of servicing the authorized and blocking everyone else has been noted. Connection security breaks down into three specific areas, each of which we’ll look at:
- Network admission control, meaning the ability to control who can join the community the network connects.
- Network interference prevention, meaning the ability to prevent anyone inside or outside the network from doing something that’s destructive to service overall.
- Network interception prevention, meaning the ability to prevent passive interception of traffic.
Network admission control is primarily a service management process in today’s networks. When services are ordered or changed, they can be added to (or removed from) sites or, perhaps in some cases, user’s inventories. If services permit plug-and-play joining, then this process could be automated and based on credentialing. The risks SDN or NFV would bring in this category is encouragement of self-service portals, which could make the admission-control process less secure.
Network interference prevention has two main dimensions. One (the most commonly discussed) is denial-of-service prevention and the other is the decertification of maverick endpoints. For other than public networks like the Internet or networks that share infrastructure, these tasks tend to converge and require both a determination mechanism (“finger-pointing”) and a cutoff mechanism. SDN and NFV could impact this area positively or negatively.
Network interception prevention, if we step outside the area of intercepting physical media like the access line, is also a management and control task. There are some SDN-or-NFV-facilitated activities like passive taps for testing that might be hijacked to create a new risk here.
Like all risks, security risks should be addressed incrementally. If SDN or NFV have the same risk factors in some areas as we face, and accept, today then they aren’t changing the game in security. If they improve or increase risk, then they are. Let’s look at each technology based on that rule and see what falls out.
SDN, in the classic sense, is a centrally managed forwarding framework that eliminates adaptive routing based on inter-device communication. If the central SDN controller is compromised, the entire network is compromised, but that’s true if network management is compromised in general. It’s difficult, in my view, to argue that the centralization of forwarding control adds risk to the picture.
What would create a major security flap is the ability to intercept or hack the device-to-SDN-controller link. SDN raises a point that’s going to be central to all of virtual networking, which is that there has to be a control path that is truly out-of-band to the data plane. It’s not enough to just encrypt it because it could then still be attacked via denial of service. You have to support an independent control plane, just like some old-timers will recall SS7 provided in voice.
On the other hand, central management that eliminates device topology and status exchanges makes it significantly more difficult for a device that’s been compromised to hijack the network. Providing, that is, that the links between SDN domains for interconnect-related exchanges are secure. That security would be easier to accomplish than securing networks from maverick devices—we’ve already seen that happen with false route advertisements.
The big point with SDN may be its ability to partition tenant networks into true ships in the night. Centrally set forwarding rules create routes explicitly and change them explicitly. The devices themselves can’t contaminate this process and because the tenant networks are “out of band” to the common control processes they can’t diddle with each other’s resources. SDN networks could be significantly more secure.
On the NFV side, things are a lot more complicated. What’s difficult about NFV is that what used to be locked up safely inside a box is now distributed across a shared resource pool. Virtual functions that add up to a virtual device could be multi-hosted and interconnected, and this structure presents a two-dimensional risk.
The first dimension is that network connection among functions. Just what is the network the connections are on? If we presumed the ridiculous, which is that it was an open public network, then you’d be able to hack each functional component. But suppose the network is simply the service data network itself? You have still exposed individual functions to connections from the outside, which you now have to prevent. Even if you can do that, you probably could not prevent denial-of-service attacks from the service data plane.
The second dimension is the vertical dimension between functions and their resources. One of the complex issues of NFV is managing resources to secure an SLA, and the setup for doing that in the ETSI spec is a “VNF Manager” at least a component of which might be assembled and run with the VNF. Unless the VNF manager is expected to do its thing with no idea what the state of the assigned resources are, there is now a channel from a tenant software element (the VNF/VNFM) and a shared resource. That could result in major security and stability issues.
Both these dimensions of risk could be exacerbated by the fact that NFV introduces the risk of agile malware that imbeds in the network. A VNF, like a maverick device, could bugger a service. It could also, if it has connection to either the service data plane or the shared resource MIBs, bugger the user’s applications and data or the shared resource pool. Any flaw in a VNF, if it’s exploitable, could be a true disaster.
NFV could require a number of separate control planes or independent resource networks. Every VNF, IMHO, should have a private IP subnet that its components live on. In addition to that, you’ll need the service data plane for the user, and you’ll also need at least one management plane network for centralized control of the resource pool, and probably another for the service management links. All of these will require virtualization along the lines of Google’s Andromeda, meaning that some elements will be represented in multiple virtual networks.
The common thread here is that the real security issues of both SDN and NFV are outside the traditional security framework, or should be, because they involve securing the control plane(s) that manage virtual resources and their relationships with applications and services. We do have an incremental security risk in that area because we have incremental exposure issues. We’re also exacerbating that risk by not addressing the real issues at all. Instead we talk about SDN/NFV “risk” as though it’s an extension of the risks of the past. It’s not, and the security strategies of the past cannot be extended to address the future.
There will be the same old service-security questions with SDN and NFV as with legacy networks, but the virtual security processes are different and we need to understand that it’s virtualization itself we’re securing. Otherwise we’re going to open a true can of worms.