Vulnerability Management — Process Proposal
A defined, auditable path from detection (BSI CERT, NVD, R7/Qualys) to a classified, SLA-timed ServiceNow ticket — written in response to the ISO 27001 audit finding, with a working proof of concept.
Three findings, in the auditor's own terms — each one is a missing link in the same chain, from a signal arriving to a ticket that proves it was handled in time.
R7/Qualys scan results don't reliably produce a ticket. Without a ticket, SLA compliance can't be measured or shown to an auditor.
Onboarding gaps, shallow scan depth on Fortinet devices, and unclear asset assignment mean R7/Qualys can't act as the sole source of truth.
27.4.1 / 27.4.3 / PHB 5.11 require additional sources such as BSI CERT for acute threats — not implemented as a defined process today.
Reactive vs. proactive. A scanner alone is structurally reactive: it only surfaces a CVE once a scan cycle runs and its own signature database has caught up — well documented as weaker for network appliances like Fortinet. The sources below deliberately mix both natures, so acute threats can be identified on the attacker's timeline, not the scanner's.
| Source | Nature | Type | Access | Role in the process |
|---|---|---|---|---|
| R7 / Qualys | Reactive | Vulnerability scanner | existing scan export/API | Primary source for assets inside scan scope. Known gaps: onboarding, Fortinet depth, asset assignment. |
| BSI CERT-Bund | Proactive | Public CERT advisory feed | wid.cert-bund.de — public, no auth | Contractually required secondary source. Catches acute threats independent of scan coverage or timing. |
| CISA KEV | Proactive | Exploitation-confirmed catalog | cisa.gov/.../known_exploited_vulnerabilities.json — public | CVEs CISA confirms are being actively exploited right now — independent of scanner status. The most direct read of "identify acute threats." Forces a severity floor regardless of CVSS (§4). |
| EPSS | Proactive | Predictive scoring API (FIRST.org) | api.first.org/data/v1/epss — public | Daily probability (0–1) a CVE is exploited in the next 30 days — complements CVSS's static severity with a predictive signal. Standard risk-based triage combo alongside CVSS + KEV. |
| Fortinet PSIRT | Proactive | Vendor security advisories | filestore.fortinet.com/fortiguard/rss/ir.xml — public | Vendor-native advisories for FortiGate/FortiSwitch/FortiMail/FortiWeb/FortiSandbox — closes the Fortinet scan-depth gap directly, ahead of a generic scanner signature. |
| NVD | Reference | Public CVE / CVSS database | services.nvd.nist.gov — public API | Authoritative CVSS scoring — classifies severity and normalizes BSI & scanner findings to one baseline. |
| CMDB (ServiceNow) | — | Asset inventory + CIA rating | existing CMDB | Not a threat source — supplies asset context: which CI, and how much it matters. |
Why not a commercial threat-intel platform (e.g. Recorded Future): the same acute-threat signal is already free from CISA and FIRST.org — the same public datasets a commercial platform repackages. That buys convenience, not information otherwise unavailable. Free public sources cover the requirement now; a paid platform is a convenience upgrade to revisit later, not a capability gap.
Every detection is checked against this stack before it becomes a finding — a hit that doesn't apply to anything in the environment doesn't generate noise.
Critical and High are taken directly from the contract as stated by Olivier. Medium and Low are placeholders — stored as editable data, not code, specifically so they can be corrected the moment the full SLA table is available.
| Classification | CVSS range | Response time | Ticket required | Source |
|---|---|---|---|---|
| Critical | 9.0 – 10.0 | 4 hours | Yes | Confirmed |
| High | 7.0 – 8.9 | 1 business day | Yes | Confirmed |
| Medium | 4.0 – 6.9 | 5 business days | To confirm | Placeholder |
| Low | 0.1 – 3.9 | 30 days | To confirm | Placeholder |
Asset-criticality escalation — a finding's SLA can be shortened based on the affected CI's business criticality and CIA rating from the CMDB (e.g. a High finding on a "most critical" asset is treated tighter than a High finding elsewhere). This rule only ever tightens the SLA, never relaxes it.
Proactive-intelligence escalation — same principle, tighten only: a CVE listed in CISA KEV is floored at High (escalated to Critical if tied to ransomware campaigns) regardless of its raw CVSS score; a CVE with an EPSS score above a configurable threshold (default 0.5) is escalated one tier above what CVSS alone would assign. This is what makes the process proactive — a finding can be Critical because it's being exploited right now, independent of whether the scanner has run yet.
Proceeds to classification with full asset context.
Logged & flagged as unassigned — the exact evidence for the "unclear asset assignment" gap.
Mapped to Getronics CSO's actual reporting structure, not a generic MSP template: SOC/SecOps report to the CISO; the engineering teams (Network, OS, DBA, Digital Workplace, Managed Cloud, DevOps) report to the Technical Management Director; both the CISO and the Technical Management Director report to the VP of CSO, alongside the regional CSM managers. The Change Management Team reports to the Global Service Desk Director, but is functionally distinct from Service Desk itself (Incident/Request management only).
| Process step | SOC / SecOps | Technical Management | Change Management | CISO | CSM (regional) |
|---|---|---|---|---|---|
| Monitor detection sources (BSI, KEV, EPSS, Fortinet PSIRT, NVD, scanner) | R | I | – | A | I |
| Correlate finding against CMDB/asset | R | C | – | I | I |
| Classify severity & assign SLA | R | I | – | A | I |
| Open ticket & route to owning team | R | I | – | I | I |
| Remediate | I | RA | C | I | I |
| Verify closure | R | C | – | A | I |
| SLA / audit reporting | R | I | – | A | C |
How to read "Remediate": the owning engineering team under Technical Management (e.g. Network for a firewall CVE) is both the one doing the work (R) and — via the Technical Management Director — accountable for hitting the SLA on their own devices (A). SOC/SecOps hands off the ticket and stays Informed to verify later; they are not the ones patching.
Why Service Desk doesn't appear: vulnerability findings are security-classified and go straight from SOC to the owning Technical Management team — they don't pass through the general Service Desk Incident/Request intake. Change Management is consulted at Remediate only when the fix needs a formal change record (most production patches will).
To move from process-on-paper to something visible, a working PoC implements this flow end-to-end inside Kaligulix's own infrastructure.
"Having something is better than having nothing — and we can start to extend the process going further."
Even before production system access is granted, this process and its PoC already close the audit's core complaint: previously there was no defined trigger from scan/CERT data to a ticket, so compliance couldn't be measured. Now there is a documented, demonstrable path from detection to a classified, SLA-timed, auditable ticket.