To blatantly steal an idea from one of my long time cohorts, Steve, I want to cover what things you should do with your penetration test reports after they have been delivered to you. These things should be done whether you get your tests from us or someone else. I generally hate “Top 10” lists so I’ve condensed mine down to five. Here we go:

5. Have a “closing” meeting to go over the results.

This is important as no metric or severity rating in the world tells you what was in the mind of the testers when they discovered a given exploit. I put this at number 5 because not only do I really hate meetings, but this has been one of the more effective instruments I’ve had when dealing with the fallout from a given test. Once we even did a three day course demonstrating the sorts of things we found and how they can be better defended against. Both methods work well when trying to discover the “what next” that should logically follow from the testing.

4. Categorize the exploits.

What is important to your organization is NOT important to others. You may find that an exploit in the .NET framework is of critical importance, while someone else may be wondering what on earth a Windows server is doing running on their network. Both are equally valid concerns, but may have different paths to remediation. Don’t try to make a penetration tester understand the intricacies of your business that’s your job. It’s often better to have someone who does not have that insider view looking at things because they will offer a more unique perspective than someone who lives it.

3. Work with your administrators and developers to build a remediation plan, then execute that plan.

One of the most frustrating things we see in our recurring penetration tests are problems that continue to exist from cycle to cycle. An FTP service that shouldn’t be there just remains running as an example. It’s a relatively simple thing to fix - just shut off the service - but all manner of excuses apply. If you don’t have the time to remediate it then outsource it. (Full disclosure: We offer remediation services as well). Most customers have plans in place to remediate the higher severity items but the lower ones are allowed to exist as lesser priorities. If I could yell this I would, but this is in print form: Sometimes lower risks can become much higher risks if circumstances change. You really should work through all things in a report and not just focus on the higher criticality ones, it’s just good mojo.

2. Test now, test later, keep on testing.

A lot of regulations call for quarterly tests as a precaution. I say that quarterly tests can allow months to go by before the good guys discover a problem and it can get fixed. I am and have been for quite a while a proponent of a more continuous testing cycle. Not because it makes me more money, but because it makes common sense. If you don’t subscribe to the “Billford Plan of Continuous Testing”, then at least make sure you allow for a re-test of the assets after your remediation is complete. This will help to make sure the remediation was successful and will make your auditors shiver with delight.

1. This is the most important and a great part of one of my favorite writer’s masterpieces, DON’T PANIC!

A penetration test is meant to be preemptive and not threaten anyone. It’s meant to identify trouble spots before they become trouble. It shouldn’t be used as a blunt instrument but instead be more like Steve said: It should be a learning experience. Too many times we see folks panic about what we might find or about what we found. There is sometimes so much panic, that the fact we found out before any bad guys did is forgotten. We need to rise above that and calmly deal with the situation so we don’t worry ourselves into a worse mess. We need to learn the lessons these tests show us and apply them throughout our network. Your life will be happier for it.