Re: Rationale of the great DMZ

[Dave Piscitello <dave () corecom com>]

At the risk of resurrecting a tired and old thread, I saw this and had a 
comment of a different sort than Scott's post and subsequent responses.


At 11:38 AM 7/10/2002 -0500, Scott Richard wrote:
> Readers,
>
> It comes obvious in many situations that these days the interpretation of a
> DMZ and its implied security has changed.  Originally, DMZ's were the zoned
> area where systems were placed, that, if they were compromised, wouldn't
> directly comprise the internal system.  The idea is that systems were placed
> in the DMZ were that they should not contain sensitive access points in to
> the internal network.  More so, data would be pushed to these systems in the
> DMZ and data obtain via some proxied effort.  Network activity wouldn't
> necessarily begin from the DMZ and be tunneled in to the internal network.
>
> From what I have seen, the advent of SSL accelerators, hybrid firewalls and
> data encryption technology the traditional DMZ is being depleted for a more
> trusted zone environment.

This is popular among several companies I've worked for and with. IMO it's 
A Good Thing, because it hopefully suggests that organizations (a)  want to 
improve security for their public-facing servers and (b) finally realize 
that there's no such thing as a sacrificial lamb host/server (if there ever 
were such things other than honeypots, I'm not certain I ever agreed with 
this).

Don't you think that eventually, enough organizations will be held 
accountable for attacks perpetrated from systems they are responsible for 
operating that all zones an organization operates will have to be more like 
what we've traditionally called trusted zones? Is it wrong to think that 
how we distinguish "trusted zones" would be a matter of (many) 
constituencies and AAA policy rather than a boolean "here's something we're 
willing to place at (greater) risk, and here's stuff we're not"?

Some companies are still using what we've traditionally called a DMZ but as 
a "dirty network". It's a place where they allow visitors, guests, any 3rd 
party who has authorized entry to their facility but no license/authority 
to use their trusted network. In addition to the compartmentalization of 
these people from the trusted network, they have more lax outbound policies 
- for example, one company does not allow outbound connections to IM or 
gotomypc or any peer to peer application (at least the ones they know how 
to block:-)  on their trusted network but allows these on their dirty network.


> Some points I have noted:
>
> (1)     Commonly SSL accelerators terminate the SSL end point prior to the
> web services receiving the HTTP data.
> (2)     Firewalls are placed between servers and are more passive between
> the DMZ and the internal network.
> (3)     Certain data like credit card data is encrypted, and since this is
> perceived as being secure, more trusted and sensitive data is placed in the
> DMZ. without thought to the very nature of how this data could be easily
> decrypted, or captured prior to it being stored encrypted.
>
>
> Some of the issues:
> (1)     If the SSL connection is terminated prior to the servers inside the
> DMZ, network sniffing is far easier to perform than application hacking to
> obtain sensitive data, traversing from the Internet in to the DMZ and fro
> the DMZ to the inside corporate network.
> (2)     The implicit trust between applications and databases between the
> DMZ and the internal network means, that once a compromise has occurred,
> tunneling in to the corporate network becomes more easily penetrable.
> (3)     As a sites functionality becomes more tightly integrated to the
> business, the DMZ notion is weathered to form a perimeter security barrier
> and the DMZ part of the internal network.
> (4)     The lack of support for SSL on the servers within the DMZ mean s
> that more often or not, data is transmitted insecurely from the DMZ to other
> networks, be it, Internal or back out the DMZ.
> (5)     Cyclical redundancies in network traffic, as VPN's are set up to
> obtain data feeds but the feeds terminate on different hardware that is
> insecure both at the network through to the application levels.
>
> Is anyone else seeing this trend, particularly as e-commerce strives to
> fulfill the management and marketing expectation of reporting functionality?
>
> Cheers
> Richard
>
> Richard Scott
> Information Security
> Tel: (001) -952-324-0697
> Best Buy World Headquarters
> 7075 Flying Cloud Drive
> Eden Prairie, MN 55344 USA
>
> The views expressed in this email do not represent Best Buy
> or any of its subsidiaries
>
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () honor icsalabs com
> http://honor.icsalabs.com/mailman/listinfo/firewall-wizards


David M. Piscitello
Core Competence, Inc. &
3 Myrtle Bank Lane
Hilton Head, SC 29926
dave () corecom com
843.689.5595
www.corecom.com



_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards