Requesting a Penetration Test

Friday, March 22, 2002
Many companies these days look to penetration testing ( also sometimes termed ethical hacking ) to evaluate their level of exposure and risk of attack. While the idea and approach are good and sound, some factors need to be taken into account when requesting such a test. This paper offers advice to organisations planning on requesting such a penetration test.

I've performed a number of penetration tests against companies myself, and I've also been a system administrator for systems which have been subject to penetration tests. What follows comes from practical experience, and has useful lessons that were learned the hard way.

Define the scope of the test
Define the exact scope of the penetration test - explicitly, and in writing. If the test involves your Internet connection ( as most penetration tests do ), then explicitly state which network addresses are to be tested, which web servers, which mail systems and so on. Also define which systems you do not want tested. Candidates for exclusion could be :

  • Important production systems
  • Systems belonging to customers
  • Remote access systems - modems, VPN devices, etc
You may also want to exclude some types of tests, such as Denial of Service ( DoS ) tests, and war-dialing tests which call a number of phone lines looking for modems. These tests are very likely to be disruptive to normal operations.

Discouraging conflicts of interest
This can be a difficult area. I've found that many penetration tests are performed on the basis that the people performing the test will also be called in to perform remedial work to fix the problems. This can lead to security problems and vulnerabilities being blown out of proportion by the testers in order to "win" the remedial work. If possible, you should avoid this by stating to the testers from the the very beginning that they will not be performing any remedial work following on from the testing. You can, if you like, use the testers to re-check the systems after remedial work has been carried out.

Define the amount of effort
A lot of time (and money) can be spent in performing penetration testing - from a minimum of about 1 week up to many weeks, or even months. Define just how much effort you want, if not just to put a cap on how much the testing will cost you.

Maintain contact details
Clearly document contact details for your organisation to contact the people performing the test. Also give the penetration-testers contact details for the system administrators and managers responsible for the systems that they are testing. Quite often penetration tests can cause system outages and peculiar errors - it is important that these are identified and resolved quickly and that the system owners can call an immediate stop to the testing. It is also necessary to be aware that there could be a real penetration taking place at the same time as testing, and the system administrators need to know the difference between the two.

Also make sure that the testers provide you with the network address of the systems which will be performing the test.

Define the exact dates and times of the test window
Agree with the testers the exact dates and times during which the testing will take place, and make sure that no testing will be performed outside these times. The times can be during business hours if you want to make sure that the support team is one the job and ready to resolve any problems, or it could be out of hours to avoid disrupting business traffic. I've never had a definitive answer as to which time is best so its up to the people managing the systems to decide.

Define the objectives of the test
It is always a good idea to define what you want to get out of the test. Do you really want the testers to find a hole on your systems? - or do you just want to get a broad evaluation of how secure your systems are? Do you want a simple list of where the holes are? Do you want a more complete risk assessment that you can show to management?

Reporting
Reporting must be the most important area of penetration testing. At the end of testing, the testers should compile and submit a report of their findings. The report should include the following sections :

  • Vulnerabilities found ( in a risk-priority ordering )
  • A risk analysis and severity rating for the vulnerabilities found
  • Recommendations for remedial action
  • Detailed results from scanning tests - such as log files, data files, and other information which was collected
If you have penetration tests performed on a regular basis, then changes in the vulnerability landscape should be highlighted by comparing test results against previous test results. The aim of this is to examine how vulnerabilities can creep into systems and to make every effort to stop them being implemented in the future.

Remember, that security is an ongoing process. The penetration test and subsequent risk assessment will give you a quick and rough estimate of where your risks are - but it is not a full audit and it is only a snapshot of the system taken at the time of testing. It is easy for new vulnerabilities to arise during the lifetime of computer systems, and it is always important to employ good practices for security in managing information systems.


Penetration Testing References:
Some highly recommended reading.