ISO 27001 A.8.9-8.16: Schutz vor Malware, Backup und Logging

Der operative Unterbau

Während die Controls A.8.1 bis A.8.8 die grundlegenden Sicherheitsmechanismen abdecken (Endgeräte, Zugriffsrechte, Malware, Schwachstellen), gehen A.8.9 bis A.8.16 tiefer in den operativen IT-Betrieb. Sie regeln, wie Systeme konfiguriert, gesichert, überwacht und mit ausreichenden Ressourcen versorgt werden.

Für ein Unternehmen mit rund 100 Mitarbeitenden sind diese Controls oft eine Mischung aus „machen wir schon" und „haben wir nie dokumentiert". Die Herausforderung liegt weniger in der technischen Umsetzung als in der systematischen Dokumentation und der regelmäßigen Überprüfung.

A.8.9: Configuration Management

Was der Standard fordert

Konfigurationen, einschließlich Sicherheitskonfigurationen, von Hardware, Software, Diensten und Netzwerken müssen festgelegt, dokumentiert, implementiert, überwacht und überprüft werden.

Ein neues Control mit hoher Relevanz

A.8.9 ist eines der neuen Controls in der ISO 27001:2022 und adressiert ein häufiges Problem: Systeme werden installiert, konfiguriert und dann vergessen. Über die Zeit weicht die tatsächliche Konfiguration von der geplanten ab, Sicherheitseinstellungen werden gelockert, unnötige Dienste aktiviert, und niemand bemerkt es.

Umsetzung

Sichere Basiskonfigurationen (Baselines): Definiere für jeden Systemtyp (Windows-Server, Linux-Server, Windows-Clients, Netzwerk-Switches, Firewalls, Cloud-Dienste) eine sichere Basiskonfiguration. Orientiere dich an den CIS Benchmarks oder den BSI-Grundschutz-Empfehlungen.

Eine Baseline für einen Windows-Server umfasst zum Beispiel: deaktivierte unnötige Dienste, konfigurierte Firewall-Regeln, aktivierte Audit-Protokollierung, deaktivierter Remote-Desktop für Nicht-Admins, konfigurierte Passwortrichtlinien, aktivierte Festplattenverschlüsselung, aktuelle Patches.

Konfigurationsänderungen steuern: Jede Änderung an der Konfiguration eines produktiven Systems muss über den Change-Management-Prozess laufen (siehe A.8.32). Das gilt auch für scheinbar kleine Änderungen wie das Öffnen eines Firewall-Ports.

Konfigurationsüberwachung: Idealerweise werden die Konfigurationen automatisiert überwacht, sodass Abweichungen von der Baseline erkannt werden. Tools wie Microsoft Defender for Cloud, Chef InSpec, Ansible oder SCAP-Scanner können das leisten. Für ein Unternehmen mit rund 100 Mitarbeitenden ist auch ein manuelles Review der Konfigurationen in regelmäßigen Abständen (halbjährlich) ein akzeptabler Ansatz.

A.8.10: Information Deletion

Was der Standard fordert

Informationen, die in Informationssystemen, Geräten oder anderen Speichermedien gespeichert sind, müssen gelöscht werden, wenn sie nicht mehr benötigt werden.

Mehr als Datei löschen

Das einfache Löschen einer Datei entfernt nur den Verzeichniseintrag, nicht die Daten selbst. A.8.10 fordert, dass Löschverfahren dem Schutzbedarf der Daten entsprechen.

Klassifizierungsbasierte Löschung: Die Löschmethode hängt von der Klassifizierung der Daten ab. Öffentliche Daten können normal gelöscht werden. Vertrauliche Daten erfordern sicheres Überschreiben. Streng vertrauliche Daten erfordern zertifiziertes Löschen oder physische Zerstörung des Mediums.

Löschkonzept: Dokumentiere ein Löschkonzept, das für jeden Datentyp festlegt: Aufbewahrungsfrist (wie lange müssen die Daten mindestens aufbewahrt werden?), Löschfrist (wann müssen die Daten spätestens gelöscht werden?) und Löschverfahren (wie werden sie gelöscht?).

