Schlagwortarchiv für: IT Sicherheit

Heute geht’s los – der Karrie­retag 2023 mit SRC in Bonn

Heute ist der große Tag! Wir sind aufgeregt, Dich als Studenten und Absol­venten am Karrie­retag 2023 in Bonn begrüßen zu dürfen. Die SRC GmbH freut sich darauf, Dich an unserem Stand zu treffen und über aufre­gende Karrie­re­mög­lich­keiten in der IT-Sicherheit zu sprechen.

Entdecke die Welt der Cybersecurity

Unsere Experten stehen bereit, um Dir einen Einblick in die Welt der IT-Sicherheit zu geben. Von mobilen Bezahl­me­thoden bis hin zu künst­licher Intel­ligenz und kriti­schen Infra­struk­turen – wir zeigen Dir, wie spannend die IT sein kann.

Unsere Kollegen vor Ort

Am Stand der SRC GmbH wirst Du auf einige unserer talen­tierten Kollegen treffen:

  • Randolf Skerka, Business Develo­pment: Randolf ist der Experte in Sachen Geschäfts­ent­wicklung. Er kennt die neuesten Trends und Chancen in der IT-Branche.
  • Oliver Borcherding, Sales Team: Oliver steht bereit, um Dir alles über unsere Vertriebs­stra­tegien und ‑möglich­keiten zu erzählen.
  • Janina Walgenbach, Fachbe­reich PCI: Janina ist unsere Fachex­pertin und kann Dir Einblicke in die komplexen Themen­felder der IT-Sicherheit bieten.
  • Mustafa Tarik, Pentester: Mustafa bringt praktische Erfahrung mit und kann direkt aus erster Hand über seine Arbeit als Pentester berichten.
  • Stefanie Rader­macher, HR: Stefanie ist unser Ansprech­partner für alle Fragen rund um Karrie­re­chancen und Bewer­bungs­pro­zesse bei SRC.

Egal, welchen Bereich der IT Dich inter­es­siert, unsere Kollegen haben die Antworten auf Deine Fragen und freuen sich darauf, mit Dir zu sprechen.

SRC auf dem Karrie­retag 2023 in Bonn: Dein Sprung­brett zur IT-Karriere

Verpass nicht die Chance, Teil dieses aufre­genden Tages zu sein. Besuche uns am Karrie­retag 2023 in Bonn und lass Dich inspirieren

Karrie­retag 2023 – SRC ist wieder dabei!

Der Karrie­retag 2023 in Bonn  – Die Karrie­re­messe für Studie­rende und Berufseinsteiger

Das Ende des Studiums ist ersichtlich. Der Abschluss in greif­barer Nähe. Spätestens jetzt benötigen Studie­rende und Absol­venten Kontakt zu einem poten­ti­ellen, zukünf­tigen Arbeit­geber. SRC freut sich auf diesen Kontakt: Der Karrie­retag 2023 in Bonn ist der perfekte erste Einstieg dazu.

Die Jobmesse wird mit vielen Angeboten rund um das Thema Karriere und Karrie­re­planung abgerundet. Dazu gehören z.B. Vorträge, Workshops, Jobboards und vieles mehr.

Karriere in der IT – SRC gewährt einen Einblick in spannende Aufgabenbereiche

SRC gibt Studie­renden und Absol­venten auch auf dem Karrie­retag 2023 die Möglichkeit, einen Einblick in und den Austausch über die vielfäl­tigen Themen­felder der IT-Sicherheit zu nehmen. Die SRC-Experten erläutern den Alltag und die Heraus­for­de­rungen bei der Begut­achtung sicher­heits­re­le­vanter IT-Techno­logien. Eine Auswahl aktueller Themen sind z. B. mobile Bezahl­me­thoden, künst­liche Intel­ligenz und kritische Infra­struk­turen. Von unseren neuen Kollegen erwarten wir einen ausge­prägten Instinkt für poten­zielle Fehler­quellen in komplexen Techno­logien, die Kompetenz zur Findung von Lösungen und das Durch­set­zungs­ver­mögen, das Ergebnis ihrer Arbeit gegenüber den Auftrag­gebern zu vertreten.

Aktuelle Stellen­an­gebote auf unserem Karriereportal

