This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Reporting"
Amro Ahmed (talk | contribs) |
(Final edit) |
||
Line 1: | Line 1: | ||
{{Template:OWASP Testing Guide v4}} | {{Template:OWASP Testing Guide v4}} | ||
− | Performing the technical side of the assessment is only half of the overall assessment process | + | 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 report should be easy to understand and highlight all the risks found during the assessment phase | ||
− | The report needs to have three major sections | + | 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. | + | '''1. Executive Summary''' |
− | The executive summary sums up the overall findings of the assessment and gives managers | + | 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 | + | 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 | + | 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: | 1.1 Project Objective: | ||
− | + | This section outlines the project objectives and the expected outcome of the assessment. | |
+ | |||
1.2 Project Scope: | 1.2 Project Scope: | ||
− | + | This section outlines the the agreed scope. | |
+ | |||
1.3 Limitations: | 1.3 Limitations: | ||
− | This section | + | 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: | 1.4 Targets: | ||
− | + | This section lists the number of applications or targeted systems. | |
− | '''2. | + | '''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. | 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. | ||
− | |||
− | '''3. | + | 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: | The findings section should include: | ||
Line 47: | Line 51: | ||
* The risk rating and impact value | * 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): | Here is the report (see https://www.owasp.org/index.php/Testing_Checklist for the complete list of tests): | ||
Line 54: | Line 57: | ||
<center>[[Image:tablerep2.PNG]]</center> | <center>[[Image:tablerep2.PNG]]</center> | ||
<center>[[Image:tablerep3.PNG]]</center> | <center>[[Image:tablerep3.PNG]]</center> | ||
+ | |||
'''Appendix''' | '''Appendix''' | ||
− | This section is often used to describe the commercial and open-source tools that were used in conducting the assessment. When custom scripts | + | 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 08:00, 13 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 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):
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.