ETSI's Leadbeater: Automation Fuels NFV's True Power

NFV automation can be a double-edged sword for InfoSec, but either way the real cybersecurity issues of virtualization come down to both resource segregation and actual compute power, according to says Alex Leadbeater, BT compliance executive and vice chair of the ETSI NFV Security Group.

Accordingly, it's little surprise that, as the European Telecommunications Standards Institute (ETSI) reports that its NFV group is likely its largest and fastest growing in terms of membership, ETSI is in the process of major undertakings involving NFV security as impacted by automation.

Previously, in part one of this Q&A (lightly edited for length and clarity), Leadbeater emphasized the need for good security implementation fundaments in virtualized networking. (See ETSI's Leadbeater on Securing NFV With Fundamentals.)

Here in part two, Leadbeater gives his perspective on network security as it impacts both virtualization automation -- and preaches the importance of isolation.

Telco Transformation: What have been the security implications that you're seeing of NFV-driven automation?

Alex Leadbeater: Automation is a difficult topic. And one of the reasons it's difficult is that there is a gap; the Moore's Law cycle problem of automation is the direction in which the industry is heading. It's automation that will give NFV its true power. However, at the current time, building fully automated countryside telecom networks is a little bit beyond the compute power of the automation. So one of the start points I would observe is that the reason there has been less done around security automation applications is because it hasn't actually arrived at that level.

That said, there is no reason why automation itself should bring any more challenges than a manually configured network should. If anything, actually, automation allows you to build in security monitoring and other attestation processes by design -- and it also removes, to some degree, the human element out of the loop.

If you typically look at a large number of security vulnerabilities and unfortunate data leaks that have occurred over the years, they very often occurred due to internal error or malicious internal attack. So in that sense, while automation presents challenges because now you've got the network doing things on its own, you've got VMs moving around on their own to a much higher degree without direct oversight. On the other side of the coin, well-implemented automation is a good thing. It brings far more security. It removes some of that human weakness in the loop that exists…So there's a 50-50 tradeoff in that one. The extent to which it's going to be a problem or an advantage? Interesting. I think ask me in a year on that one.

TT: As SD-WAN has really taken off, automation is increasingly being talked about in security-policy implementation and security policymaking via the concept of the self-organized network (SON) -- this concept of a self-healing network that may one day not just operate itself but also long-term plan for itself. For example: "On Tuesdays at 2 pm to 3 pm, we see this kind of traffic, and so I'm going to organize the network this way." How close are we to that with NFV automation and SD-WAN? What are the challenges and obstacles that would need to be overcome?

AL: In principle, I think the biggest barrier to that is actually compute power.

So containers provide some of the answer because they solve some of what you might call the startup delay paradox problem. If you consider for example that with 5G, we're talking about 5-millisecond round-trip delays between two user devices, then the ability to stand up virtual machines, automated slices, or other things in real time literally out-of-the-container fresh -- the ability to do that for an entire countrywide network -- is still some way away. That's just sheer compute power. That said, in two or three or five years' time, that compute power will turn up sooner or later -- and when it does, then great.

Regarding the policy stuff, that's exactly the heart of all the work that's been started in NFV-SEC 013, and it's now progressing. We have a number of other work items in training behind that. But that's exactly where the heart of that work in NFV goes -- is to say, "Okay, what are the building blocks we would require to do that automation from a sec perspective?" And ETSI is very much leading to say, "Okay, these are the things that we are going to need." But that technology -- does it arrive today, or tomorrow? To some degree, that's a moot point from the security perspective. But ETSI is very much taking a lead on it and saying, "Okay, what is it going to need? How would you do that?"

That adaptive policy comes back to the ability to monitor multiple points in the network and to understand how a network needs to evolve -- both at the NFV virtualization layer and the application layer. It's key that those two are tied together. You cannot do security-policy automation at the virtualization layer and the application layer independently. The two have to be together so that the two can marry up. So that's the kind of direction of travel.

TT: What is the role of microservices and the microservices model in virtualized network security moving forward?

AL: I think a large part of that comes down to another technology -- the ability to subdivide the network up into, effectively, little chunks to allow a microservices model. However, and this is something we frequently talk about in the NFV groups, from an application-layer perspective, microservices are resulting in smaller lumps of network resource being, in parallel, given out to smaller and smaller user groups -- be it an enterprise, a small SME, or, in fact, individuals. But actually -- at the virtualization layer and from the perspective of cloud -- they don't, from a security perspective, make a massive difference. What we're talking about in terms of doing security properly in a virtualized environment is the ability to isolate one lump of resource from another -- the only thing to prevent malicious exchange between one virtual machine and another virtual machine, or one set of virtual machines in a container and another set of virtual machines in a different container.

Now that actually goes to the heart of "What is the NFV security challenge?" And that is: How do you separate both in memory and physically one lump or one set of resources from another set of resources? It doesn't really matter whether that's a macroservice or a microservice; or a voice slice, a data slice, or an Internet slice; or if you have a set of three slices and I have a set of three slices, but we share those slices.

The fundamental requirement from a virtualization perspective is keeping one or more lumps or resources within a trust domain -- and preventing those resources from breaking out. So if we have two virtual machines and they serve 5,000 users each and they're doing different things, in order to implement those services securely, you have to be able to keep the two virtual machines away from each other such that no memory failure in one can result in access to the other and vice versa.

Once you solve that problem of how do you isolate things, it doesn't really matter whether it's a macroservice or a microservice. What cloud and NFV and the underlying ETSI technology that's being developed gives you is the ability to do that. Once you've done it, whether you chunk it up into microservices or you chunk it up into something that looks like a legacy model, actually, that doesn't matter. The challenge just sort of scales with it. The keys are trust, isolation and attestation of those things, and an absolute separation of the resources if you wish to do it securely.

— Joe Stanganelli, Contributing Writer, Telco Transformation