Security Testing Sicherheitstester - Der anspruchsvollste Job in der Tech-Industrie?

Autor / Redakteur: Jouni Hiltunen / Peter Schmitz

Betrachtet man die Geschwindigkeit des technologischen Wandels, die Entwicklung der Cyberkriminalität sowie die Anforderungen an das Risikomanagement, dann ist Sicherheitstester ein extrem anspruchsvoller Job in der IT-Sicherheit. Es lohnt sich, einmal anzusehen, wie Security-Tester diese Herausforderungen meistern und welchen Denkmustern und Herangehensweisen sie dabei folgen.

Firmen zum Thema

Jede gepatchte Sicherheitslücke in einem Produkt bedeutet eine geringere Chance für den Angreifer, eine Schwachstelle zu finden.
Jede gepatchte Sicherheitslücke in einem Produkt bedeutet eine geringere Chance für den Angreifer, eine Schwachstelle zu finden.
(© Cybrain - stock.adobe.com)

Er mag etwas voreingenommen sein, und die Welt mag sich seit dieser Aussage verändert haben. Wenn man jedoch die Geschwindigkeit des technologischen Wandels, die Entwicklung der Cyberkriminalität sowie die Anforderungen an das Risikomanagement betrachtet und bedenkt, dass man gleichzeitig kaum etwas über die Fähigkeiten der Gegner weiß, dann wird klar, dass es zumindest nicht an Herausforderungen mangelt.

Viele junge, enthusiastische Techies entscheiden sich für den Bereich IT-Sicherheit, weil man hier sozusagen an vorderster Front gegen „das Böse“ kämpfen und auch selbst einmal als Hacker aus legitimem Anlass tätig werden kann. In der IT-Sicherheitsforschung sind die Bedrohungen dabei häufig recht abstrakt, und man muss sich nicht mit echten Gegnern auseinandersetzen. Arbeitet man dagegen als Tester im Bereich Produktsicherheit, dann werden die Gefahren und Gegner wesentlich konkreter. In jedem Fall ist es aber sinnvoll, bei den täglichen, anspruchsvollen Aufgaben einige grundlegende Überlegungen und Vorgehensweisen zu beachten.

Die existenzielle Sinnfrage

Eine existenzielle Frage im Bereich IT-Sicherheit ist, ob Testen und Patchen überhaupt von Belang sind. Wenn es Tausende von Schwachstellen gibt, macht es überhaupt einen Unterschied, zehn zu finden und zu patchen, da das Produkt dann immer noch verwundbar sein wird? Das würde allerdings voraussetzen, dass die Schwachstellen alle den gleichen Schweregrad haben. Um dieses Dilemma zu lösen, werden Metriken entwickelt. Sie sollen beispielsweise zeigen, wie viele Bugs es pro Million Codezeilen gibt, wie viele dieser Bugs Sicherheitsprobleme verursachen und wie viele dieser Schwachstellen in einem bestimmten Bedrohungsszenario ausnutzbar sind. Eine fundierte Auswertung ist jedoch nur im Nachhinein möglich.

In der Praxis sollte die Konzentration daher auf dem allgemeinen Ziel der Abwehrsicherheit liegen. Dabei versucht man, die Kosten für den Angreifer so zu erhöhen, dass sich der Angriff nicht lohnt. Jede gepatchte Sicherheitslücke im Produkt bedeutet eine geringere Chance für den Angreifer, eine Schwachstelle zu finden. Dies ist eine der Möglichkeiten, der eigenen Arbeit angesichts der oben genannten Unwägbarkeiten einen Sinn zu geben.

Sicherheitstests können dabei den entscheidenden Unterschied machen. Zum Beispiel hat das Android-Betriebssystem zusätzliche Eindämmungsstrategien eingeführt. Dazu gehören bessere Zugriffskontrolle, Reduzierung der Angriffsfläche und architektonische Dekomposition - insbesondere für Teile des Systems, die am meisten unter Schwachstellen litten, wie z. B. das Medien-Framework.

Eine gesunde Portion Paranoia

Für Sicherheitsverantwortliche ist es bereits eine Herausforderung, bei den täglichen sicherheitsrelevanten Nachrichten auf dem Laufenden zu bleiben. Sogar Nachrichten aus Politik und Gesetzgebung können Einfluss auf Sicherheitstests haben.

Eine weitere tiefgreifende Frage, die sich jeder Sicherheitstester stellen muss, der sich einem neuen Testziel nähert, ist: "Vertrauen oder nicht vertrauen?". Die Informationsasymmetrie (Fähigkeiten und Wissen der jeweiligen Parteien sind nicht öffentlich) zwischen den Akteuren im Bereich der Sicherheit bietet einen fruchtbaren Boden für Mythen und schlichte Paranoia. Die Realität ist jedoch, dass es angesichts der Komplexität der heutigen Technologien immer einige Dinge gibt, die als Grundwahrheiten angenommen werden müssen.

