Most security professionals are under pressure both to demonstrate value for the money they invest in security and to get more from their security budget. From my experience in providing independent security penetration testing services to a wide range of public and private sector clients, organisations could often get better value from their
There are two broad areas where organizations can ensure they maximize the potential benefits of penetration testing:
- Logistics; and
- Eliminating common vulnerabilities prior to the test.
Whilst the first area may seem obvious to those reading this article, it is surprising how much of the effort available to perform a security penetration test can be wasted by the client not being fully prepared for the test. Eliminating common vulnerabilities allows time for experts to concentrate on more complex vulnerabilities and more advanced attack techniques, providing much greater insight into the security of the system under test. This article offers penetration testing best practices regarding the issues that can easily be sorted out prior to a test, so that more effort is spent actually testing the systems. (The next tip will detail the common network and application vulnerabilities that we repeatedly find that could be easily fixed before a penetration test.)
So what are the common logistical problems?
Engaging at the last minute
Potential clients will frequently phone up and ask: "Can you test my system next week? It needs to go live by Friday." Notwithstanding the possibility that a firm might not have the resources to do a penetration test at such short notice, the real problem for the client is that they have not allowed time to fix and retest any issues that we might find. Penetration tests always find some security issues: It is better to plan time to fix and retest rather than assume that nothing will be found. The time required to fix the system will depend on its complexity and the number and nature of the issues found; worst-case scenario, plan on the retest taking the same amount of time as the initial test.
Not providing system documentation that reflects reality during scoping
The testing plan and the resources required for the test will have been put together on the basis of a scope agreed upon with the client that includes a description of the systems and networks under test. If that plan is incorrect, insufficient resources may have been allocated to the test, or even people with the wrong skills assigned to the work (i.e. only Linux experts should test Linux, etc.). This is a minimal issue with remote testing , but can be a major problem when a testing team must travel to an on-site deployment.
Fixing things during the test
There are some occasions when this must be done. However, organisations will get more thorough and authoritative results if a stable build is tested wherein aspects of the system are not constantly changing . If changes have to be made on the fly, then there should be an agreed upon way of making them and communicating them back to the testing team.
If, when testing a live system, testers find a major security hole, they should inform the client straight away. In that event, standard procedure is usually to stop the test so the client can fix the vulnerability as soon as possible.
Not allowing direct access to the developers of third-party Web applications
When testing Web applications, organisations will get much more value if the testers can talk directly to the developers of the application to discuss the issues found and the potential fixes. If direct communication is not allowed, it is difficult to engage in a detailed dialogue, often resulting in misunderstandings regarding the changes required to fix an issue or increases in the time required to fully assess a vulnerability and its effects.
Using a penetration test to demonstrate how to harden a system rather than applying security best practices to start with
There are plenty of best practices out there regarding how to harden systems. If organisations haven't applied system hardening techniques prior to a penetration test, testers will discover many more vulnerabilities, increasing the cost of the testing, and give advice that the technical team should already know and have implemented. This wastes both time and money.
- Not having fixed the previous vulnerabilities before a retest
This last point may seem obvious, but it's surprising how often, when retesting a client's system, testers find vulnerabilities identified in a previous test that have not been fixed. Why bother having a penetration test if you are not going to address the issues found? Make the good faith effort to do so prior to a retest; that way, if the same issues are discovered, it will be because the fix wasn't applied correctly or didn't work as intended.
Addressing these logistical issues prior to working with a penetration testing firm can increase the quality of the test's results and provide a greater return on investment. It's worth taking the time to do so.
About the author:
Neil O'Connor is a principal consultant at Activity Information Management Ltd. in Farnborough.
This was first published in October 2010