Black Box, Grey Box, White Box testing.
Das Blue Team sucht Verstärkung.
White Hats vs. Black Hats.
Red Teaming Projekte immer mehr gefragt.

In der IT-Security ist es üblich geworden, mit farbigen Metaphern komplexe Sachverhalte zu bezeichnen. Da gibt es die weißen und schwarzen Hüte, die „guten“ und „schlechten“ Hackern aufgesetzt werden, aber auch rote oder blaue Teams der IT-Security und schwarze, weiße oder graue Boxen zur Bezeichnung von verschiedenen Szenarien einer Sicherheitsüberprüfung durch penetration testing. Doch was verbirgt sich technisch hinter diesen farbigen Buzzwords? Und sind die mit ihnen getroffenen Einteilungen in der Praxis wirklich sinnvoll? Im folgenden Beitrag werde ich etwas Ordnung in diese bunte Welt bringen und zeigen, dass die wirklich wichtigen Unterscheidungen auf einer technischen Ebene getroffen werden sollten.

Die Teams

Die Bezeichnungen Red und Blue Teaming beziehen sich leider nicht auf verschiedene Pokémon-Editionen, sondern hier ist von offensiven (roten) und defensiven (blauen) IT-Security Teams die Rede.

Während das Blue Team sich darum kümmert, IT-Systeme zu schützen, Angriffe von außen zu identifizieren und diese abzuwehren, simuliert das Red Team einen gezielten Angriff auf das System und bemüht sich, die vom Blue Team aufgebauten Schutzmaßnahmen zu überwinden.

Rote Teams sind dabei meist extern Beauftragte Spezialistinnen und Spezialisten, während das Blaue Team typischerweise von der eigenen IT einer Einrichtung oder eines Unternehmens gestellt wird.

Welche Angriffsszenarien ein Red Teaming Auftrag genau abdeckt, ist von den jeweiligen Anbietern in diesen Bereichen abhängig. Beispielweise ist zu klären, ob und wie die in einem Unternehmen Beschäftigten mittels Social Engineering als mögliche Schwachstelle angegriffen werden dürfen oder ob das physische Eindringen in Gebäude den Testern erlaubt wird. Auch die Abgrenzung zum “klassischen” penetration test, also typischerweise dem Angriff auf die IT-Infrastruktur über das Internet, wird gemeinhin sehr unscharf gehandhabt.

Generell herrscht aber bei der Unterscheidung zwischen Red und Blue Teaming Einigkeit über eine Einteilung in defensiv und offensiv operierende Teams, was aufgrund der deutlichen Unterschiede in den Arbeitsweisen, Abläufen und eingesetzten Techniken der beiden Gruppen durchaus eine sinnvolle Unterscheidung darstellt.

Die Boxen

Die Begriffe Black, Grey und White Box beziehen sich auf verschiedene Szenarien eines penetration tests und beschreiben den Informationsgrad, über den ein mit dem Test beauftragter Pentester in Bezug auf sein Testobjekt verfügt. Die zwei Extreme bilden hierbei ein Vorgehen ohne vorab zur Verfügung gestellte Informationen durch den Kunden, weshalb der Tester auf der Suche nach dem Lichtschalter zunächst durch das Dunkel einer Black Box tappt. In der metaphorischen White Box hingegen, hat man freundlicherweise das Licht bereits angeschaltet und den Pentester mit umfangreichen Informationen zum Testobjekt ausgestattet.

Der klassische Pentest des Webauftritts eines Unternehmens ließe sich beispielsweise als Black Box bezeichnen, wenn man dem Tester lediglich die Webadresse zukommen lässt und der Tester nicht wüsste was er unter dieser Addresse überhaupt vorfinden würde.

Würde man ihm hingegen technische Informationen über den Webserver, die verwendeten Technologien sowie den Quellcode der Webseite zukommen lassen, spricht man von einem White Box Test. Hier ist eine Abgrenzung zum Source Code Audit nötig, bei dem der Quellcode auf Schwachstellen überprüft und bewertet wird, ohne dass die Anwendung aktiv von außen angegriffen wird. Gelegentlich wird nämlich auch ein Source Code Audit fälschlich als White Box Test bezeichnet.

Die Bezeichnung Grey Box Test kann sich vor diesem Hintergrund dann entweder auf einen Test mit minimaler Zusatzinformation beziehen, meint gelegentlich aber auch einen Test, bei dem vorab beispielsweise Nutzer- oder Administrationskonten zur Verfügung gestellt werden. Diese Bezeichnung ist jedoch nicht trennscharf, da es eine Vielzahl von Anwendungen gibt, auf die ausschließlich mithilfe eines Kontos zugegriffen werden kann. Ein Beispiel wäre etwa der Kundenbereich einer Versicherung. Wenn außer den Zugangsdaten daher keinerlei weitere Information vor dem Test zur Verfügung gestellt werden, ließe sich dieser sowohl als Black Box aber auch als Grey Box Test bezeichnen.

Da viele Tests im laufenden Betrieb von Anwendungen stattfinden, sind einem Pentest sehr häufig Grenzen gesetzt. Dies geschieht, um den Ablauf nicht zu stark zu beeinträchtigen. Bestimmte Bereiche können auch vom Test ausgenommen werden, da diese z.B. der Hoheit eines externen Dienstleisters oder Anbieters unterliegen und somit keine Testgenehmigung vorliegt. Durch diese notwendigen Bedingungen eines Tests ist der einem Tester zur Verfügung stehende Informationsanteil allein durch den organisatorischen Ablauf der Vorbereitung eines penetration tests in der Regel niemals gleich null. Streng genommen ist ein „richtiger“ Black Box Test in der Praxis damit kaum möglich. Bereits an diesem Aspekt zeigt sich, als wie unscharf sich eine kategoriale Unterscheidung zwischen einzelnen Test-Szenarien in der Praxis erweist.

