tssci security

Qualities of good pen-testers

Taking care of business

Before I get into this post, I wanted to give you some updates on progress of other projects here at TS/SCI Security.

First off, I've been working on the OWASP Evaluation and Certification Criteria Project and hope to announce something very soon. Secondly, you'll want to take a look at today's post on The New School of Information Security book (Acidus also did a writeup). As a side-note, there was an interesting data breach recently announced, which makes information on breaches even that much more relevant.

Lastly, I wanted to announce the return of the "Day X: ITSM Vulnerability Assessment techniques". Expect a post everyday with new and relevant material.

Positive spin on pen-testers

Matasano posted last week on the Seven Deadly Pen-Test Sins, with follow-ups from two other blogs I'm aware of: Mike Andrews and BlogFranz. This should be a hot-topic!

At TS/SCI Security, we like to focus on the positive instead of the negative. Pen-testing, especially application pen-testing/review is an important topic to us. So here's our rundown of what we feel is important to know about pen-testing, as a response to what Matasano wrote.

Seven things you can do to improve your pen-test results

1. Time Management. If you're not already using GCalendar, RTM (with GCal), Twitter, Sandy, and Jott (thanks to Dennis Groves for some of these!) -- take a look at how these can help you manage your time better.

2. Utilize applicable MITRE resources. CAPEC (for runtime testing) and CWE (for static analysis testing, which may include reversing) should be utilized throughout. Be careful to only choose the relevant aspects of each (relevant to the application, not your skill or other criteria).

3. Work with developers. Assuming that the dev team is already doing Continuous Integration (or something like it), Fagan inspection, using the V-Model (in the requirements phase), continuous-prevention development, integrating concepts from the Microsoft SDL (or similar secure SDLC), and automated integration testing -- then get involved right away with a software walkthrough with all of the key players.

4. Automate development-testing. While web application security scanners (or fat application-based fuzzers) collectively only typically find at-most 30% of the bugs with a large amount of false positives, there are plenty of developer tools that don't have these problems.

5. Peer review your work. This one is easy. Find a friend and have him/her check your work. The more eyes you get on your pen-test and assessment work, the less likely you're going to miss something.

6. Stay up-to-date on both process and technology. Read forums/blogs/mailing-lists, trade journals/magazines, and books. Attend conferences. Keep it cheap and continuous if possible.

7. Go back to basics. Set a minimum bar of maturity with clients before you pen-test or do an assessment. The BITS Shared Assessments Standardized Information Gathering questionnaire is a nice start, especially combined with Visible Ops, ITIL, COBIT, ISO27K, PCI-DSS, PABP/PA-DSS, ISECOM, and OWASP information on process.

All of the above is going to go a long way towards improvements to what pen-testers and vulnerability assessors do. There's very few good certifications out there for what we do, and it's difficult to measure what we do. Put the cards on the table up front with your clients and teach them your methodology and approach.

Posted by dre on Monday, March 17, 2008 in Hacking, Security and Work.

blog comments powered by Disqus
blog comments powered by Disqus