Security Engineering Explained - Chapter 3 - Security Design Guidelines

From Guidance Share

(Difference between revisions)
Jump to: navigation, search
Revision as of 21:59, 26 November 2006 (edit)
Admin (Talk | contribs)

← Previous diff
Current revision (09:44, 24 January 2010) (edit)
JD (Talk | contribs)

Line 1: Line 1:
 +<em style="margin:0;background-color:#cedff2;font-family:sans-serif;border:1px solid #a3b0bf;text-align:center;color:#000;padding:0.2em 0.4em;">
 +Note - patterns & practices Security Engineering is now live at
- J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Jason Taylor, Rudolph Araujo - J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Jason Taylor, Rudolph Araujo

Current revision

Note - patterns & practices Security Engineering is now live at

- J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Jason Taylor, Rudolph Araujo



Design guidelines represent proven practices that have evolved over time to reduce risks associated with designing applications. Adopting security design guidelines can help reduce your attack surface by addressing common vulnerabilities, allowing you to focus on the unique aspects of your design. This module summarizes the patterns & practices approach to security design guidelines by explaining what it is and why you should use it. It also describes the key concepts behind the approach.


Designing a secure application can present architects and developers with many challenges. Design guidelines represent the set of practices that can be employed to reduce the risk of security vulnerabilities.

Each guideline must meet the following qualifications before it is included:

  • Actionable. Must be associated with a vulnerability that can be mitigated through the use of the guideline.
  • Relevant. Must be associated with a vulnerability that is known to affect real applications.
  • Impactful. Must represent key engineering decisions that will have a wideranging impact.

The set of guidelines is distilled into a pattern-based security frame, or framework, that describes all of the areas in which poor design can lead to security vulnerabilities. The security frame allows the inclusion of additional guidelines or the refinement of existing guidelines based on newly discovered vulnerabilities.

Design guidelines include both deployment considerations and design considerations.

Security Frame

The security frame is a pattern-based information model that defines a set of security related categories specifically for the application type you are designing. These categories represent the areas where security mistakes are most often made. This security guidance includes context-specific security frames for each major application type.

Categories of Vulnerabilities

Design guidelines are organized by the common application vulnerability categories contained in the security frame, including input / data validation, authentication, authorization, configuration management, sensitive data, cryptography, exception management and auditing and logging. These represent the key areas for application security design, where mistakes are most often made.

Table 3.1 lists the set of vulnerability categories that is common to most application types along with the associated potential problems that can occur due to bad design.

Table 3.1. Application Vulnerabilities and Potential Problems

Vulnerability Category

Potential Problem Due to Bad Design

Input / Data Validation

Insertion of malicious strings in user interface elements or public APIs. These attacks include command execution, cross - site scripting (XSS), SQL injection, and buffer overflow. Results can range from information disclosure to elevation of privilege and arbitrary code execution.


Identity spoofing, password cracking, elevation of privileges, and unauthorized access.


Access to confidential or restricted data, data tampering, and execution of unauthorized operations.

Configuration Management

Unauthorized access to administration interfaces, ability to update configuration data, and unauthorized access to user accounts and account profiles.

Sensitive Data

Confidential information disclosure and data tampering.


Access to confidential data or account credentials, or both.

Exception Management

Denial of service and disclosure of sensitive system-level details.

Auditing and Logging

Failure to spot the signs of intrusion, inability to prove a user’s actions, and difficulties in problem diagnosis.

Application-Specific Guidelines

Depending on the application being designed, the types of issues that must be addressed vary. The categories defined in each application-specific security frame were defined by security experts who have examined and analyzed the top security issues across many applications. They have been refined with input from Microsoft consultants, product support engineers, customers, and Microsoft partners.

For example, when you design a secure Web application, it is important that you follow guidelines to ensure effective user authentication and authorization, to protect sensitive data as it is transmitted over public networks, and to prevent attacks such as session hijacking.

Some of the important Web application issues that must be addressed with secure design practices are shown in Figure 3.1.


Figure 3.1 Web application design issues

When you design a secure, smart client application, the set of guidelines changes to address the most important threats for this application type. For example, authentication and authorization are no longer such important concerns; however, input / data validation and exception handling are.

Deployment Considerations

During the application design phase, you should review your corporate security policies and procedures together with the infrastructure that your application is to be deployed on. Frequently, the target environment is rigid, and your application design must reflect the restrictions. In some cases, you may need to make design tradeoffs; for example, because of protocol or port restrictions or specific deployment topologies. Identify constraints early in the design phase to avoid surprises later, and involve members of the network and infrastructure teams to help with this process.

Figure 3.2 shows the various deployment aspects that require design-time consideration.


Figure 3.2 Deployment considerations

Design Guidelines Summary

Design guidelines are best practices associated with specific known vulnerabilities and common design mistakes. Patterns & practices security guidance contains design guidelines for a variety of application types. Table 3.2 summarizes general design guidelines that are common to most application types.

Table 3.2. Design Guidelines for Your Application



Input / Data Validation

Do not trust input; consider centralized input validation. Do not rely on client-side validation. Be careful with canonicalization issues. Constrain, reject, and sanitize input. Validate for type, length, format, and range.


Use strong passwords. Support password expiration periods and account disablement. Do not store credentials (use one-way hashes with salt). Encrypt communication channels to protect authentication tokens.


Use least privileged accounts. Consider authorization granularity. Enforce separation of privileges. Restrict user access to systemlevel resources.

Configuration Management

Use least privileged process and service accounts. Do not store credentials in clear text. Use strong authentication and authorization on administration interfaces. Do not use the Local Security Authority (LSA). Secure the communication channel for remote administration.

Sensitive Data

Avoid storing secrets. Encrypt sensitive data over the wire. Secure the communication channel. Provide strong access controls for sensitive data stores.


Do not develop your own. Use proven and tested platform features. Keep unencrypted data close to the algorithm. Use the right algorithm and key size. Avoid key management (use DPAPI). Cycle your keys periodically. Store keys in a restricted location.

Exception Management

Use structured exception handling. Do not reveal sensitive application implementation details. Do not log private data such as passwords. Consider a centralized exception management framework.

Auditing and Logging

Identify malicious behavior. Know what good traffic looks like. Audit and log activity through all of the application tiers. Protect access to log files. Back up and regularly analyze log files.


Design guidelines can be used as a tool to help you meet your application security objectives. The security frame provides a structure within which you can modify or add design guidelines as you learn about your application’s architecture and deployment environment. Patterns & practices security guidance includes a core set of guidelines, organized by application type that you can use as a starting point for your application’s guidelines. Each guideline should be actionable, impactful, and relevant; and guidelines should be organized into the categories contained in the security frame.

Personal tools