Home page logo

pen-test logo Penetration Testing mailing list archives

RE: Reporting aspect of pen-testing
From: "Brewis, Mark" <mark.brewis () eds com>
Date: Tue, 2 Dec 2003 11:09:30 -0000


Over time (and I appreciate that you don't have that luxury,) you develop
your own style in reporting.  There is no one report template that fits all
jobs.  What you do have though, as other posters have pointed out, is a
basic structure, which is some variation on:

- Executive Summary
- Scope
- Detailed Reporting
- Risk Assessment
- Conclusions and Recommendations
- Technical Annexes and Appendices

If you think of the Executive Summary as a separate document that can be
taken off the front of your report and distributed separately, you won't go

Scope - what when why how and why not.

Detailed Reporting and Risk Assessment needn't be separate sections.

Recommendations can range from the highly detailed to the generic - it very
much depends on what the client wants.

Annexes and Appendices can include your evidence, tool output, advisories,
patch status lists etc.  Again, this depends on the job and the client.

The important part for the client is (generally) the Risk Assessment (as an
extrapolation of findings.)  The question you are answering is "What does
what you have found mean for me?"

The reporting of an assessment of risk is a complex process.  The technical
side (the severity of a vulnerability) is easy enough to assess, but
modelling that within the client environment can be a remarkably difficult
task.  You don't know their business as well as your client does.  All you
can really do is assist them in making their own conclusions on risk for
their environment, by presenting your findings clearly, and in a context
they can understand.

There is a huge amount of information out there on risk - some of it is too
simplistic, other papers and models are too complex or academic to use on a
daily basis.  Finding one that you are comfortable with, and learning how to
interpret technical results to fit the model, takes time.

A good starting point is:

NIST Risk Management Guide for Information Technology Systems,
Recommendations of the National Institute of Standards and Technology,
Special Publication 800-30: Gary Stoneburner, Alice Goguen, and Alexis


This is a concise, model, with an easy to understand matrix.

Hope this helps,

Good Luck with the Masters,

Mark Brewis

Security Consultant
Information Assurance Group
Wavendon Tower
Milton Keynes
MK17 8LX.

Tel:    +44 (0)1908 28 4013
Mbl:  +44 (0)7989 291 648
Fax:    +44 (0)1908 28 4393
E@:     mark.brewis () eds com

This email is confidential and intended solely for the use of the
individual(s) to whom it is addressed. Any views or opinions presented are
solely those of the author.  If you are not the intended recipient, be
advised that you have received this email in error and that any use,
dissemination, forwarding, printing, or copying of this mail is strictly

Precautions have been taken to minimise the risk of transmitting software
viruses, but you must carry out your own virus checks on any attachment to
this message. No liability can be accepted for any loss or damage caused by
software viruses.


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]