S w

9B01E019

Authorized for use only in the course Lawrence Kinlin School of Business Courses at Fanshawe College taught by All Instructors from 5/1/2023 to 9/1/2023.
MICROSOFT SECURITY RESPONSE CENTER (A)

Jeffrey Clayman prepared this case under the supervision of Michael Wade solely to provide material for class discussion. The
authors do not intend to illustrate either effective or ineffective handling of a managerial situation. The authors may have disguised
certain names and other identifying information to protect confidentiality.

Ivey Management Services prohibits any form of reproduction, storage or transmittal without its written permission. Reproduction of
this material is not covered under authorization by any reproduction rights organization. To order copies or request permission to
reproduce materials, contact Ivey Publishing, Ivey Management Services, c/o Richard Ivey School of Business, The University of
Western Ontario, London, Ontario, Canada, N6A 3K7; phone (519) 661-3208; fax (519) 661-3882; e-mail cases@ivey.uwo.ca.

Copyright © 2001, Ivey Management Services Version: (A) 2009-12-18

Use outside these parameters is a copyright violation.

At 6:00 p.m. on Friday, October 13, 2000, Scott Culp, a security program manager at the Microsoft
Security Response Center (MSRC) received an e-mail from CyBER Paladin (CyP), a fairly well known
member of the hacker community. In his message, CyP said that he had run across a discussion in the
“PacketStorm” mailing list about a way to encode a command to a Web server running Microsoft’s
Internet Information Server software (IIS), that would bypass some of the security architecture. Members
of the mailing list had tried to make the idea work fully, but apparently none had succeeded, and the
discussion eventually trailed off. CyP, however, took the idea back to his system, tinkered with it, and had
figured it out.

Clearly this was serious. Literally millions of Web sites ran IIS software and every one of them was at
risk. The effect of the vulnerability was that a properly-coded command could “escape from the virtual
directory” on the server. This meant that visitors would be able to “break out” from the normal views of
Web site text and graphics, and access the server’s operating system. Once a visitor had access to the
operating system, he or she could input system commands, which effectively gave the user complete
control over the server’s operation. Users could reformat the server’s hard drive, change or modify Web
site content, steal data or install additional software on the machine, among other things.

Culp knew from experience that CyP had solid technical skills, so it was likely that the vulnerability
actually did exist. Furthermore, because CyP pulled the information off a mailing list, Culp had to treat
the information as if it was already known to the black hat community (hackers seeking to break in to
systems for malicious purposes). Something needed to be done quickly.

BACKGROUND

As long as there has been data, there have been concerns over data security. As time has progressed and
as technology has become more pervasive, these concerns have become more prevalent and potentially
more damaging. According to a 2000 study by International Data Corporation, organizations spent
US$6.2 billion on data security in 1999, and were expected to spend US$14.8 billion in 2003.
 Page 9B01E0

Of all technologies, the Internet has proven to be the greatest threat to data security. There are three main
reasons for this: scope, anonymity and reproducibility. The scope of the Internet is such that the security
of data may be compromised from virtually anywhere. The scope also refers to the vast amount of
information that may be compromised. Since it is relatively easy to become anonymous on the Internet,
the risk of detection and prosecution are lower than for other crimes. With less chance of being caught,

Authorized for use only in the course Lawrence Kinlin School of Business Courses at Fanshawe College taught by All Instructors from 5/1/2023 to 9/1/2023.
data security crimes have increased in number and severity. The ease and speed with which information
can be reproduced and disseminated makes security vulnerabilities more dangerous, more quickly than
before. Once a potential security problem is publicized, that information can be shared widely, increasing
the potential harm from the vulnerability.

A security vulnerability is generally defined as anything that offers a potential avenue of attack against a
system. There are many different types and forms of vulnerabilities, including viruses, worms,
incorrectly- configured systems, passwords written on sticky pads, and so on. The type of security
vulnerability of most interest to Microsoft was related to use of its software. Microsoft defined a security
vulnerability as a flaw in a product that makes it infeasible — even when using the product properly — to
prevent an attacker from usurping privileges on the user’s system, regulating its operation, compromising
data on it, or assuming ungranted trust.

