La prueba en el proceso de nulidad

evaluations post-production, reporting vulnerabilities and taking action as necessary, such as updating the SDL process, education and tools usage.

Microsoft has published extensive and detailed information on SDL for the benefit of other software organizations that may want to adopt its

approach. Questions have been raised among systems integrators, particularly in government, regarding whether SDL is well suited for noncommercial software projects, given its focus on development, distribution, patching, maintenance, and customer support for turnkey products. SDL does not include activities related to installation and deployment, operation, or disposal, which are key phases in DoD and other government system life cycles. It may, however, be possible to follow SDL in the development of individual components, while following a more integration-oriented system life cycle process for the system as a whole.

Microsoft itself has acknowledged that education and trust of its developers are both key to the success of SDL-guided projects. This points to the need for adding and enforcing criteria to government request for proposals (RFP) and statement of work (SOW) related to individual developer knowledge, expertise, and education and contractor commitment to ongoing developer education and training.

Finally, SDL does not explicitly address business and other nontechnical inputs to the software process, such as inputs driven by Federal, DoD, or individual combatant command, service, or agency policy. The SDL view of security risk management is technically focused, so provisions would have to be made to ensure that security risk management within the SDL-guided software project dovetailed smoothly with less technical risk management methods used in many government software projects, which are defined mainly in terms of C&A concerns.

Even if SDL does not prove to be adaptable for use in government software projects, however, the fact that the methodology has been so well documented provides the acquisition officer with unprecedented insight into the software process followed by one of the government’s major software suppliers. This visibility into Microsoft’s development process provides exactly the type of assurance evidence acquisition officers should seek to attain from all of their suppliers of critical software.

Software Security Assurance State-of-the-Art Report (SOAR)

124 Scope.

Section 5 SDLC Processes and Methods and the Security of Software

For Further Reading

Michael Howard and Steve Lipner, The Security Development Lifecycle, (Redmond, WA Microsoft Press, 2006).

Michael Howard (Microsoft Corp.), “How Do They Do It?: A Look Inside the Security Development Lifecycle at Microsoft” MSDN Magazine, (November, 2005).

Available from: http://msdn.microsoft.com/msdnmag/issues/05/11/SDL/default.aspx

Steve Lipner and Michael Howard (Microsoft Corp.), “The Trustworthy Computing Security Development Lifecycle”, [web page], (Redmond, WA: Microsoft Corporation).

Available from: http://msdn.microsoft.com/security/sdl or

http://msdn.microsoft.com/security/default.aspx?pull=/library/en-us/dnsecure/html/sdl.asp

Steve Lipner (Microsoft Corp.), “Practical Assurance: Evolution of a Security Development Lifecycle,”

[web page] in Proceedings of the 20th Annual Computer Security Applications Conference, 2004 December 6-10; Tucson, AZ.

Available from: http://www.acsa-admin.org/2004/papers/Lipner.pdf

Microsoft Corp, “Application Security Best Practices at Microsoft: The Microsoft IT Group Shares Its Experiences”, January 2003.

Available from: http://download.microsoft.com/download/0/d/3/0d30736a-a537-480c-bfce-5c884a2fff6c/

AppSecurityWhitePaper.doc

5.1.8.2.2 Oracle Software Security Assurance Process [161]

Like Microsoft, Oracle Corporation claims to have adopted a secure development process in which all developers are required to follow secure coding standards and use standard libraries of security functions (authentication, cryptography), and to perform extensive security testing that includes penetration testing, automated vulnerability scanning, validations against security checklists, and third-party (government and industry) security IV&V.

As does Microsoft, Oracle claims to ensure that all of its developers are “security aware” throughout the development process (presumably, through training). Oracle products are shipped with secure configuration guidelines, and the company’s vulnerability management practices include critical patch deliveries along with fixes to the main code base, both of which are then used to inform revisions to Oracle’s security standards in order to reflect their lessons learned from vulnerability discoveries and security incident reports. Indeed, the main emphasis of the Software Security Assurance Process appears to be on security patch distribution.

By contrast with Microsoft’s SDL, however, Oracle does not appear to consider its Software Security Assurance Process to be widely usable or adaptable by other software firms, and especially not by software development teams not involved in commercial software product development. It provides some guidance for consumers of its products, primarily in support of database security configuration and vulnerability assessment, and patch management. Guidance for developers of applications or systems that incorporate Oracle databases is not provided.

In contrast with the more than 350-page book by Microsoft’s Michael Howard and Steve Lipner detailing their SDL, and dozens of pages of SDL resources on Microsoft’s various portals, websites, and blogs, Oracle has

published a 12-page whitepaper, along with other information and resources on the Software Security Assurance Process.

Software Security Assurance State-of-the-Art Report (SOAR) 125 Assumptions and Constraints.

Section 5 SDLC Processes and Methods and the Security of Software

5.1.8.2.3 CLASP

Developed by software security expert John Viega, chief security architect and vice-president of McAfee, Inc., CLASP [162] is designed to insert security methodologies into each life cycle phase. CLASP has been released under an open source license. Its core feature is a set of 30 security-focused activities that can be integrated into any software development process. CLASP offers a prescriptive approach and provides ongoing documentation of activities that organizations should perform to enhance security. Some of the 30 key activities include the following:

u Monitor security metrics

u Identify user roles and requirements

u Research and assess security solutions

u Perform security analysis of system design

u Identify and implement security tests.

While the above activities are designed to cover the entire software development cycle, they also enable an organization to skip tasks that are not appropriate to their development efforts. The program also provides users a detailed implementation guide to help determine which activities are the most appropriate including—

u Activity Assessment—CLASP Activity Assessment lessens the burden on a project manager and his/her process engineering team by giving guidance to help assess the appropriateness of CLASP activities. The Assessment provides the following information for each activity:

information on activity applicability; information on risks of omitting the activity; implementation costs in terms of frequency of activity, calendar time and staff-hours per iteration.

u Vulnerability Catalog—CLASP contains a comprehensive vulnerability catalog. It helps development teams avoid or remediate specific design or coding errors that can lead to exploitation. The basis of the catalog is a highly flexible classification structure that enables development teams to quickly locate information from many perspectives: problem types, categories of problem types, exposure periods, avoidance and mitigation periods, consequences of exploited vulnerabilities, affected platforms and programming languages, and risk assessment.

u CLASP and RUP—CLASP is available as a plug-in to the RUP

development methodology, or as a reference guide to a stand alone development process. In 2005, IBM/Rational released a CLASP plug-in to RUP that included a notation language for diagramming system architectures, and a suggested set of UML extensions for describing system security elements.

Software Security Assurance State-of-the-Art Report (SOAR)

126 Context.

Section 5 SDLC Processes and Methods and the Security of Software

For Further Reading

John Viega, “Security in the Software Development Lifecycle”, IBM DeveloperWorks, (October 15, 2004) Available from: http://www-128.ibm.com/developerworks/rational/library/content/RationalEdge/oct04/

viega/#N100AF