From: Anders Thulin (Anders.Thulin@kiconsulting.se)
Date: Mon Dec 01 2003 - 02:45:04 EST
TJ O'Grady wrote:
> 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.
A pen-test is rarely done in a vacuum: it's done for a reason, and
that reason is the basis for the documentation. It could be that
someone's getting worried. It could be that there's been major
restructuring in the network, and that a check is needed that security
hasn't dropped because of that. It could be that a competitor has
pen-tested the network, couldn't find a thing, and management for some
reason would like to have a second opinion. Or it could be that
*you* are being tested as a pen-tester, but on the other hand you're
not likely to be told about that.
The typical outcome of a pen-test is an activity to correct all
found problems. This, of course, partly misses the point, but you
might as well get used to it. So you need to identify the actual
problems sufficiently well that the correction is clear to the
person or persons who will have to do something about them. Never
document hypothetical problems unless you feel very, very sure you
could have exploited them. Pen-testing is catch-the-flag. Merely
seeing a flag is not really enough.
If you feel optimistic, you can also try to point out that some
problems are there because they were allowed to be so: there's
probably some problem in procedures, policy or architecture.
Another typical result is that your customer wants to tell his
management about what he did -- and you will need to provide if not
the final text, at least something that is close enough for that
kind of communication. But don't forget that the technical contents
of a pen-test usually is secret.
And, depending on what kind of organization you're dealing with,
you might want to let them know what they can do on their own.
If you rely on open-source or freeware tools, I think it's a good
idea to document them somewhere. It makes it clearer that anyone
with these tools could be a threat -- not that only someone equipped
with the latest Acme Pen-testing Tool 9.5 is one.
You will also need to know what a pen-test is, and how it differs
from other types of security testing. Someone is bound to ask why
you didn't do this, didn't do that, didn't use MBSA, didn't look
over *all* systems for missing patches, etc. You may need to
describe just what a pen-test does somewhere.
Of course, what you think of as a security breach may not
necessesarily be one, and it may be that something you only vaguely
noticed but couldn't find any use for is a major disaster. (Wasn't
there a bit of a flap some years ago because a .MIL host that was
supposed to be visible only to other .MIL systems turned out to be
visible to the rest of the net as well?) However, you'll only be
able to analyze that kind of things if the organization you're
pen-testing already have useful policies in place, and can evaluate
threats usefully.
Raw data ... it depends. If it didn't bag you access, there's
seldom any need to document it -- if you didn't catch the flag,
you're not successful, and it's not until you do return with a
flag that it becomes interesting just how you did it. Unless,
of course, you're doing the job for highly security-conscious
people. But then, you'd know about that from the start.
-- Anders Thulin anders.thulin@kiconsulting.se 040-661 50 63 Ki Consulting AB, Box 85, SE-201 20 Malmö, Sweden --------------------------------------------------------------------------- ----------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:53:43 EDT