Reale Bedrohungsszenarien lassen sich zudem nur schwerlich mithilfe dieser vereinfachten Kategorisierung abbilden. Es ist daher ratsam, diesen keine zu große Bedeutung beizumessen und stattdessen in der Praxis ein individuell abgestimmtes Testszenario mit den Kunden zu entwickeln und dabei den zur Verfügung gestellten Informationsanteil mit dem Tester abzustimmen.

Auf den ersten Blick erscheint ein Black Box Test zwar wie ein realistisches Angriffsszenario und Angriffe ohne jegliche Informationen über das Ziel finden selbstverständlich statt. Dabei werden aber in der Regel bereits allgemein bekannte Schwachstellen in Applikationen oder Software ausgenutzt, die vom eigentlichen Ziel unabhängig sind.

Im Falle einer zielgerichteten Attacke ist es hingegen nicht der Fall, dass Angreifer über kein oder nur ein geringes Vorwissen über ihr Ziel verfügen würden. Es erschiene realitätsfern davon auszugehen, dass ein potenzieller Angreifer nicht vorab jede zur Verfügung stehende Möglichkeit der Informationsbeschaffung nutzen sollte. So lassen sich die eingesetzten Technologien meist bereits anhand des frei einsehbaren Quellcodes einer Website identifizieren, während die gewünschten Fähigkeiten in Stellenausschreibungen der betroffenen Unternehmen oder die aufgeführten Skills der Mitarbeitenden auf Portalen wie Xing und LinkedIn über zum Einsatz kommende Programme und Infrastrukturen informieren. Hinzu kommen wahrscheinliche Angriffsszenarien, bei denen die Angreifer bereits Nutzer- oder sogar Administrator-Konten kompromittiert haben oder diese (z.B. über Phishing) sogar vollständig unter Ihre Kontrolle bringen konnten.

In dieser für Kunden oft undurchschaubaren Gemengelage potenzieller Bedrohungen und Vulnerabilitäten der eigenen digitalen Infrastruktur erweist sich die simple Einteilung in schwarze, weiße oder graue Boxen daher als irreführend und realitätsfern. Bei der Konzeption eines penetration tests empfiehlt sich vielmehr, den Test individuell an den Bedürfnissen des Kunden auszurichten und dabei die Anforderungen und Gegebenheiten der zu testenden Infrastruktur sowie die realistisch zu erwartenden Bedrohungsszenarien zu berücksichtigen.

Die Hüte

Als letztes möchte ich noch auf die wohl geläufigste Metapher aus dem Bereich IT-Security eingehen: die Einteilung von Hackern in Black Hats und White Hats. Dieser Unterscheidung liegt der Versuch zugrunde, mithilfe einer binären Einteilung zwischen „guten“ und „schlechten“ Hackern zu unterscheiden. Auf der einen Seite stehen die White Hats als moralisch einwandfrei agierende Akteure, die zum Beispiel beauftragt werden, einen Pentest durchführen oder die in Open Source Projekten nach Sicherheitslücken suchen, um diese ohne finanzielles Interesse zu schließen. Diese „guten“ Hacker informieren zudem die Öffentlichkeit über Schwachstellen der IT-Infrastruktur, von deren Existenz Sie auf legalem Wege erfahren haben.

Gegenübergestellt werden ihnen häufig die sogenannten Black Hats, welche als klassische bad guys kriminell agieren und gerade nicht ethisch motiviert sind, sondern zur eigenen finanziellen Bereicherung oder aus anderen niederen Motiven Systeme angreifen, diese lahmlegen, Daten stehlen oder Menschen und Unternehmen erpressen.

Zuweilen wird in der öffentlichen Diskussion dann von dieser Einteilung ausgehend weiter differenziert und beispielsweise von Grey Hats, Hacktivists, Cyber Criminals oder State Acteurs gesprochen, wobei letztere im Auftrag von nationalen Regierungen Angriffe durchführen.

All diesen Kategorisierungen liegt die Annahme zugrunde, dass durch die Einteilung in bestimmte Gruppen ein besseres Verständnis der Materie erreicht werden kann, was in der Praxis wiederum zu einer effektiveren Verteidigung beitragen kann. Aus der Sicht des Praktikers muss ich gestehen, dass ich das leider für ausgemachten Unsinn halte.

Tatsächlich verteidigt man ein System nämlich nicht gegen Begriffe und Konzepte, sondern gegen reale Angriffe auf einer technischen Ebene. Es geht in der Praxis der IT-Security ganz konkret darum, Schwachstellen zu schließen, Fehlkonfigurationen zu identifizieren und gleichzeitig auf der operativen Ebene die Zugriffsrechte eines Systems zu verwalten und die Mitarbeiter*Innen sicherheitstechnisch zu schulen. Das Operieren mit den im Beitrag erklärten Buzzwords fördert meiner Ansicht nach daher durch die vorgenommene Vereinfachung einer hochkomplexen Thematik ein gefährliches Halbwissen, bei dem Missverständnisse und Fehleinschätzungen vorprogrammiert sind.

Ich halte es daher für weitaus sinnvoller, eine Kategorisierung auf die rein technische Ebene zu verlagern. Hier gilt es etwa, zwischen verschiedenen Formen des Angriffs zu unterscheiden und beispielsweise zwischen Phishing und Exploiting zu differenzieren, da diese dann auch andere Strategien und Handlungsanweisungen benötigen. Ob man es dabei mit Grey Hats oder Cyber Criminals zu tun hat, ist für die Abwehr des Angriffs unerheblich.