Informationssicherheitsziele

Informationssicherheitsziele – von den klassischen Schutzzielen zur tatsächlichen Wirksamkeit


Informationssicherheit wird häufig mit den drei klassischen Schutzzielen Vertraulichkeit, Integrität und Verfügbarkeit – kurz V.I.V. oder C.I.A. (Confidentiality, Integrity, Availability) – beschrieben.

Diese drei Ziele bilden nach wie vor das Fundament eines Informationssicherheitsmanagementsystems (ISMS). In der Praxis reichen sie jedoch häufig nicht aus, um die tatsächlichen Anforderungen eines Unternehmens, seiner Kunden, Mitarbeiter, Lieferanten und regulatorischen Rahmenbedingungen vollständig zu beschreiben.

Moderne Informationssicherheit umfasst deshalb weitere Eigenschaften wie Authentizität, Nachvollziehbarkeit, Resilienz, Wiederherstellbarkeit, Datenschutz, Lieferkettensicherheit oder Missbrauchsschutz.

Entscheidend ist dabei nicht nur die Frage:

„Welche Maßnahmen haben wir umgesetzt?“

Sondern vor allem:

„Erreichen wir damit tatsächlich unsere Informationssicherheitsziele?“

Damit kommt eine wichtige Unterscheidung ins Spiel: Innensicht und Außensicht.

 

1. Informationssicherheitsziele sind mehr als eine Liste von Controls

Ein häufiger Fehler in der Praxis besteht darin, Informationssicherheit über Maßnahmen zu beschreiben:

  • Wir haben eine Firewall.
  • Wir verwenden MFA.
  • Wir erstellen Backups.
  • Wir führen Awareness-Schulungen durch.
  • Wir haben ein Berechtigungskonzept.
  • Wir überwachen unsere Systeme.
  • Wir führen Lieferantenbewertungen durch.

Das sind jedoch Maßnahmen bzw. Controls und noch keine Informationssicherheitsziele.

Ein Sicherheitsziel beschreibt zunächst den gewünschten Zustand.

Beispielsweise:

Vertrauliche Informationen dürfen nur von dazu berechtigten Personen, Systemen oder Prozessen verarbeitet werden.

Erst danach stellt sich die Frage:

Welche Anforderungen und Maßnahmen benötigen wir, um dieses Ziel zu erreichen?

Und anschließend:

Woran erkennen wir, ob die Maßnahmen tatsächlich wirksam sind?

Damit entsteht eine wichtige Kette:

Informationssicherheitsziel → Sicherheitsanforderung → Maßnahmen/Controls → Prozess → Messung → tatsächliche Wirkung

Diese Systematik wird in einem separaten Beitrag zu KPI und Metriken für Informationssicherheitsziele ausführlicher behandelt.

 

2. Die klassische Basis: CIA

2.1 Vertraulichkeit – Confidentiality

Ziel:

Informationen sollen ausschließlich denjenigen Personen, Systemen oder Prozessen zugänglich sein, die dafür berechtigt sind.

Vertraulichkeit betrifft damit nicht nur technische Zugriffe. Auch Fehlversendungen, falsch konfigurierte Cloud-Speicher, Social Engineering, Insider oder unzureichend geschützte Dokumente können zu einem Verlust der Vertraulichkeit führen.

Innensicht – Prävention und Beherrschung

Typische Kriterien sind:

  • angemessene Berechtigungskonzepte
  • Least Privilege
  • MFA
  • Verschlüsselung
  • Netzwerksegmentierung
  • DLP
  • sichere Cloud-Konfiguration
  • Zugriffskontrollen
  • Awareness
  • Schutz vertraulicher Dokumente
  • regelmäßige Überprüfung von Berechtigungen

Hier wird beispielsweise gemessen:

  • Anteil regelmäßig überprüfter Berechtigungen
  • Anteil privilegierter Konten mit MFA
  • Anzahl kritischer Fehlkonfigurationen
  • Anzahl blockierter unzulässiger Datenübertragungen
  • Anteil geschulter Mitarbeiter

Außensicht – tatsächliches Ergebnis

Die entscheidende Frage lautet:

Sind vertrauliche Informationen tatsächlich in unberechtigte Hände gelangt?

Beispielsweise:

  • erfolgreiche unberechtigte Zugriffe
  • tatsächlich exfiltrierte Daten
  • Fehlversendungen vertraulicher Informationen
  • Anzahl betroffener Datensätze
  • Schutzbedarf der offengelegten Informationen
  • Anzahl betroffener Kunden oder Geschäftspartner
  • Umfang der tatsächlich verlassenen Vertrauensgrenze

Eine besonders aussagekräftige Frage lautet:

Wie viele schützenswerte Informationen haben tatsächlich die definierte Vertrauensgrenze verlassen?

Damit wird deutlich: Eine Organisation kann sehr viele Sicherheitsmaßnahmen besitzen und trotzdem einen erheblichen Vertraulichkeitsverlust erleiden.



2.2 Integrität – Integrity

Ziel:

Informationen sollen richtig, vollständig und konsistent sein und vor unbefugten oder unbeabsichtigten Veränderungen geschützt werden.

