WHITEPAPER Executive Summary Fortify Software

Transcription

1 Optimizing the Microsoft SDL for Secure Development Fortify Solutions to Strengthen and Streamline a Microsoft Security Development Lifecycle Implementation Executive Summary Developing secure software is one of the toughest challenges that confront not only security and development teams, but IT organizations as a whole. The stakes are growing higher as security threats continue to mount, infrastructure complexity grows, and organizations demand increasing degrees of protection. Implementing a Secure Development Life Cycle (SDLC) model is a proven way to enhance software security. On a per-project basis, an SDLC prescribes activities to embed security into applications and supplies the foundation for a broader Software Security Assurance (SSA) program that extends across an IT enterprise. Microsoft offers one of the most comprehensive and well-designed SDLCs in the industry. Freely available for download and use, the Microsoft SDL has matured to agnostically support a variety of languages, platforms, and development methodologies. It is supported by the SDL Pro Network, a group of security consultants, training companies and tool providers that specialize in application security and have substantial experience and expertise with the methodology and technologies of the SDL. As a member of the SDL Pro Network, Fortify is uniquely qualified to help organizations implement and comply with the Microsoft SDL. In partnership with Microsoft, Fortify has developed solutions specific to the Microsoft SDL to streamline, accelerate, and strengthen an SDL implementation. Fortify Software 1

2 This white paper examines how the Microsoft SDL addresses the risks and challenges of secure software development, and how the Fortify 360 suite and Fortify services supply a significant value-add in building on the Microsoft SDL to achieve software security: Microsoft SDL implementation. The SSA Governance Module in Fortify 360 provides an automated, step-by-step collaboration platform to implement and comply with the Microsoft SDL across multiple projects, development and security teams, platforms and application types, and geographic locations. Application code security analysis. Fortify 360 Source Code Analyzer and Program Trace Analyzer technologies are ideal for application code vulnerability testing as required by the Microsoft SDL. Expert training and professional services. Fortify offers a broad range of training and consulting services to help organizations make the most of the Microsoft SDL and embed security throughout their application portfolios. The Challenges of Developing Secure Software The scenario is too familiar to too many IT professionals. A new mission-critical application is put into service, and in a matter of weeks, it s bombarded by hackers or cyber-criminals with SQL injections or viruses or botnets that exploit a security vulnerability overlooked during months of development and testing. Crisis ensues. Data has been compromised. After initial triage, teams of development and security technicians work 16-hour days correcting code deficiencies that left the application susceptible to attack. The expense for post-deployment security fixes is high up to 30 times the cost of building in security during development, according to the National Institute of Standards and Technology. What went wrong? The cause is usually not a failure of technology, but a failure of process. Factors may include: No systematic framework to embed and verify security Ad hoc security practices inconsistent across multiple projects Failure to prioritize projects and profile by risk No centralized inventory of applications Application-to-security staff ratios of 150:1 and more Crude collaboration tools (spreadsheets, s, phone calls) Poorly defined stakeholder responsibilities for security policies Globally dispersed teams (e.g., U.S., Ireland, India, etc.) Fortify Software 2

