IT security managers are under constant pressure to both demonstrate the effectiveness of their investment in security and how to get more value from their security budget.
With more than 22 years of experience in providing independent security penetration testing services to a wide range of public and private sector clients, we have compiled for you - 7 tips that organisations can ensure that they maximise the benefits of penetration testing:
Tip #1: ELIMINATE COMMON VULNERABILITIES BEFORE THE TEST.
Eliminating common vulnerabilities allows time for testers to concentrate on more complex vulnerabilities and more advanced attack techniques, providing much greater insight into the security of the system under test.
Tip #2: AVOID ENGAGING YOUR PENETRATION TEST PROFESSIONAL AT THE VERY LAST MINUTE.
It is common for potential clients to phone up and ask: "Can you test my system next week? It needs to go live by the following Monday." Aside from the possibility that your testers 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 themselves time to fix and retest any issues that the testers might discover.
Penetration tests will 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. Do it right...the first time.
Tip #3: PROVIDE ADEQUATE SYSTEM DOCUMENTATION THAT REFLECTS THE 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 Windows experts should test Windows, etc.). While this is a minimal issue with remote testing , it can be a major problem when a testing team must travel to an on-site deployment. Not getting this right, might cause unnecessary cost creep or time and resource mis-allocation on the testers' end.
Tip #4: TEST ONLY WHEN YOU ARE READY.
Clients will get a more thorough and authoritative result 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 ready-to-deploy 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.
Tip #5: ALLOW ACCESS TO YOUR THIRD PARTY WEB APPLICATION DEVELOPERS.
When testing Web applications, clients 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. In any case, the client can always request to be kept in all the communciation loop between the testers and developers.
Tip #6: HARDEN YOUR SYSTEMS PRIOR TO A PENETRATION TEST.
There are plenty of best practices out there regarding how to harden systems. If clients haven't applied these 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 should have implemented in the first place. This wastes both time and money.
Tip #7: FIX PREVIOUS VULNERABILITIES BEFORE A RETEST.
While this 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? By taking the effort to do so prior to a retest; that way, if the same issues are discovered, it will be because either the fix wasn't applied correctly or didn't work as intended.
To find out more on how we can help you carry out a Penetration Testing exercise check out this page.