SRC GmbH freut sich über Auftrag für die Telema­tik­in­fra­struktur Deutschlands

NEWS+++NEWS+++NEWS+++NEWS+++NEWS+++NEWS+++NEWS+++NEWS+++NEWS+++NEWS+++NEWS+++NEWS

Wir, die SRC GmbH, Anbieter von IT-Sicher­heits­prü­fungen und IT-Beratungs­dienst­leis­tungen, freuen uns, dass wir erfolg­reich an einer Ausschreibung des Bundes­amtes für Sicherheit in der Infor­ma­ti­ons­technik (BSI) teilge­nommen und den Zuschlag erhalten haben. Wir freuen uns hiermit einen Beitrag zur wachsende Bedeutung der Digita­li­sierung im deutschen Gesund­heits­wesen und der IT-Sicherheit beitragen zu können.

Unsere Expertise wird in den kommenden Aufgaben im Bereich der Telema­tik­in­fra­struktur (TI) einge­setzt, die eine entschei­dende Rolle bei der Vernetzung von Gesund­heits­ein­rich­tungen und dem sicheren Austausch von Gesund­heits­daten spielt.

Wir werden das BSI bei seinen gesetz­lichen Aufgaben unter­stützen, insbe­sondere in den Bereichen Prüfme­cha­nismen, Spezi­fi­ka­tionen und technische Richtlinien.

Das Team der SRC GmbH freut sich auf die zukünftige Zusam­men­arbeit mit dem Bundesamt für Sicherheit in der Infor­ma­ti­ons­technik (BSI) und sieht stolz der Gelegenheit entgegen, einen bedeu­tenden Beitrag zur sicheren Digita­li­sierung des deutschen Gesund­heits­wesens zu leisten.

Kontakt für weitere Infor­ma­tionen: Randolf Skerka

Neuerungen im Fast-Track-Verfahren für digitale Gesund­heits­an­wen­dungen (DiGA)

Am 4. September wurde eine aktua­li­sierte Version des Fast-Track-Verfahrens für digitale Gesund­heits­an­wen­dungen (DiGA) gemäß § 139e SGB V veröf­fent­licht. Diese Aktua­li­sierung bringt einige bedeu­tende Neuerungen mit sich, die sowohl für Hersteller, Leistungs­er­bringer als auch Anwender von DiGAs von Interesse sind.

Wir haben die wichtigsten Änderungen für Sie zusammengefasst:

Daten­ver­ar­beitung außerhalb Deutsch­lands (3.3.3)

Ein wichtiger Punkt betrifft die Daten­ver­ar­beitung außerhalb Deutsch­lands. Die aktua­li­sierte Version des Leitfadens enthält klare Richt­linien und Anfor­de­rungen für den Umgang mit Gesund­heits­daten, die außerhalb Deutsch­lands verar­beitet werden. Dies ist entscheidend, um die Integrität und Sicherheit sensibler Patien­ten­daten zu gewährleisten.

Sicherheit als Prozess (3.4.2)

Ein weiterer bemer­kens­werter Aspekt der Aktua­li­sierung ist die Betonung der Sicherheit als konti­nu­ier­licher Prozess. Die neuen Leitlinien legen großen Wert darauf, dass Sicher­heits­maß­nahmen nicht statisch sein dürfen, sondern sich im Laufe der Zeit weiter­ent­wi­ckeln müssen, um den ständig wachsenden Bedro­hungen in der digitalen Gesund­heits­land­schaft gerecht zu werden.

Inter­ope­rable E‑Health-Infra­struktur (3.5.1.1) 

Eine weitere spannende Neuerung bezieht sich auf „vesta“ und „MIOs“ als Basis einer inter­ope­rablen E‑Health-Infra­struktur. Dies weist auf die verstärkten Bemühungen hin, Gesund­heits­an­wen­dungen und ‑systeme mitein­ander zu verknüpfen, um einen reibungs­losen Daten­aus­tausch und eine bessere Patien­ten­ver­sorgung zu ermög­lichen.  Verschärfte Anfor­de­rungen an Penetrationstests

Schließlich, und vielleicht am bemer­kens­wer­testen, sind die verschärften Anfor­de­rungen an Penetra­ti­ons­tests. Laut der aktua­li­sierten Version des Fast-Track-Verfahrens müssen diese Tests vorrangig von BSI-zerti­fi­zierten Teststellen durch­ge­führt werden. Darüber hinaus sind Code Reviews und Whitebox-Tests verpflichtend. Diese Maßnahmen zielen darauf ab, die Sicherheit von DiGAs weiter zu stärken und poten­zielle Sicher­heits­lücken aufzudecken.

Insgesamt verdeut­licht die Aktua­li­sierung des Fast-Track-Verfahrens das Engagement für die Sicherheit und Qualität von digitalen Gesund­heits­an­wen­dungen. Die neuen Richt­linien und Anfor­de­rungen sollen dazu beitragen, die Gesund­heits­ver­sorgung in der digitalen Ära zu verbessern und gleich­zeitig die Sicherheit der Patien­ten­daten zu gewährleisten.

PCI DSS v4.0 rückt näher – wir unter­stützen Sie bei der Vorbereitung

Der PCI DSS ist ein ausge­reifter Standard, der Anfor­de­rungen an die sichere Verar­beitung von Karten­daten der inter­na­tio­nalen Zahlungs­systeme definiert.

Die Version 3 des PCI DSS, die – mit verschie­denen Updates – seit 2014 gültig ist, läuft Ende März 2024 endgültig aus und wird durch die neue Version 4.0 ersetzt.

Wir gehen mit Ihnen die letzten Schritte zur Migration auf PCI DSS v4.0.

Nutzen Sie gerne unsere Angebote:

 1. Monat­liche Blog-Artikel, in denen jeweils ein Thema des PCI DSS v4.0 genauer beleuchtet wird.

2. Kostenlose Webinare, welche die Änderungen von PCI DSS v3.2.1 auf v4.0 noch einmal für Sie zusammenfassen.

Sobald die genauen Termine feststehen und die Anmeldung freige­schaltet ist, finden Sie die entspre­chenden Links hier:

  • Webinar zum vollen PCI DSS-Anwen­dungs­be­reich
  • Webinar für Card-Present-Händler mit Anwen­dungs­be­reich SAQ B‑IP oder P2PE
  • Webinar für E‑Com­merce-Händler mit Anwen­dungs­be­reich SAQ A

Sie finden unsere aktuellen Webinar-Termine hier in der Übersicht.

3. Auf Sie zugeschnittene PCI DSS v4.0‑Workshops, in dem wir die für Sie relevanten Anfor­de­rungen gezielt vorstellen und diskutieren.

4. Eine Gap-Analyse für Ihre Umgebungen und Prozesse. Sie erhalten eine Liste aller in Ihrem Unter­nehmen noch offenen Punkte für die PCI DSS v4.0‑Konformität.

5. Beratungs­pakete nach Wahl, von denen Sie jederzeit Kontin­gente abrufen können, wenn Sie konkrete Rückfragen haben – per Telefon, E‑Mail, Webkon­ferenz, oder in Meetings vor Ort.

Kontakt: Frau Jana Ehlers per E‑Mail

Infor­ma­ti­onworkshop für Lösungs­an­bieter von E‑Voting-Systemen – Zerti­fi­zierung nach CC Schutz­profil BSI-CC-PP-0121

