SDN and NFV security are issues that rank high with network operators and users, but “security” is an issue that ranks high with everyone and ranking doesn’t always equate with rational action. Of 48 operators I’ve talked with over the last six months, all place SDN and NFV security among their top three issues. Enterprises, in my past surveys, have also ranked network security in the top three in over 80% of cases. But only 38% of enterprises in my survey said they had specific and effective strategies for network security, and only four of 48 operators in SDN/NFV said they even had a handle on it.
A big part of the problem of coming to terms with SDN or NFV security is the lack of a really effective model of security issues. My surveys have shown that enterprises and operators accept that security includes connection security that provides freedom from interception or injection of information on networks, information security that protects information in database form, and software security that protects programs and components from induced bad behavior. There’s clearly an overlap in the categories, indicating to me that our notion of security is to secure things rather than to address classes of risks.
Another issue with SDN and NFV security is that it’s easy to get wrapped around what could be called the “legacy axel.” SDN and NFV both produce network services, and all network services have some common security issues—the need to prevent either interception of traffic or unauthorized injection of traffic, for example. One might be tempted, with both SDN and NFV, to catalog all of the network security issues currently recognized and then rush out to address them in an SDN or NFV context. I’d submit that exercise could take quite a while, and it might or might not really hit all the SDN/NFV issues.
There might be another way, which is what I’ll call “differential security”. SDN and NFV are different in certain ways, and those differences are what will generate incremental differences in SDN and NFV security. If we insure that SDN and NFV implementations deal with securing their differential issues, then we should end up with at least what we’d have had with legacy services. If SDN or NFV have to do more, then we’ll need a map of specific security issues to be addressed and mechanisms proposed to address them.
All software-controlled or software-defined network technologies have an obvious security dependence on the software. Anything that’s going to be loaded and run can immediately start doing stuff, at least some of which might be malicious. For SDN and NFV, the paramount security concern should be software authentication. Every piece of software run has to be authenticated, meaning that the software copy must be a true copy of an explicit release by an accredited organization/entity. Furthermore, every parameter submitted to control the operation of the software must be similarly authenticated.
There’s a corollary rule here that I think could be almost as important as the primary rule. No piece of software and no software parameter file can ever be loaded except by the control software of the network owner. There can be no situations where service-level software can load other service-level software. If that happens then the authentication process is broken because there’s no guarantee that proper procedures will be followed.
Software authentication is essential but not sufficient to protect SDN or NFV. The problem is that software-defining as a process has a natural span of control—a given piece of software is entitled to do specific stuff. To let it do more is to invite errors at best and malice at worst. Thus, all SDN and NFV software must be sandboxed to insure that it can’t spread its wings beyond its intended scope. In most cases this will mean controlling the software’s interfaces, the connections to the outside world.
The most logical way to build a sandbox for SDN and NFV is to presume that you’re going to expose all your interfaces onto a virtual private network or within a private address space, and then explicitly “gate” selected interfaces into the wide world. You absolutely cannot make your control interfaces accessible in the public address space, and that includes interfaces between virtual components.
This is particularly important for “management interfaces” because NFV in particular presents a risk of “leakage” of untrusted elements into a trust-heavy environment. VNFs are caught between two worlds; they are not part of the carrier’s NFV software any more than applications bought from third parties are part of a company’s data center. If management interfaces are exposed within a service then VNFs become a possible portal for malware.
Even in a world of sandboxed, authentic, software we still have some risks of an inside job. When you can’t prevent a problem, at least identify the culprit reliably so you can punish them as a deterrent. That means that every operational change made to a software system has to be attributable via a state audit process. You sign a “change request” and submit it, and the change is then stamped with your signature. In fact, you could make a strong argument for all management-plane messages to be digitally signed.
Attributability is one of the SDN/NFV topics that I think have gotten short shrift in discussions. One reason it’s important to talk about it is that not all signature strategies are really capable of being applied to a broad and loosely coupled community of elements. Yet that’s what SDN and NFV would create. I’d like to see some strong recommendations in this area.
Boundary issues are my final point. SDN and NFV have to interwork with legacy technology at various points, and these points represent places where management and control are different on each side of the mirror. Information like reachability and topology data in IP and even Ethernet may have to be generated or converted at border points, and with this comes the risk of something spoofing itself into creating a failure or even a breach. To the extent that SDN and NFV create borders, they have to be examined carefully to insure that they’re secured.
The sum of the SDN/NFV security situation is that SDN and NFV create multi-element “black box ecosystems” that represent device functionality of the past. We have to insure that these black boxes don’t create increased levels of risk versus the devices they displace. Otherwise black boxes become black hats.