Penetration Testing mailing list archives
Re: Reporting aspect of pen-testing
From: Anders Thulin <Anders.Thulin () kiconsulting se>
Date: Mon, 01 Dec 2003 08:45:04 +0100
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 --------------------------------------------------------------------------- ----------------------------------------------------------------------------
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)