Zur Bewertung von E‑Voting Lösungen für nicht-politische Online-Wahlen hat das Bundesamt für Sicherheit in der Infor­ma­ti­ons­technik (BSI) im April 2023 eine Reihe von Techni­schen Richt­linien sowie ein Common Criteria Schutz­profil für E‑Voting Systeme [PP-0121] heraus­ge­geben. Darin wird insbe­sondere festgelegt, dass konforme Produkte der Prüftiefe EAL4 + ALC_FLR.2 genügen müssen.

E‑Voting Systeme: Maximale Sicherheit und Wachs­tums­po­tenzial dank BSI-Zertifizierung

Lösungs­an­bieter stehen damit vor der strate­gi­schen Frage, ob sie ihre Lösung nach dem Common Criteria Schutz­profil BSI-CC-PP-0121 zerti­fi­zieren lassen wollen. Dem erhöhten Entwick­lungs- und Zerti­fi­zie­rungs­aufwand steht ein wachsender kommer­zi­eller Markt gegenüber.

Strate­gische Entscheidung: Ihr Erfolg auf dem wachsenden E‑Voting Markt

Um die Frage zu beant­worten, ob ein E‑Voting Hersteller für seine Lösung ein CC-Zerti­fi­zie­rungs­ver­fahren anstreben sollte, bietet SRC in Zusam­men­arbeit mit der Alter Solutions Deutschland GmbH einen Workshop an. Alter Solutions hat maßgeblich an der vom BSI durch­ge­führten und veröf­fent­lichten Studie zur Markt- und Sicher­heits­analyse von Online-Wahlpro­dukten feder­führend mitge­wirkt. SRC als anerkannte Prüfstelle für Common Criteria berichtet über die Erfahrung aus vergleich­baren Markt­ein­füh­rungen und Zulassungsverfahren.

Die erfolg­reiche Route zur CC-Zertifizierung 

Im Rahmen des Workshops werden folgende Schwer­punkte bearbeitet:

  • Vorstellung der Verfah­rens­ab­läufe einer CC-Zertifizierung
  • Produkt­vor­stellung und erster Abgleich mit den Anfor­de­rungen des BSI-CC-PP-0121 
    • Prinzipien Cast-as-intended, Recorded-as-cast, Counted-as-recorded
    • Schutz einge­wor­fener / gezählter Stimmen vor Löschung und Änderungen
    • Archi­vierung von Election Execution Data
    • Aufrecht­erhaltung der unver­fälschten Wahlurne und manuelle Wiederherstellung
    • Schutz des Wahlge­heim­nisses und der Identität des Wählers
  • Einblick in eine Schwach­stel­len­analyse nach der Common Criteria Familie AVA_VAN.3 wie sie im BSI-CC-PP-0121ge­fordert wird
  • Beson­der­heiten bei der Definition von Sicherheit für Online-Wahlverfahren
  • Ablauf einer CC-Evaluation / Zeit- und Ressourcenplanung
  • Risiken bei der Imple­men­tierung, Erstellung der Herstel­ler­do­ku­mente und Evaluierung
  • Diskussion TOE Security Functions und Umsetzung in der Sicherheitsarchitektur
  • Vorstellung Evalua­tortest

Profi­tieren Sie von unserem Angebot!

SRC bietet den geplanten Workshop mit einer Dauer von 1,5 Tagen an. Die Kosten dafür betragen 4.000 Euro (zzgl. Umsatz­steuer und ggfs. Reise­kosten). Der Workshop kann in Präsenz oder hybrid statt­finden. Die Kosten werden zur Hälfte erstattet, wenn innerhalb von drei Monaten nach dem Workshop eine Evaluation mit Hilfe der SRC gestartet wird.

SRC – Ihr anerkannter Experte für Sicherheitsprüfungen 

Mit einer Erfahrung von mehr als 20 Jahren ist die SRC beim BSI als führendes Prüflabor für Sicher­heits­un­ter­su­chungen gemäß den inter­na­tio­nalen Common Criteria (ISO 15408) anerkannt. Doch das ist nicht alles: Wir sind auch anerkannte Gutachter für Zahlungs­ver­kehrs­kom­po­nenten bei inter­na­tio­nalen Zahlungs­sys­temen und Internet-basierten Zahlver­fahren in der Payment Card Industry (PCI). Vertrauen Sie auf unsere umfang­reiche Expertise und lassen Sie sich von uns auf Ihrem Weg zur Zerti­fi­zierung begleiten.

Inter­es­siert oder noch Fragen? 

Sollten Sie Interesse an der Durch­führung eines solchen Workshops oder weitere Fragen haben, dann wenden Sie sich bitte an

 

Herrn Ho-Yeon Kim
Tel.: 0228 2806-139
Mobil:           0179–9478336
E‑Mail:         ho-yeon.kim@src-gmbh.de
Web:             www.src-gmbh.de

Wie sicher ist die elektro­nische Patientenakte?

Nach der Digita­li­sie­rungs­stra­tegie des Bundes­mi­nis­te­riums für Gesundheit erhalten zukünftig alle gesetzlich Versi­cherten, die nicht aktiv wider­sprechen, eine elektro­nische Patien­tenakte. Wer kann dann auf die persön­lichen Patien­ten­daten zugreifen und wie gut sind die Daten gegen unberech­tigten Zugriff geschützt?

Anfang März 2023 hat Bundes­ge­sund­heits­mi­nister Prof. Karl Lauterbach in einer Presse­kon­ferenz die neue Digita­li­sie­rungs­stra­tegie des Bundes­mi­nis­te­riums für Gesundheit (BMG) vorge­stellt. Ein zentrales Thema der Digita­li­sie­rungs­stra­tegie ist die elektro­nische Patien­tenakte (ePA). Diese wird den 73 Millionen gesetzlich Versi­cherten seit Januar 2021 auf Wunsch (Opt-In) durch die Kranken­kassen bereit­ge­stellt. Laut Karl Lauterbach haben bis heute aller­dings weniger als ein Prozent der gesetzlich Versi­cherten eine ePA beantragt. Dies hat sich offenbar schon länger angedeutet, denn bereits im Koali­ti­ons­vertrag von November 2021 wurde vereinbart, die Einführung der ePA zu beschleu­nigen und allen Versi­cherten, die nicht aktiv wider­sprechen, eine ePA zur Verfügung zu stellen (Opt-Out). Im Rahmen der Digita­li­sie­rungs­stra­tegie erfolgt nun die Umsetzung. Das BMG hat bereits zwei neue Gesetze angekündigt: das Digital­gesetz und das Gesund­heits­da­ten­nut­zungs­gesetz (GDNG). Damit sollen bis zum Jahr 2025 80 Prozent der gesetzlich Versi­cherten über eine ePA verfügen und die Patien­ten­daten pseud­ony­mi­siert für die Forschung nutzbar werden.

Für die Versi­cherten bedeutet dies, eine Entscheidung treffen zu müssen. Keine ePA zu beantragen war einfach und bequem, aber sollte der Einrichtung jetzt wider­sprochen werden? Wie sind die persön­lichen Patien­ten­daten in einer ePA geschützt? Wer kann auf die Patien­ten­daten zugreifen? Dieser Artikel vermittelt Hinter­grund­in­for­ma­tionen zur Funkti­ons­weise der ePA und über den Schutz der in der ePA gespei­cherten Patientendaten.

Die elektro­nische Patientenakte

