Post

SecConcept - Vulnerability Management

Posted Updated
By Grace L
11 min read

[toc]

Vulnerability Management

Screen Shot 2020-11-11 at 19.33.42

Screen Shot 2020-11-11 at 19.36.07

Screen Shot 2020-11-11 at 19.36.26

I. Foreword

breaking down complex problems into more manageable repeatable parts: detection, reporting, and remediation.

The guide solely focuses on building repeatable processes in cycles.

  • start “small”
  • and incrementally and continuously refine each task and sub-task in the Cycle.

II. Guide

1 Detection Cycle

During the detection cycle, conduct the tasks that support vulnerability tests in essential ways: who, what, where, why, and how.

  • The principal activities are focused on defining and refining the scope after each round of the tricycle, getting tools ready and verifying their integrity, conducting tests, and verifying results.

1.1 Scope : 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
    • a vulnerability management program will require the attention of several departments and multiple stakeholders.
    • Make sure management understands the importance and supports the vulnerability management program. No business leader wants to incur losses.

End Goal: management should give you sign-off on a specific vulnerability test in writing. Ideally, you have to have a vulnerability management policy ready, but that might happen after you complete several rounds of OVMG. By completing the Scope task, you should be able to explain to management and peers why vulnerability testing is needed and how it benefits the business. You should be able to outline the next steps. You also should understand the boundaries of vulnerability tests.

1.2 Tools

  • 1.2.1 Determine the type of test/scan
    • Network scans: credential vs. uncredentialed scans
      • Network scans are suitable for detecting missing patches, misconfigurations, and default credentials on Web servers and network devices. The credentialed scan usually provides more accurate results than non-credentialed. We tend to use non-credentialed scans for scanning assists exposed to the public Internet.
      • Note, when you are rolling out the scans for the first time (and that may include a first time for some group of assets), check a “health” of assets before and after.
    • Applications scans: static code analysis (SAST) vs. dynamic scans (DAST)
      • While SAST analyzes the quality of code, DAST simulates real-world attacks.
      • Note, DAST may cause some damage to the web application and underlying server. It would be wise to avoid running DAST in the production environment.
    • Business email security or Social Engineering (SE) security tests
      • Business email security tests, or phishing tests, are a way to engage the critical thinking of users and prevent click fatigue. SE tests are not very common but found a very effective way to raise self-awareness in employees.
      • Note, retraining should be preceded by formal information security training.
  • 1.2.2 Determine the frequency of security tests
    • The scope should provide the input based on legal, regulatory, and contractual requirements that organization must comply with.
    • The most popular compliance framework for vulnerability management is PCI DSS.
  • 1.2.3 Ensure the latest vulnerability feed
    • Subscribe to “patch Tuesday” emails from all major vendors.
    • Subscribe to the full disclosure database and other feeds where you can track all new CVEs.
    • Ask the tool vendor how long it takes to update vulnerability definitions in their feed; it could be up to 1 or 2 weeks from the patch release.
  • 1.2.4 Check if vulnerability exceptions exist
    • If you inherited the vulnerability scanner tool, make sure that some vulnerabilities are not exempt from showing up on the report.
  • 1.2.5 Test tool for integrity
    • You can scan computer or other devices you are well familiar with and have access to.
    • Cross-reference the output from scanner with what is actually on the device. Does scanner properly fingerprint operating system or enumerate all URLs of a Web application? Were all applications running on device enumerated? Alternatively, you can use the OWASP vulnerable applications to assess if you correctly set up dynamic scanner for application tests. Check out the OWASP Juice shop or the OWASP Mutillidae.
  • 1.2.6 Adjust tools’ settings, preferences, templates
    • Start safe and small, observe results, then increment and observe again.
    • What is different? Does it add any value? Read help and feedback provided by the community around these security testing tools. Ensure that you are not inside own bubble.

End Goal: you should be able to adjust tools to fulfill the scoped objectives.

1.3 Run Tests

  • 1.3.1 Scan public IP addresses
    • Apply a non-credentialed scan, check for default passwords.
    • The goal is to see what an attacker would see.
  • 1.3.2 Scan private subnets
    • Apply credentialed scans using service accounts.
    • Using credential scans increases the rate of accuracy.
    • Consider secure credential handling.
  • 1.3.3 Scan/test web applications
    • Find out how a web application could be exploited. Use a replica of the production for security testing.
  • 1.3.4 Scan/test mobile apps
    • Find out how users may exploit a production app.
  • 1.3.5 Test users (phishing, social engineering training)
    • Users are the most expensive yet prone to SE assets.
    • Use security testing to find out who is likely to click the malicious link or execute a malicious drop.
    • Link the results to retrain users.
    • End Goal: you should be able to run vulnerability tests as planned.

