common criteria 2023
Janine Wolff

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.

___________________________________________________

Janine Wolff

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.

Janine Wolff

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

Janine Wolff

Anwen­dungs­be­reiche von Digital Identities: Physische Identi­täten digital reprä­sen­tieren – und schützen

Anwen­dungs­be­reiche von Digital Identities:

Physische Identi­täten digital reprä­sen­tieren – und schützen

 

Mit der aktuellen Weiter­ent­wicklung der europäi­schen Verordnung über elektro­nische Identi­fi­zierung und Vertrau­ens­dienste (eIDAS) kann europaweit eine anerkannte und sichere digitale Identität kommen. Digitale Identi­täten sind dabei schon lange gang und gäbe – vom E‑Mail-Account, über Social Media bis zu digitalen Behör­den­gängen: Die Nutzung digitaler Dienste erfordert einen Identi­täts­nachweis. Die dafür nötige Identi­fi­kation und Authen­ti­fi­zierung ist abhängig vom dafür genutzten Dienst an verschiedene Schutz­ni­veaus gekoppelt. Unter­nehmen, die Dienste anbieten wollen, für die digitale Identi­täten notwendig sind – für Mitar­beiter, Partner und Kunden – müssen die Voraus­set­zungen kennen.

Eine digitale Identität stellt die digitale Reprä­sen­tation einer physi­schen Identität dar. Letztere kann ein Mensch sein, aber auch eine Insti­tution, eine Maschine oder ein Server. Im Gesund­heits­wesen können z. B. Praxen, Kranken­häuser oder Apotheken eine digitale Identität erhalten. Sie stellt in diesem Kontext eine Sammlung von Attri­buten in elektro­ni­scher Form dar, die eine natür­liche oder juris­tische Person charak­te­ri­sieren – das können Name, Adresse und Geburts­datum sein, aber auch Benut­zername oder Email­adresse. Eine digitale ID muss eindeutig sein, da sie sonst nicht zuordenbar ist; der Prozess der ursprüng­lichen Identi­fi­zierung wird ins Digitale übertragen– für die Erst-Identi­fi­kation benötigt es eine Regis­trierung; die Wieder­erkennung erfolgt durch die Authen­ti­fi­zierung. Aus gesell­schaft­licher Perspektive gibt es drei Formen von Identi­täten: Echte, selbst­kon­stru­ierte und anonyme, wobei Letztere zum Beispiel auf Social Media eine teilweise kontro­verse Rolle spielen.

Einsatz­mög­lich­keiten digitaler Identitäten

Digitale Identi­täten sind als Grundlage bzw. digitale Reprä­sen­tation für digitale Dienste und Prozesse notwendig. Sie kommen überall dort zum Einsatz, wo digitale Dienste angeboten werden und perso­na­li­siert sind, was die Erhebung, Speicherung und Verar­beitung von Daten erfordert. Digitale Dienste haben diverse Ausprä­gungen – vom Social-Media-Benut­zer­konto, über Online-Accounts im E‑Commerce, bis hin zum Online-Banking oder digitalen Behör­den­gängen über eGovernment-Angebote. Wie beim Perso­nal­ausweis kann der Anwen­dungs­be­reich einer digitalen Identität über eine reine Identi­fi­kation hinaus­gehen und zum Beispiel eine Alters­prüfung möglich sein.

Die zuneh­mende Digita­li­sierung erschließt weitere Einsatz­mög­lich­keiten einer digitalen Identität: Die europäische eIDAS (Verordnung über elektro­nische Identi­fi­zierung und Vertrau­ens­dienste) schafft hier einheit­liche Rahmen­be­din­gungen für die Nutzung elektro­ni­scher Identi­fi­zie­rungs­mittel und Vertrau­ens­dienste über Grenzen hinweg. 2020 wurde die Überar­beitung der eIDAS-Richt­linie gestartet, sie ist derzeit noch nicht abgeschlossen. Ziel ist es, europaweit ein sicheres EU-Identity-Wallet anzubieten. Die eID ist damit das virtuelle Pendant eines Ausweises. Sie soll eine Identi­fi­kation und Authen­ti­fi­zierung ermög­lichen, eine Überprüfung der Gültigkeit durch Dritte sowie die sichere Speicherung und Darstellung der Identi­täten. Außerdem soll sie es erlauben, quali­fi­zierte elektro­nische Signa­turen zu generieren. Dieses digitale Pendant zur Unter­schrift erlaubt auf digitaler Ebene rechts­gültige Vertragsabschlüsse.

Die eIDAS gibt auch vor, dass die EU-Mitglied­staaten den Bürgern die digitale Identität zur Verfügung stellen müssen; auch die vorge­sehene Akzep­tanz­pflicht kann dazu beitragen, dass andere digitale Identi­täten wegfallen. Einkäufe im Ausland oder die Abholung eines Mietwagens könnten damit verein­facht werden, da die digitale Identität Prozesse effizi­enter macht. Denn digitale Dienste sind im Vergleich zu analogen Prozessen mit einer Kosten­re­duktion verbunden; der User profi­tiert stark von einer einfa­cheren und beque­meren Handhabung, etwa, wenn sich Behör­den­gänge von zu Hause aus erledigen lassen.