Use outside these parameters is a copyright violation.

THE MICROSOFT SECURITY RESPONSE CENTER1

In 2001, Microsoft software operated on more than 90 per cent of the world’s computers, and so the
elimination of security vulnerabilities was a major concern. A single security vulnerability, if not handled
correctly, could affect millions of users. The Microsoft Security Response Center (MSRC) was at the
centre of Microsoft’s security infrastructure. The goal of the MSRC was to protect users by eliminating
security vulnerabilities whenever they were found in a Microsoft product or service. Since its creation, the
MSRC had eliminated over 150 vulnerabilities affecting roughly 40 Microsoft products. This was not to
suggest that Microsoft products were inherently insecure — security vulnerabilities were found in all
vendors’ products at roughly the same rate. In fact, bugs in software (only some of which affected a
system’s security) were an inherent and inevitable part of software development. However, due to the
widespread adoption of Microsoft products and services, security vulnerabilities took on a heightened
level of significance, thus, an established security infrastructure was necessary.

The MSRC was part of a large product support area. The majority of product support activity, such as
user configuration issues, bugs, compatibility issues and so on, did not affect security and, thus, were not
dealt with by the MSRC. Once a security vulnerability was identified, the MSRC worked with the
relevant product development teams to find a solution (see Exhibit 1 for a description of the MSRC
problem solving process).

SECURITY VULNERABILITY PROBLEM SOLVING PROCESS

Initial reports of security vulnerabilities come in from a number of sources. These sources included e-
mails from users and developers to Microsoft’s security e-mail address (more than 5000 were received in
2000), external mailing lists (i.e., BugTraq, NTBugTraq, Win2kSecAdvice), other product support areas
within Microsoft, and from internal security tests (often from so-called “red teams”). The first step was to

