Chapter 53 Quiz: Zero-Day Response & Vulnerability Coordination¶

B — A zero-day is a vulnerability for which no official patch exists at the time of discovery or active exploitation — the defender has zero days of preparation time, creating asymmetry because the attacker has working exploit code while the defender has no vendor-provided fix, must rely on detection engineering, virtual patching, and compensating controls, and cannot simply "patch the problem away"

The "zero-day" label refers to the number of days the vendor has had to produce a patch: zero. This creates a fundamental asymmetry — the attacker has a working exploit, while the defender's normal remediation workflow (scan → prioritize → patch → verify) is broken at the "patch" step because no patch exists. Defenders must fall back to detection engineering (writing behavioral detection rules), virtual patching (WAF/IPS rules that block the exploitation pattern), threat hunting (searching for indicators of prior compromise), and architectural mitigations (network segmentation, least privilege). This is why zero-day readiness programs emphasize these capabilities rather than relying solely on patch management.

B — A CNA is an authorized organization that assigns CVE IDs to vulnerabilities within its defined scope — the multi-tier hierarchy (Root CNAs like MITRE, Top-Level CNAs like major vendors, and regular CNAs) matters because it distributes assignment authority, reduces bottlenecks, ensures vulnerabilities in vendor-specific products are assigned by the most knowledgeable party, and enables faster CVE publication without overwhelming a single central authority

The CNA program has evolved from a single assigner (MITRE) to a federated model with 300+ CNAs. Root CNAs (MITRE, CISA) manage the overall program. Top-Level CNAs (Microsoft, Google, Red Hat) assign CVEs for their own products and can recruit sub-CNAs. Regular CNAs assign CVEs within their scope. This hierarchy means a vulnerability in Microsoft Exchange gets a CVE from Microsoft's CNA (who understands the product best), not from MITRE (who would need to triage it from scratch). The result is faster, more accurate CVE assignment at scale.

B — CVSS v4.0 replaced the single composite score with a multi-metric-group architecture — Base, Threat, Environmental, and Supplemental groups — where the Threat group replaces the old Temporal metrics with real-time exploitability data (Exploit Maturity), the Environmental group allows organizations to customize scores based on their specific deployment context, and the Supplemental group adds non-scoring metadata (Automatable, Recovery, Provider Urgency), producing more context-specific scores that reduce the "everything is Critical" fatigue of CVSS v3.1

CVSS v3.1's biggest problem was that too many vulnerabilities scored 9.0+ without considering whether exploitation was feasible in a given environment. CVSS v4.0 addresses this through: (1) the Threat group's Exploit Maturity metric replaces the unreliable Temporal metrics — it captures whether an exploit is theoretical, proof-of-concept, or actively weaponized; (2) the Environmental group lets organizations apply Modified metrics and Security Requirements to produce organization-specific scores; (3) the Supplemental group adds Provider Urgency and Automatable — a vulnerability that is automatable (no human interaction required for exploitation at scale) is fundamentally more dangerous than one requiring targeted social engineering. Together, these groups enable four scoring combinations: CVSS-B (Base only), CVSS-BT (Base+Threat), CVSS-BE (Base+Environmental), CVSS-BTE (all three).

B — EPSS answers "How LIKELY is exploitation?" while CVSS answers "How SEVERE would exploitation be?" — the optimal approach combines both: a vulnerability with CVSS 9.8 but EPSS 0.01 (1% chance of exploitation) may be deprioritized below a vulnerability with CVSS 7.5 but EPSS 0.85 (85% chance) — organizations should plot vulnerabilities on a CVSS-severity × EPSS-likelihood matrix and prioritize the upper-right quadrant (high severity AND high likelihood) first

EPSS uses machine learning trained on real-world exploitation data to predict the probability of exploitation within 30 days. CVSS measures theoretical severity. Neither alone is sufficient: a CVSS 10.0 vulnerability in a rarely-used library with no public exploit (EPSS < 0.01) is less urgent than a CVSS 7.0 vulnerability in Apache with active exploitation (EPSS > 0.90). The two-dimensional matrix approach categorizes vulnerabilities into quadrants: Q1 (high CVSS, high EPSS) = patch immediately, Q2 (high CVSS, low EPSS) = schedule patching, Q3 (low CVSS, high EPSS) = investigate and monitor, Q4 (low CVSS, low EPSS) = accept risk or batch patch. This approach has been shown to reduce remediation workload by 60-80% while maintaining equivalent risk reduction.

B — Responsible disclosure gives the vendor exclusive control of timeline, coordinated disclosure sets a mutually agreed deadline (typically 90 days), and full disclosure publishes immediately without vendor notification — a researcher might choose full disclosure when: the vendor has been notified but refuses to acknowledge or patch (vendor silence beyond 90+ days), the vulnerability is already being actively exploited in the wild (defenders need detection information NOW), or the vendor has a pattern of suppressing vulnerability reports and threatening researchers with legal action