Ob als Werkstu­die­rende in unserem Kunden­ma­nagement oder als Scanworker im Pentestteam – vielfältige und spannende Aufgaben neben dem Studium erledigen ist bei uns kein Problem. Aber auch Absol­venten kommen bei uns auf ihre Kosten – Wir suchen Pentester, Beratende und Analytiker/innen für verschiedene Bereiche in unserem Unternehmen.

Gerne können sich Studie­rende und Absol­venten bereits vorab auf unserem Karrie­re­portal über offene Stellen­an­gebote in unserem Unter­nehmen infor­mieren. Wir stehen gerne für Rückfragen am Unter­neh­menstag zur Verfügung! Außerdem besteht die Möglichkeit, uns Bewer­bungs­un­ter­lagen direkt vor Ort zu überreichen.

Mehr Infor­ma­tionen zum Karrie­retag 2023 in Bonn gibt es hier.

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

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

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

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

Nutzen Sie gerne unsere Angebote:

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

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

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

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

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

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

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

Kontakt: Frau Jana Ehlers per E‑Mail

Wie sicher ist die elektro­nische Patientenakte?

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

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

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

Die elektro­nische Patientenakte

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

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

Verschlüs­selung der Akteninhalte

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

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

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

Berech­ti­gungs­ma­nagement

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

Fazit

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

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

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

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.

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

Opera­tional Resilience – Anfor­de­rungen an die Cyber-Wider­stands­fä­higkeit von Instituten

Aktuelle Schwer­punkt­themen: Opera­tional Resilience und Cybersicherheit

Angriffe auf das Finanz­system können schwer­wie­gende Folgen haben – nicht nur für das betroffene Unter­nehmen, sondern auch für die gesamte Öffent­lichkeit. Auch Experten der Bundesbank, Sicher­heits­experten der BaFin und der EZB nennen Cyber-Angriffe bzw. die fehlende Wider­stands­fä­higkeit gegen ebensolche als größte Gefahr, die sich aus der zuneh­menden Digita­li­sierung im Finanz­sektors ergibt. Nicht zuletzt aus diesem Grund werden verstärkt gesetz­liche und regula­to­rische Rahmen­be­din­gungen geschaffen, um im gesamten Finanz­sektor europaweit einheit­liche Standrads zu schaffen und die „Opera­tional Resilience“ zu erhöhen.

Sowohl für die EZB als auch für die BaFin stand das Jahr 2020  unter dem Schwer­punkt „Opera­tional Resilience“ und „Cyber­si­cherheit“. Zudem wurde auf europäi­scher Ebene das TIBER-EU-Programm ins Leben gerufen, das die Bundesbank als TIBER-DE im September 2020 umgesetzt hat. Daneben veröf­fent­lichte die EU im Oktober 2020 im Rahmen des Digital Finance Package mit DORA (Digital Opera­tional Resilience Act) ihre Anfor­de­rungen an Betriebs­sta­bi­lität und Cybersicherheit.

Für die Verant­wort­lichen stellt sich die Frage, wie diese verschie­denen Aktivi­täten zusam­men­spielen und – noch viel relevanter – wie effizient diese zur Zieler­rei­chung beitragen.

Novel­lierung MaRisk und BAIT – Operative IT-Sicherheit

Auf natio­naler Ebene veröf­fent­lichte die BaFin im Oktober letzten Jahres mit der  Novel­lierung von MaRisk und BAIT ihre Ansätze zur Adres­sierung von opera­tiven IT-Risiken. Die Bedeutung des Themas wird ersichtlich in der Erwei­terung der BAIT-Anfor­de­rungen im Rahmen eines neuen Kapitels. Die Umsetzung der dort formu­lierten konkreten Anfor­de­rungen stellen kleinere und mittlere Institute wahrscheinlich vor große Heraus­for­de­rungen, da sie auf den Betrieb eines Security Infor­mation and Event Management Systems (SIEM), der Einrichtung und den Betrieb eines Security Opera­tions Centers (SOC) sowie regel­mäßige interne Abwei­chungs­ana­lysen, Schwach­stel­len­scans, Penetra­ti­ons­tests und die Simulation von Angriffen („Red Teaming“) abzielen. Praktisch erfordert dies den Aufbau einer profes­sio­nellen Cyber-Security-Abteilung sowie unabhän­giger interner Infor­ma­ti­ons­si­cher­heits­struk­turen. Dies wird die betrof­fenen Institute schon allein aufgrund des erfor­der­lichen Know-hows und der begrenzten Ressourcen auf dem Arbeits­markt vor große Heraus­for­de­rungen stellen. Als weiterer Schwer­punkt wird das Notfall­ma­nagement – ebenfalls in einem eigenen neuen Kapitel in den BAIT – adressiert.

