Unless you’ve been on vacation to some exotic is= land with no phones or Internet access for the last couple of weeks and just got back today, you’re no doubt well familiar by now with the W32/SQLslam= mer worm that broke out early Saturday morning and slowed the Internet to a cra= wl for several hours. If you were fortunate, you weren’t running SQL Ser= ver 2000 and therefore got to watch the whole situation unfold without worrying about your own network. If you were one of the unfortunate, you were not on= ly running SQL Server 2000, but you also had not patched your servers and were infected.
It’s human nature to want to assess blame, and s= o many of the discussions I’ve seen have centered on “whose fault is it that this happened?” Unfortunately, it also seems to be human nature = to want to avoid accepting responsibility and point the blame at others, and we’re seeing a lot of that as well. After thinking about it, the prob= lem isn’t so much that any one group is to blame, but rather everyone sha= res some of the blame. Since this is a good situation to use as an example of t= he challenges of systems administration, let’s look at the differing vie= ws of fault in this fiasco.