Sicherheit über den Development Lifecycle hinweg Software Security Testing nach OWASP

Sicherheitstests sind in der Welt der Softwaretests eine eigene Disziplin. Für das Web Application Testing stellt das OWASP ein anerkanntes Rahmenwerk bereit, das beim Aufbau einer unternehmensweiten Testkultur sowie ganz konkreter Prozesse helfen kann.

Anbieter zum Thema

Arvato Systems

SEPPmail - Deutschland GmbH

Outpost24 GmbH

Das Open Web Application Security Project (OWASP) ist bekannt für Rahmenwerke, Projekte, Checklisten und Software, die sich speziell mit der Sicherheit von Webanwendungen befassen. Dementsprechend bezieht sich auch des OWASP Testing Guide auf Webapplikationen. Die darin enthaltenen Grundlagen sind mit Blick auf Ablauf und Dimensionen aber auch für Offline-App-Entwickler und -Tester interessant.

Der Guide gliedert sich grob in drei Teile: Zunächst werden die Grundlagen und Voraussetzungen für erfolgreiches Testing aufgespannt, die auch Inhalt dieses Artikels sind. Im nächsten Teil wird das OWASP Testing Framework vermittelt, das ein konkretes Phasenmodell vorstellt und dies auch im Software Development Life Cycle (SDLC) verortet. Der dritte Teil wird dann noch konkreter und zeigt detailliert auf, wie auf einzelne Bedrohungen getestet wird (beispielsweise „Testing for weak password policy”).

Die weiteren Teile sollten Sie an die Hand nehmen, wenn Sie ganz konkret mit der Implementierung von Security-Tests beginnen. Zunächst sollte aber klar sein, was überhaupt getestet werden muss, wer das wann erledigt und welche grundsätzlichen Techniken überhaupt zur Verfügung stehen – und zwar auf Management-Level.

Einleitung

Eine erste wichtige Frage lautet, was überhaupt getestet werden soll. Als ITler neigt man ja schnell zu einer rein technischen Sichtweise. Für sichere Software gilt jedoch wie schon beim Entwicklungsprozess: Es geht um Menschen, Prozesse und Technologie. Denn alle drei Teile können für Sicherheitslücken sorgen, ein falsch qualifizierter Mitarbeiter oder ein Prozess ohne Puffer ebenso wie eine unsichere Bibliothek.

Die nächste große Frage gilt dem Wann. Traditionell wird getestet, sobald ein gewisses Entwicklungsstadium erreicht ist, ein „testbares Produkt” vorliegt. Das OWASP empfiehlt kontinuierliches Testen über den gesamten SDLC. Eher weiche Aspekte wie Mitarbeiter und Prozesse lassen sich teils freilich bereits vor der ersten Zeile Code testen.

Entwickler führen während des Codens ohnehin Smoke-/Unit-Tests durch und je mehr Code entsteht und integriert wird, desto größer wird auch die Testoberfläche. Bis schließlich die Software als Ganzes zur Verfügung steht und der eigenständige, traditionelle Testing-Workflow einsetzen kann – hier verdingen sich dann eher die Tester, nicht mehr die Entwickler. Wichtig ist vor allem, andauernde Tests von Vornherein in den SDLC einzuplanen.

An dritter Stelle steht schließlich die Frage: Was soll überhaupt erreicht werden? Das sollte bereits klar sein, bevor ein Test gefahren wird. Die Ableitung von Zielen, von konkreten Anforderungen und letztlich Tests muss über die reichlich vorhandenen Ressourcen laufen. Das OWASP behandelt diesen Themenbereich sehr ausführlich.

In Kürze aber heißt das einfach: Es sollen alle verfügbaren Ressourcen wie Gefährdungslisten (OWASP Top 10), nationale Regulierungen (IT-Grundschutz in Deutschland) und sonstige Rahmenwerke hinzugezogen werden. Einerseits um vollständig, andererseits um kompatibel mit marktüblichen Standards zu sein. Wichtig hier: Alle Ziele und Test- und Sicherheitsanforderungen müssen detailliert dokumentiert werden.

