Worum geht es?
Bei Audits ist regelmäßig Zugriff auf Systeme und Daten notwendig: Ernstzunehmende Auditoren wollen Nachweise statt Behauptungen sehen. Das ist richtig und sinnvoll, kann aber Risiken erzeugen, insbesondere wenn während der Prüfungssituation üblicherweise gültige Beschränkungen oder Vorgehensweise außer Acht gelassen werden. Deshalb verlangt die Norm klare Regeln, wer was auf welche Weise prüfen darf.
Das Ziel des Controls ist, bei Prüfungen belastbare Nachweise zu liefern, ohne Vertraulichkeit oder Integrität zu gefährden, ohne Schadsoftware einzuschleppen und ohne die Verfügbarkeit produktiver Systeme unnötig zu beeinträchtigen.
Was empfiehlt die ISO 27002?
Gemäß Kapitel 8.34 der ISO 27002 sollten Auditprüfungen und vergleichbare Vorgänge organisatorisch und technisch so gesteuert sein, dass der Zugang zu Systemen und Daten angemessen autorisiert, auf den notwendigen Umfang begrenzt, möglichst nicht-invasiv (idealerweise Read-only) und vollständig nachvollziehbar ist. Wenn Prüfungen die Systemverfügbarkeit beeinflussen könnten, sind dafür geeignete Zeitfenster und Schutzmaßnahmen festzulegen.
Prüfungsanträge mit zuständigem Management abstimmen
Zugriffe für Audits sollten vorab mit den verantwortlichen System-/Datenverantwortlichen genehmigt und koordiniert werden. Zweck, Zeitraum und Scope sollten feststehen und freigegeben werden. Die Benennung von Ansprechpartnern, die für Auskünfte oder falls etwas schief geht, während des Audits bereitstehen, ist sinnvoll.
Umfang technischer Tests vereinbaren und steuern
Welche Systeme, welche Tests, welche Tools, welche Zeiten und welche Daten werden geprüft? Was wird nicht geprüft? Eine klare Agenda, auch gegebenenfalls mit Grenzen, ist sinnvoll. Beispielsweise sollten Last- oder Penetrationstests nicht während laufender Produktion oder auf definierte IPs oder Accounts begrenzt sein.
Tests im Audit möglichst auf reinen Lesezugriff beschränken
Audits sollten so gestaltet sein, dass keine Daten oder Systeme verändert werden. Wenn Read-only nicht möglich ist, sollte ein erfahrener Administrator die Prüfung stellvertretend durchführen. Nach Möglichkeit sollte der Auditor nie selbst Hand anlegen. Alle notwendigen Kommandos sollten von eigenem Personal eingeben werden. Der Auditor beobachtet all dies nur.
Sicherheitsanforderungen für zugreifende Geräte festlegen und prüfen
Insbesondere wenn für externe Geräte Zugriffsmöglichkeiten geschaffen werden müssen, sollten dafür Mindestanforderungen (z. B. Virenschutz, Patchstand) definiert sein und die Umsetzung vorab überprüft werden.
Abweichende Zugriffe nur für isolierte Kopien – danach löschen oder schützen
Schreib-/Adminrechte sollten (wenn überhaupt) nur auf isolierten Kopien von Systemdateien zugelassen werden. Nach Abschluss sollten solche Sonderbefugnisse schnellstmöglich wieder entfernt werden. Zum Nachweis erforderliche Dokumentationen sind vorzuhalten.
Besondere oder zusätzliche Bearbeitung genehmigen
Anträge auf spezielle Prüfungen (z. B. Einsatz von Audit-Tools) sollten bewertet und freigegeben werden. Beispielsweise sollten keinerlei Scripte, mit denen die Verwundbarkeit getestet werden soll, ungeprüft ausgeführt werden. Ein vorausgehender Test in Staging- oder Testsystemen kann sinnvoll sein.
Prüfungen mit potenzieller Beeinträchtigung der Verfügbarkeit außerhalb der Geschäftszeiten durchführen
Wenn durch Maßnahmen in Rahmen von Audit produktiv genutzte Systeme spürbar belastet werden könnten, sollten dafür geeignete Wartungsfenster genutzt werden. Große Log-Exporte oder intensive Datenbank-Queries sollten ggf. nachts oder am Wochenende erfolgen. Eine Abstimmung mit Change-Management und Wartungsplänen ist geboten.
Alle Audit-Zugriffe überwachen und protokollieren
Zugriffe für Audit- und Prüfzwecke sollten nachvollziehbar geloggt und bei Bedarf im Detail ausgewertet werden (inkl. wer, wann, womit, worauf zugegriffen hat). Es muss etwa nachvollziehbar sein, welches Konto im Audit genutzt wurde. An einem SIEM sollten keine Auditvorgänge vorbeigehen. Ggf. ist eine Aufnahme von Auditsitzungen am genutzten Jump-Host geboten. All dies ermöglicht auch einen erforderlichen Review der Logs im Nachgang des Audits.
Fazit
Audits, die belastbare Nachweise liefern, sind oft notwendig, aber gleichzeitig ein potenzielles Risiko. In möglicherweise stressigen Situationen kann schon ein kurzer Admin-Zugang oder ein ungetestetes Audit-Tool erhebliche negative Folgen haben.
Wer Audits im Wesentlichen wie Change- und Access-Requests versteht, reduziert Sicherheits- und Compliance-Risiken deutlich – und macht auch die Auditergebnisse besser reproduzierbar.
Organisationen sollten daher prüfen,
- ob Audit-Zugriffe und Prüfungsanträge formal beantragt, durch die zuständigen Rollen freigegeben und begleitet werden,
- ob der technische Prüfungsumfang vorab vereinbart ist und während der Durchführung gesteuert wird,
- ob Prüfungen grundsätzlich als Read-only umgesetzt sind und – falls nicht möglich – ein erfahrener Administrator die notwendigen Schritte stellvertretend ausführt,
- ob Geräte, über die auf Systeme zugegriffen wird, vorab definierte Sicherheitsanforderungen erfüllen oder ob ggf. über Jump-Hosts oder Virtual Desktop Infrastructure gearbeitet wird,
- ob isolierte Kopien/Exports (falls benötigt) nach Abschluss gelöscht oder bei Aufbewahrungspflichten sicher geschützt und nachvollziehbar abgelegt werden,
- ob besondere Bearbeitungen (z. B. Audit-Tools, Scanner, Skripte) risikobasiert bewertet und vor Einsatz genehmigt werden,
- ob potenziell die Verfügbarkeit beeinträchtigende Prüfungen in geeigneten Wartungsfenstern stattfinden und Monitoring- bzw. Incident-Bereitschaft geklärt sind,
- ob alle Audit-Zugriffe zentral überwacht und protokolliert werden (wer/was/wann/wo) und die Protokolle in die Audit-Dokumentation einfließen.