Das TIBER-Programm von EZB und Bundesbank

Bereits im Jahr 2018 haben die Noten­banken des Europäi­schen Systems der Zentral­banken das Programm TIBER-EU (Threat Intel­li­gence-based Ethical Red Teaming) ins Leben gerufen. TIBER-EU dient als Rahmenwerk zu bedro­hungs­ge­lei­teten Penetra­ti­ons­tests, mit dem die Finanz­un­ter­nehmen die eigene Wider­stands­fä­higkeit gegen Cyber­at­tacken auf den Prüfstand stellen können. Es wird hier ein „Goldstandard“ der Penetra­ti­ons­tests angestrebt. Die deutliche Zurück­haltung bei der Teilnahme an TIBER-DE lässt sich zum einen durch den aufwän­digen Projekt­umfang, die nicht unwesent­lichen Risiken und zuletzt auch durch die „Freiwil­ligkeit“ der Teilnahme erklären. Natürlich sind gerade im Jahr 2020 auch aufgrund der Covid-Pandemie viele interne Kräfte ander­weitig gebunden. Es stellt sich die Frage, ob die Institute das Risiko eines Cyber-Angriffs subjektiv genauso kritisch wahrnehmen.

Digital Opera­tional Resilience Act (DORA) der EU

Die Veröf­fent­li­chung des Digital Finance Package enthält mit dem EU regulatory framework on digital opera­tional resilience  einen umfas­senden Legis­la­tiv­vor­schlag zur europa­weiten Prävention und Reduktion von Cyber-Risiken. Bisher existieren nationale Regelungen für die Betriebs­sta­bi­lität, die aller­dings dem grenz­über­schrei­tenden und globalen Einsatz von IT-Systemen nicht gerecht werden und daher auch wenig wirksam sind. Zudem birgt diese Fragmen­tierung auch die Gefahr der Inkon­sis­tenzen und ist zudem mit zusätz­lichen hohen Aufwänden für europaweit agierende Institute verbunden.

Hier ist es also sehr wünschenswert, mit DORA einheit­liche Regelungen, insbe­sondere zum Risiko­ma­nagement, Testen, Ausla­gerung Notfall- und Incident-Management, anzustreben. Neben der Verbes­serung und Optimierung der Wider­stands­fä­higkeit der einge­setzten IT-Systemen wird hier sicherlich auch ein signi­fikant vermin­derter Verwal­tungs­aufwand auf Seiten der Institute zu beobachten sein.

Gemeinsam die Cyber-Wider­stands­fä­higkeit erhöhen

Gerne tauschen sich die SRC-Experten mit Ihnen zu den Neuerungen sowie deren Auswir­kungen auf gesetz­licher und regula­to­ri­scher Ebene aus. Gemeinsam analy­sieren wir Ihren Handlungs­bedarf und unter­stützen Sie bei der Umsetzung. Wir bewerten die Novel­lierung MaRisk und BAIT für Ihr Institut, unter­stützen bei der Vorbe­reitung, Durch­führung und Analyse von TIBER-Tests und analy­sieren die geplanten Anfor­de­rungen aus DORA. Dabei können Sie auf unserer Erfahrung aus unzäh­ligen Penetra­ti­ons­tests, Banken-Compliance- und Infor­ma­ti­ons­si­cher­heits­ma­nagement-Projekten zurückgreifen.

20 Jahre SRC

20 Jahre SRC

Vor 20 Jahren, am 27. November 2000 fand die Gründungs­ver­sammlung der Gesell­schafter der SRC statt. Das ist eine lange Zeit, aber in der Rückschau betrachtet kommt es den handelnden Personen nicht so vor. Diese Wahrnehmung ist natürlich subjektiv, aber ein entschei­dender Faktor hierfür wird sicherlich die rasante Entwicklung im Bereich der Infor­ma­ti­ons­technik sein.

Die Komple­xität der Digita­li­sierung und der stetig wachsende Bedarf, Vertrauen in neue Lösungen zu schaffen, ist die Geschäfts­grundlage von SRC, der wesent­liche Grund, warum es SRC gibt. Gleich­zeitig ist dies auch eine große Verpflichtung – nämlich dafür zu sorgen, dass neue digitale Lösungen auch wirklich vertrau­ens­würdig sind.

