Internet Explorer 8 and the Security
Development Lifecycle
By Mark Shlimovich
February 27, 2010
For the latest information, please see http://www.microsoft.com/sdl
Abstract
Creating a functional and more secure Web browser is a tremendous challenge
that all browser vendors face. To confront this challenge, Microsoft has
proactively embedded security into every stage of the Windows® Internet
Explorer® 8 software engineering process by using the Security Development
Lifecycle (SDL). By requiring all products to adopt the SDL, Microsoft has made
security a part of its engineering culture and a top priority for every engineer.
This white paper offers a case study that describes how the Internet Explorer
team has applied the SDL to Internet Explorer 8.
The information contained in this document represents the current view of Microsoft Corporation on
the issues discussed as of the date of publication. Because Microsoft must respond to changing
market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and
Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR
IMPLIED, IN THIS SUMMARY.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the
rights under copyright, no part of this document may be reproduced, stored in, or introduced into a
retrieval system, or transmitted in any form, by any means (electronic, mechanical, photocopying,
recording, or otherwise), or for any purpose, without the express written permission of Microsoft
Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property
rights covering subject matter in this document. Except as expressly provided in any written license
agreement from Microsoft, the furnishing of this document does not give you any license to these
patents, trademarks, copyrights, or other intellectual property.
Unless otherwise noted, the example companies, organizations, products, domain names, e-mail
addresses, logos, people, places, and events depicted herein are fictitious, and no association with any
real company, organization, product, domain name, e-mail address, logo, person, place, or event is
intended or should be inferred.
© 2010 Microsoft Corporation. All rights reserved.
Microsoft, ActiveX, Internet Explorer, Visual Studio, Windows, Windows Server, and Windows Vista are
trademarks of the Microsoft group of companies.
The names of actual companies and products mentioned herein may be the trademarks of their
respective owners.
Internet Explorer 8 and the Security Development Lifecycle
TABLE OF CONTENTS
The Evolving Threat Landscape .................................................................1
The Training Phase ......................................................................................2
The Requirements Phase ............................................................................2
The Design Phase .........................................................................................2
The Implementation Phase ........................................................................6
The Verification Phase ................................................................................7
The Release Phase........................................................................................9
The Response Phase ................................................................................. 10
Conclusion ................................................................................................. 11
Additional Resources ............................................................................... 11
Acknowledgments .................................................................................... 11
Internet Explorer 8 and the Security Development Lifecycle
THE EVOLVING THREAT LANDSCAPE
Microsoft has worked hard to improve the security of its platforms and use of the SDL has shown
encouraging results. Partially as a result of this, the industry has witnessed a migration of attacks up the
stack into the application layer. According to the Microsoft Security Intelligence report, more than 90
percent of vulnerabilities disclosed in the first half of 2008 affected applications rather than operating
systems.
Similarly, after a significant security effort in Internet Explorer 7, the Internet Explorer team has seen realworld browser-based threats migrate further into third-party browser extensions such as ActiveX®
controls. During this time, the Internet Explorer team has witnessed an increased exploitation of Web
application vulnerabilities including SQL injection, cross-site request forgery (XSRF), cross-site scripting
(XSS), and social-engineering attacks such as phishing.
The Internet Explorer team worked vigorously during the development of Internet Explorer 8 to improve
its security, but did not lose sight of the fact that a significant portion of the attack surface of the browser
is third-party code. This meant that the team had to consider not only the threat model of the browser
itself, but also the threat models of third-party browser extensions and the Web applications that the
browser accessed. The increased focus on Web application security in Internet Explorer 8 has led to new,
proactive defense-in-depth for Web applications, and APIs that make it easier for developers to create
more secure Web applications. For ActiveX browser extensions, the per-site ActiveX Opt-in feature
provides additional proactive attack surface reduction. Although the Internet Explorer team forecasted an
increased exploitation of ActiveX controls and Web applications at the beginning of the Internet Explorer
8 development cycle, it could not predict all emerging classes of threat in advance.
To stay abreast of new and emerging threats throughout the development cycle, the Internet Explorer
team worked closely with researchers in the security community. Clickjacking is an example of a previously
obscure threat that was popularized during the Internet Explorer 8 development cycle by Jeremiah
Grossman and Robert Hansen. How the Internet Explorer team added a new feature late in the
development cycle to address this newly discovered threat is described later in this paper.
There are two key points to emphasize:
1.
2.
The evolving threat landscape guides the Internet Explorer team’s security efforts.
To keep users more secure as the threat moves up the stack to the application layer, the Internet
Explorer team must collaborate with third-party developers.
Microsoft is constantly evolving both the SDL and its products to address emerging security challenges.
Microsoft is also making resources and tools available so that third-party developers can benefit from its
experience of applying the SDL and deploy Web applications that take advantage of all of Internet
Explorer 8’s defenses.
The following image shows the stages in the SDL.
Internet Explorer 8 and the Security Development Lifecycle
1
THE TRAINING PHASE
Since Bill Gates’ Trustworthy Computing memo of 2002, Microsoft has been driving a cultural shift and
educational effort to make security and privacy “part of our DNA.” All engineers are required to
understand the fundamental security principles and practices that apply to their discipline. Available
training courses span a wide array of topics such as ActiveX, Security Basics, Buffer Overflows,
Cryptography, Trustworthy User Experiences, Fuzz Testing, and Threat Modeling.
THE REQUIREMENTS PHASE
Forming a Security Team
To drive the SDL, the Internet Explorer team created a virtual security team. This Security team was
responsible for creating and executing the security plan, participating in threat model reviews, prioritizing
security vulnerabilities, and reviewing all security vulnerability resolutions to ensure that important
security vulnerabilities were fixed. Although the Security team was responsible for driving the SDL, the
team recognized that success would not be possible without the participation of the entire product team.
Creating a Security Plan
The Security team created a document called “Security Guardrails” that described the overall Internet
Explorer 8 security requirements and goals, and provided guidance based on the SDL to feature teams. A
key emphasis of “Security Guardrails” was that, although the Security team was available to help the
feature teams, it was ultimately the responsibility of the feature teams to secure their own features. When
schedule pressure made it tempting to cut corners, the feature teams’ initial agreement to “Security
Guardrails” helped to ensure that they did not sacrifice security investments.
THE DESIGN PHASE
Threat Modeling Internet Explorer
Before the coding of any new feature began, each feature team was required to hold a threat model
analysis (TMA) meeting. A TMA meeting would consist of a review of the threats that applied to the
feature, in addition to identifying and planning possible mitigations for those threats. The relevant feature
team and members of the Security team attended each TMA meeting. A TMA meeting would begin with
the Program Manager (PM) of the feature walking through the new functionality to ensure that everyone
involved had a clear understanding of the new feature. The TMA meetings also included an introductory
discussion and brainstorm of the security test plans for the feature.
In addition, the TMA meeting reviewed any unmitigated threats to ensure that any risk they exposed was
acceptable. Following the SDL bug bar, any vulnerabilities with Moderate, Important, or Critical security
ratings must be mitigated.
Threat Modeling Web Applications and Extensions
In Internet Explorer 8, the Internet Explorer team increased its focus on Web application security. By
considering the threat model for Web applications and extensions, the team was able to identify several
new features that could help improve the overall security of a user’s browsing experience.
Internet Explorer 8 and the Security Development Lifecycle
2
Attack Surface Reduction: Creating Secure Primitives for Mashups
To enable cross-site integration scenarios today, many sites work around the cross-domain restrictions by
integrating script and HTML content obtained from third parties into their pages. Unfortunately, such
techniques often result in an increased security exposure for the consuming Web application.
In Internet Explorer 8, the team added several new features to enable secure cross-site communication.
While designing these features, the team worked to minimize the attack surface of Web applications and
to minimize changes to the browser security footprint.
An example feature is the cross-domain request object, XDomainRequest (XDR), introduced in Internet
Explorer 8. The design of this feature had to mitigate a number of threats. For example:
 Although allowing Web pages to reuse the user’s cookies and credentials on cross-domain requests
