Re: Deploying a DMZ Internationally

From: Gawain Tomlinson (grtomlin@home.com)
Date: 07/29/01 

Message-ID: <01a401c117b4$e479e370$6501a8c0@fed1.sdca.home.com>
From: "Gawain Tomlinson" <grtomlin@home.com>
To: <leds@darkwater.net>, <security-basics@securityfocus.com>
Subject: Re: Deploying a DMZ Internationally
Date: Sat, 28 Jul 2001 15:30:23 -0700

This problem is a lot more common than most people realize.

There are multiple factors that always contribute to this problem. First is
that there is almost always a lack of corporate security policies in place
or lack of authority to enforce policy. When you run into this situation it
should be a priority to give corporate management a wake-up call. One way
to do this is to contract with a qualified security consulting firm for a
network vulnerability assessment (ethical hack). This not only clearly
demonstrates the vulnerabilities to management, but gives you useful
information about the most significant weaknesses.

Second is that when a problem like this has been ongoing for a long period
of time, there are no easy fixes. The "correct" approach is vulnerability,
threat, and risk assessment of each application that is accessed over the
network, and the development of risk mitigation plans. If you get security
policies in place that mandate a reasonable engineering process, you
eventually end up with a maintainable and manageable security
infrastructure.

Since that is a long term process, the next question you should ask is, what
interim steps are appropriate? A VLAN DMZ is a reasonable step. VLANS
provide little protection from insider abuse, but do help limit your outside
exposure. You should also pay attention to intrusion detection monitoring
points, since you cannot monitor effectively on an encrypted connection.

In addition to VLANS you should work on defining security domain boundaries.
Apply the least privilege principle, and attempt to limit users' access to
those functions and information that they have business requirements for.
Carefully architected VLANS and other domain boundary controls can help you
do this.

Also authenticate users. Proper authentication limits deniability in cases
of misuse, and helps control access across domain boundaries.

-Gawain Tomlinson, AT&T Solutions

----- Original Message -----
From: "Led Slinger" <leds@darkwater.net>
To: <security-basics@securityfocus.com>
Sent: Friday, July 27, 2001 5:38 AM
Subject: Deploying a DMZ Internationally

> The company that I work for is in the process of correcting a very old
> and misguided philosophy on Server access. Traditionally they simply
> punched holes through the firewall and allowed access to certain
> servers (Individual Projects) within the corporate network
> infrastructure. It's been a tremendous challenge to get them to
> realize how dangerous it is to allow connectivity behind the protection
> of the firewall. SADMIN/IIS and Code Red worked very well though.
> <grin> The major hurdle right now is that they have built this legacy
> infrastructure internationally and so we're looking at two options:
>
> 1. Suck it up and deal with the pain of locating boxes in two places:
> a U.S. and European based DMZ. There is quite a bit of logistics
> involved with moving servers to these DMZs and the warfare that will
> surely start the moment you take these servers out of the hands of
> those that currently (mis)manage them locally.
>
> 2. Someone suggested that we create a 'VLAN DMZ'. I have to admit
> that I am not entirely familiar with the risk versus reward of this
> one. I understand that this would enable the current sytem
> administrators to keep their machines where they are and still somewhat
> isolate them from the corporate infrastructure. Something about
> carrying this traffic over the corporate backbone still seems a bit odd
> to me.
>
> I was hoping that someone might have dealt with a similar situation and
> could provide a litle feedback on the risk/rewards of these two
> solutions or maybe know of a better solution altogether.
>
> Thanks in Advance!
>
> Leds...
>
> --
> There's nothing wrong with Windows until you install it........
>

Relevant Pages

  • Re: DMZ NT4 TO Internal 2000 AD One-Way Trust via Firewall
    ... leverage an effectivity security policy to ensure that password complexities ... > currently a mess of local and domain users, no security policy, etc. ... DMZ, not publicly accessible) that aren't going away within the stated ... to non-DC web servers in the DMZ on 80 and 443 - none of which are directed ...
    (microsoft.public.windows.server.active_directory)
  • Re: DMZ - Question
    ... Many times you will go as far as to have a web facing DMZ ... security requirements these systems will likely be on their own VLAN at ... architecture to prevent any web facing servers connecting into the ... Mainframe on the LAN, and a Mail server that need access to another ...
    (Security-Basics)
  • Re: PIX network config advice
    ... servers are really at once the code hits the box. ... the DMZ, and it works well. ... Thanks for the advice, like I mentioned all my servers are configured from a DHCP entry, so it's simply just assigning the new non-routables from there and then adding the map to the public IP on the PIX. ... I'll certainly test it in my lab, I think I'll go with it - any extra security is a good thing:D ...
    (comp.dcom.sys.cisco)
  • Re: Joining Servers to a Domain
    ... You can certanly stop policies and scripts from running on specific servers, so that really shouldn't be the determining factor. ... I would be asking questions as to what security benefits they would expect to see, though there are certanly some security and management benefits. ... Usually people will have a seperate forest for the DMZ and use either a trust or federated services to provide access to an internal resource. ...
    (microsoft.public.windows.server.active_directory)
  • Re: webdav on SBS2003
    ... Traditional FW architecture describes a DMZ, ... DMZ and LAN. ... DMZ is that the entire server isn't exposed in the zone, ... you depend on Windows Security to ...
    (microsoft.public.windows.server.sbs)