afongen

Jukka Korpela, whose well-researched writings on characters and encodings are standard references to which I frequently turn, has written a book on Unicode that has just been published by O’Reilly. Marvellous. I’ve been waiting for this one. It’s likely to be a few months before I get to it, but I’m very glad it’s there.

I just got word that a coworker and her four children were hit by a car yesterday as they were walking near their home. We don’t know their status other than what’s in that article, as the family has more important things on their mind than contacting the office with updates.

I’ve worked closely with Stacy for years (her husband recently joined us here as well), and these are some of the most adorable kids you’ve ever met. They are in our thoughts and a whole lot of prayers.

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.

I keep forgetting to mention this. The Twin Cities OWASP chapter is meeting Tuesday night this week at the Minneapolis campus of Metro State (right near MCTC). Directions and details are on the chapter page.

Tim McGuire will be talking about free and open source pen-testing tools, and Joe Teff will talk about Fortify, a commercial source code analysis tool. Looks to be a good meeting. Since I’ve been unable to attend the last two, I’m looking forward to it. Maybe I’ll see you there!

Rachel Coleman and her daughter Leah of Signing Time fame performed at the Minnesota Children’s Museum last week, so naturally we had to bring Owen and Alec. We all had fun.

You may recall that we’ve been using sign language with our kids from an early age. Neither Kiara nor I is fluent in ASL, but we could learn enough to help Owen express himself before his verbal abilities took off wildly. He still loves to sign, and I know that he’ll have a lot of fun signing with his little brother.

A recent conversation made me realize how easily a mismanaged iterative development cycle can become a waterfall.

Break work out in stages, fine. Use those stages as short iterations with scheduled releases, building toward a final release of a “finished” product, good. Build on what you learn during those iterations to progressively refine your understanding of the requirements and your design, good.

Uncover important requirements and/or significant design flaws in early stages, but explicitly label these findings as “new features” that won’t be implemented because you didn’t know about them during the Big Design Up Front and now you don’t have time… not good. You’ve just missed the point and lost the advantage of iterative development.

It’s not enough just to know that requirements will change during development: you should act accordingly and build your process around the expectation of change. When requirements change (and they will), but you respond as if they have not and must not, then your process is broken.

I snapped this from the bus on the way into work yesterday:

I’ve got a lot of email the last couple days (a surprising amount of it in response to my Jabber post the other day … gotta enable comments) but haven’t been able to respond because I’ve been dealing with a family health issue. Nothing that massive amounts of antibiotics and painkillers won’t help, hopefully, but please know that I haven’t been ignoring you. I’ve just had other things going on.

We had a “town hall” meeting today to discuss the MnSCU ITS workplan for the next year. It was only hours later that I realized that it didn’t follow an all-too-common pattern of telling us a whole bunch of new stuff that we could have got in email. Instead, a PowerPoint overview was distributed beforehand (the narrative version is being written next, otherwise I hope that’s what we would have got), and knowledge of the contents was just assumed during the meeting. This opened up the meeting for discussion.

Marvellous. I am no fan of using meetings to disseminate information, so this is a very welcome change.

Jon Udell shares a sadly amusing anecdote about the sort of thing that gives PR flacks a bad name.

I share this not only because it’s sad and funny, but because it means Jon’s likely to write about GData. I’m looking forward to that, because I have a hunch that GData will be important. Stephen O’Grady explains why in far more detail than I have time for, so just go read that. Or since they’re having problems with their web host, read a cached version. Fundamentally, a relational database isn’t always the best solution for storing and manipulating data, and as Adam Bosworth has argued, we need new ways to access/manage our data in its various stores. GData, an Atom-based format, is a step in that direction.