OWASP Guide 3.0 Starts

Well, I’ve had a bit of a holiday … doing work, and it’s time to pick up the pen and start writing again.

I was struck by the Wiki at just how hard it was to edit and get it the way I want it to look. Even more so when my free time coincides with poor or non-existent network access. Right now, I don’t need to fight the tools. Neil Smithline has a tool which can Wiki-fy a Word document, so my plan is to work in Word (again) and get regular re-publishes to the Wiki. That way, I get maximum productivity where I don’t need to fight the template (I can just write words), and we all benefit once the work is done.

Over the last day or so, I’ve looked at the OWASP Guide 2.1 (a draft which is essentially what you see in the Wiki as 3.0), and it’s not pretty. There’s lot of … interesting … advice in there. I know I (re-)wrote a bunch of it (well, most of it), but it’s proof of the pudding – choose one of “quick, secure, cheap” and you get your priority. The priority last time was to make BlackHat in 2005, a Herculean task that took me out of commission for months afterwards. I was so burnt out from doing stupid insane hours (basically a full day’s work and then a full day’s work at night on the Guide followed by 4-6 hours sleep and doing it over again), that after it was done, I ended up watching more Tivo than doing geeky stuff or going out with friends.

I’m taking the “secure” path this time. The Guide 3.0 is going to be much shorter. In fact, I’m generally going to start over unless there’s some good text already. There’s two reasons for this:

• We want to change the license from the GNU FDL to the Creative Commons Sharealike license, and we can’t do that right now. It would take a long time to find everyone and ask them to assign their (C) to the OWASP Foundation, and if even ONE of the previous authors / contributors / editors cannot be found, we cannot relicense. Now, I know many folks think, “do first, apologize later”, and in general most folks who contribute ANYTHING to an open source effort must realize that they’re efforts are working towards the Foundation’s goals, not particularly theirs… but in this case, we live or die by looking after our copyrighted works. If we want to ensure that others do not copy without attribution, we also have to do that too. It’s a moral thing.
• Much of the previous content really belongs in the (Penetration) Testing Guide, and a significant chunk would be good for the forthcoming Code Review Guide. There’s remarkably little in the current 2.1/3.0 Wiki draft for building secure software.

So that needs to be created. And once I go down that path, I may as well make the effort to re-structure the Guide into a proper security architecture format:

Introduction / Frontispiece

Security Architecture & Secure Design
– Principles
– Policy
– Regulatory environments
– Risk Management and Threat Risk Modeling
– Asset Classification
– Secure by design
– Initiator / Approver
– Help Desk / Administrative interfaces
– Secure Coding Standards and Methodologies

Identity Management
+ My family and other animals, or Evidence of identity and the user management life cycle
– Questions and Answers – still stupid after all these years
– Providing advice on storing strong credentials

+ Authentication & Session Management
– When to use 2FA vs passwords
– Designing for federated authentication
– Designing for federated trusted authentication
– Transaction signing – Authenticate the transaction, not the user (necessarily)
– Signing calculators
– Flow diagram for SMS / e-mail trx signing
– Flow diagrams (2FA, certificate, password)
– Common controls (idle timeouts, etc)
– Protecting against common attacks (Brute forcing, phishing, etc)

+ Access Control
– Coarse (access to system at all)
– Medium (access to secured resource / secured function)
– Fine (access to particular datum i.e. Direct Object References)
– Building indirect object references
– Attacks (forced browsing, direct object reference, etc)

Data Protection
– Designing highly protected systems
– Asset classification and legal requirements to protect data
– NOT using / storing certain types of data
– Privacy
– Secure Communications
– Secure Storage of sensitive information
– State management
– Pattern
– In a “normal” web app, Ajax, and web service

Integrity
– Data validation
– Output encoding
– File system

Accountability
– Designing high value systems – preventing fraud and promoting accountability
– Designing for incident response / forensics
– Auditing
– Logging
– Error handling

Availbility
– Protecting against injections
– The pattern of badness and how to protect against it
– XSS
– CSRF
– SQL / MDX
– LDAP
– XPath
– …
– Denial of service
– Buffer overflows
– Concurrency and race conditions

Services
– Traditional (OS, e-mail, etc)
– Web Services
– Ajax (JSON, and plenty of other topics, etc)
– REST
– XMLRPC
– .NET Remoting
– JNDI and JMS

Ensuring Quality
– Software quality assurance – how to test web apps properly (and where to go after here)
– Configuration
– Deployment
– Maintenance

Index
– Index
– Glossary
– References
– XSS Cheat Sheet (after permission is sought again)

Although I am not looking forward to writing every night again, at least this time I have a good basis to work from and I’m not trying to write three Guides in one. I am probably underestimating the effort required, but I hope to bring this in under 150 pages, delivering basically a chapter a month or so (about 10 pages per chapter) to the OWASP Guide list to be peer reviewed, code snippets and diagrams created. Once we are nearly there, with some luck, we can send it to the publisher.

Why don’t I want a co-author? I tried that in the past and although help was offered, only a few rare individuals submitted work afterwards. Some of it was excellent, but much of it needed re-writing due to technical errors or outright hinky prose. The Testing Guide shows that the quality varies so much when you DO get help that it’s simpler to write the text yourself.

I will gratefully accept help with the editing – editing the text once complete is a very necessary step, and it’s certainly much easier for folks who are unaccustomed to writing large books to edit than to write from scratch. There’s a world of difference between writing a blog entry and a book. I think it’ll just be faster this way, and hopefully, a bit higher quality. Of course I could be wrong!

Off to fire up Word.