Posts mit dem Label EBICS-Kommunikation werden angezeigt. Alle Posts anzeigen
Posts mit dem Label EBICS-Kommunikation werden angezeigt. Alle Posts anzeigen

EBICS-Security – Wann ist es Zeit für das Update Ihres Kundensystems?

Mit EBICS sind verschiedene Sicherheitsfunktionen und -vorgaben spezifiziert, die von Kunden und Banken einzuhalten sind. Die Bank muss stets darauf achten, dass die aktuellen Vorgaben in ihrem EBICS-Bankrechner angeboten und unterstützt werden. Aber auch der EBICS-Kunde und der einzelne EBICS-Teilnehmer selbst sind dafür verantwortlich, stets Kundensoftware einzusetzen, die den aktuellen EBICS-Sicherheitsstandards entspricht. Daher sind nicht nur aufgrund von funktionalen Anpassungen, sondern auch aus Sicherheitsgründen regelmäßige Softwareupdates der EBICS-Clientsysteme unerlässlich.

Ist eine bestehende EBICS-Clientsoftware schließlich durch Updates auf den neuesten Stand gebracht, heißt das jedoch nicht, dass diese EBICS-Software dann auch automatisch über die aktuellste EBICS-Version und das neueste Sicherheitsverfahren mit der Bank kommuniziert. Je nach zuvor genutzter EBICS-Version und Clientfunktionalität müssen dazu erst noch die verschiedenen Applikationsschlüssel für Verschlüsselung (E002), Authentifikation (X002) und Autorisierung (A004, A005 oder A006) sowie die neu zu nutzende EBICS-Version aktualisiert und mit dem oder den EBICS-Bankrechnern ausgetauscht werden. Zudem könnte es erforderlich sein, die Internetverschlüsselung (TLS) durch einen neuen Zertifikatsaustausch auf eine neuere und sichere Version zu aktualisieren. Diese Art von Aktualisierungen erfordern i.d.R. aktives Handeln und manuelle Eingriffe des EBICS-Teilnehmers.

Warum sind diese Aktualisierungen wichtig?

Für die EBICS-Kommunikation über das Internet sind eigene Sicherheitsverfahren spezifiziert. Diese werden von der EBICS-Gesellschaft im Laufe der Zeit mit neuen EBICS-Versionen immer wieder aktualisiert und an die aktuellen Sicherheitsbedürfnisse angepasst. Ein Beispiel stellen die Schlüssellängen dar. So sind für die Verschlüsselung (E002), Authentifikation (X002) und Autorisierung (A004, A005 oder A006) in älteren EBICS-Versionen noch Schlüssellängen von 1.024 Bit zulässig. Diese Länge entspricht nicht mehr den aktuellen Sicherheitsanforderungen, denn zu kurze Schlüssel gelten als unsicher. Neuere EBICS-Versionen hingegen lassen derzeit nur Schlüssel mit einer Mindestlänge von 2.048 Bit zu. Ein anderes Beispiel sehen wir bei den genutzten Verfahren und Versionen der TLS-Verschlüsselung. Um Sicherheitsempfehlungen, wie z. B. den Empfehlungen des BSI in Deutschland flexibler folgen zu können, hat die EBICS-Gesellschaft für EBICS 3.0 die entsprechenden Vorgaben in einem eigenen Anhang Transport Layer Security zur Spezifikation ausgelagert. Da rückwirkend die Spezifikation zu EBICS 2.5 nicht angepasst werden konnte, hat die DK (Die Deutsche Kreditwirtschaft) 2019 unter dem Titel Empfehlungen zu EBICS-Sicherheitsverfahren und Schlüssellängen zudem ein eigenes Empfehlungsschreiben zu den in EBICS zu nutzenden Sicherheitsverfahren herausgegeben. Siehe hierzu auch www.ebics.de und www.ebics.org.

