The Classical DMZ Design Pattern: How To Kill Security In the Cloud
Every day I get asked to discuss how Cloud Computing impacts security architecture and what enterprise security teams should do when considering “Cloud.”
These discussions generally lend themselves to a bifurcated set of perspectives depending upon whether we’re discussing Public or Private Cloud Computing.
This is unfortunate.
From a security perspective, focusing the discussion primarily on the deployment model instead of thinking holistically about the “how, why, where, and who” of Cloud, often means that we’re tethered to outdated methodologies because it’s where our comfort zones are.
When we’re discussing Public Cloud, the security teams are starting to understand that the choice of compensating controls and how they deploy and manage them require operational, economic and architectural changes. They are also coming to terms with the changes to application architectures as it relates to distributed computing and SOA-like implementation. It’s uncomfortable and it’s a slow-slog forward (for lots of good reasons,) but good questions are asked when considering the security, privacy and compliance impacts of Public Cloud and what can/should be done about them and how things need to change.
When discussing Private Cloud, however, even when a “clean slate design” is proposed, the same teams tend to try to fall back to what they know and preserve the classical n-tier application architecture separated by physical or virtual compensating controls — the classical split-subnet DMZ or perimeterized model of “inside” vs “outside.” They can do this given the direct operational control exposed by highly-virtualized infrastructure. Sometimes they’re also forced into this given compliance and audit requirements. The issue here is that this discussion centers around molding cloud into the shape of the existing enterprise models and design patterns.
This is an issue; trying to simultaneously secure these diametrically-opposed architectural implementations yields cost inefficiencies, security disparity, policy violations, introduces operational risk and generally means that the ball doesn’t get moved forward in protecting the things that matter most.
Public Cloud Computing is a good thing for the security machine; it forces us to (again) come face-to-face with the ugliness of the problems of securing the things that matter most — our information. Private Cloud Computing — when improperly viewed from the perspective of simply preserving the status quo — can often cause stagnation and introduce roadblocks. We’ve got to move beyond this.
Public Cloud speaks to the needs (and delivers on) agility, flexibility, mobility and efficiency. These are things that traditional enterprise security are often not well aligned with. Trying to fit “Cloud” into neat and tidy DMZ “boxes” doesn’t work. Cloud requires revisiting our choices for security. We should take advantage of it, not try and squash it.
/Hoff
Related articles by Zemanta
- The Four Horsemen Of the Virtualization (and Cloud) Security Apocalypse… (rationalsurvivability.com)
- Virtualization & Cloud Don’t Offer An *Information* Security Renaissance… (rationalsurvivability.com)
- The Hypervisor Platform Shuffle: Pushing The Networking & Security Envelope (rationalsurvivability.com)
- Security: In the Cloud, For the Cloud & By the Cloud… (rationalsurvivability.com)
- Incomplete Thought: “The Cloud in the Enterprise: Big Switch or Little Niche?” (rationalsurvivability.com)
- Incomplete Thought: The DevOps Disconnect (rationalsurvivability.com)
- You Can’t Secure The Cloud… (rationalsurvivability.com)
- Friday Cloud Poetry: “On the Bullshit That is False Cloud” (rationalsurvivability.com)
This is a pay me now or pay me later thing for the most part. At some point folks have to realize that the inside and outside are not that different in many cases. The potentially looser concept of compensating controls is not unlike a full choke version of the "silver buckshot" we have joked about previously.
I saw a TED talk yesterday and what the presenter says at the end of it is pretty amazing for its simpleness at face value and yet raw nearly limitless power when applied to topics like this one. It sums up a lot of what I think regarding taking even the basest of standards (people (read training), process, technology. policy etc.) and scaling them up and down religiously.
Benoit Mandelbrot says at the end:
"Bottomless wonders spring from simple rules…repeated without end."
Good post Chris. It is a good illustration of how culture shock is as much if not more of an issue than the technology. Tech is more often than not the easier part of this equation.
Now is the time I wish I had a blog. I was provoked by your article about security and the cloud. I agree with you that our existing methods of securing a physical infrastructure do not apply in a virtualised world. However the security principles remain and need to be addressed. If we choose to sacrifice these for some of the conveniencences of a virtualised infrastructure we will come to regret that decision at some point.
I am a trained CISSP, though in fact I have allowed my membership to lapse, so I feel qualified to talk about security. I am also a VCP and main architect and administrator of my company's VMware virtual infrastructure.
I begin with grave doubts about the compromises that are increasingly made with security. I beleive we are forgotting the lessons of the early nineties when we had serious vulnerabilites. In those days we were lucky that hackers were generally just gaining bragging rights, if our security lapses now professional criminals will not be so sparing. Although we've always seen security as frustrating our productivity, we are now making choices that prioritise productivity. This doesn't sound so bad, and it isn't so long as we are aware of the risks inherent with these decisions.
So lets begin with the pillars of security. Confidentiality, Integrity and Availability. Just google for a thorough explanation of the meanings of these words and an explanation of why these three principles summarise the intentions of security. Basically confidentiality is ensuring our data is not revealed to those it is not intended for. Integrity is ensuring our data is true and trustworthy. Availability is just what it sounds like, though it takes in actual requirements, not just maximising uptime; if its only needed for 30 mins each day, that is when it must be available and must perform acceptably.
With those in mind what bearing do they have on cloud security. I have to say I find the "cloud" moniker unnecessary, especially when talking about private clouds. Essentially we are asking what effect does a virtual infrastructure have on security.
Firstly lets make it clear that availability in most virtual environments is an improvement on their physical architecture. The virtualised hardware, snapshots and HA, FT and VMotion technologies improve uptime, and powerful host systems can more than handle most workloads. Clearly an understanding of VM workloads when specifying host hardware along with careful configuration of hosts is needed to provide necessary resources in a timely manner. But used correctly a virtual infrastructure should improve availability.
Many of the issues of confidentiality and integrity are not affected by our choice of physical or virtual infrastructure, they are more a consequence of the VM's security configuration. The vulnerabilities that are added as a result of a virtual infrastructure are in three main areas; hypervisor, data storage and networking.
The hypervisor security has largely stood up to scrutiny and has gained our confidence. In spite of initial fears of being able to exploit one VM from another, this has not proven possible. The majority of vulnerabilities for VMware have come down to their choice of RHEL for thsir host OS, which will soon be phased out when ESXi becomes the standard.
In my view data storage has not added many vulnerabilities. The only one that springs to mind is that with the necessary permissions on the host a VMDK file could be mounted/opened and data accessed. You could argue that you can restrict those permissions, but how do you hide data from the administrator of your virtual infrastructure. The only answer would be to use RDM storage or disk encryption on the guest OS. It is really only the same risk we all addressed when we started using SAN storage, and the modern equivalent of someone stealing your hard disk.
The final source of vulnerabilites, networking, is I think the crux of most people's problem with private cloud security. Many organisations have a security model that relies on a DMZ supported by physical separation. This is not something that can be recreated in a virtual infrastructure. Cloud advocates would argue this is old thinking, but so did network architects when VLANs came along. Personally I like physical separation; I find that trusting software and more importantly configuration to be a concern. However I think this is a personal decision, not one based on massive empirical evidence. I recognise that in my world mis-configuration is someone plugging a cable in the wrong place and that is not an impossible scenario.
Whatever the right answer, some organisations have already decided that VLANs are not sufficient to support their security requirements and continue to separate their networks physically. These organisations cannot embrace the cloud, so long as they know that vSwitches offer the same kind of security as VLANs – software level security.
That covers security in a virtual "cloud" infrastructure but what impact does a public cloud add to this. It does have a significant impact on security. The first most obvious factor is that the infrastructure is being outsourced. So the usual outsourcing questions apply, ones of trust and SLAs and their security. The second issue is that your VM is now available over the internet. This means your communication channel with it will need to be secured, but this is nothing we haven't handled before with VPNs and the like.
In summary both the public and private clouds do add some security risks, but most of them are similar in nature to ones we have faced before.
@VitaRedux
Thank you for your thoughtful comment. I think, however, you missed my point. The bulk of your comment focused on Private Clouds (nee virtualized infrastructure per your definition) with only a small wrap-up commentary on Public Cloud. My point was that one shouldn't throw away the experience of the former but also that one should not try to force fit definitional or architectural/operational practices on the latter.
The realities of how a completely abstracted and "dumbed down" networking/storage/compute architecture impacts security architecture and operations is quite profound if what you're doing is trying to compare one to the other and force-fit a model.
It's a "squeezing the balloon problem."
The continuous application deployment methodologies associated with Agile, huge scalability, multi-tenancy, mobility, the notion of DevOps, the lack of flexibility and solutions engineering of compensating controls, the lack of transparency, and lack of direct-touch on much of the infrastructure…all of these things make for a difficult set of challenges with public cloud. It takes the private cloud challenges and amplifies them.
Sure these risks are "similar" to those we may have seen before, but the velocity of the technology and prevailing business conditions associated with Cloud (in general — public and private) is the challenge.
The trust model foundations have shifted from physical segregation and separation of duties to a homogenous software layer in hypervisors and software platforms — many of which have not stood the rigors of public review or protracted service times. Only time will tell whether this was a foolish decision…
…but as you said, we've been here before, also. What have we learned?
Thanks again for your comment.
/Hoff
I think maybe I did miss your point. Perhaps that was just something I needed to work through regarding cloud and security as much as a response to your article.
TBH I still dont get your point. Are you talking from the perspective of a public cloud provider? Because if not, you are the cloud consumer and you would not be in a position to "force fit definitional or architectural/operational practices". In true service provision there is normally a lack of transparency in how that service is delivered; you get a service definition and an SLA. If you want control you don't buy into a commodity service.
I agree that software layers are increasingly replcing physical enforced segregation, and certainly IT not only moves forward but accelerates in pace. Perhaps the lessons learnt wont help us if we dont have time to consider them. Personally I always shy away from the bleeding-edge, and maybe even the leading-edge, for that very reason.
"tethered to outdated methodologies because it’s where our comfort zones are." …. all too often that's true. Some people believe what's comfortable (generally… outdated methodologies, etc.) rather than what's true. How can they be comfortable with that? Submit themselves to chaos and insecurity via commitment to status quo. What many don't notice about Service-oriented Architecture is that generally speaking, service layers will spawn in any situation where Technology has been applied for business. When business develops, it's nice for more developed customers to gain the option of looking under the hood. Service layers don't negate the ability to look inside the box by nature, only when service layers have been layered in a shameful / fearful fashion… so as to lock a customer in. Locking a customer in may require information hiding, which may motivate security breaches by an outsider. But perhaps this isn't a Technology problem in a pure sense. What I love about Cloud Computing is that it encourages people to think outside the box and look silly if they are boxing everything together. Packaging can often be a real struggle for Technology people… especially when insecurely designed private packages are inherited or there is market mindedness available as a distraction. SOA offers more packaging options and makes people realize they had a choice all along.
/HOFF: you know what is missing here?
In “Agile, huge scalability, multi-tenancy, mobility, the notion of DevOps” there’s no place for security.
And then OVH has been hacked, and Amazone, And Yahoo, and Diginotar, and…
“Agile, huge scalability, multi-tenancy, mobility, the notion of DevOps” did you say?
do not forget that “the cloud” is just another data center upon which you do not have full control.Will you rely on it and “Agile, huge scalability, multi-tenancy, mobility, the notion of DevOps”?