Finanzgedanken: Ihre Dosis Sicherheit – Teil 2

Herzlichen Dank für Ihre zahlreichen E-Mails, die uns gezeigt haben, wie ernst das Thema Betrug genommen wird. Zunächst möchten wir hier noch eine Abgrenzung vornehmen, um die Diskussion in geregelte Bahnen zu lenken. Rechnung tragen wollen wir auch der typischen Leserschaft des Litreca Inside: CFOs, Treasurer, Cash-Manager und Mitarbeiter in Finanzabteilungen. Das Kriterium für die Abgrenzung ist die unterschiedliche Zielsetzung der Angreifer und mithin die unterschiedlichen Wege, die für Angriffe genutzt werden.

Werden die 3 Ziele betrachtet, wird deutlich, dass es sich immer um zweistufige Verfahren handelt. Zunächst muss es den Angreifern gelingen in das fremde System einzudringen. Natürlich klappt das leider nur allzu oft, es ist aber durchaus nicht ganz so einfach, wie das mitunter vermittelt wird. Stufe 2 ist dann das Ausnutzen der Situation. Heißt: Konten von Personen, deren Daten gestohlen wurden, werden geplündert oder das Unternehmen wird erpresst. Die Täter müssen also mit ihrer Beute noch davonkommen. Auch das will gelernt sein.

Der typische Mitarbeiter in der Finanzbuchhaltung – egal ob Buchhalter oder CFO – hat wenig oder gar keinen Einfluss auf die Verhinderung der geschilderten Vorgänge. Es sei denn er geht fahrlässig mit seinen Zugangsdaten um und verschafft den Betrügern dadurch Zugriff auf das System.

Die Welt von Finanzbuchhalter und Co. ist eine Welt der Zahlen: Bilanz und GuV, Liquidität und Cash flow, Kontenstände und Cashpooling, Fremdwährungsgeschäfte und Akkreditive, Regulierung von Forderungen und Verbindlichkeiten etc., sowie die Erstellung von Zahlungsdateien. Damit wollen wir uns (zunächst) befassen.

Die direkte Manipulation des Zahlungsverkehrs übt seit jeher großen Reiz auf Kriminelle aus. Wenn es gelingt eine Überweisung auf das eigene Konto zu veranlassen – man kann es sich vorstellen, erst das Adrenalin, dann die Glückshormone, dann ab in den Süden! Aber wie geht das? Wie Sie an den folgenden Beispielen sehen können, ist es gar nicht immer erforderlich ein System zu hacken. Es müssen auch nicht unbedingt Mitarbeiter manipuliert werden. Oft genug bietet sich die Gelegenheit zu Diebstahl und Betrug.

Eine Landesbehörde in Baden-Württemberg: Es sind regelmäßig Auszahlungen über hohe Beträge an Antragsteller zu tätigen, die seinerzeit noch mittels manuell ausgefüllten Überweisungsträgern zur Bank gegeben werden. Ein Buchhalter stellt eigene Überweisungen mit seiner Kontonummer darauf aus und schleust diese in den Strom der übrigen Zahlungsträger ein. Die Zahlscheine passieren den Prüfprozess und schon sind die nächsten Besuche im Spielcasino gesichert.

Die zweite Masche ist dreister. Der Mitarbeiter nimmt fertig ausgefüllte Überweisungsscheine mit 6-stelligen Beträgen und schreibt rechts unten das Kürzel „b.w.“. Auf der Rückseite steht dann: „Davon 10.000 Euro zu Gunsten Konto …“ Auch das funktioniert. Aber es kommt, wie es kommen muss, der Schwindel fliegt schließlich durch einen Zufall, nach circa 4 Jahren, auf. Eine Überweisung, genauer gesagt eine Teilüberweisung, kam zurück, da der Empfänger verstorben und das Konto erloschen war. Der Schaden betrug bis dahin über 600.000 Euro. Wenigstens einen Teil des Verlustes muss die Bank übernehmen, weil sie die so genannten Afterüberweisungen nicht hätte ausführen dürfen. Tröstlich ist vielleicht, dass zumindest die zweite Variante im Zeitalter der elektronischen Überweisungen nicht mehr passieren kann. Die hat ja keine Rückseite.

