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)
Recent Comments