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@xxxxxxxxxxxx> 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
