We consider reporting to be an essential part of the penetration testing process. HMG customers require penetration testing reports to provide them with a full understanding of vulnerabilities within their network as well as specific advice on how to eliminate or mitigate those vulnerabilities.
In order to ensure that our review procedure is comprehensive and consistent, we require that the reports that you supply to support your application cover a network penetration test of a non-trivial heterogeneous network. These reports should also demonstrate a level of technical ability beyond that which would be required to operate and interpret results from automated vulnerability scanning software.
All CHECK companies must submit reports monthly - companies will be expected to submit 'null' returns if they will not be sending in any reports in a particular month. Copies of reports must be sent to the Scheme Officer for quality checking by the Assessment Panel within 4 weeks of the report having been issued to the customer.
Much of the work done by CHECK companies is sensitive and could, if disclosed to unauthorised persons, result in compromise of the system(s) concerned or cause great embarrassment to the system owner. Therefore, all reports must be encrypted before submission. For details please contact Enquiries.
Please notify CHECK via email or phone if you perform any tests with report classifications above OFFICIAL so that arrangements can be made to obtain copies of these reports.
Content of the report
The report should include the following information:
- a non-technical summary of the findings
- an objective or aim for the task
- the Scope of the task as agreed with the customer
- the vulnerability findings each with a recommendation of a method to resolve the issue
- details of possible methods by which the customer could have identified the vulnerability themselves through business as usual testing
- basic log data to support claims of vulnerability except where identification is trivial
- contact details of the customer and CHECK team consultants
The following reporting requirements laid down by CHECK ensure that reports contain the information necessary for HMG customers to understand and respond to the findings.
Report authors should ensure that the report is readable and accessible to the customer:
- the content of the report should be clear, concise and unambiguous
- the executive summary of the report must be directed at a non-technical audience (thereafter the report can be exclusively directed at a technical audience if desired) and should include an overview of the technical findings and an assessment of how aware the customer was of the vulnerability of their target system before the task occurred
We will be looking for the following items within the report:
- a point of contact and contact details for the CHECK customer organisation
- the CHECK logo on the front of the report
- a list of the individuals involved in the test on the front of the report
- a summary - a good high-level description of the main findings aimed at a non-technical audience along with an assessment of how aware the customer was of the vulnerabilities of the system prior to testing
- all findings are positively identified (where possible) and described
- each finding is accompanied by a solution that is relevant to the customer's environment
- automated vulnerability scanning tools do not appear to have been heavily relied upon (including "cut-and-paste" output from vulnerability scanners)
- The tests and attacks performed have been as comprehensive as possible, technically sound and within the bounds of the customer agreed scope
The report should communicate the background, scope and context of the task:
- the report should document the aim of the task (as agreed with the customer during scoping)
- the report should identify the hosts and devices or address ranges agreed with the customer as in scope
- the report should contain an explanation of any strategy to reduce the ideal scope of the task (eg representative sampling)
- any hosts and devices that are specifically out of scope should be identified
- any other customer-imposed restrictions that affected testing should be made clear
Vulnerabilities should be accurately identified:
- false-positives should be avoided through positively confirming the presence of a vulnerability whenever possible
- vulnerabilities should be described as well as identified
- a vulnerability description should include an indication of its impact to the customer
- the severity of a vulnerability should be stated as HIGH, MEDIUM or LOW according to the level of associated risk posed to the customer. Information from other scoring or classification schemes may be included in addition to (but not in place of) this
- any deviation from the standard severity rating of a vulnerability should be justified (eg the provision of other mitigating controls)
- hosts affected by each vulnerability should be clearly identified, including relevant TCP or UDP port numbers where applicable
A solution should be provided for each vulnerability identified:
- each solution should be as accurate as possible
- solutions should generally refer to technical controls and should be provided in procedural form where possible
- recommendations should be impartial as far as possible and not favour the products of any particular vendor without justification
- solutions should be provided with reference to the customer's environment, context and any relevant restrictions rather than blanket recommendations, wherever possible
- solutions should include appropriate short-term or alternative remedial actions that the customer may take to address the vulnerability in advance of a full solution
- references to resources containing further information on a vulnerability should be provided, where possible
Copies of customer reports will be treated as confidential documents. We understand that there may be issues concerning disclosure and will accept sanitised documents. However, the sanitisation should not affect the readability of the report nor alter its technical premises. Please contact us if you would like guidance on report sanitisation.
The report should be classified as appropriate. The Security Classification used should be agreed with the customer but as a rule it should reflect the Security Classification of the system or any data on that system.