Prinzipien/Mindset

Wie auch bei vielen anderen Publikationen legt das OWASP viel Wert auf die richtige Einstellung zum Thema, ein grundlegendes Verständnis oder wie es im Management gerne heißt Mindset. Dazu werden zwölf Prinzipien aufgestellt, die man durchaus im Hinterkopf behalten sollte. Viele sind weitestgehend selbsterklärend, daher hier nur in aller Kürze:

• No Silver Bullet: Es gibt nicht die eine ultimative Waffe in Form eines Vulnerability Scanners oder sonst einer Tool-Lösung – Sicherheit ist ein Prozess, kein Produkt.

• Strategisch, nicht taktisch: Nicht bloß am Ende testen und patchen, sondern über den gesamten SDLC Security-Testing-Prozesse implementieren.

• SDLC is King: Es gibt etablierte SDLC-Frameworks, die genutzt werden und die Richtung klar vorgeben sollten.

• Oft und früh testen: Auf lange Sicht sind früh erkannte Bugs günstiger zu beseitigen und sorgen für weniger Verzögerungen im SDLC.

• Security-Anforderungen verstehen: Die unterschiedlichen Sicherheitsanforderungen einzelner Phasen und Bestandteile, zum Beispiel durch nationale Vorgaben, sollten sauber dokumentiert werden.

• Richtige Sichtweise entwickeln: Schauen Sie über den Tellerrand, denken Sie wie ein Hacker – wie könnte die Software missbraucht werden?

• Das Subjekt verstehen: Die Dokumentation der Software (Anforderungen, Flussdiagramme, Use-/Misuse-Cases etc.) sollte ausführlich und formal erstellt und Testern zugänglich gemacht werden.

• Die richtigen Tools: Security-Testing-Werkzeuge sind oft hoch spezialisiert und sollten entsprechend sorgfältig ausgewählt werden.

• Der Teufel steckt im Detail: Oberflächliche Black-Box-Tests vermitteln schnell falsche Sicherheit – Hacker verbeißen sich gerne in Details, folglich sollten dies auch die Tester.

• Quellen nutzen: Wann immer möglich, sollte mit dem Source Code getestet werden, nicht bloß Black-Box-Tests mit Binaries.

• Metriken entwickeln: Für die langfristige Beurteilung und Verbesserung des Security-Testing-Prozesses sollten Metriken aufgestellt werden, die zum Beispiel quantitative Merkmale wie Anzahl der gefundenen Sicherheitsprobleme, aber auch weiche Merkmale wie nicht vorhandene Skills beim Personal aufzeigen.

• Dokumentation: Alle Aktivitäten und Resultate sollten formal festgehalten werden. Wer hat wann was gemacht und was dabei herausgefunden? Da kreatives Schreiben nicht unbedingt die Kernkompetenz von Testern und Entwicklern darstellt, empfiehlt das OWASP konkrete Vorlagen.

Techniken

Das OWASP unterscheidet vier unterschiedliche Test-Arten oder -Techniken, die jeweils Vor- und Nachteile haben, unterschiedlich geschulte Mitarbeiter erfordern und vorzugsweise in Kombination eingesetzt werden sollten – was aber nicht immer möglich ist.

Manuelle Inspektionen und Reviews

Die Technik der Wahl hier: Fragen. Es geht darum, Prozesse und Personal daraufhin zu testen, ob die nötigen Skills vorhanden sind, ob Prozesse richtig umgesetzt werden, ob der jeweilige Produktionsschritt und die Sicherheitsbelange verstanden werden, ob die Dokumentation ordnungsgemäß durchgeführt wird und so weiter.

Solche Tests können früh in den SDLC implementiert werden, erfordern keinerlei technologische Unterstützung, fördern (bestenfalls) das Teamwork und sind flexibel – daher aber auch sehr zeitintensiv. Zudem sind sie massiv von den zwischenmenschlichen Fähigkeiten der jeweiligen Tester abhängig.

