OWASP - User contributions [en]

SAMM - Security Requirements - 1

2015-04-20T00:55:30Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Security_Requirements|abbr=SR|border1=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Construction http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveC1|name=Security Requirements|obj=Consider security explicitly during the software requirements process}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* High-level alignment of development effort with business risks
* Ad hoc capturing of industry best-practices for security as explicit requirements
* Awareness amongst stakeholders of measures being taken to mitigate risk from software

====Success Metrics====
* >50% of project teams with explicitly defined security requirements

====Costs====
* Project overhead from addition of security requirements to each development cycle

====Personnel====
* Security Auditor (2 days/yr)
* Business Owner (1 days/yr)
* Managers (1 day/yr)
* Architects (1 day/yr)

====Related Levels====
* Education & Guidance - 1
* Policy & Compliance - 2
* Design Review - 1
* Code Review - 1
* Security Testing - 1

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Derive security requirements from business functionality===
Conduct a review of functional requirements that specify the business logic and overall behavior for each software project. After gathering requirements for a project, conduct an assessment to derive relevant security requirements. Even if software is being built by a third-party, these requirements, once identified, should be included with functional requirements delivered to vendors.

For each functional requirement, a security auditor should lead stakeholders through the process of explicitly noting any expectations with regard to security. Typically, questions to clarify for each requirement include expectations for data security, access control, transaction integrity, criticality of business function, separation of duties, uptime, etc.

It is important to ensure that all security requirements follow the same principles for writing good requirements in general. Specifically, they should be specific, measurable, and reasonable.

Conduct this process for all new requirements on active projects. For existing features, it is recommended to conduct the same process as a gap analysis to fuel future refactoring for security.

===B. Evaluate security and compliance guidance for requirements===
Determine industry best-practices that project teams should treat as requirements. These can be chosen from publicly available guidelines, internal or external guidelines/standards/policies, or established compliance requirements.

It is important to not attempt to bring in too many best-practice requirements into each development iteration since there is a time trade-off with design and implementation. The recommended approach is to slowly add best-practices over successive development cycles to bolster the software’s overall assurance profile over time.

For existing systems, refactoring for security best practices can be a complex undertaking. Where possible, add security requirements opportunistically when adding new features. At a minimum, conducting the analysis to identify applicable best practices should be done to help fuel future planning efforts.

This review should be performed by a security auditor with input from business stakeholders. Senior developers, architects, and other technical stakeholders should also be involved to bring design and implementation-specific knowledge into the decision process.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-SR-1]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-SR-1]]

SAMM - Operational Enablement - 3

2015-04-20T00:52:55Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Operational_Enablement|abbr=OE|border3=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Deployment http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveD3|name=Operational Enablement|obj=Mandate communication of security information and validate artifacts for completeness}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Organization-wide understanding of expectations for security-relevant documentation
* Stakeholders better able to make tradeoff decisions based on feedback from deployment and operations
* Operators and/or users able to independently verify integrity of software releases

====Add’l Success Metrics====
* >80% of projects with updated operational security guide in last 6 months
* >80% of stakeholders briefed on code signing options and status in past 6 months

====Add’l Costs====
* Ongoing project overhead from audit of operational guides
* Ongoing organization overhead from management of code signing credentials
* Ongoing project overhead from identification and signing of code modules.

====Add’l Personnel====
* Developers (1 days/yr)
* Architects (1 days/yr)
* Managers (1 days/yr)
* Security Auditors (1-2 days/yr)

====Related Levels====

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Expand audit program for operational information===
When conducting routine project-level audits, expand the review to include inspection of artifacts related to operational enablement for security. Projects should be checked to ensure they have an updated and complete operational security guides as relevant to the specifics of the software.

These audits should begin toward the end of the development cycle close to release, but must be completed and passed before a release can be made. For legacy systems or inactive projects, this type of audit should be conducted and a one-time effort should be made to address findings and verify audit compliance, after which additional audits for operational enablement are no longer required.

Audit results must be reviewed with business stakeholders prior to release. An exception process should be created to allow projects failing an audit to continue with a release, but these projects should have a concrete timeline for mitigation of findings. Exceptions should be limited to no more that 20% of all active projects.

===B. Perform code signing for application components===
Though often used with special-purpose software, code signing allows users and operators to perform integrity checks on software such that they can cryptographically verify the authenticity of a module or release. By signing software modules, the project team enables deployments to operate with a greater degree of assurance against any corruption or modification of the deployed software in its operating environment.

Signing code incurs overhead for management of signing credentials for the organization. An organization must follow safe key management processes to ensure the ongoing confidentiality of the signing keys. When dealing with any cryptographic keys, project stakeholders must also consider plans for dealing with common operational problems related to cryptography such as key rotation, key compromise, or key loss.

Since code signing is not appropriate for everything, architects and developers should work with security auditors and business stakeholders to determine which parts of the software should be signed. As projects evolve, this list should be reviewed with each release, especially when adding new modules or making changes to previously signed components.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-OE-3]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-OE-3]]

SAMM - Operational Enablement - 2

2015-04-20T00:52:38Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Operational_Enablement|abbr=OE|border2=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Deployment http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveD2|name=Operational Enablement|obj=Improve expectations for continuous secure operations through provision of detailed procedures}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Detailed guidance for security-relevant changes delivered with software releases
* Updated information repository on secure operating procedures per application
* Alignment of operations expectations among developers, operators, and users.

====Add’l Success Metrics====
* >50% of projects with updated change management procedures in past 6 months
* >80% of stakeholders briefed on status of operational security guides in past 6 months

====Add’l Costs====
* Ongoing project overhead from maintenance of change management procedures
* Ongoing project overhead from maintenance of operational security guides

====Add’l Personnel====
* Developers (1-2 days/yr)
* Architects (1-2 days/yr)
* Managers (1 days/yr)
* Support/Operators (1 days/yr)

====Related Levels====
* Environment Hardening - 1

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Create per-release change management procedures===
To more formally update users and operators on relevant changes in the software, each release must include change management procedures relevant to upgrade and first-time installation. Overall, the goal is to capture the expected accompanying steps that ensure the deployment will be successful and not incur excessive downtime or degradation of security posture.

To build these procedures during development, the project teams should setup a lightweight internal process for capturing relevant items that would impact deployments. It is effective to have this process in place early in the development cycle so that this information can be retained as soon as it is identified while in the requirements, design, and implementation phases.

Before each release, the project team should review the list as a whole for completeness and feasibility. For some projects, extensive change procedures accompanying a given release may warrant special handling, such as building automated upgrade scripts to prevent errors during deployment.

===B. Maintain formal operational security guides===
Starting from the information captured on critical software events and the procedures for handling each, project teams should build and maintain formal guides that capture all the security-relevant information that users and operators need to know.

Initially, this guide should be built from the known information about the system, such as security-related configuration options, event handling procedures, installation and upgrade guides, operational environment specifications, security-related assumptions about the deployment environment, etc. Extending this, the formal operational security guide should elaborate on each of these to cover more details such that the majority of the users and operators will be informed for all the questions they might have had. For large or complex systems, this can be challenging, so project teams should work with business stakeholders to determine the appropriate level of documentation. Additionally, project teams should document any recommendations for deployments that would enhance security.

The operational security guide, after initial creation, should be reviewed by project teams and updated with each release.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-OE-2]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-OE-2]]

SAMM - Operational Enablement - 1

2015-04-20T00:52:18Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Operational_Enablement|abbr=OE|border1=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Deployment http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveD1|name=Operational Enablement|obj=Enable communications between development teams and operators for critical security-relevant data}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Ad hoc improvements to software security posture through better understanding of correct operations
* Operators and users aware of their role in ensuring secure deployment
* Improved communications between software developers and users for security-critical information

====Success Metrics====
* >50% of projects with updated deployment security information in past 6 months
* >50% of projects with operational procedures for events updated in past 6 months

====Costs====
* Ongoing project overhead from maintenance of deployment security information
* Ongoing project overhead from maintenance of critical operating procedures

====Personnel====
* Developers (1-2 days/yr)
* Architects (1-2 days/yr)
* Managers (1 days/yr)
* Support/Operators (1 days/yr)

====Related Levels====

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Capture critical security information for deployment===
With software-specific knowledge, project teams should identify any security-relevant configuration and operations information and communicate it to users and operators. This enables the actual security posture of software at deployment sites to function in the same way that designers in the project team intended.

This analysis should begin with architects and developers building a list of security features built-in to the software. From that list, information about configuration options and their security impact should be captured as well. For projects that offer several different deployment models, information about the security ramifications of each should be noted to better inform users and operators about the impact of their choices.

Overall, the list should be lightweight and aim to capture the most critical information. Once initially created, it should be reviewed by the project team and business stakeholders for agreement. Additionally, it is effective to review this list with select operators or users in order to ensure the information is understandable and actionable. Project teams should review and update this information with every release, but must do so at least every 6 months.

===B. Document procedures for typical application alerts===
With specific knowledge of ways in which software behaves, project teams should identify the most important error and alert messages which require user/operator attention. From each identified event, information related to appropriate user/operator actions in response to the event should be captured.

From the potentially large set of events that the software might generate, select the highest priority set based on relevance in terms of the business purpose of the software. This should include any security-related events, but also may include critical errors and alerts related to software health and configuration status.

For each event, actionable advice should be captured to inform users and operators of required next steps and potential root causes of the event. These procedures must be reviewed by the project team and updated at every major product release, every 6 months, but can be done more frequently, e.g. with each release.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-OE-1]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-OE-1]]

SAMM - Environment Hardening - 3

2015-04-20T00:51:40Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Environment_Hardening|abbr=EH|border3=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Deployment http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveD3|name=Environment Hardening|obj=Validate application health and status of operational environment against known best practices}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Reinforced operational environment with layered checks for security
* Established and measured goals for operational maintenance and performance
* Reduced likelihood of successful attack via flaws in external dependencies

====Add’l Success Metrics====
* >80% of stakeholders briefed on relevant operations protection tools in past 6 months
* >75% of projects passing infrastructure audits in past 6 months

====Add’l Costs====
* Research and selection of operations protection solutions
* Buildout or license of operations protections tools
* Ongoing operations overhead from maintenance of protection tools
* Ongoing project overhead from infrastructure-related audits

====Add’l Personnel====
* Business Owners (1 day/yr)
* Managers (1-2 days/yr)
* Support/Operators (3-4 days)

====Related Levels====
* Policy & Compliance - 2

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Identify and deploy relevant operations protection tools===
In order to build a better assurance case for software in its operating environment, additional tools can be used to enhance the security posture of the overall system. Operational environments can vary dramatically, thus the appropriateness of given protection technology should be considered in the project context.

Commonly used protections tools include web application firewalls, XML security gateways for web services, anti-tamper and obfuscation packages for client/embedded systems, network intrusion detection/prevention systems for legacy infrastructure, forensic log aggregation tools, host-based integrity verification tools, etc.

Based on the organization and project-specific knowledge, technical stakeholders should work with support and operations staff to identify and recommend selected operations protection tools to business stakeholders. If deemed a valuable investment in terms of risk-reduction versus cost of implementation, stakeholders should agree on plans for a pilot, widespread rollout, and ongoing maintenance.

===B. Expand audit program for environment configuration===
When conducting routine project-level audits, expand the review to include inspection of artifacts related to hardening the operating environment. Beyond an up-to-date specification for the operational environment, audits should inspect current patch status and historic data since the previous audit. By tapping into monitoring tools, audits can also verify key factors about application configuration management and historic changes. Audits should also inspect the usage of operations protections tools against those available for the software’s architecture type.

Audits for infrastructure can occur at any point after a project’s initial release and deployment, but should occur at least every 6 months. For legacy systems or projects without active development, infrastructure audits should still be conducted and reviewed by business stakeholders. An exception process should be created to allow special-case projects to continue operations, but with an explicitly assigned timeframe for mitigation of findings. Exceptions should be limited to no more that 20% of all projects.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-EH-3]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-EH-3]]

SAMM - Environment Hardening - 2

2015-04-20T00:51:22Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Environment_Hardening|abbr=EH|border2=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Deployment http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveD2|name=Environment Hardening|obj=Improve confidence in application operations by hardening the operating environment}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Granular verification of security characteristics of systems in operations
* Formal expectations on timelines for infrastructure risk mitigation
* Stakeholders consistently aware of current operations status of software projects

====Add’l Success Metrics====
* >80% of project teams briefed on patch management process in past 12 months
* >80% of stakeholders aware of current patch status in past 6 months

====Add’l Costs====
* Ongoing organization overhead from patch management and monitoring
* Buildout or license of infrastructure monitoring tools

====Add’l Personnel====
* Architects (1-2 days/yr)
* Developers (1-2 days/yr)
* Business Owners (1-2 days/yr)
* Managers (1-2 days/yr)
* Support/Operators (3-4 days/yr)

====Related Levels====

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Establish routine patch management process===
Moving to a more formal process than ad hoc application of critical upgrades and patches, an ongoing process should be created in the organization to consistently apply updates to software dependencies in the operating environment.

In the most basic form, the process should aim to make guarantees for time lapse between release and application of security upgrades and patches. To make this process efficient, organizations typically accept high latency on lower priority updates, e.g. maximum of 2 days for critical patches spanning to a maximum of 30 days for low priority patches.

This activity should be primarily conducted by support and operations staff, but routine meetings with development should also be conducted to keep the whole project abreast of past changes and scheduled upgrades.

Additionally, development staff should share a list of third-party components upon which the software project internally depends so that support and operations staff can monitor those as well to cue development teams on when an upgrade is required.

===B. Monitor baseline environment configuration status===
Given the complexity of monitoring and managing patches alone across the variety of components composing the infrastructure for a software project, automation tools should be utilized to automatically monitor systems for soundness of configuration.

There are both commercial and open-source tools available to provide this type of functionality, so project teams should select a solution based on appropriateness to the organization’s needs. Typical selection criteria includes ease of deployment and customization, applicability to the organization’s platforms and technology stacks, built-in features for change management and alerting, metrics collection and trend tracking etc.

In addition to host and platform checks, monitoring automation should be customized to perform application-specific health checks and configuration verifications. Support and operations personnel should work with architects and developers to determine the optimal amount of monitoring for a given software project.

Ultimately, after a solution is deployed for monitoring the environment’s configuration status, unexpected alerts or configuration changes should be collected and regularly reviewed by project stakeholders as often as weekly but at least once per quarter.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-EH-2]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-EH-2]]

SAMM - Environment Hardening - 1

2015-04-20T00:51:02Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Environment_Hardening|abbr=EH|border1=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Deployment http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveD1|name=Environment Hardening|obj=Understand baseline operational environment for applications and software components}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Clear understanding of operational expectations within the development team
* High-priority risks from underlying infrastructure mitigated on a well-understood timeline
* Software operators with a high-level plan for security-critical maintenance of infrastructure

====Success Metrics====
* >50% project with updated operational environment specification in past 6 months
* >50% of projects with updated list of relevant critical security patches in past 6 months

====Costs====
* Ongoing project overhead from buildout and maintenance of operational environment specification
* Ongoing project overhead from monitoring and installing critical security updates

====Personnel====
* Developers (1-2 day/yr)
* Architects (1-2 day/yr)
* Managers (2-4 day/yr)
* Support/Operators (3-4 days/yr)

====Related Levels====
* Operational Enablement - 2

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Maintain operational environment specification===
For each project, a concrete definition of the expected operating platforms should be created and maintained. Depending on the organization, this specification should be jointly created with development staff, stakeholders, support and operations groups, etc.

Begin this specification should by capturing all details that must be true about the operating environment based upon the business function of the software. These can include factors such as processor architecture, operating system versions, prerequisite software, conflicting software, etc.
Further, note any known user or operator configurable options about the operating environment that affect the way in which the software will behave.

Additionally, identify any relevant assumptions about the operating environment that were made in design and implementation of the project and capture those assumptions in the specification.

This specification should be reviewed and updated at least every 6 months for active projects or more often if changes are being made to the software design or the expected operating environment.

===B. Identify and install critical security upgrades and patches===
Most applications are software that runs on top of another large stack of software composed of built-in programming language libraries, third-party components and development frameworks, base operating systems, etc. Because security flaws contained in any module in that large software stack affect the overall security of the organization’s software, critical security updates for elements of the technology stack must be installed.

As such, regular research or ongoing monitoring of high-risk dependencies should be performed to stay abreast of the latest fixes to security flaws. Upon identification of a critical upgrade or patch that would impact the security posture of the software project, plans should be made to get affected users and operators to update their installations. Depending on the type of software project, details on doing this can vary.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-EH-1]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-EH-1]]

SAMM - Vulnerability Management - 3

2015-04-20T00:50:28Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Vulnerability_Management|abbr=VM|border3=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Deployment http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveD3|name=Vulnerability Management|obj=Improve analysis and data gathering within response process for feedback into proactive planning}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Detailed feedback for organizational improvement after each incident
* Rough cost estimation from vulnerabilities and compromises
* Stakeholders better able to make tradeoff decisions based on historic incident trends

====Add’l Success Metrics====
* >80% of incidents documented with root causes and further recommendations in past 6 months
* >80% of incidents collated for metrics in the past 6 months

====Add’l Costs====
* Ongoing organization overhead from conducting deeper research and analysis of incidents
* Ongoing organization overhead from collection and review of incident metrics

====Add’l Personnel====
* Security Auditors (3 days/yr)
* Managers (2 days/yr)
* Business Owners (2 days/yr)

====Related Levels====
* Strategy & Metrics - 3

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Conduct root cause analysis for incidents===
Though potentially time consuming, the incident response process should be augmented to include additional analysis to identify the key, underlying security failures. These root causes can be technical problems such as code-level vulnerabilities, configuration errors, etc. or they can be people/process problems such as social engineering, failure to follow procedures, etc.

Once a root cause is identified for an incident, it should be used as a tool to find other potential weaknesses in the organization where an analogous incident could have occurred. For each identified weakness additional recommendations for proactive mitigations should be communicated as part of closing out the original incident response effort.

Any recommendations based on root cause analysis should be reviewed by management and relevant business stakeholders in order to either schedule mitigation activities or note the accepted risks.

===B. Collect per-incident metrics===
By having a centralized process to handle all compromise and high-priority vulnerability reports, an organization is enabled to take measurements of trends over time to determine impact and efficiency of initiatives for security assurance.

Records of past incidents should be stored and reviewed at least every 6 months. Group similar incidents and simply tally the overall count for each type of problem. Additional measurements to take from the incidents include frequency of software projects affected by incidents, system downtime and cost from loss of use, human resources taken in handling and cleanup of the incident, estimates of long-term costs such as regulatory fines or brand damage, etc. For root causes that were technical problems in nature, it is also helpful to identify what kind of proactive, review, or operational practice might have detected it earlier or lessened the damage.

This information is concrete feedback into the program planning process since it represents the real security impact that the organization has felt over time.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-VM-3]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-VM-3]]

SAMM - Vulnerability Management - 2

2015-04-20T00:50:10Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Vulnerability_Management|abbr=VM|border2=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Deployment http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveD2|name=Vulnerability Management|obj=Elaborate expectations for response process to improve consistency and communications}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Communications plan for dealing with vulnerability reports from third-parties
* Clear process for releasing security patches to software operators
* Formal process for tracking, handling, and internally communicating about incidents

====Add’l Success Metrics====
* >80% of project teams briefed on incident response process in past 6 months
* >80% of stakeholders briefed on security issue disclosures in past 6 months

====Add’l Costs====
* Ongoing organization overhead from incident response process

====Add’l Personnel====
* Security Auditors (3-5 days/yr)
* Managers (1-2 days/yr)
* Business Owners (1-2 days/yr)
* Support/Operators (1-2 days/yr)

====Related Levels====

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Establish consistent incident response process===
Extending from the informal security response team, explicitly document the organization’s incident response process as well as the procedures that team members are expected to follow. Additionally, each member of the security response team must be trained on this material at least annually.

There are several tenets to sound incident response process and they include initial triage to prevent additional damage, change management and patch application, managing project personnel and others involved in the incident, forensic evidence collection and preservation, limiting communication about the incident to stakeholders, well-defined reporting to stakeholders and/or communications trees, etc.

With development teams, the security responders should work together to conduct the technical analysis to verify facts and assumptions about each incident or vulnerability report. Likewise, when project teams detect an incident or high-risk vulnerability, they should follow an internal process that puts them in contact with a member of the security response team.

===B. Adopt a security issue disclosure process===
For most organizations, it is undesirable to let news of a security problem become public, but there are several important ways in which internal-to-external communications on security issues should be fulfilled.

The first and most common is through creation and deployment of security patches for the software produced by the organization. Generally, if all software projects are only used internally, then this becomes less critical, but for all contexts where the software is being operated by parties external to the organization, a patch release process must exist. It should provide for several factors including change management and regression testing prior to patch release, announcement to operators/users with assigned criticality category for the patch, sparse technical details so that an exploit cannot be directly derived, etc.

Another avenue for external communications is with third parties that report security vulnerabilities in an organization’s software. By adopting and externally posting the expected process with timeframes for response, vulnerability reporters are encouraged to follow responsible disclosure practices.

Lastly, many states and countries legally require external communications for incidents involving data theft of personally identifiable information and other sensitive data type. Should this type of incident occur, the security response team should work with managers and business stakeholders to determine appropriate next-steps.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-VM-2]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-VM-2]]

SAMM - Vulnerability Management - 1

2015-04-20T00:49:50Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Vulnerability_Management|abbr=VM|border1=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Deployment http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveD1|name=Vulnerability Management|obj=Understand high-level plan for responding to vulnerability reports or incidents}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Lightweight process in place to handle high-priority vulnerabilities or incidents
* Framework for stakeholder notification and reporting of events with security impact
* High-level due diligence for handling security issues

====Success Metrics====
* >50% of the organization briefed on closest security point of contact in past 6 months
* >1 meeting of security response team and points of contact in past 12 months

====Costs====
* Ongoing variable project overhead from staff filling the security point of contact roles
* Identification of appropriate security response team

====Personnel====
* Security Auditors (1 day/yr)
* Architects (1 day/yr)
* Managers (1 day/yr)
* Business Owners (1 day/yr)

====Related Levels====
* Education & Guidance - 2
* Strategy & Metrics - 3

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Identify point of contact for security issues===
For each division within the organization or for each project team, establish a point of contact to serve as a communications hub for security information. While generally this responsibility will not claim much time from the individuals, the purpose of having a predetermined point of contact is to add structure and governance for vulnerability management.

Examples of incidents that might cause the utilization include receipt of a vulnerability report from an external entity, compromise or other security failure of software in the field, internal discovery of high-risk vulnerabilities, etc. In case of an event, the closest contact would step in as an extra resource and advisor to the affected project team(s) to provide technical guidance and brief other stakeholders on progress of mitigation efforts.

The point of contact should be chosen from security-savvy technical or management staff with a breadth of knowledge over the software projects in the organization. A list of these assigned security points of contact should be centrally maintained and updated at least every six months. Additionally, publishing and advertising this list allows staff within the organization to request help and work directly with one another on security problems.

===B. Create informal security response team(s)===
From the list of individuals assigned responsibility as a security point of contact or from dedicated security personnel, select a small group to serve as a centralized technical security response team. The responsibilities of the team will include directly taking ownership of security incidents or vulnerability reports and being responsible for triage, mitigation, and reporting to stakeholders.

Given their responsibility when tapped, members of the security response team are also responsible for executive briefings and upward communication during an incident. It is likely that most of the time, the security response team would not be operating in this capacity, though they must be flexible enough to be able to respond quickly or a smooth process must exist for deferring and incident to another team member.

The response team should hold a meeting at least annually to brief security points of contact on the response process and high-level expectations for security-related reporting from project teams.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-VM-1]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-VM-1]]

SAMM - Security Testing - 3

2015-04-20T00:49:01Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Security_Testing|abbr=ST|border3=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Verification http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveV3|name=Security Testing|obj=Require application-specific security testing to ensure baseline security before deployment}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Organization-wide baseline for expected application performance against attacks
* Customized security test suites to improve accuracy of automated analysis
* Project teams aware of objective goals for attack resistance

====Add’l Success Metrics====
* >50% of projects using security testing customizations
* >75% of projects passing all security tests in past 6 months

====Add’l Costs====
* Buildout and maintenance of customizations to security testing automation
* Ongoing project overhead from security testing audit process
* Organization overhead from project delays caused by failed security testing audits

====Add’l Personnel====
* Architects (1 day/yr)
* Developers (1 day/yr)
* Security Auditors (1-2 days/yr)
* QA Testers (1-2 days/yr)
* Business Owners (1 day/yr)
* Managers (1 day/yr)

====Related Levels====
* Policy & Compliance - 2
* Secure Architecture - 3

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Employ application-specific security testing automation===
Through either customization of security testing tools, enhancements to generic test case execution tools, or buildout of custom test harnesses, project teams should formally iterate through security requirements and build a set of automated checkers to test the security of the implemented business logic.

Additionally, many automated security testing tools can be greatly improved in accuracy and depth of coverage if they are customized to understand more detail about the specific software interfaces in the project under test. Further, organization-specific concerns from compliance or technical standards can be codified as a reusable, central test battery to make audit data collection and per-project management visibility simpler.

Project teams should focus on buildout of granular security test cases based on the business functionality of their software, and an organization-level team led by a security auditor should focus on specification of automated tests for compliance and internal standards.

===B. Establish release gates for security testing===
To prevent software from being released with easily found security bugs, a particular point in the software development life-cycle should be identified as a checkpoint where an established set of security test cases must pass in order to make a release from the project. This establishes a baseline for the kinds of security tests all projects are expected to pass.

Since adding too many test cases initially can result in an overhead cost bubble, begin by choosing one
or two security issues and include a wide variety of test cases for each with the expectation that no project may pass if any test fails. Over time, this baseline should be improved by selecting additional security issues and adding a variety of corresponding test cases.

Generally, this security testing checkpoint should occur toward the end of the implementation or testing, but must occur before release.

For legacy systems or inactive projects, an exception process should be created to allow those projects to continue operations, but with an explicitly assigned timeframe for mitigation of findings. Exceptions should be limited to no more that 20% of all projects.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-ST-3]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-ST-3]]

SAMM - Security Testing - 2

2015-04-20T00:48:43Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Security_Testing|abbr=ST|border2=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Verification http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveV2|name=Security Testing|obj=Make security testing during development more complete and efficient through automation}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Deeper and more consistent verification of software functionality for security
* Development teams enabled to self-check and correct problems before release
* Stakeholders better aware of open vulnerabilities when making risk acceptance decisions

====Add’l Success Metrics====
* >50% of projects with security testing and stakeholder sign-off in past 6 months
* >80% of projects with access to automated security testing results in past 1 month

====Add’l Costs====
* Research and selection of automated security testing solution
* Initial cost and maintenance of automation integration
* Ongoing project overhead from automated security testing and mitigation

====Add’l Personnel====
* Developers (1 days/yr)
* Architects (1 day/yr)
* Managers (1-2 days/yr)
* Security Auditors (2 days/yr)
* QA Testers (3-4 days/yr)

====Related Levels====

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Utilize automated security testing tools===
In order to test for security issues, a potentially large number of input cases must be checked against each software interface, which can make effective security testing using manual test case implementation and execution unwieldy. Thus, automated security test tools should be used to automatically test software, resulting in more efficient security testing and higher quality results.

Both commercial and open-source products are available and should be reviewed for appropriateness for the organization. Selecting a a suitable tool is based on several factors including robustness and accuracy of built-in security test cases, efficacy at testing architecture types important to organization, customization to change or add test cases, quality and usability of findings to the development organization, etc..

Utilize input from security-savvy technical staff as well as development and quality assurance staff in the selection process, and review overall results with stakeholders.

===B. Integrate security testing into development process===
With tools to run automated security tests, projects within the organization should routinely run security tests and review results during development. In order to make this scalable with low overhead, security testing tools should be configured to automatically run on a routine basis, e.g. nightly or weekly, and findings should be inspected as they occur.

Conducting security tests as early as the requirements or design phases can be beneficial. While traditionally, used for functional test cases, this type of test-driven development approach involves identifying and running relevant security test cases early in the development cycle, usually during design. With the automatic execution of security test cases, projects enter the implementation phase with a number of failing tests for the non-existent functionality. Implementation is complete when all the tests pass. This provides a clear, upfront goal for developers early in the development cycle, thus lowering risk of release delays due to security concerns or forced acceptance of risk in order to meet project deadlines.

For each project release, results from automated and manual security tests should be presented to management and business stakeholders for review. If there are unaddressed findings that remain as accepted risks for the release, stakeholders and development managers should work together to establish a concrete timeframe for addressing them.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-ST-2]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-ST-2]]

SAMM - Security Testing - 2

2015-04-20T00:48:35Z

David Fern:

SAMM - Security Testing - 1

2015-04-20T00:48:19Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Security_Testing|abbr=ST|border1=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Verification http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveV1|name=Security Testing|obj=Establish process to perform basic security tests based on implementation and software requirements}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Independent verification of expected security mechanisms surrounding critical business functions
* High-level due diligence toward security testing
* Ad hoc growth of a security test suite for each software project

====Success Metrics====
* >50% of projects specifying security test cases in past 12 months
* >50% of stakeholders briefed on project status against security tests in past 6 months

====Costs====
* Buildout or license of security test cases
* Ongoing project overhead from maintenance and evaluation of security test cases

====Personnel====
* QA Testers (1-2 days/yr)
* Security Auditor (1-2 days/yr)
* Developers (1 day/yr)
* Architects (1 day/yr)
* Business Owners (1 day/yr)

====Related Levels====
* Security Requirements - 1

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Derive test cases from known security requirements===
From the known security requirements for a project, identify a set of test cases to check the software for correct functionality. Typically, these test cases are derived from security concerns surrounding the functional requirements and business logic of the system, but should also include generic tests for common vulnerabilities based on the implementation language or technology stack.

Often, it is most effective to use the project team’s time to build application-specific test cases and utilize publicly available resources or purchased knowledge bases to select applicable general test cases for security. Although not required, automated security testing tools can also be utilized to cover the general security test cases.

