IT-Sicherheitscheck nach Vorfall: erst prüfen, dann kaufen

Die Woche nach einem Sicherheitsvorfall ist der schlechteste Zeitpunkt, um Security-Produkte zu kaufen. Genau dann wird am meisten gekauft. Der Druck ist hoch, die Geschäftsleitung will Handlung sehen, und die Anbieter wissen beides. Ein IT-Sicherheitscheck nach dem Vorfall klingt daneben fast provozierend unspektakulär. Über deine Sicherheitskosten der nächsten Jahre entscheidet aber genau dieser Schritt.

Wir werden immer wieder in Unternehmen geholt, bei denen der Vorfall ein paar Wochen zurückliegt. Der Betrieb läuft wieder, die Forensiker sind durch, die Versicherung ist informiert. Auf dem Tisch liegen drei Offerten: eine EDR-Plattform, ein SOC-Service, eine Awareness-Lösung. Die Frage an uns lautet dann selten «Was ist bei uns eigentlich schiefgelaufen?», sondern «Welche der drei sollen wir nehmen?».

Die ehrliche Antwort: vielleicht keine. Noch nicht.

Warum der Kaufreflex zuschlägt, wenn er am teuersten ist

Nach einem Vorfall fühlt sich Kaufen wie Handeln an. Der Verwaltungsrat will zeigen, dass er reagiert hat, auch mit Blick auf seine eigene Verantwortung. Die IT will diesen Zustand nie wieder erleben. Und der Anbieter, der zwei Tage nach dem Vorfall anruft, hat ein Verkaufsargument gratis geliefert bekommen, das kein Prospekt hergibt: eure eigene Erfahrung.

Ein Kauf ist ausserdem bequem. Er ist sichtbar, schnell entschieden, und man kann ihn delegieren. Eine Budgetfreigabe dauert eine Sitzung. Die Frage, warum ein gekündigter Mitarbeiter Monate später noch ein aktives Konto hatte, dauert länger und zeigt auf niemanden, auf den man gerne zeigt.

Das Problem: Die Entscheidung basiert auf dem Schrecken, nicht auf dem Befund. Der Vorfall wird zum Verkaufsargument, statt zur Datenquelle. In unserer Erfahrung entstehen überdimensionierte Security-Stacks genau so, in den Wochen nach einem Vorfall. Drei Jahre später verlängert noch immer jemand Lizenzen, deren einzige Begründung die Panik von damals ist.

Dazu kommt: Die Unternehmen, die es erwischt, sind selten die ohne Sicherheitsprodukte. In unseren Mandaten sehen wir nach Vorfällen regelmässig Umgebungen mit einem halben Dutzend Security-Werkzeugen, von denen jedes einzelne den Angriff theoretisch hätte bemerken können. Sie waren gekauft, installiert und halb konfiguriert. Der Vorfall fand in der Lücke zwischen den Zuständigkeiten statt, nicht in der Lücke im Produktkatalog. Wenn das die Ausgangslage ist, löst ein siebtes Werkzeug das Problem nicht. Es verbreitert es.

Der Vorfall ist der ehrlichste Bericht, den du je bekommst

Ein Vorfall ist der einzige Moment, in dem dir jemand ungeschminkt zeigt, wo dein Unternehmen verwundbar ist. Kein Auditor und kein Fragebogen kommt an diese Information heran: Der Angreifer hat den Weg dokumentiert, den er gegangen ist, unter realen Bedingungen und gegen euren realen Alltag.

Und dieser Weg führt in unserer Erfahrung selten über eine fehlende Technologie. Er führt über Dinge wie diese: das Konto ohne Multi-Faktor-Authentifizierung, das nach einem Austritt aktiv blieb. Die Admin-Rechte, die «vorübergehend» vergeben und nie entzogen wurden. Das Backup, das brav lief, aber dessen Wiederherstellung niemand je geprobt hat. Die Meldung eines aufmerksamen Mitarbeiters, die versandete, weil nicht klar war, wer dafür zuständig ist. Der Fernzugang eines Dienstleisters, den seit Projektende niemand mehr brauchte und den trotzdem niemand geschlossen hat.