Cloud-Daten: Bei Cloud-Diensten muss sichergestellt sein, dass Daten nach Vertragsende vom Anbieter gelöscht werden. Fordere eine schriftliche Bestätigung der Löschung.

Zusammenspiel mit DSGVO: Das Löschkonzept muss mit den Anforderungen der DSGVO konsistent sein. Personenbezogene Daten dürfen nur so lange gespeichert werden, wie der Verarbeitungszweck es erfordert.

A.8.11: Data Masking

Was der Standard fordert

Datenmaskierung muss gemäß der themenspezifischen Richtlinie zur Zugangskontrolle und anderen themenspezifischen Richtlinien sowie den geschäftlichen Anforderungen der Organisation angewendet werden, unter Berücksichtigung der geltenden Gesetze.

Relevanz

A.8.11 ist ein neues Control und betrifft vor allem Unternehmen, die mit sensiblen Daten in Test- oder Entwicklungsumgebungen arbeiten. Wenn Produktionsdaten (Kundendaten, personenbezogene Daten) in Testumgebungen verwendet werden, müssen sie maskiert oder pseudonymisiert werden.

Für ein Unternehmen mit rund 100 Mitarbeitenden ist dieses Control relevant, wenn eigene Software entwickelt wird oder wenn Standardsoftware-Anpassungen mit Echtdaten getestet werden. Wenn du ausschließlich Standardsoftware ohne Anpassungen nutzt, hat das Control geringere Bedeutung.

A.8.12: Data Leakage Prevention

Was der Standard fordert

Maßnahmen zur Verhinderung von Datenlecks müssen auf Systeme, Netzwerke und andere Geräte angewendet werden, die sensible Informationen verarbeiten, speichern oder übertragen.

Umsetzung

Data Leakage Prevention (DLP) verhindert, dass vertrauliche Daten das Unternehmen unkontrolliert verlassen. Für ein Unternehmen mit rund 100 Mitarbeitenden muss DLP nicht als Enterprise-Lösung mit automatischer Inhaltserkennung umgesetzt werden. Ein pragmatischer Ansatz umfasst:

E-Mail-basierte DLP: Regeln, die das Versenden großer Dateien oder bestimmter Dateitypen an externe Empfänger blockieren oder zur Bestätigung auffordern. Microsoft 365 bietet integrierte DLP-Funktionen.

Cloud-Storage-Kontrolle: Blockierung nicht autorisierter Cloud-Speicher-Dienste. Nur freigegebene Dienste für den Datentransfer.

USB-Kontrolle: Einschränkung der Nutzung von USB-Speichergeräten.

Klassifizierungskennzeichnung: Vertrauliche Dokumente werden gekennzeichnet, sodass Mitarbeitende bewusst mit ihnen umgehen.

A.8.13: Information Backup

Was der Standard fordert

Backup-Kopien von Informationen, Software und Systemen müssen gemäß der vereinbarten themenspezifischen Richtlinie zum Backup gepflegt und regelmäßig getestet werden.

Der Backup-Plan

Ein dokumentierter Backup-Plan enthält für jedes System:

Was wird gesichert: Vollständiges System-Image oder nur Daten? Konfigurationsdateien? Datenbanken?

Wie oft: Die Backup-Frequenz muss zum RPO passen (siehe BIA). Tägliche Vollsicherung und stündliche inkrementelle Sicherungen sind für die meisten Unternehmen mit rund 100 Mitarbeitenden ein guter Standard für geschäftskritische Systeme.

Wohin: Primärer Backup-Speicher (lokal oder auf einem dedizierten Backup-Server), sekundärer Speicher an einem anderen Standort oder in der Cloud. Die 3-2-1-Regel (3 Kopien, 2 verschiedene Medien, 1 Kopie extern) ist der anerkannte Best Practice.