This test case planning should occur during the requirements and/or design phases, but must occur before final testing prior to release. Candidate test cases should be reviewed for applicability, efficacy, and feasibility by relevant development, security, and quality assurance staff.

===B. Conduct penetration testing on software releases===
Using the set of security test cases identified for each project, penetration testing should be conducted to evaluate the system’s performance against each case. It is common for this to occur during the testing phase prior to release.

Penetration testing cases should include both application-specific tests to check soundness of business logic as well as common vulnerability tests to check the design and implementation. Once specified, security test cases can be executed by security-savvy quality assurance or development staff, but first-time execution of security test cases for a project team should be monitored by a security auditor to assist and coach team members.

Prior to release or deployment, stakeholders must review results of security tests and accept the risks indicated by failing security tests at release time. In the latter case, a concrete timeline should be established to address the gaps over time.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-ST-1]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-ST-1]]

SAMM - Design Review - 3

2015-04-20T00:47:05Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Design_Review|abbr=DR|border3=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Verification http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveV3|name=Design Review|obj=Require assessments and validate artifacts to develop detailed understanding of protection mechanisms}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Granular view of weak points in a system design to encourage better compartmentalization
* Organization-level awareness of project standing against baseline security expectations for architecture
* Comparisons between projects for efficiency and progress toward mitigating known flaws

====Add’l Success Metrics====
* >80% of projects with updated data-flow diagrams in past 6 months
* >75% of projects passing design review audit in past 6 months

====Add’l Costs====
* Ongoing project overhead from maintenance of data-flow diagrams
* Organization overhead from project delays caused by failed design review audits

====Add’l Personnel====
* Developers (2 days/yr)
* Architects (1 day/yr)
* Managers (1-2 days/yr)
* Business Owners (1-2 days/yr)
* Security Auditors (2-3 days/yr)

====Related Levels====
* Secure Architecture - 3
* Code Review - 3

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Develop data-flow diagrams for sensitive resources===
Based on the business function of the software project, conduct analysis to identify details on system behavior around high-risk functionality. Typically, high-risk functionality will correlate to features implementing creation, access, update, and deletion of sensitive data. Beyond data, high-risk functionality also includes project-specific business logic that is critical in nature, either from a denial-of-service or compromise perspective.

For each identified data source or business function, select and use a standardized notation to capture relevant software modules, data sources, actors, and messages that flow amongst them. It is often helpful to start with a high-level design diagram and iteratively flesh out relevant detail while removing elements that do not correspond to the sensitive resource.

With data-flow diagrams created for a project, conduct analysis over them to determine internal choke-points in the design. Generally, these will be individual software modules that handle data with differing sensitivity levels or those that gate access to several business functions of various levels of business criticality.

===B. Establish release gates for design review===
Having established a consistent design review program, the next step of enforcement is to set a particular point in the software development life-cycle where a project cannot pass until an design review is conducted and findings are reviewed and accepted. In order to accomplish this, a baseline level of expectations should be set, e.g. no projects with any high-severity findings will be allowed to pass and all other findings must be accepted by the business owner.

Generally, design reviews should occur toward the end of the design phase to aide early detection of security issues, but it must occur before releases can be made from the project team.

For legacy systems or inactive projects, an exception process should be created to allow those projects to continue operations, but with an explicitly assigned timeframe for each to be reviewed to illuminate any hidden vulnerabilities in the existing systems. Exceptions for should be limited to no more than 20% of all projects.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-DR-3]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-DR-3]]

SAMM - Design Review - 2

2015-04-20T00:46:46Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Design_Review|abbr=DR|border2=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Verification http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveV2|name=Design Review|obj=Offer assessment services to review software design against comprehensive best practices for security}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Formally offered assessment service to consistently review architecture for security
* Pinpoint security flaws in maintenance-mode and legacy systems
* Deeper understanding amongst project stakeholders on how the software provides assurance protections

====Add’l Success Metrics====
* >80% of stakeholders briefed on status of review requests in past 6 months
* >75% of projects undergoing design review in past 12 months

====Add’l Costs====
* Buildout, training, and maintenance of design review team
* Ongoing project overhead from review activities

====Add’l Personnel====
* Architects (1-2 days/yr)
* Developers (1 day/yr)
* Managers (1 day/yr)
* Security Auditors (2-3 days/yr)

====Related Levels====
* Education & Guidance - 2
* Strategy & Metrics - 2

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Inspect for complete provision of security mechanisms===
For each interface on a module in the high-level architecture diagram, formally iterate through the list of security mechanisms and analyze the system for their provision. This type of analysis should be performed on both internal interfaces, e.g. between tiers, as well as external ones, e.g. those comprising the attack surface.

The six main security mechanisms to consider are authentication, authorization, input validation, output encoding, error handling and logging. Where relevant, also consider the mechanisms of cryptography and session management. For each interface, determine where in the system design each mechanism is provided and note any missing or unclear features as findings.

This analysis should be conducted by security-savvy staff with assistance from the project team for application-specific knowledge. This analysis should be performed once per release, usually toward the end of the design phase. After initial analysis, subsequent releases are required to update the findings based on changes being made during the development cycle.

===B. Deploy design review service for project teams===
Institute a process whereby project stakeholders can request a design review. This service may be provided centrally within the organization or distributed across existing staff, but all reviewers must be trained on performing the reviews completely and consistently.

The review service should be centrally managed in that the review request queue should be triaged by senior managers, architects, and stakeholders that are familiar with the overall business risk profile for the organization. This allows prioritization of project reviews in alignment with overall business risk.

During a design review, the review team should work with project teams to collect information sufficient to formulate an understanding of the attack surface, match project-specific security requirements to design elements, and verify security mechanisms at module interfaces.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-DR-2]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-DR-2]]

SAMM - Design Review - 1

2015-04-20T00:46:28Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Design_Review|abbr=DR|border1=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Verification http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveV1|name=Design Review|obj=Support ad hoc reviews of software design to ensure baseline mitigations for known risks}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* High-level understanding of security implications from perimeter architecture
* Enable development teams to self-check designs for security best-practices
* Lightweight process for conducting project-level design reviews

====Success Metrics====
* >50% of projects with updated attack surface analysis in past 12 months
* >50% of projects with updated security requirements design-level analysis in past 12 months

====Costs====
* Buildout and maintenance of architecture diagrams for each project
* Ongoing project overhead from attack surface and security requirement design inspection

====Personnel====
* Architects (2-3 days/yr)
* Developers (1-2 days/yr)
* Managers (1 day/yr)
* Security Auditor (1 day/yr)

====Related Levels====
* Security Requirements - 1

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Identify software attack surface===
For each software project, create a simplified view of the overall architecture. Typically, this should be created based on project artifacts such as high-level requirements and design documents, interviews with technical staff, or module-level review of the code base. It is important to capture the high-level modules in the system, but a good rule of thumb for granularity is to ensure that the diagram of the whole system under review fits onto one page.

From the single page architecture view, analyze each component in terms of accessibility of the interfaces from authorized users, anonymous users, operators, application-specific roles, etc. The components providing the interfaces should also be considered in the context of the one-page view to find points of functional delegation or data pass-through to other components on the diagram. Group interfaces and components with similar accessibility profiles and capture this as the software attack surface.

For each interface, further elaborate the one-page diagram to note any security-related functionality. Based on the identified interface groups comprising the attack surface, check the model for design-level consistency for how interfaces with similar access are secured. Any breaks in consistency can be noted as assessment findings

This analysis should be conducted by security-savvy technical staff, either within the project team or external. Typically, after initial creation, the diagram and attack surface analysis only needs to be updated during the design phase when additions or changes are made to the edge system interfaces.

===B. Analyze design against known security requirements===
Security requirements, either formally identified or informally known, should be identified and collected. Additionally, identify and include any security assumptions upon which safe operation of the system relies.

Review each item on the list of known security requirements against the one-page diagram of the system architecture. Elaborate the diagram to show the design-level features that address each security requirement. Separate, granular diagrams can be created to simplify capturing this information if the system is large and/or complex. The overall goal is to verify that each known security requirement has been addressed by the system design. Any security requirements that are not clearly provided at the design level should be noted as assessment findings.

This analysis should be conducted by security-savvy technical staff with input from architects, developers, managers, and business owners as needed. It should be updated during the design phase when there are changes in security requirements or high-level system design.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-DR-1]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-DR-1]]

SAMM - Secure Architecture - 3

2015-04-20T00:45:40Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Secure_Architecture|abbr=SA|border3=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Construction http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveC3|name=Secure Architecture|obj=Formally control the software design process and validate utilization of secure components}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Customized application development platforms that provide built-in security protections
* Organization-wide expectations for proactive security effort in development
* Stakeholders better able to make tradeoff decisions based on business need for secure design

====Add’l Success Metrics====
* >50% of active projects using reference platforms
* >80% of projects reporting framework, pattern, and platform usage feedback in past 6 months
* >3.0 Likert on usefulness of guidance/platforms reported by project teams

====Add’l Costs====
* Buildout or license of reference platform(s)
* Ongoing maintenance and support of reference platforms
* Ongoing project overhead from usage validation during audit

====Add’l Personnel====
* Managers (1 day/yr)
* Business Owners (1 day/yr)
* Architects (3-4 days/yr)
* Developers (2-3 days/yr)
* Security Auditors (2 days/yr)

====Related Levels====
* Policy & Compliance - 2
* Design Review - 3
* Code Review - 3
* Security Testing - 3

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Establish formal reference architectures and platforms===
After promoting integration with shared security services and working with security patterns specific to each type of architecture, a collection of code implementing these pieces of functionality should be selected from project teams and used as the basis for a shared code-base. This shared code-base can initially start as a collection of commonly recommended libraries that each project needs to use and it can grow over time into one or more software frameworks representing reference platforms upon which project teams build their software. Examples of reference platforms include frameworks for model-view-controller web applications, libraries supporting transactional back-end systems, frameworks for web services platforms, scaffolding for client-server applications, frameworks for middle-ware with pluggable business logic, etc.

Another method of building initial reference platforms is to select a particular project early in the life-cycle and have security-savvy staff work with them to build the security functionality in a generic way so that it could be extracted from the project and utilized elsewhere in the organization.

Regardless of approach to creation, reference platforms have advantages in terms of speeding audit and security-related reviews, increasing efficiency in development, and lowering maintenance overhead.

Architects, senior developers and other technical stakeholders should participate in design and creation of reference platforms. After creation, a team must maintain ongoing support and updates.

===B. Validate usage of frameworks, patterns, and platforms===
During routine audits of projects conduct additional analysis of project artifacts to measure usage of recommended frameworks, design patterns, shared security services, and reference platforms. Though conducted during routine audits, the goal of this activity is to collect feedback from project teams as much as to measure their individual proactive security effort.

Overall, it is important to verify several factors with project teams. Identify use of non-recommended frameworks to determine if there may be a gap in recommendations versus the organization’s functionality needs. Examine unused or incorrectly used design patterns and reference platform modules to determine if updates are needed. Additionally, there may be more or different functionality that project teams would like to see implemented in the reference platforms as the organization evolves.

This analysis can be conducted by any security-savvy technical staff. Metrics collected from each project should be collated for analysis by managers and stakeholders.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-SA-3]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-SA-3]]

SAMM - Secure Architecture - 2

2015-04-20T00:45:20Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Secure_Architecture|abbr=SA|border2=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Construction http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveC2|name=Secure Architecture|obj=Direct the software design process toward known-secure services and secure-by-default designs}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Detailed mapping of assets to user roles to encourage better compartmentalization in design
* Reusable design building blocks for provision of security protections and functionality
* Increased confidence for software projects from use of established design techniques for security

====Add’l Success Metrics====
* >80% of projects with updated permission matrix in past 6 months
* >80% of project teams briefed on applicable security patterns in past 6 months

====Add’l Costs====
* Buildout or license of applicable security patterns
* Ongoing project overhead from maintenance of permission matrix

====Add’l Personnel====
* Architects (2-4 days/yr)
* Developers (1-2 days/yr)
* Managers (1-2 days/yr)
* Business Owners (1 day/yr)
* Security Auditors (1-2 days/yr)

====Related Levels====
* Education & Guidance - 1

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Identify and promote security services and infrastructure===
Organizations should identify shared infrastructure or services with security functionality. These will typically include single-sign-on services, corporate directory systems, access control or entitlements services, and authentication systems. By collecting and evaluating reusable systems, assemble a list of such resources and categorize them by the security mechanism they fulfill. It is also helpful to consider each resource in terms of why a development team would want to integrate with it, i.e. the benefits of using the shared resource.

If multiple resources exist in each category, an organization should select and standardize on one or more shared service per category. Because future software development will rely on these selected services, each should be thoroughly audited to ensure the baseline security posture is understood. For each selected service, design guidance should be created for development teams to understand how to integrate with the system. After such guidance is assembled, it should be made available to development teams through training, mentorship, guidelines, and standards.

The benefits of doing this include promotion of known-secure systems, simplified security guidance for project design teams, and clearer paths to building assurance around the applications utilizing the shared security services.

===B. Identify security design patterns from architecture===
Across software projects at an organization, each should be categorized in terms of the generic architecture type. Common categories include client-server applications, embedded systems, desktop applications, web-facing applications, web services platforms, transactional middleware systems, mainframe applications, etc. Depending on your organizations specialty, more detailed categories may need to be developed based upon language, or processor architecture, or even era of deployment.

For the generic software architecture type, a set of general design patterns representing sound methods of implementing security functionality can be derived and applied to the individual designs of an organization’s software projects. These security design patterns represent general definitions of generic design elements they can be researched or purchased, and it is often even more effective if these patterns are customized to be made more specific to your organization. Example patterns include a single-sign-on subsystem, a cross-tier delegation model, a hardened interface design, separation-of-duties authorization model, a centralized logging pattern, etc.

The process of identification of applicable and appropriate patterns should be carried out by architects, senior developers, and other technical stakeholders during the design phase.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-SA-2]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-SA-2]]

SAMM - Secure Architecture - 1

2015-04-20T00:45:01Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Secure_Architecture|abbr=SA|border1=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Construction http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveC1|name=Secure Architecture|obj=Insert consideration of proactive security guidance into the software design process}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Ad hoc prevention of unexpected dependencies and one-off implementation choices
* Stakeholders aware of increased project risk due to libraries and frameworks chosen
* Established protocol within development for proactively applying security mechanisms to a design

====Success Metrics====
* >80% of development staff briefed on software framework recommendations in past 1 year
* >50% of projects self-reporting application of security principles to design

====Costs====
* Buildout, maintenance, and awareness of software framework recommendations
* Ongoing project overhead from analysis and application of security principles

====Personnel====
* Architects (2-4 days/yr)
* Developers (2-4 days/yr)
* Security Auditors (2-4 days/yr)
* Managers (2 days/yr)

====Related Levels====
* Education & Guidance - 1

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Maintain list of recommended software frameworks===
Across software projects within the organization identify commonly used third-party software libraries and frameworks in use. Generally, this need not be an exhaustive search for dependencies, but rather focus on capturing the high-level components that are most often used.

From the list of components, group them into functional categories based on the core features provided by the third-party component. Also, note the usage prevalence of each component across project teams to weight the reliance upon the third-party code. Using this weighted list as a guide, create a list of components to be advertised across the development organization as recommended components.

Several factors should contribute to decisions for inclusion on the recommended list. Although a list can be created without conducting research specifically, it is advisable to inspect each for incident history, track record for responding to vulnerabilities, appropriateness of functionality for the organization, excessive complexity in usage of the third-party component, etc.

This list should be created by senior developers and architects, but also include input from managers and security auditors. After creation, this list of recommended components matched against functional categories should be advertised to the development organization. Ultimately, the goal is to provide well-known defaults for project teams.

===B. Explicitly apply security principles to design===
During design, technical staff on the project team should use a short list of guiding security principles as a checklist against detailed system designs. Typically, security principles include defense in depth, securing the weakest link, use of secure defaults, simplicity in design of security functionality, secure failure, balance of security and usability, running with least privilege, avoidance of security by obscurity, etc.

In particular for perimeter interfaces, the design team should consider each principle in the context of the overall system and identify features that can be added to bolster security at each such interface. Generally, these should be limited such that they only take a small amount of extra effort beyond the normal implementation cost of functional requirements and anything larger should be noted and scheduled for future releases.

While this process should be conducted by each project team after being trained with security awareness, it is helpful to incorporate more security-savvy staff to aide in making design decisions.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-SA-1]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-SA-1]]

SAMM - Security Requirements - 3

2015-04-20T00:44:17Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Security_Requirements|abbr=SR|border3=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Construction http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveC3|name=Security Requirements|obj=Mandate security requirements process for all software projects and third-party dependencies}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Formally set baseline for security expectations from external code
* Centralized information on security effort undertaken by each project team
* Ability to align resources to projects based on application risk and desired security requirements

====Add’l Success Metrics====
* >80% of projects passing security requirements audit in past 6 months
* >80% of vendor agreements analyzed for contractual security requirements in past 12 months

====Add’l Costs====
* Increased cost from outsourced development from additional security requirements
* Ongoing project overhead from release gates for security requirements

====Add’l Personnel====
* Security Auditor (2 days/yr)
* Managers (2 days/yr)
* Business Owners (1 day/yr)

====Related Levels====
* Threat Assessment - 3
* Policy & Compliance - 2

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Build security requirements into supplier agreements===
Beyond the kinds of security requirements already identified by previous analysis, additional security benefits can be derived from third-party agreements. Typically, requirements and perhaps high-level design will be developed internally while detailed design and implementation is often left up to suppliers.

Based on the specific division of labor for each externally developed component, identify specific security activities and technical assessment criteria to add to the vendor contracts. Commonly, this is a set of activities from the Design Review, Code Review, and Security Testing Practices.

Modifications of agreement language should be handled on a case-by-case basis with each supplier since adding additional requirements will generally mean an increase in cost. The cost of each potential security activity should be balanced against the benefit of the activity as per the usage of the component or system being considered.

===B. Expand audit program for security requirements===
Incorporate checks for completeness of security requirements into routine project audits. Since this can be difficult to gauge without project-specific knowledge, the audit should focus on checking project artifacts such as requirements or design documentation for evidence that the proper types of analysis were conducted.

Particularly, each functional requirement should be annotated with security requirements based on business drivers as well as expected abuse scenarios. The overall project requirements should contain a list of requirements generated from best-practices in guidelines and standards. Additionally, there should be a clear list of unfulfilled security requirements and an estimated timeline for their provision in future releases.

This audit should be performed during every development iteration, ideally toward the end of the requirements process, but it must be performed before a release can be made.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-SR-3]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-SR-3]]

SAMM - Security Requirements - 2

2015-04-20T00:43:50Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Security_Requirements|abbr=SR|border2=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Construction http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveC2|name=Security Requirements|obj=Increase granularity of security requirements derived from business logic and known risks}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Detailed understanding of attack scenarios against business logic
* Prioritized development effort for security features based on likely attacks
* More educated decision-making for tradeoffs between features and security efforts
* Stakeholders that can better avoid functional requirements that inherently have security flaws

====Add’l Success Metrics====
* >75% of all projects with updated abuse-case models within past 6 months

====Add’l Costs====
* Project overhead from buildout and maintenance of abuse-case models

====Add’l Personnel====
* Security Auditor (2 days/yr)
* Managers (1 day/yr)
* Architects (2 days/yr)
* Business Owners (1 day/yr)

====Related Levels====
* Threat Assessment - 1 & 3
* Strategy & Metrics - 1

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Build an access control matrix for resources and capabilities===
Based upon the business purpose of the application, identify user and operator roles. Additionally, build a list of resources and capabilities by gathering all relevant data assets and application-specific features that are guarded by any form of access control.

In a simple matrix with roles on one axis and resources on the other, consider the relationships between each role and each resource and note in each intersection the correct behavior of the system in terms of access control according to stakeholders.

For data resources, it is important to note access rights in terms of creation, read access, update, and deletion. For resources that are features, gradation of access rights will likely be application-specific, but at a minimum note if the role should be permitted access to the feature.

This permission matrix will serve as an artifact to document the correct access control rights for the business logic of the overall system. As such, it should be created by the project teams with input from business stakeholders. After initial creation, it should be updated by business stakeholders before every release, but usually toward the beginning of the design phase.

===B. Specify security requirements based on known risks===
Explicitly review existing artifacts that indicate organization or project-specific security risk in order to better understand the overall risk profile for the software. When available, draw on resources such as the high-level business risk profile, individual application threat models, findings from design review, code review, security testing, etc.

In addition to review of existing artifacts, use abuse-case models for an application to serve as fuel for identification of concrete security requirements that directly or indirectly mitigate the abuse scenarios.

This process should be conducted by business owners and security auditors as needed. Ultimately, the notion of risks leading to new security requirements should become a built-in step in the planning phase whereby newly discovered risks are specifically assessed by project teams.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-SR-2]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-SR-2]]

SAMM - Security Requirements - 1

2015-04-20T00:43:29Z

David Fern:

SAMM - Threat Assessment - 3

2015-04-20T00:42:38Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Threat_Assessment|abbr=TA|border3=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Construction http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveC3|name=Threat Assessment|obj=Concretely tie compensating controls to each threat against internal and third-party software}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Deeper consideration of full threat profile for each software project
* Detailed mapping of assurance features to established threats against each software project
* Artifacts to document due diligence based on business function of each software project

====Add’l Success Metrics====
* >80% of project teams with updated threat models prior to every implementation cycle
* >80% of project teams with updated inventory of third-party components prior to every release
* >50% of all security incidents identified a priori by threat models in past 12 months

====Add’l Costs====
* Project overhead from maintenance of detailed threat models and expanded attacker profiles
* Discovery of all third-party dependencies

====Add’l Personnel====
* Business Owners (1 day/yr)
* Developers (1 day/yr)
* Architects (1 day/yr)
* Security Auditors (2 day/yr)
* Managers (1 day/yr)

====Related Levels====
* Security Requirements - 2 & 3

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Explicitly evaluate risk from third-party components===
Conduct an assessment of your software code-base and identify any components that are of external origin. Typically, these will include open-source projects, purchased COTS software, and online services which your software uses.

For each identified component, elaborate attacker profiles for the software project based upon potential compromise of third-party components. Based upon the newly identified attacker profiles, update software threat models to incorporate any likely risks based upon new attacker goals or capabilities.

In addition to threat scenarios, also consider ways in which vulnerabilities or design flaws in the third-party software might affect your code and design. Elaborate your threat models accordingly with the potential risks from vulnerabilities and knowledge of the updated attacker profile.

After initially conducted for a project, this must be updated and reviewed during the design phase or every development cycle. This activity should be conducted by a security auditor with relevant technical and business stakeholders.

===B. Elaborate threat models with compensating controls===
Conduct an assessment to formally identify factors that directly prevent preconditions for compromise represented by the threat models. These mitigating factors are the compensating controls that formally address the direct risks from software. Factors can be technical features in the software itself, but can also be process elements in the development life-cycle, infrastructure features, etc.

If using attack trees, the logical relationship represented by each branch will be either an AND or an OR. Therefore, by mitigating against just one precondition on an AND branch, the parent and all connected leaf nodes can be marked as mitigated. However, all child nodes on an OR node must be prevented before the parent can be marked as mitigated.

Regardless of threat modeling technique, identify compensating controls and annotate the threat models directly. The goal is to maximize coverage in terms of controls that mark parts of the threat model as mitigated. For any viable paths remaining, identify potential compensating controls for feedback into organizational strategy.

After initially conducted for a project, this must be updated and reviewed during the design phase or every development cycle. This activity should be conducted by a security auditor with relevant technical and business stakeholders.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-TA-3]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-TA-3]]

SAMM - Threat Assessment - 2

2015-04-20T00:42:15Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Threat_Assessment|abbr=TA|border2=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Construction http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveC2|name=Threat Assessment|obj=Increase accuracy of threat assessment and improve granularity of per-project understanding}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Granular understanding of likely threats to individual projects
* Framework for better tradeoff decisions within project teams
* Ability to prioritize development efforts within a project team based on risk weighting

====Add’l Success Metrics====
* >75% of project teams with identified and rated threats
* >75% of project stakeholders briefed on threat and abuse models of relevant projects within past 6 months

====Add’l Costs====
* Project overhead from maintenance of threat models and attacker profiles

====Add’l Personnel====
* Security Auditor (1 day/yr)
* Business Owner (1 day/yr)
* Managers (1 day/yr)

====Related Levels====
* Strategy & Metrics - 2
* Secure Architecture - 2

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Build and maintain abuse-case models per project===
Further considering the threats to the organization, conduct a more formal analysis to determine potential misuse or abuse of functionality. Typically, this process begins with identification of normal usage scenarios, e.g. use-case diagrams if available.

If a formal abuse-case technique isn’t used, generate a set of abuse-cases for each scenario by starting with a statement of normal usage and brainstorming ways in which the statement might be negated, in whole or in part. The simplest way to get started is to insert the word “no” or “not” into the usage statement in as many ways as possible, typically around nouns and verbs. Each usage scenario should generate several possible abuse-case statements.

Further elaborate the abuse-case statements to include any application-specific concerns based on the business function of the software. The ultimate goal is for the completed set of abuse statements to form a model for usage patterns that should be disallowed by the software. If desired, these abuse cases can be combined with existing threat models.

After initial creation, abuse-case models should be updated for active projects during the design phase. For existing projects, new requirements should be analyzed for potential abuse, and existing projects should opportunistically build abuse-cases for established functionality where practical.

===B. Adopt a weighting system for measurement of threats===
Based on the established attacker profiles, identify a rating system to allow relative comparison between the threats. Initially, this can be a simple high-medium-low rating based upon business risk, but any scale can be used provided that there are no more than 5 categories.

After identification of a rating system, build evaluation criteria that allow each threat to be assigned a rating. In order to do this properly, additional factors about each threat must be considered beyond motivation. Important factors include capital and human resources, inherent access privilege, technical ability, relevant goals on the threat model(s), likelihood of successful attack, etc.

After assigning each threat to a rating, use this information to prioritize risk mitigation activities within the development life-cycle. Once built for a project team, it should be updated during design of new features or refactoring efforts.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-TA-2]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-TA-2]]

SAMM - Education & Guidance - 3

2015-04-20T00:41:35Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Education_&_Guidance|abbr=EG|border3=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Governance http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveG3|name=Education & Guidance|obj=Mandate comprehensive security training and certify personnel for baseline knowledge}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Efficient remediation of vulnerabilities in both ongoing and legacy code bases
* Quickly understand and mitigate against new attacks and threats
* Judge security-savvy of staff and measure against a common standard
* Establish fair incentives toward security awareness

====Add’l Success Metrics====
* >80% staff certified within past 1 year

====Add’l Costs====
* Certification examination build-out or license
* Ongoing maintenance and change control for application security support portal
* Human-resources and overhead cost for implementing employee certification

====Add’l Personnel====
* Developers (1 day/yr)
* Architects (1 day/yr)
* Managers (1 day/yr)
* Business Owners (1 day/yr)
* QA Testers (1 day/yr)
* Security Auditors (1 day/yr)

====Related Levels====
* Policy & Compliance - 2 & 3

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Create formal application security support portal===
Building upon written resources on topics relevant to application security, create and advertise a centralized repository (usually an internal web site). The guidelines themselves can be created in any way that makes sense for the organization, but an approval board and straightforward change control processes must be established.

Beyond static content in the form of best-practices lists, tool-specific guides, FAQs, and other articles, the support portal should feature interactive components such as mailing lists, web-based forums, or wikis to allow internal resources to cross-communicate security relevant topics and have the information cataloged for future reference.

The content should be cataloged and easily searchable based upon several common factors such as platform, programming language, pertinence to specific third party libraries or frameworks, life-cycle stage, etc. Project teams creating software should align themselves early in product development to the specific guidelines that they will follow. In product assessments, the list of applicable guidelines and product-related discussions should be used as audit criteria.

===B. Establish role-based examination/certification===
Either per role or per training class/module, create and administer aptitude exams that test people for comprehension and utilization of security knowledge. Typically, exams should be created based on the role-based curricula and target a minimum passing score around 75% correct. While staff should be required to take applicable training or refresher courses annually, certification exams should be required biannually at a minimum.

Based upon pass/fail criteria or exceptional performance, staff should be ranked into tiers such that other security-related activities could require individuals of a particular certification level to sign-off before the activity is complete, e.g. an uncertified developer cannot pass a design into implementation without explicit approval from a certified architect. This provides granular visibility on an per-project basis for tracking security decisions with individual accountability. Overall, this provides a foundation for rewarding or penalizing staff for making good business decisions regarding application security.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-EG-3]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-EG-3]]

SAMM - Education & Guidance - 2

2015-04-20T00:41:11Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Education_&_Guidance|abbr=EG|border2=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Governance http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveG2|name=Education & Guidance|obj=Educate all personnel in the software life-cycle with role-specific guidance on secure development}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* End-to-end awareness of the issues that leads to security vulnerabilities at the product, design, and code levels
* Build plans to remediate vulnerabilities and design flaws in ongoing projects
* Enable qualitative security checkpoints at requirements, design, and development stages
* Deeper understanding of security issues encourages more proactive security planning

====Add’l Success Metrics====
* >60% development staff trained within past 1 year
* >50% management/analyst staff trained within past 1 year
* >80% senior development/architect staff trained within past 1 year
* >3.0 Likert on usefulness of training courses

====Add’l Costs====
* Training library build-out or license
* Security-savvy staff for hands-on coaching

====Add’l Personnel====
* Developers (2 days/yr)
* Architects (2 days/yr)
* Managers (1-2 days/yr)
* Business Owners (1-2 days/yr)
* QA Testers (1-2 days/yr)
* Security Auditors (1-2 days/yr)

====Related Levels====
* Vulnerability Management - 1
* Design Review - 2
* Secure Architecture - 2

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Conduct role-specific application security training===
Conduct security training for staff that highlights application security in the context of each role’s job function. Generally, this can be accomplished via instructor-led training in 1-2 days or via computer-based training with modules taking about the same amount of time per person.

For managers and requirements specifiers, course content should feature security requirements planning, vulnerability and incident management, threat modeling, and misuse/abuse case design.

Tester and auditor training should focus on training staff to understand and more effectively analyze software for security-relevant issues. As such, it should feature techniques for code review, architecture and design analysis, runtime analysis, and effective security test planning.

