“Offline Zahlungs-Software im Visier von Hackern – Schweizer Unternehmen betroffen”

Obige Schlagzeile ist der Mitteilung der Melde- und Analysestelle Informationssicherung MELANI im Juli dieses Jahres entnommen. Sie beschreibt eine neue Art von Hacker-Angriff auf Unternehmen in der Schweiz.

Firmen verwenden heute für die Abwicklung von Massenzahlungen, insbesondere bei Multibank-Verbindungen, in der Regel eine sog. Offline-Software für die Übermittlung, Freigabe und Ausführung von elektronischen Zahlungsaufträgen. Dabei werden Überweisungen automatisiert direkt aus der ERP-Software ausgelöst und über sichere Protokolle an die Bank übermittelt. Diese Art der Zahlungsverkehrsabwicklung macht den Großteil der heute in der Schweiz elektronisch eingereichten Aufträge aus.


Die in der Meldung von MELANI beschriebene Schadsoftware „Dridex“, die sich über schädliche Microsoft Office Dokumente in E-Mails von vermeintlich legitimen Absendern verbreitet, fokussiert seit neuestem genau diese Offline-Software-Lösungen. Dabei werden gezielt Hersteller attackiert, die im Schweizer Markt eine gewisse Verbreitung haben. Viele Firmen sind aktuell etwas verunsichert, wie sicher ihre Lösung in Tat und Wahrheit noch ist und wie sie sich gegen ähnliche Hacker-Angriffe schützen können.

Zunächst gelten einmal die von MELANI seit langem publizierten Sicherheitshinweise wie Verwendung dedizierter Computer, Ignorierung von Mails mit verdächtigen Attachments, regelmäßige Aktualisierung von Betriebssystemen und Virenschutzprogrammen etc., um die Absicherung der eigenen Infrastruktur zu gewährleisten. Ein Hinweis fällt dabei ins Auge, nämlich der, dass Kollektiv- anstelle von Einzelunterschriften eingesetzt werden sollen. Wie funktioniert das in der Praxis, wo ja keine Papier-Aufträge mehr physisch von den Bevollmächtigten der Firma signiert und an die Bank versendet werden?

Die Banken bieten hier grundsätzlich zwei Lösungen an (teilweise auch in Kombination). Einerseits ist die Freigabe über einen anderen Kanal möglich. Das heißt, die Datei mit den Zahlungsaufträgen wird beispielsweise über das Protokoll EBICS (Electronic Banking Internet Communication Standard) direkt aus der Offline-Software an die Bank übermittelt, wobei der Auftrag aber noch nicht zur Ausführung autorisiert wurde. Mittels Freigabe im Online-Banking der Bank können die Aufträge dann definitiv von einer zweiten Person freigegeben werden.

Eine weitere, sichere und flexible Art der Kollektiv-Unterschrift ist der Einsatz der im EBICS-Standard enthaltenen „Verteilten elektronischen Unterschrift“ (VEU). Der Standard sieht hierbei die Unterschriften-Modelle „Transport“- (keine Autorisierung), „Einzel“-, „Kollektiv A“- und „Kollektiv B“-Unterschriften vor. Pro Auftrag kann zudem auf Seiten der Bank ein Tageslimit definiert werden (wahlweise pro Kunde, Konto und Auftragsart). Die VEU erlaubt dem Kunden eine 1:1 Abdeckung der Unterschriftenregelung seiner Unternehmung und führt in Verwendung mehrerer Kanäle (z. B. Erteilung der zweiten Unterschrift über ein Mobile Device) zu einem sehr hohen Sicherheitsniveau.
Immer mehr Banken in der Schweiz führen die EBICS VEU als Angebot ihrer E-Banking-Lösungen ein. Erkundigen Sie sich bei Ihrem Institut explizit danach oder stellen Sie Ihre Fragen an info@ppi.ch, wenn Sie noch mehr Information zur EBICS VEU benötigen.

Original-Meldung MELANI: https://www.melani.admin.ch/melani/de/home/dokumentation/newsletter/offline-payment-software.html

Carsten Miehling 

Weiterlesen

EBICS und der mobile Zahlungsverkehr in Frankreich

