6 Things To Do After Receiving Pen Test Results

6 Things To Do After Receiving Pen Test Results

So, your organisation just completed a penetration test. The pen test results are in: various risk ratings, CVEs highlighted, and other technical and non-technical data. But where do you go next?

It’s not as simple as “just fixing things.”

What if security is not your team’s first or even third concern? It’s likely that before you decided to test your IT systems, security may have been a relatively niche issue. Or maybe security is important, but your team lacks the internal security expertise to mitigate or remediate the issues that have been found.

This article is based on SECFORCE’s experience helping security teams go from pen test results (and recommendations) to successful post-test remediation. Your exact situation may differ.


Read the Report

Pen test results are not designed to be “shelfware.” It might sound obvious, but after the report detailing pen test results comes in, the most dangerous thing you can do is let pen test findings sit unread in a folder somewhere.

You should strive to address the findings in a pen test report before attackers highlight them for you.

A pen test report is a roadmap designed to be easily read by a variety of different audiences.

Different teams are going to be interested in different sections.


Get the Business TL;DR from the Executive Summary

The executive summary part of the report is addressed to the C-level. It's the TL;DR (too long; didn't read) summary of the entire report.

The executive summary is aimed at people who have some understanding of tech but may not do technical things as part of their job. The main goal is to explain how the pen test went, summarise the key issues found, and outline the business impact of those issues.

The executive summary shows business critical findings like:


Read the Technical Sections of the Report and Plan Remediation

The rest of the report will be most interesting to the technical team rather than the C-level.

For example, the technical summary is designed to feed into a remediation roadmap. The data here should be helpful in developing a plan for essential security fixes like deploying new controls, reviewing code, or even pushing new policies for things like password management (complexity of passwords).

There’s also the vulnerabilities section, which outlines the steps pen testers took to exploit each issue, including a high-level description explaining the issue's nature and what an attacker could do.

Plus, evidence and recommendations, i.e., what you should do to fix the specific issues pen testers uncovered (e.g., make sure all the Windows servers are updated to at least this version).


Consider Your Team’s Skill Sets

The remediation plan that comes out of a penetration test report should be actionable, realistic, and timely.

It needs to assign responsibilities to relevant parties with a due date, but it also needs to take into account how security-minded the people who will undertake remediation are. It’s one thing to assign remediation actions and quite another to make sure that people perform these actions in a security-minded way.

When you share vulnerability details from a pen test report with developers (or whoever else is responsible for implementing fixes), they might not always understand how to complete those tasks in a way that actually reduces risk.

Take a web application as an example. Someone tasked with fixing an issue like insufficient password complexity (i.e., the application allows overly simple passwords) could implement a fix on the UI of the web application that prevents users from choosing a "weak" password.

However, the server would still accept the "weak" password if it is sent directly (bypassing the UI restrictions).

In this case, the mitigation is half done. Although the risk of a real-life attack scenario (a user creating a weak password which could later be guessed by an attacker) is lower, it is still considered bad practice. A better approach would be to check for weak passwords both at the UI and the backend server.

The fact that the application was built to accept weak passwords in the first place might also highlight a more fundamental problem with security hygiene that is likely to be present elsewhere in the same environment.


Take the Opportunity to Build Defence In Depth

Risks can also emerge when the people tasked with implementing fixes take shortcuts or over-rely on surface-level protections, which creates a false sense of security. Adding security controls to an application, like a WAF through Cloudflare, doesn’t change the fact that unresolved code vulnerabilities are still open to attack.

A more effective strategy is to build defence in depth, i.e., implement layered protections and controls across the application to strengthen security at each point. This way, even if cybercriminals bypass the first layer of protections, they still have to get past multiple layers of controls.

Of course, if you fix the underlying code, then the attack cannot technically happen. However, from a business perspective, putting more controls in place on top of fixing vulnerabilities just makes everyone sleep better at night.


Retest

The only way to prove that the fixes your organisation implemented work is to test them. We recommend that companies retest as soon as possible after remediating issues.

Fortunately, retests are usually quite short. They typically take a couple of days at most because the testers are focused on the same issues they already encountered and are familiar with your environment.


Pen Test Result Remediation Companion

If you’re struggling to transition from pen test results to remediation, SECFORCE can help.

After a pen test report lands on your desk, we can provide a follow-up service to pen testing remediation that's compact, focused, and gives you a shortcut to building defence in depth.

Our dedicated service can support your team in the following ways:

Contact us today to learn more.

You may also be interested in...

Visual-Portada-Pen-Test-vs-Vul-Scan
Sept. 3, 2024

Pen Test vs Vulnerability Scan: How to Tell the Difference and Why It Matters

This blog post goes deeper into why understanding the use cases for a pen test vs a vulnerability scan matters.

See more
Cover
June 18, 2024

Threat-Led Penetration Testing Explained

Insights from SECFORCE’s offensive security experts on what threat-led penetration testing is (and what it isn't)

See more