OWASP - User contributions [en]

Category:OWASP Application Security Assessment Standards Project

2007-10-05T12:22:27Z

Cbarlow: /* Current Project Status: */

Currently there is a lack of standardization over what constitutes an application security assessment. With no single set of criteria being referenced, it is suggested that OWASP establish a set of standards defining and establishing a baseline approach to conducting differing types/levels of application security assessment. The standards should be flexible in design to accommodate a range of security assurance levels. The standards should not be viewed as placing requirements on any party. Rather, the standards should make recommendations about what should be done to be consistent with what the OWASP community believes is best practice. Adhering to the standards should help increase end user organization confidence that assessments meet an industry agreed-upon approach.

== Objective ==

The Project’s primary objective is to establish common, consistent methods for application security assessments standards that organizations can use as guidance on what tasks should be completed, how the tasks should be completed, who should be involved and what level of assessment is appropriate based on business requirements. The following are seen as key tasks in order to meet this objective:

* Where practical, attempt to “standardize” nomenclature and definitions for common business application types.

* Where practical, attempt to “standardize” nomenclature and definitions of the differing security assessment types.

* Define standard application assessment process in SWIM flow chart.

* Define standard assessment scope per application type.

* Define standard testing boundaries for application assessments.

* Define what is needed on business end to prepare for application assessment.

* Establish where in SDLC should assessment steps be defined/conducted.

* Where practical, attempt to “standardize” skills nomenclature and establish baseline assessor qualifications and evaluation criteria.

* Establish a common set of application assessment levels:

** Define degree of assessment depth per level
** Define testing components required per level
** Establish level of tool usage/type vs. hands on assessment per level
** Establish linkages between level results and security metrics derived
** Establish linkages between levels and Security Maturity Models

* Establish guidance parameters to allow organizations to determine appropriate assessment level based on business application to be assessed.

* Document integration/linkages to other OWASP projects.

This project will not define how to technically to conduct an assessment (refer to OWASP Testing Project); it is instead meant to tie business operations and information management practices to application security in order to establish a common, consistent set of standards which provide guidance in conducting such assessments.

== Current Project Status: ==
'''OWASP Organization Backing'''

* Minimal feedback - Need Leadership Backing.

'''Phase I – Project Approach:'''

* Minimal feedback obtained. Contributors jumped in.

'''Phase II - Definitions:'''

* Define Common Business Application Types – '''Need Input.'''
* Define Security Assessment Types – '''Need Input.'''

'''Phase III – Assessment Context:'''

* Define Standard Application Assessment Process – '''Stub Started - Need Input.'''
* Define Standard Assessment Scope Per Application Type – Need Stub
* Define Standard Testing Boundaries For Application Assessments – Need Stub
* Define Business End Preparation For Application Assessment – Need Stub
* Establish Where In SDLC Should Assessment Steps Be Defined/Conducted – Need Stub
* Establish Baseline Assessor Qualifications And Evaluation Criteria – '''Stub Started - Need Input.'''

'''Phase IV – Assessment Levels:'''

''[ Suggest Establishment of Definitions and Context prior to commencement ]''

* Establish assessment level system common terminology and decision criteria - Included is analysis of potentially corresponding security measurements (i.e. common security metrics, security assurance/maturity models, related legislation, other standards, etc.).
* Create assessment levels based on previous Phase II and III objectives. Define assessment depth, testing components required, and level of tool usage/type (not product names) of tools used per level.
* Document corresponding linkages between assessment levels and common security metrics, security assurance/maturity models, related legislation, other documented national standards defined as component of first Phase III objective.
* Establish guidance parameters to allow organizations to determine appropriate assessment level based on business application to be assessed.

Also refer to project Roadmap.

== Feedback and Participation ==

