Well, what is your definition of "Security in Depth"? On Thu, 11 Oct 2007, pdp (architect) wrote:
> 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 <[EMAIL PROTECTED]> 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 > _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/