Expand technical training targeting developers and architects to include other relevant topics such as security design patterns, tool-specific training, threat modeling and software assessment techniques.

To rollout such training, it is recommended to mandate annual security awareness training and periodic specialized topics training. Course should be available (either instructor-led or computer-based) as often as required based on head-count per role.

===B. Utilize security coaches to enhance project teams===
Using either internal or external experts, make security-savvy staff available to project teams for consultation. Further, this coaching resource should be advertised internally to ensure that staff are aware of its availability.

The coaching staff can be created by recruiting experienced individuals within the organization to spend some percentage of their time, around 10% maximum, performing coaching activities. The coaches should communicate between one another to ensure they are aware of each other’s area of expertise and route questions accordingly for efficiency.

While coaches can be used at any point in the software life-cycle, appropriate times to use the coaches include during initial product conception, before completion of functional or detailed design specification(s), when issues arise during development, test planning, and when operational security incidents occur.

Over time, the internal network of coaching resources can be used as points-of-contact for communicating security-relevant information throughout the organization as well as being local resources that have greater familiarity with the ongoing project teams than a purely centralized security team might.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-EG-2]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-EG-2]]

SAMM - Policy & Compliance - 3

2015-04-20T00:40:03Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Policy_&_Compliance|abbr=PC|border3=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Governance http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveG3|name=Policy & Compliance|obj=Require compliance and measure projects against organization-wide policies and standards}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Organization-level visibility of accepted risks due to non-compliance
* Concrete assurance for compliance at the project level
* Accurate tracking of past project compliance history
* Efficient audit process leveraging tools to cut manual effort

====Add’l Success Metrics====
* >80% projects in compliance with policies and standards as seen by audit
* <50% time per audit as compared to manual

====Add’l Costs====
* Buildout or license tools to automate audit against internal standards
* Ongoing maintenance of audit gates and exception process

====Add’l Personnel====
* Developers (1 days/yr)
* Architects (1 days/yr)
* Managers (1 days/yr)

====Related Levels====
* Education & Guidance - 3
* Code Review - 2
* Security Testing - 2

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Create compliance gates for projects===
Once an organization has established internal standards for security, the next level of enforcement is to set particular points in the project life-cycle where a project cannot pass until it is audited against the internal standards and found to be in compliance.

Usually, the compliance gate is placed at the point of software release such that they are not allowed to publish a release until the compliance check is passed. It is important to provide enough time for the audit to take place and remediation to occur, so generally the audit should begin earlier, for instance when a release is given to QA.

Despite being a firm compliance gate, legacy or other specialized projects may not be able to comply, so an exception approval process must also be created. No more than about 20% of all projects should have exception approval.

===B. Adopt solution for audit data collection===
Organizations conducting regular audits of project teams generate a large amount of audit data over time. Automation should be utilized to assist in automated collection, manage collation for storage and retrieval, and to limit individual access to sensitive audit data.

For many concrete requirements from the internal standards, existing tools such as code analyzers, application penetration testing tools, monitoring software, etc. can be customized and leveraged to automate compliance checks against internal standards. The purpose of automating compliance checks is to both improve efficiency of audit as well as enable more staff to self-check for compliance before a formal audit takes place. Additionally, automated checks are less error-prone and allow for lower latency on discovery of problems.

Information storage features should allow centralized access to current and historic audit data per project. Automation solutions must also provide detailed access control features to limit access to approved individuals with valid business purpose for accessing the audit data.

All instructions and procedures related to accessing compliance data as well as requesting access privileges should be advertised to project teams. Additional time may be initially required from security auditors to bootstrap project teams.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-PC-3]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-PC-3]]

SAMM - Policy & Compliance - 2

2015-04-20T00:39:39Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Policy_&_Compliance|abbr=PC|border2=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Governance http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveG2|name=Policy & Compliance|obj=Establish security and compliance baseline and understand per-project risks}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Awareness for project teams regarding expectations for both security and compliance
* Business owners that better understand specific compliance risks in their product lines
* Optimized approach for efficiently meeting compliance with opportunistic security improvement

====Add’l Success Metrics====
* >75% of staff briefed on policies and standards in past 6 months
* >80% stakeholders aware of compliance status against policies and standards

====Add’l Costs====
* Internal standards buildout or license
* Per-project overhead from compliance with internal standards and audit

====Add’l Personnel====
* Architects (1 days/yr)
* Managers (1 days/yr)
* Security Auditors (2 days/project/yr)

====Related Levels====
* Education & Guidance - 1 & 3
* Strategy & Metrics - 2
* Security Requirements - 1 & 3
* Secure Architecture - 3
* Code Review - 3
* Design Review - 3
* Environment Hardening - 3

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Build policies and standards for security and compliance===
Beginning with a current compliance guidelines, review regulatory standards and note any optional or recommended security requirements. Also, the organization should conduct a small amount of research to discover any potential future changes in compliance requirements that are relevant.

Augment the list with any additional requirements based on known business drivers for security. Often it is simplest to consult existing guidance being provided to development staff and gather a set of best practices.

Group common/similar requirements and rewrite each group as more generalized/simplified statements that meet all the compliance drivers as well as provide some additional security value. Work through this process for each grouping with the goal of building a set of internal policies and standards that can be directly mapped back to compliance drivers and best practices.

It is important for the set of policies and standards to not contain requirements that are too difficult or excessively costly for project teams to comply. A useful heuristic is that approximately 80% of projects should be able to comply with minimal disruption. This requires a good communications program being set up to advertise the new policies/standards and assist teams with compliance if needed.

===B. Establish project audit practice===
Create a simple audit process for project teams to request and receive an audit against internal standards. Audits are typically performed by security auditors but can also be conducted by security-savvy staff as long as they are knowledgeable about the internal standards.

Based upon any known business risk indicators, projects can be prioritized concurrently with audit queue triage such that high-risk software is assessed sooner or more frequently. Additionally, low-risk projects can have internal audit requirements loosened to make the audit practice more cost-effective.

Overall, each active project should undergo an audit at least biannually. Generally, subsequent audits after the initial will be simpler to perform if sufficient audit information about the application is retained.

Advertise this service to business owners and other stakeholders so that they may request an audit for their projects. Detailed pass/fail results per requirement from the internal standards should be delivered to project stakeholders for evaluation. Where practical, audit results should also contain explanations of impact and remediation recommendations.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-PC-2]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-PC-2]]

SAMM - Policy & Compliance - 1

2015-04-20T00:39:17Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Policy_&_Compliance|abbr=PC|border1=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Governance http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveG1|name=Policy & Compliance|obj=Understand relevant governance and compliance drivers to the organization}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Increased assurance for handling third-party audit with positive outcome
* Alignment of internal resources based on priority of compliance requirements
* Timely discovery of evolving regulatory requirements that affect your organization

====Success Metrics====
* >1 compliance discovery meeting in past 6 months
* Compliance checklist completed and updated within past 6 months
* >1 compliance review meeting with stakeholders in past 6 months

====Costs====
* Initial creation and ongoing maintenance of compliance checklist

====Personnel====
* Architects (1 day/yr)
* Managers (2 days/yr)
* Business Owners (1-2 days/yr)

====Related Levels====
* Strategy & Metrics - 1

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Identify and monitor external compliance drivers===
While an organization might have a wide variety of compliance requirements, this activity is specifically oriented around those that either directly or indirectly affect the way in which the organization builds or uses software and/or data. Leverage internal staff focused on compliance if available.

Based on the organization’s core business, conduct research and identify third-party regulatory standards with which compliance is required or considered an industry norm. Possibilities include the Sarbanes-Oxley Act (SOX), the Payment Card Industry Data Security Standards (PCI-DSS), the Health Insurance Portability and Accountability Act (HIPAA), etc. After reading and understanding each third-party standard, collect specific requirements related to software and data and build a consolidated list that maps each driver (third-party standard) to each of its specific requirements for security. At this stage, try to limit the amount of requirements by dropping anything considered optional or only recommended.

At a minimum, conduct research at least biannually to ensure the organization is keeping updated on changes to third-party standards. Depending upon the industry and the importance of compliance, this activity can vary in effort and personnel involvement, but should always be done explicitly.

===B. Build and maintain compliance guidelines===
Based upon the consolidated list of software and data-related requirements from compliance drivers, elaborate the list by creating a corresponding response statement to each requirement. Sometimes called control statements, each response should capture the concept of what the organization does to ensure the requirement is met (or to note why it does not apply).

Since typical audit practice often involves checking a control statement for sufficiency and then measuring the organization against the control statement itself, it is critical that they accurately represent actual organizational practices. Also, many requirements can be met by instituting simple, lightweight process elements to cover base-line compliance prior to evolving the organization for better assurance down the road.

Working from the consolidated list, identify major gaps to feed the future planning efforts with regard to building the assurance program. Communicate information about compliance gaps with stakeholders to ensure awareness of the risk from non-compliance.

At a minimum, update and review control statements with stakeholders at least biannually. Depending on the number of compliance drivers, it may make sense to perform updates more often.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-PC-1]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-PC-1]]

SAMM - Code Review - 3

2015-04-20T00:36:41Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Code_Review|abbr=CR|border3=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Verification http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveV3|name=Code Review|obj=Mandate comprehensive code review process to discover language-level and application-specific risks}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Increased confidence in accuracy and applicability of code analysis results
* Organization-wide baseline for secure coding expectations
* Project teams with an objective goal for judging code-level security

====Add’l Success Metrics====
* >50% of projects using code analysis customizations
* >75% of projects passing code review audit in past 6 months

====Add’l Costs====
* Buildout and maintenance of custom code review checks
* Ongoing project overhead from code review audit
* Organization overhead from project delays caused by failed code review audits

====Add’l Personnel====
* Architects (1 day/yr)
* Developers (1 day/yr)
* Security Auditors (1-2 days/yr)
* Business Owners (1 day/yr)
* Managers (1 day/yr)

====Related Levels====
* Policy & Compliance - 2
* Secure Architecture - 3

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Customize code analysis for application-specific concerns===
Code scanning tools are powered by built-in a knowledge-base of rules to check code based on language APIs and commonly used libraries, but have limited ability to understand custom APIs and designs to apply analogous checks. However, through customization, a code scanner can be a powerful, generic analysis engine for finding organization and project-specific security concerns.

While details vary between tools in terms of ease and power of custom analysis, code scanner customization generally involves specifying checks to be performed at specific APIs and function call sites. Checks can include analysis for adherence to internal coding standards, unchecked tainted data being passed to custom interfaces, tracking and verification of sensitive data handling, correct usage of an internal API, etc.

Checkers for usage of shared code-bases are an effective place to begin scanner customizations since the created checkers can be utilized across multiple projects. To customize a tool for a code-base, a security auditor should inspect both code and high-level design to identify candidate checkers to discuss with development staff and stakeholders for implementation.

===B. Establish release gates for code review===
To set a code-level security baseline for all software projects, a particular point in the software development life-cycle should be established as a checkpoint where a minimum standard for code review results must be met in order to make a release.

To begin, this standard should be straightforward to meet, for example by choosing one or two vulnerability types and a setting the standard that no project may pass with any corresponding findings. Over time, this baseline standard should be improved by adding additional criteria for passing the checkpoint.

Generally, the code review checkpoint should occur toward the end of the implementation phase, but must occur before release.

For legacy systems or inactive projects, an exception process should be created to allow those projects to continue operations, but with an explicitly assigned timeframe for mitigation of findings. Exceptions should be limited to no more that 20% of all projects.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-CR-3]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-CR-3]]

SAMM - Strategy & Metrics - 3

2015-04-20T00:34:10Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Strategy_&_Metrics|abbr=SM|border3=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Governance http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveG3|name=Strategy & Metrics|obj=Align security expenditure with relevant business indicators and asset value}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Information to make informed case-by-case decisions on security expenditures
* Estimates of past loss due to security issues
* Per-project consideration of security expense versus loss potential
* Industry-wide due diligence with regard to security

====Add’l Success Metrics====
* >80% of projects reporting security costs in past 3 months
* >1 industry-wide cost comparison in past 1 year
* >1 historic security spend evaluation in past 1 year

====Add’l Costs====
* Buildout or license industry intelligence on security programs
* Program overhead from cost estimation, tracking, and evaluation

====Add’l Personnel====
* Architects (1 days/yr)
* Managers (1 days/yr)
* Business Owners (1 days/yr)
* Security Auditor (1 days/yr)

====Related Levels====
* Vulnerability Management - 1

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Conduct periodic industry-wide cost comparisons===
Research and gather information about security costs from intra-industry communication forums, business analyst and consulting firms, or other external sources. In particular, there are a few key factors that need to be identified.

First, use collected information to identify the average amount of security effort being applied by similar types of organizations in your industry. This can be done either top-down from estimates of total percentage of budget, revenue, etc. or it can be done bottom-up by identifying security-related activities that are considered normal for your type of organization. Overall, this can be hard to gauge for certain industries, so collect information from as many relevant sources as are accessible.

The next goal of researching security costs is to determine if there are potential cost savings on third-party security products and services that your organization currently uses. When weighing the decision of switching vendors, account for hidden costs such as retraining staff or other program overhead.

Overall, these cost-comparison exercises should be conducted at least annually prior to the subsequent assurance program strategy session. Comparison information should be presented to stakeholders in order to better align the assurance program with the business.

===B. Collect metrics for historic security spend===
Collect project-specific information on the cost of past security incidents. For instance, time and money spent in cleaning up a breach, monetary loss from system outages, fines and fees to regulatory agencies, project-specific one-off security expenditures for tools or services, etc.

Using the application risk categories and the respective prescribed assurance program roadmaps for each, a baseline security cost for each application can be initially estimated from the costs associated with the corresponding risk category.

Combine the application-specific cost information with the general cost model based on risk category, and then evaluate projects for outliers, i.e. sums disproportionate to the risk rating. These indicate either an error in risk evaluation/classification or the necessity to tune the organization’s assurance program to address root causes for security cost more effectively.

The tracking of security spend per project should be done quarterly at the assurance program strategy session, and the information should be reviewed and evaluated by stakeholders at least annually. Outliers and other unforeseen costs should be discussed for potential affect on assurance program roadmap.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-SM-3]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-SM-3]]

SAMM - Strategy & Metrics - 2

2015-04-20T00:33:37Z

David Fern:

