Security Engineering Explained - Chapter 2 - Security Objectives

From Guidance Share

Revision as of 21:59, 26 November 2006 (edit) Admin (Talk | contribs) ← Previous diff		Current revision (09:44, 24 January 2010) (edit) JD (Talk | contribs)
Line 1:		Line 1:
		+	<em style="margin:0;background-color:#cedff2;font-family:sans-serif;border:1px solid #a3b0bf;text-align:center;color:#000;padding:0.2em 0.4em;">
		+	Note - patterns & practices Security Engineering is now live at http://msdn.microsoft.com/en-us/library/ms998382.aspx.
		+	</em>
		+
		+
	- J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Jason Taylor, Rudolph Araujo		- J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Jason Taylor, Rudolph Araujo

---

Current revision

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 1 Summary 2 Overview 3 Discovery Process 4 Types of Objectives 5 Techniques 5.1 Roles Matrix 5.2 Derive From Functional Requirements 6 Conclusion

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

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.