Anders als bei digitalen Identi­täten über Google oder Facebook kann durch die Behörden sicher­ge­stellt werden, dass der Daten­schutz nach DSGVO einge­halten wird. Im Gesund­heits­wesen sollen digitale Identi­täten auf dem Smart­phone perspek­ti­visch die elektro­nische Gesund­heits­karte ablösen – aktuell kann dies aber noch nicht reali­siert werden.

Sicherheit und Schutz des Users 

Ein mögliches Angriffs­sze­nario, das digitale Identi­täten in beson­derem Maße betrifft, ist der Diebstahl in Form von Imper­so­nation bzw. Identi­täts­dieb­stahl. Das Schadens­po­tenzial reicht dabei von Hasskom­men­taren auf Social Media bis zum Zugriff und Missbrauch von persön­lichen Daten etwa bei Bankge­schäften oder vertrau­lichen Gesund­heits­daten. Während der analoge Perso­nal­ausweis den Missbrauch durch Diebe wegen des darauf abgebil­deten Fotos limitiert, sieht der Fall online anders aus. Die digitale Identität muss also besonders geschützt werden. Schutz­maß­nahmen können zum Beispiel sichere Passwörter sein oder eine Zweifaktor-Authen­ti­fi­zierung, wie sie bereits im Online-Banking zum Beispiel mit Passwort einer­seits und zusätz­licher TAN-Generierung auf einem externen Gerät anderer­seits statt­findet. Der Hardware­token in Smart­cards stellt als zerti­fi­zierte Ausführung ein Höchstmaß an Sicherheit dar.

Standar­di­sierte Vertrauensniveaus

Das Sicher­heits­niveau hängt vom Einsatz­zweck der digitalen Identität ab und wird in der Durch­füh­rungs­ver­ordnung (EU) 2015/1502 geregelt. So liegen zum Beispiel im Online-Banking oder im Gesund­heits­be­reich besonders sensible, perso­nen­be­zogene Daten vor, die eines hohen Schutz­ni­veaus bedürfen. Die Verordnung definiert drei standar­di­sierte Vertrau­ens­ni­veaus: niedrig, substan­tiell und hoch. Ein niedriger Schutz­bedarf entspricht einer Ein-Faktor-Authen­ti­fi­zierung, wie sie in Social Networks oder Foren geläufig ist. Substan­ziell wird der Schutz durch die bereits genannte Zwei-Faktor-Authen­ti­fi­zierung. Ein hoher Schutz, wenn etwa Gesund­heits­daten betroffen sind, muss aller­dings noch stärker abgesi­chert sein, zum Beispiel mit einem Pass samt Foto und biome­tri­schen Merkmalen. So können Identi­fi­zie­rungen über Video-Ident- oder Post-Ident­ver­fahren erfolgen.

Je höher das Sicher­heits­niveau, desto kompli­zierter gestaltet sich aller­dings dessen technische Umsetzung. So bringen hochpreisige Smart­phones zerti­fi­zierte Sicher­heits­kom­po­nenten mit – während in günsti­geren Endge­räten jedoch minder­wer­tigere biome­trische Sensoren verbaut werden, die leicht manipulier- oder überbrückbar sind. Sie verfügen also über keine geschützten Speicher­be­reiche. Smart­cards in Gesund­heits­karten können dagegen mit ihren Chip-Prozes­soren krypto­gra­fi­sches Schlüs­sel­ma­terial verwenden und speichern. Damit stellen die dahin­ter­lie­genden Infra­struk­turen die Echtheit sicher.

Das Zukunfts­po­tenzial digitaler Identitäten

Die Digita­li­sierung nimmt zu, all ihre Dienste erfordern eine digitale Identität und diese sind bereits weit verbreitet: Im Schnitt hat jeder Bürger 90 digitale Identi­täten. Dabei können digitale und analoge Welt verschmelzen, etwa, wenn Zutritts­kon­trollen in Unter­nehmen digita­li­siert sind und den Nachweis einer digitalen Identität erfordern, oder wenn in Arztpraxen die Gesund­heits­karte als ID einge­lesen wird. Hier werden Medien­brüche als Hemmnis wahrge­nommen, etwa wenn Papier­do­ku­mente als Scans bei Kranken­kassen einge­reicht werden sollen. Digitale Identi­täten und die damit mögliche Zuordnung machen die Digita­li­sierung solcher Prozesse überhaupt erst möglich. Im Bereich eHealth können Ärzte so z. B. Rechnungen und Rezepte digital signieren und versenden.

Unter­nehmen wiederum können digitale Identi­täten in der Breite für Kunden und Mitar­beiter, Endkunden oder Partner nutzen. Damit kann zum Beispiel die Urlaubs­be­an­tragung über ein Portal erfolgen. Nicht zu vernach­läs­sigen sind auch denkbare Anwen­dungs­mög­lich­keiten für die Kunden­bindung: Denn über digitale Dienste, die Kunden nutzen, lassen sich nicht zuletzt Infor­ma­tionen über deren Verhalten gewinnen – um damit das eigene Angebot besser zuschneiden und optimieren zu können. Dabei müssen sich Unter­nehmen der verschie­denen Sicher­heits­ni­veaus aller­dings zwingend bewusst sein. Nutzer­freund­lichkeit ist zwar wichtig –  ebenso aber auch der digitale Schutz vor Identitäts- und Datenraub. Ist dieser nicht gewähr­leistet, können gravie­rende Auswir­kungen die Folgen sein. Ein Beratungs­un­ter­nehmen wie die SRC GmbH kann hier helfen, Lösungen – kosten­pflichtige wie open source – zu beleuchten, Zerti­fi­zie­rungen zu prüfen und die Konfor­mität und damit Rechts­si­cherheit sicherzustellen.