Integrität bedeutet daher nicht einfach „Unveränderbarkeit“.

Eine Datenbank, die überhaupt nicht verändert werden kann, wäre beispielsweise nicht automatisch integer. Entscheidend ist, dass Änderungen autorisiert, korrekt, nachvollziehbar und vollständig erfolgen.

Innensicht

Typische Kriterien:

  • Berechtigungskonzepte
  • Trennung von Rollen
  • Vier-Augen-Prinzip
  • Change Management
  • Versionierung
  • digitale Signaturen oder Hashwerte
  • Protokollierung
  • Integritätsprüfungen
  • kontrollierte Datenübertragung
  • Backup und Wiederherstellung

Außensicht

Hier geht es um die tatsächlich eingetretene Veränderung:

  • Wie viele Daten wurden unberechtigt verändert?
  • Welche Datensätze waren betroffen?
  • Welche Systeme oder Geschäftsprozesse waren betroffen?
  • Wie lange blieb die Manipulation unentdeckt?
  • Konnte die Veränderung vollständig erkannt werden?
  • Konnte ein vertrauenswürdiger Zustand wiederhergestellt werden?
  • Welche Veränderungen waren nicht mehr rekonstruierbar?

Die entscheidende Wirksamkeitsfrage lautet:

Welche Informationen wurden tatsächlich unberechtigt verändert – und welche Veränderungen konnten nicht mehr zuverlässig aus einer vertrauenswürdigen Quelle wiederhergestellt werden?



2.3 Verfügbarkeit – Availability

Ziel:

Informationen und die dafür erforderlichen Systeme sollen für berechtigte Nutzer verfügbar sein, wenn sie benötigt werden.

Verfügbarkeit bedeutet dabei nicht zwangsläufig 100 % technische Verfügbarkeit.

Entscheidend ist vielmehr die für den jeweiligen Geschäftsprozess erforderliche Verfügbarkeit.

Innensicht

Beispiele:

  • Redundanz
  • Hochverfügbarkeit
  • Backup
  • Failover
  • Monitoring
  • Notfallverfahren
  • Kapazitätsmanagement
  • Wartung
  • Wiederanlaufverfahren
  • Disaster Recovery

Außensicht

Hier zählt das tatsächlich erlebte Ergebnis:

  • tatsächliche Ausfallzeit
  • betroffene Geschäftsservices
  • betroffene Nutzer oder Kunden
  • verlorene Transaktionen
  • verzögerte Geschäftsprozesse
  • tatsächliche Geschäftsunterbrechung

Die entscheidende Frage lautet:

Wie stark und wie lange war der Geschäftsbetrieb tatsächlich beeinträchtigt?



3. Innensicht und Außensicht – zwei Seiten eines Sicherheitsziels

Die Unterscheidung zwischen Innen- und Außensicht lässt sich auf praktisch jedes Informationssicherheitsziel übertragen.

Innensicht

Die Innensicht betrachtet beispielsweise:

Sind wir angemessen vorbereitet und beherrschen wir die Risiken?

Hier stehen Controls, Prozesse, Verantwortlichkeiten und Prävention im Mittelpunkt.

Außensicht

Die Außensicht betrachtet:

Was konnte tatsächlich passieren bzw. welche Wirkung ist tatsächlich eingetreten?

Dabei geht es nicht ausschließlich um externe Angreifer.

Die Außensicht umfasst beispielsweise:

  • Cyberangriffe
  • Fehlkonfigurationen
  • menschliche Fehler
  • Insider
  • Lieferanten
  • technische Ausfälle
  • Naturereignisse
  • Fehlbedienung
  • Social Engineering
  • unzureichende Prozesse

Die Außensicht ist damit die tatsächliche Wirkung in der Realität.



4. Von der Maßnahme zur tatsächlichen Wirkung

Eine sinnvolle Betrachtung von Informationssicherheit kann deshalb mehrere Ebenen unterscheiden:

1. Innensicht – Kontrolle

Was haben wir umgesetzt?

2. Prävention und Detektion

Was konnten wir verhindern oder erkennen?

3. Außensicht – Outcome

Was ist tatsächlich passiert?

4. Auswirkung und Wiederherstellung

Welche Konsequenzen entstanden und wie schnell konnten wir einen vertrauenswürdigen Zustand wiederherstellen?

Vereinfacht:

Control → Prävention → Detektion → erfolgreicher Vorfall → Auswirkung → Wiederherstellung

Diese Betrachtung verhindert einen typischen Fehler:

Viele implementierte Controls bedeuten nicht automatisch wirksame Informationssicherheit.

Ebenso bedeutet ein gemessener Wert von „0 Vorfällen“ nicht automatisch, dass keine Vorfälle stattgefunden haben. Ein nicht erkannter Angriff kann schließlich ebenfalls als „0 Vorfälle“ erscheinen.

Deshalb sollten Control-, Präventions-, Detektions- und Outcome-Metriken sinnvoll miteinander kombiniert werden.



5. Erweiterte Informationssicherheitsziele