3 If you don t know SDL, you will soon. Whether it s Microsoft s SDL or another similar model, secure code development will become a standard in the near future. Jon Oltsik Principal Analyst, Enterprise Strategy Group The lack of a systematic process to govern security throughout development is not uncommon at many organizations, from smaller businesses to the Fortune 100, from government agencies to educational institutions. Generally speaking, the larger the organization and the more complex its infrastructure, the higher the security risk. Application developers can outnumber security professionals in ratios of 100:1 to 300:1 and even more. Software engineers often view security as an afterthought or someone else s problem usually a small, overworked team of security specialists. On average, software engineers don t pay enough attention to security, said Michael Howard, Microsoft Principal Security Program Manager. They may know quite a bit about security features, but they need a better understanding of what it takes to build and deliver security features. The Microsoft SDL Approach to Secure Software Development In the past several years, security process models have emerged that aim to correct the process weaknesses that are so frequently the culprit behind security flaws and breaches. Faced with growing infrastructure complexity and inexorable security threats, many organizations have made it a priority to transition towards security process models such as the Microsoft SDL, OWASP CLASP, Cigital Touchpoints, or SAFECode.org practices. This trend reflects a widespread recognition that effective security must be a principal consideration throughout each and every phase of application design and development. Though they differ in details, each unique security process model shares a common philosophy that secure development must: Be structured, systematic, and repeatable across projects Collaboratively engage developers and security specialists Support prioritization, risk profiling, and continuous improvement If you don t know SDL, you will soon, said Jon Oltsik, principal analyst at the Enterprise Strategy Group. Whether it s Microsoft s SDL or another similar model, secure code development will become a standard in the near future. 1 As Oltsik noted, one of the key drivers behind SDL adoption is emerging requirements for cyber supply chain assurance from the U.S. government and leading organizations in financial services, telecommunications, utilities, and others. Sellers of technology products will need to verify that they adhered to an SDL model to buyers incorporating these new security requirements. Fortify Software 3

4 Compliance requirements for PCI, HIPAA, FISMA, SOX, NERC, and other mandates provide increasing motivation for secure software development practices. Organizations need to cultivate the ability to rapidly demonstrate compliance. Although compliance does not always equate to security; security within compliance is enhanced through adherence to well defined and rigorous SDL development practices. The Microsoft SDL: Leadership in Secure Software Development The Microsoft SDL is a seven-phase security assurance process that is focused on software development. Combining a holistic and practical approach, the Microsoft SDL aims to reduce the number and severity of vulnerabilities in software by introducing security and privacy throughout all phases of the development process. As a common framework for software developers and security specialists to collaborate on security activities across multiple development projects, the Microsoft SDL aims to help organizations: Mitigate risk by making software more inherently secure Improve trust by enhancing privacy and protecting sensitive information Reduce time and costs by eliminating vulnerabilities early in development The Microsoft SDL is fairly new to the public domain. Microsoft first released its SDL process guidance in April 2008, and has since delivered several refinements as well as related SDL resources. It has also created and expanded the SDL Pro Network. The Microsoft SDL Web portal offers resources for technology professionals to learn more about the SDL. The Microsoft SDL was created as a result of a series of high profile security breaches involving Microsoft technology in the early 2000s. Those incidents prompted the software giant to develop the SDL, which has been a mandatory process at Microsoft since The SDL has become the foundation of security guidance for internal development of all Microsoft software. The big question is, does SDL work? said Howard, The answer is a resounding yes! We have seen the number of security defects reduced by approximately 50 to 60 percent when we follow SDL. By publishing the Simplified Implementation of the SDL paper in early 2010, Microsoft sought to clarify certain misconceptions surrounding the SDL, namely that it is geared only for Microsoft technologies and very large enterprises. The Simplified Implementation paper demonstrates that the SDL is agnostic and applicable across a range of scenarios. Fortify Software 4

