The Perfect Pen Test? Your opinions?

[t.ellio.09 at gmail.com (Tommy Elliott)]

 First, you never expressed the importance of knowing the limits of
equipment.  For instance, in your first step you might find a particular end
point that is a little older. Testing load balancing can be an important
step as a DDoS attack can be easier to perform against a cisco router from
2001 used as a internet gateway compared to the new hot shot bam diggity
2010 power house routers coming out that can hold up to massive amounts of
streaming porn and other useful videos that get streamed.

Next, is physical security and social engineering not of importance?

Making use of a vulnerability is not always an appropriate method to take in
a production environment.  Actually exploiting a vulnerability is never a
great idea in a production environment. Use the famous last words, "This *
could* happen because...." or "There is a possible of a network breach
because..." or even just using the proof of concept documented with the
vulnerability online somewhere. Every vulnerability has a PoC somewhere.

Also, the very foremost important part of pentesting was not mentioned
either, documentation.  Make a document of everything so in the event of a
server crash, you can prove it wasn't you when your documentation states at
the time of the server crash you were scanning Billy Joe's computer for
vulnerable software.  That is unless you were actually making use of the
buffer overflow vulnerability on the windows 2003 server used as a DC, then
your just f*c*e* and shouldn't have done it anyways.

Finally is a great form of documentation that is slowly trying to make an
attempt for standardization for security specialists.  Go to google and
check out the OSSTMM.  That is a much more thorough form of documentation
for penetration testing purposes.

~Tommy





> Dear All,
> > Thanks for taking the time to read this message. First off - I'd like to
> > say
> > to HD Moore and co; keep up the damn fine work, and also to everyone on
> > this
> > list who helps others who have issues, (and I mean MSF based issues, not
> > like, "my wife left me, because she caught me in my PA" type issues :) ).
> > I've been trying for a long time to get my head around pen testing, and
> > for
> > me it's not too much of a problem to understand, I usually explain in in
> > these four steps,
> >
> >
> >  - Take a look around the network, to find as many end points as possible
> >  - Take a look at each end point to see what services are running on which
> >  ports,
> >  - Match the service, service version, port, and OS, to a known
> >  vulnerability
> >  - Make use of the vulnerability, hence, proving a security
> >  breach/hole/issue
> >  - ( I know this is a fifth step, but you could also use fuzzing, if no
> >  prior known vulnerability exists )
> >
> > Now, I've had numerous discussions with people that think there is much
> > more
> > to pentesting that what I just stated, and my argument is that, unless I
> > already have a target in mind, how can I be more specific? It was at that
> > point, I realise that people tend to have personal approaches to a pen
> > test
> > rather than a general approach - which leads me to my question - What
> > would
> > be your perfect pen test approach? Personally, I think the steps I have
> > outlined, is the best principal you can follow, but I will be delighted if
> > someone could not only prove me wrong, but improve on it :)
> >
> > The scenario is as follows;
> >
> > You are presented with an unknown network, you have no prior knowledge,
> > other than the fact that it is an IP4 based network. You must prove that
> > it
> > has the potential to be compromised - what are your steps?
>
> --------------------------------------------------------------------------------
>
>
>
>
> _______________________________________________
> > http://spool.metasploit.com/mailman/listinfo/framework
> _______________________________________________
> http://spool.metasploit.com/mailman/listinfo/framework
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.metasploit.com/pipermail/framework/attachments/20090123/2e68c903/attachment.htm>