In der Reihe „EBICS als europäischer Standard für Mobile Payments“ wollen wir heute den Fall Frankreich näher betrachten.
Eine mobile Lösung, die es jedem Nutzer ermöglicht, Transaktionen von unterwegs - gemäß EBICS TS-Protokoll - zu unterschreiben, würde den Bedürfnissen der immer zahlreicher werdenden „Nomaden“ unter den Unterzeichnern entsprechen, die darauf hoffen, dass Mobile Banking mit EBICS endlich Realität wird.


Voraussetzung wäre, dass eine solche Lösung ausreichend flexibel ist, d. h. auf der großen Mehrheit von Mobiltelefonen und Tablets läuft, unabhängig von deren Betriebssystem (zumindest iOS, Android, Windows Mobile), und genauso ein hohes Sicherheitsniveau bietet wie die EBICS TS-Signatursoftware für PCs, die täglich tausendfach verwendet wird.

Natürlich hat bereits der eine oder andere Softwarehersteller mobile Applikationen entwickelt, doch bleiben diese allesamt unbefriedigend und werden wenig genutzt, weil ihnen die nötige Flexibilität und Benutzerfreundlichkeit fehlt. Um den Spezifikationen des CFONB (französisches Komitee für Organisation und Normierung im Bankwesen) aus dem Implementation Guide zu entsprechen, muss jede Unterschrift über ein persönliches Unterschriftszertifikat auf einem physikalischen Träger verfügen, das von einer von der Bank anerkannten Zertifizierungsstelle ausgestellt wird. Und genau da liegt der Hund begraben: Es ist zwar möglich, einen USB-Token an bestimmte Tablets anzuschließen, aber es ist bis heute nicht möglich, ihn an alle mobilen Geräte unabhängig von ihrer Marke anzuschließen. Nimmt man hohe Adapter- und Anschlusstechnikkosten in Kauf, könnte man dennoch ans Ziel kommen. Doch funktionieren all diese Lösungen eher schlecht als recht, zumal sie den Benutzer zwingen, sein Gerät in einen komplizierten Apparat zu verwandeln, was schließlich den letzten Enthusiasten von einem systematischen Gebrauch solcher Lösungen abhalten wird.
Auch ist es weder vernünftig noch angemessen, die Unterzeichner zu zwingen, sich ein zusätzliches Smartphone oder Tablet zuzulegen, bei dem ein Token einigermaßen komplikationslos angeschlossen werden kann, so dass es bei Bedarf sofort genutzt werden könnte.

Eine Lösung bestünde darin, anstelle des physikalischen Trägers als Speichermedium für das Zertifikat ein „flüchtiges“, d. h. einmalig zu verwendendes Zertifikat einzuführen. Neben der hierfür unerlässlichen Zustimmung durch das CFONB würde dies jedoch bedingen, dass das Zertifikat, wann immer es verwendet wird, bei der Zertifizierungsstelle neu registriert werden muss, was dem Vorgang jedwede Flexibilität und damit jedweden Charme nähme.

So bleibt das Problem, dass das Verfahren der verteilten Unterschrift nicht standardisiert ist wie bei unseren Nachbarn jenseits des Rheins, die von der Verteilten Elektronischen Unterschrift (VEU) profitieren. Auch wenn es bedauerlich ist, dass EBICS DS bis heute nicht konkretisiert worden ist, so stellt dies doch keinen Hinderungsgrund dafür dar, einen Service mit äquivalenter Funktionsabdeckung anzubieten, also den reisenden Unterzeichnern zu erlauben Aufträge vor der Ausführung zu bestätigen. Die Verwaltung dieser Gruppen von Unterzeichnern und Unterschriftenmappen erfolgt vorher auf einer vom Unternehmen oder von vertrauenswürdigen Dienstleistern bzw. Betreibern betriebenen Plattform. Sobald alle notwendigen Unterschriften vorliegen (unbedingt im Format EBICS [A005 bzw. A006]), werden der Auftrag und die gespeicherten Unterschriften über EBICS im TS-Profil an den entsprechenden Server weitergeleitet. Mit dieser Lösung könnten umfassendere Unterschriftsrechte als mit dem EBICS-Standard (1+1 bzw. 2) verwaltet werden, womit sie den Ansprüchen der Benutzer potenziell näher kommt.

Marc Dutech 

Weiterlesen

Blog-Serie: Wie sich EBICS verbessern lässt, Teil 2 – mit EBICS und der VEU Autorisierungen delegieren

