Client SDN: Securely Delivering the Client-Cloud Transformation (1 of 2) [feedly]

Client SDN: Securely Delivering the Client-Cloud Transformation (1 of 2)
// A Collection of Bromides on Infrastructure

You're surely familiar with the infrastructure revolution promised by Software Defined Networking.   Of course, anyone who's built a public cloud has been doing SDN since day one, because the network – like the virtualized server infrastructure – must enforce isolation, security and privacy per tenant or hosted app.  In the enterprise, VMware's private cloud SDN aspirations (AKA: automate your CCIEs) face a longer journey, but the traditional big iron vendors are in trouble: Cisco's Insieme (an oddly) hardware-based SDN play looks great – as long as you run an all Cisco network.

SDN is a consequence of Moore's law, virtualization and a trend toward DevOps that together mandate that the network be "programmable":

• The legacy app-per-VM model needs the network (including the last hop vSwitch) to satisfy per-VM networking requirements (ACLs, bandwidth needs etc) wherever an instance happens to be dynamically (re-)located.
• Web apps need the cloud fabric to dynamically adjust as application tiers scale and adapt to failures.

SDN extends virtualization to embrace and enforce the requirement for multi-tenancy in the (cloud) data center, dynamically delivering app/instance specific network isolation & resources.  This, together with the cost advantages of running the network stack on standard compute nodes with lots of I/O  are up-ending the business of legacy custom-silicon network vendors.  Software and commodity hardware are indeed eating the world.

You're thinking: "Got it …what's new?" Read on: Courtesy of micro-virtualization Client SDNs will turn the other half of the enterprise network on its head too.

The future of computing is about clouds & clients.   The enterprise will have a private cloud.   It will also consume SaaS and IaaS services from various providers.   Many users will be be mobile – needing application access from mobile devices and laptops/PCs, from untrusted non-enterprise networks, and perhaps even from untrusted BYO devices.   It is unavoidable that the enterprise will only control a small fraction of its network connectivity.   Client SDNs will transform the networks that serve end users in much the same way that cloud SDNs will transform the future of datacenters.

In the days of client-server computing PCs were directly attached to the enterprise network.   To "protect" them IT deployed all sorts of widgets – the Proxy, Firewall, IDS, IPS, and now network sandboxes.   Each promised some new ability to block attacks.  But attackers are agile, and enterprises are not.  Today this legacy is a bit like a Maginot Line that can be easily bypassed in unexpected ways.  These systems implement a mass of inflexible policy and configuration goop with as many holes punched through them as there are apps that users can't do without.

Today's enterprise "perimeter" is a myth. It's indefensible and cannot be re-configured fast enough to detect/block attackers on a time scale that is relevant to the rate of attack evolution.   Moreover, it is becoming less relevant because many of today's users are mobile, off-net and want direct client-cloud access – at the very least for personal use.

But the ultimate problem is not the enterprise network – it's the end point:  Every end point runs hundreds, even thousands, of applications.  Sure IT approves enterprise apps, but each Internet site, each file you download and each attachment you open is a different app – a different trust domain with specific privacy, isolation & security needs.     Client devices are inherently multi-tenant: salesforce.com and a supply chain app co-exist in my browser.  They are different apps, with mutually exclusive needs for access to data, compute and networking on the device.    What's needed is granular isolation and privacy on a per-app basis, for data, compute, memory and networking – on each device.

Inflexible, indefensible, single tenant networks fail in today's cloud-client world as surely as does the notion that a single VM instance could enforce multi-tenancy between different customers / tenants of the cloud. Instead, we rely on the separation enforced by VMs and SDNs.   We need to do the same on clients: If I can fool the user in one context and break an OS abstraction, I gain access to everything on the device.

Micro-virtualization on a client device offers the device equivalent of cloud multi-tenancy – enforced by hardware.  It offers each application (eg: browser tab, or document) a defensible micro-perimeter by hardware-isolating its execution and by enforcing least-privilege access to the device, data and networks.  When a micro-VM communicates with its cloud-hosted back-end service, it requires app-specific, granular, secure isolation.  The client equivalent of a cloud SDN is granular, agile, app-specific network isolation per-micro-VM, at the heart of the client itself.   This is the heart of the Client-SDN.  In part 2: how the Client SDN will help the Maginot Line of legacy network bumps-in-the-wire to become agile and responsive to new attacks.

----
Shared via my feedly reader

Sent from my iPhone