Don’t Abuse Scope to Hide the Skeletons in your Network

It happens all the time. A new penetration test work order comes into my inbox, and the customer is asking us to test only a handful of external IP addresses. A quick WHOIS request shows me that the customer owns an entire class C of public IP space, and that they didn’t even include their public webserver in the scope. In an ideal world, I’d get in touch with our Project Manager. We’d get in touch with the customer, and we talk about the scope, the customer would say it was a simple mistake, and give us a full list of IP addresses they control.The sad fact is that this is rarely what happens. Why can’t we test the public webserver? “Well… the public website can’t be tested because it might slow down the website and impact sales.” Fair, but have you considered that we may be able to tune our tools to be less impactful? Have you considered that if a single computer scanning your website can knock it offline, that that might be a vulnerability in and of itself? What about the small scope? “Well… we only want to test the devices which directly interact with our PCI environment.” Fair, but have you considered that your segmentation might not be as solid as you thought it was, and there might be users re-using passwords between your secure and non-secure networks?Another good reason to let your penetration tester assess the entirety of your network is that they might find things that you might never expect. Systems that someone setup years ago and then forgot about? Systems left behind by the previous tenant? Systems with public vulnerabilities which have already been exploited by other real-world adversaries? You wouldn’t believe the things we’ve found on some networks, both external and internal.All of that said, there are some places where things get more complicated, but just because it’s complicated doesn’t mean that it should be ignored. What about when we have X, Y, and Z services hosted in various cloud providers? Legally we can’t test them without the permission of the server owner/operator, but a real attacker wouldn’t let such a thing limit them. So what do you do? Quite simply, the answer is to get in touch with that service provider, and tell them that you’re undergoing a security assessment, and that you need the testers to be able to test those systems. Get something from the provider showing that they’ve approved the testing. If they won’t approve the testing, fine, but that potential risk should be considered and documented. You might even want to consider migrating to a service provider who would approve such testing. I recommend looking for one with a public bug bounty program to show that they care about security.