Reporting - Revision history

Nvhaver: /Reporting/

2014-12-01T19:04:01Z

‎Reporting

Andrew Muller at 08:06, 8 August 2014

2014-08-08T08:06:08Z

Andrew Muller: replace the table images with inline table

2014-08-08T08:04:50Z

replace the table images with inline table

Show changes

Andrew Muller: Andrew Muller moved page How to write the report of the testing to Reporting: made this the only report writing chapter and removed reference to risk ratings as other folks already do risk better than us. OWASP should focus on calculating vulne...

2014-08-08T07:11:10Z

Andrew Muller moved page How to write the report of the testing to Reporting: made this the only report writing chapter and removed reference to risk ratings as other folks already do risk better than us. OWASP should focus on calculating vulne...

Amro Ahmed at 11:45, 29 May 2014

2014-05-29T11:45:49Z

Jane O'Connor: Final edit

2014-05-13T08:00:06Z

Final edit

Amro Ahmed at 00:16, 19 October 2013

2013-10-19T00:16:44Z

Amro Ahmed at 17:59, 21 February 2013

2013-02-21T17:59:53Z

Amro Ahmed at 17:58, 21 February 2013

2013-02-21T17:58:53Z

Amro Ahmed at 17:53, 21 February 2013

2013-02-21T17:53:39Z

@@ Line 22: / Line 22: @@
 This section outlines the agreed scope.
-.3 Project Schedule
+.3 Project Schedule:
 This section outlines when the testing commenced and when it was completed.
@@ Line 31: / Line 31: @@
 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.
-.6 Findings Summary
+.6 Findings Summary:
 This section outlines the vulnerabilities that were discovered during testing.
-.7 Remediation Summary
+.7 Remediation Summary:
 This section outlines the action plan for fixing the vulnerabilities that were discovered during testing.

@@ Line 305: / Line 305: @@
+|
 |}
 '''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.

← Older revision		Revision as of 11:45, 29 May 2014
Line 20:		Line 20:

	1.2 Project Scope:		1.2 Project Scope:
−	This section outlines ~~the~~ the agreed scope.	+	This section outlines the agreed scope.

@@ Line 1: / Line 1: @@
 {{Template:OWASP Testing Guide v4}}
-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.
+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 and be created in a manner that allows each section to be split off and printed and given to the appropriate teams, such as the developers or system managers.
+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.0 Executive Summary'''
+'''1. Executive Summary'''
-The executive summary sums up the overall findings of the assessment and gives managers, or system owners, an idea of the overall risk faced.
+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 that a summary be included, which details when the testing commenced and when it was completed.
+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, which is often overlooked, is a paragraph on implications and actions. This allows the system owners to understand what is required to be done in order to ensure the system remains secure.
+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  Project Objective:
-In this section you will need to outline the project objectives and what is expected as an outcome of the assessment.
+This section outlines the project objectives and the expected outcome of the assessment.
 .2 Project Scope:
-In this section you will need to outline the agreed scope.
+This section outlines the the agreed scope.
 .3 Limitations:
-This section is dedicated for every and each limitation which you faced throughout the assessment, for instance, limitations of project-focused tests, limitation in your security testing methods, performance or technical issues that you come across during the course of assessment etc ....
+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.
 .4 Targets:
-In this section you will need to list the number of applications and/or targeted systems.
+This section lists the number of applications or targeted systems.
-'''2.0 Technical Management Overview'''
+'''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.
-'''3.0 Assessment Findings'''
+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.
 The findings section should include:
@@ Line 47: / Line 51: @@
 * 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):
@@ Line 54: / Line 57: @@
 <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/code are utilized during the assessment, it should be disclosed in this section or noted as attachment.
+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.

@@ Line 21: / Line 21: @@
 .2 Project Scope:
-In this section you will need to outline the agreed scope  - in some cases the limitation of scope.
+In this section you will need to outline the agreed scope.
-.3 Targets:
+.3 Limitations:
 In this section you will need to list the number of applications and/or targeted systems.

← Older revision	Revision as of 07:11, 8 August 2014
(No difference)

← Older revision		Revision as of 17:59, 21 February 2013
Line 27:		Line 27:


−	'''2.0 Technical Management Overview''"	+	'''2.0 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.

@@ Line 2: / Line 2: @@
 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 highlight all the risks found during the assessment phase and appeal to both management and technical staff.
+A report should be easy to understand and highlight all the risks found during the assessment phase and appeal to both executive management and technical staff.
 The report needs to have three major sections and be created in a manner that allows each section to be split off and printed and given to the appropriate teams, such as the developers or system managers.
@@ Line 8: / Line 8: @@
 The sections generally recommended are:
-'''I. Executive Summary'''
+''''''1.0 Executive Summary''' '''
-The executive summary sums up the overall findings of the assessment and gives managers, or 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 that a summary be included, which details when the testing commenced and when it was completed.
+The executive summary sums up the overall findings of the assessment and gives managers, or system owners, an idea of the overall risk faced.
 Another section, which is often overlooked, is a paragraph on implications and actions. This allows the system owners to understand what is required to be done in order to ensure the system remains secure.
-'''II. 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 and then finally a technical summary of the findings.
-'''III Assessment Findings'''
+'''3.0 Assessment Findings'''
 The last section of the report is the section, which includes detailed technical detail about the vulnerabilities found, and the approaches needed to ensure they are resolved. This section is aimed at a technical level and should include all the necessary information for the technical teams to understand the issue and be able to solve it.
@@ Line 39: / Line 52: @@
 <center>[[Image:tablerep3.PNG]]</center>
-'''IV Toolbox'''
+'''Appendix'''
 This section is often used to describe the commercial and open-source tools that were used in conducting the assessment. When custom scripts/code are utilized during the assessment, it should be disclosed in this section or noted as attachment.
 It is often appreciated by the customer when the methodology used by the consultants is included. It gives them an idea of the thoroughness of the assessment and also an idea what areas were included.