Fazit

Ohne digitale Identi­täten läuft im Internet nichts – digitale Dienste erfordern initial eine Identi­fi­kation des Users und für die Weiter­nutzung eine Authen­ti­fi­zierung zum Beispiel über Passwörter mit zusätz­licher TAN-Generierung im Rahmen von Multi­faktor-Verfahren. Von der Art des Dienstes und der dabei genutzten Daten hängen die Erfor­der­nisse an die Sicherheit ab, die über drei Niveaus sicher­ge­stellt wird. Unter­nehmen, die digitale Dienste nutzen wollen, müssen deswegen die Voraus­set­zungen kennen um die Anwen­dungs­po­ten­ziale für Kunden, Partner oder Liefe­ranten zu nutzen.

___________________________________________________

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

 

Homepage Admin

SRC unter­stützt ID:Smart Workshop 2023 – Call for Papers veröffentlicht

Am 21. und 22. Juni 2023 findet nach zweijäh­riger Pause der

ID:Smart Workshop 2023

in Darmstadt statt. Wegen der Auszeit durch die Corona Pandemie wird der Workshop in diesem Jahr ausnahms­weise im Juni durch­ge­führt und soll ab 2024 wieder zur „gewohnten“ Zeit im Frühjahr stattfinden.

Mögliche Beiträge zu den im hier verfüg­baren Call for Paper genannten Themen können bis Ende Februar einge­reicht werden.

Hinweise zur Anmeldung und zum Programm finden sie auf der Webseite des ID:Smart Workshops.

Homepage Admin

Weihnachten für alle

Nach zwei Jahren Pande­mie­ein­schränkung können wir uns wieder etwas befreiter darauf freuen, den Advent und die Weihnachtstage mit der Familie und den Freunden zu feiern. Doch mit der Freude mischt sich Traurigkeit, wenn wir die Nachrichten hören und sehen. Der Krieg in der Ukraine ist brutal und der Winter ist kalt. Viele Häuser sind zerstört, kein Strom, kein Wasser, keine Wärme. Auch die Versorgung mit Lebens­mitteln ist vielfach zusam­men­ge­brochen. Nachdem wir in den letzten Jahren vielfältige Geschäfts­be­zie­hungen in die Ukraine aufgebaut und gepflegt haben, geht uns dies besonders nahe.

Wir haben uns daher entschlossen, in diesem Jahr auf Geschenke an Mitar­bei­tende und Geschäfts­partner zu verzichten und statt­dessen die von der Help e.V. organi­sierte Winter­hilfe für die Ukraine zu unter­stützen. Wir denken, dass wir damit auch im Sinne aller unserer Geschäfts­partner handeln und hoffen, auf diese Weise ein wenig dazu beitragen zu können, dass Weihnachten auch in der Ukraine ankommt.

Für Ihr Vertrauen und für die Zusam­men­arbeit im zu Ende gehenden Jahr möchten wir uns bei Ihnen herzlich bedanken. Wir sind sehr froh darüber, dass Sie uns auch in einem von räumlicher Distanz geprägten Jahr nahe waren und schauen erwar­tungsfroh auf das kommende Jahr, um mit Ihnen gemeinsam weitere spannende Projekte umzusetzen. Aber bis dahin bleibt natürlich noch ein bisschen Zeit. Nutzen Sie die freien Tage, um neue Kraft zu tanken und ruhige Stunden zu verbringen.

Wir wünschen Ihnen ein – trotz der Umstände – wunder­volles Weihnachtsfest und vor allem genügend Erholung. Und dann natürlich einen guten Start ins neue Jahr voller Ideen und Kraft für neue Aufgaben.

Herzliche Grüße,

Ihr

 

 

 

 

Gerd Cimiotti
SRC GmbH

 

Technische Sicherheitseinrichtungen
Homepage Admin

Teilgut­achten zur Betriebs­um­gebung von fiskaly signCloud-TSE Instanzen

Seit 2020 ist der Einsatz von zerti­fi­zierten Techni­schen Sicher­heits­ein­rich­tungen (TSE) zur Absicherung von Aufzeich­nungen in Regis­trier­kassen in Deutschland gesetzlich vorge­schrieben. Das Bundesamt für Sicherheit in der Infor­ma­ti­ons­technik (BSI) hat Sicher­heits­an­for­de­rungen an Techni­schen Sicher­heits­ein­rich­tungen veröf­fent­licht und prüft die Einhaltung dieser zerti­fi­zie­rungs­re­le­vanten Aspekte und Vorgaben durch die TSE-Hersteller. Die Einhaltung der Sicher­heits­an­for­de­rungen werden durch anerkannte Prüfstellen des BSI bewertet. Bei positivem Prüfungs­er­gebnis zerti­fi­ziert das BSI auf Grundlage des Prüfbe­richts die TSE eines Herstellers.

