Das Lexikon zur ISO 27001

Beispiel

Im Anhang A finden sich unter anderem Themen wie Informationssicherheitsrichtlinien, Zugangsrechte, Sicherheitsbewusstsein, physischer Zutritt, Schwachstellenmanagement und Datensicherung.

In der Praxis

Der Anhang A ist keine bloße optionale Ideensammlung. Er ist normativ und wird im Rahmen eines ISO-27001-Audits berücksichtigt. Die Organisation muss jedoch risikobasiert bestimmen, welche Maßnahmen für ihr ISMS erforderlich sind. Genau dafür wird die SoA erstellt.

Mögliche Nachweise

• Erklärung zur Anwendbarkeit (SoA)
• Richtlinien und Verfahren zu den ausgewählten Maßnahmen
• Umsetzungsnachweise und Aufzeichnungen
• Risikoanalyse und Risikobehandlungsplan

Beispiel

Der Scope kann den gesamten Cloud-Betrieb in Deutschland umfassen – oder nur die Entwicklung und den Betrieb einer bestimmten SaaS-Anwendung einschließlich der dafür zuständigen Mitarbeitenden und Dienstleister.

In der Praxis

• Der Scope muss klar und nachvollziehbar beschrieben sein.
• Schnittstellen zu Bereichen außerhalb des Scopes sollten berücksichtigt werden.
• Der Scope darf nicht so gewählt werden, dass wichtige Risiken künstlich ausgeblendet werden.
• Der Scope ist nicht dasselbe wie die SoA.

Mögliche Nachweise

• Schriftliche Scope-Erklärung
• Organisations- und Standortübersicht
• Prozess- und Systemübersicht
• Begründung für ein- oder ausgeschlossene Bereiche
• Beschreibung relevanter Schnittstellen zu Lieferanten oder anderen Organisationseinheiten

Beispiel

Die Kundendatenbank ist ein schützenswerter Informationswert. Der Server, auf dem sie betrieben wird, ist ein unterstützendes Asset.

In der Praxis

Ein Asset sollte einer verantwortlichen Person oder Funktion zugeordnet werden. Außerdem sollte erkennbar sein, welche anderen Assets davon abhängen.

Mögliche Nachweise

• Asset- oder Werte-Inventar
• Zuordnung von Asset-Eigentümern
• Übersicht der Abhängigkeiten zwischen Prozessen, Informationen und Systemen
• Schutzbedarfs- oder Klassifizierungsergebnis

Beispiel

Ein Auditor prüft nicht nur, ob es eine Richtlinie für Zugangsrechte gibt. Er kann auch anhand von Stichproben prüfen, ob Zugänge tatsächlich beantragt, genehmigt, eingerichtet und bei Austritt entzogen werden.

In der Praxis

Ein Audit besteht nicht nur aus Dokumentenprüfung. Gespräche, Stichproben und die Betrachtung tatsächlich gelebter Abläufe sind ebenfalls wichtig.

Mögliche Nachweise

• Auditprogramm und Auditplan
• Auditfragen und Stichproben
• Interviewnotizen
• Auditbericht
• Feststellungen und Maßnahmenverfolgung

Beispiel

Bei der Prüfung der Passwortverwaltung können die ISO-27001-Anforderung, die interne Passwort-Richtlinie und vertragliche Kundenvorgaben gemeinsam als Auditkriterien dienen.

In der Praxis

Eine Bedrohung allein ist noch kein Risiko. Erst wenn sie auf ein schützenswertes Asset und eine Schwachstelle trifft, kann daraus ein konkretes Risiko entstehen.

Beispiel

Wenn das primäre Rechenzentrum ausfällt, kann ein Dienst aus einer zweiten Umgebung bereitgestellt werden. Zusätzlich gibt es getestete Wiederanlauf- und Kommunikationsabläufe.

In der Praxis

Business Continuity betrifft nicht nur Backups. Es geht auch um Verantwortlichkeiten, Prioritäten, Kommunikationswege, Ausweichverfahren und Tests.

Mögliche Nachweise

• Business-Continuity- oder Notfallkonzept
• Wiederanlaufplan
• Notfallübungen und Testergebnisse
• Backup- und Restore-Nachweise
• Liste kritischer Prozesse und Abhängigkeiten

Beispiel

