OWASP - User contributions [en]

Category:Principle

2006-11-10T21:37:01Z

Roodee: Grammar

This category is for tagging articles related to application security principles.

==What's an application security principle?==

Application security principles are collections of desirable application properties, behaviors, designs and implementation practices that attempt to reduce the likelihood of threat realization and impact should that threat be realized. Security principles are language independent, architecturally neutral primitives that can be leveraged within most software development methodologies to design and construct applications.

Principles are important because they help us make security decisions in new situations with the same basic ideas. 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 to address a specific problem. Although principles can serve as general guidelines, simply telling a software developer that their software must "[[fail safely]]" or that they should do "[[defense in depth]]" won't mean that much.

==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

{{Template:PutInCategory}}

==References==

* [http://web.mit.edu/Saltzer/www/publications/protection/Basic.html Saltzer and Schroeder(see Section 3)]

* [http://www.ranum.com/security/computer_security/editorials/dumb/index.html The Six Dumbest Ideas in Computer Security]

* http://news.com.com/2008-1082-276319.html

* [[OWASP Guide Project]]

* Engineering Principles for Information Technology Security (EP-ITS), by Gary Stoneburner, Clark Hayden, and Alexis, NIST Special Publication (SP) 800-27 [http://csrc.nist.gov/publications/nistpubs/800-27A/SP800-27-RevA.pdf PDF version][http://csrc.nist.gov/publications/nistbul/itl06-2001.txt TXT overview version]

[[Category:OWASP Honeycomb Project]]

Category:Principle

2006-11-09T21:32:00Z

Roodee: Refined application security principles defintion

This category is for tagging articles related to application security principles.

==What's an application security principle?==

Application security principles are a collection of desirable application properties, behaviors, designs and implementation practices that attempt to reduce the likelihood of threat realization and impact should that threat be realized. Security principles are language independent, architecturally neutral primitives that can be leveraged within most software development methodologies to design and construct applications.

Principles are important because they help us make security decisions in new situations with the same basic ideas. 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 to address a specific problem. Although principles can serve as general guidelines, simply telling a software developer that their software must "[[fail safely]]" or that they should do "[[defense in depth]]" won't mean that much.

==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

{{Template:PutInCategory}}

==References==

* [http://web.mit.edu/Saltzer/www/publications/protection/Basic.html Saltzer and Schroeder(see Section 3)]

* [http://www.ranum.com/security/computer_security/editorials/dumb/index.html The Six Dumbest Ideas in Computer Security]

* http://news.com.com/2008-1082-276319.html

* [[OWASP Guide Project]]

* Engineering Principles for Information Technology Security (EP-ITS), by Gary Stoneburner, Clark Hayden, and Alexis, NIST Special Publication (SP) 800-27 [http://csrc.nist.gov/publications/nistpubs/800-27A/SP800-27-RevA.pdf PDF version][http://csrc.nist.gov/publications/nistbul/itl06-2001.txt TXT overview version]

[[Category:OWASP Honeycomb Project]]

Category talk:Threat Agent

2006-11-09T21:13:07Z

Roodee: Distinctions between threat agent and threat

I can appreciate the attempt made to clarify threats with respect to risk, but a redirection on the wiki from threat to threat agent does not, in my opinion, clarify the most basic concept of threat. The definition of 'threat agent' is distinct from the definition of 'threat'. Agent implies a causative entity and, in the case of the wiki entry, I think has been roughly sketched. What has not been done yet is to define the types of events (the threat) the causative entity (threat agent) brings about. Perhaps a rough workflow of a standard security event (a system compromise) will serve to identify the necessary components that need definition. This may also provide the context needed to keep the definitions from shifting.

Here is my previous comment on threat: [[Category_talk:Threat]]

Category talk:Threat

2006-10-11T19:45:21Z

Roodee: Threats as atomic events

I would argue (no surpise there) that threat has little to do with "the potential (or likelihood)" of something bad happening. Instead, a threat should be understood as the "bad happening" itself. In other words, it is the description of that atomic event. Potential and likelihood artifically introduce the concept that a threat is to be understood within the context of probability. I don't think that the definition of threat can, nor should it bear this additional criteria. The concepts of potential and likelihood are more appropriate in describing risk.