Ein Beispiel hierfür ist die Kryptografie. Praktisch alle Kommunikationstechnologien stützen sich auf standardisierte kryptografische Algorithmen. In der Praxis werden nur Algorithmen verwendet, die rechnerisch sicher sind. Das bedeutet, dass sie nicht innerhalb einer angemessenen Zeit mit vertretbaren Ressourcen an Kosten, Energieaufwand und so weiter geknackt werden können. Man muss also darauf vertrauen, dass der Standardisierungsprozess sicherstellt, dass die zugelassenen Algorithmen einer genauen Prüfung durch mehrere unabhängige Experten unterzogen werden, damit niemand einen signifikanten Vorteil hat, die Algorithmen zu entschlüsseln.

Allerdings entbindet dies Sicherheitsverantwortliche nicht davon, sich in Sicherheitsbelangen auf dem Laufenden zu halten, Hintergrundrecherchen durchzuführen und sich ein gesundes Maß an Paranoia zu bewahren, um vertrauensbasierte Entscheidungen zu treffen. Denn es gibt immer wieder Fälle, wie den von Edward Snowden, der anhand durchgesickerter Dokumente nahelegte, dass Schwächen bei einem standardisierten kryptographisch sicheren Generator für Zufallszahlen namens Dual Elliptic Curve Deterministic Random Bit Generator bereits bekannt waren und er trotzdem von 2006 bis 2014 in den Listen der zugelassenen Algorithmen eines international anerkannten Standardisierungsgremiums enthalten war.

Die Kunst der Priorisierung

So faszinierend die Mythen und Verschwörungstheorien rund um das Thema Sicherheitstests auch sein mögen, die knappen Ressourcen für Sicherheitstests erfordern Pragmatismus und geschäftsorientierte Ansätze. Wenn man betrachtet welche Angriffsfläche allein ein Smartphone bietet (z.B. Komplexität des Betriebssystems und Vielfalt der Eingabeschnittstellen) und dann die Geschwindigkeit des Wandels im mobilen Ökosystem hinzunimmt wird klar, wie groß die Herausforderungen im Bereich Produktsicherheit sind.

Die Priorisierung von Sicherheitstests auf Basis von Bedrohungen ist theoretisch recht einfach. Ein Standard-Risikomodell besagt, dass das Risiko gleich der Wahrscheinlichkeit (also der Chance, dass eine bestimmte Bedrohung eintritt) mal der Auswirkung (also der Schwere der Folgen, wenn die bestimmte Bedrohung eintritt) ist. Man fragt sich jedoch schnell, wie man die Wahrscheinlichkeit und die Auswirkung berechnen kann. DREAD, eine beliebte Merkregel, könnte bei dieser Aufgabe helfen. Das Akronym steht für Damage (wie groß wäre der Schaden, wenn der Angriff erfolgreich wäre), Reproducibility (wie einfach ist es, einen Angriff zu reproduzieren, damit er funktioniert), Exploitability (wie viel Zeit, Aufwand und Fachwissen ist erforderlich, um die Bedrohung auszunutzen), Affected Users (wie viel Prozent der Benutzer wären betroffen, wenn eine Bedrohung ausgenutzt würde) und Discoverability (wie einfach es für einen Angreifer ist, diese Bedrohung zu entdecken). In der Praxis erfordert die Beantwortung dieser Fragen in quantitativer Hinsicht jedoch viel Phantasie, um die unbekannten Faktoren abzuschätzen. Das macht die Priorisierung eher zu einer Kunst als zu einer technischen Aufgabe, vor allem, wenn sie in einer angemessenen Zeit erfolgen soll.

Der Zweck definiert die Richtung

Es ist bereits deutlich geworden, dass Bedrohungen nicht schwarz oder weiß sind, sondern verschiedene Grautöne haben - je nachdem, aus welchem Blickwinkel man sie betrachtet und wer sie beurteilt. Daher sind einige nüchterne Fakten erforderlich, um Klarheit zu schaffen. Tester sollten sich also fragen: Welche Rolle spielt das Testobjekt in der gesamten Sicherheitslage? Wie wird es von den Kunden genutzt und welche Sicherheitsrichtlinien gibt es? Wie hoch ist der Testaufwand auf Basis der verfügbaren Ressourcen und Expertise? Wenn eine Schwachstelle gefunden wird, können wir sie beseitigen? Steht in naher Zukunft ein Code-Refactoring oder eine Designänderung für das Zielsystem an? Können die Tests automatisiert werden? Wie ist die Historie der getesteten Codebasis und wird sie gepflegt? Was sind die Trends in der Schwachstellenforschung?

