Security Engineering Explained - Chapter 5 - Security Architecture and Design Review

From Guidance Share

Jump to: navigation, search

Note - patterns & practices Security Engineering is now live at

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



This module summarizes the patterns & practices approach to security architecture and design review by explaining what it is and why you should use it. It also describes the key concepts behind the approach.

There are three important aspects to conducting an architecture and design review for security:

  • You evaluate your application architecture in relation to its target deployment environment and infrastructure.
  • You review your design choices in each of the key vulnerability categories defined by a security frame.
  • Finally, you conduct a tier-by-tier component analysis and examine the security mechanisms employed by your key components, such as your presentation layer, business layer, and data access layer.


The architecture and design review process analyzes application architecture and design from a security perspective. Use this activity to expose the high-risk design decisions that have been made. Do not rely solely on the use of design documentation as some design decisions will not be explicit but will have to be discovered through dialog and exploration. Use a combination of design documents, architecture experts and discussion to achieve the best results. The goal of the review is to decompose your application and identify key items, including trust boundaries, data flow, entry points, and privileged code. You must also keep in mind the physical deployment configuration of your application.

Pay attention to those areas defined by the security frame for your application as this is where you will most commonly find vulnerabilities. Patterns & practices security guidance includes context-specific security frames for each major application type that you can use to get started.


Use a question driven approach to expose the highest risk design decisions and use the security frame to dive into areas that reveal common mistakes. The following techniques can help to guide your approach when reviewing the architecture and design of your application.

  • Deployment and infrastructure. Review the design of your application in relation to the target deployment environment and the associated security policies. Consider the restrictions imposed by the underlying infrastructure layer security.
  • Security frame. Review the approach to critical areas in your application, including authentication, authorization, input / data validation, exception management, and other areas. Use the application vulnerability categories as a roadmap

and to make sure that you do not miss any key areas during the review.

  • Tier-by-tier analysis. Walk through the logical tiers of your application, and evaluate security choices within your presentation, business, and data access layers.

Figure 5.1 shows this three-pronged approach to the review process.


Figure 5.1 Application review


Use checklists to help you perform architecture and design reviews while evaluating the security of your applications. The checklist should help you explore the highlevel design and architecture decisions that have been made for your application. You should evolve your checklists to include custom checks based on the unique aspects of your application’s architecture.

Patterns & practices security guidance includes checklists for each major application type. Use these checklists as a starting point and add new items as you learn more about architecture and design reviews. A small sample checklist containing items that are applicable to many applications is shown below. To view a complete checklist, refer to patterns & practices guidance on the Web at

Deployment and Infrastructure Considerations



The design identifies, and accommodates the company security policy.

Restrictions imposed by infrastructure security (including available services, protocols, and firewall restrictions) are identified.

The design recognizes and accommodates restrictions imposed by hosting environments (including application isolation requirements).

The target environment code access security trust level is known.

The design identifies the deployment infrastructure requirements and the deployment configuration of the application.

Domain structures, remote application servers, and database servers are identified.

The design identifies clustering requirements.

Secure communication features provided by the platform and the application are known.

The design addresses the required scalability and performance criteria.

Application Architecture and Design Considerations

Input / Data Validation



All entry points and trust boundaries are identified by the design.

Input validation is applied whenever input is received from outside the current trust boundary.

The design assumes that user input is malicious.

Centralized input validation is used where appropriate.

The input validation strategy that the application adopted is modular and consistent.

The validation approach is to constrain, reject, and then sanitize input. (Looking for known, valid, and safe input is much easier than looking for known malicious or dangerous input.)

Data is validated for type, length, format, and range.

The design addresses potential canonicalization issues.

Input file names and file paths are avoided where possible.

The design addresses potential SQL injection issues.

The design addresses potential cross-site scripting issues.

The design does not rely on client-side validation.

The design applies defense in depth to the input validation strategy by providing input validation across tiers.


If you spend time and effort at the beginning of your project to analyze and review your application architecture and design, you can eliminate design-related vulnerabilities and improve your application’s overall security. It is much easier and less expensive to fix vulnerabilities at design time than it is later in the development cycle when substantial re-engineering might be required.

Use the architecture and design review as a checkpoint to ensure compliance with your team’s design guidelines. The review should cover both deployment and design considerations. By considering your design in relation to the target deployment environment and the security policies defined by that environment, you can help to ensure a smoother and more secure application deployment.

Perform architecture and design reviews iteratively as your design evolves or as you learn more about the design and architecture of your applications. If your application has already been created, the architecture and design review is still an important part of the security assessment process that can help you to fix vulnerabilities and improve future designs.

Additional Resources

For more information, see “Security Architecture and Design Review Index” at

Personal tools