BETA

You've got to love Google. Besides how quickly and effectively they've disrupted the advertising world and built a company of scale, they have changed the way most folks think about web applications. Google (to my knowledge) was the first that harnessed the power of "BETA" to release buggy software with a smile on their face.

You see, BETA is all about managing expectations. By putting the BETA moniker on an application, you are telling the customer (and amazingly enough people even pay for BETA software) that there are problems. There will be issues, it won't work as you want, you'll probably lose data, and it's your problem. The software developer doesn't want to hear from you when they crater your email or application or anything else.

That's right. By plastering BETA in your application, you get off the hook. And it works. When I can't get to my Gmail, I just shrug and say - well it's BETA after all. And the price is right.

Yet, this is killer for someone who is responsible for web application security. Why? Because BETA (and Web 2.0) is all about getting something out there, not something that is good. Once it's out there, you can iterate and make it better.

From a functionality standpoint, that's exactly right. Quick interations are critical to gather market feedback and improve the experience. From a security standpoint, by the time you get to iterate - you'll already be dead. Or looking for your next job, at a minimum.

Let's go back to Web App Security theory. In a perfect world, a threat model is built ahead of architecture and development, and systematic process of testing the application for vulnerabilities and exposures happens at every step of the dev process. Right?

Wrong. There are maybe a handful of companies that actually develop applications like that. The rest just build crap, plaster BETA on it, and let it loose on the world. XSS, CSRF, SQL injection and any number of other application vulnerabilities and all.

Which creates quite a quandary for a security professional. What to do? Basically you need to hack your BETA applications. That's right, go Hack Yourself. Even if you have to do it in your free time, you have to do it.

The only way to make it clear to the developers the dangers of the BETA mentality is to show them with incontrovertible evidence. You need to break your own stuff and then they'll at least have to listen to what you say. Or then you can go find another job in better conscience that you tried your best to do the right thing.

No this isn't a big departure from a lot of my thinking on security assurance, but it's a bit further under the radar.

Once you've broken the BETA, you can start building your credibility and showing the developers that a bit of balance between getting it out there (the BETA mindset) and shipping commercial-grade software (you know, stuff actually works and is sort of secure) can be reached.

And then thank Google for setting the web application bar so low that no one seems to care anymore.

Photo credit: "Public Enemy" originally uploaded by Matheus Kawasaki