This article is a follow-up to an article on the Windows security push in the first issue of IEEE Security and Privacy (January 2003). It provides additional detail on the security push and its results, and describes the creation and evolution of the Security Development Lifecycle (SDL) that integrated software security into Microsoft's development process. The article concludes with a summary of lessons learned about effective ways of creating secure software at scale.

Revisiting a recent column considering security updates.

How can customers tell they are getting it?

This article traces the origins of US government-sponsored computer security research and the path that led from a focus on government-funded research and system development to a focus on the evaluation of commercial products. That path led to the creation of the Trusted Computer System Evaluation Criteria (TCSEC), or Orange Book. The TCSEC placed great emphasis on requirements for mandatory security controls and high assurance, and the resulting TCSEC evaluation process was time-consuming and costly for commercial vendors and emphasized product features not valued by customers. As a result, vendor commitment to evaluations waned. The TCSEC was eventually supplanted by the international Common Criteria, which after almost 15 years, have moved to a model based on more straightforward requirements and a more deterministic evaluation process.

The challenges of transferring cybersecurity technologies are varied and span a wide range from detailed technical issues to market, sales, and production issues. It often seems that there is an art to successfully crossing the great divide. Are there cybersecurity-specific issues and challenges that make technology transfer more difficult?

The authors take a look back at VAX/SVS, a high-assurance virtual machine monitor (VMM) project from the 1980s, extracting its most pertinent lessons, including reference monitor architectural principles, approaches to verifiable and tamperproof access control, the benefits of layering, the impacts of minimization and verification, and the reasons behind its cancellation.

Over the past decade, a variety of methods have been created to address security vulnerabilities in application software development. Generally speaking, the methods that have risen to prominence can be categorized in two ways — prescriptive methods that emphasize the use of security practices and techniques as part of a carefully monitored and repeatable security initiative, and descriptive methods that describe a set of security threats that should be addressed.

Paul Karger, a great friend to all and a thought leader in security, passed away in September 2010.

ABSTRACTThis talk presents some observations on the nature of system security and security assurance, and on processes that attempt to evaluate assurance. Over the past forty years, approaches to assuring software security have evolved from "penetrate and patch" through attempts to prove security to application of automated tools that help developers detect and remove potential vulnerabilities. A review of that evolution leads to some observations on the effectiveness and practicality of various approaches and to the conclusion that the most theoretically appealing approaches may not be the most practical or likely to succeed. The talk then considers the processes by which user organizations, primarily governments, have attempted to evaluate product security. A review of historic approaches to evaluation supports the conclusion that past evaluation regimes have achieved limited success. The talk suggests some attributes of approaches to evaluation better suited to the realities of processes that achieve security assurance and more likely to provide valuable information to end users.

This paper gives insights into how the threat's evolving nature, the current information technology environment, and various market forces are combining to yield new security challenges and likely new technology paths for the future.

With the growth of the Internet as a vehicle for commercial, governmental, and personal communications and information sharing, the importance of providing trustworthy computing facilities that will resist hostile attack has grown dramatically. In response to this growing need, Microsoft has developed the Trustworthy Computing Security Development Lifecycle (SDL), an integrated process for improving the security of commercial software as it is being developed. This paper describes the phases of the SDL from initial requirements definition through the Final Security Review before software release, and summarizes some of the improvements in security demonstrated by software that has completed the SDL.

This paper discusses the trustworthy computing security development lifecycle (or simply the SDL), a process that Microsoft has adopted for the development of software that needs to withstand malicious attack. The process encompasses the addition of a series of security-focused activities and deliverables to each of the phases of Microsoft's software development process. These activities and deliverables include the development of threat models during software design, the use of static analysis code-scanning tools during implementation, and the conduct of code reviews and security testing during a focused "security push". Before software subject to the SDL can be released, it must undergo a final security review by a team independent from its development group. When compared to software that has not been subject to the SDL, software that has undergone the SDL has experienced a significantly reduced rate of external discovery of security vulnerabilities. This paper describes the SDL and discusses experience with its implementation across a range of Microsoft software.

The growth of the Internet since the mid-1990s has changed system security from a niche concern of a few customers and researchers to a requirement shared by the vast majority of customers and the stuff of front page news. Perhaps as difficult as meeting security requirements is the problem of measuring the actual benefits of steps intended to improve security. This talk will focus on effective ways of meeting security requirements and of measuring success.