The question of how to secure SDN and NFV comes up all the time, and in my view it’s yet to be fully resolved. I think we’re trying to achieve “security by dissection”, meaning that we look at things like VNFs or NFV Infrastructure and ask how to secure them. Yes, you have to build a secure ecosystem from secure pieces, but ecosystem security isn’t assured that way, only preserved. The things that connect SDN and NFV, the things that make them different, have to be addressed.
The big challenge in SDN and NFV security, speaking ecosystemically, is that there’s a significant “signaling” or “control/management” plane that’s explicit in both. Inside this plane you can command devices, establish behaviors, and most of all admit things from the outside. Compromise this process and your security measures are doomed no matter what you do elsewhere.
Part of the challenge, as I noted in a prior blog, is that we have to define an “architecture” for either SDN or NFV to understand just what security is needed. If there’s a control/management plane, how is it related to the data plane of the service or of the infrastructure? For example, is an NFV service created “inside” a private IP address space and gated to the outside world only for its external ports? If so, and if management connections are gated in a secure way, you’ve gone a long way to creating a secure implementation. If not, if you use public addresses for all components, then everything inside a service could in theory be attacked from the data plane.
Aside from architecture, there is another point about SDN and NFV security that can be addressed in a general sense. Both SDN and NFV are highly dependent on control/management interactions. In fact you could argue that what separates SDN and NFV from the older technologies is the dominance of control/management processes over adaptive processes. That to me means that it’s likely that these control/management processes will need special attention to secure them properly.
Message authentication is like disarmament; the operative concept is “trust but verify.” The presumption in SDN and NFV is that commands issued to devices or device systems are authentic, meaning that they emerge from a trusted entity. Most security is focused on trust management, and most of that falls into the categories of isolation and path protection.
If all your trusted entities are collected in a single subnetwork, and if that subnetwork is made up of protected paths—encrypted or whatever—so that outsiders can’t gain access, then you can control trust conveyance by controlling who’s on the subnetwork. This is why I think the question of subnetwork architecture and security are critical for both SDN and NFV. It does little good to talk about security if your critical control/management interfaces are exposed to public access.
The problem with a pure trust focus is that you don’t account for a trusted entity turning on you, either deliberately or because they were hacked and someone has taken control. Few control measures are total proof against hacking, but it’s possible to reduce risk by making sure that trusted entities are not exposed to public Internet access or subject to the introduction of malicious software. You need a very isolated sandbox, which is not just addressing but processes.
Even that’s not always going to solve your problem. Things creep through almost anything, and there’s also that risk of someone going rogue or simply making a major mistake. This is where the “verification” comes in.
It should be an axiom of SDN and NFV that any control/management change made for any reason must be explicitly associated with a causal factor (both event and the agent making the change) and logged. Further, it should be an axiom that the message itself (including the causal factor and commands) must be authenticated.
Message authentication in networking and IT has been around for a while. The basic idea is that you generate a secure “hash code” from a message that is a form of a cryptographic key. Anyone can send this key to an authority for validation, which means that if you derive the key of a message you receive you can validate the key and through it the authenticity of the message.
Everyone is familiar with a technology that can be useful for the verification of messages in SDN and NFV, but not in the form they’d expect. Bitcoin uses what’s called “block chaining” or (as one word) “blockchain” to keep a tamper-proof history of something. One could apply blockchain principles to SDN and NFV interfaces or control elements to keep a log of everything that happened there, and because the players in the process can be authenticated via a token using a public key, you can identify who did what. One company I’ve encountered who offers this is Guardtime, who as it happens has a relationship with Ericsson. However, I can’t find any specific reference to the two companies working on an SDN or NFV strategy together, which suggests that blockchain applications to control/management security are still novel.
The application of a bitcoin-like process to the control/management action history of a network device or management interface is pretty clear, but you can also apply the blockchain principle to automated responses. We’re entering the “I, Robot” age of networking, where we rely on automated processes to do everything for us. The price of economical operations is low human touch. Absent the Three Laws of Robotics, though (see Asimov’s work if you don’t recognize the term), it’s hard to be confident that our robotic network agents aren’t throwing a flyer now and then. Event-driven processes can also be logged through blockchains so you can track back how something happened.
You can use elements of blockchain technology to authenticate agents, messages, control interfaces, devices, and more. You can even “authenticate” the state of a service or infrastructure element, which means you could know whether you were in it or not. In theory you could build up a model of security using these principles and then use an audit process to establish whether you were still in a state of trust, even in a state of functional optimality.
It seems to me that there’d be a lot of value in exploring what blockchain technology could do in SDN and NFV security, and even in how it could change the view of what audit trails and network state management should look like. Thus, it seems we should be thinking about the blockchain concept as part of the SDN and NFV story, and probably in other IT areas as well.