Scope: The final frontier
You all know what i’m talking about. You scored an assignment, a nice big pentest, and the customer defines it: scope. Or you are the customer, give some pentest company or platform written permission to test your website, and you define it: scope.
But what is scope? Or rather, what should be in it? Or definitely out?
Scope is mostly used and defined as to ‘limit penetration test risk by defining testing scope’. Which means that you, as a company, strictly define what a researcher is allowed to test, and what is strictly out of bounds. And yes, this is a good thing. But is it?
Well, let me give you some food for thought:
Let’s say you own a nice, internet enabled, growing company. Which gets more and more interest from the public, then the media, and then of course the competition. Hmmm. So you start to think about risks. And security. You have a cool website, with lots of features, in a cool datacenter, and you’re building up a nice database with customer records behind it. Sure, it’s safe, the development team said so. But you are wise, not to be fooled easily, and you decide to free up money for a pentest.
So you choose your best fitting pentest company, lay down the rules -no data loss, downtime etc- and give them the scope to test. Https://Your_website.
Nothing more, nothing less. And oh yeah, they can only test on the last monday of the month, because business is slow then and you’ll have time to fix stuff if -God forbid- things go wrong.
So, they test. And they find stuff. Your SSL setup could be better. Your headers need to be more strict. And they even find an XSS in one of your forms. But that’s basically it. They write a nice report, you pay, and you’re done. You are safe!
But are you?
Let’s ask the competition. Do they have scope? Do they only test your site on port 443? And do they try that only one time, on the last monday of the month?
Nope. The don’t. They have no rules.
They do a portscan on your server, find a vulnerable plesk (Management console) installation on your server, and they root the whole box. Game over.
Or they find that your database server listens on port 3306, is accessible for the whole world and still has the default (or too easy to guess) admin credentials. Game over.
Or they scan the IP range that houses your server, and find a web interface to the Idrac (management) console of that server rack. Username: root Password:calvin. Powerdown. Game over.
And sure. That is awfully mean. No fair play. Totally out of your control. Out of scope.
But tell me. Wouldn’t you want to know?
To me, sometimes scope is like asking someone to test the new lock on the front door of your house. The lock is fine. Perfect. But the window next to your door has a broken latch and is opened in 2 seconds.
Out of scope.
But wouldn’t you want to know?
Don’t get me wrong, sometimes scope is needed. And sometimes restrictions are absolutely necessary. But if you want to really test your business, or website, or app, or network… give those researchers time, and room. Let them try, and think, and try again, and come back after 2 weeks on a completely different angle.
Let them try to find access points, or vulnerable and/or outdated software somewhere along the path to your service. Let them report the things that could break your business. Let them do the things they do best. Let the hackers hack. Because if they aren’t allowed to do that, your competitors will win.
“Use the scope wisely. Don’t let it be your final fronteer!”