The three models represent a spectrum of information control. Responsible disclosure (vendor-controlled timeline) trusts the vendor to act in good faith. Coordinated disclosure (deadline-driven) trusts the vendor but with accountability — if the deadline passes, the researcher publishes regardless. Full disclosure (immediate publication) trusts neither the vendor nor the coordination process. Each has legitimate use cases. Google Project Zero's 90-day policy is coordinated disclosure. When a researcher discovers active exploitation of an unpatched vulnerability, waiting 90 days means defenders are blind while attackers have working exploits — full disclosure of detection guidance (IOCs, behavioral signatures) becomes the ethical choice because it arms defenders immediately.

B — Deploy a layered virtual patching strategy: (1) WAF rules blocking the specific exploitation pattern at the network edge, (2) IPS/IDS signatures for east-west traffic, (3) EDR behavioral rules detecting post-exploitation activity, (4) network segmentation to isolate critical instances, (5) enhanced logging, and (6) threat hunting for prior compromise

Virtual patching is the practice of implementing compensating controls that prevent exploitation of a vulnerability without modifying the vulnerable code itself. The layered approach is critical because: WAF rules block known exploitation patterns at the edge but can be bypassed with encoding variations. IPS signatures catch lateral movement exploitation. EDR behavioral rules detect post-exploitation regardless of how the exploit is delivered (catching the effect rather than the cause). Network segmentation limits blast radius. Enhanced logging ensures forensic visibility. Threat hunting determines if the vulnerability was exploited before the virtual patch was deployed (the "exposure window"). A single layer can be bypassed — defense in depth is the principle. This approach buys time until the vendor releases an official patch.

B — VEX is a machine-readable document that communicates whether a product is affected by a known vulnerability and its exploitation status — it complements SBOMs because an SBOM shows that a product CONTAINS a vulnerable component, but VEX communicates whether the vulnerability is actually EXPLOITABLE in that specific product context

The "vulnerability noise" problem is acute: an SBOM might show that a product includes OpenSSL 3.0.2, which has CVE-2022-XXXXX. But if the product never calls the vulnerable function (X509_verify()), the vulnerability is present but not exploitable. Without VEX, every downstream consumer of that SBOM must independently assess exploitability — multiplying effort across the entire supply chain. VEX provides four status values: not_affected (vulnerability exists in component but is not exploitable in this product), affected (vulnerability is exploitable — action needed), fixed (vulnerability was present but has been remediated), under_investigation (assessment is ongoing). CSAF (Common Security Advisory Framework) is the primary format for distributing VEX data. Together, SBOM + VEX answer the complete question: "What's in my software?" (SBOM) + "Does it matter?" (VEX).

B — Conduct a targeted threat hunt using multiple detection strategies: retrospective IOC sweeps, behavioral post-exploitation detection, memory forensics, network traffic analysis, and file integrity monitoring

Vulnerability scanners detect whether a vulnerability EXISTS — they do not detect whether it was EXPLOITED. Antivirus may not have signatures for a zero-day exploit. SIEM alerts only fire if a detection rule exists for the specific exploitation pattern. A proper threat hunt for zero-day exploitation requires: (1) IOC sweeps — if the advisory includes IOCs (hashes, IPs, domains), sweep historical logs immediately; (2) behavioral detection — the exploit may be novel, but post-exploitation is often reused (LOLBins, reverse shells, credential dumping); (3) memory forensics — fileless exploits leave artifacts in memory (injected DLLs, reflective loading, shellcode); (4) network analysis — C2 traffic patterns persist even if the exploit itself leaves no disk artifacts; (5) file integrity — web shells, modified binaries, new cron jobs. The critical caveat: "we didn't find evidence of exploitation" does not mean "we weren't exploited" — especially for zero-days that may have been used for months before public disclosure.

B — VINCE provides a structured, multi-party collaboration platform that solves the coordination problem of vulnerabilities affecting multiple vendors simultaneously

Multi-party vulnerability disclosure is one of the hardest coordination problems in cybersecurity. When a vulnerability affects a shared library used by 15 different vendors, email-based coordination fails: threads become unmanageable, vendors may accidentally reply-all with confidential patch details, there's no visibility into which vendors have acknowledged the report, embargo dates are communicated inconsistently, and there's no audit trail. VINCE addresses all of these: each vendor gets a private channel with the coordinator and shared channels for group discussion, patch readiness is tracked per-vendor, embargo dates are enforced with automated notifications, and the entire coordination history is preserved. This is critical because a single vendor breaking embargo (releasing a patch early) can trigger a cascade — other vendors' customers are now exposed to a known vulnerability without a patch, and attackers can reverse-engineer the early patch to develop exploits.

B — CSAF is an OASIS open standard (version 2.0) that provides a machine-readable JSON format for security advisories

