Industry:DPC BS 8878:2009 - Revision history

Clerkendweller: Status updated

2009-01-31T13:03:44Z

Status updated

Clerkendweller: /* Final version */

2009-01-31T12:51:19Z

‎Final version

Clerkendweller: /* Final version */

2009-01-31T12:46:52Z

‎Final version

Clerkendweller: /* Final version */ typo

2009-01-31T12:19:44Z

‎Final version: typo

Clerkendweller: Collated edits to produce Final version

2009-01-31T10:30:42Z

Collated edits to produce Final version

Dc: /* Draft Text version 3 */

2009-01-30T17:21:11Z

‎Draft Text version 3

Clerkendweller: Mailing list link

2009-01-29T18:15:44Z

Mailing list link

Clerkendweller: G.2 comment

2009-01-29T17:43:45Z

G.2 comment

Clerkendweller: Added H.1.1 text

2009-01-29T17:14:18Z

Added H.1.1 text

Clerkendweller: Draft 2 added

2009-01-29T16:55:41Z

Draft 2 added

@@ Line 38: / Line 38: @@
   | style="width:25%; background:#7B8ABD" align="center"| '''Status'''
   | colspan="3" style="width:75%; background:#cccccc" align="left"|
-* Started
+* Closed
-* 2nd draft in discussion
+* Response submitted to BSI Standards on 31 Jan 2009
   |-
   | style="width:25%; background:#7B8ABD" align="center"| '''Resources'''

