Web Application

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

Was the Fake Steve Jobs blog hacked? It sure seems that way. Over the long weekend, there were a number of posts from "Fake Bono," which were actually pretty entertaining. I figured it was just another ruse to drive traffic (like Fake Larry), but this post on FSJ yesterday seems legit. If it is, then let's speculate a bit on how the blog could be hacked and figure out what lessons are to be learned.

First of all, this clearly was a targeted attack. It's not like a bunch of SEO bandits took over the site (like Gore's Inconvenient Truth site H/T to Jeremiah), this was someone who clearly had the imposter posts ready to go in a FSJ style. So if I was the bad guy (and I'm not), how would I do it?

FSJ links to a lot of random pictures and web sites, so I presume he gets lots of emails with tips on things he could/should check out. There's nothing wrong there, but if an attacker knew this - he/she sends a message to FSJ with some juicy title that he wouldn't be able to ignore. Maybe like "SquirrelBoy found with nuts in his mouth." Or something like that. So the real FSJ clicks on the link and goes to a web page that then uses (most likely) a CSRF attack to send a request to Google using FSJ's credentials.

Remember, since FSJ is most likely still logged into Google (which is vulnerable to all sorts of XSS and CSRF attacks), the request comes from the malicious web server, but uses FSJ's credentials, as if it really came from FSJ. Once the bad folks successfully execute the CSRF then they can access and reset the account. They log into Blogspot as FSJ, change the password, add the account for Fake Bono and it's game over. The real FSJ is locked out and only Google can reset it, which usually takes days.

How do you stop this kind of very targeted, very specific attack? It's very hard and since FSJ is using Google's software, it's not like he can require a CAPTCHA or additional authentication or email confirmation of a password change. And part of FSJ's business is to check out these sites, so he'll have to be very good about logging out of Google or more likely checking out these random links within a virtualization window on his fake MacBook Pro that is NOT logged into Google (EVER).

Again, I don't know for sure that this hack was real. But it is certainly plausible.

That's all for now. I have to write some Fake Incite posts.

• Identity Management - There was lots of activity at the show, validating the choice of IdM as the subject of the first battle plan (available at the end of the month). All of the big guys (Microsoft, IBM, Sun, HP, et al) where there in force and lots of other network-security oriented vendors were talking about the linkages between IdM and network access control (NAC) in an effort to differentiate. My checks with resellers and users indicated the IdM strength is not vendor push. It's happening. Another data point was the overflowing sessions on IdM during the conference - I'm talking standing room only. IdM is hot.
  
  
• Network Access Control - A bit further off is NAC, but there was tons of activity in this space as well. The big (Cisco, Microsoft, Symantec, McAfee) and the little (ConSentry, ForeScout, Lockdown, Mirage, StillSecure, Vernier) were well represented and NAC will be the next big thing. The clear challenge for the start-ups will be to focus on clear differentiation to remain relevant. I can't recall a hot market space where the big players are delivering products, mostly home-grown, in the same timeframe as the start-up. Big is clearly the new small.
  
  
• Encryption - Scarily enough, this may actually be the year that encryption happens. Sure, there is still confusion as to what you really can do, and it's not nearly transparent enough. But the rising tide is lifting all the boats (PGP, PostX and Voltage notably) and it seems that a decent portion of that compliance budget is being allocated to rolling out crypto.
  
  
• OATH - The stand set up to demonstrate the Open Standard for Authentication seemed to be packed the entire show. There were something like 10 vendors in there demonstrating their OATH compatible solutions, and this standard is taking root. Given the momentum for IdM and NAC, the need for continued focus on the authentication part of the equation is clear.
  
  
• "Leak Prevention" - It's not clear what this category is called quite yet, but it's basically about making sure that private data and intellectual property stays where it belongs. There was a lot of activity in this space.
  
  
• Web/Application/Database Security - There is a lot of interest in boxes (and software too, I guess) that protects applications and databases from targeted attacks. This market is poised to be big in 2007, so figure next year's RSA show will have this as a prominent theme.