Phase 3: Implementation The Implementation phase is when the end user of your software is foremost in your mind. During this phase you create the documentation and tools the customer uses to make informed decisions about how to deploy your software securely. To this end, the Implementation phase is when you establish development best practices to detect and remove security and privacy issues early in the development cycle.

On This Page

Creating Documentation and Tools for Users That Address Security and Privacy
Security Recommendations
Privacy Recommendations
Resources
Establish and Follow Best Practices for Development
Security Requirements
Privacy Requirements
Security Recommendations
Resources

Creating Documentation and Tools for Users That Address Security and Privacy

Every release of a software program should be secure by design, in its default configuration, and in deployment. However, people use programs differently, and not everyone uses a program in its default configuration. You need to provide users with enough security information so they can make informed decisions about how to deploy a program securely. Because security and usability might conflict, you also need to educate users about the threats that exist and the balance between risk and functionality when deciding how to deploy and operate software programs.

It is difficult to discuss specific security documentation needs before development plans and functional specifications stabilize. As soon as the architecture is reasonably stable, the user experience (UX) team can develop a security documentation plan and schedule. Delivering documentation about how to use a software program securely is just as important as delivering the program itself.

Security Recommendations

• Development management, program management, and UX teams should meet to identify and discuss what information users will need to use the software program securely. Define realistic use and deployment scenarios in functional and design specifications. Consider user needs for documentation and tools.

• User experience teams should establish a plan to create user-facing security documentation. This plan should include appropriate schedules and staffing needs. Communicating the security aspects of a program to the user in a clear and concise fashion is as important as ensuring that the product code or functionality is free of vulnerabilities.

• For new versions of existing programs, solicit or gather comments about what problems and challenges users faced when securing prior versions.

• Make information about secure configurations available separately or as part of the default product documentation and/or help files. Consider the following issues:

  • The program will follow the best practice of reducing the default attack surface. However, what should users know if they need to activate additional functionality? What risks will they be exposed to?

  • Are there usage scenarios that allow users to lock down or harden the program more securely than the default configuration without losing functionality? Inform users about how to configure the program for these situations. Better yet, provide easy-to-use templates that implement such configurations.

  • Inform users about security best practices, such as removing guest accounts and default passwords. External security notes from threat modeling are good sources of information to consider.

  • For programs that use network or Internet communications, describe all communications channels and ports, protocols, and communications configuration options (and their associated security impacts).

  • To support earlier versions of the software and older protocols, it is often necessary to operate less securely. Do not enable insecure protocols in the default configuration. You might still need to deliver them with the release, so inform users about the security implications of older protocols and backward compatibility. Inform users about these trade-offs and how to disable older compatibility modes to achieve the best possible security.

  • Tell users how they can ensure safe use of the program or take advantage of built-in security and privacy features.

Privacy Recommendations

• If the program contains privacy controls, create deployment guides for organizations to help them protect their users’ privacy (for example, Group Policy controls).

• Create content to help users protect their privacy when using the program (for example, secure your subnet).

Resources

• The Security Development Lifecycle (ISBN 9780735622142; ISBN-10 0-7356-2214-0), Chapter 10: Stage 5 – Creating Security Documents, Tools, and Best Practices for Customers

• Templates contained in the Windows Server 2003 Security Guide

Establish and Follow Best Practices for Development

To detect and remove security issues early in the development cycle, it helps to establish, communicate, and follow effective practices for developing secure code. A number of resources, tools, and processes are available to help you accomplish this goal. Investing time and effort to apply effective practices early will help you eliminate security issues and avoid having to respond to them later in the development cycle—or even after release, which is expensive.

Security Requirements

• Build tools. Use the currently required (or later) versions of compilers to compile options for the Win32®, Win64, WinCE and Macintosh target platforms, as listed in Appendix E: SDL Required and Recommended Compilers, Tools, and Options for All Platforms.

  • Compile C/C++ code with /GS or approved alternative on other platforms.

  • Link C/C++ code with /SAFESEH or approved alternative on other platforms.

  • Link C/C++ code with /NXCOMPAT (for more information, refer to Appendix F: SDL  Requirement No Executable Pages) or approved alternative on other platforms.

  • Use MIDL with /robust or approved alternative on other platforms.

