cat slave diary

A little while ago, I wrote a dejected post saying that OSCON, Black Hat, and Defcon all missed the greatest opportunity to speak to the right folks about securing their apps. Well, with the final schedules of Black Hat and Defcon up, we have:

• Fear - Pretty much every talk
• Uncertainty - you betchya
• Doubt - doesn’t the security industry work on creating doubt? Yep.
• Solutions - 10 out 444 talks == 2% of all talks

  We have to move past this. I am not asking for solutions to be even 50% of the talks, but dammit, it should be over 10% and it should be over 25%.

  The CIOs and CTOs and mid-level junketeers in our industry (who go to these events to pick up chicks of negotiable affection*) and go: “WHOA! I’m so screwed! What do I need to do to protect my assets from all this badness?” And the snake oil sales puke from the large security ISV will go: “let me show you this bridge I have for sale over here…”

  At Black Hat 3 of 5 potential security solution talks are the 20 minute turbo talks. How much can you learn in 20 minutes? Enough to be scared, or enough to learn a URL? In Defcon, there’s just one talk on using a tool as a shield around your crap. Of course that’ll work. Like anti-virus or IDS “works”. Not.

  The CIOs and CTOs and high level business folks don’t want horror stories. They get that enough of that from the snake oils sales pukes. They want solutions that work. They want to know what to do right. These solutions should not cost the earth and should be effective. None of which they’ll learn about at these conferences. Will this stop them going to conferences? Of course not! It’s Vegas, baby!

  The conferences will have to start being relevant or they’ll end up like being CES. CES started out small, grew immensely, changed to be vendor friendly, and no one came. They cancelled it. Now everyone goes to E3. They’ve changed the rules to be more industry friendly… and it’s only a matter of time before it, too, dies. “Our” industry conferences on the outside seem more popular than ever, but they are dead. I will not be submitting any more talks to them as they are irrelevant. They do not support solutions, only fear.

  * And occasionally, chicks with dicks of negotiable affection. But what happens in Vegas, stays in Vegas, eh baby!

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.