In both white box and black box scenarios, Skoudis recommends daily briefings with the test stakeholders to let them know what the testers are doing. For example, the rules of engagement may allow the pen testers to exploit vulnerabilities, but the briefing can be used to give folks a heads up that they are about to do it.
"It builds bridges," he said. "It shows the pen testers are not a distant, evil group that is out to 'catch me.' Rather, it's all about transparency and openness."
The rules of engagement also may set limits on what may and may not be exploited, such as client machines, or techniques that may or may not be used, such as social engineering.
Tip 9: Report Findings and Measure Progress
The goal of penetration testing is to improve your security posture, so if you are conducting internal tests, your report should provide useful, actionable and specific information.
"The goal is to help improve security, for management to make decisions to improve business and help the operations team improve security," said InGuardians' Skoudis.
You should provide an executive summary, but the heart of your reporting should include detailed descriptions of the vulnerabilities you found, how you exploited them and what assets would be at risk if a real attack took place. Detail every step used to penetrate, each vulnerability that had to be exploited, and, most important, perhaps, all the attack paths.
"The beauty of identifying the attack path is that it allows you to solve specific problems by breaking the path," said Core Security's Solino.
Be very specific about recommendations. If architectural changes are required, include diagrams. Explain how to verify that a fix is in place (use this command, or that tool to measure). In cases where multiple systems are involved, explain how to mass deploy a fix, using GPOs if possible.
Make sure that each recommended remediation includes a caveat that the solution is thoroughly tested before it is implemented in a production environment. Enterprise IT infrastructure may be very complex.
"This is a huge issue," said Skoudis. "You don't know all the subtleties. You don't want to break production."
Penetration testing should not be a one-time exercise, and successive results should be compared. If you are performing internal testing, put together deltas to measure how your people are addressing issues. If the problems from the last test--or the last two--remain unaddressed, you may have a problem. Perhaps the software patching program isn't working as it should, or developers are not being properly trained to write secure code.