We live in an age of virtualization, abstraction. We’re facing an onrush of changes in our basic technology platforms driven by the cloud, by SDN, by NFV. We’re told that these new technical options are more, or maybe less, secure. According to my fall survey of users, nearly 90% of businesses said that they felt that security concerns would be greater with new technologies, but at the same time almost 80% felt the new technologies would help to address security. It sounds pretty confused, but it may capture the issue with security in our onrushing virtual age. So let’s look not so much at what we know can be done (which we have little practical history to validate) but at what we know cannot be done.
The first thing we know is that you cannot make a give service model secure by implementing it differently. If you look at things like hacking and DDoS and other Internet security problems, they’re problems related to the fact that the Internet offers uniform addressability and at the same time anonymity. You can initiate a packet that doesn’t carry your return address (if you don’t expect a reply), and you can send to anyone who has an address in your address space.
We hear that SDN would eliminate these kinds of threats, but the fact is that we could eliminate them now if we wanted to surrender one or both of these Internet service-model attributes. The fact is that there are things that SDN could do with security, but we don’t hear about them because they would create a fundamental change in the IP service model. That’s hard to harmonize with current infrastructure and also with our culture of leaving the Internet alone. So in this respect, don’t expect any good security outcomes any time soon.
The second thing we know is that you cannot allow any shared infrastructure to exist in the service data plane of a tenant. Think about it; suppose your competitor can address the switches and servers that your company uses for cloud hosting, SDN application control, or NFV virtual function elements. You’d be OK with that, right? Yet today we have control-plane and management-plane visibility to all the elements of infrastructure in our “network”. We can’t have true tenant isolation in the cloud if we can’t isolate all the shared stuff from all the tenants.
One seldom-recognized corollary to this is that you can’t make management interfaces to shared server/platform and network devices visible to the tenant networks or applications. A MIB that gives you control over a shared switch lets you diddle with its behavior to suit your own interests, but that diddling might be cutting off the other tenants. In a virtual network, everything about management must be virtual or you have a completely insecure situation with no possible limits to your risks. Management APIs are the biggest Achilles’ heel of virtualization today and we’re not talking about that risk enough, even in NFV discussions.
Speaking of NFV, the concept of cooperative virtual function components creating experiences creates another risk, one that is in fact shared with cloud applications or any componentized service. We know that you cannot allow anything to run that cannot be positively authenticated as being what it’s representing to be. All forms of dynamic binding of elements into services or applications creates the risk of not only inviting the wolf into the fold, but cloaking the wolf in a sheep robe before the introduction. And guess what? Signing stuff per se isn’t the answer. A component might be perfectly good in some role or another, and come from a known source, but create fatal instability or security compromises when it’s introduced somewhere else. In componentized services and infrastructure, signature must be role-specific, which means that when we bind stuff into cooperative behavior we authenticate that the pieces bound will serve as we expect. Yes, we have to start with who provided this component and what it is, but we have to go beyond that.
That introduces another thing that we know, which is that secure, stable, componentized applications and services cannot allow components to bind other components directly. You can’t let Thing A load and run Thing B anymore. You must always demand that components signal for the loading of something, even if that something is another copy of itself being created for scale-out.
I’ve always disagreed with prevailing practices and even emerging NFV specifications over this issue. Scaling something creates both a major change in functionality and an opportunity to introduce our wolf again. What we’re saying is that in a cooperative, multi-component, system every management lifecycle process has to be outside the service plane where it can enforce absolute security/compliance practices without interference or being bypassed.
And encryption of data paths? We know that in a cooperative service framework with significant component reuse we cannot make traditional public-key systems scale to support the number of component/role combinations we might have. Too many pieces have to know too much, and anything that knows your keys and my keys knows how to leak stuff between us.
We have had incident after incident relating to compromise of security certificates and public keys, yet we keep believing against all odds that the practice that’s failing under relatively little complexity stress today is going to succeed for us when we make even more demands on it. Tell me how that’s logical?
I’m not crying wolf here (though I referred to one!) I’m of the view that there are solutions available to every challenge I’ve posed, but I’m also of the view that we’re demonstrably not addressing the challenges with the available tools. In most cases this is because all the nuances of our revolutionary technologies haven’t been explored. It’s also true that vendors and the media have cried “wolf!” in security for everything from baselining networks to basketballs, and everyone is just worn out with the barrage of claims. The thing is, we are at a moment in the securing of our future network and IT models where we can get the job done fairly easily and painlessly simply by addressing what we know can’t be done, can’t be allowed, right now, while the architecture is malleable and the investment in place manageable. That’s not going to last long.