Cc307414.Design(en-us,MSDN.10).png

Phase 2: Design

The Design phase is when you build the plan for how you will take your project through the rest of the SDL process—from implementation, to verification, to release. During the Design phase you establish best practices to follow for this phase by way of functional and design specifications, and you perform risk analysis to identify threats and vulnerabilities in your software.

On This Page

Establish and follow best practices for design
Security Requirements
Privacy Requirements
Security Recommendations
Privacy Recommendations
Resources
Risk Analysis
Security Requirements
Privacy Requirements
Security Recommendations
Resources


Establish and Follow Best Practices for Design

The best time to influence a project’s trustworthy design is early in its life cycle. Functional specifications may need to describe security features or privacy features that are directly exposed to users, such as requiring user authentication to access specific data or user consent before use of a high-risk privacy feature. Design specifications should describe how to implement these features and how to implement all functionality as secure features. Secure features are defined as features with functionality that is well engineered with respect to security, such as rigorously validating all data before processing it or cryptographically robust use of cryptographic APIs. It is important to consider security and privacy concerns carefully and early when you design features and to avoid attempts to add security and privacy near the end of a project’s development.

Threat modeling (described in Design Phase: Risk Analysis) is the other critical security activity that must be completed during the design phase.

Security Requirements

  • Complete a security design review with a security advisor for any project or portion of a project that requires one. Some low-risk components might not require a detailed security design review.

  • When developing with managed code, use strong-named assemblies and request minimal permission. When using strong-named assemblies, do not use APTCA (Allow Partially Trusted Caller Attribute) unless the assembly was approved after a security review. Without specific security review and approval, assemblies that use APTCA will generate FxCop errors and will fail to pass a Final Security Review (FSR).

  • For online services, all new releases must use the Relying Party Suite (RPS) v4.0 SDK. RPS provides significant security advantages over the current Passport Manager (PPM) SDK; most important being the elimination of the shared symmetric encryption keys, which mitigates security issues involving key distribution, deployment, and administration. This also provides a significantly reduced cost of key revision.

  • (New for SDL 4.1) User Account Control (UAC) is a new feature in Windows Vista that is intended to help the transition to non-administrative users. Comply with UAC best practices to ensure that your application runs correctly as a non-administrator. Exit criteria for this requirement is confirmation from the project team that it has analyzed and minimized the need for elevated privileges and followed best practices for operation in a UAC environment. Following this requirement enables teams to design and develop applications with a standard user in mind. This results in a reduced attack surface exposed by applications, thus increasing the security of the user and system.

  • (New for SDL 4.1) At least 80 percent of a program’s users require an open port in the firewall, and the code that listens on the port must comply with certain quality requirements. Prohibited and permitted actions are covered in the bulleted list that follows. See Appendix D: Firewall Rules and Requirements for additional information. For a discussion of Windows Firewall integration and best practices, please visit http://msdn.microsoft.com/en-us/library/bb736286(VS.85).aspx.

    The following actions are prohibited:

    • Except for security products, disabling of the firewall or changing the state of the firewall. The firewall must only be disabled by explicit user action.
    • Any service or feature that adds, changes, or removes firewall rules automatically at runtime. Except at setup time (that is, during the installation process), programs, features, and services that are not designed specifically as firewall management utilities must not change firewall settings unless the user has explicitly initiated some action.
    • Any service or feature that allows a port to be opened or a rule to be enabled by a user without administrative privileges. A user must be acting as an administrator in order to change the settings of the firewall, and no service or feature (both Windows and non-Windows) must bypass this restriction.
    • Silent activation or enabling of any feature that permits other programs to receive unsolicited traffic. For example, the RemoteAdmin feature permits other RPC-based programs to receive unsolicited traffic. In such cases, the system must obtain user consent before activating such functionality.
    • Programs, services, and features may not configure an external device (for example, a NAT gateway) without user consent.
    • Any interference with Post Setup Security Update or similar functionality designed to ensure that the system is up-to-date prior to accepting incoming traffic without user consent
    • Creation of inbound firewall rules unless the feature or service will receive unsolicited inbound traffic.

    The following actions are permitted:

    • Programs, services, and features may define a firewall rule and leave it disabled for the sake of making it convenient for the user to enable the rule later on.
  • (Updated/New for SDL 4.1) All cryptography must comply with the Microsoft Cryptographic Standards for SDL-covered products. Adhere to the SDL crypto requirements, which at a high-level are:
    • Use AES for symmetric enc/dec.
    • Use 128-bit or better symmetric keys.
    • Use RSA for asymmetric enc/dec and signatures.
    • Use 2048-bit or better RSA keys.
    • Use SHA-256 or better for hashing and message-authentication codes.