• Ein unberechtigter Zugriff auf eine Personalakte verletzt die Vertraulichkeit.
• Eine manipulierte Rechnung verletzt die Integrität.
• Ein nicht erreichbarer Onlineshop verletzt die Verfügbarkeit.

In der Praxis

Bei der Risikobeurteilung sollte geprüft werden, welches Schutzziel durch ein Risiko gefährdet wird. Je nach Organisation können zusätzlich Authentizität, Zurechenbarkeit, Nichtabstreitbarkeit und Verlässlichkeit wichtig sein.

Beispiel

Der ISMS-Beauftragte koordiniert die Risikoanalyse, bereitet Managementbewertungen vor und verfolgt Verbesserungsmaßnahmen. Der jeweilige Fachbereich bleibt trotzdem für seine Prozesse und Werte verantwortlich.

Mögliche Nachweise

• Rollenkonzept
• Ernennungsschreiben
• Aufgaben- und Verantwortlichkeitsbeschreibung
• Organigramm
• Protokolle von Sicherheitsgremien

Beispiel

Mehrfaktor-Authentisierung, Backups, Schulungen, Zutrittskontrollen oder ein geregeltes Berechtigungsverfahren können Controls sein.

In der Praxis

Eine Maßnahme ist nicht automatisch wirksam, nur weil sie in einer Richtlinie beschrieben ist. Die Umsetzung und die Wirksamkeit müssen in angemessener Weise überprüfbar sein.

Beispiel

Vor der Einführung einer umfangreichen biometrischen Zugangskontrolle wird geprüft, welche personenbezogenen Daten verarbeitet werden, welche Gefahren bestehen und welche Schutzmaßnahmen erforderlich sind.

In der Praxis

Die Datenschutz-Folgenabschätzung ist ein Datenschutzinstrument. Sie kann methodisch vom Risikomanagement des ISMS profitieren, ersetzt aber nicht automatisch die datenschutzrechtliche Prüfung.

Beispiel

• Passwort-Richtlinie = Vorgabe
• Protokoll einer durchgeführten Zugangsüberprüfung = Aufzeichnung

In der Praxis

Dokumente müssen kontrolliert, aktuell und auffindbar sein. Gleichzeitig verlangt ISO/IEC 27001 nicht, jeden Arbeitsschritt unnötig zu verschriftlichen. Der Umfang sollte zur Organisation und zum Risiko passen.

Mögliche Nachweise

• Dokumentenlenkungsprozess
• Freigabe- und Versionshistorie
• Aufbewahrungs- und Löschregeln
• Änderungsprotokolle
• Schulungs- oder Prüfungsaufzeichnungen

Beispiel

Ein Unternehmen schützt seine Kundendaten durch Berechtigungen, Verschlüsselung, Backups, Schulungen und geregelte Prozesse für Sicherheitsvorfälle.

In der Praxis

Informationssicherheit umfasst mehr als IT-Sicherheit. Auch Papierunterlagen, Gespräche, Gebäude, Mitarbeitende, Lieferanten und Geschäftsprozesse können dazugehören.

Beispiel

Ein Mitarbeiter erhält eine verdächtige Phishing-Mail. Es ist noch nicht klar, ob ein Schaden eingetreten ist, aber das Ereignis sollte gemeldet und bewertet werden.

Abgrenzung zum Vorfall Ein Ereignis ist zunächst eine Beobachtung. Nach der Bewertung kann sich herausstellen, dass kein Sicherheitsvorfall vorliegt – oder dass ein tatsächlicher Vorfall behandelt werden muss.

Mögliche Nachweise

• Meldeweg für Ereignisse
• Meldungen im Ticketsystem
• Bewertung und Klassifizierung
• Schulungs- und Sensibilisierungsnachweise

Beispiel

Das ISMS legt fest, wie Risiken bewertet werden, wer Sicherheitsvorfälle bearbeitet, wie Zugänge vergeben werden und wie die Leitung die Wirksamkeit regelmäßig bewertet.

In der Praxis

Ein ISMS ist kein einzelnes Tool und keine reine Sammlung technischer Einstellungen. Es verbindet Menschen, Organisation, Prozesse und Technik.

Mögliche Nachweise

• ISMS-Handbuch oder Prozessübersicht
• Informationssicherheitsleitlinie
• Scope-Erklärung
• Risikoregister und SoA
• Audit- und Managementbewertungsunterlagen

Beispiel

