The SQL Slammer/Sapphire worm was the biggest security event in IT since the Code Red/Nimda infections of 2001. Following the outbreak, we surveyed admins about their experiences and learned about the progress that has been made in IT security.
In January, the SQL Slammer/Sapphire worm blitzed Microsoft SQL Servers (and client machines with MSDE, the desktop version of SQL) using a creative and effective delivery mechanism that exploited a well-known flaw in SQL. In the wake of this fast-spreading infection—which bogged down Internet traffic and caused multiple denial of service events—we surveyed administrators and asked them how their company was affected by the worm and whom they blamed for this problem, among other questions.
Were you hit?
We asked TechRepublic members the general question of how SQL Slammer affected their respective companies, and 73 percent responded that they had not been hit by the worm (Figure A). Of course, since we asked this question generally, many of the respondents simply may not have had any SQL Servers or machines with MSDE installed on their network and therefore were not susceptible to the worm.
It's interesting to note that of the 27 percent of respondents who were hit, 20 percent did suffer some downtime because of the infection. But most of those respondents characterized the downtime as being "moderate" rather than "significant."
What happened to keeping up with patches?
IT administrators have been raked over the coals in recent years for not keeping software up to date with needed security patches, and many IT departments have responded by allocating more resources to patch management. However, software companies are also releasing more patches than ever, which has made the patching burden even more overwhelming for IT.
We asked those admins whose companies were hit by SQL Slammer/Sapphire why they had not deployed the patch for SQL Server that would have prevented this infection. The answers were varied, as shown in Figure B.
The encouraging thing is that only about 17 percent of respondents said that they just didn't get around to patching the well-known SQL flaw. The other respondents at least attempted to patch some of their SQL Servers with the appropriate patch prior to the outbreak of Slammer.
Ultimately, who's to blame?
When we brought up the issue of who was most responsible for the fact that this worm exploited a well-known flaw, the majority of respondents placed the blame squarely on the shoulders of administrators (Figure C).
Of course, 37 percent of respondents blamed Microsoft for either not producing secure software or not releasing quality software patches in a timely manner. In this case, those numbers seem high since Microsoft had released a patch for this flaw long before the attack was launched. That goes to show that Microsoft is often an easy and popular target.
However, the fact that Slammer also infected Microsoft's own internal systems provided some ammunition for Microsoft detractors to use against the company and helped add to the sense of Microsoft's guilt in this infection.
How does this affect Microsoft?
We also specifically asked TechRepublic members whether the fact that Microsoft was infected by Slammer had affected their view of Microsoft's ability to produce secure software, and 52 percent said that the incident had further eroded their confidence in the software giant (Figure D).
Changing security approach?
When asked whether the SQL Slammer/Sapphire incident had changed their approach to securing SQL Server, 46 percent said that they would not be making any changes (Figure E). Meanwhile, 11 percent said they are considering a move to another DBMS system. The rest claimed that they will either do a better job of keeping SQL Server updated or use a combination of firewall protection and patch management to keep SQL Server secure.
Shouldering the blame
The most significant aspect of these survey results may be that most admins have primarily placed the blame for this infection on the shoulders of admins. It's also interesting to note that, based on Figure B, admins are clearly making efforts to keep software up to date, but some are further along in the process than others.