5 Languages, tools, and platforms. The SDL is not limited to Microsoft-centric coding but also applies to a variety of development platforms including but not limited to Ruby for OS X, or Java for Solaris. We point to Microsoft as best in class in terms of incorporation of security into the development lifecycle. Neil MacDonald Vice President, Gartner Development methodologies. The SDL is suited for Agile (Web- and cloud-based projects), waterfall methodologies, and any hybrid of the two. Organizational size. Large organizations benefit from the SDL, but its value is strong for smaller enterprises as well. Microsoft has taken an industry leadership position with its delivery and evangelism of its SDL. The company has demonstrated a strong commitment to security with its years of developing the SDL and applying it to its internal development. Now, with its public release of the SDL and the best-practice resources, it has made the information and resources they have used to improve the security of their software freely available to the community. Security specialists, developers, and analysts have taken note. We point to Microsoft as best in class in terms of incorporation of security into the development lifecycle, said Neil MacDonald, Gartner vice president. Think about security in terms of requirements. That s what Microsoft is talking about. 2 Fortify Solutions for the Microsoft SDL While the Microsoft SDL supplies a framework for secure software development, implementing security best practices and adopting the SDL can be challenging for any organization with diverse development and security teams and multiple development projects in the pipeline at any given time. A Microsoft SDL implementation is ideally backed by a technology platform engineered specifically for the SDL with the following characteristics: Automated. A workflow-driven platform should supply step-by-step, role-based functionality through each phase of the Microsoft SDL with strong verification of and visibility into processes. Repeatable. The platform should provide consistent, centralized capabilities that may be readily extended across any number of security projects, application types, business units, and geographic locations. Collaborative. A Web-based interface should tighten collaboration among developers, architects, security professionals, project leads, and others and promote continuous improvement among team members. Customizable. Out-of-the box functionality and best-practice processes need to be augmented with flexibility for teams to customize the platform and SDL processes to meet the unique needs of their projects and organizations. Fortify Software 5

6 As outlined below, the Fortify SSA Governance Module provides five key capabilities that help security professionals and developers meet the objectives of an SDL implementation. An accompanying process template specific to the Microsoft SDL guides users through activities. 1. Create and manage a detailed application inventory The SSA Governance Module allows teams to create a security-specific inventory and centralized system of record of their entire application portfolio. Its workflow-driven process simplifies what would be costly, time-consuming, and error-prone ordeal if done from scratch. With a customizable Web interface, teams can rapidly build security profiles based in part on: Project dependencies. Accounts for components and libraries, and other projects related to a subject project. Business attributes. Defines business risk, type of business data, internal/external, applicable compliance mandates. Technical Attributes: Details project type, background, and status; captures platform and development language. 2. Establish and consistently apply security policies Leveraging the security-specific inventory, the SSA Governance Module can automatically profile the project and assign the appropriate version of the Microsoft SDL based on the maturity of the development group and risk profile of the project. The module guides users through activities that correspond to both Microsoft SDL requirements and the assigned security risk (e.g., new development/high risk, third-party development/low risk) of a given project. Examples of activities include: Upload abuse case or threat modeling document Upload architectural review or code analysis Remove all hot issues from code analysis Deploy an application firewall 3. Communicate across diverse teams and track activities With a Web-based dashboard interface, the SSA Governance Module supplies a collaborative platform for role-based coordination among developers, security specialists, and other project stakeholders. The portal environment gives teams, regardless of location, a centralized clearinghouse to coordinate and streamline dozens of critical SDL activities: View, update, and execute assignments Download and manage security artifacts Track activities, monitor progress, and identify weaknesses Sign off on activities with permission-based controls Fortify Software 6

7 4. Respond to inquiries with audit-quality information With Fortify 360 server as a central repository for all Microsoft SDL project resources, the SSA Governance Module enables team members to rapidly respond to inquiries both during development and post-release. This capability is also valuable to demonstrate compliance with PCI, SOX, FISMA, and other requirements. A single system of record helps stakeholders: Report on project progress and status Reproduce historical activities and related artifacts Conduct root-cause analysis of any post-release security flaws Demonstrate compliance with SDL and regulatory requirements 5. Monitor trends to drive continuous improvement Analysis and reporting is a particularly valuable component for SDL implementations, especially in organizations managing dozens or hundreds of development projects. The SSA Governance Module enables analysis and reporting on trends behind SDL and SSA program performance. It supplies visibility into such issues as: Most prevalent security vulnerabilities Time required to meet SDL security requirements Performance weaknesses by teams, application types, security levels Problem areas to improve process, efficiency, and compliance Fortify 360 with SSA Governance for the Microsoft SDL The Fortify 360 suite, as well as Fortify professional services and expert training, are ideal to help organizations streamline a Microsoft SDL implementation and achieve compliance with its requirements. The Fortify SSA Governance Module, with its Microsoft SDL template, speeds and simplifies SDL processes with step-by-step automation that prescribes activities based on an application s risk profile (basic, standard, advanced, or dynamic), stakeholder roles, and other considerations. Fortify Source Code Analyzer (SCA) and Program Trace Analyzer (PTA) tools supply code analysis as required by the Microsoft SDL. The following graphic illustrates Fortify support for the SDL. Fortify Software 7

