Do you use “traditional” penetration testing?

A paper entitled “Adapting Penetration Testing for Software Development Purposes” was published recently and is a very good read for CIOs, CTOs, and anyone responsible for security of applications.  The suggestions for how to better adapt “traditional” penetration testing methods to software development are well thought out and I hope help the industry as a whole.

One thing I hope that readers come away with is an understanding of what penetration testing should be.  Any penetration testing that is done today should address the topics identified.  It should be constructed to adequately test what you want tested. It should convey business-prioritized risk to the CIO as well as developers.  It should utilize personnel with multidisciplinary skills and the ability to tailor and interpret testing to your needs.

When I first read this article, I felt a little bugged by the whole notion of “traditional” penetration testing.  Having  been around since the “early days” of penetration testing mentioned in this article, penetration testing to me has always been a fluid and dynamic method of demonstrating risk that by nature has to adapt and incorporate new technologies and challenges as they develop.

While I hope this helps advance the overall state of penetration testing, I also hope that the penetration testing services you are getting already incorporates these ideas.  If not, it is definitely behind the curve and should be called “traditional”.