Die elektro­nische Patien­tenakte ist im Wesent­lichen ein sicherer cloud­ba­sierter Dokumen­ten­speicher mit einem komplexen Berech­ti­gungs­system. Versi­cherte können ihre Patien­ten­daten jederzeit einsehen und die Berech­tigung für den Zugriff durch Ärzte oder andere Personen selber steuern. Dies wird durch das Zusam­men­spiel verschie­dener Kompo­nenten erreicht:

  • Das ePA-Akten­system (ePA-AS) ist die zentrale Backend-Kompo­nente, in der die Patien­ten­daten gespei­chert werden. Hier erfolgen außerdem die Nutzer­au­then­ti­fi­zierung und die Durch­setzung der Zugriffsrechte.
  • Das ePA-Frontend des Versi­cherten (ePA-FdV) ist der dezen­trale Zugangs­punkt für die Versi­cherten. Das ePA-FdV gibt es als mobile App wie auch als Desktop­an­wendung. Über das ePA-FdV können Versi­cherte die eigene Akte verwalten sowie Inhalte hochladen, einsehen, herun­ter­laden oder löschen.
  • Über das Fachmodul ePA auf den Konnek­toren greifen Ärzte und andere Leistungs­er­bringer auf die ePA der Patienten zu.
  • Zwei unabhängige Schlüs­sel­ge­nerie­rungs­dienste (SGD) stellen nutzer­indi­vi­duelle Schlüssel für die Verschlüs­selung der Akten­in­halte bereit.

Verschlüs­selung der Akteninhalte

Die in der ePA gespei­cherten Patien­ten­daten sind perso­nen­be­zogene Gesund­heits­daten gemäß Artikel 9 Daten­schutz­grund­ver­ordnung (DSGVO) und somit besonders schüt­zenswert. Der Schutz wird durch zahlreiche Maßnahmen umgesetzt. Besondere Relevanz hat die Verschlüs­selung der Akten­in­halte. Beim poten­zi­ellen Zugriff auf Akten­in­halte durch eine unberech­tigte Person erhält diese nur verschlüs­selte Daten. Das Gesamt-Verschlüs­se­lungs­ver­fahren setzt sich aus mehreren Verschlüs­se­lungen mit unter­schied­lichen Schlüsseln zusammen:

  • Der Dokumen­ten­schlüssel wird zur Verschlüs­selung eines bestimmten Akten­in­halts verwendet. Im Weiteren wird verein­facht angenommen, dass es sich bei Akten­in­halten um Dokumente (zum Beispiel PDF-Dokumente) handelt. Jedes in der ePA gespei­cherte Dokument wird mit einem indivi­du­ellen Schlüssel verschlüsselt.
  • Der Kontext­schlüssel wird zur Verschlüs­selung der Meta- und Proto­koll­daten verwendet. Die Metadaten enthalten Klartext­in­for­ma­tionen und erlauben, trotz der verschlüs­selten Ablage der medizi­ni­schen Dokumente, einen Überblick der Akten­in­halte und eine server­seitige Suche in der Akte.
  • Der Akten­schlüssel wird für die Verschlüs­selung der Akten­in­halte verwendet. Dazu gehören die bereits genannten Dokumen­ten­schlüssel wie die Dokumente selbst.
  • Die Berech­tig­ten­schlüssel 1 und 2 werden für die Verschlüs­selung des Kontext- und des Akten­schlüssels verwendet. Sie sind nutzerindividuell.

Der Zugriff auf und die Entschlüs­selung von Patien­ten­daten aus der ePA läuft wie folgt ab: eine berech­tigte Person, zum Beispiel der oder die Versi­cherte, authen­ti­siert sich über das ePA-FdV gegenüber dem ePA-Akten­system und den Schlüs­sel­ge­nerie­rungs­diensten. Von den Schlüs­sel­ge­nerie­rungs­diensten erhält das ePA-FdV die indivi­du­ellen Berech­tig­ten­schlüssel 1 und 2, vom ePA Akten­system erhält das ePA-FdV den Akten- und Kontext­schlüssel in verschlüs­selter Form. Mithilfe der Berech­tig­ten­schlüssel werden Akten- und Kontext­schlüssel im Zwiebel­scha­len­prinzip entschlüsselt. Der Kontext­schlüssel wird im Klartext über ein speziell gesichertes Protokoll an das ePA-Akten­system übertragen. Im ePA-Akten­system gibt es eine sogenannte Vertrau­ens­würdige Ausfüh­rungs­um­gebung, die technisch Zugriffe des Betreibers verhindert und damit sicher­stellt, dass der Betreiber keine Akten­in­halte einsehen kann. In dieser Vertrau­ens­wür­digen Ausfüh­rungs­um­gebung wird der sogenannte Akten­kontext mit dem Kontext­schlüssel entschlüsselt. Es handelt sich um Metadaten, die zum Beispiel eine Inhalts­angabe der in der ePA gespei­cherten Dokumente enthält. Über den Akten­kontext kann am ePA-FdV das gewünschte Dokument ausge­wählt und auf das Endgerät geladen werden. Dort wird das Dokument zunächst mit dem Akten­schlüssel entschlüsselt. Das Ergebnis ist ein Dokumen­ten­schlüssel und das damit verschlüs­selte Dokument. Mit dem Dokumen­ten­schlüssel wird das Dokument entschlüsselt und liegt letztlich im Klartext vor. Wird das Dokument außerhalb des ePA-FdV gespei­chert, kann die Sicherheit nicht mehr durch die ePA gewähr­leistet werden.

Berech­ti­gungs­ma­nagement

Gibt eine versi­cherte Person einer anderen Person (zum Beispiel einem Arzt) die Berech­tigung, auf Akten­in­halte zuzugreifen, werden der Akten- und Kontext­schlüssel mit Berech­tig­ten­schlüsseln dieser anderen Person verschlüsselt und im Akten­system für den Abruf durch diese gespei­chert. Nicht berech­tigte Personen, wie der Betreiber des ePA-Akten­systems, sind somit krypto­gra­fisch vom Akten­zu­griff ausge­schlossen. Ist eine Person generell berechtigt und es liegen die notwen­digen Schlüssel vor, kann der Zugriff weiterhin auf Dokumenten-Ebene einge­schränkt werden. So können Versi­cherte für jedes Dokument einzeln festlegen, wer darauf zugreifen darf.

Fazit

Die ePA setzt verschiedene Sicher­heits­me­cha­nismen für den Schutz der Patien­ten­daten um. Für den Zugriff müssen sich Versi­cherte grund­sätzlich authen­ti­sieren. Für die Entschlüs­selung der Inhalte müssen weiterhin verschiedene Schlüssel zusam­men­ge­bracht werden. Die Sicherheit der Verschlüs­selung liegt maßgeblich in den Berech­tig­ten­schlüsseln. Aus diesem Grund gibt es hiervon zwei, die von unabhän­gigen Schlüs­sel­ge­nerie­rungs­diensten bereit­ge­stellt werden. So ist sicher­ge­stellt, dass immer verschiedene Instanzen bei der Entschlüs­selung invol­viert sind. Weder der Betreiber des Akten­systems, noch die Betreiber der Schlüs­sel­ge­nerie­rungs­dienste sind technisch dazu in der Lage, Akten­in­halte zu entschlüsseln. Die Berech­tigung zum Zugriff auf Akten­in­halte wird durch die Versi­cherten selbst gesteuert. Nur berech­tigte Personen können die notwen­digen krypto­gra­fi­schen Schlüssel entschlüsseln, alle anderen sind krypto­gra­fisch ausge­schlossen. Die Berech­tigung zum Zugriff kann feingra­nular für jedes Dokument einzeln vergeben werden.

