Finanzgedanken: Ihre Dosis Sicherheit - Teil 2

von Andreas Schulz

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.

Ziel 1: Erlangung von Wettbewerbsvorteilen durch Ausspähen von Geheimnissen
Mittel: Industriespionage
Daten: Produktionsdaten / Schaltpläne / Dokumentationen / Mails / Strategiepapiere / …
Beispiel: Einem Abgesandten eines amerikanischen Konkurrenzunternehmens gelang es bei dem Unternehmen Enercon aus Aurich mit einem Computer wichtige Daten über die Windkraftturbine "E 40" zu stehlen. Weitere Turbinen konnten nicht nach Amerika exportiert werden, da behauptet wurde, dass die Turbine von Amerikanern entwickelt worden sei. Dies hatte zur Folge, dass eine große Anzahl von Aufträgen nicht mehr erfüllt werden konnte, und Enercon letztlich Einnahmen von ca. 100 Millionen Euro einbüßte.
   
Ziel 2: Erpressung
Mittel: Datendiebstahl
Daten: Daten von Mitarbeitern, Kunden und Lieferanten
Beispiel: Bei dem Seitensprungportal Ashley Madison wurden Userdaten (Adressen / Kontonummern / Vorlieben / …) durch TIM (The Impact Team) abgefischt. Die Hacker behaupteten, die Betreiberfirma ALM belüge ihre Kunden und forderte, dass Ashley Madison und eine weitere Site vom Netz genommen werden. TIM veröffentlicht zunächst in Teilen Daten zu Gehältern und Kontoverbindungen von ALM-Mitarbeitern sowie Daten (Klarnamen + intime Informationen) von Usern. Der Fall ist noch nicht abgeschlossen.
   
Ziel 3: Kompromittieren von Systemen
Mittel: z.B. Einschleusen eines Virus
Daten: Alle
Beispiel: WannaCry – Oops, your files have been encrypted. Hacker haben mit einem Großangriff 120.000 Computer in bis zu 100 Ländern gekapert. Regierungen, Unternehmen, Behörden und auch viele Bürger sind betroffen (Deutschen Bahn / russisches Innenministerium / englische Krankenhäuser), besonders viele in Russland, der Ukraine und Taiwan. Nichts geht mehr. Die Hacker haben die infizierten Computer wie mit einem großen Schloss gesperrt und fordern Lösegeld. Sie forderten etwa 300€ Lösegeld für jeden Computer. Dieses sollte in Bitcoins, einer virtuellen Währung, anonym im Internet bezahlt 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.

Die wahre Geschichte - Innentäter

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.

Die wahre Geschichte - Außentäter

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!

Zerlegen Sie ihre Prozesse und identifizieren Sie die Schwachstellen

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 versenden: Die Versendung erfolgt mittels einer BCM (Bankkommunikationssoftware). In den meisten Fällen ist das eine vom ERP-System unabhängige Software. Das bedingt Schnittstellen. Verhindern Sie das Einschleusen von Dateien. In jeder (vernünftigen) BCM kann voreingestellt werden, dass Zahldateien nur von ausgewählten Verzeichnissen importiert werden können! Befassen Sie sich mit der Berechtigungsverwaltung ihrer BCM. Die ist unabhängig von Signaturrechten gegenüber den Hausbanken und regelt den Zugriff auf die Software an sich.
   
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-Systems 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.

Schreiben Sie uns gerne Ihre Erfahrungen und Meinungen an andreas.schulz@litreca.com und helfen Sie damit allen.

Zurück

 

Sie haben Fragen oder möchten mehr über unsere Lösungen erfahren?

Dann vereinbaren Sie jetzt eine unverbindliche Onlinepräsentation, bei der Sie ganz bequem vom Schreibtisch aus teilnehmen können.

 

Jetzt Onlinepräsentation vereinbaren