Friday, December 21, 2007

Who do you blame?





First - take a peek at this, get over the fact that I used IE7 to take the screen shot, and then think about this: If you're a random person browing the web, hit this site and are welcomed by this error - who do you blame?




When it's time to lay blame, there are few choices on who to blame, namely:
  1. A lazy administrator
  2. Poorly written software
  3. Anonymous "bad guys"

Without a doubt, incidents like this only further throw kerosene on the flames of the old religious argument - Linux/Unix vs Windows... Sadly - I would argue that administrators of modern websites have a trio of problems - workload, software quality, and bad guys. If you're an administrator you know what I'm talking about. You've got a hundred projects or tasks and only 20hrs in a day to get it done (you have to sleep some time). Of course, the quality of modern software isn't helping anyone do their jobs better... every time you turn around you hear of another bug that has to be patched, or some default mis-configuration that has to be changed to avoid exploits. Why can't we just get quality software that's stable, bug-free, and configured securely by defaults? The last factor, and perhaps one of the only predictable ones is the bad guys. I say predictable because as an administrator you can count on being attacked, guaranteed.

I guess it's easy enough to pick on this specific goof and say "See, that's what you get for running Microsoft's software". I'm not sure I agree - the problem is, I can just as easily mis-configure a LAMP (Linux, Apache, MySQL, PHP) application component to expose my server to attack. The lesson learned here is this - anything can be misconfigured in haste or laziness. Linux is more complex, so the administrators (typically) know more because they have to be more knowledgeable to run the stuff. Windows is more point-click so the generalization that MS-admins are relatively low-skilled can hold at times. But are either of these generalizations "law"? Can you find an administrator of Microsoft systems that's just as good at security their infrastructure as a skilled Linux/Unix admin? Of course. Conversely - can you find a Linux/Unix admin that's just as inept as a bad Windows admin? Definitely.

So I come back to - who do you blame? Well - first the site is owned by a security company so a gaff like this is inexcusable. Second - if you're going to host a site on the Internet at least check your defaults, and hire a competent administrator...

Who do I blame? The admin - sorry - no matter how bad the software is you're making a conscious effort to use it, and should therefore have a strategy to keep it secure and running. As an analogy - if you buy a car that has a bad reputation of breaking down, and an overly simplistic setup without the proper tools to keep it going - it's your own fault when you break down in the middle of the motorway...

4 comments:

Cameron said...

There is also another person to blame generally and that is the business processes that are in place. Does the business allocate the admin enough time each day/week/month to check up on things? Everyone in the real world knows that things break from time to time no matter how enterprise grade or how much redundancy is built in to the device/application/database. It may well be the admin is doing the best with what he has however management has put restraints on what is allowed (be it limited time or approval processes for getting upgrades 'live')

Anonymous said...

No its the admin. On a typical IIS deployment, you should either be configuring the server to disable debugging or have a script you use for all sites to ensure the web.config file has debugging disabled.

(That's the only reason IIS is returning the source details -- normally if an exception like this is thrown, it will go to the EventLog and a normal web error returned. If debugging is enabled, then to assist the developer it gives this screen.)

Ex-hacker said...

I concur with anonymous. It is the fault of the admin. And, yes, I encounter similar error messages from JSP sites (Tomcat), PHP, and Perl. I have found issues on Linux, Windows, and MacOS (OSX, etc.) machines as well.
The buck stops with the admin. There may be blame to lay at the feet of the process and management, but ultimately, the admin is the one who must bear the brunt of the responsibility.

Mark said...

I think the biggest problem is that there's two huge red lines on the browser - I think the person who did the screen shot must have some really bad virus ;-)

Seriously though, I completely concur with Mr. Anonymous ... bugs happen. It's tough to foresee every situation - but when something like this occurs, let's not do a code dump to the screen for the entire planet to see! From a security focused website, it's quite ironic.

Google+