Blog

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.

It would have been nice to get Web 1.0’s security fixed first before starting on Web 2.0. And before Web 1.0 was … the mainframe.

In my time with health care providers, at one of the world’s largest telcos, at various largish Australian banks, and over the last few weeks teaching mainframe folks about secure coding techniques, I’ve come to a conclusion: we’re in a crisis. Not only have we not really solved the necessary problems in Web x.0 land, we haven’t been keeping an eye on the ball in the most important area of all: where the value lies.

Critical nationally protected infrastructure all use mainframes to process the value of our lives:

• Banking (money – a necessity, which allows you to buy housing)
• Logistics (getting stuff from A to B)
• Defense (making sure we’re protected)
• Food chain (eating – a necessity)
• Government (unfortunate necessity)

Pretty much covers Maslow’s Hierarchy of Needs in every way – modern life would not be possible without mainframes. We cannot:

• house ourselves (buy houses with a mortgage),
• eat (we no longer farm or hunt ourselves and rely on getting access to food at supermarkets (who use mainframes to keep stock levels and understand what their customers are buying) which requires shipping – and most large logistics firms use mainframes for everything from load optimization through billing and scheduling
• or even get water depending on your water utility.

I look back wistfully at seminal security papers and works from the 1960’s and 1970’s. I feel miffed that this 40 year head start has been squandered. Almost everything we’ve “discovered” in web application security is old news to these researchers. Their programmer contemporaries are still out there, building mainframe apps, and they do not know anything about the old research, let alone the new. “Web apps? Not my job, governor!”

Today’s mainframe devs do not know the core principles – confidentiality, integrity, and availability (except for performance reasons). Key security principles such as defense in depth, complete mediation, and validation are no longer practiced, even though the old code lived and breathed it.

In my discussions with mainframe devs, they struggle with basic security concepts, and even in some cases, the need for security at all. After all, the attackers know nothing of the mainframe and they can’t get on to the system. Right?

In the end, the fault partially lies with the application security community. We in web application security know no mainframe stuff. I don’t know anyone competent to review COBOL, RPG, PL/1, IBM assembly language (!), or a host of 4GLs. I don’t know anyone who knows a jot about RACF, ACF2, and all the security mechanisms available on mainframes since before I was born.

Very few know anything about TPF, MVS, z/OS, CICS, and VM. And yet, taking even one of these – TPF – could reward study for years. It powers all the airlines, the travel industry (Galileo, the world wide booking system used by everyone who travels, is a TPF application), and even 911 emergency response systems. And yet, I must admit I’ve never heard of it until last week, and yet I’ve worked around folks who used mainframes for the last 15 odd years. What chance does that newbie .NET coder who needs to have a secure ordering system involving a mainframe as a backend? We have no advice.

So we can’t properly review applications that use mainframes … except to treat them as black boxes. And that is wrong! Most large organizations have a 30-40 year investment in their applications and they’re not going to re-write in a Johnny come lately language like Java or C# just because we can’t review old code. There are literally billions of lines of COBOL out there, and it … runs the world. There should and MUST be a way we can review this code.

What needs to happen in the security research community?

We need to research the security concerns in commonly used mainframe languages (COBOL, RPG, PL/1, assembly) on top of common platforms (z/OS, others) using their common data stores (DB2, and so on). We will break old/new ground here. Probably this stuff was being thought about back in the late 70’s early 80’s, but was never published. I think our field’s brightest researchers simply stopped looking at commercial environments around this time.

We need to understand their native toolsets to provide key security architecture deliverables, such as using RACF to provide authC and authZ services. The mainframes have a rich set of security tools… but no one uses them any more.

We need to become competent in reviewing these older systems and applications, so we can provide reasonable advice

We need to be choosy about what to review – there’s simply so much code at every large firm and government agency and basically no one to review it

Although OWASP should be publishing the results of this work, maybe we as the security industry should have an extended residency with the IBM Redbook folks to get access to the real deal (do you have a mainframe?), peer review our work, document all our findings and get it back in the hands of the mainframe devs in a timely fashion.

What needs to happen on the mainframe side of the fence

Business requirements should reflect in the security architecture. We know that mainframe has almost all if not all of the necessary support of a “modern” security architecture:

Data protection

• Confidentiality. Most mainframes have an inbuilt HSM. Few sites are using this feature! What a waste. Let’s get this out there and encourage the use of hard core encryption
• Integrity. Most of the protocols in the SNA stack have inbuilt integrity controls, and yet once they are mated to TCP/IP, the common protocols such as ftp, x3270, and access to MQ is all unencrypted and has no integrity controls. This needs to change

Identity management

• RACF is basically as old as me. It supports everything a SSO vendor would happily sell a Java site and has done for over 30 years. It now supports modern pass phrases, LDAP support, and so on. These “advanced” features should be in use at more sites.

Event management

• I still need to do more reading, but I can’t imagine that the systems which power banks has no audit or logging features. Let’s learn how to differentiate between logging and auditing, and ensure these logs are protected from unauthorized use.

The folks on the mainframe need to understand the powerful tools and native platform support they already in their possession. This requires training and support from their vendor. IBM? Hear me.

We in the security research community can’t possibly understand every possible version of every language and platform out there. It’s time to start consolidating around a few common platforms and languages. I propose the security industry sticks to supported platforms and languages as IBM has a chance of rectifying any problems we find.

This will be painful for many, but it’s like the pains the accounting industry went through in adopting the GAAP. We can’t and should not audit a planet’s worth of loose receipts.

I am not hopeful that any of this will change any time soon. I am willing to have a dialog with any and all mainframe folks. Let’s talk.

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.

After a nine month process, starting with a visit to a pho restaurant with Raoul Endres in Melbourne Australia, and ending with me working in a hotel room in Pennsylvania, USA, the Top 10 2007 is really done. It’s 35 pages packed to the rafters of good advice.

The document will be launched at OWASP EU this week. Look for it on our Wiki shortly in PDF, Word and Wiki format.

Whilst not quite a 1-1 mapping to MITRE data, this is a succinct update to the 2004 work, and I think a very worthy successor. Hopefully, it will not be three years between this release and the next.

Jeff Williams and Dave Wichers (my co-authors) have put in some excellent work on the back end, as well as being a devil’s advocate when it was necessary. Much thanks to Steve Christey of MITRE for his excellent careful line by line reviews, and indeed all our peer reviewers.

Feel free to download it and have a read. I welcome all comments.