Vor einem unberech­tigten Zugriff sind die Patien­ten­daten in der ePA gut geschützt. Für die Berech­ti­gungs­steuerung und die Sicherheit herun­ter­ge­la­dener Patien­ten­daten sind die Versi­cherten selbst verant­wortlich. Daten­sou­ve­rä­nität erfordert Eigenverantwortung.

Autor:  Nico Martens, Berater SRC Security Research & Consulting GmbH

Basis­wissen IT-Grund­lagen und ‑Sicher­heits­maß­nahmen für Nicht-Informatiker

Mit fortschrei­tender Digita­li­sierung rückt auch die Banken-IT immer stärker in den Fokus. Um Sicherheit und Schutz insbe­sondere sensibler Infor­ma­tionen und Daten zu gewähr­leisten, müssen u. a. Infor­ma­ti­ons­si­cher­heits­be­auf­tragte, Daten­schutz­be­auf­tragte und IT-Verant­wort­liche eng zusam­men­ar­beiten. Dabei gilt es trotz unter­schied­licher fachlicher Hinter­gründe eine gemeinsame „Sprache“ zu sprechen. Denn: Je besser man IT-Begriffe, Zusam­men­hänge und Prozesse versteht, desto besser gelingt auch die Kommu­ni­kation mit den IT-Fachleuten und desto eher können vorge­schlagene IT-Sicher­heits­maß­nahmen und ihre Wirkung einge­schätzt werden.

Das folgende Inten­siv­se­minar vermittelt IT-Basis­wissen und grund­le­gende IT-Sicher­heits­maß­nahmen und richtet sich speziell an Nicht-Infor­ma­ti­ke­rInnen in Kreditinstituten:

„Basis­wissen IT-Grund­lagen und ‑Sicher­heits­maß­nahmen für Nicht-Informatiker“
am Montag, 20. November 2023, 09:30 bis 17:00 Uhr in Köln

Die erfah­renen Referenten erläutern IT-Begriffe und ‑Grund­lagen, z. B. zum Thema Netzwerke, Kommu­ni­ka­ti­ons­medien und ‑proto­kolle. Vorge­stellt werden außerdem die grund­le­genden IT-Sicher­heits­maß­nahmen in Netzen / im Rechen­zentrum, vom Thema Backup, über Virtua­li­sierung bis hin zur Benutzerverwaltung.

Ein weiteres Modul widmet sich speziell den Themen Verschlüs­selung (symme­trische und asymme­trische Verfahren, Key Management), Signatur, Authen­ti­kation (z. B. Multi-Faktor-Authen­ti­sierung gemäß PSD2) und Integri­täts­si­cherung. Sie erhalten außerdem einen Überblick über neue Techno­logien und Trends (Big Data, Cloud, Künst­liche Intel­ligenz, Beson­der­heiten im mobilen Arbeiten / Homeoffice) und disku­tieren die Anfor­de­rungen an die Sicherheit.

Es referieren:

Florian Schumann | SRC Security, Research & Consulting GmbH
Der Referent Florian Schumann ist IT-Leiter bei der SRC Security Research & Consulting GmbH. In dieser Position verant­wortet er die konti­nu­ier­liche Weiter­ent­wicklung der IT. Außerdem ist er Berater für Infor­ma­ti­ons­si­cherheit und quali­fi­zierter Prüfer gem. § 8 (a) BSIG für kritische Infrastrukturen.

Vincent Becker | SRC Security, Research & Consulting GmbH

Ihre Fragen beant­wortet gern Frau Andrea van Kessel  (Tel. 0221/5490–161) vom bank-verlag.

 

Wir freuen uns auf Ihre Teilnahme!

 

Basis­wissen IT-Grund­lagen und ‑Sicher­heits­maß­nahmen für Nicht-Informatiker
am Montag, 20. November 2023, 09:30 bis 17:00 Uhr

Infor­mation Security Management Systeme (ISMS) – Mythen, Missver­ständ­nisse und Irrtümer

Es gibt einige Mythen, Missver­ständ­nisse und Irrtümer rund um Infor­mation Security Management Systeme (ISMS), die zu falschen Annahmen oder unzurei­chenden Imple­men­tie­rungen führen können.

In unserem aktuellen Blogar­tikel möchten wir einige davon kurz vorstellen:

 

Mythos Nr. 1: ISMS ist nur für große Unternehmen

Es ist ein verbrei­teter Irrtum, dass ein ISMS nur etwas für große Unter­nehmen ist. Tatsächlich können Organi­sa­tionen jeder Größe von einem ISMS profi­tieren, da es dabei hilft, sich Bedro­hungen bewusst zu werden, Risiken zu minimieren und Konfor­mi­täts­an­for­de­rungen zu erfüllen. Unabhängig von der Größe der Organi­sation unter­stützt ein effek­tives ISMS dabei, Infor­ma­ti­ons­si­cherheit in allen Aspekten des Geschäfts­be­triebs zu berück­sich­tigen, was letztlich zur Stärkung des allge­meinen Geschäfts­er­folgs und zur Förderung des Vertrauens beiträgt.

Mythos Nr. 2: ISMS ist nur eine technische Angelegenheit

Es besteht oft das Missver­ständnis, dass ein ISMS ausschließlich technische Maßnahmen umfasst. Primär stehen aber Infor­ma­tionen und Prozesse im Fokus. Über diese kommen dann sowohl die techni­schen als auch weitere organi­sa­to­rische Aspekte, wie z.B. Richt­linien, Verfahren, Schulungen und Awareness-Programme, in die Betrachtung. Mit anderen Worten, ein effek­tives ISMS erfordert einen ganzheit­lichen Ansatz, der Menschen, Prozesse und Techno­logie einbe­zieht, um die Sicherheit der Infor­ma­tionen in der Organi­sation zu gewähr­leisten und zu verbessern.

Mythos Nr. 3: Ein ISMS ist eine einmalige Aufgabe

Ein ISMS ist nicht bloß eine einmalige Aufgabe. Es wird zwar manchmal angenommen, dass ein ISMS einmal imple­men­tiert und dann nebenbei betrieben werden kann, doch in Wirklichkeit ist es ein konti­nu­ier­licher Prozess, der ständige Überwa­chung, Überprüfung und Verbes­serung erfordert, um mit sich ändernden Bedro­hungen und Geschäfts­an­for­de­rungen Schritt zu halten. Dieser Prozess fördert eine dauer­hafte Kultur der Infor­ma­ti­ons­si­cherheit in der Organi­sation, die auf proaktive Risiko­min­derung und ständige Anpassung an neue Sicher­heits­her­aus­for­de­rungen ausge­richtet ist.

Mythos Nr. 4: Konfor­mität garan­tiert Sicherheit

Konfor­mität mit Normen wie ISO 27001 bedeutet nicht automa­tisch, dass eine Organi­sation vollständig geschützt ist. Ein ISMS sollte als konti­nu­ier­licher Verbes­se­rungs­prozess betrachtet werden, der über die bloße Einhaltung von Vorschriften hinausgeht. Es geht darum, ein Bewusstsein für Infor­ma­ti­ons­si­cherheit in der gesamten Organi­sation zu schaffen, die Fähigkeit zur Reaktion auf sich ändernde Bedro­hungen zu verbessern und letztlich eine nachhaltige Sicher­heits­kultur zu etablieren.

