Firewall Wizards mailing list archives

Re: websiite log transfers from exposed to internal nets :


From: Richard Threadgill <richardt () midgard net>
Date: Mon, 23 Jun 2003 10:00:22 -0700

In message <F370552B4017D2118B4700A0C9CFE54F019F7462 () exchange vfa com>"Sloane, 
David" writes
Richard,

I thoroughly enjoyed your post - especially the methodology for selecting a
solution.

One question - what brought you to this conclusion?

We want the secure area to connect to the unsecure area. 

It has always seemed safer to me to connect from the secure area to the
unsecure.  When the unsecure system is compromised, it has fewer attack
vectors to internal systems.

Can you elaborate on your preference?

-David

Heh, sorry, my bad - that's such a basic rule that I
neglected to provide the explanation and justification.  

Let's start out by dividing our network into two regions - the
'more secure' side and the 'less secure' side.  We'll put our
storehouse of sensitive data on the part of the network that is
'more secure,' since the entire point of this exercise is to
protect it from malicious attack. As a practical matter, the
difference between them is that we have no control over the 
'less secure' region, and we have some control over the 'more 
secure' region.

Now, let's consider the possible effect of a security compromise
in each of these regions on our sensitive data:

        1. The internal, 'more secure' network is compromised, by
        an unknown attacker who may be internal or may be external.
        If my sensitive data is not independently secured, the 
        attacker now has all of the sensitive data they want, and may
        even be able to establish an ongoing update process to constantly
        report changes in the sensitive data. This would be bad, its
        probably one of the things we've been paid to prevent.
        2. The external, 'less secure' network is compromised.
        Because the 'more secure' network is protected from the 'less
        secure' network, the attacker does not yet have the keys to
        the kingdom, and must now do some amount of work to go get
        the sensitive data.  This is good, whatever risks are being
        mitigated by protecting this data are still being mitigated.

Since our job is to protect the sensitive data, we should assume
that the 'less secure' network is *always* compromised. We should
also assume that any host on the less secure network is easier to
compromise, because other compromised hosts have easy, regular
access to not-yet-compromised hosts on the less secure network.
So we're trying to figure out how to reduce the likelihood that the
compromise will spread from the less secure network to the more
secure network.

Now, let us propose that we are producing some interesting 
sensitive data on the 'less secure' network, and we need to 
transport the data to the 'more secure' network, where it will 
be stored indefinitely and analyzed.  In short, one side needs 
to 'trust' a connection from the other side.  So our question 
is 'do I want a host in the more secure region to trust that 
a host in the less secure region has not been compromised?'
Given our assumption that hosts in the less secure region are
either compromised or merely easier to compromise, I want to put as
little trust in them as possible.  My alternative is to put more
trust in the hosts on the 'more secure' side of the network - 
'do I want a host in the less secure region to trust that a host 
in the more secure region has not been compromised?'  That's a
much, much more appealing alternative.

Furthermore, I want to transfer this data in an automated way, so
humans don't have to get involved.  This means that the trust is
unattended and largely unchecked.  This makes this particular
data transfer a 'risky' operation for the trusting host; if the
trusted host has been compromised, they can probably fairly
easily compromise the trusting host.  This means that I do NOT
want the host on the less secure network to be in control of the
connection.  They may perform some operation which requests that
the trusted host on the more secure connection come pick up the
data, but the trusted host still needs to control that
communication.

In short, the secure host should always connect to the insecure
host.

RichardT


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


Current thread: