CLASP Best Practices - Revision history

Pravir Chandra at 10:37, 29 May 2006

2006-05-29T10:37:28Z

Pravir Chandra at 10:35, 29 May 2006

2006-05-29T10:35:39Z

Pravir Chandra at 01:22, 24 May 2006

2006-05-24T01:22:08Z

Pravir Chandra at 01:20, 24 May 2006

2006-05-24T01:20:32Z

Pravir Chandra at 00:13, 24 May 2006

2006-05-24T00:13:24Z

Pravir Chandra at 00:10, 24 May 2006

2006-05-24T00:10:46Z

New page

{{Template:SecureSoftware}}

==Best Practices==

====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.

← Older revision		Revision as of 10:37, 29 May 2006
Line 1:		Line 1:
−	#redirect [[Category:CLASP Best Practice]]	+	#redirect [[:Category:CLASP Best Practice]]

← Older revision		Revision as of 10:35, 29 May 2006
Line 1:		Line 1:
−	~~{{Template:SecureSoftware}}~~	+	#redirect [[Category:CLASP Best Practice]]
−
−	~~==Best Practices==~~
−
−	~~===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.
−
−	[[Category:~~OWASP~~ CLASP ~~Project~~]]

← Older revision		Revision as of 01:22, 24 May 2006
Line 22:		Line 22:
	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.

−	[[Category:CLASP]]	+	[[Category:OWASP CLASP Project]]

← Older revision		Revision as of 01:20, 24 May 2006
Line 21:		Line 21:
	===Publish operational security guidelines===		===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.		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.
		+
		+	[[Category:CLASP]]

@@ Line 3: / Line 3: @@
 ==Best Practices==
-====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.
-====Perform application assessments====
+===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====
+===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.
@@ Line 13: / Line 13: @@
 * The architecture of the application and probable attack vectors.
 * Potential compensating controls, and their cost and effectiveness.
-====Implement secure development practices====
+===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====
+===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====
+===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====
+===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.