Nach erteilter Zerti­fi­zierung der TSE, muss für die Finanz­be­hörden zusätzlich nachge­wiesen werden, dass der Betrieb einer TSE beim Steuer­pflich­tigen so erfolgt, dass der zerti­fi­zierte Zustand erhalten bleibt.

SRC hat als eine beim BSI anerkannte Prüfstelle das Produkt fiskaly sign Cloud TSE (Version 1.2.0 – 1.0.5) der fiskaly unter­sucht und das BSI hat hierfür die entspre­chenden Zerti­fikate erteilt. Darüber hinaus hat SRC den Betrieb der fiskaly TSE näher beleuchtet. Die Anfor­de­rungen an den Betrieb wurden in inten­siver gemein­samer Zusam­men­arbeit mit fiskaly analy­siert und geprüft. Die Überprüfung der Einhaltung zur Aufrecht­erhaltung des zerti­fi­zierten Zustands konnte für alle von fiskaly im Markt befind­lichen o.g. TSE-Versionen durch­ge­führt werden.

Die Ergeb­nisse der Prüfung lassen sich in den nachfol­genden Punkten zusammenfassen:

  1. Es wird nachge­wiesen, dass die fiskaly SMAERS ausschließlich Anfragen von Systemen oder Kompo­nenten entge­gen­nehmen kann, welche aus derselben physi­schen opera­tio­nellen Einsatz­um­gebung (vgl. “same physical opera­tional environment”) kommen.
  2. Die Kommu­ni­kation mit der fiskaly SMAERS ist integri­täts­ge­schützt und verschlüsselt.
  3. Es wird bestätigt, dass sowohl A.ProtComERS als auch OE.SecOEnv aus SMAERS PP konform umgesetzt sind.
  4. Die Vorgaben aus dem von SRC betrach­teten Umgebungs­schutz­konzept von fiskaly werden eingehalten.
  5. Die durch fiskaly betrie­benen und von SRC betrach­teten TSE-Instanzen erfüllen die Anfor­de­rungen an einen zerti­fi­zierten Betrieb.

Details sind dem ausführ­lichen Unter­su­chungs­be­richt der SRC zu entnehmen.

Über fiskaly

fiskaly entwi­ckelt innovative SaaS-Infra­struktur und bietet sichere Cloud-Lösungen rund um den Kassen­beleg für Kassen­an­bieter- und händler in Öster­reich und Deutschland. Im Bereich der Fiska­li­sierung betreibt das Unter­nehmen ein markt­füh­rendes Produkt im deutschen Markt, unsere zerti­fi­zierte TSE wird bundesweit in einer halben Million Regis­trier­kassen einge­setzt. Mit dem digitalen Kassenbon wurde vor Kurzem ein neues Geschäfts­segment eröffnet, die Erschließung neuer europäi­scher Märkte ist für Ende dieses Jahres geplant.

Gegründet wurde fiskaly 2019 in Wien. Mehr als 50 Mitar­bei­te­rInnen in den Büros in Wien, Frankfurt und Berlin tragen zum Erfolg des Unter­nehmens bei.

fiskaly.com

SRC GEAR
Homepage Admin

SRC wird Teil des GEAR (Global Executive Assessor Roundtable)!

PCI SSC und SRC

Das Payment Card Industry Security Standards Council (PCI SSC) ist ein globales Forum, welches Infor­ma­ti­ons­si­cher­heits­stan­dards für sichere Zahlungen entwi­ckelt und deren Anwendung voran­treibt. Es ist verant­wortlich für 15 weltweit anerkannte und verbreitete Standards zur Absicherung von elektro­ni­schen Zahlver­fahren – von der Zahlkar­ten­pro­duktion und ‑herausgabe über die Zahlung am Point of Interest oder in Web & App bis hin zur Abwicklung der Zahlungen im Hinter­grund. SRC prüft die Nutzung der Infor­ma­ti­ons­si­cher­heits­stan­dards seit Gründung des PCI SSC im Rahmen entspre­chender Audits und Produktprüfungen.

Das PCI SSC legt Wert auf den Austausch zwischen verschie­denen Stake­holdern und nutzt dafür verschiedene Gremien und Aktivi­täten. SRC hat sich bisher im Rahmen von Special Interest Groups und Task Forces sowie durch die Teilnahme an Community Meetings und Request for Comment-Phasen beteiligt.

Global Executive Assessor Roundtable

Das PCI SSC gibt seit 2018 im Global Executive Assessor Round­table (GEAR) erfah­renen Audit-Unter­nehmen die Möglichkeit, seine obere Führungs­ebene zu beraten.

Wir freuen uns, dass unser Unter­nehmen dieses Jahr mit ausge­wählt wurde, im Rahmen dieser verant­wor­tungs­vollen Mitglied­schaft eine der Schnitt­stellen zwischen der Führung des PCI SSC selbst und der Führung der Auditie­rungs­ge­sell­schaften zu bekleiden. Hierdurch können wir unsere jahre­lange Erfahrung zukünftig auf direktem Wege einbringen.

