Blogger: Dan Blum
Visualizing the Boundaries of Control in the Cloud, which is Scott Morrison's post, reprints my previously posted stack diagram that shows how the complexion of control changes as you move from traditional IT to hosted services to public cloud IaaS, PaaS, and SaaS implementations.
Scott (VP of Engineering and Chief Architect for Layer7) goes on to say that as one cedes control of network security, one must bake security into the software services themselves. Layer7's SecureSpan product has its roots in the XML security gateway (aka web services management) category, and is being transformed into a cloud security gateway. As such, it provides appliances, virtual appliances, and policy management constructs designed to enable customers to run a secure overlay of services over hybrid cloud environments and to exchange standards-based application messages leveraging user or service identity to and from other organizations' hybrid cloud properties, or domains.
Dave Passmore (Burton Group's network research director) notes this is not first time we've seen security architecture layering changes. On seeing Scott's blog post, Dave emailed me: "The author of the blog post summarized very nicely what we’ve been trying to promote for years, long before clouds: “Secure services, not networks."
Actually, what we promote is "layers of security." When at risk, we want as many layers of security as possible. Unfortunately, security may get in the way of functionality, and we must peel back a layer. And with each layer removed, lose a bit of assurance and have to do years of engineering work to try and recover assurance somewhere else.
Let me illustrate. The most secure computer sits encased in cement at the bottom of the ocean. But if you want to use it hoist it up and put it in a locked room. If you want it on a network, lock that network down with firewalls. What if someone from the Internet needs to communicate with it? Now we're on the slippery slope to Burton Group and Jericho Forum's idea of de-perimeterization, which necessitates "secure endpoints and secure protocols."
That's what Dave's talking about. He and I worked hard a few years ago on this idea of "secure endpoints and secure protocols" to create a comprehensive perimeter and zones reference architecture that degrades gracefully from secure, controlled sites to wild and wooly SOHO or branch office sites where endpoints must self-defend or risk compromise. The reference architecture combines sites with trusted networks and sites without them into logical zones of trust leveraging a "security overlay." This is a good reference architecture and still valid.
So we've taken our secure computers out of the locked room, de-perimeterized some of our networks, and are still in the midst of years of engineering required to properly secure endpoints and protocols - which by the way, will require ongoing redesign of hardware and drivers of all sorts to enable full-scale hardware-assisted desktop virtualization as well as changes to the Internet itself. In the midst of this, IT and security are being required by their businesses to outsource to the cloud. Not only have we lost control of the network, now we can't even be sure we have secure endpoints (i.e. servers in the cloud) because they may be run by one of the many (though not all) cloud service providers whose security implementations are incomplete and audit reports unhelpful at best. What to do? What to do?
Can we move the security up a layer, as we did before? Up to "secure services" as Scott suggested in his post? Not entirely. Whereas an endpoint made of hardware has some ability to isolate itself from a hostile network, a service made of software cannot isolate itself. Before a potentially hostile host OS or hypervisor, the application or virtual machine lies helpless. It's like Frodo in the Lord of the Rings: "...there is no veil between me and the wheel of fire. I begin to see it even with my waking eyes, and all else fades."
Yet more years of engineering must be done to get public cloud computing endpoint security up to speed. As I've written elsewhere,To cloud computing vendors: Stop practicing security by obscurity! Also, we need robust NAC (that is, endpoint health assessment) for virtual machines. Before a VM handling sensitive functions fully decrypts itself to run in the public cloud, it should be able to check the Trusted Platform Module (TPM) and do other things to verify the identity of the hosting domain and the security posture of the hosting endpoint. Only then should it activate its services. Trust, but verify. This is just a vision, but perhaps its time will come.
All that being said, Scott and his team and everyone who worked on SAML, WS-*, REST security, and such are doing great work. Its critical for services to communicate securely, comply with policy, and authenticate regardless of location and hosting domain because without that we can't have secure hybrid cloud architectures. That is what the XML gateways morphing to cloud security gateways can offer. But you have to trust all the hosting domains and the hosting endpoints for this to work. And we cannot trust them particularly well right now.
Comments