Mythos Nr. 5: ISMS dient nur Marketingzwecken

Auch wenn die Vertriebs- und Marke­ting­ab­teilung dem sicher nicht wider­sprechen wird, so hilft ein wirksames ISMS vorrangig dabei, dass Organi­sa­tionen, Risiken mindern, Konfor­mi­täts­an­for­de­rungen erfüllen und Vertrauen bei Kunden und Partnern aufgebaut wird. Insgesamt fördert ein solches System eine sicher­heits­be­wusste Kultur und verbessert die Geschäftspraktiken.

Hätten Sie’s gewusst?

Indem diese Mythen, Missver­ständ­nisse und Irrtümer aufge­klärt werden, können Organi­sa­tionen ein besseres Verständnis dafür entwi­ckeln, wie ein ISMS effektiv imple­men­tiert und genutzt werden kann, um ihre Infor­ma­tionen zu schützen und den Geschäfts­erfolg zu fördern.

Wir von der SRC Security Research & Consulting GmbH können Sie aktiv in dem Prozess von der Beratung bin hin zur Zerti­fi­zierung unter­stützen, sprechen Sie uns dazu gerne an.

Kontakt: 
Christoph Sesterhenn
E‑Mail

 

common criteria 2023

CC:2022 – Ein Überblick

Neue Version der Common Criteria erschienen

Im November 2022 ist eine neue Version der Common Criteria erschienen, die inoffi­ziell als „CC 4.0“ bezeichnet wird, jedoch offiziell CC:2022 heißt. Wir wollen Ihnen mit diesem Überblick dazu einige erste Infor­ma­tionen geben, damit Sie die Möglichkeit haben, sich auf den Übergang zu dieser neuen Version vorzubereiten. 

Zunächst einige Hinweise zu den Rahmen­be­din­gungen der neuen CC-Version: Die CC:2022 ist wie die Vorgänger einer­seits als ISO-Standard erschienen, als ISO/IEC 15408:2022, anderer­seits auch kostenfrei hier auf der Seite des CCRA zu erhalten. Die entspre­chende Mitteilung des BSI dazu findet sich unter dem Link hier.

Auf der Seite des CCRA findet sich auch die Übergangs­re­gelung, die kurz gesagt folgendes enthält:

• Bis 30.06.2024 können noch Evalu­ie­rungen nach der bishe­rigen CC Version 3.1 begonnen werden.
• Re-Evalu­ie­rungen, Re-Assess­ments und Maintenance von nach CC 3.1 zerti­fi­zierten Produkten sind innerhalb von zwei Jahren nach Zerti­fi­kats­er­teilung noch möglich.
• In Evalu­ie­rungen nach CC:2022 dürfen PPs, die nach CC 3.1 geschrieben wurden, noch bis 31.12.2027 verwendet werden.

Hinweis: Vom BSI kam schon die Signa­li­sierung, dass sich diese Übergangs­re­gelung nochmal ändern wird. Darüber hinaus wird es dann auch in Kürze eine detail­liertere Transition Policy geben.

Zu den inhalt­lichen Änderungen in der CC:2022

Die Änderungen der CC bestehen im wesent­lichen darin, dass es künftig mehr Varian­ten­reichtum in der ST-Erstellung und der Durch­führung der Evalu­ierung auf verschie­denen Ebenen geben wird, sie ist aber inhaltlich „abwärts­kom­pa­tibel“ zur CC 3.1, d.h., wer Evalu­ie­rungen im selben Stil wie bisher durch­führen will, soll dies im wesent­lichen tun können. Im letzteren Fall muss an einigen Stellen des ST der Text etwas angepasst werden, so muss wegen der größeren Zahl an Optionen die Beschreibung des „Confor­mance Claim“ etwas umfang­reicher sein.

Wir fassen hier die wichtigsten Änderungen zusammen (ohne Anspruch auf Vollstän­digkeit und Präzision)

• Die CC besteht künftig aus 5 statt wie bisher 3 Teilen. Die Erwei­terung wurde vorge­nommen, weil es sowohl bei der Auswahl der Evalu­ie­rungs­me­thoden (Teil 4) als auch bei sogenannten „Packages“ (Teil 5) nun mehr Varianten gibt als bisher.

• Die CEM besteht wie bisher aus einem Dokument.

• Einige SFRs, die bisher häufig als „extended“ (also selbst­de­fi­nierte) Kompo­nenten genutzt wurden, wurden offiziell in die CC aufge­nommen. Dies betrifft insbe­sondere solche zu Zufallszahlen.

• Eine neue Wahlmög­lichkeit ist wie folgt: Bisher beruht das Evalua­tor­urteil am Ende auf einer Schwach­stel­len­analyse anhand eines definierten Angriffs­po­ten­tials, wozu der Evaluator mögli­cher­weise Penetra­ti­ons­tests neu definiert. Dieser bisherige Weg wird zur Abgrenzung auch „Attack-based approach“ genannt. In Zukunft soll es neben dieser Vorge­hens­weise auch eine Variante einer Evalu­ierung geben, für die eine Menge von Tests fest vorab definiert wird, gegen die jeder TOE geprüft wird. Dies heißt dann „Speci­fi­cation based approach“.

• Die Kompo­si­ti­ons­eva­lu­ierung, wie sie in der Chipkar­tenwelt seit langem üblich ist, wurde nun auch offiziell in die CC aufge­nommen (bisher war sie durch SOGIS/JIL, also die europäi­schen CC-Schemata definiert).

• Der „Multi-assurance-approach“ erlaubt es künftig, für verschiedene Teile eines Produktes verschiedene Assurance-Kompo­nenten (also z.B. verschiedene Angriffs­stärken) zu definieren. (Auch dies wurde in einzelnen PPs schon in der Vergan­genheit modelliert.)

• Das „Package“-Konzept wurde erweitert. • Statt der bishe­rigen „low assurance“ STs (die kaum genutzt wurden) soll es künftig sogenannte „direct rationale“ STs geben, bei denen SFRs nicht auf Sicher­heits­ziele sondern unmit­telbar auf die „Security Problem Definition“ (also Threats etc.) zurück­ge­führt werden.

• Die mögliche „Confor­mance“ zu einem PP kann neben den bishe­rigen Varianten „demons­trable“ und „strict“ nun auch „exact“ sein. Letzteres bedeutet, dass ein Produkt genau die Sicher­heits­an­for­de­rungen eines PP erfüllt, nicht aber eventuelle zusätz­liche (was bei strict und demons­trable erlaubt ist). Dies wurde als Erwei­terung der CC auch bisher schon verwendet, etwa in vielen PPs aus den USA.

• Der oben genannte „speci­fi­cation based approach“ ist primär vorge­sehen für das Verwenden eines PPs zusmman mit den Confor­mance claim „exact“. D.h. ein PP legt sowohl genau fest, was die Funktio­na­lität eines Produktes ist, als auch alle Tests, die vom Evaluator dazu durch­ge­führt werden. (Anmerkung: Dies ist eine in den USA heute schon oft verwendete Vorgehensweise.)

• Noch einmal der Hinweis auf die „Abwärts­kom­pa­ti­bi­lität“: Wenn man keine der neuen Features benötigt, kann man wie bisher nach einer der bekannten EAL-Stufen evalu­ieren lassen und muss dann an den Herstel­ler­do­ku­menten (außer dem Confor­mance Claim im ST) nichts wesent­liches ändern.

