Tip

Corporate penetration testing: Best practices for thorough assessments

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

    Requires Free Membership to View

corporate penetration testing budget.

There are two broad areas where organizations can ensure they maximize the potential benefits of penetration testing:

  1. Logistics; and
  2. 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?

  1. 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.

     

  2. 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.

     

  3. 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.

     

  4. 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.

     

  5. 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.

     

  6. 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. 

Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in October 2010

 

COMMENTS powered by Disqus  //  Commenting policy

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.