Die Ernennung gilt für die kommenden zwei Jahre und gibt uns die Möglichkeit, an der Weiter­ent­wicklung von Vorgaben für Audit-Verfahren, neue Schulungs­pro­gramme und Quali­fi­ka­ti­ons­an­for­de­rungen zukünf­tiger Auditie­render einfluss­gebend mitzu­wirken. Weitere Aufga­ben­be­reiche der GEAR sind unter anderem, Möglich­keiten zu finden, das Engagement von Auditie­renden in aufstre­benden und neuen Märkten zu fördern, und die Fähig­keiten und Fertig­keiten von Auditie­renden im Sinne eines Mehrwerts für Zahlungs­ver­kehrs-Unter­nehmen zu optimieren.

Wir sind stolz, in diesen Kreis aufge­nommen worden zu sein, und sehen darin eine Anerkennung unserer bishe­rigen Leistung und Relevanz auf dem Markt der Zahlungs­ver­kehrs­si­cherheit. Zugleich sind wir uns unserer Verant­wortung bewusst, die Stell­ver­tretung für eine große Gemein­schaft an Auditie­rungs­ge­sell­schaften wahrzu­nehmen, und nehmen dies als zusätz­lichen Ansporn für die Zukunft.

Link zum GEAR: https://www.pcisecuritystandards.org/about_us/global_executive_assessor_roundtable/

Janine Wolff

8‑stellige BINs und PCI DSS

Am 1. April 2022 werden die Karten­or­ga­ni­sa­tionen Visa und Mastercard die BIN (Bank Identi­fi­cation Number) ihrer Karten weltweit von 6 auf 8 Stellen ausdehnen. Von einer 16-stelligen Kredit­kar­ten­nummer (Primary Account Number, PAN) dienen dann in Zukunft die ersten 8 Stellen zur Identi­fi­kation des Karten­her­aus­gebers. Die BIN wird an vielen Stellen genutzt, wo die Verwendung der vollstän­digen PAN nicht nötig ist – z.B. für das Routing von Trans­ak­tionen oder für Reportings.

BINs und PCI DSS 

Überall dort, wo eine vollständige PAN genutzt wird, müssen die Systeme, Umgebungen, Prozesse und Personen die Anfor­de­rungen des Daten­si­cher­heits­stan­dards PCI DSS (Payment Card Industry Data Security Standard) erfüllen. So sinnvoll der Schutz der PAN durch den PCI DSS ist – für die BIN ist er nicht notwendig.

Im PCI DSS ist daher beschrieben, unter welchen Bedin­gungen für Teile der PAN nicht der gleiche Schutz wie für die volle PAN notwendig ist. Wird nicht die volle PAN gespei­chert, verar­beitet oder übertragen, sondern nur einige Stellen davon, spricht man im PCI DSS von „Trunkierung“. Ist zwar die volle PAN im Hinter­grund gespei­chert, aber in einer Appli­kation werden nicht alle Stellen angezeigt, spricht man im PCI DSS bei der Anzeige von „Maskierung“. Im Alltag wird für beide unter­schied­lichen Maßnahmen auch der Begriff „ausgeixt“ verwendet; aus Sicht des PCI DSS muss man diese aber unterscheiden.

Für Trunkierung und Maskierung galten bisher folgende Regeln:

  • Maskierung: PCI DSS-Anfor­derung 3.3 besagt, dass maximal die ersten sechs und letzten vier Stellen („first 6, last 4“) der PAN angezeigt werden dürfen, solange es keinen Business Need für die Einsicht in die volle PAN gibt.
  • Trunkierung: In PCI DSS-Anfor­derung 3.4 wird Trunkierung als Beispiel für die Unkennt­lich­ma­chung von PANs benannt, aber nicht genauer definiert. Die erlaubten Formate werden jeweils von den inter­na­tio­nalen Zahlkarten-Organi­sa­tionen festgelegt und vom PCI SSC im FAQ-Eintrag #1091 zusam­men­ge­fasst. Die meisten Zahlkarten-Organi­sa­tionen hatten sich dabei auf die Regel „first 6, any other 4“ geeinigt, die viele Jahre Bestand hatte.

Änderung der Regeln für Trunkierung und Maskierung 

Aufgrund der Umstellung auf 8‑stellige BINs und der Notwen­digkeit vieler Unter­nehmen, diese zu verar­beiten, haben die Zahlkarten-Organi­sa­tionen ihre Vorgaben nun aber geändert. In der aktuellen Zusam­men­fassung im FAQ-Eintrag des PCI SSC ist nun definiert, dass für 16-stellige PANs bei der Trunkierung „first 8, any other 4“ zulässig ist.
Die (Test)Kartennummer 4012888888881881 dürfte dann in Zukunft z.B. in der Form 40128888xxxx1881 gespei­chert und verar­beitet werden – es reicht aus, wenn beliebige vier Stellen hinter der BIN ausgeixt sind.
Lediglich für kürzere PANs bleibt es bei den bestehenden Regeln „first 6, any other 4“ (Discover) bzw. „first 6, last 4“ (American Express).  Bei der Maskierung wird eine entspre­chende Anpassung der PCI DSS-Anfor­derung mit der Umstellung auf PCI DSS v4.0 erwartet.

