I made it to Tuesday night’s Minneapolis/Saint Paul OWASP meeting for the first time this year. It’s good to be back. There was good information and conversation both during and after the meeting.

Tim must have drawn the short straw to be scheduled first, so he got to deal with the usual projector problems. But once things got rolling, he treated us to a demo of a few free or low-cost scanning tools. He has notes on his blog. From what we saw tonight, what really differentiates higher-priced commercial scanners/pen-testing tools like AppScan and WebInspect is the reporting. It’s obviously not that simple, but man it makes a difference. Reading a Still, I’m with Tim: the Burp suite is a nice toolset, I enjoy using it.

Bob Sullivan gave us a quick overview of what’s new in WegGoat 4.0, a teaching tool for web application security. One thing that I’m glad to see is moving the documentation to the OWASP wiki. There’s also an Eclipse developer environment using WTP, but I haven’t investigated to see exactly what that means.

Next Joe Teff gave a quick demo of Fortify’s source code analysis tool. He was quick to point out that he wasn’t selling the tool, but he had experience with it with his job at Wells Fargo and thought it was worth talking about this type of tool. I don’t know if there are open source tools in this space, but it is at least heartening to see more and more commercial tools building on the Eclipse platform. As I understand it, source code analysis tools take a couple approaches. Static analysis is essentially a glorified grep, searching for problematic patterns. In dynamic or runtime analysis, the binary is examined while it is running. Fortify seems to do the latter, and is connected to your static source code to trace problematic data paths through the app. This is simple for small or standalone apps (think jar, war, ear), but it sounds like you have to jump through hoops to make it work with a distributed app. Possible, yes, but SOA will push the limits of these tools, so I expect some movement on that front in the next couple years. Unless I completely misunderstand how they work, which is possible. Either way, interactions at the boundary between two applications/modules/services merit close scrutiny; relying on a tool alone is insufficient.

Gunnar Peterson gave a quick overview of the goings-on at AppSec Europe. Good stuff, I’ll have to check out the presentations and watch for video. I really need to attend an OWASP conference. One interesting takeaway is a discussion of whether the open source world is keeping pace with Microsoft on the development and dissemination of secure development practices. Johan Peeters has a summary and interestingirritatingly pedantic discussion in the comments. Note to self: take another look at CLASP.

This meeting came at a very good time, as I actively work on improving how we incorporate security into our development process. Much as I resist generating documentation that does not move us closer to working software (and do like docs that help us get work done), I am cautious about introducing tools that may chew up cycles without sufficient benefit. Penetration testing software has an obvious place in the SDLC, but it comes too late in the process to intervene with a train about to derail. I used to be suspicious of code analysis tools but have warmed to them. I believe that they can help developers learn more about secure coding practice. If they can tie into bug reporting and tracking, all the better. (I’m also becoming a fan of metrics.)

I want to stay clear of the notion that it’s all a developer problem, though, which I think a focus on development tools tends to encourage. “Oh, those darn developers, if only they’d just think!” Yes, developers need better security education. So do designers and architects. More on that another day.