The current vulnerability advisory ecosystem is fragmented: each vendor publishes advisories in different formats (Microsoft's MSRC uses one format, Apache uses another, Cisco uses another). Security teams must manually parse hundreds of advisory sources, match them against their inventory, and determine impact. CSAF solves this by providing a standardized JSON schema with five document profiles: csaf_base, csaf_security_incident_response, csaf_informational_advisory, csaf_security_advisory, and csaf_vex. The last profile enables machine-generated VEX documents. CSAF 2.0's trusted provider framework allows organizations to subscribe to vendor advisory feeds and automatically process new advisories — matching products against SBOMs, evaluating exploitability, and generating prioritized remediation tickets without human intervention.

B — Use a phased canary deployment with monitoring at each stage, rollback capability, and verification queries

Emergency patching under zero-day pressure creates a tension: every hour unpatched is an hour of exposure, but a botched patch that crashes production causes a different kind of incident. The canary approach resolves this tension. The 5-server canary (1%) catches configuration-specific failures — "does the patch break our custom module?" The 50-server first wave (10%) catches scale-dependent issues — "does the patch cause connection pool exhaustion under load?" Monitoring windows are compressed (30-60 minutes vs. the normal 24-48 hours) to balance speed and safety. Rollback must be available at every stage — either VM snapshots, container image rollback, or package manager downgrade. Verification queries (checking patch version in registry, file hash, or package database) ensure no server was missed. The key metric is "percentage of vulnerable servers patched" reported hourly to leadership until 100% is reached.

B — The percentile ranks a vulnerability against ALL known CVEs — providing relative context that transforms an abstract probability into an actionable comparison

Raw EPSS probabilities are hard to operationalize because the base rate of exploitation is low. An EPSS probability of 0.05 (5%) sounds insignificant, but most CVEs have EPSS scores below 0.01. The percentile contextualizes: "this vulnerability is more likely to be exploited than 90% of all known vulnerabilities." This enables SLA-based policies: 95th+ percentile = patch within 24 hours, 80th-95th = patch within 7 days, 50th-80th = patch within 30 days, below 50th = patch in next maintenance window. EPSS scores are updated daily as new exploitation intelligence becomes available — a vulnerability might jump from the 60th to the 98th percentile when a public exploit is released, automatically escalating its priority.

B — The hardest failure mode is the "weakest link" problem: if any single vendor breaks embargo, attackers can reverse-engineer the patch to develop exploits targeting other vendors' still-unpatched products

Multi-party vulnerability disclosure is an n-party coordination game where failure by any single participant endangers all others. Historical examples of this pattern include the Spectre/Meltdown disclosure (Intel, AMD, ARM, every OS vendor), the Log4Shell disclosure (every application using Log4j), and the Heartbleed disclosure (every product using OpenSSL). Coordination challenges include: different vendors have different patch development timelines, some vendors are responsive while others are unresponsive, vendors may be competitors who distrust each other, and the window between "patch developed" and "coordinated disclosure date" creates insider knowledge that could be leaked. CERT/CC's VINCE platform and FIRST's multi-party disclosure guidelines exist specifically to manage this complexity.

B — This is a maximum-urgency vulnerability requiring immediate response

Each signal independently demands attention: CVSS 7.8 (High severity), EPSS 0.92 (99th+ percentile — more likely to be exploited than 99% of all CVEs), CISA KEV (confirmed active exploitation). Together, they represent the highest-priority combination possible. CISA KEV is especially significant because it's evidence-based — vulnerabilities are only added when CISA has confirmed active exploitation in the wild, not based on theoretical risk. Federal agencies are mandated (BOD 22-01) to remediate KEV vulnerabilities within specific timelines, but the intelligence value applies to all organizations: if attackers are actively exploiting this vulnerability in the wild, your organization may be next. The appropriate response is not "plan to patch next Tuesday" but "invoke emergency procedures NOW."

B — Level 1 scrambles reactively; Level 4 has automated identification, pre-built response templates, pre-authorized processes, and regular exercises

The maturity model for zero-day response measures preparedness across multiple dimensions: (1) Asset visibility — can you answer "are we affected?" within minutes (Level 4) or does it take days of manual inventory (Level 1)? (2) Virtual patching — do you have pre-built WAF/IPS templates for common vulnerability classes (Level 4) or must you write rules from scratch during the crisis (Level 1)? (3) Change management — are emergency change windows pre-authorized (Level 4) or must you convene a CAB meeting during the crisis (Level 1)? (4) Detection engineering — do you have a library of behavioral detection queries (Level 4) or start from zero (Level 1)? (5) Communication — are executive templates pre-approved (Level 4) or does legal review add hours of delay (Level 1)? (6) Exercises — does the team practice quarterly (Level 4) or has never rehearsed (Level 1)? The difference between Level 1 and Level 4 is the difference between a fire department that has never trained and one that runs drills every week.