Warum man nicht alles wissen muss Marc Ruef | 04.10.2010 Ich habe schon hunderte Sicherheitsüberprüfung (http://www.scip.ch/?dienstleistungen.auditing) durchgeführt. Auch wenn jede von ihnen individuell ausgestaltet war und durchgeführt wurde, haben die meisten von ihnen in ihrem Kern eine Gleichmässigkeit vereint. Und sei dies auch nur definiert durch meine Herangehensweise. Diese mag für so manchen ein bisschen sonderbar erscheinen. In Bezug auf ihre Effizienz und Effektivität kann man sie aber nur schwerlich kritisieren. Was ich gar nicht mag, sind Reibereien und Reibungsverlust. Aus diesem Grund pflege ich besonders Meetings sehr effektiv anzugehen. Die Anzahl der Teilnehmer soll möglichst begrenzt sein. Im Idealfall nehmen lediglich zwei Personen teil. Eine Sitzung mit mehr als fünf Teilnehmern ist fragwürdig, denn es kann sowieso nur immer eine Person zu Wort kommen. Sodann droht aus einem Dialog ein Monolog zu werden, der mehr einer Nachrichtensendung (Broadcasting) als einem Informationsaustausch entspricht. Ebenso bin ich der Meinung, dass eine gute Sitzung nicht länger als 30 Minuten dauern sollte. Falls doch, dann sollte man sie wenigstens so aufbauen, dass jene Personen, die nicht ständig gebraucht werden, entweder erst später zum Gespräch dazustossen oder dieses früher verlassen können. Wenn also mehr als fünf Personen länger als eine Stunde in einem Raum sitzen und reden, dann ist das keine Sitzung mehr, sondern ein Brainstorming. So mancher Kunde - vor allem bei grösseren Unternehmen - wünscht sich möglichst ausschweifende Kickoff-Sitzungen. Da soll dann möglichst umfangreich über die Arbeiten diskutiert werden. Alles, was weniger als eine Stunde dauert, kann nix Gescheites sein. Am besten zwei oder gar drei Stunden soll das Beisammensein umfassen. Doch das ist Unsinn. Beim technischen Kickoff geht es darum, dass der Kunde grundlegende Informationen zum Projekt und dem Zielobjekt zusammenfasst: Risikobeurteilung, Angriffsszenarien, Zugriffsschnittstellen. Eigentlich sind die beiden erstgenannten gar optional und können nur von wenigen Kunden in qualifizierter Weise aufgezeigt werden. Schliesslich ist es auch unsere Aufgabe als Auditoren, hier eine solide Aussage zu treffen. Die zentrale Information zur erfolgreichen Umsetzung einer technischen Sicherheitsüberprüfung ist also das Wissen um die Zugriffsmöglichkeiten, die einem in Bezug auf das Zielobjekt gewährt werden. Bei netzwerkbasierten Tests sind dies IP-Adresse und Ports/Dienste. Bei applikationsbasierten Tests sind dies Schnittstellen zur Interaktivität mit der Anwendung (Interface, Dateisystem, Datenbank). Im Sinn einer intelligenten Ausgabe an Informationen interessiert es bei einem Test auf eine Internet-Anwendung in einer DMZ herzlich wenig, ob und inwiefern die Backend-Systeme miteinander kommunizieren. In den allermeisten Fällen wird gar nie die Möglichkeit bestehen, diese Kommunikation sehen oder gar (gewollt) beeinflussen zu können. Wird lang und breit dargelegt, wie eine solche aussähen würde, ist dies falsch eingesetzte Zeit. Stattdessen fokussiert man sich lieber auf die exponierten Komponenten. Man kann zwar die Hintergründe kurz skizzieren und sich einigen, bei Bedarf näher auf diese einzugehen. Aber pauschal über alle Ecken und Winkel eines Produkts zu diskutieren, das ist schlussendlich nur hinderlich für das Projekt. Denn anstatt viel geredet wird, sollte oftmals lieber mehr getestet werden.