Konkrete Kritik an CVSS4
Marc Ruef
Banken, Kreditkartenaussteller und Online-Händler sind gleichermassen mit dem Problem des Betrugs konfrontiert. Dieser Artikel bespricht, wie anhand des Verhaltens von Betrügern bzw. den durch sie zugeführten Zugriffen böswillige Aktivitäten erkannt und auf diese reagiert werden kann.
Man kann sagen, dass es so etwas wie den normalen Benutzer gibt. Darunter versteht man alle Benutzer, die sich im bzw. nahe am durchschnittlichen Verhalten bewegen. Zum Beispiel sind der grösste Teil der Facebook-Benutzer zwischen 25 und 34 Jahre alt (29.7%), bestehen aus weiblichen Benutzern (76%) und benutzen die Seite im Schnitt 20 Minuten. Falls Sie diese drei Eigenschaften für Sie vereinen, handelt es sich bei Ihnen um den durchschnittlichen Facebook-Benutzer.
Solche Statistiken lassen sich für sämtliche Angebote, Dienste und Nutzungsbereiche erstellen. In manchen Fällen sehen die Resultate verschiedener Plattformen ähnlich aus, in anderen gibt es ganz offensichtliche soziodemografische und/oder technische Abweichungen.
Um betrügerisches Verhalten erkennen zu können, muss als erstes das normale Verhalten identifiziert werden. Auf technischer Ebene sind dies zum Beispiel:
Abweichungen von der ermittelten Normalität können sodann Hinweise auf betrügerisches Verhalten sein. Bei der Einführung einer ersten Implementierung sollte man sich am Durchschnitt aller Benutzer orientieren. Professionelle Lösungen im Finanzbereich vergleichen mit dem normalen Verhalten des spezifischen Benutzers, der Benutzer im gleichen Postleitzahlenbereich und der Benutzer in der gleichen geografischen Sprachregion. Andere Gruppierungen (z.B. eingesetzter Webbrowser) sind ebenfalls denkbar.
Der empfohlene Ansatz sieht nicht vor, dass sämtliche Abweichungen sofort als betrügerisches Verhalten verstanden und sanktioniert werden sollen. Viel mehr soll durch das Zusammenführen verschiedener Indizien eine Beweislage geschaffen werden, auf der Basis derer eine nachvollziehbare Entscheidung getroffen werden kann.
Zu diesem Zweck sollen Strafpunkte für einzelne Abweichungen definiert werden. Die Abweichungen sollten aufgelistet und in verschiedene Kategorien an Schweregrad aufgeteilt werden. Es ist unnötig, für einen Übergriff 51 Punkte und für einen anderen 59 Punkte vergeben zu können. Stattdessen sollte man möglichst mit einstelligen Punkten, in diesem Fall 5 und 6, arbeiten. Dies vereinfacht das System enorm und erhöht den Überblick.
Um False-Positives zu vermeiden, sollte bei der Zunahme der Schwere eines Verstosses mit überproportionalen Abstufungen gearbeitet werden. Bewährt haben sich exponentielle Erhöhungen der Form 1, 2, 4, 8 und 16. Es ist für einen Kunden viel schwieriger, versehentlich im Maximum zu landen, weder wenn eine Skala von 1, 2, … 5 eingesetzt werden würde.
Die Anzahl der Abstufungen sollte 3, 4, 5 oder 6 Möglichkeiten zulassen. Weniger 3 als schränken bei der Punktevergabe ein. Und bei mehr Möglichkeiten wird wiederum die Komplexität und Nachvollziehbarkeit negativ beeinträchtigt.
Die Metrik ist immer individuell auszulegen und muss im Rahmen der Erarbeitung des Modells iterariv erarbeitet werden.
Im folgenden Beispiel soll aufgezeigt werden, wie die Abstufung für die Geolokalisierung bei einem Schweizer Online-Händler, der keinen internationalen Versand vorsieht, stattfinden kann:
ID | Abweichung | Strafpunkte |
---|---|---|
Client-IP-Adresse | ||
1 | IP-Adresse ausserhalb CH | 1 |
2 | IP-Adresse ausserhalb DACH | 2 |
3 | IP-Adresse ausserhalb EU | 4 |
4 | IP-Adresse ausserhalb Europa | 6 |
5 | IP-Adresse in Ländern mit hoher Cybercrime-Rate (z.B. Russland, China) | 8 |
6 | IP-Adresse von bekanntem VPN-Dienst oder Tor Exit Node | 8 |
Webbrowser | ||
7 | User-Agent kein zeitgenössischer Browser | 4 |
8 | Leerer User-Agent String | 8 |
Versandadresse | ||
9 | Versand an bekannten Benutzer mit offenen Rechnungen | 2 |
10 | Versand an bekannten Benutzer mit bekannten Betreibungen | 4 |
11 | Versand an neuen Benutzer ohne bisherige Bestellungen | 4 |
12 | Versand an nicht existente Adresse | 6 |
Eine besondere Klasse von Abweichungen ist je nachdem auf der Zeitachse zu beobachten. Es gibt typische Pausen, die normale Benutzer zwischen Aktivitäten einbringen. Zum Beispiel dauert es x Sekunden, bis nach dem Laden der Login-Seite die entsprechenden Credentials eingegeben wurden. Ist diese Pause speziell kurz oder lang, kann dies wiederum auf ein verdächtiges Verhalten hinweisen. Zum Beispiel lassen sich so Automatisierungen (z.B. Bruteforce-Attacken) sehr einfach erkennen. Ein Angreifer müsste in diesem Fall zufällige aber realistisch wirkende Verzögerungen einbringen, um dadurch nicht erkannt werden zu können.
Zeitgestützte Abweichungen orientieren sich immer am Zeitpunkt zweier unterschiedlicher Aktionen. Diese Aktionen müssen dabei nicht direkt nacheinander erfolgen. Die Eingabe der Credentials und das Abschicken des Login-Formulars folgt in der Regel aufeinander. Man kann aber auch stattdessen die Zeit zwischen der Eingabe des Benutzernamens und der ersten Ausgeführten Transaktion im Online-Banking beobachten. Jenachdem deuten Abweichungen auf ein zielgerichtetes Plündern von Konten hin.
Wie bei allen Abweichungen sollen auch die zeitbasierten Abweichungen mit Strafpunkten belegt werden. Hier folgt man dem gleichen Schema, das für die Taxierung der eigentlichen Aktionen genutzt wird. Als Aktion ist hier jedoch der zeitliche Ablauf zweier Aktionen zu verstehen.
Beim Erreichen eines vordefinierten Thresholds kann eine Aktion ausgelöst werden. Diese können eine ganze Bandbreite von passiven oder aktiven Aktionen umfassen. Zum Beispiel:
Es gilt also zu definieren, ab welcher Summe von Strafpunkten welche Aktion ausgelöst wird. Die Schwierigkeit besteht hier darin, den goldenen Mittelweg zu finden. Bei False-Negatives werden illegitime Zugriffe nicht erkannt bzw. nicht darauf reagiert. Und bei False-Positives werden Restriktionen zu rigoros angewendet und damit legitime Zugriffe unnötig erschwert. Beides gilt es zu verhindern.
Ein leicht nachvollziehbares Beispiel liefert das Verhalten bei fehlerhaften Login-Versuchen. Der Einfachheit halber gehen wir davon aus, dass jeder fehlerhafte Login-Versuch den Strafpunktebestand um 1 erhöht.
Stufe | Threshold | Aktion |
---|---|---|
1 | 3 | Benachrichtigung des Kontoinhabers über verdächtige Aktivitäten. Zurücksetzen des Passworts offerieren, falls es vergessen wurde. |
2 | 5 | Verlangsamen der Datenverarbeitung um 1-3 Sekunden, um Bruteforce-Angriffe stark zu verlangsamen. |
3 | 10 | Login ist gar nicht mehr möglich. Der Benutzer wird aber nicht darauf hingewiesen, so dass Bruteforce-Zugriffe ins “Leere” laufen. Selbst die Eingabe der richtigen Login-Daten würde nicht zu einem Login führen. |
4 | 25 | Sperren der Quell-IP-Adresse für sämtliche Login-Versuche für alle Benutzerkonten für 15 Minuten, um breitflächige Bruteforce-Attacken einzuschränken. |
Hierbei ist zu sehen, wie ein Innen-nach-Aussen Ansatz gewählt wurde: Die Bestrafung wird zuerst möglichst eng gefasst (nur punktuelle Information) und dann immer mehr ausgeweitet (langsamer und dann einschränken). Dadurch können Kollateralschäden verhindert oder wenigstens hinausgezögert werden.
Der Aspekt bei dem hier diskutierten Ansatz, der den meisten Kunden die grössten Probleme bereiten, ist das Entwickeln einer Metrik samt ihrer Abstufungen. In Bezug auf fehlerhafte Login-Versuche scheint dies noch einfach zu sein. Komplizierter wird es aber, wenn man Transaktionen nach einem erfolgreichen Login überwachen will.
Hierbei gilt es in Szenarien zu denken. Die für die diskutierten Szenarien generierten Punkte sind entsprechend zu sanktionieren. Wenn uzm Beispiel ein Betrüger einen Account übernommen hat, um eine Bestellung an eine nicht existierende Adresse zu schicken, den Zugriff via VPN durchsetzt und den diesen automatisiert hat (es wird kein User-Agent String mitgeschickt), ergibt dies 22 Punkte. Anhand der unten definierten Thresholds würde dies das Einschränken der Zugriffsmöglichkeiten nach sich ziehen:
Threshold | Aktion |
---|---|
4 | Warn-/Fehlermeldung |
6 | Erweitertes Logging |
12 | Verlangsamung der Verarbeitung |
16 | Informieren bestimmter Stellen |
16 | Zusätzliche Identifikation erforderlich |
18 | Zusätzliche Authentisierung erforderlich |
20 | Manuelle Prüfung erforderlich |
22 | Einschränken von Zugriffsmöglichkeiten |
25 | Unterbinden sämtlicher Zugriffe |
Während der Diskussion der Szenarien kann auffallen, dass einzelne Verstösse nicht offensichtlich genug mit Strafpunkten versehen sind. Dass sich also kleinere Verstösse nicht früh genug erkennen oder sich nicht von groben Verstössen unterscheiden lassen. In diesem Fall muss man die grundlegenden Strafpunkte neu vergeben. Es erfordert viel Zeit und Diskussionen, um ein nachhaltiges Model entwickeln zu können, das zuverlässig arbeiten kann.
In einer Client-/Server-basierten Lösung müssen die Sicherheitsmechanismen auf dem Server zusammengefasst werden, um Manipulationen zu verhindern. In der Applikationslogik müssen bestimmte Punkte definiert werden, an denen Strafpunkte vergeben werden können. In diesem Beispiel wird bei jedem fehlerhaften Loginversuch ein Strafpunkt hinzugefügt.
if(password_verify($_POST['password'], $row['password'])){ echo 'You are authenticated!'; }else{ $_SESSION['penalty'] = $_SESSION['penalty'] + 1; echo 'Authentication failed.'; }
In einem weiteren Schritt geht es darum, dass frühstmöglich in der Applikation abgefragt werden muss, ob der Threshold für Strafpunkte schon erreicht wurde. Zu diesem Zweck wird im Idealfall zu Beginn ein Codeblock der folgenden Form verwendet:
if($_SESSION['penalty'] >= 3){ mailuser(); }elseif($_SESSION['penalty'] >= 5){ slowdown(); }elseif($_SESSION['penalty'] >= 10){ disablelogin(); }
Eine intelligente Implementierung verhindert die Ausführung unnötigen Codes (früh in der Applikationslogik), setzt auf intelligente Thresholds und nachhaltige Aktionen.
Die Schwierigkeit besteht darin, ein zuverlässiges Modell zu erarbeiten. Zu diesem Zweck ist eine umfassende Auswertung des legitimen Verhaltens erforderlich. Hierfür müssen unter Umständen mehrere Monate von Benutzerzugriffen ausgewertet und gruppiert werden. Die grosse Datenlage macht diese Arbeit komplex und aufwendig.
Dennoch oder gerade deswegen empfehlen wir einen simulationsbasierten Ansatz. Das Modell wird als Simulation zur Verfügung gestellt, in der die bisher angefallenen Daten eingebracht werden können. Durch das Parametrisieren der Events, Thresholds und Actions können statistische Aussagen zur Zuverlässigkeit (False-Positives und False-Negatives) einzelner Einstellungsvarianten getroffen werden.
Das Erreichen eines perfekten Modells ist eigentlich niemals möglich. Eine Gewisse Abweichung des Optimums muss immer in Kauf genommen werden. Die Simulation hilft dabei, diese Abweichung erkennen und akzeptieren zu können. Auch dadurch vielleicht 2% der Betrugsfälle trotzdem nicht erkannt und verhindert werden können, stellt dies eine Verbesserung von 98% dar.
Betrug in Online-Diensten ist kein neues Phänomen. Stattdessen hat hierbei eine regelrechte Professionalisierung stattgefunden. Diese zu bekämpfen ist wichtig, um gewisse Dienste zuverlässig und wirtschaftlich halten zu können.
Zu diesem Zweck lohnt sich der Einsatz einer Anomalieerkennung. Zuerst muss das normale Verhalten ermittelt werden, um Abweichungen erkennen und richtig taxieren zu können. Durch das Vergeben von Strafpunkten werden irgendwann vordefinierte Thresholds erreicht, wodurch punktuelle Aktionen ausgelöst werden können. Dadurch können Angriff erschwert oder gänzlich abgewehrt werden.
Eine Simulation hilft dabei, ein optimales Modell zu entwickeln. Es ist wichtig dabei zu bedenken, dass man sich in der Regel dem Optimum nur annähern, dieses jedoch nie erreichen kann. Eine Verbesserung ist aber in jedem Fall möglich und sollte dementsprechend auch angestrebt werden.
Wir führen gerne für Sie ein Monitoring des Digitalen Untergrunds durch!
Marc Ruef
Marc Ruef
Marc Ruef
Marc Ruef
Unsere Spezialisten kontaktieren Sie gern!