{{OpenSAMM}}
<div style="float:left; width:65%;">
{{SAMM-BadgeList|name=Strategy_&_Metrics|abbr=SM|border2=2}}
</div>
<div style="float:right; width:30%;">
[http://www.owasp.org/index.php/SAMM_-_Governance http://www.opensamm.org/downloads/BackButton.png]
</div>

<div style="width:100%; float:left;">
{{SAMM-ObjectiveG2|name=Strategy & Metrics|obj=Measure relative value of data and software assets and choose risk tolerance}}
<div style="width:30%; float:right; padding-top:50px; padding-left:10px;">
====Results====
* Customized assurance plans per project based on core value to the business
* Organization-wide understanding of security-relevance of data and application assets
* Better informed stakeholders with respect to understanding and accepting risks

====Add’l Success Metrics====
* >90% applications and data assets evaluated for risk classification in past 12 months
* >80% of staff briefed on relevant application and data risk ratings in past 6 months
* >80% of staff briefed on relevant assurance program roadmap in past 3 months

====Add’l Costs====
* Buildout or license of application and data risk categorization scheme
* Program overhead from more granular roadmap planning

====Add’l Personnel====
* Architects (2 days/yr)
* Managers (2 days/yr)
* Business Owners (2 days/yr)
* Security Auditor (2 days/yr)

====Related Levels====
* Policy & Compliance - 2
* Threat Assessment - 2
* Design Review - 2

</div>
<div style="float:left; width:65%;">
==Activities==
===A. Classify data and applications based on business risk===
Establish a simple classification system to represent risk-tiers for applications. In its simplest form, this can be a High/Medium/Low categorization. More sophisticated classifications can be used, but there should be no more than seven categories and they should roughly represent a gradient from high to low impact against business risks.

Working from the organization’s business risk profile, create project evaluation criteria that maps each project to one of the risk categories. A similar but separate classification scheme should be created for data assets and each item should be weighted and categorized based on potential impact to business risks.

Evaluate collected information about each application and assign each a risk category based upon overall evaluation criteria and the risk categories of data assets in use. This can be done centrally by a security group or by individual project teams through a customized questionnaire to gather the requisite information.

An ongoing process for application and data asset risk categorization should be established to assign categories to new assets and keep the existing information updated at least biannually.

===B. Establish and measure per-classification security goals===
With a classification scheme for the organization’s application portfolio in place, direct security goals and assurance program roadmap choices can be made more granular.

The assurance program’s roadmap should be modified to account for each application risk category by specifying emphasis on particular Practices for each category. For each iteration of the assurance program, this would typically take the form of prioritizing more higher-level Objectives on the highest risk application tier and progressively less stringent Objectives for lower/other categories.

This process establishes the organization’s risk tolerance since active decisions must be made as to what specific Objectives are expected of applications in each risk category. By choosing to keep lower risk applications at lower levels of performance with respect to the Security Practices, resources are saved in exchange for acceptance of a weighted risk. However, it is not necessary to arbitrarily build a separate roadmap for each risk category since that can leads to inefficiency in management of the assurance program itself.

</div>
</div>

<div style="float:left; width:100%;"><br/><br/><br/>
----
----
===Additional Resources===
[[:Category:SAMM-SM-2]]

</div>

__NOTOC__ __NOEDITSECTION__
[[Category:SAMM-SM-2]]

SAMM - Strategy & Metrics - 2

2015-04-20T00:32:34Z

David Fern:

SAMM - Strategy & Metrics - 2

2015-04-20T00:32:02Z

David Fern:

Projects/OWASP Mobile Security Project -2015 Scratchpad

2015-04-05T17:10:16Z

David Fern: /* Prominent Characteristics */

This is just a place to gather some ideas for the 2015 reworking of the Mobile Top Ten. It's totally unofficial open musings about truth, beauty, and justice.

=What is It?=

This is the "Mobile Top Ten" ''what''? It's the top 10 "stuff people tend to screw up", but here are some important questions.

* Business risk or technical risk? The business risk would be something like "intellectual property unprotected" or "customer data exposed." A technical risk would be something like "data stored in plain text files."

* Root cause, or final impact? Often root causes are things like not encrypting when we should. Final impact is stuff like unintended data leaks. The problem is that some of these things are overlapping. Not every lack of crypto is a data leak, but many are.

* What threats are in scope? There are apps that simply do not care about protecting from malware, jailbreaking, etc. Think Yelp: it's just restaurant reviews. No financial impact, no reason to care about many client-side attacks. Plenty of apps ''do'' care about client-side attacks. E.g., banking, communications, health data. Many items hinge on whether or not you care about client side attacks. How do we capture this?
** If you care about client-side attacks, then failing to encrypt stuff is basically a data leakage.
** If you don't care about client-side attacks, then failing to encrypt stuff is kinda "gee you should do that".
** If you care about client-side attacks, there are probably some platform features that are not sufficient as-is: the app sandbox, etc. You probably want to be putting your own additional layer of encryptiong / protection, etc.
** If you don't care about client-side attacks, then you simply need to be using the standard APIs (keychain, app data storage, etc.) in the standard supported ways.

=Who is it For?=

Do we intend this to be a tool that infosec / appsec people use? Do we intend lay people to make use of it? (e.g., developers and non-mobile IT security people) What does the target audience need to get from it?

(''Paco's opinion'') We need to have a narrative: If you found functionality that does X, it is probably in bucket A, unless it is also doing (or not doing) Y, in which case that's bucket B.

=Comments on Submitted Data=

==General==

(Jason) By looking at some data sets it becomes clear there is a doctrine that some consultancies use to do mobile testing. Some did not contribute m1 data, because they consider mobile security client-only. The same applied to m10. In addition, a couple of datasets used CWE IDs. These were harder to parse because generic CWE's do not specify if the vuln is client or server (and in a lot of these cases the vuln could be either). As Paco stated, code quality, source level findings are hard to categorize as well.

==BugCrowd==
I see “storing passwords in the clear” as a very common finding among their data. It gets classifed as M5 poor authentication, M2 insecure data storage, M4 data leakage, and sometimes M6 (broken crypto).

I see “storing session tokens insecurely” as a common finding. It is getting classified as M9 (session handling) and M2 (insecure data storage). I wonder openly whether passwords and session tokens are really that different.

We see a lot of caching of non-password, non-session data. Some of it is done explicitly by the app, some of it is done by the mobile OS through snapshotting, backups, etc. Sometimes it is classified as “data leakage” (M4) and sometimes as insecure storage (M2). And what is interesting is that some of it is the result of the OS and some is the result of the app. Do we want to make that distinction in the T10?

==MetaIntelli==

They only have 18 distinct things they report on, though they have 111,000 data points. Two of the 18 things are double-counted. They appear to be categorised in both M3 and another one.

=Other Questions=
Communications issues are a problem a lot. But TLS and crypto are tightly coupled. “Communications issues" includes certificate pinning, weak TLS ciphers, improper cert validation, HTTP and plaintext protocols, and more. There’s a lot of overlap with “broken crypto” like using Base64 instead of encryption, hard coded keys/passwords, weak hash algorithms, and so on. How do we tease out “crypto” issues from “communications” issues from “insecure storage” issues?

I can imagine a heuristic like this:
* did you use crypto where you were supposed to, but the crypto primitive you chose wasn’t appropriate for the task? That’s broken crypto.
* Did you omit crypto entirely when you should have used it? That’s insecure comms or insecure storage.

Some findings are deeply mobile (e.g., intent hijacking, keychain issues, jailbreak/root detection, etc.). They’re really tied to their respective platforms. Is that a problem for us? Does it matter?

=Conclusions Drawn From Data=
These are conclusions proposed from the 2014 data.
==At Least One New Category Is Needed==
((Paco)) The "Other" category is not the least popular category. It's more popular, by an order of magnitude, than several others. This tells me that if we had a better category that captured "other" findings, it would be a benefit to the users of the top 10.

==The Bottom 5 Categories account for 25% Or Less==

The least popular 5 items are (where "1" is the least popular and "5" is 5th least popular or 6th most popular):

# M8: Security Decisions Via Untrusted Inputs
# M7: Client Side Injection
# M9: Improper Session Handling
# M6: Broken Cryptography
# M1: Weak Server Side Controls

Combined with the fact that the 3rd or 4th most popular category is "Other", this suggests that 2 or 3 of these are, in fact, not in the "top ten". They may be, for example, 11 and 12 or even higher.

==The Existing Buckets are Hard To Use==

A few contributors tried to categorise their findings into the existing MT10. When they did, they showed symptoms of difficulty. Some examples in the table below show how MetaIntelli flagged findings in two different categories, and BugCrowd flagged the same kind of finding in 3 different categories. This suggests that the existing MT10 is not clear enough about where these issues belong.

{|
! Description
! Contributor
! Categories
|-
|The app is not verifying hostname, certificate matching and validity when doing SSL secure connections.
|MetaIntelli
|M3 and M9
|-
|Contains URLs with not valid SSL certificates and/or chain of trust
|MetaIntelli
|M3 and M5
|-
|Authentication cookies stored in cleartext in sqlite database
|BugCrowd
|M9 - Improper Session Handling
|-
|Blackberry app stores credentials in plaintext
|BugCrowd
|M2 - Insecure Data Storage
|-
|Credentials and sensitive information not secured on Windows Phone app
|BugCrowd
|M5 - Poor Authorization and Authentication
|}

==Some Topics that Show Up But Are Hard To Place==

There are a few things that show up in the contributed data that do not have a good category to go into.

===Code Level Findings===

If someone is doing bad C coding (e.g., strcpy() and similar), there is no good bucket for that. Likewise, misusing the platform APIs (e.g., Android, iOS, etc.) is not well covered. It's hard to place violations of platform best practices (e.g., with intents and broadcasts and so on).

Most of the Android developers use "printStackTrace" in their code, which is a bad practice. Even the Android APK is released in DEBUG mode.

=OWASP Category Elements=
This section explores the critical elements that must be included within all OWASP Mobile Top Ten 2015 categories. Each element is listed below along with a brief description of the appropriate content. The goal is to "test drive" this list of required elements with a sample, non-commital category to verify that the elements adequately cover what is needed within each of the OWASP Mobile Top Ten 2015 categories. Each of these elements has been initially based off the Google Hangout meeting held on April 1 2015.

==Label (generic and audience-specific labels)==
This element is a unique identifier for the bucket of issues that belong together. In the [https://docs.google.com/a/owasp.org/forms/d/1WMEbjVgXU4VkjHP5AcW934D9EI0_XQ5vmjb-Y5liMQY/viewform OWASP Mobile Top Ten 2015 Survey], we found that there were many different audiences that may use the OWASP Mobile Top Ten 2015 for different purposes. As always, there needs to be a generic label that uniquely identifies each bucket of issues. However, there should also be additional labels for the same category that are audience-specific to make it easier for different audiences to identify the category they are looking for. These additional labels will help clarify and differentiate the categories.

==Overview Text==
This element is a generic education piece (100-200 words) around the nature of the category. It should describe the nature of the category as it relates to the different audiences (e.g., penetration testers; software engineers). It should include external references and educational links to other sources around the nature of the problem.

==Prominent Characteristics==
This element eliminates any uncertainty or ambiguity that may result from vagueness / broadness in the category labels. It should include "headline vulnerabilities" that made it into the media and help each audience get a "gut feel" for what belongs to this category. In the 2014 list, we found that there were many instances where the same vulnerabilities were spread across many different categories. Hence, the need for this additional element along with a strive towards better categorisation.

==Risk==
This element helps clarify how critical the category of issues is from both a business and technical perspective. During the meeting of April 1 2015, it was proposed that the CVSS classification scheme may be used here as a way of helping guide the audiences in prioritisation of the fixing of the issues.

==Examples==
This element gives coding-specific examples, CVE vulnerabilities and newsworthy events that fall into this category. This element will help clarify to the difference audiences what fits into this category.

== Audience Specific Guidance==
This element gives practical advice and guidance for category remediation that is relevant to each audience (100-200 words). Each audience may approach the issue of remediation from very different perspectives. For example, an auditor may simply want to know more about whether or not remediation is appropriate. Meanwhile, a software engineer may want to have coding-specific advice. Each audience's concerns must be addressed in this element.

="Test Drive" Category Element=
Here, we are testing a particular category to see whether or not the proposed elements for each category are adequate to address each audience's needs. It is important to note that this is a sample category and is not a formal commitment to any final category in the OWASP Mobile Top Ten 2015. It is strictly meant for testing purposes. Members who would like to 'own' particular elements in the category below should 'sign up' and add content where appropriate.

==Insecure Data Transmission==

===Generic Label===
Owner(s): Jonathan Carter

===Audience-Specific Labels===
Owner(s): Jonathan Carter

===Overview Text===

This category focuses on the many available communication channels in the mobile environment and the secure transmission of data through them. If your application is using '''Wi-Fi, WiFi-direct, Bluetooth, Infra-red, RFIDs, POS devices (with NFC Tags)'''; then this category provides guidance in securing data while in transit. Included but not limited to are '''plaintext transmission of sensitive data, insufficient authentication of encrypted channel endpoints, insufficient regard to failures in building a properly encrypted channel, poor choice of security mechanisms over distinct networks''', etc.

Additionaly, this category applies in the same way to secure data transmission in the '''Internet Of Things (IoT)'''.

Owner(s): Milan Singh Thakur

===Prominent Characteristics===
Owner(s): David Fern

The key differentiator of this vulnerability is that it is concerned about unencrypted or improperly encrypted data being stolen during transmission, not on the device but through the airwaves.

[[File:Data Transport.jpg]]

'''Insecure Data Transmission should not be confused with others in the top 10 such as:
'''

'''M3: Insufficient Transport Layer Protection''' – I DO NOT SEE ANT DIFFERENCE

'''M4: Unintended Data Leakage''' – Unintended data leakage is a result of insecure data transmission. Once data has been stolen and interpreted it may contain information that is valuable to attackers (leaked).

'''M6: Broken Cryptography''' – While broken cryptography does relate to data that has been improperly encrypted, and it may be an input or causes of insecure data transmission, it focuses on the encryption process/technique itself on the device transmitting the data.

===Risk===
Confidential and sensitive data residing on the mobile devices if not fully SSL encrypted during transmission is highly susceptible to eavesdropping. As majority of wireless, mobile devices have capability to use and switch to various home Wifi and public unsecured Wifi. This could be disastrous while giving attackers a glimpse of your personal, non-shareable information which can lead to '''identity theft''' and '''social engineering attacks'''. Similarly, it applies to those mobile apps also where data transmission is not fully SSL encrypted and failed to perform a Valid SSL Certificate check. Additionally, this might lead further to '''man-in-the-middle attacks'''.

Even if the application uses encryption and the device is connected to a public WiFi, an attacker can easily capture all Wireless traffic (as in War-driving). Then attacker can perform '''offline decryption''' and possibly have all your sensitive data.
Consider the situation where your application server uses TLS1.0/SSLv3. You think it is secure? Nope, it is highly vulnerable to attacks like '''CRIME, POODLE and Handshake Re-negotiation'''.

Owner(s): Rajvinder Singh, Milan Singh Thakur

===Examples===
Owner(s): Adam Kliarsky

===Audience-Specific Guidance===
Owner(s): Andi Pannell

=Top Ten Scratchpad=
Here's some top-ten possible categories. This is a wiki. Edit them. Change them. Leave comments. Mark it up.

==M1: Weak Server Side Controls ==
Stuff

==M2: Insecure Data Storage ==
(Jason) As i look through the data I think more and more about how m2 and m4 might be combined.

==M3: Insufficient Transport Layer Protection ==
Stuff

==M4: Unintended Data Leakage ==

Stuff
==M5: Poor Authorization and Authentication ==

Stuff
==M6: Broken Cryptography ==

Stuff
==M7: Client Side Injection ==

Stuff
==M8: Security Decisions Via Untrusted Inputs ==

Stuff
==M9: Improper Session Handling ==

Stuff
==M10: Lack of Binary Protections ==

(Jason) Regarding m10 - Several submissions reported m10 vulns. Unfortunately some were types of services such as binary reputation scanners, that do not have the ability to check for dynamic or code level findings. In order to fix this i recommend a name change or re-working of this category. I want to separate out the delineation of Anti-exploit vs Code Obfuscation/Anti-reversing. Must talk to group about this.

File:Data Transport.jpg

2015-04-05T17:09:17Z

David Fern:

Projects/OWASP Mobile Security Project -2015 Scratchpad

2015-04-05T17:00:12Z

David Fern: /* Prominent Characteristics */

This is just a place to gather some ideas for the 2015 reworking of the Mobile Top Ten. It's totally unofficial open musings about truth, beauty, and justice.

=What is It?=

This is the "Mobile Top Ten" ''what''? It's the top 10 "stuff people tend to screw up", but here are some important questions.

* Business risk or technical risk? The business risk would be something like "intellectual property unprotected" or "customer data exposed." A technical risk would be something like "data stored in plain text files."

* Root cause, or final impact? Often root causes are things like not encrypting when we should. Final impact is stuff like unintended data leaks. The problem is that some of these things are overlapping. Not every lack of crypto is a data leak, but many are.

* What threats are in scope? There are apps that simply do not care about protecting from malware, jailbreaking, etc. Think Yelp: it's just restaurant reviews. No financial impact, no reason to care about many client-side attacks. Plenty of apps ''do'' care about client-side attacks. E.g., banking, communications, health data. Many items hinge on whether or not you care about client side attacks. How do we capture this?
** If you care about client-side attacks, then failing to encrypt stuff is basically a data leakage.
** If you don't care about client-side attacks, then failing to encrypt stuff is kinda "gee you should do that".
** If you care about client-side attacks, there are probably some platform features that are not sufficient as-is: the app sandbox, etc. You probably want to be putting your own additional layer of encryptiong / protection, etc.
** If you don't care about client-side attacks, then you simply need to be using the standard APIs (keychain, app data storage, etc.) in the standard supported ways.

=Who is it For?=

Do we intend this to be a tool that infosec / appsec people use? Do we intend lay people to make use of it? (e.g., developers and non-mobile IT security people) What does the target audience need to get from it?

(''Paco's opinion'') We need to have a narrative: If you found functionality that does X, it is probably in bucket A, unless it is also doing (or not doing) Y, in which case that's bucket B.

=Comments on Submitted Data=

==General==

(Jason) By looking at some data sets it becomes clear there is a doctrine that some consultancies use to do mobile testing. Some did not contribute m1 data, because they consider mobile security client-only. The same applied to m10. In addition, a couple of datasets used CWE IDs. These were harder to parse because generic CWE's do not specify if the vuln is client or server (and in a lot of these cases the vuln could be either). As Paco stated, code quality, source level findings are hard to categorize as well.

==BugCrowd==
I see “storing passwords in the clear” as a very common finding among their data. It gets classifed as M5 poor authentication, M2 insecure data storage, M4 data leakage, and sometimes M6 (broken crypto).

I see “storing session tokens insecurely” as a common finding. It is getting classified as M9 (session handling) and M2 (insecure data storage). I wonder openly whether passwords and session tokens are really that different.

We see a lot of caching of non-password, non-session data. Some of it is done explicitly by the app, some of it is done by the mobile OS through snapshotting, backups, etc. Sometimes it is classified as “data leakage” (M4) and sometimes as insecure storage (M2). And what is interesting is that some of it is the result of the OS and some is the result of the app. Do we want to make that distinction in the T10?

==MetaIntelli==

They only have 18 distinct things they report on, though they have 111,000 data points. Two of the 18 things are double-counted. They appear to be categorised in both M3 and another one.

=Other Questions=
Communications issues are a problem a lot. But TLS and crypto are tightly coupled. “Communications issues" includes certificate pinning, weak TLS ciphers, improper cert validation, HTTP and plaintext protocols, and more. There’s a lot of overlap with “broken crypto” like using Base64 instead of encryption, hard coded keys/passwords, weak hash algorithms, and so on. How do we tease out “crypto” issues from “communications” issues from “insecure storage” issues?

I can imagine a heuristic like this:
* did you use crypto where you were supposed to, but the crypto primitive you chose wasn’t appropriate for the task? That’s broken crypto.
* Did you omit crypto entirely when you should have used it? That’s insecure comms or insecure storage.

Some findings are deeply mobile (e.g., intent hijacking, keychain issues, jailbreak/root detection, etc.). They’re really tied to their respective platforms. Is that a problem for us? Does it matter?

=Conclusions Drawn From Data=
These are conclusions proposed from the 2014 data.
==At Least One New Category Is Needed==
((Paco)) The "Other" category is not the least popular category. It's more popular, by an order of magnitude, than several others. This tells me that if we had a better category that captured "other" findings, it would be a benefit to the users of the top 10.

==The Bottom 5 Categories account for 25% Or Less==

The least popular 5 items are (where "1" is the least popular and "5" is 5th least popular or 6th most popular):

# M8: Security Decisions Via Untrusted Inputs
# M7: Client Side Injection
# M9: Improper Session Handling
# M6: Broken Cryptography
# M1: Weak Server Side Controls

Combined with the fact that the 3rd or 4th most popular category is "Other", this suggests that 2 or 3 of these are, in fact, not in the "top ten". They may be, for example, 11 and 12 or even higher.

==The Existing Buckets are Hard To Use==

A few contributors tried to categorise their findings into the existing MT10. When they did, they showed symptoms of difficulty. Some examples in the table below show how MetaIntelli flagged findings in two different categories, and BugCrowd flagged the same kind of finding in 3 different categories. This suggests that the existing MT10 is not clear enough about where these issues belong.

{|
! Description
! Contributor
! Categories
|-
|The app is not verifying hostname, certificate matching and validity when doing SSL secure connections.
|MetaIntelli
|M3 and M9
|-
|Contains URLs with not valid SSL certificates and/or chain of trust
|MetaIntelli
|M3 and M5
|-
|Authentication cookies stored in cleartext in sqlite database
|BugCrowd
|M9 - Improper Session Handling
|-
|Blackberry app stores credentials in plaintext
|BugCrowd
|M2 - Insecure Data Storage
|-
|Credentials and sensitive information not secured on Windows Phone app
|BugCrowd
|M5 - Poor Authorization and Authentication
|}

==Some Topics that Show Up But Are Hard To Place==

There are a few things that show up in the contributed data that do not have a good category to go into.

===Code Level Findings===

If someone is doing bad C coding (e.g., strcpy() and similar), there is no good bucket for that. Likewise, misusing the platform APIs (e.g., Android, iOS, etc.) is not well covered. It's hard to place violations of platform best practices (e.g., with intents and broadcasts and so on).

Most of the Android developers use "printStackTrace" in their code, which is a bad practice. Even the Android APK is released in DEBUG mode.

=OWASP Category Elements=
This section explores the critical elements that must be included within all OWASP Mobile Top Ten 2015 categories. Each element is listed below along with a brief description of the appropriate content. The goal is to "test drive" this list of required elements with a sample, non-commital category to verify that the elements adequately cover what is needed within each of the OWASP Mobile Top Ten 2015 categories. Each of these elements has been initially based off the Google Hangout meeting held on April 1 2015.

==Label (generic and audience-specific labels)==
This element is a unique identifier for the bucket of issues that belong together. In the [https://docs.google.com/a/owasp.org/forms/d/1WMEbjVgXU4VkjHP5AcW934D9EI0_XQ5vmjb-Y5liMQY/viewform OWASP Mobile Top Ten 2015 Survey], we found that there were many different audiences that may use the OWASP Mobile Top Ten 2015 for different purposes. As always, there needs to be a generic label that uniquely identifies each bucket of issues. However, there should also be additional labels for the same category that are audience-specific to make it easier for different audiences to identify the category they are looking for. These additional labels will help clarify and differentiate the categories.

==Overview Text==
This element is a generic education piece (100-200 words) around the nature of the category. It should describe the nature of the category as it relates to the different audiences (e.g., penetration testers; software engineers). It should include external references and educational links to other sources around the nature of the problem.

==Prominent Characteristics==
This element eliminates any uncertainty or ambiguity that may result from vagueness / broadness in the category labels. It should include "headline vulnerabilities" that made it into the media and help each audience get a "gut feel" for what belongs to this category. In the 2014 list, we found that there were many instances where the same vulnerabilities were spread across many different categories. Hence, the need for this additional element along with a strive towards better categorisation.

==Risk==
This element helps clarify how critical the category of issues is from both a business and technical perspective. During the meeting of April 1 2015, it was proposed that the CVSS classification scheme may be used here as a way of helping guide the audiences in prioritisation of the fixing of the issues.

==Examples==
This element gives coding-specific examples, CVE vulnerabilities and newsworthy events that fall into this category. This element will help clarify to the difference audiences what fits into this category.

== Audience Specific Guidance==
This element gives practical advice and guidance for category remediation that is relevant to each audience (100-200 words). Each audience may approach the issue of remediation from very different perspectives. For example, an auditor may simply want to know more about whether or not remediation is appropriate. Meanwhile, a software engineer may want to have coding-specific advice. Each audience's concerns must be addressed in this element.

="Test Drive" Category Element=
Here, we are testing a particular category to see whether or not the proposed elements for each category are adequate to address each audience's needs. It is important to note that this is a sample category and is not a formal commitment to any final category in the OWASP Mobile Top Ten 2015. It is strictly meant for testing purposes. Members who would like to 'own' particular elements in the category below should 'sign up' and add content where appropriate.

==Insecure Data Transmission==

===Generic Label===
Owner(s): Jonathan Carter

===Audience-Specific Labels===
Owner(s): Jonathan Carter

===Overview Text===

This category focuses on the many available communication channels in the mobile environment and the secure transmission of data through them. If your application is using '''Wi-Fi, WiFi-direct, Bluetooth, Infra-red, RFIDs, POS devices (with NFC Tags)'''; then this category provides guidance in securing data while in transit. Included but not limited to are '''plaintext transmission of sensitive data, insufficient authentication of encrypted channel endpoints, insufficient regard to failures in building a properly encrypted channel, poor choice of security mechanisms over distinct networks''', etc.

Additionaly, this category applies in the same way to secure data transmission in the '''Internet Of Things (IoT)'''.

Owner(s): Milan Singh Thakur

===Prominent Characteristics===
Owner(s): David Fern

The key differentiator of this vulnerability is that it is concerned about unencrypted or improperly encrypted data being stolen during transmission, not on the device but through the airwaves.

'''Insecure Data Transmission should not be confused with others in the top 10 such as:
'''

'''M3: Insufficient Transport Layer Protection''' – I DO NOT SEE ANT DIFFERENCE

'''M4: Unintended Data Leakage''' – Unintended data leakage is a result of insecure data transmission. Once data has been stolen and interpreted it may contain information that is valuable to attackers (leaked).

'''M6: Broken Cryptography''' – While broken cryptography does relate to data that has been improperly encrypted, and it may be an input or causes of insecure data transmission, it focuses on the encryption process/technique itself on the device transmitting the data.

===Risk===
Confidential and sensitive data residing on the mobile devices if not fully SSL encrypted during transmission is highly susceptible to eavesdropping. As majority of wireless, mobile devices have capability to use and switch to various home Wifi and public unsecured Wifi. This could be disastrous while giving attackers a glimpse of your personal, non-shareable information which can lead to '''identity theft''' and '''social engineering attacks'''. Similarly, it applies to those mobile apps also where data transmission is not fully SSL encrypted and failed to perform a Valid SSL Certificate check. Additionally, this might lead further to '''man-in-the-middle attacks'''.

Even if the application uses encryption and the device is connected to a public WiFi, an attacker can easily capture all Wireless traffic (as in War-driving). Then attacker can perform '''offline decryption''' and possibly have all your sensitive data.
Consider the situation where your application server uses TLS1.0/SSLv3. You think it is secure? Nope, it is highly vulnerable to attacks like '''CRIME, POODLE and Handshake Re-negotiation'''.

Owner(s): Rajvinder Singh, Milan Singh Thakur

===Examples===
Owner(s): Adam Kliarsky

===Audience-Specific Guidance===
Owner(s): Andi Pannell

=Top Ten Scratchpad=
Here's some top-ten possible categories. This is a wiki. Edit them. Change them. Leave comments. Mark it up.

==M1: Weak Server Side Controls ==
Stuff

==M2: Insecure Data Storage ==
(Jason) As i look through the data I think more and more about how m2 and m4 might be combined.

==M3: Insufficient Transport Layer Protection ==
Stuff

==M4: Unintended Data Leakage ==

Stuff
==M5: Poor Authorization and Authentication ==

Stuff
==M6: Broken Cryptography ==

Stuff
==M7: Client Side Injection ==

Stuff
==M8: Security Decisions Via Untrusted Inputs ==

Stuff
==M9: Improper Session Handling ==

Stuff
==M10: Lack of Binary Protections ==

(Jason) Regarding m10 - Several submissions reported m10 vulns. Unfortunately some were types of services such as binary reputation scanners, that do not have the ability to check for dynamic or code level findings. In order to fix this i recommend a name change or re-working of this category. I want to separate out the delineation of Anti-exploit vs Code Obfuscation/Anti-reversing. Must talk to group about this.

Projects/OWASP Mobile Security Project -2015 Scratchpad

2015-04-05T16:59:21Z

David Fern: /* Prominent Characteristics */

This is just a place to gather some ideas for the 2015 reworking of the Mobile Top Ten. It's totally unofficial open musings about truth, beauty, and justice.

=What is It?=

This is the "Mobile Top Ten" ''what''? It's the top 10 "stuff people tend to screw up", but here are some important questions.

* Business risk or technical risk? The business risk would be something like "intellectual property unprotected" or "customer data exposed." A technical risk would be something like "data stored in plain text files."

* Root cause, or final impact? Often root causes are things like not encrypting when we should. Final impact is stuff like unintended data leaks. The problem is that some of these things are overlapping. Not every lack of crypto is a data leak, but many are.

* What threats are in scope? There are apps that simply do not care about protecting from malware, jailbreaking, etc. Think Yelp: it's just restaurant reviews. No financial impact, no reason to care about many client-side attacks. Plenty of apps ''do'' care about client-side attacks. E.g., banking, communications, health data. Many items hinge on whether or not you care about client side attacks. How do we capture this?
** If you care about client-side attacks, then failing to encrypt stuff is basically a data leakage.
** If you don't care about client-side attacks, then failing to encrypt stuff is kinda "gee you should do that".
** If you care about client-side attacks, there are probably some platform features that are not sufficient as-is: the app sandbox, etc. You probably want to be putting your own additional layer of encryptiong / protection, etc.
** If you don't care about client-side attacks, then you simply need to be using the standard APIs (keychain, app data storage, etc.) in the standard supported ways.

=Who is it For?=

Do we intend this to be a tool that infosec / appsec people use? Do we intend lay people to make use of it? (e.g., developers and non-mobile IT security people) What does the target audience need to get from it?

(''Paco's opinion'') We need to have a narrative: If you found functionality that does X, it is probably in bucket A, unless it is also doing (or not doing) Y, in which case that's bucket B.

=Comments on Submitted Data=

==General==

(Jason) By looking at some data sets it becomes clear there is a doctrine that some consultancies use to do mobile testing. Some did not contribute m1 data, because they consider mobile security client-only. The same applied to m10. In addition, a couple of datasets used CWE IDs. These were harder to parse because generic CWE's do not specify if the vuln is client or server (and in a lot of these cases the vuln could be either). As Paco stated, code quality, source level findings are hard to categorize as well.

==BugCrowd==
I see “storing passwords in the clear” as a very common finding among their data. It gets classifed as M5 poor authentication, M2 insecure data storage, M4 data leakage, and sometimes M6 (broken crypto).

I see “storing session tokens insecurely” as a common finding. It is getting classified as M9 (session handling) and M2 (insecure data storage). I wonder openly whether passwords and session tokens are really that different.

We see a lot of caching of non-password, non-session data. Some of it is done explicitly by the app, some of it is done by the mobile OS through snapshotting, backups, etc. Sometimes it is classified as “data leakage” (M4) and sometimes as insecure storage (M2). And what is interesting is that some of it is the result of the OS and some is the result of the app. Do we want to make that distinction in the T10?

==MetaIntelli==

They only have 18 distinct things they report on, though they have 111,000 data points. Two of the 18 things are double-counted. They appear to be categorised in both M3 and another one.

=Other Questions=
Communications issues are a problem a lot. But TLS and crypto are tightly coupled. “Communications issues" includes certificate pinning, weak TLS ciphers, improper cert validation, HTTP and plaintext protocols, and more. There’s a lot of overlap with “broken crypto” like using Base64 instead of encryption, hard coded keys/passwords, weak hash algorithms, and so on. How do we tease out “crypto” issues from “communications” issues from “insecure storage” issues?

I can imagine a heuristic like this:
* did you use crypto where you were supposed to, but the crypto primitive you chose wasn’t appropriate for the task? That’s broken crypto.
* Did you omit crypto entirely when you should have used it? That’s insecure comms or insecure storage.

Some findings are deeply mobile (e.g., intent hijacking, keychain issues, jailbreak/root detection, etc.). They’re really tied to their respective platforms. Is that a problem for us? Does it matter?

=Conclusions Drawn From Data=
These are conclusions proposed from the 2014 data.
==At Least One New Category Is Needed==
((Paco)) The "Other" category is not the least popular category. It's more popular, by an order of magnitude, than several others. This tells me that if we had a better category that captured "other" findings, it would be a benefit to the users of the top 10.

==The Bottom 5 Categories account for 25% Or Less==

The least popular 5 items are (where "1" is the least popular and "5" is 5th least popular or 6th most popular):

# M8: Security Decisions Via Untrusted Inputs
# M7: Client Side Injection
# M9: Improper Session Handling
# M6: Broken Cryptography
# M1: Weak Server Side Controls

Combined with the fact that the 3rd or 4th most popular category is "Other", this suggests that 2 or 3 of these are, in fact, not in the "top ten". They may be, for example, 11 and 12 or even higher.

==The Existing Buckets are Hard To Use==

A few contributors tried to categorise their findings into the existing MT10. When they did, they showed symptoms of difficulty. Some examples in the table below show how MetaIntelli flagged findings in two different categories, and BugCrowd flagged the same kind of finding in 3 different categories. This suggests that the existing MT10 is not clear enough about where these issues belong.

{|
! Description
! Contributor
! Categories
|-
|The app is not verifying hostname, certificate matching and validity when doing SSL secure connections.
|MetaIntelli
|M3 and M9
|-
|Contains URLs with not valid SSL certificates and/or chain of trust
|MetaIntelli
|M3 and M5
|-
|Authentication cookies stored in cleartext in sqlite database
|BugCrowd
|M9 - Improper Session Handling
|-
|Blackberry app stores credentials in plaintext
|BugCrowd
|M2 - Insecure Data Storage
|-
|Credentials and sensitive information not secured on Windows Phone app
|BugCrowd
|M5 - Poor Authorization and Authentication
|}

==Some Topics that Show Up But Are Hard To Place==

There are a few things that show up in the contributed data that do not have a good category to go into.

===Code Level Findings===

If someone is doing bad C coding (e.g., strcpy() and similar), there is no good bucket for that. Likewise, misusing the platform APIs (e.g., Android, iOS, etc.) is not well covered. It's hard to place violations of platform best practices (e.g., with intents and broadcasts and so on).

Most of the Android developers use "printStackTrace" in their code, which is a bad practice. Even the Android APK is released in DEBUG mode.

=OWASP Category Elements=
This section explores the critical elements that must be included within all OWASP Mobile Top Ten 2015 categories. Each element is listed below along with a brief description of the appropriate content. The goal is to "test drive" this list of required elements with a sample, non-commital category to verify that the elements adequately cover what is needed within each of the OWASP Mobile Top Ten 2015 categories. Each of these elements has been initially based off the Google Hangout meeting held on April 1 2015.

==Label (generic and audience-specific labels)==
This element is a unique identifier for the bucket of issues that belong together. In the [https://docs.google.com/a/owasp.org/forms/d/1WMEbjVgXU4VkjHP5AcW934D9EI0_XQ5vmjb-Y5liMQY/viewform OWASP Mobile Top Ten 2015 Survey], we found that there were many different audiences that may use the OWASP Mobile Top Ten 2015 for different purposes. As always, there needs to be a generic label that uniquely identifies each bucket of issues. However, there should also be additional labels for the same category that are audience-specific to make it easier for different audiences to identify the category they are looking for. These additional labels will help clarify and differentiate the categories.

==Overview Text==
This element is a generic education piece (100-200 words) around the nature of the category. It should describe the nature of the category as it relates to the different audiences (e.g., penetration testers; software engineers). It should include external references and educational links to other sources around the nature of the problem.

==Prominent Characteristics==
This element eliminates any uncertainty or ambiguity that may result from vagueness / broadness in the category labels. It should include "headline vulnerabilities" that made it into the media and help each audience get a "gut feel" for what belongs to this category. In the 2014 list, we found that there were many instances where the same vulnerabilities were spread across many different categories. Hence, the need for this additional element along with a strive towards better categorisation.

==Risk==
This element helps clarify how critical the category of issues is from both a business and technical perspective. During the meeting of April 1 2015, it was proposed that the CVSS classification scheme may be used here as a way of helping guide the audiences in prioritisation of the fixing of the issues.

==Examples==
This element gives coding-specific examples, CVE vulnerabilities and newsworthy events that fall into this category. This element will help clarify to the difference audiences what fits into this category.

== Audience Specific Guidance==
This element gives practical advice and guidance for category remediation that is relevant to each audience (100-200 words). Each audience may approach the issue of remediation from very different perspectives. For example, an auditor may simply want to know more about whether or not remediation is appropriate. Meanwhile, a software engineer may want to have coding-specific advice. Each audience's concerns must be addressed in this element.

="Test Drive" Category Element=
Here, we are testing a particular category to see whether or not the proposed elements for each category are adequate to address each audience's needs. It is important to note that this is a sample category and is not a formal commitment to any final category in the OWASP Mobile Top Ten 2015. It is strictly meant for testing purposes. Members who would like to 'own' particular elements in the category below should 'sign up' and add content where appropriate.

==Insecure Data Transmission==

===Generic Label===
Owner(s): Jonathan Carter

===Audience-Specific Labels===
Owner(s): Jonathan Carter

===Overview Text===

This category focuses on the many available communication channels in the mobile environment and the secure transmission of data through them. If your application is using '''Wi-Fi, WiFi-direct, Bluetooth, Infra-red, RFIDs, POS devices (with NFC Tags)'''; then this category provides guidance in securing data while in transit. Included but not limited to are '''plaintext transmission of sensitive data, insufficient authentication of encrypted channel endpoints, insufficient regard to failures in building a properly encrypted channel, poor choice of security mechanisms over distinct networks''', etc.

Additionaly, this category applies in the same way to secure data transmission in the '''Internet Of Things (IoT)'''.

Owner(s): Milan Singh Thakur

===Prominent Characteristics===
Owner(s): David Fern

The key differentiator of this vulnerability is that it is concerned about unencrypted or improperly encrypted data being stolen during transmission, not on the device but through the airwaves.

'''Insecure Data Transmission should not be confused with others in the top 10 such as:
'''
'''M3: Insufficient Transport Layer Protection''' – I DO NOT SEE ANT DIFFERENCE

'''M4: Unintended Data Leakage''' – Unintended data leakage is a result of insecure data transmission. Once data has been stolen and interpreted it may contain information that is valuable to attackers (leaked).

'''M6: Broken Cryptography''' – While broken cryptography does relate to data that has been improperly encrypted, and it may be an input or causes of insecure data transmission, it focuses on the encryption process/technique itself on the device transmitting the data.

===Risk===
Confidential and sensitive data residing on the mobile devices if not fully SSL encrypted during transmission is highly susceptible to eavesdropping. As majority of wireless, mobile devices have capability to use and switch to various home Wifi and public unsecured Wifi. This could be disastrous while giving attackers a glimpse of your personal, non-shareable information which can lead to '''identity theft''' and '''social engineering attacks'''. Similarly, it applies to those mobile apps also where data transmission is not fully SSL encrypted and failed to perform a Valid SSL Certificate check. Additionally, this might lead further to '''man-in-the-middle attacks'''.

Even if the application uses encryption and the device is connected to a public WiFi, an attacker can easily capture all Wireless traffic (as in War-driving). Then attacker can perform '''offline decryption''' and possibly have all your sensitive data.
Consider the situation where your application server uses TLS1.0/SSLv3. You think it is secure? Nope, it is highly vulnerable to attacks like '''CRIME, POODLE and Handshake Re-negotiation'''.

Owner(s): Rajvinder Singh, Milan Singh Thakur

===Examples===
Owner(s): Adam Kliarsky

===Audience-Specific Guidance===
Owner(s): Andi Pannell

=Top Ten Scratchpad=
Here's some top-ten possible categories. This is a wiki. Edit them. Change them. Leave comments. Mark it up.

==M1: Weak Server Side Controls ==
Stuff

==M2: Insecure Data Storage ==
(Jason) As i look through the data I think more and more about how m2 and m4 might be combined.

==M3: Insufficient Transport Layer Protection ==
Stuff

==M4: Unintended Data Leakage ==

Stuff
==M5: Poor Authorization and Authentication ==

Stuff
==M6: Broken Cryptography ==

Stuff
==M7: Client Side Injection ==

Stuff
==M8: Security Decisions Via Untrusted Inputs ==

Stuff
==M9: Improper Session Handling ==

Stuff
==M10: Lack of Binary Protections ==

(Jason) Regarding m10 - Several submissions reported m10 vulns. Unfortunately some were types of services such as binary reputation scanners, that do not have the ability to check for dynamic or code level findings. In order to fix this i recommend a name change or re-working of this category. I want to separate out the delineation of Anti-exploit vs Code Obfuscation/Anti-reversing. Must talk to group about this.

Projects/OWASP Mobile Security Project -2015 Scratchpad

2015-04-02T10:09:38Z

David Fern: /* Prominent Characteristics */

This is just a place to gather some ideas for the 2015 reworking of the Mobile Top Ten. It's totally unofficial open musings about truth, beauty, and justice.

=What is It?=

This is the "Mobile Top Ten" ''what''? It's the top 10 "stuff people tend to screw up", but here are some important questions.

* Business risk or technical risk? The business risk would be something like "intellectual property unprotected" or "customer data exposed." A technical risk would be something like "data stored in plain text files."

* Root cause, or final impact? Often root causes are things like not encrypting when we should. Final impact is stuff like unintended data leaks. The problem is that some of these things are overlapping. Not every lack of crypto is a data leak, but many are.

* What threats are in scope? There are apps that simply do not care about protecting from malware, jailbreaking, etc. Think Yelp: it's just restaurant reviews. No financial impact, no reason to care about many client-side attacks. Plenty of apps ''do'' care about client-side attacks. E.g., banking, communications, health data. Many items hinge on whether or not you care about client side attacks. How do we capture this?
** If you care about client-side attacks, then failing to encrypt stuff is basically a data leakage.
** If you don't care about client-side attacks, then failing to encrypt stuff is kinda "gee you should do that".
** If you care about client-side attacks, there are probably some platform features that are not sufficient as-is: the app sandbox, etc. You probably want to be putting your own additional layer of encryptiong / protection, etc.
** If you don't care about client-side attacks, then you simply need to be using the standard APIs (keychain, app data storage, etc.) in the standard supported ways.

=Who is it For?=

Do we intend this to be a tool that infosec / appsec people use? Do we intend lay people to make use of it? (e.g., developers and non-mobile IT security people) What does the target audience need to get from it?

(''Paco's opinion'') We need to have a narrative: If you found functionality that does X, it is probably in bucket A, unless it is also doing (or not doing) Y, in which case that's bucket B.

=Comments on Submitted Data=

==General==

(Jason) By looking at some data sets it becomes clear there is a doctrine that some consultancies use to do mobile testing. Some did not contribute m1 data, because they consider mobile security client-only. The same applied to m10. In addition, a couple of datasets used CWE IDs. These were harder to parse because generic CWE's do not specify if the vuln is client or server (and in a lot of these cases the vuln could be either). As Paco stated, code quality, source level findings are hard to categorize as well.

==BugCrowd==
I see “storing passwords in the clear” as a very common finding among their data. It gets classifed as M5 poor authentication, M2 insecure data storage, M4 data leakage, and sometimes M6 (broken crypto).

I see “storing session tokens insecurely” as a common finding. It is getting classified as M9 (session handling) and M2 (insecure data storage). I wonder openly whether passwords and session tokens are really that different.

We see a lot of caching of non-password, non-session data. Some of it is done explicitly by the app, some of it is done by the mobile OS through snapshotting, backups, etc. Sometimes it is classified as “data leakage” (M4) and sometimes as insecure storage (M2). And what is interesting is that some of it is the result of the OS and some is the result of the app. Do we want to make that distinction in the T10?

==MetaIntelli==

They only have 18 distinct things they report on, though they have 111,000 data points. Two of the 18 things are double-counted. They appear to be categorised in both M3 and another one.

=Other Questions=
Communications issues are a problem a lot. But TLS and crypto are tightly coupled. “Communications issues" includes certificate pinning, weak TLS ciphers, improper cert validation, HTTP and plaintext protocols, and more. There’s a lot of overlap with “broken crypto” like using Base64 instead of encryption, hard coded keys/passwords, weak hash algorithms, and so on. How do we tease out “crypto” issues from “communications” issues from “insecure storage” issues?

I can imagine a heuristic like this:
* did you use crypto where you were supposed to, but the crypto primitive you chose wasn’t appropriate for the task? That’s broken crypto.
* Did you omit crypto entirely when you should have used it? That’s insecure comms or insecure storage.

Some findings are deeply mobile (e.g., intent hijacking, keychain issues, jailbreak/root detection, etc.). They’re really tied to their respective platforms. Is that a problem for us? Does it matter?

=Conclusions Drawn From Data=
These are conclusions proposed from the 2014 data.
==At Least One New Category Is Needed==
((Paco)) The "Other" category is not the least popular category. It's more popular, by an order of magnitude, than several others. This tells me that if we had a better category that captured "other" findings, it would be a benefit to the users of the top 10.

==The Bottom 5 Categories account for 25% Or Less==

The least popular 5 items are (where "1" is the least popular and "5" is 5th least popular or 6th most popular):

# M8: Security Decisions Via Untrusted Inputs
# M7: Client Side Injection
# M9: Improper Session Handling
# M6: Broken Cryptography
# M1: Weak Server Side Controls

Combined with the fact that the 3rd or 4th most popular category is "Other", this suggests that 2 or 3 of these are, in fact, not in the "top ten". They may be, for example, 11 and 12 or even higher.

==The Existing Buckets are Hard To Use==

A few contributors tried to categorise their findings into the existing MT10. When they did, they showed symptoms of difficulty. Some examples in the table below show how MetaIntelli flagged findings in two different categories, and BugCrowd flagged the same kind of finding in 3 different categories. This suggests that the existing MT10 is not clear enough about where these issues belong.

{|
! Description
! Contributor
! Categories
|-
|The app is not verifying hostname, certificate matching and validity when doing SSL secure connections.
|MetaIntelli
|M3 and M9
|-
|Contains URLs with not valid SSL certificates and/or chain of trust
|MetaIntelli
|M3 and M5
|-
|Authentication cookies stored in cleartext in sqlite database
|BugCrowd
|M9 - Improper Session Handling
|-
|Blackberry app stores credentials in plaintext
|BugCrowd
|M2 - Insecure Data Storage
|-
|Credentials and sensitive information not secured on Windows Phone app
|BugCrowd
|M5 - Poor Authorization and Authentication
|}

==Some Topics that Show Up But Are Hard To Place==

There are a few things that show up in the contributed data that do not have a good category to go into.

===Code Level Findings===

If someone is doing bad C coding (e.g., strcpy() and similar), there is no good bucket for that. Likewise, misusing the platform APIs (e.g., Android, iOS, etc.) is not well covered. It's hard to place violations of platform best practices (e.g., with intents and broadcasts and so on).

Most of the Android developers use "printStackTrace" in their code, which is a bad practice. Even the Android APK is released in DEBUG mode.

=OWASP Category Elements=
This section explores the critical elements that must be included within all OWASP Mobile Top Ten 2015 categories. Each element is listed below along with a brief description of the appropriate content. The goal is to "test drive" this list of required elements with a sample, non-commital category to verify that the elements adequately cover what is needed within each of the OWASP Mobile Top Ten 2015 categories. Each of these elements has been initially based off the Google Hangout meeting held on April 1 2015.

==Label (generic and audience-specific labels)==
This element is a unique identifier for the bucket of issues that belong together. In the [https://docs.google.com/a/owasp.org/forms/d/1WMEbjVgXU4VkjHP5AcW934D9EI0_XQ5vmjb-Y5liMQY/viewform OWASP Mobile Top Ten 2015 Survey], we found that there were many different audiences that may use the OWASP Mobile Top Ten 2015 for different purposes. As always, there needs to be a generic label that uniquely identifies each bucket of issues. However, there should also be additional labels for the same category that are audience-specific to make it easier for different audiences to identify the category they are looking for. These additional labels will help clarify and differentiate the categories.

==Overview Text==
This element is a generic education piece (100-200 words) around the nature of the category. It should describe the nature of the category as it relates to the different audiences (e.g., penetration testers; software engineers). It should include external references and educational links to other sources around the nature of the problem.

==Prominent Characteristics==
This element eliminates any uncertainty or ambiguity that may result from vagueness / broadness in the category labels. It should include "headline vulnerabilities" that made it into the media and help each audience get a "gut feel" for what belongs to this category. In the 2014 list, we found that there were many instances where the same vulnerabilities were spread across many different categories. Hence, the need for this additional element along with a strive towards better categorisation.

==Risk==
This element helps clarify how critical the category of issues is from both a business and technical perspective. During the meeting of April 1 2015, it was proposed that the CVSS classification scheme may be used here as a way of helping guide the audiences in prioritisation of the fixing of the issues.

==Examples==
This element gives coding-specific examples, CVE vulnerabilities and newsworthy events that fall into this category. This element will help clarify to the difference audiences what fits into this category.

== Audience Specific Guidance==
This element gives practical advice and guidance for category remediation that is relevant to each audience (100-200 words). Each audience may approach the issue of remediation from very different perspectives. For example, an auditor may simply want to know more about whether or not remediation is appropriate. Meanwhile, a software engineer may want to have coding-specific advice. Each audience's concerns must be addressed in this element.

="Test Drive" Category Element=
Here, we are testing a particular category to see whether or not the proposed elements for each category are adequate to address each audience's needs. It is important to note that this is a sample category and is not a formal commitment to any final category in the OWASP Mobile Top Ten 2015. It is strictly meant for testing purposes. Members who would like to 'own' particular elements in the category below should 'sign up' and add content where appropriate.

==Insecure Data Transmission==

===Generic Label===
Owner(s): Jonathan Carter

===Audience-Specific Labels===
Owner(s): Jonathan Carter

===Overview Text===

This category focuses on Inter-device communication channels and the way data is being transmitted in it. So if your application is using '''WiFi-direct, Bluetooth, Infra-red, RFIDs, POS devices (with NFC Tags)'''; then this category provides guide for securing your data while using these technologies.

Moreover, this can be used to secure your data over '''Internet Of Things (IOT)'''.

Owner(s): Milan Singh Thakur

===Prominent Characteristics===
Owner(s): David Fern

===Risk===
Confidential and sensitive data residing on the mobile devices if not fully SSL encrypted during transmission is highly susceptible to eavesdropping. As majority of wireless, mobile devices have capability to use and switch to various home Wifi and public unsecured Wifi. This could be disastrous while giving attackers a glimpse of your personal, non-shareable information which can lead to '''identity theft''' and '''social engineering attacks'''. Similarly, it applies to those mobile apps also where data transmission is not fully SSL encrypted and failed to perform a Valid SSL Certificate check. Additionally, this might lead further to '''man-in-the-middle attacks'''.

Even if the application uses encryption and the device is connected to a public WiFi, an attacker can easily capture all Wireless traffic (as in War-driving). Then attacker can perform '''offline decryption''' and possibly have all your sensitive data.
Consider the situation where your application server uses TLS1.0/SSLv3. You think it is secure? Nope, it is highly vulnerable to attacks like '''CRIME, POODLE and Handshake Re-negotiation'''.

Owner(s): Rajvinder Singh, Milan Singh Thakur

===Examples===
Owner(s): Adam Kliarsky

===Audience-Specific Guidance===
Owner(s): Andi Pannell

=Top Ten Scratchpad=
Here's some top-ten possible categories. This is a wiki. Edit them. Change them. Leave comments. Mark it up.

==M1: Weak Server Side Controls ==
Stuff

==M2: Insecure Data Storage ==
(Jason) As i look through the data I think more and more about how m2 and m4 might be combined.

==M3: Insufficient Transport Layer Protection ==
Stuff

==M4: Unintended Data Leakage ==

Stuff
==M5: Poor Authorization and Authentication ==

Stuff
==M6: Broken Cryptography ==

Stuff
==M7: Client Side Injection ==

Stuff
==M8: Security Decisions Via Untrusted Inputs ==

Stuff
==M9: Improper Session Handling ==

Stuff
==M10: Lack of Binary Protections ==

(Jason) Regarding m10 - Several submissions reported m10 vulns. Unfortunately some were types of services such as binary reputation scanners, that do not have the ability to check for dynamic or code level findings. In order to fix this i recommend a name change or re-working of this category. I want to separate out the delineation of Anti-exploit vs Code Obfuscation/Anti-reversing. Must talk to group about this.

OWASP Testing Guide v4 Table of Contents

2014-01-03T22:14:18Z

David Fern:

{{OWASP Breakers}}
__NOTOC__

'''This is the DRAFT of the table of content of the New Testing Guide v4.'''<br>
<br>You can download the stable version v3 [http://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf here] <br>

Back to the OWASP Testing Guide Project:
http://www.owasp.org/index.php/OWASP_Testing_Project

'''Updated: 16th December 2013'''

[[ OWTGv4 Contributors list|'''Contributors List]]

----

The following is a DRAFT of the Toc based on the feedback already received.

== Table of Contents ==

==[[Testing Guide Foreword|Foreword by Eoin Keary]]==
[To review--> Eoin Keary -> Done!!]

==[[Testing Guide Frontispiece |1. Frontispiece]]==
[To review--> Mat]

'''[[Testing Guide Frontispiece|1.1 About the OWASP Testing Guide Project]]'''
[To review--> Mat]

'''[[About The Open Web Application Security Project|1.2 About The Open Web Application Security Project]]'''
[To review--> ]

==[[Testing Guide Introduction|2. Introduction]]==

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

2.4 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Requirements_Test_Derivation Security requirements test derivation],[https://www.owasp.org/index.php/Testing_Guide_Introduction#Functional_and_Non_Functional_Test_Requirements functional and non functional test requirements], and [https://www.owasp.org/index.php/Testing_Guide_Introduction#Test_Cases_Through_Use_and_Misuse_Cases test cases through use and misuse cases]

2.5 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Test_Data_Analysis_and_Reporting Security test data analysis and reporting: root cause identification and business/role case test data reporting]

==[[The OWASP Testing Framework|3. The OWASP Testing Framework]]==

'''3.1. Overview'''

'''3.2. Phase 1: Before Development Begins '''

'''3.3. Phase 2: During Definition and Design'''

'''3.4. Phase 3: During Development'''

'''3.5. Phase 4: During Deployment'''

'''3.6. Phase 5: Maintenance and Operations'''

'''3.7. A Typical SDLC Testing Workflow '''

==[[Web Application Penetration Testing |4. Web Application Penetration Testing ]]==

[[Testing: Introduction and objectives|'''4.1 Introduction and Objectives''']] [To review--> Mat]

[[Testing Checklist| 4.1.1 Testing Checklist]] [To review at the end of brainstorming --> Mat]

[[Testing Information Gathering|'''4.2 Information Gathering ''']]

[[Testing: Search engine discovery/reconnaissance (OWASP-IG-002)|4.2.1 Conduct Search Engine Discovery and Reconnaissance for Information Leakage (OTG-INFO-001) ]] formerly "Search Engine Discovery/Reconnaissance (OWASP-IG-002)"

[[Fingerprint Web Server (OTG-INFO-002)|4.2.2 Fingerprint Web Server (OTG-INFO-002) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-004)"

[[Testing: Spiders, Robots, and Crawlers (OWASP-IG-001)|4.2.3 Review Webserver Metafiles for Information Leakage (OTG-INFO-003) ]] formerly "Spiders, Robots and Crawlers (OWASP-IG-001)"

[[Testing for Application Discovery (OWASP-IG-005)|4.2.4 Enumerate Applications on Webserver (OTG-INFO-004) ]] formerly "Application Discovery (OWASP-IG-005)"

[[Testing Review webpage comments and metadata(OWASP-IG-007)|4.2.5 Review Webpage Comments and Metadata for Information Leakage (OTG-INFO-005) ]] formerly "Review webpage comments and metadata(OWASP-IG-007)"

[[Testing: Identify application entry points (OWASP-IG-003)|4.2.6 Identify application entry points (OTG-INFO-006) ]] formerly "Identify application entry points (OWASP-IG-003)"

[[Testing Map execution paths through application (OWASP-IG-009)|4.2.8 Map execution paths through application (OTG-INFO-008)]] formerly "Map execution paths through application (OWASP-IG-009)"

[[Fingerprint Web Application Framework (OTG-INFO-009)|4.2.9 Fingerprint Web Application Framework (OTG-INFO-009) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-010)" '''Ready to be reviewed'''

[[Testing for Web Application (OTG-INFO-011)|4.2.10 Fingerprint Web Application (OTG-INFO-010) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-010)" [Amro AlOlaqi] '''Ready to be reviewed'''

[[Map Network and Application Architecture (OTG-INFO-012)|4.2.11 Map Network and Application Architecture (OTG-INFO-011) ]] formerly "Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)" [Amro AlOlaqi] '''Ready to be reviewed'''

[[Testing for configuration management|'''4.3 Configuration and Deploy Management Testing ''']]

[[Testing for infrastructure configuration management (OWASP-CM-003)|4.3.1 Test Network/Infrastructure Configuration (OTG-CONFIG-001) ]] formerly "Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)"

[[Testing for application configuration management (OWASP-CM-004)|4.3.2 Test Application Platform Configuration (OTG-CONFIG-002) ]] formerly "Testing for Application Configuration Management weakness (OWASP-CM-002)" [Amro AlOlaqi] '''Ready to be reviewed'''

[[Testing for file extensions handling (OWASP-CM-005)|4.3.3 Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003) ]] formerly "Testing for File Extensions Handling (OWASP-CM-003)"

[[Testing for Old, Backup and Unreferenced Files (OWASP-CM-006)|4.3.4 Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004) ]] formerly "Old, Backup and Unreferenced Files (OWASP-CM-004)"

[[Testing for Admin Interfaces (OWASP-CM-007)|4.3.5 Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005) ]] formerly "Infrastructure and Application Admin Interfaces (OWASP-CM-005)" [Amro AlOlaqi] '''Ready to be reviewed'''

[[Testing for HTTP Methods and XST (OWASP-CM-008)|4.3.6 Test HTTP Methods (OTG-CONFIG-006) ]] formerly "Testing for Bad HTTP Methods (OWASP-CM-006)"

[[Testing for Database credentials/connection strings available|4.3.7 Testing for Database credentials/connection strings available (OTG-CONFIG-007) ]] formerly "Testing for Database credentials/connection strings available (OWASP-CM-007)"

[[Testing for Content Security Policy weakness|4.3.8 Test Content Security Policy (OTG-CONFIG-008) ]] formerly "Testing for Content Security Policy weakness (OWASP-CM-008)"

[[Testing for Missing HSTS header|4.3.9 Test HTTP Strict Transport Security (OTG-CONFIG-009) ]] formerly "Testing for Missing HSTS header (OWASP-CM-009)"

[[Testing for Frame Options|4.3.10 Test Frame Options (OTG-CONFIG-010) ]]

[[Testing for RIA policy files weakness|4.3.11 Test RIA cross domain policy (OTG-CONFIG-011) ]] formerly "Testing for RIA policy files weakness (OWASP-CM-010)"

[[Testing for Content Type Options|4.3.12 Test Content Type Options (OTG-CONFIG-012) ]] new

[[Testing Identity Management|'''4.4 Identity Management Testing''']]

[[Test Role Definitions (OTG-IDENT-001)|4.4.1 Test Role Definitions (OTG-IDENT-001)]] New

[[Test User Registration Process (OTG-IDENT-002)|4.4.2 Test User Registration Process (OTG-IDENT-002)]] New

[[Test Account Provisioning Process (OTG-IDENT-003)|4.4.3 Test Account Provisioning Process (OTG-IDENT-003)]] New

[[Testing for Account Enumeration and Guessable User Account (OWASP-AT-002)|4.4.4 Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004) ]] formerly "Testing for Account Enumeration and Guessable User Account (OWASP-AT-002)"

[[Testing for Weak or unenforced username policy (OWASP-AT-009)| 4.4.5 Testing for Weak or unenforced username policy (OTG-IDENT-005)]] formerly "Testing for Weak or unenforced username policy (OWASP-AT-009)

[[Test Permissions of Guest/Training Accounts (OTG-IDENT-006)|4.4.6 Test Permissions of Guest/Training Accounts (OTG-IDENT-006)]] New

[[Test Account Suspension/Resumption Process (OTG-IDENT-007)|4.4.7 Test Account Suspension/Resumption Process (OTG-IDENT-007)]] New

[[Test User Deregistration Process (OTG-IDENT-008)|4.4.8 Test User Deregistration Process (OTG-IDENT-008)]] New

[[Test Account Deregistration Process (OTG-IDENT-009)|4.4.9 Test Account Deregistration Process (OTG-IDENT-009)]] New

[[Testing for authentication|'''4.5 Authentication Testing ''']]

[[Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|4.5.1 Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]] formerly "Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)"

[[Testing for default credentials (OWASP-AT-003)|4.5.2 Testing for default credentials (OTG-AUTHN-002)]] formerly "Testing for default credentials (OWASP-AT-003)"

[[Testing for Weak lock out mechanism (OWASP-AT-004)|4.5.3 Testing for Weak lock out mechanism (OTG-AUTHN-003)]] formerly "Testing for Weak lock out mechanism (OWASP-AT-004)"

[[Testing for Bypassing Authentication Schema (OWASP-AT-005)|4.5.4 Testing for bypassing authentication schema (OTG-AUTHN-004)]] formerly "Testing for bypassing authentication schema (OWASP-AT-005)"

[[Testing for Vulnerable Remember Password (OWASP-AT-006)|4.5.5 Test remember password functionality (OTG-AUTHN-005)]] formerly "Testing for vulnerable remember password functionality (OWASP-AT-006)"

[[Testing for Browser cache weakness (OWASP-AT-007)|4.5.6 Testing for Browser cache weakness (OTG-AUTHN-006)]] formerly "Testing for Browser cache weakness (OWASP-AT-007)"

[[Testing for Weak password policy (OWASP-AT-008)|4.5.7 Testing for Weak password policy (OTG-AUTHN-007)]] formerly "Testing for Weak password policy (OWASP-AT-008)"

[[Testing for Weak security question/answer (OTG-AUTHN-008)|4.5.8 Testing for Weak security question/answer (OTG-AUTHN-008)]] New! - Robert Winkel

[[Testing for weak password change or reset functionalities (OWASP-AT-011)|4.5.9 Testing for weak password change or reset functionalities (OTG-AUTHN-009)]] formerly "Testing for weak password change or reset functionalities (OWASP-AT-011)"

[[Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)|4.5.10 Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)]] (e.g. mobile app, IVR, help desk)

[[Testing for Authorization|'''4.6 Authorization Testing''']]

[[Test Management of Account Permissions (OTG-AUTHZ-001)|4.6.1 Test Management of Account Permissions (OTG-AUTHZ-001)]] New

[[Testing for Path Traversal (OWASP-AZ-001)|4.6.2 Testing Directory traversal/file include (OTG-AUTHZ-002)]] formerly "Testing Directory traversal/file include (OWASP-AZ-001)"

[[Testing for Bypassing Authorization Schema (OWASP-AZ-002)|4.6.3 Testing for bypassing authorization schema (OTG-AUTHZ-003)]] formerly "Testing for bypassing authorization schema (OWASP-AZ-002)"

[[Testing for Privilege escalation (OWASP-AZ-003)|4.6.4 Testing for Privilege Escalation (OTG-AUTHZ-004)]] formerly "Testing for Privilege Escalation (OWASP-AZ-003)"

[[Testing for Insecure Direct Object References (OWASP-AZ-004)|4.6.5 Testing for Insecure Direct Object References (OTG-AUTHZ-005)]] formerly "Testing for Insecure Direct Object References (OWASP-AZ-004)"

[[Testing for Failure to Restrict access to authorized resource (OWASP-AZ-005)|4.6.6 Testing for Failure to Restrict access to authorized resource (OTG-AUTHZ-006)]] formerly "Testing for Failure to Restrict access to authorized resource (OWASP-AZ-005)"

[[Test privileges of server components (OTG-AUTHZ-007)|4.6.7 Test privileges of server components (OTG-AUTHZ-007)]] (e.g. indexing service, reporting interface, file generator)

[[Test enforcement of application entry points (OTG-AUTHZ-008)|4.6.8 Test enforcement of application entry points (OTG-AUTHZ-008)]] (including exposure of objects)

[[Testing for failure to restrict access to authenticated resource(OWASP-AT-010)|4.6.9 Testing for failure to restrict access to authenticated resource (OTG-AUTHZ-009)]] formerly "Testing for failure to restrict access to authenticated resource (OWASP-AT-010)"

[[Testing for Session Management|'''4.7 Session Management Testing''']]

[[Testing for Session_Management_Schema (OWASP-SM-001)|4.7.1 Testing for Bypassing Session Management Schema (OTG-SESS-001)]] formerly "Testing for Bypassing Session Management Schema (OWASP-SM-001)"

[[Testing for cookies attributes (OWASP-SM-002)|4.7.2 Testing for Cookies attributes (OTG-SESS-002)]] formerly "Testing for Cookies attributes (OWASP-SM-002)" (Cookies are set not ‘HTTP Only’, ‘Secure’, and no time validity)

[[Testing for Session Fixation (OWASP-SM-003)|4.7.3 Testing for Session Fixation (OTG-SESS-003)]] formerly "Testing for Session Fixation (OWASP-SM-003)"

[[Testing for Exposed Session Variables (OWASP-SM-004)|4.7.4 Testing for Exposed Session Variables (OTG-SESS-004)]] formerly "Testing for Exposed Session Variables (OWASP-SM-004)"

[[Testing for CSRF (OWASP-SM-005)|4.7.5 Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)]] formerly "Testing for Cross Site Request Forgery (CSRF) (OWASP-SM-005)"

[[Test Session Token Strength (OTG-SESS-006)|4.7.6 Test Session Token Strength (OTG-SESS-006)]]

[[Testing for logout functionality (OWASP-SM-007)|4.7.7 Testing for logout functionality (OTG-SESS-007)]] formerly "Testing for logout functionality (OWASP-SM-007)"

[[Test Session Timeout (OTG-SESS-008)|4.7.8 Test Session Timeout (OTG-SESS-008)]]

[[Test multiple concurrent sessions (OTG-SESS-009)|4.7.9 Test multiple concurrent sessions (OTG-SESS-009)]]

[[Testing for Session puzzling (OTG-SESS-010)|4.7.10 Testing for Session puzzling (OTG-SESS-010)]]

[[Testing for Data Validation|'''4.8 Data Validation Testing''']]

[[Testing for Reflected Cross site scripting (OWASP-DV-001) |4.8.1 Testing for Reflected Cross Site Scripting (OTG-INPVAL-001)]] formerly "Testing for Reflected Cross Site Scripting (OWASP-DV-001)"

[[Testing for Stored Cross site scripting (OWASP-DV-002) |4.8.2 Testing for Stored Cross Site Scripting (OTG-INPVAL-002)]] formerly "Testing for Stored Cross Site Scripting (OWASP-DV-002)"

[[Testing for HTTP Verb Tampering (OWASP-DV-003)|4.8.3 Testing for HTTP Verb Tampering (OTG-INPVAL-003)]] formerly "Testing for HTTP Verb Tampering (OWASP-DV-003)"

[[Testing for HTTP Parameter pollution (OWASP-DV-004)|4.8.4 Testing for HTTP Parameter pollution (OTG-INPVAL-004) ]] formerly "Testing for HTTP Parameter pollution (OWASP-DV-004)"

[[Testing for Unvalidated Redirects and Forwards (OWASP-DV-004)|4.8.5 Testing for Unvalidated Redirects and Forwards (OTG-INPVAL-005) ]] formerly "Testing for Unvalidated Redirects and Forwards (OWASP-DV-004)"

[[Testing for SQL Injection (OWASP-DV-005)| 4.8.6 Testing for SQL Injection (OTG-INPVAL-006)]] formerly "Testing for SQL Injection (OWASP-DV-005)" '''Ready to be reviewed'''

[[Testing for Oracle|4.8.6.1 Oracle Testing]]

[[Testing for MySQL|4.8.6.2 MySQL Testing [Ismael Gonçalves]]]

[[Testing for SQL Server|4.8.6.3 SQL Server Testing]]

[[OWASP_Backend_Security_Project_Testing_PostgreSQL|4.8.6.4 Testing PostgreSQL (from OWASP BSP) ]]

[[Testing for MS Access |4.8.6.5 MS Access Testing]]

[[Testing for NoSQL injection|4.8.6.6 Testing for NoSQL injection [New!]]]

[[Testing for LDAP Injection (OWASP-DV-006)|4.8.7 Testing for LDAP Injection (OTG-INPVAL-007)]] formerly "Testing for LDAP Injection (OWASP-DV-006)"

[[Testing for ORM Injection (OWASP-DV-007)|4.8.8 Testing for ORM Injection (OTG-INPVAL-008)]] formerly "Testing for ORM Injection (OWASP-DV-007)"

[[Testing for XML Injection (OWASP-DV-008)|4.8.9 Testing for XML Injection (OTG-INPVAL-009)]] formerly "Testing for XML Injection (OWASP-DV-008)"

[[Testing for SSI Injection (OWASP-DV-009)|4.8.10 Testing for SSI Injection (OTG-INPVAL-010)]] formerly "Testing for SSI Injection (OWASP-DV-009)"

[[Testing for XPath Injection (OWASP-DV-010)|4.8.11 Testing for XPath Injection (OTG-INPVAL-011)]] formerly "Testing for XPath Injection (OWASP-DV-010)"

[[Testing for IMAP/SMTP Injection (OWASP-DV-011)|4.8.12 IMAP/SMTP Injection (OTG-INPVAL-012)]] formerly "IMAP/SMTP Injection (OWASP-DV-011)"

[[Testing for Code Injection (OWASP-DV-012)|4.8.13 Testing for Code Injection (OTG-INPVAL-013)]] formerly "Testing for Code Injection (OWASP-DV-012)"

[[Testing for Local File Inclusion|4.8.13.1 Testing for Local File Inclusion]] [Alexander Antukh]

[[Testing for Remote File Inclusion|4.8.13.2 Testing for Remote File Inclusion]] [Alexander Antukh]

[[Testing for Command Injection (OWASP-DV-013)|4.8.14 Testing for Command Injection (OTG-INPVAL-014)]] formerly "Testing for Command Injection (OWASP-DV-013)"

[[Testing for Buffer Overflow (OWASP-DV-014)|4.8.15 Testing for Buffer overflow (OTG-INPVAL-015)]] formerly "Testing for Buffer overflow (OWASP-DV-014)"

[[Testing for Heap Overflow|4.8.15.1 Testing for Heap overflow]]

[[Testing for Stack Overflow|4.8.15.2 Testing for Stack overflow]]

[[Testing for Format String|4.8.15.3 Testing for Format string]]

[[Testing for Incubated Vulnerability (OWASP-DV-015)|4.8.16 Testing for incubated vulnerabilities (OTG-INPVAL-016)]] formerly "Testing for incubated vulnerabilities (OWASP-DV-015)"

[[Testing for HTTP Splitting/Smuggling (OWASP-DV-016)|4.8.17 Testing for HTTP Splitting/Smuggling (OTG-INPVAL-017) ]] formerly "Testing for HTTP Splitting/Smuggling (OWASP-DV-016)" [Juan Galiana]

[[Error Handling|'''4.9 Error Handling''']]

[[Testing for Error Code (OWASP-IG-006)|4.9.1 Analysis of Error Codes (OTG-ERR-001)]] formerly "Analysis of Error Codes (OWASP-IG-006)"

[[Testing for Stack Traces (OWASP-IG-XXX)|4.9.2 Analysis of Stack Traces (OTG-ERR-002)]] formerly "Analysis of Stack Traces"

[[Cryptography|'''4.10 Cryptography''']]

[[Testing for Insecure encryption usage (OWASP-EN-001)| 4.10.1 Testing for Insecure encryption usage (OTG-CRYPST-001)]] formerly "Testing for Insecure encryption usage (OWASP-EN-001)"

[[Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)| 4.10.2 Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-002)]] formerly "Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)" [Simone Onofri]

[[Testing for Padding Oracle (OWASP-EN-003)| 4.10.3 Testing for Padding Oracle (OTG-CRYPST-003)]] formerly "Testing for Padding Oracle (OWASP-EN-003)"

[[Testing for Cacheable HTTPS Response (OTG-CRYPST-004)| 4.10.4 Testing for Cacheable HTTPS Response (OTG-CRYPST-004)]]

[[Test Cache Directives (OTG-CRYPST-005)|4.10.5 Test Cache Directives (OTG-CRYPST-005)]]

[[Testing for Insecure Cryptographic Storage (OTG-CRYPST-006)|4.10.6 Testing for Insecure Cryptographic Storage (OTG-CRYPST-006)]]

[[Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|4.10.7 Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)]] [Simone Onofri]

[[Test Cryptographic Key Management (OTG-CRYPST-008)|4.10.8 Test Cryptographic Key Management (OTG-CRYPST-008)]]

[[Logging|'''4.11 Logging''']] Not convinced Logging should be included as it requires access to logs to test

[[Test time synchronisation (OTG-LOG-001)|4.11.1 Test time synchronisation (OTG-LOG-001) ]] formerly "Incorrect time"

[[Test user-viewable log of authentication events (OTG-LOG-002)|4.11.2 Test user-viewable log of authentication events (OTG-LOG-002)]]

[[Testing for business logic (OWASP-BL-001)|'''4.12 Business Logic Testing (OWASP-BL-001)''']]
Business Logic<br>

[[Test business logic data validation (OTG-BUSLOGIC-001)|4.12.1 Test Business Logic Data Validation (OTG-BUSLOGIC-001)]]

[[Test Ability to forge requests (OTG-BUSLOGIC-002)|4.12.2 Test Ability to Forge Requests (OTG-BUSLOGIC-002)]]

[[Test integrity checks (OTG-BUSLOGIC-003)|4.12.3 Test Integrity Checks (OTG-BUSLOGIC-003)]]

[[Test for Process Timing (OTG-BUSLOGIC-007)|4.12.4 Test for Process Timing (OTG-BUSLOGIC-004)]]

[[Test number of times a function can be used limits (OTG-BUSLOGIC-007)|4.12.5 Test Number of Times a Function Can be Used Limits (OTG-BUSLOGIC-005)]]

[[Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-009)|4.12.6 Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-006)]]

[[Test defenses against application mis-use (OTG-BUSLOGIC-011)|4.12.7 Test Defenses Against Application Mis-use (OTG-BUSLOGIC-007)]]

[[Test Upload of Unexpected File Types (OTG-BUSLOGIC-015)|4.12.8 Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)]]

[[Test Upload of Malicious Files (OTG-BUSLOGIC-016)|4.12.9 Test Upload of Malicious Files (OTG-BUSLOGIC-009)]]

[[Client Side Testing|'''4.15 Client Side Testing''']] [New!]

[[Testing for DOM-based Cross site scripting (OWASP-DV-003)|4.15.1 Testing for DOM based Cross Site Scripting (OTG-CLIENT-001)]] formerly "Testing for DOM based Cross Site Scripting (OWASP-CS-001)" [Stefano Di Paola]

[[Testing for JavaScript Execution|4.15.2 Testing for JavaScript Execution (OWASP-CS-002)]] (Stefano Di Paola, Matteo Meucci)

[[Testing for HTML Injection|4.15.3 Testing for HTML Injection (OWASP-CS-003)]] (Stefano Di Paola, Matteo Meucci)

[[Testing for Client Side URL Redirect|4.15.4 Testing for Client Side URL Redirect (OWASP-CS-004)]] (Mauro Gentile, Davide Danelon)

[[Testing_for_CSS_Injection|4.15.5 Testing for CSS Injection (OWASP-CS-005)]] (Mauro Gentile, Davide Danelon)

[[Testing_for_Client_Side_Resource_Manipulation|4.15.6 Testing for Client Side Resource Manipulation (OWASP-CS-006)]] (Mauro Gentile, Davide Danelon)

[[Test Cross Origin Resource Sharing (OTG-CLIENT-002)|4.15.7 Test Cross Origin Resource Sharing (OTG-CLIENT-007)]] formerly "Testing for HTML5 (OWASP CS-002)" [Juan Galiana]

[[Testing for Cross site flashing (OWASP-DV-004)|4.15.8 Testing for Cross Site Flashing (OTG-CLIENT-008)]] formerly "Testing for Cross Site Flashing (OWASP-CS-003)"

[[Testing for Clickjacking (OWASP-CS-004)|4.15.9 Testing for Clickjacking (OTG-CLIENT-009)]] formerly "Testing for Clickjacking (OWASP-CS-004)" [Davide Danelon]

[[Testing WebSockets (OTG-CLIENT-005)|4.15.10 Testing WebSockets (OTG-CLIENT-010)]] [Ryan Dewhurst]

[[Test Web Messaging (OTG-CLIENT-006)|4.15.11 Test Web Messaging (OTG-CLIENT-011)]] [Juan Galiana]

[[Test Local Storage (OTG-CLIENT-007)|4.15.12 Test Local Storage (OTG-CLIENT-012)]] [Juan Galiana]

==[[Writing Reports: value the real risk |5. Writing Reports: value the real risk ]]==

[[How to value the real risk |5.1 How to value the real risk]] [To review--> Amro AlOlaqi] '''Ready to be reviewed'''

[[How to write the report of the testing |5.2 How to write the report of the testing]] [To review--> Amro AlOlaqi] '''Ready to be reviewed'''

==[[Appendix A: Testing Tools |Appendix A: Testing Tools ]]==

* Black Box Testing Tools [To review--> Amro AlOlaqi] '''Ready to be reviewed'''

==[[OWASP Testing Guide Appendix B: Suggested Reading | Appendix B: Suggested Reading]]==
* Whitepapers [To review--> David Fern]'''Ready to be reviewed'''
* Books [To review--> David Fern]'''Ready to be reviewed'''
* Useful Websites [To review--> David Fern]'''Ready to be reviewed'''

==[[OWASP Testing Guide Appendix C: Fuzz Vectors | Appendix C: Fuzz Vectors]]==

* Fuzz Categories [To review--> Amro AlOlaqi] '''Ready to be reviewed'''

==[[OWASP Testing Guide Appendix D: Encoded Injection | Appendix D: Encoded Injection]]==
[To review--> Amro AlOlaqi] '''Ready to be reviewed'''

----

ARTICLES DELETED:

INFO GATHERING:

BUSINESS LOGIC:

XXXX[[Testing for Forged Requests Using Predictive Parameters (OTG-BUSLOGIC-003)|4.12.3 Testing for Forged Requests Using Predictive Parameters (OTG-BUSLOGIC-003)]] [New!]- [Combine with Test Ability to forge requests as an example]

[[Test integrity checks (OTG-BUSLOGIC-003)|4.12.3 Test Integrity Checks (OTG-BUSLOGIC-003)]] (e.g. overwriting updates)

DENIAL OF SERVICE

[[Denial of Service|'''4.13 Denial of Service''']]

[[Test Regular expression DoS (OTG-DOS-001)| 4.13.1 Test Regular expression DoS (OTG-DOS-001)]] [New!] note: to understand better<br>

[[Test XML DoS (OTG-DOS-002)| 4.13.2 Test XML DoS (OTG-DOS-002)]] [New! - Andrew Muller]

[[Testing for Captcha (OWASP-AT-012)|4.13.3 Testing for CAPTCHA (OTG-DOS-003)]] formerly "Testing for CAPTCHA (OWASP-AT-012)"

[[Test excessive rate (speed) of use limits (OTG-BUSLOGIC-005)|4.13.4 Test excessive rate (speed) of use limits (OTG-DOS-004)]] [New!]- [Moved from Business Logic, formerly OTG-BUSLOGIC-006]

[[Test size of request limits (OTG-BUSLOGIC-006)|4.13.5 Test size of request limits (OTG-DOS-005)]] [New!] - [Moved from Business Logic, formerly OTG-BUSLOGIC-008]

WEB SERVICES TESTING

[[Web Service (XML Interpreter)|'''4.14 Web Service Testing''']] [Tom Eston]

[[Scoping a Web Service Test (OWASP-WS-001)|4.14.1 Scoping a Web Service Test (OTG-WEBSVC-001)]] formerly "Scoping a Web Service Test (OWASP-WS-001)"

[[WS Information Gathering (OWASP-WS-002)|4.14.2 WS Information Gathering (OTG-WEBSVC-002)]] formerly "WS Information Gathering (OWASP-WS-002)"

[[WS Authentication Testing (OWASP-WS-003)|4.14.3 WS Authentication Testing (OTG-WEBSVC-003)]] formerly "WS Authentication Testing (OWASP-WS-003)"

[[WS Management Interface Testing (OWASP-WS-004)|4.14.4 WS Management Interface Testing (OTG-WEBSVC-004)]] formerly "WS Management Interface Testing (OWASP-WS-004)"

[[Weak XML Structure Testing (OWASP-WS-005)|4.14.5 Weak XML Structure Testing (OTG-WEBSVC-005)]] formerly "Weak XML Structure Testing (OWASP-WS-005)"

[[XML Content-Level Testing (OWASP-WS-006)|4.14.6 XML Content-Level Testing (OTG-WEBSVC-006)]] formerly "XML Content-Level Testing (OWASP-WS-006)"

[[WS HTTP GET Parameters/REST Testing (OWASP-WS-007)|4.14.7 WS HTTP GET Parameters/REST Testing (OTG-WEBSVC-007)]] formerly "WS HTTP GET Parameters/REST Testing (OWASP-WS-007)"

[[WS Naughty SOAP Attachment Testing (OWASP-WS-008)|4.14.8 WS Naughty SOAP Attachment Testing (OTG-WEBSVC-008)]] formerly "WS Naughty SOAP Attachment Testing (OWASP-WS-008)"

[[WS Replay/MiTM Testing (OWASP-WS-009)|4.14.9 WS Replay/MiTM Testing (OTG-WEBSVC-009)]] formerly "WS Replay/MiTM Testing (OWASP-WS-009)"

[[WS BEPL Testing (OWASP-WS-010)|4.14.10 WS BEPL Testing (OTG-WEBSVC-010)]] formerly "WS BEPL Testing (OWASP-WS-010)"

[[Category:OWASP Testing Project]]

OWASP Testing Guide v4 Table of Contents

2014-01-03T22:13:27Z

David Fern:

{{OWASP Breakers}}
__NOTOC__

'''This is the DRAFT of the table of content of the New Testing Guide v4.'''<br>
<br>You can download the stable version v3 [http://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf here] <br>

Back to the OWASP Testing Guide Project:
http://www.owasp.org/index.php/OWASP_Testing_Project

'''Updated: 16th December 2013'''

[[ OWTGv4 Contributors list|'''Contributors List]]

----

The following is a DRAFT of the Toc based on the feedback already received.

== Table of Contents ==

==[[Testing Guide Foreword|Foreword by Eoin Keary]]==
[To review--> Eoin Keary -> Done!!]

==[[Testing Guide Frontispiece |1. Frontispiece]]==
[To review--> Mat]

'''[[Testing Guide Frontispiece|1.1 About the OWASP Testing Guide Project]]'''
[To review--> Mat]

'''[[About The Open Web Application Security Project|1.2 About The Open Web Application Security Project]]'''
[To review--> ]

==[[Testing Guide Introduction|2. Introduction]]==

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

2.4 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Requirements_Test_Derivation Security requirements test derivation],[https://www.owasp.org/index.php/Testing_Guide_Introduction#Functional_and_Non_Functional_Test_Requirements functional and non functional test requirements], and [https://www.owasp.org/index.php/Testing_Guide_Introduction#Test_Cases_Through_Use_and_Misuse_Cases test cases through use and misuse cases]

2.5 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Test_Data_Analysis_and_Reporting Security test data analysis and reporting: root cause identification and business/role case test data reporting]

==[[The OWASP Testing Framework|3. The OWASP Testing Framework]]==

'''3.1. Overview'''

'''3.2. Phase 1: Before Development Begins '''

'''3.3. Phase 2: During Definition and Design'''

'''3.4. Phase 3: During Development'''

'''3.5. Phase 4: During Deployment'''

'''3.6. Phase 5: Maintenance and Operations'''

'''3.7. A Typical SDLC Testing Workflow '''

==[[Web Application Penetration Testing |4. Web Application Penetration Testing ]]==

[[Testing: Introduction and objectives|'''4.1 Introduction and Objectives''']] [To review--> Mat]

[[Testing Checklist| 4.1.1 Testing Checklist]] [To review at the end of brainstorming --> Mat]

[[Testing Information Gathering|'''4.2 Information Gathering ''']]

[[Testing: Search engine discovery/reconnaissance (OWASP-IG-002)|4.2.1 Conduct Search Engine Discovery and Reconnaissance for Information Leakage (OTG-INFO-001) ]] formerly "Search Engine Discovery/Reconnaissance (OWASP-IG-002)"

[[Fingerprint Web Server (OTG-INFO-002)|4.2.2 Fingerprint Web Server (OTG-INFO-002) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-004)"

[[Testing: Spiders, Robots, and Crawlers (OWASP-IG-001)|4.2.3 Review Webserver Metafiles for Information Leakage (OTG-INFO-003) ]] formerly "Spiders, Robots and Crawlers (OWASP-IG-001)"

[[Testing for Application Discovery (OWASP-IG-005)|4.2.4 Enumerate Applications on Webserver (OTG-INFO-004) ]] formerly "Application Discovery (OWASP-IG-005)"

[[Testing Review webpage comments and metadata(OWASP-IG-007)|4.2.5 Review Webpage Comments and Metadata for Information Leakage (OTG-INFO-005) ]] formerly "Review webpage comments and metadata(OWASP-IG-007)"

[[Testing: Identify application entry points (OWASP-IG-003)|4.2.6 Identify application entry points (OTG-INFO-006) ]] formerly "Identify application entry points (OWASP-IG-003)"

[[Testing Map execution paths through application (OWASP-IG-009)|4.2.8 Map execution paths through application (OTG-INFO-008)]] formerly "Map execution paths through application (OWASP-IG-009)"

[[Fingerprint Web Application Framework (OTG-INFO-009)|4.2.9 Fingerprint Web Application Framework (OTG-INFO-009) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-010)" '''Ready to be reviewed'''

[[Testing for Web Application (OTG-INFO-011)|4.2.10 Fingerprint Web Application (OTG-INFO-010) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-010)" [Amro AlOlaqi] '''Ready to be reviewed'''

[[Map Network and Application Architecture (OTG-INFO-012)|4.2.11 Map Network and Application Architecture (OTG-INFO-011) ]] formerly "Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)" [Amro AlOlaqi] '''Ready to be reviewed'''

[[Testing for configuration management|'''4.3 Configuration and Deploy Management Testing ''']]

[[Testing for infrastructure configuration management (OWASP-CM-003)|4.3.1 Test Network/Infrastructure Configuration (OTG-CONFIG-001) ]] formerly "Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)"

[[Testing for application configuration management (OWASP-CM-004)|4.3.2 Test Application Platform Configuration (OTG-CONFIG-002) ]] formerly "Testing for Application Configuration Management weakness (OWASP-CM-002)" [Amro AlOlaqi] '''Ready to be reviewed'''

[[Testing for file extensions handling (OWASP-CM-005)|4.3.3 Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003) ]] formerly "Testing for File Extensions Handling (OWASP-CM-003)"

[[Testing for Old, Backup and Unreferenced Files (OWASP-CM-006)|4.3.4 Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004) ]] formerly "Old, Backup and Unreferenced Files (OWASP-CM-004)"

[[Testing for Admin Interfaces (OWASP-CM-007)|4.3.5 Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005) ]] formerly "Infrastructure and Application Admin Interfaces (OWASP-CM-005)" [Amro AlOlaqi] '''Ready to be reviewed'''

[[Testing for HTTP Methods and XST (OWASP-CM-008)|4.3.6 Test HTTP Methods (OTG-CONFIG-006) ]] formerly "Testing for Bad HTTP Methods (OWASP-CM-006)"

[[Testing for Database credentials/connection strings available|4.3.7 Testing for Database credentials/connection strings available (OTG-CONFIG-007) ]] formerly "Testing for Database credentials/connection strings available (OWASP-CM-007)"

[[Testing for Content Security Policy weakness|4.3.8 Test Content Security Policy (OTG-CONFIG-008) ]] formerly "Testing for Content Security Policy weakness (OWASP-CM-008)"

[[Testing for Missing HSTS header|4.3.9 Test HTTP Strict Transport Security (OTG-CONFIG-009) ]] formerly "Testing for Missing HSTS header (OWASP-CM-009)"

[[Testing for Frame Options|4.3.10 Test Frame Options (OTG-CONFIG-010) ]]

[[Testing for RIA policy files weakness|4.3.11 Test RIA cross domain policy (OTG-CONFIG-011) ]] formerly "Testing for RIA policy files weakness (OWASP-CM-010)"

[[Testing for Content Type Options|4.3.12 Test Content Type Options (OTG-CONFIG-012) ]] new

[[Testing Identity Management|'''4.4 Identity Management Testing''']]

[[Test Role Definitions (OTG-IDENT-001)|4.4.1 Test Role Definitions (OTG-IDENT-001)]] New

[[Test User Registration Process (OTG-IDENT-002)|4.4.2 Test User Registration Process (OTG-IDENT-002)]] New

[[Test Account Provisioning Process (OTG-IDENT-003)|4.4.3 Test Account Provisioning Process (OTG-IDENT-003)]] New

[[Testing for Account Enumeration and Guessable User Account (OWASP-AT-002)|4.4.4 Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004) ]] formerly "Testing for Account Enumeration and Guessable User Account (OWASP-AT-002)"

[[Testing for Weak or unenforced username policy (OWASP-AT-009)| 4.4.5 Testing for Weak or unenforced username policy (OTG-IDENT-005)]] formerly "Testing for Weak or unenforced username policy (OWASP-AT-009)

[[Test Permissions of Guest/Training Accounts (OTG-IDENT-006)|4.4.6 Test Permissions of Guest/Training Accounts (OTG-IDENT-006)]] New

[[Test Account Suspension/Resumption Process (OTG-IDENT-007)|4.4.7 Test Account Suspension/Resumption Process (OTG-IDENT-007)]] New

[[Test User Deregistration Process (OTG-IDENT-008)|4.4.8 Test User Deregistration Process (OTG-IDENT-008)]] New

[[Test Account Deregistration Process (OTG-IDENT-009)|4.4.9 Test Account Deregistration Process (OTG-IDENT-009)]] New

[[Testing for authentication|'''4.5 Authentication Testing ''']]

[[Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|4.5.1 Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]] formerly "Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)"

[[Testing for default credentials (OWASP-AT-003)|4.5.2 Testing for default credentials (OTG-AUTHN-002)]] formerly "Testing for default credentials (OWASP-AT-003)"

[[Testing for Weak lock out mechanism (OWASP-AT-004)|4.5.3 Testing for Weak lock out mechanism (OTG-AUTHN-003)]] formerly "Testing for Weak lock out mechanism (OWASP-AT-004)"

[[Testing for Bypassing Authentication Schema (OWASP-AT-005)|4.5.4 Testing for bypassing authentication schema (OTG-AUTHN-004)]] formerly "Testing for bypassing authentication schema (OWASP-AT-005)"

[[Testing for Vulnerable Remember Password (OWASP-AT-006)|4.5.5 Test remember password functionality (OTG-AUTHN-005)]] formerly "Testing for vulnerable remember password functionality (OWASP-AT-006)"

[[Testing for Browser cache weakness (OWASP-AT-007)|4.5.6 Testing for Browser cache weakness (OTG-AUTHN-006)]] formerly "Testing for Browser cache weakness (OWASP-AT-007)"

[[Testing for Weak password policy (OWASP-AT-008)|4.5.7 Testing for Weak password policy (OTG-AUTHN-007)]] formerly "Testing for Weak password policy (OWASP-AT-008)"

[[Testing for Weak security question/answer (OTG-AUTHN-008)|4.5.8 Testing for Weak security question/answer (OTG-AUTHN-008)]] New! - Robert Winkel

[[Testing for weak password change or reset functionalities (OWASP-AT-011)|4.5.9 Testing for weak password change or reset functionalities (OTG-AUTHN-009)]] formerly "Testing for weak password change or reset functionalities (OWASP-AT-011)"

[[Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)|4.5.10 Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)]] (e.g. mobile app, IVR, help desk)

[[Testing for Authorization|'''4.6 Authorization Testing''']]

[[Test Management of Account Permissions (OTG-AUTHZ-001)|4.6.1 Test Management of Account Permissions (OTG-AUTHZ-001)]] New

[[Testing for Path Traversal (OWASP-AZ-001)|4.6.2 Testing Directory traversal/file include (OTG-AUTHZ-002)]] formerly "Testing Directory traversal/file include (OWASP-AZ-001)"

[[Testing for Bypassing Authorization Schema (OWASP-AZ-002)|4.6.3 Testing for bypassing authorization schema (OTG-AUTHZ-003)]] formerly "Testing for bypassing authorization schema (OWASP-AZ-002)"

[[Testing for Privilege escalation (OWASP-AZ-003)|4.6.4 Testing for Privilege Escalation (OTG-AUTHZ-004)]] formerly "Testing for Privilege Escalation (OWASP-AZ-003)"

[[Testing for Insecure Direct Object References (OWASP-AZ-004)|4.6.5 Testing for Insecure Direct Object References (OTG-AUTHZ-005)]] formerly "Testing for Insecure Direct Object References (OWASP-AZ-004)"

[[Testing for Failure to Restrict access to authorized resource (OWASP-AZ-005)|4.6.6 Testing for Failure to Restrict access to authorized resource (OTG-AUTHZ-006)]] formerly "Testing for Failure to Restrict access to authorized resource (OWASP-AZ-005)"

[[Test privileges of server components (OTG-AUTHZ-007)|4.6.7 Test privileges of server components (OTG-AUTHZ-007)]] (e.g. indexing service, reporting interface, file generator)

[[Test enforcement of application entry points (OTG-AUTHZ-008)|4.6.8 Test enforcement of application entry points (OTG-AUTHZ-008)]] (including exposure of objects)

[[Testing for failure to restrict access to authenticated resource(OWASP-AT-010)|4.6.9 Testing for failure to restrict access to authenticated resource (OTG-AUTHZ-009)]] formerly "Testing for failure to restrict access to authenticated resource (OWASP-AT-010)"

[[Testing for Session Management|'''4.7 Session Management Testing''']]

[[Testing for Session_Management_Schema (OWASP-SM-001)|4.7.1 Testing for Bypassing Session Management Schema (OTG-SESS-001)]] formerly "Testing for Bypassing Session Management Schema (OWASP-SM-001)"

[[Testing for cookies attributes (OWASP-SM-002)|4.7.2 Testing for Cookies attributes (OTG-SESS-002)]] formerly "Testing for Cookies attributes (OWASP-SM-002)" (Cookies are set not ‘HTTP Only’, ‘Secure’, and no time validity)

[[Testing for Session Fixation (OWASP-SM-003)|4.7.3 Testing for Session Fixation (OTG-SESS-003)]] formerly "Testing for Session Fixation (OWASP-SM-003)"

[[Testing for Exposed Session Variables (OWASP-SM-004)|4.7.4 Testing for Exposed Session Variables (OTG-SESS-004)]] formerly "Testing for Exposed Session Variables (OWASP-SM-004)"

[[Testing for CSRF (OWASP-SM-005)|4.7.5 Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)]] formerly "Testing for Cross Site Request Forgery (CSRF) (OWASP-SM-005)"

[[Test Session Token Strength (OTG-SESS-006)|4.7.6 Test Session Token Strength (OTG-SESS-006)]]

[[Testing for logout functionality (OWASP-SM-007)|4.7.7 Testing for logout functionality (OTG-SESS-007)]] formerly "Testing for logout functionality (OWASP-SM-007)"

[[Test Session Timeout (OTG-SESS-008)|4.7.8 Test Session Timeout (OTG-SESS-008)]]

[[Test multiple concurrent sessions (OTG-SESS-009)|4.7.9 Test multiple concurrent sessions (OTG-SESS-009)]]

[[Testing for Session puzzling (OTG-SESS-010)|4.7.10 Testing for Session puzzling (OTG-SESS-010)]]

[[Testing for Data Validation|'''4.8 Data Validation Testing''']]

[[Testing for Reflected Cross site scripting (OWASP-DV-001) |4.8.1 Testing for Reflected Cross Site Scripting (OTG-INPVAL-001)]] formerly "Testing for Reflected Cross Site Scripting (OWASP-DV-001)"

[[Testing for Stored Cross site scripting (OWASP-DV-002) |4.8.2 Testing for Stored Cross Site Scripting (OTG-INPVAL-002)]] formerly "Testing for Stored Cross Site Scripting (OWASP-DV-002)"

[[Testing for HTTP Verb Tampering (OWASP-DV-003)|4.8.3 Testing for HTTP Verb Tampering (OTG-INPVAL-003)]] formerly "Testing for HTTP Verb Tampering (OWASP-DV-003)"

[[Testing for HTTP Parameter pollution (OWASP-DV-004)|4.8.4 Testing for HTTP Parameter pollution (OTG-INPVAL-004) ]] formerly "Testing for HTTP Parameter pollution (OWASP-DV-004)"

[[Testing for Unvalidated Redirects and Forwards (OWASP-DV-004)|4.8.5 Testing for Unvalidated Redirects and Forwards (OTG-INPVAL-005) ]] formerly "Testing for Unvalidated Redirects and Forwards (OWASP-DV-004)"

[[Testing for SQL Injection (OWASP-DV-005)| 4.8.6 Testing for SQL Injection (OTG-INPVAL-006)]] formerly "Testing for SQL Injection (OWASP-DV-005)" '''Ready to be reviewed'''

[[Testing for Oracle|4.8.6.1 Oracle Testing]]

[[Testing for MySQL|4.8.6.2 MySQL Testing [Ismael Gonçalves]]]

[[Testing for SQL Server|4.8.6.3 SQL Server Testing]]

[[OWASP_Backend_Security_Project_Testing_PostgreSQL|4.8.6.4 Testing PostgreSQL (from OWASP BSP) ]]

[[Testing for MS Access |4.8.6.5 MS Access Testing]]

[[Testing for NoSQL injection|4.8.6.6 Testing for NoSQL injection [New!]]]

[[Testing for LDAP Injection (OWASP-DV-006)|4.8.7 Testing for LDAP Injection (OTG-INPVAL-007)]] formerly "Testing for LDAP Injection (OWASP-DV-006)"

[[Testing for ORM Injection (OWASP-DV-007)|4.8.8 Testing for ORM Injection (OTG-INPVAL-008)]] formerly "Testing for ORM Injection (OWASP-DV-007)"

[[Testing for XML Injection (OWASP-DV-008)|4.8.9 Testing for XML Injection (OTG-INPVAL-009)]] formerly "Testing for XML Injection (OWASP-DV-008)"

[[Testing for SSI Injection (OWASP-DV-009)|4.8.10 Testing for SSI Injection (OTG-INPVAL-010)]] formerly "Testing for SSI Injection (OWASP-DV-009)"

[[Testing for XPath Injection (OWASP-DV-010)|4.8.11 Testing for XPath Injection (OTG-INPVAL-011)]] formerly "Testing for XPath Injection (OWASP-DV-010)"

[[Testing for IMAP/SMTP Injection (OWASP-DV-011)|4.8.12 IMAP/SMTP Injection (OTG-INPVAL-012)]] formerly "IMAP/SMTP Injection (OWASP-DV-011)"

[[Testing for Code Injection (OWASP-DV-012)|4.8.13 Testing for Code Injection (OTG-INPVAL-013)]] formerly "Testing for Code Injection (OWASP-DV-012)"

[[Testing for Local File Inclusion|4.8.13.1 Testing for Local File Inclusion]] [Alexander Antukh]

[[Testing for Remote File Inclusion|4.8.13.2 Testing for Remote File Inclusion]] [Alexander Antukh]

[[Testing for Command Injection (OWASP-DV-013)|4.8.14 Testing for Command Injection (OTG-INPVAL-014)]] formerly "Testing for Command Injection (OWASP-DV-013)"

[[Testing for Buffer Overflow (OWASP-DV-014)|4.8.15 Testing for Buffer overflow (OTG-INPVAL-015)]] formerly "Testing for Buffer overflow (OWASP-DV-014)"

[[Testing for Heap Overflow|4.8.15.1 Testing for Heap overflow]]

[[Testing for Stack Overflow|4.8.15.2 Testing for Stack overflow]]

[[Testing for Format String|4.8.15.3 Testing for Format string]]

[[Testing for Incubated Vulnerability (OWASP-DV-015)|4.8.16 Testing for incubated vulnerabilities (OTG-INPVAL-016)]] formerly "Testing for incubated vulnerabilities (OWASP-DV-015)"

[[Testing for HTTP Splitting/Smuggling (OWASP-DV-016)|4.8.17 Testing for HTTP Splitting/Smuggling (OTG-INPVAL-017) ]] formerly "Testing for HTTP Splitting/Smuggling (OWASP-DV-016)" [Juan Galiana]

[[Error Handling|'''4.9 Error Handling''']]

[[Testing for Error Code (OWASP-IG-006)|4.9.1 Analysis of Error Codes (OTG-ERR-001)]] formerly "Analysis of Error Codes (OWASP-IG-006)"

[[Testing for Stack Traces (OWASP-IG-XXX)|4.9.2 Analysis of Stack Traces (OTG-ERR-002)]] formerly "Analysis of Stack Traces"

[[Cryptography|'''4.10 Cryptography''']]

[[Testing for Insecure encryption usage (OWASP-EN-001)| 4.10.1 Testing for Insecure encryption usage (OTG-CRYPST-001)]] formerly "Testing for Insecure encryption usage (OWASP-EN-001)"

[[Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)| 4.10.2 Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-002)]] formerly "Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)" [Simone Onofri]

[[Testing for Padding Oracle (OWASP-EN-003)| 4.10.3 Testing for Padding Oracle (OTG-CRYPST-003)]] formerly "Testing for Padding Oracle (OWASP-EN-003)"

[[Testing for Cacheable HTTPS Response (OTG-CRYPST-004)| 4.10.4 Testing for Cacheable HTTPS Response (OTG-CRYPST-004)]]

[[Test Cache Directives (OTG-CRYPST-005)|4.10.5 Test Cache Directives (OTG-CRYPST-005)]]

[[Testing for Insecure Cryptographic Storage (OTG-CRYPST-006)|4.10.6 Testing for Insecure Cryptographic Storage (OTG-CRYPST-006)]]

[[Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|4.10.7 Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)]] [Simone Onofri]

[[Test Cryptographic Key Management (OTG-CRYPST-008)|4.10.8 Test Cryptographic Key Management (OTG-CRYPST-008)]]

[[Logging|'''4.11 Logging''']] Not convinced Logging should be included as it requires access to logs to test

[[Test time synchronisation (OTG-LOG-001)|4.11.1 Test time synchronisation (OTG-LOG-001) ]] formerly "Incorrect time"

[[Test user-viewable log of authentication events (OTG-LOG-002)|4.11.2 Test user-viewable log of authentication events (OTG-LOG-002)]]

[[Testing for business logic (OWASP-BL-001)|'''4.12 Business Logic Testing (OWASP-BL-001)''']]
Business Logic<br>

[[Test business logic data validation (OTG-BUSLOGIC-001)|4.12.1 Test Business Logic Data Validation (OTG-BUSLOGIC-001)]]

[[Test Ability to forge requests (OTG-BUSLOGIC-002)|4.12.2 Test Ability to Forge Requests (OTG-BUSLOGIC-002)]]

[[Test integrity checks (OTG-BUSLOGIC-003)|4.12.3 Test Integrity Checks (OTG-BUSLOGIC-003)]]

[[Test for Process Timing (OTG-BUSLOGIC-007)|4.12.4 Test for Process Timing (OTG-BUSLOGIC-004)]]

[[Test number of times a function can be used limits (OTG-BUSLOGIC-007)|4.12.5 Test Number of Times a Function Can be Used Limits (OTG-BUSLOGIC-005)]]

[[Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-009)|4.12.6 Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-006)]]

