Myst - stock.adobe.com
Anwendungen systematisch auf Schwachstellen untersuchen
Sicherheitstests bei produktiv genutzten Systemen führen zu anderen Ergebnissen als in nicht-produktiven Umgebungen. Wo liegen die Vor- und Nachteile der ermittelten Daten?
Verlässliche Tests der Sicherheit Ihrer Anwendungen sind keine leichte Aufgabe. Eine der dabei wichtigsten Fragen ist, welche Systeme überhaupt auf Schwachstellen untersucht werden sollten? Nur die Anwendungen in der Entwicklungsumgebung? Die in der Staging-Umgebung oder erst die auf den produktiv eingesetzten Systemen? Oder gar eine Kombination aus diesen Situationen?
Viele Unternehmen entscheiden sich zunächst dafür, nur ihre produktiv genutzten Anwendungen zu testen. Das führt zu Missverständnissen, wenn es um die Bedeutung und die Akzeptanz von Tests der nicht-produktiven Systeme geht. Viele Firmen sind sich nicht über die Risiken mangelnder Untersuchungen bewusst oder es ist ihnen gleichgültig, weil sie selbst nicht von den Auswirkungen betroffen sind.
Verschiedene Perspektiven berücksichtigen
Was sollte also getestet werden? Wenn man die betroffenen Manager, die Unternehmensziele und die technischen Schwierigkeiten mit in seine Überlegungen einbezieht, kann man die Frage nicht so leicht beantworten. Firmen aus unterschiedlichen Branchen haben teilweise stark voneinander abweichende Voraussetzungen und Vorgehensweisen, wenn es um ihre jeweilige Risikobereitschaft und die Verwaltung ihrer Security-Programme geht.
Das Testen von produktiv genutzten Systemen ergibt die weitestgehend realistische Sichtweise auf die aktuelle Situation und wie sie möglicherweise von Angreifern ausgenutzt werden kann. In einer einfach gestrickten Welt würden sich die meisten Unternehmen deswegen nur auf die Analyse ihrer produktiven Systeme beschränken und damit auch gut fahren. Es gibt aber einige wesentliche Aspekte, die dabei außer Acht gelassen werden. Dazu gehören:
- negative Auswirkungen auf die Leistung der untersuchten Systeme,
- potentielle Serviceunterbrechungen,
- mögliche E-Mail-Fluten, die durch Webformulare ausgelöst werden, die nicht durch Captchas geschützt sind,
- das Risiko, das die Datenbanken mit sinnlosen Daten gefüllt werden, die nicht so leicht wieder entfernt werden können,
- ein möglicher Zugriff auf sensible Informationen und Quellcode durch externe Partner und
- der Verbrauch von Ressourcen aus den Bereichen IT, Sicherheit und Entwicklung, um sicherzustellen, dass die geprüften Systeme während der Tests auch wirklich weiter stabil laufen.
Auch wenn es also viele Einschränkungen und Hürden zu meistern gibt, wenn es um die Tests von produktiven Systemen auf Sicherheitslücken geht, lässt sich damit doch das zuverlässigste Bild der aktuellen Lage zeichnen. Nur so erfahren Sie, wie sich aktuelle Änderungen am Code einer Applikation in der Praxis und in der realen Welt auswirken.
Das ändert aber nichts daran, dass auch Tests nicht-produktiv genutzter Systeme aus der Entwicklung, der Qualitätssicherung und dem Staging-Bereich einen hohen Wert haben und nicht vernachlässigt werden sollten. Viele Praktiker entscheiden sich deswegen dafür, ihre nicht-produktiven Systeme ebenfalls zu testen, da dies einen weit geringeren Einfluss auf ihre produktiv genutzten Anwendungen hat.
Abweichende Testergebnisse
Diese Tests nicht-produktiver Systeme geben aber nicht notwendigerweise ein Bild der tatsächlichen Umgebung wieder. Das liegt daran, dass viele dieser Umgebungen eine andere technische Basis als die produktiven Systeme haben. So laufen sie nicht immer auf demselben Server-Betriebssystem und selbst wenn, dann haben sie nur selten exakt dieselben Patches installiert. Dazu kommen unterschiedliche Konfigurationen auf dem Anwendungs- und Server-Level, so dass es meist der Fall ist, dass bei Penetrationstests teilweise sehr voneinander abweichende Ergebnisse anzutreffen sind. Das gilt gerade dann, wenn produktive mit nicht-produktiven Systemen verglichen werden sollen.
Die Verbindung nicht-produktiver Systeme mit dem Internet, um sie auf Schwachstellen zu testen, kann zu weiteren Problemen führen. So werden diese Systeme unnötigen Gefahren ausgesetzt. Das trifft insbesondere dann zu, wenn bekannt unsicherer Code, fehlende Patches oder nur schlecht abgesicherte Daten verwendet werden.
Weitere Fragen, die Sie sich stellen sollten: Wenn Sie Ihre nicht-produktiven Systeme auf Schwachstellen testen, wird diese Tatsache dann auch in Ihrem abschließenden Bericht erwähnt? Lässt sich das Ergebnis direkt auf die produktiv genutzte Umgebung übertragen? Wenn Sie bei Ihren Tests in einer nicht-produktiven Umgebung auf Sicherheitslücken stoßen, dann sollten Sie auf jeden Fall auch umgehend Ihre produktiven Systeme auf diese Schwachstellen prüfen. Das ist vor allem dann wichtig, wenn es um die Bereiche SQL Injection, Cross Site Scripting und fehlende Server-Patches geht.
Die Ausführungen zeigen, dass es keine definitive Antwort auf die Frage gibt, welche Umgebung sich besser für Tests auf Schwachstellen eignet. Möglicherweise ist die Antwort, nur Ihre produktiv genutzten Systeme zu testen oder doch lieber die nicht-produktiven Umgebungen oder aber auch eine Kombination aus beiden. Das Wichtigste ist dabei aber, überhaupt erst einmal dafür zu sorgen, dass Application Security Tests durchgeführt werden und dass die notwendigen Kontrollen existieren, damit die dabei gefundenen Probleme auch tatsächlich behoben werden.
Setzen Sie sich deshalb möglichst bald mit den richtigen Kollegen in den Bereichen IT, Security und anderen relevanten Fachbereichen zusammen, um verlässliche Standards für die durchzuführenden Tests zu entwickeln. Auf diese Weise sorgen Sie dafür, dass Sie die passenden Antworten parat haben, wenn sich Ihre Kunden, Geschäftspartner oder auch Auditoren nach den von Ihnen durchgeführten Tests auf Anwendungssicherheit erkundigen.
Folgen Sie SearchSecurity.de auch auf Twitter, Google+, Xing und Facebook!
