Partilhar via

  • Artigo
Cc307412.Requirements(en-us,MSDN.10).png

Phase 1: Requirements

The Requirements phase of the SDL includes the project inception—when you consider security and privacy at a foundational level—and a cost analysis—when you determine if development and support costs for improving security and privacy are consistent with business needs.
On This Page

Project Inception
Security Requirements
Privacy Requirements
Security Recommendations
Resources
Cost Analysis
Security Requirements
Privacy Requirements
Privacy Recommendations
Resources

Project Inception

The need to consider security and privacy at a foundational level is a fundamental tenet of software development. The best opportunity to build trusted software is during the initial planning stages of a new release or a new version, because development teams can identify key objects and integrate security and privacy, which minimizes disruption to plans and schedules.

Security Requirements

  • Develop and answer a short questionnaire to verify whether your development team is subject to Security Development Lifecycle (SDL) policies. The questionnaire has two possible outcomes:

    1. If the project is subject to SDL policies, it must be assigned a security advisor who serves as the point of contact for its Final Security Review (FSR). It is in the project team’s interest to register promptly and establish the security requirements for which they will be held accountable. The team will also be asked some technical questions as part of a security risk assessment to help the security advisor identify potential security risks. (See Cost Analysis in this document.)

    2. If the project is not subject to SDL policies, it is not necessary to assign a security advisor and the release will be classified as exempt from SDL security requirements.

  • Identify the team or individual that is responsible for tracking and managing security for the product. This team or individual does not have sole responsibility for ensuring that a software release is secure, but the team or individual is responsible for coordinating and communicating the status of any security issues. In smaller product groups, a single program manager might take this role.

  • Ensure that bug reporting tools can track security bugs and that a database can be queried dynamically for all security bugs at any time. The purpose of this query is to examine unfixed security bugs in the FSR. The project’s bug tracking system must accommodate the bug bar ranking value recorded with each bug.

  • Define and document a project’s security bug bar. This set of criteria establishes a minimum level of quality. Defining it at the start of a project improves understanding of risks associated with security issues and enables teams to identify and fix security bugs during development. The project team must negotiate a bug bar approved by the security advisor with project-specific clarifications and (as appropriate) more stringent security requirements specified by the security advisor. The bug bar must never be relaxed, though, even as a project’s release date nears. Bug bar examples can be found in Appendix M: SDL Privacy Bug Bar and Appendix N: SDL Security Bug Bar.

  • Include third-party code licensing security requirements in all new contracts. If your product contains licensed third-party code that is newly contracted in the current release, you should ensure that there is a provision in the licensing contract that requires the third party to provide proof of compliance with a predefined list of SDL requirements. Depending upon your company's relationship with the third party, this can include things such as the source code itself for verification, security tool output and logs, or independent verification performed by an outside agent.

Privacy Requirements

  • Identify the privacy advisor who will serve as your team’s first point of contact for privacy support and additional resources.

  • Identify who on the team is responsible for privacy for a project. This person is typically called the privacy lead or, sometimes, the privacy champion.

  • Define and document the project’s privacy bug bar (see the preceding Security Requirements section).

Security Recommendations

It is useful to create a security plan document during the design phase, to outline the processes and work items your team will follow to integrate security into their development process. The security plan should identify the timing and resource requirements that the Security Development Lifecycle prescribes for individual activities. These requirements should include:

  • Team training

  • Threat modeling

  • Security push

  • Final Security Review (FSR)

The security plan should reflect a development team’s overall perspective on security goals, challenges, and plans. Security plans can change, but articulating one early helps ensure that no requirements are overlooked and avoid last-minute surprises. A sample security plan is included in the Appendix O.

Consider using a tool to track security bugs by cause and effect. This information is very important to have later in a project. Ensure that the bug reporting tool you use includes fields with the STRIDE values in the following lists (definitions for these values are available in Appendix B: Security Definitions for Vulnerability Work Item Tracking).

  • The tool’s Security Bug Effect field should be set to one or more of the following STRIDE values:

    • Not a Security Bug

    • Spoofing

    • Tampering

    • Repudiation

    • Information Disclosure

    • Denial of Service

    • Elevation of Privilege

    • Attack Surface Reduction

