.

pen test documentation

<<

tturner

User avatar

Sr. Member
Sr. Member

Posts: 435

Joined: Thu Jun 26, 2008 4:50 pm

Post Fri Aug 10, 2012 12:17 am

Re: pen test documentation

Most of the time it's just not necessary. What does it add to the report? If anything, it shows laziness. There may be situations where you need a short snippet of output to help you tell your story but for the most part no it should not be in the report.
Certifications:
CISSP, CISA, GPEN, GWAPT, GAWN, GCIA, GCIH, GSEC, GSSP-JAVA, OPSE, CSWAE, CSTP, VCP

WIP: Vendor WAF stuff

http://sentinel24.com/blog @tonylturner http://bsidesorlando.org
<<

Jamie.R

User avatar

Sr. Member
Sr. Member

Posts: 435

Joined: Mon Aug 06, 2012 9:57 am

Location: UK

Post Fri Aug 10, 2012 4:58 am

Re: pen test documentation

Yes I agree dont add stuff that it not helpful to a client giving them a reprot of 450 pages you may think you show value for money but if the contents is not help it come back to bite you
| OSWP | eCPPT Silver and Gold | eWPT |

I'm an InterN0T'er
<<

cyber.spirit

User avatar

Sr. Member
Sr. Member

Posts: 356

Joined: Sun Feb 26, 2012 8:07 am

Location: in your heart!

Post Fri Aug 10, 2012 5:33 am

Re: pen test documentation

ok so without those detail we just need to put a story about server's vulns lol
ICS Academy Network Security Certified
<<

tturner

User avatar

Sr. Member
Sr. Member

Posts: 435

Joined: Thu Jun 26, 2008 4:50 pm

Post Fri Aug 10, 2012 10:23 am

Re: pen test documentation

What I do is I redirect all my tool output to text files and move those into an encrypted archive I retain with the report. We also require full packet capture with a filter set for anything in target scope + tester machine(s). It's mostly a training aid for IR purposes and IPS/SIEM tuning than anything else. So yes, we are retaining a lot of other data with the report, but the key is, not IN the report.

And yes cyber.spirit, we are telling a story. Usually the story the client wants us to tell as long as the data supports it.
Last edited by tturner on Fri Aug 10, 2012 12:58 pm, edited 1 time in total.
Certifications:
CISSP, CISA, GPEN, GWAPT, GAWN, GCIA, GCIH, GSEC, GSSP-JAVA, OPSE, CSWAE, CSTP, VCP

WIP: Vendor WAF stuff

http://sentinel24.com/blog @tonylturner http://bsidesorlando.org
<<

sh4d0wmanPP

Newbie
Newbie

Posts: 42

Joined: Sat Aug 11, 2012 6:42 am

Post Tue Aug 14, 2012 9:20 am

Re: pen test documentation

Creating a good report is one of the hardest things to do so here is the format I use.

Executive Summary: Introduction, Summary of Results, Summary of Recommendation, Conclusion
This part I try to write as clear as possible avoiding most tech speak. I try to add some pictures or graphs that help to explain the issues found and recommended mitigations.

Project Scope, Rules of Engagement and Methodology
General information about what is and is not allowed + overview of the system/ip's we did use to conduct our audit.

Technical Attack Narrative
This is written for the tech guys and details any attack we carried out (succes AND failure). Discovery/enumeration is kept basic.

Vulnerability Mitigation Techniques
Here we calculate the risk of each vulnerability and they ways it could be mitigated. By calculating the risk we help the company to prioritize the fixes.

Appendix A - Toolkit
This lists all tools we have used in the audit.

Appendix B - Cleanup
This lists all files that were created and deleted during the test.

I like to have a video record of my tests and archive them offsite together with a digital copy of the report (encrypted of course). This way we can always show proof of what we have done in case the customer claims any damage or misconduct.
EXIN ISO/IEC 27002: ISF & ISMAS, ITIL Foundation, Comptia Security+, CCNA, CCNA Security, Wip: OSWP
<<

Jamie.R

User avatar

Sr. Member
Sr. Member

Posts: 435

Joined: Mon Aug 06, 2012 9:57 am

Location: UK

Post Tue Aug 14, 2012 9:31 am

Re: pen test documentation

hmm thats intresting a video of what you doing does the client mind you doing that ? Also be intresting to know what software you use ?
| OSWP | eCPPT Silver and Gold | eWPT |

I'm an InterN0T'er
<<

sh4d0wmanPP

Newbie
Newbie

Posts: 42

Joined: Sat Aug 11, 2012 6:42 am

Post Wed Aug 15, 2012 9:33 am

Re: pen test documentation

I use Camtasia Studio for this as I run most audits of my Windows box (I have backtrack in VM or just use a SSH connection).

The client does not mind it but of course I have to store it securely and can not disclose it without their approval. Nothing beats a live demo but a recorded video also makes a lasting impression if it is a spectacular hack ;)
EXIN ISO/IEC 27002: ISF & ISMAS, ITIL Foundation, Comptia Security+, CCNA, CCNA Security, Wip: OSWP
<<

m0wgli

User avatar

Sr. Member
Sr. Member

Posts: 308

Joined: Fri Jul 20, 2012 3:34 pm

Post Wed Aug 15, 2012 10:15 am

Re: pen test documentation

sh4d0wmanPP wrote:Technical Attack Narrative
This is written for the tech guys and details any attack we carried out (succes AND failure). Discovery/enumeration is kept basic.


I've not heard of failed attacks being included in the main body of the report before (although if you are logging everything they will obviously be documented). Is this common practice to actually report on them?