Privacy Requirements


Security Recommendations

  • Include in all functional and design specifications a section that describes impacts on security.
  • Write a security architecture document that provides a description of a software project that focuses on security. Such a document should complement and reference existing traditional development collateral without replacing it. A security architecture document should contain, at a minimum:
    • Attack surface measurement. After all design specifications are complete, define and document what the program’s default and maximum attack surfaces are. The size of the attack surface indicates the likelihood of a successful attack. Therefore, your goal should be to minimize the attack surface. You can find additional background information in the papers Fending Off Future Attacks by Reducing Attack Surface and Measuring Relative Attack Surfaces.
    • Product structure or layering. Highly structured software with well-defined dependencies among components is less likely to be vulnerable than software with less structure. Ideally, software should be structured in a layered hierarchy so that higher components (layers) depend on lower ones. Lower layers should never depend on higher ones. Developing this sort of layered design is difficult and might not be feasible with legacy or pre-existing software. However, teams that develop new software should consider layered and highly structured designs.
  • Minimize default attack surface/enable least privilege.
    • All feature specifications should consider whether the features should be enabled by default. If a feature is not used frequently, you should disable it. Consider carefully whether to enable by default those features that are used infrequently.
    • If the program needs to create new user accounts, ensure that they have as few permissions as possible for the required function and that they also have strong passwords.
    • Be very aware of access control issues. Always run code with the fewest possible permissions. When code fails, find out why it failed and fix the problem instead of increasing permissions. The more permissions any code has, the greater its exposure to abuse.
  • Default installation should be secure. Review functionality and exposed features that are enabled by default and constitute the attack surface carefully for vulnerabilities
  • Consider a defense-in-depth approach. The most exposed entry points should have multiple protection mechanisms to reduce the likelihood of exploitation of any security vulnerabilities that might exist. If possible, review public sources of information for known vulnerabilities in competitive products, analyze them, and adjust your product’s design accordingly.
  • If the program is a new release of an existing product, examine past vulnerabilities in previous versions of the product and analyze their root causes. This analysis might uncover additional instances of the same classes of problems.
  • Deprecate outdated functionality. If the product is a new release of an existing product, evaluate support for older protocols, file formats, and standards, and strongly consider removing them in the new release. Older code written when security awareness was less prevalent almost always contains security vulnerabilities.
  • Conduct a security review of all sample source code released with the product and use the same level of scrutiny as for object code released with the product.
  • If the product is a new release of an existing product, consider migration of any possible legacy code from unmanaged code to managed code.
  • Implement any new code using managed code whenever possible.
  • When developing with managed code, take advantage of .NET security features:
    • Refuse unneeded permissions.
    • Request optional permissions.
    • Use CodeAccessPermission Assert and LinkDemand carefully. Use Assert in as small a window as possible.
    • Disable tracing and debugging before deploying ASP.NET applications.
  • Watch for ambiguous representation issues. Hackers will try to force code to follow a dangerous path or URL by hiding their intent in escape characters or obscure conventions. Always design code to deal with full canonical representations, rather than acting on externally provided data. The canonical representation of something is the standard, most direct, and least ambiguous way to represent it.
  • Remain informed about security issues in the industry. Attacks and threats evolve constantly, and staying current is important. Keep your team informed about new threats and vulnerabilities.
  • Ensure that everyone on your team knows about unsafe functions and coding patterns. Maintain a list of your code’s vulnerabilities. When you find new vulnerabilities, publish them. Make security everyone’s business.
  • Be careful with error messages. Sensitive information displayed in an error message can provide an attacker with privileged information, such as a file path on a server or the structure of a query. Such information makes it easier for an attacker to attack any defenses. In general, record detailed failure messages in a secure log, and give the user discreet failure messages.
  • For online services and/or LOB applications, ensure appropriate logging is enabled for forensics.
  • For online services and/or LOB applications, page flow integrity checking should be performed.

