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 "Talk:OWASP Vulnerability Management Guide"

From OWASP
Jump to: navigation, search
Line 1: Line 1:
 
[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 v.1 ==
 +
<small>("bare bones" list) <br></small>
 +
=== 1 Detection Cycle ===
  
OWASP Vulnerability Management Guide v.1
+
1.1 Define/Refine scope <br>
(“bare bones” list)
+
1.1.1 Know the enterprise risks<br>
 +
1.1.2 Know operational constraints<br>
 +
1.1.3 Know technical constraints<br>
 +
1.1.4 Distinguish primary assets vs. secondary<br>
 +
1.1.5 Embed vulnerability management processes into the enterprise processes<br>
 +
1.1.6 Build managerial support<br>
  
1 Detection Cycle
+
1.2 Optimize Tools<br>
 +
1.2.1 Determine the type of your test/scan<br>
 +
1.2.2 Determine the frequency of your tests/scans<br>
 +
1.2.3 Ensure the latest vulnerability feed<br>
 +
1.2.4 Check if vulnerability exceptions exist<br>
 +
1.2.5 Test your tool for integrity<br>
 +
1.2.6 Adjust your tools settings, preferences, templates<br>
  
1.1 Define/Refine scope
+
1.3 Confirm Findings<br>
1.1.1 Know the enterprise risks
+
1.3.1 Check if your test results have valuable data<br>
1.1.2 Know operational constraints
+
1.3.2 Interpret and reconcile system/device fingerprinting across your tests<br>
1.1.3 Know technical constraints
+
1.3.3 Determine that running services  are what they are supposed to be<br>
1.1.4 Distinguish primary assets vs. secondary
+
1.3.4 Find something that falls out of the pattern and investigate why<br>
1.1.5 Embed vulnerability management processes into the enterprise processes
+
1.3.5 Randomly select vulnerabilities and confirm them with a different tool or manually<br>
1.1.6 Build managerial support
 
  
1.2 Optimize Tools
+
=== 2 Reporting Cycle<br> ===
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
+
2.1 Create Assets Groups<br>
1.3.1 Check if your test results have valuable data
+
2.1.1 Determine functional asset groups<br>
1.3.2 Interpret and reconcile system/device fingerprinting across your tests
+
2.1.2 Determine asset groups by type of environment<br>
1.3.3 Determine that running services  are what they are supposed to be
+
2.1.3 Determine asset groups by type of system<br>
1.3.4 Find something that falls out of the pattern and investigate why
+
2.1.4 Determine groups by CVE numbering authority or underlying technology<br>
1.3.5 Randomly select vulnerabilities and confirm them with a different tool or manually
+
2.1.5 Determine groups by type of vulnerability<br>
  
2 Reporting Cycle
+
2.2 Define/Refine Metrics<br>
 +
2.2.1 Determine amount and percentage of vulnerable assets<br>
 +
2.2.2 Determine amount and percentage of vulnerable assets by severity and CVSS<br>
 +
2.2.3 Determine amount and percentage of new vulnerabilities:<br>
 +
2.2.3.1 -by severity<br>
 +
2.2.3.2 -by functional groups<br>
 +
2.2.3.3 -by type of environment<br>
 +
2.2.3.4 -by type of system<br>
 +
2.2.3.5 -by CVE numbering authority<br>
 +
2.2.3.6 -by type of vulnerability<br>
 +
2.2.4 Compare and analyze aging data by severity of vulnerabilities and their share:<br>
 +
2.2.4.1 -enterprise wide<br>
 +
2.2.4.2 -among all other vulnerable assets<br>
 +
2.2.4.3 -by functional groups<br>
 +
2.2.4.4 -by type of environment<br>
 +
2.2.4.5 -by type of system<br>
 +
2.2.4.6 -by CVE numbering authority<br>
 +
2.2.4.7 -by type of vulnerability<br>
 +
2.2.5 Draw out the trends by count and percentage utilizing KPI that matter to your enterprise risks and
 +
compliance<br>
 +
2.2.6 Determine exploitability of vulnerable assets by severity; specify count, percentage, decrease or
 +
increase<br>
  
2.1 Create Assets Groups
+
2.3 Log Confirmed Findings<br>
2.1.1 Determine functional asset groups
+
2.3.1 Use your organization?s ticketing system<br>
2.1.2 Determine asset groups by type of environment
+
2.3.2 Provide a summary of the issue<br>
2.1.3 Determine asset groups by type of system
+
2.3.3 Provide tools? based output<br>
2.1.4 Determine groups by CVE numbering authority or underlying technology
+
2.3.4 Notify/assign the issue/ticket to the responsible teams or individuals<br>
2.1.5 Determine groups by type of vulnerability
+
2.3.5 Make sure that your manager/CISO is aware<br>
  
2.2 Define/Refine Metrics
+
2.4 Create Reports<br>
2.2.1 Determine amount and percentage of vulnerable assets
+
2.4.1 Maintain a consistent frequency of reporting and use it to track the changes<br>
2.2.2 Determine amount and percentage of vulnerable assets by severity and CVSS
+
2.4.2 Aggregate and process collected data<br>
2.2.3 Determine amount and percentage of new vulnerabilities:
+
2.4.3 Using CVSS, apply unique environmental traits to your vulnerability analysis<br>
2.2.3.1 -by severity
+
2.4.4 State vulnerability trends<br>
2.2.3.2 -by functional groups
+
2.4.5 Hypothesize about these trends in one sentence<br>
2.2.3.3 -by type of environment
+
2.4.6 In one paragraph, add your recommendations<br>
2.2.3.4 -by type of system
+
2.4.7 Apply data sensitivity classification to your report<br>
2.2.3.5 -by CVE numbering authority
+
2.4.8 Make a shorter version (1-2 pages) of your report<br>
2.2.3.6 -by type of vulnerability
+
2.4.9 Submit both versions of the report to your manager/CISO<br>
2.2.4 Compare and analyze aging data by severity of vulnerabilities and their share:
+
2.4.10 Create and maintain your own vulnerability management repository for internal or external audit<br>
2.2.4.1 -enterprise wide
+
2.4.11 Be able to explain the details of the vulnerability detection and reporting process<br>
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
+
=== 3 Remediation Cycle<br> ===
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
+
3.1 Prioritize Vulnerabilities<br>
2.4.1 Maintain a consistent frequency of reporting and use it to track the changes
+
3.1.1 Use your reports<br>
2.4.2 Aggregate and process collected data
+
3.1.2 Use your trend analysis<br>
2.4.3 Using CVSS, apply unique environmental traits to your vulnerability analysis
+
3.1.3 Use information from additional sources<br>
2.4.4 State vulnerability trends
+
3.1.4 Apply other environmental factors<br>
2.4.5 Hypothesize about these trends in one sentence
+
3.1.5 Communicate to responsible and accountable stakeholders<br>
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.2 Patching<br>
 +
3.2.1 Find the stakeholders responsible for patching<br>
 +
3.2.2 Communicate your findings via the tools and processes they use<br>
 +
3.2.3 Establish a frequency and scope of patching<br>
 +
3.2.4 Establish a group of assets dedicated for patch testing<br>
 +
3.2.5 Report back your test results to the responsible stakeholders<br>
 +
3.2.6 Use the ticketing system or change management system to resolve the patch management issues<br>
 +
3.2.7 Always assign these tickets<br>
 +
3.2.8 Include responsible, accountable, stakeholders, and who needs to be informed on unresolved
 +
issues<br>
 +
3.2.9 Use the frequency of your reporting cycle to follow up on open issues<br>
  
3.1 Prioritize Vulnerabilities
+
3.3 Investigate False Positives (FP)<br>
3.1.1 Use your reports
+
3.3.1 Ensure integrity of a claim<br>
3.1.2 Use your trend analysis
+
3.3.2 Construct a repeatable business process<br>
3.1.3 Use information from additional sources
+
3.3.3 Document all FP submissions<br>
3.1.4 Apply other environmental factors
+
3.3.4 Find SMEs who can agree or argue a false positive claim<br>
3.1.5 Communicate to responsible and accountable stakeholders
+
3.3.5 Set a time frame at which FP should be reevaluated<br>
 +
3.3.6 Document each FP and store it in an auditable repository<br>
 +
3.3.7 Create an appropriate policy<br>
 +
3.3.8 Communicate this policy to all employees<br>
  
3.2 Patching
+
3.4 Control Vulnerability Exception Process<br>
3.2.1 Find the stakeholders responsible for patching
+
3.4.1 Find an executive authority to sign off on a cyber security exception<br>
3.2.2 Communicate your findings via the tools and processes they use
+
3.4.2 Establish ground rules for vulnerability exceptions<br>
3.2.3 Establish a frequency and scope of patching
+
3.4.3 Establish periodic reviews of  vulnerability exceptions<br>
3.2.4 Establish a group of assets dedicated for patch testing
+
3.4.4 Establish acceptable compensating controls<br>
3.2.5 Report back your test results to the responsible stakeholders
+
3.4.5 Document each exception and store it in the company?s audit system<br>
3.2.6 Use the ticketing system or change management system to resolve the patch management issues
+
3.4.6 Create an appropriate policy<br>
3.2.7 Always assign these tickets
+
3.4.7 Communicate this policy to all employees<br>
3.2.8 Include responsible, accountable, stakeholders, and who needs to be informed on unresolved issues
+
3.4.8 Have vulnerability exception solicitors asking the executive authority for an approval every time<br>
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
 

Revision as of 04:21, 24 September 2018

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