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 "Category:OWASP CSA Project"

From OWASP
Jump to: navigation, search
 
(18 intermediate revisions by 6 users not shown)
Line 1: Line 1:
Last Updated: 6/25/2009
+
Last Updated: 6/25/2009  
  
<hr>
+
----
<b>Mission of CSA_Project Collective</b>
 
To promote the use of best practices for providing security assurance within Cloud Computing, and provide education on the uses of Cloud Computing to help secure all other forms of computing
 
  
Primary Project Website: [http://www.cloudsecurityalliance.org http://www.cloudsecurityalliance.org]
+
'''Mission of CSA_Project Collective''' To promote the use of best practices for providing security assurance within Cloud Computing, and provide education on the uses of Cloud Computing to help secure all other forms of computing
<br>
 
Project leaders: Warren Axelrod & Michael Sutton
 
  
Version 1.0 Document: [http://www.cloudsecurityalliance.org/guidance/csaguide.pdf Get it Now] and [http://cloudsecurityalliance.org/guidance Additional CSA resources]
+
Primary Project Website: [http://www.cloudsecurityalliance.org http://www.cloudsecurityalliance.org] <br> Project leaders: Warren Axelrod &amp; Michael Sutton
  
<h1><center><b> Deadline for RFC July 8th 2009 </b></center></h1>
+
Version 1.0 Document: [http://www.cloudsecurityalliance.org/guidance/csaguide.pdf Get it Now] and [http://cloudsecurityalliance.org/guidance Additional CSA resources]
  
<hr>
+
= <center>'''Deadline for RFC July 8th 2009'''</center>  =
  
If you would like to contribute to this effort as a OWASP voice of Industry/Projects you can and its VERY simple to get started.
+
----
  
Step #1 - Review V1.0 http://www.cloudsecurityalliance.org/guidance/csaguide.pdf
+
If you would like to contribute to this effort as a OWASP voice of Industry/Projects you can and its VERY simple to get started.  
  
Step #2 - Condense your written comments, references for improvement and suggestions and review/post them to the WIKI - http://www.owasp.org/index.php/Category:OWASP_CSA_Project.  This location will be monitored by CSA for inclusion into Version 2.0
+
Step #1 - Review V1.0 http://www.cloudsecurityalliance.org/guidance/csaguide.pdf
  
Step #3 - Add your name to the wiki page if you would like to work on this effort. The goal is to utilize the experts at OWASP to review and comment as a collective group and reference OWASP existing materials to help the CSA effort and to raise awareness to others about OWASP.
+
Step #2 - Condense your written comments, references for improvement and suggestions and review/post them to the WIKI - http://www.owasp.org/index.php/Category:OWASP_CSA_Project. This location will be monitored by CSA for inclusion into Version 2.0
  
<b><u>Name/eMail/Phone</u></b>
+
Step #3 - Add your name to the wiki page if you would like to work on this effort. The goal is to utilize the experts at OWASP to review and comment as a collective group and reference OWASP existing materials to help the CSA effort and to raise awareness to others about OWASP.
  
Tom Brennan/tomb(at)owasp.org/9732020122
+
'''<u>Name/eMail/Phone</u>'''
  
Michael Coates/michael.coates(at)owasp.org/6302072567
+
Tom Brennan/tomb(at)owasp.org/9732020122
  
Thomas Ryan/thomas.ryan(at)owasp.org/7322077916
+
Michael Coates/michael.coates(at)owasp.org/6302072567
  
Adam Muntner/Adam.Muntner(at)quietmove.com/6024459801
+
Adam Muntner/Adam.Muntner(at)quietmove.com/6024459801  
<hr>
 
  
Comments on the Domain 11: Application Security  Page 65-71  (not limited to that domain BTW)
+
Arthur Hedge/ahedge(at)castleventures.com/9735388004
<table border=1>
 
<tr>
 
<td>
 
Page #</td>                <td>  Comment  </td>                <td>  Your Name </td></tr>
 
  
<tr><td>72</td>  <td>The second sentence of the Issuance and Guidance on page 72 is misleading and factually incorrect. "Encrypted data is intrinsically protected; if someone has the data without its corresponding keys, they cannot use the data at all." Encrypting data will guarantee that the data is not viewed or modified by a party that does not possess the corresponding keys. However, encrypted data can be used in reply attacks. As such, it is imperative that the transfer of encrypted data utzilize secure tokens and timestamps to ensure the transmission is not subject to replay attacks.  The use of SSL/TLS for data transmission will provide both encryption of data and protection against replay attacks.</td><td>Michael Coates</td></tr>
+
Georg Hess/georg.hess(at)artofdefence.com/+4994160488958
  
<tr><td>65</td><td>The entire Domain 11, Application Security, seems to focus more on some minor architecture differences, but doesn't focus on acutal application level threats - XSS, CSRF, SQL etc injection attacks, and business logic holes such as authentication/authorization issues.</td><td> Adam Muntner  </td></tr>
+
Neil Fryer/xyberpix(at)xyberpix.com/+447917260746<br>  
<tr><td>65</td><td> "For application security, the answer to each of these questions has two: what
 
security controls must the application provide over and above the controls inherent in the cloud
 
platform and how must an enterprise’s secure development lifecycle change to accommodate
 
cloud computing?"
 
This is the only quote in the Problem Statement which is relevant. The rest can safely be scrubbed. </td><td>Adam Muntner  </td></tr>
 
<tr><td>70</td><td> "Final Thoughts" section: Attack methods are well known. OWASP Testing Guide is one point of reference, and OSSTM is another. How will malicious actors react? By being malicious actors. A list of web links for further research would be more useful.</td><td> Adam Muntner  </td></tr>
 
<tr><td>page#</td><td> Comment Here </td><td> Name Here  </td></tr>
 
<tr><td>page#</td><td> Comment Here </td><td> Name here </td></tr>
 
<tr><td>page#</td><td> Comment Here </td><td> Name here </td></tr>
 
<tr><td>page#</td><td> Comment Here </td><td> Name here </td></tr>
 
<tr><td>page#</td><td> Comment Here </td><td> Name here </td></tr>
 
<tr><td>page#</td><td> Comment Here </td><td> Name here </td></tr>
 
<tr><td>page#</td><td> Comment Here </td><td> Name here </td></tr>
 
  
</table>
+
----
Comments on the Domain 11: Application Security  Page 65-71 
 
  
Page #                          Comment                                  Your Name
+
Comments on the Domain 11: Application Security Page 65-71 (not limited to that domain BTW)
===================================================================================
 
  
 +
{| border="1"
 +
|-
 +
| Page #
 +
| Comment
 +
| Your Name
 +
|-
 +
| 4
 +
| Include OWASP member attribution and affiliation. The more names, the better
 +
| James McGovern
 +
|-
 +
| 27
 +
| PCI defines requirements above and beyond just payment processing. Challenges such as file integrity monitoring and patch management become more nebulous in a cloud
 +
| James McGovern
 +
|-
 +
| 34
 +
| Additional considerations may include constructs such as receiving a document preservation notice where a court may order you to restore a system to a known point in time. The fluidity of a cloud makes this challenging
 +
| James McGovern
 +
|-
 +
| 72
 +
| The second sentence of the Issuance and Guidance on page 72 is misleading and factually incorrect. "Encrypted data is intrinsically protected; if someone has the data without its corresponding keys, they cannot use the data at all." Encrypting data will guarantee that the data is not viewed or modified by a party that does not possess the corresponding keys. However, encrypted data can be used in reply attacks. As such, it is imperative that the transfer of encrypted data utzilize secure tokens and timestamps to ensure the transmission is not subject to replay attacks. The use of SSL/TLS for data transmission will provide both encryption of data and protection against replay attacks.
 +
| Michael Coates
 +
|-
 +
| 65
 +
| The entire Domain 11, Application Security, seems to focus more on some minor architecture differences, but doesn't focus on acutal application level threats - XSS, CSRF, SQL etc injection attacks, and business logic holes such as authentication/authorization issues.
 +
| Adam Muntner
 +
|-
 +
| 65
 +
| "For application security, the answer to each of these questions has two: what
 +
security controls must the application provide over and above the controls inherent in the cloud platform and how must an enterprise’s secure development lifecycle change to accommodate cloud computing?" This is the only quote in the Problem Statement which is relevant. The rest can safely be scrubbed.
  
<hr>
+
| Adam Muntner
 +
|-
 +
| 70
 +
| "Final Thoughts" section: Attack methods are well known. OWASP Testing Guide is one point of reference, and OSSTM is another. How will malicious actors react? By being malicious actors. A list of web links for further research would be more useful.
 +
| Adam Muntner
 +
|-
 +
| 13
 +
| Authentication mentioned - should refer to Authorization as well
 +
| Adam Muntner
 +
|-
 +
| 71
 +
| The [[:Category:OWASP Application Security Verification Standard Project|OWASP Application Security Verification Standard]], [[:Category:OWASP Enterprise Security API|OWASP Enterprise Security API]] and [[:Category:Software Assurance Maturity Model|OWASP Software Assurance Maturity Model]] should be added to the list of references
 +
| Colin Watson
 +
|-
 +
| 48
 +
| Consideration should be given to having cloud providers produce audit reports of privileged user access and activity to the data owner.
 +
| Arthur Hedge
 +
|-
 +
| 7
 +
| Should be rewritten to "Domain 1 principles of cloud computing" or "Domain 1 principal characteristics of cloud computing"
 +
| Arthur Hedge
 +
|-
 +
| 28
 +
| Should be "Procedures for addressing a Legal Hold;" instead of "Procedures for address a Legal Hold;"
 +
| Arthur Hedge
 +
|-
 +
| 11
 +
| Could start with "Cloud Applications are Web Applications in particular. Thus, virtually all of the challenges of Web Application Security apply to cloud applications, too. This document focuses on the new challenges of web applications "living in the cloud" but all knowledge about "classical" Web Application Security such as provided by OWASP should still be considered.
 +
| Georg Hess
 +
|-
 +
| 65
 +
| Could start with "Cloud Applications are Web Applications in particular. Thus, virtually all of the challenges of Web Application Security apply to cloud applications, too. This document focuses on the new challenges of web applications "living in the cloud" but all knowledge about "classical" Web Application Security such as provided by OWASP should still be considered.
 +
| Georg Hess
 +
|-
 +
| 65
 +
| Issues and Guidance, last sentence of first paragraph should be rewritten "... a set of application level controls and through the appropriate choice of cloud services - e.g. Web App Security Scanning, Source Code Analysis or Web App Firewalls - and the through the service agreement with the cloud vendor.
 +
| Georg Hess
 +
|-
 +
| 66
 +
| IaaS Impact on Application Security Architecture, second sentence, should be rewritten "... put in place to secure the application itself, the host and the network...." .
 +
| Georg Hess
 +
|-
 +
| 66
 +
| IaaS Impact on Application Security Architecture, should be added as a last sentence "IaaS providers may offer - third-party or on their own - cloud application security specific services - e.g. Web App Security Scanning, Source Code Analysis or Web App Intrusion Detection/Prevention Systems - to increase security at the application layer and to support customers in fulfilling application specific compliance requirements.
 +
| Georg Hess
 +
|-
 +
| 67
 +
| First sentence below Figure 4: should be rewritten "...and the vendor through application specific security services and controls and the Service Level Agreement (SLA)...." .
 +
| Georg Hess
 +
|-
 +
| 69
 +
| PaaS Impact on Application Security Architecture, should be added as a last sentence of first paragraph "On the other hand, PaaS providers may offer built-in application security controls within their - already restricted - programming environment to help developers avoid known application vulnerabilities.
 +
| Georg Hess
 +
|-
 +
| 70
 +
| "Final thoughts" section: This section is completely lacking of "classical" web app vulnerabilities like OWASP Top 10 that currently are - and in my opinion will still be - most relevant also in the cloud context. I suggest to, at least, mention some of the classical attack vectors like e.g. Cross-Site-Scripting, SQL-Injection, OWASP Top10 etc. in addition to JavaScript etc. - and perhaps re-work this chapter with a bit more time later on....
 +
| Georg Hess
 +
|-
 +
| page#
 +
| Comment Here
 +
| Name here
 +
|-
 +
| page#
 +
| Comment Here
 +
| Name here
 +
|}
 +
 
 +
Comments on the Domain 11: Application Security Page 65-71
 +
 
 +
Page # Comment Your Name
 +
 
 +
====== =======================================================================  ======
 +
 
 +
----

Latest revision as of 14:18, 13 July 2009

Last Updated: 6/25/2009


Mission of CSA_Project Collective To promote the use of best practices for providing security assurance within Cloud Computing, and provide education on the uses of Cloud Computing to help secure all other forms of computing

Primary Project Website: http://www.cloudsecurityalliance.org
Project leaders: Warren Axelrod & Michael Sutton

Version 1.0 Document: Get it Now and Additional CSA resources

Deadline for RFC July 8th 2009


If you would like to contribute to this effort as a OWASP voice of Industry/Projects you can and its VERY simple to get started.

Step #1 - Review V1.0 http://www.cloudsecurityalliance.org/guidance/csaguide.pdf

Step #2 - Condense your written comments, references for improvement and suggestions and review/post them to the WIKI - http://www.owasp.org/index.php/Category:OWASP_CSA_Project. This location will be monitored by CSA for inclusion into Version 2.0

Step #3 - Add your name to the wiki page if you would like to work on this effort. The goal is to utilize the experts at OWASP to review and comment as a collective group and reference OWASP existing materials to help the CSA effort and to raise awareness to others about OWASP.

Name/eMail/Phone

Tom Brennan/tomb(at)owasp.org/9732020122

Michael Coates/michael.coates(at)owasp.org/6302072567

Adam Muntner/Adam.Muntner(at)quietmove.com/6024459801

Arthur Hedge/ahedge(at)castleventures.com/9735388004

Georg Hess/georg.hess(at)artofdefence.com/+4994160488958

Neil Fryer/xyberpix(at)xyberpix.com/+447917260746


Comments on the Domain 11: Application Security Page 65-71 (not limited to that domain BTW)

Page # Comment Your Name
4 Include OWASP member attribution and affiliation. The more names, the better James McGovern
27 PCI defines requirements above and beyond just payment processing. Challenges such as file integrity monitoring and patch management become more nebulous in a cloud James McGovern
34 Additional considerations may include constructs such as receiving a document preservation notice where a court may order you to restore a system to a known point in time. The fluidity of a cloud makes this challenging James McGovern
72 The second sentence of the Issuance and Guidance on page 72 is misleading and factually incorrect. "Encrypted data is intrinsically protected; if someone has the data without its corresponding keys, they cannot use the data at all." Encrypting data will guarantee that the data is not viewed or modified by a party that does not possess the corresponding keys. However, encrypted data can be used in reply attacks. As such, it is imperative that the transfer of encrypted data utzilize secure tokens and timestamps to ensure the transmission is not subject to replay attacks. The use of SSL/TLS for data transmission will provide both encryption of data and protection against replay attacks. Michael Coates
65 The entire Domain 11, Application Security, seems to focus more on some minor architecture differences, but doesn't focus on acutal application level threats - XSS, CSRF, SQL etc injection attacks, and business logic holes such as authentication/authorization issues. Adam Muntner
65 "For application security, the answer to each of these questions has two: what

security controls must the application provide over and above the controls inherent in the cloud platform and how must an enterprise’s secure development lifecycle change to accommodate cloud computing?" This is the only quote in the Problem Statement which is relevant. The rest can safely be scrubbed.

Adam Muntner
70 "Final Thoughts" section: Attack methods are well known. OWASP Testing Guide is one point of reference, and OSSTM is another. How will malicious actors react? By being malicious actors. A list of web links for further research would be more useful. Adam Muntner
13 Authentication mentioned - should refer to Authorization as well Adam Muntner
71 The OWASP Application Security Verification Standard, OWASP Enterprise Security API and OWASP Software Assurance Maturity Model should be added to the list of references Colin Watson
48 Consideration should be given to having cloud providers produce audit reports of privileged user access and activity to the data owner. Arthur Hedge
7 Should be rewritten to "Domain 1 principles of cloud computing" or "Domain 1 principal characteristics of cloud computing" Arthur Hedge
28 Should be "Procedures for addressing a Legal Hold;" instead of "Procedures for address a Legal Hold;" Arthur Hedge
11 Could start with "Cloud Applications are Web Applications in particular. Thus, virtually all of the challenges of Web Application Security apply to cloud applications, too. This document focuses on the new challenges of web applications "living in the cloud" but all knowledge about "classical" Web Application Security such as provided by OWASP should still be considered. Georg Hess
65 Could start with "Cloud Applications are Web Applications in particular. Thus, virtually all of the challenges of Web Application Security apply to cloud applications, too. This document focuses on the new challenges of web applications "living in the cloud" but all knowledge about "classical" Web Application Security such as provided by OWASP should still be considered. Georg Hess
65 Issues and Guidance, last sentence of first paragraph should be rewritten "... a set of application level controls and through the appropriate choice of cloud services - e.g. Web App Security Scanning, Source Code Analysis or Web App Firewalls - and the through the service agreement with the cloud vendor. Georg Hess
66 IaaS Impact on Application Security Architecture, second sentence, should be rewritten "... put in place to secure the application itself, the host and the network...." . Georg Hess
66 IaaS Impact on Application Security Architecture, should be added as a last sentence "IaaS providers may offer - third-party or on their own - cloud application security specific services - e.g. Web App Security Scanning, Source Code Analysis or Web App Intrusion Detection/Prevention Systems - to increase security at the application layer and to support customers in fulfilling application specific compliance requirements. Georg Hess
67 First sentence below Figure 4: should be rewritten "...and the vendor through application specific security services and controls and the Service Level Agreement (SLA)...." . Georg Hess
69 PaaS Impact on Application Security Architecture, should be added as a last sentence of first paragraph "On the other hand, PaaS providers may offer built-in application security controls within their - already restricted - programming environment to help developers avoid known application vulnerabilities. Georg Hess
70 "Final thoughts" section: This section is completely lacking of "classical" web app vulnerabilities like OWASP Top 10 that currently are - and in my opinion will still be - most relevant also in the cloud context. I suggest to, at least, mention some of the classical attack vectors like e.g. Cross-Site-Scripting, SQL-Injection, OWASP Top10 etc. in addition to JavaScript etc. - and perhaps re-work this chapter with a bit more time later on.... Georg Hess
page# Comment Here Name here
page# Comment Here Name here

Comments on the Domain 11: Application Security Page 65-71

Page # Comment Your Name

=======================================================================

This category currently contains no pages or media.