Ein Unternehmen nutzt die Dienste eines Beratungshauses, um Einstellungen am ERP-System vornehmen zu lassen. Ein üblicher Vorgang. Ein Mitarbeiter des Dienstleisters ist vor Ort. Er wird damit betraut notwendige Änderungen am Zahlungsverkehr durchzuführen. Die Änderungen werden im Entwicklungssystem vorgenommen und dann zur Prüfung in ein Test-System übernommen. Wenn alles funktioniert, werden die Einstellungen produktiv gesetzt. Gesagt, getan. Abschließend kontrolliert der Consultant die Änderungen auf dem Computer (im SAP-System) seines Kunden und legt dafür einen Zahlposten für einen Kreditor mit dem Namen „Testlieferant“ und seiner eigenen Kontonummer an. Alles klappt. Er schreibt seinen Dienstleistungsbericht und macht Feierabend. Einige Tage später schaut der Mann zu Hause seine Kontoauszüge durch und ist sehr erstaunt über den außergewöhnlichen Kontostand. Grund: eine Gutschrift über 1.234.567,89 Euro. Ausversehen hatte er den Zahlposten im Produktivsystem des Kunden angelegt. Weder der ungewöhnliche Name noch der unwahrscheinliche Betrag wurde bei der finalen Bearbeitung durch die Mitarbeiter bemerkt und so ging die Überweisung raus.

Wo viel ist, gibt es viele Begehrlichkeiten. Das lässt sich nicht verhindern. Schützen kann man sich dagegen schon. Das ist wie im Straßenverkehr. Wenn das Tempo-30-Schild nicht hilft, muss man eben Ampeln, Blitzer und Blumenkübel aufstellen. Auch Bodenwellen haben sich bewährt!

Die Ausgestaltung von Prozessen obliegt dem Fachbereich und hat zunächst nichts mit der IT zu tun. Ein Zahlprozess besteht aus einzelnen Schritten, an deren Ende eine Zahlung steht. Typischerweise:

Stammdaten:

Erfassung und Änderung von Stammdaten wird nicht von den Buchhaltern, sondern von einer separaten Personengruppe durchgeführt. Geht eine Bitte um Änderung von Stammdaten ein (per Mail, schriftlich, telefonisch), ist die Anfrage zu verifizieren. Es erfolgt ein Rückruf unter den im System geführten Kommunikationsdaten durch Person A. Diese erfasst die Daten und speichert sie. Zur Vermeidung von Erfassungsfehlern werden die Änderungen von Person B geprüft. Person B sendet anschließend eine Benachrichtigung an den Geschäftspartner, dass die Daten XYZ wie gewünscht geändert wurden. Auch diese Information geht an die im System gespeicherten Kontaktpersonen.

Bewegungsdaten:

Erfassung und Änderung von Bewegungsdaten erfolgt typischerweise durch den Einkauf. In klassischen ERP-Systemen ist ein fester Workflow definiert (Bestellung > Wareneingang > Rechnungsprüfung > Überleitung), der nicht ausgehebelt werden kann/darf. Bei Freigabe der Rechnung kann nur unter den im System gepflegten Giroverbindungen ausgewählt werden, die (s.o.) korrekt gepflegt sind. Davon abzugrenzen ist die Erfassung von Rechnungen ohne Bezug zur Logistik, also unmittelbar in der FiBu. Auch hier kann nur unter den im System gepflegten Giroverbindungen ausgewählt werden. Außerdem gilt es Eingabefehler zu verhindern, z.B. beim Betrag. Von Mitarbeiter C erfasste Daten sind von Mitarbeiter D zu kontrollieren. Das gilt auch bei Trennung nach Sachbearbeitern.

Vorschlagslauf einstellen:

Die Erstellung eines Vorschlagslaufes ist an sich unkritisch. Es können aber auch hier Fehler passieren, z.B. wenn die Parameter falsch gesetzt oder falsche Zahlwege ausgewählt wurden etc. Lassen Sie daher die Erstellung des Laufes vom System protokollieren (in SAP über das Registerblatt Zusatzprotokoll). Das Protokoll zeigt an, welche Posten reguliert werden, welche Bank verwendet wird, wie viel Skonto berücksichtigt wird, oder aber warum ein Posten eben nicht ausgeglichen wird. Man erspart sich mitunter viel Sucharbeit.

