Sicherheit von e-Arztbriefen

[RAMöller]

In bereits 50% der Fälle funktioniert bei uns der Import von e-Arztbriefen schon sehr erfolgreich.
Sorge bereitet uns nun die Information, dass in PDF-Anhängen Malware enthalten sein kann, die via Word (!) Makros Ransomsware etc. runterlädt und aufgrund der Nutzung der Snake-Malware vom Virusschutz nicht immer entdeckt werden. Selbstverständlich verwenden wir aktuelle Versionen von Word etc., aber die Meldungen weisen darauf hin, dass bei kleinen Unaufmerksamkeiten das System übernommen werden kann. Leider gibt es keine ausreichenden Infos, wie welche Schutzmaßnahmen seitens der Gematik zur Absicherung bestehen, offenbar war in der letzten Woche bei denen einiges los.

[baerdoc]

Sie benötigen nicht einmal Word, um mit PDF "nette Begleiter" zu verteilen.

Eine Absicherung über die Gematik gibt es nicht. Wenn alles end-zu-end-verschlüsselt wird, muss man sich entweder von einigen Datenschutzvorgaben trennen und eine Überprüfung beim Übertragen von Arztbriefen einbauen (Mein PVS-Anbieter kann ja vertraglich geregelt bei technischen Problemen auch meine Patientendaten einsehen, ohne dass der Datenschutz darunter stark leidet) oder man empfängt keine Arztbriefe über die TI oder man hofft, dass die eigenen Abwehrmaßnahmen es rechtzeitig entdecken.

Aber so, wie es im Moment läuft, ist es nur eine Frage der Zeit, wann die ersten Praxen sich ihre Ransomeware einfangen.

[McLeod]

Schlußendlich hängt die Sicheheit von PDFs zum größten Teil vom verwendeten Viewer ab. Platt ausgedrückt: "Wenn der nix kann, passiert auch nix."
Beispiel Sumatra-PDF: Keine Unterstützung für JavaScript oder Formulare, Nachladen von MS-Office Dokumenten funktioniert meines Wissens auch nicht.

Man hätte das Ganze natürlich auch grundsätzlich sicherer designen können:
- Verpflichtende Verwendung von PDF/A (kein Javascript, keine externen Links usw.) für den e-Arztbrief sowie weitere Anhänge
- Verpflichtende Prüfung beim Eingang auf PVS-Seite, ob Dokument PDF/A entspricht. Falls nicht wird der Kram gelöscht.
- weitere zugelassene Anhänge nur jpg, bmp & tif. (Evtl. noch DICOM-Geschchten)

[bofh]

Man hätte das Ganze natürlich auch grundsätzlich sicherer designen können:
- Verpflichtende Verwendung von PDF/A (kein Javascript, keine externen Links usw.) für den e-Arztbrief sowie weitere Anhänge
- Verpflichtende Prüfung beim Eingang auf PVS-Seite, ob Dokument PDF/A entspricht. Falls nicht wird der Kram gelöscht.
- weitere zugelassene Anhänge nur jpg, bmp & tif. (Evtl. noch DICOM-Geschchten)

Genau so ist es. Es sollten nur leicht validierbare geschlossene Formate zugelassen sein. Mit einem Virenscanner läuft man naturgemäß der Evolution nur hinterher. Das derzeitige Design ist grob fahrlässig - das interessiert aber von den Verantwortlichen niemanden.

Das Thema hatten wir vor kurzen im anderen Portal auch schon: https://www.doczudoc.de/viewtopic.php?t=34

[EWERK official]

Weder bei eArztbrief noch bei der ePA erfolgt eine Prüfung seitens der Telematik / der AIS Anbieter.
Als wirklich sicherer Weg im Umgang mit eArztbriefen ist mir bisher nur folgende Konstallation bekannt:
Abrufen der KIM Nachrichten über Thunderbird (oder nen beliebiegen Mailclient, der KIM Adressen unterstützt) auf nem seperaten linux Server. Dort werden die nachrichten abgerufen, gescannt und erst dann an die einzlenen Ärzte weiterverteilt.
Der Aufwand lohnt sich aber wirklich nur größeren Einrichtungen.

Ansonsten mit einem Nutzer ohne Adminrechte arbeiten, das hält den Schaden dann zumeist in gewissen Grenzen.