It is also important to use the Security Bug Cause field to log the cause of a vulnerability (this field should be mandatory if Security Bug Effect is anything other than Not a Security Bug).

  • The Security Bug Cause field should be set to one of the following values:

    • Not a security bug

    • Buffer overflow/underflow

    • Arithmetic error (for example, integer overflow)

    • SQL/Script injection

    • Directory traversal

    • Race condition

    • Cross-site scripting

    • Cryptographic weakness

    • Weak authentication

    • Weak authorization/Inappropriate permission or ACL (access control list)

    • Ineffective secret hiding

    • Unlimited resource consumption (Denial of Service, or DoS)

    • Incorrect/No error messages

    • Incorrect/No pathname canonicalization

    • Other

Be sure to configure bug reporting tools correctly; limit access to bugs with security implications to the project team and security advisors only.

Resources

Cost Analysis

Before you invest time in design and implementation, it is important to understand the costs and requirements involved in handling data with privacy considerations. Privacy risks increase development and support costs, so improving security and privacy can be consistent with business needs.

Security Requirements

A security risk assessment (SRA) is a mandatory exercise to identify functional aspects of the software that might require deep security review. Given that program features and intended functionality might be different from project to project, it is wise to start with a simple SRA and expand it as necessary to meet the project scope.

Such assessments must include the following information:

  • What portions of the project will require threat models before release.

  • What portions of the project will require security design reviews before release.

  • What portions of the project will require penetration testing (pen testing) by a mutually agreed upon group that is external to the project team. Any portion of the project that requires pen testing must resolve issues identified during pen testing before it is approved for release.

  • Any additional testing or analysis requirements the security advisor deems necessary to mitigate security risks.

  • Clarification of the specific scope of fuzz testing requirements. (Verification Phase: Security and Privacy Testing discusses fuzz testing.)

NOTE: SRA guidelines are discussed in Chapter 8 of The Security Development Lifecycle, along with a sample SRA on the DVD included with the book.

Privacy Requirements

Complete the Initial Assessment of the Appendix C: SDL Privacy Questionnaire. An initial assessment is a quick way to determine a project’s Privacy Impact Rating and estimate how much work is necessary to comply with Microsoft Privacy Guidelines for Developing Software Products and Services.

The Privacy Impact Rating (P1, P2, or P3) measures the sensitivity of the data your software will process from a privacy point of view. More information about Privacy Impact Ratings can be found in Chapter 8 of The Security Development Lifecycle. General definitions of privacy impact are defined below:

  • P1 – High Privacy Risk: The feature, product, or service stores or transfers Personally Identifiable Information (PII) or error reports; monitors the user with an ongoing transfer of anonymous data; changes settings or file type associations; or installs software.

  • P2 – Moderate Privacy Risk: The sole behavior that affects privacy in the feature, product, or service, is a one-time user-initiated anonymous data transfer (e.g., the user clicks on a link and goes out to a website).

  • P3 – Low Privacy Risk: No behaviors exist within the feature, product, or service that affect privacy.  No anonymous or personal data is transferred, no PII is stored on the machine, no settings are changed on the user's behalf, and no software is installed.

Product teams must complete only the work that is relevant to their Privacy Impact Rating. Complete the initial assessment early in the product planning/requirements phase, before you write detailed specifications or code.

Privacy Recommendations

If your Privacy Impact Rating is P1 or P2, understand your obligations and try to reduce your risk. Early awareness of all the required steps for deploying a project with high privacy risk might help you decide whether the costs are worth the business value gained. Review the guidance in the Understand Your Obligations and Try to Lower Your Risk of Appendix C: SDL Privacy Questionnaire. If your Privacy Impact Rating is P1, schedule a “sanity check” with your organization's privacy expert. This person should be able to guide you through implementation of a high-risk project and might have other ideas to help you reduce your risk.

Resources

Content Disclaimer

This documentation is not an exhaustive reference on the SDL process as practiced at Microsoft. Additional assurance work may be performed by product teams (but not necessarily documented) at their discretion. As a result, this example should not be considered as the exact process that Microsoft follows to secure all products.

This documentation is provided “as-is.” Information and views expressed in this document, including URL and other Internet website references, may change without notice. You bear the risk of using it.

This documentation does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.

© 2012 Microsoft Corporation. All rights reserved.

Licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported