Welche Controls beim Tool-Abbau nicht wegfallen dürfen

6 Min. Lesezeit

Ein typisches Szenario: drei Tools weniger, spürbar geringere Lizenzkosten, ein zufriedenes Controlling. Sechs Wochen später der erste echte Alarm. Ein Dienstkonto rotiert nachts Passwörter, die Bewegung läuft über drei Netzsegmente. Im SIEM fehlen die Firewall-Logs des abgeschalteten Perimeter-Tools. Die Erkennung war da, die Korrelation nicht, weil die Log-Quelle beim Abbau nie in die neue Plattform migriert wurde. Konsolidierung spart Geld. Sie darf aber keine Pflicht-Funktion mitnehmen.

Verwandt:Lieferkettenrisiko ist ein Programm, keine Audit-Liste  /  Warum das ISO-Zertifikat dem BSI allein nicht reicht

Warum der Stack schrumpft und wo die Compliance-Grenze liegt

Was ist Security-Stack-Konsolidierung? Security-Stack-Konsolidierung ist das gezielte Zusammenlegen oder Abschalten von Sicherheitswerkzeugen, um Lizenzkosten, Integrationsaufwand und Alarm-Rauschen zu senken. Mehrere Einzellösungen wandern dabei in eine Plattform, etwa Erkennung und Reaktion in einen kombinierten SIEM- und EDR-Stack.

Der Druck dazu ist real. Viele Sicherheitsteams betreiben über die Jahre einen wachsenden Werkzeug-Zoo, in dem jedes Tool eigene Parser, Schnittstellen und Wartungslast mitbringt. Dazu kommt die Alarm-Ermüdung: Wenn ein Team im Rauschen der Fehlalarme die echten Signale übersieht, ist weniger manchmal mehr Sicherheit. Konsolidierung ist deshalb oft eine vernünftige Entscheidung.

Das Gesetz steht dem nicht im Weg. Paragraf 30 Absatz 1 BSIG verlangt geeignete, verhältnismäßige und wirksame Maßnahmen und nennt die Umsetzungskosten als einen Verhältnismäßigkeitsfaktor unter mehreren, neben Risikoexposition, Größe und möglichem Schaden. Kostendruck ist damit ein zulässiges Argument. Die Grenze verläuft woanders: Absatz 1 verlangt Wirksamkeit, Absatz 2 Nummer 6 verlangt Konzepte und Verfahren zu deren Bewertung. Sparsam sein ist erlaubt. Wer ein Tool abschaltet und die Pflicht-Funktion dahinter verliert, verletzt die Wirksamkeitspflicht.

Ein Control ist eine Funktion, ein Tool ist nur das Vehikel

Der Denkfehler bei fast jeder missglückten Konsolidierung ist derselbe. Man denkt in Produkten, nicht in Funktionen. Ein Control ist eine nachweisbare Fähigkeit, zum Beispiel MFA für privilegierte Konten erzwingen, Logs über einen definierten Zeitraum korrelierbar halten oder ein Backup regelmäßig testweise wiederherstellen. Das Tool ist nur der Träger dieser Fähigkeit. Konsolidierung heißt, die Zahl der Träger zu senken und jede Fähigkeit zu behalten.

Ich habe einmal zwei Schwachstellen-Scanner geerbt, einen streng konfiguriert, einen lax. Aus Kostengründen flog der teurere raus. Er war der strenge. Auf dem Papier lief das Schwachstellen-Management weiter, in der Praxis sank die Abdeckung und die Reaktionsfrist verlängerte sich still. Genau so entsteht eine Lücke: Das Abschalten selbst ist harmlos, die unbemerkte Absenkung der Kontrolltiefe richtet den Schaden an.

Drei Muster tauchen dabei immer wieder auf. Eine Log-Quelle fällt weg, die Erkennungsregel im SIEM bleibt und läuft ins Leere. Ein EDR deckt die Arbeitsplätze ab, aber nach dem Tool-Wechsel bleiben Server oder Linux-Hosts ohne Agent. Oder ein strenges Control wird durch ein laxeres ersetzt, etwa eine bedingte Zugriffssteuerung durch ein simples VPN. In jedem Fall bleibt die Funktion auf der Folie, verschwindet aber aus dem Betrieb.

Zehn Pflicht-Maßnahmen, die kein Lizenzende ersetzt

Paragraf 30 Absatz 2 BSIG listet zehn Mindestmaßnahmen. Sie sind der Prüfstein für jede Abbau-Entscheidung. Die folgende Übersicht übersetzt die wichtigsten in die Betriebssprache und benennt, was beim Tool-Wechsel erhalten bleiben muss.

Zwei Punkte binden diese Tabelle rechtlich. Paragraf 30 Absatz 1 verlangt, die Einhaltung zu dokumentieren. Hängen die Nachweise an einem abgeschalteten Tool, entsteht sofort eine Prüf-Lücke. Für DORA-pflichtige Finanzunternehmen gilt zudem DORA beim IKT-Risikomanagement und der Vorfallmeldung vorrangig vor den einschlägigen BSIG-Pflichten. An diesen Anforderungen ändert eine Konsolidierung nichts, nur an ihrer technischen Umsetzung.

Fünf Fallen, die nach dem Abbau auffliegen