Wie lange: Aufbewahrungsfristen für Backups. Tagesbackups werden typischerweise 30 Tage aufbewahrt, Wochenbackups 3 Monate, Monatsbackups 1 Jahr. Die genauen Fristen hängen von regulatorischen und geschäftlichen Anforderungen ab.

Verschlüsselung: Backups, die den gesicherten Bereich verlassen (externer Standort, Cloud), müssen verschlüsselt sein.

Ransomware-Schutz: Mindestens eine Backup-Kopie muss gegen Ransomware geschützt sein. Das bedeutet: nicht vom Netzwerk erreichbar (Air Gap), unveränderlich (Immutable Backup) oder durch Zugriffsbeschränkungen so geschützt, dass ein Angreifer mit Admin-Rechten im Netzwerk die Backups nicht löschen kann.

Restore-Tests

Der entscheidende Punkt, an dem viele Unternehmen scheitern: Backups, die nie getestet wurden, sind wertlos. Regelmäßige Restore-Tests verifizieren, dass die Backups vollständig, konsistent und innerhalb des RTO wiederherstellbar sind. In ISMS Lite lassen sich Restore-Tests planen, dokumentieren und mit dem Backup-Plan verknüpfen, sodass überfällige Tests sofort sichtbar werden.

Testfrequenz: Vierteljährlich für geschäftskritische Systeme, mindestens jährlich für alle Systeme mit Backup.

Testdokumentation: Datum, getestetes System, Backup-Datum, Wiederherstellungsdauer, Ergebnis (erfolgreich/fehlgeschlagen), aufgetretene Probleme, Maßnahmen.

A.8.14: Redundancy of Information Processing Facilities

Was der Standard fordert

Informationsverarbeitungseinrichtungen müssen mit ausreichender Redundanz implementiert werden, um die Verfügbarkeitsanforderungen zu erfüllen.

Umsetzung

Die Redundanzplanung basiert auf der BIA. Systeme mit kurzen RTOs brauchen mehr Redundanz als Systeme, deren Ausfall für Tage tolerierbar ist.

Server-Redundanz: Für geschäftskritische Server (ERP, E-Mail, Datenbank): Clustering, Hot-Standby oder zumindest vorbereitete Wiederherstellungsumgebung. Virtualisierung erleichtert die Redundanz erheblich, weil VMs schnell auf andere Hosts migriert werden können.

Storage-Redundanz: RAID-Systeme für die lokale Datenhaltung. Replizierte Storage-Systeme für höhere Anforderungen.

Netzwerk-Redundanz: Redundante Switches für das Kernnetzwerk. Zweiter Internet-Provider oder Mobilfunk-Fallback.

Standort-Redundanz: Für Unternehmen mit sehr hohen Verfügbarkeitsanforderungen: ein zweiter Standort, der bei Totalausfall des primären Standorts den Betrieb übernehmen kann. Für ein Unternehmen mit rund 100 Mitarbeitenden ist das oft nicht praktikabel, aber Cloud-basierte Disaster-Recovery-Lösungen bieten eine kosteneffektive Alternative.

A.8.15: Logging

Was der Standard fordert

Logs, die Aktivitäten, Ausnahmen, Fehler und andere relevante Ereignisse aufzeichnen, müssen erstellt, gespeichert, geschützt und analysiert werden.

Warum Logging so wichtig ist

Logs sind die Grundlage für drei kritische Funktionen: Erkennung von Sicherheitsvorfällen (Monitoring), forensische Untersuchung nach Vorfällen (Incident Response) und Nachweis der Compliance (Audit). Ohne aussagekräftige Logs bist du im Blindflug.

Was geloggt werden muss

Authentifizierungsereignisse: Erfolgreiche und fehlgeschlagene Anmeldungen, Account-Sperrungen, Passwortänderungen. Diese Logs sind die erste Anlaufstelle bei der Erkennung von Brute-Force-Angriffen und unbefugten Zugriffen.

Zugriffsaktivitäten privilegierter Accounts: Alle Aktionen von Admin-Accounts müssen protokolliert werden: Systemänderungen, Benutzerverwaltung, Konfigurationsänderungen.

