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:

  • RSAProtectedConfigurationProvider. This is the default provider and uses RSA public key encryption to encrypt and decrypt data. It can also be used across multiple machines (for example web.config file secrets in a cluster). See How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA
  • DPAPIProtectedConfigurationProvider. This provider uses the Windows Data Protection API (DPAPI) to encrypt and decrypt data. See How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI
  • In a single server deployment scenario, utilities such as Aspnet_setreg.exe are available to protect secrets. Also see the Knowledge Base (KB) article How to use the ASP.NET utility to encrypt credentials and session state connection strings. .NET Framework 2.0 introduced a protected configuration feature that can be used to encrypt sensitive configuration file data using a command line tool Aspnet_Regiis.exe. How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA explains how to use the Aspnet_Regiis.exe tool with the RSAProtectedConfigurationProvider to encrypt sections of the configuration file.

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

• Index of Security Checklists. While focused on .NET and web application development, much of the guidance here is technology agnostic.
• Perform a Security Code Review for Managed Code (Baseline Activity).
• Anti-XSS 4.2 Library.
• CAT.NET, a code analysis tool for .NET.
• Microsoft Source Code Analyzer for SQL Injection.

Content Disclaimer