enables certain authenticated mashup scenarios, doing so could expose sites to cross-domain privilege
escalation threats including cross-site request forgery. Internet Explorer 8 mitigates these threats by
prohibiting cross-domain requests from carrying the user’s cookies and credentials.
 Most sites today rely on the same-origin security principle, so the design of the feature had to ensure
that the introduction of cross-domain requests in the browser did not introduce vulnerabilities to
existing sites. This is done in two ways:
– The target server must explicitly mark responses to XDR-generated requests to allow the caller to
receive them.
– It must not be possible for XDR to generate requests that cannot already be sent by previouslyexisting HTML features (e.g. IMG and FORM tags). This means that there is no increase to the
scope of cross-domain requests that a page can issue.
As a result, existing sites that do not opt in to XDR remain completely unaffected and their threat
model stays the same. Existing sites that opt in to XDR have the same security exposure as is already
granted to an anonymous Internet user. These two key design decisions ensured that XDR did not
expose existing Web applications to new threats.
The widespread use of the JavaScript object notation (JSON) data format has introduced another threat.
Many sites contain logic that eval()s (executes) script that contains potentially untrusted data, increasing
the security exposure of those Web applications. To help Web application developers mitigate the threat
of cross-site scripting, while still enabling them to take advantage of the convenience of using JSON in
cross-domain scenarios, Internet Explorer 8 includes native methods accessible from JavaScript that
perform secure JSON serialization and deserialization (JSON.stringify() and JSON.parse()). These
methods enable developers to mitigate this class of XSS attacks. Similarly, for HTML that is retrieved from
third-party domains, Internet Explorer 8 provides the toStaticHTML() function, which removes event
attributes and script from untrusted HTML to help prevent XSS vulnerabilities.
Attack Surface Reduction: Per-Site ActiveX
As browser security has improved, there has been an increased exploitation of vulnerabilities in third-party
browser extensions. Today, most browser compromises occur through the exploitation of vulnerable
extensions.
Internet Explorer 8 introduced the new per-site ActiveX feature to help prevent the malicious repurposing
of ActiveX controls. Using the per-site ActiveX feature, only the site installing a control can use that
Internet Explorer 8 and the Security Development Lifecycle
3
control by default. When a user browses to a different site, the control is disabled by default. An
Information Bar enables the user to enable the control, if desired.
Defense in Depth: XSS Filter
To counter the prevalence of XSS vulnerabilities in Web applications, the Internet Explorer team decided
to invest in an XSS Filter feature for Internet Explorer 8. This feature provides proactive defense in depth
to help secure users even when they are visiting vulnerable sites. The XSS Filter provides defense in depth
against Reflected XSS, which is the predominant class of XSS attacks on the Web today. This is an example
of layered defense implied by the principle of defense in depth; even if one security mechanism fails (in this
case, any of the measures taken by the Web application), the design of Internet Explorer 8 means that
there are additional layers of security that can prevent the successful exploitation of vulnerabilities.
Defense in Depth: Using URL Reputation to Block Known Downloads of Malicious Software
To make trust decisions simpler and more secure, the Internet Explorer team revisits the Trust user
experience (UX) and listens to feedback from users at every release of Internet Explorer. The design of the
Trust UX follows several guiding principles:
1.
2.
3.
Users must understand that they are being asked to make a trust decision.
Users must understand the implications of their trust decisions.
The information presented to users must be accurate.
To help mitigate the possibility of users accidentally installing malicious software (also called malware) in
Internet Explorer 8, the Internet Explorer team developed the SmartScreen Filter, which builds on the
Phishing Filter in Internet Explorer 7. SmartScreen is URL reputation–based and enables protection from
unknown threats issuing from known malicious sites. This new feature helps prevent users from
downloading and running malicious software from sites known to host malicious content.
After the Internet Explorer team released Internet Explorer 8 Beta 2, the team received feedback that the
blocking page used to impede navigation to dangerous sites was too easy for users to “click through.”
Using this feedback, the Internet Explorer team redesigned the blocking page to clarify the recommended
next step for the user.
Balancing Security with Application Compatibility
Security improvements that must modify the way in which existing features work are often at odds with
compatibility requirements. This is because legacy applications may depend upon the precise functionality
that is being changed. Unless new browser versions provide compatibility with previous versions, users
and organizations are unlikely to upgrade, thus losing all of the benefits offered by the enhanced security
features in the new version.
Data Execution Prevention/No Execute (DEP/NX) is a powerful Windows® feature that helps mitigate
various memory-related vulnerabilities. For compatibility reasons, this option was not enabled by default
in Internet Explorer 7. This has changed in Internet Explorer 8, and the browser now enables this option by
default. Later on, this paper describes how the Internet Explorer team solved this compatibility problem in
Internet Explorer 8.
Internet Explorer 8 and the Security Development Lifecycle
4
Mitigating a Newly Discovered Threat: Clickjacking
Late in the Internet Explorer 8 development cycle, the Internet Explorer team became aware of a new
threat called clickjacking, which malicious sites could exploit in all modern Web browsers. This attack
works by tricking the user into interacting with embedded cross-origin content.
A common feature of all clickjacking variants is that they depend on the browser allowing the victim site’s
content to be loaded into a frame by a malicious page. Many sites on the Internet today rely on this
capability to host cross-domain content inside frames, so compatibility requirements mean that the
browser cannot prohibit this behavior. Instead, Internet Explorer 8 offers the X-FRAME-OPTIONS HTTP
response header, enabling Web sites to control how other sites can frame them. For more information
and examples of clickjacking, in addition to detailed guidance on mitigating the clickjacking threat by
using the X-FRAME-OPTIONS header, see Clickjacking Defense in IE8 on the SDL blog and IE8 Security
Part VII: ClickJacking Defenses on the Internet Explorer blog.
The clickjacking mitigation in Internet Explorer 8 uses an opt-in mechanism to disable browser capabilities
that, for application compatibility reasons, Internet Explorer 8 could not unconditionally disable.
MIME-Handling Improvements
Each type of file delivered from a Web server has an associated Multipurpose Internet Mail Extensions
(MIME) type that describes the nature of the content (for example, image, text, or application). For
compatibility reasons, Internet Explorer has a MIME-sniffing feature that will attempt to determine the
content type for each downloaded resource. Several legacy servers on the Web depend on MIME sniffing
to operate properly. Unfortunately, MIME sniffing can introduce a persistent XSS attack vector in servers
hosting untrusted content, enabling the attacker to assume control of a trusted site. The MIME-sniffing
feature made it difficult to host untrusted content securely on a trusted domain. To combat this problem,
the Internet Explorer team made several improvements to the MIME-type determination mechanisms in
Internet Explorer 8.
One improvement enables Web applications to opt out of MIME sniffing. Sites hosting untrusted content
can use the X-Content-Type-Options: nosniff header to ensure that Internet Explorer 8 does not sniff
files to any other MIME type. Additionally, files of type image/* will never be sniffed to an HTML or XML
type, increasing protection by default.
Another improvement impacts Web applications that need to serve untrusted HTML files. Internet
Explorer 8 introduces an opt-in mechanism to help prevent the untrusted content from compromising the
site’s security. When the new X-Download-Options header is present with the value noopen, Internet
Explorer prevents users from opening a file download directly. Instead, they must first save the file locally,
preventing persistent cross-site scripting from the untrusted HTML file.
These opt-in security defenses can help Web applications to mitigate the threat of persistent cross-site
scripting through the hosting of untrusted files.
Internet Explorer 8 and the Security Development Lifecycle
5
THE IMPLEMENTATION PHASE
Secure Development Best Practices
Banned APIs
The SDL identifies a set of banned application programming interfaces (APIs) in the C Runtime Library.
The SDL prohibits their use because, used incorrectly, they can result in memory-safety issues.
Most of these are string functions that can result in buffer overruns and format string vulnerabilities, but
they also include some other function types. By prohibiting the use of all of these error-prone functions in
Internet Explorer’s code base, the Internet Explorer team has reduced the number of potential buffer
overflows and other common security problems. 1
Static Analysis Tools
Static analysis tools analyze source code to discover potential vulnerabilities without executing the code.
During implementation, the Internet Explorer team used static analysis extensively to highlight potential
security issues:
 PREfast is a lightweight static analysis tool that discovers vulnerabilities in C and C++ code. Developers
run PREfast on their code before checking it in to the central source tree and must fix a set of issues
that it discovers. These include memory-safety vulnerabilities, integer overflow vulnerabilities, and
others.2
 PREfix is a static analysis tool that the Internet Explorer team deploys in its build labs. PREfix detects a
wide array of memory-safety vulnerabilities, in addition to use of potentially untrusted format strings,
and several other classes of vulnerabilities. PREfix finds vulnerabilitiesthat the team might not find
through dynamic testing. The SDL considers the set of warnings reported by PREfix that correlate
strongly with security vulnerabilities as must-fix vulnerabilities.
Exploit Mitigations
Address Space Layout Randomization
Address space layout randomization (ASLR) provides protection against memory-safety related exploits.
Starting with Internet Explorer 7 in Windows Vista® and Windows Server® 2008, the Internet Explorer
process and libraries are linked with the /DYNAMICBASE flag that enables ASLR on Windows Vista and
beyond. However, ASLR only provides a robust mitigation against memory-safety vulnerabilities when
coupled with DEP/NX, which Internet Explorer 8 now enables by default.
Data Execution Prevention (DEP/NX Permanent)
Internet Explorer 8 enables DEP/NX by default on supported platforms. Internet Explorer 7 could not
enable DEP/NX by default because enabling it impaired compatibility with some older browser extensions.
1
For information about the Safe CRT libraries, see the MSDN Magazine article, Repel Attacks on Your Code with the Visual Studio
2005 Safe C and C++ Libraries by Martyn Lovell.
2
PREfast technology (called /analyze) is included in Microsoft® Visual Studio® Team Edition for Software Developers.
Internet Explorer 8 and the Security Development Lifecycle
6
A new Windows feature called ATL Thunk Emulation enables Internet Explorer 8 to address this
compatibility concern. On the platforms that support the new SetProcessDEPPolicy API, Internet Explorer 8
will run with DEP/NX Permanent on by default.
This is a significant security improvement for Internet Explorer 8, and the Internet Explorer team expects
that, combined with ASLR, this will counteract most of the techniques used today to exploit memorysafety-based security vulnerabilities.
/GS Stack Protection
Internet Explorer 8 is also compiled with /GS to help mitigate stack-based buffer overflows. Although /GS
makes it significantly harder to successfully exploit a stack-based buffer overflow vulnerability, several
techniques to bypass /GS have been discovered. To help mitigate these /GS bypasses, the Internet
Explorer team has combined /GS with other mitigations to increase significantly the difficulty of exploiting
stack-based buffer overflows.
One technique that has been discovered to be a reliable mechanism for bypassing /GS stack protection is
to overwrite a structured exception handler that is stored on a thread’s stack using a stack-based buffer
overflow. To help mitigate this threat, all binaries in Internet Explorer are linked with /SAFESEH to enable
Safe Structured Exception Handlers.
THE VERIFICATION PHASE
TruScan
The Internet Explorer team takes advantage of dynamic program verification tools to help detect security
vulnerabilities. The Internet Explorer team performs dynamic binary instrumentation on test runs to
capture instruction-level traces of Internet Explorer’s program execution. The Internet Explorer team then
runs these instruction-level traces through the internal TruScan tool. The TruScan tool detects several
implementation-level vulnerability patterns that often result in security vulnerabilities, such as the use of
uninitialized memory, buffer overruns, and race conditions. TruScan is similar to other memory debuggers
such as Valgrind,3 which use a virtual machine to perform dynamic binary instrumentation.
The Internet Explorer team uses TruScan on all automated test runs, in addition to using it on many
manual test runs. Doing this enables the Internet Explorer team to maximize code coverage.
Although dynamic verification techniques such as running TruScan on traces are very useful for detecting
issues in running code, such tools can only uncover vulnerabilities that are encountered while running the
test cases. The static analysis tools mentioned earlier complement dynamic verification by considering
code paths that are difficult to exercise in practice.
Application Verifier
Application Verifier (AppVerifier) monitors native-code application behavior. These checks include several
security-related checks such as detecting heap corruption, the hiding of potentially dangerous access
violation exceptions using structured exception handling, and the incorrect usage of critical sections.
During the verification phase, Internet Explorer testers run all of their test cases (both manual and
3
See http://valgrind.org/.
Internet Explorer 8 and the Security Development Lifecycle
7
automated) with AppVerifier enabled. From a security perspective, the most important check that
AppVerifier enables is the PageHeap4 check, which detects several heap-related memory-safety issues
including heap corruption, double-frees, use-after-free, and unsynchronized heap access.
Fuzz Testing
Fuzz testing is a testing technique that supplies random data as program input to detect erroneous
conditions including crashes related to security and reliability. During fuzz testing, the program is run in
an automated debugging session to capture information about any faults that occur. All fuzz tests are run
with AppVerifier enabled.
Fuzzers are generally classified on two primary axes:
 Smart versus Dumb. Smart fuzzers are protocol-aware and can often achieve better code coverage by
satisfying certain branch conditions such as input-validation checks that may otherwise prohibit
completely random data from passing into potentially vulnerable code paths. Dumb fuzzers are not
aware of the specifics of the protocol they are testing. They can be useful in ensuring that the same
assumptions made in the program that potentially result in a vulnerability are not also replicated in the
test generation code.
 Generational versus Mutational. Generational fuzzers create random program input from scratch
based on a model. Mutational fuzzers modify existing template files to generate input.
The team used all four types of fuzzers to test Internet Explorer 8.
As a guideline, any data flow crossing a trust boundary in the Dataflow Diagram of the threat model
(created during the Design phase) may contain untrusted data and should be considered as a target for
fuzz testing. The SDL requires fuzzing for all potentially untrusted file formats, all ActiveX controls, and all
remote procedure call (RPC) endpoints.
HTML Fuzzer
To fuzz HTML files, the Internet Explorer team used a generational fuzzer that created fuzzed HTML pages.
These HTML pages included valid and invalid HTML tags, attributes, properties of cascading style sheets,
and JavaScript code that performed operations on the DOM. By using the HTML Fuzzer during Internet
Explorer 8 development, the Internet Explorer team found many vulnerabilities internally before releasing
the product. Whenever the team independently discovered a security-related vulnerability that the HTML
Fuzzer should have found, the Security team would update the HTML Fuzzer to better detect that class of
bugs. HTML fuzz testing is run continuously.
File Format Fuzzing
The Security team worked with individual feature team testers to help them perform fuzz testing on file
formats parsed by both new feature code and legacy code. During the Internet Explorer 8 Verification
phase, over 70 different file formats, spanning every feature team, were fuzz tested. These file formats
included images, fonts, media, and other data files. The Internet Explorer team ensured that every file
format that Internet Explorer handled received at least 100,000 fuzz test iterations as required by the SDL,
often going well beyond this number.
4
You can also enable PageHeap by using the Gflags tool or Pageheap.exe.
Internet Explorer 8 and the Security Development Lifecycle
8
ActiveX Fuzzing and RPC Fuzzing
All ActiveX controls shipped with Internet Explorer that were marked Safe for Scripting or Safe for
Initialization were fuzz tested. In addition, the local RPC endpoint used for communication between the
Low and Medium integrity levels was fuzz tested to help prevent privilege escalation vulnerabilities.
Prioritizing Crashes with the !exploitable Crash Analyzer
Every tester on the Internet Explorer team was trained to use the Microsoft !exploitable Crash Analyzer.
This debugger extension prioritizes fatal exceptions based on an automated analysis of exploitability. In
addition to being run manually by testers, !exploitable is automatically run during fuzz testing. By helping
to identify the exploitability of a given crash, the results of !exploitable helped the security team to
prioritize vulnerabilities.
COM Hygiene Testing
Many Component Object Model (COM) objects are tested only in the single container in which the
implementer expects the component to be instantiated. However, most COM objects are registered
system-wide and as a result can be run in alternate COM containers. ComChk is an internal Microsoft tool
that helps validate that a set of given COM objects abides by its COM contracts. This helps to identify
exploitable conditions that some containers may mask. The Internet Explorer team ran ComChk on all
COM objects that Internet Explorer registers with AppVerifier enabled. The team then fixed all potentially
exploitable issues such as dangling pointers that the COM contract requires to be set to null and fatal
exceptions including access violations.
THE RELEASE PHASE
Tracking Third-Party Components
Internet Explorer, like many applications, includes some software components created by external
organizations. Such components generally include static-link libraries and dynamic-link libraries (DLLs), in
addition to source code that has been included in the source tree. Such third-party components typically
present two significant security challenges:
1.
2.
How to ensure that the components have been developed with security in mind following the best
practices of a process like the SDL.
How to be prepared to service these components in the event that a security vulnerability is
discovered in them that puts the security of the overall product at risk.
The first step that the Internet Explorer team took in dealing with third-party components was to
document them all in a list. This list contained:
 Binary libraries linked into Internet Explorer executable files (identified with the help of a static analysis
tool).
 Source code libraries checked into the Internet Explorer 8 source tree.
 Carried DLLs that Internet Explorer 8 uses and that are shipped as part of the Internet Explorer 8
package.
Internet Explorer 8 and the Security Development Lifecycle
9
 Windows platform components that reside on the system, but are not shipped directly as a part of the
Internet Explorer 8 package. Internet Explorer 8 uses these components and exposes them to
untrusted data through the browser attack surface.
While threat modeling during the Design and Implementation phases, the Internet Explorer team
identified those third-party components that were being newly placed on the browser attack surface. They
met with the creators of those components to ensure that the creators used the SDL when developing the
components, and tested for the level of security exposure that they would be receiving through Internet
Explorer. Despite any existing security testing that had already been done for these components, the
Internet Explorer team performed additional security testing on them to ensure their robustness.
To prepare for servicing those third-party components that were packaged with Internet Explorer 8, the
Internet Explorer team either took ownership of the source code and servicing responsibility for the
component, or established a servicing agreement with the team that would be responsible for servicing
the component.
Security Response Planning
During the Release phase, the Internet Explorer team reviewed the Security Response Plan with the
Microsoft Security Response Center (MSRC) and Software Security Incident Response Process (SSIRP)
teams. The Security Response Plan for Internet Explorer 8 includes documented processes and
contingency plans to cover any scenarios that would affect Microsoft’s ability to release a security update.
The Internet Explorer team can be mobilized during nonstandard business hours in the event of a severe
security incident.5
THE RESPONSE PHASE
Despite the Internet Explorer team’s best efforts to minimize the number of product security
vulnerabilities, fix known security issues, and provide defense in depth in their products, no software
development team or product is perfect. In addition, new classes of browser vulnerabilities are discovered
that cannot be forecast in advance. As a result, the Internet Explorer team must be prepared to respond
to, and fix, newly discovered vulnerabilities in released versions of Internet Explorer through security
updates.
Learning from Our Mistakes: Root Cause Analysis
Microsoft looks at every externally reported security vulnerability as an opportunity to reflect on, and
improve, security tools and internal processes. The team considers how it could have discovered and
eliminated the given security vulnerability before the affected product was shipped. In addition, they look
at how they could have mitigated the successful exploitation of the vulnerability through defense-indepth measures. The team performs an in-depth, root cause analysis on each security vulnerability that
resulted in an externally reported vulnerability. This investigation includes an analysis of the vulnerable
source code and an evaluation of which security tools or processes could have discovered the
5
For more information about security response planning and execution, please see Chapters 10 and 12 respectively of The Security
Development Lifecycle by Michael Howard and Steve Lipner.
Internet Explorer 8 and the Security Development Lifecycle
10
vulnerability, but failed to do so. The team uses the information from this analysis to help evolve the
Security Development Lifecycle.
Recently, Microsoft has begun sharing some root cause analysis data with the public. As an example, see
Michael Howard’s blog post on MS08-078, the Internet Explorer data-binding vulnerability.
CONCLUSION
Shipping secure products requires making security a priority at every phase of the software development
life cycle. The Microsoft SDL has evolved based on experiences at Microsoft, and offers prescriptive and
best practice guidance for every phase of software development. You can use the SDL within your
software development organization to improve the security of your application. We hope that, by sharing
some of our experiences in applying the SDL to Internet Explorer 8, you will be encouraged to apply the
best practices that the SDL offers to your own application.
ADDITIONAL RESOURCES
See the Microsoft SDL Portal for more information about the SDL at Microsoft, and for tools and
resources to help you deploy the SDL in your software development organization.
Microsoft Software Security Blogs
 Keep up to date with SDL news and advances by following the Microsoft Security Development
Lifecycle Blog.
 Stay abreast of technical security analysis and Microsoft security research by following the Microsoft
Security Research & Defense Blog.
 Follow the latest Microsoft Security Response developments on the MSRC Blog.
ACKNOWLEDGMENTS
The author would like to express his gratitude to the following individuals who reviewed and provided
feedback: Eric Lawrence, Dominic Betts, Bronwen Matthews, David Ladd, Vishal Kumar, Mark Cartwright,
and Chris Peterson.
Internet Explorer 8 and the Security Development Lifecycle
11