Difference between revisions of "Reporting"

From OWASP
Jump to: navigation, search
(29 intermediate revisions by 7 users not shown)
Line 1: Line 1:
{{Template:OWASP Testing Guide v2}}
+
{{Template:OWASP Testing Guide v4}}
THIS SECTION IN PROGRESS AS OF 11/29/2006 - Tom Brennan
+
  
Writing the report is easy if you have been collecting the information during each stage of testing. If is important for the customer to always get a systematic assessment looking for classes of issues in unknown developer code.  
+
Performing the technical side of the assessment is only half of the overall assessment process. The final product is the production of a well written and informative report. A report should be easy to understand and should highlight all the risks found during the assessment phase. The report should appeal to both executive management and technical staff.  
  
A question I always ask is, is this project a baseline report or the 12th report of a single application/system in the current year? Either way the report needs to be consistent in the delivery to customers, management etc. The reason this is important is that the 1st rule of security is to use multiple vendors for testing security right, but unless you specify you threat model type (see 5.1 How to value the real risk ) each report will have its own interpretation of risk and threats. If it does happen to be the 5 report on the same system, I typically submit an example report, and then ask the customer to compare apples to apples. If he liked certain areas of the other firms report, I want to review how it will look on our report ahead of time. It’s all about meeting expectations. On the technical level, I am a fan of using the VISA/MasterCard PCI standard for host reporting.  
+
The report needs to have three major sections. It should be created in a manner that allows each separate section to be printed and given to the appropriate teams, such as the developers or system managers. The recommended sections are outlined below.
  
The following sections are typically standard
+
 +
'''1. Executive Summary'''
  
'''I. Executive Summary''' - It this report is for many systems then there should be a summary paragraph that outlines the total devices tested, the dates of the testing and a summary of the results. I think we all know that management likes visual graphics to illustrate problems so why not provide some to do that for all of the systems tested.
+
The executive summary sums up the overall findings of the assessment and gives managers and system owners an idea of the overall risk faced.  
II. Systems Summary – If more than 1 application or system is tested, we recommend that the systems summary defined the systems and the systems boundaries and a description of the systems purpose. Each “System” may contain many sub-systems etc., it is important to provide both Executive Summary about systems as well as within the systems summary. Appendix A, below would be ideal to illustrate per system the status of an Application Assessment and if you were to add a few items, you could include the host/network level as well.  
+
  
'''III System Detail''' – This is a details on each system test and details of the individual hosts or applications again Appendix A would serve this purpose as a summary on a individual system level and then detailed information and recommended corrective actions to the found issues.  
+
The language used should be more suited to people who are not technically aware and should include graphs or other charts which show the risk level. It is recommended to include a summary that details when the testing commenced and when it was completed.
  
Within the system detail I like to utilize the following sections:
+
Another section that is often overlooked is a paragraph on implications and actions. This allows the system owners to understand what is required to be done to ensure the system remains secure.
'''
+
Findings
+
Observations
+
Recommendations'''
+
  
Keeping in mind as an assessment person that you can find the biggest issues in the world, but it is the customer/employer etc... That has to accept the facts and elect to fix them. So the report is exactly that, as a subject matter expert you are providing the facts good or bad. Think in context of testifying in a court of law as to what you observed, what you found and what you recommended this document is your professional deliverable.
 
  
IIII Toolbox - This is the area that is used to describe to the customer the commercial and open-source tools that were used in conducting the assessment. When custom scripts/code is utilized during the assessment, it should be disclosed in this section. The customer paid for the assessment and should be provided with a list of the tools used to provide the service in addition to the digital knowledge of the tester.  Some may argue that the tools used by other professionals when providing a service are not disclosed so why should we do this as a standard practice?  I answer that question with this, the OWASP Testing Guide is FREE and OPEN-SOURCE to any who wish to follow what we believe are best practices not only in conducting testing but as a information security professional.
+
1.1  Project Objective:
 +
This section outlines the project objectives and the expected outcome of the assessment.
  
  
'''APPENDIX A'''
+
1.2 Project Scope:
 +
This section outlines the agreed scope.
  
