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 "OWASP RFP-Criteria"

From OWASP
Jump to: navigation, search
m
(change)
 
(59 intermediate revisions by 2 users not shown)
Line 1: Line 1:
  
==== Project Details ====
 
{{:Projects/RFP-Criteria | Project About}}
 
[http://www.proactiverisk.com http://www.owasp.org/images/7/71/Proactiverisk.jpg]
 
  
__NOTOC__ <headertabs />
+
=Main=
 +
{{#widget:PayPal Donation
 +
|target=_blank
 +
|budget=RFP_CRITERA
 +
}} 
 +
 
 +
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div>
 +
 
 +
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
 +
| valign="top"  style="border-right: 1px dotted gray;padding-right:25px;" |
 +
 
 +
==OWASP RFP Criteria==
 +
The purpose of this project is to simply provide an objective list of important set of questions  companies should utilize when they issue a Request For Proposal for Web Application Security Projects.
 +
 
 +
A Request For Proposal, (RFP) is a call made by an organization soliciting for bids by service providers or vendors to meet a need and it is often done by documents.
 +
 
 +
The information provided in RFPs are important and when you create an RFP for an Application Security Verification project , emphasis should be  on providing clear information about the scope of verification activities and evaluation criteria so prospective service providers and vendors can submit proposals that are comparable.
 +
 
 +
You also need to provide adequate background information about the company soliciting for bids and other relevant information that can ensure that the project life cycle is successful. Also it is important that prospective service providers or vendors provide detailed information that helps the client to make an informed decision on who is the best fit for the project.
 +
 
 +
Usually this information may include standard questions such as proposed Application Security Verification Methodologies for defined tasks, relevant project experience etc. Others may include Security Coverage, Risk Evaluation Process , Reporting Techniques etc.
 +
 
 +
We outline in subsequent sections detailed information that should be provided for each application that is subject to verification in an Application Security Verification project.
  
[[Category:OWASP RFP-Criteria|RFP-Criteria]]
+
==Audience==
  
==== Main ====
+
The project is written to raise visibility for software security related questions that buyers of services should consider when issuing a request for quote as example or in procurement process.  Supply chain management as noted by DHS referring this project [https://buildsecurityin.us-cert.gov/swa/forums-and-working-groups/acquisition-and-outsourcing DHS SWA]
  
 +
==Licensing==
  
'''Project Leader:''' <b>Tom Brennan</b> tomb(at)proactiverisk.com for more information
+
The OWASP RFP Criteria Project and project components is licensed under '''https://creativecommons.org/licenses/by-nc-sa/3.0/''' , the Creative Commons Attribution-NonCommercial-ShareAlike license. This implies that you must give appropriate credit , provide a link to the license and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. Also note that the material cannot be used for commercial purpose and if you transform or build on the material , you are required to distribute your contributions under the same license as the original.
  
 +
==Project Sponsor==
 +
OWASP RFP Criteria project is sponsored by [http://www.proactiverisk.com ProactiveRISK Inc.].
  
 +
[[File:Proactiverisk_logo_v2.jpg | link=http://www.proactiverisk.com]]
  
__TOC__
 
  
=APPLICATION SECURITY VERIFICATION=
+
| valign="top"  style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |
  
==SUGGESTED INFORMATION TO PROVIDE==
+
== In Print ==
  
To receive proposals that are comparable it is important to provide clear information to proposing parties about the scope of verification activities.
+
See below
  
Information to provide for each application to be subject to verification:
+
[https://www.owasp.org/images/a/a3/OWASP_RFP_Best_Pract.pdf OWASP RFP CRITERIA]
  
1. Lines of code (Required for verification efforts where source code review will be involved; recommended in all cases in order provide background information about the scale of the application being assessed.  Freely-available software such as CLOC http://cloc.sourceforge.net/ can be used to calculate the number of lines of code.  It is also helpful to provide further information about how the lines of code count was determined – for example a raw count of the lines of code or a count of non-comment source statements)
+
== Presentation ==
  
2. Number of dynamic pages (Some form of this is required for verification efforts where manual penetration testing will be involved.  It is recommended in all cases in order to provide background information about the scale of the application being assessed.  In calculating the number of dynamic pages, it is important to focus on the number of pages with unique functionality.  For example, the URLs /show_product.jsp?id=1 and /show_product.jsp?id=2 likely refer to only one unique dynamic page)
+
See Below.
  
3. List of user roles with role descriptions (Recommended for all verification efforts in order to provide business context for any vulnerabilities identified)
+
[https://www.owasp.org/images/1/10/OWASP_RFP.pptx OWASP RFP CRITERIA Presentation]
  
4. Brief description of the application and its architecture.  This is less important for applications with a basic web application architecture (web server, application server, database server...) but more important for applications with non-standard architectures such as those using thick clients, web services or integration with legacy systems.
+
== Project Leader ==
  
5. Level of verification desired (Failing to provide guidance on the level of verification desired can result in suppliers providing inconsistent proposals that vary wildly in price):
+
[https://www.owasp.org/index.php/User:Brennan Tom Brennan] [http://www.twitter.com/brennantom @brennantom]
  
a) dynamic vulnerability scanning<BR>
+
== Version 2.0 ==
b) static analysis<BR>
+
Want to help out and make this project BETTER?  Add your comments here
c) manual penetration testing<BR>
+
[https://docs.google.com/document/d/17_CrTAmhaump4C-I2-zH-lllmFWkP3GscHkKo86z_wM/edit?usp=sharing Version 2.0 GoogleDocs - Add Comments]
d) manual code review<BR>
 
e) threat modeling<BR>
 
f) security architecture review<BR>
 
g) malicious code analysis<BR>
 
  
6. Frequency or duration during which verifications should be performed.  Do you want a single verification or would you like multiple verifications to be performed over a period of time?
+
== Related Projects ==
  
==SUGGESTED RFP QUESTIONS==
+
[https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project OWASP Top 10]
  
===Company Background===
+
[https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series OWASP Cheat Sheets]
  
1. Provide a brief overview of products and/or services offered.
+
[https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project OWASP Mod_Security CRS]
  
2. How many years has your company been in business?  Please list any major milestones such as significant acquisitions or the introduction or elimination of relevant lines of business.
+
[https://www.owasp.org/index.php/OWASP_WASC_Web_Hacking_Incidents_Database_Project Web Hacking Incident Database]
  
3. Describe your experience with applications of a similar size, scope, complexity, and vertical as the applications to be verified.
 
  
4. Describe your experience with the languages, frameworks, libraries, and other technologies that comprise the applications to be verified.
 
  
5. Describe your level of involvement in the application security community, in organizations such as the Open Web Application Security Project (OWASP) and the Web Application Security Consortium (WASC).
+
| valign="top"  style="padding-left:25px;width:200px;" |
  
6. Describe any other relevant background information about your organization and your qualification to provide the request product/service.
 
  
 +
== News and Events ==
 +
* Release date 1/27/2015 NJ Chapter Meeting
  
 +
==Classifications==
  
===Application Security Verification Methodology===
+
  {| width="200" cellpadding="2"
 +
  |-
 +
  | align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-incubator-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]
 +
  |-
 +
  | align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]
 +
  |-
 +
  | colspan="2" align="center"  | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]
 +
  |-
 +
  | colspan="2" align="center"  | [[File:Project_Type_Files_DOC.jpg|link=]]
 +
  |}
  
1. Describe your methodology for all the verification techniques to be used:
+
|}
  
a) dynamic vulnerability scanning<BR>
+
= Acknowledgements =
b) static analysis<BR>
+
==Volunteers==
c) manual penetration testing<BR>
+
Incident Response Project is developed by a worldwide team of volunteers. The primary contributors to date have been:
d) manual code review<BR>
 
e) threat modeling<BR>
 
f) security architecture review<BR>
 
g) malicious code analysis<BR>
 
  
2. Describe the steps required from our organization in order to prepare for and execute an application verification.
+
* [https://www.owasp.org/index.php/User:Brennan Tom Brennan], [http://www.proactiverisk.com ProactiveRISK]
 +
* Jason Jolaoso, [http://www.proactiverisk.com ProactiveRISK]
 +
* Jeff Williams
 +
* Mike Esposito
 +
* <insert your name>
  
3. If multiple techniques are used, how will they be used together in the verification effort?
+
Want to help? Get in touch with us
  
4. Provide your thoughts on why performing this security verification is important to our organization.
+
==Others==
 +
* OWASP NYC Metro Chapter
  
5. Describe your desired interaction with software developers, security staff, and business owners during the verification process.
+
= Road Map and Getting Involved =
 +
Involvement in the development and promotion of OWASP RFP Criteria Project is actively encouraged!
 +
You do not have to be a security expert in order to contribute.
 +
Some of the ways you can help:
  
 +
* Proof Reading
 +
* Graphic Design
 +
* Conduct Industry Survey
 +
* Educate local communities
 +
*  list of open-source IR tools
 +
* <insert your idea>
  
  
===Security Coverage===
 
  
1. Describe the vulnerability and security control coverage provided by your verification efforts. Where possible include references to the OWASP ASVS,[http://projects.webappsec.org/Threat-Classification WASC 24] Broad Classes of Attacks, and the [http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project OWASP Top 10]
 
  
2. Describe the different levels of rigor that you offer for the verification effort. What are the differences in security coverage between these levels?
 
  
3. Are you currently able to test for Cross-Site Request Forgery (CSRF) and HTTP Response Splitting?
 
  
4. Provide guidance on the level of coverage included in your proposal.  What are potential gaps in coverage for the current proposal and what steps could be taken to address them?
 
  
5. Does your solution meet PCI 6.6 standards?
 
  
  
  
  
===Application Coverage===
 
  
1. How does your product/service baseline an application?
 
  
2. How do you tune your product/service to verify an application most effectively?
 
  
3. What methods do you use to ensure coverage of the entire application?
 
  
4. How do you verify with a customer that you are providing thorough coverage of the targeted application?
 
  
5. What potential gaps are there between your proposed solution and the platform and architecture of the application being verified?  (For example if the target application contains both web pages and web services and your testing does not cover web services this would indicate a gap)
 
  
  
===Risk Evaluation===
 
  
1. Describe your process for determining the specific likelihood and business impact of vulnerabilities you discover.
+
====== OLD TEMPLATE BELOW THIS (WE ARE UPGRADING IT COME BACK LATER ;) ======
  
2. How do you limit the reporting of false positives?
+
==== Project Details ====
 +
{{:Projects/RFP-Criteria | Project About}}
  
3. Describe your approach for combining similar risks so that they can be easily understood and remediated.  
+
[http://www.proactiverisk.com http://www.owasp.org/images/7/71/Proactiverisk.jpg]
  
 +
__NOTOC__ <headertabs />
  
 +
[[Category:OWASP RFP-Criteria|RFP-Criteria]]
  
===Differentiators===
+
==== Main ====
 +
The information in this document will help you to create a standard , detailed RFP for Application Security Verification projects that service providers or vendors can work with  to submit relevant comparable proposals for an organization.
  
1. What is the most challenging aspect of your verification efforts?
 
  
2. What about your approach is unique and why is that important to us?
+
__TOC__
  
 +
=Application Security Verification.=
 +
==Recommended Information the Client (your Organization) should provide to Service Providers/Vendors.==
  
 +
1. '''Lines of code.''' Lines of Code (LOC) or sometimes referred to as Source Lines of Code (SLOC) is a prerequisite for any verification task that involves the review of source code.  This software metric (LOC) provides information about the scale of the program under review. There are software packages on the public domain such as LocMetrics on http://locmetrics.com or CLOC on http://cloc.sourceforge.net/ which can be used to count the number of lines of code. Additional information about LOC such as if the count included commented source code or not is also beneficial
  
 +
2.'''Number of dynamic pages.''' Information about the number of dynamic pages is advisable as it provides insights about the scale of the application under assessment. It is important for verification efforts that involved manual penetration testing. When estimating the amount of dynamic pages , pay attention to pages with unique functionality or purpose. If you have urls like:<br/>
 +
i.  /display_results.php?rs=1 , <br/>
 +
ii. /display_results.php?rs=2 ,<br/>
 +
iii./display_results.php?rs=3 , <br/>
  
===Scope===
+
you need to ensure that you confirm if they refer to a single unique dynamic page or not
  
1. Approximately how long does it take to implement your product/service?
+
3. '''An Inventory of user roles and role descriptions.'''  The catalog of user roles is endorsed for all verification efforts  as it furnishes  business context for  vulnerabilities  (if any) established.
  
2. Specifically, how does your solution scale for multiple websites?
+
4. '''Brief Application Summary and Application architecture.''' This is mission critical for  applications with non-standard architectures such as those using thick clients, web services or integration with legacy systems but not so paramount for applications with a standard web application architecture (web server, application server, database server setup).
  
3. What performance impact should testing have on applications being tested? What steps are taken to minimize the impact of testing on the performance of applications during the testing process?
+
5.'''Degree  of verification expected .'''  To manage or prevent suppliers providing erratic bids  that vary in figures or timelines ,There is a need to provide definitive guidance on the level of verification desired. This should include requirements for or on: <br/>
 +
a. Dynamic vulnerability scanning. <br/>
 +
b. Manual code review. <br/>
 +
c. Manual penetration testing. <br/>
 +
d. Static analysis. <br/>
 +
e. Security architecture review. <br/>
 +
f. Malicious code analysis. <br/>
 +
g. Threat modeling.
  
4. Does your product or service allow for on-demand / ad hoc testing? What is the lead time required to initiate testing?
+
6. '''The frequency or duration for performing verification.''' It is important to indicate if you want a  single verification exercise or if you want several  many verification exercises executed within a specified time-frame.
  
 +
==Recommended RFP Questions (Responses are made by Service Providers/Vendors to Client).==
  
 +
=== Company Background.===
 +
a. Summarize the product(s) or service(s) provided by your company.
  
===Security===
+
b. How  long has your company been providing products or services relevant to this project? Please provide any relevant  information about major milestones such as significant acquisitions , mergers or the introduction or elimination of relevant lines of business.
  
1. Describe exactly how you will protect our information, including all information about our application and any risks discovered, while it is in your custody. Please describe your network security, information storage security, and need-to-know processes.
+
c. Please provide succinct information your past experience with applications of a similar scope, complexity, and vertical as the applications to be verified in this project.
  
2. Please provide information on the trustworthiness of individuals who will have access to our information as part of the verification.
+
d. Outline your familiarity and experience with the frameworks, libraries,languages and other relevant technologies that comprise the applications to be verified.
  
3. Please describe how information necessary for the verification will be exchanged securely.
+
e. Are you involved with organizations or stakeholders  in the application security community, such as the '''Open Web Application Security Project (OWASP)''' and the '''Web Application Security Consortium (WASC)'''? if yes , what roles do you play ?
  
4. Please describe how our information will be purged from your systems when the verification is complete.
+
f. Provide other helpful background information about your organization and your qualification to supply  the required product/service.
  
5. Please describe how our information is kept separate from the risk information of other customers.
+
=== Application Security Verification Methodology.===
 +
a. Outline , in clear details your proposed methodology for all the verification techniques to be utilized:
 +
  i. Dynamic vulnerability scanning.<br/>
 +
  ii. Malicious code analysis.<br/>
 +
iii. Manual code review.<br/>
 +
  iv. Manual penetration testing.<br/>
 +
  v. Security architecture review.<br/>
 +
  vi. Static analysis.<br/>
 +
vii. Threat modeling.<br/>
 +
 +
b. What would you require from the client to prepare for and successfully execute an application verification exercise ?
  
6. Please provide evidence that your systems are protected against attack.
+
c. Would you be using  multiple techniques for this project ? If yes  how will you combine these in the verification exercise?
  
 +
d. Describe your proposed level of communication/ interaction with software development teams , security experts, and business process owners during the verification process.
  
 +
===Security Coverage.===
 +
a. Explain  the vulnerability and security control coverage that is  provided by your verification efforts. Where relevant , supply references to the OWASP ASVS,[http://projects.webappsec.org/Threat-Classification WASC 24] Broad Classes of Attacks, and the [http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project OWASP Top 10]
  
===Burden===
+
b. Provide the different levels of efforts  that you will provider for the verification effort. What are the differences in security coverage between these levels?
  
1. Describe any personnel requirements from our organization. How many personnel are needed? What are their skill sets and experience levels?
+
c. Presently , are you able to test (precisely) for Cross-Site Request Forgery (CSRF) and HTTP Response Splitting?
  
2. Describe exactly what materials we will be expected to provide to support the verification efforts.
+
d. What are potential gaps in coverage for the current proposal and what steps would you  take to mitigate the gaps?
  
 +
e. Does your solution meet current PCI 6.6 standards?
  
  
===Reporting Interface===
+
===Application Coverage.===
 +
a. How effectively does your product/service baseline an application?
  
1. Describe exactly how risks will be written up, including:
+
b. How do you adjust your product/service to verify an application most effectively?
  
a) title<BR>
+
c. What methods or techniques do you use to ensure coverage of the entire application?
b) location (URL and/or line of code)<BR>
 
c) specific vulnerability description<BR>
 
d) risk likelihood, business impact, and severity<BR>
 
e) code snippets<BR>
 
f) specific remediation recommendations<BR>
 
  
2. Describe the risk model you use as well as how it can be customized for our corporate standard.
+
d. How do you corroborate with a customer that you are providing accurate coverage of the targeted application?
  
3. Describe your reporting interface using criteria such as ease of use, clarity, comprehensiveness, how reporting components are organized, etc.  
+
e. What potential gaps (if any)  exists between your proposed solution and the platform and architecture of the application under verification?  A case in point - if the target application contains both web pages and web services and your testing does not cover web services this would indicate a gap.
  
4. How does your product or service provide timely updates on any new web application risks identified?  Are alerts delivered to authorized personnel?  If so, how are they delivered and under what conditions?
 
  
5. Do you provide historical trending reports that track open/closed risks and the ongoing remediation process?
+
===Risk Evaluation.===
 +
a.  Outline your risk evaluation process for establishing the probable vulnerabilities you might discover and it’s business impact.
  
6. Can assessment reports be generated to reflect the risk status of individual web applications, as well as the security health of all web applications?  
+
b. What is your procedure for managing the reporting of false positives?
  
7. Can your reports be tailored and adapted for viewing by various levels of management, internal/external auditors, security specialists, etc.?
+
c. Outline your procedures for categorizing similar risks for easy absorption and rectification.
  
