Vulnerability Tracking

During the development cycle, vulnerabilities are handled as bugs. May have a dedicated security team or not.

When software is available, vulnerabilities are also tracked globally. For every system and software publicly available.

Public tracking helps with:

  • focusing the discussion around the same issue.

    • e.g. a library that is used in multiple applications, and distributions.

  • defenders to easily test their systems, enhancing security.

  • attackers to easily know what vulnerability can be used.

Vulnerabilities are privately tracked.

  • Constitute an arsenal for future attacks against targets.

  • Exploits are weapons.

Knowledge about vulnerabilities and exploits is publicly traded.

  • From 0 to 2-3M€ (more?) through direct markets or acquisition programs.

  • Up to 2.5M€ for bug hunting programs or direct acquisition (Google, Zerodium).

    • 2.5M€: 1 click Android exploit.

    • 2M€: 1 click iPhone exploit.

    • 1.5M€: WhatsApp or iMessage exploit.

    • ~2K for an XSS at HackerOne (although there are records of $1M payouts).

Privately traded at unknown prices.

Most well-known trackers systems: CVE and NVD.

  • CVE: Common Vulnerabilities and Exposures, managed by MITRE.

  • NVD: National Vulnerability Database, managed by NIST.

Others:

  • CERT Vulnerability Notes Database (VNDB).

    • Maintained by CERTs, may provide additional information regarding a CVE.

  • VulnDB.

    • Focus on APIs and providing information to companies.

  • DISA IAVA and STIGS.

    • Information Assurance Vulnerability Alerts: includes MIL and GOV systems.

    • Security Technical Implementation Guides.

  • Industry Sharing and Analysis Centers (ISAC).

    • Industry-driven, thematic (AUTO, FINANCIAL, IT, etc… groups).

CVE: Common Vulnerabilities and Exposures

Dictionary of publicly known information security vulnerabilities and exposures.

  • For vulnerability management.

  • For patch management.

  • For vulnerability alerting.

  • For intrusion detection.

Uses common identifiers for the same CVEs.

  • Enable data exchange between security products.

  • Provide a baseline index point for evaluating coverage of tools and services.

Details about a vulnerability can be kept private.

  • Part of responsible disclosure: Until the owner provides a fix.

Not an easy task.

  • Exploits are not always known.

  • Impact and Value may be underestimated.

Old feeds may create a false sense of security.

A highly dynamic community is great:

  • To defenders as they can test and implement defenses.

  • To attackers as they can incorporate exploits.

CVSS – Common Vulnerability Scoring System

Provides a quick way to determine the severity of a vulnerability (0-10 score).

  • Helps defenders prioritize the deployment of mitigations.

  • Helps attackers select the most convenient vulnerability to explore.

  • Tends to be pessimistic (higher values).

Example: CVSS 3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N

  • Final Score: 3.1 (LOW)

  • Attack Vector: Network

  • Attack Complexity: Low

  • Privileges Required: High

  • User Interaction: None

  • Scope: Unchanged

  • Confidentiality: Low

  • Integrity: Low

  • Exploit Availability: None

Example: Base Metrics

The Base Score formula depends on sub-formulas for Impact Sub-Score (ISS), Impact, and Exploitability.

Last updated