Vulnerability Evaluation

During both the initial bulk triage phase and the later continuous security phase, an information security professional must evaluate individual vulnerabilities and make decisions.

How to evaluate

  • Criticality and impact - Vulnerabilities that are highly critical and could result in severe consequences should be prioritized
  • Attack vector - Vulnerabilities with a clear and practical attack vector should be prioritised
  • Industry best practices - Stay informed with your industry best practices and compliance standards that are explicitly highlighted by the regulatory bodies
  • Prioritization with other project work - Organizational leaders must agree that vulnerability remediation is as important to the business as other development activities

Vulnerability Assessment and Severity Ratings

Vendor-Specific Vulnerability Ratings

Different vendors may have varying criteria for assessing vulnerability impact. For instance, historically, a "low impact" rating from Red Hat typically indicated that a vulnerability was either unlikely to be exploited or that its exploitation would not likely lead to severe consequences. While specific vendor criteria may evolve over time, the fundamental principles often remain consistent.

National Vulnerability Database (NVD) and Vendor Assessments

The National Vulnerability Database (NVD) maintained by NIST has faced challenges in recent years, including a lack of contextual information and significant backlogs. As a result, many security professionals often prioritize vendor-specific vulnerability assessments. Vendors frequently employ more dedicated researchers than the NVD, potentially allowing for more nuanced and timely vulnerability evaluations.

Mitigation Strategies

For certain types of vulnerabilities, such as those potentially leading to Distributed Denial of Service (DDoS) attacks, implementing rate limiting can often serve as an effective mitigation strategy.

Contextual Nature of Severity Ratings

It's crucial to understand that severity ratings should not be interpreted in isolation. The impact of a vulnerability can vary significantly depending on the specific context of the affected application or system. This contextual nature underscores the importance of human review in the security assessment process.

Example

A potential DDoS vulnerability might have catastrophic implications for a mission-critical or safety-critical system, while its impact on an e-commerce website, though still significant, might be comparatively less severe.

Best Practices for Vulnerability Management

  1. Consider multiple sources when evaluating vulnerabilities, including vendor-specific assessments and broader databases like the NVD.
  2. Understand the specific criteria used by different sources to determine severity ratings.
  3. Always contextualize vulnerability severity within your specific application or system environment.
  4. Implement a robust vulnerability management process that includes both automated tools and human expert review.
  5. Prioritize vulnerabilities based on their potential impact on your specific systems and business operations.

Risk and Confidence

From issue under GitLab UX Research entitled Further understand the job of prioritizing security scan results and assessing their risk

Users want to estimate the potential impact of a vulnerability if it is exploited.

Users want to estimate the likelihood of a particular vulnerability being exploited.

Most organizations have a clear process for assessing the risk of security scan results and prioritizing them alongside other vulnerabilities, even if it's not always formally named.

Risk assessment is more of a top-down process compared to vulnerability management. Risk assessment tries to determine how the organization can be exploited, assess the likelihood of those events happening, estimate the event's impact, and take necessary actions to prevent that exploitation.

The data points that users currently use to estimate the likelihood of exploitation and possible impact are Severity rating, what branch/group/project the vulnerability was in, the title and description of the vulnerability, what type of scanner was used to find that vulnerability, and the CVE number if available.

From survey results:

  • Most (6/8) participants did not look at security scan results outside the default branch.
  • Most (6/8) participants only circumvented their typical workflow if an immediately exploitable vulnerability surfaced.
  • The majority (5/8) of participants did not expect a risk assessment tool to contextualize results to the organization's business needs or infrastructure. But, everyone expressed a desire if a tool could do that.

A business-critical threat is one that: 1. has a high chance of being exploited 1. disrupts the business model in a significant way 1. can extract customer or user data from the organization.

Also see the discussion of "confidence level" as a concept.

Capabilities that help with understanding and prioritizing vulnerabilities