8. Does your solution provide an API so that risks can be exported into other applications, such as CRM apps, bug tracking systems, SIEMs?  Are there any canned scripts or standard integrations that exist?  With which applications?
+
===Differentiators.===
 +
a. What aspect of the verification process do you find most challenging ( if any )?
  
9. Do your reports contain specific recommendations for application developers, tailored for the exact problem in the code?
+
b. Tell us why your approach towards this project is exceptional or singular. How and why is this important to the client?
  
10. How do you provide timely and reliable reporting of risks for ongoing visibility, measurement, and management?
+
===Scope.===
 +
a. What are the time estimates for implement your product/service in a similar verification exercise?
  
11. How frequently do you provide enhancements to your reporting interface?  What is the process?
+
b. How does the proposed solution scale for multiple websites?
  
12. How do developers know if they have successfully remediated a risk?
+
c. What are the advised steps for curtailing the impact of testing on the performance of applications during the testing process?
  
 +
d. Indicate if your  product or service provisions for on-demand / ad hoc testing.
  
 +
e. What is the lead time required to initiate testing?
  
 +
===Security.===
  
===Innovation===
+
a. What are your procedures for protecting client’s information made available to you? Outline in detail  your network security, information storage security, and need-to-know policy.
  
1. Describe any recent innovations your company has introduced to lower costs or improve service for your customers.
+
b. Describe the level of confidence you have in staff that would have access to our information in this project.
  
