As organizations evaluate penetration tests and other types of security consulting, one of the common questions we get at Secure Ideas is, “What is the deliverable?”. This is an important question since the deliverable is the formal record of the assessment activities and recommendations. So what should you expect, and why are the pieces important? Let’s look at each piece now:
Executive Summary
This section of the report describes the history, the purpose, and a summary of the engagement. It tends to be written for non-technical, executive-level personnel so that they can understand the parts and results of the penetration test without needing to fully understand the technical details. This section will also provide risk-based guidance on the priorities for addressing findings. Finally, the executive summary may list factors that are helping or harming the security posture of the organization.
Narrative
This section contains a narrative of the testing process. It serves two primary purposes based on the mix of goals most organizations have for their penetration testing:
First, it provides an explanation of what happened during the testing. It walks the reader through the procedures and thought process the tester followed. This helps as the organization determines how to reproduce the findings and remediate the various issues. In some cases, it may also describe how a combination of vulnerabilities were exploited to reach a critical objective.
Second, the narrative walks through various parts of the testing that did not result in findings. While this often seems counterintuitive, good documentation of what tests failed helps the organization understand what security controls are working properly within its security program. This can also help account for effort when a test has very few findings to report.
Findings and Recommendations
The findings and recommendations section is often the most significant portion of the testing deliverable to those accountable or responsible for remediation. As the section is titled, everything in it is split into two pieces: the finding and our recommendation.
The finding is the description of the problem uncovered in the application. They can be anything from SQL injection to a misconfiguration within the platform hosting the application. Each finding outlines these three items:
- Summary: The summary is a general explanation of what the finding means. For example, it would describe how Cross-Site Scripting (XSS) works and how that can be exploited. It may also explain the typical risks associated with this type of finding.
- Finding: The finding section will explain the specific details of this finding as they pertain to this test, such as wherein the application a vulnerability was discovered, or which hosts and ports were found to susceptible to a configuration flaw. This is where the reader will find steps to reproduce an issue or specific evidence demonstrating the issue. Some examples of information that may be included are URLs, payloads, port numbers, testing tools and techniques used, steps to reproduce, and screenshots.
- Recommendations: The recommendation section is meant to contain a solution or remediation for the finding. Sometimes this may include multiple options to solve the issue, or even multiple steps that must be implemented in concert. This recommendation is based on the experience Secure Ideas’ consultants have running and developing applications throughout their careers. (As outlined elsewhere, Secure Ideas senior consultants are hired from developers, system administrators, and other IT skill sets.) In general, Secure ideas attempts to provide recommendations that are actionable, and if multiple are included, the pros and cons of each will be covered.
Strategic Guidance
At first glance, this section may seem similar to the Findings and Recommendations section of the report. It outlines any recommendations that Secure Ideas believes the organization should consider as future improvements for its security posture, even though there may not be a specific finding or one that warrants a full finding. These are meant to assist organizations in were to consider future investments in IT Security. For example, we may recommend additional developer training due to the types of flaws found within the application. While the application developers' skills and knowledge aren't really in scope for a penetration test, we may infer from the findings that the organization would benefit by providing additional training.
Appendices
While not a part of every deliverable, sometimes within a penetration test, there is data collected that needs to be communicated to the client organization. This is where that would be placed. For example, if Secure Ideas found leaked credentials for an application, we would record the specific accounts discovered in an appendix so the client can communicate with those users. Another reason for an appendix is if a finding is discovered in so many areas of the application the list would impact the readability of the report. We would create an appendix listing those locations.
What you need to know
Since the report is the only persistent part of a penetration test, companies must know what they will receive when choosing between vendors. As you discuss your testing AND reporting needs, make sure to request a sample report, and discuss your expectations with the consultants. Also, remember that the sample will be redacted or sanitized to protect the original client's information. If it is sanitized past the point of usefulness, move on to another company.
At this point you might be wondering if Secure Ideas provides a sample report. Of course we do! It is downloadable from our article: Can We See a Sample Report?
