This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Category:Principle"
| Line 1: | Line 1: | ||
| − | + | Principles are important because they help us make security decisions in new situations. By considering each of these principles, we can derive security requirements, make architecture and implementation decisions, and identify possible weaknesses in systems. | |
| − | + | The important thing to remember is that in order to be useful, principles must be evaluated, interpreted, and applied. You can't simply tell a software developer that their software must "[[fail safely]]" or that they should do "[[defense in depth]]". It won't mean anything. | |
| − | |||
| − | + | ==Some proven application security principles== | |
| − | |||
| − | |||
| + | *Apply [[defense in depth]] (complete mediation) | ||
| + | *Use a [[positive security model]] (fail safe defaults)(minimize attack surface) | ||
*[[Fail safely]] | *[[Fail safely]] | ||
| − | *Run with [[least privilege]] | + | *Run with [[least privilege]] |
| − | *[[Avoid security by obscurity]] (open design | + | *[[Avoid security by obscurity]] (open design) |
| − | |||
| − | |||
*[[Keep security simple]] (verifiable)(economy of mechanism) | *[[Keep security simple]] (verifiable)(economy of mechanism) | ||
*[[Detect intrusions]] (compromise recording) | *[[Detect intrusions]] (compromise recording) | ||
*[[Don’t trust infrastructure]] | *[[Don’t trust infrastructure]] | ||
*[[Don’t trust services]] | *[[Don’t trust services]] | ||
| − | *[[Establish secure defaults]] (psychological acceptability) | + | *[[Establish secure defaults]] (psychological acceptability) |
| − | |||
| − | + | ==Applying security principles== | |
| + | |||
| + | Consider the exercise of designing a simple web application that allows people to send email to a friend. By evaluating and interpreting each principle, we can arrive at many of the threats to this application and ultimately derive a set of protection requirements. We want to end up with a complete list of what is required to offer this service securely. | ||
| + | |||
| + | TBD: walk through this exercise | ||
| + | |||
| + | ==References== | ||
| + | |||
| + | A. http://web.mit.edu/Saltzer/www/publications/protection/Basic.html (Saltzer and Schroeder)(see Section 3) | ||
| − | + | B. http://news.com.com/2008-1082-276319.html | |
| − | |||
| − | + | C. [[OWASP Guide Project]] | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Revision as of 11:20, 19 April 2006
Principles are important because they help us make security decisions in new situations. By considering each of these principles, we can derive security requirements, make architecture and implementation decisions, and identify possible weaknesses in systems.
The important thing to remember is that in order to be useful, principles must be evaluated, interpreted, and applied. You can't simply tell a software developer that their software must "fail safely" or that they should do "defense in depth". It won't mean anything.
Some proven application security principles
- Apply defense in depth (complete mediation)
- Use a positive security model (fail safe defaults)(minimize attack surface)
- Fail safely
- Run with least privilege
- Avoid security by obscurity (open design)
- Keep security simple (verifiable)(economy of mechanism)
- Detect intrusions (compromise recording)
- Don’t trust infrastructure
- Don’t trust services
- Establish secure defaults (psychological acceptability)
Applying security principles
Consider the exercise of designing a simple web application that allows people to send email to a friend. By evaluating and interpreting each principle, we can arrive at many of the threats to this application and ultimately derive a set of protection requirements. We want to end up with a complete list of what is required to offer this service securely.
TBD: walk through this exercise
References
A. http://web.mit.edu/Saltzer/www/publications/protection/Basic.html (Saltzer and Schroeder)(see Section 3)
B. http://news.com.com/2008-1082-276319.html
Pages in category "Principle"
The following 24 pages are in this category, out of 24 total.
D
- Defense in depth
- Defense in depth (code modification prevention)
- Detect integrity violation incidents (code modification prevention)
- Detect intrusions
- Don't trust user input
- Don’t trust infrastructure
- Don’t trust local resources (code modification prevention)
- Don’t trust mobile OS infrastructure (code modification prevention)
- Don’t trust services
