If you integrate or depend upon on a third party, you should ensure that the service they provide is secure, and a common way to do this is with at least an annual Pen Test to confirm that the web service has a basic level of security.

I say basic quite deliberately, as a Pen Test in of itself says nothing about:

• The security awareness, expertise and background of those in the business whose web service you are scanning;
• The internal security testing policies, procedures and controls.
• What occurs ‘behind the scenes’ and if that is secure, for instance batch processing, feeds processing, file transfer, backup & archiving, etc

In fact, a Pen Test often says very little about the real security of the web site under test – yes a serious failure indicates something is wrong; but a pass is no guarantee of absolute security, it just means what was scanned was found to be secure. The trouble is, you can only scan for what you know to be exploits against what you think is the way the web site is set up. It may be the web site is configured in a way that comes across with a clean bill of health via a Pen Test, yet under human examination and deduction, something nasty is found – this wouldn’t be the first time!

If you do decide to Pen Test a 3rd Party, there are some simple rules you must follow.

Rule#1 – Never test against production!

I cannot state this strongly enough; running a Pen Test against anybodies live production instance is just crazy and unprofessional. For several reasons:

• It’s highly likely that the production instance has controls in place to defeat Pen Tests directly – so they never get the chance to do an actual scan, they get denied within seconds.
• Pen Tests are known to be resource-intensive, they often fire off many requests a second as they explore and probe the website looking for vulnerabilities. This could on its own overload a web service or severely degrade the usability of web service of other customers.
• Even if you able to scan slowly, this is no guarantee that harm will not be done; for instance, a Pen test scan quite often looks for buffer overflows and server-side execution vulnerabilities; this could cause the web server itself to crash, or the web server could be taken down as a protection measure. It could even cause data integrity issues. Remember both the Pen test suite and the service under test are software written by humans, and humans make lots of mistakes!

There is even the question of timing, your Pen Test run on its own might not be that dangerous, but what happens if that co-incidences with somebody else doing a Pen Test? Or with someone doing a large file upload or end of month report run?

There is also the problem for the security team looking after the web service, how do they know which is a customer-driven Pen Test or a hacker using a Pen Test tool to find a way in to hack the service? Note: This is also a problem for the IaaS provider, how do they know your traffic is not that of a hacker?

If you must run a Pen Test, arrange with the service provider to use a dedicated Pen Test instance specifically for the task – this way there is no risk of damaging the production service.

Rule#2 – Always get permission first!

I cannot stress this enough, running a Pen Test across a web service which you do not own and operate without prior permission is a Federal Offence in Australia and most other countries around the world. You could end up getting arrested and having a terrible ‘please explain’ time with the Police and the web service operator. You could well end up with a criminal record. How do they know what you did was not malicious or could endanger the viability of service?

This is serious for a reason, as it enforces a clear distinction between what is done with prior permission (legal) and what cannot be done without it (illegal).

This even applies if you use a hosted Pen Testing service to scan a 3rd party; its you using the tool and they often have in the small print ‘only test what you own’ (or words to that effect). Buyer beware!

This is why proper Pen Test providers always require a ‘get out of jail free card’ from the customer saying they have prior permission to scan their sites.

In short, if you do not have prior permission from the web service operator – you cannot scan!