Neben diesen genannten Änderungen gibt es noch einige weitere, die die Beschreibung von Evalua­tor­tä­tig­keiten betreffen, aber nichts Grund­le­gendes für den Hersteller ändern.

Bitte wenden Sie sich bei Rückfragen und Diskus­si­ons­bedarf gern an Ihre Ansprech­partner bei SRC.

___________________________________________________

Sicherheit von Medizin­pro­dukten gemäß BfArM: IT-Sicherheit ist die zweite Säule neben der Produktsicherheit

Mit der neuen EU-MDR rücken die aus der immer stärker vernetzter Techno­logie resul­tie­renden Risiken stärker in den regula­to­ri­schen Fokus: Die IT-Sicherheit in zulas­sungs­pflich­tigen Produkten oder Anwen­dungen nimmt an Bedeutung zu – bei Entwicklung, Herstellung und im Betrieb dieser Produkte sind die sich ergebenden Risiken zu berück­sich­tigen. Auf die Hersteller von Medizin­pro­dukten kommen neue Heraus­for­de­rungen zu. Sie müssen sich darauf einstellen, dass die IT-Sicherheit der herge­stellten Produkte auch im Zulas­sungs­prozess stärker berück­sichtigt wird. Randolf Skerka hat dieses Thema in einem bei medizin & technik veröf­fent­lichten Artikel dargestellt.

Beim Zulas­sungs­prozess für Medizin­pro­dukte stand bisher die Produkt­si­cherheit im Mittel­punkt. Das ändert sich nun. Die europäische Verordnung über Medizin­pro­dukte, (EU) 2017/745 (MDR), ersetzt die Richt­linien über Medizin­pro­dukte (93/42/EWG, MDD) und aktive implan­tierbare Medizin­pro­dukte (90/385/EWG, AIMDD). Ihre Novel­lierung wurde durch die zuneh­mende Digita­li­sierung notwendig – Medizin­technik und ‑produkte funktio­nieren nicht mehr autonom, sondern innerhalb vernetzter Systeme, was sie prinzi­piell angreifbar macht. Damit sind das Risiko von Perso­nen­schäden und die IT-Sicherheit in den Fokus gerückt. Denn Medizin­pro­dukte nehmen direkten Einfluss auf den Körper des Patienten – seien es etwa Infusi­ons­pumpen oder bildge­bende Verfahren wie Röntgen oder Compu­ter­to­mo­gra­phien. Hersteller sind nun in der Pflicht, poten­zielle Risiken auszu­schalten bezie­hungs­weise zu minimieren. Hinzu kommt, dass sich das Sicher­heits­niveau eines auf den Markt gebrachten, vernetzten Medizin­pro­dukts im Laufe der Zeit verändert – etwa, wenn neue Sicher­heits­lücken entstehen. Auch dies bringt neue Anfor­de­rungen an den Zulas­sungs­prozess mit sich.

Neue Anfor­de­rungen an Diga als Medizinprodukt

Für die Hersteller ist der notwendige Perspek­tiv­wechsel hin zu Cyber­si­cherheit eine Heraus­for­de­rungen: Denn bisher lag ihr Fokus darauf gewünschte Funktionen sicher­zu­stellen. Dabei ging man oft vom Best Case aus. Die IT-Sicherheit nimmt aber die gegen­teilige Perspektive ein: Die Verhin­derung unerwünschter Funktionen und damit die Frage­stellung, wie Techno­logie manipu­liert werden kann. Hinzu kommt, dass zu Medizin­pro­dukten nun auch digitale Gesund­heits­an­wen­dungen (Diga), beispiels­weise Apps auf Rezept, gehören. Auch diese wirken sich indirekt auf die Gesundheit der Nutzer aus – sei es bei Erinne­rungs­funk­tionen zur Einnahme von Medika­menten oder beim Vorhalten von Blutdruck­an­gaben. Der Nutzer verlässt sich auf die Korrektheit der Infor­ma­tionen – und der Hersteller muss diese gewähr­leisten können.

Software ist damit nicht mehr nur Bestandteil eines Medizin­pro­dukts, sondern wird selbst zu einem. Die MDR deckt diese neue Realität nun ab; ihre Anfor­de­rungen sind, wie üblich, aber nicht konkret. Unter anderem ist es die Aufgabe der für die Prüfung der Produkte zustän­digen Benannten Stellen – in der Regel privat­wirt­schaft­liche Unter­nehmen wie TÜV oder Dekra – diese zu konkretisieren.

Bei Problemen ist das BfArm zuständig

Anders als bei der Zulassung von Arznei­mitteln ist das Bundes­in­stitut für Arznei­mittel und Medizin­pro­dukte (BfArM) nicht in das Inver­kehr­bringen von Medizin­pro­dukten invol­viert. Die Voraus­setzung dafür stellt das CE-Kennzeichen dar, dessen Erteilung an gewisse Kriterien gebunden ist. Hier übernehmen wieder die benannten Stellen. Anders liegen die Zustän­dig­keiten für Produkte, die bereits am Markt sind: Für die zentrale Erfassung, Auswertung und Bewertung der bei Anwendung oder Verwendung auftre­tenden Risiken und für die Koordi­nierung der zu ergrei­fenden Maßnahmen bei Problemen von Medizin­pro­dukten ist das BfArM zuständig. In der Euromed-Datenbank werden diese zentral gesammelt und an die Betreiber weiter­geben. Ergeben sich Erkennt­nisse über Auswir­kungen auf die Patien­ten­si­cherheit bei Medizin­pro­dukten, müssen diese eskaliert und behoben werden. In der Regel werden die Produkt­ver­ant­wort­lichen bzw. Betreiber von den Herstellern informiert.

Ein IT-Sicher­heits­konzept wird notwendig

Für die Zulassung müssen Hersteller nachweisen, dass sie in der Lage sind, sichere Produkte zu entwi­ckeln – das beginnt mit Security by Design, das späteren Schwach­stellen im Betrieb vorbeugt und Secure Coding. Außerdem muss das Produkt in der späteren Anwendung für den Zulas­sungs­zeitraum sicher sein – das umfasst vor allem das Schwach­stel­len­ma­nagement. Neue Hersteller, die medizi­nische Produkte auf den Markt bringen wollen, müssen an die Hand genommen werden, um den Zulas­sungs­prozess und seine Rahmen­be­din­gungen zu verstehen; etablierte benötigen fachliche bezie­hungs­weise inhaltlich Unter­stützung für den Bereich der IT-Sicherheit und den Aufbau neuer Prozesse.

Ein Partner wie die SRC GmbH kann im Sicher­heits­prozess, bei der Erstellung und dem Ausbau des IT-Sicher­heits­kon­zepts unter­stützen: Dieses muss gemäß dem Questi­on­naire IT Security for Medical Devices der IG-NB erstellt werden. Zunächst erfolgt dabei die Schutz­be­darfs­fest­stellung. Dem schließen sich eine Bedro­hungs­analyse und eine Risiko­analyse mit geeig­neten Maßnahmen zur Vermeidung von Gefähr­dungen für Patienten, Anwender und Dritte an. Schwach­stellen und ihr Schad­po­tenzial werden bewertet. Außerdem muss das Sicher­heits­konzept dauerhaft in einer konti­nu­ier­lichen Ausein­an­der­setzung oder ereig­nis­ba­siert aktua­li­siert werden, um den gesamten Lebens­zyklus eines Produkts abzudecken. In den isolierten Systemen früherer Zeit war die IT nach der Markt­ein­führung dagegen keinen Änderungen mehr unterworfen.

