It’s time to get moving again. The Top 10 2007 is out. So it’s time to look at the raison d’Ãªtre of OWASP – The OWASP Guide. The OWASP Guide is a compendium of best practices, what not to do (in 2003-2005), how to test for a problem, and occasionally comically bad English. I did 18 hour days for nearly six months back in the day to get it out the door, something that is just not possible these days as I have my insomnia mostly under control.
My view is that we need four smaller books:
1. OWASP Secure Lifecycle Guide for Requirements, Architecture & Design
2. OWASP Guide to Writing Secure Applications
3. OWASP Testing Guide
4. OWASP Code Review Guide
That way, we can farm out the materials that exist in the Guide today to the appropriate books, and make it much more lightweight. Being 300 pages is fine, but honestly, I doubt anyone besides me and the translators have read it in its entirety. I don’t think the average work-a-day developer has the time nor the inclination to read yet another fat book, particularly one that they themselves don’t see as being particularly useful to their primary role: pumping out insecure code, leaving time for instant messages and a few quick rounds of killing fellow cubicle dwellers … in whatever FPS du jour.
Schneier stated recently in one of his famous counter points with mjr, that he believes that the security industry shouldn’t exist and that penetration tests (paraphrasing) should read and then shredded. Seriously, if you’re waiting until the pen testers tell you that you have a problem, it’s far too late. Software engineering must make the jump from being a cowboy nation of lazy and uneducated coders to being a repeatable, safe art. That’s why I work in the area I do – fixing the problems before they are problems. Then it’s basic risk management. And folks have been doing risk management for years, well before the current security industry sprang up. There are snake oil sales folks in our industry without a doubt, but there are many skilled and useful folks as well. I hope I am one of the latter.
Back to the Guide… There’s a need for the OWASP Wiki to be in sync with these master works. This is an ongoing problem; I don’t know how to solve it. Writing a book one page at a time is ineffectual and wasteful. Editing a massive tome even more so. Wikis have their place though, even if the Wiki fan boys hype it beyond its actual capabilities. The Wiki way is not the book way. To a Wiki fan boy, this is actually not a problem. But to me, as a lover of narrative and meaning, the dictionary like slabs of text are like context-less ships passing in the night. There’s no thumbing around there without maybe missing something important. The Wiki is great as a dictionary; terrible as a learning platform. I love puttering around great Wikis like H2G2. Towel Day is May 25. Don’t forget your towel.
No matter which way you slice it, someone has a lot of work to do to translate a book into a useful and helpfully hyperlinked Wiki, and a truly awesome Wiki is nearly impossible to fold back into a book.
2 thoughts on “Time to start on the Guide 3.0”
You wrote: “Software engineering must make the jump from being a cowboy nation of lazy and uneducated coders to being a repeatable, safe art.”
Could not agree more. Has the time come for software engineering to come of age and have an umbrella professional organization with entry exams and affiliation/accreditation? Look at (what I will call for the purposes of this post) genuine profesisons: lawyers, doctors, architects, teachers, nurses. All have some requirement to pass a mandatory qualification exam (in the case of teachers, this is jurisdictionally dependent, and nurses can go only so far without sitting the board registration exam). In some case, the profession names themselves are protected — I understand the Architects’ Registration Board of Victoria is going after folks in the IT community requiring them to either sit their exam or stop calling themselves architects. (and never say I give you rant topics).
The anti-Falwell is in the detail of course: who, what level, etc. But at the moment we seem to have a bunch of people consulting from home, using wikipedia as a reference work…
Dude, you need to read Martin Amis’ recent novel “House of Meetings”. It has nothing to do with IT security or your blog entry, but you might find it a good read (even if buying the book contributed to MA’s dentist (another profession with quite stringent entry requirements (although (correct) bracket nesting is not one of them))).
Your pal in old studded leather wetsuit.
I agree with both Schneier and mjr that pen-testing can be thrown out. Penetration testing usually refers to a zero-knowledge, black box, external vulnerability assessment that does not seek to find every vulnerability, but usually at least one critical one.
But if anyone thinks that means that developers will do all the testing by themselves – they are sadly mistaken. An internal or external team needs to do a formal, full-knowledge review of both the source code (static analysis) and the live, production application itself (dynamic analysis) both before and after-the-fact. This sort of vulnerability assessment should be as complete as possible. This eventually could be developers-as-assessors themselves as long as a process is in place to prevent corruption and mis-trust (and assuming that they have the skills to do this in the first place). Trust, but verify – as always.
I’m also lost in the wiki vs. book argument. Which do you support for OWASP Guide 3.0 and why? Why not put all definitions, dictionary terms, and hyperlink-savvy data on the wiki, and build the book from these wiki items – with the remaining book content “going straight from brain to paper”? In other words, let each medium concentrate on each’s own specialty. The book can contain parts of the wiki, and the book can be converted to wiki format when it is complete and reviewed.
I noticed that with the OWASP Top Ten 2007 a few changes were made on the wiki to reflect hyperlinked data. PDF’s can have this same hyperlinked data. Start with that data on the wiki, merge it into the book, write the rest of the book, and then publish back to the wiki.
I wonder how the v3 Guide will overlap with the OWASP Certification project. Thoughts on this?