2. How do you identify new classes of vulnerabilities and test for them?
+
c. Outline the techniques and policies for information exchange between you (the vendor)and us(the client)during this exercise.
  
3. How are you able to uncover and test for new attack techniques that can be used to exploit known classes of risks?
+
d. Describe your procedure for deleting and purging  information from your systems at the completion of this project.
  
4. How do you test new technologies (e.g. new versions of Flash) for risks?  
+
e. How would  you compartmentalize  our information from the risk information belonging to your other clients?
  
 +
f. Outline (with tangible evidence) that your systems and network is protected from attacks.
  
 +
===Burden.===
 +
a. Outline any resource (human) requirements from our organization. This should include technical/operational skill sets and experience.
  
===Integration===
+
b. Specify in details the requirements you require from us to execute the verification exercise.
  
1. What standard data formats will your product/service export or provide?
+
===Reporting Interface.===
  
2. What other technologies (for example, Web Application Firewalls) does your product/service integrate with? What benefits do these integrations provide? How do the integrations work?
+
a. Outline your risk documentation structure. This should include:
 +
  i. The Title. <br/>
 +
  ii. The Location (URL and/or line of code).<br/>
 +
  iii. Specific vulnerability description.<br/>
 +
  iv. Risk likelihood, business impact, and severity.<br/>
 +
  v. Code snippets.<br/>
 +
  vi. Specific remediation recommendations.<br/>
  
 +
b. Explain the risk model you utilize . How can it be customized to meet your client’s standards and expectations ?
  
 +
c. Explain your reporting interface employing criteria such as the learning curve, how reporting components are structured, etc.
  
 +
d. How do you or  your product or services deliver (important) updates on new identified  web application risks?
  
===Benefits===
+
e.  What trend and historical reports do you provide that monitor identified/open/closed risks and the ongoing remediation exercise?
  
1. How do you make the remediation process more efficient?
+
f. Is it possible to generate status reports to show the risk status of separate  web applications, and the overall  security health of all web applications?
  
2. Describe the balance of internal and external resources in an ideal application security program.
+
g. Are these reports customizable for different stakeholders i.e management.
  
3. Can you deliver accurate results and diminish/eliminate false positives, thus making the verification process more efficient?
+
h. Do you have any standard scripts or standard integration that are bundled with your solution? If yes indicate the applications.
  
4. Are you able to demonstrate a positive ROI and increased benefits to management?  How?
+
i. Do your reports provide specific directions for application developers, attuned to the exact problem in the code?
  
5. Are you able to influence secure coding techniques / reduce time spent debugging? How?
+
j. What is your process for timely and reliable reporting of risks for stakeholders?
  
6. Explain why we would realize a competitive advantage by doing business with your company?
+
k. How often is your reporting interface updated? What process do you follow for this updates?
  
 +
l. What benchmark  exists for developers to know if they have successfully re-mediated a risk?
  
 +
===Innovation.===
 +
a. Are there any recent innovations or products your firm has delivered that has resulted in improved service delivery for clients?
  
===Supporting Services===
+
b. What is your process for identifying  new categories  of vulnerabilities and test for this?
  
1. Describe any training or eLearning options available associated with the verification effort.
+
c. What is your process of identifying  new attack techniques that can be used to exploit known vulnerabilities ?
  
2. Do you offer remediation support to software development groups?
+
d. What is your process for testing new technologies (e.g. new versions of Flash) for vulnerabilities?
  
3. Is strategic consulting support available to support our application security program.
+
===Integration.===
 +
a. What are the standard data formats your product/service produce or export?
  
 +
b. What other relevant technologies (for example, Firewall Applications) does your product/service integrate with?
  
 +
c. How will the integration work and what benefits will they bring?
  
 +
===Benefits.===
 +
a. How can you increase the efficiency of the remediation process?
  
===Customer Support===
+
b. In your opinion , what is  the balance of internal and external resources in an ideal application security program?
  
