| |||
| | | |
| |
Einleitung Artikelserie „IT-Sicherheitsaudits“ und Begriffsdefinitionen
Kontrolle und Auditierung getroffener Sicherheitsmaßnahmen sind wichtige Bestandteile eines erfolgreichen Sicherheitsmanagements. Um eine Aussage über das gebotene Maß an Sicherheit treffen zu können, werden Audits und Sicherheitsanalysen durchgeführt. Hierdurch kann festgestellt werden, welche Maßnahmen nicht ausreichend wirksam sind oder welche Maßnahmen fehlen. Doch welcher Ansatz ist der Richtige? Gibt es überhaupt den richtigen Ansatz? Was bedeutet der Begriff Audit und welche Anforderungen müssen an die Durchführung gestellt werden? Wie viel Aufwand entsteht für welche Art der Analysen, welches Mindestmaß an Ressourcen ist erforderlich? Welche Ergebnisse können von einem Audit erwartet werden? Diese und weitere Fragen sollen im Rahmen dieser Artikelserie im Detail beantwortet werden. Dabei soll der „akademische“ Anteil auf ein Mindestmaß reduziert werden, lediglich in diesem ersten einleitenden Artikel werden Begriffe und Ansätze definiert. Den Schwerpunkt bilden praxiserprobte Vorgehensweisen und Erfahrungen des Autors bei gut 30 durchgeführten Audits. Der Umgang mit technischen und organisatorischen Schwierigkeiten wird dabei ebenso beleuchtet wie die erfolgreiche Darstellung von Ergebnissen in Form von entsprechenden Berichten und Präsentationen.
Definition Penetrationstest Ein Penetrationstest ist eine Unterform von Audits, durch welchen das Vorhandensein und die Wirksamkeit von Sicherheitsmaßnahmen durch Überwindungsversuche geprüft werden. Diese Untersuchungen sind in der Regel rein technischer Natur, d. h. organisatorische Sicherheitsmaßnahmen stehen nicht im Fokus der Untersuchungen. Neben automatisierten Schwachstellen-Scans und einer manuellen Verifikation der Ergebnisse sollten sie weitere manuelle Untersuchungen unter Einsatz von Kreativität und Erfahrung beinhalten. Hierzu können so genannte Exploits , welche ggf. angepasst oder selbst entwickelt werden müssen, und spezifische Angriffstools, beispielsweise für inside-out Angriffe , verwendet werden. In vielen Fällen reicht aber auch schon ein Browser aus, um beispielsweise Schwachstellen in Webapplikationen festzustellen. In jedem Fall sollten geeignete Vorsichtsmaßnahmen (siehe unten) für mögliche Störfälle ergriffen werden. Selbst wenn manche Angriffs-Tools nicht auf „scharf“ geschaltet sind, kann eine Störung nicht vollständig ausgeschlossen werden. Definition Black-Box Analyse Eine Black-Box Analyse ist eine Unterform von Audits, wobei diese ohne Kenntnis von Sicherheitsmaßnahmen, Systemdetails, Infrastrukturen, Personen und Rollen durchgeführt wird. Sie wird also aus Sicht eines externen oder internen Angreifers konzipiert, wobei aufgrund der hohen Integration von IT-Systemen mit Partnern, Dienstleistern etc. die Unterscheidung zwischen intern und extern immer schwieriger wird. Ein interner Angreifer kann beispielsweise jeder sein, der über eine Netzverbindung verfügt, aber auch ein eigener Mitarbeiter, der in der Lage ist, Angriffstools auf seinem System zu installieren oder bereits vorhandene Werkzeuge nutzt. Black-Box Analysen sind in der Regel technisch und zeigen organisatorische oder architektonische Mängel nur implizit auf (z. B. unzureichendes Patch-Management oder einstufige Firewall-Konzeptionen). Die Begriffe „Black-Box Analyse“ und „Penetrationstest“ werden fälschlicherweise oft synonym verwendet. In manchen Fällen werden aber vorab Informationen für Penetrationstests zur Verfügung gestellt, es handelt sich in diesem Fall dann per Definition nicht um eine Black-Box Analyse. Dieser Fall wird als „Grey-Box Analyse“ bezeichnet, die Begriffe werden in der Praxis aber oft nicht unterschieden. Definition Grey-Box Analyse Im Unterschied zu einem „echten“ Angreifer, beispielsweise aus dem Internet, unterliegen Anbieter im Bereich der Sicherheitsanalysen in der Regel einem Termin- und Budget-Druck. Das Projekt soll in absehbarer Zeit durchgeführt werden und auch die zur Verfügung stehenden personellen und monetären Ressourcen sind beschränkt. Daher bietet es sich in vielen Fällen an, bestimmte Informationen zur Verfügung zu stellen. Man spricht dann von Grey-Box Analysen. Eine Informationsbeschaffung zu den Netzen eines Unternehmens und den zur Verfügung gestellten Internet-Diensten kann in der Regel ohne Unterstützung in wenigen Minuten durchgeführt werden. Anders sieht es aus, wenn beispielsweise gezielt Schwachstellen in eingesetzter Software, beispielsweise dem Internet Browser, überprüft werden sollen. Anstatt zu versuchen, über einen präparierten Webserver sämtliche Schwachstellen aller potenziell einsetzbaren Browser auszunutzen kann einige Zeit gespart werden, wenn zumindest der Typ des Browsers (Internet Explorer, Firefox, Mozilla, Opera etc.) vorab benannt wird. Falls ein Grey-Box Ansatz gewählt wird, sollte aber auf jeden Fall durch exemplarische Beispiele der Nachweis erbracht werden, dass die gelieferten Informationen bei ausreichender Zeit auch ohne Hilfestellung beschafft werden könnten und nur die Effizienz der Durchführung steigerten. Definition White-Box Analyse Im Rahmen einer White-Box Analyse haben der Auditor und das Auditor-Team (vgl. Artikel 4 der Serie) Zugang zu Informationen über Konzepte, Sicherheitsmaßnahmen, Architekturen und Rollen. Beispielsweise werden die Systemverantwortlichen oder – insbesondere bei ausgelagerten Dienstleistungen – die Betreiber in Form von Interviews und konkreten Konfigurationsprüfungen mit einbezogen. Eine White-Box Analyse erfordert daher in der Regel auch einen höheren Zeitbedarf seitens des Auftraggebers bzw. der Betreiber. Die Prüfungsbereiche sind vielfältig und sollten vorab im Detail festgelegt werden. Beispielsweise können
Bei bestimmten Fragestellungen kann ein White-Box Ansatz aber auch effizienter Antworten liefern als ein Black-Box Ansatz. Ein Beispiel: Um zu bestimmen, ob Angriffsversuche durch Brute-Force Angriffe auf Passwörter erfolgreich sind, können im Rahmen einer Black-Box Analyse entsprechende Angriffe auf Benutzerkonten durchgeführt werden. Werden diese nicht nach einer bestimmten Anzahl von Fehlanmeldungen gesperrt kann, dies ggf. über Monate hinweg erfolgen – was zumindest nachdenklich stimmen sollte, wenn es keinem auffällt. Alternativ kann man aber auch im Rahmen einer White-Box Analyse mit den Verantwortlichen die verwendete Passwortregelung diskutieren. Die Geschwindigkeit, mit welcher sich derartige Angriffe durchführen lassen, kann durch praktische Tests in wenigen Minuten bestimmt werden, z. B. durch ein kurzes Testen von einigen hundert Passwort-Möglich¬keiten. Ist die Regelung bekannt und können die Passwörter nicht durch Wörterbuchangriffe oder Social Engineering gebrochen werden, so kann die erforderliche Zeit berechnet und abgeschätzt werden. Abgrenzung der Begriffe In folgendem Schaubild sind die verschiedenen Ansätze und Begriffe zusammenfassend dargestellt: 
Referenzdokumente Mit dem Thema Sicherheitsanalysen und Penetrationstests beschäftigen sich Dokumente wie das OSSTMM (Open Source Security Testing Methodology Manual) und die BSI-Studie „Durchführungskonzept von Penetrationstests“ aus dem Jahr 2003. Zum OSSTMM lässt sich sagen, dass es oft als Vorgehensmodell im Bereich der Sicher¬heitsanalysen referenziert wird. Liest man es im Detail, kommen jedoch Unwägbarkeiten zum Vorschein. Beispielsweise ist der Detaillierungsgrad einzelner Prüfgebiete recht unter¬schiedlich und die optisch ansprechende „security map“ wirkt relativ willkürlich zusammen gestellt. Das OSSTMM bietet aber einen recht guten Einstieg zum Thema Systematik von Sicherheitsanalysen und kann auch als „Fundgrube“ zur Erstellung von eigenen Checklisten verwendet werden. Die BSI-Studie bietet ebenfalls einen ganz guten Einstieg zum Thema, wirkt aber an manchen Stellen recht theoretisch und komplizierter als erforderlich. Beispielsweise werden bei dem vorgeschlagenen Ablauf Kriterien wie „Informationsbasis“, „Aggressivität“ und „Umfang“ unterschieden. Während die Unterscheidung „Informationsbasis“, d. h. ob man Informationen seitens des Auftraggebers erhält, noch durchaus Sinn macht (Black-Box vs. White-Box, siehe oben), kann bezweifelt werden, ob eine Unterscheidung nach „vorsichtig“, „abwägend“ und „aggressiv“ zielführend ist. Es kann als Qualitätsmerkmal angesehen werden, dass ein professioneller Penetrationstester vorab geeignete Vorsichtsmaßnahmen mit den Kunden abstimmt. Bei der eigentlichen Durchführung von Angriffen sollten diese dennoch so „echt“ wie möglich angesetzt werden – schlichtweg weil ein potenzieller Angreifer hier auch keine Rücksicht nehmen würde oder ein Wurm im internen Netz sich auch nicht an Konventionen hält. Es soll aber auch nicht zum Ausdruck gebracht werden, dass der Tester möglichst willenlos auf Applikationen, Systeme und Netze „draufhauen“ soll. In manchen Fällen wird man beispielsweise nicht an Produktivsystemen testen können, wenn an diese entsprechend hohe Anforderungen an die Verfügbarkeit gestellt werden und man daher auf Testsysteme ausweichen muss. Es ist mehr oder weniger selbstverständlich, dass man durchaus an den Tester die Anforderung stellen kann, möglichst behutsam zu arbeiten und die Systeme möglichst wenig zu gefährden. Aber Einschränkungen bei der Durchführung oder Abstufungen der – man könnte es als „Angriffshärte“ bezeichnen – erhöhen nur den Ressourcenverbrauch oder mindern die Aussagekraft der Ergebnisse. Hier sollten klare Aussagen gefordert werden. Also kein „Es ist potenziell möglich, Systeme zu übernehmen.“ oder „Das System weist vermutlich Schwachstellen auf.“, sondern „Es ist zum Zeitpunkt x möglich, das System durch Exploit y zu übernehmen und sich administrative Berechtigungen zu verschaffen.“. Lediglich bei einer Verkettungsmöglichkeit von Schwachstellen kann/sollte eine Abstimmung erfolgen. Kann beispielsweise ein System in einer DMZ übernommen werden, sollten potenziell weiterführende Angriffe vor deren Ausführung abgestimmt sein. Details zur Durchführung von Black-Box Analysen und Penetrationstests werden im nächsten Artikel dieser Serie vorgestellt werden. 03/2007, Stefan Gora
| | | | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| © 1999-2010 FEiG & PARTNER | Nutzungsbedingungen | | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 | |  | |  | |  | |  | |  | |  | |  | |  | |   |
|
| ||
| know how news veranstaltungen sicherheitswarnungen | |
| ||
| ||
| ||
| ||
| ||
| ||
|
