Lessons From the Slammer January's Slammer infection held valuable lessons for all security stakeholders.
By Richard Forno Feb 05, 2003 � 2003 Securityfocus. http://online.securityfocus.com/columnists/140 The rapid spread of W32.SQLExp.Worm, more commonly known as Slammer, demonstrates yet again several glaring problems with the state of Internet security today. In so doing, it again raises the question of when, if ever, we will see positive improvements to our collective security posture. This is particularly evident as the mass media is focused on the Slammer exploit itself but it refuses to ask the tough questions needed to address the issues. Sure, we know that Slammer targeted SQL servers running on Microsoft Windows. We know that Slammer consumed network bandwidth around the world as its spurious packets were transmitted globally. We know that system administrators did not apply patches that had been available for some time. And we know that several American critical infrastructures - some bank ATMs, a 911 service in Bellvue, Washington, and allegedly some aircraft - were affected by it. Lesson Number One That's the first, and most important, lesson we need to learn from Slammer. Critical infrastructures? What were critical infrastructure systems doing being connected to the public Internet in the first place? You'd think by now that if something is deemed critical to society, security should always outweigh convenience ... and that includes maintaining separate networks for such critical systems, even if it costs more. Such costs must be accepted if a system is to be deemed critical, otherwise we're just kidding ourselves. In responding to Slammer, let's forget the incessant race to patch flawed software. Let's leave aside the inclination to point fingers at hackers, crackers, terrorists, and complacent system administrators. There is a more egregious security problem: namely, that we bring these incidents upon ourselves by making it not only easy but also convenient for a bad guy to cause mischief. Unfortunately, this major shortcoming continually gets overlooked by the media and government officials who are quick to point out the need to simply continue patching our software, preferring a passive approach to vulnerability remediation, instead of an active one. Lesson Number Two In his farewell address to the IT community, outgoing White House Cybersecurity Advisor Richard Clarke correctly prophesized that "as long as we have vulnerabilities in cyberspace and as long as America has enemies, we are at risk of the two coming together to severely damage our great country." But if history is any indicator, his words will go unheeded, and we'll continue seeing major network attacks in the future, including ones that disrupt or disable critical infrastructure systems. Furthermore, when things do go wrong because of complacency, nobody's going to be held accountable for their actions � or lack thereof. Whether it's a vendor who produces repeatedly exploitable code, a lazy system administrator who fails to keep his systems in proper order, an incompetent security manager, or a executive-level officer who refuses to provide IT staff with the necessary resources to ensure proper security, unless personal accountability is forced onto security stakeholders, there will be no incentive for them to really improve the security of their systems. This is the second lesson to be learned from Slammer. Granted, it's next to impossible to effect total security, but there is a great deal that needs to be done as we strive toward that noble goal. Unfortunately, few, if any, people have been fired or officially sanctioned for their failure to create a secure environment. Perhaps more troubling yet, such incidents seem to be viewed as the price of doing business in the Information Age. Lesson Number Three But it's not all bad, though. Slammer forced Microsoft's Product Activation Servers off-line for a while, and users were unable to register their copies of Windows XP or Office XP to allow their full use as networked computers. So for a brief, shining moment - in Internet time, at least - Slammer actually increased the security posture of the Internet, by not allowing easily exploited hosts to be connected to it. And that's the third lesson from Slammer. In all seriousness, though, the trend toward relying on broadband connections to centralized remote servers (or server farms) for product activation, authentication, or functionality may be convenient for vendors and their bottom line; unfortunately, it provides an easy single point of failure that could seriously limit our ability to function in cyberspace, regardless of whether we're a large company or a lone end user. Will such server farms be deemed a "critical" infrastructure system as a result? If so, we're back to Lesson Number One - at which time, security professionals should think seriously about a new line of work. Here endeth the Lesson. # # # # Richard Forno is the coauthor of Incident Response (O'Reilly) and The Art of Information Warfare (Universal). He helped to establish the first incident response team for the U.S. House of Representatives, and is the former Chief Security Officer at Network Solutions. Richard is currently writing and consulting in the Washington, DC area. -- You are a subscribed member of the infowarrior list. Visit www.infowarrior.org/lists for list information or to unsubscribe. This message may be redistributed freely in its entirety.
