Posted on 2020-05-21 by Matt Strahan in Business Security
What is in scope for a penetration test will be tested and what isn’t in scope for a penetration test won’t be tested. Simple enough, right? The problem comes when the hackers don’t follow the same scope that the penetration testers follow.
The choices that are usually made when scoping a penetration test are often made around simple practicalities and the various requirements that pop up for the organisation. Security considerations are important, but can be a secondary factor to it all.
For smaller organisations it’s not uncommon to have a full annual test with the entire internal and external environment in scope. After all, it’s easier to do it in one lot and just get it over with.
For larger organisations a full annual test would be too much since there are too many moving parts. It’s more common to have the scope restricted to a single project, maybe the new web application, new SOE, or the new network environment.
More interesting than what’s in scope is what isn’t. This article looks at the increasingly common scenario where there are third party systems and connections in your environment. You might have a web application that passes data to a third party for processing or a SaaS ERP that integrates into your customer databases. You might even use a third party data warehouse as a backend for your main business critical application.
Sometimes you host critical data or business functions in a SaaS cloud service or managed service and you just want to make sure it’s not likely to be hacked.
Can we please hack your stuff?
If I was to hire a penetration tester and say “hey could you please hack Instagram for me and increase the number of likes I have? Uhh…it’s to test their security” I might get a bit of scepticism. It’s illegal to hack stuff without authorisation. That’s part of what makes a clear scope so important.
It’s no different if I decided to ask a construction company to demolish a building that’s not mine. If I hire a cleaning company to clean a house that’s not mine I might get some interesting conversations with extremely mixed feelings. “Thanks, but…huh?”
Getting permission before testing something that’s not yours is extremely important not just from an ethical point of view but from a legal point of view as well. You might be under some liability if you don’t get the required OK.
Ideally you would get permission to test when forming the initial relationship with your supplier or third party. The contract that you have would make it explicit that you have the right to test at any time with limits to liability in the case the penetration test causes issues or outage.
It becomes harder when you haven’t covered yourself up front. You will need to ask permission before the test starts. At Volkis we have some form letters you can send across to try and make it a bit easier to get the sign-off. You’ll need to send it to the third party and get the authorised sign-off from the provider.
The scope is what you make it
That said, it sounds pretty hard tracking down the right person and getting that sign-off. Wouldn’t it be easier to just exclude it from scope? It’s not uncommon for us to be told “please test this application, but leave that part that takes critical customer data alone because we don’t have permission to include that in the test.”
When something is excluded from scope the penetration testers’ hands are tied. They can only give their recommendations to potentially add something to scope, but since they can literally get arrested if they go outside of scope they have to make sure they stay inside the boundaries at all times. We have to totally ignore the supply tree!
Unfortunately hackers that might be targeting you aren’t quite so gracious as to keep to the same scope as the penetration test. They’re not going to say “I can’t target this other company with my illegal hacking, that would make things awkward.” More likely they’re just going to go at it and target those third party systems as well. When that happens it could be your data that gets taken.
And we all know when it’s your data that’s taken then it’s you who’s on the line and blamed by your customers or clients. It’s not enough now-a-days to say “it was one of our suppliers” or “it was someone else’s fault”. You will still be judged and blamed.
I would personally recommend finding a way to make sure all systems that host your critical data or business functions are tested in some way, even those hosted in third parties. That could be by including it in the scope of your test or by requesting they have their own test and provide you the results. Incorporating this into the initial due diligence and contracting makes it even easier.
The third parties can help make the test better
Actively including third parties in your testing can make your test even better. The third parties can provide information, resources, feedback, and assistance to the testers, making testing more effective. This assistance can lead the testers to revealing more security issues and finding more ways to improve the system.
Pentests should always be a collaboration. This is often between the tester and the organisation between tested, but the more stakeholders you can bring in (even if the stakeholders don’t work for your organisation) the more visibility you’ll get, which means the more security issues you’ll uncover.
About the author
Matthew Strahan is Co-Founder and Managing Director at Volkis. He has over a decade of dedicated cyber security experience, including penetration testing, governance, compliance, incident response, technical security and risk management. You can catch him on Twitter and LinkedIn.
Photo by Martijn Baudoin on Unsplash.
If you need help with your security,
get in touch with Volkis.
Follow us on Twitter and
LinkedIn