Kritische Sicherheitslücke: in Stunden von der Meldung zur Entscheidung
Das BSI zählt im Lagebericht 2025 im Schnitt 119 neue Schwachstellen pro Tag. Patchen kannst du nicht alle, entscheiden musst du über jede, die euch trifft.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Kurz gesagt
Wenn eine kritische Schwachstelle öffentlich wird, entscheiden die ersten Stunden über zwei Dinge: ob ihr betroffen seid und ob die Lücke bei euch erreichbar und bereits ausgenutzt ist. Die Antwort kommt nicht aus dem CVSS-Wert allein, sondern aus dem eigenen Inventar, dem Katalog bekannter Ausnutzungen der CISA, der Ausnutzungswahrscheinlichkeit nach EPSS und der Frage, ob das System vom Internet erreichbar ist. Daraus folgt eine von drei Entscheidungen: sofort patchen, mit Workaround überbrücken oder begründet zurückstellen, jede mit Nachweis, denn § 30 BSIG verlangt ein belegbares Schwachstellenmanagement.
Stand dieser Seite: 04.10.2026
01 Worum es geht
Die Meldung ist da, und niemand kann sagen, ob es euch betrifft
Freitagnachmittag kommt die Warnung: eine Schwachstelle mit CVSS-Wert 9.8 in einem Produkt, das irgendwo im Haus läuft. Die erste Stunde geht dafür drauf, herauszufinden, wo. Das Inventar nennt den Hersteller, aber nicht die Version. Der Scanner läuft nachts und kennt die neue Lücke noch nicht. Währenddessen fragt die Geschäftsführung, ob man sicher sei, und die ehrliche Antwort lautet, dass man es nicht weiß. Der Preis ist entweder ein Wochenende unnötiger Notfallarbeit oder eine Lücke, die über Wochen offen bleibt.
Das BSI hat im Lagebericht 2025 für den Zeitraum von Juli 2024 bis Juni 2025 im Durchschnitt 119 neue Schwachstellen pro Tag gezählt, ein Anstieg um 24 Prozent gegenüber dem Vorjahr. Kein Team kann diese Menge einzeln bewerten. Wer deshalb nach dem CVSS-Wert sortiert und alles über 9 sofort behandelt, patcht die lauten Fälle und übersieht die Lücke mit dem Wert 7, die seit Tagen in automatisierten Angriffen genutzt wird.
Eine weitere Schwierigkeit kommt nach der Entscheidung. Ein Patch, der eingespielt wurde, muss nachweisbar wirken, eine Ausnahme muss begründet sein, ein Workaround braucht ein Ablaufdatum. § 30 Abs. 2 Nr. 5 BSIG verlangt von besonders wichtigen und wichtigen Einrichtungen Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung einschließlich des Managements und der Offenlegung von Schwachstellen. Ein Ticket mit dem Status „erledigt“ genügt dafür nicht; gefragt ist eine Spur von der Meldung bis zur Verifikation.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
02 Symptom, Ursache, Lösung
Die Befunde, die im Betrieb tatsächlich auftreten
Sechs Lagen decken den größten Teil dessen ab, was bei einer öffentlich gewordenen Schwachstelle schiefgeht. Zu jeder steht hier, woran du sie erkennst, was meist dahintersteckt und in welcher Reihenfolge du vorgehst.
Symptom
Eine kritische Lücke in einem verbreiteten Produkt ist seit Stunden öffentlich, und im Haus kann niemand sagen, ob und wo das Produkt in der betroffenen Version läuft.
Ursache
Das Inventar führt Hersteller, aber keine Versionen, oder es kennt Appliances, Container-Images und eingebettete Bibliotheken nicht. Häufig fehlen auch Testinstallationen und Systeme, die ein Fachbereich selbst betreibt. Der Scanner hilft erst, wenn sein Hersteller eine Erkennung nachgeliefert hat.
Lösung
Prüfe zuerst die Systeme, die aus dem Internet erreichbar sind, mit einem direkten Versionsabruf oder einem gezielten Scan auf das betroffene Produkt. Frage parallel die Eigentümer der Fachanwendungen schriftlich an und setze eine Frist. Halte das Ergebnis je System fest, auch das negative, und trage danach ins Inventar nach, welche Felder gefehlt haben und wer sie künftig pflegt.
Symptom
Das Team arbeitet eine Lücke mit CVSS-Wert 9.8 unter Hochdruck ab, während eine andere mit Wert 7.5 liegen bleibt, obwohl sie im KEV-Katalog steht und ein Exploit öffentlich ist.
Ursache
Die Priorisierung folgt allein dem CVSS-Basiswert. Der beschreibt die Schwere unter ungünstigsten Annahmen, nicht die Wahrscheinlichkeit der Ausnutzung und nicht eure Umgebung. CVSS 4.0 trennt deshalb ausdrücklich zwischen dem Basiswert, dem um Bedrohungsmetriken ergänzten Wert und dem um Umgebungsmetriken ergänzten Wert, aber die meisten Meldungen und Scanner zeigen nur den Basiswert.
Lösung
Ergänze jede Meldung um zwei Angaben, bevor du eine Frist setzt: Steht die Lücke im KEV-Katalog, und wie hoch ist der EPSS-Wert? Ein Eintrag im KEV-Katalog hebt die Lücke unabhängig vom Basiswert in die höchste Stufe. Einen hohen Basiswert ohne Exploit und ohne Erreichbarkeit darfst du dokumentiert in den regulären Zyklus einplanen.
Symptom
Der Hersteller hat einen Patch veröffentlicht, aber das System darf nicht neu gestartet werden, oder der Anbieter der darauf laufenden Fachanwendung hat den Patch noch nicht freigegeben.
Ursache
Die Lücke sitzt in einer Komponente, die ein anderes Produkt mitbringt oder voraussetzt, und die Freigabekette hat zwei Hersteller. Oder das System trägt einen Geschäftsprozess, für den es kein Wartungsfenster außer nachts am Wochenende gibt.
Lösung
Richte einen Workaround ein, der die Angriffsfläche schließt, ohne das System zu verändern: Zugriff auf das Verwaltungsnetz begrenzen, die betroffene Funktion abschalten, eine Regel in der Web Application Firewall oder im Reverse Proxy, verschärfte Überwachung der Protokolle. Dokumentiere den Workaround als befristete Ausnahme mit Unterschrift des Eigentümers und einem Datum, an dem der Patch spätestens eingespielt wird. Fordere die Freigabe beim Anbieter schriftlich an.
Symptom
Die Lücke war laut KEV-Katalog schon ausgenutzt, bevor ihr davon wusstet, und das System war in dieser Zeit aus dem Internet erreichbar.
Ursache
Die Lücke war länger offen, als ihr wusstet. Das ist keine reine Patch-Frage mehr, sondern ein möglicher Sicherheitsvorfall: Ein Angreifer kann die Zeit genutzt haben, um sich einzurichten, und der Patch entfernt ihn nicht wieder.
Lösung
Patchen allein reicht nicht. Prüfe das System und seine Nachbarn auf Spuren einer Kompromittierung: neue Konten, geplante Aufgaben, unbekannte Prozesse, ausgehende Verbindungen, Webshells in Verzeichnissen des Webservers, Protokolleinträge seit dem Tag der Veröffentlichung. Sichere die Protokolle, bevor du patchst. Findest du Hinweise, läuft ab jetzt der Prozess für Sicherheitsvorfälle mit den Meldepflichten nach dem BSI-Gesetz und, bei personenbezogenen Daten, nach der DSGVO. Fehlt im Haus Forensik-Erfahrung, gehört ein externer Dienstleister dazu.
Symptom
Der Patch ist eingespielt, aber der Schwachstellenscanner meldet die Lücke weiterhin, und niemand weiß, ob der Scanner oder der Patch falsch liegt.
Ursache
Scanner erkennen viele Lücken über die Versionsnummer, die ein Dienst meldet. Distributionen spielen Sicherheitskorrekturen aber häufig in ältere Versionsstände zurück, ohne die Nummer zu ändern. Oder der Patch braucht einen Neustart des Dienstes oder eine Konfigurationsänderung, die noch fehlt. Oder eine zweite Instanz des Produkts auf demselben Host wurde nicht gepatcht.
Lösung
Prüfe zuerst, ob der Dienst nach dem Patch neu gestartet wurde und ob die Hersteller-Anleitung weitere Schritte verlangt. Vergleiche dann die Erkennungsmethode des Scanners mit dem tatsächlich installierten Paket. Bei einer Rückportierung dokumentierst du den Befund als falsch positiv mit Beleg und meldest ihn dem Scannerhersteller. Suche schließlich nach weiteren Installationen desselben Produkts auf dem Host, etwa in Containern. Erst dann gilt der Fall als verifiziert.
Symptom
Ein Audit oder die Vorbereitung auf eine Prüfung nach dem BSI-Gesetz verlangt den Nachweis des Schwachstellenmanagements, und es gibt nur geschlossene Tickets ohne Begründung.
Ursache
Die Behandlung lief, aber die Dokumentation beschränkt sich auf den Ticketstatus. Einstufung, Entscheidung und Verifikation sind nicht nachvollziehbar, Ausnahmen wurden mündlich vereinbart. Für § 30 Abs. 2 Nr. 5 BSIG, der das Management und die Offenlegung von Schwachstellen als Maßnahme nennt, fehlt damit der Beleg der Wirksamkeit.
Lösung
Lege im Ticketsystem Pflichtfelder an: Quelle und Datum der Meldung, Ergebnis der Betroffenheitsprüfung, KEV-Status und EPSS-Wert zum Zeitpunkt der Bewertung, Erreichbarkeit, Entscheidung mit Frist, Verantwortlicher, Beleg der Verifikation. Für Ausnahmen kommt ein Freigabefeld des Eigentümers mit Ablaufdatum dazu. Rückwirkend lässt sich das kaum nachziehen; zeige dem Prüfer den neuen Prozess und die ersten vollständigen Fälle.
03 Was du mitnimmst
Was du einrichtest, damit die nächste Meldung abgearbeitet wird statt diskutiert
Sechs Bausteine machen aus der Schwachstellenbehandlung eine Routine. Vier davon sind einmalige Vorarbeit, zwei sind Entscheidungen darüber, wer im Ernstfall das letzte Wort hat.
Von der Meldung zur Entscheidung
- 01 Sind wir betroffen?
- 02 Wird sie ausgenutzt?
- 03 Ist das System erreichbar?
- 04 Patch, Workaround oder Ausnahme
- 05 Verifiziert und dokumentiert
Quellen abonnieren, die Ausnutzung melden, nicht nur Existenz
Der Warn- und Informationsdienst von CERT-Bund liefert deutschsprachige Hinweise mit Einstufung und RSS-Feed. Der Katalog bekannter ausgenutzter Schwachstellen der CISA nimmt eine Lücke nur auf, wenn eine CVE-Nummer vergeben ist, verlässliche Belege für aktive Ausnutzung vorliegen und eine Abhilfe existiert. Die europäische Schwachstellendatenbank EUVD der ENISA führt ein eigenes Dashboard für aktiv ausgenutzte Lücken. Dazu kommen die Sicherheitsmitteilungen der Hersteller, die ihr tatsächlich einsetzt.
Ein Inventar, das die Frage nach der Version in Minuten beantwortet
Betroffenheit klärt sich über Produkt, Version und Konfiguration. Das Inventar muss deshalb Versionen führen, nicht nur Hersteller, und es muss Container-Images, Bibliotheken in eigenen Anwendungen und Appliances einschließen. Scanner, eine Stückliste der Software je Anwendung und ein Werkzeug wie Trivy für Images liefern die Daten; die Eigentümer der Systeme pflegen sie. Bleibt die Betroffenheit länger als eine Stunde unklar, ist das ein Befund gegen das Inventar.
Drei Fragen, die über die Dringlichkeit entscheiden
Erstens: Wird die Lücke ausgenutzt? Antwort aus dem KEV-Katalog und aus EPSS, das die Wahrscheinlichkeit einer Ausnutzung in den nächsten 30 Tagen schätzt. Zweitens: Ist das betroffene System für den Angreifer erreichbar, also aus dem Internet, aus dem Gastnetz oder nur aus einem Verwaltungsnetz mit Mehr-Faktor-Anmeldung? Drittens: Was passiert im schlimmsten Fall? CVSS 4.0 bildet genau diese Ergänzung ab, indem es den Basiswert um Bedrohungs- und Umgebungsmetriken zum Wert CVSS-BTE erweitert.
Patch, Workaround oder begründete Ausnahme, mit festen Fristen
Für jede Kombination aus Ausnutzung und Erreichbarkeit legt ihr vorab eine Frist fest: etwa drei Tage für ausgenutzte Lücken an erreichbaren Systemen, zwei Wochen für ausgenutzte Lücken im Innennetz, den nächsten Wartungszyklus für den Rest. Geht der Patch nicht sofort, tritt ein Workaround an seine Stelle, der die Angriffsfläche schließt, ohne das System zu verändern. Eine Ausnahme ohne Workaround braucht die Unterschrift des Eigentümers und ein Datum zur Neubewertung.
Intern so kommunizieren, dass niemand zweimal fragt
Eine kurze Meldung an Geschäftsführung und Fachbereiche mit vier Angaben beendet die Nachfragen: Was ist betroffen, wird es ausgenutzt, was tun wir bis wann, was müssen die Fachbereiche beitragen, etwa ein Wartungsfenster freigeben. Diese Meldung geht raus, sobald die Betroffenheit geklärt ist, auch wenn die Lösung noch fehlt. Eine Vorlage mit diesen vier Feldern verhindert, dass drei Versionen der Lage im Haus kursieren.
Den Nachweis beim Arbeiten erzeugen, nicht hinterher
Jede Meldung erhält einen Eintrag mit Quelle, Datum des Bekanntwerdens, Ergebnis der Betroffenheitsprüfung, Einstufung mit Begründung, Entscheidung, Verantwortlichem, Frist und dem Beleg der Verifikation, etwa dem Scanergebnis nach dem Patch. Das ist der Nachweis, den ein Auditor nach ISO/IEC 27001 oder eine Prüfung nach § 30 BSIG sehen will. Im Ticketsystem mit Pflichtfeldern kostet er zwei Minuten je Fall, nachträglich zusammengesucht Tage.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
CVSS richtig lesen: Basiswert ist nicht Dringlichkeit
Der CVSS-Wert, den eine Meldung nennt, ist fast immer der Basiswert. Er bewertet die Schwachstelle an sich: Wie wird sie erreicht, braucht sie eine Anmeldung oder eine Benutzeraktion, was kann im schlimmsten Fall passieren. Ob jemand sie ausnutzt und ob das System bei euch erreichbar ist, sagt er nicht.
CVSS 4.0, seit November 2023 der aktuelle Standard der FIRST, macht diese Trennung ausdrücklich. Der Basiswert heißt dort CVSS-B. Wird er um die Bedrohungsmetrik ergänzt, die den Reifegrad eines Exploits erfasst, entsteht CVSS-BT. Kommen Umgebungsmetriken hinzu, die eure Schutzmaßnahmen und die Bedeutung des Systems abbilden, entsteht CVSS-BE oder, mit beidem, CVSS-BTE. Ergänzende Metriken wie Automatisierbarkeit fließen nicht in den Wert ein, helfen aber bei der Entscheidung.
Für die Arbeit heißt das: Der gemeldete Wert ist der Anfang der Bewertung, nicht ihr Ergebnis. Ergänzt um die Frage der Ausnutzung und um die eigene Umgebung wird daraus eine Einstufung, die zu euren Systemen passt und mit Basiswert und Begründung in die Dokumentation gehört. Eine Herabstufung ohne Begründung liest ein Prüfer als Versäumnis.
KEV und EPSS: zwei Quellen für die Frage nach der Ausnutzung
Der Katalog bekannter ausgenutzter Schwachstellen der CISA, kurz KEV, ist eine Liste von Lücken, für die verlässliche Belege einer Ausnutzung vorliegen. Die CISA empfiehlt ausdrücklich allen Organisationen, nicht nur US-Behörden, die Behandlung von KEV-Einträgen als festen Bestandteil ihres Schwachstellenmanagements aufzunehmen.
EPSS, das Exploit Prediction Scoring System der FIRST, geht einen Schritt weiter und schätzt für jede veröffentlichte CVE die Wahrscheinlichkeit, dass sie in den nächsten 30 Tagen ausgenutzt wird, als Wert zwischen 0 und 1 mit einem zugehörigen Perzentil. EPSS ersetzt den KEV-Katalog nicht, sondern ergänzt ihn: KEV sagt, dass eine Ausnutzung bereits stattfindet, EPSS sagt, wie wahrscheinlich sie demnächst ist. Eine Lücke mit hohem EPSS-Wert, die noch nicht im KEV steht, gehört in die zweite Stufe eurer Fristen.
Beide Quellen haben Grenzen. KEV erfasst, was die CISA belegen kann, und hinkt der Realität hinterher. EPSS ist ein Modell und liegt im Einzelfall falsch, besonders bei Nischenprodukten. Und beide sagen nichts über eure Umgebung. Eine weitere Quelle entsteht gerade: Der Cyber Resilience Act verpflichtet Hersteller, aktiv ausgenutzte Schwachstellen zu melden und Sicherheitsupdates bereitzustellen; die eigene Seite zur CRA-Meldepflicht ordnet das ein. Die dritte Frage, die Erreichbarkeit, bleibt trotzdem eure eigene Arbeit: Welche Systeme sind aus dem Internet erreichbar, welche aus Gast- und Partnernetzen, welche nur mit Mehr-Faktor-Anmeldung aus dem Verwaltungsnetz. Diese Liste pflegt niemand für euch.
Fristen, die zu euren Systemen passen
Fristen für die Behebung sollten vor der nächsten Meldung feststehen, sonst werden sie in jeder Lage neu verhandelt. Ein tragfähiges Schema hat drei bis vier Stufen und bildet die Kombination aus Ausnutzung und Erreichbarkeit ab. Lücken im KEV-Katalog an erreichbaren Systemen werden innerhalb weniger Tage geschlossen. Lücken im KEV-Katalog im Innennetz und Lücken mit hohem EPSS-Wert an erreichbaren Systemen bekommen zwei Wochen. Der Rest läuft im regulären Wartungszyklus. Wichtiger als die konkrete Zahl ist, dass sie gilt.
Die CISA hat ihre Vorgaben für US-Bundesbehörden im Jahr 2026 von festen Fristen je CVSS-Wert auf ein Modell umgestellt, das Erreichbarkeit, Ausnutzung, Automatisierbarkeit und Auswirkung kombiniert. Die Entscheidungsmethode SSVC der CISA, die Stakeholder-Specific Vulnerability Categorization, arbeitet mit denselben Fragen und kommt zu vier Ergebnissen von „Beobachten“ bis „Sofort handeln“. Für ein mittelständisches Haus ist das Modell übertragbar: Es braucht keine Behörde, um die eigenen Lücken nach Ausnutzung und Erreichbarkeit zu sortieren.
Fristen gelten auch für Ausnahmen. Ein Workaround ist eine Ausnahme mit Ablaufdatum, eine Risikoakzeptanz ist eine Ausnahme mit Unterschrift und Wiedervorlage. Ein Haus, das seine Ausnahmen kennt, zeigt dem Prüfer bewusste Entscheidungen; eines, dessen Ausnahmen in Postfächern liegen, hat dieselben Lücken ohne Beleg.
Wann aus einer Schwachstelle ein Sicherheitsvorfall wird
Eine Schwachstelle ist eine Möglichkeit, ein Vorfall ist ihre Nutzung. Die Grenze ist überschritten, sobald es Hinweise gibt, dass jemand die Lücke bei euch verwendet hat: ungewöhnliche Anmeldungen, neue Konten, fremde Dateien im Webserver, ausgehende Verbindungen zu unbekannten Zielen. Es genügt auch schlicht die Tatsache, dass die Lücke laut KEV-Katalog ausgenutzt wurde, während euer System erreichbar und ungepatcht war. Dann ist der Patch nur noch ein Teil der Arbeit.
Ab hier gelten andere Regeln. Protokolle werden gesichert, bevor jemand sie durch einen Neustart oder ein Update verändert. Das System wird vom Netz getrennt, nicht ausgeschaltet, damit flüchtige Spuren erhalten bleiben. Fehlt im Haus Erfahrung mit Forensik, ist jetzt der Moment für einen externen Dienstleister, nicht nach drei Tagen eigener Versuche. Und die Meldepflichten setzen ein: nach dem BSI-Gesetz für betroffene Einrichtungen mit kurzen Fristen, nach der DSGVO gegenüber der Aufsichtsbehörde, wenn personenbezogene Daten betroffen sein können.
Diese Grenze ist auch der Grund, warum die Dokumentation von Anfang an mitläuft. Wer im Vorfall nachweisen kann, wann die Lücke bekannt wurde, wann die Betroffenheit festgestellt und wann der Patch oder Workaround gesetzt wurde, hat gegenüber Aufsicht, Versicherung und Kunden eine Grundlage. Schwachstellenmanagement und Vorfallbehandlung sind deshalb keine zwei Prozesse, sondern zwei Stufen desselben.
Dazu passende Kurse
Wer einmal selbst gesehen hat, wie schnell eine erreichbare Lücke mit öffentlichem Exploit fällt, bewertet Meldungen anders; Kurse, in denen du Schwachstellen ausnutzt, um sie richtig zu priorisieren vermitteln genau diese Erfahrung.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
04 Konkrete Kurse
Wo du genau das übst
- Trivy Schulung: Container-Releases automatisiert prüfen
- IT-Sicherheit: (Anti-) Hacking für Admins - Angriffe erkennen und Schutzmaßnahmen verstärken
- Metasploit Einstieg Kompaktkurs
- Exploit Entwicklung und Reverse Engineering
Weitere Kurse aus diesem Bereich
Preise, Orte und Buchung für alle Kurse des Bereichs findest du im Katalog: Alle IT-Security-Schulungen mit Terminen.
Stimmen aus den Kursen
Was Teilnehmende über die Kurse in diesem Bereich sagen
Super Dozent mit vielen Praxisbeispielen so dass ich mich gleich für den folge Kurs interessiere.
Es war eine sehr gute Lernatmosphäre und der Trainer verstand sein Thema sehr gut.
Dank des äusserst kompetenten Trainers war dies ein sehr informativer und förderlicher Kurs.
05 Fragen
Häufige Fragen
Deine Frage ist nicht dabei? Stell sie uns direkt, wir antworten dir persönlich.
Müssen wir jede Lücke mit CVSS-Wert über 9 sofort patchen?
Woher wissen wir, ob eine Lücke ausgenutzt wird?
Was tun wir, wenn der Hersteller noch keinen Patch hat?
Wie dokumentieren wir das so, dass es im Audit hält?
Wann brauchen wir externe Hilfe?
Betrifft uns § 30 BSIG überhaupt?
Passt thematisch dazu
Die Entscheidung, die diese Seite beschreibt, muss irgendwo umgesetzt werden; wie ein Patch-Management für Linux, das den NIS2-Nachweis übersteht aussieht, steht auf der Linux-Seite dazu.
Für die Windows-Seite der Flotte stellt sich seit dem Ende von WSUS die Frage nach dem Werkzeug neu; wie du Windows-Server künftig ohne WSUS patchst, steht auf der eigenen Seite.
Im SAP-System hat die Schwachstellenbehandlung einen eigenen Rhythmus und eigene Werkzeuge; wie du SAP Security Notes vom Patch Day bis in die Produktion bringen kannst, zeigt die SAP-Seite.
Quellen
- CISA, Known Exploited Vulnerabilities Catalog: Aufnahmekriterien und Empfehlung an alle Organisationen
- FIRST, Exploit Prediction Scoring System (EPSS)
- FIRST, Common Vulnerability Scoring System v4.0
- BSI, Die Lage der IT-Sicherheit in Deutschland 2025 (Zusammenfassung)
- § 30 BSIG Risikomanagementmaßnahmen besonders wichtiger Einrichtungen und wichtiger Einrichtungen
- CISA, Stakeholder-Specific Vulnerability Categorization (SSVC)
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem IT-Security-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Angriffe auf bekannte Lücken selbst nachstellen und daraus die Priorisierung lernen
In den Security-Kursen bei cmt nutzt du Schwachstellen in einer eigenen Laborumgebung aus, prüfst Container-Images mit Trivy auf bekannte Lücken und siehst dabei, welche Faktoren eine Lücke wirklich gefährlich machen. Die Trainer kommen aus Betrieb und Penetration Testing.
Verwandte Themen
- Schwachstelle im eigenen Produkt: die CRA-Meldepflicht in 24 Stunden
- EDR oder Antivirus: was auf den Endgeräten heute noch reicht
- SIEM oder XDR: was dein Team wirklich braucht, um Angriffe zu sehen
- WordPress gehackt: Seite bereinigen, Einfallstor schließen, Vertrauen zurückholen