Re: [fw-wiz] Rationale of the great DMZ

From: Dave Piscitello (
Date: 09/27/02

From: Dave Piscitello <>
To: Scott Richard <>,
Date: Fri Sep 27 13:49:01 2002

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

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

David M. Piscitello
Core Competence, Inc. &
3 Myrtle Bank Lane
Hilton Head, SC 29926

Relevant Pages

  • Re: Firewall and DMZ topology
    ... > network, Windows and Linux. ... > laptop used as a simple firewall setup. ... > machine and placing it in a DMZ. ... > internal network, one for the DMZ and one for the Internet. ...
  • Re: Firewall and DMZ topology
    ... >> I would like to set up a SOHO network with a firewall and DMZ for mostly ... >> machine and placing it in a DMZ. ... >> internal network, one for the DMZ and one for the Internet. ... >> The Gartner Group just put Neoteris in the top of its Magic Quadrant, ...
  • RE: DMZ
    ... you've got an internal network consisting of workstations and 1 or more ... or other undesirables would be your DMZ machine which means you can harden ... very secure type of setup as it ensures traffic flows through one and ONLY ...
  • Re: Issue connecting through firewall using jdbc connector.
    ... Web applicationin DMZ ... SQL Server on internal network ... Not a solution for us, though, since the web master has set up a Microsoft network within the DMZ. ...
  • Re: Firewall and DMZ topology
    ... attacker cannot spread his influence across the network. ... If the DMZ resides between the public Internet and the ... Should the DMZ be behind the LAN and not split off at the firewall, ... > The Gartner Group just put Neoteris in the top of its Magic Quadrant, ...