SEC-101 Week 11: Coordinated Vulnerability Disclosure I

The CVD process: CERT/CC's published guide, ISO/IEC 29147 + 30111. CVE numbering authorities (CNAs). CVSS v3.1 scoring breakdown. Lab 8: CVE-record-walk worksheet.

Reading (~45 min)

Read the CERT/CC Coordinated Vulnerability Disclosure Guide executive summary (available at kb.cert.org/vuls/html/coordinator_cvd_guide). This is the practitioner's reference for the disclosure process. Then open the FIRST.org CVSS v3.1 calculator (first.org/cvss/calculator/3.1) and study the metric definitions. You'll use this tool in Lab 8.

Lecture outline (~1.5 hr)

Part 1: What coordinated vulnerability disclosure is (20 min)

Coordinated Vulnerability Disclosure (CVD) is the process by which a security researcher who discovers a vulnerability notifies the affected vendor privately, works with the vendor to develop a fix, and then publishes the details after the vendor has had a reasonable opportunity to patch.

CVD is not the only disclosure model. The alternatives and their trade-offs:

CVD is the industry standard for legitimate security research. Every major certification (ISC2 CC, CompTIA Security+, OSCP, CEH) requires practitioners to attest to a code of conduct that includes responsible disclosure.

Part 2: The CVD process step by step (25 min)

A typical CVD timeline:

1. Discovery: The researcher finds a vulnerability.

2. Reporter notification to vendor: The researcher contacts the vendor's security team. Most major organizations have a published security contact: a security@ email address, a HackerOne or Bugcrowd program, or a .well-known/security.txt file.

3. Vendor acknowledges: The vendor confirms receipt of the report. Good vendors do this within 24-72 hours.

4. Embargo period: Both parties agree on a date by which the vendor will release a patch and the researcher will publish. CERT/CC's default is 45 days; Google Project Zero's is 90 days. The embargo balances vendor fix time against the public's right to know about a risk.

5. CVE assignment: A CVE number is assigned by a CVE Numbering Authority (CNA). The CVE is a unique identifier (CVE-YEAR-NNNN) that all parties use to refer to the same vulnerability. The NVD (National Vulnerability Database) publishes the CVE record with technical details.

6. Patch release: The vendor releases the fix. Users update. Organizations begin their patch deployment cycles.

7. Advisory publication: The researcher publishes their full technical write-up. The advisory includes the CVE number, the technical details, proof-of-concept if applicable, and the disclosure timeline.

8. Post-disclosure: The security community builds detection signatures, updates scanners, and the vulnerability enters the historical record.

When the process breaks:

• The vendor does not respond within the embargo period: the researcher publishes anyway at the deadline (or extends once with notice).
• The vendor disputes the severity and refuses to patch: the researcher publishes, often forcing the vendor's hand.
• The vulnerability is publicly exploited before the patch is released (zero-day in the wild): all parties typically move to immediate disclosure and emergency patching.

Part 3: CVE, CNA, NVD, CISA KEV (20 min)

CVE (Common Vulnerabilities and Exposures):

CVE is a dictionary of publicly-known security vulnerabilities, managed by MITRE under a contract with CISA. Each CVE has a unique identifier, a brief description, and references. The CVE record itself does not score severity; that is done by NVD.

CVE numbers: CVE-2021-44228 is Log4Shell. The year is the year the CVE was assigned (usually the year of disclosure, not necessarily the year the bug was introduced). The numeric suffix is sequential within the year.

CNA (CVE Numbering Authority):

A CNA is an organization authorized by MITRE to assign CVE numbers. There are over 300 CNAs, including major vendors (Microsoft, Google, Apple, Cisco), security researchers (Zero Day Initiative, Project Zero), and national CERTs. If a researcher finds a vulnerability in Microsoft software, Microsoft (a CNA) assigns the CVE number. If the vendor is not a CNA or refuses to participate, CERT/CC or MITRE itself may assign the CVE.

NVD (National Vulnerability Database):

