…we don’t whitelist hackers!”
Before a Penetration Testing engagement I have some stock text that I send to a client just to make sure everything is in order before the testing begins. Most clients just nod and don’t even mention it, the things on the list are generally obvious items. I’m talking about things like: Please ensure that a desk has been reserved, with an appropriate network connection and power socket.
Some of the requests that I put in that preflight email might seem obvious to some people. However I like to offer this checklist to clients because for some of them it’s their first time being tested and they’re unsure what to expect – or for some of them the main contact is just incredibly busy and it’s good to give them a list so they can quickly check if everything is in order before I arrive. Also I send the list because I’ve arrived more than once to a site and not been supplied the simple things like a power socket, so it’s always good to check ahead of arrival!
One of the things I include in the email for Internet based testing is to request that my source IP addresses are whitelisted on their Intrusion Prevention Systems, Intrusion Detection Systems, and Analytics software. Today certainly wasn’t the first time that I’ve had a client come back with “Whitelisting Penetration Testers is Cheating…we don’t whitelist hackers!”.
For a penetration test of this nature I don’t require whitelisting, however it all depends on the types of testing that will be undertaken, the reasons for the testing and how much time has been given for the assessment. So I figured I’d put some notes together here, so if you’re looking at procuring testing from a company, to shine a little light on why they might ask to be whitelisted.
You see it all comes down to the tools and tactics available to testers and those available to malicious attackers. It also comes down to time. It’s linked to what the assessment is aiming to achieve. Note that we’re not talking about whitelisting on the firewall here to make additional services available but strictly speaking about protection mechanisms that ban addresses when an attack is detected.
Many intrusion prevention systems can be bypassed given enough time. Malicious attackers have significant amounts of time to execute an attack, their attacks are measured in months whereas your penetration test is likely measured in days. A tester likely has to sacrifice subtly and stealth in the name of just getting the test done. Penetration Testers’ time is rarely cheap, so consider – are you trying to assess if your IPS can be bypassed through time-consuming reduced speed scanning or are you trying to efficiently identify and prioritise vulnerabilities on your systems? Both are valid approaches and things that should be assessed, but for the purposes of each assessment you should set a primary goal.
Secondly if you have blocking protections in place then an attacker can potentially bypass this type of protection by changing their external addresses through proxies, technologies like TOR and botnets. The first thing about this is that it’s unlikely that your Penetration Tester has a BotNet at their disposal, so that leaves them with TOR and proxies. These services aren’t owned exclusively by the testing company and are shared services. There is the potential that a malicious TOR exit node, for example, could monitor the traffic from the tester’s machine and could gather information about the assessment, which is undesirable.
Plus the ability to tie the assessment to a collection of IP addresses accurately is important. If something happens during the assessment such as a service crash, it’s important that we can determine if testing activity caused the outage or if it was a malicious and poorly timed attacker.
Now when it comes to tactics you should bear in mind that attackers often exploit “flavour of the month” vulnerabilities whereas a penetration tester will try a large collection of vulnerabilities to give a wider image of the vulnerabilities a company suffers from. Think about Heartbleed, when it was first publicly disclosed a significant portion of attack traffic was exploiting this single vulnerability. Attackers were unlikely to run full port scans or enumeration for this issue as a penetration tester would during assessments.
Additionally, you shouldn’t rely on any single protection mechanism such as an IPS. If there is a vulnerability behind the protection system then you should look to remediate it just in case an issue is found in the future with the IPS itself, this is applied defence in depth. Security devices are not infallible themselves.
Finally if your performing a penetration test for compliance reasons such as PCI ASV scans, then the compliance documentation itself may mandate whether whitelisting should be done. PCI requires it, whereas Cyber Essentials states that we shouldn’t whitelist.
In short, there are reasons for both approached – to whitelist or not whitelist. However you should work with your testing provider during pre-engagement meeting and discuss questions like the following:
- Is this assessment part of a compliance requirement such as PCI ASV scans which require whitelisting?
- Are you specifically looking to test your intrusion detection and prevention systems, or the wider network security?
- Do you have the budget to cover a prolonged, more realistic attack simulations?
In most cases and for most companies: it’s likely that you’ll get the most out of your budget if you whitelist your penetration testers, even though you wouldn’t whitelist your attackers.