Vorschlagslauf prüfen:

Bei der Prüfung von Vorschlagsläufen sind die Möglichkeiten der Manipulation gering. Ein Prüfer ändert vielleicht die Bank, an die ein Betrag zu überweisen ist. Da hier aber nur Stammdaten des Geschäftspartners genutzt werden können, die im Vorfeld durch andere gepflegt wurden, …

Zahllauf erstellen:

Die Erstellung des Zahllaufs ist ein technischer Vorgang: Finale Speicherung der freigegebenen Posten. Im ERP-System werden mit dem Speichern Belege gebucht und die OPs ausgeglichen. Damit ist der Zahllauf per se nicht änderbar. Wurde ein Posten fälschlicherweise freigegeben, gibt es nur eine Möglichkeit: Alles auf Anfang! Ausgleiche zurücknehmen und Zahlposten stornieren. Das ist ärgerlich, besonders im Massenzahlungsverkehr. Pech gehabt. Der letzte Stand der VL-Bearbeitung muss identisch sein mit dem Stand des ZL. Eine Änderung der ZL-Daten würde unweigerlich zu einer Abweichung führen. Das kann man überprüfen.

Zahldatei erstellen:

In der Zahldatei sind die Zahlungstransaktionen in strukturierter Form gespeichert. Eine Zahldatei zu ändern ist bei Todesstrafe verboten, gleichwohl ist das möglich und wird auch mitunter gemacht. Gerechtfertigt wird das mit dem immensen Korrekturaufwand, sollte sich mal ein Fehler eingeschlichen haben (Sie erinnern sich: Alles auf Anfang)! Kriminelle haben weniger ehrenwerte Motive und lassen sich auch von der Strafandrohung nicht abschrecken. Verschließen Sie diese Tür. In alten Zeiten hat man zur Sicherheit Prüfsummen über Beträge, Kontonummern und BLZs gebildet. Das geht mit SEPA natürlich nicht mehr. Man kann aber über das Dokument einen Hashwert bilden und das Dokument selbst verschlüsseln, dann ist der Manipulation schon rein technisch ein Riegel vorgeschoben.

Zahldatei signieren:

Mittels der Signatur geben Sie der Hausbank die Freigabe zur Ausführung der Transaktionen in der Zahldatei. Ein Unterzeichner sollte schlimmsten Falls wissen, bestenfalls kontrollieren, was er da unterschreibt. Das ist aber eher unüblich und in den meisten Fällen sogar unmöglich. Besonders im Massenzahlungsverkehr fehlt es dafür an drei Dingen: Zeit, Kompetenz und technische Möglichkeiten. Im Einzelfall kann ein Unterzeichner gar nicht entscheiden, ob eine Zahlung gerechtfertigt ist; das ist Aufgabe des Buchhalters. Auch eine inhaltliche Prüfung ist nicht möglich. Die Datei liegt entweder auf dem Serververzeichnis oder ist schon bei der Bank. Einen Bezug zu einem Vorgang im ERP-System gibt es daher nicht. Sicherheit kann hier die Technik bringen.

1. Generell kann/sollte man die Verantwortung auf zwei Schultern laden. Warum Einzelunterschrift? Vereinbaren Sie mit den Banken, dass immer zwei Berechtigte unterzeichnen müssen.
2. Der letzte Bearbeitungsstand des Vorschlagslaufs ist gleich dem Stand des Zahlungslaufs. Das lässt sich über das Protokoll aus dem ERP-System prüfen.
3. Die Zahlungsdatei selbst wird verschlüsselt. Im ERP-System wird ein Hashwert über die Datei gebildet, der dem Signateur per Mail oder SMS übermittelt wird. Die BCM erstellt ihrerseits einen Hashwert. Der Unterzeichner prüft die Übereinstimmung der beiden Werte.

Wenn Sie die Prozesse wie beschrieben umstellen, sind in den Zahlungsvorgang immer mindestens 4 Personen involviert. Damit ist dann auch fake president kein Thema mehr für Sie! Die Masche funktioniert nur durch Manipulation von Einzelpersonen.