[[Test defenses against application mis-use (OTG-BUSLOGIC-011)|4.12.7 Test Defenses Against Application Mis-use (OTG-BUSLOGIC-007)]]

[[Test Upload of Unexpected File Types (OTG-BUSLOGIC-015)|4.12.8 Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)]]

[[Test Upload of Malicious Files (OTG-BUSLOGIC-016)|4.12.9 Test Upload of Malicious Files (OTG-BUSLOGIC-009)]]

[[Client Side Testing|'''4.15 Client Side Testing''']] [New!]

[[Testing for DOM-based Cross site scripting (OWASP-DV-003)|4.15.1 Testing for DOM based Cross Site Scripting (OTG-CLIENT-001)]] formerly "Testing for DOM based Cross Site Scripting (OWASP-CS-001)" [Stefano Di Paola]

[[Testing for JavaScript Execution|4.15.2 Testing for JavaScript Execution (OWASP-CS-002)]] (Stefano Di Paola, Matteo Meucci)

[[Testing for HTML Injection|4.15.3 Testing for HTML Injection (OWASP-CS-003)]] (Stefano Di Paola, Matteo Meucci)

[[Testing for Client Side URL Redirect|4.15.4 Testing for Client Side URL Redirect (OWASP-CS-004)]] (Mauro Gentile, Davide Danelon)

