-
IPv6 Neighbor Cache Exhaustion Attacks – Risk Assessment & Mitigation Strategies, Part 1 →
-
Mailvelope Penetration Test Report (PDF) →
-
Blog, Ideas for a report writing competition →
-
Security-assessment.com Kiosk Review Penetration Test Report →
You want something real to read… this is definitely worth a look!
-
Restoration of defocused and blurred images →
Maybe useful… certainly for those that blurr stuff in reports ;)
-
Getting your message across: Screenshots →
A quick post I drew up on screenshots… and how not to abuse them!
-
A few example reports
To expand on the previously shared “offensive security” example report, I had a search for some other example reports that have been shared online over the years. Some are a little outdated, but we’ll just call them “classic” as regardless of date, there are some good points we can take from them.
- NII Consulting (report PDF)
Although this example report was created back in 2005 (it seems) I like the way the Web Application Vulnerabilities are communicated (page 16). I would have liked to have seen more detail on each issue however… Still, the matrix like list gives the reader the ability to easily see what the issues are and what the recommended fix is.
- FooBar Security Inc (report PDF)
Again, and older report (2004). The format is a little sparse for my tastes and the lack of colour makes for bland reading. It’s also hard to see where the real issues are due to lack of risk ratings.
Personally I would avoid using the appendix for listing tool output unless it adds to the findings or is needed to clear up any questions (proof of exploit?). I would also stay clear of listing usernames and passwords in a report unless it was specifically required by a client. Simply showing proof that they could be broken and that they were insecurely stored/generated is usually enough. If you need more, stats on length, complexity is probably a good middle point.
- Cynergi Solutions (report PDF)
I’m not really sure about the 3D effect and cover art on this one, then again, that’s a personal choice really. Over half of the report is made up of charts it seems. Although some of the network layouts (zenmap output?) are interesting, if a little inaccurate probably, the number of charts is a little over the top IMHO.
Again, the layout on page 25 is easy to read and see where the issues are (similar to the previous report discussed). I particularly like the addition of the “fix” column that has keywords on what the fix entails (involved, quick, planned, …). This allows customers to get in the quick wins that don’t need much work.
- Fireworks (report PDF)
This report has a good mix, not too many charts etc… but it lacks some of the useful tables found in the other reports. Without the ability to quickly see where the issues are, the report lends itself to more technical readers. The technical summary is brief and contains more info about the way the test was run than anything else.
In the technical report section there’s good use of graphics to explain the issues, but a lack of screenshots in some findings. I know there’s a fine line between too many and not enough, but I feel that some of the findings could be better explained with the addition of a screenshot.
Note: These are just my quick thoughts on these example reports… I encourage you to take a look and tell me what you think are the good and bad points!
-
SANS Reading Room - Writing a Penetration Testing Report →
2010 SANS reading room document on writing Penetration Testing reports —> http://www.sans.org/reading_room/whitepapers/bestprac/writing-penetration-testing-report_33343
This includes a simple example report at the end. Although the use of a simple Critical, High, Medium, Low risk rating is used, I think there are some points that can be taken from this example.
I especially like the attention to detail in the “Document Properties” section, and the addition of the Version Control. These are often overlooked, but are important, especially when working with a customer across multiple versions of a report. The easy to understand methodology (even if it’s not the one you choose) is a good example of displaying information in a simple to read fashion.
I’m not overly happy with some of the blunt remarks in the “Summary of Findings” however. Comments such as “GPEN.KM needs to pay more attention to information security” when put to a real customer are not likely to get you asked back for a retest, even if it is true! Add in “ It was obvious that GPEN.KM patch management policy and procedure is either not existing or not implemented correctl” and a lot of companies will stop reading. The customer wants to hear your findings, and not read sarcastic or rude comments.. even if they were not meant in that way.
What are you thoughts? How can we make this report better? What can we take from it and use in a perfect report template?
-
Penetration Testing - Reporting and Analysis: Being a Tester, Not Just Another Hacker →
Mike Murray is running this course at CanSecWest next week… looking forward to hearing feedback and getting comments from some of the attendees!
-
Reporting: The Difference Between Good and Great Penetration Testers | The Hacker Academy →
I’ve not had a chance to run through the whole webcast myself, but thanks to @jason_wood for sharing! Please leave feedback and comments if you find the content useful or not… Good and bad points!
