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 |
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 |
|
Intangible assets to protect |
|
Compliance requirements |
|
Quality of service requirements |
|
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.