Worum geht es?
Unzureichend geprüfte Anwendungen, Updates oder Konfigurationsänderungen führen schnell zu gravierenden Sicherheitslücken in der Produktionsumgebung. Die ISO 27002 sieht daher vor, dass Sicherheitsprüfverfahren definiert und in den Entwicklungslebenszyklus fest integriert werden.
Es geht dabei um gänzlich neue Informationssysteme, Upgrades und neue Versionen, wesentliche Änderungen der Konfiguration und dies alles auch und insbesondere hinsichtlich zugekaufter Produkte oder ausgelagerter Entwicklung.
Was empfiehlt die ISO 27002?
Sicherheitsprüfungen sollen nicht gelegentlich oder ad-hoc erfolgen, sondern verbindliche Teil des Entwicklung- und Änderungsprozesses sein. Die Norm ISO 27002 stellt in Kapitel 8.29 den Prozess auf drei Standbeine.
Sicherheitsprüfungen:
- Sicherheitsfunktionen, also sichere Benutzerauthentisierung, Zugangsbeschränkungen und den Einsatz von Verschlüsselung, wie jeweils in den entsprechenden Kapiteln der Norm beschrieben.
- Sichere Codierung, wie im Kapitel 8.28
- Sichere Konfiguration, wiederum unter Verweis auf die entsprechenden Kapitel 9, 8.20 und 8.22.
Testplanung, mit klaren und detaillierten Vorgaben:
- Ein Zeitplan sollte erstellt werden, der alle vorgesehenen Aktivitäten und Prüfungen ersehen lässt.
- Es sollte festgelegt werden, welche Eingaben unter verschiedenen Bedingungen zu welchen Ergebnissen führen sollen oder dürfen. Ein einfaches Beispiel wäre die Reaktion eines Systems auf einen fehlerhaften Anmeldeversuch, etwa „Verweigerung des Zugangs, Ausgabe Fehlermeldung, Logging“
- Für die Bewertung aller Tests sollte es klare und vorbestimmte Kriterien geben.
- Ebenso sollte eine Grundlage für Entscheidungen vorhanden sein, was im Falle von Problemen weiter passieren soll. Wird beispielsweise nachgebessert oder entscheidet das Management über den Fortgang?
- Die Verwendung von Tools zur Code Analyse oder dem Scan nach Schwachstellen legt die Norm ausdrücklich nahe.
Abnahmeprüfungen:
- Zunächst können und sollten Sicherheitsüberprüfungen durch das Entwicklungsteam erfolgen. Letztendlich sollte allerdings eine unabhängige Abnahmeprüfung verpflichtend sein.
- Die Prüfungen sollen sicherstellen, dass das System wie erwartet aber eben auch nur wie erwartet funktioniert.
- Die Norm empfiehlt hierzu insbesondere:
- Code-Reviews mit Fokus auf Sicherheitsmängel und unerwartete Eingaben,
- Schwachstellenscans zur Identifikation unsicherer Konfigurationen,
- Penetrationstests zur Aufdeckung unsicheren Codes und Designs.
Für externe Software und Dienstleistungen fordert die Norm, einen formalisierten Beschaffungsprozess. Vor allem sollen sich die Sicherheitsanforderungen klar in den geschlossenen Verträgen wiederfinden und vor jedem Kauf sollten alle in Erwägung gezogenen Produkte und Dienste anhand dieser Kriterien bewertet werden.
Dass jegliche Sicherheitsüberprüfung ausschließlich in Testumgebungen erfolgen sollte, spricht die Norm ausdrücklich aus. Diese Testumgebungen sollen selbstverständlich der Produktivumgebung möglichst nachgebildet sein. Sie können aber auch verschiedene Szenarien berücksichtigen, beispielsweise je nachdem ob es um Funktionalität oder Stabilität geht.
Fazit
Sicherheitsprüfverfahren sind kein nice-to-have, sondern eine Grundvoraussetzung. Ungeprüfter oder nur oberflächlich geprüfter Code in der Produktion führt schnell zu Schwachstellen, die erfahrungsgemäß auch zunehmend ausgenutzt werden.
Organisationen sollten daher zeitnah prüfen,
- ob Sicherheitsprüfungen verbindlich in allen Entwicklungs- und Änderungsprozessen verankert sind,
- ob Testpläne, Tools und Testumgebungen den Anforderungen aus Kapitel 8.29 entsprechen,
- ob unabhängige Abnahmeprüfungen tatsächlich stattfinden – auch bei Drittsoftware und ausgelagerter Entwicklung.
Wo Lücken bestehen, sollten Verantwortliche konkrete Maßnahmenpläne aufsetzen: Prozesse anpassen, Rollen und Verantwortlichkeiten klären, geeignete Tools einführen und die Qualität der Testumgebungen erhöhen. Nur so lässt sich sicherstellen, dass neue oder geänderte Systeme nicht zur Schwachstelle, sondern zum stabilen Bestandteil der Informationssicherheit werden.