{| border=1
 
|| '''Category''' || '''Ref Number''' || '''Name ''' || '''Finding ''' ||'''Affected Item'''|| '''Comment/Solution ''' || '''Risk Value '''
 
|-
 
|| Information Gathering ||  || Application Discovery ||  ||  ||  ||
 
|-
 
||  ||  || Spidering and googling ||  ||  ||  ||
 
|-
 
||  ||  || Analisys of error code ||  ||  ||  ||
 
|-
 
||  ||  || SSL/TLS Testing ||  ||  ||  ||
 
|-
 
||  ||  || DB Listener Testing ||  ||  ||  ||
 
|-
 
||  ||  || File extensions handling ||  ||  ||  ||
 
|-
 
||  ||  || Old, backup and unreferenced files ||  ||  ||  ||
 
|-
 
||Business logic testing  ||  ||  ||  ||  ||  ||
 
|-
 
|| Authentication Testing ||  || Default or guessable account ||  ||  ||  ||
 
|-
 
||  ||  || Brute Force ||  ||  ||  ||
 
|-
 
||  ||  || Bypassing authentication schema ||  ||  ||  ||
 
|-
 
||  ||  || Directory traversal/file include ||  ||  ||  ||
 
|-
 
||  ||  || Vulnerable remember password and pwd reset ||  ||  ||  ||
 
|-
 
||  ||  || Logout and Browser Cache Management Testing ||  ||  ||  ||
 
|-
 
|| Session Management Testing ||  || Session Management Schema  ||  ||  || ||
 
|-
 
||  ||  || Session Token Manipulation ||  ||  ||  ||
 
|-
 
||  ||  || Exposed Session Variables ||  ||  ||  ||
 
|-
 
||  ||  || Session Riding ||  ||  ||  ||
 
|-
 
||  ||  || HTTP Exploit ||  ||  ||  ||
 
|-
 
|| Data Validation Testing ||  || Cross site scripting ||  ||  ||  ||
 
|-
 
||  ||  || HTTP Methods and XST ||  ||  ||  ||
 
|-
 
||  ||  || SQL Injection ||  ||  ||  ||
 
|-
 
||  ||  || Stored procedure injection ||  ||  ||  ||
 
|-
 
||  ||  || ORM Injection ||  ||  ||  ||
 
|-
 
||  ||  || LDAP Injection ||  ||  ||  ||
 
|-
 
||  ||  || XML Injection ||  ||  ||  ||
 
|-
 
||  ||  || SSI Injection ||  ||  ||  ||
 
|-
 
||  ||  || XPath Injection ||  ||  ||  ||
 
|-
 
||  ||  || IMAP/SMTP Injection ||  ||  ||  ||
 
|-
 
||  ||  || Code Injection ||  ||  ||  ||
 
|-
 
||  ||  || OS Commanding ||  ||  ||  ||
 
|-
 
||  ||  || Buffer overflow ||  ||  ||  ||
 
|-
 
||  ||  || Incubated vulnerability ||  ||  ||  ||
 
|-
 
|| Denial of Service Testing ||  || Locking Customer Accounts ||  ||  ||  ||
 
|-
 
||  ||  || User Specified Object Allocation ||  ||  ||  ||
 
|-
 
||  ||  || User Input as a Loop Counter ||  ||  ||  ||
 
|-
 
||  ||  || Writing User Provided Data to Disk ||  ||  ||  ||
 
|-
 
||  ||  || Failure to Release Resources ||  ||  ||  ||
 
|-
 
||  ||  || Storing too Much Data in Session ||  ||  ||  ||
 
|-
 
|| Web Services Testing  ||  || XML Structural Testing ||  ||  ||  ||
 
|-
 
||  ||  || XML content-level Testing ||  ||  ||  ||
 
|-
 
||  ||  || HTTP GET parameters/REST Testing ||  ||  ||  ||
 
|-
 
||  ||  || Naughty SOAP attachments ||  ||  ||  ||
 
|-
 
||  ||  || Replay Testing  ||  ||  ||  ||
 
|-
 
|| AJAX Testing ||  || AJAX Vulnerabilities  ||  ||  ||  ||
 
|-
 
|}
 
  
 +
1.3 Limitations:
 +
This section outlines every limitation which was faced throughout the assessment. For example, limitations of project-focused tests, limitation in the security testing methods, performance or technical issues that the tester come across during the course of assessment, etc.
  
  
 +
1.4 Targets:
 +