Neben den klassischen CIA-Schutzzielen können abhängig vom Kontext weitere Ziele relevant sein.

Dabei sollte allerdings unterschieden werden:

Nicht jede gewünschte Systemeigenschaft ist automatisch ein primäres Informationssicherheitsziel.

Beispielsweise können Skalierbarkeit, Wartbarkeit oder Interoperabilität wichtige technische oder betriebliche Ziele sein. Sie können aber gleichzeitig erhebliche Auswirkungen auf die Informationssicherheit haben.

Die konkrete Auswahl sollte deshalb aus Kontext, Risiken, Geschäftsanforderungen, gesetzlichen Anforderungen und den Bedürfnissen interessierter Parteien abgeleitet werden.



5.1 Authentizität

Ziel: Es soll zuverlässig festgestellt werden können, ob ein Benutzer, System, Gerät, Dokument oder Kommunikationspartner tatsächlich derjenige ist, der er vorgibt zu sein.

Innensicht:

  • starke Authentifizierung
  • MFA
  • Zertifikate
  • Identitätsmanagement
  • sichere Geräteidentitäten

Außensicht:

  • tatsächlich akzeptierte gefälschte Identitäten
  • erfolgreiche Account-Übernahmen
  • manipulierte Kommunikationspartner
  • gefälschte Dokumente oder Nachrichten

Wirksamkeitsfrage:

Wurden tatsächlich nicht authentische Identitäten oder Kommunikationsinhalte als echt akzeptiert?



5.2 Autorisierung

Ziel: Nur berechtigte Personen und Systeme dürfen definierte Aktionen durchführen.

Innensicht:

  • Rollen- und Berechtigungskonzepte
  • Least Privilege
  • Rezertifizierung
  • Segregation of Duties

Außensicht:

  • tatsächlich unberechtigt ausgeführte Aktionen
  • missbrauchte Privilegien
  • erfolgreiche Privilege Escalation



5.3 Nachvollziehbarkeit und Zurechenbarkeit

Ziel: Relevante Aktionen sollen einer verantwortlichen Identität oder einem verantwortlichen System zugeordnet werden können.

Innensicht:

  • Logging
  • eindeutige Benutzerkonten
  • Zeitstempel
  • manipulationsgeschützte Audit Trails
  • Protokollierungsanforderungen

Außensicht:

Können wir einen tatsächlichen Sicherheitsvorfall oder eine relevante Transaktion zuverlässig rekonstruieren?



5.4 Auditierbarkeit

Ziel: Sicherheitsrelevante Prozesse, Entscheidungen und Kontrollen sollen überprüfbar sein.

Innensicht:

  • dokumentierte Prozesse
  • Audit Trails
  • Nachweise
  • Prüfpläne
  • Verantwortlichkeiten

Außensicht:

Können wir einen konkreten Vorgang im Nachhinein tatsächlich nachvollziehbar und belastbar nachweisen?



5.5 Transparenz

Ziel: Relevante Informationen über Prozesse, Entscheidungen und Systemverhalten sollen für die jeweils berechtigten Interessengruppen verständlich und nachvollziehbar sein.

Innensicht:

  • dokumentierte Verantwortlichkeiten
  • nachvollziehbare Prozesse
  • transparente Entscheidungsregeln
  • geeignete Berichte

Außensicht:

Verstehen Betroffene und Verantwortliche tatsächlich, was ein System oder Prozess gemacht hat und warum?

Bei KI-Systemen gewinnt dieses Ziel beispielsweise besondere Bedeutung.



5.6 Datenschutz und Privacy

Ziel: Personenbezogene Daten sollen entsprechend den rechtlichen, vertraglichen und organisatorischen Anforderungen geschützt und verarbeitet werden.

Innensicht:

  • Datenschutzanforderungen
  • Zugriffsschutz
  • Löschkonzepte
  • Privacy by Design
  • Verzeichnis von Verarbeitungstätigkeiten
  • technische und organisatorische Maßnahmen

Außensicht:

  • tatsächliche Datenschutzverletzungen
  • betroffene Personen
  • Umfang der offengelegten personenbezogenen Daten
  • tatsächliche Auswirkungen auf Betroffene



5.7 Datenminimierung

Ziel: Es sollen nur diejenigen personenbezogenen oder schützenswerten Daten erhoben, verarbeitet und gespeichert werden, die tatsächlich benötigt werden.

Außensicht:

Nicht nur:

„Haben wir ein Löschkonzept?“

sondern:

„Wie viele nicht mehr erforderliche Daten befinden sich tatsächlich noch in unseren Systemen?“



5.8 Zweckbindung

Ziel: Informationen sollen nur für festgelegte und zulässige Zwecke verarbeitet werden.

Die Wirksamkeit zeigt sich daher nicht allein in einer dokumentierten Zweckbeschreibung, sondern auch darin, ob Daten tatsächlich für nicht vorgesehene Zwecke verwendet werden.



5.9 Resilienz

Ziel: Die Organisation soll auch bei Störungen, Angriffen oder unerwarteten Ereignissen handlungsfähig bleiben.