Mit diesem Artikel setzen wir unsere im Dezember begonnene Serie über mögliche Verbesserungen in EBICS fort. Dieser Artikel widmet sich nun folgendem Problem: Wenn man heute per EBICS einen Zahlungsverkehrsauftrag einreicht, hat der Einreicher im Standardfunktionsumfang keine Möglichkeit mehr, auf die weitere Autorisierung Einfluss zu nehmen. In manchen Fällen ergibt sich aber erst mit der Einreichung, wer für die weitere Autorisierung in Frage kommt und man möchte die Autorisierung situativ delegieren.

Im aktuell spezifizierten Funktionsumfang von EBICS sind Bankrechner-seitig unterschiedliche Berechtigungsmodelle für die Einreichung und Autorisierung von Auftragsdateien durch Firmenkunden anwendbar. Diese Modelle beruhen in der Praxis stets auf den Unterschriftsklassen E, A, B und T, der Anzahl erforderlicher Unterschriften sowie der personenbezogenen Berechtigung für eine physische Datei. Darüber hinaus haben die Kreditinstitute und Softwarehersteller die Berechtigungsmodelle im Laufe der Zeit so erweitert, dass sie sich für verschiedene Einsatzszenarien eignen. Beispiele für solche Erweiterungen sind:

• Berechtigungen bezogen auf eine Person und einen Auftrag in Kombination mit Unterschriftsklassen,  Auftragsarten (also bestimmten Geschäftsvorfällen) und Konten.
• Verschiedene Limit-Konzepte, zum Beispiel über Beträge, Anzahl der Transaktionen, für Zeitfenster, geltend für Personen, Konten und/oder Kunden sowie nach Unterschriftsklassen gestaffelte.
• Gruppenkonzepte in Verbindung mit Unterschriftsklassen, zum Beispiel  zur Berechtigung der Autorisierung von Personen ausschließlich verschiedener oder ausschließlich gleicher Gruppen.
• Proprietäre Unterschriftsklassen, die eigene Wertungen für eine Autorisierung berücksichtigen.
• Verfahren für Service-Rechenzentren (SRZ-Verfahren), in denen die Prozesse der Einreichung und Autorisierung auf Kundenebene getrennt ablaufen.

All diese Modelle sind als relativ statisch anzusehen. Das heißt, wenn ein EBICS-Kunde einen Auftrag einreicht, kann er nur bedingt beeinflussen, wie die Bank den Geschäftsvorfall abwickelt. Es gelten stets die bankseitig eingerichteten Stammdaten als Grundlage für die Berechtigungsprüfung, Formatprüfung und Autorisierung. In den Fällen, in denen eine eindeutige Herleitung der Berechtigungen im EBICS-Umfeld bankseitig möglich ist,  mag dies sinnvoll und auch gewollt sein. Allerdings können im EBICS-Prozess Einreichungs-Aufträge, die vom Sachverhalt her unterschiedliche Behandlungen erfordern, nicht in verschiedener Weise abgewickelt werden. Bei gleichförmigen SEPA-Einreichungen mit der Auftragsart CCT zugunsten eines bestimmten Kontos wären zum Beispiel stets alle für dieses Konto und diese Auftragsart im Bankrechner zur verteilten elektronischen Unterschrift (VEU) berechtigen Personen zur Autorisierung berechtigt.

Wäre es nicht sinnvoll, wenn man als Kunde bei Bedarf mit der Einreichung in EBICS bereits die Personen benennen könnte, an die man die Autorisierung delegieren möchte? Diese Personen müssen natürlich bankseitig grundsätzlich über die entsprechende Basis-Berechtigung verfügen. Der Vorteil wäre, dass die nicht benannten Personen mit der ansonsten gleichen Basis-Berechtigung den Auftrag nicht zur VEU gestellt bekommen und somit auch nicht einsehen können. Dieses Modell ist zum Beispiel für Fälle geeignet, in denen über ein bestimmtes Konto sowohl beliebige Zahlungen, als auch Gehälter oder Gagen-ähnliche Zahlungen abgewickelt werden und die Zahlungen gleichzeitig über keine besondere Kennzeichnung verfügen. Solche Kennzeichnungen sind ohnehin weitestgehend format- und länderspezifisch. Mit einer entsprechenden Erweiterung des EBICS-Standards wäre somit eine formatunabhängige Lösung umsetzbar.

Michael Lembcke 

Weiterlesen