While working out the details with a client for an upcoming security assessment, whitelisting the penetration testers IP addresses always generates additional conversation. It may seem odd because you wouldn’t whitelist your adversaries to bypass a security control, so why would you do it during an attack simulation. Depending on your resources, needs, and what you hope to accomplish whitelisting may not be the best fit, so let’s see what our options are.
What do we mean by whitelisting in this context? It’s allowing an exception through your security control, which often times will be a firewall or some type of IPS (intrusion prevention system). This could vary depending on the assessment you are having conducted for instance in application testing you may want to whitelist in the WAF (web application firewall). Essentially it is allowing traffic or some interaction that normally you wouldn’t allow.
The most common reason for doing this is it reduces the amount of time spent on an engagement which thusly reduces cost. If the penetration tester can immediately begin testing an asset without having to take the time to bypass detective/preventive controls, more value-add testing will be conducted in a shorter period. Often engagements are sold based on an allotment of time versus goal achievement and it may not be beneficial to test the firewall more than the application itself.
As the saying goes, an attacker only has to be right once, but the defender has to be right every time. Most attackers are looking for the easiest way to achieve their goal, while security testing by nature is to measure risk holistically. A penetration tester may find an easy way in, but the work doesn’t stop there, he/she has start over from the beginning and look for new avenues. Noisy tools such as vulnerability scanning are utilized, which is quite noisy and often detected by defensive security products, to speed the process up and provide a much thorough view of the attack surface.
As mentioned earlier, whitelisting allows for a much faster engagement. Bypassing security products is often a manual process which takes time and may eat up the majority of an engagements time-limited scope. The tester may not be able to bypass the control in the allotted time which would give the client a false sense of security because attackers have unlimited amounts of time. If an attacker is able to bypass a control, they could have the ability to conduct an attack that the tester would have easily found had they been whitelisted but were toying with the IPS.
We’ve discussed the benefits of whitelisting a penetration tester’s IP address, but you do have some additional option’s if you aren’t totally convinced.
Penetration testing organizations typically ask that you still detect malicious activity to better provide a measurement for your detection capabilities and it’s no different in terms of whitelisting. Traditionally the best solution is to detect the malicious activity but not block it for penetration testers IP address. This will give you a more complete view of your detective abilities and reduce the cost of an assessment.
An option that we see some clients choose is to whitelist for only part of the engagement. This is typically done towards the end of the engagement if there is additional time or set at a specific date or point in the engagement. This option is great if conduct engagements regularly and see there is often time left over or want to further mature your security program.
If you’ve recently purchased a new IPS and want to test out its capabilities, then starting a separate assessment that’s dedicated to the IPS and evasion techniques may be an effective solution. In this scenario you would have 2 engagements, 1 where you whitelist and test an asset and 1 where the IPS itself is tested.
Of course, you always could block the penetration testers IP address anyways and thusly would turn your testing into more of a red team engagement. These engagements are traditionally performed over longer periods of time, but they do simulate an organic attack as closely as possible. We highly recommend you review the scope closely and budget for the additional time required as well as only choose this option if your security program is in a mature state.