[[Testing_for_CSS_Injection|4.15.5 Testing for CSS Injection (OWASP-CS-005)]] (Mauro Gentile, Davide Danelon)

[[Testing_for_Client_Side_Resource_Manipulation|4.15.6 Testing for Client Side Resource Manipulation (OWASP-CS-006)]] (Mauro Gentile, Davide Danelon)

[[Test Cross Origin Resource Sharing (OTG-CLIENT-002)|4.15.7 Test Cross Origin Resource Sharing (OTG-CLIENT-007)]] formerly "Testing for HTML5 (OWASP CS-002)" [Juan Galiana]

[[Testing for Cross site flashing (OWASP-DV-004)|4.15.8 Testing for Cross Site Flashing (OTG-CLIENT-008)]] formerly "Testing for Cross Site Flashing (OWASP-CS-003)"

[[Testing for Clickjacking (OWASP-CS-004)|4.15.9 Testing for Clickjacking (OTG-CLIENT-009)]] formerly "Testing for Clickjacking (OWASP-CS-004)" [Davide Danelon]

[[Testing WebSockets (OTG-CLIENT-005)|4.15.10 Testing WebSockets (OTG-CLIENT-010)]] [Ryan Dewhurst]

[[Test Web Messaging (OTG-CLIENT-006)|4.15.11 Test Web Messaging (OTG-CLIENT-011)]] [Juan Galiana]

