The BETA Mindset: Public Enemy #1

Submitted by Mike Rothman on Mon, 2008-06-30 09:25.

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

Submitted by Anonymous (not verified) on Mon, 2008-06-30 11:48.
Well, just because some guy uploads a picture to flickr, he is not necessarily the owner. I would give credits to the rap-group the logo belongs to: Public Enemy (tataaa, what a surprise). I don't like copyrights either, but that's just the way it is (by the way, I do not like flickr more than copyrights, but that's just my opinion).
Submitted by Davi Ottenheimer (not verified) on Tue, 2008-07-01 18:20.
Bah, the "under construction" concept of the web is as old as the web itself. Microsoft was even kind enough to run a beta program where you were given access to virtually all of their software for free as long as you gave them "feedback". The more you ran your production systems on their beta, the better your feedback, or so it was explained in the 1990s. Google did nothing new, really, other than become wildly successful for other reasons and become an instantly recognizable brand. You might as well credit them with being the first to have a color logo.
More to the point, the fast and iterative release model is a boon to security as much as it is a bane. If you absolutely positively must release a patch to the site, you do not want to go through a massive regression exercise or be stopped by QA so they can evaluate user experience. The risk of compromise could be high enough that you have to push a patch ASAP regardless of usability or comfort issues. For example a major release that took multiple months to build could develop a critical failure in production that needs to be patched only hours after release. Could it have been avoided? Perhaps. But the fact that the security team could initiate and push a patch in a timely fashion actually works to our benefit. This is also complicated by the fact that few companies have the resources or expertise to create a proper test environment and they often do not know what will happen until they go live.
Also, I do not believe you are correct that all people should think "by the time you may iterate you are dead". This depends on a number of factors. If there is little/no threat (e.g. few attackers look at your site) then the vulnerability can be present without causing a huge risk. On the flip side if there is constant threat (e.g. attackers pride themselves on finding a flaw as soon as a new element is launched) then even the most trivial vulnerability can lead to high risk.
Submitted by Blake (not verified) on Thu, 2008-07-10 14:36.

Even worse than companies not being careful with security is how trusting users are. They will share information without thinking twice. Especially the younger generation.

If you haven't already written a post on this you should. 

Here is a helpful article: Security Web 2.0: Open Season for the Attackers?

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Post new comment

The content of this field is kept private and will not be shown publicly.

More information about formatting options