This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "CLASP Concepts"
| Line 27: | Line 27: | ||
* Activity-Implementation View | * Activity-Implementation View | ||
* Vulnerability View | * Vulnerability View | ||
| − | + | See figure 1. | |
| − | [[Image:CLASP_Views.gif|thumb|300px|CLASP Views]] | + | [[Image:CLASP_Views.gif|thumb|300px|Figure 1: CLASP Views and their interactions]] |
===CLASP Resources=== | ===CLASP Resources=== | ||
| Line 40: | Line 40: | ||
!Location | !Location | ||
|----- | |----- | ||
| − | | Basic Principles in Application Security (all Views) | + | | Basic Principles in Application Security (all Views) || Resource A |
| − | | Resource | + | |----- |
| + | | Example of Basic Principle: Input Validation (all Views)|| Resource B | ||
| + | |----- | ||
| + | | Example of Basic-Principle Violation: Penetrate-and-Patch Model (all Views) Resource C | ||
| + | |----- | ||
| + | | Core Security Services (all Views; especially III)|| Resource D | ||
| + | |----- | ||
| + | | Sample Coding Guideline Worksheets (Views II, III & IV) | ||
| + | Note: Each worksheet can be pasted into a MS Word document. Resource E | ||
| + | |----- | ||
| + | | System Assessment Worksheets (Views III & IV) | ||
| + | Note: Each worksheet can be pasted into a MS Word document. Resource F | ||
| + | |----- | ||
| + | | Sample Road Map: Legacy Projects (View III) Resource G1 | ||
| + | |----- | ||
| + | | Sample Road Map: New-Start Projects (View III)|| Resource G2 | ||
| + | |----- | ||
| + | | Creating the Process Engineering Plan (View III)|| Resource H | ||
| + | |----- | ||
| + | | Forming the Process Engineering Team (View III) Resource I | ||
| + | |----- | ||
| + | | Glossary of Security Terms (all Views)|| Resource J | ||
|----- | |----- | ||
|} | |} | ||
| + | |||
| + | ===Vulnerability Use Cases=== | ||
| + | The CLASP Vulnerability Use Cases depict conditions under which security services can become vulnera¬ble in software applications. The Use Cases provide CLASP users with easy-to-understand, specific exam¬ples of the cause-and-effect relationship between security-unaware design/source coding and possible resulting vulnerabilities in basic security services — e.g., authentication authorization, confidentiality, avail¬ability, accountability, and non-repudiation. | ||
| + | The CLASP Vulnerability Use Cases are based on the following common component architectures: | ||
| + | • Monolithic UNIX | ||
| + | • Monolithic mainframe | ||
| + | • Distributed architecture (HTTP[S] & TCP/IP) | ||
| + | It is recommended to understand the CLASP Use Cases as a bridge from the Concepts View of CLASP to the Vulnerability Lexicon (in the Vulnerability View) since they provide specific examples of security ser¬vices becoming vulnerable in software applications | ||
| + | See figure 2. | ||
| + | [[Image:CLASP_Vulnerability_Use_Cases.gif|thumb|300px]|Figure 2: Recommended position of the Use Cases within the CLASP process] | ||
Revision as of 20:14, 15 May 2006
Concepts View
CLASP is the outgrowth of years of extensive field work in which system resources of many development lifecycles were methodically decomposed in order to create a comprehensive set of security requirements. These resulting requirements form the basis of CLASP’s best practices which allow organizations to systematically address vulnerabilities that, if exploited, can result in the failure of basic security services — e.g., confidentiality, authentication, and access control.
Adaptability of CLASP to Existing Development Processes
CLASP is designed to allow you to easily integrate its security-related activities into your existing application development processes. Each CLASP activity is divided into discrete process components and linked to one or more specific project roles. In this way, CLASP provides guidance to project participants — e.g., project managers, security auditors, developers, architects, testers, and others — that is easy to adopt to their way of working; this results in incremental improvements to security that are easily achievable, repeatable, and measurable.
CLASP Vulnerability Lexicon
CLASP also contains a comprehensive Vulnerability Lexicon that helps development teams avoid/remediate specific designing/coding errors that can lead to exploitable security services. The basis of this Lexicon is a highly flexible taxonomy — i.e., classification structure — that enables development teams to quickly locate Lexicon information from many perspectives: e.g., problem types (i.e., basic causes of vulnerabilities); categories of problem types; exposure periods; avoidance and mitigation periods; consequences of exploited vulnerabilities; affected platforms and programming languages; risk assessment.
Automated Analysis Tool
Much of the information in the CLASP Vulnerability Lexicon can be enforced through use of automated tools using techniques of static analysis of source code.
Overview of CLASP Process
This section provides an overview of CLASP’s structure and of the dependencies between the CLASP process components and is organized as follows:
- CLASP Views
- CLASP Resources
- Vulnerability Use Cases
CLASP Views
The CLASP process is presented through five high-level perspectives called CLASP Views. These views are broken down into activities which in turn contain process components. This top-down organization by View > Activity > Process Component allows you to quickly understand the CLASP process, how CLASP pieces interact, and how to apply them to your specific software development lifecycle. These are the CLASP Views:
- Concepts View
- Role-Based View
- Activity-Assessment View
- Activity-Implementation View
- Vulnerability View
See figure 1.
CLASP Resources
The CLASP process supports planning, implementing and performing security-related software development activities. The CLASP Resources provide access to artifacts that are especially useful if your project is using tools to help automate CLASP process pieces. This table lists the name and location of CLASP Resources delivered with CLASP and indicates which CLASP Views they can support:
| CLASP Resources | Location |
|---|---|
| Basic Principles in Application Security (all Views) | Resource A |
| Example of Basic Principle: Input Validation (all Views) | Resource B |
| Example of Basic-Principle Violation: Penetrate-and-Patch Model (all Views) Resource C | |
| Core Security Services (all Views; especially III) | Resource D |
| Sample Coding Guideline Worksheets (Views II, III & IV)
Note: Each worksheet can be pasted into a MS Word document. Resource E | |
| System Assessment Worksheets (Views III & IV)
Note: Each worksheet can be pasted into a MS Word document. Resource F | |
| Sample Road Map: Legacy Projects (View III) Resource G1 | |
| Sample Road Map: New-Start Projects (View III) | Resource G2 |
| Creating the Process Engineering Plan (View III) | Resource H |
| Forming the Process Engineering Team (View III) Resource I | |
| Glossary of Security Terms (all Views) | Resource J |
Vulnerability Use Cases
The CLASP Vulnerability Use Cases depict conditions under which security services can become vulnera¬ble in software applications. The Use Cases provide CLASP users with easy-to-understand, specific exam¬ples of the cause-and-effect relationship between security-unaware design/source coding and possible resulting vulnerabilities in basic security services — e.g., authentication authorization, confidentiality, avail¬ability, accountability, and non-repudiation. The CLASP Vulnerability Use Cases are based on the following common component architectures: • Monolithic UNIX • Monolithic mainframe • Distributed architecture (HTTP[S] & TCP/IP) It is recommended to understand the CLASP Use Cases as a bridge from the Concepts View of CLASP to the Vulnerability Lexicon (in the Vulnerability View) since they provide specific examples of security ser¬vices becoming vulnerable in software applications See figure 2. [[Image:CLASP_Vulnerability_Use_Cases.gif|thumb|300px]|Figure 2: Recommended position of the Use Cases within the CLASP process]
