Pitfalls to Avoid in your Penetration Testing Programme

Typically, organisations will not perform a pen test on a weekly or monthly basis, due to the associated costs.  Instead, pen testing is often conducted annually or 6 months, and 6-12 months is a very long period of time to not receive any indication of what vulnerabilities exist in your environment.  As such, we would recommend conducting more frequent vulnerability scanning in between the scheduled pen tests.   Vulnerability scanners are highly effective tools for quickly identifying vulnerabilities and misconfigurations in your IT assets as they do not require any human supervision, and they can be run from an authenticated or an unauthenticated perspective.  Scanners can also cover both infrastructure and web applications, so will help you identify vulnerabilities before they can be exploited by threat actors.  One particular area where scanners will be of value is in identifying unsupported and unpatched software that can then be removed or updated, allowing you to remediate this very common vulnerability in a time and cost-effective manner.  If you want to learn more about the risks associated with unsupported software, read our blog on the 10 Most Common Vulnerabilities Found in Pen Tests.

We would recommend running vulnerability scans on a regular basis, as frequently as is manageable for your organisation (i.e., weekly or monthly – there is no point in running daily scans, for example, if you do not have the time or resources to look at their results).  We would also recommend running both authenticated and unauthenticated scans, as these different perspectives will provide you with an improved insight into network vulnerabilities, misconfigurations, etc.

‍

As mentioned above, automated tools such as vulnerability scanners are extremely useful for enhancing efficiency and identifying vulnerabilities between pen tests, however you should not rely on automated tools alone.  Tools will not be able to contextualise the findings they identify.  If, for example, a web application provides the scanner tool with access to a particular resource, how does the tool know whether this resource is supposed to be accessible or not?  Even the most expensive or effective automated tools will not be able to match a human’s ability to understand and consider the context of findings identified, and to use these findings to draw conclusions.  

Overreliance on scanners can also lead to a false sense of security.  If a scanner designates vulnerabilities as medium or low risk, it is not uncommon for organisations to view remediation of these vulnerabilities as a low priority and only address those that are high or critical risk.  However, if you have several low or medium-severity findings that can be linked together, this can create a higher (and potentially critical) impact on your organisation if a malicious actor attempts to exploit them.  However, a penetration tester would be able to identify this.

Organisations will sometimes want to exclude particular systems or aspects from the scope of their pen tests that may result in high or critical risk vulnerabilities being missed.    Organisations may exclude part of their environment from the test’s scope as they do not want to risk a particular system suffering an outage during a test, a system contains data they do not want third parties to access, they can’t get approval from a relevant third party, or simply because they think a particular functionality within a web application does not require testing.   We also find organisations test a web application but exclude the platform hosting the web application or other potential entry points, as they have not been considered during the scoping process.

Pen testers will often ask to be allowlisted against active protection mechanisms.  This is not because the tester is trying to make their job easier, but because they only have a limited amount of time to perform the test and it is beneficial to you that they test as much as possible, rather than spending a significant proportion of the allocated time slowly breaking through these defences.  If your tester’s IP address is blocked for an hour by a web application firewall (WAF) or intrusion prevention system (IPS), you will not receive the greatest value from your test as time will be wasted waiting for the block to expire.  In terms of credentials, for a test such as a build review, a tester will also need to be on the system in order to access and investigate the necessary areas, and will not be able to achieve this in the time allocated for the test unless credentials are provided.

It is perfectly acceptable to take a black box approach and not disable your active protection mechanisms if you specifically want to test these.   However, if, for example, your organisation does not develop and manage its own WAF and you have engaged a pen tester to test a web application, refusing to allowlist your tester will mean that much of the time you have paid for is spent testing another organsiation’s solution rather than your application.

There are a number of practical, quick-win improvements that will help to support your pen testing programme and enhance your cyber security.  For example, you will often be unable to fix every finding identified in a pen test straight away.  As such, it is important to prioritise the remediation of these findings based on your business requirements, using a risk-based approach and integrating existing risk management frameworks, i.e., identifying which findings are the most critical to your organisation, and amending these first.  

We at URM would also suggest setting strong passwords across your environment and enforcing multi-factor authentication (MFA) where possible, as well as using password managers to assist with this.  Meanwhile, hiding administrative interfaces (such as login interfaces) from the internet and from standard users within your internal network will reduce your attack surface and, in turn, reduce the likelihood of your organisation being subject to a breach.  If your organisation develops applications, it is also essential that you follow secure code development practices and refer to the Open Worldwide Application Security Project (OWASP) to keep up to date with current best practice.