Innensicht:

  • Resilienzkonzepte
  • Redundanzen
  • Notfallorganisation
  • Szenarien
  • Übungen
  • Krisenmanagement

Außensicht:

Wie gut konnte die Organisation einen tatsächlichen Angriff oder eine Störung verkraften, ohne ihre kritischen Funktionen zu verlieren?



5.10 Wiederherstellbarkeit

Ziel: Ein vertrauenswürdiger Zustand soll nach einer Störung oder einem Angriff wiederhergestellt werden können.

Innensicht:

  • Backups
  • Recovery-Verfahren
  • Wiederanlaufpläne
  • getestete Restore-Verfahren

Außensicht:

  • tatsächlich benötigte Wiederherstellungszeit
  • tatsächlich verlorene Daten
  • tatsächlich wiederhergestellte Systeme
  • verbleibende Schäden

Wichtig:

RTO und RPO sind in erster Linie Ziel- bzw. Anforderungswerte.

Die eigentlichen KPI können beispielsweise messen, ob die tatsächlich erreichte Wiederherstellungszeit und der tatsächliche Datenverlust diese Anforderungen eingehalten haben.



5.11 Kontinuität

Ziel: Kritische Geschäftsprozesse sollen auch bei erheblichen Störungen aufrechterhalten oder innerhalb definierter Grenzen wieder aufgenommen werden können.

Die Außensicht zeigt sich beispielsweise in:

  • tatsächlicher Dauer der Geschäftsunterbrechung
  • Anzahl betroffener Geschäftsprozesse
  • tatsächlich ausgefallenen Leistungen
  • tatsächlich entstandenen Auswirkungen auf Kunden



5.12 Robustheit

Ziel: Systeme und Prozesse sollen gegenüber Fehlern, Belastungen und Störungen ausreichend widerstandsfähig sein.

Die Außensicht betrachtet beispielsweise:

  • tatsächliche Fehlerraten
  • Ausfallverhalten
  • Auswirkungen unerwarteter Eingaben
  • Verhalten unter außergewöhnlicher Belastung



5.13 Missbrauchsschutz

Ziel: Informationen, Systeme und Berechtigungen sollen nicht für unzulässige Zwecke missbraucht werden können.

Dazu gehören beispielsweise:

  • Missbrauch privilegierter Konten
  • Insider-Aktivitäten
  • Credential Theft
  • Missbrauch von APIs
  • automatisierter Missbrauch
  • Social Engineering

Die entscheidende Frage lautet:

Welche Missbrauchsszenarien konnten tatsächlich erfolgreich umgesetzt werden?



5.14 Compliance

Ziel: Anwendbare gesetzliche, regulatorische, vertragliche und normative Anforderungen sollen eingehalten werden.

Dabei ist „100 % Compliance“ als pauschales Ziel wenig aussagekräftig.

Sinnvoller sind beispielsweise:

  • Anteil identifizierter anwendbarer Anforderungen
  • Anteil fristgerecht umgesetzter Anforderungen
  • Anzahl bestätigter Compliance-Verstöße
  • Dauer bis zur Behebung von Abweichungen

Die Frage lautet:

Werden die für uns relevanten Anforderungen tatsächlich eingehalten?



5.15 Lieferkettensicherheit

Ziel: Risiken aus Lieferanten, Dienstleistern, Cloud-Anbietern und anderen externen Abhängigkeiten sollen angemessen beherrscht werden.

Innensicht:

  • Lieferantenbewertung
  • Sicherheitsanforderungen in Verträgen
  • Due Diligence
  • regelmäßige Bewertungen
  • Überwachung kritischer Dienstleister

Außensicht:

  • tatsächlich eingetretene Lieferanten-Sicherheitsvorfälle
  • Ausfälle kritischer Dienstleister
  • tatsächlich entstandene Abhängigkeiten
  • Auswirkungen eines Lieferantenausfalls

Dabei sollte nicht das unrealistische Ziel formuliert werden:

„Drittanbieter stellen kein Risiko dar.“

Sinnvoller ist:

Risiken aus Drittparteien werden identifiziert, bewertet, behandelt und überwacht.



5.16 Reaktionsfähigkeit

Ziel: Sicherheitsereignisse sollen schnell und angemessen erkannt, bewertet und behandelt werden können.

Innensicht:

  • Incident-Management
  • Alarmierung
  • Verantwortlichkeiten
  • Eskalationswege
  • Playbooks
  • Übungen

Außensicht:

  • tatsächliche Zeit bis zur Erkennung
  • tatsächliche Zeit bis zur Reaktion
  • tatsächliche Zeit bis zur Eindämmung
  • Auswirkungen des Vorfalls vor der Eindämmung



5.17 Nichtabstreitbarkeit

Ziel: Das spätere Abstreiten einer relevanten Aktion oder Transaktion soll unter definierten Bedingungen verhindert bzw. erschwert werden.

Relevant sind beispielsweise:

  • digitale Signaturen
  • beweissichere Protokollierung
  • Zeitstempel
  • Transaktionsnachweise

Die Außensicht stellt die Frage:

Können wir eine konkrete Transaktion oder Handlung im Streitfall tatsächlich belastbar nachweisen?