← Older revision		Revision as of 12:51, 31 January 2009
Line 56:		Line 56:

	[''This response is submitted on behalf of the Open Web Application Security Project (OWASP) http://www.owasp.org/. OWASP is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. Everyone is free to participate in OWASP and all of our materials are available under a free and open software license. The OWASP Foundation is a not-for-profit charitable organization, registered in the United States, that ensures the ongoing availability and support for our work.'']		[''This response is submitted on behalf of the Open Web Application Security Project (OWASP) http://www.owasp.org/. OWASP is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security "visible," so that people and organizations can make informed decisions about application security risks. Everyone is free to participate in OWASP and all of our materials are available under a free and open software license. The OWASP Foundation is a not-for-profit charitable organization, registered in the United States, that ensures the ongoing availability and support for our work.'']
		+

	0.2 Understanding accessible experiences		0.2 Understanding accessible experiences

@@ Line 54: / Line 54: @@
 === Final version ===
 .2 Understanding accessible experiences
@@ Line 86: / Line 88: @@
-.3 User Agent Accessibility Guidelines (UAAG)
+.3.2 User Agent Accessibility Guidelines (UAAG)
 ----------------------------------------------
 Comment:  While the website should be usable in popular browsers, this is not sufficient for testing purposes. Developers/programmers needs to realise that people will try and access the content using "non-browser" tools to look for vulnerabilities and the website should be secure enough to protect users and itself from such threats. This requires testing beyond "popular browsers".
-Proposed change: Add "Note 6 - The website must secure enough to protect itself and its users from security vulnerabilities which may not be apparent by limiting testing to 'a reasonable range of web browsers'.  OWASP has produced a detailed testing guide http://www.owasp.org/index.php/Category:OWASP_Testing_Project"
+Proposed change: Add "Note 6 - The website must secure enough to protect itself and its users from security vulnerabilities which may not be apparent by limiting testing to 'a reasonable range of web browsers'.
@@ Line 123: / Line 125: @@
 -----------------------------
-Comment:  Security is an aspect of quality (see ISO 9126).  Content may not be accessible if there are security vulnerabilities.
+Comment:  Security is an aspect of quality (see ISO 9126).  Content may not be fully accessible, or fully comply with a particular conformance level (e.g. WCAG 2.0)  if there are security vulnerabilities.
 Proposed change: Add "It is also important for a web developer to learn secure coding. This will help reduce the risk of security vulnerabilities in the website and provide users with a better usability and accessibility of the content. OWASP has defined best practices for secure coding aided with code snippets and examples that can help developers to learn the art of secure coding."
@@ Line 150: / Line 152: @@
 http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
-Proposed change: Add "Open Web Application Security Project (OWASP) http://www.owasp.org"
+Proposed change: Add to "Useful web contents", "Open Web Application Security Project (OWASP) http://www.owasp.org"
 === Draft Text version 2 ===

@@ Line 108: / Line 108: @@
 Comment:  Undocumented or unwanted functionality can often lead to security vulnerabilities.  For a webpage to conform, every aspect must be validated; this requires a full understanding of the webpage and how it interacts with the user, data, servers, etc.
-Proposed change: Add to the end of the first paragraphs "All elements within the webpage must be inspected.  Thus any undocumented features, functions or security vulnerabilities must also undergo validation testing.  The web site code should be reviewed to ensure no security vulnerabilities exist that may hamper the usage and accessibility. OWASP provides a very methodical approach to security code review that is available under 'OWASP Code Review Guide'
+Proposed change: Add to the end of the first paragraph "All elements within the webpage must be inspected.  Thus any undocumented features, functions or security vulnerabilities must also undergo validation testing.  The web site code should be reviewed to ensure no security vulnerabilities exist that may hamper the usage and accessibility. OWASP provides a very methodical approach to security code review that is available under 'OWASP Code Review Guide'
 http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project"

@@ Line 55: / Line 55: @@
 === Final version ===
-TBC
+.2 Understanding accessible experiences
 === Draft Text version 2 ===

@@ Line 120: / Line 120: @@
 Comment: Security testing should also be undertaken at the same time.
-Proposed change: Add "The Security of the website should be validated by ensuring compliance to OWASP Top10. A comprehensive testing methodology is published by OWASP as 'OWASP Testing Guide'
+Proposed change: Add "The Security of the website should be validated by ensuring that vulnerabilities identified in the <strike>compliance to </strike>OWASP Top 10 are mitigated. A comprehensive testing methodology is published by OWASP as 'OWASP Testing Guide'
 http://www.owasp.org/index.php/Category:OWASP_Testing_Project"
@@ Line 129: / Line 129: @@
 Comment:  Undocumented or unwanted functionality can often lead to security vulnerabilities.  For a webpage to conform, every aspect must be validated; this requires a full understanding of the webpage and how it interacts with the user, data, servers, etc.
-Proposed change: Add to the end of the first paragraphs "All aspects within the webpage must be inspected.  Thus any undocumented features, functions or security vulnerabilities must also undertake a validation test.  The webpage code should be reviewed to ensure no security vulnerabilities exist that may hamper the usage and accessibility. OWASP provides as very methodical approach to security code review that is available under 'OWASP Code Review Guide'
+Proposed change: Add to the end of the first paragraphs "All <strike>aspects</strike> elements within the webpage must be inspected.  Thus any undocumented features, functions or security vulnerabilities must also undergo validation testing.<strike>undertake a validation test</strike>.  The web <strike>page</strike> site code should be reviewed to ensure no security vulnerabilities exist that may hamper the usage and accessibility. OWASP provides a<strike>s</strike> very methodical approach to security code review that is available under 'OWASP Code Review Guide'
 http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project"
@@ Line 139: / Line 139: @@
 Proposed change: Add "Quality can not be achieved without ensuring proper security. Security is a quality vector and should be taken into consideration while conducting expert reviews. OWASP experts familiar with methodologies can help review the application from security standpoint and help ensure high quality."
@@ Line 144: / Line 146: @@
 -----------------------------
-Comment:  Security is an aspect of quality (see ISO 9126).  Content cannot be accessible if there are security vulnerabilities.
+Comment:  Security is an aspect of quality (see ISO 9126).  Content <strike>cannot</strike> may not be accessible if there are security vulnerabilities.
 Proposed change: Add "It is also important for a web developer to learn secure coding. This will help reduce the risk of security vulnerabilities in the website and provide users with a better usability and accessibility of the content. OWASP has defined best practices for secure coding aided with code snippets and examples that can help developers to learn the art of secure coding."
@@ Line 164: / Line 166: @@
 Comment: User confidence is vital, and it does not matter what the skill, knowledge, experience or ability level a user has, we must develop web sites that are safe to use and do not create additional risks to the user.  Webpages and websites with security vulnerabilities are not accessible unless the vulnerabilities are also validated for conformance.
-Proposed changes:  <span style="color:red;">In H.1.1 add " In regards to web security, OWASP a globally recognized community has produced tools, specifications and guidelines focusing on best coding practices, security code review, Testing Guide, Code Review and Top 10 vulnerabilities (considered as a de-facto list for most of the compliances such as PCI-DSS, VISA etc). All of OWASP resources are free to use.",</span> In H.1.3 add another item "awareness of website security issues", in H.3.1 add another item "Will security implications be included in the testing?" and in H.3.2 add another item "Does the supplier use the OWASP Application Security Verification Standard (ASVS) to provide a level of confidence in the security of the project"
+Proposed changes:  <span style="color:red;">In H.1.1 add " In regards to web security, OWASP a globally recognized community has produced tools, specifications and guidelines focusing on best coding practices, security code review, Testing Guide, Code Review and Top 10 vulnerabilities (considered as a de-facto list for most of the compliances such as PCI-DSS, VISA etc). All <strike>of</strike> OWASP resources are free to use.",</span> In H.1.3 add another item "awareness of website security issues", in H.3.1 add another item "Will security implications be included in the testing?" and in H.3.2 add another item "Does the supplier use the OWASP Application Security Verification Standard (ASVS) to provide a level of confidence in the security of the project"
 Bibliography - Useful web contents
@@ Line 174: / Line 177: @@
 Proposed change: Add "Open Web Application Security Project (OWASP) http://www.owasp.org"
 === Draft Text version 1 ===

@@ Line 18: / Line 18: @@
   | style="width:25%; background:#cccccc" align="center"|'''Primary'''<br>[mailto:colin.watson(at)owasp.org '''Colin Watson''']
   | style="width:25%; background:#cccccc" align="center"|'''Secondary'''<br>[mailto:puneet.mehta(at)owasp.org '''Puneet Mehta''']
-  | style="width:25%; background:#cccccc" align="center"|'''Mailing list'''<br>None
+  | style="width:25%; background:#cccccc" align="center"|'''Mailing list'''<br>Please use the [http://lists.owasp.org/mailman/listinfo/global_industry_committee Industry Committee list]
   |}

@@ Line 152: / Line 152: @@
 --------------------------------------------
-Comment:
+Comment: Without validated security, there is no way to ensure that webpages conform to accessibility requirements.
 Proposed change: Add as a new bullet point under a) "How well the risk of getting compromised through a security vulnerability is mitigated? (degree of risk vs. usability)" and as a new bullet point under b) "How low is the threat of user’s computer becoming infected through malicious code from the website? (Degree of confidence in the website for efficient utilization)" and as a new bullet point under c) "Perceived security (Peace of mind / trust / reliable and secure user experience)"

