Enhancing Customer Securiy: Built-in versus Bolt-on

Glenn Schoonover CISSP MCSE
Microsoft Security Solutions Specialist

Introduction

Can you really bolt on security after the fact? I don't think so, at least not effectively. That is a question that software developers and security specialists have been discussing for quite some time and with the increasing number of vulnerabilities and the reduction in number of days between vulnerability and patch the best answer is to get it right the first time. At Microsoft there have been a number of significant changes in the past 3 years to address the problem of building software that is secure "out of the box" and resistant to attack even if unpatched.

 

What is the Problem?

One of the problems with building secure software is spelling out the requirements for the developers as early as possible. "Programmers can be taught to avoid creating buffer overflows and other well-known vulnerabilities found in commercial software," said Lawrence Hale, speaking at this year's FOSE conference on government technology. The problem is that, historically, most developers did not spend much time worrying about buffer overruns nor did they do threat modeling against applications except in very tightly controlled government environments. If they did consider the potential for a threat they were often not trained in writing secure code. An example I like to use is the URL injection exploit where a hacker can force a buffer overrun by inserting an exceptionally long character string. While I was not present those many years ago when Mosaic, Netscape, and, later, Internet Explorer were first being coded, I'm pretty sure that none of the developers ever stopped to consider what would happen if someone did insert an extra long string into their browser forcing a buffer overrun. This was new territory and people tended to trust each other when conducting business on the nascent Internet. The result was an attack path that individuals with malicious intent could use to run executable code on an unsuspecting user's machine. Writing secure code is not a challenge that is unique to Microsoft. All software vendors are faced with the challenge of building secure products, but as part of their Trustworthy Computing and Security Mobilization Initiatives Microsoft is doing something about it. The goal of our Security Mobilization is to address five key issues: 1) Build Security into our products, 2) Address Customer Pain, 3) Demonstrate Leadership, 4) Mobilize the company, and 5) Provide Security and Assurance for computer services and products that are built on Microsoft Products.

 

Security Philosophy: Past and Present

Until recently Microsoft's philosophy has been to build products that were easy to use and that worked seamlessly across the platform. This meant that many services were enabled by default when the operating system was installed. For example, in Windows 2000 Server, the Internet Information Services are installed by default, set to start automatically, with the Internet Printing ISAPI filter enabled. Security was often thought of in terms of "features" such as IPSEC and EFS (Encrypting File System). While this gave system administrators and home users alike the ability to run a wide range of applications with minimum intervention, it did nothing to enhance security. In the Department of Defense it took many hours of testing and evaluation to develop configuration templates that would allow organizations to meet our Certification and Accreditation requirements. System administrators would lock themselves out of the operating system because they did not understand the impact that turning off a service would have and many times the only way to recover was to reinstall the OS from scratch.

With the implementation of Trustworthy Computing, security has become the number one priority. Default installations aimed at ease of use are now not always sufficiently secure, but, going forward, security in Microsoft's products will take precedence over ease-of-use.

For instance, in Windows Server 2003, IIS6 is turned off by default. It will need to be specifically chosen for installation, and when installed will only serve up static HTML pages by default. All other functionality (ISAPI filters, Active Server pages capabilities) must be turned on by the administrator after installation. Also, the Outlook Security Patch functionality, introduced as a download for Outlook 2000, is now built-in to Outlook XP and 2003. This security patch blocks access to potentially dangerous attachments, and warns when programs try to send mail on the users' behalf.

Microsoft has committed unprecedented resources to achieving the highest level of security possible in all of our products. The goal is to become the leader in the industry both in terms of product security, and in response to security issues that arise.

 

Trustworthy Computing

In 2002, Bill Gates announced the Trustworthy Computing Initiative. This was the first step in a 180 degree turn in building secure products. Success with Trustworthy Computing (TWC) is not going to be an easy task. It will take several years - perhaps a decade or more, before technology is trusted. The initiative is predicated on four key pillars:

•   Security: Operating systems and applications must be resilient to attack; confidentiality, integrity and availability of data and systems are protected, enabling customers to safeguard critical information.

•   Privacy: Products and online services adhere to fair information principles, while protecting the individual's right to be left alone.

•   Reliability: Ensuring systems and services work the way customers expect; dependable, performing and available when needed.