Ein Kunde fordert eine bestimmte Verfügbarkeit. Ein Gesetz verlangt den Schutz personenbezogener Daten. Beides kann eine relevante Anforderung einer interessierten Partei sein.

Mögliche Nachweise

• Liste interessierter Parteien
• Übersicht gesetzlicher, vertraglicher und regulatorischer Anforderungen
• Kundenverträge
• Lieferantenvereinbarungen
• Kommunikationsplan

Beispiel

Bei einer Prüfung wird festgestellt, dass Zugänge ausscheidender Mitarbeitender zu spät gesperrt werden. Die reine nachträgliche Sperrung ist eine Korrektur. Die Überarbeitung des Austrittsprozesses, die Festlegung eines Verantwortlichen und eine automatische Meldung können Korrekturmaßnahmen sein.

In der Praxis

Die Organisation sollte nicht nur das sichtbare Problem beheben, sondern die Ursache untersuchen und anschließend prüfen, ob die Maßnahme wirksam war.

Mögliche Nachweise

• Nichtkonformitätsbericht
• Ursachenanalyse
• Maßnahmenplan
• Verantwortlicher und Frist
• Wirksamkeitsprüfung

In der Praxis

Ob eine Organisation tatsächlich als KRITIS-Betreiber gilt, hängt von gesetzlichen Definitionen, Anlagenkategorien und Schwellenwerten ab. Eine ISO-27001-Zertifizierung allein bedeutet nicht automatisch, dass alle KRITIS-Anforderungen erfüllt sind.

Beispiel

Die Geschäftsleitung betrachtet unter anderem Auditergebnisse, Sicherheitsvorfälle, Kennzahlen, Änderungen im Geschäftsumfeld, Risiken und Verbesserungsmaßnahmen und entscheidet über notwendige Anpassungen.

In der Praxis

Eine Managementbewertung sollte echte Entscheidungen hervorbringen. Ein bloßes Abzeichnen ohne Bewertung und ohne Folgemaßnahmen ist in der Praxis wenig hilfreich.

Mögliche Nachweise

• Agenda und Protokoll
• Managementbericht
• Kennzahlen und Trendanalysen
• Entscheidungen und Aufgaben
• Nachverfolgung früherer Beschlüsse

Beispiel

Für den Zugriff auf das Administrationskonto sind ein Passwort und ein Einmalcode oder Sicherheitsschlüssel erforderlich.

In der Praxis

MFA ist eine mögliche Sicherheitsmaßnahme, aber nicht automatisch für jedes Szenario die einzige erforderliche Maßnahme. Schutzbedarf, Risiken und Anwendungsfall sind zu berücksichtigen.

Beispiel

Eine interne Richtlinie verlangt eine jährliche Überprüfung privilegierter Zugänge. Die Überprüfung wird nicht durchgeführt. Das ist eine Nichtkonformität gegenüber der eigenen Vorgabe.

In der Praxis

Eine Nichtkonformität ist nicht automatisch ein Sicherheitsvorfall. Sie muss aber bewertet, behandelt und – soweit erforderlich – auf ihre Ursache untersucht werden.

Mögliche Nachweise

• Auditfeststellung
• Abweichungsbericht
• Ursachenanalyse
• Korrekturmaßnahme
• Wirksamkeitsprüfung

Beispiel

Die Organisation plant eine Verbesserung des Patchmanagements, setzt sie um, misst die Zeit bis zur Installation kritischer Updates und passt den Prozess bei Bedarf an.

In der Praxis

Der Zyklus ist kein Projekt mit einem endgültigen Abschluss. Neue Risiken, Vorfälle, Änderungen und Auditergebnisse führen zu weiteren Verbesserungen.

Beispiel

Ein Unternehmen setzt Backups, Notfallpläne und redundante Systeme ein. Ein längerer Ausfall ist dadurch unwahrscheinlicher, aber nicht völlig ausgeschlossen. Das verbleibende Risiko ist das Restrisiko.

In der Praxis

Restrisiken sollten bewusst bewertet und durch die zuständigen Risikoeigentümer akzeptiert oder weiter behandelt werden. Eine Akzeptanz sollte nachvollziehbar dokumentiert sein.

Mögliche Nachweise

• aktualisierte Risikobewertung
• Risikobehandlungsplan
• dokumentierte Entscheidung des Risikoeigentümers
• Begründung der Risikoakzeptanz