Aus Sicher­heits­sicht ist das Ausixen so weniger Stellen keine Verbes­serung – aus der Business-Perspektive ist die Änderung aber wohl notwendig. Es bleibt zu hoffen, dass dies in der Gesamt­sicht durch andere Sicher­heits­maß­nahmen ausge­glichen wird.
Auf jeden Fall stehen in Zukunft die Anfor­de­rungen des PCI DSS der Verwendung einer 8‑stelligen BIN nicht im Wege.

Vorsicht bei der Kombi­nation verschie­dener Formate 

Händler und Dienst­leister, die mit trunkierten Karten­daten arbeiten, sollten – unabhängig von der Länge der BIN – darauf achten, den Schutz der Karten­daten nicht durch die Vermi­schung verschie­dener Formate zu schwächen.

  • Es muss darauf geachtet werden, dass die erwei­terten Trunkie­rungs­formate nur für 16-stellige PANs gelten. Die Länge der PAN muss also für die Trunkierung bei der Speicherung berück­sichtigt werden.
  • Trunkie­rungs­formate wie „first 6, any other 4“ erlauben theore­tisch das Vorliegen unter­schied­licher trunkierter Versionen der gleichen PAN. Die oben angeführte Karten­nummer könnte in einem System als 40128888xxxx1881 gespei­chert sein, in einem anderen als 401288888888xxxx. Das ist nicht verboten – es muss jedoch darauf geachtet werden, dass keiner ohne entspre­chenden Business Need die beiden Versionen zusam­men­führen kann und somit weitere Stellen der PAN – bis hin zur vollstän­digen Karten­nummer – rekon­stru­ieren kann.
    Dies gilt genauso, wenn für Maskierung und Trunkierung unter­schied­liche Formate verwendet werden.
  • Werden in einer Umgebung sowohl trunkierte PANs als auch die Hash-Werte von PANs gespei­chert, so sind die beiden Werte an sich erst einmal unkri­tisch. Lassen sich die trunkierten PANs und ihre Hash-Werte jedoch in Verbindung bringen, lässt sich über Rainbow Tables leicht die ursprüng­liche volle PAN rekon­stru­ieren. Auch in diesem Fall muss also über zusätz­liche Maßnahmen die Möglichkeit der Zusam­men­führung der beiden Versionen verhindert werden.

 

 

Janine Wolff

IT-Sicher­heits­re­gu­lierung im Gesund­heits­wesen: Welche Regeln für die Cyber­se­curity gelten

Die Digita­li­sierung des Gesund­heits­sektors entwi­ckelt sich dynamisch: Digitale Produkte erobern den Markt; Künst­liche Intel­ligenz hält Einzug, Innova­tionen in Bereichen wie Pflege, Medizin, Genthe­rapie oder Nanotech­no­logie sind weitere Treiber. Gleich­zeitig ist die Markt­ein­führung neuer Healthcare-Produkte an strenge IT-Sicher­heits­be­stim­mungen gebunden – zu Recht, da sie äußerst sensible Daten zu Gesundheit und Leben von Menschen berühren oder die Therapie beein­flussen. IT-Sicherheit wird umso wichtiger. Doch welche Vorgaben zu beachten, welche Nachweise zu erbringen sind, ist für Anbieter und Betreiber oft nicht leicht zu überblicken.

Kritische Infra­struk­turen: Die KRITIS-Verordnung

Besondere Anfor­de­rungen an die IT-Sicherheit gelten bereits für bestehende Einrich­tungen des Gesund­heits­wesens, sofern sie vom Bundesamt für Sicherheit in der Infor­ma­ti­ons­technik (BSI) als Kritische Infra­struk­turen klassi­fi­ziert sind. Im Gesund­heits­sektor betrifft das nicht nur die stationäre medizi­nische Versorgung, sondern auch die Versorgung mit unmit­telbar lebens­er­hal­tenden Medizin­pro­dukten, verschrei­bungs­pflich­tigen Arznei­mitteln, Blut- und Plasma­kon­zen­traten sowie die Labora­to­ri­ums­dia­gnostik ab einer bestimmten Größe. Die jewei­ligen Schwel­len­werte sind in der BSI-Kritis­ver­ordnung definiert. Als Richt­größe gilt hier der Regel­schwel­lenwert von 500.000 von der Einrichtung versorgten Personen.

Laut BSI-Gesetz (§ 8a) müssen die jewei­ligen Betreiber nach Stand der Technik angemessene organi­sa­to­rische und technische Vorkeh­rungen treffen, um Störungen der Verfüg­barkeit, Integrität, Authen­ti­zität und Vertrau­lichkeit ihrer maßgeb­lichen infor­ma­ti­ons­tech­ni­schen Systeme, Kompo­nenten oder Prozesse zu vermeiden. Gegenüber dem Bundesamt ist die IT-Sicherheit alle zwei Jahre durch Sicher­heits­audits, Prüfungen oder Zerti­fi­zie­rungen nachzu­weisen. Zusätzlich kann das BSI auch selbst Sicher­heits­über­prü­fungen durch­führen oder durch­führen lassen. Bei Nicht­ein­haltung der gesetz­lichen Vorgaben drohen empfind­liche Geldstrafen.

Ausweitung der Verordnung auf alle Kranken­häuser: KRITIS „light“

