RE: PIX -> ISA -> OWA Configuration

["Paul Melson" <psmelson () comcast net>]

Bring on the logic...

while [ "$horse" = "dead" ]; do
        beat $horse
done

At the end of the day, everybody that expresses the opinion that #1 < #2 has
missed the point of what a firewall can actually do for them.  Perhaps they
are wise to mistrust IIS, but not if it means trusting a larger number of
other native Windows services.  Let's break it down, and then I've gotta get
off this thread because nobody pays me to worry about OWA/Exchange
infrastructure anymore.

PIX Firewalls offer access control at layer 3.  This mitigates risk by
reducing the number of possible attack vectors against a given system by
only permitting that traffic which is necessary.

An ISA Server, an OWA server, an Exchange server, and an AD domain
controller all run on similar platforms, having similar numbers and types of
attack vectors, give or take a few.

If my OWA presence consists of an ISA Server doing reverse proxy to an OWA
server, and like most organizations, my Exchange server is part of my
production AD environment, then I can create a list that looks like this:

ISA Attack Vectors      OWA Attack Vectors      AD Attack Vectors
Total Attack Vectors
------------------      ------------------      -----------------
--------------------
                35                      30            Exchange 26
116
        
AD DC 25

I am using an arbitrary number (25) assigned to Windows boxes in an AD
domain, but you could calculate this with a quick nmap of your production
boxes.  I'm then adding 10 proxy ports to ISA, 5 ports for IIS (ftp, http/s,
smtp, etc.), and 1 port for Exchange (SMTP).  In this case, I select to
define an attack vector as allowed communication from network of lower
"trust" to a network of higher "trust" (per the PIX interface model) - for
example, traffic allowed from the Internet to the ISA Server is an attack
vector, but traffic from the OWA server to the ISA Server is not.  Then I
subtract the attack vectors from my table and add them up, like so:

ISA (#1)        OWA (#1)        AD (#1) Total (#1)
--------        --------        ------- ----------
         1             1             26           53
                                     25

ISA (#1)        OWA (#1)        AD (#1) Total (#1)
--------        --------        ------- ----------
         1            30             21           72
                                     20

Now you can get fancy with weighting your attack vector charts, perhaps
using your risk assessment and mitigation policy to do so, and you can use
the actual number of listening ports on your production systems, but you'll
still come out with the same conclusion: #1 reduces the exposure of your
ISA/OWA implementation more than #2 does.  

PaulM

PS - How come nobody's come back with, "The most secure option is to not use
OWA at all and make people check their e-mail from the office like normal
human beings." ?  If you apply that option to the risk valuation I use
above, you get a sum of 0.  Clearly better than the rest.


-----Original Message-----
Subject: [fw-wiz] PIX -> ISA -> OWA Configuration

Option #1 would have to be the worst option for security, all you have to do
is re-read Ben Nagy's response and think about it for a few more minutes.
When you place the OWA server directly into your internal network without
controls, you have no controls unless of course you truely believe that a
Microsoft product is not considered a "Hackable device" and in this case we
are talking about two Microsoft products - ISA Proxy Server and OWA.....
[spaghetti] --> [hackable box] --> [hackable box] --> [pot of gold]

Option #2 is the better solution since there is atleast on additional contol
added in the diagram.

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