Um den EBICS-Teilnehmern einen weichen Umstieg auf neuere EBICS-Versionen und Sicherheitsstandards zu ermöglichen, bieten die meisten Banken ihren Kunden jedoch parallel noch die älteren Verfahren an. Leider lässt sich feststellen, dass von Kunden dann aber die Gelegenheit zur EBICS-Aktualisierung in vielen Fällen nicht genutzt wird. Viele verharren auf älteren Systemen und Verfahren. Damit fällt es dann wiederum den Banken, schwer die alten Verfahren abzuschalten.
Am Ende erwartet jeder Beteiligte in der EBICS-Kommunikation, dass ein sicherer Datenaustausch gegeben ist. Einen Schaden möchte niemand erleiden. Also sollte auch jeder dafür Sorge tragen, dass er seinen Teil dazu beträgt. Natürlich ist die EBICS-Sicherheit nicht das Einzige, was Banken und Firmenkunden im Auge halten müssen. Letztendlich müssen heutzutage alle Beteiligten in ihrer Infrastruktur und ihren Softwarelösungen alle erdenklichen Sicherheitsmaßnahmen ergreifen, um Missbrauch und Schaden vorzubeugen.

Also warum noch warten? Gehen wir es an.

Autor: Michael Lembcke

Sie sind Bankkunde und nutzen EBICS: Funktioniert Ihr EBICS-Monitoring auch noch mit EBICS 3.0?

Für das Monitoring der EBICS-Prozesse und -Ergebnisse steht seit EBICS 2.5 den EBICS-Clients neben dem rein textbasierten Kundenprotokoll auch ein XML-basiertes Protokoll für das fachliche EBICS-Monitoring zur Verfügung. Letzteres eignet sich insbesondere für maschinelle Auswertungen. Das textbasierte Protokoll kann durch den EBICS-Client mit der Auftragsart PTK und das XML-basierte Protokoll mit der Auftragsart HAC vom EBICS-Server heruntergeladen werden. Mit EBICS-Version 3.0 ist das textbasierte Protokoll nicht mehr Bestandteil der Spezifikation. Zudem gibt es Änderungen im HAC-Protokoll, die bei der maschinellen Ergebnisauswertung zu berücksichtigen sind. Diese Änderungen wirken sich wegen der erforderlichen übergreifenden Versionsinteroperabilität z. T. auch auf EBICS-Clients niedriger EBICS-Versionen aus, sobald ein EBICS-Bankrechner EBICS Version 3.0 unterstützt.

Für Software-Hersteller und EBICS-Nutzer gilt daher, dass man sich bei den EBICS-Clients, die bereits über Funktionen der maschinellen Kundenprotokoll-Auswertung verfügen, auf Änderungen einstellen muss. Zunächst sollte für maschinelle Auswertungen in EBICS-Clients der Wechsel vom PTK zum HAC vollzogen werden. Außerdem gilt für diejenigen, die bereits das HAC-Protokoll nutzen, dass mit EBICS 3.0 das finale Ergebnis im HAC-Protokoll anders abgebildet wird.

Bisher informierte das HAC-Ende-Kennzeichen mit den Angaben ORDER_HAC_FINAL_POS und ORDER_HAC_FINAL_NEG direkt darüber, ob das Ergebnis der Einreichung positiv oder negativ war. Mit EBICS 3.0 gibt es lediglich noch ein HAC-Ende-Kennzeichen ORDER_HAC_FINAL, welches den Ausgang der Einreichung ausschließlich in Verbindung mit dem letzten Reason Code ausdrückt. Demnach weist dann beispielsweise der finale Code DS04 darauf hin, dass der Auftrag abgelehnt wurde und DS05, dass der Auftrag erfolgreich eingereicht und an die Banksysteme weitergeleitet wurde. Weitere Reason Codes sind zu berücksichtigen.

Also, damit Ihr EBICS-Monitoring auch weiterhin die korrekten Ergebnisse liefert, empfehle ich auf das HAC-Kundenprotokoll zu setzen und sich auf die Auswertung der Reason Codes zu konzentrieren. So behalten Sie auch zukünftig den Überblick in der EBICS-Kommunikation mit Ihrer Bank.


Michael Lembcke