The importance of technical reports

Technical reports are formal documents, resulting from the research of an expert on the subject, or a multidisciplinary team, which complies information or relevant evidence, with a criterion of independence and objectivity, on a fact or situation. Their aim is to analyse such information or evidence and provide conclusions to aid good decision making.

Some of their main features are:

• Impartiality, as the information and data contained in the report must be objective, avoiding expressing the opinion, viewpoint or subjective aspects of the writer.
• Clarity, data, information and the language used must be clear and straightforward, in such a way that it can be understood without difficulty by the addressees, facilitating the fluidity of its reading and subsequent decision-making. Moreover, if the report includes any images, such as illustrations, screenshots or other content, it must be of a good quality, resolution and accessibility, so it is truly useful.
• Sequence, the report should maintain a concrete and orderly structure for the presentation of information, as well as coherence and cohesion in the information written.
• Chronological order, in studies where there is a timeline, this should be indicated.
• Confidentiality, this type of information, can be sensitive of classified, so it should be processed in compliance with the established rules for exchanging or publishing information such as the TLP
• Rigorousness, the information provided must be rigorous, comparable and reproducible.

Report structure

Although there are different types of technical reports, such as forensic , pentest, malware, and audit, among others, all of these share the need for a clear structure to make them easy to understand, which should include the presentation of the aims, methods and results of the tests carried out, adapted for different audiences. 

However, it is common for each company or institution to use a fully customised reporting scheme according to their needs. The following is a proposal for a general structure, stating all the points that should be included.

Front Cover:

Although it will depend on the report type, in general, the front cover includes information with the aim of identifying and classifying the report correctly, it will need to include certain information, such as its classification level, information on the author/researcher, numbering of the investigation/case and the dates of receipt and preparation of the report.

Table of contents and version control:

In the table of contents it is common to include links or shortcuts to make it easy to move through the different sections of the document, while version control should include at least a description of the changes introduced in each modification of the document with a date and author of the changes.

Executive summary:

This section will communicate to the reader the specific goals of the test to be conducted and the high-level findings of the testing exercise. The recipients of this part of the report will be those who are in charge of overseeing the work done, as well as any member of the organisation who may be affected by the identified/confirmed threats. Bearing in mind that these audiences may not have sufficient time or technical knowledge understand certain findings and go into detail, the most relevant information should be summarised as briefly as possible.

An overall risk score will help to understand the hazards or threats resulting from the analysis in a visually appealing way, without having to go into technicalities. For this purpose, it is necessary for the tester to identify the scoring mechanism and the individual mechanism for monitoring/classifying the risk, usually calculated quantitatively using the formula RISK = PROBABILITY x IMPACT, or qualitatively, using the following risk matrix:
 

For vulnerability analyses, the criticality will be assigned based on the CVSS rating, the latest version of which is currently 3.1. 

Introduction:

 A clear and simple description of the analysis or issues to be addressed, which should help the reader to construe what kind of information is to be found in the rest of the document and why.

• Background: explaining to the reader the history or motivation for the technical report. For example: an information leak has been detected, it is required in order to comply with a certain standard or procedure etc., in addition to the general purpose of the test performed or any other details that must be taken into account for the proper construction of the results contained in the report.
• Aim: this section shall present in a clear and detailed way what is sought through the scientific or technical research or development work carried out. For example, conducting an intrusion test is intended to verify the effectiveness of the security controls implemented by a system to protect critical information, and the report will make visible the findings of the assessment and associated recommendations to help strengthen the security posture of the system.
• Scope: this field limits the scope of the study. It basically serves to determine the space or time limits of the study. The report should therefore address the completeness of the scope, no more and no less. Alternatively, a justification must be provided when certain aspects outside the scope have been analysed, or why other aspects have been left unanalysed. In some cases, during the course of the analysis, exceptions may arise for consideration.
• Incidents: If during the course of the analysis or testing, the scope of the analysis or testing has to be adapted or even changed, all such changes or incidents should be recorded and listed in this section of the report. In addition, the document approving such a change should be included in the appendix to the report and linked from this section.

Methodology:

This section indicates the rules or set of procedures that have been followed in order to carry out the task at hand.

If OSINT techniques are used, it is advisable to detail which ones are used and why.

Results obtained:

This section is the main and longest section of the report and will contain the technical details of the findings, as well as all aspects and components agreed as key indicators of success within the agreed or planned scope. It shall describe in detail the scope, information, directions or routes relevant to the finding, the impact.

By its very nature, this section of the report will be specific to the type of report, setting out the results, and providing evidence to support them.

The vulnerabilities or faults found must be identified and classified according to the criteria defined. It is also important, especially in the case of forensic analysis, to include dates or time records identifying the findings and the chain of custody. For this purpose, a timeline is usually set up, where the stages of the processes involved in the analyses and the results obtained are established. 

Conclusions and recommendations:

The overall conclusions will provide a synopsis of the results obtained. They can be reinforced by graphical representations of tested targets, test results, processes, attack scenarios, success rates and other relevant metrics as previously defined.

Recommendations for improvement can also be added if necessary, which should provide the recipient with a high-level of understanding of the tasks needed to address the identified risks and the overall level of effort required for their implementation. 

Glossary of terminology (optional):

A glossary of terminology helps the reader to improve their understanding of the content, allowing the easy and organised consultation of technical terms or acronyms which may appear in the body of the report. In alphabetical order, the reader will find each key word and its definition.

Annexes (optional):

This section shall include additional documentation that supports and completes the report and which, due to its length or specificity, cannot be included in the previous sections. It includes detailed evidence, complete evidence, scripts, Internet references, logs generated by the system under analysis, memory dumps, code snippets, etc.

It is common to include relevant parts of such evidence within the body of the report to highlight findings and to include the full content in annexes.

Some tools for technical reporting

Having seen the proposed structure and knowing that any office package that includes word processing and spreadsheets can be a valid tool for the elaboration of reports. Here are some tools which may be of use. 

• Dradis: an open source, cross-platform and extensible security project framework for collaboration and reporting.
• Serpico: a tool designed to create information security reports, which supports the use of templates and mark-up language.
• Petereport: a system that enables detailed descriptions of data relevant to the finding, such as routes, attacks, etc., all this with the aim of giving investigators more time to carry out tests. It also allows the management of a database of findings templates.
• PwnDoc: enables generation of customisable Word files, with the main goal of speeding up the process of documenting results.
• JasperReports Library: an open-source Java library that provides a reporting engine. An XML editor can be used, or graphic design tools can be used, although the latter are often paid for.
• LibreOffice: office suite that includes among its tools word processing, spreadsheet, presentations, database, creation of diagrams, among others. It is open source and cross-platform.
• Plaso: enables the setup of timelines.

In addition to this small sample, many specific applications include their own reporting tools. Because those tools are integrated, they may be easier to handle, but having additional resources can mean the difference between a mechanical report and a more customised report.

Conclusion

Drafting of a technical report is a recurrent task among professionals and, although there are reports of all kinds, when it comes to preparing a technical report the important thing is to know the target audience and the information they expect to obtain from this report. 

Another strategy for a successful report can be to prepare them in parallel to the research, rather than waiting until the last moment, when they can be more complicated and tedious, as some of the necessary details may be missing or forgotten.

Finally, it should be borne in mind that the reports are the result of the work carried out and, therefore, they can mean either its success or failure. Hence the importance of preparing them with the care and dedication they deserve.