securityengineeringoverview

Return to HomePage

patterns and practices Security Engineering Overview

Summary

This page summarizes the patterns and practices approach to security engineering. To design, build and deploy secure applications, you must integrate security into your application development lifecycle and adapt your current software engineering practices and methodologies to include specific security related activities. These include identifying security objectives, creating threat models, applying secure design guidelines, patterns and principles, conducting architecture and design reviews for security, performing regular code reviews for security, testing for security, and conducting deployment reviews to ensure secure configuration.

* Overview
* Key Activities in the Lifecycle
* Bake Security into Your Application Lifecycle
* Key Activities in the Life Cycle
* Proactive vs. Reactive Security
* How The Security Activities Work Together
* Incremental Adoption
* Know Your Threats
* Threat Modeling
* Summary

Overview

The patterns and practices approach to security engineering can be summarized as follows:
* Integrate security into your lifecycle. Upfront security design must be an integral part of your application development processes.
* Know your threats. A structured and systematic approach to security is essential. The threat modeling activity enables you to identify and understand threats and the risks they pose and uncover vulnerabilities that you can use to shape subsequent security design.
* Organize by vulnerability category. By focusing on vulnerability categories you can focus on the areas where security mistakes are most frequently made. Vulnerability categories help to make security measures actionable. They help to shape design, and package up principles, practices, patterns and anti-patterns.

Bake Security into Your Application Lifecycle

Security is much more than technology. It is an ongoing process involving people and practices. Upfront security design performed against a defined set of security objectives is required. Security objectives should also be balanced against other quality of service attributes such as performance, availability and flexibility requirements and other business objectives such as time to market.

Key Activities in the Life Cycle

Figure 1.1 shows the key security engineering activities and how they should be integrated into the application lifecycle.
http://msdn.microsoft.com/library/en-us/dnpag2/html/securityinlifcycle.gif

Figure 1 Security engineering activities within the application development lifecycle

There are a number of distinct security related activities that should be an integral part of your application lifecycle. These are:
* Security Objectives. Define security objectives and requirements early in the process. Security objectives are your goals and constraints around the confidentiality, integrity, and availability of your data and application.
* Threat Modeling. Threat modeling helps you to understand and prioritize the threats relevant to your specific application scenario.
* Design Guidelines for Security. To avoid many possible 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 key areas where security mistakes are most often made.
* Architecture and Design Review for Security. The architecture and design review process analyzes the architecture and design from a security perspective. It considers a number of aspects including deployment and infrastructure, application architecture and design and a tier by tier analysis. You need to know the questions to ask when you perform a security review of your application architecture and design.
* Code Review for Security. All code should be subject to code inspections where the emphasis is on spotting security vulnerabilities. This should be a continual activity during the development phase of your lifecycle.
* Security Testing. Use a risk-based approach and use the output from the threat modeling activity to help scope the testing activities and define 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.

By using specific activities for security engineering, you know where to start, how to proceed, and when you are done.

Proactive vs. Reactive Security

If you don't know your application's threats, how do you design for security? If you don't identify your security objectives up front, then what will good (or bad) look like? You need to consider security up front. Essential security activities such as threat modeling, architecture and design reviews, code reviews and deployment reviews should be an integral part of your development processes and fully integrated into your application lifecycle.

Considering security as an afterthought and something that can be bolted onto your application prior to deployment is a mistake. Another common mistake is to place emphasis on application functionality at the expense of security and failing to balance your security objectives with other quality of service attributes and business objectives.

How The Security Activities Work Together

Security related activities start early and should continue throughout the lifecycle, many in parallel with one another. Your security objectives should be considered alongside other critical business objectives. Application specific security objectives should be identified and documented early during requirements and analysis and should be balanced along side other quality of service requirements such as performance, availability and reliability.
Your security objectives help to prioritize and focus your threat modeling activity to identify threats and vulnerabilities. The identified vulnerabilities should be used to shape and influence subsequent design and development decisions. They should also be used by your test teams to scope testing and to define specific test cases to ensure that specific vulnerabilities have either been eliminated or suitably addressed.
Code reviews for security should be an ongoing activity within your development phase. Testing should start early and be driven in part by the vulnerabilities identified during the threat modeling activity.

Incremental Adoption

If your current software engineering processes do not include specific security activities, it is possible to incrementally adopt the key security activities. For example you can start by adding architecture and design reviews to your methodology, or by creating threat models or by performing code reviews for security.
By introducing architecture and design reviews focused on security, you avoid the need for costly rework later in the lifecycle. Similarly, by reviewing your code for security vulnerabilities you potentially save rework or help avoid costly exploits.
By adopting threat modeling, in addition to helping you focus your security development efforts, to improve the overall quality of your software engineering, and to ensure you address the relevant threats, you can also help your test teams create their test plans to test for specific vulnerabilities. Threat models also serve as a focus for communication among the various roles and help to ensure that developers and IT professionals alike really understand your application.

Know Your Threats

Threats can be external, such as attacker on the Internet, or internal, for example, a disgruntled employee or administrator. They can also stem from inadvertent mistakes made by legitimate users. It is important to understand the difference between threats, vulnerabilities, attacks and countermeasures.

Your application's security measures could be useless, or even counter productive, if those measures are applied randomly. You need to know your threats before you can successfully apply security measures. Threat modeling is an activity designed to address this requirement.

Threat Modeling

Threat modeling is a structured activity to help you identify potential security design flaws and vulnerabilities before the problems become significant and before significant investment. A threat model takes a system design and a threat list for that system and identifies relevant threats (the bad effects), by evaluating the design of the system.

Why use threat modeling?

Threat modeling is performed to identify when and where more effort should be applied. There are many possible vulnerabilities, threats and exploits and it is unlikely that your application will encounter all of them. It is also unlikely that your company would need to address all of them. Threat modeling helps you identify where your organization needs to apply effort. Threat modeling helps you to:
* Shape your application design to meet your security objectives.
* Help make trade-offs during key engineering decisions.
* Address quality of engineering through the elimination of common vulnerabilities.
* Attain quality of service by implementing necessary and effective countermeasures.
* Reduce risk of security issues arising during development and operations.

Where does threat modeling fit in?

Threat modeling begins early in the architecture and design phase of the lifecycle. It is performed with knowledge of your security objectives. Your security objectives are a key part of your business objectives and they are used to scope the threat modeling activity and to determine where to spend the most effort.
As the lifecycle progresses and your design and development evolve, you progressively add more detail to your threat model. Threat modeling is iterative and you iterate:
* By increasing the detail of your model whenever new environmental facts become known.
* While you develop, as design and implementation decisions reveal new facts.
* Through the application lifetime (including once it’s in production and being maintained by the operations team), as uses and configurations of the application appear.

Incrementally render the information as it becomes available to you and keep identifying what you now know and what you need to know next.

More Information

See ThreatModeling for more information.

Summary

The patterns and practices approach to security engineering revolves around integrating security into your lifecycle, and identifying and understanding threats and vulnerabilities. It also uses a pattern based information model in the form of a set of vulnerability categories to help you systematically focus your efforts at those areas where mistakes are most often made.
The specific activities that make up the security engineering discipline include defining security objectives, creating threat models, applying design guidelines for security, conducting architecture and design reviews for security, code reviews for security and deployment reviews for security.

Return to HomePage