Was sind Informationssicherheitsziele?
Informationssicherheitsziele legen fest, welchen Zustand ein ISMS in einem bestimmten Zeitraum erreichen soll, und machen seine Wirksamkeit damit prüfbar. ISO/IEC 27001:2022 regelt sie in Abschnitt 6.2, zusammen mit der Planung, wie sie erreicht werden. Die Zuordnungstabelle des BSI ordnet Abschnitt 6.2 dem BSI-Standard 200-2, Kapitel 3 zu. Die Ziele leiten sich aus der Informationssicherheitsleitlinie ab.
Wie Ziele in den Aufbau eines ISMS passen, zeigt der Leitfaden ISMS einführen.
Was verlangt Abschnitt 6.2 der ISO 27001?
Abschnitt 6.2 regelt zwei Dinge: die Ziele selbst und die Planung, wie sie erreicht werden. Sein Kerntext stammt aus der harmonisierten Struktur, die ISO für Managementsystemnormen vorgibt. Im Audit achtet ein Auditor vor allem auf drei Punkte:
- Jedes Ziel lässt sich auf die Leitlinie zurückführen und gilt für benannte Funktionen oder Ebenen.
- Für jedes Ziel ist geplant, wie es erreicht und wie die Erreichung bewertet wird.
- Die Ziele sind dokumentiert, den Beteiligten bekannt und auf dem aktuellen Stand.
Ziel, Kennzahl, Maßnahme: drei Ebenen
Ein Ziel beschreibt einen Zustand, eine Kennzahl misst ihn, eine Maßnahme führt ihn herbei. Die Tabelle zeigt die Trennung an einem Beispiel:
| Ebene | Frage | Beispiel |
|---|---|---|
| Ziel | Welcher Zustand soll erreicht werden? | Kritische Systeme sind innerhalb der vereinbarten Wiederanlaufzeit wiederherstellbar |
| Kennzahl | Woran wird das gemessen? | Anteil der kritischen Systeme mit erfolgreich getestetem Wiederanlauf |
| Maßnahme | Was wird dafür getan? | Wiederherstellungstests je System, Behebung der Befunde, Nachtest |
Ohne diese Trennung entstehen zwei Fehlformen. Die erste ist ein Ziel, das in Wahrheit eine Maßnahme ist („Einführung eines SIEM“); die zweite eine Kennzahl ohne Zielzustand („Anzahl der Vorfälle“).
Woraus sollten Informationssicherheitsziele entstehen?
Informationssicherheitsziele sollten eine Herkunft haben, die sich im Audit benennen lässt. Vier Quellen tragen:
- der Risikobehandlungsplan, weil die wesentlichen Risiken die Prioritäten setzen;
- Anforderungen interessierter Parteien, etwa vertraglich zugesagte Wiederanlaufzeiten;
- Feststellungen aus internen Audits, Vorfällen und Übungen;
- Vorhaben mit Sicherheitsbezug, etwa eine Cloud-Migration.
Lässt sich ein Ziel keiner dieser Quellen zuordnen, gehört es nicht in die Liste.
Drei Beispiele mit erkennbarer Herkunft
| Ziel (Beispiel) | Herkunft | Messgröße |
|---|---|---|
| Privilegierte Zugänge sind personenbezogen und nachvollziehbar | Feststellung aus dem internen Audit | Anteil der privilegierten Konten ohne Sammelnutzung |
| Sicherheitsrelevante Schwachstellen werden nach Schweregrad in festgelegten Fristen behandelt | Ergebnis der Risikobehandlung | Zeit bis zur Behebung je Schweregrad |
| Neue Beschäftigte kennen Meldeweg und Leitlinie ab dem ersten Arbeitstag | Vorfall mit organisatorischer Ursache | Anteil der Eintritte mit Unterweisung vor dem Systemzugang |
Ziel- und Ausgangswerte fehlen hier bewusst. Sie sind organisationsspezifisch und aus den eigenen Vorgaben und Risiken herzuleiten.
Messbar, soweit praktikabel: Ausgangswert, Zielwert, Stichtag
Die Messbarkeit gilt nach dem Kerntext nur, soweit sie praktikabel ist. Wo keine Zahl passt, kann die Erreichung auch über eine Reifegradaussage oder das Ergebnis einer Übung festgestellt werden.
Wird eine Zahl gewählt, gehören drei Angaben dazu: Ausgangswert, Zielwert und Stichtag. Fehlt der Ausgangswert, lässt sich am Ende des Zeitraums nicht entscheiden, ob das Ziel erreicht wurde.
Wie werden Ziele auf Funktionen und Ebenen kaskadiert?
Die Pflicht, Ziele auf den relevanten Funktionen und Ebenen festzulegen, verlangt eine Kaskade. Aus Zielen auf Ebene des Managementsystems leiten sich Beiträge der Bereiche ab, die tatsächlich beitragen, etwa IT-Betrieb, Entwicklung, Personal und Einkauf. Eine Kaskade, die jedem Bereich dasselbe Ziel zuweist, erzeugt Aufwand ohne Steuerungswirkung.
Kommunizieren heißt dabei nicht veröffentlichen. Wer zur Zielerreichung beitragen soll, muss seinen Beitrag kennen. Ein Auditor kann dazu etwa einen Verantwortlichen aus dem IT-Betrieb fragen, welches Ziel seinen Bereich betrifft und woran die Erreichung gemessen wird.
Vier Mängel, die im Audit zu Feststellungen führen
Feststellungen entstehen dort, wo eine Anforderung aus Abschnitt 6.2 nicht erfüllt ist:
- Ziele sind seit Jahren unverändert, obwohl sie erreicht oder gegenstandslos sind (Aktualisierung).
- Zu einem Ziel fehlt die Planung oder ihre Bewertung (Planung).
- Die Beteiligten können die Ziele ihres Bereichs nicht benennen (Kommunikation).
- Die Zielerreichung wird berichtet, aber nicht bewertet (Überwachung).
Die Bewertung selbst gehört in die Managementbewertung, in der die oberste Leitung entscheidet, ob das ISMS noch passt und wirkt.
Wie Rizzqo Ziele mit gerechneten Werten unterlegt
Rizzqo rechnet den Erfüllungsgrad je Asset, je Assetkategorie und je Regelwerk aus den abschließend beantworteten Anforderungen. Ein Ziel wie „Bis Jahresende sind alle Cloud-Dienste gegenüber den ISO-27001-Anforderungen vollständig abgedeckt“ hat damit eine Messgröße. Sie ist der Anteil der vollständig abgedeckten Assets dieser Kategorie. Der Wert entsteht aus der Arbeit und wird nicht von Hand gepflegt.
Ein täglicher Snapshot hält diese Werte fest, sodass die Zielerreichung über Monate belegt ist. Offene Anforderungen erscheinen mit der verantwortlichen Person, und die Maßnahmen für ein verfehltes Ziel lassen sich direkt daraus ableiten.