Der LogPulse Intelligence Hub erledigt die Vorarbeit zentral: für jede relevante CVE eine getestete Erkennungsregel, eine Mitigation mit klaren Schritten und wiederverwendbare SOAR-Aktionen. Ihre Umgebung macht daraus Arbeit für Ihr Team: ein Ticket, eine Sperre oder ein deaktiviertes Konto und eine Prüfung, ob es tatsächlich geklappt hat.
Die meisten Security-Tools hören beim Alarm auf. Danach muss jemand das Advisory des Herstellers suchen, ein Ticket für das Team schreiben, das das System betreibt, nachfassen und prüfen, ob der Patch wirklich ausgerollt ist. Für eine CVE ist das machbar. Bei Hunderten ausgenutzter Schwachstellen pro Jahr ist genau das die Arbeit, die liegen bleibt.
LogPulse macht diese Nacharbeit zum Teil der Plattform. Das Wissen über eine CVE (wie man sie erkennt, wie man sie behebt und was sich automatisieren lässt) wird einmal im Intelligence Hub aufgebaut, getestet und von einem Menschen geprüft. Danach erreicht es jede Kundenumgebung, für die es gilt. Ihr Team bekommt eine klare Aufgabe statt eines weiteren Alarms, den es deuten muss.
Die Kette
Jeder Schritt baut auf dem vorherigen auf, vom ersten Signal bis zum Nachweis, dass die Schwachstelle weg ist.
Der Hub verfolgt CISA KEV, EPSS und NVD mehrmals täglich und gleicht sie mit Ihren eigenen Schwachstellenscans aus Trivy, Grype oder Snyk ab. So sehen Sie, welche ausgenutzten CVEs auf Ihren Systemen sind.
Für jede relevante CVE erstellen wir eine Erkennungsregel mit Tests. Sie wird erst veröffentlicht, wenn ein Engineer sie geprüft hat und sie einen Angriffsfall und einen harmlosen Fall besteht. Signiert erreicht sie jede Umgebung und achtet auf Ausnutzung.
Jede CVE bekommt eine Mitigation: einen Patch, eine Konfigurationsänderung, einen Workaround oder eine kompensierende Maßnahme, mit den Schritten aus dem Hersteller-Advisory und einer Frist. Nur Umgebungen mit einer betroffenen Version sehen sie.
Eine wiederverwendbare SOAR-Aktion führt die Mitigation aus oder gibt sie weiter: ein Ticket für Ihre IT, eine IP-Sperre am Rand oder ein deaktiviertes Konto. Destruktive Aktionen warten immer auf die Freigabe eines Owners.
Eine CVE gilt erst als mitigiert, wenn ein neuer Scan sie nicht mehr meldet, eine Prüfung in Ihren Logs null ergibt oder die Regel still bleibt. So ist „erledigt“ belegt und nicht nur gemeldet.
Mehr zu den ersten beiden Schritten? Von der CVE zur Erkennung
Fast jede CVE verlangt einen Patch oder eine Konfigurationsänderung am System selbst. Das kann LogPulse nicht für Sie erledigen. Was sich automatisieren lässt, passt auf eine kurze Liste: melden, anreichern, sperren, deaktivieren und isolieren. Diese Aktionen bauen wir einmal, mit Parametern und Grenzen, und verknüpfen sie mit jeder CVE, bei der sie helfen.
Eigene Anbindungen an TOPdesk, Jira Service Management und ServiceNow, wobei der Status zurück an das Notable fließt. Jedes andere ITSM-Tool per E-Mail oder Webhook.
Eine Nachricht per E-Mail, Slack oder Webhook mit der Notable, dem Risikoscore und den Belegen.
Bevor jemand handelt, wird jede Notable mit Threat Feeds abgeglichen und vom AI Investigator untersucht, der seine Begründung festhält.
Senden Sie die Quelladresse per Webhook an Ihre Firewall oder sperren Sie sie in Cloudflare mit dem Managed Template.
Destruktiv: erst nach Freigabe eines Owners
Deaktivieren Sie einen kompromittierten Benutzer in Microsoft Entra ID über Microsoft Graph, mit dem Zielkonto im Audit-Log.
Destruktiv: erst nach Freigabe eines Owners
Einen Rechner über die API Ihres EDR isolieren, als Schritt einer Mitigation.
Destruktiv: erst nach Freigabe eines Owners
Anbindungen
Ein Scanner, der denselben Exploit 400-mal versucht, würde Ihren Servicedesk sonst überfluten. LogPulse erstellt ein Ticket pro CVE und Umgebung und ergänzt jede neue Sichtung als Notiz in diesem Ticket.
Von Ihrer IT geschlossen? Dann prüft LogPulse, ob die CVE verschwunden ist, und öffnet das Ticket mit einer Notiz wieder, falls nicht.
Reaktionen, die sperren oder deaktivieren, müssen zu Ihrer eigenen Change- und Sicherheitsrichtlinie passen. So haben wir das eingerichtet.
Regeln, Mitigationen und Aktionen aus dem Hub werden erst nach Review durch einen LogPulse-Engineer und einem bestandenen Test auf einen Angriffsfall und einen harmlosen Fall veröffentlicht. Ihre Umgebung lädt nur signierte Versionen, es kommt also genau das an, was freigegeben wurde.
Eine IP sperren oder ein Konto deaktivieren ist standardmäßig aus. Schaltet Ihre Organisation es ein, gibt ein Owner jede Aktion einzeln frei. Eine Aktion läuft höchstens einmal und nie ohne diese Freigabe.
Für jede Aktion halten wir fest, wer sie angefordert und wer sie freigegeben hat, wann, auf welches Ziel und mit welchem Ergebnis. So haben Ihr Auditor und Ihr CISO einen Nachweis für NIS2, ISO 27001 und interne Kontrollen.
Fügt ein angebundenes System über die API oder den MCP-Server eine Reaktionsaktion oder einen Trigger hinzu, kommt das als Vorschlag an. Aktiv wird er erst nach Freigabe durch jemanden mit der passenden Rolle, sodass keine Automatisierung an Ihrem Change-Prozess vorbei entsteht.
Jede Aktion bekommt einen Testlauf mit einer simulierten Notable. Anbindungen laufen im Testmodus, Sie sehen also die genaue Anfrage und das Ticket, wie Ihr ITSM es erhalten würde, ohne dass etwas hinausgeht.
Ihre eigenen Einstellungen (Parameter, Freigaben und abgeschaltete Schritte) liegen als Schicht über der signierten Basis. Eine neue Version zeigt zuerst den Unterschied und lässt sich zurückrollen, sodass Updates ankommen, ohne Ihre Vorgaben zu überschreiben.
Benachrichtigen, Tickets, eine IP sperren und ein Konto deaktivieren sind mit Action Pipelines, Freigabeschritten, Mitigationen und dem ITSM-Ticket pro CVE in jedem Plan enthalten, auch in Free. Die verwalteten SOAR-Aktionen aus dem Hub, Detection Lab und der Abdeckungsbericht für NIS2 und ISO 27001 sind in Pro (59 € pro Monat) und Business (199 € pro Monat) enthalten.
Größere Organisation oder MSP? Book a demo
Zuletzt aktualisiert: 6. November 2026
Kostenloser Plan, keine Kreditkarte. Verbinden Sie Logs und Scans und sehen Sie heute, welche CVEs Sie betreffen.