Über die letzten Wochen haben wir das Thema schwache Kennwort-Hashes in SAP ausführlich beleuchtet. Neben einem denkbaren Szenario zur Ausnutzung einer solchen Schwachstelle, einer Anleitung zum Hacken von schwachen Kennwort-Hashes und den Maßnahmen zum Schutz, stellen wir in diesem Blog Beitrag die Verwendung von Datenanalysen zur Erkennung von Fraud Potentialen vor.
Die Kombination aus Datenanalysen als Schlüssel zum Erfolg
Betrachtet man das Szenario aus dem Blog Artikel „Schwarzer (Hash) Peter: Wer mit den Hunden schläft,…„, so fällt dem versierten Leser eine Verkettung unglücklicher Umstände auf. Einzeln betrachtet mögen die Ergebnisse der jeweiligen Datenanalyse zunächst weniger kritisch erscheinen, die Kombination sollte Sie als Prüfer allerdings stutzig und hellhörig machen. Doch eins nach dem anderen. Bevor wir mit der Tür ins Haus fallen zeigen wir zunächst detailliert auf, welche Möglichkeiten der Datenanalysen überhaupt bestehen, um im Anschluss die Verkettung deutlicher darzustellen.
In dem beschriebenen Szenario macht Pjotr Melnikow sich die unzureichende Absicherung der Lesezugriffe auf die SAP Tabelle USR02 zu nutze. Dieser Tatbestand findet sich leider in keiner SAP Tabelle wieder, da rein lesende Zugriffe in keiner Tabelle, sondern in einem Log dokumentiert werden. Die Log-Analyse steht in diesem Artikel allerdings nicht im Vordergrund. Als erster verwertbarer Ansatzpunkt dient somit die Nutzung des „SAP_ALL“ Profils. Eine Liste aller Nutzer mit SAP_ALL Profil findet sich in der SAP Tabelle „UST04“, oder alternativ über den Report „RSUSR002“. Entweder Sie filtern direkt auf die kritischen Profile „SAP_ALL“, bzw. „SAP_NEW“, oder alternativ besteht auch die Möglichkeit der Verwendung des SQL Editors, z.B. über die Transaktion „DB50“ oder „DBACOCKPIT“. Links in der Navigation unter „Diagnose -> SQL-Editor“ können Sie dann folgenden SQL Befehl eingeben:
SELECT * FROM UST04 WHERE PROFILE=’SAP_ALL‘ OR PROFILE=’SAP_NEW‘
Soviel zunächst zu allen Profilen mit allen Rechten. Mit der Liste können Sie bereits in Ihre IT-Abteilung gehen und kritisch hinterfragen. Der DSAG Prüfleitfaden SAP ERP 6.0 spricht in diesem Zusammenhang ganz deutlich die Vermeidung solcher Profile aus. Neben den genannten Profilen kann es unter Umständen noch weitere Profile mit sehr weitreichenden Rechten geben. Diese Art der Analyse wäre an dieser Stelle allerdings zu weitreichend.
Im Anschluss hat Pjotr einen gehackten SAP Nutzer für die Änderung von Kreditoren-Stammdaten in SAP verwendet. In dem Zusammenhang sind gleich zwei Datenanalysen sinnvoll für die Aufdeckung. Zum einen ist es die Vermeidung von Funktionstrennungskonflikten, die wir bereits im letzten Artikel beschrieben haben: Einrichtung des Vier-Augen-Prinzips für Stammdatenänderungen und zum anderen die kritische Änderung der Kreditoren-Bankverbindung. Auch ohne Betrachtung der Funktionstrennung kann die Veränderung z.B. der Kreditoren Stammdaten analysiert werden.
Allerdings wäre es nicht SAP, wenn wir einen Blog Post ohne einen einzigen Haken an der Sache schreiben könnten. Änderungen werden mit ein paar Ausnahmen in der Tabelle „CDHDR“ (Änderungsbelegkopf) gespeichert. Dazugehörige Positionen finden sich in der SAP Tabelle „CDPOS“ (Änderungsbelegposition). Die manuelle Auswertung gestaltet sich bis zu einem gewissen Punkt dann auch nicht mehr so schwierig.
Rufen Sie die Transaktion „SE16N“ oder „SE16“ unter Angabe der Tabelle „CDPOS“ auf. Für die Felder Tabellenname verwenden wir die SAP Tabelle „LFBK“ (Lieferantenstamm – Bankverbindungen) und als Feldname „KEY“. Die entsprechenden Einstellungen sehen dann folgendermaßen aus:
Der Feldname „Key“ erscheint zunächst verwirrend. Für die Leser mit mindestens rudimentären Datenbank-Grundlagen ist das allerdings schnell erklärt: Wird in SAP ein Wert geändert, der in der entsprechenden Tabelle als Primärschlüssel oder Teil des Primärschlüssels verwendet wird, dann wird in der „CDPOS“ lediglich eine Veränderung des Primärschlüssels gespeichert. In der Kurzfassung ist ein Primärschlüssel ein Wert, oder eine Kombination aus Werten, die eindeutig zur Identifizierung eines Datensatzes (vereinfacht: einer Tabellenzeile) verwendet werden. Im Bild oben ist der Primärschlüssel der Tabelle „CDPOS“ blau gekennzeichnet. Demnach besteht der Primärschlüssel von „CDPOS“ aus: Mandant, Änderungsbelegobjekt, Objektwert, Belegnummer, Tabellenname, Tabellenschlüssel, Feldname und Änderungskennzeichen.
Leider befindet sich in der Tabelle „CDPOS“ nicht der Benutzer der Änderung. Diesen finden Sie über eine anschließende Abfrage auf die identifizierte Belegnummer aus „CDPOS“ in der Tabelle „CDHDR“. So können Sie zumindest manuell herausfinden, wann welcher Nutzer Bankdaten in den Kreditoren-Stammdaten geändert hat. Einmalige Änderungen können je nach SAP System und der Anzahl von Buchungen allerdings häufig vorkommen. Aus dem Grund ist es nicht ratsam jeden einzelnen Fall zu untersuchen, da wir in diversen Analyseprojekten eine große Menge an False-Positives festgestellt haben. Besonders auffällig sind mehrfache Änderungen von Kreditoren-Bankverbindungen eines einzigen Kreditors. Diese sollten von Ihnen besonders gewürdigt und näher untersucht werden. Unter Umständen stellen Sie in diesem Zusammenhang aber auch keine besonderen Auffälligkeiten fest. Wie das sein kann erklären wir im nächsten Abschnitt.
Das Zusammensetzen des Puzzles
Vielleicht kommen Sie zu dem Entschluss, dass jede Prüfung für sich zunächst durchschnittlich kritisch zu bewerten und zudem auch noch sehr aufwändig / zeitintensiv ist. Allerdings spielt die Musik in der Kombination an Feststellungen und dem jeweiligen Kontext. Um den Kontext richtig einordnen zu können bedienen wir uns unter anderem an Methoden aus dem Bereich des Process Minings. Diese nutzen wir für die automatische Rekonstruktion der tatsächlichen Geschäftsvorfälle und Nutzen den Ausgleichsmechanismus in SAP für die vollständig automatisierte Generierung von Prozesssequenzen. Auf dieser Grundlage bekommen Feststellungen eine ganz andere Bedeutung. Stellen Sie sich vor, dass während der Bestellung von Stahl, kurz vor dem Wareneingang der Bestellung die Kontodaten des Kreditors geändert werden und kurz nach dem Rechnungsausgleich erneut – und das in ein und derselben Prozesssequenz. Welches Bild bekommen Sie jetzt von der Prozesssequenz im Einkauf? Und dann stellen Sie fest, dass eine Funktionstrennung in der Sequenz auch noch fehlt und als Feststellung markiert wurde. Klingelt es bei Ihnen schon?
Sie merken die Kombination aus Feststellungen und ihrem Kontext ist ein sehr guter Ansatz zur Bewertung von wirklich kritischen Prozesssequenzen / Prozessabläufen, die im wahren Leben, wie auch in SAP nie so ablaufen, wie sie einmal geplant waren. Vergessen Sie den Abgleich von Soll und Ist Prozessen. Eine Übereinstimmung und damit einen reibungslosen Ablauf gibt es in vielleicht 5% der Fälle.
Die Datenindikatoren aus zap Audit für die kritischen Feststellungen wären folglich:
| Name des Indikators | Beschreibung |
|---|---|
| Funktionstrennungskonflikte | Ein Beleg wird markiert, wenn dieser in einem Funktionstrennungskonflikt zu einem anderen Beleg steht. |
| Mehrfach geänderte Kreditor-Bankverbindungen | Ein Rechnungswesenbeleg wird markiert, wenn dieser zwischen zwei Änderungen des Bankkontos eines im Beleg verwendeten Lieferanten erfasst wurde. Dabei liegen diese Änderungen an dem Bankkonto maximal 7 Tage auseinander. |
| Aktivitäten von Superusern | Ein Beleg wird markiert, wenn dieser von einem Nutzer gebucht wurde, welcher Standard SAP Administrationsprofile als Nutzerrechte hat. |
Tabelle 1: Eine mögliche Kombination aus zap Audit Datenindikatoren zur Aufdeckung von Fraud
Mit dem Beta Update auf die neue Version von zap Audit am 08.12.2017 erweitern wir außerdem den Indikator für die Aktivitäten von Superusern. In Zukunft wird neben dem pseudonymisierten Nutzernamen zusätzlich ein Hinweis auf den verwendeten Kennwort-Hash gegeben. Dieser gliedert sich in drei Stufen von schwach (md5 Hash) über mittel (SHA-1 Hash) bis zu stark (iSSHA-1 Hash). Auf diese Art können extrem kritische Superuser mit zusätzlich sehr schwachen Kennwort Hashes noch schneller und effektiver identifiziert und geprüft werden.
