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

ISB

Zerti­fi­kats­lehrgang „Infor­ma­ti­ons­si­cher­heits­be­auf­tragte (ISB) für Kredit­in­stitute” – 21. bis 24. November 2023

Für den wirtschaft­lichen Erfolg eines Kredit­in­stituts ist eine sichere und effiziente IT unbedingt erfor­derlich. Kredit­in­stitute haben gemäß KWG und MaRisk dafür zu sorgen, dass ihre IT-Systeme und ‑Prozesse die Integrität, Verfüg­barkeit, Authen­ti­zität und Vertrau­lichkeit der Daten sicherstellen.

Mit den „Bankauf­sicht­lichen Anfor­de­rungen an die IT“, die zum 16. August 2021 novel­liert wurden, hat die BaFin ihre Anfor­de­rungen an die Funktion des Infor­ma­ti­ons­si­cher­heits­be­auf­tragten konkre­ti­siert: Diese steuern den Infor­ma­ti­ons­si­cher­heits­prozess, unter­stützen die Geschäfts­leitung bei der Festlegung der Infor­ma­ti­ons­si­cher­heits­leit­linie und erstellen Infor­ma­ti­ons­si­cher­heits­richt­linien. Darüber hinaus sind sie Ansprech­partner für alle Fragen der Infor­ma­ti­ons­si­cherheit – intern und für Dritte.

Nach der großen Resonanz und dem erfolg­reichen Abschluss von nunmehr elf Zerti­fi­kats­lehr­gängen seit 2017 freuen wir uns, Ihnen einen neuen Termin anbieten zu können:

Der viertägige Zertifikatslehrgang

Informationssicherheitsbeauftragte/r (ISB) für Kreditinstitute
vom 21. bis 24. November 2023 in Köln

unter­stützt Sie als (künftige) Informations­sicherheitsbeauftragte oder Stell­ver­treter bei der Erfüllung Ihrer Aufgaben. Sie erhalten einen umfas­senden Einblick in die Aufgaben und Kompe­tenzen des Informations­­sicherheitsbeauftragten, das Thema Informations­sicherheitsmanagement und die diesbe­züg­lichen Risiken sowie alle relevanten gesetzlichen/regulatorischen Anfor­de­rungen. Weitere Schwer­punkte sind die Themen Incident- und Notfall­ma­nagement sowie die Standards ISO 27001 und BSI IT-Grund­schutz. Exkurse aus der Bankpraxis runden die Veran­staltung ab.

Es referieren:
Dr. Anna-Lisa Kofahl
| SRC Security Research & Consulting GmbH
Heinrich Lottmann | TARGOBANK AG
Alexandros Manakos | Apollon Security GmbH
Dagmar Schoppe | SRC Security Research & Consulting GmbH

Als Teilnehmer des Lehrgangs haben Sie die Möglichkeit, das Zerti­fikat „Informationssicherheitsbeauftragte/r für Kredit­in­stitute“ zu erwerben. Voraus­setzung ist die Teilnahme an allen Modulen sowie das Bestehen der webba­sierten Abschluss­prüfung (Multiple Choice) am 27. November. Es fallen keine zusätz­lichen Prüfungs­ge­bühren an.

Profi­tieren Sie bei einer Anmeldung bis spätestens 24. September 2023 von unserem Frühbu­cher­rabatt!

Der Lehrgang setzt Grund­la­gen­wissen zum Thema IT und IT-Sicher­heits­maß­nahmen voraus, welches jedoch im Vorfeld in einem eintä­gigen Seminar erworben werden kann:

Optional: Inten­siv­se­minar „Basis­wissen IT-Grund­lagen und ‑Sicher­heits­maß­nahmen für Nicht-Infor­ma­tiker“ am 20. November 2023

Es referieren:
Florian Schumann | SRC Security Research & Consulting GmbH
Vincent Becker | SRC Security Research & Consulting GmbH

Vermittelt werden hier IT-Begriffe und ‑Grund­lagen; vorge­stellt werden außerdem die grund­le­genden IT-Sicher­heits­maß­nahmen in Netzen / im Rechen­zentrum. Ein weiteres Modul widmet sich speziell den Themen Verschlüs­selung, Signatur, Authen­ti­kation und Integri­täts­si­cherung. Sie bekommen außerdem einen Überblick über neue Techno­logien und Trends (z. B. Big Data, Cloud, Künst­liche Intelligenz).

Feedbacks bishe­riger TeilnehmerInnen:

„Das Seminar war sehr gut! Es hat mir Spaß gemacht und sehr gefallen.“

„Danke für die Organi­sation und die indivi­duelle Ausge­staltung des Lehrgangs – eine profes­sio­nelle Durch­führung und gleich­zeitig viel Austausch und Eingehen auf indivi­duelle Anfor­de­rungen ist in virtu­ellen Zeiten eine große Herausforderung.“

„Sehr angenehmer Mix aus Theorie, Regula­torik und Praxis“

„Vielen Dank, sehr gut geleitete und begleitete Schulung“

Ihre Fragen zum Lehrgang und zum IT-Grund­lagen-Seminar beant­wortet gern Frau Andrea van Kessel (Tel. 0221/5490–161)

Wir freuen uns auf Ihre Teilnahme!

Web-Seite zum Lehrgang

Online-Anmeldung

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

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

 

Technische Sicherheitseinrichtungen

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

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/

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.