Difference between revisions of "CLASP Concepts"

From OWASP
Jump to: navigation, search
Line 2: Line 2:
  
 
==Concepts View==
 
==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.
+
[[Glossary#CLASP|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 [[Glossary#CLASP|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===
+
===Adaptability of [[Glossary#CLASP|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.  
+
[[Glossary#CLASP|CLASP]] is designed to allow you to easily integrate its security-related activities into your existing application development processes. Each [[Glossary#CLASP|CLASP]] activity is divided into discrete process components and linked to one or more specific project roles. In this way, [[Glossary#CLASP|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===
+
===[[Glossary#CLASP|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.
+
[[Glossary#CLASP|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===
 
===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.
+
Much of the information in the [[Glossary#CLASP|CLASP]] Vulnerability Lexicon can be enforced through use of automated tools using techniques of static analysis of source code.
  
==Overview of CLASP Process==
+
==Overview of [[Glossary#CLASP|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:
+
This section provides an overview of [[Glossary#CLASP|CLASP]]’s structure and of the dependencies between the [[Glossary#CLASP|CLASP]] process components and is organized as follows:
* CLASP Views
+
* [[Glossary#CLASP|CLASP]] Views
* CLASP Resources
+
* [[Glossary#CLASP|CLASP]] Resources
 
* Vulnerability Use Cases
 
* Vulnerability Use Cases
  
===CLASP Views===
+
===[[Glossary#CLASP|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.
+
The [[Glossary#CLASP|CLASP]] process is presented through five high-level perspectives called [[Glossary#CLASP|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 [[Glossary#CLASP|CLASP]] process, how [[Glossary#CLASP|CLASP]] pieces interact, and how to apply them to your specific software development lifecycle.
These are the CLASP Views:  
+
These are the [[Glossary#CLASP|CLASP]] Views:  
 
* Concepts View
 
* Concepts View
 
* Role-Based View
 
* Role-Based View
Line 29: Line 29:
 
See figure 1.
 
See figure 1.
  
[[Image:CLASP_Views.gif|none|thumb|300px|Figure 1: CLASP Views and their interactions]]
+
[[Image:[[Glossary#CLASP|CLASP]]_Views.gif|none|thumb|300px|Figure 1: [[Glossary#CLASP|CLASP]] Views and their interactions]]
  
===CLASP Resources===
+
===[[Glossary#CLASP|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.
+
The [[Glossary#CLASP|CLASP]] process supports planning, implementing and performing security-related software development activities. The [[Glossary#CLASP|CLASP]] Resources provide access to artifacts that are especially useful if your project is using tools to help automate [[Glossary#CLASP|CLASP]] process pieces.
This table lists the name and location of CLASP Resources delivered with CLASP and indicates which CLASP Views they can support:   
+
This table lists the name and location of [[Glossary#CLASP|CLASP]] Resources delivered with [[Glossary#CLASP|CLASP]] and indicates which [[Glossary#CLASP|CLASP]] Views they can support:   
 
{| class="wikitable"
 
{| class="wikitable"
 
|+
 
|+
 
|-----
 
|-----
!CLASP Resources
+
![[Glossary#CLASP|CLASP]] Resources
 
!Location
 
!Location
 
|-----
 
|-----
Line 69: Line 69:
  
 
===Vulnerability Use Cases===
 
===Vulnerability Use Cases===
The CLASP Vulnerability Use Cases depict conditions under which security services can become vulnerable in software applications. The Use Cases provide CLASP users with easy-to-understand, specific examples 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, availability, accountability, and non-repudiation.  
+
The [[Glossary#CLASP|CLASP]] Vulnerability Use Cases depict conditions under which security services can become vulnerable in software applications. The Use Cases provide [[Glossary#CLASP|CLASP]] users with easy-to-understand, specific examples 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, availability, accountability, and non-repudiation.  
The CLASP Vulnerability Use Cases are based on the following common component architectures:
+
The [[Glossary#CLASP|CLASP]] Vulnerability Use Cases are based on the following common component architectures:
 
* Monolithic UNIX
 
* Monolithic UNIX
 
* Monolithic mainframe
 
* Monolithic mainframe
 
* Distributed architecture (HTTP[S] & TCP/IP)
 
* 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 services becoming vulnerable in software applications
+
It is recommended to understand the [[Glossary#CLASP|CLASP]] Use Cases as a bridge from the Concepts View of [[Glossary#CLASP|CLASP]] to the Vulnerability Lexicon (in the Vulnerability View) since they provide specific examples of security services becoming vulnerable in software applications
 
See figure 2.
 
See figure 2.
[[Image:CLASP_Vulnerability_Use_Cases.gif|none|thumb|300px|Figure 2: Recommended position of the Use Cases within the CLASP process]]
+
[[Image:[[Glossary#CLASP|CLASP]]_Vulnerability_Use_Cases.gif|none|thumb|300px|Figure 2: Recommended position of the Use Cases within the [[Glossary#CLASP|CLASP]] process]]
  
===CLASP Best Practices===
+
===[[Glossary#CLASP|CLASP]] Best Practices===
 
If security vulnerabilities built into your applications’ source code survive into production, they can become corporate liabilities with broad and severe business impact on your organization. In view of the consequences of exploited security vulnerabilities, there is no reasonable alternative to using best practices of application security as early as possible in — and throughout — your software development lifecycle. See figure 3.
 
If security vulnerabilities built into your applications’ source code survive into production, they can become corporate liabilities with broad and severe business impact on your organization. In view of the consequences of exploited security vulnerabilities, there is no reasonable alternative to using best practices of application security as early as possible in — and throughout — your software development lifecycle. See figure 3.
[[Image:CLASP_Best_Practices.gif|none|thumb|300px|Figure 3: Business View of Best Practices of Software Security]]
+
[[Image:[[Glossary#CLASP|CLASP]]_Best_Practices.gif|none|thumb|300px|Figure 3: Business View of Best Practices of Software Security]]
  
 
To be effective, best practices of software application security must have a reliable process to guide a development team in creating and deploying a software application that is as resistant as possible to security vulnerabilities.
 
To be effective, best practices of software application security must have a reliable process to guide a development team in creating and deploying a software application that is as resistant as possible to security vulnerabilities.
Within a software development project, the CLASP Best Practices are the basis of all security-related software development activities — whether planning, designing or implementing — including the use of all tools and techniques that support CLASP.  
+
Within a software development project, the [[Glossary#CLASP|CLASP]] Best Practices are the basis of all security-related software development activities — whether planning, designing or implementing — including the use of all tools and techniques that support [[Glossary#CLASP|CLASP]].  
These are the CLASP Best Practices:
+
These are the [[Glossary#CLASP|CLASP]] Best Practices:
* [[CLASP#Institute awareness programs|Institute awareness programs]]
+
* [[[[Glossary#CLASP|CLASP]]#Institute awareness programs|Institute awareness programs]]
* [[CLASP#Perform application assessments|Perform application assessments]]
+
* [[[[Glossary#CLASP|CLASP]]#Perform application assessments|Perform application assessments]]
* [[CLASP#Capture security requirements|Capture security requirements]]
+
* [[[[Glossary#CLASP|CLASP]]#Capture security requirements|Capture security requirements]]
* [[CLASP#Implement secure development practices|Implement secure development practices]]
+
* [[[[Glossary#CLASP|CLASP]]#Implement secure development practices|Implement secure development practices]]
* [[CLASP#Build vulnerability remediation procedures|Build vulnerability remediation procedures]]
+
* [[[[Glossary#CLASP|CLASP]]#Build vulnerability remediation procedures|Build vulnerability remediation procedures]]
* [[CLASP#Define and monitor metrics|Define and monitor metrics]]
+
* [[[[Glossary#CLASP|CLASP]]#Define and monitor metrics|Define and monitor metrics]]
* [[CLASP#Publish operational security guidelines|Publish operational security guidelines]]
+
* [[[[Glossary#CLASP|CLASP]]#Publish operational security guidelines|Publish operational security guidelines]]
 
====Institute awareness programs====
 
====Institute awareness programs====
 
Essential security concepts and techniques may be foreign to your organization’s software developers and others involved in application development and deployment. So it is imperative at the outset to educate everyone involved. It is critical that project managers — as the driving force behind most application development or upgrade projects — consider security to be an important project goal, both through training and accountability. Awareness programs can be readily implemented, using external expert resources, as appropriate, and deliver a high return by helping to ensure that other activities promoting secure software will be implemented effectively.
 
Essential security concepts and techniques may be foreign to your organization’s software developers and others involved in application development and deployment. So it is imperative at the outset to educate everyone involved. It is critical that project managers — as the driving force behind most application development or upgrade projects — consider security to be an important project goal, both through training and accountability. Awareness programs can be readily implemented, using external expert resources, as appropriate, and deliver a high return by helping to ensure that other activities promoting secure software will be implemented effectively.
Line 111: Line 111:
 
Security does not end when an application is completed and deployed in a production environment. Making the most out of existing network and operational security investments requires that you inform and educate those tasked with monitoring and managing the security of running systems with advice and guidance on the security requirements your application demands, and how best to make use of the capabilities you’ve built into your application.
 
Security does not end when an application is completed and deployed in a production environment. Making the most out of existing network and operational security investments requires that you inform and educate those tasked with monitoring and managing the security of running systems with advice and guidance on the security requirements your application demands, and how best to make use of the capabilities you’ve built into your application.
  
==CLASP and Security Policies==
+
==[[Glossary#CLASP|CLASP]] and Security Policies==
A high-level view of CLASP can help increase awareness of the importance of implementing application security on these organizational levels, from the bottom up: > best practices of application-security > application-security policy > IT security policy > operations security policy > corporate security policy.
+
A high-level view of [[Glossary#CLASP|CLASP]] can help increase awareness of the importance of implementing application security on these organizational levels, from the bottom up: > best practices of application-security > application-security policy > IT security policy > operations security policy > corporate security policy.
[[Image:CLASP_and_Security_Policies.gif|none|thumb|300px|Figure 4: Interaction of CLASP and Security Policies]]
+
[[Image:[[Glossary#CLASP|CLASP]]_and_Security_Policies.gif|none|thumb|300px|Figure 4: Interaction of [[Glossary#CLASP|CLASP]] and Security Policies]]
  
==What is a Security Vulnerability==CLASP defines a security vulnerability as a flaw in a software environment — especially in an application — that allows an attacker to assume privileges within the user's system, utilize and regulate its operation, compromise the data it contains, and/or assume trust not granted to the attacker.
+
==What is a Security Vulnerability==[[Glossary#CLASP|CLASP]] defines a security vulnerability as a flaw in a software environment — especially in an application — that allows an attacker to assume privileges within the user's system, utilize and regulate its operation, compromise the data it contains, and/or assume trust not granted to the attacker.
 
A security vulnerability occurs in a software application when any part of it allows a breach of the security policy governing it.
 
A security vulnerability occurs in a software application when any part of it allows a breach of the security policy governing it.
CLASP identifies 104 underlying problem types that form the basis of security vulnerabilities in application source code. An individual problem type in itself is often not a security vulnerability; frequently it is a combination of problems that create a security condition leading to a vulnerability in the source code. CLASP divides the 104 problem types into 5 high-level categories. Each problem type may have more than one parent category.  
+
[[Glossary#CLASP|CLASP]] identifies 104 underlying problem types that form the basis of security vulnerabilities in application source code. An individual problem type in itself is often not a security vulnerability; frequently it is a combination of problems that create a security condition leading to a vulnerability in the source code. [[Glossary#CLASP|CLASP]] divides the 104 problem types into 5 high-level categories. Each problem type may have more than one parent category.  
CLASP defines a consequence of an exploited or exploitable vulnerability as a failure in one or more of these basic security services:  
+
[[Glossary#CLASP|CLASP]] defines a consequence of an exploited or exploitable vulnerability as a failure in one or more of these basic security services:  
 
* Authorization (resource access control)
 
* Authorization (resource access control)
 
* Confidentiality (of data or other resources)
 
* Confidentiality (of data or other resources)
Line 126: Line 126:
 
* Non-repudiation
 
* Non-repudiation
 
The following figure shows in which phases of the software development lifecycle a security-related vulnerability can occur and also which points in an operational system an attack can target.
 
The following figure shows in which phases of the software development lifecycle a security-related vulnerability can occur and also which points in an operational system an attack can target.
[[Image:CLASP_Vulnerabilities_SDLC_Phases.gif|none|thumb|300px|Figure 5: Vulnerabilities from Perspective of SDLC Phases]]
+
[[Image:[[Glossary#CLASP|CLASP]]_Vulnerabilities_SDLC_Phases.gif|none|thumb|300px|Figure 5: Vulnerabilities from Perspective of SDLC Phases]]
  
==Overview of CLASP Taxonomy==
+
==Overview of [[Glossary#CLASP|CLASP]] Taxonomy==
The CLASP taxonomy is a high-level classification of the CLASP process, divided into the following classes for better evaluation and resolution of security vulnerabilities in source code:  
+
The [[Glossary#CLASP|CLASP]] taxonomy is a high-level classification of the [[Glossary#CLASP|CLASP]] process, divided into the following classes for better evaluation and resolution of security vulnerabilities in source code:  
 
* '''Problem types''' underlying security-related vulnerabilities.
 
* '''Problem types''' underlying security-related vulnerabilities.
 
* '''Categories''' into which the problem types are divided for diagnostic and resolution purposes.
 
* '''Categories''' into which the problem types are divided for diagnostic and resolution purposes.
Line 139: Line 139:
 
* '''Avoidance and mitigation periods''' (i.e., SDLC phases) in which preventative measures and countermeasures can be applied.
 
* '''Avoidance and mitigation periods''' (i.e., SDLC phases) in which preventative measures and countermeasures can be applied.
 
See figure 6.
 
See figure 6.
[[Image:CLASP_Taxonomy.gif|none|thumb|300px|Figure 6: CLASP taxonomy and the relationship between its parts]]
+
[[Image:[[Glossary#CLASP|CLASP]]_Taxonomy.gif|none|thumb|300px|Figure 6: [[Glossary#CLASP|CLASP]] taxonomy and the relationship between its parts]]
  
==Applying CLASP Components==
+
==Applying [[Glossary#CLASP|CLASP]] Components==
This page describes a possible sequence for applying CLASP components, using the Sample Coding Guidelines (CLASP Resource E) as a basis. See figure 7.
+
This page describes a possible sequence for applying [[Glossary#CLASP|CLASP]] components, using the Sample Coding Guidelines ([[Glossary#CLASP|CLASP]] Resource E) as a basis. See figure 7.
[[Image:CLASP_Applying_Components.gif|none|thumb|300px|Figure 7: a possible sequence for applying CLASP components]]
+
[[Image:[[Glossary#CLASP|CLASP]]_Applying_Components.gif|none|thumb|300px|Figure 7: a possible sequence for applying [[Glossary#CLASP|CLASP]] components]]
The steps below describe a possible sequence for applying CLASP components depicted in the figure above:
+
The steps below describe a possible sequence for applying [[Glossary#CLASP|CLASP]] components depicted in the figure above:
* Read the CLASP Concepts View to gain an overview of the CLASP process.
+
* Read the [[Glossary#CLASP|CLASP]] Concepts View to gain an overview of the [[Glossary#CLASP|CLASP]] process.
* In the Concepts View, pay special attention to the page Description of CLASP Process. This page contains a diagram showing, among other things, the location of the 104 CLASP problem types (i.e., basic causes of vulnerabilities), the five high-level, source-code-related categories by which they are organized, and the consequences of exploitable security vulnerabilities for security services.
+
* In the Concepts View, pay special attention to the page Description of [[Glossary#CLASP|CLASP]] Process. This page contains a diagram showing, among other things, the location of the 104 [[Glossary#CLASP|CLASP]] problem types (i.e., basic causes of vulnerabilities), the five high-level, source-code-related categories by which they are organized, and the consequences of exploitable security vulnerabilities for security services.
* Read the CLASP Sample Coding Guidelines thoroughly and select a subset of them relevant to your specific software development project. These guidelines contain a set of security-related coding standards to be applied to your project.
+
* Read the [[Glossary#CLASP|CLASP]] Sample Coding Guidelines thoroughly and select a subset of them relevant to your specific software development project. These guidelines contain a set of security-related coding standards to be applied to your project.
* Apply the remaining CLASP Resources throughout the planning, design, construction, and testing process, as needed.
+
* Apply the remaining [[Glossary#CLASP|CLASP]] Resources throughout the planning, design, construction, and testing process, as needed.
* Use the Sample Coding Guidelines to select a subset of the 104 CLASP problem types (i.e., basic causes of vulnerabilities) — located in the CLASP Vulnerability View — which are most important to your project.
+
* Use the Sample Coding Guidelines to select a subset of the 104 [[Glossary#CLASP|CLASP]] problem types (i.e., basic causes of vulnerabilities) — located in the [[Glossary#CLASP|CLASP]] Vulnerability View — which are most important to your project.
* Familiarize yourself with the CLASP Role-Based View, which provides an overview of the project roles associated with applying the selected subset of Sample Coding Guidelines, and assign these guidelines to your relevant project personnel — e.g., designer, security auditor, implementers.
+
* Familiarize yourself with the [[Glossary#CLASP|CLASP]] Role-Based View, which provides an overview of the project roles associated with applying the selected subset of Sample Coding Guidelines, and assign these guidelines to your relevant project personnel — e.g., designer, security auditor, implementers.
 
* Consider the subset of vulnerabilities selected in part though the Sample Coding Guidelines when using the Activity-Assessment View to assess and select the desired subset of 24 activities contained in the Activity-Implementation View.
 
* Consider the subset of vulnerabilities selected in part though the Sample Coding Guidelines when using the Activity-Assessment View to assess and select the desired subset of 24 activities contained in the Activity-Implementation View.
  
== CLASP and IT Internal Controls ==
+
== [[Glossary#CLASP|CLASP]] and IT Internal Controls ==
 
A significant number of the internal controls required by the Sarbanes-Oxley Act for assurance of accurate and reliable corporate financial reporting are located in the IT area.  
 
A significant number of the internal controls required by the Sarbanes-Oxley Act for assurance of accurate and reliable corporate financial reporting are located in the IT area.  
The figure below shows how CLASP can help secure the IT internal controls that are necessary to assure the integrity of data in financial applications within the scope of security-related software development projects.
+
The figure below shows how [[Glossary#CLASP|CLASP]] can help secure the IT internal controls that are necessary to assure the integrity of data in financial applications within the scope of security-related software development projects.
[[Image:CLASP_IT_Internal_Controls.gif|none|thumb|300px|Figure 8: How CLASP can help secure the IT internal controls that are necessary to assure the integrity of data in financial applications within the scope of security-related software development projects. Centers on Sarbanes-Oxley sections 302, 404 and 409]]
+
[[Image:[[Glossary#CLASP|CLASP]]_IT_Internal_Controls.gif|none|thumb|300px|Figure 8: How [[Glossary#CLASP|CLASP]] can help secure the IT internal controls that are necessary to assure the integrity of data in financial applications within the scope of security-related software development projects. Centers on Sarbanes-Oxley sections 302, 404 and 409]]

Revision as of 16:53, 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.

[[Image:CLASP_Views.gif|none|thumb|300px|Figure 1: CLASP Views and their interactions]]

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 vulnerable in software applications. The Use Cases provide CLASP users with easy-to-understand, specific examples 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, availability, 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 services becoming vulnerable in software applications See figure 2. [[Image:CLASP_Vulnerability_Use_Cases.gif|none|thumb|300px|Figure 2: Recommended position of the Use Cases within the CLASP process]]

CLASP Best Practices

If security vulnerabilities built into your applications’ source code survive into production, they can become corporate liabilities with broad and severe business impact on your organization. In view of the consequences of exploited security vulnerabilities, there is no reasonable alternative to using best practices of application security as early as possible in — and throughout — your software development lifecycle. See figure 3. [[Image:CLASP_Best_Practices.gif|none|thumb|300px|Figure 3: Business View of Best Practices of Software Security]]

To be effective, best practices of software application security must have a reliable process to guide a development team in creating and deploying a software application that is as resistant as possible to security vulnerabilities. Within a software development project, the CLASP Best Practices are the basis of all security-related software development activities — whether planning, designing or implementing — including the use of all tools and techniques that support CLASP. These are the CLASP Best Practices:

  • [[CLASP#Institute awareness programs|Institute awareness programs]]
  • [[CLASP#Perform application assessments|Perform application assessments]]
  • [[CLASP#Capture security requirements|Capture security requirements]]
  • [[CLASP#Implement secure development practices|Implement secure development practices]]
  • [[CLASP#Build vulnerability remediation procedures|Build vulnerability remediation procedures]]
  • [[CLASP#Define and monitor metrics|Define and monitor metrics]]
  • [[CLASP#Publish operational security guidelines|Publish operational security guidelines]]

Institute awareness programs

Essential security concepts and techniques may be foreign to your organization’s software developers and others involved in application development and deployment. So it is imperative at the outset to educate everyone involved. It is critical that project managers — as the driving force behind most application development or upgrade projects — consider security to be an important project goal, both through training and accountability. Awareness programs can be readily implemented, using external expert resources, as appropriate, and deliver a high return by helping to ensure that other activities promoting secure software will be implemented effectively.

Perform application assessments

While it’s true that you cannot test security into an application, application testing and assessments should still be a central component of your overall security strategy. Assessments — particularly automated tests — can find security problems not detected during code or implementation reviews, find security risks introduced by the operational environment, and act as a defense-in-depth mechanism by catching failures in design, specification or implementation. Test and assessment functions are typically owned by a test analyst or by the QA organization but can span the entire life cycle.

Capture security requirements

Ensure that security requirements have the same level of “citizenship” as all other “must haves.” It’s easy for application architects and project managers to focus on functionality when defining requirements, since they support the greater purpose of the application to deliver value to the organization. Security considerations can easily go by the wayside. So it is crucial that security requirements be an explicit part of any application development effort. Among the factors to be considered:

  • An understanding of how applications will be used, and how they might be misused or attacked.
  • The assets (data and services) that the application will access or provide, and what level of protection is appropriate given your organization’s appetite for risk, regulations you are subject to, and the potential impact on your reputation should an application be exploited.
  • The architecture of the application and probable attack vectors.
  • Potential compensating controls, and their cost and effectiveness.

Implement secure development practices

Defined security activities, artifacts, guidelines and continuous reinforcement should become part of your organization’s overall culture.

Build vulnerability remediation procedures

It is especially important in the context of application updates and enhancements to define which steps will be taken to identify, assess, prioritize and remediate vulnerabilities.

Define and monitor metrics

You cannot manage what you cannot measure. Unfortunately, implementing an effective metrics monitoring effort can be a difficult undertaking. Despite this, metrics are an essential element of your overall application security effort. They are crucial in assessing the current security posture of your organization, help focus attention on the most critical vulnerabilities, and reveal how well — or poorly — your investments in improved security are performing.

Publish operational security guidelines

Security does not end when an application is completed and deployed in a production environment. Making the most out of existing network and operational security investments requires that you inform and educate those tasked with monitoring and managing the security of running systems with advice and guidance on the security requirements your application demands, and how best to make use of the capabilities you’ve built into your application.

CLASP and Security Policies

A high-level view of CLASP can help increase awareness of the importance of implementing application security on these organizational levels, from the bottom up: > best practices of application-security > application-security policy > IT security policy > operations security policy > corporate security policy. [[Image:CLASP_and_Security_Policies.gif|none|thumb|300px|Figure 4: Interaction of CLASP and Security Policies]]

==What is a Security Vulnerability==CLASP defines a security vulnerability as a flaw in a software environment — especially in an application — that allows an attacker to assume privileges within the user's system, utilize and regulate its operation, compromise the data it contains, and/or assume trust not granted to the attacker. A security vulnerability occurs in a software application when any part of it allows a breach of the security policy governing it. CLASP identifies 104 underlying problem types that form the basis of security vulnerabilities in application source code. An individual problem type in itself is often not a security vulnerability; frequently it is a combination of problems that create a security condition leading to a vulnerability in the source code. CLASP divides the 104 problem types into 5 high-level categories. Each problem type may have more than one parent category. CLASP defines a consequence of an exploited or exploitable vulnerability as a failure in one or more of these basic security services:

  • Authorization (resource access control)
  • Confidentiality (of data or other resources)
  • Authentication (identity establishment and integrity)
  • Availability (denial of service)
  • Accountability
  • Non-repudiation

The following figure shows in which phases of the software development lifecycle a security-related vulnerability can occur and also which points in an operational system an attack can target. [[Image:CLASP_Vulnerabilities_SDLC_Phases.gif|none|thumb|300px|Figure 5: Vulnerabilities from Perspective of SDLC Phases]]

Overview of CLASP Taxonomy

The CLASP taxonomy is a high-level classification of the CLASP process, divided into the following classes for better evaluation and resolution of security vulnerabilities in source code:

  • Problem types underlying security-related vulnerabilities.
  • Categories into which the problem types are divided for diagnostic and resolution purposes.
  • Exposure periods (i.e., SDLC phases) in which vulnerabilities can be inadvertently introduced into application source code.
  • Consequences of exploited vulnerabilities for basic security services.
  • Platforms and programming languages which may be affected by a vulnerability.
  • Resources required for attack against vulnerabilities.
  • Risk assessment of exploitable/exploited vulnerabilities.
  • Avoidance and mitigation periods (i.e., SDLC phases) in which preventative measures and countermeasures can be applied.

See figure 6. [[Image:CLASP_Taxonomy.gif|none|thumb|300px|Figure 6: CLASP taxonomy and the relationship between its parts]]

Applying CLASP Components

This page describes a possible sequence for applying CLASP components, using the Sample Coding Guidelines (CLASP Resource E) as a basis. See figure 7. [[Image:CLASP_Applying_Components.gif|none|thumb|300px|Figure 7: a possible sequence for applying CLASP components]] The steps below describe a possible sequence for applying CLASP components depicted in the figure above:

  • Read the CLASP Concepts View to gain an overview of the CLASP process.
  • In the Concepts View, pay special attention to the page Description of CLASP Process. This page contains a diagram showing, among other things, the location of the 104 CLASP problem types (i.e., basic causes of vulnerabilities), the five high-level, source-code-related categories by which they are organized, and the consequences of exploitable security vulnerabilities for security services.
  • Read the CLASP Sample Coding Guidelines thoroughly and select a subset of them relevant to your specific software development project. These guidelines contain a set of security-related coding standards to be applied to your project.
  • Apply the remaining CLASP Resources throughout the planning, design, construction, and testing process, as needed.
  • Use the Sample Coding Guidelines to select a subset of the 104 CLASP problem types (i.e., basic causes of vulnerabilities) — located in the CLASP Vulnerability View — which are most important to your project.
  • Familiarize yourself with the CLASP Role-Based View, which provides an overview of the project roles associated with applying the selected subset of Sample Coding Guidelines, and assign these guidelines to your relevant project personnel — e.g., designer, security auditor, implementers.
  • Consider the subset of vulnerabilities selected in part though the Sample Coding Guidelines when using the Activity-Assessment View to assess and select the desired subset of 24 activities contained in the Activity-Implementation View.

CLASP and IT Internal Controls

A significant number of the internal controls required by the Sarbanes-Oxley Act for assurance of accurate and reliable corporate financial reporting are located in the IT area. The figure below shows how CLASP can help secure the IT internal controls that are necessary to assure the integrity of data in financial applications within the scope of security-related software development projects. [[Image:CLASP_IT_Internal_Controls.gif|none|thumb|300px|Figure 8: How CLASP can help secure the IT internal controls that are necessary to assure the integrity of data in financial applications within the scope of security-related software development projects. Centers on Sarbanes-Oxley sections 302, 404 and 409]]