•   Business Integrity: Open, transparent and responsive with customers, with an internal focus on excellence in our decision-making and processes.

Goal: To be everyone's trusted supplier of secure, private, and reliable computing.

Security is a core tenant and Microsoft is committed to building software and services to help better protect our customers and the industry.

 

Commitments

At the Worldwide Partner Conference in October 2003, Steve Ballmer announced Microsoft's commitment to "Build software and services that will help better protect our customers and the industry."

In developing and refining our approach to security over the past few years, the largest set of stakeholders that have influenced us has been our customers. Security sometimes seems too simple a term for the many aspects of business and information technology that it touches. Even just looking at security from an IT viewpoint, we want to protect networks, systems, data, processes and users. For each of those areas, people, processes and technology are necessary to manage the security business risk.

The security of our customers' computers and networks is a top priority for Microsoft. Security is an industry-wide issue and although there is no one solution, our approach to security spans across both technology and social aspects. In technology, we're focused on:

•   Building greater isolation and resiliency into the computing platform.

•   Providing customers with the latest and most effective advanced updating methods.

•   Enabling new business scenarios through integrated authentication, authorization and access control options.

•   Improving quality by enabling engineering excellence.

 

Progress

The first product to ship as part of the Trustworthy Computing Initiative was Windows Server 2003. We focused on making the product secure by design, by default, and in deployment. This represents huge progress on security, and the processes we use have begun to win recognition in the industry and even awards. In the area of "Secure by Design," we made a $200M Investment in security engineering covering tools, training, and the process of software development. We instituted better developer accountability - each line of code is owned by a particular developer who is responsible for ensuring security compliance. We developed pervasive threat-modeling techniques and automated code analysis to analyze the design. Another key development is shipping Windows Server 2003 in a "Secure by Default" mode. The product uses locked-down configurations so that only the features you need are enabled, reducing the attack surface to less than half of what it was in NT 4.0. IIS 6.0 is turned off by default. We implemented a stronger security policy, access control list defaults and new "low privilege" service accounts. Windows Server 2003 is also the first product to ship "Secure in Deployment." We improved the power and simplicity of Security Management Tools & Services, including software restriction policies. Secure communications (VPN/Wireless) is now easier to deploy with IEEE 802.1X protocol support, and integrated certificate services with auto-enrollment. There is greater breadth of Patch Management Solutions within and outside of the product, including Software Update Services (SUS) 2.0, and we offer much more extensive Prescriptive Guidance so system administrators can easily get information on how to deploy the product securely.

These security engineering practices have been recognized by organizations such as RSA and the SANS Institute who have given Microsoft awards on our training, tools, and product update investments. In short, with the degree of customer engagement, early production deployments across all customer segments and workloads and the measures of quality, especially security, Windows Server 2003 is a product that can be deployed today, without waiting for a service pack.

 

RSA Industry Innovation Award

As members of Microsoft's elite Secure Windows Initiative team, Michael Howard and David LeBlanc published "Writing Secure Code" (now in its' second edition) to provide software developers with a better understanding of the processes and practices needed to produce sound software code. Howard and LeBlanc's book is the cornerstone of the security training programs developed during the implementation of the Trustworthy Computing initiative. During the Windows security push, product development halted for more than two months as Microsoft software developers attended, and then implemented, mandatory security training, all based on the "Writing Secure Code" book.

Thousands of product developers and testers from across the company have now been trained in writing secure code as part of the Trustworthy Computing Initiative. Since being introduced internally at Microsoft, "Writing Secure Code" has become the definitive security resource for software developers and engineers at Microsoft. In addition, "Writing Secure Code" is being adapted into textbook format for university computer science courses by Addison Wesley. The success of Howard and LeBlanc's book and curriculum underscores the industry's need for secure coding guidelines and the importance of educating developers about the value of secure software in today's computing landscape.

 

SANS 2003 Information Security Leadership Awards

Microsoft earned recognition in three categories of SANS 2003 Information Security Leadership Awards, including automated patching and training programmers to write safer code. Red Hat also was recognized for automated patch notification.

http://www.computerworld.com/securitytopics/security/story/0,10801,79164,00.html.

Microsoft won three of the awards - demonstrating that its Trustworthy Computing Initiative is beginning to bear fruit:

•   The Award for Leadership In Automated Updates for Microsoft's automated patching service (for Windows XP and Windows 2000 SP3 and above) that helps protect users who are not security experts and for the Update Server that allows security experts inside organizations to test patches and then release them for automated patching of all systems managed by the Update Server, both locally and remote.

•   The Award for Leadership in Security Training of Software Developers for Microsoft's nascent program of requiring all Microsoft software developers to become familiar with common security errors made by programmers and how to avoid them.

•   The Award for Leadership in Testing Software for Security Vulnerabilities for Microsoft's extensive automation of the software testing process.

What are these changes? The Security Development Lifecycle is the process that is used internally at Microsoft to build more secure software. This is a sophisticated process, with threat modeling, audit, testing and signoff stages, coupled with developer education and tools. At Microsoft, we have trained over 13,000 engineers in the rigorous process. (See Figure 1)

Figure 1. Security Development Lifecycle

 

Security review

Once the product design is understood, the specs complete and the threat models are done, it's time to have the design reviewed. The product group should set aside a day or more for such reviews. At this meeting (taking a day at a minimum), component owners will present their architecture and the security implications, threats and countermeasures pertaining to their component. The team will provide experienced feedback and, if need be, the product group makes adjustments to the product.

 

Develop and Test

The purpose of the Security Days is simply to keep everyone on their toes, and to provide updated education and security analysis. In the past, many groups held such "bugbashes," but the focus should not be simply on finding bugs, it should be to educate, and attempt new attack techniques and methods on an ongoing basis. If you give people the time to do this they will find new issues.

 

Security Push

A security push occurs at beta time and is a team-wide stand down to focus on threat model updates, code review, testing and documentation scrub. Note that the push is not a quick fix for a process that lacks security discipline; it is simply a concerted effort to eradicate bugs before ship. Note, in the short-term, a security push is a length milestone.

 

Security Audit

Once the end of the project draws near, a very important question must be asked, "from a security viewpoint, are we ready to ship." The only way to answer this question is to have an end of project security audit. The process is well understood - the three main analysis points are: (1) Have the threats changed? (2) Perform a root cause analysis of incoming security vulnerabilities that require code modifications in the current code base. Why were they missed? What needs changing? (3) Penetration work; The Secure Windows Initiative (SWI ) (and outside contractors and the product team) review default settings, attempt to compromise the system.

 

Security Response

You can only design, write and test for the security issues you know today; no matter how rigorous the process security, issues will arise simply because the threat landscape changes each week. Because of this, each team needs a group of people to handle security vulnerabilities as they are discovered after the product has shipped. The team must focus on addressing the vulnerabilities found, and also on performing a root cause analysis on each vulnerability so as to find and modify potential vulnerabilities proactively - before they are also found in the field. The team must meet common standards for response time, quality, patch packaging and release.

 

Challenges Ahead

At Microsoft, we are thinking about the "big picture" of security, and working to help customers in a variety of ways. First and foremost, we remain deeply committed to building software and services that will help better protect our customers and the industry. Our goal is to build the most secure software we can, while still building products that customers will want and be able to use. Beyond that, we are taking steps to help protect our customers in a world where vulnerabilities are inevitable and the threats are evolving. This means investing in new technologies; investing in training, guidance and communications to help our customers get the expertise they need; and partnering with industry leaders, customers, governments, and law enforcement to address the challenge.

 

Biography

Glenn Schoonover CISSP MCSE, is currently a Security Specialist with Microsoft. He is responsible for developing and executing on the Infrastructure and Security strategy for the Federal District and spends most of his time helping government customers build a secure, connected infrastructure. Prior to arriving at Microsoft he was the Director of Security for a global Internet Service Provider and Chief of Network Security for the Army at the Pentagon. A 1986 graduate of the United States Military Academy at West Point, he is an authority on network security architecture, vulnerability assessments and intrusion detection with experience using a wide variety of commercial and open source tools.

 

July 2005
Vol. 8, Number 2

Secure Software Engineering
 

Articles in this issue:

Developing Secure Software

The Challenge of Low Defect, Secure Software

Enhancing Customer Security

Software Development Security

User Comment

Lessons Learned
 

Download this issue (PDF)

Get Acrobat

Receive the Software Tech News