Sicherheitsüberprüfungen sind ein komplexes Thema, das neben technischen Aspekten ebenso in philosophischer Weise (konzeptionell und organisatorisch) für Gesprächsstoff sorgen kann. Ein Aspekt, der oft diskutiert wird, ist die Reduzierbarkeit von Tests. Darunter wird gemeinhin das Folgende verstanden:

Ein Test mit einem Gesamtumfang x soll in Bezug auf Teilprozesse und/oder Zeitumfang verringert werden.

Das eigentliche Ziel einer solchen Reduktion ist in den allermeisten Fällen wirtschaftlicher Natur. Und damit wird unverzüglich ein Interessenskonflikt etabliert, denn in einer direkten Gegenüberstellung widersprechen sich Wirtschaftlichkeit und Sicherheit (ganz im Gegensatz zu langfristigen Überlegungen).

Wohl kein Tester wird aus freien Stücken den Umfang seiner Analysen einschränken wollen, da damit stets die Qualität der Betrachtungen verloren geht. Und doch gibt es Situationen, in denen der Testumfang in gegenseitigem Einverständnis reduziert werden will. Die Frage ist jedoch stets:

Wann und wie viel Reduktion ist sinnvoll?

Als Grundsatz gilt es zu bedenken, dass eine Sicherheitsüberprüfung stets nur deterministische Aussagen zur effektiv getesteten Angreifbarkeit eines Objekts machen kann. Wenn eine Prüfung x Tage dauert, dann kann nicht exakt bestimmt werden, welche Effekte ein Angreifer erzielen kann, dem x+y Tage zur Verfügung stehen. Bevor der Rahmen einer Prüfung definiert wird, sollte also die zeitliche Wichtigkeit des Schutzbedarfs bestimmt werden. Und in gleicher Weise die Aufwände, die potentielle Angreifer zu betreiben gewillt sind (z.B. Zusammentragen von Knowhow, Investieren von Geld).

Das Problem beim Reduzieren von Testreihen ist, dass sich diese nicht beliebig skalieren lassen. Erfordert das Testing für ein Objekt x Tage, dann kann nicht per se x/2 oder x-10% Tage investiert werden. Hierfür gibt es drei Gründe:

• Minimalaufwand: Unterschiedliche Tests weisen jeweils einen Minimalaufwand auf. Genauso wie man eine Fussballmannschaft nicht mit nur 5 Mann spielen lassen kann, kann man eine übliche Webapplikation nicht einfach in 2 Stunden fachgerecht überprüfen.

• Verknüpfbarkeit: Verschiedene Testreihen weisen eine Verknüpfbarkeit auf. Eine zentrale Analysetechnik von Software besteht in der Betrachtung von Eingabeüberprüfungen (Input Validation). Als Teilmenge derer fungieren beispielsweise Pufferüberlauf-Attacken und SQL-Injection. Wird auf eine dieser Angriffsklassen verzichtet, so können theoretisch auch gleich auf andere Klassen verzichtet werden.

• Gleichwertigkeit: Angriffsvektoren und -techniken weisen für sich (und manchmal auch untereinander) eine Gleichwertigkeit auf. Es gibt eine Vielzahl unterschiedlicher Angriffsvektoren für verschiedene Angriffstechniken (z.B. Cross Site Scripting-Attacken). Lediglich 80% derer zu testen ist nicht sinnvoll, da es oftmals (gerade in einem Penetration Test) keine wichtigsten Varianten gibt.

Die Folge davon ist, dass sich Sicherheitsüberprüfungen nur bruch- und damit stufenweise reduzieren lassen. Zum Beispiel können bei der Prüfung eines Internet-Perimeters sämtliche Webapplikationen ausgeschlossen und stattdessen nur ein Vulnerability Scan angesetzt werden. Halt mit dem Risiko, dass ein wichtiger Aspekt der Perimetersicherheit nicht geprüft wird. (Kein kluger Schachzug, da Applikationssicherheit immer mehr in den Fokus rückt.)

Es ist wichtig zu Beginn eines Projekts mit den Spezialisten zu diskutieren, welche Aspekte eines Tests besonders wichtig sind (z.B. hohe Exponierbarkeit) und auf welche aus wirtschaftlichen Gründen verzichtet werden kann bzw. erst in einer späteren Phase geprüft werden sollen (z.B. authentisierte Bereiche). Nur so kann gewährleistet werden, dass ein Prüfobjekt umfangreich und professionell untersucht werden kann.

About the Author

Marc Ruef has been working in information security since the late 1990s. He is well-known for his many publications and books. The last one called The Art of Penetration Testing is discussing security testing in detail. He is a lecturer at several faculties, like ETH, HWZ, HSLU and IKF. (ORCID 0000-0002-1328-6357)

Links

• http://itexpertvoice.com/ad/scale-and-scalability-rethinking-the-most-overused-it-system-selling-point-for-the-cloud-era/
• http://jeremiahgrossman.blogspot.com/2010/02/infrastructure-vs-application-security.html
• https://www.computec.ch/projekte/tractatus/
• https://www.computec.ch/projekte/tractatus/?s=tractatus&m=liste&h=2.1.2.6.2&l=6
• https://www.scip.ch/publikationen/fachartikel/scip_cross_site_scripting.pdf