5.18 Steuerbarkeit und Kontrollierbarkeit

Ziel: Sicherheitsrelevante Zustände und Maßnahmen sollen gezielt beeinflusst und kontrolliert werden können.

Beispiele:

  • Berechtigungen sperren
  • Systeme isolieren
  • Zugriffe deaktivieren
  • Sicherheitskonfigurationen ändern
  • Notfallmaßnahmen auslösen

Die Außensicht zeigt sich darin, ob diese Maßnahmen im tatsächlichen Ereignisfall rechtzeitig und wirksam umgesetzt werden konnten.



5.19 Anonymität

Ziel: Wenn Anonymität erforderlich ist, soll die Identität einer Person nicht über das vorgesehene Maß hinaus ermittelt werden können.

Dabei ist zwischen Anonymisierung und Pseudonymisierung zu unterscheiden.

Das Ziel ist nicht grundsätzlich „maximale Anonymität“, sondern ein angemessener Schutz der Identität entsprechend dem jeweiligen Anwendungsfall und den geltenden Anforderungen.



5.20 Datenqualität

Ziel: Für sicherheits- und geschäftskritische Entscheidungen sollen Daten ausreichend korrekt, vollständig, aktuell und konsistent sein.

Datenqualität ist nicht ausschließlich ein Informationssicherheitsziel. Sie kann ebenso ein Qualitäts-, Prozess- oder Data-Governance-Ziel sein.

Sie wird jedoch sicherheitsrelevant, wenn fehlerhafte oder manipulierte Daten zu falschen Sicherheits- oder Geschäftsentscheidungen führen.



5.21 Vertrauenswürdigkeit

Ziel: Systeme, Informationen und Ergebnisse sollen unter definierten Bedingungen als vertrauenswürdig eingestuft werden können.

Bei KI-Systemen können beispielsweise folgende Aspekte relevant sein:

  • Genauigkeit
  • Robustheit
  • Nachvollziehbarkeit
  • Datenschutz
  • Informationssicherheit
  • menschliche Aufsicht
  • Zuverlässigkeit

Die Bewertung sollte daher nicht auf einen einzelnen Wert wie eine „Halluzinationsrate“ reduziert werden.



5.22 Interoperabilität

Ziel: Systeme sollen sicher und zuverlässig miteinander kommunizieren und Informationen austauschen können.

Informationssicherheitsrelevant sind beispielsweise:

  • sichere Schnittstellen
  • definierte Protokolle
  • Authentifizierung
  • Integrität der übertragenen Daten
  • kontrollierte Datenflüsse



5.23 Skalierbarkeit

Ziel: Sicherheitsmechanismen sollen auch bei wachsender Benutzerzahl, Datenmenge, Systemanzahl oder Transaktionsvolumen wirksam bleiben.

Die Frage lautet beispielsweise:

Funktioniert unser Sicherheitskonzept auch dann noch, wenn sich die Anzahl der Systeme oder Benutzer verdoppelt?

Skalierbarkeit ist dabei eher eine technische bzw. betriebliche Eigenschaft als ein klassisches Schutzziel.



5.24 Wartbarkeit

Ziel: Sicherheitsrelevante Systeme und Maßnahmen sollen dauerhaft betrieben, aktualisiert und angepasst werden können.

Beispiele:

  • Patchbarkeit
  • Updatefähigkeit
  • Austausch veralteter Komponenten
  • Wartbarkeit von Sicherheitskonfigurationen
  • Aktualisierung von Regeln und Signaturen

Auch hier handelt es sich eher um eine unterstützende technische Eigenschaft als um ein klassisches Schutzziel.



5.25 Supply-Chain- und Abhängigkeitssicherheit

Neben der klassischen Lieferantensicherheit kann es sinnvoll sein, kritische Abhängigkeiten explizit zu betrachten:

  • Cloud-Abhängigkeiten
  • Softwarebibliotheken
  • Open-Source-Komponenten
  • Managed Services
  • externe Identitätsprovider
  • Kommunikationsanbieter
  • Single Points of Failure

Die entscheidende Frage lautet:

Was passiert mit unserer Informationssicherheit, wenn eine kritische externe Abhängigkeit ausfällt oder kompromittiert wird?



6. Nicht jedes Ziel ist ein primäres Informationssicherheitsziel

Die große Zahl möglicher Ziele zeigt auch eine wichtige Grenze.

Nicht jedes Unternehmensziel sollte automatisch zu einem Informationssicherheitsziel erklärt werden.

Eine sinnvolle Struktur kann beispielsweise so aussehen:

Primäre Informationssicherheitsziele

  • Vertraulichkeit
  • Integrität
  • Verfügbarkeit

Erweiterte Sicherheits- und Governance-Ziele

  • Authentizität
  • Autorisierung
  • Nachvollziehbarkeit
  • Auditierbarkeit
  • Nichtabstreitbarkeit
  • Zurechenbarkeit
  • Transparenz
  • Steuerbarkeit

Resilienz- und Continuity-Ziele

  • Resilienz
  • Wiederherstellbarkeit
  • Kontinuität
  • Robustheit
  • Reaktionsfähigkeit

