Chapter 21. Incident Response
Case Study: Worm Mayhem
Right around lunchtime, a help desk operator at Example, Inc. (a medium-sized manufacturing company) received a frantic call from a user who was unable to use his PC: it was continually rebooting. The user also reported that strange items had appeared on his desktop. The help desk operator was not sure whom to contact about such issues, so he tried calling his boss, but his boss was not in at the moment. The operator then opened a case in his Remedy console, describing the user’s problem and recording his machine’s hostname. Unfortunately, other calls for unrelated support issues grabbed his attention and the rebooting desktop was forgotten.
Meanwhile, the worm—which is what really caused the problems with the user’s PC—continued to spread in the company network. The malicious software was inadvertently brought in by one of the sales people who often had to plug their laptops into untrusted networks. However, most of the security-monitoring capabilities were deployed in the DMZ (or “demilitarized zone”—a somewhat inaccurate term for a semi-exposed part of the network where you place publicly accessed servers such as web, FTP, and email servers) and on the outside network perimeter, which left the “soft, chewy center” unwatched. Thus, the company’s security team was not yet aware of the developing problem.
The network traffic generated by the worm increased dramatically as more machines became infected and contributed to the flood. ...