Die Fehler zeigen sich selten sofort. Sie tauchen im nächsten Incident oder im nächsten Audit auf, wenn das Sparprojekt längst als erledigt gilt.

Verwaiste Schnittstellen. Ein Automatisierungs-Playbook ruft die Programmierschnittstelle eines abgeschalteten Tools auf. Die Erkennung läuft, die Reaktion hängt. Der Vorfall verzögert sich genau dort, wo Tempo zählt.

Fehlende Log-Quellen. Firewall, Proxy, Cloud-Protokolle oder Identitäts-Logs werden nach dem Wechsel nicht neu eingebunden. Die Korrelation bricht, ohne dass jemand einen Fehler sieht. Es kommt schlicht nichts mehr an.

Doppelte Controls mit unterschiedlicher Härte. Zwei Wege für dasselbe, einer strenger. Gekündigt wird der teurere, oft ohne die Policy vorher zu migrieren. Zurück bleibt die laxere Variante als neuer Standard.

Nachweise am Tool festgemacht. Export-Berichte, Prüf-Belege und Pentest-Reports verweisen auf alte Produktnamen. Der Prüfer fragt nach der Kontinuität und die Antwort fehlt.

Übersprungene Wirksamkeitsbewertung. Die Konsolidierung wird als Projekt abgehakt, ohne die Wirksamkeit vorher und nachher zu prüfen. Damit fehlt der Beleg, den die Konzepte und Verfahren nach Paragraf 30 Absatz 2 Nummer 6 vorsehen.

Der richtige Weg: Control-Inventar vor Tool-Inventar

Die Reihenfolge entscheidet über das Ergebnis. Wer mit der Lizenzliste beginnt, spart am Control. Wer mit dem Control-Inventar beginnt, spart am Tool. Sechs Schritte halten die Funktion, während das Werkzeug geht.

Erstens: Jede Pflicht-Maßnahme aus Paragraf 30 in operative Funktionen und messbare Kennzahlen übersetzen, etwa Anteil der Assets mit EDR, MFA-Abdeckung der Admin-Konten oder mittlere Zeit bis zur Erkennung. Zweitens: eine Matrix bauen, welches Tool welche Funktion mit welcher Härte für welche Asset-Klasse abdeckt. Drittens: nur Tools zum Abbau freigeben, deren Funktionen im Ziel-System vollständig abgebildet und getestet sind, nicht nur laut Anbieter-Liste vorhanden.

Viertens: für jede Pflicht-Funktion einen Migrationspfad festlegen, von der Log-Weiterleitung über die Erkennungsregeln bis zu den Backup-Jobs, mit einem Rückfallplan. Fünftens: den Wirksamkeitsnachweis führen, mit einer Messung vorher und nachher, einem Restore-Test und einem durchgespielten Incident-Playbook. Sechstens: die Dokumentation auf das Datum der Control-Migration setzen. Maßgeblich ist der Zeitpunkt, an dem die Funktion umgezogen ist, nicht der Tag der Lizenzkündigung. Für kritische Funktionen wie Logging, EDR und Backup lohnt ein Parallelbetrieb von einigen Wochen. Er kostet kurzfristig, verhindert aber die blinde Phase, in der niemand weiß, ob die Erkennung noch greift.

Häufige Fragen

Darf ich unter NIS2 und BSIG Security-Tools zusammenlegen, um Kosten zu sparen?

Ja. Paragraf 30 Absatz 1 BSIG nennt die Umsetzungskosten ausdrücklich als Kriterium der Verhältnismäßigkeit. Die Einsparung rechtfertigt aber keinen Wegfall einer Pflicht-Funktion. Die Maßnahmen müssen wirksam bleiben und die Wirksamkeit muss nachgewiesen werden.

Welche Controls aus Paragraf 30 BSIG sind an ein bestimmtes Tool gebunden?

Keines. Das Gesetz definiert Maßnahmen, keine Produkte. MFA, Logging, Backup und Schwachstellen-Management müssen funktionieren. Ob das über den einen oder anderen Anbieter läuft, ist eine Umsetzungsfrage.

Was passiert mit unseren Prüf-Nachweisen, wenn wir das SIEM oder die GRC-Plattform ablösen?

Die historischen Nachweise gehören archiviert, ab der Konsolidierung entstehen neue Wirksamkeitsnachweise aus dem Ziel-Tool. Eine Lücke in dieser Kette wird bei der Nachweisführung gegenüber der Aufsicht zum Problem.

Gilt DORA statt NIS2, wenn wir ein Finanzunternehmen sind?

Für das Risikomanagement der Informations- und Kommunikationstechnik und die Meldung erheblicher Vorfälle hat DORA als spezielleres Recht Vorrang. Eine Tool-Konsolidierung muss die Anforderungen des IKT-Risikorahmens weiter erfüllen.

Lesetipps der Redaktion

• Lieferkettenrisiko ist ein Programm, keine Audit-Liste
• NIS2 nach der Frist: Jetzt beginnt die BSI-Aufsicht
• NIS2-Compliance im Mittelstand: machbare Schritte, vermeidbare Fehler

Mehr aus dem MBF Media Netzwerk

Bildquelle: KI-generiert (Juli 2026)