Auf eine sichere Lösung durch die Telematik warten wir wohl vergeblich.

[bofh]

Dort werden die nachrichten abgerufen, gescannt und erst dann an die einzlenen Ärzte weiterverteilt.

Scannen per Virenscanner ist nicht wirklich zielführend, da der Virenscanner nur das findet, was er kennt. Aber besser als nichts. (Derzeit muss es der M$-Defender abfangen, wenn auf Windows gespeichert/zugegriffen wird. Vorgaben der KBV sind erfüllt - Virenscanner ist vorhanden und aktuell. )

Anstatt nach Viren zu scannen würde ich eher das Dokument einmal über einen restriktiv konfigurierten PDF-Drucker laufen lassen und dann die eMail neu zusammenbauen. Da werde ich wohl doch noch einen Linux-Mail-Server auf einem Raspberry-Pi aufsetzen... (wenn mir viel zu langweilig wird). Viel Rechenleistung braucht`s ja nicht. Problem ist aber, dass dabei die Signatur des Dokuments verloren geht.

Und wie bekommt man die ePA in den Griff? Ist ja das gleiche Problem, nur ungleich schwieriger, weil man nicht so einfach eingreifen kann.

[W. Steuber]

Weder bei eArztbrief noch bei der ePA erfolgt eine Prüfung seitens der Telematik / der AIS Anbieter.
Als wirklich sicherer Weg im Umgang mit eArztbriefen ist mir bisher nur folgende Konstallation bekannt:
Abrufen der KIM Nachrichten über Thunderbird (oder nen beliebiegen Mailclient, der KIM Adressen unterstützt) auf nem seperaten linux Server. Dort werden die nachrichten abgerufen, gescannt und erst dann an die einzlenen Ärzte weiterverteilt.
Der Aufwand lohnt sich aber wirklich nur größeren Einrichtungen.

Ansonsten mit einem Nutzer ohne Adminrechte arbeiten, das hält den Schaden dann zumeist in gewissen Grenzen.

Auf eine sichere Lösung durch die Telematik warten wir wohl vergeblich.

Bleibt das Problem, womit gescannt wird, und ob das Programm 'auf dem Laufenden' ist.
Auch dies kann nicht realistisch alle prospektiven Bedrohungen ausschließen.
Letztendlich wäre die oberste Sicherheitsstufe, in einem standalone-client die KIM-Nachrichten zu empfangen, auszudrucken und im Praxisnetz wieder einzuscannen, dem airgap geschuldet.

Soviel zum Thema 'Vereinfachung von Abläufen mittels Digitalisierung'.
Wo wir gerade im Thema sind: gibt es eigentlich irgendeinen Bericht über zumindest einen hack eines Faxes????

[bofh]

Die KVS hat dazu folgendes Pamphlet erstellt: https://www.kvs-sachsen.de/mitglieder/k ... astruktur/

Prüfen Sie, welche Schutzmaßnahmen für KIM-Nachrichten in Ihrer Praxis bereits umgesetzt sind. Erfolgt vor der Übernahme der Daten / Dateien in Ihr Primär-/Praxisverwaltungssystem bereits eine Virenprüfung? Wenn Sie diese Frage mit „Ja“ beantworten, ist alles in Ordnung.

Woher soll ich denn wissen, was CGM in TM und im CGM-KIM-Modul implementiert hat? Wenn ich FortiSecond in https://www.doczudoc.de/viewtopic.php?p=185#p185 richtig verstanden habe, dann sollte der Windows-Defender in Standardkonfiguration rechtzeitig zuschlagen!? Also wäre nichts weiter zu tun.

Einige KIM-Anbieter gewähren ein ergänzendes System zum oder innerhalb des KIM-Clientmoduls, welches die KIM-Nachrichten auf Schadsoftware prüft, bevor diese in das Primär-/Praxisverwaltungssystem übernommen werden.

Und was wäre das beim CGM-KIM mit Turbomed? Gibt es dann eine garantierte 100 % Erkennung? Wie schneidet das im Vergleich zum Windows-Defender (im Offlinemodus) ab? Oder soll hier mal wieder Schlangenöl vermarktet werden?

Die Lösung mit dem scannenden Mailserver wird dann auch noch genannt. Aber der kann ja auch nicht alles finden und zieht unter Anderem das Problem eines weiteren zu wartenden Virenscanners nach sich, der Kosten verursacht.
https://github.com/gematik/api-kim/blob ... av-service

[Johnny]

Wenn ich das alles höre wird mir schlecht

Also bleibe ich doch weiter bei meinem komfortablen PC-Fax.
Habe noch nie etwas von einem FAX-Virus gehört.
Faxen gehört übrigens zu den peer-to-peer Netzwerkapplikation im Gegensatz zu den den email-server-email Netzwerkapplikation (Stichwort: "man in the middle attack") oder irre ich mich da?

Grüsse aus Kiel
Johnny

[bofh]

Man in the middle scheidet bei KIM/eArtzbrief aus, da dort Ende-zu-Ende verschlüsselt ist. Einzig innerhalb des Praxis-LAN, wo unverschlüsselt weiterverteilt wird, wäre dies möglich. Da ist FAX aber genauso betroffen.

Zur Virenerkennung bei ePA hat die KVS (noch?) nichts gesagt. Ist wohl derzeit nicht aktuell. Bin mal gespannt, was dort vorgeschlagen werden wird.

[Johnny]

Was ich mich immer frage bei diesen KIm-Verschlüsselung eArzt-Briefen.

- Wer produziert und wer hat die privaten Schlüssel und wo lliegen sie auf meinem PVS
- Wer produziert die öffentlichen Schlüssel und wo liegen sie auf meinem PVS?

Danke

Grüsse aus Kiel
Johnny

[FortiSecond]

KIM von I-Motion (IBM) hat eine Schnittstelle zum Virenscanner, die eine Zwischenstation innerhalb des POP3-Proxys darstellt. Hier ließe sich also transparent ein Scanner einbinden - einen mit REST-API.

Wenn´s nicht so unbequem wäre, könnte man ein halbautomatisches Scannen abbilden per Thunderbird: Automatisch Anhang speichern und dann scannen. Man müsste halt nur den Check abwarten, bevor man die KIM-Nachricht in TM öffnet.

[Anmerkung: Nach aktuellem Stand wäre es ein Leichtes, ein präpariertes PDF oder auch ZIP etc. an einen eArztbrief oder eine KIM-Nachricht anzuhängen. Dann würde ein Öffnen beim Empfänger zum Problem werden.
Vielleicht hat jemand Zeit, das mit EICAR zu testen... Bei mir wäre es EICAR-Testmail an Praxis, dort in Thunderbird ins KIM-Postfach kopieren - dann per KIM weiterleiten an eine anderen Praxis.
Ich kann es NICHT testen, weil ich ganz sicher nicht in der "sendenden" Praxis den Virenscanner deaktiviere (was ja nötig dafür ist) und dann eine Test-Malware an eine andere Praxis schicke... ]

Allerdings scheint bei TM zunächst die gesamte KIM-Nachricht auf die Platte gelegt zu werden (Unterordner von TM). Solange hier eine Ausnahme für x:\turbomed\* besteht, müsste der Scanner zugreifen, bevor die Nachricht in TM geöffnet werden kann. Ob TM dann abstürzt oder eine Fehlermeldung sendet? Keine Ahnung.

----

Was ich mich immer frage bei diesen KIm-Verschlüsselung eArzt-Briefen.

- Wer produziert und wer hat die privaten Schlüssel und wo lliegen sie auf meinem PVS
- Wer produziert die öffentlichen Schlüssel und wo liegen sie auf meinem PVS?

Danke

Grüsse aus Kiel
Johnny

1) privater Schlüssel = Wird erzeugt beim Registrieren der KIM-Adresse. Beteiligt sind dabei SMC-B für die Telematik-ID, der eHBA *oder* erneut die SMC-B für die Registrierung (Identitätsprüfung) und Legitimation ggü. Konnektor für den Kryptodienst, der KIM-Anbieter (erzeugt die Zertifikate, die unter KIM/.../data liegen; macht den Eintrag im Verzeichnisdienst samt öffentlichem Schlüssel - dafür ist der VZD/LDAP neben der Adressauskunft zuständig).
2) Dito und -> Im Verzeichnisdienst/LDAP.