[[Test Local Storage (OTG-CLIENT-007)|4.15.12 Test Local Storage (OTG-CLIENT-012)]] [Juan Galiana]

==[[Writing Reports: value the real risk |5. Writing Reports: value the real risk ]]==

[[How to value the real risk |5.1 How to value the real risk]] [To review--> Amro AlOlaqi] '''Ready to be reviewed'''

[[How to write the report of the testing |5.2 How to write the report of the testing]] [To review--> Amro AlOlaqi] '''Ready to be reviewed'''

==[[Appendix A: Testing Tools |Appendix A: Testing Tools ]]==

* Black Box Testing Tools [To review--> Amro AlOlaqi] '''Ready to be reviewed'''

==[[OWASP Testing Guide Appendix B: Suggested Reading | Appendix B: Suggested Reading]]==
* Whitepapers [To review--> David Fern]
* Books [To review--> David Fern]
* Useful Websites [To review--> David Fern]

==[[OWASP Testing Guide Appendix C: Fuzz Vectors | Appendix C: Fuzz Vectors]]==

* Fuzz Categories [To review--> Amro AlOlaqi] '''Ready to be reviewed'''

==[[OWASP Testing Guide Appendix D: Encoded Injection | Appendix D: Encoded Injection]]==
[To review--> Amro AlOlaqi] '''Ready to be reviewed'''

----

ARTICLES DELETED:

INFO GATHERING:

BUSINESS LOGIC:

XXXX[[Testing for Forged Requests Using Predictive Parameters (OTG-BUSLOGIC-003)|4.12.3 Testing for Forged Requests Using Predictive Parameters (OTG-BUSLOGIC-003)]] [New!]- [Combine with Test Ability to forge requests as an example]

[[Test integrity checks (OTG-BUSLOGIC-003)|4.12.3 Test Integrity Checks (OTG-BUSLOGIC-003)]] (e.g. overwriting updates)

DENIAL OF SERVICE

[[Denial of Service|'''4.13 Denial of Service''']]

[[Test Regular expression DoS (OTG-DOS-001)| 4.13.1 Test Regular expression DoS (OTG-DOS-001)]] [New!] note: to understand better<br>

[[Test XML DoS (OTG-DOS-002)| 4.13.2 Test XML DoS (OTG-DOS-002)]] [New! - Andrew Muller]

[[Testing for Captcha (OWASP-AT-012)|4.13.3 Testing for CAPTCHA (OTG-DOS-003)]] formerly "Testing for CAPTCHA (OWASP-AT-012)"

[[Test excessive rate (speed) of use limits (OTG-BUSLOGIC-005)|4.13.4 Test excessive rate (speed) of use limits (OTG-DOS-004)]] [New!]- [Moved from Business Logic, formerly OTG-BUSLOGIC-006]

[[Test size of request limits (OTG-BUSLOGIC-006)|4.13.5 Test size of request limits (OTG-DOS-005)]] [New!] - [Moved from Business Logic, formerly OTG-BUSLOGIC-008]

WEB SERVICES TESTING

[[Web Service (XML Interpreter)|'''4.14 Web Service Testing''']] [Tom Eston]

[[Scoping a Web Service Test (OWASP-WS-001)|4.14.1 Scoping a Web Service Test (OTG-WEBSVC-001)]] formerly "Scoping a Web Service Test (OWASP-WS-001)"

[[WS Information Gathering (OWASP-WS-002)|4.14.2 WS Information Gathering (OTG-WEBSVC-002)]] formerly "WS Information Gathering (OWASP-WS-002)"

[[WS Authentication Testing (OWASP-WS-003)|4.14.3 WS Authentication Testing (OTG-WEBSVC-003)]] formerly "WS Authentication Testing (OWASP-WS-003)"

[[WS Management Interface Testing (OWASP-WS-004)|4.14.4 WS Management Interface Testing (OTG-WEBSVC-004)]] formerly "WS Management Interface Testing (OWASP-WS-004)"

[[Weak XML Structure Testing (OWASP-WS-005)|4.14.5 Weak XML Structure Testing (OTG-WEBSVC-005)]] formerly "Weak XML Structure Testing (OWASP-WS-005)"

[[XML Content-Level Testing (OWASP-WS-006)|4.14.6 XML Content-Level Testing (OTG-WEBSVC-006)]] formerly "XML Content-Level Testing (OWASP-WS-006)"

[[WS HTTP GET Parameters/REST Testing (OWASP-WS-007)|4.14.7 WS HTTP GET Parameters/REST Testing (OTG-WEBSVC-007)]] formerly "WS HTTP GET Parameters/REST Testing (OWASP-WS-007)"

[[WS Naughty SOAP Attachment Testing (OWASP-WS-008)|4.14.8 WS Naughty SOAP Attachment Testing (OTG-WEBSVC-008)]] formerly "WS Naughty SOAP Attachment Testing (OWASP-WS-008)"

[[WS Replay/MiTM Testing (OWASP-WS-009)|4.14.9 WS Replay/MiTM Testing (OTG-WEBSVC-009)]] formerly "WS Replay/MiTM Testing (OWASP-WS-009)"

[[WS BEPL Testing (OWASP-WS-010)|4.14.10 WS BEPL Testing (OTG-WEBSVC-010)]] formerly "WS BEPL Testing (OWASP-WS-010)"

[[Category:OWASP Testing Project]]

OWASP Testing Guide v4 Table of Contents

2013-12-22T23:13:54Z

David Fern:

{{OWASP Breakers}}
__NOTOC__