1
This case draws heavily from “A Tour of the Microsoft Security Response Center”
(http://www.microsoft.com/technet/security/sectour.asp) and “The Definition of a Security Vulnerability”
(http://www.microsoft.com/technet/security/vulnrbl.asp) both written by Scott Culp of the MSRC (2000,2001).
 Page 9B01E0

determine whether the reported problem was really a security vulnerability. More than 90 per cent of
reports were filtered out at this stage. Most of these reports resulted from user error or a failure to follow
“best practices” and, therefore, could be fixed immediately. The MSRC replied to all users, even if it
turned out that a security vulnerability were not present (the MSRC received over 10,000 e-mails in
2000).

Authorized for use only in the course Lawrence Kinlin School of Business Courses at Fanshawe College taught by All Instructors from 5/1/2023 to 9/1/2023.
If the report really did appear to identify a potential security vulnerability, the MSRC attempted to
reproduce the vulnerability on its own systems. The remaining 10 per cent of reported problems (those
that were reproduced by MSRC and not a result of user error) were classified as “potential” vulnerabilities
that required further analysis. At this stage, a formal investigation would be opened.

If a formal investigation were opened, the customer notifying Microsoft of the vulnerability would be
contacted again and provided with a tracking number in order to keep up to date with the status of the
investigation. Next, a request would be sent to the affected product or service’s development team, asking
for their help in the investigation. The development team had detailed technical knowledge of the product
or service. During the investigation, the MSRC acted as a liaison between the product team and the
customer, requesting additional information when needed and providing periodic status updates to keep
the customer appraised of the investigation’s progress.

Use outside these parameters is a copyright violation.

Just as only about 10 per cent of the reports the MSRC received became the subject of a formal
investigation, fewer than 20 per cent of the investigations revealed a bona fide security vulnerability. Of
the 600 formal investigations the MSRC conducted during the year 2000, 100 revealed bona fide security
vulnerabilities.

Three options existed for dealing with security vulnerabilities: workarounds, service packs and patches.
Workarounds were descriptions of alternate ways of using the product or service that avoided the security
vulnerability. Workarounds tended to be needed only in rare cases where a vulnerability couldn’t be
fixed through a software change, or in cases where an interim solution was required.

The majority of bona fide security vulnerabilities resulted in a software fix via either a service pack or a
patch. A service pack was a scheduled, periodic software update that corrected a large number of bugs,
including security vulnerabilities. Every fix made via a service pack was accompanied by a knowledge
base article that discussed in detail the bug and security fixes it included. These service packs were widely
promoted on the Microsoft Web site.

When a fix couldn’t wait for the next service pack, a patch was developed. A patch corrected only one
specific vulnerability. Building a patch was no easy task. The patch needed not only to eliminate the
vulnerability, but also to do so without introducing any changes in system behavior that might cause new
problems. During the first step of the process, a developer created a so-called “private build,” which
would be reviewed line-by-line by another developer. Then the private build underwent initial testing. If it
passed this testing, it would proceed to the “War Team.” This was a team of senior developers who
reviewed every proposed code change, and challenged the developer to show that the private build was
necessary, and that the engineering solution was correct. MSRC staff frequently attended War Team
meetings, to serve as advocates for the patch.

Once the War Team had accepted the private build, it would be ready for formal testing. If the patch was
simple in scope and affected few other components, testing would only take a few days. More complex
patches would take up to a week to fully test. However, if the patch made changes that affected how other
vendors’ products interacted with the Microsoft product, it would be necessary to conduct full
compatibility testing with a number of other products, which could take weeks. This was necessary since
Page 9B01E0

Microsoft products ran on thousands of different hardware platforms, in conjunction with millions of
third- party products, and in countless different scenarios.

Once the patch was developed and tested, it would be released. First, an installer package had to be built
that would put the new code into the proper location on each customer’s machine, make any needed

Authorized for use only in the course Lawrence Kinlin School of Business Courses at Fanshawe College taught by All Instructors from 5/1/2023 to 9/1/2023.
changes to the system configuration, and record information that let the customer uninstall the patch if
needed. Typically, a separate installer package had to be developed for each version of the affected
product. When all of the packages had been built, they were digitally signed by Microsoft (to ensure
authenticity), and then retested. Security bulletins, which informed the user about the vulnerability and
the fix, (without providing too much information that could be exploited by malicious users) were also
written for each patch. The number of bulletins released by Microsoft between 1997 and 2000 are shown
in Exhibit 2.

Once the patch, security bulletin and knowledge base article were ready for release, they would be
distributed (see Exhibit 3 for an example of a security bulletin). The patch would be posted to the
Microsoft Download Center or the Windows Update site, the security bulletin would be placed on the
Microsoft TechNet Security Web site, and the knowledge base article would be published on the
Microsoft Web site. Next, the bulletin would be sent to more than 130,000 subscribers via the Microsoft

Use outside these parameters is a copyright violation.

Product Security Notification Service. Once the information was public, the MSRC worked with a variety
of media outlets to provide timely, accurate information for any news articles that would be written.

At any given time, the MSRC was likely to have 25 or more ongoing investigations, and 15 or more
patches underway. Each patch was estimated to cost Microsoft more than US$100,000.

CURRENT PROBLEM

Culp realized that this issue required his immediate attention, and probably the attention of others, too.
Unfortunately, because it was Friday night, most Microsoft employees had already gone home for the
weekend. Culp contacted the team that ran the Microsoft Web site and asked them to try to reproduce
Rain Forest Puppy’s findings. He also started calling the IIS development team to get their take on the
situation, and possibly get them back into the office.

By 9:00 p.m., the Microsoft.com folks had duplicated CyP’s findings. The vulnerability was legitimate.

Time was short. In his message, CyP said that he planned to post his findings publicly “within a few
days.” Since the information was already public (he had discovered it on a message board), CyP argued
that it was probable that someone else had figured out how to exploit the vulnerability, as he had done.
That person (or people), he argued, could already be compromising Web sites running IIS software.
Therefore, CyP wanted to warn system administrators as soon as possible of the risks. The problem with
this logic, Culp knew, was that knowing about the problem would not help system administrators to solve
the problem. Only a patch could do that, and as of yet, none was available.

Now that he knew something about the problem, Culp wondered what should be done, who should be
told, and when.
Page 9B01E0

Exhibit 1

MSRC STEPS IN SOLVING PROBLEMS

1. Obtain information about possible security problems through:

Authorized for use only in the course Lawrence Kinlin School of Business Courses at Fanshawe College taught by All Instructors from 5/1/2023 to 9/1/2023.
 secure@microsoft.com — e-mail address that goes directly to an on-duty officer at MSRC
 Product Support Services — internal Microsoft department that users call to seek help or
to provide feedback
 internal security tests — done throughout the development phase — sometimes testing a
product in development will reveal an issue in a version already used by the public
 external mailing lists (e.g., BugTraq, NTBugTraq)
 external Web sites - MSRC employees patrol hacker Web sites

2. Perform Initial Triage

 removes reports that are due to user error or poor documentation
 reports are filtered by
- working with customers to gather more information on the problem

Use outside these parameters is a copyright violation.

- testing the user’s reported configuration
- informing the user of patches or workarounds already released
 this resolves about 90 per cent of reports — the other 10 per cent are not yet
vulnerabilities and require further investigation

3. Involve Product Team

 product teams are usually more familiar with the code since they are the group who
actually designed the product
 about 10 per cent of the reports that reach this stage are not the result of user error, bad
documentation, or a failure to follow “best practices” and, therefore, may cause problems
in all copies of the program
 at this point, the issue is labelled as a security vulnerability

4. Devise Solution Alternatives

 Server-side fixes
- used for Web-based applications (e.g., Hotmail, MSN.com, HomeAdvisor)
- server-side fixes for general purpose bugs occur continually and are only publicized if
the problem becomes a matter of public concern

 Fix in service-packs
- used when there is no imminent threat of danger — vulnerabilities get changed in the
next version update of the application
- this is the preferred method of fixing since fuller testing can be done
- also, a service-pack fix can remedy many problems, while patches or workarounds
(see below) can only remedy one problem
- a service-pack fix can also include previous patches or workarounds
 Page 9B01E0

Exhibit 1 (continued)

 Patches
- used when the vulnerability needs to be fixed immediately — patches are driven by
time and not test level

Authorized for use only in the course Lawrence Kinlin School of Business Courses at Fanshawe College taught by All Instructors from 5/1/2023 to 9/1/2023.
- a patch remedies the immediate problem, but only that problem — it is intended to
keep customers safe until they can apply the next service pack
- requires much testing since it must work on millions of personal computers using
millions of configurations
- security bulletins and knowledge base articles are released along with every patch

 Workarounds
- provide the user with an alternate method of using a product that prevents a
vulnerability from being exploited
- used when patches cannot be provided (i.e., a vulnerability involving a product’s
installation process can’t be patched, since the product would need to be installed
already in order to apply the patch)

Use outside these parameters is a copyright violation.

- security bulletins and knowledge base articles are released along with every
workaround

5. Implement Solutions
 Bulletins
- written by MSRC
- 100 bulletins were released in 2000
- goal of writing them is to get the most amount of information to the public by telling
the public what the problem is, what could happen, and how to protect themselves
- caution is taken not to release too much information so that hackers can’t exploit the
vulnerabilities

 Knowledge base articles

- written by Product Support Services
- always accompany a bulletin
- provides more technical information than a bulletin

 Dissemination of patches and workarounds

- placed on MS Web site
- mailed out to MS security listserver, which is a mass e-mail to over 100,000
subscribers
- must be created in more than 70 languages, and compatible with different programs
and back versions

6. Press Response
 further information provided upon request to media outlets
 some reporters are personally called and updated on the situation

Source: Microsoft Security Response Center, July 17, 2001.

 Page 9B01E0

Exhibit 2

PATCHES BY YEAR OF RELEASE FOR THE OFFICE SUITE

Authorized for use only in the course Lawrence Kinlin School of Business Courses at Fanshawe College taught by All Instructors from 5/1/2023 to 9/1/2023.
1997 1998 1999 2000
Outlook
Total 6 35 29 32
Security related 0 1 2 9
Word
Total 6 14 33 36
Security related 0 0 6 11
Excel
Total 3 19 40 30

Use outside these parameters is a copyright violation.

Security related 0 0 6 10
PowerPoint
Total 6 14 22 27
Security related 0 0 4 8
Access
Total 3 16 25 18
Security related 0 0 2 4
FrontPage
Total 0 5 14 19
Security related 0 0 3 5
Total Security Bulletins 0 1 23 47

Source: Microsoft Security Response Center, July 17, 2001.

Page 9B01E0

Exhibit 3

EXAMPLE OF A SECURITY BULLETIN

Authorized for use only in the course Lawrence Kinlin School of Business Courses at Fanshawe College taught by All Instructors from 5/1/2023 to 9/1/2023.
Microsoft Security Bulletin (MS00-057)

Patch Available for "File Permission Canonicalization" Vulnerability

Originally posted: August 10, 2000

Summary

Microsoft has released a patch that eliminates a security vulnerability in Microsoft® Internet
Information Server. Under very restricted conditions, the vulnerability could allow a malicious
user to gain additional permissions to certain types of files hosted on a web server.

Use outside these parameters is a copyright violation.

Issue

A canonicalization error can, under certain conditions, cause IIS 4.0 or 5.0 to apply incorrect
permissions to certain types of files. If an affected file residing in a folder with restrictive
permissions were requested via a particular type of malformed URL, the permissions actually
used would be those of a folder in the file’s parentage chain, but not those of the folder the file
actually resides in. If the ancestor folder’s permissions were more permissive than those of the
correct folder, the malicious user would gain additional privileges to the affected file.

The vulnerability is subject to several significant restrictions:

 It only affects CGI scripts and file types that are implemented via ISAPI extensions. It does
not affect static web page or non-web file types such as .exe, .doc or .bat
 It only affects servers that expose a web folder structure that mirrors the physical folder
structure on the server.
 It does not allow arbitrary permissions to be selected, only permissions present on an
ancestor folder
 It provides no way to enumerate the server and locate files that could be affected by the
vulnerability.

Affected Software Versions

 Microsoft Internet Information Server 4.0
 Microsoft Internet Information Server 5.0

Patch Availability
 Microsoft Internet Information Server 4.0
 Microsoft Internet Information Server 5.0

Note: Additional security patches are available at the Microsoft Download Center
 Page 9B01E0

Exhibit 3 (continued)

More Information

Please see the following references for more information related to this issue.

Authorized for use only in the course Lawrence Kinlin School of Business Courses at Fanshawe College taught by All Instructors from 5/1/2023 to 9/1/2023.
 Frequently Asked Questions: Microsoft Security Bulletin MS00-057
 Microsoft Knowledge Base (KB) article Q269862,
 Microsoft TechNet Security web site,

Obtaining Support on this Issue

This is a fully supported patch. Information is available by contacting the Microsoft Product
Support Services Web site.

Acknowledgments

Microsoft thanks Burt Abreu & Søren Skov of VBExplorer.com for reporting this issue to us and

Use outside these parameters is a copyright violation.

working with us to protect customers.

Revisions

 August 10, 2000: Bulletin Created.

The information provided in the Microsoft knowledge base is provided “as is” without warranty
of any kind. Microsoft disclaims all warranties, either express or implied, including the
warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft
corporation or its suppliers be liable for any damages whatsoever including direct, indirect,
incidental, consequential, loss of business profits or special damages, even if Microsoft
corporation or its suppliers have been advised of the possibility of such damages. Some states do
not allow the exclusion or limitation of liability for consequential or incidental damages so the
foregoing limitation may not apply.

Source: Microsoft Security Response Center, July 17, 2001.