The 6-Step Guide to Reviewing Your PenTest Results
Picture this: You’ve just spent the past few days (or maybe weeks) working alongside your development team and the pentesting service you hired. The test environment was created, the access was granted and the tests were run. Now, that final report with your pentest 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 deliver real-time information from a hacker’s perspective. That 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 a pentest 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. Although pentesters are always on the lookout for false positives, they can occasionally slip through the cracks.
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 and 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.
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.
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.
4. Determine a Resolution for Each Risk
Once you’ve developed a clear sense of the vulnerabilities your pentester discovered and their severity levels, it’s time to get to work!
Bringing a remediation expert on board at this point could save you time and energy as you deal with the results of a pentest. These experts will have plenty of insights on what can be done.
In general, there are four major resolutions to aim for:
- Eliminate. Completely closing the vulnerability.
- Reduce. Mitigating the vulnerability, reducing the likelihood of exploitation. Lowering either the impact of the vulnerability or the likelihood of occurrence will reduce the severity.
- Manage. The vulnerability is known and monitored but not mitigated.
- Accept. The vulnerability exists within your risk appetite, and the cost of fixing the risk is too high. No further action is required for the vulnerability.
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 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?
Test Early, Fix Often with Pentesting as a Service
Being confronted with the results of a pentest can feel a lot like getting doused with cold water. When a pentest reveals vulnerabilities, it means the whole process was a success. It did what it was supposed to do, which was to discover ways you can improve your software’s security posture.
After your test wraps up, our pentesters are ready to help you develop a more secure application through the six steps of debriefing, replicating, rating, resolving, implementing and reviewing.
Looking to start a new test or integrate PTaaS into your DevOps pipeline? We’re happy to walk you through a demo. Book a call here!
We help DevOps teams at SaaS companies to build confidence in their application security.Discover PTaaS
Was this article helpful?
Share This Post