Re: Rationale of the great DMZ

[Paul Robertson <proberts () patriot net>]

On Wed, 10 Jul 2002, 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

While I'll agree that the level of security has changed, I'm not sure the 
original zoning concept has- let's not forget that what's allowed in and 
out of the internal network has changed as well.

> 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.

More pointedly, it's that traffic coming from the outside be controlled 
and cordoned (for instance, SMTP traffic has almost always come from 
outside-- except in really paranoid places that UUCP out to get mail from 
a DMZ SMTP server.)

> 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 seems to be true overall, where people take time to seperate by 
function, access control or sensativity.

> Some points I have noted:
>
> (1)   Commonly SSL accelerators terminate the SSL end point prior to the
> web services receiving the HTTP data.

True, but typically on a DMZ, the exposure is the accelerator and the Web 
server- and it's not like the  Web server's exposure is lessened in any 
case.

> (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.

This is unfortunately one of the bigger problems out there.  You'd think 
the lessons of Egghead, et al. would have shown people the errors of 
placing CC data on servers outside the perimeter.

> 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.

Typically, application compromise must be performed to get to the point of 
being able to sniff, so it games out pretty evenly.

> (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.

THis depends on the exposure allowed inside- typically only DB traffic at 
the sites I've looked at/been involved in designing.

> (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.

This should be offset by tighter maintenance cycles and greater vigilance 
on DMZ servers.

> (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.

Sniffing is normally the lowest order of problem unless you're transiting 
in the clear from a colocation facility.

> (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.

Not sure I get this one...

> Is anyone else seeing this trend, particularly as e-commerce strives to
> fulfill the management and marketing expectation of reporting functionality?

"Reporting functionality" is what brought us SNMP (I'm pretty sure billing 
off of it came later.)  Just like real-time machine profiling several 
years ago, it adds complexity, load and potential vulnerabilities.  The 
biggest problem though is that nobody wants to pay to do reporting right.  
I've always been of the opinion that stats should be gathered off the 
network by a machine that doesn't have transmit capability (either the 
cable doesn't have a TX wire, or the Ethernet driver for the listening NIC 
doesn't have that code.)  Oddly enough- decrypting SSL early helps obtain 
a good listening post.  I'm hoping that IDS systems grow up to fill that 
void easily.

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
proberts () patriot net      which may have no basis whatsoever in fact."
probertson () trusecure com Director of Risk Assessment TruSecure Corporation

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