1. Can you describe the process in place whereby customers interact with your internal service and support?  What are the escalation procedures?
+
c. Can you provide precise results and diminish/eliminate false positives ?
  
2. Do you provide tracking of all trouble tickets that have been opened and are they tracked through resolution?
+
d. Can provide a proof of concept for a positive Return on Investment (ROI) and an increase in benefits to management?
  
3. Do you offer any kind of Service Level Agreement?
+
e. Do you have the capacity to influence secure coding techniques / reduce time spent debugging? If yes , How?
  
 +
f. Outline the technical and business advantage we would gain from working with you in this project.
  
 +
===Supporting Services.===
 +
a. Explain any knowledge transfer process or procedure i.e training , platforms etc you will provide with the verification effort.
  
===Pricing/Licensing Options===
+
b. What  remediation support do you provide to software development teams?
  
1. Explain your pricing model.
+
===Client Support Details.===
   
+
a. Outline your client or customer support framework . What are the of support levels you provide and what are the escalation procedures?
2. What are the terms associated with your product or service? Please include a sample Software License Agreement or Master Services Agreement template.
 
  
3. Are there other costs we should be made aware of? If consulting or training costs are involved, how do you charge for these services?
+
b. Do provide a ticket raising and tracking system ? How are your open tickets tracked and closed?
  
 +
c. What Service Level Agreement(SLA) do you offer ?
  
 +
===Pricing/Licensing Information.===
 +
a. What terms or conditions are linked to the product or service ?Do you have a sample Software License Agreement we can review ?
  
 +
b. Describe clearly  your proposed pricing model.
  
===Customer References===
+
c. Outline clearly other cost implications  which are attached to this bid and requires our attention.
  
1. Please provide three references for comparable customers - similar size, vertical, technology, and verification effort.
+
d. Do you provide pro-bono training or consulting services or attach costs to them ? If yes what are the charges attached to them?

Latest revision as of 20:29, 3 November 2017


OWASP Project Header.jpg

OWASP RFP Criteria

The purpose of this project is to simply provide an objective list of important set of questions companies should utilize when they issue a Request For Proposal for Web Application Security Projects.

A Request For Proposal, (RFP) is a call made by an organization soliciting for bids by service providers or vendors to meet a need and it is often done by documents.

The information provided in RFPs are important and when you create an RFP for an Application Security Verification project , emphasis should be on providing clear information about the scope of verification activities and evaluation criteria so prospective service providers and vendors can submit proposals that are comparable.

You also need to provide adequate background information about the company soliciting for bids and other relevant information that can ensure that the project life cycle is successful. Also it is important that prospective service providers or vendors provide detailed information that helps the client to make an informed decision on who is the best fit for the project.

Usually this information may include standard questions such as proposed Application Security Verification Methodologies for defined tasks, relevant project experience etc. Others may include Security Coverage, Risk Evaluation Process , Reporting Techniques etc.

We outline in subsequent sections detailed information that should be provided for each application that is subject to verification in an Application Security Verification project.

Audience

The project is written to raise visibility for software security related questions that buyers of services should consider when issuing a request for quote as example or in procurement process. Supply chain management as noted by DHS referring this project DHS SWA

Licensing

The OWASP RFP Criteria Project and project components is licensed under https://creativecommons.org/licenses/by-nc-sa/3.0/ , the Creative Commons Attribution-NonCommercial-ShareAlike license. This implies that you must give appropriate credit , provide a link to the license and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. Also note that the material cannot be used for commercial purpose and if you transform or build on the material , you are required to distribute your contributions under the same license as the original.

Project Sponsor

OWASP RFP Criteria project is sponsored by ProactiveRISK Inc..

Proactiverisk logo v2.jpg


In Print

See below

OWASP RFP CRITERIA

Presentation

See Below.

OWASP RFP CRITERIA Presentation

Project Leader

Tom Brennan @brennantom

Version 2.0

Want to help out and make this project BETTER? Add your comments here Version 2.0 GoogleDocs - Add Comments

Related Projects

OWASP Top 10

OWASP Cheat Sheets

OWASP Mod_Security CRS

Web Hacking Incident Database



News and Events

  • Release date 1/27/2015 NJ Chapter Meeting

Classifications

Owasp-incubator-trans-85.png
Owasp-defenders-small.png
Cc-button-y-sa-small.png
Project Type Files DOC.jpg

Volunteers

Incident Response Project is developed by a worldwide team of volunteers. The primary contributors to date have been:

Want to help? Get in touch with us

Others

  • OWASP NYC Metro Chapter

Involvement in the development and promotion of OWASP RFP Criteria Project is actively encouraged! You do not have to be a security expert in order to contribute. Some of the ways you can help:

  • Proof Reading
  • Graphic Design
  • Conduct Industry Survey
  • Educate local communities
  • list of open-source IR tools
  • <insert your idea>










