Difference between revisions of "Defense in depth"

From OWASP
Jump to: navigation, search
(Added the rest of the template sections; expanded the description slightly; added a reference.)
Line 5: Line 5:
 
==Description==
 
==Description==
  
The principle of defense in depth calls for a set of layered controls that each present unique obstacles for an attacker. Controls used in defense in depth posture enhance the resilience of an application as the failure of one control will not result in the exploitation of the system as a whole. An application using defense in depth would include controls that fit the “protect, detect, and react” paradigm. This means that the application would not just implement controls that prevent an attack from occurring, but would also be capable of detecting a successful attack and response procedures to support the recovery of the application.  
+
The principle of defense-in-depth is that redundant security mechanisms increase security. If one mechanism fails, perhaps the other one will still provide the necessary security. For example, it is not a good idea to rely on a firewall to provide security for an internal-use-only application, as firewalls can usually be circumvented by a determined attacker (even if it requires a physical attack or a social engineering attack of some sort).  
  
With secure coding, this may take the form of tier-based validation, centralized auditing controls, and requiring users to be logged on all pages.
+
Implementing a defense-in-depth strategy can add to the complexity of an application, which runs counter to the “simplicity” principle often practiced in security. That is, one could argue that new protection functionality adds additional complexity that might bring new risks with it. The risks need to be weighed. For example, a second mechanism may make no sense when the first mechanism is believed to be 100% effective; therefore, there is not much reason for introducing the additional solution, which may pose new risks. But usually the risks in additional complexity are minimal compared to the risk the protection mechanism seeks to reduce.  
  
  
Line 13: Line 13:
  
 
===Vulnerable Administrative Interface===
 
===Vulnerable Administrative Interface===
:A flawed administrative interface is unlikely to be vulnerable to anonymous attack if it correctly gates access to production management networks, checks for administrative user authorization, and logs all access.  
+
:A failed authentication control to the [[Administrative Interface]] is unlikely to be enable to anonymous attack on the system as a whole if it correctly gates access to production management networks, checks for administrative user authorization, and logs all access.  
  
  
Line 27: Line 27:
  
 
* [http://www.nsa.gov/snac/support/defenseindepth.pdf National Security Agency Defense In Depth Guide]
 
* [http://www.nsa.gov/snac/support/defenseindepth.pdf National Security Agency Defense In Depth Guide]
 +
* [[CLASP Security Principles]]
  
 
[[Category:Principle]]
 
[[Category:Principle]]

Revision as of 11:27, 26 May 2008

This is a principle or a set of principles. To view all principles, please see the Principle Category page.

This article is a stub. You can help OWASP by expanding it or discussing it on its Talk page.


Description

The principle of defense-in-depth is that redundant security mechanisms increase security. If one mechanism fails, perhaps the other one will still provide the necessary security. For example, it is not a good idea to rely on a firewall to provide security for an internal-use-only application, as firewalls can usually be circumvented by a determined attacker (even if it requires a physical attack or a social engineering attack of some sort).

Implementing a defense-in-depth strategy can add to the complexity of an application, which runs counter to the “simplicity” principle often practiced in security. That is, one could argue that new protection functionality adds additional complexity that might bring new risks with it. The risks need to be weighed. For example, a second mechanism may make no sense when the first mechanism is believed to be 100% effective; therefore, there is not much reason for introducing the additional solution, which may pose new risks. But usually the risks in additional complexity are minimal compared to the risk the protection mechanism seeks to reduce.


Examples

Vulnerable Administrative Interface

A failed authentication control to the Administrative Interface is unlikely to be enable to anonymous attack on the system as a whole if it correctly gates access to production management networks, checks for administrative user authorization, and logs all access.


Related Vulnerabilities

Related Controls

References