Keine dieser Lücken wird durch ein neues Produkt geschlossen. Sie sind organisatorisch: unklare Zuständigkeiten, fehlende Routinen, Konfigurationen, um die sich niemand gekümmert hat. Wer nach dem Vorfall zuerst bestellt, kauft eine Antwort auf eine Frage, die er noch gar nicht gestellt hat.

Mal ehrlich: Dass die Schwachstelle im eigenen Betrieb liegt und nicht im Einkaufskatalog, hört niemand gern. Ein Produkt zu kaufen fühlt sich besser an, als zuzugeben, dass der Offboarding-Prozess seit Jahren auf Zuruf funktioniert. Genau deshalb lohnt es sich, den Befund zu erheben, bevor die Offerten entscheiden, worüber überhaupt gesprochen wird.

Was ein IT-Sicherheitscheck nach dem Vorfall anders macht

Zuerst die Abgrenzung, weil sie oft verwechselt wird. Die Forensik und das Incident Response beantworten die Fragen «Was ist passiert?» und «Ist es vorbei?». Das ist Feuerwehr, und sie muss zuerst kommen. Der IT-Sicherheitscheck beantwortet eine andere Frage: «Warum konnte es passieren, und was heisst das für unsere Prioritäten?» Das ist Baustatik. Beides braucht es, in dieser Reihenfolge, und meist mit unterschiedlichen Leuten: Die Forensik braucht Spezialisten für Spuren, der Check jemanden, der Organisation und Technik zusammen lesen kann. (Wo die Grenze zwischen einem Assessment und einem Pen-Test verläuft, haben wir hier beschrieben.)

Konkret läuft so ein Check nach einem Vorfall in vier Schritten:

1. Vorfallpfad nachvollziehen. Welchen Weg hat der Angriff genommen, Station für Station? An jeder Station steht dieselbe Frage: Welche Kontrolle hat gefehlt, und welche war vorhanden, hat aber nicht gegriffen?
2. Bestand aufnehmen. Was existiert an Tools, Massnahmen und Verträgen, und wie viel davon ist tatsächlich konfiguriert? Ein häufiger Befund aus unseren Mandaten: Die Funktion, die den Vorfall verhindert hätte, war bereits lizenziert. Sie war nur nie aktiviert.
3. Lücken priorisieren. Gewichtet nach dem, was der Vorfall belegt hat, statt nach der Vollständigkeit irgendeines Frameworks. Der Vorfall hat dir die Priorisierung abgenommen, das ist sein einziger Vorteil.
4. Massnahmenplan in Reihenfolge. Erst Konfiguration und Verantwortlichkeiten, dann Prozesse, zuletzt Neukäufe. Falls am Ende tatsächlich ein Produkt fehlt, kaufst du es dann mit einer Begründung, die auch in drei Jahren noch trägt.

Der Vorfallpfad ist dabei der Einstieg, nicht die Grenze. Ein Angriff zeigt dir einen Weg, der funktioniert hat. Ein guter Sicherheitscheck schaut danach auf die Nachbartüren: Wie sauber ist der Lebenszyklus von Konten und Berechtigungen insgesamt? Wurde die Wiederherstellung aus dem Backup je unter realistischen Bedingungen geprobt? Was ist von aussen erreichbar, und weiss das jemand? Und die Frage, die in unserer Erfahrung am meisten auslöst: Wer bemerkt es, wenn morgen etwas Ähnliches über einen anderen Weg beginnt, und wen ruft diese Person an?

So eine Standortbestimmung dauert wenige Wochen. Was sie kostet, haben wir transparent aufgeschrieben. Verglichen mit einer einzigen Panik-Beschaffung ist sie fast immer der kleinere Posten.

