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.