Partilhar via

  • Artigo
Dd831972.Implementation(en-us,MSDN.10).png

Phase 3: Implementation for LOB

For the LOB-SDL, additional tasks beyond the standard SDL Implementation phase include an internal review, which incorporates security checklists and standards, a self-directed code review, and code analysis.

On This Page

Internal Review
Incorporate Security Checklist and Review Policies
Conduct ‘Self’ Code Review
Run Code Analysis Tools and Incorporate Security Libraries
Security Requirements
Security Recommendations
Resources

Internal Review

The internal review is conducted by the application team.

Incorporate Security Checklist and Review Policies

  • Tools. A mix of freeware, third-party tools to perform code analysis, or penetration testing can be employed during this phase. The challenge tools present is that they often require security expertise to filter false positives or to maximize the results from the tool. This is especially true for more sophisticated toolsets.

  • Security checklist. Development teams must review available information resources to adopt appropriate coding techniques and methodologies. A coding checklist that describes the minimal requirements for any checked-in code for ASP.NET version 2.0 applications. See checklist items from the Security Checklist Index from Microsoft Patterns and Practices.

  • Review internal policies and standards. Review internal policies created by the central security and policy team around application development and hosting to ensure that development teams are in sync with the security policies relevant to their application design. These policies may also reflect domestic and international legal requirements.

  • Review and develop deployment guidelines. The application team needs to answer this question: How will the application be securely deployed removing artifacts, test code, and settings that are needed during development and testing? For example, web.config files in ASP.NET often contain the following statement to facilitate debugging during this phase.

    
<compilation debug="true">
<trace enabled="true"/>

    However, it needs to be explicitly turned off in production, otherwise a malicious user may be able to take advantage of these settings to profile the application that could lead to an actual exploit. Whether there is a manual or automated process, the development team needs to work with the owners of the production servers to ensure that inappropriate code, artifacts, and settings are not actually used in production.

  • Encrypt all secrets in text format whether in source code, web.config, machine.config, or any file. Unencrypted, these secrets are prone to discovery and can easily allow a partially compromised application or system to be further exploited, thus increasing the impact of the exploit. All passwords, connection strings with passwords, encryption keys, credentials, and other secrets are stored encrypted when stored in configuration files. Secrets must never be in source code encrypted or plaintext. Use one or more of the following as a countermeasure:

  • (New for SDL 5.2) For multiple servers and clusters, use Distributed Key Manager (DKM) (preferred) or RSA.

  • (New for SDL 5.2) Privacy.NET Framework 2.0 introduced a protected configuration feature that can be used to encrypt sensitive configuration file data using the command line tool Aspnet_Regiis.exe. How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA explains the process of using the Aspnet_Regiis.exe tool with the RSAProtectedConfigurationProvider to encrypt sections of the configuration file.

  • Input validation. Input validation must be applied at all identified entry points (including form fields, QueryStrings, cookies, HTTP headers, and web service parameters). It is a security practice never to trust user input data without first confirming its authenticity. Verify that all inputs to the application are validated on the server side before consuming. String data is validated for length and format. Where possible use regular expressions to validate format. Make sure numeric data is validated for range (upper and lower bound) and type (signed vs. unsigned). String data should preferably use inclusion list (known, valid, and safe input) rather than exclusion list (rejecting known malicious or dangerous input).

  • Line of Business Secure Code Review. High-risk items (Pri 1) that are considered the most sensitive or important for security should be reviewed in depth at the earliest opportunity. Resolve any Severity 1 bugs or bugs that are, per the Code Review Checklist, a standards violation. If the bug cannot be fixed, document the underlying infrastructure or framework limitation. Resolve all bugs that are moderate or higher based on the SDL Bug Bar. Development owners for all source code and testing owners for all binaries have been identified, documented, and archived—for example, in the source tracking system used by the product. All source code is assessed and assigned a priority—Pri 1, Pri 2, and Pri 3. This information is recorded in a document or spreadsheet and is archived in a tracking bug for ease-of-discovery.

  • Conduct Internal Security Design Review. An architecture and design review helps you validate the security-related design features of your application before you start the development phase. Enter all security design requirements in the bug tracking system, triage the defects with the team and security advisor, correct all defects that are Severity 1 or higher, update threat models and work items accordingly.

  • Secure sensitive data-at-rest. High business impact (HBI) data needs to be encrypted "at-rest," that is, when located in your database server or other data stores. Ensuring that HBI data is encrypted with appropriate encryption algorithms and key strength when at-rest in a data-store, and that this encryption takes place within the data store. Where possible, leveraging existing operating system or server functionality to manage encryption rather than building such functionality from scratch. Be sure that that this encryption actually secures sensitive data. For SQL Server, use SQL Server Transparent Data Encryption to encrypt the entire database. Note that this approach still requires good management of any keys used for encryption. Use T-SQL functions and SQL Server infrastructure to encrypt specific data elements.

  • Secure sensitive data-in-transit. Encryption should be used for any HBI data that is transmitted over wired or wireless connections on the corporate network (corpnet) or is extranet/Internet-facing. Encryption should be used for any medium business impact (MBI) information in transit via wireless or wired connections when in-transit across the Internet.

Conduct ‘Self’ Code Review

The development team carries out ‘self’ code reviews of the application source code to detect low-hanging security vulnerabilities. See How to Perform a Security Code Review for Managed Code (Baseline Activity).

Run Code Analysis Tools and Incorporate Security Libraries

Use static analysis and runtime security tools. As appropriate, incorporate security libraries. The following is a list of free tools available from Microsoft for download.

Security Requirements

  • Microsoft Anti-Cross-Site Scripting Library V4.2. Incorporate Anti-XSS library to protect ASP.NET web-based applications from XSS attacks. This library offers a more rigorous “white-list” approach than the native encoding methods found in .NET. Also featured is new support for globalization also not present in the .NET library.
  • CAT.NET. Run CAT.NET on managed code (C#, Visual Basic .NET, J#) applications. CAT.NET is a snap-in to the Visual Studio IDE that helps you identify exploitable code paths for security vulnerabilities, such as Cross-Site Scripting - SQL Injection - Process Command Injection - File Canonicalization - Exception Information - LDAP Injection - XPATH Injection - Redirection to User Controlled Site.
  • FxCop. FxCop is an application that analyzes managed code assemblies (code that targets the .NET Framework common language runtime) and reports information about the assemblies, such as possible design, localization, performance, and security improvements.
  • Microsoft Source Code Analyzer for SQL Injection. Run this static code analysis tool that helps identify SQL injection vulnerabilities in Active Server Pages (ASP) code.

Security Recommendations

Security vulnerabilities identified during self-review and through code analysis tools should be logged under the project's bug tracking system.

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