1.4 Confirm Findings

  • 1.4.1 Check if test results have valuable data
    • The scan results could be incomplete, inconclusive, or contradictory. \
    • It may take some settings tweaking to find the right fit for each environment.
    • Be sure to whitelist the IP associated with the scanner on the firewall side.
    • Otherwise, the firewall might filter out any attempts to connect to various ports, meaning you will see all ports closed and no vulnerabilities.
    • It is vital to ensure the integrity of results before you share them with management and teams.
  • 1.4.2 Interpret and reconcile system/device fingerprinting across tests
    • Take time and go through the results, ensuring that device fingerprinting is representative of environment and well defined. You might want to run the discovery scans before you start running vulnerability tests. Rerun the security tests as needed.
  • 1.4.3 Determine that running services are what they are supposed to be
    • It is plausible that the tool may capture as a vulnerability software that is no longer in the system.
    • You want to make sure that you adjust tool settings to be a credible source of vulnerability discovery.
  • 1.4.4 Find something that falls out of the pattern and investigate why
    • You’ll be able to explain something out of ordinary if you spot it first and find a reasonable explanation based on facts (not opinions though). Thus, you’ll learn tool better.
  • 1.4.5 Randomly select vulnerabilities and confirm them with a different tool or manually
    • Every given vulnerability may have a level of certainty and risk.
    • Some vulnerabilities are harder to replicate or prove, and some are harder to exploit.
    • At the end of this exercise, you may improve pen-tester skills and learn something new about a vulnerability that may help to give it a higher or lower priority and improve reporting.

End Goal: understand the security test results; use the collected data to tune the vulnerability scanning tool for precision or have credible evidence that tool doesn’t need some finetuning.

2 Reporting Cycle

The reporting cycle targets activities that help an organization understand vulnerability in a measurable way. The principal activities are focused on learning and categorizing organizational, creating meaningful metrics that would become a cornerstone of vulnerability management reports, and assigning work for remediation.

2.1 Assets Groups

  • 2.1.1 Determine functional asset groups
  • 2.1.2 Determine asset groups by type
  • 2.1.3 Determine asset groups by type of a system
  • 2.1.4 Determine groups by CVE numbering authority or underlying technology
  • 2.1.5 Determine groups by type of vulnerability

End Goal: you should know environment enough to come up with the categories for organizational assets.

2.2 Metrics

  • 2.2.1 Determine the amount and percentage of vulnerable assets
  • 2.2.2 Determine the amount and percentage of vulnerable assets by severity and CVSS
  • 2.2.3 Determine the 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.1.4 Compare and analyze aging data by the 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 enterprise risks and compliance
  • 2.2.6 Determine exploitability of vulnerable assets by severity; specify count, percentage, decrease or

End Goal: you should create (and later revise) metrics for vulnerability reports. The metrics should be consistent and make sense for the audience of reports (management and teams assigned to do remediation work).

2.3 Audit Trail

  • 2.3.1 Use 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 manager/CISO is aware

End Goal: create an audit trail for a remediation workload. Assign work or training to individuals who are responsible for vulnerability remediation (a code rewrite, a configuration fix, e.g.).

2.4 Reports

  • 2.4.1 Maintain a consistent frequency of reporting and use it to track the changes Consistent equals reliable.
  • 2.4.2 Aggregate and process collected data
  • 2.4.3 Using CVSS, apply unique environmental traits to vulnerability analysis
  • 2.4.4 State vulnerability trends
    • different from the last month, week, quarter, year: is it better, is it worse, no change?
  • 2.4.5 Hypothesize about these trends in one sentence
  • 2.4.6 In one paragraph, add recommendations
  • 2.4.7 Apply data sensitivity classification to report
  • 2.4.8 Make a shorter version (1-2 pages) of report
  • 2.4.9 Submit both versions of the report to manager/CISO
  • 2.4.10 Create and maintain 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

End Goal: summarize security scanning results in a concise form that would be easy to understand. Share reports with all who need to know. Keep vulnerability reports consistent in format and delivery.

3 Remediation Cycle

The remediation cycle targets activities that should reduce or eliminate vulnerabilities or provide evidence of why a particular vulnerability is believed not to be a threat. The key activities are focused on defining priorities and terms of remediation work, discussing and documenting false-positives, and dealing with exceptions.

3.1 Prioritize

  • 3.1.1 Use reports
  • 3.1.2 Use 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

End Goal: create a data-based argument for vulnerability prioritization.

3.2 Remediation

  • 3.2.1 Find the stakeholders responsible for remediation work
  • 3.2.2 Communicate findings via the tools and processes they use
  • 3.2.3 Establish a frequency and scope of patching, rewriting code, retraining people
  • 3.2.4 Establish a group of assets dedicated to remediation 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 remediation management issues
  • 3.2.7 Always assign remediation work
    • No assignee or no deadline means audit trail is incomplete.
  • 3.2.8 Include responsible, accountable, stakeholders, and who needs to be informed on unresolved issues
  • 3.2.9 Use the frequency of reporting cycle to follow up on open issues

End Goal: complete vulnerability remediation work. Note, remediation is not to be assumed until retested in detection (1.3 Run Tests). All vulnerability instances that couldn’t be remediated should be identified and documented.

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 a 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

End Goal: establish ground rules of how the vulnerability is evaluated for false positive. Review the evidence on a caseby-case basis. Periodically revise false-positive cases. The process should be transparent and not be abused.

3.4 Exceptions TASK

  • 3.4.1 Find an executive authority to sign off on a cybersecurity 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

End Goal: you must ensure that all non-compliance is approved by senior management and documented in the companywide repository. Vulnerability exception must have an expiration date, after which it should be revised. Vulnerability exception must describe compensating controls that prevent vulnerability exploitation.

roles

Screen Shot 2020-11-11 at 19.42.09

Screen Shot 2020-11-11 at 19.42.32

Screen Shot 2020-11-11 at 19.43.02

Screen Shot 2020-11-11 at 19.43.21

Screen Shot 2020-11-11 at 19.44.06

ref

.

10SecConcept, VulManage
SecConcept
This post is licensed under CC BY 4.0 by the author.

Comments powered by Disqus.