Der formale Zulas­sungs­prozess ist das Kernge­schäft des Bonner Unter­nehmens. Man kennt hier zum einen die Probleme der Hersteller, versteht aber auch die Denkweise der prüfenden, bezie­hungs­weise der benannten Stelle, und kann als Vermittler auftreten. Die Priorität der Hersteller liegt meist auf einer Verkürzung der Zulas­sungszeit auf ein Minimum und damit auf einer schnellen Time to Market. Das gelingt mit einem Partner schneller. SRC weiß, was die einzu­rei­chenden Dokumente beinhalten müssen, kann ihre Eignung prüfen, darüber die notwendige Qualität und den Reifegrad sicher­stellen und Rückfragen vermeiden.

IT-Sicherheit fürs Medizinprodukt

Das Gesund­heits­wesen ist ein komplexes System zur Kranken­ver­sorgung und Gesund­erhaltung. Es ist geprägt von einem überdurch­schnittlich hohen Bedarf an Infor­mation, Dokumen­tation und Kommu­ni­kation. Gleich­zeitig besteht ein außer­or­dentlich ausge­prägter Anspruch an die Integrität und Vertrau­lichkeit der Daten, so wie die Verfüg­barkeit medizi­ni­scher Versorgungsprozesse.

Mit der Neufassung der MDR rückt bei der Zulassung von Medizin­pro­dukten die IT-Sicherheit in den Fokus. Hersteller müssen diese während der Entwicklung und später dauerhaft beim Einsatz im Feld sicher­stellen können und damit die Patien­ten­si­cherheit gewähr­leisten. Notwendig wird dafür ein IT-Sicher­heits­konzept mit Bestand­teilen wie Risiko- und Schwach­stel­len­ma­nagement – eine Dauer­aufgabe, da neue Risiken konti­nu­ierlich bewertet werden müssen. Für Hersteller ist das mit dem Aufbau neuer Kompe­tenzen verbunden – hier kann ein externer Partner unterstützen.

Die SRC Security Research & Consulting GmbH aus Bonn bündelt aktuelles Know-how der Infor­ma­ti­ons­tech­no­logie und ihrer Sicherheit. Entstanden aus der Kredit­wirt­schaft stellt die IT-Sicher­heits­experte SRC ein zentrales Binde­glied zwischen Forschung und Produkten bezie­hungs­weise Dienst­leis­tungen dar.

Dieser Artikel ist bei Medizin und Technik am 21. Februar erschienen.

Digitale Identi­täten im Gesund­heits­wesen – Ein Überblick

Digitale Identi­täten im Gesund­heits­wesen – Ein Überblick

Digitale Identi­täten können verschie­denste Ausprä­gungen haben. Alle haben ihre Berech­tigung und alle haben ihre Vor- und Nachteile. Die einen sind besonders komfor­tabel in der Nutzung, andere sind besonders sicher, wieder andere besonders innovativ. Welche Ausprägung ist für das deutsche Gesund­heits­wesen die beste Wahl? Gibt es überhaupt die eine Lösung? Aktuell existieren verschiedene Ausprä­gungen und zukünftig kommt noch eine weitere hinzu.

Digitale Identi­täten sind Voraus­setzung für die Nutzung digitaler perso­na­li­sierter Dienste. So auch im Gesund­heits­wesen. Wer zum Beispiel eine elektro­nische Patien­tenakte (ePA) nutzt, möchte in dieser vermutlich seine eigenen Gesund­heits­daten wieder­finden und nicht die Daten einer anderen Person. Noch weniger ist es gewünscht, dass die eigene Patien­tenakte unberechtigt von anderen Personen einge­sehen werden kann. Damit das ePA-Akten­system den Zugriff auf die Akten korrekt steuern kann, müssen diese einer Identität zugeordnet sein, einer digitalen Identität des Versicherten.

Für die Gestaltung der digitalen Identi­täten im Gesund­heits­wesen ist die gematik GmbH zuständig. Diese wurde bereits im Jahr 2005 auf gesetz­licher Basis (vgl. SGB V) gegründet und erhielt in diesem Zuge die Aufgabe der Etablierung der Telema­tik­in­fra­struktur (TI) für die sichere digitale Vernetzung der Akteure des Gesundheitswesens.

Zurzeit existieren verschiedene Ausprä­gungen digitaler Identi­täten in der TI. Am weitesten verbreitet ist die digitale Identität in Form eines krypto­gra­fi­schen Schlüssels in Verbindung mit einem Zerti­fikat aus der Public Key Infra­struktur (PKI) der TI, welcher auf einer perso­nen­be­zo­genen Smartcard gespei­chert ist. Im Fachportal der gematik findet man unter dem Titel „Smart­cards in der TI“ eine gute Übersicht, über die in der TI verwen­deten Smartcards.

Smart­cards in der TI

Die wohl bekann­teste Smartcard in diesem Kontext ist die elektro­nische Gesund­heits­karte (eGK), die in Deutschland alle gesetzlich Versi­cherten von ihrer Kranken­kasse bekommen. Die eGK dient dem Versi­cherten zum einen als Kranken­ver­si­che­rungs­nachweis, zum anderen kann sie vom Versi­cherten zur Authen­ti­sierung gegenüber der Fachdienste der TI wie der ePA oder dem elektro­ni­schen Rezept (E‑Rezept) verwendet werden.

Neben der eGK existieren in der TI noch weitere Smart­cards wie der Heilbe­rufs­ausweis (HBA), der die digitale Identität eines Leistungs­er­bringers (z. B. Arzt) speichert, die SMC‑B, die als Insti­tu­ti­ons­karte die digitale Identität einer Leistungs­er­brin­ger­insti­tution (z.B. Arztpraxis) speichert sowie geräte­spe­zi­fische Smart­cards für den Konnektor (gSMC‑K) oder eHealth-Terminals (gSMC-KT).

Mit der ePA kam der erste Fachdienst in die TI, auf den der Versi­cherte von seinem eigenen Endgerät aus über das Internet zugreifen konnte. Die in der Akte gespei­cherten Patien­ten­daten gehören zu den besonders schüt­zens­werten perso­nen­be­zo­genen Daten nach Artikel 9 der DSGVO. Die Sensi­ti­vität dieser Daten erfordert einen entspre­chend hohen Zugriffs­schutz. Hierzu gehört auch das Vertrau­ens­niveau der Authen­ti­fi­zierung des Nutzers. Um das notwendige Vertrau­ens­niveau bei der Authen­ti­fi­zierung des Versi­cherten zu erreichen, wurde die Authen­ti­fi­zierung mittels der eGK spezi­fi­ziert. Hierbei nutzt der Versi­cherte sein persön­liches Endgerät und sein ePA Frontend des Versi­cherten (ePA FdV). Während der Authen­ti­fi­zierung sendet das Akten­system in einem Challenge-Response-Protokoll eine Zufallszahl. Der Versi­cherte hält seine NFC-fähige eGK an sein NFC-fähiges Endgerät und signiert mit dem Schlüs­sel­ma­terial auf der eGK die Zufallszahl. Die Signatur kann vom Akten­system verifi­ziert werden und stellt den Nachweis der erfolg­reichen Authen­ti­fi­zierung dar. Dieser Prozess setzt neben einem kompa­tiblen Endgerät eine NFC-fähige eGK und die Kenntnis der PIN voraus. Die Verwendung eines zusätz­lichen Hardware-Tokens wie einer Smartcard stellt außerdem bis heute eine Hürde bei der Nutzung dar. Um diesem Umstand vorbeugend zu begegnen, hat die gematik bereits zur Einführung der ePA auch die sogenannte Alter­native Versi­cher­ten­iden­tität eingeführt.