Es gibt noch einen Nebeneffekt, der oft unterschätzt wird: Der dokumentierte Befund samt der Entscheidungen, die daraus folgen, ist gleichzeitig euer Sorgfaltsnachweis. Wenn nach dem Vorfall jemand fragt, ob die Geschäftsleitung angemessen reagiert hat, ist «Wir haben strukturiert geprüft, priorisiert und entschieden» eine belastbare Antwort. «Wir haben drei Produkte gekauft» ist keine.

Was das mit deinem Budget macht

Der Sicherheitscheck dreht die übliche Logik nach einem Vorfall um: Erst nutzt du, was du hast. Dann reparierst du, was organisatorisch kaputt ist. Und erst dann kaufst du, was danach noch fehlt.

In unserer Erfahrung endet diese Reihenfolge öfter mit einer kürzeren Tool-Liste als mit einer längeren, bei besserer Abdeckung. Sicherheit verliert dabei nichts, sie gewinnt: Jede Lizenz, die nur wegen der Panik von damals weiterläuft, bindet Geld und Aufmerksamkeit, die an der Schwachstelle fehlen, die der Vorfall belegt hat. Es wäre schade, diese teuer bezahlte Information ungenutzt zu lassen.

Der Effekt zieht sich durch die Folgejahre. Was in der Panikphase gekauft wurde, taucht bei jeder Verlängerung wieder auf, und bei Verlängerungen entscheidet selten jemand aktiv. Der Vertrag läuft weiter, weil Kündigen eine Begründung bräuchte und Weiterlaufen keine. Ein Befund aus einem strukturierten Check ist genau diese Begründung, in beide Richtungen: Er sagt dir, was du behalten und richtig konfigurieren solltest, und er gibt dir die Argumente, um den Rest auslaufen zu lassen.

Wenn es bei euch gerade passiert ist

Drei Dinge, in dieser Reihenfolge:

Parke alle grösseren Kaufentscheide, bis ein Befund vorliegt. Ausgenommen ist, was der Wiederanlauf zwingend braucht. Alles andere kann vier Wochen warten, auch wenn es sich nicht so anfühlt. Die Offerten laufen dir nicht davon, und ein Rabatt, der nur diese Woche gilt, ist ein Verkaufsinstrument, kein Argument. Falls die Geschäftsleitung oder der Verwaltungsrat sofort sichtbare Handlung verlangt: Der Beschluss, strukturiert zu prüfen, mit Termin und Verantwortlichem, ist sichtbare Handlung. Er lässt sich protokollieren und später belegen, was von einer eiligen Bestellung nicht behauptet werden kann.

Dokumentiere den Vorfallpfad, solange die Erinnerung frisch ist. Wer hat was wann bemerkt, welche Systeme waren betroffen, welche Meldung ging an wen, und wo hat es geklemmt. Das ist unspektakuläre Schreibarbeit, aber sie ist die Grundlage für den Sicherheitscheck und für jedes Gespräch danach, mit der Versicherung wie mit der Geschäftsleitung. In drei Monaten ist die Hälfte davon weg, und mit ihr die Chance, aus dem Vorfall mehr zu machen als eine Rechnung.

Setze einen strukturierten IT-Sicherheitscheck an, extern oder intern. Extern hat einen Vorteil, der nichts mit Kompetenz zu tun hat: Wer intern untersucht, untersucht immer auch die eigene Arbeit, und das prägt den Befund. Ein Aussenstehender kann aufschreiben, was er vorfindet, ohne jemandem im Haus etwas schuldig zu sein. Genau solche Checks machen wir als Security Assessment, und ein Erstgespräch dazu ist unverbindlich.

Uns interessiert an den Offerten, die nach einem Vorfall auf dem Tisch liegen, übrigens jeweils dieselbe Sache: Welche davon beantwortet die Frage, warum es passieren konnte?