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:OWASP Metrics Project"
| Line 1: | Line 1: | ||
| − | The OWASP Metrics project is in the process of being reformed. | + | The OWASP Metrics project is in the process of being reformed. We are seeking a leader (or leaders) for the project develop the [[OWASP AJAX Security Project Roadmap]] and identify the first tasks. If you're interested and could commit to 4-8 hours a week, please send an email describing your background to [mailto:[email protected] [email protected]]. |
| − | + | ==Metrics Overview== | |
| + | |||
| + | [[Image:softwarefacts.jpg|right|300px]] | ||
| + | [[Image:Ingredients.png|right|300px]] | ||
| + | |||
| + | It's been said that you can't improve what you can't measure. We currently don't have any good metrics for application security. Everyone understands what we want to measure -- how secure is it? But we're really not sure what low-level measurements we should be making, nor do we know how to roll them up into something meaningful for the buyer or user of software. | ||
| + | |||
| + | The difficulty of this problem is essentially the same as determining if there are any loopholes in a legal contract. Like legalese, programming languages are arbitrarily complex. A malicious developer, like a crafty lawyer, will use all their skill to obfuscate their attack. | ||
| + | |||
| + | ==Direct Metrics== | ||
| + | |||
| + | Ideally, we could just measure the software itself. If we could count all the vulnerabilities and determine their likelihood and impact, we'd know how secure it is. Unfortunately, even the best static analysis tools can't come close to doing this. Still, there are things we can measure, and perhaps we can figure out which of these things directly correlate with increased security. | ||
| + | |||
| + | * How many lines of code? | ||
| + | * What languages are used? | ||
| + | * What libraries does this application use (and how)? | ||
| + | * What type of network access is required (client, server, none)? | ||
| + | * What security mechanisms are used? | ||
| + | * What configuration files are associated with the application? | ||
| + | * How are sensitive assets protected? | ||
| + | * What vulnerabilities have been identified | ||
| + | |||
| + | ==Indirect Metrics== | ||
| + | |||
| + | If you can't measure the security of software directly, another option is to measure the people, process, and technology that are associated with creating the software in the first place? | ||
| + | |||
| + | * Is there security documentation (design, test results, vulnerabilities)? | ||
| + | * Is the documentation accurate and complete? | ||
| + | * Is there a process for reporting security flaws? | ||
| + | * Who developed this code (training, experience, background check)? | ||
| + | * What assurance activities were performed (threat modeling, analysis, code review, test, evaluation)? | ||
| + | * What was the outcome of those assurance activities? | ||
[[Category:OWASP Project]] | [[Category:OWASP Project]] | ||
Revision as of 10:21, 20 June 2006
The OWASP Metrics project is in the process of being reformed. We are seeking a leader (or leaders) for the project develop the OWASP AJAX Security Project Roadmap and identify the first tasks. If you're interested and could commit to 4-8 hours a week, please send an email describing your background to [email protected].
Metrics Overview
It's been said that you can't improve what you can't measure. We currently don't have any good metrics for application security. Everyone understands what we want to measure -- how secure is it? But we're really not sure what low-level measurements we should be making, nor do we know how to roll them up into something meaningful for the buyer or user of software.
The difficulty of this problem is essentially the same as determining if there are any loopholes in a legal contract. Like legalese, programming languages are arbitrarily complex. A malicious developer, like a crafty lawyer, will use all their skill to obfuscate their attack.
Direct Metrics
Ideally, we could just measure the software itself. If we could count all the vulnerabilities and determine their likelihood and impact, we'd know how secure it is. Unfortunately, even the best static analysis tools can't come close to doing this. Still, there are things we can measure, and perhaps we can figure out which of these things directly correlate with increased security.
- How many lines of code?
- What languages are used?
- What libraries does this application use (and how)?
- What type of network access is required (client, server, none)?
- What security mechanisms are used?
- What configuration files are associated with the application?
- How are sensitive assets protected?
- What vulnerabilities have been identified
Indirect Metrics
If you can't measure the security of software directly, another option is to measure the people, process, and technology that are associated with creating the software in the first place?
- Is there security documentation (design, test results, vulnerabilities)?
- Is the documentation accurate and complete?
- Is there a process for reporting security flaws?
- Who developed this code (training, experience, background check)?
- What assurance activities were performed (threat modeling, analysis, code review, test, evaluation)?
- What was the outcome of those assurance activities?
Pages in category "OWASP Metrics Project"
This category contains only the following page.
