RE: Reporting aspect of pen-testing

From: Brewis, Mark (
Date: 12/02/03

  • Next message: "pptp brute force"
    To: "'TJ O'Grady'" <>,
    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

    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.


  • Next message: "pptp brute force"

    Relevant Pages