Diese Evaluierungen sollten getroffen werden, bevor mit dem eigentlichen Testen begonnen werden kann. Dazu muss man also quasi den Farbkontrast erhöhen, anstatt den genauen Grauton zu definieren. Die Definition des Testzwecks ist von größter Bedeutung, um effizient und zielgerichtet arbeiten zu können.

Von der Black Box...

Neben Tests für die Produktsicherheit gehören auch Penetrations- und Sicherheitstests für externe Netzwerke und Geräte zum Alltag eines Sicherheitstesters. Dies geschieht in der Regel entweder als Black Box Testing (keine Vorabinformationen über das Ziel) oder als Gray Box Testing (einige Informationen wie z.B. Dokumente zur IT-Architektur werden als Vorabinformationen verwendet) . Die Entdeckung von Informationen über das Ziel (welche Technologien verwendet werden, wie es konfiguriert ist, was die geschützten Assets sind und manchmal sogar Hinweise auf die Gedankengänge der Entwickler) durch Reverse-Engineering und Aufklärung ist an sich schon spannend.

Aber dieser Ansatz ist hinsichtlich der Ergebnisse und Erwartungen noch offener als White-Box-Sicherheitstests, bei denen die Details der meisten Teile der Implementierung zur Verfügung stehen. Da es schwer ist herauszufinden, wie gut man seine Arbeit gemacht hat, z.B. in Bezug auf die Testabdeckung, besteht ein ständiger Druck, das Testen mit einem wertvollen Ergebnis abzuschließen – wie etwa der Entdeckung einer kritischen Schwachstelle auf dem Ziel.

...zur White Box

White-Box-Tests haben einen anderen Ansatz. Allerdings können Erfahrungen, die man bei Block Box-Tests gemacht hat, auch hierbei wertvoll sein. Denn viele White-Box-Tests starten heute mit einem Durcheinander von komplexen Frameworks und Systemumgebungen sowie miteinander verbundenen Abhängigkeiten. Daher funktionieren manchmal sogar einige grundlegende Teile des Codes nicht wie erwartet, was durch eine Art von Blackbox-Testing entdeckt werden kann.

Im Bereich Produktsicherheit gilt der White-Box-Ansatz als effizienter. Das bedeutete jedoch nicht, dass die Tests in kürzerer Zeit durchgeführt werden können, obwohl die gleiche Abdeckung schneller erreicht werden kann. Wenn man mit offenen Karten spielt, gibt es auch höhere Erwartungen an ein lohnendes Ergebnis. Wenn der Code zur Überprüfung zur Verfügung steht, sind neue Testtechniken und -werkzeuge wie Quellcode-Auditing sowie statische und dynamische Code-Analyse möglich. Erwähnenswert ist hier etwa das Fuzz-Testing, eine Testtechnik, bei der ungültige, unerwartete oder zufällige Daten als Eingaben verwendet werden und die ebenfalls ein wichtiger Teil des Arsenals von Black-Box-Testern ist. Es könnte durch Instrumentierungen - die ein schnelleres und abdeckungsorientiertes Fuzzing ermöglichen - sowie durch Sanitizer, die bisher unbemerkte Sicherheitsprobleme aufdecken, effizienter genutzt werden.

Auch die beim Black-Box-Testing verwendeten Testtools, wie Schwachstellen-Scanner, Tools zur Analyse des Netzwerkverkehrs und für Angriffe sowie Sicherheitsscanner für Android-Anwendungen, sind wertvoll. Theoretisch könnte man sich nur auf diese Tools (und die dazugehörigen Checklisten) verlassen, aber normalerweise sind die Ziele so einzigartig, dass die Tools nicht alle relevanten Aspekte abdecken. Daher geht es bei Sicherheitstests nicht immer darum, Dinge auseinanderzunehmen, sondern auch darum, die richtigen Tools für den Job zu entwickeln.

Resümee

Das Sicherheitstesten ist eine nie endende Reise. Auch für mich als „altem Hasen“ ist es bei jedem Test nach wie vor spannend, neue Schwachstellen zu finden und zu beheben. Die Mischung aus Erfahrungswerten, der Chance, jeden Tag etwas Neues zu lernen, der Herausforderung offene Fragen zu klären, analytisches Denken, der notwendige Pragmatismus und die Zusammenarbeit mit tollen Kollegen und Teams, macht die Arbeit in der IT-Sicherheit für mich nach wie vor zu einem Traumjob.

Über den Autor: Jouni Hiltunen ist ein leidenschaftlicher Informationssicherheitsexperte, der über viele Jahre Erfahrung als Forscher und Tester verfügt. Seit 2016 trägt er als Software-Sicherheitstester und Testmanager sowie als Sicherheitsproduktmanager zur Produktsicherheit von Bittium bei. Jouni hat mehrere wissenschaftliche Publikationen verfasst und ist ein zertifizierter Ethical Hacker, der in seiner Freizeit gerne Bug Bounty Hunting und Internet-Schwachstellenforschung betreibt.

(ID:47401080)