8 Fortify 360 technology, including the SSA Governance Module and code-analysis tools, and Fortify services support all phases of the Microsoft SDL. Let s take a closer look at how Fortify solutions support the seven phases of the Microsoft SDL and its prescribed practices. Pre-SDL Requirements Phase: Security Training The Microsoft SDL requires that all members of a software development team be trained on security basics and industry trends. The SDL s Practice 1 (Perform Core Security Training) requires that individuals in technical roles (developers, testers, program managers) take at least one unique security training class a year. Training should cover such concepts as secure design and coding, threat modeling, testing, as well as advanced topics as appropriate. Fortify offers a comprehensive curriculum of software security training courses to ensure a high level of application security awareness and proficiency. Instructor-led workshops and a range of SSA e-learning courses cover all aspects of SDL projects, SSA programs, and the use of Fortify technology. Phase One: Requirements The Requirements phase is when development teams consider how to best integrate security and privacy into the development process and identify key security objectives while minimizing disruption to application usability, plans, and schedules. The phase includes three discrete practices: Practice 2: Security Requirements: Early definition of requirements allows teams to identify key milestones and deliverables to integrate security as a streamlined part of their software development process. Fortify Software 8

9 Practice 3: Quality Gates/Bug Bars: Defining the product s security criteria up front helps teams, assess risk, and correct security bugs during development and verification. These also become final review criteria to assess the security of their product prior to release. Practice 4: Security and Privacy Risk Assessment: These processes are designed to identify functional aspects of a product that may have higher risk and require deeper scrutiny to address such issues as whether portions of a project need threat models, security design reviews, or penetration testing before release. With a sequential and intuitive process, the Fortify SSA Governance Module prescribes the proper Microsoft SDL Requirements steps. It helps ensure development and security teams get off on the right foot and do not overlook key considerations that could impact the project in subsequent phases. Fortify 360 server stores artifacts produced in the Requirements phase for later use. Phase Two: Design The Design phase identifies the overall requirements and structure for the software and establishes design best practices. This critical phase engages designers, architects, developers, and security specialists and is a team s best opportunity to design security functionality in the most timely and cost-effective manner. SDL Practice 5: Design Requirements: The practice covers creation of design specifications, specification review, and specification of minimal cryptographic design requirements. SDL Practice 6: Attack Surface Reduction: The practice encompasses shutting off or restricting access to system services, applying principles of least privilege, and employing layered defenses. SDL Practice 7: Threat Modeling: The primary security analysis task performed during the Design phase, it promotes consideration of security issues in context of their operational environment and informs the design of features or protections by the development team as they begin implementing code. With the project security level established (basic, standard, advanced, or dynamic), the SSA Governance Module outlines the activities required by the Microsoft SDL. Role-based functionality specifies steps to be executed by diverse stakeholders. Artifacts generated by threat modeling and attack surface reduction exercises are stored and available on demand. These artifacts also become valuable references for building test scenarios to exercise the security of a product in the Verification Phase. Phase Three: Implementation During the Implementation phase, the development team mandates and enforces best practices identified in the Requirements Phase and follows them for the duration of a project using three practices: Fortify Software 9

