Penetration Testing mailing list archives
RE: Reporting aspect of pen-testing
From: "Cotter, Joe" <jcotter () everestusa com>
Date: Fri, 12 Dec 2003 08:37:36 -0600
TJ, I'm a little late to the conversation - so forgive me. However, I agree with what everyone else has said so far about the reporting aspects. I've seen this while talking to my customers MANY times. There are quite a few companies that are very good at penetration testing, but cannot effectively verbalize how they did what they did and what the customer can do to fix it. So the customer ends up looking at and trying to decipher a highly technical report - that is almost always generated by the vulnerability tool in use by the security consultant. I like to think that this is one of the main reasons my company completed over 30 security assessments in the last year. We put the "human touch" into the report by going over the information and putting it into simpler terms that management can understand. This bundled with the raw data collected is enough to satisfy all the parties at most companies. I think this aspect is one of the single largest reasons why security consultants do not get asked to return. The work may be fantastic, but if no one can understand the deliverable - it has no meaning to the customer. Typically, we layout reports thusly: *Introduction *Overview - why they need an assessment *Scope of Assessment *Goals of Assessment *Security Assessment Approach *System Characterization - what we discovered about the network in broad strokes. *Threat Statement - Threat cataegories, levels and the explanation of NIST sp800-30 and how we use the conventions of that standard in our document. *Assessment Results - Plain English explanations of everything uncovered. *External *Internal *Final Results & Recommendations - Summary *Report Card & Task List - I resisted using a "letter grade" for as long as I could - but discovered that it greatly eased the understanding of my report. Letter grades are subjective, so I take great pains to explain the hows and whys. I have developed a formula for "scoring" the vulnerability of a machine based around a ton of factors and I also include this in the report. And finally I include a task list for the IS/IT staff so that they immediately see what the priority action items are and know what to fix to improve. Hope this helps! -Joe -----Original Message----- From: TJ O'Grady [mailto:tjogrady () flyingwithouta net] Sent: Sunday, November 30, 2003 7:08 AM To: pen-test () securityfocus com Subject: Reporting aspect of pen-testing Hi folks, I am putting together a pen testing proposal as part of my final Master's project. If it's good enough, it will lead to a full pen test of a real network. This list has been very helpful with the technology background, but the part I am stuck on right now is the reporting piece. When a pen-test is complete, what do you include in the report? How do you structure the information for business contacts, I imagine raw data is often not helpful in many cases. Any hints or tips would be greatly appreciated. Thank you, TJ ------------------------------------------------------------------------ --- ------------------------------------------------------------------------ ---- --------------------------------------------------------------------------- ----------------------------------------------------------------------------
Current thread:
- Re: Reporting aspect of pen-testing riptide (Dec 01)
- <Possible follow-ups>
- Re: Reporting aspect of pen-testing Stephen de Vries (Dec 01)
- Re: Reporting aspect of pen-testing Anders Thulin (Dec 01)
- Re: Reporting aspect of pen-testing Carlos Eduardo Pinheiro (Dec 01)
- Re: Reporting aspect of pen-testing Ivan Arce (Dec 03)
- RE: Reporting aspect of pen-testing Brewis, Mark (Dec 03)
- RE: Reporting aspect of pen-testing Cotter, Joe (Dec 12)