Die Alter­native Versichertenidentität

Die Alter­native Versi­cher­ten­iden­tität (al.vi) verlagert die Signatur der Zufallszahl im Challenge-Response-Verfahren zwischen Akten­system und Frontend von der eGK zu einem Signa­tur­dienst. Beim Signa­tur­dienst ist für jeden Nutzer ein eigener Signa­tur­schlüssel gespei­chert, dessen Signa­turen wiederum über ein Zerti­fikat aus dem Vertrau­ensraum der TI verifi­zierbar sind. Um den Signa­tur­schlüssel zu verwenden, muss der Nutzer sich beim Signa­tur­dienst authen­ti­sieren. Hierbei können beliebige Authen­ti­fi­zie­rungs­ver­fahren verwendet werden, die das Vertrau­ens­niveau von mindestens substan­ziell gemäß eIDAS-VO erfüllen. Somit können auch Verfahren ohne zusätz­liche Hardware verwendet werden. Der Signa­tur­dienst hat gegenüber der eGK den sicher­heits­tech­ni­schen Nachteil, dass der Versi­cherte den Signa­tur­schlüssel nicht mehr unmit­telbar unter seiner Kontrolle hat.

Der Identity Provider-Dienst

Mit der Einführung des E‑Rezepts setzte die gematik erstmals auf das Modell eines Identity Provider-Dienstes (IDP-Dienst), der heute auch zentraler IDP oder Smartcard-IDP genannt wird. Die Idee dahinter ist, die Funktio­na­lität der Nutzer-Authen­ti­fi­zierung vom Fachdienst zu lösen und diese vom IDP-Dienst durch­führen zu lassen. Der IDP-Dienst stellt dem Fachdienst dann auf Basis von OpenID Connect eine Authen­ti­fi­zie­rungs­be­stä­tigung bereit. Auf diese Weise erfüllt jeder Dienst seinen fachlichen Zweck. Außerdem kann der IDP-Dienst zumindest in der Theorie auch die Authen­ti­fi­zierung der Nutzer für weitere Fachdienste, etwa für die ePA übernehmen. Die Funktio­na­lität der Authen­ti­sierung muss somit nicht für jeden Fachdienst neu spezi­fi­ziert und imple­men­tiert werden und der Nutzer kann seine bestehende Regis­trierung beim IDP-Dienst wieder­ver­wenden. Da für die Authen­ti­fi­zierung beim IDP-Dienst wiederum die eGK verwendet werden muss, liegt hier die gleiche digitale Identität zugrunde wie zuvor bei der ePA. Zwar kann der Nutzer, je nach Eigen­schaften seines Endgeräts nach initialer Identi­fi­zierung auch biome­trische Verfahren für die Authen­ti­sierung nutzen, muss sich (außer bei wenigen geeig­neten Endge­räten) aber zum Erhalt des Sicher­heits­ni­veaus regel­mäßig auch mit der eGK authentisieren.

Fasttrack

Um dem Versi­cherten einen ähnlich komfor­tablen Zugang zum E‑Rezept wie zur ePA zu ermög­lichen, wurde die Lösung Fasttrack entwi­ckelt. Hierbei wird der IDP-Dienst mit dem Signa­tur­dienst der ePA gekoppelt, so dass eine Authen­ti­fi­zierung über die al.vi möglich wird. Voraus­setzung für die Nutzung ist aber, dass der Versi­cherte über eine ePA verfügt und die al.vi einge­richtet hat.

Föderiertes Identi­täts­ma­nagement

Ende 2020 veröf­fent­lichte die gematik das White­paper Arena für digitale Medizin und kündigte darin unter anderem die TI 2.0 an. In diesem Zusam­menhang wurde ein weiteres Modell für digitale Identität vorge­stellt, das föderierte Identitätsmanagement.

Beim föderierten Identi­täts­ma­nagement gibt es nicht mehr einen zentralen IDP-Dienst, sondern eine Menge von sogenannten sekto­ralen Identity Providern (sektorale IDP), die in einer Föderation organi­siert sind. Mitunter wird auch von dezen­tralen IDPs gesprochen. Die Grundlage bildet, wie schon beim zentralen IDP, wieder OpenID Connect. Dies gilt gleicher­maßen für die Föderation, welcher der OpenID Connect Federation Standard zugrunde liegt. Die sekto­ralen IDPs sollen von den Kranken­kassen bereit­ge­stellt werden. Die Idee: jede Kranken­kasse verwaltet die digitalen Identi­täten ihrer Versi­cherten, führt die Authen­ti­fi­zierung der Versi­cherten durch und bestätigt diese gegenüber den Fachdiensten in der TI und zukünf­tigen TI 2.0. Das föderierte Identi­täts­ma­nagement soll dabei die Vorgaben aus § 291 SGB V umsetzen, wonach die gesetz­lichen Kranken­ver­si­che­rungen ihren Versi­cherten ab 01.01.2023 auf Verlangen eine digitale Identität zur Verfügung stellen müssen. Da die finalen Spezi­fi­ka­tionen zum föderierten Identi­täts­ma­nagement Mitte Dezember 2022 noch nicht veröf­fent­licht sind, wird die tatsäch­liche Einführung dieser digitalen Identi­täten aber wohl noch etwas dauern.

Fazit

In der TI gibt es aktuell verschiedene Ausprä­gungen von digitalen Identi­täten. Mit der Einführung der TI 2.0 könnte das föderierte Identi­täts­ma­nagement die anderen Ausprä­gungen verdrängen. Dies scheint auch der Gesetz­geber zu planen. So heißt es im Digitale-Versorgung-und-Pflege-Moder­ni­sie­rungs-Gesetz (DVPM), dass „die digitalen Identi­täten in gleicher Weise wie die elektro­nische Gesund­heits­karte zur Authen­ti­sierung des Versi­cherten im Gesund­heits­wesen und als Versi­che­rungs­nachweis“ dienen sollen. Nach Stand der aktuell veröf­fent­lichten Entwürfe der Spezi­fi­ka­tionen spielt die eGK zur Authen­ti­sierung des Versi­cherten aber auch im föderierten Identi­täts­ma­nagement weiterhin eine Rolle. Vorerst werden wohl alle beschrie­benen Ausprä­gungen digitaler Identi­täten ihre Relevanz für eine funktio­nie­rende TI und einem zunehmend digitalen Gesund­heits­wesen behalten.

___________________________________________________

Autor: Nico Martens, Berater SRC Security Research & Consulting GmbH

Weitere Infor­ma­tionen:  https://src-gmbh.de/

Presse­kontakt:                    

Patrick Schulze

WORDFINDER GmbH & CO. KG

Lornsen­straße 128–130

22869 Schenefeld

 Tel. +49 (0) 40 840 55 92–18

ps@wordfinderpr.com

 www.wordfinderpr.com