Beispiel

Wenn ein Administrationskonto kein ausreichendes Schutzniveau besitzt, besteht das Risiko, dass ein Angreifer Systeme manipuliert oder Daten abzieht.

In der Praxis

Ein Risiko sollte konkret beschrieben werden – am besten mit Bezug zu einem Asset, einer Bedrohung, einer Schwachstelle und möglichen Auswirkungen. Vage Aussagen wie „Cyberangriff möglich“ reichen für eine gute Priorisierung meist nicht aus.

Beispiel

Ein Risiko durch fehlende Wiederherstellbarkeit wird durch getestete Backups und einen Wiederanlaufplan reduziert. Ein nicht mehr benötigter besonders riskanter Dienst wird eventuell abgeschaltet.

In der Praxis

Die ausgewählten Maßnahmen sollten aus der Risikobeurteilung und aus weiteren Anforderungen abgeleitet werden. Anschließend werden sie mit den Maßnahmen aus Anhang A abgeglichen, damit keine wichtigen Themen übersehen werden.

Mögliche Nachweise

• Risikobehandlungsprozess
• Risikobehandlungsplan
• Zuordnung von Risiken zu Maßnahmen
• Umsetzungsstatus und Verantwortliche
• Genehmigungen der Risikoeigentümer

Beispiel

Der Leiter Kundenservice ist Risikoeigentümer für die Verfügbarkeit des Kundenportals. Die technische Umsetzung von Backups kann beim IT-Team liegen.

In der Praxis

Ein Risikoeigentümer sollte ausreichend Entscheidungskompetenz und Kenntnis des betroffenen Geschäftsbereichs haben.

Mögliche Nachweise

• Risikoregister mit Eigentümer-Spalte
• Rollenbeschreibung
• Genehmigung des Risikobehandlungsplans
• dokumentierte Akzeptanz von Restrisiken

Beispiel

Ein Risiko gilt als kritisch, wenn ein Ausfall länger als 24 Stunden dauert oder wenn besonders schützenswerte personenbezogene Daten betroffen sein können.

In der Praxis

Die Kriterien sollten so klar sein, dass verschiedene Personen bei vergleichbaren Risiken zu ähnlichen Ergebnissen kommen.

Mögliche Nachweise

• Risikomethodik
• Risikomatrix
• Definitionen für niedrig, mittel, hoch und kritisch
• Risikoakzeptanzkriterien
• Freigabe der Methodik

Beispiel

Das Risikoregister zeigt, welche fünf Risiken aktuell höchste Priorität haben und welche Maßnahmen bereits umgesetzt oder noch offen sind.

Mögliche Nachweise

• aktuelles Risikoregister
• Änderungs- oder Versionshistorie
• Stichproben zu einzelnen Risiken
• Verknüpfung mit Risikobehandlungsplan und SoA

In der Praxis

Ein Vorfall sollte gemeldet, bewertet, behandelt und nachbereitet werden. Aus Vorfällen sollten Erkenntnisse für die Verbesserung des ISMS gewonnen werden.

Mögliche Nachweise

• Incident-Response-Plan
• Vorfallsmeldung und Klassifizierung
• Maßnahmen- und Kommunikationsprotokoll
• Ursachenanalyse
• Lessons Learned
• Nachweis von Tests oder Übungen

Beispiel

Die Maßnahme zur sicheren Authentisierung wird aufgenommen, weil ein Risiko durch kompromittierte Benutzerkonten besteht. Als Umsetzung werden unter anderem MFA für Administrationskonten und eine verbindliche Authentisierungsrichtlinie genannt.

In der Praxis

• Die SoA ist nicht dasselbe wie die Scope-Erklärung.
• Die SoA legt nicht fest, welche ISO-Standards für die Organisation gelten.
• Sie darf nicht nur eine unkommentierte Liste mit „ja“ oder „nein“ sein.
• Ein Ausschluss muss begründet werden.
• Die SoA sollte mit Risikoregister, Risikobehandlungsplan und tatsächlicher Umsetzung zusammenpassen.
• Die SoA muss aktuell gehalten werden, wenn sich Risiken, Systeme, Prozesse oder Anforderungen ändern.

Typische Inhalte einer SoA-Tabelle

Mögliche Nachweise