NVD is operated by NIST. It builds on the CVE list by adding CVSS v3.1 scores, CPE (Common Platform Enumeration) entries (which software versions are affected), and CWE (Common Weakness Enumeration) classifications. NVD is the primary reference database for automated patch-management and vulnerability-scanning tools.

CISA KEV (Known Exploited Vulnerabilities catalogue):

CISA maintains a curated list of CVEs that have been observed being actively exploited in the wild. Federal agencies are required to patch KEV entries on specific timelines. KEV is the pragmatic sub-set of NVD that practitioners prioritize: if a vulnerability is on KEV, it is being exploited now and should be patched immediately regardless of CVSS score.

Part 4: CVSS v3.1 scoring (25 min)

CVSS (Common Vulnerability Scoring System) is a framework for scoring the severity of security vulnerabilities. Version 3.1 is the current standard; v4.0 was released in 2023 and adoption is increasing.

Base score metrics (the eight dimensions):

The base score formula combines these into a 0.0-10.0 score. Score ranges: 0.1-3.9 = Low; 4.0-6.9 = Medium; 7.0-8.9 = High; 9.0-10.0 = Critical.

Log4Shell scored:

• AV: Network (N) -- exploitable remotely over any network
• AC: Low (L) -- no special conditions required; any unpatched server is vulnerable
• PR: None (N) -- no credentials required; the JNDI string is in a log message, no authentication needed
• UI: None (N) -- no user interaction required; a single logged request triggers it
• Scope: Changed (C) -- the attacker can affect resources beyond the vulnerable component (code execution on the server)
• C: High (H), I: High (H), A: High (H) -- full compromise

Result: CVSS v3.1 base score 10.0 (Critical).

The FIRST.org calculator walks through each metric with explanatory text. Lab 8 uses it to score a CVE by hand.

Lab exercises (~1.5 hr)

Lab 8: CVE-record-walk worksheet (graded)

See labs/lab-8-cve-walk.md for the full lab.

Pick a CVE from the past 24 months from the NVD search (nvd.nist.gov/vuln/search) that interests you. Trace it through the MITRE CVE record, the NVD entry, the vendor advisory, and at least one independent technical write-up. Score the CVSS v3.1 base score by hand using the FIRST.org calculator. Compare your scored result to the NVD-assigned score.

Independent practice (~5 hr)

• Reading (1 hr): Read the ISO/IEC 29147 standard summary (search "ISO 29147 vulnerability disclosure summary" or read the CERT/CC guide section on ISO standards). ISO 29147 covers what vendors should do when they receive a vulnerability report; ISO 30111 covers the technical handling process internally.
• picoCTF spine (3 hr): Continue in Binary Exploitation or push into any remaining Web Exploitation challenges you haven't completed. If you're ahead, try a challenge in a category you've avoided.
• Capstone preparation (1 hr): Browse the capstone CVE list (Heartbleed, Shellshock, Log4Shell, Spectre/Meltdown, EternalBlue, ImageTragick, Dirty COW, BlueKeep). Pick one that interests you most. Read its Wikipedia article. You will choose your capstone CVE in Week 13.

Reflection prompts

1. The CVSS base score is calculated from eight dimensions, each independently assessed. DREAD (from Week 2) collapsed five dimensions into a single aggregate score. What is the advantage of keeping eight dimensions separate rather than producing one number? What information do you lose when you read only the final score (e.g., "7.5, High") without the individual metric values?

2. The CERT/CC default embargo is 45 days; Google Project Zero's is 90 days. A vendor argues that 90 days is not enough time to patch a critical vulnerability in a widely-deployed product. What factors would you weigh in deciding the right embargo length? Is there an argument for a 180-day embargo?

3. The CISA KEV contains vulnerabilities that are being actively exploited. The NVD contains all CVEs, including those with no known exploitation. A security team with limited patching capacity must prioritize. Make the argument for prioritizing KEV over NVD. Then make the argument against.

Week 11 of 14. Next: CVD II (legal landscape, CFAA, safe-harbour language, codes of professional conduct, ethics reflection).