Datenschutz- und Datenziele

  • Datenschutz
  • Datenminimierung
  • Zweckbindung
  • Anonymität
  • Datenqualität

Externe und regulatorische Ziele

  • Compliance
  • Lieferkettensicherheit

Technische unterstützende Eigenschaften

  • Interoperabilität
  • Skalierbarkeit
  • Wartbarkeit

Vertrauens- und KI-relevante Ziele

  • Vertrauenswürdigkeit
  • Missbrauchsschutz

Diese Einteilung ist keine normative Vorgabe. Sie dient dazu, Ziele im jeweiligen Unternehmenskontext sinnvoll zu strukturieren.



7. Von der Innensicht zur Außensicht: Wie wird Wirksamkeit sichtbar?

Ein modernes Informationssicherheitsmanagement sollte nicht bei der Frage stehen bleiben:

„Haben wir die Maßnahme umgesetzt?“

Viel interessanter sind drei aufeinander aufbauende Fragen:

1. Sind wir vorbereitet?

Beispielsweise:

  • Sind alle kritischen Systeme identifiziert?
  • Sind Berechtigungen definiert?
  • Sind Backups vorhanden?
  • Sind Lieferanten bewertet?

2. Funktionieren unsere Kontrollen?

Beispielsweise:

  • Werden Angriffe erkannt?
  • Werden unzulässige Zugriffe blockiert?
  • Funktionieren Backups?
  • Werden kritische Schwachstellen rechtzeitig behoben?

3. Was passiert tatsächlich?

Beispielsweise:

  • Sind Daten tatsächlich abgeflossen?
  • Wurden Daten tatsächlich manipuliert?
  • Wie lange waren Systeme tatsächlich nicht verfügbar?
  • Wie viele Kunden waren tatsächlich betroffen?
  • Wie viel Datenverlust ist tatsächlich entstanden?

Damit verschiebt sich die Perspektive:

Nicht nur messen, was wir tun. Messen, was wir verhindern – und was trotz unserer Maßnahmen tatsächlich passiert.



8. Informationssicherheitsziel ist nicht gleich KPI

Ein häufiger Fehler besteht darin, einen KPI mit einem Ziel gleichzusetzen.

Beispiel:

Ziel:
Vertraulichkeit schützenswerter Informationen sicherstellen.

Anforderung:
Nur autorisierte Personen dürfen auf vertrauliche Informationen zugreifen.

Maßnahme:
Rollenbasierte Zugriffskontrolle und MFA.

Prozessziel:
Berechtigungen werden korrekt und fristgerecht vergeben, geändert und entzogen.

KPI/Metrik:

  • Anteil fristgerecht bearbeiteter Berechtigungsänderungen
  • Anzahl kritischer Berechtigungsfehler
  • Anzahl blockierter unberechtigter Zugriffsversuche
  • Anzahl erfolgreicher unberechtigter Zugriffe

Outcome:

  • tatsächlich offengelegte Informationen
  • Anzahl betroffener Datensätze
  • Schutzbedarf der betroffenen Informationen
  • tatsächliche Auswirkungen

Erst die Gesamtheit dieser Betrachtung ermöglicht eine belastbare Aussage über die Wirksamkeit.



9. Die entscheidende Frage: Wirkt unser ISMS?

Ein ISMS sollte nicht nur nachweisen können:

„Wir haben Prozesse.“

oder:

„Wir haben Controls.“

oder:

„Wir haben KPI.“

Die entscheidende Frage lautet:

Erreichen wir mit unserem ISMS tatsächlich die definierten Informationssicherheitsziele?

Dafür müssen Ziele, Anforderungen, Maßnahmen, Prozesse und Messgrößen miteinander verbunden werden.

Die grundlegende Logik lautet:

·      Informationssicherheitsziel

·      konkrete Sicherheitsanforderung

·      geeignete Controls und Maßnahmen

·      Prozessziel

·      KPI und Metriken

·      tatsächliches Ergebnis / Outcome

·      Bewertung der Wirksamkeit

Damit wird aus einer Sammlung von Sicherheitsmaßnahmen ein steuerbares und bewertbares Informationssicherheitsmanagement.



Fazit

Informationssicherheitsziele beginnen mit den klassischen Schutzzielen Vertraulichkeit, Integrität und Verfügbarkeit. In modernen Organisationen müssen sie jedoch häufig um weitere Eigenschaften ergänzt werden – beispielsweise Authentizität, Nachvollziehbarkeit, Resilienz, Wiederherstellbarkeit, Datenschutz, Lieferkettensicherheit oder Missbrauchsschutz.

Entscheidend ist dabei die Verbindung von Innensicht und Außensicht.

Die Innensicht beantwortet:

Sind wir angemessen vorbereitet und beherrschen wir unsere Risiken?

Die Außensicht beantwortet:

Was konnte tatsächlich passieren und welche Auswirkungen sind tatsächlich eingetreten?

Erst beide Perspektiven zusammen ermöglichen eine realistische Bewertung der Informationssicherheit.

Oder kurz gesagt:

Nicht nur messen, ob das ISMS arbeitet – messen, ob es wirkt.

Der nächste Schritt ist deshalb die Übersetzung der Sicherheitsziele in eine belastbare Messlogik:

Ziel → Anforderung → Control → Prozessziel → KPI/Metrik → Outcome → Wirksamkeitsbewertung.

Genau diese Systematik zeigt, wie aus Informationssicherheitszielen messbare und steuerbare Ziele werden.


Konstantin Ziouras Blog Artikel

von Konstantin Ziouras • 5. Oktober 2026
Wenn die Kennzahl zum Ziel wird – eine kleine Parabel über KPI und Wirksamkeit
von Konstantin Ziouras • 5. Oktober 2026
ISMS-Wirksamkeit messen – Ein Mindestmaß an Zielen, KPI und Metriken
von Konstantin Ziouras • 22. September 2026
Software Testing und Test Management nach ISTQB - International Software Testing Qualifications Board
von Konstantin Ziouras • 22. September 2026
Anforderungsmanagement nach IREB - International Requirements Engineering Board
von Konstantin Ziouras • 22. September 2026
Requirements Engineering als Qualitäts- und Sicherheitsfaktor
von Konstantin Ziouras • 18. Mai 2026
Unterschiede zwischen EULA, SLA und AVV
von Konstantin Ziouras • 18. Mai 2026
Unterschiede und Parallelen bezüglich Bewertungen, bezüglich Lieferanten, Software, Cloud Dienstleistern
von Konstantin Ziouras • 10. Mai 2026
Risiken bezüglich Lieferanten
von Konstantin Ziouras • 10. Mai 2026
Lieferanten, Auswahl und Bewertung
von Konstantin Ziouras • 15. April 2026
Endpoint Security bedeutet: Schutz aller Endgeräte, die mit IT Systemen verbunden sind – also Laptops, Desktops, Smartphones, Tablets, Server, virtuelle Maschinen, Container Hosts, OT HMI Rechner etc. Bildlich: Jedes Gerät ist eine Tür ins Unternehmen. Endpoint Security sorgt dafür, dass diese Türen: • nicht offenstehen • nicht mit gestohlenen Schlüsseln geöffnet werden • und im Idealfall einen Alarm auslösen, wenn jemand versucht einzubrechen. Warum das Thema heute wichtig ist 1. Angriffe starten fast immer am Endpoint • Phishing Mails → Klick → Malware auf dem Laptop • Ransomware → Verschlüsselung startet am Endpoint • Initial Access Broker → kompromittierte Endgeräte werden verkauft 2. Arbeitswelt hat sich verändert • Homeoffice, Remote Work, BYOD • Cloud Zugriffe von überall • Mehr Endgeräte, weniger klarer Perimeter 3. Business Relevanz • Ein kompromittierter Endpoint kann: o Zugang zu AD / Identitäten geben o Ransomware ins gesamte Netz bringen o Datenabfluss ermöglichen • Direkte Auswirkungen: Ausfall, Lösegeld, Reputationsschäden, NIS2 Sanktionen. Technische Grundlagen Kernidee: Endpoint Security kombiniert Schutz, Erkennung und Reaktion direkt auf dem Gerät. Wichtige Bausteine: • Antivirus / Anti Malware: Signatur und verhaltensbasierter Schutz • Host Firewall: Filtert eingehenden/ausgehenden Traffic • Endpoint Detection & Response (EDR): Erkennung verdächtigen Verhaltens, Forensik, Response • Extended Detection & Response (XDR): Korrelation von Endpoint Daten mit Netzwerk, Cloud, Identitäten • Hardening: Konfiguration, die Angriffsfläche reduziert (z. B. Deaktivierung unnötiger Dienste) • Patch Management: Schließen von Schwachstellen Stand der Technik / Best Practices 1. Von klassischem AV zu EDR/XDR • Klassischer Virenscanner allein ist nicht mehr ausreichend. • Stand der Technik: EDR/XDR Lösungen, die Verhalten analysieren, Prozesse korrelieren und Angriffe in frühen Phasen erkennen. 2. Zero Trust am Endpoint • Endpoint wird nicht automatisch vertraut, nur weil er „im Netz“ ist. • Kombination aus: o Gerätestatus (Compliance) o Identität (User) o Kontext (Ort, Zeit, Risiko) 3. Harter Fokus auf Identitäten • Endpoint Security ist eng mit Identity & Access Management verknüpft. • Kompromittierter Endpoint → kompromittierte Identität → lateral movement. 4. Standardisierte Baselines • CIS Benchmarks, BSI Empfehlungen, Hardening Guides • Standardisierte Konfigurationen für Windows, macOS, Linux, Mobile, OT Systeme. Typische Risiken & Fehler in der Praxis • Nur Antivirus, kein EDR/XDR • Kein zentrales Management der Endpoints • Ungepatchte Systeme (insbesondere Drittsoftware wie Browser, Java, Office Plugins) • Lokale Adminrechte für Benutzer • Kein Application Whitelisting (alles darf laufen) • Shadow IT (private Geräte, nicht verwaltete Systeme) • OT Endpoints ohne Schutz, weil „Produktionssysteme darf man nicht anfassen“ • Fehlende Integration in SIEM/SOC – Alarme bleiben unbemerkt Moderne Lösungsansätze & Technologien • EDR/XDR Plattformen o Sammeln Telemetrie (Prozesse, Registry, Netzwerk, Dateien) o Erkennen verdächtige Muster (z. B. Ransomware Verhalten) o Unterstützen Incident Response (Isolieren von Endpoints, Forensik) • Zero Trust Network Access (ZTNA) o Zugriff auf Anwendungen nur, wenn Endpoint „gesund“ ist (Compliance Check) • Mobile Device Management (MDM) / Unified Endpoint Management (UEM) o Verwaltung von Laptops, Smartphones, Tablets, teilweise auch IoT/OT o Erzwingung von Policies (Verschlüsselung, PIN, Jailbreak Erkennung) • Application Control / Whitelisting o Nur erlaubte Anwendungen dürfen laufen o Sehr wirksam gegen Malware und Ransomware • Hardware basierte Sicherheit o TPM, Secure Boot, Device Guard, Plattferverschlüsselung (BitLocker, FileVault) Relevanz für Informationssicherheit & Compliance NIS2 • Verlangt „Stand der Technik“ bei technischen und organisatorischen Maßnahmen. • Endpoint Security ist zentral für: o Schutz vor Ransomware o Incident Detection & Response o Nachweis von Maßnahmen gegenüber Aufsichtsbehörden. ISO 27001:2022 • Relevante Controls u. a.: o A.5.15: Access control o A.8.1: User end point devices o A.8.7: Protection against malware o A.8.8: Management of technical vulnerabilities o A.8.9: Configuration management IEC 62443 (für OT) • Endpoint ähnliche Systeme (Engineering Stationen, HMI, Server) müssen: o gehärtet sein o nur notwendige Dienste bereitstellen o überwacht werden o in Zonen/Conduits eingebettet sein. Endpoint Security ist damit ein Pflichtbaustein für jede ernsthafte Umsetzung von NIS2, ISO 27001 und IEC 62443. Empfehlungen für Unternehmen (konkret, priorisiert) Priorität 1 – Basis schaffen • Zentrales Endpoint Management einführen (Windows, macOS, Linux, Mobile) • EDR Lösung ausrollen (mindestens auf kritischen Systemen) • Patch Management etablieren (inkl. Drittsoftware) • Plattferverschlüsselung aktivieren (Laptops, mobile Geräte) • Lokale Adminrechte abschaffen (Role Based Access, Just in Time Admin) Priorität 2 – Reifegrad erhöhen • Application Whitelisting für besonders kritische Systeme • Zero Trust Policies: Zugriff nur bei „gesundem“ Endpoint • Integration in SIEM/SOC: Alarme zentral auswerten • Standardisierte Hardening Baselines (CIS, BSI) Priorität 3 – OT & Spezialumgebungen • OT Endpoints inventarisieren (Engineering Stationen, HMI, SCADA Server) • Schutzkonzept definieren: o Hardening o Segmentierung o Monitoring (passiv, wo aktiv nicht möglich) • Remote Zugriffe auf OT nur über kontrollierte Jump Hosts mit starker Authentifizierung und Session Recording. CTO Checkliste: Die 3 entscheidenden Fragen 1) „Wie erkennen und stoppen wir heute einen Angriff auf einen Endpoint, der keine bekannte Malware Signatur hat?“ Diese Frage trennt klassischen Antivirus von echtem EDR/XDR. Eine moderne Antwort muss enthalten: • verhaltensbasierte Erkennung • Prozess und Speicheranalyse • Telemetrie Korrelation • automatische Isolation des Endpoints • Integration ins SOC/SIEM Wenn die Antwort nur „Antivirus“ oder „Signaturen“ enthält → nicht modern. 2) „Wie stellen wir sicher, dass alle Endgeräte (inkl. Homeoffice, mobile Geräte, Admin Laptops, OT Engineering Stationen) vollständig verwaltet, gepatcht und gehärtet sind?“ Diese Frage deckt Management Reifegrad, Patch Prozesse und Hardening auf. Eine moderne Antwort muss enthalten: • zentrales Endpoint Management (UEM/MDM) • automatisiertes Patch Management (inkl. Drittsoftware) • CIS/BSI Hardening Baselines • Compliance Checks vor Zugriff (Zero Trust) Wenn die Antwort „Wir patchen regelmäßig“ lautet → nicht ausreichend. 3) „Wie schnell können wir einen kompromittierten Endpoint identifizieren, isolieren und forensisch analysieren – und wer macht das konkret?“ Diese Frage prüft Incident Response Fähigkeit und operative Realität. Eine moderne Antwort muss enthalten: • EDR gestützte Isolation per Klick • klare Rollen (SOC, IT Ops, Dienstleister) • forensische Daten (Prozesse, Registry, Netzwerk, Timeline) • definierte Reaktionszeiten • Playbooks Wenn die Antwort unklar ist oder niemand zuständig ist → kritische Lücke.