Privacy Recommendations


Resources


Risk Analysis

During the design phase of development, carefully review security and privacy requirements and expectations to identify security concerns and privacy risks. It is efficient to identify and address these concerns and risks during the design phase

For security concerns, threat modeling is a systematic process that is used to identify threats and vulnerabilities in software. You must complete threat modeling during project design. A team cannot build secure software unless it understands the assets the project is trying to protect, the threats and vulnerabilities introduced by the project, and details of how the project will mitigate those threats.

Important risk analysis considerations include the following:

  • Threats and vulnerabilities that exist in the project’s environment or that result from interaction with other systems. You cannot consider the design phase complete unless you have a threat model or models that include such considerations. Threat models are critical components of the design phase and reference a project’s functional and design specifications to describe vulnerabilities and mitigations.

  • Code that was created by external development groups in either source or object form. It is very important to evaluate carefully any code from sources external to your team. Failure to do so might cause security vulnerabilities about which the project team is unaware.

  • Threat models that include all legacy code if the project is a new release of an existing program. Such code could have been written before much was known about software security, and therefore could contain vulnerabilities.

  • A Review of the design of high-risk (P1) privacy projects with a privacy subject matter expert and, if necessary, with appropriate legal counsel conducted as soon as possible in the project. Definitions of privacy rankings (P1, P2, P3) can be found in Cost Analysis and Chapter 8 of The Security Development Lifecycle.

  • A detailed privacy analysis to document your project’s key privacy aspects. Important issues to consider include:

    • What personal data is collected?

    • What is the compelling customer value proposition and business justification?

    • What notice and consent experiences are provided?

    • What controls are provided to users and enterprises?

    • How is unauthorized access to personal information prevented?

Security Requirements

  • Complete threat models for all functionality identified during the cost analysis phase. Threat models typically must consider the following areas:

    • All projects. All code exposed on the attack surface and all code written by or licensed from a third party.

    • New projects. All features and functionality.

    • Updated versions of existing projects. New features or functionality added in the updated version.

  • Ensure that all threat models meet minimal threat model quality requirements. All threat models must contain data flow diagrams, assets, vulnerabilities, and mitigation. Threat modeling can be done in a variety of ways using either tools or documentation/specifications to define the approach. For assistance in creating threat models, see "Chapter 9: Stage 4 – Risk Analysis" in The Security Development Lifecycle book or consult other guidance listed in Resources.

  • Have all threat models and referenced mitigations reviewed and approved by at least one developer, one tester, and one program manager. Ask architects, developers, testers, program managers, and others who understand the software to contribute to threat models and to review them. Solicit broad input and reviews to ensure the threat models are as comprehensive as possible.

  • Confirm that threat model data and associated documentation (functional/design specifications) has been stored using the document control system used by the product team.


Privacy Requirements

If a project has a privacy impact rating of P1:

If your project has a privacy impact rating of P2:

  • Complete the Detailed Privacy Analysis in Appendix C: SDL Privacy Questionnaire. The questions will be customized to the behaviors specified in the initial assessment.

  • Hold a design review with your privacy subject matter expert only if one or more of these criteria apply:

    • The privacy subject matter expert requests a design review.

    • You want confirmation that the design is compliant.

    • You wish to request an exception.

If your project has a privacy impact rating of P3, there are no privacy requirements during this phase.


Security Recommendations

  • The person who manages the threat modeling process should complete threat modeling training before working on threat models.

  • After all specifications and threat models have been completed and approved, the process for making changes to functional or design specifications—known as design change requests (DCRs—should include an assessment of whether the changes alter existing threats, vulnerabilities, or the effectiveness of mitigations.

  • Create an individual work item for each vulnerability listed in the threat model so that your quality assurance team can verify that the mitigation is implemented and functions as designed.


Resources

Content Disclaimer

The following documentation on the Microsoft Security Development Lifecycle, version 4.1 is for illustrative purposes only.

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 should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented herein. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, OR STATEMENTS ABOUT APPLICABILITY OR FITNESS OF PURPOSE FOR ANY ORGANIZATION ABOUT THE INFORMATION IN THIS DOCUMENT.

Page view tracker