OLD TEMPLATE BELOW THIS (WE ARE UPGRADING IT COME BACK LATER ;)

Project Details

PROJECT INFO
What does this OWASP project offer you?
RELEASE(S) INFO
What releases are available for this project?
what is this project?
Name: OWASP RFP-Criteria (home page)
Purpose: Purpose of this project is to simply provide an objective list and a aggregate set of questions from companies to utilize when they issue a RFPs for web application security.
License: N/A
who is working on this project?
Project Leader(s):
how can you learn more?
Project Pamphlet: Not Yet Created
Project Presentation:
Mailing list: Mailing List Archives
Project Roadmap: View
Key Contacts
current release
Not Yet Published
last reviewed release
Not Yet Reviewed


other releases


Proactiverisk.jpg

Main

The information in this document will help you to create a standard , detailed RFP for Application Security Verification projects that service providers or vendors can work with to submit relevant comparable proposals for an organization.


Application Security Verification.

Recommended Information the Client (your Organization) should provide to Service Providers/Vendors.

1. Lines of code. Lines of Code (LOC) or sometimes referred to as Source Lines of Code (SLOC) is a prerequisite for any verification task that involves the review of source code. This software metric (LOC) provides information about the scale of the program under review. There are software packages on the public domain such as LocMetrics on http://locmetrics.com or CLOC on http://cloc.sourceforge.net/ which can be used to count the number of lines of code. Additional information about LOC such as if the count included commented source code or not is also beneficial

2.Number of dynamic pages. Information about the number of dynamic pages is advisable as it provides insights about the scale of the application under assessment. It is important for verification efforts that involved manual penetration testing. When estimating the amount of dynamic pages , pay attention to pages with unique functionality or purpose. If you have urls like:
i. /display_results.php?rs=1 ,
ii. /display_results.php?rs=2 ,
iii./display_results.php?rs=3 ,

you need to ensure that you confirm if they refer to a single unique dynamic page or not

3. An Inventory of user roles and role descriptions. The catalog of user roles is endorsed for all verification efforts as it furnishes business context for vulnerabilities (if any) established.

4. Brief Application Summary and Application architecture. This is mission critical for applications with non-standard architectures such as those using thick clients, web services or integration with legacy systems but not so paramount for applications with a standard web application architecture (web server, application server, database server setup).

5.Degree of verification expected . To manage or prevent suppliers providing erratic bids that vary in figures or timelines ,There is a need to provide definitive guidance on the level of verification desired. This should include requirements for or on:
a. Dynamic vulnerability scanning.
b. Manual code review.
c. Manual penetration testing.
d. Static analysis.
e. Security architecture review.
f. Malicious code analysis.
g. Threat modeling.

6. The frequency or duration for performing verification. It is important to indicate if you want a single verification exercise or if you want several many verification exercises executed within a specified time-frame.

Recommended RFP Questions (Responses are made by Service Providers/Vendors to Client).

Company Background.

a. Summarize the product(s) or service(s) provided by your company.

b. How long has your company been providing products or services relevant to this project? Please provide any relevant information about major milestones such as significant acquisitions , mergers or the introduction or elimination of relevant lines of business.

c. Please provide succinct information your past experience with applications of a similar scope, complexity, and vertical as the applications to be verified in this project.

d. Outline your familiarity and experience with the frameworks, libraries,languages and other relevant technologies that comprise the applications to be verified.

e. Are you involved with organizations or stakeholders in the application security community, such as the Open Web Application Security Project (OWASP) and the Web Application Security Consortium (WASC)? if yes , what roles do you play ?

f. Provide other helpful background information about your organization and your qualification to supply the required product/service.

Application Security Verification Methodology.

a. Outline , in clear details your proposed methodology for all the verification techniques to be utilized:

  i. Dynamic vulnerability scanning.
ii. Malicious code analysis.
iii. Manual code review.
iv. Manual penetration testing.
v. Security architecture review.
vi. Static analysis.
vii. Threat modeling.

b. What would you require from the client to prepare for and successfully execute an application verification exercise ?

c. Would you be using multiple techniques for this project ? If yes how will you combine these in the verification exercise?

d. Describe your proposed level of communication/ interaction with software development teams , security experts, and business process owners during the verification process.

Security Coverage.

a. Explain the vulnerability and security control coverage that is provided by your verification efforts. Where relevant , supply references to the OWASP ASVS,WASC 24 Broad Classes of Attacks, and the OWASP Top 10

b. Provide the different levels of efforts that you will provider for the verification effort. What are the differences in security coverage between these levels?

c. Presently , are you able to test (precisely) for Cross-Site Request Forgery (CSRF) and HTTP Response Splitting?

d. What are potential gaps in coverage for the current proposal and what steps would you take to mitigate the gaps?

e. Does your solution meet current PCI 6.6 standards?