Anschaulich lässt sich die Arbeit der SRC an solchen Dingen erläutern, die viele Menschen im täglichen Leben erleben. Dies sind allem voran das kontaktlose Bezahlen mit Karte und Handy, der sichere Zugriff auf Bankkonten durch Dritte, die elektro­nische Patien­tenakte, die sichere Kommu­ni­kation im Zusam­menhang mit dem Galileo-System und in der Bundeswehr oder auch ganz „profane“ Dinge wie Flaschen­pfand­au­to­maten oder manipu­la­ti­ons­si­chere Regis­trier­kassen – alles Themen der Digita­li­sierung, mit denen Tag für Tag Millionen Menschen in der ein oder anderen Art in Berührung kommen. Die Entwicklung ist damit nicht zu Ende, mit Open Finance, IoT und der verstärkten Nutzung von KI-Methoden stehen noch viele spannende Themen an.

Keine dieser Lösungen wurde von SRC selbst herge­stellt oder wird von SRC betrieben, aber wir haben bei allen einen ganz entschei­denden Beitrag geleistet: Wir sorgen für Vertrauen in diese digitale Lösungen – für Zuver­läs­sigkeit, Sicherheit und Zukunfts­si­cherheit. Wir schaffen „ein gutes Gefühl“ im Umgang mit der Digitalisierung:

  • Standards für neue Techno­logien schaffen Investitionssicherheit,
  • Zuver­lässige Funktio­na­lität neuer Lösungen durch Testen
  • Technische Sicherheit neuer Lösungen durch Sicher­heits­kon­zepte und –prüfungen.

Tatsächlich ist es so, dass dieses „gute Gefühl“, das Vertrauen, so etwas wie der Schmier­stoff der Digita­li­sierung ist. Denn mit der Digita­li­sierung und Techni­sierung des Alltags geht für viele Menschen einher, dass Prozesse nicht mehr überschaubar sind und der Wahrheits­gehalt von Infor­ma­tionen manchmal unklar ist. Vertrauen ermög­licht es, diese Komple­xität zu reduzieren und eröffnet häufig erst die Akzeptanz der mit der Digita­li­sierung angestrebten neuen Möglich­keiten des Erlebens und Handelns.

Die Komple­xität der Digita­li­sierung und der stetig wachsende Bedarf, Vertrauen in neue Lösungen zu schaffen, ist die Geschäfts­grundlage von SRC, der wesent­liche Grund, warum es SRC gibt. Gleich­zeitig ist dies auch eine große Verpflichtung – nämlich dafür zu sorgen, dass neue digitale Lösungen auch wirklich vertrau­ens­würdig sind.

In den 20 Jahren seit Bestehen der SRC haben wir mehr als 20.000 Projekte durch­ge­führt. Jedes Jahr wurden es mehr und auch SRC ist Jahr für Jahr gewachsen – nicht nur bezüglich der Anzahl der Mitar­beiter, sondern ganz besonders bei der Erwei­terung der Expertise, teilweise auf Gebieten, die es zum Zeitpunkt der Gründung der SRC noch nicht gab.

Die gegen­wärtige Pandemie-Situation erlaubt es nicht, das 20jährige Bestehen angemessen feiern zu können, was wir gerne gemeinsam mit unseren Kunden gemacht hätten. Wir denken darüber nach, dies zu einem geeig­neten Zeitpunkt nachzu­holen. Aber auch ohne Party würden wir uns freuen, wenn Sie uns als unsere Kunden auch weiterhin Ihr Vertrauen schenken.

TIBER-DE

TIBER-DE | Stärkung der Cyber­wi­der­stands­fä­higkeit des Finanzsystems?

Digita­li­sierung des Finanz­sektors | Chancen & Cyber­ri­siken | TIBER-DE

Die zuneh­mende Digita­li­sierung des Finanz­sektors sorgt nicht nur für neue Möglich­keiten, sondern bringt auch erhöhte Cyber­ri­siken mit sich. Insbe­sondere können Angriffe auf das Finanz­system schwer­wie­gende Folgen nicht nur für das betroffene Unter­nehmen, sondern auch für die gesamte Öffent­lichkeit haben. Bereits im Jahr 2018 haben daher die Noten­banken des Europäi­schen Systems der Zentral­banken das Programm TIBER-EU (Threat Intel­li­gence-based Ethical Red Teaming) ins Leben gerufen. TIBER-EU dient als Rahmenwerk zu bedro­hungs­ge­lei­teten Penetrationstests.

