Joel Espenschied over at Computerworld wrote a topical today titled "The DMZ's not dead...whatever the vendors are telling you." Joel basically suggests that due to poorly written software, complex technology such as Web Services and SOA and poor operational models, that the DMZ provides the requisite layers of defense in depth to provide the security we need.
I'm not so sure I'd suggest that DMZ's provide "defense in depth." I'd suggest they provide segmentation and isolation, but if you look at most DMZ deployments they represent the typical Octopus approach to security; a bunch of single segments isolated by one (or a cluster) or firewalls. It's the crap surrounding these segments that is appropriately tagged with the DiD moniker.
A DMZ is an abstracted representation of a security architecture, while I argue that defense in depth is an control implementation strategy...and one I think needs to be dealt with as honestly by security/network teams as it is by Enterprise Architects. My simple truth is that there are now hundreds if not thousands of "micro-perimeterized single host" DMZ's in most enterprise networks today and we lean on defense in depth as a crutch and a bad habit because we're treating the symptom and not the problem -- and it's the only thing that most people know.
By the way, defense in depth doesn't mean 15 network security boxes piled on top of one another. Defense in depth really spoke to this model which entailed a holistic view of the "stack" -- but in a coordinated manner. You must focus on data, applications, host and networking as equal and objective recipients of investment in a protection strategy, not just one.
Too idealistic? Waiting for me to run out of air holding my breath for secure applications, operating systems and protocols? Good. We'll see who plays chicken first.
You keep designing for obsolescence and the way things were 10 years ago while I look at what the business needs and where its priorities are and how best to balance risk with sharing information. We'll see who's better prepared in the next three year refresh cycle to tackle the problems that arise as the business continues to embrace disruptive technology while you become the former by focusing on the latter.
There's a real difference between managing threats and vulnerabilities versus managing risk. Back to the article.
Two quotes stand out in the bunch, and I'll focus on them:
The philosophy of Defense in Depth is based on the idea that stuff invariably fails or is cracked, and it ought to take more than one breach event before control is lost over data or processes. But with this "dead DMZ" talk, the industry seems to be inching away from that idea -- and toward potential trouble.
Right. I see how effective that's been with all the breaches thus far. Please demonstrate how defense in depth has protected us against XSS, CSRF, SQL Injection and fuzzing so far? How about basic wireless security issues? How about data leakage? Your precious design anachronism isn't looking so good at this point. You spend hundreds of thousands of dollars and are still completely vulnerable.
That's because your defense in depth is really defense in breadth and it's being applied to the wrong sets of problems. Where's the security value in that?
The talking heads may say the DMZ is dead, but those actually managing enterprise IT installations shouldn't give it up so easily. Until no mistakes are made in application coding, placement, operations and other processes -- and you know better than to hold your breath -- layered network security controls still provide a significant barrier to loss of data or other breach. The advice regarding application configuration and optimization is useful and developers' efforts to make that work are encouraging, but when it comes to the real-world network, organizations can't just ignore the reality of undiscovered vulnerabilities and older systems still lurking in the corners.
Look, the reality is that "THE DMZ" is dead, but it doesn't mean "the DMZ" is...it simply means you have to reassess and redefine both your description and expectation of what a DMZ and defense in depth really mean to your security posture given today's attack surfaces.
Keep your firewalled DMZ Octopi for now, but realize that with the convergence of technologies such as virtualization, mobility, Mashups, SaaS, etc., the reality is that a process or data could show up running somewhere other than where you thought it was -- VMotion is a classic example.
If security policies don't/can't travel with affinity to the resources they protect, your DMZ doesn't mean squat if I just VMotioned a VM to a segment that doesn't have a firewall, IDS, IPS, WAF and Proxy in front of it.
THAT'S what these talking heads are talking about while you're intent on sticking yours in the sand. If you don't start thinking about how these disruptive technologies will impact you in the next 12 months, you'll be reading about yourself in the blogosphere breach headlines soon enough.
Think different.
/Hoff