Der Bericht liegt seit drei Wochen im Ablageordner, und die Firma steht genau dort, wo sie vorher stand. Das ist nach einem Security Assessment der Normalfall, und es liegt selten am Bericht.
Ein Assessment liefert Findings. Ein Massnahmenplan IT-Sicherheit entsteht daraus nicht von selbst, weil die beiden Dokumente verschiedene Fragen beantworten. Der Bericht sagt, was bei euch nicht in Ordnung ist. Der Plan sagt, wer bis wann was tut, und was ihr bewusst offen lässt. Der zweite Teil ist der unbequeme, und er ist der Grund, warum Berichte liegen bleiben.
Warum die Spalte «kritisch» nicht deine Prioritätenliste ist
Die Schweregrade in einem Prüferbericht kommen in den meisten Fällen aus dem CVSS, dem Common Vulnerability Scoring System. Das ist ein brauchbares System, es beantwortet nur eine andere Frage als deine. FIRST, die Organisation hinter dem Standard, schreibt in der Spezifikation zu CVSS 4.0: «The Base Score reflects the severity of a vulnerability according to its intrinsic characteristics which are constant over time.» Der Wert beschreibt die Schwachstelle an sich, unabhängig davon, wo sie steht.
Deshalb steht im selben Dokument der Hinweis, dass die Arbeit beim Empfänger weitergeht: «Consumers of CVSS should enrich the Base metrics with Threat and Environmental metric values specific to their use of the vulnerable system to produce a score that provides a more comprehensive input to risk assessment specific to their organization.» Und FIRST zählt auf, was ausserhalb des eigenen Bewertungsrahmens liegt: regulatorische Anforderungen, Zahl der betroffenen Kunden, finanzielle Verluste, Gefahr für Leben oder Sachwerte, Rufschaden. Diese Faktoren seien «outside the scope of CVSS».
Übersetzt heisst das: Die Zahl im Bericht ist die Einschätzung von draussen. Was sie für euch bedeutet, entscheidet sich an eurem Geschäft, und dieser Teil steht nirgends im Dokument.
Wir sehen das Muster in Assessments regelmässig. Ein Finding mit hohem Schweregrad sitzt auf einem Testsystem, auf dem keine Kundendaten liegen und das zwei Personen kennen. Ein Finding mit mittlerem Schweregrad sitzt auf dem einen Server, auf dem die Auftragsabwicklung läuft. Wer die Liste von oben nach unten abarbeitet, beginnt beim Testsystem. Das ist kein Fehler der Prüfenden. Es ist der Punkt, an dem der Bericht endet und deine Arbeit anfängt. Mehr dazu, was ein Security Assessment leistet und was nicht.
Die drei Fragen, die aus Findings einen Plan machen
Du brauchst keine Methodik mit Namen. Du brauchst drei Durchgänge durch dieselbe Liste.
Was stoppt den Betrieb?
Geh die Findings durch und frag bei jedem, was passiert, wenn dieses System einen Tag still steht oder seine Daten abfliessen. Nicht theoretisch. In euren Begriffen: Können wir noch liefern und verrechnen. Alles, was hier ein klares Nein erzeugt, gehört nach vorne, auch wenn im Bericht «mittel» steht.
Welche eine Änderung erledigt mehrere Zeilen?
In jedem Bericht, den wir sehen, hängen Findings in Gruppen zusammen. Zu weite Berechtigungen erzeugen ein halbes Dutzend Findings an verschiedenen Stellen. Fehlende Mehrfaktor-Anmeldung taucht bei Fernzugriff, Postfächern und Verwaltungskonten dreimal auf. Wenn du eine Sache sauber löst, fallen mehrere Zeilen weg. Das ist der billigste Fortschritt, den der Plan zu bieten hat, und in der Liste ist er nicht sichtbar, weil Berichte nach Systemen sortiert sind und nicht nach Ursachen.
Der häufigste Fall dieser Art sind Berechtigungsgruppen, in denen über die Jahre alle gelandet sind, die einmal Zugriff gebraucht haben. Solche Gruppen produzieren Findings in der Dateiablage und in den Fachanwendungen gleichzeitig. Eine Durchsicht der Mitgliedschaften räumt deshalb mehrere Zeilen auf einmal ab, und sie kostet Arbeitszeit statt Lizenzen. Im Bericht steht sie trotzdem als drei oder vier getrennte Findings, weil die Prüfung pro System schaut.
Was kostet nur einen Entscheid?
Ein Teil der Findings lässt sich mit einer Festlegung erledigen: eine Einstellung, die in der bestehenden Lizenz schon enthalten ist, ein Konto, das niemand mehr braucht, eine Regel, die bisher nicht aufgeschrieben war. In unserer Erfahrung ist dieser Stapel grösser, als die Geschäftsleitung erwartet, und er ist der Grund, warum ein Massnahmenplan IT-Sicherheit nicht automatisch ein Investitionsantrag ist.
Drei Durchgänge, und aus der Liste wird eine Reihenfolge. Was dann noch übrig bleibt, kostet Geld oder Zeit, und darüber kann die Geschäftsleitung sauber entscheiden.
Wie ein Massnahmenplan IT-Sicherheit die dritte Woche übersteht
Ein Plan, der liegen bleibt, sieht fast immer gleich aus: eine Tabelle mit mehreren Dutzend Zeilen, in der als Verantwortliche überall «IT» steht und als Termin «laufend». Beides ist keine Zuordnung, sondern eine höfliche Form von niemand und irgendwann.
Fünf Angaben pro Zeile reichen, und keine davon ist optional:
- die Massnahme in einem Satz, in der Sprache der Umsetzenden
- eine Person mit Namen, nicht eine Abteilung
- ein Datum
- die erwartete Wirkung, also welche Findings damit erledigt sind
- der Entscheid: umsetzen, verschieben mit Begründung, oder bewusst akzeptieren
Die letzte Spalte verändert am meisten. Ein Massnahmenplan ohne akzeptierte Restrisiken ist eine Wunschliste, denn kaum jemand arbeitet eine Liste dieser Länge ganz ab. Wenn ihr dagegen festhaltet, dass ihr drei Findings dieses Jahr nicht anfasst, weil das betroffene System im Sommer ersetzt wird, dann ist das eine Entscheidung mit Datum und Begründung. Die hält im Audit, und sie hält gegenüber dem Verwaltungsrat, der im Ernstfall belegen muss, dass er die Risiken kannte und bewusst entschieden hat.
Dazu gehört ein Rhythmus. Eine halbe Stunde im Monat, in der jemand die Zeilen durchgeht und drei Fragen stellt: erledigt, blockiert, oder nicht mehr relevant. Kein Projektbüro, kein Statusbericht an drei Verteiler. In unserer Erfahrung entscheidet dieser Monatstermin mehr über das Ergebnis als die Qualität des Berichts, mit dem alles angefangen hat.
Eine Sache gehört geklärt, bevor der Plan verteilt wird: Welche Zeilen entscheidet die IT selbst, und welche brauchen die Geschäftsleitung? Alles, was Geld, Arbeitsabläufe oder Zusagen an Kunden berührt, ist keine IT-Entscheidung, auch wenn es technisch klingt. Wird diese Grenze nicht gezogen, bleiben genau die wirksamen Massnahmen hängen. Die umsetzende Person hat die Zustimmung nicht, fragt aber auch nicht nach, weil die Zeile ja ihr zugeordnet ist.
Wie lange darf die Umsetzung dauern?
Ein Massnahmenplan IT-Sicherheit läuft in unseren Mandaten über ein Jahr. Was den Betrieb stoppen kann, geht in die ersten drei Monate. Die Gruppenlösungen, die mehrere Findings auf einmal erledigen, bis etwa Mitte Jahr. Alles Weitere bekommt ein Datum oder wird als Restrisiko festgehalten. Wer darüber hinaus plant, plant für eine Umgebung, die es dann nicht mehr gibt.
Wichtiger als die Dauer ist, woran die Termine hängen. Ein Datum, das aus dem Nichts gesetzt wird, verschiebt sich. Ein Datum, das an einer Lizenzverlängerung oder einem Wartungsfenster hängt, hält meist. Darum lohnt es sich, die Massnahmen beim Aufschreiben an Termine zu koppeln, die ohnehin im Kalender stehen.
Ein Bericht, der ein Jahr alt ist, beschreibt eine andere Firma als die heutige. Wenn die Liste nach zwölf Monaten noch halb offen ist, steht zuerst eine Entscheidung an: welche dieser Zeilen überhaupt noch stimmen.
Was im Plan nichts verloren hat
Ein Teil der Arbeit besteht darin, Dinge nicht zu tun. Vier Positionen streichen wir in Mandaten regelmässig.
Ein Werkzeug pro Finding. Der Reflex ist verständlich, weil jede Zeile wie ein Loch aussieht, in das ein Produkt passt. Am Ende stehen sieben Abonnemente da, die sich überlappen und die niemand betreibt. Wie du stattdessen zusammenlegst, steht in unserem Beitrag zum Konsolidieren von Sicherheitstools.
Das Nachaudit, bevor etwas umgesetzt ist. Eine zweite Prüfung bestätigt dieselben Findings und kostet dasselbe nochmal. Der richtige Zeitpunkt dafür liegt nach der Umsetzung.
Findings aus Systemen, die ihr ohnehin ablegt. Wenn die Ablaufplanung steht, gehört das in die Spalte «bewusst akzeptiert» und nicht in die Umsetzung.
Die Jagd nach Vollständigkeit. Ein Prüfbericht ist eine Momentaufnahme und kein vollständiges Bild eures Betriebs. Was uns bei Prüfungen praktisch immer begegnet, haben wir in was wir bei jedem IT-Audit finden gesammelt. Diese Findings zuerst zu lösen, bringt mehr als die Suche nach dem letzten Eintrag in der Liste.
Wenn du beim Lesen merkst, dass euer Bericht nie in eine Reihenfolge gebracht wurde: dieser Schritt gehört bei uns zum Security Assessment mit Umsetzungsbegleitung. Der Bericht ist der kleinere Teil der Arbeit.
Der nächste Freitagnachmittag
Nimm den Bericht, der bei euch liegt, und eine Stunde Zeit. Geh die Findings einmal nach der Frage durch, was den Betrieb stoppt, und markier die fünf, bei denen die Antwort unangenehm ist. Mehr als fünf Zeilen braucht ein erster Massnahmenplan IT-Sicherheit nicht. Schreib hinter jede einen Namen und ein Datum, und notier darunter, was ihr dieses Jahr bewusst liegen lässt.
Das ist in einer Stunde erledigt und bringt euch weiter als die vollständige Liste, die niemand anfasst.
Bleibt eine Frage, die wir selbst oft erst im zweiten Gespräch sauber beantworten können: Wer in deiner Firma darf eigentlich entscheiden, dass ein Risiko offen bleibt? Wenn du dir bei der Antwort nicht sicher bist, ist das die Lücke, nicht die Technik.
Wenn du einen vorhandenen Bericht in eine belastbare Reihenfolge bringen willst, sprich mit uns. Ein erstes Gespräch ist unverbindlich.
Häufige Fragen
Wie priorisiere ich die Findings aus einem Security Assessment?
Nicht nach der Schwere-Spalte. Geh die Liste dreimal durch: Was stoppt den Betrieb, wenn es ausfällt oder abfliesst? Welche eine Änderung erledigt mehrere Findings auf einmal? Was lässt sich mit einem Entscheid statt mit Budget erledigen? Aus diesen drei Durchgängen entsteht die Reihenfolge.
Was gehört in einen Massnahmenplan IT-Sicherheit?
Pro Zeile fünf Angaben: die Massnahme in einem Satz, eine Person mit Namen statt einer Abteilung, ein Datum, die erwartete Wirkung mit den Findings, die damit erledigt sind, und der Entscheid. Umsetzen, verschieben mit Begründung oder bewusst als Restrisiko akzeptieren.
Wie lange darf die Umsetzung nach einem Assessment dauern?
Ein Jahr ist in unseren Mandaten der Rahmen. Was den Betrieb stoppen kann, geht in die ersten drei Monate, Gruppenlösungen bis etwa Mitte Jahr, der Rest bekommt ein Datum oder wird als Restrisiko festgehalten. Termine halten besser, wenn sie an Lizenzverlängerungen oder Wartungsfenster gekoppelt sind.
