Out of Scope als latente Gefahr
Marc Ruef | 30.06.2014

Bei einer Sicherheitsüberprüfung wird ein Objekt analysiert. Was alles zu diesem "Objekt" gehört, wird im Scope festgelegt. Ein typisches Scoping lautet zum Beispiel "alle vom Internet erreichbaren Systeme" oder "System X als authentisierter Benutzer". Diese Definition ist also massgeblich mitentscheidend, was und wie etwas betrachtet werden wird.

Ein Scope ist immer auch eine implizite Abgrenzung. Wenn System X angeschaut werden soll, dann hat man gefälligst System Y nicht anzuschauen. Diese Abgrenzung kann aber auch explizit geschehen, indem die Sachen, die nicht untersucht werden sollen, als "out of scope" deklariert werden. Zum Beispiel kann System X in scope sein, aber Service A ist explizit out of scope.

Es gibt verschiedene Gründe, warum etwas out of scope sein kann:

* Es wird/wurde im Rahmen einer anderen Prüfung untersucht
* Es ist besonders heikel und muss gesondert untersucht werden
* Es ist noch nicht produktiv und einsatzbereit
* Es wird "bald" abgelöst
* Es wird keine Wichtigkeit (Kritikalität/Exponiertheit) beigemessen
* Es ist nicht im Hoheitsgebiet des Kunden
* Man will es einfach nicht angeschaut haben

Nicht alle der genannten Gründe lassen mich in einem Gefühl des Wohlbehagens zurück. Es ist nämlich nicht selten, dass Dinge als out of scope geführt werden, nur weil sie unbequem sind. Man drückt sich quasi vor der Verantwortung, sich den Herausforderungen dafür zu stellen.

Das Exkludieren von Prüfungen aus dem genannten Grund ist stets fahrlässiger oder gar böswilliger Natur. Früher oder später wird genau diese Komponente in einem Zwischenfall involviert sein und dann wird es schwierig sich zu rechtfertigen, warum man da nicht schon viel früher reagiert hat. Ein gutes Scoping muss ehrlich sein. Langfristig profitieren alle davon.