Der externe Auditor startet einen Schwachstellenscan auf dem Produktionsserver — mitten am Vormittag, während 300 Benutzer mit dem System arbeiten. Die Datenbank wird durch die Scan-Last überlastet, das ERP reagiert nicht mehr, und der Helpdesk registriert 47 Störungsmeldungen in 20 Minuten. A.8.34 verlangt, dass Audit- und Prüfungsaktivitäten so geplant und durchgeführt werden, dass ihre Auswirkungen auf den operativen Betrieb minimiert werden.
Die Kontrolle schützt die Verfügbarkeit und Integrität der Produktionssysteme vor unbeabsichtigten Nebenwirkungen von Prüfungstests.
Was verlangt die Norm?
- Mit dem Management koordinieren. Audit-Zugang und Testumfang werden vorab mit den zuständigen Managern abgestimmt.
- Umfang und Art der Tests kontrollieren. Nur die vereinbarten Systeme, Methoden und Zeiträume.
- Nur-Lese-Zugriff bevorzugen. Wo möglich, Nur-Lese-Zugriff für Auditoren, um versehentliche Änderungen zu vermeiden.
- Testgeräte absichern. Geräte, die Auditoren für Tests verwenden, müssen sicher konfiguriert sein.
- Systemdateien schützen. Sorgfältiger Umgang mit Systemdateien und Überwachung aller Zugriffe.
- Tests außerhalb der Geschäftszeiten. Aktivitäten, die die Verfügbarkeit beeinträchtigen könnten, werden außerhalb der Hauptnutzungszeiten durchgeführt.
In der Praxis
Audit-Testplan erstellen. Vor jedem Audit: Testplan mit Umfang, Zeitfenster, Testmethoden und verantwortlichen Kontaktpersonen. Der Plan wird vom IT-Betrieb freigegeben. Bei Penetrationstests: zusätzlich Rules of Engagement.
Zeitfenster mit dem Betrieb abstimmen. Lasttests, Schwachstellenscans und andere potenziell störende Aktivitäten werden außerhalb der Spitzenzeiten durchgeführt. Wenn das nicht möglich ist, werden die betroffenen Abteilungen vorab informiert.
Auditoren-Zugriff kontrollieren und protokollieren. Temporäre Accounts mit minimalen Rechten, zeitlich begrenzt, vollständig protokolliert. Nach Abschluss des Audits werden die Accounts deaktiviert und die Logs archiviert.
Ergebnisse sicher behandeln. Audit-Berichte enthalten oft detaillierte Informationen über Schwachstellen. Diese Berichte werden als vertraulich klassifiziert und nur an autorisierte Personen verteilt. Elektronische Kopien werden verschlüsselt.
Typische Audit-Nachweise
- Audit-Testpläne — dokumentierte Pläne mit Umfang und Zeitfenstern (→ Richtlinie sichere Softwareentwicklung im Starter Kit)
- Rules of Engagement — schriftliche Vereinbarung vor Penetrationstests
- Zugriffsprotokolle — Nachweis der temporären Audit-Zugänge
- Genehmigungsnachweise — dokumentierte Freigabe durch das Management
- Nachbereitungsprotokolle — Bestätigung der Account-Deaktivierung und Datenbereinigung nach dem Audit
KPI
Anteil der Audit-Tests mit dokumentierten IS-Schutzmaßnahmen
Gemessen als Prozentsatz: Wie viele deiner Audit-Tests wurden mit dokumentiertem Testplan, Genehmigung und Schutzmaßnahmen durchgeführt? Ziel: 100%.
Ergänzende KPIs:
- Anzahl der betrieblichen Störungen durch Audit-Tests (Ziel: 0)
- Anteil der Pentests mit schriftlichen Rules of Engagement (Ziel: 100%)
BSI IT-Grundschutz
- ISMS.1 (Sicherheitsmanagement) — übergreifende Anforderungen an Audit-Aktivitäten im Rahmen des ISMS.
- DER.3.1 (Audits und Revisionen) — Planung und Durchführung von Audits, einschließlich Abstimmung mit dem Betrieb.
- DER.3.2 (Revision auf Basis des BSI-Grundschutzes) — spezifische Anforderungen für BSI-Grundschutz-Revisionen.
Verwandte Kontrollen
- A.8.8 — Verwaltung technischer Schwachstellen: Schwachstellenscans als regelmäßige Aktivität vs. Audit-Scans als Prüfungsinstrument.
- A.8.32 — Änderungsmanagement: Audit-Tests, die Konfigurationsänderungen erfordern, folgen dem Change-Prozess.
- A.5.35 — Unabhängige Überprüfung der Informationssicherheit: Der organisatorische Rahmen für Audits und Revisionen.
Quellen
- ISO/IEC 27001:2022 Annex A, Control A.8.34 — Schutz von Informationssystemen während der Prüfungstests
- ISO/IEC 27002:2022 Abschnitt 8.34 — Umsetzungshinweise
- BSI IT-Grundschutz, DER.3.1 — Audits und Revisionen