From: Cotter, Joe (jcotter@everestusa.com)
Date: Fri Dec 12 2003 - 09:37:36 EST
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
------------------------------------------------------------------------
--- ------------------------------------------------------------------------ ---- --------------------------------------------------------------------------- ----------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:53:44 EDT