Pen-Testing and Metasploit Question

[kbeaver at principlelogic.com (Kevin Beaver)]

I wrote an article on this for TechTarget that you may be interested in 
as well:
Essential Elements of a Good Security Assessment Report
http://searchenterprisedesktop.techtarget.com/tip/0,289483,sid192_gci1235715_mem1,00.html

Hope this helps.

Kevin Beaver, CISSP
Consultant*Author*Speaker*Expert Witness
Independent information security advice ~ Principle Logic, LLC
company: www.principlelogic.com
audio programs: securityonwheels.com
blog: securityonwheels.com/blog
twitter: www.twitter.com/kevinbeaver

Matt Gardenghi wrote:
> Well, I think that this should be enough:
>
> - Exec summary (1 page)
> -- Overview the work that was done
> -- Any significant highlights
> -- Grade/Score on the work
>
> - Summarize Flaws (1-2 pages)
> -- Explain the rating for the flaws
> -- List flaws in categories (High, Medium, Low)
> -- This isn't the place to give in depth discussion, just <ip/machine 
> name> <vulnerability>  OR <vulnerability> <multiple IPs>
>
> - Detail Flaws (multiple pages)
> -- Detail each flaw tested starting with the High
> -- Include screenshots where applicable
> -- Possibly add highlights to the screenshots/captured data to emphasize 
> a point
> -- Explain how the flaw was exploited  / broad strokes
> -- Add footnotes or endnotes detailing specific methods to fix and/or 
> replicate the flaw for the IT guys to repair it as applicable with this 
> specific test
>
> - Detailed recommendations
> -- This should give the client actionable measures to fix many of these 
> vulnerabilities.
> -- Recommend an IPS if necessary to block automated exploits / RFI / LFI 
> / SQL etc... attacks
> -- Recommend explicit techniques to sanitize input
> -- Recommend methods to decrease time to patching and/or methods to 
> protect boxes that cannot be patched regularly
> -- Recommend best practices for securing RDP, FTP, Telnet, DNS, et al...
> -- This stuff depends on the results of your test, bust as you can see, 
> most of these recommendation are procedures and do not necessarily 
> require cash.  The recommendations requiring cash (like an IPS, better 
> AV) should solve multiple problems if possible.  The goal of this 
> section is to highlight low cost methods to boost security.  Generally, 
> a client can spend a few hours and secure systems better than they 
> currently are by switching to SSH, SFTP and so forth.  These 
> recommendations are the value.  You found a whole and if you can help 
> them secure it at a low price, you just made yourself their new best 
> friend.  In stead of losing tens of thousands or millions on a breach, 
> they just spent a few on you and secured these holes.  :-)
>
> - Conclude with statements about what they have done well and a brief 
> summary about what they need to do to continue improving.
>
> Hope that helps.
>
> Matt Gardenghi
>
>
> chuks Jonia wrote:
> > Hi Matt, would you mind posting a sample report with the guidelines
> > you just specified?
> >
> > ./Chuks
> >
> > On Thu, Apr 30, 2009 at 3:35 PM, Matt Gardenghi <mtgarden at gmail.com> 
> > wrote:
> >  
> > > This is my opinion of course:
> > >
> > > A report should give an overview for the execs, followed by a short
> > > list/snapshot of the critical items found.  Then the report should 
> > > detail
> > > the critical holes and data found.  Lots of screenshots are helpful.  
> > > The
> > > end of the report should make detailed recommendations on how to fix the
> > > holes.
> > >
> > > so
> > > -exec summary
> > > -summary of flaws
> > > -details of flaws/data captured/flags placed
> > > -detailed recommendations to fix the environment (especially low cost
> > > high-value solutions)
> > > -conclusions
> > >
> > > Hope that helps.  That is roughly what I do.  I also like to have 
> > > plenty of
> > > footnotes and appendices with extra-geeky details.  My goal is to 
> > > write a
> > > report that any exec can read and understand the basic points, but 
> > > also has
> > > the meat for the technical teams to delve in and solve things.  That 
> > > meat is
> > > usually in footnotes and appendices.  Write so that a reasonably 
> > > techie exec
> > > has the ability to delve as deeply as they want or stay high up on the
> > > surface.
> > >
> > > Matt
> > >
> > > pandini pandini wrote:
> > >    
> > > > Matt Gardenghi, TK and BN thanks for your replies !
> > > >
> > > >  One quote about Matt Gardenghi reply, about writing a good report.
> > > > Just a .pdf document, containing all vulnerabilities found (Machine
> > > > XXX vulnerable to ms08-069), its severity (Critical), and how to fix
> > > > it (some link to a patch) ? Other informations (If I was asked to do
> > > > it)  like credentials grabbed(Plain text/hashed passwords),
> > > > informations about hosts and devices (running linux, apache, etc), if
> > > > the target has some database then some tables of an database, or
> > > > source codes from the a internal cvs server of the company, as "proof"
> > > > of what can be done by an attacker is usefull or just say "passwords
> > > > can be stolen" ?
> > > >
> > > >  About the report, someone has some "model" or example of report that
> > > > can be shared with us ?
> > > >
> > > >  I agree with you TK about certifications, and I seriouly thinking
> > > > about CEH certification. But I have no ideia from where to start,
> > > > someone knows a good book/material ?
> > > >
> > > >  Thanks in advance,
> > > >  Pandini.
> > > >
> > > > On 4/23/09, Ben Nell <enemy.cow at gmail.com> wrote:
> > > >
> > > >      
> > > > > A good place to look for help with these types of questions might be
> > > > > the Security Focus pen-test list.  You can read some details about it
> > > > > at http://seclists.org/#pen-test.
> > > > >
> > > > > A lot of this sort of thing has already been discussed, so you could
> > > > > probably find a lot of useful information reading through the
> > > > > archives.
> > > > >
> > > > > BN
> > > > >
> > > > >
> > > > >        
> > > > > > pandini pandini wrote:
> > > > > >
> > > > > >          
> > > > > > >  I'm in the same boat that professor, trying to get into pentest
> > > > > > > industry but I don't know "where to start". I agree with what max
> > > > > > > said, imho methodology is the center of the thing, know how and why,
> > > > > > > is really better than know "where to click" or what command to run.
> > > > > > >
> > > > > > >  My questions are, "What the industry expect from a pentester" 
> > > > > > > (audit
> > > > > > > database, software source code, networks, servers , etc..), "What is
> > > > > > > generally done in a basic pentest", and what certifications are 
> > > > > > > "good"
> > > > > > > to proof some basic knowledge. Just say to a company that "I'm 
> > > > > > > able to
> > > > > > > do a pentest, can you give me a change ?" will don't work.
> > > > > > >
> > > > > > >  I think that I need some formal proof of knowledge, as I haven't 
> > > > > > > any
> > > > > > > professinal experience in pentest, this is the only one way that I
> > > > > > > see.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >  Thanks in advance,
> > > > > > >  Pandini.
> > > > > > > _______________________________________________
> > > > > > > https://mail.metasploit.com/mailman/listinfo/framework
> > > > > > >
> > > > > > >
> > > > > > >             
> > > > > > _______________________________________________
> > > > > > https://mail.metasploit.com/mailman/listinfo/framework
> > > > > >
> > > > > >
> > > > > >           
> > > > > _______________________________________________
> > > > > https://mail.metasploit.com/mailman/listinfo/framework
> > > > >
> > > > >
> > > > >         
> > > > _______________________________________________
> > > > https://mail.metasploit.com/mailman/listinfo/framework
> > > >
> > > >       
> > > _______________________________________________
> > > https://mail.metasploit.com/mailman/listinfo/framework
> > >
> > >     
> >
> >
> >
> >   
> _______________________________________________
> https://mail.metasploit.com/mailman/listinfo/framework