Partilhar via

  • Artigo
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.

    The AllowPartiallyTrustedCallersAttribute (APTCA) enables an assembly to be called by untrusted code. APTCA behavior is different depending on the version of the framework, but the general effect is the same: potentially dangerous functionality is now exposed to partially trusted code, and the effects of this additional attack surface exposure have to be mitigated by security checks, strong enforcement mechanisms, and review. In order to comply with this requirement, you should follow these steps:

    1. Determine whether or not your assembly has enabled the AllowPartiallyTrustedCallersAttribute. You may do this by either looking for the annotations in your source code or using tools like FxCop, which will flag usage. If you determine that this attributes is not enabled, you are compliant with this requirement, no review is required, and you may skip the rest of these steps.
    2. If your assembly has enabled the AllowPartiallyTrustedCallers attribute, your assembly needs to be reviewed by project security experts.

  • 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.

  • (Updated for SDL 5.2) User Account Control (UAC) is a security feature in Windows Vista, Windows 7, Windows Server 2008, and Windows Server 2008 R2. It is intended to help the transition to regular use of non-administrative privilege by client applications.

  • (Updated for SDL 5.2) Comply with UAC best practices and ensure that your application runs with least privilege whenever possible. 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. Highly privileged features of the application (such as those that perform administrative functions) are separated out and placed behind an elevation prompt as appropriate. Following this requirement enables teams to design and develop their applications with a standard user in mind. This results in a reduced attack surface exposed by applications, which increases the security of the user and the system.

  • If a program’s users require an open port in the firewall, then 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 https://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.

  • 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.
    • Support certificate revocation.
    • Limit lifetimes for symmetric keys and asymmetric keys without associated certificates
    • Support cryptographically secure versions of SSL (must not support SSL v2).
    • Use cryptographic certificates reasonably and choose reasonable certificate validity periods.
    • (New for SDL 5.2) Use Transport Layer encryption securely. Properly use Transport Layer Security (TLS) when communicating with another entity, and verify that your service checks the Common Name attribute to be sure it matches the host with which you intended to communicate. Verify that your service consults a certificate revocation list (CRL) for an updated list of revoked certificates at a frequent interval. If your service is accessible via a browser, confirm that no security warnings appear at any visited URL for any supported browser.

  • Mitigate against Cross-Site Scripting (XSS), which is a client-side code injection attack that allows arbitrary code execution in your customer’s browser. XSS has been used by attackers to capture credentials, financial data, and other sensitive information. It has also been used to map back-end server space and in cases of vulnerable browser plug-ins, completely compromise a customer’s machine. Perform all pre-approved tests that have been explicitly approved by your security advisor. If this is an ASP.NET application, this should include use of CAT.NET. All test results should be uploaded into your project tracking system to validate against project requirements. All issues found by approved tests must be triaged with the security advisor and fixed in accordance with the SDL bug bar. Suggested tools include: Web Protection (Anti-XSS) Library, CAT.NET, and Watcher (from Casaba Security for the MAC portion).

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:

    • (Updated for SDL 5.2) 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. Use of tools like Attack Surface Analyzer (ASA) and Web Application Configuration Analyzer (WACA) should be required for existing products to identify the existing attack surface.
    • 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.

  • Hardware security design review. Conduct a high-level security design review for hardware products that are new or being updated in the current release. The goal of a high-level hardware security design review is to identify aspects of the design that could lead to security vulnerabilities. This might include checks such as:

    1. Methods of cryptographic key generation and storage.
    2. Methods of data storage, including encryption. For example, does the design meet Microsoft Cryptographic Standards?
    3. Methods of data manipulation.
    4. The "business or customer impact" of the data being manipulated and stored. For example, whether the data could be considered High Business Impact (HBI), Moderate Business Impact (MBI), or Low Business Impact (LBI) by the product's expected customers.
    5. Use of standard versus custom protocols.
    6. Presence of JTAG /debugging back doors. Joint Test Action Group (JTAG) is the common name used for the IEEE 1149.1 standard entitled Standard Test Access Port and Boundary-Scan Architecture for testing/debugging access ports using a boundary scan.
    7. Firmware upgrade features and procedures (security, process, and scalability).
    8. Firmware development process – /analyze, fuzzing and/or other security tools may be applicable.

  • Integration-points security design review. Enterprise server application suites, software-as-a-service (SaaS) offerings, and security products interact with a variety of other products and platforms in order to provide robust, enterprise-focused services. It is not sufficient to threat model these products by themselves because the points of interaction with other products are the source of many nuanced security issues. Conduct an integration-points security design review with dependent product teams across your end-to-end scenarios. Examples of products that should do this are:

    • Products designed to handle high business impact (HBI) data.
    • Enterprise applications and services.
    • Security products.
    • SaaS offerings.

    The exit criteria for this recommendation is that the product teams and security reviewers/owners have reviewed and are satisfied with the security threat mitigations and validations provided at each point of integration.

  • Strong log-out and session management. Proper session handling is one of the most important parts of web application security. At the most fundamental level, sessions must be initiated, managed, and terminated in a secure manner. If a product employs an authenticated session, it must begin as an encrypted authentication event to avoid session fixation.

    • A session identifier/token must never be transmitted via the URL to avoid side-jacking via the referrer header or browser history.
    • All session data must be maintained on the server, not the client, to avoid tampering.
    • Sessions must be completely terminated on the server side via logout and timeout mechanisms. When multiple sessions are tied to a single authentication event, all of the sessions tied to that event must be terminated by logout/time-out.

    The following items must be met as part of the exit criteria for this recommendation:

    • When multiple sessions are tied to a single user identity, they must be collectively terminated on the server side at timeout or logout.
    • Authentication events must invalidate unauthenticated sessions and create a new session identifier.
    • Logout functionality is available on every page.
    • Session state, outside of a single identifier, is maintained on the server and not accepted from the user (including via cookie or header).
    • Session tokens are not present in the URI.
    • Timeout functionality is present and timeout thresholds are documented along with the rationale.

    Apply no-open header to user-supplied downloadable files. Use the HTTP Header X-Download-Options: no-open for each HTTP file download response that may contain user-controllable content. Recommended tool: Casaba Passive Security Auditor.

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. Threat modeling applies to all products and services, all code types, and all platforms. Verify that threat models exist for all attack surfaces and new features and each threat model includes: diagrams showing the software and all trust boundaries, STRIDE threats enumerated for each element that crosses a trust boundary or that connects to a data flow that crosses a trust boundary, mitigations for all threats, a list of assumptions made while threat modeling, all non-platform external dependencies that the elements in the threat model rely on.

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 code exposed on the attack surface and all code written by or licensed from a third party.

    • All features and functionality.

    • 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.

  • (New for SDL 5.2) Follow NEAT security user experience (UX) guidance to ensure that warnings are Necessary, Explained, Actionable, and Tested.

    • Microsoft has produced guidance to help engineers design better warnings. The guidance is summarized in the four-letter acronym NEAT—Necessary, Explained, Actionable, and Tested. The objective of NEAT is to improve security warnings in products by making sure they are:
      • Necessary. Does the user really need to be presented with the decision?
      • Explained. Does the UX present all the information the user needs to make this decision?
      • Actionable. Is there a set of steps users can take to make good decisions in both benign and malicious scenarios?
      • Tested. Has the warning been reviewed by multiple engineers to make sure users will understand how to respond to the warning?
    • Improve security-related prompts in your products to enable customers to make good security decisions that protect them from harm.
    • Users face a barrage of decisions about whom and what to trust, and when to be concerned about their security. These security decisions arise when users initiate activities like installing an executable from the web, using an application that needs to get through the firewall, and allowing a web application to access their sensitive data. These decisions also arise when a product prompts the user to take an action to improve their security, such as when Windows prompts the user to reboot or to turn the Windows Firewall on. With attacks moving “up the stack” from silent code exploits to social engineering, good security UX gives you a chance to help the user avoid running malicious software.

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