Wie geht das Red Team bei einer Überprüfung vor?
Nehmen wir an, wir testen eine App. Dann tauschen wir uns in einem ersten Schritt mit jenen Spezialist:innen aus, die die App entwickeln, betreiben oder weiterentwickeln und definieren die Ziele des Testings. Ein solches Ziel kann sein, in einer Testumgebung eine Finanztransaktion zu manipulieren oder Informationen über eine Schnittstelle innerhalb der App abzugreifen. Anschliessend wird bestimmt, welchen Ansatz wir verfolgen wollen – den Blackbox-, den Graybox- oder den Whitebox-Ansatz. Beim Blackbox-Ansatz erhalten wir fürs Testing Zugang zur Applikation ohne weitere Informationen zur inneren Struktur. Beim weit häufigeren Graybox-Ansatz kriegen wir etwas mehr Unterstützung, indem wir zum Beispiel mit einer Version arbeiten können, in der gewisse Schutzmassnahmen ausgeschaltet sind. Dies verschafft uns einen Vorsprung gegenüber potenziellen Angreifer:innen, die meist mehr Zeit zur Verfügung haben als wir – und die Möglichkeit, die kostbare Testzeit zur Prüfung verwenden zu können und nicht für die Umgehung von Sicherheitsmassnahmen. Oder aber man geht mit dem Whitebox-Ansatz noch einen Schritt weiter und legt den Quellcode offen, sodass es für uns Tester:innen einfacher wird, die Schutzmassnahmen zu umgehen. Anschliessend bauen wir das Testsetup auf und legen los. Wir prüfen zum Beispiel die Authentisierung, das Loginverfahren oder die Zurücksetzung des Passworts auf logische Fehler und Abweichungen von Standards. Oder wir beobachten, wie sich die App verhält, wenn wir sie mit Informationen füttern, für die sie eigentlich nicht gedacht war. Läuft zum Beispiel eine Zahlung von Kunde A zu Kunde B im Hintergrund über zehn Schritte, schauen wir, was passiert, wenn wir die Reihenfolge der Schritte oder den Inhalt verändern. Haben wir dann genügend solche Ansatzpunkte geprüft, ziehen wir Rückschlüsse und dokumentieren diese. Wo nötig, werden dann Massnahmen getroffen, um erkannte Schwachstellen zu beheben.