'''This is the DRAFT of the table of content of the New Testing Guide v4.'''<br>
<br>You can download the stable version v3 [http://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf here] <br>

Back to the OWASP Testing Guide Project:
http://www.owasp.org/index.php/OWASP_Testing_Project

'''Updated: 16th December 2013'''

[[ OWTGv4 Contributors list|'''Contributors List]]

----

The following is a DRAFT of the Toc based on the feedback already received.

== Table of Contents ==

==[[Testing Guide Foreword|Foreword by Eoin Keary]]==
[To review--> Eoin Keary -> Done!!]

==[[Testing Guide Frontispiece |1. Frontispiece]]==
[To review--> Mat]

'''[[Testing Guide Frontispiece|1.1 About the OWASP Testing Guide Project]]'''
[To review--> Mat]

'''[[About The Open Web Application Security Project|1.2 About The Open Web Application Security Project]]'''
[To review--> ]

==[[Testing Guide Introduction|2. Introduction]]==

'''2.1 The OWASP Testing Project'''

'''2.2 Principles of Testing'''

'''2.3 Testing Techniques Explained'''

2.4 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Requirements_Test_Derivation Security requirements test derivation],[https://www.owasp.org/index.php/Testing_Guide_Introduction#Functional_and_Non_Functional_Test_Requirements functional and non functional test requirements], and [https://www.owasp.org/index.php/Testing_Guide_Introduction#Test_Cases_Through_Use_and_Misuse_Cases test cases through use and misuse cases]

2.5 [https://www.owasp.org/index.php/Testing_Guide_Introduction#Security_Test_Data_Analysis_and_Reporting Security test data analysis and reporting: root cause identification and business/role case test data reporting]

==[[The OWASP Testing Framework|3. The OWASP Testing Framework]]==

'''3.1. Overview'''

'''3.2. Phase 1: Before Development Begins '''

'''3.3. Phase 2: During Definition and Design'''

'''3.4. Phase 3: During Development'''

'''3.5. Phase 4: During Deployment'''

'''3.6. Phase 5: Maintenance and Operations'''

'''3.7. A Typical SDLC Testing Workflow '''

==[[Web Application Penetration Testing |4. Web Application Penetration Testing ]]==

[[Testing: Introduction and objectives|'''4.1 Introduction and Objectives''']] [To review--> Mat]

[[Testing Checklist| 4.1.1 Testing Checklist]] [To review at the end of brainstorming --> Mat]

[[Testing Information Gathering|'''4.2 Information Gathering ''']]

[[Testing: Search engine discovery/reconnaissance (OWASP-IG-002)|4.2.1 Conduct Search Engine Discovery and Reconnaissance for Information Leakage (OTG-INFO-001) ]] formerly "Search Engine Discovery/Reconnaissance (OWASP-IG-002)"

[[Fingerprint Web Server (OTG-INFO-002)|4.2.2 Fingerprint Web Server (OTG-INFO-002) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-004)"

[[Testing: Spiders, Robots, and Crawlers (OWASP-IG-001)|4.2.3 Review Webserver Metafiles for Information Leakage (OTG-INFO-003) ]] formerly "Spiders, Robots and Crawlers (OWASP-IG-001)"

[[Testing for Application Discovery (OWASP-IG-005)|4.2.4 Enumerate Applications on Webserver (OTG-INFO-004) ]] formerly "Application Discovery (OWASP-IG-005)"

[[Testing Review webpage comments and metadata(OWASP-IG-007)|4.2.5 Review Webpage Comments and Metadata for Information Leakage (OTG-INFO-005) ]] formerly "Review webpage comments and metadata(OWASP-IG-007)"

[[Testing: Identify application entry points (OWASP-IG-003)|4.2.6 Identify application entry points (OTG-INFO-006) ]] formerly "Identify application entry points (OWASP-IG-003)"

[[Testing Map execution paths through application (OWASP-IG-009)|4.2.8 Map execution paths through application (OTG-INFO-008)]] formerly "Map execution paths through application (OWASP-IG-009)"

[[Fingerprint Web Application Framework (OTG-INFO-009)|4.2.9 Fingerprint Web Application Framework (OTG-INFO-009) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-010)" '''Ready to be reviewed'''

[[Testing for Web Application (OTG-INFO-011)|4.2.10 Fingerprint Web Application (OTG-INFO-010) ]] formerly "Testing for Web Application Fingerprint (OWASP-IG-010)" [Amro AlOlaqi] '''Ready to be reviewed'''

[[Map Network and Application Architecture (OTG-INFO-012)|4.2.11 Map Network and Application Architecture (OTG-INFO-011) ]] formerly "Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)" [Amro AlOlaqi] '''Ready to be reviewed'''

[[Testing for configuration management|'''4.3 Configuration and Deploy Management Testing ''']]

[[Testing for infrastructure configuration management (OWASP-CM-003)|4.3.1 Test Network/Infrastructure Configuration (OTG-CONFIG-001) ]] formerly "Testing for Infrastructure Configuration Management Testing weakness (OWASP-CM-001)"

[[Testing for application configuration management (OWASP-CM-004)|4.3.2 Test Application Platform Configuration (OTG-CONFIG-002) ]] formerly "Testing for Application Configuration Management weakness (OWASP-CM-002)" [Amro AlOlaqi] '''Ready to be reviewed'''

[[Testing for file extensions handling (OWASP-CM-005)|4.3.3 Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003) ]] formerly "Testing for File Extensions Handling (OWASP-CM-003)"

[[Testing for Old, Backup and Unreferenced Files (OWASP-CM-006)|4.3.4 Review Old, Backup and Unreferenced Files for Sensitive Information (OTG-CONFIG-004) ]] formerly "Old, Backup and Unreferenced Files (OWASP-CM-004)"

[[Testing for Admin Interfaces (OWASP-CM-007)|4.3.5 Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005) ]] formerly "Infrastructure and Application Admin Interfaces (OWASP-CM-005)" [Amro AlOlaqi] '''Ready to be reviewed'''

[[Testing for HTTP Methods and XST (OWASP-CM-008)|4.3.6 Test HTTP Methods (OTG-CONFIG-006) ]] formerly "Testing for Bad HTTP Methods (OWASP-CM-006)"

[[Testing for Database credentials/connection strings available|4.3.7 Testing for Database credentials/connection strings available (OTG-CONFIG-007) ]] formerly "Testing for Database credentials/connection strings available (OWASP-CM-007)"

[[Testing for Content Security Policy weakness|4.3.8 Test Content Security Policy (OTG-CONFIG-008) ]] formerly "Testing for Content Security Policy weakness (OWASP-CM-008)"

[[Testing for Missing HSTS header|4.3.9 Test HTTP Strict Transport Security (OTG-CONFIG-009) ]] formerly "Testing for Missing HSTS header (OWASP-CM-009)"

[[Testing for Frame Options|4.3.10 Test Frame Options (OTG-CONFIG-010) ]]

[[Testing for RIA policy files weakness|4.3.11 Test RIA cross domain policy (OTG-CONFIG-011) ]] formerly "Testing for RIA policy files weakness (OWASP-CM-010)"

[[Testing for Content Type Options|4.3.12 Test Content Type Options (OTG-CONFIG-012) ]] new

[[Testing Identity Management|'''4.4 Identity Management Testing''']]

[[Test Role Definitions (OTG-IDENT-001)|4.4.1 Test Role Definitions (OTG-IDENT-001)]] New

[[Test User Registration Process (OTG-IDENT-002)|4.4.2 Test User Registration Process (OTG-IDENT-002)]] New

[[Test Account Provisioning Process (OTG-IDENT-003)|4.4.3 Test Account Provisioning Process (OTG-IDENT-003)]] New

[[Testing for Account Enumeration and Guessable User Account (OWASP-AT-002)|4.4.4 Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004) ]] formerly "Testing for Account Enumeration and Guessable User Account (OWASP-AT-002)"

[[Testing for Weak or unenforced username policy (OWASP-AT-009)| 4.4.5 Testing for Weak or unenforced username policy (OTG-IDENT-005)]] formerly "Testing for Weak or unenforced username policy (OWASP-AT-009)

[[Test Permissions of Guest/Training Accounts (OTG-IDENT-006)|4.4.6 Test Permissions of Guest/Training Accounts (OTG-IDENT-006)]] New

[[Test Account Suspension/Resumption Process (OTG-IDENT-007)|4.4.7 Test Account Suspension/Resumption Process (OTG-IDENT-007)]] New

[[Test User Deregistration Process (OTG-IDENT-008)|4.4.8 Test User Deregistration Process (OTG-IDENT-008)]] New

[[Test Account Deregistration Process (OTG-IDENT-009)|4.4.9 Test Account Deregistration Process (OTG-IDENT-009)]] New

[[Testing for authentication|'''4.5 Authentication Testing ''']]

[[Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)|4.5.1 Testing for Credentials Transported over an Encrypted Channel (OTG-AUTHN-001)]] formerly "Testing for Credentials Transported over an Encrypted Channel (OWASP-AT-001)"

[[Testing for default credentials (OWASP-AT-003)|4.5.2 Testing for default credentials (OTG-AUTHN-002)]] formerly "Testing for default credentials (OWASP-AT-003)"

[[Testing for Weak lock out mechanism (OWASP-AT-004)|4.5.3 Testing for Weak lock out mechanism (OTG-AUTHN-003)]] formerly "Testing for Weak lock out mechanism (OWASP-AT-004)"

[[Testing for Bypassing Authentication Schema (OWASP-AT-005)|4.5.4 Testing for bypassing authentication schema (OTG-AUTHN-004)]] formerly "Testing for bypassing authentication schema (OWASP-AT-005)"

[[Testing for Vulnerable Remember Password (OWASP-AT-006)|4.5.5 Test remember password functionality (OTG-AUTHN-005)]] formerly "Testing for vulnerable remember password functionality (OWASP-AT-006)"

[[Testing for Browser cache weakness (OWASP-AT-007)|4.5.6 Testing for Browser cache weakness (OTG-AUTHN-006)]] formerly "Testing for Browser cache weakness (OWASP-AT-007)"

[[Testing for Weak password policy (OWASP-AT-008)|4.5.7 Testing for Weak password policy (OTG-AUTHN-007)]] formerly "Testing for Weak password policy (OWASP-AT-008)"

[[Testing for Weak security question/answer (OTG-AUTHN-008)|4.5.8 Testing for Weak security question/answer (OTG-AUTHN-008)]] New! - Robert Winkel

[[Testing for weak password change or reset functionalities (OWASP-AT-011)|4.5.9 Testing for weak password change or reset functionalities (OTG-AUTHN-009)]] formerly "Testing for weak password change or reset functionalities (OWASP-AT-011)"

[[Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)|4.5.10 Testing for Weaker authentication in alternative channel (OTG-AUTHN-010)]] (e.g. mobile app, IVR, help desk)

[[Testing for Authorization|'''4.6 Authorization Testing''']]

[[Test Management of Account Permissions (OTG-AUTHZ-001)|4.6.1 Test Management of Account Permissions (OTG-AUTHZ-001)]] New

[[Testing for Path Traversal (OWASP-AZ-001)|4.6.2 Testing Directory traversal/file include (OTG-AUTHZ-002)]] formerly "Testing Directory traversal/file include (OWASP-AZ-001)"

[[Testing for Bypassing Authorization Schema (OWASP-AZ-002)|4.6.3 Testing for bypassing authorization schema (OTG-AUTHZ-003)]] formerly "Testing for bypassing authorization schema (OWASP-AZ-002)"

[[Testing for Privilege escalation (OWASP-AZ-003)|4.6.4 Testing for Privilege Escalation (OTG-AUTHZ-004)]] formerly "Testing for Privilege Escalation (OWASP-AZ-003)"

[[Testing for Insecure Direct Object References (OWASP-AZ-004)|4.6.5 Testing for Insecure Direct Object References (OTG-AUTHZ-005)]] formerly "Testing for Insecure Direct Object References (OWASP-AZ-004)"

[[Testing for Failure to Restrict access to authorized resource (OWASP-AZ-005)|4.6.6 Testing for Failure to Restrict access to authorized resource (OTG-AUTHZ-006)]] formerly "Testing for Failure to Restrict access to authorized resource (OWASP-AZ-005)"

[[Test privileges of server components (OTG-AUTHZ-007)|4.6.7 Test privileges of server components (OTG-AUTHZ-007)]] (e.g. indexing service, reporting interface, file generator)

[[Test enforcement of application entry points (OTG-AUTHZ-008)|4.6.8 Test enforcement of application entry points (OTG-AUTHZ-008)]] (including exposure of objects)

[[Testing for failure to restrict access to authenticated resource(OWASP-AT-010)|4.6.9 Testing for failure to restrict access to authenticated resource (OTG-AUTHZ-009)]] formerly "Testing for failure to restrict access to authenticated resource (OWASP-AT-010)"

[[Testing for Session Management|'''4.7 Session Management Testing''']]

[[Testing for Session_Management_Schema (OWASP-SM-001)|4.7.1 Testing for Bypassing Session Management Schema (OTG-SESS-001)]] formerly "Testing for Bypassing Session Management Schema (OWASP-SM-001)"

[[Testing for cookies attributes (OWASP-SM-002)|4.7.2 Testing for Cookies attributes (OTG-SESS-002)]] formerly "Testing for Cookies attributes (OWASP-SM-002)" (Cookies are set not ‘HTTP Only’, ‘Secure’, and no time validity)

[[Testing for Session Fixation (OWASP-SM-003)|4.7.3 Testing for Session Fixation (OTG-SESS-003)]] formerly "Testing for Session Fixation (OWASP-SM-003)"

[[Testing for Exposed Session Variables (OWASP-SM-004)|4.7.4 Testing for Exposed Session Variables (OTG-SESS-004)]] formerly "Testing for Exposed Session Variables (OWASP-SM-004)"

[[Testing for CSRF (OWASP-SM-005)|4.7.5 Testing for Cross Site Request Forgery (CSRF) (OTG-SESS-005)]] formerly "Testing for Cross Site Request Forgery (CSRF) (OWASP-SM-005)"

[[Test Session Token Strength (OTG-SESS-006)|4.7.6 Test Session Token Strength (OTG-SESS-006)]]

[[Testing for logout functionality (OWASP-SM-007)|4.7.7 Testing for logout functionality (OTG-SESS-007)]] formerly "Testing for logout functionality (OWASP-SM-007)"

[[Test Session Timeout (OTG-SESS-008)|4.7.8 Test Session Timeout (OTG-SESS-008)]]

[[Test multiple concurrent sessions (OTG-SESS-009)|4.7.9 Test multiple concurrent sessions (OTG-SESS-009)]]

[[Testing for Session puzzling (OTG-SESS-010)|4.7.10 Testing for Session puzzling (OTG-SESS-010)]]

[[Testing for Data Validation|'''4.8 Data Validation Testing''']]

[[Testing for Reflected Cross site scripting (OWASP-DV-001) |4.8.1 Testing for Reflected Cross Site Scripting (OTG-INPVAL-001)]] formerly "Testing for Reflected Cross Site Scripting (OWASP-DV-001)"

[[Testing for Stored Cross site scripting (OWASP-DV-002) |4.8.2 Testing for Stored Cross Site Scripting (OTG-INPVAL-002)]] formerly "Testing for Stored Cross Site Scripting (OWASP-DV-002)"

[[Testing for HTTP Verb Tampering (OWASP-DV-003)|4.8.3 Testing for HTTP Verb Tampering (OTG-INPVAL-003)]] formerly "Testing for HTTP Verb Tampering (OWASP-DV-003)"

[[Testing for HTTP Parameter pollution (OWASP-DV-004)|4.8.4 Testing for HTTP Parameter pollution (OTG-INPVAL-004) ]] formerly "Testing for HTTP Parameter pollution (OWASP-DV-004)"

[[Testing for Unvalidated Redirects and Forwards (OWASP-DV-004)|4.8.5 Testing for Unvalidated Redirects and Forwards (OTG-INPVAL-005) ]] formerly "Testing for Unvalidated Redirects and Forwards (OWASP-DV-004)"

[[Testing for SQL Injection (OWASP-DV-005)| 4.8.6 Testing for SQL Injection (OTG-INPVAL-006)]] formerly "Testing for SQL Injection (OWASP-DV-005)" '''Ready to be reviewed'''

[[Testing for Oracle|4.8.6.1 Oracle Testing]]

[[Testing for MySQL|4.8.6.2 MySQL Testing [Ismael Gonçalves]]]

[[Testing for SQL Server|4.8.6.3 SQL Server Testing]]

[[OWASP_Backend_Security_Project_Testing_PostgreSQL|4.8.6.4 Testing PostgreSQL (from OWASP BSP) ]]

[[Testing for MS Access |4.8.6.5 MS Access Testing]]

[[Testing for NoSQL injection|4.8.6.6 Testing for NoSQL injection [New!]]]

[[Testing for LDAP Injection (OWASP-DV-006)|4.8.7 Testing for LDAP Injection (OTG-INPVAL-007)]] formerly "Testing for LDAP Injection (OWASP-DV-006)"

[[Testing for ORM Injection (OWASP-DV-007)|4.8.8 Testing for ORM Injection (OTG-INPVAL-008)]] formerly "Testing for ORM Injection (OWASP-DV-007)"

[[Testing for XML Injection (OWASP-DV-008)|4.8.9 Testing for XML Injection (OTG-INPVAL-009)]] formerly "Testing for XML Injection (OWASP-DV-008)"

[[Testing for SSI Injection (OWASP-DV-009)|4.8.10 Testing for SSI Injection (OTG-INPVAL-010)]] formerly "Testing for SSI Injection (OWASP-DV-009)"

[[Testing for XPath Injection (OWASP-DV-010)|4.8.11 Testing for XPath Injection (OTG-INPVAL-011)]] formerly "Testing for XPath Injection (OWASP-DV-010)"

[[Testing for IMAP/SMTP Injection (OWASP-DV-011)|4.8.12 IMAP/SMTP Injection (OTG-INPVAL-012)]] formerly "IMAP/SMTP Injection (OWASP-DV-011)"

[[Testing for Code Injection (OWASP-DV-012)|4.8.13 Testing for Code Injection (OTG-INPVAL-013)]] formerly "Testing for Code Injection (OWASP-DV-012)"

[[Testing for Local File Inclusion|4.8.13.1 Testing for Local File Inclusion]] [Alexander Antukh]

[[Testing for Remote File Inclusion|4.8.13.2 Testing for Remote File Inclusion]] [Alexander Antukh]

[[Testing for Command Injection (OWASP-DV-013)|4.8.14 Testing for Command Injection (OTG-INPVAL-014)]] formerly "Testing for Command Injection (OWASP-DV-013)"

[[Testing for Buffer Overflow (OWASP-DV-014)|4.8.15 Testing for Buffer overflow (OTG-INPVAL-015)]] formerly "Testing for Buffer overflow (OWASP-DV-014)"

[[Testing for Heap Overflow|4.8.15.1 Testing for Heap overflow]]

[[Testing for Stack Overflow|4.8.15.2 Testing for Stack overflow]]

[[Testing for Format String|4.8.15.3 Testing for Format string]]

[[Testing for Incubated Vulnerability (OWASP-DV-015)|4.8.16 Testing for incubated vulnerabilities (OTG-INPVAL-016)]] formerly "Testing for incubated vulnerabilities (OWASP-DV-015)"

[[Testing for HTTP Splitting/Smuggling (OWASP-DV-016)|4.8.17 Testing for HTTP Splitting/Smuggling (OTG-INPVAL-017) ]] formerly "Testing for HTTP Splitting/Smuggling (OWASP-DV-016)" [Juan Galiana]

[[Error Handling|'''4.9 Error Handling''']]

[[Testing for Error Code (OWASP-IG-006)|4.9.1 Analysis of Error Codes (OTG-ERR-001)]] formerly "Analysis of Error Codes (OWASP-IG-006)"

[[Testing for Stack Traces (OWASP-IG-XXX)|4.9.2 Analysis of Stack Traces (OTG-ERR-002)]] formerly "Analysis of Stack Traces"

[[Cryptography|'''4.10 Cryptography''']]

[[Testing for Insecure encryption usage (OWASP-EN-001)| 4.10.1 Testing for Insecure encryption usage (OTG-CRYPST-001)]] formerly "Testing for Insecure encryption usage (OWASP-EN-001)"

[[Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)| 4.10.2 Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-002)]] formerly "Testing for Weak SSL/TSL Ciphers, Insufficient Transport Layer Protection (OWASP-EN-002)" [Simone Onofri]

[[Testing for Padding Oracle (OWASP-EN-003)| 4.10.3 Testing for Padding Oracle (OTG-CRYPST-003)]] formerly "Testing for Padding Oracle (OWASP-EN-003)"

[[Testing for Cacheable HTTPS Response (OTG-CRYPST-004)| 4.10.4 Testing for Cacheable HTTPS Response (OTG-CRYPST-004)]]

[[Test Cache Directives (OTG-CRYPST-005)|4.10.5 Test Cache Directives (OTG-CRYPST-005)]]

[[Testing for Insecure Cryptographic Storage (OTG-CRYPST-006)|4.10.6 Testing for Insecure Cryptographic Storage (OTG-CRYPST-006)]]

[[Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)|4.10.7 Testing for Sensitive information sent via unencrypted channels (OTG-CRYPST-007)]] [Simone Onofri]

[[Test Cryptographic Key Management (OTG-CRYPST-008)|4.10.8 Test Cryptographic Key Management (OTG-CRYPST-008)]]

[[Logging|'''4.11 Logging''']] Not convinced Logging should be included as it requires access to logs to test

[[Test time synchronisation (OTG-LOG-001)|4.11.1 Test time synchronisation (OTG-LOG-001) ]] formerly "Incorrect time"

[[Test user-viewable log of authentication events (OTG-LOG-002)|4.11.2 Test user-viewable log of authentication events (OTG-LOG-002)]]

[[Testing for business logic (OWASP-BL-001)|'''4.12 Business Logic Testing (OWASP-BL-001)''']] [To review--> David Fern]
Business Logic<br>

[[Test business logic data validation (OTG-BUSLOGIC-001)|4.12.1 Test Business Logic Data Validation (OTG-BUSLOGIC-001)]]

[[Test Ability to forge requests (OTG-BUSLOGIC-002)|4.12.2 Test Ability to Forge Requests (OTG-BUSLOGIC-002)]]

[[Test integrity checks (OTG-BUSLOGIC-003)|4.12.3 Test Integrity Checks (OTG-BUSLOGIC-003)]]

[[Test for Process Timing (OTG-BUSLOGIC-007)|4.12.4 Test for Process Timing (OTG-BUSLOGIC-004)]]

[[Test number of times a function can be used limits (OTG-BUSLOGIC-007)|4.12.5 Test Number of Times a Function Can be Used Limits (OTG-BUSLOGIC-005)]]

[[Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-009)|4.12.6 Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-006)]]

[[Test defenses against application mis-use (OTG-BUSLOGIC-011)|4.12.7 Test Defenses Against Application Mis-use (OTG-BUSLOGIC-007)]]

[[Test Upload of Unexpected File Types (OTG-BUSLOGIC-015)|4.12.8 Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)]]

[[Test Upload of Malicious Files (OTG-BUSLOGIC-016)|4.12.9 Test Upload of Malicious Files (OTG-BUSLOGIC-009)]]

[[Client Side Testing|'''4.15 Client Side Testing''']] [New!]

[[Testing for DOM-based Cross site scripting (OWASP-DV-003)|4.15.1 Testing for DOM based Cross Site Scripting (OTG-CLIENT-001)]] formerly "Testing for DOM based Cross Site Scripting (OWASP-CS-001)" [Stefano Di Paola]

[[Testing for JavaScript Execution|4.15.2 Testing for JavaScript Execution (OWASP-CS-002)]] (Stefano Di Paola, Matteo Meucci)

[[Testing for HTML Injection|4.15.3 Testing for HTML Injection (OWASP-CS-003)]] (Stefano Di Paola, Matteo Meucci)

[[Testing for Client Side URL Redirect|4.15.4 Testing for Client Side URL Redirect (OWASP-CS-004)]] (Mauro Gentile, Davide Danelon)

[[Testing_for_CSS_Injection|4.15.5 Testing for CSS Injection (OWASP-CS-005)]] (Mauro Gentile, Davide Danelon)

[[Testing_for_Client_Side_Resource_Manipulation|4.15.6 Testing for Client Side Resource Manipulation (OWASP-CS-006)]] (Mauro Gentile, Davide Danelon)

[[Test Cross Origin Resource Sharing (OTG-CLIENT-002)|4.15.7 Test Cross Origin Resource Sharing (OTG-CLIENT-007)]] formerly "Testing for HTML5 (OWASP CS-002)" [Juan Galiana]

[[Testing for Cross site flashing (OWASP-DV-004)|4.15.8 Testing for Cross Site Flashing (OTG-CLIENT-008)]] formerly "Testing for Cross Site Flashing (OWASP-CS-003)"

[[Testing for Clickjacking (OWASP-CS-004)|4.15.9 Testing for Clickjacking (OTG-CLIENT-009)]] formerly "Testing for Clickjacking (OWASP-CS-004)" [Davide Danelon]

[[Testing WebSockets (OTG-CLIENT-005)|4.15.10 Testing WebSockets (OTG-CLIENT-010)]] [Ryan Dewhurst]

[[Test Web Messaging (OTG-CLIENT-006)|4.15.11 Test Web Messaging (OTG-CLIENT-011)]] [Juan Galiana]

[[Test Local Storage (OTG-CLIENT-007)|4.15.12 Test Local Storage (OTG-CLIENT-012)]] [Juan Galiana]

==[[Writing Reports: value the real risk |5. Writing Reports: value the real risk ]]==

[[How to value the real risk |5.1 How to value the real risk]] [To review--> Amro AlOlaqi] '''Ready to be reviewed'''

[[How to write the report of the testing |5.2 How to write the report of the testing]] [To review--> Amro AlOlaqi] '''Ready to be reviewed'''

==[[Appendix A: Testing Tools |Appendix A: Testing Tools ]]==

* Black Box Testing Tools [To review--> Amro AlOlaqi] '''Ready to be reviewed'''

==[[OWASP Testing Guide Appendix B: Suggested Reading | Appendix B: Suggested Reading]]==
* Whitepapers [To review--> David Fern]
* Books [To review--> David Fern]
* Useful Websites [To review--> David Fern]

==[[OWASP Testing Guide Appendix C: Fuzz Vectors | Appendix C: Fuzz Vectors]]==

* Fuzz Categories [To review--> Amro AlOlaqi] '''Ready to be reviewed'''

==[[OWASP Testing Guide Appendix D: Encoded Injection | Appendix D: Encoded Injection]]==
[To review--> Amro AlOlaqi] '''Ready to be reviewed'''

----

ARTICLES DELETED:

INFO GATHERING:

BUSINESS LOGIC:

XXXX[[Testing for Forged Requests Using Predictive Parameters (OTG-BUSLOGIC-003)|4.12.3 Testing for Forged Requests Using Predictive Parameters (OTG-BUSLOGIC-003)]] [New!]- [Combine with Test Ability to forge requests as an example]

[[Test integrity checks (OTG-BUSLOGIC-003)|4.12.3 Test Integrity Checks (OTG-BUSLOGIC-003)]] (e.g. overwriting updates)

DENIAL OF SERVICE

[[Denial of Service|'''4.13 Denial of Service''']]

[[Test Regular expression DoS (OTG-DOS-001)| 4.13.1 Test Regular expression DoS (OTG-DOS-001)]] [New!] note: to understand better<br>

[[Test XML DoS (OTG-DOS-002)| 4.13.2 Test XML DoS (OTG-DOS-002)]] [New! - Andrew Muller]

[[Testing for Captcha (OWASP-AT-012)|4.13.3 Testing for CAPTCHA (OTG-DOS-003)]] formerly "Testing for CAPTCHA (OWASP-AT-012)"

[[Test excessive rate (speed) of use limits (OTG-BUSLOGIC-005)|4.13.4 Test excessive rate (speed) of use limits (OTG-DOS-004)]] [New!]- [Moved from Business Logic, formerly OTG-BUSLOGIC-006]

[[Test size of request limits (OTG-BUSLOGIC-006)|4.13.5 Test size of request limits (OTG-DOS-005)]] [New!] - [Moved from Business Logic, formerly OTG-BUSLOGIC-008]

WEB SERVICES TESTING

[[Web Service (XML Interpreter)|'''4.14 Web Service Testing''']] [Tom Eston]

[[Scoping a Web Service Test (OWASP-WS-001)|4.14.1 Scoping a Web Service Test (OTG-WEBSVC-001)]] formerly "Scoping a Web Service Test (OWASP-WS-001)"

[[WS Information Gathering (OWASP-WS-002)|4.14.2 WS Information Gathering (OTG-WEBSVC-002)]] formerly "WS Information Gathering (OWASP-WS-002)"

[[WS Authentication Testing (OWASP-WS-003)|4.14.3 WS Authentication Testing (OTG-WEBSVC-003)]] formerly "WS Authentication Testing (OWASP-WS-003)"

[[WS Management Interface Testing (OWASP-WS-004)|4.14.4 WS Management Interface Testing (OTG-WEBSVC-004)]] formerly "WS Management Interface Testing (OWASP-WS-004)"

[[Weak XML Structure Testing (OWASP-WS-005)|4.14.5 Weak XML Structure Testing (OTG-WEBSVC-005)]] formerly "Weak XML Structure Testing (OWASP-WS-005)"

[[XML Content-Level Testing (OWASP-WS-006)|4.14.6 XML Content-Level Testing (OTG-WEBSVC-006)]] formerly "XML Content-Level Testing (OWASP-WS-006)"

[[WS HTTP GET Parameters/REST Testing (OWASP-WS-007)|4.14.7 WS HTTP GET Parameters/REST Testing (OTG-WEBSVC-007)]] formerly "WS HTTP GET Parameters/REST Testing (OWASP-WS-007)"

[[WS Naughty SOAP Attachment Testing (OWASP-WS-008)|4.14.8 WS Naughty SOAP Attachment Testing (OTG-WEBSVC-008)]] formerly "WS Naughty SOAP Attachment Testing (OWASP-WS-008)"

[[WS Replay/MiTM Testing (OWASP-WS-009)|4.14.9 WS Replay/MiTM Testing (OTG-WEBSVC-009)]] formerly "WS Replay/MiTM Testing (OWASP-WS-009)"

[[WS BEPL Testing (OWASP-WS-010)|4.14.10 WS BEPL Testing (OTG-WEBSVC-010)]] formerly "WS BEPL Testing (OWASP-WS-010)"

[[Category:OWASP Testing Project]]

Test business logic data validation (OTG-BUSLOGIC-001)

2013-12-22T16:05:31Z

David Fern:

== Brief Description ==

The application must ensure that only logically valid data can be entered at the front end as well as directly to the server side of an application of system. Only verifying data locally may leave applications vulnerable to server injections through proxies or at handoffs with other systems. This is different from simply performing Boundary Value Analysis (BVA) in that it is more difficult and in most cases cannot be simply verified at the entry point, but usually requires checking some other system.

For example: An application may ask for your Social Security Number. In BVA the application should check formats and semantics (is the value 9 digits long, not negative and not all 0's) for the data entered, but there are logic considerations also. SSNs are grouped and categorized.

Is this person on a death file?

Are they from a certain part of the country?

Vulnerabilities related to business data validation is unique in that they are application specific and different from the vulnerabilities related to forging requests in that they are more concerned about logical data as opposed to simply breaking the business logic workflow.

== Issue ==

The front end and the backend of the application should be verifying and validating that the data it has, is using and is passing along is logically valid. Even if the user provides valid data to an application the business logic may make the application behave differently depending on data or circumstances.

== Examples ==

Example 1

Suppose you manage a multi-tiered e-commerce site that allows users to order carpet. The user selects their carpet, enters the size, makes the payment, and the front end application has verified that all entered information is correct and valid for contact information, size, make and color of the carpet. But, the business logic in the background has two paths, if the carpet is in stock it is directly shipped from your warehouse, but if it is out of stock in your warehouse a call is made to a partner’s system and if they have it in-stock they will ship the order from their warehouse and reimbursed by them.

What happens if an attacker is able to continue a valid in-stock transaction and send it as out-of-stock to your partner?

What happens if an attacker is able to get in the middle and send messages to the partner warehouse ordering carpet without payment?

Example 2

Many credit card systems are now downloading account balances nightly so the customers can check out more quickly for amounts under a certain value. The inverse is also true. If I pay my credit card off in the morning I may not be able to use the available credit in the evening. Another example may be if I use my credit card at multiple locations very quickly it may be possible to exceed my limit if the systems are basing decisions on last night’s data.

== Testing Method ==

Generic Test Method

• Review the project documentation and use exploratory testing looking for data entry points or hand off points between systems or software.

• Once found try to insert logically invalid data into the application/system.

Specific Testing Method:

• Perform front-end GUI Functional Valid testing on the application to ensure that the only "valid" values are accepted.

• Using an intercepting proxy observe the HTTP POST/GET looking for places that variables such as cost and quality are passed. Specifically, look for "hand-offs" between application/systems that may be possible injection of tamper points.

• Once variables are found start interrogating the field with logically "invalid" data, such as social security numbers or unique identifiers that do not exist or that do not fit the business logic. This testing verifies that the server functions properly and does not accept logically invalid data them.

== Test Tools ==

''OWASP Zed Attack Proxy (ZAP)'' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

== Related Test Cases ==

4.8 Data Validation Testing

4.4.4 Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)

4.7.1 Testing for Bypassing Session Management Schema (OTG-SESS-001)

4.7.4 Testing for Exposed Session Variables (OTG-SESS-004)

== References ==

Beginning Microsoft Visual Studio LightSwitch Development - http://books.google.com/books?id=x76L_kaTgdEC&pg=PA280&lpg=PA280&dq=business+logic+example+valid+data+example&source=bl&ots=GOfQ-7f4Hu&sig=4jOejZVligZOrvjBFRAT4-jy8DI&hl=en&sa=X&ei=mydYUt6qEOX54APu7IDgCQ&ved=0CFIQ6AEwBDgK#v=onepage&q=business%20logic%20example%20valid%20data%20example&f=false

== Remediation ==

The application/system must ensure that only "logically valid" data is accepted at all input and handoff points of the application or system and data is not simply trusted once it has entered the system.

Test business logic data validation (OTG-BUSLOGIC-001)

2013-12-22T16:05:08Z

David Fern:

Test integrity checks (OTG-BUSLOGIC-003)

2013-12-22T16:03:03Z

David Fern:

== Brief Description ==

Many applications are designed to display different fields depending on the user of situation by leaving some inputs hidden. However, in many cases it is possible to submit values hidden field values to the server using a proxy. In these cases the server side controls must be smart enough to perform relational or server side edits to ensure that the proper data is allowed to the server based on user and application specific business logic.

Additionally, the application must not depend on non-editable controls, drop-down menus or hidden fields for business logic processing because these fields remain non-editable only in the context of the browsers. Users may be able to edit their values using proxy editor tools and try to manipulate business logic. If the application exposes values related to business rules like quantity, etc. as non-editable fields it must maintain a copy on the server side and use the same for business logic processing.

Finally, aside application/system data, log systems must be secured to prevent read, writing and updating.

Business logic integrity check vulnerabilities is unique in that these misuse cases are application specific and if users are able to make changes one should only be able to write or update/edit specific artifacts at specific times per the business process logic.

== Issue ==

The application must be smart enough to check for relational edits and not allow users to submit information directly to the server that is not valid, trusted because it came from a non-editable controls or the user is not authorized to submit through the front end. Additionally, system artifacts such as logs must be “protected” from unauthorized read, writing and removal.

== Example ==

Example 1

Imagine an ASP.NET application GUI application that only allows the admin user to change the password for other users in the system. The admin user will see the username and password fields to enter a username and password while other users will not see either field. However, if a non admin user submits information in the username and password field through a proxy they may be able to “trick” the server into believing that the request has come from an admin user and change password of other users.

Example 2

Most web applications have dropdown lists making it easy for the user to quickly select their state, month of birth, etc. Suppose a Project Management application allowed users to login and depending on their privileges presented them with a drop down list of projects they have access to. What happens if an attacker finds the name of another project that they should not have access to and submits the information via a proxy. Will the application give access to the project? They should not have access even though they skipped an authorization business logic check.

Example 3

Suppose the motor vehicle administration system required an employee initially verify each citizens documentation and information when they issue an identification or driver's license. At this point the business process has created data with a high level of integrity as the integrity of submitted data is checked by the application. Now suppose the application is moved to the Internet so employees can log on for full service or citizens can log on for a reduced self-service application to update certain information. At this point an attacker may be able to use an intercepting proxy to add or update data that they should not have access to and they could destroy the integrity of the data by stating that the citizen was not married but supplying data for a spouse’s name. This type of inserting or updating of unverified data destroys the data integrity and might have been prevented if the business process logic was followed.

Example 4

Many systems include logging for auditing and troubleshooting purposes. But, how good/valid is the information in these logs? Can they be manipulated by attackers either intentionally or accidentially having their integrity destroyed?

== Testing Method ==

Generic Testing Method

• Review the project documentation and use exploratory testing looking for parts of the application/system (components i.e. For example, input fields, databases or logs) that move, store or handle data/information.

• For each identified component determine what type of data/information is logically acceptable and what types the application/system should guard against. Also, consider who according to the business logic is allowed to insert, update and delete data/information and in each component.

• Attempt to insert, update or edit delete the data/information values with invalid data/information into each component (i.e. input, database, or log) by users that .should not be allowed per the busines logic workflow.

Specific Testing Method 1

• Using a proxy capture and HTTP traffic looking for hidden fields.

• If a hidden field is found see how these fields compare with the GUI application and start interrogating this value through the proxy by submitting different data values trying to circumvent the business process and manipulate values you were not intended to have access to.

Specific Testing Method 2

• Using a proxy capture and HTTP traffic looking a place to insert information into areas of the application that are non-editable.

• If it is found see how these fields compare with the GUI application and start interrogating this value through the proxy by submitting different data values trying to circumvent the business process and manipulate values you were not intended to have access to.

Specific Testing Method 3

• List components of the application or system that could be edited, for example logs or databases.

• For each component identified, try to read, edit or remove its information. For example log files should be identified and Testers should try to manipulate the data/information being collected.

== Test Tools ==

• Various system/application tools such as editors and file manipulation tools.

• ''OWASP Zed Attack Proxy (ZAP)'' - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

ZAP is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

== Related Test Cases ==

4.8 Data Validation Testing

4.11.1 Test time synchronization (OTG-LOG-001) formerly "Incorrect time"

4.11.2 Test user-viewable log of authentication events (OTG-LOG-002)

== References ==

Implementing Referential Integrity and Shared Business Logic in a RDB - http://www.agiledata.org/essays/referentialIntegrity.html

On Rules and Integrity Constraints in Database Systems - http://www.comp.nus.edu.sg/~lingtw/papers/IST92.teopk.pdf

Use referential integrity to enforce basic business rules in Oracle - http://www.techrepublic.com/article/use-referential-integrity-to-enforce-basic-business-rules-in-oracle/

Maximizing Business Logic Reuse with Reactive Logic - http://architects.dzone.com/articles/maximizing-business-logic

Tamper Evidence Logging - http://tamperevident.cs.rice.edu/Logging.html

== Remediation ==

The application must be smart enough to check for relational edits and not allow users to submit information directly to the server that is not valid, trusted because it came from a non-editable controls or the user is not authorized to submit through the front end. Additionally, any component that can be edited must have mechanisms in place to prevent unintentional/intentional writing or updating.

Test for Process Timing (OTG-BUSLOGIC-004)

2013-12-22T15:53:17Z

David Fern:

== Brief Description ==

It is possible that attackers can gather information on an application by monitoring the time it takes to complete a task or give a respond. Additionally, attackers may be able to manipulate and break designed business process flows by simply keeping active sessions open and not submitting their transactions in the "expected" time frame.

Process timing logic vulnerabilities is unique in that these manual misuse cases should be created considering execution and transaction timing that are application/system specific.

== Issue ==

Processing timing may give/leak information on what is being done in the application/system background processes. If an application allows users to guess what the particulate next outcome will be by processing time variations, users will be able to adjust accordingly and change behavior based on the expectation and "game the system".

== Example ==

Example 1

Video gambling/slot machines may take longer to process a transaction just prior to a large payout. This would allow astute gamblers to gamble minimum amounts until they see the long process time which would then prompt them to bet the maximum.

Example 2

Many system log on processes ask for the user name and password. If you look closely you may be able to see that entering an invalid user name and invalid user password takes more time to return an error than entering a valid username and invalid user password. This may allow the attacker to know if they have a valid username and not need to rely on the GUI message.

Example 3

Most Arenas or travel agencies have ticketing applications that allow users to purchase tickets and reserve seats. When the user requests the tickets seats are locked or reserved pending payment. What if an attacker keeps reserving seats but not checking out? Will the seats be released, or will no tickets be sold? Some ticket vendors now only allow users 5 minutes to complete a transaction or the transaction is invalidated.

Example 4

Suppose a precious metals e-commerce site allows users to make purchases with a price quote based on market price at the time they log on. What if an attacker logs on and places an order but does not complete the transaction until later in the day only of the price of the metals goes up? Will the attacker get the initial lower price?

== Testing Method ==

• Review the project documentation and use exploratory testing looking for application/system functionality that may be impacted by time. Such as execution time or actions that help users predict a future outcome or allow one to circumvent any part of the business logic or workflow. For example, not completing transactions in an expected time.

• Develop and execute the mis-use cases ensuring that attackers can not gain an advantage based on any timing.

== Test Tools ==

None

== Related Test Cases ==

4.7.2 Testing for Cookies attributes (OTG-SESS-002)

4.7.8 Test Session Timeout (OTG-SESS-008)

4.11.1 Test time synchronization (OTG-LOG-001)

4.13.4 Test excessive rate (speed) of use limits (OTG-DOS-004)

== References ==

None

== Remediation ==

Develop applications with processing time in mind. If attackers could possibly gain some type of advantage from knowing the different processing times and results add extra steps or processing so that no matter the results they are provided in the same time frame.

Additionally, the application/system must have mechanism in place to not allow attackers to extend transactions over an "acceptable" amount of time. This may be done by cancelling or resetting transactions after a specified amount of time has passed like some ticket vendors are now using.

Test number of times a function can be used limits (OTG-BUSLOGIC-005)

2013-12-22T15:41:23Z

David Fern:

== Brief Description ==

Many of the problems that applications are solving require limits to the number of times a function can be used or action can be executed. Applications must be “smart enough” to not allow the user to exceed their limit on the use of these functions since in many cases each time the function is used the user may gain some type of benefit that must be accounted for to properly compensate the owner. For example: an eCommerce site may only allow a users apply a discount once per transaction, or some applications may be on a subscription plan and only allow users to download three complete documents monthly.

Vulnerabilities related to testing for the function limits are application specific and misuse cases must be created that strive to exercise parts of the application/functions/ or actions more than the allowable number of times.

== Issue ==

Attackers may be able to circumvent the business logic and execute a function more times than “allowable” exploiting the application for personal gain.

== Example ==

Suppose an eCommerce site allows users to take advantage of any one of many discounts on their total purchase and then proceed to checkout and tendering. What happens of the attacker navigates back to the discounts page after taking and applying the one “allowable” discount? Can they take advantage of another discount? Can they take advantage of the same discount multiple times?

== Testing Method ==

• Review the project documentation and use exploratory testing looking for functions or features in the application or system that should not be executed more that a single time or specified number of times during the business logic workflow.

• For each of the functions and features found that should only be executed a single time or specified number of times during the business logic workflow, develop abuse/misuse cases that may allow a user to execute more than the allowable number of times. For example, can a user navigate back and forth through the pages multiple times executing a function that should only execute once? or can a user load and unload shopping carts allowing for additional discounts.

== Test Tools ==

None

== Related Test Cases ==

4.4.4 Testing for Account Enumeration and Guessable User Account (OTG-IDENT-004)

4.4.7 Test Account Suspension/Resumption Process (OTG-IDENT-007)

4.5.3 Testing for Weak lock out mechanism (OTG-AUTHN-003)

4.13.4 Test excessive rate (speed) of use limits (OTG-DOS-004)

4.13.5 Test size of request limits (OTG-DOS-005)

== References ==

InfoPath Forms Services business logic exceeded the maximum limit of operations Rule - http://mpwiki.viacode.com/default.aspx?g=posts&t=115678

Gold Trading Was Temporarily Halted On The CME This Morning -
http://www.businessinsider.com/gold-halted-on-cme-for-stop-logic-event-2013-10

== Remediation ==

The application should have checks to ensure that the business logic is being followed and that if a function/action can only be executed a certain number of times, when the limit is reached the user can no longer execute the function. To prevent users from using a function over the appropriate number of times the application may use mechanisms such as cookies to keep count or through sessions not allowing users to access to execute the function additional times.

Testing for the Circumvention of Work Flows (OTG-BUSLOGIC-006)

2013-12-22T15:24:51Z

David Fern:

== Brief Description ==

Workflow vulnerabilities involve any type of vulnerability that allows the attacker to misuse an application/system in a way that will allow them to circumvent (not follow) the designed/intended workflow.

“A workflow consists of a sequence of connected steps where each step follows without delay or gap and ends just before the subsequent step may begin. It is a depiction of a sequence of operations, declared as work of a person or group, an organization of staff, or one or more simple or complex mechanisms. Workflow may be seen as any abstraction of real work.” (https://en.wikipedia.org/wiki/Workflow)

The application’s business logic must require that the user complete specific steps in the correct/specific order and if the workflow is terminated without correctly completing, all actions and spawned actions are “rolled back” or canceled.

Vulnerabilities related to the circumvention of workflows or bypassing the correct business logic workflow are unique in that they are very application/system specific and careful manual misuse cases must be developed using requirements and use cases.

== Issue ==

The applications business process must have checks to ensure that the user's transactions/actions are proceeding in the correct/acceptable order and if a transaction triggers some sort of action, that action will be “rolled back” and removed if the transaction is not successfully completed.

== Examples ==

Example 1

Many of us receive so type of “club/loyalty points” for purchases from grocery stores and gas stations. Suppose a user was able to start a transaction linked to their account and then after points have been added to their club/loyalty account cancel out of the transaction or remove items from their “basket” and tender. In this case the system either should not apply points/credits to the account until it is tendered or points/credits should be “rolled back” if the point/credit increment does not match the final tender. With this in mind, an attacker may start transactions and cancel them to build their point levels without actually buy anything.

Example 2

An electronic bulletin board system may be designed to ensure that initial posts do not contain profanity based on a list that the post is compared against. If a word on a "black" the list is found in the user entered text the submission is not posted. But, once a submission is posted the submitter can access, edit, and change the submission contents to include words included on the profanity/black list since on edit the posting is never compared again. Keeping this in mind, attackers may open an initial blank or minimal discussion then add in whatever they like as an update.

== Testing Methods ==

Generic Testing Method

• Review the project documentation and use exploratory testing looking for methods to skip or go to steps in the application process in a different order from the designed/intended business logic flow.

• For each method develop a misuse case and try to circumvent or perform an action that is "not acceptable" per the the business logic workflow.

Testing Method 1

• Start a transaction going through the application past the points that triggers credits/points to the users account.

• Cancel out of the transaction or reduce the final tender so that the point values should be decreased and check the points/ credit system to ensure that the proper points/credits were recorded.

Testing Method 2

• On a content management or bulletin board system enter and save valid initial text or values.

• Then try to append, edit and remove data that would leave the existing data in an invalid state or with invalid values to ensure that the user is not allowed to save the incorrect information. Some "invalid" data or information may be specific words (profanity) or specific topics (such as political issues).

== Test Tools ==

None

== Related Test Cases ==

4.6.2 Testing Directory traversal/file include (OTG-AUTHZ-002)

4.6.3 Testing for bypassing authorization schema (OTG-AUTHZ-003)

4.7.1 Testing for Bypassing Session Management Schema (OTG-SESS-001)

4.12.1 Test business logic data validation (OTG-BUSLOGIC-001)

4.12.2 Test Ability to forge requests (OTG-BUSLOGIC-002)

4.12.3 Test Integrity Checks (OTG-BUSLOGIC-003)

4.12.4 Test for Process Timing (OTG-BUSLOGIC-004)

4.12.5 Test Number of Times a Function Can be Used Limits (OTG-BUSLOGIC-005)

4.12.7 Test Defenses Against Application Mis-use (OTG-BUSLOGIC-007)

4.12.8 Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)

4.12.9 Test Upload of Malicious Files (OTG-BUSLOGIC-009)

== References ==

OWASP Detail Misuse Cases - https://www.owasp.org/index.php/Detail_misuse_cases

Real-Life Example of a 'Business Logic Defect - http://h30501.www3.hp.com/t5/Following-the-White-Rabbit-A/Real-Life-Example-of-a-Business-Logic-Defect-Screen-Shots/ba-p/22581

Top 10 Business Logic Attack Vectors Attacking and Exploiting Business Application
Assets and Flaws – Vulnerability Detection to Fix - http://www.ntobjectives.com/go/business-logic-attack-vectors-white-paper/ and http://www.ntobjectives.com/files/Business_Logic_White_Paper.pdf

CWE-840: Business Logic Errors - http://cwe.mitre.org/data/definitions/840.html

== Remediation ==

The application must be self-aware and have checks in place ensuring that the users complete each step in the work flow process in the correct order and prevent attackers from circumventing/skipping/or repeating any steps/processes in the workflow. Test for workflow vulnerabilities involves developing business logic abuse/misuse cases with the goal of successfully completing the business process while not completing the correct steps in the correct order.

Test Upload of Unexpected File Types (OTG-BUSLOGIC-008)

2013-12-22T15:14:29Z

David Fern:

== Brief Description ==

Many application’s business processes allow for the upload and manipulation of data that is submitted via files. But the business process must check the files and only allow certain “approved” file types. Deciding what files are "approved" is determined by the business logic and is application/system specific. The risk in that by allowing users to upload files, attackers may submit an unexpected file type that that could be executed and adversely impact the application or system through attacks that may deface the web site, perform remote commands, browse the system files, browse the local resources, attack other servers, or exploit the local vulnerabilities, just to name a few.

Vulnerabilities related to the upload of unexpected file types is unique in that the upload should quickly reject a file if it does not have a specific extension. Additionally, this is different from uploading malicious files in that in most cases an incorrect file format may not by it self be inherently “malicious” but may be detrimental to the saved data. For example if an application accepts Windows Excel files, if an similar database file is uploaded it may be read but data extracted my be moved to incorrect locations.

== Issue ==

The application may be expecting only certain file types to be uploaded for processing, such as .CSV, .txt files. The application may not validate the uploaded file by extension (for low assurance file validation) or content (high assurance file validation). This may result in unexpected system or database results within the application/system or give attackers additional methods to exploit the application/system..

== Example ==

Suppose a picture sharing application allows users to upload a .gif or .jpg graphic file to the web site. What if an attacker is able to upload an html file with a <script> tag in it or php file? The system may move the file from a temporary location to the final location where the php code can now be executed against the application or system.

== Testing Method ==

Generic Testing Method

• Review the project documentation and perform some exploratory testing looking for file types that should be "unsupported" by the application/system.

• Try to upload these “unsupported” files an verify that it are properly rejected.

• If multiple files can be uploaded at once, there must be tests in place to verify that each file is properly evaluated.

Specific Testing Method

• Study the applications logical requirements.

• Prepare a library of files that are “not approved” for upload that may contain files such as: jsp, exe, or html files containing script.

• In the application navigate to the file submission or upload mechanism.

• Submit the “not approved” file for upload and verify that they are properly prevented from uploading

== Test Tools ==

None

== Related Test Cases ==

4.3.3 Test File Extensions Handling for Sensitive Information (OTG-CONFIG-003)

4.12.9 Test Upload of Malicious Files (OTG-BUSLOGIC-009)

== References ==

OWASP - Unrestricted File Upload - https://www.owasp.org/index.php/Unrestricted_File_Upload

File upload security best practices: Block a malicious file upload - http://www.computerweekly.com/answer/File-upload-security-best-practices-Block-a-malicious-file-upload

Stop people uploading malicious PHP files via forms - http://stackoverflow.com/questions/602539/stop-people-uploading-malicious-php-files-via-forms

CWE-434: Unrestricted Upload of File with Dangerous Type - http://cwe.mitre.org/data/definitions/434.html

Secure Programming Tips - Handling File Uploads - https://www.datasprings.com/resources/dnn-tutorials/artmid/535/articleid/65/secure-programming-tips-handling-file-uploads?AspxAutoDetectCookieSupport=1

== Remediation ==

Applications should be developed with mechanisms to only accept and manipulate “acceptable“ files that the rest of the application functionality is ready to handle and expecting. Some specific examples include: Black or White listing of file extensions, using “Content-Type” from the header, or using a file type recognizer, all to only allow specified file types into the system.