Systemereignisse: Start und Stopp von Diensten, Systemfehler, Sicherheitswarnungen, Firewall-Events.

Änderungen an sicherheitsrelevanten Konfigurationen: Firewall-Regeländerungen, Gruppenrichtlinienänderungen, Änderungen an Zugriffsrechten.

Datenzugriffe auf sensible Informationen: Zugriffe auf vertrauliche Dateien und Datenbanken, sofern technisch umsetzbar.

Schutz der Logs

Logs sind nur dann nützlich, wenn sie vertrauenswürdig sind. Ein Angreifer, der die Logs manipulieren kann, verwischt seine Spuren.

Zentrale Sammlung: Logs werden von den Quellsystemen an einen zentralen Log-Server oder ein SIEM-System gesendet. Dort sind sie vom Quellsystem getrennt und können nicht so leicht manipuliert werden.

Integritätsschutz: Logs werden mit Zeitstempeln und Prüfsummen versehen. Änderungen sind erkennbar.

Zugriffsbeschränkung: Nur autorisierte Personen haben Zugriff auf die Logs. Administratoren, deren Aktivitäten geloggt werden, sollten idealerweise keinen Schreibzugriff auf die Logs haben (Trennung von Pflichten).

Aufbewahrungsdauer: Definiere eine Aufbewahrungsdauer für Logs. Typisch: 90 Tage online verfügbar, 1 Jahr archiviert. Die genaue Dauer hängt von regulatorischen Anforderungen und der Speicherkapazität ab.

Log-Analyse

Logs zu sammeln und nicht auszuwerten ist fast so schlimm wie gar nicht zu loggen. Definiere, wie und wie oft Logs analysiert werden:

Automatisierte Alerts: Für kritische Ereignisse (mehrere fehlgeschlagene Anmeldungen, Admin-Aktionen außerhalb der Geschäftszeiten, Zugriff auf honeypot-Dateien) werden automatische Alerts konfiguriert.

Regelmäßige manuelle Überprüfung: Wöchentliche Stichproben der wichtigsten Logs durch die IT oder den ISB.

Anlassbezogene Analyse: Bei Verdacht auf einen Sicherheitsvorfall werden die relevanten Logs systematisch ausgewertet.

A.8.16: Monitoring Activities

Was der Standard fordert

Netzwerke, Systeme und Anwendungen müssen auf anomales Verhalten überwacht und angemessene Maßnahmen ergriffen werden, um potenzielle Informationssicherheitsvorfälle zu bewerten.

Abgrenzung zu Logging

A.8.15 (Logging) beschreibt das Aufzeichnen von Ereignissen. A.8.16 (Monitoring) geht einen Schritt weiter und fordert die aktive Überwachung und Auswertung. Logging ist passiv (aufzeichnen), Monitoring ist aktiv (erkennen und reagieren).

Umsetzung für rund 100 Mitarbeitende

Ein vollständiges Security Operations Center (SOC) ist für ein Unternehmen mit rund 100 Mitarbeitenden in der Regel nicht wirtschaftlich. Pragmatische Alternativen:

Managed Detection and Response (MDR): Ein externer Dienstleister überwacht die Systeme rund um die Uhr und alarmiert bei verdächtigen Aktivitäten. Viele EDR-Lösungen bieten MDR als Zusatzdienst an.

SIEM-Light: Ein leichtgewichtiges SIEM-System (z.B. Wazuh, Graylog) sammelt Logs zentral und wertet sie mit vordefinierten Regeln aus. Für ein Unternehmen mit rund 100 Mitarbeitenden reicht das oft aus, erfordert aber jemanden, der die Alerts auswertet.

Netzwerk-Monitoring: Tools wie Nagios, Zabbix oder PRTG überwachen die Verfügbarkeit und Performance von Systemen. Anomale Netzwerkaktivitäten (ungewöhnlich hohe Datenübertragungen, Kommunikation mit bekannten Malware-C2-Servern) werden erkannt.

