Export (0) Print
Expand All

patterns & practices Security Engineering Explained

 
Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

patterns & practices Developer Center

patterns & practices Developer Center

Microsoft Corporation

October 2005

Summary

To meet your application security objectives, you must integrate security into your application development life cycle. You can do so by including specific security-related activities in your current software engineering processes. These activities include identifying security objectives, applying secure design guidelines, patterns, and principles, creating threat models, conducting architecture and design reviews for security, performing regular code reviews for security, testing for security, and conducting deployment reviews to ensure secure configuration.

Contents

Overview
Chapter List
Feedback and Support
Tell Us About Your Success
Authors and Contributors
Related Links

Overview

patterns & practices Security Engineering includes specific security-related activities that help you meet your application security objectives. Figure 1 shows the key security engineering activities and where they should be integrated into the application life-cycle.

Security Overlay

Ff648940.securityinlifcycle(en-us,PandP.10).gif

Figure 1. Security engineering activities in the application development life cycle

The patterns & practices approach to security engineering can be summarized as follows:

  • Integrate security into your life cycle. Security design, secure coding practices, and testing for security must all be an integral part of your application development processes.
  • Identify your objectives. Understand early what the security objectives are for your application. These objectives will play a critical role in shaping threat modeling, code reviews, and testing.
  • Know your threats. Analyze your application in a structured and systematic way to recognize its threats and vulnerabilities. The threat modeling activity enables you to identify and understand threats, understand the risks each threat poses, and uncover vulnerabilities that you can use to shape subsequent security design and implementation decisions.
  • Use an iterative approach. Some activities, such as code review, threat modeling, and security testing should be performed multiple times during the development process in order to maximize application security.

There are a number of distinct security-related activities that should be an integral part of your application life cycle. These are:

  • Security Objectives. Define security objectives and requirements early in the process. Security objectives are goals and constraints that affect the confidentiality, integrity, and availability of your data and application.
  • Design Guidelines for Security. To avoid many of the vulnerabilities introduced by poor design choices, your design activity should use proven design practices, patterns, and principles. By organizing these design patterns and practices into common vulnerability categories, you can focus on those areas where security mistakes are most often made.
  • Threat Modeling. Threat modeling helps you to understand and identify the threats and vulnerabilities relevant to your specific application scenario.
  • Architecture and Design for Security. The architecture and design review process analyzes the architecture and design from a security perspective. It examines a number of aspects including deployment and infrastructure, overall application architecture and design, and each tier in the application.
  • Code Review for Security. All code should be subject to code inspections where the emphasis is on identifying security vulnerabilities. This should be a continuous activity during the development and test phases of the application life cycle.
  • Security Testing. Use a risk-based approach and use the output from the threat modeling activity to help establish the scope of your testing activities and define your test plans.
  • Deployment Review for Security. When your application is deployed, you need to be sure that weak or inappropriate configuration settings do not introduce security vulnerabilities.

Chapter List

Security Engineering Explained is divided into the following chapters that correspond to the key security activities that you should embed into your engineering practices:

  • Introduction
  • Chapter 1, Security Engineering Approach
  • Chapter 2, Security Objectives
  • Chapter 3, Security Design Guidelines
  • Chapter 4, Threat Modeling
  • Chapter 5, Security Architecture and Design Review
  • Chapter 6, Security Code Review
  • Chapter 7, Security Deployment Review

Feedback and Support

We have made every effort to ensure the accuracy of this guidance.

Feedback

Provide feedback by using either a Wiki or e-mail:

We are particularly interested in feedback regarding the following:

  • Technical issues specific to recommendations
  • Usefulness and usability issues

Technical Support

Technical support for the Microsoft products and technologies referenced in this guidance is provided by Microsoft Support Services. For product support information, see the Microsoft Support Web site at http://support.microsoft.com.

Community and Newsgroup Support

Community support is provided in the forums and newsgroups:

To get the most benefit, find the newsgroup that corresponds to your technology or problem. For example, if you have a problem with ASP.NET security features, you would use the ASP.NET Security forum.

Tell Us About Your Success

If this guidance helps you, we would like to know. Tell us by writing a short summary of the problems you faced and how this guide helped you out. Submit your summary to: MyStory@Microsoft.com.

Authors and Contributors

Security Engineering Explained was produced by the following individuals:

  • Authors: J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Jason Taylor, and Rudolph Araujo.
  • Test Team: Larry Brader, Microsoft Corporation; Nadupalli Venkata Surya Sateesh, Sivanthapatham Shanmugasundaram, Infosys Technologies Ltd.
  • Edit Team: Nelly Delgado, Microsoft Corporation
  • Release Management: Sanjeev Garg, Microsoft Corporation

Many thanks to the following contributors and reviewers:

  • External Contributors and Reviewers: Anil John, Johns Hopkins University – Applied Physics Laboratory; Frank Heidt; Keith Brown Pluralsight LLC; Mark Curphey, Foundstone Professional Services
  • Microsoft Services and PSS Contributors and Reviewers: Adam Semel, Denny Dayton, Gregor Noriskin, Kate Baroni, Tom Christian, Wade Mascia
  • Microsoft Product Group: Charlie Kaufman, Don Willits, Mike Downen, Rick Samona
  • Microsoft IT Contributors and Reviewers: Akshay Aggarwal, Irfan Chaudhry, Shawn Veney, Talhah Mir
  • MSDN Contributors and Reviewers: Kent Sharkey
  • Microsoft EEG: Corey Ladas, James Waletzky

Related Links

patterns & practices Developer Center

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Show:
© 2014 Microsoft