We hope you find the OWASP Application Security Assessment Standards Project useful. Please contribute back to the project by sending your comments, questions, and suggestions to owasp@owasp.org. To join the OWASP Assessment Standards mailing list or view the archives, please visit the [http://lists.owasp.org/mailman/listinfo/owasp-appsec-standards subscription page.]

== Project Contributers ==

The Assessment Standards project lead is Cliff Barlow of KoreLogic Security. He can be reached at cbarlow@korelogic.com.

Key contributors:

* Bob Austin, KoreLogic Security

* Jeff Williams, Aspect Security

* Vinay Bansal, Cisco Systems

* Imre Kertesz, KoreLogic Security

[[Category:OWASP Project]]

Category:OWASP Application Security Assessment Standards Project

2006-10-20T16:41:26Z

Cbarlow:

Currently there is a lack of standardization over what constitutes an application security assessment. With no single set of criteria being referenced, it is suggested that OWASP establish a set of standards defining and establishing a baseline approach to conducting differing types/levels of application security assessment. The standards should be flexible in design to accommodate a range of security assurance levels. The standards should not be viewed as placing requirements on any party. Rather, the standards should make recommendations about what should be done to be consistent with what the OWASP community believes is best practice. Adhering to the standards should help increase end user organization confidence that assessments meet an industry agreed-upon approach.

== Objective ==

The Project’s primary objective is to establish common, consistent methods for application security assessments standards that organizations can use as guidance on what tasks should be completed, how the tasks should be completed, who should be involved and what level of assessment is appropriate based on business requirements. The following are seen as key tasks in order to meet this objective:

* Where practical, attempt to “standardize” nomenclature and definitions for common business application types.

* Where practical, attempt to “standardize” nomenclature and definitions of the differing security assessment types.

* Define standard application assessment process in SWIM flow chart.

* Define standard assessment scope per application type.

* Define standard testing boundaries for application assessments.

* Define what is needed on business end to prepare for application assessment.

* Establish where in SDLC should assessment steps be defined/conducted.

* Where practical, attempt to “standardize” skills nomenclature and establish baseline assessor qualifications and evaluation criteria.

* Establish a common set of application assessment levels:

** Define degree of assessment depth per level
** Define testing components required per level
** Establish level of tool usage/type vs. hands on assessment per level
** Establish linkages between level results and security metrics derived
** Establish linkages between levels and Security Maturity Models

* Establish guidance parameters to allow organizations to determine appropriate assessment level based on business application to be assessed.

* Document integration/linkages to other OWASP projects.

This project will not define how to technically to conduct an assessment (refer to OWASP Testing Project); it is instead meant to tie business operations and information management practices to application security in order to establish a common, consistent set of standards which provide guidance in conducting such assessments.

== Current Project Status: ==

'''Phase I – Project Approach:'''

* Minimal feedback obtained. Contributors jumped in.

'''Phase II - Definitions:'''

* Define Common Business Application Types – '''Stub Started - Need Input.'''
* Define Security Assessment Types – '''Stub Started - Need Input.'''

'''Phase III – Assessment Context:'''

* Define Standard Application Assessment Process – Need Stub
* Define Standard Assessment Scope Per Application Type – Need Stub
* Define Standard Testing Boundaries For Application Assessments – Need Stub
* Define Business End Preparation For Application Assessment – Need Stub
* Establish Where In SDLC Should Assessment Steps Be Defined/Conducted – Need Stub
* Establish Baseline Assessor Qualifications And Evaluation Criteria – '''Stub Started - Need Input.'''

'''Phase IV – Assessment Levels:'''

''[ Suggest Establishment of Definitions and Context prior to commencement ]''

* Establish assessment level system common terminology and decision criteria - Included is analysis of potentially corresponding security measurements (i.e. common security metrics, security assurance/maturity models, related legislation, other standards, etc.).
* Create assessment levels based on previous Phase II and III objectives. Define assessment depth, testing components required, and level of tool usage/type (not product names) of tools used per level.
* Document corresponding linkages between assessment levels and common security metrics, security assurance/maturity models, related legislation, other documented national standards defined as component of first Phase III objective.
* Establish guidance parameters to allow organizations to determine appropriate assessment level based on business application to be assessed.

Also refer to project Roadmap.

== Feedback and Participation ==

We hope you find the OWASP Application Security Assessment Standards Project useful. Please contribute back to the project by sending your comments, questions, and suggestions to owasp@owasp.org. To join the OWASP Assessment Standards mailing list or view the archives, please visit the [http://lists.owasp.org/mailman/listinfo/owasp-appsec-standards subscription page.]

== Project Contributers ==

The Assessment Standards project lead is Cliff Barlow of KoreLogic Security. He can be reached at cbarlow@korelogic.com.

Key contributors:

* Bob Austin, KoreLogic Security

* Jeff Williams, Aspect Security

* Vinay Bansal, Cisco Systems

* Imre Kertesz, KoreLogic Security

[[Category:OWASP Project]]

Definition for Security Assessment Techniques

2006-10-09T19:06:45Z

Cbarlow:

==Overview==

This article’s focus is to define, where practical, nomenclature and definitions of the differing security '''Assessment Techniques'''. Agreement and establishment of these definitions are foundational to establishing the '''Assessment Levels''' later within this project.

==Techniques==

The following assessment techniques are proposed (in assessment depth order):

* Application Security Threat Assessment
* Application Security Architecture Review
* Automated External Application Scanning (Tool Based)
* Automated Source Code Analysis (Tool-Based Static Code Analysis)
* Manual Penetration Testing (Security Test Specialist)
* Manual Security-Focused Code Review (Software Security Specialist)

NOTE: these should probably link to full articles on each subject

[Semi Agree. Detail on each technique is needed to establish definitions baseline for assessment levels component of project (the guts). OK with moving to full articles if can maintain one master article (need to build in this one) that demonstrates relationships between techniques, commonalities, and relative building of assessment depth from technique to technique]

==Application Security Threat Assessment==

Analyzes application architectural information to develop a threat profile for the application components.

* Identify the nature of the threats – the likely vulnerabilities of the given application and business.

* Estimate the probability that those vulnerabilities might lead to a disruption and the type of impact – both expected and worst case – that might arise.

* Analyze the different consequences and their likelihood of occurrence and determine which should be dealt with and what priority should be attached to mitigate.

While the threats to each asset within the Application can be individually developed and mapped, a more efficient approach is to develop a master list of threat types and identify how these can be used to launch an attack on the Application and/or its components and potentially in turn the business itself. A single threat may exploit a vulnerability to damage different types of assets. Conversely, several threat types may exploit disparate vulnerabilities in order to attack a single critical asset. Given the many-to-many relationships between threats and assets, it is best to use a simple representation of threat to asset mapping by listing threat types by each critical asset identified.

A threat assessment should categorize threat types and threat agents but should focus on malicious threats and will not cover accidental and natural threats. The source of Malicious Threats (the attacker or perpetrator, in this context) can be classified as unauthorized and authorized. Threat vectors and operating environment more fully define how and why a particular “user” falls into one of these categories:

Unauthorized:
* An attacker who does not have credentials to legitimately access the application

Authorized:
* A legitimate user of the application
* A malicious insider
* A previously unauthorized user who has gained authorized access through compromise of a valid account or user session

While the threat agents may have similar intent, varying reasons for engaging in illegal activities motivates them. Some authorized employees may willfully commit fraud for financial gain or engage in sabotage in order to disrupt routine operations. Theft, vandalism, intentional corruptions and alteration of information are also categorized as malicious threats.

''Advantages:''
* Aids in focusing testing activities and defining true targets in large scale enterprise level applications.
* By using results from a threat assessment, the end-client is able to focus assessment (testing) activities based on business requirements and operational reality.
* Allows vulnerabilities discovered in other assessment types to be weighted and prioritized based on threat probability vs. raw vulnerability finding.

''Disadvantages:''
* Cannot guarantee that all possible security threats will be uncovered.
* End-client must evaluate analysis and determine responses(s).
* Requires existence of application architecture documentation.
* Often confused with Risk Assessments, which weigh asset value, threat, and vulnerability in order to determine business risk. Threat assessments focus on identifying only the threat component (vector(s) and probability).

Recommended use:
* Best as a precursor to development activities allowing best use of security resources (i.e., “bake in” security during application development begets higher return on investment vs. “bolting on” application security fixes post production).
* Best utilized to determine the need and extent for further assessment (testing) activities (e.g., automated testing, expert testing, code review, etc.).

==Application Security Architecture Review==

Typically a table-top design level review and analysis of the application to identify critical assets, sensitive data stores and business critical interconnections. The purpose of architecture reviews is to also aid in determining potential attack vectors, which could be used in testing. Thus many organizations will blend this activity with Threat Assessment. The review of the application and its interconnections should include both a network- and application-level evaluation. Evaluation should identify areas of potential and actual vulnerability from these levels. This includes areas of vulnerability in the network and application architecture, in addition to a high-level measure of risk of each of those areas.

''Advantages:''
* Aids in focusing testing activities and defining true targets in large scale enterprise level applications.
* Provides more depth to the development rationale of various functionality in the application life cycle.
* By using results from Architecture Review, the assessment (testing) team is able to follow development logic in the “how” and “why” business and security requirements were integrated into application behavior and security controls/constraints.

''Disadvantages:''
* Cannot guarantee identification of all possible security threats.
* Because the scope of an architectural assessment is far more complex than the limited perspective of an application layer assessment, recommendations are similarly complex, sometimes involving “political” changes (i.e., security department’s level of involvement in the SDLC).
* Requires on-site discussions with application principals.

Recommended use:
* Best as a precursor to development activities allowing best use of security dollars (i.e., incorporate security in beginning begets higher return on investment vs. fixing applications post production).
* Best utilized to determine the need and extent for further assessment (testing) activities (e.g., automated testing, expert testing, code review, etc.).

==Automated External Application Scanning==

Utilizing automated open source or commercial software to discover known application layer vulnerabilities.

''Advantages:''
* Able to quickly identify default content, misconfigurations and error conditions resulting from improper input.
* Ability to be run on automated, regular basis to provide baseline and ongoing vulnerability management metrics.
* Can reduce the time required to assess large applications.
* Lower cost to operate/execute (excluding initial capital cost if using commercial testing software).

''Disadvantages:''
* Not designed to determine the extent to which the vulnerabilities can be exploited to compromise the data the application handles.
* Requires appropriate skills/knowledge to use, configure, and interpret results (despite “point and click” vendor marketing claims).
* Requires extensive configuration and customization to emulate a user session.
* Limited ability to correlate events and correlate minor issues that may lead to larger exposure.
* Inability to adapt to dynamic responses in business logic flows.
* Unable to find vulnerabilities that only become apparent after performing a sequence of steps (e.g., business logic flow bypass, session state compromise, etc.).
* Unable to figure out “how deep the rabbit hole goes” – No means to interpret security implications, express extent of potential compromise, or identify seriousness of business and information exposure.
* Tools will often be confused by some aspect of an application's behavior, causing a particular class of test to generate a false positive. Because most tools lack intelligence and cannot adapt to such conditions, test results include a large number of identical false positives.
** For valid findings, the tools will often find dozens or hundreds of nearly identical findings, each with the same root cause.
* Tool based findings are only indications of problems. Manual review (by someone well versed in web application testing) is usually necessary to draw the necessary parallels between different findings, and determine which findings identify unique problems, and which represent repetition.

Recommended use:
* Handling routine, manually intensive steps (e.g., input validation, field “fuzzing”, etc.) in an assessment is useful, particularly in large applications. However, scanner-based results can be used as the starting point from which expert testing can take over.
* Testing less critical applications (i.e., applications that do not contain/handle business sensitive data and/or are not critical to business operation) where the perceived lower risk does not warrant performing hands-on testing.
* Testing critical applications as a prelude to expert testing or code reviews.

If a tool is used, it is important to define the technical limitations of the tool when the findings are presented. An example of this may involve noting the potential for SQL injection attacks based upon verbose SQL error messages, but also the tool’s inability to produce the correct syntax needed to extract specific information from the vulnerable database. A failure to convey the differences between automated and expert testing increases the risk that the application assessment results will be interpreted (particularly by management) as being more “secure” than they actually are.

==Automated Source Code Analysis==

Automated source code analysis involves the use of special software "tools" to conduct [http://en.wikipedia.org/wiki/Static_code_analysis Static Code Analysis] on software source code to identify potential vulnerabilities within the code.

''Advantages:''
* can be very effective method for identifying defects in code functionality and syntax errors
* most automated source code analysis tools are highly scalable
* expedites code review process (can review 400-500 LOC/hr via manual review vs. up to 10,000 LOC/hr using automated source code scanning tools)
* helps teams focus their manual code review activities on flagged, high-risk areas

''Disadvantages:''
* most automated source code analysis tools generate false positives
* some automated source code analysis tools have a significant learning curve
* some coding languages (such as ASP) are not supported by the tools
* results of automated scans are basically "blueprints" of source code vulnerabilities, so they must be properly protected
* Most of the automated source code analysis tools available on the market today can not identify logic errors, timing errors, resource conflicts, data errors and configuration errors.

Recommended use:
* Automated source code analysis tools can be used to enhance and improve an organization’s overall efforts to find and eliminate security vulnerabilities within software applications. However, they should not be viewed as a "silver bullet". Manual code reviews must still be conducted to identify false positives and security-related defects that tools can not identify.

==Manual Penetration Testing==

Manual Penetration Testing involves application analysis performed by an experienced analyst, usually using a combination of open source automated utilities (either self created or through security community) for performing task-specific functions and hands-on analysis to attempt to further ‘hack’ the application as an attacker.

''Advantages:''
* Open source tools utilized by the expert tester are developed usually for specific purposes rather than wrapping multiple functionality into a GUI. Typically are one of many components in the testers toolkit.
* “Expert testing” is an intuitive approach (Business logic analysis), with the ability to identify flaws in business logic that automated scanners are usually incapable of finding.
* Addresses many of the disadvantages noted in Automated Testing.
* Ability to correlate events and minor issues that may lead to larger exposure. This is a critical advantage of hands-on testing and simulates how a real attacker would operate.
* Ability to communicate complex technical findings in a manner that all can understand. The job is not done until the assessment end-client understands the nature of the vulnerability discovered and its security implications.
** The analysis phase of expert testing provides “root cause” identification and recommendations based upon the unique, developmental characteristics of an application. Results from an automated tool cannot provide customized, specific recommendations tailored for each application and the end-client’s requirements.

''Disadvantages:''
* Often confused with Automated Testing – Marketing of commercial tools uses terms such as “expert” and “intuitive”, normally associated with an assessment performed by an experienced analyst.
* Inability of most end-client organizations to determine if tester has appropriate application security skills required. There are no community accepted credentials/certifications established for this area of security.
* Cost to conduct will be higher though there is no upfront capital cost.
* Without establishing clear metrics up front, ongoing testing to determine trends within business environment or iterations of application is difficult.

Recommended use:
* Testing critical applications (i.e., applications that do contain/handle business sensitive data and/or are critical to business operation) where the perceived higher risk does not warrant performing automated testing.
* Best suited for B2B, B2C and/or any transactional based and/or multi-level access application.

==Manual Security-Focused Code Review==

Review of the software source code to identify source code-level issues, which may enable an attacker to compromise an application, system, or business functionality. Web applications in particular are likely to have these vulnerabilities, as they are frequently developed quickly in an environment that does not allow for much security planning and testing. This should not be viewed as simply a generic software audit. Security-focused code reviews should be specifically tailored to find common vulnerabilities in applications.

''Advantages:''
* If integrated into the [http://en.wikipedia.org/wiki/Software_development_life_cycle Software Development Life Cycle (SDLC)], coding issues can be resolved earlier in the development process. (which is much less expensive to fix than a post-production revision of the code).
* Provides the ability to identify and address serious coding issues (e.g., input validation, hard-coded credentials, debugging features, etc.) prior to production.
* Enables development teams to identify and correct insecure coding techniques that could lead to security vulnerabilities or possible incidents.
* Helps developers learn from each other and share knowledge on secure coding techniques, best practices and common solutions.

''Disadvantages:''
* can be very time consuming and costly if automated tools are not available to help augment the review process
* If conducted solely by tools, results will be mostly static signature matching though some tools claim to walk codepath (follow nested loops and other regression through objects).
* Even applications that exhibit strong and thorough software development practices (e.g., documentation, seamless modularity, string checking to prevent buffer overflows, etc.) can fall victim to attack if the underlying business logic doesn’t follow security requirements.
* Requires specific programming expertise (e.g., Java, .NET, PHP, etc.) that many application testers do not have.

Recommended use:
* Security-focused code reviews should be conducted as part of the normal SDLC. Reviews may also be needed during or after security testing, prior to implementing system upgrades, prior to making system configuration changes, when new security bulletins are released, or immediately following any reported security incidents.

==References/Sources==

* Testing Taxonomy & Testing Tools Classification : http://www.owasp.org/index.php/Image:AppSec2005DC-Arian_Evans_Tools-Taxonomy.ppt

[[Category:OWASP Application Security Assessment Standards Project]]
{{Template:Stub}}

Metrics Survey Form

2006-09-27T16:12:04Z

Cbarlow:

Please use attached to participate in Application Security Metrics Survey

https://www.owasp.org/images/3/30/Survey_form_draft0925061.doc

[[Category:OWASP Application Security Metrics Project]]

Metrics Survey Form

2006-09-27T16:11:39Z

Cbarlow:

Please use attached to participate in Application Security Metrics Survey

[[Category:OWASP Application Security Metrics Project]]

Metrics Survey Form

2006-09-27T16:09:50Z

Cbarlow:

Please use attached to participate in Application Security Metrics Survey

File:Survey form draft0925061.doc

2006-09-27T16:06:11Z

Cbarlow:

Definition for Security Assessment Techniques

2006-09-14T16:37:38Z

Cbarlow:

This project article’s focus is to define, where practical, nomenclature and definitions of the differing security assessment types. Agreement and establishment of these definitions are foundational to establishing the Assessment Levels later within this project. The following assessment types are proposed:

* Application Threat Assessment
* Application Architecture Review
* Automated Testing (Application Scanning (Tool Based))
* Expert Testing (Hands On Based)
* Application Code Review

== Application Assessment Types - Defined: ==

'''Application Threat Assessment''' – Analyzes application architectural information to develop a threat profile for the application components. Threat assessments:

* Identify the nature of the threats – the likely vulnerabilities of the given application and business.

* Estimate the probability that those vulnerabilities might lead to a disruption and the type of impact – both expected and worst case – that might arise.

* Analyze the different consequences and their likelihood of occurrence and determine which should be dealt with and what priority should be attached to mitigate.

While the threats to each asset within the Application can be individually developed and mapped, a more efficient approach is to develop a master list of threat types and identify how these can be used to launch an attack on the Application and/or its components and potentially in turn the business itself. A single threat may exploit a vulnerability to damage different types of assets. Conversely, several threat types may exploit disparate vulnerabilities in order to attack a single critical asset. Given the many-to-many relationships between threats and assets, it is best to use a simple representation of threat to asset mapping by listing threat types by each critical asset identified.

A threat assessment should categorize threat types and threat agents but should focus on malicious threats and will not cover accidental and natural threats. The source of Malicious Threats (the attacker or perpetrator, in this context) can be classified as unauthorized and authorized. Threat vectors and operating environment more fully define how and why a particular “user” falls into one of these categories:

Unauthorized:
* An attacker who does not have credentials to legitimately access the application

Authorized:
* A legitimate user of the application
* A malicious insider
* A previously unauthorized user who has gained authorized access through compromise of a valid account or user session

While the threat agents may have similar intent, varying reasons for engaging in illegal activities motivates them. Some authorized employees may willfully commit fraud for financial gain or engage in sabotage in order to disrupt routine operations. Theft, vandalism, intentional corruptions and alteration of information are also categorized as malicious threats.

''Advantages:''
* Aids in focusing testing activities and defining true targets in large scale enterprise level applications.
* By using results from a threat assessment, the end-client is able to focus assessment (testing) activities based on business requirements and operational reality.
* Allows vulnerabilities discovered in other assessment types to be weighted and prioritized based on threat probability vs. raw vulnerability finding.

''Disadvantages:''
* Cannot guarantee that all possible security threats will be uncovered.
* End-client must evaluate analysis and determine responses(s).
* Requires existence of application architecture documentation.
* Often confused with Risk Assessments, which weigh asset value, threat, and vulnerability in order to determine business risk. Threat assessments focus on identifying only the threat component (vector(s) and probability).

Recommended use:
* Best as a precursor to development activities allowing best use of security resources (i.e., “bake in” security during application development begets higher return on investment vs. “bolting on” application security fixes post production).
* Best utilized to determine the need and extent for further assessment (testing) activities (e.g., automated testing, expert testing, code review, etc.).

'''Application Architecture Review''' – Typically a table-top design level review and analysis of the application to identify critical assets, sensitive data stores and business critical interconnections. The purpose of architecture reviews is to also aid in determining potential attack vectors, which could be used in testing. Thus many organizations will blend this activity with Threat Assessment. The review of the application and its interconnections should include both a network- and application-level evaluation. Evaluation should identify areas of potential and actual vulnerability from these levels. This includes areas of vulnerability in the network and application architecture, in addition to a high-level measure of risk of each of those areas.

''Advantages:''
* Aids in focusing testing activities and defining true targets in large scale enterprise level applications.
* Provides more depth to the development rationale of various functionality in the application life cycle.
* By using results from Architecture Review, the assessment (testing) team is able to follow development logic in the “how” and “why” business and security requirements were integrated into application behavior and security controls/constraints.

''Disadvantages:''
* Cannot guarantee identification of all possible security threats.
* Because the scope of an architectural assessment is far more complex than the limited perspective of an application layer assessment, recommendations are similarly complex, sometimes involving “political” changes (i.e., security department’s level of involvement in the SDLC).
* Requires on-site discussions with application principals.

Recommended use:
* Best as a precursor to development activities allowing best use of security dollars (i.e., incorporate security in beginning begets higher return on investment vs. fixing applications post production).
* Best utilized to determine the need and extent for further assessment (testing) activities (e.g., automated testing, expert testing, code review, etc.).

'''Automated Testing (Application Scanning (Tool Based))''' – Utilizing automated open source or commercial software to discover known application layer vulnerabilities.

''Advantages:''
* Able to quickly identify default content, misconfigurations and error conditions resulting from improper input.
* Ability to be run on automated, regular basis to provide baseline and ongoing vulnerability management metrics.
* Can reduce the time required to assess large applications.
* Lower cost to operate/execute (excluding initial capital cost if using commercial testing software).

''Disadvantages:''
* Not designed to determine the extent to which the vulnerabilities can be exploited to compromise the data the application handles.
* Requires appropriate skills/knowledge to use, configure, and interpret results (despite “point and click” vendor marketing claims).
* Requires extensive configuration and customization to emulate a user session.
* Limited ability to correlate events and correlate minor issues that may lead to larger exposure.
* Inability to adapt to dynamic responses in business logic flows.
* Unable to find vulnerabilities that only become apparent after performing a sequence of steps (e.g., business logic flow bypass, session state compromise, etc.).
* Unable to figure out “how deep the rabbit hole goes” – No means to interpret security implications, express extent of potential compromise, or identify seriousness of business and information exposure.
* Tools will often be confused by some aspect of an application's behavior, causing a particular class of test to generate a false positive. Because most tools lack intelligence and cannot adapt to such conditions, test results include a large number of identical false positives.
** For valid findings, the tools will often find dozens or hundreds of nearly identical findings, each with the same root cause.
* Tool based findings are only indications of problems. Manual review (by someone well versed in web application testing) is usually necessary to draw the necessary parallels between different findings, and determine which findings identify unique problems, and which represent repetition.

Recommended use:
* Handling routine, manually intensive steps (e.g., input validation, field “fuzzing”, etc.) in an assessment is useful, particularly in large applications. However, scanner-based results can be used as the starting point from which expert testing can take over.
* Testing less critical applications (i.e., applications that do not contain/handle business sensitive data and/or are not critical to business operation) where the perceived lower risk does not warrant performing hands-on testing.
* Testing critical applications as a prelude to expert testing or code reviews.

If a tool is used, it is important to define the technical limitations of the tool when the findings are presented. An example of this may involve noting the potential for SQL injection attacks based upon verbose SQL error messages, but also the tool’s inability to produce the correct syntax needed to extract specific information from the vulnerable database. A failure to convey the differences between automated and expert testing increases the risk that the application assessment results will be interpreted (particularly by management) as being more “secure” than they actually are.

'''Expert Testing (Hands On Based)''' – “Expert Testing” involves application analysis performed by an experienced analyst, usually using a combination of open source automated utilities (either self created or through security community) for performing task-specific functions and hands-on analysis to attempt to further ‘hack’ the application as an attacker.

''Advantages:''
* Open source tools utilized by the expert tester are developed usually for specific purposes rather than wrapping multiple functionality into a GUI. Typically are one of many components in the testers toolkit.
* “Expert testing” is an intuitive approach (Business logic analysis), with the ability to identify flaws in business logic that automated scanners are usually incapable of finding.
* Addresses many of the disadvantages noted in Automated Testing.
* Ability to correlate events and minor issues that may lead to larger exposure. This is a critical advantage of hands-on testing and simulates how a real attacker would operate.
* Ability to communicate complex technical findings in a manner that all can understand. The job is not done until the assessment end-client understands the nature of the vulnerability discovered and its security implications.
** The analysis phase of expert testing provides “root cause” identification and recommendations based upon the unique, developmental characteristics of an application. Results from an automated tool cannot provide customized, specific recommendations tailored for each application and the end-client’s requirements.

''Disadvantages:''
* Often confused with Automated Testing – Marketing of commercial tools uses terms such as “expert” and “intuitive”, normally associated with an assessment performed by an experienced analyst.
* Inability of most end-client organizations to determine if tester has appropriate application security skills required. There are no community accepted credentials/certifications established for this area of security.
* Cost to conduct will be higher though there is no upfront capital cost.
* Without establishing clear metrics up front, ongoing testing to determine trends within business environment or iterations of application is difficult.

Recommended use:
* Testing critical applications (i.e., applications that do contain/handle business sensitive data and/or are critical to business operation) where the perceived higher risk does not warrant performing automated testing.
* Best suited for B2B, B2C and/or any transactional based and/or multi-level access application.

'''Application Code Review''' – Reviews the underlying foundational level to identify coding issues, which may create/enable an attacker to compromise an applications systems and/or business functionality. Web applications in particular are likely to have these vulnerabilities, as they are frequently developed quickly in an environment that does not allow for much security planning and testing. This should not be viewed as simply a generic software audit. Code reviews should be specifically tailored to find vulnerabilities common in applications.

''Advantages:''
* If integrated into application SDLC, coding issues can be resolved early in the development and functional testing process. (which is much less expensive to fix than a post-production revision of the code).
* Provides the ability to identify and address serious coding issues (e.g., input validation, hard-coded credentials, debugging features, etc.) prior to production.
* …

''Disadvantages:''
* …
* If conducted solely by tools, results will be mostly static signature matching though some tools claim to walk codepath (follow nested loops and other regression through objects).
* Even applications that exhibit strong and thorough software development practices (e.g., documentation, seamless modularity, string checking to prevent buffer overflows, etc.) can fall victim to attack if the underlying business logic doesn’t follow security requirements.
* Requires specific programming expertise (e.g., Java, .NET, PHP, etc.) that many application testers do not have.

Recommended use:
* …

References/Sources:

* Testing Taxonomy &�Testing Tools Classification : http://www.owasp.org/index.php/Image:AppSec2005DC-Arian_Evans_Tools-Taxonomy.ppt

[[Category:OWASP Application Security Assessment Standards Project]]
{{Template:Stub}}

Category:OWASP Application Security Assessment Standards Project

2006-09-13T17:45:00Z

Cbarlow: /* Current Project Status: */

Currently there is a lack of standardization over what constitutes an application security assessment. With no single set of criteria being referenced, it is suggested that OWASP establish a set of standards defining and establishing a baseline approach to conducting differing types/levels of application security assessment. The standards should be flexible in design to accommodate a range of security assurance levels. The standards should not be viewed as placing requirements on any party. Rather, the standards should make recommendations about what should be done to be consistent with what the OWASP community believes is best practice. Adhering to the standards should help increase end user organization confidence that assessments meet an industry agreed-upon approach.

== Objective ==

The Project’s primary objective is to establish common, consistent methods for application security assessments standards that organizations can use as guidance on what tasks should be completed, how the tasks should be completed, who should be involved and what level of assessment is appropriate based on business requirements. The following are seen as key tasks in order to meet this objective:

* Where practical, attempt to “standardize” nomenclature and definitions for common business application types.

* Where practical, attempt to “standardize” nomenclature and definitions of the differing security assessment types.

* Define standard application assessment process in SWIM flow chart.

* Define standard assessment scope per application type.

* Define standard testing boundaries for application assessments.

* Define what is needed on business end to prepare for application assessment.

* Establish where in SDLC should assessment steps be defined/conducted.

* Where practical, attempt to “standardize” skills nomenclature and establish baseline assessor qualifications and evaluation criteria.

* Establish a common set of application assessment levels:

** Define degree of assessment depth per level
** Define testing components required per level
** Establish level of tool usage/type vs. hands on assessment per level
** Establish linkages between level results and security metrics derived
** Establish linkages between levels and Security Maturity Models

* Establish guidance parameters to allow organizations to determine appropriate assessment level based on business application to be assessed.

* Document integration/linkages to other OWASP projects.

This project will not define how to technically to conduct an assessment (refer to OWASP Testing Project); it is instead meant to tie business operations and information management practices to application security in order to establish a common, consistent set of standards which provide guidance in conducting such assessments.

== Current Project Status: ==

'''Phase I – Project Approach:'''

* Minimal feedback obtained. Contributors jumped in.

'''Phase II - Definitions:'''

* Define Common Business Application Types – '''Stub Started - Need Input.'''
* Define Security Assessment Types – '''Stub Started - Need Input.'''

'''Phase III – Assessment Context:'''

* Define Standard Application Assessment Process – Need Stub
* Define Standard Assessment Scope Per Application Type – Need Stub
* Define Standard Testing Boundaries For Application Assessments – Need Stub
* Define Business End Preparation For Application Assessment – Need Stub
* Establish Where In SDLC Should Assessment Steps Be Defined/Conducted – Need Stub
* Establish Baseline Assessor Qualifications And Evaluation Criteria – '''Stub Started - Need Input.'''

'''Phase IV – Assessment Levels:'''

''[ Suggest Establishment of Definitions and Context prior to commencement ]''

* Establish assessment level system common terminology and decision criteria - Included is analysis of potentially corresponding security measurements (i.e. common security metrics, security assurance/maturity models, related legislation, other standards, etc.).
* Create assessment levels based on previous Phase II and III objectives. Define assessment depth, testing components required, and level of tool usage/type (not product names) of tools used per level.
* Document corresponding linkages between assessment levels and common security metrics, security assurance/maturity models, related legislation, other documented national standards defined as component of first Phase III objective.
* Establish guidance parameters to allow organizations to determine appropriate assessment level based on business application to be assessed.

Also refer to project Roadmap.

== Feedback and Participation ==

We hope you find the OWASP Application Security Assessment Standards Project useful. Please contribute back to the project by sending your comments, questions, and suggestions to owasp@owasp.org. To join the OWASP Assessment Standards mailing list or view the archives, please visit the subscription page.

== Project Contributers ==

The Assessment Standards project lead is Cliff Barlow of KoreLogic Security. He can be reached at cbarlow@korelogic.com.

Key contributors:

* Bob Austin, KoreLogic Security

* Jeff Williams, Aspect Security

* Vinay Bansal, Cisco Systems

* Imre Kertesz, KoreLogic Security

== Project Sponsors ==

The OWASP Application Security Assessment Standards Project is sponsored by: [[Image:Kore_Logo.jpg]][http://www.korelogic.com]

[[Category:OWASP Project]]

Category:OWASP Application Security Assessment Standards Project

2006-09-13T17:32:27Z

Cbarlow: /* Current Project Status: */

Currently there is a lack of standardization over what constitutes an application security assessment. With no single set of criteria being referenced, it is suggested that OWASP establish a set of standards defining and establishing a baseline approach to conducting differing types/levels of application security assessment. The standards should be flexible in design to accommodate a range of security assurance levels. The standards should not be viewed as placing requirements on any party. Rather, the standards should make recommendations about what should be done to be consistent with what the OWASP community believes is best practice. Adhering to the standards should help increase end user organization confidence that assessments meet an industry agreed-upon approach.

== Objective ==

The Project’s primary objective is to establish common, consistent methods for application security assessments standards that organizations can use as guidance on what tasks should be completed, how the tasks should be completed, who should be involved and what level of assessment is appropriate based on business requirements. The following are seen as key tasks in order to meet this objective:

* Where practical, attempt to “standardize” nomenclature and definitions for common business application types.

* Where practical, attempt to “standardize” nomenclature and definitions of the differing security assessment types.

* Define standard application assessment process in SWIM flow chart.

* Define standard assessment scope per application type.

* Define standard testing boundaries for application assessments.

* Define what is needed on business end to prepare for application assessment.

* Establish where in SDLC should assessment steps be defined/conducted.

* Where practical, attempt to “standardize” skills nomenclature and establish baseline assessor qualifications and evaluation criteria.

* Establish a common set of application assessment levels:

** Define degree of assessment depth per level
** Define testing components required per level
** Establish level of tool usage/type vs. hands on assessment per level
** Establish linkages between level results and security metrics derived
** Establish linkages between levels and Security Maturity Models

* Establish guidance parameters to allow organizations to determine appropriate assessment level based on business application to be assessed.

* Document integration/linkages to other OWASP projects.

This project will not define how to technically to conduct an assessment (refer to OWASP Testing Project); it is instead meant to tie business operations and information management practices to application security in order to establish a common, consistent set of standards which provide guidance in conducting such assessments.

== Current Project Status: ==

'''Phase I – Project Approach:'''

* Minimal feedback obtained. Contributors jumped in.

'''Phase II - Definitions:'''

* Define Common Business Application Types – '''Stub Started - Need Input.'''
* Define Security Assessment Types – '''Stub Started - Need Input.'''

'''Phase III – Assessment Context:'''

* Define Standard Application Assessment Process – Need Stub
* Define Standard Assessment Scope Per Application Type – Need Stub
* Define Standard Testing Boundaries For Application Assessments – Need Stub
* Define Business End Preparation For Application Assessment – Need Stub
* Establish Where In SDLC Should Assessment Steps Be Defined/Conducted – Need Stub
* Establish Baseline Assessor Qualifications And Evaluation Criteria – '''Stub Started - Need Input.'''

Also refer to project Roadmap.

== Feedback and Participation ==

We hope you find the OWASP Application Security Assessment Standards Project useful. Please contribute back to the project by sending your comments, questions, and suggestions to owasp@owasp.org. To join the OWASP Assessment Standards mailing list or view the archives, please visit the subscription page.

== Project Contributers ==

The Assessment Standards project lead is Cliff Barlow of KoreLogic Security. He can be reached at cbarlow@korelogic.com.

Key contributors:

* Bob Austin, KoreLogic Security

* Jeff Williams, Aspect Security

* Vinay Bansal, Cisco Systems

* Imre Kertesz, KoreLogic Security

== Project Sponsors ==

The OWASP Application Security Assessment Standards Project is sponsored by: [[Image:Kore_Logo.jpg]][http://www.korelogic.com]

[[Category:OWASP Project]]

Baseline Assessor Qual and Eval Criteria

2006-09-13T17:30:54Z

Cbarlow:

This project article’s focus is to establish common set of assessor qualifications and evaluation criteria to facilitate end service user ability to determine competence per assessment type. Agreement and establishment of these qualifications and criteria are foundational to establishing the Assessment Levels later within this project.

== Baseline Assessor Qualifications for Expert Testing ==

Prior to hiring a firm or before hiring internally, verify and ensure on individual basis each Assessor has the following skills:
* 4+ years of technical security experience with multiple computer platforms, operating systems, software products, network protocols and system architecture.
* Knowledge of security architecture methodologies, industry best practices and generally accepted information security principles.
* Demonstrated ability to secure (lock-down/harden) underlying operating systems and web services such as IIS or Apache – Thus inverse ability to break into insecure systems.
* Demonstrated experience in designing and integrating security services (authentication, authorization, encryption, integrity, and non-repudiation) into systems and/or applications.
** Demonstrated ability to recognize MD5 from Base64 from an encrypted value visually. (Example to demonstrate depth of knowledge in encryption)
* Demonstrated experience in conducting vulnerability assessments and penetration testing – Seen as foundational skills to application level testing.
** Demonstrated evidence of vulnerability discoveries (new undiscovered vulnerability).
** Demonstrated ability to interpret a generated report from vulnerability scanners and quickly recognize potential false positives.
** Able to demonstrate any exploit used during a test if requested by a client.
* Solid understanding and experience in Web application and Internet security.
* Solid, in-depth understanding of all Internet and Web protocols.
* Full understanding of major HTML directives and code.
* Knowledge of Service Oriented Architectures (SOA) and SOAP if applicable to environment.
* Demonstrated ability to reverse engineer a transactional web application.
* Produces own security tools known in reputable security circles. Ability to shell code to automate custom tests.
* Demonstrated use of testing methodologies defined in OWASP Testing Project – Ask for specific testing process used for three or more testing areas.
* Demonstrated ability to create and follow a project specific well documented test plan.
* Programming / web services development experience a benefit. However, not all programmers make good security testers (it’s a mindset thing).
* Demonstrated ability to formulate written technical material in a clear and effective manner – Ask for writing sample.

Assessors identify and exploit security weaknesses, evaluate counter-measures and conduct analysis to determine potential security impacts to business. More so, the assessor must demonstrate ability to take assessment data and formulate security technical solutions.

The following education and/or certifications are helpful and increase the viability of the Assessor (establishes their business foundation skills thus ability to link technical results to business impact) but should not be taken as sole means for evaluating.
* Undergraduate degree in Computer Science, Information Systems, Engineering, or related discipline
* CISSP or CCNA or GIAC certifications

'''Evaluation Criteria'''

The following matrix is intended to summarize the skills required per assessment level.

''…[To Be Developed After Assessment Levels Established]''

[[Category:OWASP Application Security Assessment Standards Project]]
{{Template:Stub}}

Category:OWASP Application Security Assessment Standards Project

2006-09-13T17:26:03Z

Cbarlow: /* Project Contributers */

Currently there is a lack of standardization over what constitutes an application security assessment. With no single set of criteria being referenced, it is suggested that OWASP establish a set of standards defining and establishing a baseline approach to conducting differing types/levels of application security assessment. The standards should be flexible in design to accommodate a range of security assurance levels. The standards should not be viewed as placing requirements on any party. Rather, the standards should make recommendations about what should be done to be consistent with what the OWASP community believes is best practice. Adhering to the standards should help increase end user organization confidence that assessments meet an industry agreed-upon approach.

== Objective ==

The Project’s primary objective is to establish common, consistent methods for application security assessments standards that organizations can use as guidance on what tasks should be completed, how the tasks should be completed, who should be involved and what level of assessment is appropriate based on business requirements. The following are seen as key tasks in order to meet this objective:

* Where practical, attempt to “standardize” nomenclature and definitions for common business application types.

* Where practical, attempt to “standardize” nomenclature and definitions of the differing security assessment types.

* Define standard application assessment process in SWIM flow chart.

* Define standard assessment scope per application type.

* Define standard testing boundaries for application assessments.

* Define what is needed on business end to prepare for application assessment.

* Establish where in SDLC should assessment steps be defined/conducted.

* Where practical, attempt to “standardize” skills nomenclature and establish baseline assessor qualifications and evaluation criteria.

* Establish a common set of application assessment levels:

** Define degree of assessment depth per level
** Define testing components required per level
** Establish level of tool usage/type vs. hands on assessment per level
** Establish linkages between level results and security metrics derived
** Establish linkages between levels and Security Maturity Models

* Establish guidance parameters to allow organizations to determine appropriate assessment level based on business application to be assessed.

* Document integration/linkages to other OWASP projects.

This project will not define how to technically to conduct an assessment (refer to OWASP Testing Project); it is instead meant to tie business operations and information management practices to application security in order to establish a common, consistent set of standards which provide guidance in conducting such assessments.

== Current Project Status: ==

'''Phase I – Project Approach:'''

* Minimal feedback obtained. Contributors jumped in.

'''Phase II - Definitions:'''

* Define Common Business Application Types – Stub Started.
* Define Security Assessment Types – Stub Started.

'''Phase III – Assessment Context:'''

* Define Standard Application Assessment Process – Need Stub
* Define Standard Assessment Scope Per Application Type – Need Stub
* Define Standard Testing Boundaries For Application Assessments – Need Stub
* Define Business End Preparation For Application Assessment – Need Stub
* Establish Where In SDLC Should Assessment Steps Be Defined/Conducted – Need Stub
* Establish Baseline Assessor Qualifications And Evaluation Criteria – Need Stub

Also refer to project Roadmap.

== Feedback and Participation ==

We hope you find the OWASP Application Security Assessment Standards Project useful. Please contribute back to the project by sending your comments, questions, and suggestions to owasp@owasp.org. To join the OWASP Assessment Standards mailing list or view the archives, please visit the subscription page.

== Project Contributers ==

The Assessment Standards project lead is Cliff Barlow of KoreLogic Security. He can be reached at cbarlow@korelogic.com.

Key contributors:

* Bob Austin, KoreLogic Security

* Jeff Williams, Aspect Security

* Vinay Bansal, Cisco Systems

* Imre Kertesz, KoreLogic Security

== Project Sponsors ==

The OWASP Application Security Assessment Standards Project is sponsored by: [[Image:Kore_Logo.jpg]][http://www.korelogic.com]

[[Category:OWASP Project]]

Definition for Security Assessment Techniques

2006-09-13T17:24:08Z

Cbarlow:

This project article’s focus is to define, where practical, nomenclature and definitions of the differing security assessment types. Agreement and establishment of these definitions are foundational to establishing the Assessment Levels later within this project.

== Application Assessment Types - Defined: ==

'''Application Threat Assessment''' – Analyzes application architectural information to develop a threat profile for the application components. Threat assessments:

* Identify the nature of the threats – the likely vulnerabilities of the given application and business.

* Estimate the probability that those vulnerabilities might lead to a disruption and the type of impact – both expected and worst case – that might arise.

* Analyze the different consequences and their likelihood of occurrence and determine which should be dealt with and what priority should be attached to mitigate.

While the threats for each asset within the Application can be individually developed and mapped, a more efficient approach is to develop a master list of threat types and identify how these can be used to launch an attack on the Application and/or its components and potentially in turn the business itself. A single threat may exploit a vulnerability to damage different types of assets. Conversely, several threat types may exploit disparate vulnerabilities in order to attack a single critical asset. Given the many-to-many relationships between threats and assets, it is best to use a simple representation of threat to asset mapping by listing threat types by each critical asset identified.

A threat assessment should categorize threat types and threat agents but should focus on malicious threats and will not cover accidental and natural threats. The source of Malicious Threats (the attacker or perpetrator, in this context) can be classified as unauthorized and authorized. Threat vectors and operating environment more fully define how and why a particular “user” falls into one of these categories:

Unauthorized:
* An attacker who does not have credentials to legitimately access the application

Authorized:
* A legitimate user of the application
* A malicious insider
* A previously unauthorized user who has gained authorized access through compromise of a valid account or user session

While the threat agents may have the similar intent, varying reasons for engaging in illegal activities motivates them. Some authorized employees may willfully commit fraud for financial gain or engage in sabotage in order to disrupt routine operations. Theft, vandalism, intentional corruptions and alteration of information are also categorized as malicious threats.

''Advantages:''
* Aids in focusing testing activities and defining true targets in large scale enterprise level applications.
* By using results from Threat Assessment, the end-client is able to focus assessment (testing) activities based on business requirements and operational reality.
* Allows vulnerabilities discovered in other assessment types to be weighted and prioritized based on threat probability vs. raw vulnerability finding.

''Disadvantages:''
* Cannot guarantee that all possible security threats will be uncovered.
* End-client must evaluate analysis and determine action(s).
* Requires existence of application architecture documentation.
* Often confused with Risk Assessments, which weigh asset value, threat, and vulnerability in order to determine business risk. Threat assessments focus on identifying only the threat component (vector(s) and probability).

Recommended use:
* Best as a precursor to development activities allowing best use of security dollars (i.e., “bake in” security during application development begets higher return on investment vs. “bolting on” application security fixes post production).
* Best utilized to determine the need and extent for further assessment (testing) activities (e.g., automated testing, expert testing, code review, etc.).

'''Application Architecture Review''' – Typically a table-top design level review and analysis of the application to identify critical assets, sensitive data stores and business critical interconnections. The purpose of architecture reviews is to also aid in determining potential attack vectors, which could be used in testing. Thus the reason many organizations will blend this activity with Threat Assessment. The review of the application and their interconnections should include both a network- and application-level evaluation. Evaluation should identify areas of potential and actual vulnerability from these levels. This includes areas of vulnerability in the network and application architecture, in addition to a high-level measure of risk of each of those areas.

''Advantages:''
* Aids in focusing testing activities and defining true targets in large scale enterprise level applications.
* Provides more depth to the development rationale of various functionality in the application life cycle.
* By using results from Architecture Review, the assessment (testing) team is able to follow development logic in the “how” and “why” business and security requirements were integrated into application behavior and security controls/constraints.

''Disadvantages:''
* Cannot guarantee identification of all possible security threats.
* Because the scope of an architectural assessment is far more complex than the limited perspective of an application layer assessment, recommendations are similarly complex, sometimes involving “political” changes (i.e., security department’s level of involvement in the SDLC).
* Requires on-site discussions with application principals.

Recommended use:
* Best as a precursor to development activities allowing best use of security dollars (i.e., incorporate security in beginning begets higher return on investment vs. fixing applications post production).
* Best utilized to determine the need and extent for further assessment (testing) activities (e.g., automated testing, expert testing, code review, etc.).

'''Automated Testing (Application Scanning (Tool Based))''' – Utilizing automated open source or commercial software to discover known application layer vulnerabilities.

''Advantages:''
* Able to quickly identify default content, misconfigurations and error conditions resulting from improper input.
* Ability to be run on automated, regular basis to provide baseline and ongoing vulnerability management metrics.
* Can reduce the time required to assess large applications.
* Lower cost to operate/execute (excluding initial capital cost if using commercial testing software).

''Disadvantages:''
* Not designed to determine the extent to which the vulnerabilities can be exploited to compromise the data the application handles.
* Requires appropriate skills/knowledge to use, configure, and interpret results (despite “point and click” vendor marketing claims).
* Requires extensive configuration and customization to emulate a user session.
* Limited ability to correlate events and correlate minor issues that may lead to larger exposure.
* Inability to adapt to dynamic responses in business logic flows.
* Unable to find vulnerabilities that only become apparent after performing a sequence of steps (e.g., business logic flow bypass, session state compromise, etc.).
* Unable to figure out “how deep the rabbit hole goes” – No means to interpret security implications, express extent of potential compromise, or identify seriousness of business and information exposure.
* Tools will often be confused by some aspect of an application's behavior, causing a particular class of test to generate a false positive. Because most tools lack intelligence and cannot adapt to such conditions, test results include a large number of identical false positives.
** For valid findings, the tools will often find dozens or hundreds of nearly identical findings, each with the same root cause.
* Tool based findings are only indications of problems. Manual review (by someone well versed in web application testing) is usually necessary to draw the necessary parallels between different findings, and determine which findings identify unique problems, and which represent repetition.

Recommended use:
* Handling routine, manually intensive steps (e.g., input validation, field “fuzzing”, etc.) in an assessment is useful, particularly in large applications. However, scanner-based results can be used as the starting point from which expert testing can take over.
* Testing less critical applications (i.e., applications that do not contain/handle business sensitive data and/or are not critical to business operation) where the perceived lower risk does not warrant performing hands-on testing.

If a tool is used, it is important to define the technical limitations of the tool when the findings are presented. An example of this may involve noting the potential for SQL injection attacks based upon verbose SQL error messages, but also the tool’s inability to produce the correct syntax needed to extract specific information from the vulnerable database. A failure to convey the differences between automated and expert testing increases the risk that the application assessment results will be interpreted as being more “secure” than they actually are.

'''Expert Testing (Hands On Based)''' – “Expert Testing” involves application analysis performed by an experienced analyst, usually using a combination of open source automated utilities (either self created or through security community) for performing task-specific functions and hands-on analysis to attempt to further ‘hack’ the application as an attacker.

''Advantages:''
* Open source tools utilized by the expert tester are developed usually for specific purposes rather than wrapping multiple functionality into a GUI. Typically are one of many components in the testers toolkit.
* “Expert testing” is an intuitive approach (Business logic analysis), with the ability to identify flaws in business logic that automated scanners are usually incapable of finding.
* Addresses many of the disadvantages noted in Automated Testing.
* Ability to correlate events and minor issues that may lead to larger exposure. This is a critical advantage of hands-on testing and simulates how a real attacker would operate.
* Ability to communicate complex technical findings in a manner that all can understand. The job is not done until the assessment end-client understands the nature of the vulnerability discovered and its security implications.
** The analysis phase of expert testing provides “root cause” identification and recommendations based upon the unique, developmental characteristics of an application. Results from an automated tool cannot provide customized, specific recommendations tailored for each application and the end-client’s requirements.

''Disadvantages:''
* Often confused with Automated Testing – Marketing of commercial tools uses terms such as “expert” and “intuitive”, normally associated with an assessment performed by an experienced analyst.
* Inability of most end-client organizations to determine if tester has appropriate application security skills required. There are no community accepted credentials/certifications established for this area of security.
* Cost to conduct will be higher though there is no upfront capital cost.
* Without establishing clear metrics up front, ongoing testing to determine trends within business environment or iterations of application is difficult.

Recommended use:
* Testing critical applications (i.e., applications that do contain/handle business sensitive data and/or are critical to business operation) where the perceived higher risk does not warrant performing automated testing.
* Best suited for B2B, B2C and/or any transactional based and/or multi-level access application.

'''Application Code Review''' – Reviews the underlying foundational level to identify coding issues, which may create/enable an attacker to compromise an applications systems and/or business functionality. Web applications in particular are likely to have these vulnerabilities, as they are frequently developed quickly in an environment that does not allow for much security planning and testing. This should not be viewed as simply a generic software audit. Code reviews should be specifically tailored to find vulnerabilities common in applications.

''Advantages:''
* If integrated into application SDLC, coding issues can be resolved early in the development and functional testing process. (which is much less expensive to fix than a post-production revision of the code).
* Provides the ability to identify and address serious coding issues (e.g., input validation, hard-coded credentials, debugging features, etc.) prior to production.
* …

''Disadvantages:''
* …
* If conducted solely by tools, results will be mostly static signature matching though some tools claim to walk codepath (follow nested loops and other regression through objects).
* Even applications that exhibit strong and thorough software development practices (e.g., documentation, seamless modularity, string checking to prevent buffer overflows, etc.) can fall victim to attack if the underlying business logic doesn’t follow security requirements.
* Requires specific programming expertise (e.g., Java, .NET, PHP, etc.) that many application testers do not have.

Recommended use:
* …

References/Sources:

* Testing Taxonomy &�Testing Tools Classification : http://www.owasp.org/index.php/Image:AppSec2005DC-Arian_Evans_Tools-Taxonomy.ppt

[[Category:OWASP Application Security Assessment Standards Project]]
{{Template:Stub}}

Category:OWASP Application Security Assessment Standards Project

2006-08-22T14:51:23Z

Cbarlow: /* Current Project Status: */

Currently there is a lack of standardization over what constitutes an application security assessment. With no single set of criteria being referenced, it is suggested that OWASP establish a set of standards defining and establishing a baseline approach to conducting differing types/levels of application security assessment. The standards should be flexible in design to accommodate a range of security assurance levels. The standards should not be viewed as placing requirements on any party. Rather, the standards should make recommendations about what should be done to be consistent with what the OWASP community believes is best practice. Adhering to the standards should help increase end user organization confidence that assessments meet an industry agreed-upon approach.

== Objective ==

The Project’s primary objective is to establish common, consistent methods for application security assessments standards that organizations can use as guidance on what tasks should be completed, how the tasks should be completed, who should be involved and what level of assessment is appropriate based on business requirements. The following are seen as key tasks in order to meet this objective:

* Where practical, attempt to “standardize” nomenclature and definitions for common business application types.

* Where practical, attempt to “standardize” nomenclature and definitions of the differing security assessment types.

* Define standard application assessment process in SWIM flow chart.

* Define standard assessment scope per application type.

* Define standard testing boundaries for application assessments.

* Define what is needed on business end to prepare for application assessment.

* Establish where in SDLC should assessment steps be defined/conducted.

* Where practical, attempt to “standardize” skills nomenclature and establish baseline assessor qualifications and evaluation criteria.

* Establish a common set of application assessment levels:

** Define degree of assessment depth per level
** Define testing components required per level
** Establish level of tool usage/type vs. hands on assessment per level
** Establish linkages between level results and security metrics derived
** Establish linkages between levels and Security Maturity Models

* Establish guidance parameters to allow organizations to determine appropriate assessment level based on business application to be assessed.

* Document integration/linkages to other OWASP projects.

This project will not define how to technically to conduct an assessment (refer to OWASP Testing Project); it is instead meant to tie business operations and information management practices to application security in order to establish a common, consistent set of standards which provide guidance in conducting such assessments.

== Current Project Status: ==

'''Phase I – Project Approach:'''

* Minimal feedback obtained. Contributors jumped in.

'''Phase II - Definitions:'''

* Define Common Business Application Types – Stub Started.
* Define Security Assessment Types – Stub Started.

'''Phase III – Assessment Context:'''

* Define Standard Application Assessment Process – Need Stub
* Define Standard Assessment Scope Per Application Type – Need Stub
* Define Standard Testing Boundaries For Application Assessments – Need Stub
* Define Business End Preparation For Application Assessment – Need Stub
* Establish Where In SDLC Should Assessment Steps Be Defined/Conducted – Need Stub
* Establish Baseline Assessor Qualifications And Evaluation Criteria – Need Stub

Also refer to project Roadmap.

== Feedback and Participation ==

We hope you find the OWASP Application Security Assessment Standards Project useful. Please contribute back to the project by sending your comments, questions, and suggestions to owasp@owasp.org. To join the OWASP Assessment Standards mailing list or view the archives, please visit the subscription page.

== Project Contributers ==

The Assessment Standards project lead is Cliff Barlow of KoreLogic Security. He can be reached at cbarlow@korelogic.com.

Key contributors:

* Bob Austin, KoreLogic Security

* Jeff Williams, Aspect Security

* Vinay Bansal, Cisco Systems

== Project Sponsors ==

The OWASP Application Security Assessment Standards Project is sponsored by: [[Image:Kore_Logo.jpg]][http://www.korelogic.com]

[[Category:OWASP Project]]

Definition for Security Assessment Techniques

2006-08-22T14:50:51Z

Cbarlow:

This articles focus is to define, where practical, nomenclature and definitions of the differing security assessment types.

== Assessment Type Categories - Defined: ==

'''Application Scanning (Tool Based)''' – (Definition)

'''Hands On Based Application Testing''' – (Definition)

'''Application Code Review''' – (Definition)

'''?''' – (Definition)

[[Category:OWASP Application Security Assessment Standards Project]]
{{Template:Stub}}

Definition for Security Assessment Techniques

2006-08-22T14:49:28Z

Cbarlow:

This articles focus is to define, where practical, nomenclature and definitions of the differing security assessment types.

== Assessment Type Categories - Defined: ==

'''Application Scanning (Tool Based)''' –

'''Hands On Based Application Testing''' –

'''Application Code Review''' –

'''?''' –

[[Category:OWASP Application Security Assessment Standards Project]]
{{Template:Stub}}

Category:OWASP Application Security Assessment Standards Project

2006-08-22T14:41:22Z

Cbarlow:

Currently there is a lack of standardization over what constitutes an application security assessment. With no single set of criteria being referenced, it is suggested that OWASP establish a set of standards defining and establishing a baseline approach to conducting differing types/levels of application security assessment. The standards should be flexible in design to accommodate a range of security assurance levels. The standards should not be viewed as placing requirements on any party. Rather, the standards should make recommendations about what should be done to be consistent with what the OWASP community believes is best practice. Adhering to the standards should help increase end user organization confidence that assessments meet an industry agreed-upon approach.

== Objective ==

The Project’s primary objective is to establish common, consistent methods for application security assessments standards that organizations can use as guidance on what tasks should be completed, how the tasks should be completed, who should be involved and what level of assessment is appropriate based on business requirements. The following are seen as key tasks in order to meet this objective:

* Where practical, attempt to “standardize” nomenclature and definitions for common business application types.

* Where practical, attempt to “standardize” nomenclature and definitions of the differing security assessment types.

* Define standard application assessment process in SWIM flow chart.

* Define standard assessment scope per application type.

* Define standard testing boundaries for application assessments.

* Define what is needed on business end to prepare for application assessment.

* Establish where in SDLC should assessment steps be defined/conducted.

* Where practical, attempt to “standardize” skills nomenclature and establish baseline assessor qualifications and evaluation criteria.

* Establish a common set of application assessment levels:

** Define degree of assessment depth per level
** Define testing components required per level
** Establish level of tool usage/type vs. hands on assessment per level
** Establish linkages between level results and security metrics derived
** Establish linkages between levels and Security Maturity Models

* Establish guidance parameters to allow organizations to determine appropriate assessment level based on business application to be assessed.

* Document integration/linkages to other OWASP projects.

This project will not define how to technically to conduct an assessment (refer to OWASP Testing Project); it is instead meant to tie business operations and information management practices to application security in order to establish a common, consistent set of standards which provide guidance in conducting such assessments.

== Current Project Status: ==

'''Phase I – Project Approach:'''

* Minimal feedback obtained. Contributors jumped in.

'''Phase II - Definitions:'''

* Define Common Business Application Types – Stub Started.
* Define Security Assessment Types – Need Stub.

'''Phase III – Assessment Context:'''

* Define Standard Application Assessment Process – Need Stub
* Define Standard Assessment Scope Per Application Type – Need Stub
* Define Standard Testing Boundaries For Application Assessments – Need Stub
* Define Business End Preparation For Application Assessment – Need Stub
* Establish Where In SDLC Should Assessment Steps Be Defined/Conducted – Need Stub
* Establish Baseline Assessor Qualifications And Evaluation Criteria – Need Stub

Also refer to project Roadmap.

== Feedback and Participation ==

We hope you find the OWASP Application Security Assessment Standards Project useful. Please contribute back to the project by sending your comments, questions, and suggestions to owasp@owasp.org. To join the OWASP Assessment Standards mailing list or view the archives, please visit the subscription page.

== Project Contributers ==

The Assessment Standards project lead is Cliff Barlow of KoreLogic Security. He can be reached at cbarlow@korelogic.com.

Key contributors:

* Bob Austin, KoreLogic Security

* Jeff Williams, Aspect Security

* Vinay Bansal, Cisco Systems

== Project Sponsors ==

The OWASP Application Security Assessment Standards Project is sponsored by: [[Image:Kore_Logo.jpg]][http://www.korelogic.com]

[[Category:OWASP Project]]

Category:OWASP Application Security Metrics Project

2006-08-22T14:25:57Z

Cbarlow:

== Welcome to the Application Security Metrics Security Project ==

This OWASP Project will first identify and provide the OWASP community a set of application security metrics that have been found by contributors to be effective in measuring application security. This will be followed by the development of new metrics that build on the initial metrics foundation to fulfill unmet metrics requirements.
The goals of this Project are to make a baseline set of application security metrics available to the OWASP community and subsequently to provide a forum for the community to contribute metrics back into the baseline.

== Project Guiding Principles: ==

The Application Security Metrics Security Project Project’s Guiding Principles were created in order to express the intentions of its contributors when designing application security metrics.

* Effective security metrics have proven to be challenging to develop. As such, provide a means for the OWASP community to initially leverage what others have developed and find useful (i.e., provide the OWASP community useful metrics in use today).

* Where practical, attempt to “standardize” nomenclature with other security metrics initiatives such as securitymetrics.org, Systems Security Engineering Capability Maturity Model (SSE-CMM), etc.

* In selecting best practice metrics, make use of high-level filters. For example, use Dr. Dan Geer’s decision support mantra regarding security metrics: “How would that proposed measure advance appropriate decision making?"

* Link each metric to the business driver for the metric (e.g., Metric “X” helps support regulatory compliance and risk management objectives.”

Comments to the editor or endorsements are welcome.

== Project Scope: ==

In keeping with OWASP’s mission, this project will focus primarily on application security metrics.

== Feedback and Participation: ==

We hope you find the OWASP Application Security Metrics Project useful. Please contribute to the Project by volunteering for one of the Tasks, sending your comments, questions, and suggestions to owasp@owasp.org. To join the OWASP Application Security Metrics Project mailing list or view the archives, please visit the subscription page.

== Project Contributors: ==

If you contribute to this Project, please add your name here
Project Lead:

* Bob Austin of KoreLogic Security. He can be reached at austinb@korelogic.com.

Contributors:

* Cliff Barlow, KoreLogic Security

[[Category:OWASP Project]]

Category:OWASP Application Security Metrics Project Roadmap

2006-08-22T14:23:59Z

Cbarlow: /* DETAILED PHASE ONE TASKS */

Subject to Contributor feedback, the following Roadmap is proposed. Phase One tasks are more specifically defined. Phase Two tasks will be developed and defined over time based on Phase One experience.

== Proposed Project Phases: ==

'''Phase One - Collect and Provide Proven Metrics'''

The objective is to provide useful current state metrics to the OWASP community in the near-term.

'''Phase Two - Develop “Next Generation” metrics'''

Develop new metrics using Contributor feedback on Phase One metrics and metrics that organizations have asked for but do not currently exist.

== Summary of Proposed Phase One Tasks ==

* Comment Period for Proposed Project Approach, Solicit Contributor Support
* Develop Metric Collection Survey Instrument
* Solicit Organizational Participants
* Conduct Metric Collection Survey
* Organize and Analyze Collected Survey Data
* Prepare Draft Findings and Provide to Reviewers
* Comment Period for Published Draft Findings
* Publish Final Findings, Metrics and Resources
* Conduct Phase One Project Post-Mortem

== Detailed Phase One Tasks ==

'''Task 1 – Comment Period for Proposed Project Approach'''

Solicit Contributor feedback to ensure the most effective and widely supported approach.

Target Time Frame: Complete by August 1st, 2006
Current Status: Call for Contributors

'''Task 2 – Develop Metric Collection Survey Instrument'''

Develop a survey instrument that can be used by Contributors to gather metrics data in a uniform fashion. Design considerations will include “organizational” demographic data required (e.g., industry vertical), the format of the metric description, etc. Ideally, we can categorize the metric types using a standard nomenclature. The final survey instrument will be based on the 80/20 principle – developing the “perfect” instrument will excessively delay the Project. Contributor support in developing a survey form that will allow efficient data aggregation and analysis would be appreciated (or at least ideas how this could be accomplished).

Target Time Frame: Complete by August 15, 2006
Current Status: Call for Volunteers
Contributors: Bob Austin

'''Task 3– Solicit Organizational Participants'''

Contributors will be asked to approach organizations that are known to have effective metrics in use and request their (anonymous) participation in the survey. It may be wise to limit the number of organizations participating in the survey to 30 or so organizations. One incentive to participate is the sharing of current “best practice” metrics. From a confidentiality perspective, each Contributor would ensure that data provided by an organization is sanitized to ensure anonymity.

Target Time Frame: Complete by August 15, 2006
Current Status: Call for Volunteers

'''Task 4 – Conduct Metric Collection Survey'''

Using the survey instrument, collect survey data. It may be wise to conduct a “pilot” survey with 1 or 2 organizations, make fine-tuning adjustments to the survey instrument, and then complete the surveys.

Target Time Frame: Complete by September 15, 2006 (this date is particularly dependent upon Contributor support)
Current Status: Call for Volunteers

'''Task 5 – Organize and Analyze Collected Survey Data'''

This will involve merging and organizing the collected data to allow effective analysis and presentation of the data.

Target Time Frame:
Current Status: Call for Volunteers

'''Task 6 – Prepare Draft Findings and Provide to Reviewers'''

We envision capturing a number of key data points including a description of metrics used, consumers of the metrics, length of time used, barriers to metric collection, metrics needed, planned metrics initiatives, useful tools/resources that facilitate metrics collection/analysis, etc. We also will attempt to provide insight into management’s interest and support for the metrics program.

Target Time Frame:
Current Status: Call for Volunteers

'''Task 7 – Comment Period for Published Draft Findings'''

Solicit feedback from the OWASP community, address errors/ambiguity. Make edits based on feedback.

Target Time Frame:
Current Status: Call for Volunteers

'''Task 8 – Publish Final Findings, Metrics, and Resources'''

Self-explanatory. Ideally, present the metrics in a way that Contributors can continue to add to and comment on over time. Create a Resources Page that incorporates the resources recommended by survey participants.

Target Time Frame:
Current Status: Call for Volunteers

'''Task 9 – Conduct Phase One Project Post-Mortem'''

Solicit feedback and lessons learned on Phase One to improve Phase Two approach.

Target Time Frame:
Current Status: Call for Volunteers

[[Category:OWASP Application Security Metrics Project]]

Category:OWASP Application Security Metrics Project Roadmap

2006-08-22T14:23:09Z

Cbarlow:

Subject to Contributor feedback, the following Roadmap is proposed. Phase One tasks are more specifically defined. Phase Two tasks will be developed and defined over time based on Phase One experience.

== Proposed Project Phases: ==

'''Phase One - Collect and Provide Proven Metrics'''

The objective is to provide useful current state metrics to the OWASP community in the near-term.

'''Phase Two - Develop “Next Generation” metrics'''

Develop new metrics using Contributor feedback on Phase One metrics and metrics that organizations have asked for but do not currently exist.

== Summary of Proposed Phase One Tasks ==

* Comment Period for Proposed Project Approach, Solicit Contributor Support
* Develop Metric Collection Survey Instrument
* Solicit Organizational Participants
* Conduct Metric Collection Survey
* Organize and Analyze Collected Survey Data
* Prepare Draft Findings and Provide to Reviewers
* Comment Period for Published Draft Findings
* Publish Final Findings, Metrics and Resources
* Conduct Phase One Project Post-Mortem

== DETAILED PHASE ONE TASKS ==

'''Task 1 – Comment Period for Proposed Project Approach'''

Solicit Contributor feedback to ensure the most effective and widely supported approach.

Target Time Frame: Complete by August 1st, 2006
Current Status: Call for Contributors

'''Task 2 – Develop Metric Collection Survey Instrument'''

Develop a survey instrument that can be used by Contributors to gather metrics data in a uniform fashion. Design considerations will include “organizational” demographic data required (e.g., industry vertical), the format of the metric description, etc. Ideally, we can categorize the metric types using a standard nomenclature. The final survey instrument will be based on the 80/20 principle – developing the “perfect” instrument will excessively delay the Project. Contributor support in developing a survey form that will allow efficient data aggregation and analysis would be appreciated (or at least ideas how this could be accomplished).

Target Time Frame: Complete by August 15, 2006
Current Status: Call for Volunteers
Contributors: Bob Austin

'''Task 3– Solicit Organizational Participants'''

Contributors will be asked to approach organizations that are known to have effective metrics in use and request their (anonymous) participation in the survey. It may be wise to limit the number of organizations participating in the survey to 30 or so organizations. One incentive to participate is the sharing of current “best practice” metrics. From a confidentiality perspective, each Contributor would ensure that data provided by an organization is sanitized to ensure anonymity.

Target Time Frame: Complete by August 15, 2006
Current Status: Call for Volunteers

'''Task 4 – Conduct Metric Collection Survey'''

Using the survey instrument, collect survey data. It may be wise to conduct a “pilot” survey with 1 or 2 organizations, make fine-tuning adjustments to the survey instrument, and then complete the surveys.

Target Time Frame: Complete by September 15, 2006 (this date is particularly dependent upon Contributor support)
Current Status: Call for Volunteers

'''Task 5 – Organize and Analyze Collected Survey Data'''

This will involve merging and organizing the collected data to allow effective analysis and presentation of the data.

Target Time Frame:
Current Status: Call for Volunteers

'''Task 6 – Prepare Draft Findings and Provide to Reviewers'''

We envision capturing a number of key data points including a description of metrics used, consumers of the metrics, length of time used, barriers to metric collection, metrics needed, planned metrics initiatives, useful tools/resources that facilitate metrics collection/analysis, etc. We also will attempt to provide insight into management’s interest and support for the metrics program.

Target Time Frame:
Current Status: Call for Volunteers

'''Task 7 – Comment Period for Published Draft Findings'''

Solicit feedback from the OWASP community, address errors/ambiguity. Make edits based on feedback.

Target Time Frame:
Current Status: Call for Volunteers

'''Task 8 – Publish Final Findings, Metrics, and Resources'''

Self-explanatory. Ideally, present the metrics in a way that Contributors can continue to add to and comment on over time. Create a Resources Page that incorporates the resources recommended by survey participants.

Target Time Frame:
Current Status: Call for Volunteers

'''Task 9 – Conduct Phase One Project Post-Mortem'''

Solicit feedback and lessons learned on Phase One to improve Phase Two approach.

Target Time Frame:
Current Status: Call for Volunteers

[[Category:OWASP Application Security Metrics Project]]

Category:OWASP Project

2006-08-22T13:53:01Z

Cbarlow: /* Project descriptions */

An OWASP project is a collection of related tasks that have a defined roadmap and team members. OWASP project leaders are responsible for defining the vision, roadmap, and tasks for the project. The project leader also promotes the project and builds the team.

==Proposing a new project==

To propose a new project, please send an email to owasp@owasp.org. Each project should have a roadmap page that details the current set of tasks and rough schedule. The page should be named "OWASP XXX Project Roadmap"

==Project descriptions==

* [[:Category:OWASP AJAX Security Project|OWASP AJAX Security Project]] - investigating the security of AJAX enabled applications
* [[:Category:OWASP Application Security Assessment Standards Project|OWASP Application Security Assessment Standards Project]] - establish a set of standards defining baseline approaches to conducting differing types/levels of application security assessment
* [[:Category:OWASP Application Security Metrics Project|OWASP Application Security Metrics Project]] - identify and provide a set of application security metrics that have been found by contributors to be effective in measuring application security
* [[:Category:OWASP AppSec FAQ Project|OWASP AppSec FAQ Project]] - an FAQ covering many application security topics
* [[:Category:OWASP CAL9000 Project|OWASP CAL9000 Project]] - a JavaScript based web application security testing suite
* [[:Category:OWASP CLASP Project|OWASP CLASP Project]] - a project focused on defining process elements that reinforce application security
* [[:Category:OWASP Code Review Project|OWASP Code Review Project]] - a new project to capture best practices for reviewing code
* [[:Category:OWASP Guide Project|OWASP Guide Project]] - a massive document covering all aspects of web application and web service security
* [[:Category:OWASP Honeycomb Project|OWASP Honeycomb Project]] - a comprehensive and integrated guide to the fundamental building blocks of application security
* [[:Category:OWASP Legal Project|OWASP Legal Project]] - a project focused on contracting for secure software
* [[:Category:OWASP Logging Project|OWASP Logging Project]] - a project to define best practices for logging and log management
* [[:Category:OWASP Metrics Project|OWASP Metrics Project]] - a project to define workable application security metrics
* [[:Category:OWASP .NET Project|OWASP .NET Project]] - a project focused on helping .NET developers build secure applications
* [[:Category:OWASP Pantera Web Assessment Studio Project|OWASP Pantera Web Assessment Studio Project]] - a project focused on combining automated capabilities with complete manual testing to get the best results
* [[:Category:OWASP PHP Project|OWASP PHP Project]] - a project focused on helping PHP developers build secure applications
* [[:Category:OWASP Java Project|OWASP Java Project]] - a project focused on helping Java and J2EE developers build secure applications
* [[:Category:OWASP Risk Management Project|OWASP Risk Management Project]] - a new project focused on processes for managing application security risk
* [[:Category:OWASP Testing Project|OWASP Testing Project]] - a project focused on application security testing procedures and checklists
* [[:Category:OWASP Top Ten Project|OWASP Top Ten Project]] - an awareness document that describes the top ten web application security vulnerabilities
* [[:Category:OWASP Validation Project|OWASP Validation Project]] - a project that provides guidance and tools related to validation.
* [[:Category:OWASP WASS Project|OWASP WASS Project]] - a standards project to develop more concrete criteria for secure applications
* [[:Category:OWASP WebGoat Project|OWASP WebGoat Project]] - an online training environment for hands-on learning about application security
* [[:Category:OWASP WebScarab Project|OWASP WebScarab Project]] - a tool for performing all types of security testing on web applications and web services

[[OWASP Project Mailing Lists]]

Category:OWASP Application Security Metrics Project

2006-08-22T13:48:03Z

Cbarlow:

Category:OWASP Application Security Metrics Project

2006-08-22T13:41:21Z

Cbarlow:

OWASP Application Security Metrics Project

Category:OWASP Application Security Assessment Standards Project

2006-07-24T16:41:52Z

Cbarlow:

File:Kore Logo.jpg

2006-07-24T16:36:32Z

Cbarlow:

Category:OWASP Application Security Assessment Standards Project

2006-07-24T16:33:56Z

Cbarlow:

Category:OWASP Project

2006-07-24T16:26:36Z

Cbarlow: /* Project descriptions */

An OWASP project is a collection of related tasks that have a defined roadmap and team members. OWASP project leaders are responsible for defining the vision, roadmap, and tasks for the project. The project leader also promotes the project and builds the team.

==Proposing a new project==

To propose a new project, please send an email to owasp@owasp.org. Each project should have a roadmap page that details the current set of tasks and rough schedule. The page should be named "OWASP XXX Project Roadmap"

==Project descriptions==

* [[:Category:OWASP AJAX Security Project|OWASP AJAX Security Project]] - investigating the security of AJAX enabled applications
* [[:Category:OWASP Application Security Assessment Standards Project|OWASP Application Security Assessment Standards Project]] - establish a set of standards defining baseline approaches to conducting differing types/levels of application security assessment
* [[:Category:OWASP AppSec FAQ Project|OWASP AppSec FAQ Project]] - an FAQ covering many application security topics
* [[:Category:OWASP CAL9000 Project|OWASP CAL9000 Project]] - a JavaScript based web application security testing suite
* [[:Category:OWASP CLASP Project|OWASP CLASP Project]] - a project focused on defining process elements that reinforce application security
* [[:Category:OWASP Code Review Project|OWASP Code Review Project]] - a new project to capture best practices for reviewing code
* [[:Category:OWASP Guide Project|OWASP Guide Project]] - a massive document covering all aspects of web application and web service security
* [[:Category:OWASP Legal Project|OWASP Legal Project]] - a project focused on contracting for secure software
* [[:Category:OWASP Logging Project|OWASP Logging Project]] - a project to define best practices for logging and log management
* [[:Category:OWASP Metrics Project|OWASP Metrics Project]] - a project to define workable application security metrics
* [[:Category:OWASP .NET Project|OWASP .NET Project]] - a project focused on helping .NET developers build secure applications
* [[:Category:OWASP PHP Project|OWASP PHP Project]] - a project focused on helping PHP developers build secure applications
* [[:Category:OWASP Java Project|OWASP Java Project]] - a project focused on helping Java and J2EE developers build secure applications
* [[:Category:OWASP Risk Management Project|OWASP Risk Management Project]] - a new project focused on processes for managing application security risk
* [[:Category:OWASP Testing Project|OWASP Testing Project]] - a project focused on application security testing procedures and checklists
* [[:Category:OWASP Top Ten Project|OWASP Top Ten Project]] - an awareness document that describes the top ten web application security vulnerabilities
* [[:Category:OWASP Validation Project|OWASP Validation Project]] - a project that provides guidance and tools related to validation.
* [[:Category:OWASP WASS Project|OWASP WASS Project]] - a standards project to develop more concrete criteria for secure applications
* [[:Category:OWASP WebGoat Project|OWASP WebGoat Project]] - an online training environment for hands-on learning about application security
* [[:Category:OWASP WebScarab Project|OWASP WebScarab Project]] - a tool for performing all types of security testing on web applications and web services

[[OWASP Project Mailing Lists]]

Category:OWASP Application Security Assessment Standards Project

2006-07-24T10:58:03Z

Cbarlow:

Category:OWASP Application Security Assessment Standards Project

2006-07-24T10:41:22Z

Cbarlow:

Category:OWASP Application Security Assessment Standards Project

2006-07-24T10:28:14Z

Cbarlow: Initial population

OWASP Application Security Assessment Standards Project Roadmap

2006-07-24T10:20:04Z

Cbarlow:

The Project’s primary objective is to establish common, consistent methods for application security assessments standards that organizations can use as guidance on what tasks should be completed, how the tasks should be completed, who should be involved and what level of assessment is appropriate based on business requirements.

This project will not define how to technically to conduct an assessment (refer to OWASP Testing Project); it is instead meant to tie business operations and information management practices to application security in order to establish a common, consistent set of standards which provide guidance in conducting such assessments.

== Overall Roadmap Phases ==

'''Phase I – Project Approach''': Comment Period for Proposed Project Approach, Solicit Contributor Support

'''Phase II – Application Assessment Definitions:''' Establish core assessment definitions to ensure common base terminology.

'''Phase III – Assessment Context:''' Establish standard assessment context, selection, qualification and process frameworks.

'''Phase IV – Assessment Levels:''' Establish a common set of application assessment levels to be used as business guidance to ensure conducting appropriate level based on business-application-security requirements.

'''Phase V – OWASP Integration:''' Document integration components and linkages with existing and underway OWASP projects.

== Per Phase Project Objectives ==

'''Phase I – Project Approach and Objectives'''
Project Objective: Solicit Contributor feedback to ensure the most effective and widely supported approach.
Target Time Frame: August, 2006
Current Status: Call for Volunteers
Contributors:
Reviewers:

'''Phase II – Application Assessment Definitions'''
Project Objective: Establish common business application and security assessment type’s definitions.
Target Time Frame: September, 2006
Current Status: Call for Volunteers
Contributors:
Reviewers:

'''Phase III – Assessment Context'''
Project Objective: Define standard application assessment process in SWIM flow chart.
Target Time Frame: October, 2006
Current Status: Call for Volunteers
Contributors:
Reviewers:

'''Phase III – Assessment Context'''
Project Objective: Define standard assessment scope of work per application type. Includes standard testing boundaries and requirements/needs placed upon end user requesting assessment.
Target Time Frame: October, 2006
Current Status: Call for Volunteers
Contributors:
Reviewers:

'''Phase III – Assessment Context'''
Project Objective: Plot where within standard System Development Lifecycle (SDLC) application security assessment steps should be defined and conducted.
Target Time Frame: October, 2006
Current Status: Call for Volunteers
Contributors:
Reviewers:

'''Phase III – Assessment Context'''
Project Objective: Establish common set of assessor qualifications and evaluation criteria to facilitate end service user ability to determine competence per assessment type.
Target Time Frame: October, 2006
Current Status: Call for Volunteers
Contributors:
Reviewers:

'''Phase IV – Assessment Levels'''
Project Objective: Establish assessment level system common terminology and decision criteria - Included is analysis of potentially corresponding security measurements (i.e. common security metrics, security assurance/maturity models, related legislation, other standards, etc.).
Target Time Frame: December, 2006
Current Status: In hold based on outcome of Phase I and II. Calling for future volunteers.
Contributors:
Reviewers:

'''Phase IV – Assessment Levels'''
Project Objective: Create assessment levels based on previous Phase III objective. Define assessment depth, testing components required, and level of tool usage/type (not product names) of tools used per level.
Target Time Frame: March, 2007
Current Status: In hold based on outcome of Phase I and II. Calling for future volunteers.
Contributors:
Reviewers:

'''Phase IV – Assessment Levels'''
Project Objective: Document corresponding linkages between assessment levels and common security metrics, security assurance/maturity models, related legislation, other documented national standards defined as component of first Phase III objective.
Target Time Frame: May, 2007
Current Status: In hold based on outcome of Phase I and II.
Contributors:
Reviewers:

'''Phase IV – Assessment Levels'''
Project Objective: Establish guidance parameters to allow organizations to determine appropriate assessment level based on business application to be assessed.
Target Time Frame: May, 2007
Current Status: In hold based on outcome of Phase I and II. Calling for future volunteers.
Contributors:
Reviewers:

'''Phase V – OWASP Integration:'''
Project Objective: Document integration components and linkages with existing and underway OWASP projects.
Target Time Frame: July, 2007
Current Status: In hold based on outcome of Phases I through III.
Contributors:
Reviewers:

[[Category:OWASP Application Security Assessment Standards Project]]

OWASP Application Security Assessment Standards Project Roadmap

2006-07-24T10:11:08Z

Cbarlow: /* Per Phase Project Objectives */

The Project’s primary objective is to establish common, consistent methods for application security assessments standards that organizations can use as guidance on what tasks should be completed, how the tasks should be completed, who should be involved and what level of assessment is appropriate based on business requirements.

This project will not define how to technically to conduct an assessment (refer to OWASP Testing Project); it is instead meant to tie business operations and information management practices to application security in order to establish a common, consistent set of standards which provide guidance in conducting such assessments.

== Overall Roadmap Phases ==

'''Phase I – Project Approach''': Comment Period for Proposed Project Approach, Solicit Contributor Support
'''
Phase II – Application Assessment Definitions:''' Establish core assessment definitions to ensure common base terminology.
'''
Phase III – Assessment Context:''' Establish standard assessment context, selection, qualification and process frameworks.
'''
Phase IV – Assessment Levels:''' Establish a common set of application assessment levels to be used as business guidance to ensure conducting appropriate level based on business-application-security requirements.

'''Phase V – OWASP Integration:''' Document integration components and linkages with existing and underway OWASP projects.

== Per Phase Project Objectives ==
'''
Phase I – Project Approach and Objectives'''
Project Objective: Solicit Contributor feedback to ensure the most effective and widely supported approach.
Target Time Frame: August, 2006
Current Status: Call for Volunteers
Contributors:
Reviewers:

'''Phase II – Application Assessment Definitions'''
Project Objective: Establish common business application and security assessment type’s definitions.
Target Time Frame: September, 2006
Current Status: Call for Volunteers
Contributors:
Reviewers:

'''
Phase III – Assessment Context'''
Project Objective: Define standard application assessment process in SWIM flow chart.
Target Time Frame: October, 2006
Current Status: Call for Volunteers
Contributors:
Reviewers:

'''
Phase III – Assessment Context'''
Project Objective: Define standard assessment scope of work per application type. Includes standard testing boundaries and requirements/needs placed upon end user requesting assessment.
Target Time Frame: October, 2006
Current Status: Call for Volunteers
Contributors:
Reviewers:

'''
Phase III – Assessment Context'''
Project Objective: Plot where within standard System Development Lifecycle (SDLC) application security assessment steps should be defined and conducted.
Target Time Frame: October, 2006
Current Status: Call for Volunteers
Contributors:
Reviewers:

'''
Phase III – Assessment Context'''
Project Objective: Establish common set of assessor qualifications and evaluation criteria to facilitate end service user ability to determine competence per assessment type.
Target Time Frame: October, 2006
Current Status: Call for Volunteers
Contributors:
Reviewers:

'''Phase IV – Assessment Levels'''
Project Objective: Establish assessment level system common terminology and decision criteria - Included is analysis of potentially corresponding security measurements (i.e. common security metrics, security assurance/maturity models, related legislation, other standards, etc.).
Target Time Frame: December, 2006
Current Status: In hold based on outcome of Phase I and II. Calling for future volunteers.
Contributors:
Reviewers:

'''
Phase IV – Assessment Levels'''
Project Objective: Create assessment levels based on previous Phase III objective. Define assessment depth, testing components required, and level of tool usage/type (not product names) of tools used per level.
Target Time Frame: March, 2007
Current Status: In hold based on outcome of Phase I and II. Calling for future volunteers.
Contributors:
Reviewers:

'''
Phase IV – Assessment Levels'''
Project Objective: Document corresponding linkages between assessment levels and common security metrics, security assurance/maturity models, related legislation, other documented national standards defined as component of first Phase III objective.
Target Time Frame: May, 2007
Current Status: In hold based on outcome of Phase I and II.
Contributors:
Reviewers:

'''Phase IV – Assessment Levels'''
Project Objective: Establish guidance parameters to allow organizations to determine appropriate assessment level based on business application to be assessed.
Target Time Frame: May, 2007
Current Status: In hold based on outcome of Phase I and II. Calling for future volunteers.
Contributors:
Reviewers:

'''Phase V – OWASP Integration: '''
Project Objective: Document integration components and linkages with existing and underway OWASP projects.
Target Time Frame: July, 2007
Current Status: In hold based on outcome of Phases I through III.
Contributors:
Reviewers:

[[Category:OWASP Application Security Assessment Standards Project]]

OWASP Application Security Assessment Standards Project Roadmap

2006-07-24T10:09:44Z

Cbarlow: Initial population of project roadmap

The Project’s primary objective is to establish common, consistent methods for application security assessments standards that organizations can use as guidance on what tasks should be completed, how the tasks should be completed, who should be involved and what level of assessment is appropriate based on business requirements.

This project will not define how to technically to conduct an assessment (refer to OWASP Testing Project); it is instead meant to tie business operations and information management practices to application security in order to establish a common, consistent set of standards which provide guidance in conducting such assessments.

== Overall Roadmap Phases ==

'''Phase I – Project Approach''': Comment Period for Proposed Project Approach, Solicit Contributor Support
'''
Phase II – Application Assessment Definitions:''' Establish core assessment definitions to ensure common base terminology.
'''
Phase III – Assessment Context:''' Establish standard assessment context, selection, qualification and process frameworks.
'''
Phase IV – Assessment Levels:''' Establish a common set of application assessment levels to be used as business guidance to ensure conducting appropriate level based on business-application-security requirements.

'''Phase V – OWASP Integration:''' Document integration components and linkages with existing and underway OWASP projects.

== Per Phase Project Objectives ==
'''
Phase I – Project Approach and Objectives'''
Project Objective: Solicit Contributor feedback to ensure the most effective and widely supported approach.
Target Time Frame: August, 2006
Current Status: Call for Volunteers
Contributors:
Reviewers:

'''Phase II – Application Assessment Definitions'''
Project Objective: Establish common business application and security assessment type’s definitions.
Target Time Frame: September, 2006
Current Status: Call for Volunteers
Contributors:
Reviewers:
'''
Phase III – Assessment Context'''
Project Objective: Define standard application assessment process in SWIM flow chart.
Target Time Frame: October, 2006
Current Status: Call for Volunteers
Contributors:
Reviewers:
'''
Phase III – Assessment Context'''
Project Objective: Define standard assessment scope of work per application type. Includes standard testing boundaries and requirements/needs placed upon end user requesting assessment.
Target Time Frame: October, 2006
Current Status: Call for Volunteers
Contributors:
Reviewers:
'''
Phase III – Assessment Context'''
Project Objective: Plot where within standard System Development Lifecycle (SDLC) application security assessment steps should be defined and conducted.
Target Time Frame: October, 2006
Current Status: Call for Volunteers
Contributors:
Reviewers:
'''
Phase III – Assessment Context'''
Project Objective: Establish common set of assessor qualifications and evaluation criteria to facilitate end service user ability to determine competence per assessment type.
Target Time Frame: October, 2006
Current Status: Call for Volunteers
Contributors:
Reviewers:

'''Phase IV – Assessment Levels'''
Project Objective: Establish assessment level system common terminology and decision criteria - Included is analysis of potentially corresponding security measurements (i.e. common security metrics, security assurance/maturity models, related legislation, other standards, etc.).
Target Time Frame: December, 2006
Current Status: In hold based on outcome of Phase I and II. Calling for future volunteers.
Contributors:
Reviewers:
'''
Phase IV – Assessment Levels'''
Project Objective: Create assessment levels based on previous Phase III objective. Define assessment depth, testing components required, and level of tool usage/type (not product names) of tools used per level.
Target Time Frame: March, 2007
Current Status: In hold based on outcome of Phase I and II. Calling for future volunteers.
Contributors:
Reviewers:
'''
Phase IV – Assessment Levels'''
Project Objective: Document corresponding linkages between assessment levels and common security metrics, security assurance/maturity models, related legislation, other documented national standards defined as component of first Phase III objective.
Target Time Frame: May, 2007
Current Status: In hold based on outcome of Phase I and II.
Contributors:
Reviewers:

'''Phase IV – Assessment Levels'''
Project Objective: Establish guidance parameters to allow organizations to determine appropriate assessment level based on business application to be assessed.
Target Time Frame: May, 2007
Current Status: In hold based on outcome of Phase I and II. Calling for future volunteers.
Contributors:
Reviewers:

'''Phase V – OWASP Integration: '''
Project Objective: Document integration components and linkages with existing and underway OWASP projects.
Target Time Frame: July, 2007
Current Status: In hold based on outcome of Phases I through III.
Contributors:
Reviewers:

[[Category:OWASP Application Security Assessment Standards Project]]