Im Sommer 2019 beschlossen die Deutsche Bundesbank und das Bundes­mi­nis­terium der Finanzen (BMF) mit TIBER-DE die nationale Umsetzung dieses Rahmen­werkes, mit dem die Finanz­un­ter­nehmen die eigene Wider­stands­fä­higkeit gegen Cyber­at­tacken auf den Prüfstand stellen können. Diese Umsetzung ist nunmehr erfolgt.

An wen richtet sich TIBER-DE?

TIBER-DE richtet sich insbe­sondere an kritische Unter­nehmen des Finanz­sektors, wie z.B. große Banken und Versi­cherer sowie deren IT-Dienst­leister und Zahlungs­dienst­leister. Die Deutsche Bundesbank stellt in ihrer TIBER-Imple­men­tierung heraus, dass die Durch­führung von TIBER-DE Tests dazu dient, „ein Netzwerk der natio­nalen, zur Zielgruppe gehörenden Unter­nehmen zu etablieren, um gemeinsam und mithilfe der Durch­führung von TIBER-DE-Tests die Cyber­wi­der­stands­fä­higkeit des Finanz­sektors nachhaltig und auf koope­ra­tiver Basis zu verbessern“.

Was passiert in einem Test?

In einem TIBER-DE Test überprüfen beauf­tragte Hacker („Red Team“) basierend auf Infor­ma­tionen eines Threat Intel­li­gence Providers („Spion“) die Cyber­wi­der­stands­fä­higkeit eines Unter­nehmens. Primäres Ziel hierbei ist die Identi­fi­kation von Sicher­heits­lücken in den Produk­tiv­sys­temen („critical functions“) im Rahmen eines möglichst realen Angriffs­sze­narios. Der TIBER-DE Test besteht aus drei Phasen, welche hier verkürzt darge­stellt werden:

  • In der Vorbe­rei­tungs­phase erfolgt die Initi­ierung, der Kick-Off, die Bestimmung des Testum­fangs und die Beschaffung. Insbe­sondere werden hier die entspre­chenden Verträge mit allen Betei­ligten geschlossen, der Testumfang festgelegt und die Finanz­auf­sicht über den beabsich­tigten TIBER-DE Test informiert.
  • In der Testphase werden Infor­ma­tionen zur Bedro­hungslage gesammelt und der Red Team Penetra­ti­onstest auf der Grundlage des zuvor festge­legten Testum­fangs durchgeführt.
  • Schließlich umfasst die Abschluss­phase die Erstellung der Testbe­richte, ein Replay und Feedback, einen Behebungsplan für gefundene Schwach­stellen sowie einen Abschluss­be­richt und die Attes­tierung inklusive Ergebnisweitergabe.

Risiken des Tests

Der TIBER-DE Test zielt auf die Produk­tiv­systeme mit den „critical functions“ eines Instituts, um deren Cyber­wi­der­stands­fä­higkeit realis­tisch bewerten zu können. Damit einher gehen jedoch auch Risiken, z.B. bezüglich der Vertrau­lichkeit, Integrität oder Verfüg­barkeit der Daten bzw. Systeme. In jedem Falle muss das Institut vor der Durch­führung eines Tests eine detail­lierte Risiko­analyse durch­führen und angemessene Maßnahmen zur Risiko­mi­ni­mierung treffen.

Darüber hinaus werden die Unter­nehmen vor organi­sa­to­rische, technische und daten­schutz­be­dingte Heraus­for­de­rungen gestellt. Kritische Geschäfts­pro­zesse müssen identi­fi­ziert werden, Abwehr­maß­nahmen müssen etabliert und dokumen­tiert. Zudem müssen TIBER-DE Tests mit den verschie­denen betrof­fenen Stake­holdern, z. B. Dienst­leistern, koordi­niert werden. Darüber hinaus muss eine Geheim­hal­tungs­pflicht auf allen Seiten einge­halten werden.

Derzeit beruht die Teilnahme an diesen Tests auf freiwil­liger Basis. Zusammen mit den nicht unbeacht­lichen Risiken scheint dies der Grund für die Zurück­haltung bei der Bereit­schaft zur Durch­führung eines TIBER-DE Tests zu sein.