10 SDL Practice 8: Use Approved Tools: This practice requires teams to publish a list of approved tools and their associated security checks, such as compiler/linker options and warnings. SDL Practice 9: Deprecate Unsafe Functions: Teams are tasked with analyzing all functions and APIs to be used, determining which are unsafe, and establishing a list of banned functions. SDL Practice 10: Static Analysis: Static source code analysis provides a scalable capability that helps ensure that secure policies are followed; teams should be prepared to augment it with manual code review as appropriate. Fortify Source Code Analyzer (SCA) performs static analysis and root-cause identification of vulnerabilities in source code. Fortify 360 server consumes the static analysis results and warns of banned function violations. The SSA Governance Module supplies workflow-driven automation that streamlines team initiatives throughout the Implementation phase, and prompts team when manual code review is required. Phase Four: Verification In the Verification phase, the software is functionally complete and is tested against security and privacy goals outlined in the Requirements and Design phases, using three practices: SDL Practice 11: Dynamic Program Analysis: Run-time verification helps ensure that an application works as designed and should test for memory corruption, user privilege issues, and other problems. SDL Practice 12: Fuzz Testing: The specialized form of dynamic analysis deliberately induces program failure by introducing malformed or random data into an application. SDL Practice 13: Threat Model and Attack Surface Review: This code-complete verification reexamines security from a threat model and attack surface perspective, accounting for changes in functional and design specifications that may have occurred during development. For Practice 11, Fortify 360 s Program Trace Analyzer tool detects vulnerabilities while an application is running; it also integrates into quality assurance testing to find vulnerabilities during functional testing. Fortify 360 server consumes and provides reporting on dynamic testing, while the SSA Governance Module walks teams through the detailed threat model and attack surface review. Phase Five: Release The Release phase includes answering the critical question: From a security perspective, is the software ready for release? The SDL outlines three practices: SDL Practice 14: Incident Response Plan: The plan outlines response processes and personnel for security emergencies and on-call contacts with decision-making authority available 24/7. Fortify Software 10

11 SDL Practice 15: Final Security Review: The final review systematically re-examines all security activities performed on an application prior to release, including threat models, exception requests, tool output, and performance against quality gates and bug bars. SDL Practice 16: Release/Archive: Software release is conditional on completion of the full SDL process and must be certified by a security advisor assigned to the project. As a final step, all data related to the project is archived for reuse and serves as a baseline security reference in the next version of the software. Users can enforce a proper and rigorous release strategy with the SSA Governance Module and accompanying Microsoft SDL Process Template. The module helps teams effectively create an incident response plan and provides in-depth checks and balances to ensure all steps in the crucial final security review are completed. Post-Release Phase: Response: After an application is released, the product development team must be available to respond to any possible security vulnerabilities or privacy issues, using the plans and resources output from the Release phase. An important characteristic of the Microsoft SDL Response phase is the ability for a team to respond to inquiries, be they from the CISO or an individual who identified a security flaw. As a system-of-record repository for SDL activities and artifacts, Fortify 360 server equips teams with audit-quality project lineage data and metadata essential not only for response, but to analyze the root cause of a security flaw. Conclusion The need for secure software development will never cease. Hackers and cyber-criminals have demonstrated increasing ingenuity in attacks, and it s clear that no end is in sight to the manifold threats that they pose to businesses, governments, institutions, and consumers. It s equally clear that ad hoc, inconsistent processes that attempt to build security into applications late in their development or only at deployment are fraught with risk and more prone to intrusion or failure. Leading organizations recognize that the systematic and repeatable structure of an SDL offers the best means of embedding and verifying security and privacy within applications. Through years of development and refinement, the Microsoft SDL has emerged as a leading framework well suited for secure development on a variety of platforms, tools, languages, and development methodologies. As a member in the SDL Pro Network, Fortify is committed to delivering the technology, training, and services that organizations need to make the most of the Microsoft SDL s ability to fortify security throughout each phase of application development and deployment. Fortify Software 11

12 References 1 Network World, Microsoft SDL Progresses, February 3, SD Times, Microsoft Focuses on Security Development Lifecycle, September 25, rev20310 Fortify Software 12