Defense In Depth

First adjust your mindset security strives to MINIMIZE risk
NOT elminate it. It is impossible to Eliminate risk and provide
a usable system.


Defense in depth refers to the practice of NOT relying
on any one defense perimeter/mechanism/policy.


A perfect analogy is in climbing. Most climbers use triple point 
protection. The lifeline (rope)  is connected to three seperate 
points of failure. If each point of protection has a one in ten
chance of failure during some duration of time (say 1 hour) then
the chances of all three failing within this same time duration
are 1 in 1000.




Trip wire 

also I would connect my 2end point of protection with 2 feet of slack
this way if and when the first point of connection failed I would know it
I would feel the change and know that failure was occurring and take all steps possible to minimize my security concerns (I.E. - get down )


this is analogs to a tripwire, some way of informing the system it is failing or has been compromised or breached.




but....
how does this relate to software?


DONT TRUST THE FIREWALL


Treat a software system/application the same way
(hopefully better) as system administrators treat a network.

assume you are open:
Define the entry points to the software.
Define exit points of the software.
Define information leakage from the software
 -ie: logging, temp files, caching, etc ...







BEST PRACTICE IMPLEMENTATION EXAMPLE:
-------------

You are writing an application to move data to and from a data base.
1. Dont depend on the firewall.
2. You are the in depth part of defense in depth
3. Use Encryption during data transport to minimize risk.
4. seperate binaries and source.
5. itentify and secure data leakage points
    - caching, temp files, etc ...





NOTE: In this example I am checking for bad data not good data
      so I am breaking one of my own rules. (see "Input validation")


PROBLEM:   DEFEND AGAINST CROSS SITE SCRIPTING


THE IN DOOR
-----------


PERIMETER ONE:  client side check (view) 
-------------
block user from entering "dangerous" characters. 


PERIMETER TWO:  server side check (controller)
-------------
filter input strings for "dangerous" characters.
before passing to model.


PERIMETER THREE:  server side check (model)
-------------
At the last possible moment right before a string is 
about to be written into the database, check it.

filter input strings for "dangerous" characters.




THE OUT DOOR
------------

PERIMETER FOUR:  server side check (model)
-------------
As data is retrieved from the data base check it.
filter output strings for "dangerous" characters.


PERIMETER FIVE:  server side check (controller)
-------------
As data is retrieved from the model check it.
filter output strings for "dangerous" characters.


PERIMETER SIX:  server/client side check (view)
-------------
As data is retrieved from the controller/or yourself 
(ie: echoing of data/error messages etc..  to user)
check it.
filter output strings for "dangerous" characters.


PERIMETER SEVEN:  logging check (all modules)
-------------
As data is written to/ read from logging
check it.
filter logging strings for "dangerous" characters.