The penetration test is by far the most effective method to ensure network security.
By simulating the real-world actions of cybercriminals, managers can achieve the most concrete understanding possible of their system’s vulnerabilities.
Even more importantly, a well-executed penetration test can give you essential insight on how to bolster your cyber and information security.
The process of an actual pen test, its procedures, goals, and how to choose the right pen tester, are each a question in and of themselves. And those questions usually get the most attention.
What’s neglected by pen test customers is actually the one ‘deliverable’ that comes with the test: the post-test report.
(NOTE: If you’re considering a penetration test, our free tool below matches you with top-rated pentest firms that fit your budget.)
Why is a Penetration Test Report Important?
The test report is in fact one of the most important steps of the entire pen testing process. Unfortunately, many companies that contract a penetration test fail to realize this.
Many view a pen test the same way they might view a doctor’s visit. The patient shows up. He gets poked and prodded to make sure everything is in order. He leaves. There’s no real ‘follow-up’ unless something is found to be seriously wrong.
A penetration test, in this view, kind of works the same way. The managers want a check-up on their system, so they subject it to some test attacks. If no glaring weaknesses are found, then that’s that. While this understanding does have some truth to it, it fails to capture what the benefits and purposes of a pen test really are.
Contracting a pen test isn’t to see whether or not a system can be hacked.
In theory, any digital network possesses at least one vulnerability that can be exploited by hackers. What a pen test is trying to uncover is how the system responds to a series of pre-determined attacks and penetration techniques. Almost by definition, the pen test is the first step in a process. That process is discovering how to improve your network’s current configuration and how it can stand up to specific threats.
The penetration testing report is what is supposed to contain all of that information.
Benefits of a Good Penetration Test Report
Now that we’ve clarified that basic point, we can unpack the test report a bit more.
Broadly speaking, there are two categories of benefits a penetration test report gives you.
The first is providing direction on how to move forward. Any potential issues with your system, the risk level associated with those weaknesses, and what can be done about them are all meant to be contained in the pen test report.
This is important since it gives managers a road map on how to proceed to remediation. Do you hire a development team to revamp your system now? Can you hand off the needed corrections to your in-house IT team? Do you even need or want to invest in fixing these problems? The answer to all these questions–or at least the basic information needed to make a decision–is supposed to be contained in the test report.
The second benefit? Credentials.
Like in most fields, credentials in IT serve different purposes.
At the most basic level, a penetration testing report serves as a recognition of safety–a safety certificate of sorts. It lets your clientele know that you take your system security seriously and have subjected it to real, concrete tests to ensure its integrity.
In today’s world where the risk of data theft and crippling cyber attacks (a threat that affects primarily small-to-medium sized businesses) is all too known, projecting this security message is absolutely critical from a branding and customer-confidence perspective.
Another equally important benefit is the compliance factor. The past several years have seen a surge in IT regulation from Europe’s GDPR, to the Californian Consumer Privacy Act (CCPA). Many of these important regulations require data holders to demonstrate “reasonable precautions” to prevent data from being exfiltrated.
Having your system reviewed by credible pen testers, in almost all cases, can satisfy these requirements.
What Does a Penetration Testing Report Contain?
Knowing what a test report can provide for you, it’s a good idea to have an idea of what a decent report is supposed to look like.
The first items addressed in penetration test reports are the characteristics of the pen test itself.
Painting with a broad brush, there are three points here that will be addressed:
What information was supplied to penetration testers?
Before any pen test begins, developers will gather information about the system they’ll be testing. This will involve some intel gathering on their part but largely it’ll consist of questions on system components and configuration addressed to the managers who hired them. The information developers have at the outset will largely determine the penetration test’s methodology.
What test cases are included?
As we already alluded to earlier, pen tests are not a singularly defined procedure. The range of attacks and simulations that can be applied, from SQL injections to social engineering ruses, is quite wide. A penetration testing report should lay out clearly which tools, tactics, and techniques were used during the test.
What assets were within the scope of the test?
Just as there’s no narrow definition of what a pen test involves, so too, there’s no definitive scope for a pen test.
The typical business network (especially at the corporate level) tends to include a spectrum of components and applications. Databases, communications tools, task managers, the works. All of these programs could, technically speaking, create weak points for a system. But rarely will every single aspect of a company’s network be part of a pen test. Which components were subjected to pen testing must be highlighted in the report.
What were the vulnerabilities that were identified?
Finally, the report must list in a clear and detailed manner what vulnerabilities were identified in the course of the pen test.
The way this information is conveyed is crucial.
First off, managers should expect an executive summary at the top of this section. The executive summary will provide strategic direction for the people in charge of addressing these vulnerabilities. The head of infosec may not personally be fixing the bugs identified in the test, but he or she will need to have a general synopsis. Another value of an executive summary is to have something deliverable to company high-ups. These people might not have any direct involvement with the IT side of running the business, but should still be informed of the issues.
The second thing you’re looking for is reporting in clear and practically oriented language. This means communicating the vulnerabilities in a way a layman can know what’s being said (if the vulnerabilities are laid out in highly technical language, it won’t be of much help to most executives who read the report) and, even more crucially, putting the risk factors in context.
That last point is worth unpacking a little further.
Risk in Context
At the end of the day, companies contract pen tests to know the risks they’re facing. But the concept of risk is not a pass/fail type of thing. Risk needs to be weighed. And the way in which risk is weighed always depends on context.
What does this mean for a penetration testing report?
Simply put, it means the “vulnerabilities discovered” section should include the potential repercussions for each vulnerability.
Let’s say a company in the healthcare industry contracted a pen test. One of the vulnerabilities found was a loophole in uploading files to patient portals.
Consider these two possible versions of a pen test report:
One version might say:
“Current configuration does not prevent user uploads to patient portals.”
While this is technically accurate, it fails to highlight the real-world consequences the vulnerability could produce.
Now, consider this version:
“Current configuration does not prevent unauthorized users from uploading data to a patient’s portal. Through this vulnerability, attackers could execute code remotely and elevate their privileges, which would grant access to confidential medical records and allow attackers to operate as administrators on the program.”
See the difference?
The second one simply has more weight to it because it speaks to the potential business impact the vulnerability can have.
Of all the points that determine the quality of penetration test reports, this is probably the most important one.
It’s essential that a report details the potential consequences of each problem uncovered in a test. Only in this way can managers get a clear picture of the risk they’re facing.
How is Risk Calculated?
In addition to clearly explaining vulnerabilities in context, a pen test report should have some form of rating system for the issues discovered.
Whether this is a number grading system (scale of 1 – 10 for example) or based on categories (low, medium, high), it is important for the customer to have a relative idea of the severity of each weakness uncovered in their system.
How do pen testers make these calculations?
Broadly speaking, risk assessment is based on two particular factors: a) Likelihood and b) Impact.
In other words, what are the chances this network will face this particular threat and if it does, what are the potential consequences.
If we were to write this in equation form, it would look something like this:
impact * likelihood = risk level.
Let’s address each one of these separately.
In the cybersecurity domain, Likelihood is based largely on the commonality of the threat at a particular time and within a particular industry. This is really where expertise comes in since a tester needs to be familiar with the current threat landscape as well as the broader patterns of cybercrime. If for instance there’s been a spike in the use of a recently discovered exploit, that will mean the likelihood of a threat is increased by a lot.
What this means in terms of a risk calculation is that while Likelihood is volatile and constantly changing, there are methods to give it a concrete assessment for any given time and domain.
Now, regarding impact. The first relevant question is what can be impacted.
A vulnerability could be a threat on the technical side only, i.e. it could lead to temporary system failures or other glitches that can affect business continuity. While this isn’t insignificant, the damage from such a threat is usually temporary and therefore gets a lower impact rating.
The more severe type of impact involves threats that can permanently damage or compromise critical aspects of the business. In terms of potential impact, these are the categories pen testers will be on the lookout for:
- Personally identifiable information of clients/customers and employees
- Financial data
- Trade and industrial secrets
- Critical infrastructure
If a given vulnerability poses a potential threat to any of these components of the business, this will classify the impact level as high.
A pen test report should include a simplified rating for each vulnerability and an explanation for these ratings based on the above factors.
Report Delivery
You’ve gone through your pen test. What should you expect in terms of the report delivery?
As far as turnaround time is concerned, it depends largely on the scale of the test. A good ballpark to expect for a medium-sized business is to receive their pen test report in one workweek. Remember, the testers are recording their procedures and findings as they go. The report is simply organizing that information and framing it in the business-impact context we discussed above.
Then there’s the actual delivery method.
Needless to say, your report will contain highly sensitive information on the inner workings of your system. Different developers will have different methods for forwarding the documents to you in a secure fashion. At the very least you should expect some form of encrypted email being used for these documents. Some developers will circumvent digital coms altogether and physically deliver the data in the form of a thumb drive or an SD card.
Reviewing the Report
Once you have the report, it’s time to begin reviewing the results.
There are two main points to keep in mind for this stage.
1. Arrange a debriefing
It’s important to review the report in full with all relevant team members. Having everyone on board to discuss what’s been found is vital for remediation.
2. Rate Vulnerabilities
If your report is a good one, it clearly presented the vulnerabilities and the potential consequences they may have. Now it’s up to you to begin addressing them.
The first priority is vulnerabilities you’re legally obligated to correct. Next is factoring in budget considerations.
For many firms, fixing absolutely everything simply won’t be possible. If remediating a problem means a total revamp of a system, for instance, the investment might not be feasible. This is where the budget triage needs to occur.
Finally, there’s rating the vulnerabilities according to severity.
Here there are some very helpful open-source tools that can come in handy. A common framework recommended by experts is the Common Vulnerability Scoring System (CVSS). The CVSS uses a set of base metrics to help you calculate a score from 0 to 10 for each item. A great benefit of the CVSS is that it works with the US National Vulnerability Database (NVD) containing a massive archive of known infosec threats. If your pen test identified known vulnerabilities, you can simply look up their scores in the NVD.
Keep in mind, not all risks need to be remediated. A company can decide based on the pen test report and their subsequent assessment that a certain vulnerability is within their risk tolerance. And that’s fine.
However, any vulnerabilities deemed not risky enough to require remediation should be monitored to ensure the risk level is not elevated due to changes in the threat landscape over time.
How to Begin Remedial Action
Now you’ve arrived at the last step: remediation.
The very first thing to determine is if the issues that need solving require hiring outside experts or if they can be managed by in-house staff. This is a relatively straightforward question you can pose to your IT or Operations people.
Also good to know from the outset is that not all issues require the same type of fix.
Some problems may require patching programs that will close the weaknesses. In that case, you’ll need to contact developers who specialize in those programs.
Others will require some type of system overhaul. For instance, let’s say a certain application you use possesses security protocols that just don’t meet your industry’s security standards. In such a case, there may not be anything to do other than replace your current program with something more robust. Here, it’s not a developer you need to call, rather an alternative product or service provider.
There’s also the possibility that vulnerabilities discovered aren’t isolated issues but in fact constitute a critical flaw in your system’s design or development pipeline. If this is the case, any competent pen tester will make this clear in the report and you’ll need to seek out advice for the next steps from a systems designer.
