The 6 Step Guide on How to Review Your Penetration Test Results

Picture this: You’ve just spent the past few days (or maybe weeks) working alongside your development team and the penetration testing service you hired. The test environment was created, the access was granted and the tests were run. Now, that final report with your results have been delivered and it’s longer than you expected (possibly way longer).

The results may shock you, but look at it this way: it’s a good thing you decided to do your due diligence. You’re now one step further ahead of the real hackers who are out to steal your data. View that report as a goldmine of data. That data can be turned into information with specific insights on how to improve your security posture.

So, here’s your quick and dirty guide on what to do with the report to make sure that your application is confidently secure.

Managing Your Pentest Results

Unlike other assessments, pentests complete a simulated attack and deliver real-time information from a hacker’s perspective. Penetration testers will fully understand your unique attack surface and apply a testing methodology that will check for potential vulnerabilities and compliance requirements that are holding you back from security. This type of security assessment has the potential to uncover blind spots and vulnerabilities that an administrator can’t see. As a result, you’ll get some of the most valuable insights from this assessment.

But those insights are only as valuable as what you do with them. Here are the steps to take following the test to get the most out of your results.

1. Debrief with the Team

Whether you’ve performed a full test or simply re-tested the latest software update, your report will contain precise documentation of all known issues. This typically includes screenshots and other supporting evidence.

Pay careful attention to these and present the full report to your team to debrief. In other words, don’t assume something is unimportant or extra and leave it out just to save time. Review, discuss, and make sure everyone is on the same page about your pentest results.

At this point, it’s wise to compile a list of follow-up questions for your pentester. They’re usually willing to talk about results, clarify or explain points, and provide additional insights into the results of a pentest.

Pro insights: Research has shown repeatedly that businesses routinely exhibit overconfidence in their cybersecurity. It’s okay to know that most companies actually unknowingly push vulnerable code into production. On average, only 5% of companies actually have proper protection on their data. So, if you have more vulnerabilities in your code than expected, recognize that you’re one of the few on the right track to building a better AppSec or WebSec program.

2. Replicate All Known Issues

A good report from a reputable company will include everything you need to replicate each issue that they’ve found. Make doing so a priority as soon as possible.

There are two big reasons for this.

First, opportunities for false positives exist. These are instances where something gets flagged as an error, when in reality it’s working perfectly fine.

Second, reproducing errors or vulnerabilities will help you to understand them internally. Vulnerabilities can take many shapes, and allowing your team to practice finding and identifying known security flaws empowers an internal security culture. As they learn where security bugs can be found, they also learn how to build more secure code by design. In turn, each update will run less risk, and less team effort will be needed for patching errors after launch.

If you aren’t able to reproduce an identified issue, get a hold of your pentester. A reputable service will be willing to assist and take a second look.

3. Rate Each Risk

If the pentest results returned more than one error, you’ll need to rate them according to severity. That will help you get a sense of where the team must focus its efforts.

At this point, it might prove helpful to acquire a scoring system framework. The Common Vulnerability Scoring System (CVSS) is the most popular open framework for scoring the severity of security threats. It uses a set of base metrics to help you calculate a score from 0 to 10 for each item.

A great characteristic of the CVSS is that it works with the National Vulnerability Database (NVD). If your pentesters identified known vulnerabilities, then you can simply look up their scores in the NVD. It’s worthy to note that the NVD only provides CVSS ‘base scores’ which represent the innate characteristics of each vulnerability. However, the NVD doesn’t provide ‘temporal’ or ‘environmental’ scores. These are metrics that change throughout time due to events external to the vulnerability and scores tailored to reflect the impact of the vulnerability on your organization, respectively. Software Secured bases our scoring on a mix of industry standards - learn more about our scoring here.

This CVSS calculator allow you to calculate the ‘temporal’ and ‘environmental’ scores. It also provides more in-depth information about calculating the severity of vulnerabilities.

CALCULATE SEVERITY

Once you’ve rated each risk, prioritize them with the following ratings:

• Critical. Vulnerabilities that scored above 9.0 must be addressed immediately.
• High. Vulnerabilities between 7.0 and 8.9 should be addressed as soon as possible.
• Medium. Vulnerabilities scored between 4.0 and 6.9 should be addressed or mitigated.
• Low. Vulnerabilities between .1 and 3.9 may be addressed or managed as an acceptable risk.
• None. Vulnerabilities that score 0 are not a risk.

Pro tip: Talk to your pentester to see if your vision for fixing the vulnerabilities align with theirs. If they didn’t already provide customized remediation advice, most will be happy to offer you a few pointers.

5. Implement the Fixes

With the team on board and a resolution plan in hand, it’s time to implement fixes. How implementation happens depends on your specific DevOps setup. Generally, teams can consider the following:

• If this was a baseline or quarterly assessment, consider whether your DevOps process needs additional security measurements. For example, implementing threat modeling can help you identify vulnerabilities earlier in the SDLC. Threat modeling works best in the design stage, so your application’s overall structure will be more secure.
• If this was a re-test following an update, be aware some pentesting services will automatically re-test to check if a security bug was patched correctly. If this was the case with your provider, you will have quick access to a report with the results. If not, let your pentest provider know about the update so you can have a new report delivered.
• If most of your fixes are large scale, this may indicate there’s a critical flaw in your application’s design or your DevOps pipeline. If this is the case, seek out advice for next steps from your pentester or another security remediation expert.

6. Review the Process

Regardless if this was your first or tenth pentest, the results may have come as a shock knowing that your trusted code had more flaws than expected. It’s okay to feel surprised. However, it does signal that you may want to review secure design processes with your pentester or another security expert to determine more secure ways to manage and build applications. With a service like Penetration Testing as a Service (PTaaS), pentesting is done more frequently. Being so, you’ll always have access to a pentester who you can trust for security advice, even while your app is in development.

Here are a few questions to consider asking in the final debrief:

• What went well? What didn’t go so well?
• What type of pentest did we run? Was it the correct type for what we were trying to learn?
• Were the vulnerabilities discovered primarily known or unknown weaknesses?
• Were we happy with our experience with this pentester? Were there things we were concerned about or were we left with any questions?
• Was everyone who needed to know about the pentest kept in the loop? Were there any communication failings along the way?