• Code analysis tools. Use the currently required (or later) versions of code analysis tools for either native C and C++ or managed (C#) code that are available for the target platforms, as listed in ”Appendix E: Required and Recommended Compilers, Tools, and Options for All Platforms”.

• Banned Application Programming Interfaces (APIs). New native C and C++ code must not use banned versions of string buffer handling functions. Based on analysis of previous Microsoft Security Response Center (MSRC) cases, avoiding use of banned APIs is one actionable way to remove many vulnerabilities. For more information, see Security Development Lifecycle (SDL) Banned Function Calls and The Security Development Lifecycle (ISBN 9780735622142; ISBN-10 0-7356-2214-0), Chapter 19: SDL Banned Function Calls, pp. 241-49.

• No writable shared PE sections. Sections marked as shared in shipping binaries represent a security threat. Use properly secured dynamically created shared memory objects instead. See "Appendix G: SDL Requirement Shared Sections”.

• For online services and/or LOB applications, follow data input validation and output encoding requirements to address potential cross-site scripting vulnerabilities.
• For online services and/or LOB applications that access a SQL database, do not use “ad-hoc” SQL queries in order to avoid SQL injection attacks.
• For online services and/or LOB applications that implement Web services, use an approved XML parser.
• (New/Updated for SDL 4.1) Fix issues identified by code analysis tools for managed code. Run the FxCop code analysis tool against all managed code, and fix all violations of the “Security” rules for the version of FXCop used. Note that there are slight differences in the security rules for FXCop 1.35 (from Visual Studio® 2005) and FXCop 1.36 (from Visual Studio 2008). These differences are explained in the code analysis blog entry at http://blogs.msdn.com/fxcop/archive/2008/01/07/faq-which-rules-shipped-in-which-version.aspx. When using .NET Framework version 3.5, FXCop 1.36 must be used. Security rules for FXCop 1.35 can be found at http://msdn.microsoft.com/en-us/library/ms182296(VS.80).aspx. Security rules for FXCop 1.36 can be found at http://msdn.microsoft.com/en-us/library/ms182296.aspx.
• (New for SDL 4.1: Online services and/or LOB applications only) Use ViewStateUserKey to add a layer of defense against XSRF attacks. All ASP.NET pages that require authentication must set the System.Web.UI.Page.ViewStateUserKey property to a unique value per user (such as the user's session ID) to help protect the application against cross-site request forgery attacks.
• (New for SDL 4.1) /GS compiler option for managed code. All unmanaged C and C++ code must be compiled with the /GS compiler option. /GS—which turns off /GS—is not allowed. All build files must include the /GS compiler option so that all native code C and C++ binaries are compiled this way. High risk code (code facing the Internet, file parsers, and ActiveX controls) must have #pragma strict_gs_check(on) in an application wide header file, such as stdafx.h.
• (New for SDL 4.1) Address Space Layout Randomization (ASLR) must be enabled on all native code (unmanaged) binaries to protect against return-to-libc class of attacks. Enabling this functionality requires the flag /DynamicBase in the PE header of all binaries. This flag can be inserted using Visual Studio 2005 SP1 or later. Earlier versions do not contain a linker version that supports it. DumpBin can be used to manually verify if ASLR is enabled on a binary.
• (New for SDL 4.1) SQL only execute permission. Ensure that the application domain group is granted only execute permissions only on your stored procedures. Do not grant any other permission on your database to any other user or group.
• (New for SDL 4.1) SQL parameterized query. All online services and/or LOB applications accessing a database must do so only using parameterized queries.
• (New for SDL 4.1) SQL stored procedures. All online services and/or LOB applications accessing databases should always use stored procedures. Do not use “exec @sql” construct in your stored procedures.

Privacy Requirements

Establish and document development best practices for the development team. Communicate any design changes that affect privacy to your team’s privacy lead so that they can document and review any changes.

Security Recommendations

• Comply with minimal Standard Annotation Language (SAL) code annotation recommendations as described in "Appendix H: SDL Standard Annotation Language (SAL) Recommendations for Native Win32 Code”. Annotating code helps existing code analysis tools identify implementation issues better and also helps improve the tools. SAL annotated code has additional code analysis requirements, as described in SDL SAL Recommendations.

• All executable programs written using unmanaged code (.EXE) should call the HeapSetInformation interface, as described in "Appendix I: SDL Requirement Heap Manager Fail Fast Setting”. Calling this interface helps provide additional defense-in-depth protection against heap–based exploits (Win32 only).

• Review available information resources to adopt appropriate coding techniques and methodologies. For a current and complete list of all development best practice information and resources, see Writing Secure Code , Second Edition  (ISBN 9780735617223; ISBN-10 0-7356-1722-8).

• Review recommended development tools and adopt appropriate tools, in addition to the tools required by SDL. These tools can be found in The Security Development Lifecycle (ISBN 9780735622142; ISBN-10 0-7356-2214-0), Chapter 21: SDL-Required Tools and Compiler Options.

• Define, document, and communicate to your entire team all best practices and policies based on analysis of all the resources and tools listed in this document.

  • Document all tools that are used, including compiler versions, compile options (for example, /GS), and additional tools used. Also, forecast any anticipated changes in tools. For more information about minimum tool requirements and related policy, review How Are New Recommendations and New Requirements Added to the Security Development Life Cycle Process?

  • Create a coding checklist that describes the minimal requirements for any checked-in code. This checklist can include some of the items from Writing Secure Code, Second Edition "Appendix D:A Developer’s Security Checklist” (p. 731), clean compile warning level requirements (/W3 as minimal, and /W4 clean as ideal), or other desired minimum standards.

  • Establish and document how the team will enforce these practices. Is the team running scripts to check for compliance when code is checked in? How often do you run analysis tools? The development manager is ultimately responsible for establishing, documenting, and validating compliance of development best practices.

  • For online services and/or LOB applications that use JavaScript, avoid use of the eval() function.
  • Additional development best practices for security can be divided into three general categories:
    1. Review available information resources to adopt coding techniques and methodologies that are appropriate for the product.
    2. Review recommended development tools to adopt, and use those that are appropriate for the product, in addition to the tools required by the SDL.
    3. Define, communicate, and document all best practices and policies for the product. Based on analysis of all of the resources and tools listed above, product teams should adopt and communicate best practices, policies, and tools. This information should be documented and widely communicated to the entire product team to ensure best practices are adopted and followed.
       

       Document all tools used. This includes all compiler versions, compile options (for example, /GS), and additional tools used for static code analysis. This should also forecast any changes in tools anticipated. As updated versions of tools (both compilers and code analysis tools) are made available, products that have not yet released a final beta will likely be required to adopt the newest version of the tools. Products that have released their final beta prior to the availability of updated tools are not required to adopt the latest versions of tools. Please review How Are New Recommendations and New Requirements Added to the Security Development Lifecycle Process? for more information on how policy is established on minimum tool requirements.

  • (New for SDL 4.1) Safe error messages. Each error message should meet the following goals: 1. Provide the user with a clear message so that the issue at hand can be readily understood and the appropriate action can be taken.
    2. Do not disclose information that would materially help an attacker successfully compromise a system.
  • (New for SDL 4.1)Use the Windows Imaging Component (WIC). WIC provides an extensible framework for reading and manipulating images, image files, and image metadata. It represents a standard interface. All software products that process digital image data must perform any encoding or decoding of image data solely and exclusively using the Windows Imaging Component (WIC) and therefore must remove any potential custom (image) codecs from the product codebase. For more information, see http://msdn2.microsoft.com/en-us/library/ms737408.aspx.
  • (New for SDL 4.1) Use proper http.sys URL canonicalization. Web servers often make security decisions based on a requested URL from a user. For example, a Web server may deny access to certain files, such as configuration files, directly through the Web server; rather, such files can only be viewed and manipulated with text editing tools, such as Visual Studio, against the local file system.
    

    The weakness with this approach is that the authorization check is based on the name of the resource, rather than based on an access control mechanism, such as an ACL, enforced by the operating system. And this leads to canonicalization (C14N) vulnerabilities, because there is often more than one way to name a resource. All Web servers have suffered from such issues, but http.sys does not offer much protection from C14N vulnerabilities. It is therefore important that developers using http.sys follow these recommendations to defend themselves. Any application that uses http.sys should follow these guidelines.

    Managed Code

    1. Limit the URL length to no more than 16,384 characters (ASCII or Unicode). This is the absolute maximum URL length, based on the default IIS 6 setting. Web sites should strive for a length shorter than this, if possible.
    2. Use the standard .NET Framework file I/O classes (such as FileStream), since these take advantage of the canonicalization rules in the .NET FX.
    3. Explicitly build an allow-list of known filenames.
    4. Explicitly reject known filetypes you will not serve; UrlScan rejects: exe, bat, cmd, com, htw, ida, idq, htr, idc, shtm[l], stm, printer, ini, pol, dat files.
    5. Catch the following exceptions: System.ArgumentException (for device names), System.NotSupportedException (for data streams), System.IO.FileNotFoundException (for invalid escaped filenames), and System.IO.DirectoryNotFoundException (for invalid escaped dirs).
    6. Do not call out to Win32 file I/O APIs.
    7. On an invalid URL, gracefully return a 400 error to the user, and log the real error.

    Unmanaged Code

    1. Limit the URL length to 16,384 characters (ASCII or Unicode).
    2. Prepend \\?\ to the filename prior to accessing the file system, since this forces the file system to bypass filename equivalency checks. This is not perfect, because it does not prevent data streams (::$DATA, for example).
    3. Normalize the URL by URL double-decoding the filename, and check that the first decode matches the second decode. If not, it's an error.
    4. Look for known “bad characters” in the filename.
    5. Look for known “bad strings” in the filename.
    6. On an invalid URL or filename, return a 400, and log the real error.
  • (New for SDL 4.1) Do not use banned APIs. Several security bulletins have occurred because of insecure use of various standard C library functions. The problem arises when the attacker controls the incoming buffer, and the code uses data from the buffer to determine the maximum buffer length to copy.
  • (New for SDL 4.1) Use Standard Annotation Language (SAL). Annotate all functions that read from or write to a buffer passed as an argument to the function.
  • (New for SDL 4.1) Do not use the JavaScript eval() function (or equivalents). The JavaScript eval() function is used to interpret a string as executable code. While eval() enables a Web application to dynamically generate and execute JavaScript (including JSON), it also opens up potential security holes, such as injection attacks, where an attacker-fed string may also get executed. For this reason, the eval() function or functional equivalents, such as setTimeout() and setInterval(), should not be used.
  • (New for SDL 4.1) Enforced automated banned API replacement. Add the following to an often-used header file, such as stdafx.h:
    
    #define _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES (1) 

    
    

    This informs the compiler that you want to upgrade various C runtime functions to safer versions. For example, some calls to strcpy will upgrade to strcpy_s. For more information on banned APIs, visit http://blogs.msdn.com/sdl/archive/2008/10/22/good-hygiene-and-banned-apis.aspx.

  • (New for SDL 4.1) Encode long-lived pointers. Long-lived pointers (for example, globally scoped function pointers or pointers to shared memory regions) are subject to corruption through a buffer overrun attack that can lead to code execution attacks. This recommended defense raises the bar substantially on the attackers.
    
    

    Identify any long-lived pointers in your code. Access to these functions should be through encoded pointers using code like this:

    
    
    // g_pFoo is a global point that points to foo
              void g_pFoo = EncodePointer(&foo);
              // Now get the encoded pointer
              void *pFoo = DecodePointer(g_pFoo);
    

    
    

    The global pointer (g_pFoo) is encoded during the initialization phase, and its true value remains encoded until the pointer is needed. Each time g_pFoo is to be accessed, the code must call DecodePointer.

  • (New for SDL 4.1) Fix code flagged by /W4 compiler warnings. Attackers are finding and exploiting more obscure classes of vulnerabilities as traditional stack and heap buffer overruns become harder to find. To this end, it is recommended that all W4 warning messages are fixed prior to release.
  • (New for SDL 4.1) Safe redirect, online only. Automatically redirecting the user (through Response.Redirect, for example) to any arbitrary location specified in the request (such as a query string parameter) could open the user to phishing attacks. Therefore, it is recommended that you not allow HTTP redirects to arbitrary user-defined domains.
  • (New for SDL 4.1) No global exception handlers. Exceptions are a powerful way to handle run-time errors, but they can also be abused in a way that could mask errors or make it easier for attackers to compromise systems.
  • (New for SDL 4.1) Components must have no hard dependencies on the NTLM protocol. All explicit uses of the NTLM package for network authentication must be replaced with the Negotiate package. All client authentication calls must provide a properly formatted target name (SPN). The purpose of the requirement is to enable systems to use Kerberos in place of NTLM whenever possible.

Resources

• The Security Development Lifecycle (ISBN 9780735622142; ISBN-10 0-7356-2214-0), Chapter 11: Stage 6 – Secure Coding Policies,

  Chapter 19: SDL Banned Function Calls

• Compiler Security Checks in Depth

• SAL Annotations

Content Disclaimer