How to do penetration testing: Overcoming problems and concerns

Penetration testing is by no means an exact science. Each test tends to be unique, and numerous problems -- server outages, application availability problems, user account lockout and others -- can occur due to the nature of the tests themselves. Equally common are process and political challenges, which may result from lack of proper communication or coordination between solution providers and organizations.

This tip will discuss how to do penetration testing, covering some of the most common issues that arise during pen tests, and providing guidance on how best to overcome them.

Technical issues
Security solution providers, even including the top penetration testing companies, face a number of technical issues when conducting pen tests. By far, the most common technical issue is system or application unavailability, which may be caused by overwhelming network traffic from scanning tools like Nmap and Nessus, or by application-specific testing tools like HP WebInspect or IBM AppScan. 

After flaws in systems and applications are found, and the final report has been delivered, the organization being tested
may dismiss the findings
as less critical than the solution provider rates them.

In the first case, the network team will likely notice the volume of traffic, and the fix will be straightforward: Throttle back the scanning speed to an acceptable level for the network being tested. In the latter case, the lack of availability will likely be due to a specific application flaw, where application forms or other input acceptance channels are being bombarded with somewhat malicious data. To resolve this, in many cases, the solution provider and the application owners must review log files and discuss what went wrong. Usually the problem is obvious, and the testers can exclude specific testing types or avoid particular pages in the application during the remainder of the test. Meanwhile, the application flaw should be noted in the final report.

Another type of availability issue that can occur during pen testing concerns user account lockout, often caused by solution providers attempting to log in to authentication interfaces rapidly with “brute force” logins. If this happens, there are three possible ways to resolve the issue:

• Remove authentication brute force attempts from the scope of the test.
• Throttle, or limit, the frequency of login attempts with automated tools.
• Have the organization remove or change the user account lockout policy setting for the duration of the test.

Other technical problems may arise from the use of specific exploit code that renders services unavailable or systems unstable. When this happens in a production environment, the solution is to avoid the use of these specific exploit types for the duration of the test, although the vulnerability should be noted in the final report. To allay concerns around any of these technical issues, solution providers should discuss the possibility that services may become unavailable and systems may become unstable during the initial scoping phase, and ensure all involved stakeholders understand the inherent risks of ethical hacking activities.

Managerial issues
Many problems that occur during pen tests are more managerial or political in nature. One common issue is a lack of communication between the security team requesting the test, and the business or application owners in other parts of the organization. In many cases, the business unit finds out about the test after it has already started, or worse, when technical issues occur. This can cause significant political turmoil, and will usually delay the project. The best way to handle this issue proactively is by pointedly asking whether all stakeholders are involved at the onset of the engagement. Doing this, however, provides no guarantee all stakeholders are on board.

Another common experience solution providers will encounter relates to the delivery of findings. After flaws in systems and applications are found, and the final report has been delivered, the organization being tested may dismiss the findings as less critical than the solution provider rates them. Unfortunately, this is a risk decision that can only be made internally by the customer, and the solution provider is not accountable for this. As long as the findings are valid technically (and the solution provider has vetted them appropriately to remove false positives), under no circumstances should the testing results be changed or reduced in severity solely to “save face” or smooth political or compliance concerns internally at the organization. This represents a common ethical dilemma faced by pen testers, and it is important to uphold the highest integrity standards at all times.

These are the most common issues likely to be experienced during pen tests. Being aware of the issues in advance, and having a plan for how to handle them, will make pen tests much smoother for both solution providers and their customers.

About the author:
Dave Shackleford is the founder and principal consultant with Voodoo Security, as well as a SANS analyst, instructor, and course author and GIAC technical director. He has consulted with hundreds of organizations in the areas of security, regulatory compliance, and network architecture and engineering. He is a VMware vExpert and has extensive experience designing and configuring secure virtualized infrastructures. He has previously worked as CSO for Configuresoft, CTO for the Center for Internet Security, and as a security architect, analyst, and manager for several Fortune 500 companies. Dave is the co-author of Hands-On Information Security from Course Technology as well as the "Managing Incident Response" chapter in the Course Technology book Readings and Cases in the Management of Information Security. Recently, Dave co-authored the first published course on virtualization security for the SANS Institute. Dave currently serves on the board of directors at the Technology Association of Georgia's Information Security Society and the SANS Technology Institute.

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.