How to Write a Good Security Audit Report?

Even the best security audit of a website or application will be of little use if we don't document the detected threats, steps for reproduction, potential threats resulting from their use, and recommendations for fixing the bug. We'll show you how to prepare a detailed report step by step.

What should a good security audit report contain?

Both the visual and the substantive aspect is important. The report should be esthetic, but its visual part shouldn't dominate and interfere with the reception of its content. After all, it's the content of the report that is of key importance. In this article, we'll focus on the substantive part. Using specific examples, we'll present the individual components of a document summarizing a security audit, that is:

• subject matter of the work,
• summary of the carried-out activities and their results,
• detailed description of the detected threats.

First section – a title page with the subject matter of the audit

In this part, we should include information about the content of the document and indicate that it is a security audit report. In addition, we should specify the subject matter of the work, that is the elements the safety tests were carried out for. The date when the work was performed, the location and the persons responsible for the audit should also be provided. The title page should contain only the key and general subject matter of the work.

If the Foo application, its API, source code, and the infrastructure on which it runs were subject to testing, these elements should be on the first page of the report. On the other hand, if the entire application was audited, it shouldn't be broken down into individual parts when providing the subject matter of the audit, but described as a whole. The time for dividing the audit into smaller and more detailed parts will come later.

Security tests report – an example

Subject matter of the work:

• Penetration tests of the Foo application
• Security tests of the Foo application's API
• Analysis of the application's source code
• Penetration tests of the application's infrastructure

Date of performing the work:

01/10/2021 - 10/10/2021

Location of performing the work:

Wrocław

Auditors:

Jan Kowalski

Second section – the summary of the report's content

The following pages should contain the summary of the work. They may be used to describe the subject matter of the work in more detail than on the title page. The summary is also the place to share the collective results of the performed security audit and inform about the most critical vulnerabilities found during the audit. The critical vulnerabilities should be briefly described. All the vulnerabilities will be described in a more detailed manner later in the report.

In the summary, the readers may also familiarize themselves with the adopted vulnerability classification. Therefore, we should list all the levels and add a detailed description to each of them.

Below you can find an example of the vulnerability classification levels' description.

Information

The Information level isn't considered a vulnerability that's threatening security. It's a message that indicates good practices that, if implemented, will increase the overall security level of your application. In this level, we'll also see architectural recommendations, the implementation of which will increase the security of the application.

Low

The vulnerability is insignificant, its use has a negligible impact on the security of the application, or exploiting it requires meeting conditions that are difficult to achieve.

Medium

The vulnerability is moderately significant, which means that exploiting it may require meeting certain conditions that aren't extremely difficult to achieve. It may allow access to a limited amount of data or to the data that's classified as insignificant.

High

A significant vulnerability, exploiting of which allows access to the application's sensitive data, but its use requires certain conditions to be met, such as, for example, having an account with certain authorisations. We also define as high the vulnerabilities that can be exploited in a simple way, but the effects aren't critical.

Critical

Exploiting a critical vulnerability allows for taking full control over the server or for gaining access to important and confidential information. Usually it's easy to exploit and doesn't require certain conditions to be met. Critical vulnerabilities require undertaking immediate actions.

Third section – the vulnerabilities

Each vulnerability should contain a brief title describing the threat. The title should also include the criticality level of the vulnerability. Then, we create a description in which we present the detected threat in detail. If there are certain conditions that must be met in order to exploit the vulnerability, they should be described. Then comes the description of the bug's technical details, in which we show how to exploit the bug. At the end of this part of the security audit report, we should include the recommendations that'll eliminate the threat once introduced.

Example of a vulnerability description

Level of the vulnerability: Critical

Identifier of the vulnerability: FOO_BAR-API-000

Title of the vulnerability: Administrator mode available by manually adding a cookie

Description

The administrator authorization application uses a cookie that may be obtained by an attacker. The account that can be accessed in this way is referred to as a god mode account by the application.

Conditions necessary to exploit the vulnerability: None

Technical details

The attacker must add in the application a cookie with the following properties:

Name: code

Value: iddqd

Recommendation

Implementing login authorization and two factor authentication when accessing a god mode account. Removing the authorization via cookie.

Security audit report – summary

Following a few simple rules allows you to efficiently create a security audit report that's clear and full of relevant information. As we indicated in the introduction, the audit itself could be carried out in an exemplary manner. However, if the report (the summary of the work) isn't at the same high level, the audit result – that is all the conclusions reached during its course, all the comments and recommendations – may not be implemented correctly or even be completely omitted. The report should be written in both the most pleasant and factual manner. We should also remember about the visual aspect of such a document, which should make the whole aesthetically pleasing without diverting attention from the content.

The tips presented in this article will be useful when preparing documents after performing audits of various types of applications and websites, including the ones based on Drupal. If you need additional advice on application security reports in this framework or on conducting a complete audit, learn more about our Drupal support team.