Software Security Incident Response Process Case Study: Sasser
Microsoft has successfully used the Software Security Incident Response Process (SSIRP) to respond to Sasser, Download.ject, Mydoom, and many other well-publicized security incidents. The SSIRP has also helped the Microsoft Security Response Center (MSRC) address many less sensational incidents. The following describes how the MSRC used this process in response to Sasser.
On This Page
The Watch Phase
Whenever the MSRC releases a security update, the MSRC and its many partners begin watching carefully for any signs that malicious persons may be trying to exploit users who have not applied the update or workarounds. The MSRC maintains close coordination with industry partners, such as the Virus Information Alliance (VIA), independent software vendors (ISVs), Internet Service Providers (ISPs) through the GIAIS program, original equipment manufacturers (OEMs), and government organizations. This cooperation helps the MSRC ensure a coordinated, multivendor response in the case of a security incident and make certain it addresses vulnerabilities across all products that are affected, not just Microsoft products. During a security incident, the MSRC aims to provide and share timely information with partners to better understand the full impact of a security incident and consider various possible responses.
On April 13, 2004, Microsoft released security bulletins for the month, including MS04-011, an update that addressed 14 different vulnerabilities in the same set of files. The MSRC and its partners then began closely monitoring customer help lines, newsgroups, community activities, and press inquiries.
The same day, the security researcher who originally provided information about one of the vulnerabilities addressed in MS04-011 released a separate, detailed technical description of the vulnerability. As a result, the MSRC entered a heightened watch phase. Because the specific vulnerability that MS04-011 addressed could cause a crash in the LSASS service, the team began watching closely for LSASS crashes. Later in April, the first proof-of-concept code, which demonstrated how the vulnerability could be exploited, was posted online.
Alert and Mobilize Resources
On April 29, Product Support Services (PSS) noticed a sudden spike in calls and crashes in LSASS. In addition, two variants of the proof-of-concept code, now dubbed "Sasser," were reported. At this point, PSS immediately notified the MSRC, which instantly moved into the Alert and Mobilize Resources phase of the SSIRP.
The MSRC paged worldwide first responders, who quickly mobilized into two teams to evaluate the severity and gain a thorough understanding of the situation: the Emergency Engineering Team and the Emergency Communications Team.
Assess and Stabilize
The Emergency Engineering Team immediately began its investigation, testing the Sasser variants against the MS04-011 update to make sure that the update would protect against this specific exploit. The team also began testing the workarounds listed in the bulletin to ensure they too were effective against Sasser.
Because the MSRC had already addressed the vulnerability in a software update, the key initial guidance for users was to apply the update immediately. Within minutes, the Emergency Communications Team had posted this and other initial information and guidance on carefully selected areas of the Microsoft.com Web site. In addition, the team created an incident response page within the Security section of Microsoft.com that included this information. To help customers deal with the threat, the Emergency Communications Team also posted ads across the network to alert users to the issue and to direct them to more information, and it provided updated prescriptive information throughout the remaining stages of the incident response process.
Throughout the process, the Microsoft worldwide Sales, Marketing, and Services organization was provided with key information about the situation and specific instructions about contacting various stakeholders. E-mail alerts were also sent to subscribers through the security notification service.
The Emergency Communications Team also worked closely with partners to compare information about how Sasser was spreading. Within four hours, the MSRC had prepared key findings for use by PSS so staff could offer robust guidance to customers. The team also provided this information, along with support call scripts and syndicated Web content, to GIAIS and VIA partners to help them reach out to their customers.
To stabilize the situation further, the Emergency Engineering Team quickly began work on a cleaner tool to remove Sasser and any of its variants from infected systems. On May 3, the MSRC released the Sasser Worm Removal Tool v1.0 to the Microsoft Download Center. Soon afterward, the removal tool was also made available on the Windows Update Web site. The team's efforts to assess and stabilize the effects of the Sasser incident took only four days.
Resolve
From May 4 to May 10, 2004, the Sasser Worm Removal Tool was the key to a massive customer and partner effort to help clean and restore infected systems. During this period, the MSRC also hosted a Sasser Technical Webcast, hosted online support chats, and updated Microsoft Web sites. Since that time, Microsoft has continually updated the removal tool to clean for new Sasser variants.
After the Sasser incident was resolved, the MSRC led an internal review of the entire response effort to reinforce what went well and to improve the process for future response efforts. This phase of the Sasser incident, which is standard practice for any security incident, brought even more process improvement. As a result, the MSRC has developed a more mature and repeatable worldwide process.
Ongoing Process Improvement
From the initial Alert phase to the final Resolve phase of the Sasser incident, the MSRC provided timely and relevant information and resources to help protect customers. The vigilance during the first two weeks of the Watch phase, aggressive communications outreach to customers with instructions to deploy the update as soon as possible, and a clear understanding of what an LSASS attack would look like enabled the MSRC to identify and stabilize the Sasser threat before it grew out of control. In addition, through the Protect Your PC campaign that was introduced following the earlier Blaster incident, the communications team was able to encourage consumers to enable Automatic Updates and thereby diminish Sasser's impact. Notably, the MSRC was able to work through all subsequent stages of the SSIRP in just 5 days—a huge improvement over previous incidents with similar potential impact, such as the Blaster incident, which required 38 days from beginning to end.
Even with such impressive improvement, the MSRC is constantly on the alert for ways to be more proactive, further streamline its processes, and develop plans for multiple contingencies to help keep customers secure and to restore operations during future security incidents.
