Anfang und Ende eines Security Tests
Marc Ruef | 29.07.2013

Ich habe schon mehrfach betont, dass ich enthusiastische Amateuere mag (http://www.computec.ch/news.php?item.390). Sie sind es nämlich, die am ehesten die grossen und unkonventionellen Revolutionen in einem Fachbereich provozieren können. Und nicht die alteingesessenen Herren - zu denen gehöre ich vielleicht auch langsam -, die sich an Konventionen orientieren und auf ihren Lorbeeren ausruhen.

Dennoch neigen Amateure gerne dazu, die vollumfängliche Tragweite einer professionellen Abarbeitung zu unterschätzen. Dies ist ständig und sehr gut im Bereich des Security Testing, spezifisch beim Penetration Testing, zu beobachten.

Gut und gerne empfindet ein Laie als Kernstück eines Tests, die eigentlichen technischen Zugriffe. Also das Nutzen und Einsetzen von vorgefertigten oder angefertigten Tools, um Schwachstellen finden und ausnutzen zu können. Selbstverständlich sind sie das Herzstück einer entsprechenden Prüfung. Doch damit ein Test sein übergeordnetes Ziel erreichen kann, nämlich das Verbessern der Sicherheit einer Umgebung, müssen auch noch andere Aspekte berücksichtigt werden.

Dazu gehört ein gutes Projektmanagement, das Einhalten von abgemachten Terminen und das Aushändigen eines detaillierten Reports. Meine Erfahrung ist, dass umso begabter und vernarrter ein Tester in die technischen Details ist, desto grösser ist das Risiko, dass er das Drumherum ignoriert oder gar verachtet. Dabei wird unweigerlich vergessen, dass sie das Gerüst eines erfolgreichen Projekts darstellen.

Ein fehlendes oder fehlerhaftes Projektmanagement führt zu unnötigen Turbulenzen, die das technische Arbeiten verunmöglichen können. Wenn nämlich Termine nicht richtig platziert oder Schnittstellen schlecht definiert wurden. Ganz schnell kann dann oftmals der Zeitplan nicht eingehalten werden, wodurch gewisse Testzugriffe unter Umständen gar nicht mehr durchgeführt werden dürfen (z.B. weil der Betrieb kurz nach dem definierten Zeitfenster für das Testing einen neuen Release einspielen muss).

Und der zum Schluss abgegebene Report ist die Visitenkarte, die dem Kunden im Gedächtnis bleiben wird und unter Umständen viele Jahre verbleiben wird. Ein schlechter Report (fehlerhaft oder mangelhaft) kann auch Jahre nach seiner Abgabe ein schlechtes Licht auf das Projekt und die involvierten Parteien werfen. Irgendwann fragt vielleicht jemand: "Wieso wurde im Test das Risiko x nicht berücksichtigt?" Wenn der Report schlecht formuliert ist, kann ihn niemand verteidigen. Stattdessen heisst es dann lapidar: "Tja, das damals herbeigezogene Audit-Unternehmen war halt nicht so gut." Die Chancen, dass man beim nächsten Projekt wieder zum Handkuss kommt, werden damit verschwindend gering.

Aus diesem Grund ist es wichtig, dass man ein Security Testing Projekt stets als Ganzes betrachtet. Es geht nicht nur im Bits und Bytes. Es geht darum, dass eine Organisation von der Identifikation des bestehenden Risikos profitieren kann, indem eben dieses zeitnah adressiert werden kann. Technische Tests sind nur ein Instrument, um dieses Ziel erreichen zu können.