OWASP - User contributions [en]

Talk:OWASP Vulnerability Management Guide

2019-05-02T04:54:56Z

Efrenz: /* 1 Detection Cycle */

[https://github.com/lizfrenz/owasp-vuln-mngmnt Please leave a comment using GitHub. ]

= OWASP Vulnerability Management Guide v.1 =
("bare bones" list) 
=== 1 Detection Cycle ===

1.1 Define/Refine scope 
1.1.1 Know the enterprise risks 
1.1.2 Know operational constraints 
1.1.3 Know technical constraints 
1.1.4 Distinguish primary assets vs. secondary 
1.1.5 Embed vulnerability management processes into the enterprise processes 
1.1.6 Build managerial support 

1.2 Optimize Tools 
1.2.1 Determine the type of your test/scan 
1.2.2 Determine the frequency of your tests/scans 
1.2.3 Ensure the latest vulnerability feed 
1.2.4 Check if vulnerability exceptions exist 
1.2.5 Test your tool for integrity 
1.2.6 Adjust your tools settings, preferences, templates 

1.3 Run Tests 
1.3.1 Scan public IP addresses 
1.3.2 Scan private subnets 
1.3.3 Scan/test web applications 
1.3.4 Scan/test mobile apps 
1.3.5 Test Users (phishing, social engineering training) 

1.4 Confirm Findings 
1.4.1 Check if your test results have valuable data 
1.4.2 Interpret and reconcile system/device fingerprinting across your tests 
1.4.3 Determine that running services are what they are supposed to be 
1.4.4 Find something that falls out of the pattern and investigate why 
1.4.5 Randomly select vulnerabilities and confirm them with a different tool or manually 

=== 2 Reporting Cycle ===

2.1 Create Assets Groups 
2.1.1 Determine functional asset groups 
2.1.2 Determine asset groups by type of environment 
2.1.3 Determine asset groups by type of system 
2.1.4 Determine groups by CVE numbering authority or underlying technology 
2.1.5 Determine groups by type of vulnerability 

2.2 Define/Refine Metrics 
2.2.1 Determine amount and percentage of vulnerable assets 
2.2.2 Determine amount and percentage of vulnerable assets by severity and CVSS 
2.2.3 Determine amount and percentage of new vulnerabilities: 
2.2.3.1 -by severity 
2.2.3.2 -by functional groups 
2.2.3.3 -by type of environment 
2.2.3.4 -by type of system 
2.2.3.5 -by CVE numbering authority 
2.2.3.6 -by type of vulnerability 
2.2.4 Compare and analyze aging data by severity of vulnerabilities and their share: 
2.2.4.1 -enterprise wide 
2.2.4.2 -among all other vulnerable assets 
2.2.4.3 -by functional groups 
2.2.4.4 -by type of environment 
2.2.4.5 -by type of system 
2.2.4.6 -by CVE numbering authority 
2.2.4.7 -by type of vulnerability 
2.2.5 Draw out the trends by count and percentage utilizing KPI that matter to your enterprise risks and
compliance 
2.2.6 Determine exploitability of vulnerable assets by severity; specify count, percentage, decrease or
increase 

2.3 Log Confirmed Findings 
2.3.1 Use your organization?s ticketing system 
2.3.2 Provide a summary of the issue 
2.3.3 Provide tools? based output 
2.3.4 Notify/assign the issue/ticket to the responsible teams or individuals 
2.3.5 Make sure that your manager/CISO is aware 

2.4 Create Reports 
2.4.1 Maintain a consistent frequency of reporting and use it to track the changes 
2.4.2 Aggregate and process collected data 
2.4.3 Using CVSS, apply unique environmental traits to your vulnerability analysis 
2.4.4 State vulnerability trends 
2.4.5 Hypothesize about these trends in one sentence 
2.4.6 In one paragraph, add your recommendations 
2.4.7 Apply data sensitivity classification to your report 
2.4.8 Make a shorter version (1-2 pages) of your report 
2.4.9 Submit both versions of the report to your manager/CISO 
2.4.10 Create and maintain your own vulnerability management repository for internal or external audit 
2.4.11 Be able to explain the details of the vulnerability detection and reporting process 

=== 3 Remediation Cycle ===

3.1 Prioritize Vulnerabilities 
3.1.1 Use your reports 
3.1.2 Use your trend analysis 
3.1.3 Use information from additional sources 
3.1.4 Apply other environmental factors 
3.1.5 Communicate to responsible and accountable stakeholders 

3.2 Patching 
3.2.1 Find the stakeholders responsible for patching 
3.2.2 Communicate your findings via the tools and processes they use 
3.2.3 Establish a frequency and scope of patching 
3.2.4 Establish a group of assets dedicated for patch testing 
3.2.5 Report back your test results to the responsible stakeholders 
3.2.6 Use the ticketing system or change management system to resolve the patch management issues 
3.2.7 Always assign these tickets 
3.2.8 Include responsible, accountable, stakeholders, and who needs to be informed on unresolved
issues 
3.2.9 Use the frequency of your reporting cycle to follow up on open issues 

3.3 Investigate False Positives (FP) 
3.3.1 Ensure integrity of a claim 
3.3.2 Construct a repeatable business process 
3.3.3 Document all FP submissions 
3.3.4 Find SMEs who can agree or argue a false positive claim 
3.3.5 Set a time frame at which FP should be reevaluated 
3.3.6 Document each FP and store it in an auditable repository 
3.3.7 Create an appropriate policy 
3.3.8 Communicate this policy to all employees 

3.4 Control Vulnerability Exception Process 
3.4.1 Find an executive authority to sign off on a cyber security exception 
3.4.2 Establish ground rules for vulnerability exceptions 
3.4.3 Establish periodic reviews of vulnerability exceptions 
3.4.4 Establish acceptable compensating controls 
3.4.5 Document each exception and store it in the company?s audit system 
3.4.6 Create an appropriate policy 
3.4.7 Communicate this policy to all employees 
3.4.8 Have vulnerability exception solicitors asking the executive authority for an approval every time

OWASP Vulnerability Management Guide

2019-05-02T03:17:49Z

Efrenz:

OWASP Vulnerability Management Guide

2018-09-24T04:45:09Z

Efrenz:

OWASP Vulnerability Management Guide

2018-09-24T04:42:49Z

Efrenz: /* Description */

OWASP Vulnerability Management Guide

2018-09-24T04:40:37Z

Efrenz:

OWASP Vulnerability Management Guide

2018-09-24T04:34:14Z

Efrenz:

OWASP Vulnerability Management Guide

2018-09-24T04:32:55Z

Efrenz:

Talk:OWASP Vulnerability Management Guide

2018-09-24T04:23:22Z

Efrenz:

[https://github.com/lizfrenz/owasp-vuln-mngmnt Please leave a comment using GitHub. ]

= OWASP Vulnerability Management Guide v.1 =
("bare bones" list) 
=== 1 Detection Cycle ===

1.1 Define/Refine scope 
1.1.1 Know the enterprise risks 
1.1.2 Know operational constraints 
1.1.3 Know technical constraints 
1.1.4 Distinguish primary assets vs. secondary 
1.1.5 Embed vulnerability management processes into the enterprise processes 
1.1.6 Build managerial support 

1.2 Optimize Tools 
1.2.1 Determine the type of your test/scan 
1.2.2 Determine the frequency of your tests/scans 
1.2.3 Ensure the latest vulnerability feed 
1.2.4 Check if vulnerability exceptions exist 
1.2.5 Test your tool for integrity 
1.2.6 Adjust your tools settings, preferences, templates 

1.3 Confirm Findings 
1.3.1 Check if your test results have valuable data 
1.3.2 Interpret and reconcile system/device fingerprinting across your tests 
1.3.3 Determine that running services are what they are supposed to be 
1.3.4 Find something that falls out of the pattern and investigate why 
1.3.5 Randomly select vulnerabilities and confirm them with a different tool or manually 

=== 2 Reporting Cycle ===

2.1 Create Assets Groups 
2.1.1 Determine functional asset groups 
2.1.2 Determine asset groups by type of environment 
2.1.3 Determine asset groups by type of system 
2.1.4 Determine groups by CVE numbering authority or underlying technology 
2.1.5 Determine groups by type of vulnerability 

2.2 Define/Refine Metrics 
2.2.1 Determine amount and percentage of vulnerable assets 
2.2.2 Determine amount and percentage of vulnerable assets by severity and CVSS 
2.2.3 Determine amount and percentage of new vulnerabilities: 
2.2.3.1 -by severity 
2.2.3.2 -by functional groups 
2.2.3.3 -by type of environment 
2.2.3.4 -by type of system 
2.2.3.5 -by CVE numbering authority 
2.2.3.6 -by type of vulnerability 
2.2.4 Compare and analyze aging data by severity of vulnerabilities and their share: 
2.2.4.1 -enterprise wide 
2.2.4.2 -among all other vulnerable assets 
2.2.4.3 -by functional groups 
2.2.4.4 -by type of environment 
2.2.4.5 -by type of system 
2.2.4.6 -by CVE numbering authority 
2.2.4.7 -by type of vulnerability 
2.2.5 Draw out the trends by count and percentage utilizing KPI that matter to your enterprise risks and
compliance 
2.2.6 Determine exploitability of vulnerable assets by severity; specify count, percentage, decrease or
increase 

2.3 Log Confirmed Findings 
2.3.1 Use your organization?s ticketing system 
2.3.2 Provide a summary of the issue 
2.3.3 Provide tools? based output 
2.3.4 Notify/assign the issue/ticket to the responsible teams or individuals 
2.3.5 Make sure that your manager/CISO is aware 

2.4 Create Reports 
2.4.1 Maintain a consistent frequency of reporting and use it to track the changes 
2.4.2 Aggregate and process collected data 
2.4.3 Using CVSS, apply unique environmental traits to your vulnerability analysis 
2.4.4 State vulnerability trends 
2.4.5 Hypothesize about these trends in one sentence 
2.4.6 In one paragraph, add your recommendations 
2.4.7 Apply data sensitivity classification to your report 
2.4.8 Make a shorter version (1-2 pages) of your report 
2.4.9 Submit both versions of the report to your manager/CISO 
2.4.10 Create and maintain your own vulnerability management repository for internal or external audit 
2.4.11 Be able to explain the details of the vulnerability detection and reporting process 

=== 3 Remediation Cycle ===

3.1 Prioritize Vulnerabilities 
3.1.1 Use your reports 
3.1.2 Use your trend analysis 
3.1.3 Use information from additional sources 
3.1.4 Apply other environmental factors 
3.1.5 Communicate to responsible and accountable stakeholders 

3.2 Patching 
3.2.1 Find the stakeholders responsible for patching 
3.2.2 Communicate your findings via the tools and processes they use 
3.2.3 Establish a frequency and scope of patching 
3.2.4 Establish a group of assets dedicated for patch testing 
3.2.5 Report back your test results to the responsible stakeholders 
3.2.6 Use the ticketing system or change management system to resolve the patch management issues 
3.2.7 Always assign these tickets 
3.2.8 Include responsible, accountable, stakeholders, and who needs to be informed on unresolved
issues 
3.2.9 Use the frequency of your reporting cycle to follow up on open issues 

3.3 Investigate False Positives (FP) 
3.3.1 Ensure integrity of a claim 
3.3.2 Construct a repeatable business process 
3.3.3 Document all FP submissions 
3.3.4 Find SMEs who can agree or argue a false positive claim 
3.3.5 Set a time frame at which FP should be reevaluated 
3.3.6 Document each FP and store it in an auditable repository 
3.3.7 Create an appropriate policy 
3.3.8 Communicate this policy to all employees 

3.4 Control Vulnerability Exception Process 
3.4.1 Find an executive authority to sign off on a cyber security exception 
3.4.2 Establish ground rules for vulnerability exceptions 
3.4.3 Establish periodic reviews of vulnerability exceptions 
3.4.4 Establish acceptable compensating controls 
3.4.5 Document each exception and store it in the company?s audit system 
3.4.6 Create an appropriate policy 
3.4.7 Communicate this policy to all employees 
3.4.8 Have vulnerability exception solicitors asking the executive authority for an approval every time

Talk:OWASP Vulnerability Management Guide

2018-09-24T04:21:47Z

Efrenz:

[https://github.com/lizfrenz/owasp-vuln-mngmnt Please leave a comment using GitHub. ]

== OWASP Vulnerability Management Guide v.1 ==
("bare bones" list) 
=== 1 Detection Cycle ===

1.1 Define/Refine scope 
1.1.1 Know the enterprise risks 
1.1.2 Know operational constraints 
1.1.3 Know technical constraints 
1.1.4 Distinguish primary assets vs. secondary 
1.1.5 Embed vulnerability management processes into the enterprise processes 
1.1.6 Build managerial support 

1.2 Optimize Tools 
1.2.1 Determine the type of your test/scan 
1.2.2 Determine the frequency of your tests/scans 
1.2.3 Ensure the latest vulnerability feed 
1.2.4 Check if vulnerability exceptions exist 
1.2.5 Test your tool for integrity 
1.2.6 Adjust your tools settings, preferences, templates 

1.3 Confirm Findings 
1.3.1 Check if your test results have valuable data 
1.3.2 Interpret and reconcile system/device fingerprinting across your tests 
1.3.3 Determine that running services are what they are supposed to be 
1.3.4 Find something that falls out of the pattern and investigate why 
1.3.5 Randomly select vulnerabilities and confirm them with a different tool or manually 

=== 2 Reporting Cycle ===

2.1 Create Assets Groups 
2.1.1 Determine functional asset groups 
2.1.2 Determine asset groups by type of environment 
2.1.3 Determine asset groups by type of system 
2.1.4 Determine groups by CVE numbering authority or underlying technology 
2.1.5 Determine groups by type of vulnerability 

2.2 Define/Refine Metrics 
2.2.1 Determine amount and percentage of vulnerable assets 
2.2.2 Determine amount and percentage of vulnerable assets by severity and CVSS 
2.2.3 Determine amount and percentage of new vulnerabilities: 
2.2.3.1 -by severity 
2.2.3.2 -by functional groups 
2.2.3.3 -by type of environment 
2.2.3.4 -by type of system 
2.2.3.5 -by CVE numbering authority 
2.2.3.6 -by type of vulnerability 
2.2.4 Compare and analyze aging data by severity of vulnerabilities and their share: 
2.2.4.1 -enterprise wide 
2.2.4.2 -among all other vulnerable assets 
2.2.4.3 -by functional groups 
2.2.4.4 -by type of environment 
2.2.4.5 -by type of system 
2.2.4.6 -by CVE numbering authority 
2.2.4.7 -by type of vulnerability 
2.2.5 Draw out the trends by count and percentage utilizing KPI that matter to your enterprise risks and
compliance 
2.2.6 Determine exploitability of vulnerable assets by severity; specify count, percentage, decrease or
increase 

2.3 Log Confirmed Findings 
2.3.1 Use your organization?s ticketing system 
2.3.2 Provide a summary of the issue 
2.3.3 Provide tools? based output 
2.3.4 Notify/assign the issue/ticket to the responsible teams or individuals 
2.3.5 Make sure that your manager/CISO is aware 

2.4 Create Reports 
2.4.1 Maintain a consistent frequency of reporting and use it to track the changes 
2.4.2 Aggregate and process collected data 
2.4.3 Using CVSS, apply unique environmental traits to your vulnerability analysis 
2.4.4 State vulnerability trends 
2.4.5 Hypothesize about these trends in one sentence 
2.4.6 In one paragraph, add your recommendations 
2.4.7 Apply data sensitivity classification to your report 
2.4.8 Make a shorter version (1-2 pages) of your report 
2.4.9 Submit both versions of the report to your manager/CISO 
2.4.10 Create and maintain your own vulnerability management repository for internal or external audit 
2.4.11 Be able to explain the details of the vulnerability detection and reporting process 

=== 3 Remediation Cycle ===

3.1 Prioritize Vulnerabilities 
3.1.1 Use your reports 
3.1.2 Use your trend analysis 
3.1.3 Use information from additional sources 
3.1.4 Apply other environmental factors 
3.1.5 Communicate to responsible and accountable stakeholders 

3.2 Patching 
3.2.1 Find the stakeholders responsible for patching 
3.2.2 Communicate your findings via the tools and processes they use 
3.2.3 Establish a frequency and scope of patching 
3.2.4 Establish a group of assets dedicated for patch testing 
3.2.5 Report back your test results to the responsible stakeholders 
3.2.6 Use the ticketing system or change management system to resolve the patch management issues 
3.2.7 Always assign these tickets 
3.2.8 Include responsible, accountable, stakeholders, and who needs to be informed on unresolved
issues 
3.2.9 Use the frequency of your reporting cycle to follow up on open issues 

3.3 Investigate False Positives (FP) 
3.3.1 Ensure integrity of a claim 
3.3.2 Construct a repeatable business process 
3.3.3 Document all FP submissions 
3.3.4 Find SMEs who can agree or argue a false positive claim 
3.3.5 Set a time frame at which FP should be reevaluated 
3.3.6 Document each FP and store it in an auditable repository 
3.3.7 Create an appropriate policy 
3.3.8 Communicate this policy to all employees 

3.4 Control Vulnerability Exception Process 
3.4.1 Find an executive authority to sign off on a cyber security exception 
3.4.2 Establish ground rules for vulnerability exceptions 
3.4.3 Establish periodic reviews of vulnerability exceptions 
3.4.4 Establish acceptable compensating controls 
3.4.5 Document each exception and store it in the company?s audit system 
3.4.6 Create an appropriate policy 
3.4.7 Communicate this policy to all employees 
3.4.8 Have vulnerability exception solicitors asking the executive authority for an approval every time

Talk:OWASP Vulnerability Management Guide

2018-09-24T04:03:56Z

Efrenz:

[https://github.com/lizfrenz/owasp-vuln-mngmnt Please leave a comment using GitHub. ]

OWASP Vulnerability Management Guide v.1
(“bare bones” list)

1 Detection Cycle

1.1 Define/Refine scope
1.1.1 Know the enterprise risks
1.1.2 Know operational constraints
1.1.3 Know technical constraints
1.1.4 Distinguish primary assets vs. secondary
1.1.5 Embed vulnerability management processes into the enterprise processes
1.1.6 Build managerial support

1.2 Optimize Tools
1.2.1 Determine the type of your test/scan
1.2.2 Determine the frequency of your tests/scans
1.2.3 Ensure the latest vulnerability feed
1.2.4 Check if vulnerability exceptions exist
1.2.5 Test your tool for integrity
1.2.6 Adjust your tools settings, preferences, templates

1.3 Confirm Findings
1.3.1 Check if your test results have valuable data
1.3.2 Interpret and reconcile system/device fingerprinting across your tests
1.3.3 Determine that running services are what they are supposed to be
1.3.4 Find something that falls out of the pattern and investigate why
1.3.5 Randomly select vulnerabilities and confirm them with a different tool or manually

2 Reporting Cycle

2.1 Create Assets Groups
2.1.1 Determine functional asset groups
2.1.2 Determine asset groups by type of environment
2.1.3 Determine asset groups by type of system
2.1.4 Determine groups by CVE numbering authority or underlying technology
2.1.5 Determine groups by type of vulnerability

2.2 Define/Refine Metrics
2.2.1 Determine amount and percentage of vulnerable assets
2.2.2 Determine amount and percentage of vulnerable assets by severity and CVSS
2.2.3 Determine amount and percentage of new vulnerabilities:
2.2.3.1 -by severity
2.2.3.2 -by functional groups
2.2.3.3 -by type of environment
2.2.3.4 -by type of system
2.2.3.5 -by CVE numbering authority
2.2.3.6 -by type of vulnerability
2.2.4 Compare and analyze aging data by severity of vulnerabilities and their share:
2.2.4.1 -enterprise wide
2.2.4.2 -among all other vulnerable assets
2.2.4.3 -by functional groups
2.2.4.4 -by type of environment
2.2.4.5 -by type of system
2.2.4.6 -by CVE numbering authority
2.2.4.7 -by type of vulnerability
2.2.5 Draw out the trends by count and percentage utilizing KPI that matter to your enterprise risks and compliance
2.2.6 Determine exploitability of vulnerable assets by severity; specify count, percentage, decrease or increase

2.3 Log Confirmed Findings
2.3.1 Use your organization’s ticketing system
2.3.2 Provide a summary of the issue
2.3.3 Provide tools’ based output
2.3.4 Notify/assign the issue/ticket to the responsible teams or individuals
2.3.5 Make sure that your manager/CISO is aware

2.4 Create Reports
2.4.1 Maintain a consistent frequency of reporting and use it to track the changes
2.4.2 Aggregate and process collected data
2.4.3 Using CVSS, apply unique environmental traits to your vulnerability analysis
2.4.4 State vulnerability trends
2.4.5 Hypothesize about these trends in one sentence
2.4.6 In one paragraph, add your recommendations
2.4.7 Apply data sensitivity classification to your report
2.4.8 Make a shorter version (1-2 pages) of your report
2.4.9 Submit both versions of the report to your manager/CISO
2.4.10 Create and maintain your own vulnerability management repository for internal or external audit
2.4.11 Be able to explain the details of the vulnerability detection and reporting process

3 Remediation Cycle

3.1 Prioritize Vulnerabilities
3.1.1 Use your reports
3.1.2 Use your trend analysis
3.1.3 Use information from additional sources
3.1.4 Apply other environmental factors
3.1.5 Communicate to responsible and accountable stakeholders

3.2 Patching
3.2.1 Find the stakeholders responsible for patching
3.2.2 Communicate your findings via the tools and processes they use
3.2.3 Establish a frequency and scope of patching
3.2.4 Establish a group of assets dedicated for patch testing
3.2.5 Report back your test results to the responsible stakeholders
3.2.6 Use the ticketing system or change management system to resolve the patch management issues
3.2.7 Always assign these tickets
3.2.8 Include responsible, accountable, stakeholders, and who needs to be informed on unresolved issues
3.2.9 Use the frequency of your reporting cycle to follow up on open issues

3.3 Investigate False Positives (FP)
3.3.1 Ensure integrity of a claim
3.3.2 Construct a repeatable business process
3.3.3 Document all FP submissions
3.3.4 Find SMEs who can agree or argue a false positive claim
3.3.5 Set a time frame at which FP should be reevaluated
3.3.6 Document each FP and store it in an auditable repository
3.3.7 Create an appropriate policy
3.3.8 Communicate this policy to all employees

3.4 Control Vulnerability Exception Process
3.4.1 Find an executive authority to sign off on a cyber security exception
3.4.2 Establish ground rules for vulnerability exceptions
3.4.3 Establish periodic reviews of vulnerability exceptions
3.4.4 Establish acceptable compensating controls
3.4.5 Document each exception and store it in the company’s audit system
3.4.6 Create an appropriate policy
3.4.7 Communicate this policy to all employees
3.4.8 Have vulnerability exception solicitors asking the executive authority for an approval every time

Talk:OWASP Vulnerability Management Guide

2018-09-24T02:52:59Z

Efrenz: Created page with "[https://github.com/lizfrenz/owasp-vuln-mngmnt Please leave a comment using GitHub. ]"

[https://github.com/lizfrenz/owasp-vuln-mngmnt Please leave a comment using GitHub. ]

OWASP Vulnerability Management Guide

2018-09-24T02:48:47Z

Efrenz: /* Getting Involved */

OWASP Vulnerability Management Guide

2018-09-24T02:40:19Z

Efrenz: /* Roadmap */

OWASP Vulnerability Management Guide

2018-09-24T02:36:29Z

Efrenz:

OWASP Vulnerability Management Guide

2018-09-24T02:36:06Z

Efrenz:

OWASP Vulnerability Management Guide

2018-08-20T00:51:32Z

Efrenz:

OWASP Vulnerability Management Guide

2018-08-20T00:50:24Z

Efrenz: Created page from template

OWASP Vulnerability Management Guide

2018-08-20T00:12:48Z

Efrenz: /* Related Projects */

<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;" |


Instructions are in RED text and should be removed from your document by deleting the text with the span tags. This document is intended to serve as an example of what is required of an OWASP project wiki page. The text in red serves as instructions, while the text in black serves as an example. Text in black is expected to be replaced entirely with information specific to your OWASP project.

==Project About==

{{:Projects/OWASP_Example_Project_About_Page}}

==OWASP Documentation Project Template==

This section should include an overview of what the project is, why the project was started, and what security issue is being addressed by the project deliverable. Some readers may be discouraged from looking further at the project if they do not understand the significance of the security concern that is being addressed, so provide enough context so the average reader will continue on with reading the description. You shouldn't assume the reader will understand the objective by providing security terminology, e.g. this project builds cryptographic algorithms, but should also endeavor to explain what they are used for.


The OWASP Documentation Template Project is a template designed to help Project Leaders create suitable project pages for OWASP Projects. By following the instructional text in red (and then deleting it) it should be easier to understand what information OWASP and the project users are looking for. And it's easy to get started by simply creating a new project from the appropriate project template.

==Description==

This is where you need to add your more robust project description. A project description should outline the purpose of the project, how it is used, and the value it provides to application security. Ideally, project descriptions should be written in such a way that there is no question what value the project provides to the software security community. This section will be seen and used in various places within the Projects Portal. Poorly written project descriptions therefore detract from a project’s visibility, so project leaders should ensure that the description is meaningful.


The Documentation Project Template is simply a sample project that was developed for instructional purposes that can be used to create default project pages for a Documentation project. After copying this template to your new project, all you have to do is follow the instructions in red, replace the sample text with text suited for your project, and then delete the sections in red. Doing so should make it clearer to both consumers of this project, as well as OWASP reviewers who are trying to determine if the project can be promoted to the next category. The information requested is also intended to help Project Leaders think about the roadmap and feature priorities, and give guidance to the reviews as a result of that effort.

Creating a new set of project pages from scratch can be a challenging task. By providing a sample layout, with instructional text and examples, the OWASP Documentation Project Template makes it easier for Project Leaders to create effective security projects and hence helps promote security.

Contextual custom dictionary builder with character substitution and word variations for pen-testers

==Licensing==

A project must be licensed under a community friendly or open source license. For more information on OWASP recommended licenses, please see [https://www.owasp.org/index.php/OWASP_Licenses OWASP Licenses]. While OWASP does not promote any particular license over another, the vast majority of projects have chosen a Creative Commons license variant for documentation projects, or a GNU General Public License variant for tools and code projects. This example assumes that you want to use the AGPL 3.0 license.


This program is free software: you can redistribute it and/or modify it under the terms of the [http://www.gnu.org/licenses/agpl-3.0.html link GNU Affero General Public License 3.0] as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. OWASP XXX and any contributions are Copyright © by {the Project Leader(s) or OWASP} {Year(s)}.

==Roadmap==

As of November, 2013, the highest priorities for the next 6 months are:

* Complete the first draft of the Tool Project Template
* Get other people to review the Tool Project Template and provide feedback
* Incorporate feedback into changes in the Tool Project Template
* Finalize the Documentation Project template and have it reviewed to be promoted from an Incubator Project to a Lab Project


Subsequent Releases will add

* Internationalization Support
* Additional Unit Tests
* Automated Regression tests


==Getting Involved==

Involvement in the development and promotion of Documentation Project Template is actively encouraged!
You do not have to be a security expert or a programmer to contribute.
Some of the ways you can help are as follows:

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== Project Resources ==

This is where you can link to the key locations for project files, including setup programs, the source code repository, online documentation, a Wiki Home Page, threaded discussions about the project, and Issue Tracking system, etc.


[https://github.com/SamanthaGroves Installation Package]

[https://github.com/SamanthaGroves Source Code]

[https://github.com/SamanthaGroves What's New (Revision History)]

[https://github.com/SamanthaGroves Documentation]

[https://github.com/SamanthaGroves Wiki Home Page]

[https://github.com/SamanthaGroves Issue Tracker]

[https://github.com/SamanthaGroves Slide Presentation]

[https://github.com/SamanthaGroves Video]

== Project Leader ==

Elizabeth Frenz is a highly experienced information security professional that specializes in taking risk based approaches to improving the security and quality of software products. She works as Information Security Analyst for DOE DIIT. Previously in her career she led the vulnerability management program for a Fortune 500 company that builds software solutions for the pharmaceutical industry. Elizabeth also has extensive experience in the identity and access management arena and was one of the contributors to an IEEE standard for using biometrics for identity and access management. She is an active member in the NY information security scene and serves as chapter leader of the NYC OWASP chapter. Elizabeth holds an MS degree in Systems Management from NYU.


== Related Projects ==

No related OWASP projects yet.

* [[OWASP_Code_Project_Template]]
* [[OWASP_Tool_Project_Template]]

==Classifications==

{| width="200" cellpadding="2"
|-
| colspan="2" align="center" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|-
| 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|Incubator Project]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[Image:Creative%20Commons.png| 90px | link=https://creativecommons.org/licenses/by-sa/3.0/| Creative Commons Attribution ShareAlike 3.0 License]]
|}
|}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Document]]

OWASP Vulnerability Management Guide

2018-08-20T00:11:08Z

Efrenz: /* Project Leader */

<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;" |


Instructions are in RED text and should be removed from your document by deleting the text with the span tags. This document is intended to serve as an example of what is required of an OWASP project wiki page. The text in red serves as instructions, while the text in black serves as an example. Text in black is expected to be replaced entirely with information specific to your OWASP project.

==Project About==

{{:Projects/OWASP_Example_Project_About_Page}}

==OWASP Documentation Project Template==

This section should include an overview of what the project is, why the project was started, and what security issue is being addressed by the project deliverable. Some readers may be discouraged from looking further at the project if they do not understand the significance of the security concern that is being addressed, so provide enough context so the average reader will continue on with reading the description. You shouldn't assume the reader will understand the objective by providing security terminology, e.g. this project builds cryptographic algorithms, but should also endeavor to explain what they are used for.


The OWASP Documentation Template Project is a template designed to help Project Leaders create suitable project pages for OWASP Projects. By following the instructional text in red (and then deleting it) it should be easier to understand what information OWASP and the project users are looking for. And it's easy to get started by simply creating a new project from the appropriate project template.

==Description==

This is where you need to add your more robust project description. A project description should outline the purpose of the project, how it is used, and the value it provides to application security. Ideally, project descriptions should be written in such a way that there is no question what value the project provides to the software security community. This section will be seen and used in various places within the Projects Portal. Poorly written project descriptions therefore detract from a project’s visibility, so project leaders should ensure that the description is meaningful.


The Documentation Project Template is simply a sample project that was developed for instructional purposes that can be used to create default project pages for a Documentation project. After copying this template to your new project, all you have to do is follow the instructions in red, replace the sample text with text suited for your project, and then delete the sections in red. Doing so should make it clearer to both consumers of this project, as well as OWASP reviewers who are trying to determine if the project can be promoted to the next category. The information requested is also intended to help Project Leaders think about the roadmap and feature priorities, and give guidance to the reviews as a result of that effort.

Creating a new set of project pages from scratch can be a challenging task. By providing a sample layout, with instructional text and examples, the OWASP Documentation Project Template makes it easier for Project Leaders to create effective security projects and hence helps promote security.

Contextual custom dictionary builder with character substitution and word variations for pen-testers

==Licensing==

A project must be licensed under a community friendly or open source license. For more information on OWASP recommended licenses, please see [https://www.owasp.org/index.php/OWASP_Licenses OWASP Licenses]. While OWASP does not promote any particular license over another, the vast majority of projects have chosen a Creative Commons license variant for documentation projects, or a GNU General Public License variant for tools and code projects. This example assumes that you want to use the AGPL 3.0 license.


This program is free software: you can redistribute it and/or modify it under the terms of the [http://www.gnu.org/licenses/agpl-3.0.html link GNU Affero General Public License 3.0] as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. OWASP XXX and any contributions are Copyright © by {the Project Leader(s) or OWASP} {Year(s)}.

==Roadmap==

As of November, 2013, the highest priorities for the next 6 months are:

* Complete the first draft of the Tool Project Template
* Get other people to review the Tool Project Template and provide feedback
* Incorporate feedback into changes in the Tool Project Template
* Finalize the Documentation Project template and have it reviewed to be promoted from an Incubator Project to a Lab Project


Subsequent Releases will add

* Internationalization Support
* Additional Unit Tests
* Automated Regression tests


==Getting Involved==

Involvement in the development and promotion of Documentation Project Template is actively encouraged!
You do not have to be a security expert or a programmer to contribute.
Some of the ways you can help are as follows:

| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |

== Project Resources ==

This is where you can link to the key locations for project files, including setup programs, the source code repository, online documentation, a Wiki Home Page, threaded discussions about the project, and Issue Tracking system, etc.


[https://github.com/SamanthaGroves Installation Package]

[https://github.com/SamanthaGroves Source Code]

[https://github.com/SamanthaGroves What's New (Revision History)]

[https://github.com/SamanthaGroves Documentation]

[https://github.com/SamanthaGroves Wiki Home Page]

[https://github.com/SamanthaGroves Issue Tracker]

[https://github.com/SamanthaGroves Slide Presentation]

[https://github.com/SamanthaGroves Video]

== Project Leader ==

Elizabeth Frenz is a highly experienced information security professional that specializes in taking risk based approaches to improving the security and quality of software products. She works as Information Security Analyst for DOE DIIT. Previously in her career she led the vulnerability management program for a Fortune 500 company that builds software solutions for the pharmaceutical industry. Elizabeth also has extensive experience in the identity and access management arena and was one of the contributors to an IEEE standard for using biometrics for identity and access management. She is an active member in the NY information security scene and serves as chapter leader of the NYC OWASP chapter. Elizabeth holds an MS degree in Systems Management from NYU.


== Related Projects ==

This is where you can link to other OWASP Projects that are similar to yours.

* [[OWASP_Code_Project_Template]]
* [[OWASP_Tool_Project_Template]]

==Classifications==

{| width="200" cellpadding="2"
|-
| colspan="2" align="center" | [[File:Project_Type_Files_TOOL.jpg|link=https://www.owasp.org/index.php/Category:OWASP_Tool]]
|-
| 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|Incubator Project]]
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=Builders]]
|-
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=Defenders]]
|-
| colspan="2" align="center" | [[Image:Creative%20Commons.png| 90px | link=https://creativecommons.org/licenses/by-sa/3.0/| Creative Commons Attribution ShareAlike 3.0 License]]
|}
|}

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Document]]