What is perceived benefit of this to the client? Isn't the report supposed to highlight what is wrong with the clients security and how they can fix/mitigate it, not point out what they are doing right with their security?
Security + | OSWP | eCPPT (Silver & Gold) | CSTA
<<

RoleReversal

User avatar

Hero Member
Hero Member

Posts: 928

Joined: Fri Jan 04, 2008 8:54 am

Location: UK

Post Wed Aug 15, 2012 10:34 am

Re: pen test documentation

m0wgli wrote:What is perceived benefit of this to the client? Isn't the report supposed to highlight what is wrong with the clients security and how they can fix/mitigate it, not point out what they are doing right with their security?


It depends on the client's motives: most common is to find holes and weaknesses (or management to bash a techie....). But it's not uncommon for a business (or IT team) to look for validation that their defenses are working as expected.

In a well defended network a report that states the pentesters couldn't get in is meaningless in business terms, a report that states they couldn't get in, but they tried attacks X,Y & Z which the environment withstood has value, from both the 'look at the benefit we're providing from the resources utilised for defense' and a 'we protect your data against X'.

It also helps prove the negative of no flaws; did the testers fail because the environment is secure? or because the testing team is incompetent?

Reports showing holes with mitigations are/can be the most satisfying and impacting to the business, but from the otherside being able to show that you defended against the most common threats is also of value from a business politics aspect.

There's always more to a pentest report than missing patches and 0day.
<<

Jamie.R

User avatar

Sr. Member
Sr. Member

Posts: 435

Joined: Mon Aug 06, 2012 9:57 am

Location: UK

Post Wed Aug 15, 2012 12:12 pm

Re: pen test documentation

When I write an exec summary I tened to give the business a bit of pat on the back first before I right them a new one so:

During testing I found that none of you server were vulnerable to x,y,z what is really good but I also found some issue that you may want to address so on
| OSWP | eCPPT Silver and Gold | eWPT |

I'm an InterN0T'er
<<

m0wgli

User avatar

Sr. Member
Sr. Member

Posts: 308

Joined: Fri Jul 20, 2012 3:34 pm

Post Thu Aug 16, 2012 3:21 am

Re: pen test documentation

Andrew Waite wrote:
m0wgli wrote:What is perceived benefit of this to the client? Isn't the report supposed to highlight what is wrong with the clients security and how they can fix/mitigate it, not point out what they are doing right with their security?


It depends on the client's motives: most common is to find holes and weaknesses (or management to bash a techie....). But it's not uncommon for a business (or IT team) to look for validation that their defenses are working as expected.



Thanks for the informative response. It's a posistion I'd never really considered till now, and can now clearly see why this would be beneficial.

What few reports and guides I've been able to find to try and learn report writing from, have all focused on the break it/fix it approach.
Security + | OSWP | eCPPT (Silver & Gold) | CSTA
<<

sh4d0wmanPP

Newbie
Newbie

Posts: 42

Joined: Sat Aug 11, 2012 6:42 am

Post Thu Aug 16, 2012 4:50 am

Re: pen test documentation

I adopted this approach after stumbling over it while researching report writing info. Forgot the source but if I come across it, I'll post it here. Since then I stuck with it but of course it depends always on what the customer wants.

It is however a valuable insight if the company has spent time and money on it's defense. By seeing that some attacks fail because of their previous investment it will also help them obtain the required budget more easy.
EXIN ISO/IEC 27002: ISF & ISMAS, ITIL Foundation, Comptia Security+, CCNA, CCNA Security, Wip: OSWP
<<

Jamie.R

User avatar

Sr. Member
Sr. Member

Posts: 435

Joined: Mon Aug 06, 2012 9:57 am

Location: UK

Post Thu Aug 16, 2012 5:14 am

Re: pen test documentation

You also get a lot of client who want pass things drive you made by trying get you to reduce inpack of issue or remove them all together.
| OSWP | eCPPT Silver and Gold | eWPT |

I'm an InterN0T'er
<<

RoleReversal

User avatar

Hero Member
Hero Member

Posts: 928

Joined: Fri Jan 04, 2008 8:54 am

Location: UK

Post Thu Aug 16, 2012 7:54 am

Re: pen test documentation

Jamie.R wrote:You also get a lot of client who want pass things drive you made by trying get you to reduce inpack of issue or remove them all together.


If done correctly I don't really have a problem with clients asking for modification of results, they know the environment better than you (supposedly), providing they can provide sufficient reasoning to justify the request (for example a mitigation that was outside the scope of the assessment). In which case, the report will specify the original issue/impact rating, the modifications made and why and the name of the person requesting the change.

Legitimate debates and difference in opinion will end up being reported, any unjustified massaging/hiding of evidence will quickly get forgotten once the requesters name is going to be specified in the report  ;)

From experience it can also be wise to hash and document any reports provided to clients, I've once been asked from senior management to justify a finding/recommendation that had been edited by an IT ream to support their business-political viewpoint.
<<

Jamie.R

User avatar

Sr. Member
Sr. Member

Posts: 435

Joined: Mon Aug 06, 2012 9:57 am

Location: UK

Post Thu Aug 16, 2012 4:14 pm

Re: pen test documentation

lol thats is crazy them making changes to the report it only come back to hit them.
| OSWP | eCPPT Silver and Gold | eWPT |

I'm an InterN0T'er
Previous

Return to Network Pen Testing

Who is online

Users browsing this forum: No registered users and 1 guest

.
Powered by phpBB® Forum Software © phpBB Group.
Designed by ST Software