Links steht der Schweregrad einer Schwachstelle nach CVSS. In der Mitte steht, wie CrowdStrike sie nach tatsächlicher Ausnutzung einstuft. Rechts steht, was davon auf den betroffenen Systemen wirklich Risiko trägt. Es sind dieselben Befunde, dreimal bewertet.
Von rund 281.000 Befunden bleiben 4.000 mit hohem Risiko. Das ist Faktor 70, und es ist trotzdem kein Wochenpensum. Der rote Block rechts wäre maßstäblich kaum sichtbar, und genau darin liegt das Problem: Er verschwindet in der Liste, obwohl er die eigentliche Arbeit ist. Was jetzt noch fehlt, ist die vierte Bewertung: wer das System betreibt, wie erreichbar es ist und wann es überhaupt neu starten darf. Die liefert kein Modul, die entsteht im Betrieb. Genau dort fängt unsere Arbeit an.
Fast jede Umgebung, die wir übernehmen, hat bereits einen Scanner und einen Bericht. Was fehlt, ist die Entscheidung darüber, was diese Woche liegen bleibt.
Falcon Exposure Management ist kein einzelnes Werkzeug, sondern sechs Bausteine auf demselben Sensor, der ohnehin auf Ihren Systemen läuft. Kein zweiter Agent, kein Scanfenster, keine zusätzliche Konsole.
Die meisten Umgebungen steigen bei Stufe eins ein und entscheiden danach, wie viel sie selbst übernehmen. Jede Stufe funktioniert auch ohne die folgende.
Schwachstellenmanagement ist kein Projekt mit Enddatum, sondern ein Zyklus. Er funktioniert nur, wenn ihn jemand führt.
Die meisten Umgebungen, die wir übernehmen, haben Nessus, Qualys oder Tenable im Einsatz. Der Wechsel ist unspektakulär, wenn man drei Dinge vorher klärt.
Schwachstellenmanagement grenzt an vier Leistungen, die häufig damit verwechselt werden. Die Trennlinie ist jeweils einfach.
Welcher passt, hängt davon ab, ob Falcon bei Ihnen schon läuft.
Nein. Die Erhebung läuft über den Falcon-Sensor, der ohnehin auf dem System installiert ist. Es gibt kein Scanfenster, keine Anmeldedaten für Scan-Konten und keine zusätzliche Last im Netz. Für Geräte ohne Sensor, etwa Drucker oder Netzwerktechnik, gibt es innerhalb des Moduls einen netzbasierten Scan, der von einem vorhandenen Falcon-System aus arbeitet.
CVSS beschreibt, wie schwerwiegend eine Schwachstelle theoretisch ist. ExPRT.AI bewertet zusätzlich, ob sie in der Praxis ausgenutzt wird: ob es fertigen Angriffscode gibt, ob Angreifergruppen sie einsetzen und wie sich das über die Zeit entwickelt. Die Einstufung ändert sich deshalb, ohne dass sich an der Schwachstelle selbst etwas ändert. Der als kritisch geführte Anteil schrumpft dabei in der Regel deutlich.
Das hängt daran, wo Ihr Aufwand liegt. Wenn Sie am Scannen scheitern, also an Scanfenstern, Anmeldedaten und nicht erreichbaren Systemen, ist der Gewinn groß. Wenn Sie am Abarbeiten scheitern, löst ein Werkzeugwechsel allein nichts, dann ist der Prozess das Thema. Wir sagen das im Erstgespräch, auch wenn die Antwort gegen einen Wechsel spricht.
Ja, auf zwei Wegen. Falcon Discover erkennt Geräte, die im Netz auftauchen, aber keinen Sensor tragen. Falcon Surface findet, was von außen aus dem Internet erreichbar ist, auch dann, wenn es nie in einer Inventarliste stand. Beides zusammen deckt in der Praxis genau den Teil des Bestands auf, den niemand auf dem Schirm hatte.
Nein. Wir treiben den Prozess, prüfen die Schließung nach und automatisieren den Weg dorthin. Die Änderung an Ihren Systemen macht Ihre IT oder Ihr Dienstleister mit dem Werkzeug, das dort ohnehin im Einsatz ist. Diese Trennung ist Absicht: Wer die Liste erstellt und wer sie abarbeitet, sollten nicht dieselben sein.
Das Modul ist an einem Tag aktiv und liefert Daten. Bis daraus ein Prozess wird, den Ihre IT auch trägt, vergehen erfahrungsgemäß sechs bis zehn Wochen. Der größere Teil davon ist Abstimmung mit den Systemverantwortlichen, nicht Technik.
Eine Gegenüberstellung von bekanntem und tatsächlichem Systembestand, eine nach Ausnutzbarkeit sortierte Rangliste statt einer nach Schweregrad, einen Vorschlag für Kritikalitätsmodell und Zuständigkeiten und eine Aufwandsschätzung für die ersten 90 Tage. Zwei Wochen, Festpreis, bei Beauftragung verrechenbar.
Ein technisches Schwachstellenmanagement ist in allen drei Regelwerken gefordert, aber keines davon wird durch ein Werkzeug erfüllt. Verlangt wird der nachweisbare Prozess: dokumentierte Zuständigkeiten, Fristen, ein Verfahren für Ausnahmen und eine Historie. Genau das bauen wir mit auf. Mehr dazu auf unseren Seiten zu NIS2 und DORA.
Die Modullizenz kommt von CrowdStrike und richtet sich nach der Anzahl der Systeme. Unsere Leistung wird nach Umfang kalkuliert, vom einmaligen Exposure Check bis zum laufenden Betrieb. Beides bekommen Sie in einem Angebot, damit Sie dafür nicht zwei Gespräche führen müssen.
