Von der Schwachstelle zum Ticket: ein einfacher Mitigation-Workflow

Einleitung

Der Scanner hat 300 Findings geliefert. Jetzt was? Die größte Schwäche im Schwachstellenmanagement ist nicht das Scannen – das ist der einfache Teil. Die echte Herausforderung ist das, was danach passiert: Priorisieren, zuweisen, verfolgen, abschließen. Ohne einen klaren Workflow verschwinden Findings in Excel-Tabellen, werden nie zugewiesen, und sechs Monate später zeigt der nächste Scan exakt dieselben Ergebnisse. Dieser Artikel beschreibt einen schlanken, praxistauglichen Workflow von der Schwachstelle bis zum geschlossenen Ticket – umsetzbar auch ohne dediziertes Security-Team.

Warum das Thema wichtig ist

Vulnerability-Management ohne Remediation-Tracking ist Security-Theater: du weißt, dass du Löcher hast, tust aber systematisch nichts dagegen. Angreifer kaufen Scan-Ergebnisse aus Darknet-Quellen oder scannen selbst – und nutzen exakt die Schwachstellen, die du seit Monaten kennst, aber nie gepatcht hast. Studien zeigen, dass über 60 % der erfolgreichen Kompromittierungen auf Schwachstellen basieren, für die seit mehr als 30 Tagen ein Patch verfügbar war. Das ist kein Technologie-, sondern ein Prozess-Problem. Ein simpler Ticket-Workflow ändert das.

Überblick: Der Workflow in fünf Phasen

Scan → Triage → Ticket → Track → Close

Phase 1 – Scan

Schwachstellenscanner (OpenVAS/Greenbone, Nessus Essentials, Nuclei) liefern Rohdaten: CVE-Nummer, CVSS-Score, betroffener Host, Beschreibung, Lösung.

Wichtig: Scan-Ergebnisse immer mit konkreten Asset-Daten verknüpfen. Ein Finding auf 192.168.1.42 nutzt dir wenig, wenn du nicht weißt, welches System das ist. Asset-Register als Voraussetzung (CMDB-Artikel).

Scan-Frequenz für KMU:

Phase 2 – Triage

Nicht jedes Finding braucht ein Ticket. Triage bedeutet: Relevanz und Priorität bewerten.

Priorisierungs-Matrix

CVSS allein reicht nicht – ein CVSS 9.8 auf einem isolierten Test-System, das in 30 Tagen abgeschaltet wird, ist P4. EPSS (Exploitability Prediction Scoring System) gibt an, wie wahrscheinlich eine aktive Exploitation in den nächsten 30 Tagen ist.

Was nicht ins Ticket muss

• Findings auf Assets, die bereits im Decommission-Plan sind (dokumentieren, nicht ticketen)
• False Positives (verifizieren, Ausnahme im Scanner eintragen)
• Theoretische Lücken ohne verfügbaren Exploit auf isolierten Systemen ohne externe Anbindung

Phase 3 – Ticket erstellen

Pflichtfelder je Ticket

Titel:        [CVE-2024-XXXXX] Apache 2.4.51 – RCE via Header Injection
Priority:     P2
Asset:        webserver01.example.com (IP: 10.0.1.15)
CVE:          CVE-2024-XXXXX
CVSS:         9.8 / EPSS: 0.34
Beschreibung: Apache HTTP Server vor 2.4.52 erlaubt RCE über manipulierten
              Hop-by-Hop-Header. Öffentlicher PoC existiert.
Lösung:       apt upgrade apache2 auf >= 2.4.52 ODER WAF-Rule für Header
Deadline:     2026-05-10 (7 Tage)
Owner:        [Name, Team]
Verification: Nachscan mit nuclei -t apache/ nach Patch

Ohne Owner läuft nichts. Jedes Ticket braucht einen konkreten Namen, keinen Team-Pool.

Ticket-System-Optionen für KMU

Idealerweise nutzt du das Tool, das dein Team schon täglich öffnet – ein separates Security-Ticketsystem wird ignoriert.

Automatisierung: OpenVAS → Tickets

Python-Snippet für OpenVAS-XML → Plane-API:

import xml.etree.ElementTree as ET
import requests

def parse_openvas_xml(xml_file):
    tree = ET.parse(xml_file)
    root = tree.getroot()
    findings = []
    for result in root.findall('.//result'):
        cvss = float(result.findtext('.//cvss_base', '0') or '0')
        if cvss < 7.0:
            continue
        findings.append({
            'name': result.findtext('name', ''),
            'host': result.findtext('.//host', ''),
            'cvss': cvss,
            'cve':  result.findtext('.//cve', ''),
            'solution': result.findtext('.//solution', ''),
        })
    return sorted(findings, key=lambda x: x['cvss'], reverse=True)

