Case Study: Defense in Depth in Action

The Nimda worm hit the Internet on September 18, 2001, causing a costly denial of service (DoS) condition for many organizations. Nimda was unique in that it spread via several distinct methods:

• IIS exploits

• Email

• HTTP browsing

• Windows file shares

The use of several distinct propagation methods made Nimda particularly vicious, because it could infect server-server, server-client, and client-client. As a result, Nimda was able to infect the entire range of Windows operating systems.

A large international network of 10,000 servers was brought to its knees in a matter of hours because of Nimda. This organization discovered first-hand the cost of not heeding the defense-in-depth concept. Defense in depth could have mitigated Nimda.

How could this company have used the perimeter to mitigate Nimda? Using routers to preemptively block or restrict web access (HTTP) and file access (SMB) traffic in the inbound direction could have prevented infection via the first and fourth methods. A rate-limiting switch would have been able to dampen the effects of a DoS in the case of mass infections. Static filters or stateful firewalls, set up to block or restrict HTTP and SMB packets, also would have helped. Proxy firewalls, configured to block known strings within Nimda, would be effective as well. If the company had properly segregated public services on a screened subnet, few machines would have been facing the Internet. Given that Nimda achieved saturation in approximately 2.5 hours, it is safe to say that most organizations did not know of Nimda until it had penetrated their internal network. What could have mitigated Nimda on the internal network?

The internal network could have used many of the same components that the external perimeter had available, such as routers, firewalls, IDSs, and IPSs. Additionally, the internal network could have contained host-centric (personal) firewalls capable of blocking some IIS and windows file share access. The company could have attempted to use antivirus software to mitigate Nimda, although reliable antivirus signatures for Nimda were not available until the end of the day when this worm hit. Host hardening had the highest potential of success in blocking Nimda by preventing infection entirely. Nimda used an old exploit that administrators should have patched well before the worm began spreading. Had the company applied the patch, it would have stopped all four propagation methods. Additionally, this vulnerability was widely known, and regular audits would have found that the organization was open to such an attack.

A robust security policy could have also helped mitigate the spread of Nimda. Given a thought-out incident-handling procedure, sections of the network could have been isolated to patch the vulnerabilities or contain the spread of the worm. If the company had established a user-awareness program before the attacks, user behavior might have prevented infection (especially via email).

Why did Nimda run rampant when so many methods were available to mitigate its spread? Perhaps organizations had one or more important components of defense in depth missing. Perhaps organizations had the wrong pieces of defense in depth in place by focusing entirely on the perimeter while neglecting the internal network. Perhaps organizations didn't follow policy. Perhaps this particular organization and countless others like it will learn to address security before an incident rather than during or after.