← Older revision		Revision as of 17:14, 29 January 2009
Line 164:		Line 164:
	Comment: User confidence is vital, and it does not matter what the skill, knowledge, experience or ability level a user has, we must develop web sites that are safe to use and do not create additional risks to the user. Webpages and websites with security vulnerabilities are not accessible unless the vulnerabilities are also validated for conformance.		Comment: User confidence is vital, and it does not matter what the skill, knowledge, experience or ability level a user has, we must develop web sites that are safe to use and do not create additional risks to the user. Webpages and websites with security vulnerabilities are not accessible unless the vulnerabilities are also validated for conformance.

−	Proposed changes: In H.1.3 add another item "awareness of website security issues", in H.3.1 add another item "Will security implications be included in the testing?" and in H.3.2 add another item "Does the supplier use the OWASP Application Security Verification Standard (ASVS) to provide a level of confidence in the security of the project"	+	Proposed changes: <span style="color:red;">In H.1.1 add " In regards to web security, OWASP a globally recognized community has produced tools, specifications and guidelines focusing on best coding practices, security code review, Testing Guide, Code Review and Top 10 vulnerabilities (considered as a de-facto list for most of the compliances such as PCI-DSS, VISA etc). All of OWASP resources are free to use.",</span> In H.1.3 add another item "awareness of website security issues", in H.3.1 add another item "Will security implications be included in the testing?" and in H.3.2 add another item "Does the supplier use the OWASP Application Security Verification Standard (ASVS) to provide a level of confidence in the security of the project"

@@ Line 32: / Line 32: @@
   | style="width:25%; background:#7B8ABD" align="center"| '''Deadlines'''
   | colspan="3" style="width:75%; background:#cccccc" align="left"|
-* ''TBC'' - Complete final draft response
+* 29 Jan 2009 - Complete final draft response
-* ''TBC'' - Submit to OWASP Board for approval
+* 29 Jan 2009 - Submit for approval by [[Global Industry Committee]]
 * 31 Jan 2009 - Submit to BSI British Standards
   |-
@@ Line 59: / Line 59: @@
 === Draft Text version 2 ===
-TBC
+.2 Understanding accessible experiences
 === Draft Text version 1 ===