Pros
- • Shifts focus from passive scanning to active, risk-based remediation
- • Integrates EPSS and threat intelligence to prioritize truly exploitable flaws
- • Establishes clear asset ownership and remediation accountability
- • Implements strict retest discipline to validate patch deployment
- • Provides executive visibility into Mean Time to Remediate (MTTR)
- • Aligns closely with CIS Benchmarks (Control 7) and ISO/IEC 27001
- • Transforms raw scan data into actionable engineering workflows
Cons
- • Heavily dependent on an accurate, constantly updated asset inventory
- • Requires explicit executive support to enforce remediation SLAs
- • Necessitates time-intensive organizational mapping to assign ownership
- • Vulnerability triage requires ongoing manual effort and operational discipline
Generating a 500-page PDF filled with “Critical” and “High” vulnerabilities is not vulnerability management; it is simply vulnerability scanning. Most organizations suffer not from a lack of visibility, but from a severe lack of closure discipline. Security teams throw reports over the fence to IT and engineering, resulting in friction, ignored tickets, and an attack surface that never actually shrinks.
This Vulnerability Management Operating Model bridges the gap between identification and remediation. Drawing heavily on practitioner experience in defensive operations, system hardening, and offensive exploit validation, this service implements a structured framework to prioritize what actually matters, assign it effectively, and prove that the risk was neutralized.
The Lifecycle Phases
A mature operating model breaks the process into a continuous, repeatable lifecycle:
- Asset Inventory & Ownership: Before scanning, every IP address, repository, and cloud instance must map to a specific business owner. If an asset has no owner, it cannot be patched.
- Continuous Scanning: Utilizing authenticated (credentialed) and unauthenticated scans across network infrastructure, endpoints, and cloud environments.
- Validation & Triage: Filtering out scanner false positives. As a practitioner, I manually validate critical findings to confirm exploitability before alarming the engineering team.
- Context-Driven Prioritization: A CVE with a CVSS of 9.8 on an isolated internal test server is lower priority than a CVSS 7.2 on a public-facing API Gateway.
- Assignment & Ticketing: Integrating directly into existing IT workflows (Jira, ServiceNow) so developers work from their native queues, not security spreadsheets.
- Remediation & Exception Handling: Applying patches, compensating controls, or formally documenting risk acceptance for unpatchable legacy systems.
- Retesting: Closing the loop. A ticket is never closed because IT says it’s patched; it is closed when the security scanner or a manual retest verifies the fix.
Context-Driven Prioritization
We abandon the standard “fix all criticals within 30 days” approach, which leads to burnout. Instead, vulnerabilities are prioritized using a matrix of real-world risk:
- CVSS Base Score: The inherent technical severity of the vulnerability.
- EPSS (Exploit Prediction Scoring System): The actual probability that the vulnerability will be exploited in the wild within the next 30 days.
- Exploit Availability: Is there a weaponized exploit module in Metasploit, or is it purely theoretical?
- Asset Criticality & Exposure: Is the asset internet-facing? Does it hold PCI or PII data?
- Compensating Controls: Is the vulnerable service protected behind a properly configured Cloudflare WAF or strictly limited by internal network segmentation?
The Practitioner Tool Stack
We integrate with and optimize your existing tooling, establishing a pipeline from discovery to closure:
- Scanning & Discovery: Nessus, OpenVAS, Nmap, Shodan
- Endpoint Visibility: Wazuh Vulnerability Detection (leveraging existing agent footprint)
- Workflow & Automation: Jira, ServiceNow, GitHub Actions, custom Python API scripts for bulk ticket generation
- Intelligence: CISA KEV (Known Exploited Vulnerabilities) catalog
Remediation SLAs and Risk Acceptance
To establish accountability, the operating model enforces strict Service Level Agreements (SLAs) based on prioritized risk, alongside a formalized exception process.
| Risk Priority | Time to Remediate (SLA) | Characteristics | Exception Authority |
|---|---|---|---|
| P0 (Emergency) | 48 Hours | Internet-facing, active exploit exists (CISA KEV), critical business asset. | CISO / Exec VP |
| P1 (Critical) | 14 Days | High probability of exploitation, internal Tier 0/Tier 1 asset. | InfoSec Director |
| P2 (High) | 30 Days | CVSS 7.0+, moderate exploitability, standard internal assets. | System Owner |
| P3 (Medium) | 90 Days | Theoretical risk, local access required, robust compensating controls. | Automatic/System Owner |
If an SLA cannot be met due to vendor constraints or system fragility, a formal Risk Acceptance/Exception must be filed, detailing the compensating controls and establishing a mandatory review date.
Metrics That Matter
We pivot executive reporting away from “total vulnerabilities found” (a meaningless metric) to operational efficiency metrics:
- Mean Time to Remediate (MTTR): Tracking how fast criticals are patched across different IT teams.
- Patch Compliance Rate: The percentage of assets meeting their established SLAs.
- Critical Exposure Age: The age of the oldest internet-facing critical vulnerability.
- Scan Coverage: The percentage of the known network actually authenticated and scanned.
Deliverables
- The Vulnerability Register: A centralized, prioritized tracking matrix (or Jira board configuration) of all validated findings.
- SLA & Governance Policy: A formalized document outlining patching timelines, roles, and the risk exception process, aligning with ISO/IEC 27001 requirements.
- Remediation Matrix: Developer-friendly, batch-grouped patching instructions (e.g., “Updating this single Apache Tomcat instance resolves 14 distinct CVEs”).
- Retest & Validation Report: Evidence that specific, high-risk vulnerabilities have been eradicated.
- Executive Monthly Dashboard: A concise view of MTTR, risk burn-down, and compliance tracking.
90-Day Implementation Roadmap
- Days 1-30 (Visibility & Alignment): Map the network architecture. Validate asset ownership. Deploy authenticated scanning profiles across 80% of the internal network and 100% of the external perimeter.
- Days 31-60 (Triage & Ticketing Integration): Conduct the first deep-dive vulnerability triage. Filter out false positives. Integrate the vulnerability scanner with Jira/ServiceNow to automate ticket creation for P0 and P1 findings.
- Days 61-90 (Enforcement & Reporting): Begin enforcing SLAs. Institute the Risk Acceptance workflow for legacy systems. Generate the first executive MTTR and Patch Compliance reports.
Vulnerability management is an operational discipline, not a technology problem. By implementing this model, your organization transitions from reacting to PDF reports to systematically hardening your infrastructure against realistic threats.