Application Coverage.

a. How effectively does your product/service baseline an application?

b. How do you adjust your product/service to verify an application most effectively?

c. What methods or techniques do you use to ensure coverage of the entire application?

d. How do you corroborate with a customer that you are providing accurate coverage of the targeted application?

e. What potential gaps (if any) exists between your proposed solution and the platform and architecture of the application under verification? A case in point - if the target application contains both web pages and web services and your testing does not cover web services this would indicate a gap.


Risk Evaluation.

a. Outline your risk evaluation process for establishing the probable vulnerabilities you might discover and it’s business impact.

b. What is your procedure for managing the reporting of false positives?

c. Outline your procedures for categorizing similar risks for easy absorption and rectification.

Differentiators.

a. What aspect of the verification process do you find most challenging ( if any )?

b. Tell us why your approach towards this project is exceptional or singular. How and why is this important to the client?

Scope.

a. What are the time estimates for implement your product/service in a similar verification exercise?

b. How does the proposed solution scale for multiple websites?

c. What are the advised steps for curtailing the impact of testing on the performance of applications during the testing process?

d. Indicate if your product or service provisions for on-demand / ad hoc testing.

e. What is the lead time required to initiate testing?

Security.

a. What are your procedures for protecting client’s information made available to you? Outline in detail your network security, information storage security, and need-to-know policy.

b. Describe the level of confidence you have in staff that would have access to our information in this project.

c. Outline the techniques and policies for information exchange between you (the vendor)and us(the client)during this exercise.

d. Describe your procedure for deleting and purging information from your systems at the completion of this project.

e. How would you compartmentalize our information from the risk information belonging to your other clients?

f. Outline (with tangible evidence) that your systems and network is protected from attacks.

Burden.

a. Outline any resource (human) requirements from our organization. This should include technical/operational skill sets and experience.

b. Specify in details the requirements you require from us to execute the verification exercise.

Reporting Interface.

a. Outline your risk documentation structure. This should include:

  i. The Title. 
ii. The Location (URL and/or line of code).
iii. Specific vulnerability description.
iv. Risk likelihood, business impact, and severity.
v. Code snippets.
vi. Specific remediation recommendations.

b. Explain the risk model you utilize . How can it be customized to meet your client’s standards and expectations ?

c. Explain your reporting interface employing criteria such as the learning curve, how reporting components are structured, etc.

d. How do you or your product or services deliver (important) updates on new identified web application risks?

e. What trend and historical reports do you provide that monitor identified/open/closed risks and the ongoing remediation exercise?

f. Is it possible to generate status reports to show the risk status of separate web applications, and the overall security health of all web applications?

g. Are these reports customizable for different stakeholders i.e management.

h. Do you have any standard scripts or standard integration that are bundled with your solution? If yes indicate the applications.

i. Do your reports provide specific directions for application developers, attuned to the exact problem in the code?

j. What is your process for timely and reliable reporting of risks for stakeholders?

k. How often is your reporting interface updated? What process do you follow for this updates?

l. What benchmark exists for developers to know if they have successfully re-mediated a risk?

Innovation.

a. Are there any recent innovations or products your firm has delivered that has resulted in improved service delivery for clients?

b. What is your process for identifying new categories of vulnerabilities and test for this?

c. What is your process of identifying new attack techniques that can be used to exploit known vulnerabilities ?

d. What is your process for testing new technologies (e.g. new versions of Flash) for vulnerabilities?

Integration.

a. What are the standard data formats your product/service produce or export?

b. What other relevant technologies (for example, Firewall Applications) does your product/service integrate with?

c. How will the integration work and what benefits will they bring?

Benefits.

a. How can you increase the efficiency of the remediation process?

b. In your opinion , what is the balance of internal and external resources in an ideal application security program?

c. Can you provide precise results and diminish/eliminate false positives ?

d. Can provide a proof of concept for a positive Return on Investment (ROI) and an increase in benefits to management?

e. Do you have the capacity to influence secure coding techniques / reduce time spent debugging? If yes , How?

f. Outline the technical and business advantage we would gain from working with you in this project.

Supporting Services.

a. Explain any knowledge transfer process or procedure i.e training , platforms etc you will provide with the verification effort.

b. What remediation support do you provide to software development teams?

Client Support Details.

a. Outline your client or customer support framework . What are the of support levels you provide and what are the escalation procedures?

b. Do provide a ticket raising and tracking system ? How are your open tickets tracked and closed?

c. What Service Level Agreement(SLA) do you offer ?

Pricing/Licensing Information.

a. What terms or conditions are linked to the product or service ?Do you have a sample Software License Agreement we can review ?

b. Describe clearly your proposed pricing model.

c. Outline clearly other cost implications which are attached to this bid and requires our attention.

d. Do you provide pro-bono training or consulting services or attach costs to them ? If yes what are the charges attached to them?