Security Engineering Explained - Chapter 1 - Security Engineering Approach

From Guidance Share

Jump to: navigation, search

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


Contents

Summary

This chapter summarizes an approach to security engineering. To design, build, and deploy secure applications, you must integrate security into your application development life cycle by including specific security-related activities in your current software engineering processes. Security-related activities include identifying security objectives; applying secure design guidelines, patterns, and principles; conducting architecture and design reviews for security; creating threat models; performing regular code reviews for security; testing for security; and conducting deployment reviews to ensure secure configuration. You can adopt these activities incrementally as you see fit. These security activities are integrated in MSF Agile, available with Visual Studio Team System. This combination provides tools, guidance, and workflow to help make security a seamless part of your development experience.


Overview

The approach to security engineering can be summarized as follows:

  • Integrate security into your lifecycle. Upfront 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 to maximize application security.


Key Activities in the Life Cycle

Figure 1.1 shows the key security engineering activities and where they should be integrated into the application life cycle.

Security Overlay

Image:SecurityEngineering.gif

Figure 1.1 Security engineering activities in the application development life cycle


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.
  • Security Design Guidelines. 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.
  • Security Design Inspection. The security design inspeciton 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.
  • Security Code Inspection. 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.
  • Security Deployment Inspection. When your application is deployed, you need to be sure that weak or inappropriate configuration settings do not introduce security vulnerabilities.


How the Security Activities Work Together

Security-related activities start early and continue throughout the application life cycle, many in parallel with one another. Figure 1.2 on the next page shows how security activities span the various activities of the application development life cycle.

Image:SecurityActivitiesInTheLifeCycle.gif

Figure 1.2 Security activities in the application development life cycle


Allow the results of each activity to influence the others in order to have a security engineering process that is more effective than the sum of its parts. For example:

  • 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.
  • Using security design guidelines will mitigate many threats found during the threat modeling process.
  • Threat modeling allows you to identify threats and vulnerabilities. The identified vulnerabilities and subsequent mitigations should be used to shape and influence subsequent design, development, and testing decisions.
  • Issues found during code review and testing may result in new threats added to the threat model which in turn will drive new ideas for testing and code review.


Incremental Adoption

If your current software engineering processes do not include specific security activities, it is possible to incrementally adopt the key security activities. The activities you should adopt first will depend on the security objectives you have identified, as well as any outstanding problems your process or application currently has.


For most organizations, the best results will come from adopting the activities in the following order:

  • Security Objectives. If you do not know the security objectives for your application, it will be difficult to be successful with any other activity.
  • Security Design Inspection. Bugs introduced in the design phase are the most expensive to deal with later. By introducing architecture and design reviews focused on security, you avoid the need for costly rework later in the life cycle.
  • Threat Modeling. By adopting threat modeling, in addition to helping you focus your security development efforts, improving the overall quality of your software engineering, and ensuring that you address relevant threats, you can help your test teams create 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 the application.
  • Security Code Inspections. While design bugs are the most expensive, implementation bugs are the most common. Reviewing your code for security vulnerabilities can save you later rework or help avoid costly exploits.
  • Security Deployment Inspections. An application is only as secure as its weakest link. Even a highly effective process can be undone by a configuration error during deployment.
  • Security Design Guidelines. By adopting proven design principles and learning from others mistakes you can ensure your application is secure from the start.
  • Security Testing. Testing should be used to validate designed mitigations and ensure nothing has slipped through the cracks.


Terminology

To get the most out of the content in this document, it is important to understand the difference between threats, vulnerabilities, attacks, and countermeasures.

  • Threat. A threat is an undesired event. A potential occurrence, often best described as an effect that might damage or compromise an asset or objective. It may or may not be malicious in nature.
  • Vulnerability. A vulnerability is a weakness in some aspect or feature of a system that makes an exploit possible. Vulnerabilities can exist at the network, host, or application levels and include operational practices.
  • Attack (or exploit). An attack is an action taken that uses one or more vulnerabilities to realize a threat. This could be someone following through on a threat or exploiting a vulnerability.
  • Countermeasure. Countermeasures address vulnerabilities to reduce the probability of attacks or the impacts of threats. They do not directly address threats; instead, they address the factors that define the threats. Countermeasures range from improving application design, or improving your code, to improving an operational practice.


Conclusion

This approach to security engineering focuses on integrating security into your life cycle through the adoption of a limited set of key security activities. It uses a pattern-based information model in the form of a set of vulnerability categories to help you systematically focus your efforts on areas where mistakes are most often made.

The specific activities that make up the security engineering discipline include defining security objectives, applying design guidelines for security, creating threat models, conducting architecture and design reviews for security, completing code reviews for security, and performing deployment reviews for security.

Personal tools