Sicherheitsüberprüfungen als Prozess Marc Ruef | 08.02.2010 Im Bereich der Informationssicherheit geniesst wohl kein Zitat solche Bekanntheit, wie jenes von Bruce Schneier: "Security is not a product; it's a process." Dieses lässt sich in zweierlei Hinsicht auf Sicherheitsüberprüfungen übertragen. So ist eine Sicherheitsüberprüfung als solche kein Produkt, welches erstellt und ohne Aufwände immerwieder genutzt werden kann. Viel mehr ist das Vorbereiten und Durchführen einer Sicherheitsüberprüfung ein fortwährender Prozess, der die individuellen Eigenarten des Auftrags (unterschiedliche Bedürfnisse) sowie die technischen Entwicklungen der Zeit zu berücksichtigen hat. Zudem sind Sicherheitsüberprüfungen nicht nur durch die Sammlung von und das Zurückgreifen auf Software und Tools definiert. Der intelligente Einsatz der jeweiligen Werkzeuge entscheidet massgeblich über die Qualität der jeweiligen Sicherheitsüberprüfung. Eine Sicherheitsüberprüfung generiert sich aus einem Bedürfnis. Das Bedürfnis ist oftmals, dass eine potentielle Bedrohung und das daraus resultierende Risiko verifiziert/falsifiziert werden will. Es gilt zu prüfen, ob und inwiefern die Auswirkungen eintreten können, wie mit diesen umgegangen werden kann und ob man sich den damit verbundenen Risiken aussetzen will. Als erstes gilt es sich sodann zu fragen, aus welchem Bedürfnis eine Sicherheitsüberprüfung angestrebt wird. Durch das Ermitteln des Bedürfnisses kann sodann der Modus der Überprüfung abgeleitet werden: * Identifikation von möglichen Schwachstellen. * Verifikation von erwarteten Schwachstellen. * Identifikation von Auswirkungen erwarteter Risiken. Es gibt drei unterschiedliche Herangehensweisen, wie sodann eine Sicherheitsüberprüfung durchgeführt werden kann. Die gern diskutierte Variante sieht vor, dass die Auditoren keinen Kontakt zu den zuständigen Stellen der zu prüfenden Umgebung halten. Damit will ein Real-World Szenario generiert werden, welches die Voraussetzungen für einen echten Angriff schafft. Dieser Ansatz führt jedoch verschiedene Probleme mit sich. Auf technischer und wirtschaftlicher Ebene kann mit diesem Blackbox-Ansatz niemals (http://www.computec.ch/comment.php?comment.news.307) die Performance einer intelligenten Zusammenarbeit erreicht werden. Die Auditoren müssen sich in mühsamer Weise mit den Eigenarten der Zielumgebung auseinandersetzen. Das technische Wissen kann erst nach einer langwierigen Datensammlung zum Zug kommen. Um diese Einschränkungen zu umgehen, empfehlen wir in den allermeisten Fällen eine sogenannte Whitebox-Herangehensweise. Dabei wird die direkte Zusammenarbeit mit den zuständigen Stellen realisiert. Diese werden über die anstehende Prüfung informiert. Dadurch wird es möglich, dass sie die Auditoren schon früh auf potentielle Mängel hinweisen können. Zusätzliche Informationen zur Zielumgebung erlauben es den Auditoren, sehr schnell und effizient die effektiven Probleme aufspüren und sich diesen widmen zu können. Je nach Definition können sodann verschiedene Testobjekte bestimmt werden. Dies können zum Beispiel das Netzwerk, Sicherheitskomponenten im Netzwerk (z.B. Router und Firewall), Betriebssystem, Server-Dienste, Applikationen oder Applikationsfunktionen sein. Es sollte hierbei eine klare Abgrenzung stattfinden. Bei einem Web Application Penetration Test wird sich zum Beispiel auf eine Webapplikation und auf Teile des Webservers konzentriert. Die Funktionalität des Betriebssystems ist zweitrangig und wird in der Regel nicht berücksichtigt. Diese klare Abgrenzung verhindert es, dass bei einem Test Diskussionen entstehen, warum Probleme in einer bestimmten Komponente, die nicht Teil der Prüfung war, nicht gefunden wurden. Die Testreihen können sodann in granularer Weise ausgearbeitet werden. Zum Beispiel kann eine Webapplikation aus Sicht eines anonymen Benutzers ohne Benutzerkonto analysiert werden. Oder aus Sicht eines legitimen Benutzers mit funktionierenden Zugangsdaten und einem normalen Benutzerstatus. Jenachdem werden hier also unterschiedliche Angreifertypen und mit ihnen Szenarien definiert. Sind die Testreihen definiert worden, generieren sich aus diesen unweigerlich die durchzuführenden Zugriffe und die dafür einzusetzenden Tools. Bei einem reinen Web Application Penetration Test werden zum Beispiel erweiterte Funktionen von nmap als Portscanner nicht benötigt. Stattdessen rücken Addons für Mozilla Firefox (http://www.computec.ch/comment.php?comment.news.308) oder CGI-Scanner in den Mittelpunkt. Die technische Durchführung einer Sicherheitsüberprüfung richtet sich nach den technischen Gegebenheiten der Zielumgebung und den anzuwendenden Tests. Diese können hier nicht in angemessenem Umfang diskutiert werden. Wir empfehlen das Konsultieren entsprechender Fachliteratur. Unabhängig davon, ob eine Blackbox- oder Whitebox-Herangehensweise gewählt wird, sollten die Betreiber der angegangenen und tangierten Umgebungen über die Prüfungen informiert werden. Durch ein explizites Definieren eines Zeitfensters können die nötigen Stellen die erforderliche Bereitschaft herstellen, um bei Problemen unmittelbar reagieren zu können (z.B. Neustart eines Systems bei einem Absturz). Durch das An- und Abmelden bei den zuständigen Stellen wird für alle Beteiligten Transparenz erreicht. Dies dient auch zum Schutz des Auditors, der bei Problemen nach einem Test darauf verweisen kann, dass diese erst nach der Abmeldung erfolgt sind und deshalb nicht direkt auf die Testzugriffe zurückzuführen sind. Wird eine Blackbox-Herangehensweise angestrebt, bei der die Arbeit von Personen geprüft wird, die nicht vorinformiert werden sollen (z.B. weil sie sonst kurzeitig Massnahmen ergreifen, die das Mass der bereitgestellten Sicherheit manipuliert), ist dennoch eine Absprache erforderlich. In diesem Fall sollten die vorgesetzten Stellen informiert werden, so dass der Test (juristisch) legitimiert wird. Dies kann zum Beispiel der zuständige Abteilungsleiter sein, der das Wissen um den Test nicht weiterzugeben kann. Bei Problemen und politischen Reibereien liegt die Verantwortung sodann bei ihm, mit seinem Team zu reden und die Probleme anzugehen. Ein Test ohne Vorinformation wird sich früher oder später immer zu Ungunsten des Auditors entwickeln. Eine Sicherheitsüberprüfung versucht Schwachstellen und Sicherheitslücken in einem System zu identifizieren. In der Regel wird das Vorgehen und die Resultate einer solchen Analyse in einem Report festgehalten. Dieser wird einerseits verwendet, um die Transparenz und Nachvollziehbarkeit der Prüfung mitzuführen. Zeitgleich wird der Report jedoch ebenfalls genutzt, um die gefundenen Mängel adressieren zu können. So werden die jeweiligen Punkte den zuständigen Stellen zugewiesen. Diese können und müssen sodann Stellung zu den Findings beziehen: * Akzeptieren: So kann es sein, dass das Risiko einer Schwachstelle aufgrund technischer oder wirtschaftlicher Komplikationen akzeptiert wird. In diesem Fall werden keine Gegenmassnahmen angegangen. * Adressieren: Soll das Risiko nicht akzeptiert werden, da Eintrittswahrscheinlichkeit und Auswirkungen zu gross sind, wird das Problem mit Massnahmen vermindert oder ganz behoben. Das Beheben eines Problems kann auf verschiedenen Ebenen stattfinden. Dies kann zum Beispiel konzeptionelle oder architektonische Änderungen an einem Produkt zur Folge haben. Oder es werden vom Hersteller bereitgestellte oder selber entwickelte Patches installiert. Können Probleme nicht direkt gelöst werden, werden sie mit flankierenden Massnahmen auf einer anderen Ebene adressiert. Dies kann zum Beispiel der Einsatz eines vorgeschalteten Firewall-Elements oder das Deaktivieren von Funktionalitäten sein. Das Umsetzen von Gegenmassnahmen kann und darf nicht Teil der Aufgabe der Auditoren sein. Aufgrund des Prinzips der Gewaltentrennung weist der Auditor lediglich auf die Mängel hin. Es ist dem Besitzer bzw. Administrator des betroffenen Produkts überlassen, ob er die Gegenmassnahmen selber umsetzen oder dies einer dritten Stelle (z.B. andere Abteilung oder Drittfirma) überlassen will. Nach dem Umsetzen der empfohlenen Gegenmassnahmen, kann ein Re-Check (wird auch als Follow-Up bezeichnet) veranschlagt werden. Bei diesem werden die zuvor kritisierten Punkte erneut geprüft, um die Funktionalität und Auswirkungen der Gegenmassnahmen zu bestätigen. Im Idealfall ist die Schwachstelle nicht mehr vorhanden und damit das Problem gelöst. Es kann jedoch auch sein, dass durch das Applizieren von Massnahmen neue Probleme aufgetan oder diese nur partiell behoben wurden (z.B. werden zwar Cross Site Scripting-Attacken mit script-Tags verhindert, jedoch können diese noch immer mit Javascript-Events durchgesetzt werden). Das Durchlaufen des iterativen Prozesses Analyse-Behebung ist so lange zu wiederholen, bis das Problem gänzlich behoben wurde.