def create_plane_issue(finding, project_id, api_token):
    priority = 'urgent' if finding['cvss'] >= 9.0 else 'high'
    payload = {
        'name': f"[{finding['cve']}] {finding['name'][:80]} – {finding['host']}",
        'description_html': f"<p><b>Host:</b> {finding['host']}<br>"
                            f"<b>CVSS:</b> {finding['cvss']}<br>"
                            f"<b>Lösung:</b> {finding['solution']}</p>",
        'priority': priority,
    }
    r = requests.post(
        f"https://app.plane.so/api/v1/workspaces/YOUR_SLUG/projects/{project_id}/issues/",
        headers={'X-API-Key': api_token},
        json=payload,
        timeout=10
    )
    r.raise_for_status()
    return r.json()['id']

Das Skript läuft nach jedem Scan, erstellt nur neue P2/P1-Tickets (Duplikate prüfen via CVE+Host-Kombi).

Phase 4 – Tracking

SLA-Monitoring

Weekly-Check: welche Tickets sind überfällig?

# Beispiel für Jira-SLA-Export via REST (PowerShell)
$jiraBase = "https://your-org.atlassian.net"
$auth = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes("user@domain.com:API_TOKEN"))
$headers = @{ Authorization = "Basic $auth"; "Content-Type" = "application/json" }

$jql = 'project = SEC AND status != Done AND due <= "0" AND priority in (Urgent, High)'
$r = Invoke-RestMethod -Uri "$jiraBase/rest/api/3/search?jql=$jql&maxResults=50" -Headers $headers
$r.issues | ForEach-Object {
    [PSCustomObject]@{
        Key      = $_.key
        Title    = $_.fields.summary
        Due      = $_.fields.duedate
        Assignee = $_.fields.assignee.displayName
        DaysOver = ((Get-Date) - [DateTime]$_.fields.duedate).Days
    }
} | Sort-Object DaysOver -Descending | Format-Table

Eskalations-Regeln

Phase 5 – Close & Verification

Kein Ticket schließen ohne Verification-Scan. Ein Patch kann fehlschlagen, falsch ausgerollt sein oder nur einen Teil der betroffenen Systeme treffen.

Verification-Scan: gezielter Scan nur auf den betroffenen Host, nur für die relevante CVE.

# Nuclei-Beispiel: nur CVE-Checks auf Ziel-Host
nuclei -target webserver01.example.com \
  -tags cve2024 \
  -severity critical,high \
  -o verification_$(date +%F).txt

Erst wenn der Scan sauber ist: Ticket schließen, Datum und Scanner-Report im Ticket vermerken.

KPIs: Woran du erkennst, ob der Workflow funktioniert

Die einfachste Metrik zuerst tracken: Anzahl offener P1/P2 über Zeit. Wenn die Kurve sinkt, funktioniert der Workflow.

Stolperfallen

• Alle Findings ticketen: Triage überspringen = 300 Tickets, Team demoralisiert, nichts erledigt
• Kein Owner: „IT-Team“ als Owner bedeutet: niemand
• Deadline ohne Eskalation: Fristen ohne Konsequenz sind Empfehlungen
• Keine Verification: Patches scheitern still. Nachscan ist Pflicht
• Scan ≠ Realität: Scanner kennen nicht alle Assets. Asset-Register als Grundlage
• CVSS als einzige Priorisierung: CVSS 9.8 auf offline-System ist keine Notfall-Maßnahme
• Ticket-System-Wechsel: einmal gewählt, dabei bleiben. Migration kostet mehr als das beste Tool

Praxis-Checkliste

• Scan-Frequenz pro Asset-Klasse definiert und im Kalender eingetragen
• Priorisierungs-Matrix (CVSS + EPSS + Asset-Kritikalität) dokumentiert
• Ticket-Pflichtfelder (CVE, Host, CVSS, Owner, Deadline) definiert
• Ticket-System ausgewählt und mit Team etabliert
• P1/P2-SLAs und Eskalationsregeln dokumentiert
• Weekly SLA-Check eingerichtet (automatisch oder manuell)
• Verification-Scan-Prozess vor Ticket-Schließung verankert
• KPIs (MTTR P1/P2) monatlich getrackt
• OpenVAS/Nuclei → Ticket-Automatisierung aktiv (wenn machbar)
• False-Positive-Ausnahmen im Scanner gepflegt

Fazit

Schwachstellenmanagement endet nicht am Scanner-Output. Ein simpler fünfphasiger Workflow – Scan, Triage, Ticket, Track, Close – verwandelt den CVSS-Zahlenberg in bearbeitbare Aufgaben mit Verantwortlichkeit und Fristen. Der wichtigste Schritt ist Triage: nicht alles ist gleich wichtig, und wer alles ticketet, erledigt nichts. EPSS als zweite Priorisierungsdimension neben CVSS bringt deutlich mehr Signal. Wer diesen Workflow einmal etabliert, merkt nach dem ersten Monat, dass der nächste Scan weniger Findings hat – weil die letzten endlich geschlossen wurden.

Wenn du tiefer einsteigen willst: Im Newsletter zeige ich jeden Monat konkrete Workflow-Vorlagen, Scanner-Integrationen und KPI-Dashboards für KMU. Trag dich ein.