• aktuelle SoA
• Freigabe durch zuständige Verantwortliche
• Verknüpfung zur Risikoanalyse
• Risikobehandlungsplan
• Richtlinien, Verfahren und technische Nachweise
• dokumentierte Begründungen für Ausschlüsse

Beispiel

Für einen besonders schützenswerten Fernzugriff kann der Stand der Technik eine Kombination aus starker Authentisierung, sicherer Verschlüsselung, Protokollierung und laufender Überwachung nahelegen. Was angemessen ist, hängt aber vom konkreten Risiko und Kontext ab.

In der Praxis

Der Begriff ist kontextabhängig und kann sich mit der technischen Entwicklung verändern. Eine ISO-27001-Zertifizierung ist nicht automatisch für jede gesetzliche oder branchenspezifische Anforderung ausreichend.

Beispiel

Im Audit werden zehn neue Benutzerkonten und fünf Austritte aus einem definierten Zeitraum geprüft.

In der Praxis

Eine Stichprobe ist kein Freifahrtschein: Werden systematische Probleme sichtbar, kann der Prüfumfang erweitert werden.

In der Praxis

Wirksame Sicherheit entsteht oft durch die Kombination beider Arten. Eine technische Lösung ohne klare Verantwortlichkeit oder ohne geregelten Prozess kann unwirksam bleiben.

Beispiel

Die Geschäftsleitung genehmigt die Informationssicherheitspolitik, benennt Verantwortliche, stellt Budget für Maßnahmen bereit und entscheidet über relevante Restrisiken.

In der Praxis

Informationssicherheit kann nicht allein an die IT delegiert werden. Die Leitung muss sichtbar Verantwortung übernehmen.

Mögliche Nachweise

• genehmigte Informationssicherheitspolitik
• Rollen- und Verantwortlichkeitskonzept
• Budget- oder Ressourcenentscheidungen
• Managementbewertung
• dokumentierte Risikoentscheidungen

Beispiel

Eine digitale Freigabe wird mit einer eindeutigen Identität, einem Zeitstempel und einem geeigneten Protokoll dokumentiert.

Abgrenzung zur Zurechenbarkeit Zurechenbarkeit bedeutet vor allem, dass eine Aktion einer Identität oder einem Verantwortlichen zugeordnet werden kann. Nichtabstreitbarkeit geht weiter: Die Zuordnung soll später als belastbarer Nachweis dienen.

Beispiel

Das Kundenportal ist auch nach einem Ausfall der primären Infrastruktur innerhalb der festgelegten Zeit wieder erreichbar.

Typische Schutzmaßnahmen

• Backups
• Redundanz
• Notfall- und Wiederanlaufpläne
• Monitoring
• Ersatzkomponenten
• Schutz vor Überlastung und DDoS-Angriffen

Beispiel

Eine Personalakte darf nur von dafür berechtigten Personen eingesehen werden. Die Übertragung der Datei erfolgt verschlüsselt.

Typische Schutzmaßnahmen

• Berechtigungen und Zugriffskontrollen
• Verschlüsselung
• Geheimhaltungsvereinbarungen
• Klassifizierung und Kennzeichnung
• Schulungen

Beispiel

Eine Mitarbeiterin darf sich am Ticketsystem anmelden, kann aber nur die Vorgänge ihrer Abteilung sehen. Ein Administrator darf technische Einstellungen ändern, benötigt diesen Zugriff aber nicht für seine täglichen Standardaufgaben.

Mögliche Nachweise

• Berechtigungskonzept
• Rollenmatrix
• Antrags- und Genehmigungsnachweise
• regelmäßige Berechtigungsüberprüfungen
• Nachweise über Entzug von Zugängen
• Protokolle privilegierter Aktivitäten

Beispiel

Ein Administrationsprotokoll zeigt, welcher personalisierte Benutzer wann eine kritische Systemeinstellung geändert hat.

In der Praxis

• Gemeinsame Benutzerkonten erschweren die Zurechenbarkeit.
• Protokolle müssen angemessen geschützt und aufbewahrt werden.
• Es müssen klare Verantwortlichkeiten für Werte, Prozesse und Risiken bestehen.

Beispiel

Ein Mitarbeitender im Vertrieb darf Kundendaten einsehen, aber keine Benutzerkonten anlegen oder Produktionsdaten löschen.

In der Praxis

Berechtigungen sollten regelmäßig überprüft und bei Rollenwechseln oder Austritt angepasst beziehungsweise entzogen werden.