This section lists the number of applications or targeted systems.
  
  
{{Category:OWASP Testing Project AoC}}
+
'''2. Technical Management Overview'''
 +
 
 +
The technical management overview section often appeals to technical managers who require more technical detail than found in the executive summary. This section should include details about the scope of the assessment, the targets included and any caveats, such as system availability etc.
 +
 
 +
This section also needs to include an introduction on the risk rating used throughout the report. It should also include a technical summary of the findings.
 +
 
 +
 
 +
'''3. Assessment Findings'''
 +
 
 +
The last section of the report includes detailed technical information about the vulnerabilities found and the actions needed to resolve them. This section is aimed at a technical level and should include all the necessary information for the technical teams to understand the issue and resolve it. Each finding should be clear and concise and give the reader of the report a full understanding of the issue at hand.
 +
 
 +
 
 +
The findings section should include:
 +
 
 +
* A reference number for easy reference with screenshots
 +
* The affected item
 +
* A technical description of the issue
 +
* A section on resolving the issue
 +
* The risk rating and impact value
 +
 
 +
 
 +
Here is the report (see https://www.owasp.org/index.php/Testing_Checklist for the complete list of tests):
 +
 
 +
<center>[[Image:tablerep.PNG]]</center>
 +
<center>[[Image:tablerep2.PNG]]</center>
 +
<center>[[Image:tablerep3.PNG]]</center>
 +
 
 +
 
 +
'''Appendix''' 
 +
 
 +
This section is often used to describe the commercial and open-source tools that were used in conducting the assessment. When custom scripts or code are utilized during the assessment, it should be disclosed in this section or noted as attachment. Customers appreciate when the methodology used by the consultants is included. It gives them an idea of the thoroughness of the assessment and what areas were included.

Revision as of 06:45, 29 May 2014

This article is part of the new OWASP Testing Guide v4.
Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: https://www.owasp.org/index.php/OWASP_Testing_Project


Performing the technical side of the assessment is only half of the overall assessment process. The final product is the production of a well written and informative report. A report should be easy to understand and should highlight all the risks found during the assessment phase. The report should appeal to both executive management and technical staff.

The report needs to have three major sections. It should be created in a manner that allows each separate section to be printed and given to the appropriate teams, such as the developers or system managers. The recommended sections are outlined below.


1. Executive Summary

The executive summary sums up the overall findings of the assessment and gives managers and system owners an idea of the overall risk faced.

The language used should be more suited to people who are not technically aware and should include graphs or other charts which show the risk level. It is recommended to include a summary that details when the testing commenced and when it was completed.

Another section that is often overlooked is a paragraph on implications and actions. This allows the system owners to understand what is required to be done to ensure the system remains secure.


1.1 Project Objective: This section outlines the project objectives and the expected outcome of the assessment.


1.2 Project Scope: This section outlines the agreed scope.


1.3 Limitations: This section outlines every limitation which was faced throughout the assessment. For example, limitations of project-focused tests, limitation in the security testing methods, performance or technical issues that the tester come across during the course of assessment, etc.


1.4 Targets: This section lists the number of applications or targeted systems.


2. Technical Management Overview

The technical management overview section often appeals to technical managers who require more technical detail than found in the executive summary. This section should include details about the scope of the assessment, the targets included and any caveats, such as system availability etc.

This section also needs to include an introduction on the risk rating used throughout the report. It should also include a technical summary of the findings.


3. Assessment Findings

The last section of the report includes detailed technical information about the vulnerabilities found and the actions needed to resolve them. This section is aimed at a technical level and should include all the necessary information for the technical teams to understand the issue and resolve it. Each finding should be clear and concise and give the reader of the report a full understanding of the issue at hand.


The findings section should include:

  • A reference number for easy reference with screenshots
  • The affected item
  • A technical description of the issue
  • A section on resolving the issue
  • The risk rating and impact value


Here is the report (see https://www.owasp.org/index.php/Testing_Checklist for the complete list of tests):

Tablerep.PNG
Tablerep2.PNG
Tablerep3.PNG


Appendix

This section is often used to describe the commercial and open-source tools that were used in conducting the assessment. When custom scripts or code are utilized during the assessment, it should be disclosed in this section or noted as attachment. Customers appreciate when the methodology used by the consultants is included. It gives them an idea of the thoroughness of the assessment and what areas were included.