Seit Januar 2022 gelten diese IT-Sicher­heits­vor­gaben nicht nur für stationäre medizi­nische Einrich­tungen im Sinne der KRITIS-Verordnung, sondern für alle Kranken­häuser. Auch wenn die Nachweis­pflicht gegenüber dem BSI hier entfällt, müssen Betreiber im Ernstfall mit Schadens­er­satz­for­de­rungen und Haftungs­ri­siken rechnen. Daher sollten die im Sozial­ge­setzbuch V (§ 75) hinter­legten Anfor­de­rungen in jedem Fall umgesetzt und wie gefordert alle zwei Jahre an den aktuellen Stand der Technik angepasst werden. Orien­tierung bieten dabei die branchen­spe­zi­fi­schen Sicher­heits­stan­dards für die infor­ma­ti­ons­tech­nische Sicherheit der Gesund­heits­ver­sorgung im Krankenhaus.

Wann immer also in Kranken­häusern und Einrich­tungen der Kriti­schen Infra­struktur neue Systeme oder Kompo­nenten innerhalb der Kernfunk­tionen einge­setzt werden, sind diese auch unter KRITIS-Sicher­heits­aspekten zu bewerten und in die Prüfpro­zesse einzubeziehen.

Daten­si­cherheit: Ein Ziel – unter­schied­liche Verfahren

Der Schutz der für das Gemein­wesen wichtigen Kriti­schen Infra­struk­turen ist aber nur ein Aspekt der IT-Sicherheit im Gesund­heits­wesen. Da die Sicherheit der sensiblen Daten auch im Alltags­be­trieb jederzeit gegeben sein muss, sind in allen betrof­fenen Bereichen Cyber­se­curity-Anfor­de­rungen, Zulas­sungs­vor­aus­set­zungen und Prüfpro­zesse zu definieren und laufend auf dem aktuellen Stand der Technik zu halten. Die gesetz­lichen Rahmen­be­din­gungen dafür sind im Sozial­ge­setzbuch zusam­men­ge­fasst. Als nationale Behörde für Cyber­si­cher­heits­zer­ti­fi­zierung ist das BSI die zentrale Instanz. Aller­dings – und das macht es für Antrag­steller schwierig zu überblicken – gibt es nicht den einen Prüf- oder Zerti­fi­zie­rungs­prozess für die IT-Sicherheit von Gesundheitsprodukten.

Die IT-Sicher­heits­prü­fungen erfolgen immer in Absprache mit dem BSI oder durch das Bundesamt selbst, sind aber in die jewei­ligen Zulas­sungs­pro­zesse der verschie­denen Services einge­gliedert. Zuständig sind jeweils unter­schied­liche Insti­tu­tionen: Etwa die Gesell­schaft für Telematik für Anwen­dungen in der Telema­tik­in­fra­struktur oder das Bundes­in­stitut für Arznei­mittel und Medizin­pro­dukte für digitale Gesund­heits­an­wen­dungen, netzwerk­fähige Medizin­pro­dukte und Pflege­geräte – dazu im Folgenden einige Erläuterungen.

Telema­tik­in­fra­struktur: Mehrstufige Prüfprozesse

Zu den Heraus­for­de­rungen im Healthcare-Sektor gehört die komplexe Struktur aus Betreibern, Leistungs­er­bringern, Kosten­trägern und Versi­cherten. Die Digita­li­sierung bietet die Chance, die einzelnen Akteure neu zu vernetzten, die Kommu­ni­kation und Abläufe dadurch erheblich zu beschleu­nigen und verbessern. Basis dieser neuen digitalen Vernetzung ist in Deutschland die Telema­tik­in­fra­struktur (§ 306 SGB). Dienste wie die elektro­nische Patien­tenakte oder der E‑Medikationsplan setzen auf dieser inter­ope­rablen Kommu­ni­ka­tions- und Sicher­heits­ar­chi­tektur auf. Für Aufbau und Weiter­ent­wicklung der Telema­tik­in­fra­struktur (TI) ist die Gesell­schaft für Telematik, gematik, verant­wortlich, zu deren Aufgaben auch die Definition und Durch­setzung verbind­licher Standards für Dienste, Kompo­nenten und Anwen­dungen gehört.

Bei der IT-Sicher­heits­be­wertung arbeitet die gematik GmbH eng mit dem BSI zusammen. Dazu werden alle TI-Kompo­nenten und Dienste in einem mehrstu­figen Prüfungs­ver­fahren gemeinsam mit den Anbietern umfang­reichen Tests unter­zogen, bevor Sicher­heits­eva­lua­tionen oder genaue Sicher­heits­gut­achten erstellt werden. Die einzelnen Anfor­de­rungen sind in sogenannten Produkt­steck­briefen für die Zulassung der Anbieter in Anbie­ter­steck­briefen hinterlegt.

Auch nach der Zulassung wird der sichere und störungs­freie Betrieb überwacht. Eine unberech­tigte Nutzung der Telema­tik­in­fra­struktur wie auch die Nicht­meldung von Störungen oder Sicher­heits­mängeln kann mit hohen Geldstrafen bis zu 300.000 EUR geahndet werden.

Video­sprech­stunde – Anbieter von Videodiensten