Gemeinsam zum erfolg­reichen TIBER-DE Test

Die Experten von SRC können gemeinsam mit Ihnen einen TIBER-Test vorbe­reiten. Dazu gehört das unter­neh­mens­weite Scoping der zu testenden kriti­schen Geschäfts­pro­zesse und Unter­stützung bei der Etablierung von konformen Melde­wegen und ‑Prozessen zur Steuerung und Durch­führung von TIBER-Tests. Damit sind die internen Vorbe­rei­tungen getroffen, um einen TIBER-konformen Penetra­ti­onstest über einen Dienst­leister durch­führen zu lassen. Mit der Erfahrung aus unzäh­ligen Penetra­ti­ons­tests, Banken-Compliance- und Infor­ma­ti­ons­si­cher­heits­ma­nagement-Projekten unter­stützen wir Sie gerne durch den gesamten Verfah­rens­ablauf eines TIBER-Tests.

Novellierung der BAIT 2021

Novel­lierung der BAIT 2021– Die neuen Anfor­de­rungen an Kreditinstitute

Die Novel­lierung der BAIT für 2021 bedeutet neue Anfor­de­rungen für Kredit­in­stitute. Dagegen steht die BaFin vor der Heraus­for­derung, die Guide­lines on security measures for opera­tional and security risks under the PSD2 und die Guide­lines on ICT and security risk management der EBA in Deutschland umzusetzen. Das soll mit einer Novel­lierung der BAIT (Bankauf­sicht­liche Anfor­de­rungen an die IT) bis zum 31. Dezember 2020 abgeschlossen sein. Erste Entwürfe wurden bereits in den Insti­tuten und Verbänden disku­tiert und kommentiert.

BAIT 2021 rückt IT-Sicherheit in den Mittelpunkt

Mit einem eigenen und neuen Kapitel rückt die operative IT-Sicherheit weiter in den Mittel­punkt. Die dort formu­lierten Anfor­de­rungen sind nur mit einem Security Infor­mation and Event Management Systems (SIEM) zu erfüllen. Das umfasst auch die Einrichtung und den Betrieb eines Security Opera­tions Centers (SOC). Operativ sind regel­mäßige Überprü­fungen gefordert. Dazu gehören:

  • interne Abwei­chungs­ana­lysen
  • Schwach­stel­len­scans
  • Penetra­ti­ons­tests
  • die Simulation von Angriffen („Red Teaming“)

Die neuen Anfor­de­rungen der BAIT 2021 münden im Aufbau einer profes­sio­nellen Cyber-Security-Infra­struktur. Das bedeutet umfang­reiche und von einander unabhängige interne Informationssicherheitsstrukturen.

Die Geschäfts­leitung übernimmt die Gesamtverantwortung

Es fällt auf, dass schon der Entwurf nicht nur auf die Verant­wort­lichkeit der Geschäfts­leitung verweist. Der Geschäfts­leitung wird sogar die explizite Anerkenntnis der Gesamt­ver­ant­wortung für die Infor­ma­ti­ons­si­cherheit abver­langt. Dazu gehören auch die regel­mäßige Infor­mation über deren Belange und die Entscheidung zum angemes­senen Umgang mit Sicherheitsrisiken.

Anfor­de­rungen an das IT-Notfall­ma­nagement werden konsolidiert

Weitere Änderungen erwarten wir im Bereich IT-Notfall­ma­nagement. Die Anfor­de­rungen aus der BAIT werden mit denen aus Abschnitt AT7.3 der MaRisk konso­li­diert. So entstehen einheit­liche nationale Vorgaben. Außerdem rechnen wir mit einer Verschärfung und Präzi­sierung der Vorgaben hinsichtlich der Notfall­planung und –vorsorge, BCM, Desaster Recovery sowie die Backup­stra­tegien. Auch das Outsourcing an Dienst­leister wird aus unserer Sicht Gegen­stand der Neufassung sein.

Kredit­in­stitute stehen vor großen Herausforderungen

Nach Einschätzung der SRC-Experten für Banken Compliance werden die zu erwar­tenden Änderungen die betrof­fenen Institute vor große Heraus­for­de­rungen stellen. Das betrifft insbe­sondere das erfor­der­liche Know-how und die begrenzten Ressourcen auf dem Arbeitsmarkt.