Security Engineering Explained - Chapter 2 - Security Objectives

From Guidance Share

Jump to: navigation, search

Note - patterns & practices Security Engineering is now live at http://msdn.microsoft.com/en-us/library/ms998382.aspx.


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

Contents

Summary

Security objectives and requirements should be defined early in the application development process. Security objectives are goals and constraints that affect the confidentiality, integrity, and availability of your data and application. This module summarizes the patterns & practices approach to security objectives by explaining what they are and why you should use them. It also describes the key concepts behind the approach.


Overview

Security objectives should be identified as early in the development process as possible, ideally in the requirements and analysis phase. Security objectives are critically important. If you do not know what the objectives are for your application, then it is difficult to be successful with any other security activity.


Security objectives are used to:

  • Filter the set of design guidelines that are applicable.
  • Guide threat modeling activities.
  • Determine the scope and guide the process of architecture and design reviews.
  • Help set code review objectives.
  • Guide security test planning and execution.
  • Guide deployment reviews.


In each activity, you can use the security objectives to help you focus on the highest value areas while avoiding issues that will not affect your application.


Discovery Process

Identifying security objectives is an iterative process that is initially driven by an examination of the application’s requirements and usage scenarios. By the end of the requirements and analysis phase, you should have a first set of objectives that are not yet tied to design or implementation details. During the design phase, additional objectives will surface that are specific to the application architecture and design.


During the implementation phase, you may discover a few additional objectives based upon specific technology or implementation choices that have an impact on overall application security. Each evolution of the security objectives will affect other security activities. You should review the threat model, architecture and design review guidelines, and general code review guidelines when your security objectives change.


Types of Objectives

Security objectives are unique for each application. However, there is a set of common categories of objectives that you can use to jump-start the identification process.


Each of these categories is associated with a set of questions you can use to build your objective list. Table 2.1 lists the security objective categories and associated questions.


Table 2.1. Application Vulnerabilities and Potential Problems


Objective Category

Questions to Ask

Tangible assets to protect

  • Are there user accounts and passwords to protect?
  • Is there confidential user information (such as credit card numbers) that needs to be protected?
  • Is there sensitive intellectual property that needs to be protected?
  • Can this system be used as a conduit to access other corporate assets that need to be protected?

Intangible assets to protect

  • Are there corporate values that could be compromised by an attack on this system?
  • Is there potential for an attack that may be embarrassing, although not otherwise damaging?

Compliance requirements

  • Are there corporate security policies that must be adhered to?
  • Is there security legislation you must comply with?
  • Is there privacy legislation you must comply with?
  • Are there standards you must adhere to?
  • Are there constraints forced upon you by your deployment environment?

Quality of service requirements

  • Are there specific availability requirements you must meet?
  • Are there specific performance requirements you must meet?


Techniques

Use the following techniques to help you discover security objectives:

  • Roles Matrix
  • Derive From Functional Requirements


Roles Matrix

When an application supports multiple roles it is important to understand what each role should be allowed to do. This can be accomplished with a roles matrix that contains privileges in rows and roles in columns such as the one shown in Table 2.2.


Table 2.2: Role Matrix Example

Objects

Subjects

User creation

Permission modification

Object creation

Object removal

Object read

Admin

Content creator

Reader

Anonymous


Once the roles matrix has been created, you can generate security objectives to ensure the integrity of the application’s roles mechanism. For example, the following objectives could be generated from the preceding matrix:

  • Anonymous users should not be allowed to create users, modify permissions, create objects, or remove objects
  • Content creator users should not be allowed to modify permissions or create users


Many systems have multiple roles and privileges can be assigned flexibly to any role. In this case your objectives need to be more general:

  • Roles should only have access to the privileges to which they are assigned.
  • Privilege changes should only be allowed by a role that has the ‘permission modification’ privilege.


Derive From Functional Requirements

You can generate security objectives by examining every functional requirement in your application through the lens of confidentiality, integrity, and availability (CIA). This provides a very effective mechanism for generating security objectives based on known application characteristics.


Consider the following abbreviated set of application requirements:

  • Administrator must be able to add users and change user permissions through

an administrator interface.

  • Each application server must be able to serve 1000 concurrent users.
  • Registered users must be able to purchase books from the Web user interface.


Examine each requirement while thinking about confidentiality, integrity and availability. The first step is to derive potential vulnerabilities from the requirement. For instance, the following vulnerabilities could be derived from the first requirement above:

  • Confidentiality. User names and permissions are exposed to non-administrator.
  • Integrity. Non-administrator is able to add users and change user permissions.
  • Availability. Administrator is not able to add users and change user permissions.


Once you understand the potential vulnerabilities you can derive security objectives. Table 2.3 shows example output from this process.


Table 2.3 Objectives Derived from Functional Requirements

Image:SecurityObjectivesFromFunctionalRequirements.gif


Conclusion

Identification of security objectives is the first, best step you can take to help ensure the security of your application. The objectives, once created, can be used to direct all the subsequent security activities that you perform. Security objectives do not remain static, but are influenced by later design and implementation activities.

Personal tools