Message-ID: <6905b1570710110614m3cc723f5g43fa345f7c3d1e4d@mail.gmail.com>
Date: Thu, 11 Oct 2007 14:14:53 +0100
From: "pdp (architect)" <pdp.gnucitizen@...glemail.com>
To: gboyce <gboyce@...belly.com>
Cc: "Thor (Hammer of God)" <thor@...merofgod.com>,
	full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: Re: [Full-disclosure] Remote Desktop Command Fixation Attacks

gboyce, cheers... nice example! although I had something else in mind.
maybe I shouldn't have used the term "security in depth" since your
version differs a bit from mine. I guess different semantics. but yes,
i agree that systems, processes, data, etc needs to be separated and
blended into a balanced mix which as you said, while under attack, it
does not give away the keys to the kingdom.

thanks

On 10/11/07, gboyce <gboyce@...belly.com> wrote:
> On Thu, 11 Oct 2007, pdp (architect) wrote:
>
> > Thor, with no disrespect but you are wrong. Security in depth does not
> > work and I am not planning to support my argument in any way. This is
> > just my personal humble opinion. I've seen only failure of the
> > principles you mentioned. Security in depth works only in a perfect
> > world. The truth is that you cannot implement true security mainly
> > because you will hit on the accessibility side. It is all about
> > achieving the balance between security and accessibility. Moreover,
> > you cannot implement security in depth mainly because you cannot
> > predict the future. Therefore, you don't know what kinds of attack
> > will surface next.
> >
> > Security is not a destination, it is a process. Security in depth
> > sounds like a destination to me.
>
> The reason for security in depth is precisely because no security controls
> are foolproof.  The point isn't to make a system completely unbreakable,
> but to raise the bar for what is required in order to extend their access
> beyond what they already control.
>
> Lets take a webserver as an example.
>
> Your webserver only requires ports 80 and 443 listening to the world, so
> you deploy a firewall in front of it restricting access to just those
> ports.
>
> A default install of the OS may enable a few other processes bound to
> remote ports like a mail server, portmap, etc.  These processes aren't
> needed on this particular system.  The firewall blocks access to them, but
> firewalls aren't perfect.  The attacker may have found a way to get behind
> it.  So you turn off those unneeded services.
>
> Being a webserver, its running a number of web applications.  Since you
> don't want to place more trust in those applications than you have to, you
> chroot apache and have it run as a non-privledged user.  Hopefully this
> will contain a successful compromise.
>
> But still, the attacker may break out of the chroot, so you make sure that
> you remove setuid applications or at least keep them up to date with the
> latest security updates.  You do your best to keep them from becoming
> root.  But even that may fail.
>
> Assuming all else has failed, this system is completely owned.  But you
> have other systems with even more sensitive information.  So you architect
> your network such that this webserver does not have more network
> prilvedges than it needs.  You filter outbound network connections to
> hopefully block a good portion of botnet command and control functions.
> You block access from this webserver to other systems unless they have a
> need to talk to them.  You implement application level firewalls between
> it and services that it does need to talk to.
>
> THIS is defence is depth.  Its not about perfect security.  Its about
> containing breaches.  Its about blocking unnecessary risks.  Its about
> making sure that a small mistake that you make does not hand over the keys
> to the kingdom.
>
> --
> Greg
>


-- 
pdp (architect) | petko d. petkov
http://www.gnucitizen.org

Powered by blists - more mailing lists