Während neue TI-Dienste wie die die elektro­nische Patien­tenakte (ePA) sicher noch etwas Zeit benötigen, um auch beim Versi­cherten anzukommen, sind mit Beginn der Pandemie die Nutzer­zahlen für andere digitalen Dienst­leistung förmlich explo­diert: 1,4 Millionen Video­sprech­stunden wurden allein im ersten Halbjahr 2020 durch­ge­führt. Im Jahr 2019 waren es dagegen erst knapp 3.000.

Voraus­setzung für eine Teilnahme als Video­di­enst­an­bieter ist die Erfüllung aller Anfor­de­rungen an die techni­schen Verfahren. Die Anfor­de­rungen an Anbieter, Teilnehmer und Vertrags­ärzte wurden in einer entspre­chenden Verein­barung der Kassen­ärzt­lichen Bundes­ver­ei­nigung und des Spitzen­ver­bandes Bund der Kranken­kassen festgelegt.

Unter anderem muss die Kommu­ni­kation zwischen Patient und Arzt bzw. Pflege­kraft durch eine Ende-zu-Ende-Verschlüs­selung gesichert sein und der Video­dienst darf keine schwer­wie­genden Sicher­heits­ri­siken aufweisen. Die nötigen Nachweise und Zerti­fikate zur IT-Sicherheit sind in der Verein­barung im Einzelnen aufge­führt, Vorlagen für die Beschei­ni­gungen und der Frage­bogen mit Prüfkri­terien in der Anlage hinterlegt.

Digitale Gesund­heits­an­wen­dungen: Die App auf Rezept

Deutschland bietet seit 2020 als erstes Land überhaupt digitale Apps auf Rezept. Diese digitalen Gesund­heits­an­wen­dungen (DiGA) sind definiert als Medizin­pro­dukte niedriger Risikoklassen zur Erkennung, Überwa­chung, Behandlung oder Linderung von Krank­heiten oder zur Erkennung, Behandlung, Linderung oder Kompen­sierung von Behin­de­rungen und Verlet­zungen. Die Haupt­funktion muss dabei auf digitalen Funktionen basieren (§ 33a SGB). Voraus­setzung für eine Kosten­über­nahme durch die Kranken­kassen ist die Aufnahme im Verzeichnis des Bundes­in­stituts für Arznei­mittel und Medizin­pro­dukte (BfArM).

Für diese Beantra­gungen wurde ein dreimo­na­tiges Fast-Track-Verfahren aufge­setzt, die entspre­chenden Formulare sind zusammen mit einem Leitfaden über die Website des BfArM abrufbar. Grund­sätz­liche Vorgaben zur Daten­si­cherheit sind in der Digitalen Gesund­heits­an­wen­dungen-Verordnung (§ 4) beschrieben. Dazu gehört u.a. ein Infor­ma­ti­ons­si­cher­heits­ma­nagement-System auf Basis des BSI-Standard 200–2: IT-Grund­schutz-Methodik. Hilfe­stellung bietet zudem die Technische Richt­linie des BSI zu Sicher­heits­an­for­de­rungen an digitale Gesund­heits­an­wen­dungen.

Regulie­rungs­bedarf bei vernetzten Medizinprodukten

Regulie­rungs­bedarf besteht derzeit noch bei netzwerk­fä­higen Medizin­pro­dukten. Anders als bei den rein digitalen Gesund­heits­an­wen­dungen sind Digital­funk­tionen hier meist als Ergän­zungen zur bestehenden medizi­ni­schen Grund­funktion integriert. Daraus ergibt sich ein äußerst breites und hetero­genes Anwen­dungs­spektrum. Zum Teil sind die IT-Sicher­heits­an­for­de­rungen auch schwie­riger zu adres­sieren, denn diese Netzwerk­funk­tionen werden häufig über Dritt­an­bieter zugekauft und sind noch nicht bei allen Unter­nehmen auch in die Quali­täts­si­che­rungs­pro­zesse einge­bunden. Gleichwohl sind sie als Anbieter haftbar.

Grund­le­gende Anfor­de­rungen an Cyber-Sicher­heits­ei­gen­schaften von Medizin­pro­dukten wurden erstmals in der EU-Verordnung 2017/745 über Medizin­pro­dukte definiert, die in Deutschland durch das Medizin­pro­dukt­e­recht-Durch­füh­rungs­gesetz (MPDG) umgesetzt wird. Bei der Umsetzung dieser – recht allgemein gehal­tenen – Vorgaben zur IT-Sicherheit helfen Richt­linien und Verfah­rens­an­lei­tungen wie:

- Guideline der Medical Device Coordi­nation Group
– Leitfaden zur Nutzung des MDS2 (Manufac­turer Disclosure Statement)
– Herstel­ler­emp­fehlung zu Cyber-Sicher­heits­an­for­de­rungen an netzwerk­fähige Medizinprodukte.

Das BSI hat die Cyber­si­cherheit vernetzter Medizin­pro­dukte unter­sucht und in seinem Abschluss­be­richt dazu auch die anste­henden Aufgaben formu­liert. Die Weiter­ent­wicklung der Regula­torik zur IT-Sicherheit bleibt eine wichtige Aufgabe. Es geht neben der IT-Sicherheit bestehender Produkte vor allem auch darum, Innova­tionen zum Durch­bruch zu verhelfen und ihre schnelle und sichere Markt­ein­führung zu fördern.

Autor: Randolf Skerka, SRC GmbH