Weitere Controls: A.8.11, A.8.12 und Zwischentöne

Uhrsynchronisation (implizit in A.8.15)

Alle Systeme müssen die gleiche Zeitquelle verwenden. Wenn die Uhren der Systeme abweichen, sind die Logs nicht korrelierbar. Eine forensische Analyse wird unmöglich, wenn der Firewall-Log eine andere Zeit zeigt als der Server-Log.

NTP-Konfiguration: Alle Systeme synchronisieren ihre Uhr gegen einen zuverlässigen NTP-Server (z.B. ptbtime1.ptb.de oder pool.ntp.org). Definiere in den Basiskonfigurationen (A.8.9) den NTP-Server als Standard.

Kontrolle privilegierter Hilfsprogramme

System-Utilities mit weitreichenden Rechten (Registry-Editor, Festplatten-Management, Netzwerk-Sniffer) sollten auf Endgeräten nicht für normale Benutzer verfügbar sein. Auf Servern sollte der Zugang zu diesen Tools auf die notwendigen Administratoren beschränkt und die Nutzung protokolliert werden.

Typische Audit-Findings bei A.8.9-A.8.16

Finding 1: Keine dokumentierten Basiskonfigurationen

Systeme werden installiert und konfiguriert, aber es gibt keinen dokumentierten Standard, gegen den die Konfiguration geprüft werden kann. Jeder Administrator konfiguriert nach eigenem Ermessen.

Finding 2: Restore-Tests fehlen oder sind nicht dokumentiert

Backups werden erstellt, aber es gibt keine Nachweise über regelmäßige Wiederherstellungstests. Die IT versichert, dass „alles funktionieren würde", kann das aber nicht belegen.

Finding 3: Logs werden nicht ausgewertet

Ein zentraler Log-Server existiert, aber die Logs werden nicht regelmäßig analysiert. Es gibt keine definierten Alerts und keine manuelle Überprüfung. Die Logs dienen nur der nachträglichen Analyse nach einem Vorfall, aber nicht der Erkennung.

Finding 4: Keine Redundanz für geschäftskritische Systeme

Trotz kurzer RTOs in der BIA gibt es für geschäftskritische Server keine Redundanz. Ein Festplattenausfall am ERP-Server würde zu einem mehrtägigen Ausfall führen, obwohl die BIA maximal 4 Stunden vorsieht.

Finding 5: Uhren nicht synchronisiert

Die Systemuhren weichen um mehrere Minuten voneinander ab. Log-Einträge verschiedener Systeme lassen sich zeitlich nicht korrelieren.

Wie ISMS Lite den Nachweis unterstützt

Backup-Plan-Dokumentation: Dokumentiere für jedes System den Backup-Plan inklusive Intervall, Aufbewahrungsfrist, Speicherort und RPO. ISMS Lite erinnert an fällige Restore-Tests.

Restore-Test-Protokolle: Dokumentiere Restore-Tests strukturiert mit Ergebnis und Maßnahmen — verknüpft mit dem jeweiligen Backup-Plan.

Konfigurationsstandards: Dokumentation der Basiskonfigurationen pro Systemtyp mit Verlinkung zu den betroffenen Assets.

Logging-Richtlinie: Erstelle deine Logging-Richtlinie KI-gestützt mit definierten Aufbewahrungsfristen, Log-Quellen und Analyseverfahren.

Maßnahmenverfolgung: Alle Findings und Maßnahmen werden zentral erfasst, zugewiesen und auf Wiedervorlage gesetzt.

Weiterführende Artikel

• Backup-Strategie und Restore-Tests: Datensicherung, die im Ernstfall funktioniert
• Logging- und Monitoring-Strategie: Was du protokollieren und überwachen solltest
• Datensicherung nach dem 3-2-1-Prinzip: BSI-Empfehlung umsetzen
• Change Management im ISMS: Änderungen sicher steuern
• Löschkonzept nach DSGVO: Aufbewahrungsfristen und sichere Löschung