Re: Q: Properly separating trust domains

[woody weaver <woody () fullspeed com>]

On Thu, Mar 16, 2000 at 09:45:20PM -0800, Bill Stout wrote:
> [My rust will show here]
>
> What is the best practice to separate networks based on trust level?
>
> Say for example you have a large pool of webservers on the DMZ.  You
> then want to connect those to a pool of application servers on a
> back-end network.  Can you then: I'net---FW---www----apps, or do you
> have to I'net----FW---www---FW---apps?
Bill,

  To separate the networks, you don't have to be linear.  One reasonable
solution:
                         www
                       /
            inet -- FW
                       \
                         apps

There must be an enforcement point between networks at a different
trust level.  So inet -- fw -- www --- apps would put the apps and the
www server at the same trust level.  If they are really different, you
probably don't want to do that.

  One reason that people like the inet -- FW -- www -- FW -- apps
approach is the concept of security in depth.  In real-world firewalls,
walls are measured in minutes of time it takes a fire to burn through a
protective wall.  One would then calculate the time it would take for a
fire to burn through to the "apps" room from the "inet" room as the time
of the outer firewall plus the time of the inner firewall.  In the
electronic world, things aren't so clear.  In particular, if the two
enforcement points are using the same kind of technology and are
configured by the same people, they probably have the same kinds of
vulnerabilities, and so having them in series adds very little to the
strength of the suite.

  So for the inet -- FW -- www -- FW -- apps to make sense, the two
firewall suites should be using different technologies, e.g. the outer
FW is a packet filtering suite, with access lists on routers, maybe a
stateful packet filter, while the inner FW is an application proxy.  You
probably also want to have an IDS setting off an alarm somewhere on that
www net, so that you are made aware that there is traffic between the
two firewalls of a nature that is not permitted, so that you can take
appropriate action before the inner firewall goes down.  But now move
that www net to be another interface off the inner firewall.  (This
makes it look like my diagram.) Traffic from inet to apps still has to
pass the two firewalls, traffic from www to apps still passes one
firewall, but now traffic from inet to www must pass two protective
firewalls, so performance and maintenance aside this should be "better".

  Thus in the diagrammed design is that that thing marked "FW" could
quite reasonably consist of a router with appropriate ACLs, followed by
a screening firewall, followed by IDS alarms, followed by a multiple
interface core firewall.  This kind of strategy can work for core
firewalls in an enterprise, e.g. firewalling off marketing from
engineering from hr.  You can put the extra bric-a-brac (screens, load
balancers if required, etc) on the security domains that are at a wildly
different trust level from the others -- so putting the screen from the
Internet makes sense, but maybe you don't need a full screen to protect
engineering from marketing.

[...]
> Does the separation between trust domains have to be a traditional
> security device, or can a computer running an application itself be a
> proxy?  Does the blue net technically turn green?  

There is no hard and fast answer here.  It depends upon the guidelines
in your written security policy and the level of risk the protected
network is willing to assume.  In a colo site, it is not unreasonable to
have hardened hosts with no firewalls at all!  (Although its only
sensible to at least apply filtering rules on the routers, since that is
pretty much free.)  This computation is all about risk management.

> Bill Stout

--woody


--
(sig for identification purposes only)
Rt.1 Solutions                     voice: 510 652 4293 x405
5858 Horton St, Suite 101          cell : 510 593 5849
Emeryville, CA                     email: woody () rt1solutions com