Threat Modeling

Dieser eher neue Ansatz ist kein Garant für gute, sichere Software, sondern verhindert eher Überraschungen der Marke „Wieso haben wir das nicht kommen sehen?” Es geht darum, die Software nicht als Entwickler oder Tester zu betrachten, sondern als Hacker. Das OWASP vergleicht es mit dem Requirements Assessment: Risk Assessment soll Modelle für den Missbrauch erschaffen und so Mitigationsstrategien eröffnen. Technische Hilfe für diese Tests gibt es zum Beispiel von der Carnegie Mellon University.

Source Code Reviews

Quelltext-Untersuchungen sind unerlässlich für Software-Sicherheit. Sie bringen eine unvergleichliche Vollständigkeit in die Untersuchungen, sind sehr akkurat, lassen sich recht früh im SDLC unterbringen und im besten Falle sind sie auch sehr schnell. Dafür bedarf es jedoch hoch qualifizierter Reviewer. Auf der Seite der Nachteile stehen Runtime-Fehler und möglicherweise zugehörige, nicht quelloffene Bibliotheken – so werden komplette Quellcodebegutachtungen nur bei eigenen Projekten und hundertprozentiger Open Source Software funktionieren.

Penetration Testing

Pen-Testing ist der Klassiker. Bei diesem Black-Box-Testing geht es darum, eine Software von außen anzugreifen, zu penetrieren – sich also als feindlicher Hacker zu betätigen. In der Netzwerksicherheit können Pen-Tests sehr gut dafür sorgen, dass typische Angriffe nicht funktionieren, Script-Kiddies keine Chance haben und die Software allgemein ordentlich funktioniert. Solche Tests können, auch dank hoch integrierter Werkzeugkästen wie Metasploit, von verhältnismäßig niedrig qualifiziertem Personal übernommen werden und laufen sehr zügig ab. Allerdings lassen sie sich erst ganz am Ende des SDLC durchführen – zu spät für das Konzept kontinuierlichen Testens.

Reporting

Alle Testplanungen, Black- und White-Box-Tests und alle erhobenen Daten sind nichts wert, wenn nicht auch ein vernünftiges Reporting daraus resultiert. Es müssen die anfangs festgehaltenen Ziele und Anforderungen mit den erhobenen Daten abgeglichen und auf ein verständliches Maß gebracht werden.

Beispielsweise ist es gut und schön, Sicherheitslücken im Source Code Review gefunden und über Pen-Tests bestätigt zu haben. Aber wie bedrohlich ist dieser Bug überhaupt? Für die gesamte Risikoanalyse, die neben besserem Code natürlich ebenso ein Ziel des ganzen Security Testings ist, müssen wie üblich Ist- mit Soll-Daten zusammengebracht werden. Auch rein quantitative Werte wie die Anzahl gefundener Bugs können hier einfließen, um eine allgemeine Aussage über die Qualität von Software zu machen.

Darüber hinaus führt das Reporting auch zu Aussagen über die Qualität des SDLC beziehungsweise des Security Testings selbst: Wie schneidet beispielsweise nur via Black-Box-Testing (etwa externe Pen-Tester) geprüfte Software im Vergleich mit nach allen Regeln der Kunst geprüfter Software ab? Bringt der komplexe Testing-Prozess tatsächlich messbare Vorteile?

Das OWASP gibt noch allerhand konkrete Hinweise, welche Daten für welche Zielgruppen vermittelt werden sollten; beispielsweise wie sich gefundene Bugs auf Geschäftsvorfälle auswirken können. Letztlich geht es einfach darum, auch die unliebsame Aufgabe des Reportings mit der gleichen Sorgfalt zu planen und zu betreiben, wie das eigentliche Testing. Reports sind gewissermaßen die Schnittstelle zwischen Technikern (Tester, Entwickler) und Managern (CIO, CISO, IT-SiBe) – und eine API würde man ja auch mit entsprechender Muße angehen.

(ID:45787231)