FDA Cybersecurity Leitfaden für die Zulassung

Goran Madzar

03/15/2021

Wer ein Medizinprodukt in der USA zulassen will, kommt an der Food and Drug Administration (FDA – Behörde für Zulassung von Medizinprodukten in der USA) nicht vorbei. Medizinprodukte werden immer vernetzter und erfassen zunehmend mehr Daten. Dabei bleibt es nicht aus, dass Medizinprodukte Ziel von Angreifern werden. Um dem zu begegnen, hat die FDA das Guidance Dokument Content of Premarket Submissions for Management of Cybersecurity in Medical Devices herausgegeben. In diesem Beitrag möchte ich auf diesen Leitfaden eingehen und die wesentlichen Aspekte vorstellen. Wichtige Fachbegriffe werden hier in englischer Sprache genannt, da es für viele Begriffe in der deutschen Sprache keine richtige Entsprechung gibt. Das fängt schon bei den Begriffen „Safety“ und „Security“ an. Beides kann man im Deutschen mit „Sicherheit“ übersetzen.  Dabei meint „Safety“ die funktionale Sicherheit, also den Schutz des Menschen vor der Maschine, während die „Security“ die Sicherheit vor Angriffen von außen, also den Schutz der Maschine, der Umgebung oder des Menschen vor anderen Menschen, betrachtet.

Wen betrifft die Guideline?

In erster Hinsicht betrifft die Guideline alle Medizinprodukte-Hersteller, die eine Zulassung für ein Produkt in den USA anstreben. Das gilt für die Premarket Notification (510k), De Novo requests, Premarket Approval Application (PMAs), Product Development Protocols (PDPs) und Humanitarian Device Exemption (HDE).

Die FDA weist darauf hin, dass es eine gemeinsame Verantwortung für die Cybersecurity gibt, die durch die Gesundheitseinrichtungen, Patienten, Gesundheitsdienstleister und Hersteller von medizinischen Geräten geteilt werden muss. Den Herstellern soll durch die Richtlinie eine Hilfestellung gegeben werden, um folgende Aspekte zu berücksichtigen:

  1. Risikobasierter Ansatz, um Medizinprodukte mit angemessenen Cybersecurity-Schutzmaßnahmen zu entwickeln.
  2. Ganzheitlicher Ansatz für die Cybersecurity von Geräten, indem Risiken und Maßnahmen während des gesamten Produktlebenszyklus bewertet werden.
  3. Gewährleistung der Wartung und Kontinuität der Sicherheit kritischer Geräte und der wesentlichen Leistungsmerkmale und
  4. Förderung der Entwicklung vertrauenswürdiger, wirksamer und sicherer Geräte.

Aus meiner Sicht ist die Richtlinie aber auch für Hersteller sinnvoll, die keine FDA-Zulassung anstreben, da sie einen guten Leitfaden darstellt, wie man mit dem Thema Cybersecurity umgehen soll.

Ihr Ansprechpartner:

Dipl.-Ing. Goran Madzar, Gesellschafter, Senior Systems Engineer 
E-Mail: madzar@medtech-ingenieur.de
Tel.:  +49 9131 691 240
 

Benötigen Sie Unterstützung bei der Entwicklung Ihres Medizingeräts? Wir helfen gerne! Die MEDtech Ingenieur GmbH bietet Hardware-Entwicklung, Software-Entwicklung, Systems Engineering, Mechanik-Entwicklung und Beratung aus einer Hand. Nehmen Sie Kontakt mit uns auf.

Kontakt aufnehmen

Der risikobasierte Ansatz

Bei dem risikobasierten Ansatz geht es darum, einen Prozess zu durchlaufen, um die Cybersecurity des Medizinproduktes zu verbessern. Der Prozess besteht aus den folgenden Schritten:

  • Identifikation von Assets (Werte), Threats (Gefährdungen) und Vulnerabilites (Schwachstellen).
  • Bewertung der Auswirkungen von Bedrohungen und Schwachstellen auf die Gerätefunktionalität.
  • Einschätzung der Wahrscheinlichkeit, dass eine Bedrohung und eine Sicherheitslücke ausgenutzt werden.
  • Bestimmung des Risikograds und geeigneter Maßnahmen.
  • Bewertung des Restrisikos und der Risikoakzeptanzkriterien.

Dabei ist nicht jedes Gerät gleich zu betrachten. Medizinprodukte die vernetzter sind (Ethernet, WiFi, USB, Bluetooth oder ähnliches) sind natürlich verwundbarer als Systeme, die keine entsprechenden Schnittstellen besitzen. Die FDA schlägt hier zwei Stufen von Geräten vor. Geräte mit hohem Risiko für Cybersecurity (Tier 1) und Geräte mit normalem Risiko (Tier 2).

FDA Cybersecurity Klassifizierung
Stufen von Geräten

Die Cybersecurity-Klassifizierung hängt dabei nicht mit der Produkt-Klassifizierung zusammen. So kann es z.B. ein Medizinprodukt der Klasse II (z.B. Infusionspumpe) geben, das der höheren Klassifizierung Tier 1 entspricht, während ein Klasse III Produkt (z.B. Herzschrittmacher) ohne Konnektivität Tier 2 entsprechen kann. Maßgeblich ist der in der Abbildung oben beschriebene Entscheidungsprozess.

Produkte, die der Klasse Tier 1 entsprechen, haben dabei strengere Regelungen an die Dokumentation. Für diese Produkte sind alle Empfehlungen der Richtlinie zu befolgen. Für Produkte der Klasse Tier 2 können einzelne Empfehlungen ausgelassen werden, wenn dafür eine risikobasierte Begründung vorliegt.

Wie können sich Geräte vor Angriffen schützen?

In der Übersicht unten sehen sie eine Checkliste von Maßnahmen, die sie bei der Entwicklung von Geräten berücksichtigen sollten. All diese Punkte stammen aus der FDA Richtlinie. An dieser Stelle sollen die Punkte in Kürze gezeigt werden, damit Sie einen Überblick bekommen.

  • Nicht autorisierte Zugriffe verhindern
    • Zugangsbeschränkungen für vertrauenswürdige Benutzer und Geräte
      • Zugangsbeschränkung durch Benutzer ID, Passwort, Smartcard oder biometrisch.
      • Automatische Abmeldung des Nutzers nach einem Timeout, sofern sinnvoll.
      • Verwendung unterschiedlicher Zugriffsrechte
      • Authentifizierung für Administratoren oder Service Mitarbeiter
      • Starke Passwörter. Nicht fest einprogrammiert, einfach zu erraten, Default-Passwort, Selbes Passwort für alle Geräte, nicht änderbare Passwörter, schwierig zu ändernden Passwörter, öffentlich zugängliche Passwörter.
      • Physische Sperren, um Manipulation von Kommunikationsschnittstellen zu reduzieren.
    • Authentifizierung und Prüfung sicherheitskritischer Kommandos
      • Benutzung einer Authentifizierung, um nicht autorisierten Zugang zu Gerätefunktionen zu verhindern.
      • Benutzer Authentifizierung vor der Freigabe von Software-Updates inklusive Betriebssystem, Anwendungen oder Anti-Malware Software.
      • Verwendung einer kryptografisch starken Authentifizierung, die auf dem Gerät gespeichert ist.
      • Authentifizierung aller externen Geräte (z.B. eine Verbindung zu einem Server).
      • Authentifizierung von Firmware und Software (Signaturen, Nachrichten-Authentifizierung, Versionsnummer oder andere Metadaten). Geräte sollen elektronisch identifizierbar sein.
      • Die Authentifizierung soll auf Grundlage von Zugangsdaten oder anderen Möglichkeiten erfolgen, die nicht durch andere Geräte ausgelöst werden können.
      • Das Gerät soll nach der Richtlinie „Deny by default“ (Standardmäßig verweigern) realisiert werden. Was nicht explizit erlaubt ist, soll erst einmal verboten sein. So sollen z.B. alle unautorisierten Verbindungen (TCP, USB, Bluetooth, serielle Schnittstellen) abgelehnt werden.
      • So wendig Rechte wie notwendig gewähren.
  • Sicherstellen von verlässlichem Inhalt
    • Code Integrität
      • Nur Software-Updates zulassen, die kryptografisch überprüft sind. Downgrades verhindern.
      • Wo das möglich ist, Software Integrität vor der Ausführung überprüfen (z.B. durch digitale Signaturen).
    • Daten Integrität
      • Eingehende Daten auf Integrität prüfen.
      • Sichere Datenübertragung zum Gerät und vom Gerät und wenn sinnvoll Punkt zu Punkt Verschlüsselung.
      • Schutz der Integrität der Daten, die für die funktionale Sicherheit und wesentlichen Leistungsmerkmale notwendig sind.
      • Ausreichend starke Verschlüsselung nach Stand der Technik.
      • Gerätespezifische Verschlüsselung, damit beim Verlust eines Schlüssels nicht alle Geräte betroffen sind.
    • Ausführungsintegrität
      • Wo machbar, soll man die Best Practices nutzen, um die Integrität des Codes während der Ausführung überprüfen.
Hinweis: Security Anforderungen können im Widerspruch zu Safety Anforderungen stehen! So kann z.B. eine Authentifizierung zu einer Verzögerung der Behandlung führen, die nicht akzeptabel ist. In diesen Fällen gilt es zwischen Safety und Security abzuwägen und die Entscheidung zu dokumentieren.

Die Richtlinie erwähnt auch auf die Vertraulichkeit der Daten, wobei dieses Thema nicht explizit behandelt wird. Als Hersteller muss man sich Gedanken über den Schutz der Patientendaten machen. Hier gilt z.B. die DSGVO und andere Richtlinien und Gesetze.

Wie können Geräte mit Angriffen umgehen?

Cybersecurity Angriffe sollen natürlich möglichst verhindert werden. Doch falls es trotzdem zu einem Vorfall kommt, so ist es notwendig einen Angriff zu erkennen, zu melden und den Schaden möglichst wieder rückgängig zu machen. Dafür sollen die nachfolgenden Punkte beachtet werden.

  • Design der Geräte damit ein Cybersecurity Angriff zeitnah erkannt wird.
    • Das Gerät soll Angriffe, während dem Betrieb erkennen und mit Zeitstempel protokollieren.
    • Das Gerät soll es ermöglichen, dass Routine Checks und Antivirus Scans durchgeführt werden können, ohne sich auf die wesentlichen Leistungsmerkmale des Gerätes auszuwirken.
    • Das Gerät soll Protokolle mit Cybersecurity-relevanten Ereignissen anlegen und speichern können. Wichtig ist die Dokumentation wie und wo die Daten gespeichert oder archiviert und ausgewertet werden sollen.
    • Das Gerät soll sichere Konfigurationen spezifizieren, die mögliche Schwachstellen so weit wie möglich begrenzen.
    • Das Gerät soll so gestaltet sein, dass es das Konfigurationsmanagement unterstützt. So soll es für den autorisierten Nutzer möglich sein, Software Änderungen nachvollziehen zu können.
    • Der Produktlebenszyklus soll es erleichtern die Schwachstellen über verschiedene Produktlinien und Produktvarianten zu analysieren.
    • Das Gerät soll eine CBOM (Cyber Security Bill of Material) in einer elektronische maschinenlesbaren Form besitzen. Mehr dazu weiter unten im Blog-Beitrag.
  • Design der Geräte damit ein Cybersecurity-Angriff gemeldet und die Auswirkungen eines Angriffs bewertet werden können.
    • Das Gerät soll den Benutzer nach einem potenziellen Angriff benachrichtigen.
    • Das Gerät soll so realisiert sein, dass zukünftige Software Patches und Updates eingespielt werden können, um Schwachstellen zu beseitigen.
    • Es soll möglich sein, Patches und Updates zügig zu verifizieren und validieren.
    • Die Architektur muss es erleichtern, dass zügig Patches und Updates aufgespielt werden können.
  • Design der Geräte damit Funktionalitäten schnell wieder hergestellt werden.
    • Kritische Funktionalitäten möglichst so realisieren, dass selbst bei einer Kompromittierung des Gerätes, diese nicht betroffen sind.
    • Durch einen Benutzer mit besonderen Rechten, soll es möglich sein, Gerätekonfigurationen wieder herzustellen.
    • Es ist zu spezifizieren, wie autonom das Gerät bei Ausfall von Kommunikation weiterarbeiten kann (Resilienz).
    • Das Gerät soll resilient gegen mögliche Angriffe wie Netzwerkausfälle, Denial-of-Service Angriffe, exzessive Bandbreitennutzung, Jitter oder andere Störungen sein.

Was ist bei dem Labeling zu berücksichtigen?

Auch durch das Informieren des End-Anwenders kann die Security verbessert und damit das Risiko für Angriffe reduziert werden. Folgende Punkte nenn hierbei die FDA Richtlinie:

  1. Anweisungen im Hinblick auf Maßnahmen zur Verbesserung der Cybersecurity bei Nutzung des Produktes (z. B. Verwendung von Anti-Virus Software oder einer Firewall).
  2. Eine Beschreibung der Features, die auch im Falle einer Kompromittierung funktionstüchtig bleiben.
  3. Eine Beschreibung, wie ein Backup / Wiederherstellung durchgeführt oder die Konfiguration zurückgesetzt werden kann (z.B. Werkseinstellung).
  4. Hinweise für den Benutzer für notwendige Infrastruktur, um das Gerät nutzen zu können.
  5. Eine Beschreibung wie das Produkt sicher konfiguriert werden kann.
  6. Eine Liste der Netzwerk Ports und anderer Schnittstellen die Daten senden oder Empfangen. Ein Hinweis, dass ungenutzte Ports deaktiviert werden sollen.
  7. Eine Beschreibung, wie ein User sicher ein Software-Update erhalten kann.
  8. Eine Beschreibung, wie ein Gerät unberechtigte Zugriffe meldet (z.B. Fehlgeschlagene Login Versuche, Konfigurationsänderungen, Netzwerk Anomalien und unzulässige Kommunikation).
  9. Beschreibung der Logging Mechanismen des Produktes.
  10. Eine Beschreibung, wie ein autorisierter Benutzer Daten und Konfigurationen wiederherstellen kann.
  11. Eine ausführliche Beschreibung für den End-Anwender durch System Diagramme.
  12. Eine Cybersecurity Bill of Material, um den Anwender in die Lage zu versetzen Schwachstellen zu erkennen und Gegenmaßnahmen vorzunehmen.
  13. Wenn zutreffend, eine Anleitung wie eine sichere Verbindung zu Service-Zwecken herzustellen ist. Weiterhin eine Anleitung, wie der Benutzer Security Vorfälle melden kann.
  14. Informationen darüber, falls der Support durch den Hersteller nicht mehr  aufrechterhalten wird. Dann ist davon auszugehen, dass die Risiken über die Zeit zunehmen werden.

Risikomanagement Dokumentation

Das Risikomanagement verbindet das Design mit dem Gefährdungsmodell, den klinischen Risiken, den Maßnahmen und der Verifizierung. Um die Risiken adäquat zu beherrschen, bedarf es eines sicheren Designs. Die Prinzipien für das Risikomanagement für Cybersecurity wird durch die AAMI TIR57 (Principles for medical device security – Risk management) festgelegt. Um vertrauenswürdige Produkte zu entwickeln, bedarf es der folgenden Punkte:

  1. Ein Gefährdungsmodell auf Systemebene welches System Risiken betrachtet.
  2. Eine Liste aller Cybersecurity Risiken, die für das System zutreffen.
  3. Eine Liste aller umgesetzten Cybersecurity Maßnahmen mit Begründung. Die Maßnahmen sind in Form von verifizierbaren Anforderungen zu formulieren.
  4. Dokumentation der Testergebnisse.
  5. Eine Traceability Matrix, die die Cybersecurity Risikokontrollmaßnahmen mit den Risiken und der Verifizierung verbindet.
  6. Eine Cybersecurity Bill of Material (CBOM). Dazu mehr im darauffolgenden Kapitel.

Für die Verifikation sind folgende Themen zu adressieren:

  1. Test der Gerätefunktionalität
  2. Nachweis, dass Software von dritten (Off-The-Shelf Software) in Bezug auf Cybersecurity sicher ist.
  3. Statische und dynamische Code Analyse mit Test von Zugangsdaten (fest einprogrammierte Passwörter, Default-Passwörter oder einfach zu erratende oder einfach zu umgehende Passwörter.
  4. Schwachstellen Scan
  5. Tests der Robustheit
  6. Grenzwert Analyse
  7. Penetrationstests
  8. Test Berichte von Außenstehenden.

Was ist die Cybersecurity Bill of Material (CBOM)?

Die CBOM ist eine vollständige Liste aller Komponenten inklusive kommerzieller Software, Open Source Software, Off-The-Shelf Software aber auch Hardware, welche Schwachstellen für die Cybersecurity aufweisen können. Bei der Erstellung der CBOM sind Datenbanken wie z.B. die National Vulerability Database (NVD) oder andere ähnlichen Datenbanken nach Schwachstellen und bekannt Vorkommnissen zu prüfen. Dabei sind Kriterien für den Umgang mit Schwachstellen festzulegen und Begründungen zu dokumentieren, sofern Schwachstellen nicht behoben werden.

Fazit

Der Schutz der Geräte gegen Angriffe wird zunehmend wichtiger. Es gibt eine Vielzahl von Regularien und Quellen, die Hersteller von Medizinprodukten heranziehen können. Die hier besprochene Richtlinie der FDA ist mit Sicherheit eine ganz wesentliche und gibt einige wichtige Hinweise, die beim Design zu berücksichtigen sind. Und das nicht nur dann, wenn man das Produkt in den USA zulassen möchte. Wir merken zunehmend, dass die Cybersecurity eine immer wichtigere Rolle in unseren Projekten hat und wir unterstützen unsere Kunden dabei, vertrauenswürdige (trustworthy) und sichere Medizinprodukte zu entwickeln. Sofern sie dazu Fragen haben, treten sie gerne mit uns in Kontakt.

Viele Grüße
Goran Madzar


Geschrieben von Goran Madzar

MEDtech Ingenieur aus Leidenschaft! Mein Team und ich helfen Medizintechnik-Herstellern mit Engineering-Dienstleistungen dabei, Produkte zu entwickeln und in Verkehr zu bringen! Sprechen sie mich gerne an, ob bei LinkedIn oder per Mail. Ich freue mich Sie kennenzulernen.


Weitere Beiträge

  • 30/01/2024
  • Allgemein, Security, Software, Usability

Wo ist denn jetzt wieder dieses Headset? Wer kennt es nicht, man möchte sein Smartphone mit einem Bluetooth-Gerät verbinden, startet den Suchvorgang und plötzlich sieht man den Wald vor ...

Weiterlesen
  • 04/09/2023
  • Allgemein, Normen, Qualität, Testen

Um eine hohe Produktqualität zu gewährleisten und Kunden zufriedenzustellen, müssen Qualitätsprobleme frühzeitig erkannt, analysiert und behoben werden. Hier ist CAPA ein bewährtes Instrument, um Unternehmen dabei zu unterstützen, die ...

Weiterlesen
  • 31/10/2022
  • Dokumentation, Normen, Security, Systems Engineering

In der Medizintechnik können technische Fehler in einem Gerät fatale Folgen für Bediener oder Patienten haben. Daher wird bei der Zulassung des Medizinprodukts auch generell eine Sicherheitsarchitektur gefordert. Wichtig ...

Weiterlesen
Cookie-Übersicht

Die Internetseiten der MEDtech Ingenieur GmbH verwenden Cookies. Cookies sind Textdateien, welche über einen Internetbrowser auf einem Computersystem abgelegt und gespeichert werden.

Zahlreiche Internetseiten und Server verwenden Cookies. Viele Cookies enthalten eine sogenannte Cookie-ID. Eine Cookie-ID ist eine eindeutige Kennung des Cookies. Sie besteht aus einer Zeichenfolge, durch welche Internetseiten und Server dem konkreten Internetbrowser zugeordnet werden können, in dem das Cookie gespeichert wurde. Dies ermöglicht es den besuchten Internetseiten und Servern, den individuellen Browser der betroffenen Person von anderen Internetbrowsern, die andere Cookies enthalten, zu unterscheiden. Ein bestimmter Internetbrowser kann über die eindeutige Cookie-ID wiedererkannt und identifiziert werden.

Durch den Einsatz von Cookies kann die MEDtech Ingenieur GmbH den Nutzern dieser Internetseite nutzerfreundlichere Services bereitstellen, die ohne die Cookie-Setzung nicht möglich wären.

Mittels eines Cookies können die Informationen und Angebote auf unserer Internetseite im Sinne des Benutzers optimiert werden. Cookies ermöglichen uns, wie bereits erwähnt, die Benutzer unserer Internetseite wiederzuerkennen. Zweck dieser Wiedererkennung ist es, den Nutzern die Verwendung unserer Internetseite zu erleichtern. Der Benutzer einer Internetseite, die Cookies verwendet, muss beispielsweise nicht bei jedem Besuch der Internetseite erneut seine Zugangsdaten eingeben, weil dies von der Internetseite und dem auf dem Computersystem des Benutzers abgelegten Cookie übernommen wird.

Die betroffene Person kann die Setzung von Cookies durch unsere Internetseite jederzeit mittels einer entsprechenden Einstellung des genutzten Internetbrowsers verhindern und damit der Setzung von Cookies dauerhaft widersprechen. Ferner können bereits gesetzte Cookies jederzeit über einen Internetbrowser oder andere Softwareprogramme gelöscht werden. Dies ist in allen gängigen Internetbrowsern möglich. Deaktiviert die betroffene Person die Setzung von Cookies in dem genutzten Internetbrowser, sind unter Umständen nicht alle Funktionen unserer Internetseite vollumfänglich nutzbar.

Weitere Informationen erhalten Sie in unserer Datenschutzerklärung.

Unbedingt notwendige Cookies

Dieses Cookie wird benötigt, um Ihre Cookie-Einstellungen zu merken und weitere Hauptfunktionen zur Verfügung zu stellen

Um Ihnen eine Auskunft über Ihre gespeicherten personenbezogenen Daten hier (https://medtech-ingenieur.de/gespeicherte-daten-2/) geben zu können, benötigen wir einen Cookie, um Sie bei der Datenabfrage identifizieren zu können. Dieser Cookie muss aus Sicherheitsgründen deshalb aktiviert sein. Ein weiterer Cookie wird gesetzt, um diesen Banner nicht erneut anzeigen zu müssen.

Cookie-Name Beschreibung
PHPSESSID Name: PHP session
Anbieter:
Eigentümer der Webseite (MEDtech Ingenieur)
Zweck:
Wir benötigt, um Sie bei der Anfrage von personenbezogenen Daten identifizieren zu können. Das Cookie wird nur gesetzt, wenn Sie eine Anfrage hier (https://medtech-ingenieur.de/gespeicherte-daten-2/) stellen.
Laufzeit: Sitzungsende
Kategorie: Unbedingt notwendige Cookies
moove_gdpr_popup Name: Cookie-Box Einstellungen
Anbieter:
Eigentümer der Webseite (MEDtech Ingenieur)
Zweck:
Wird benötigt, um Ihre Cookie-Einstellungen zu speichern, um den Cookie-Banner nicht erneut anzeigen zu müssen.
Laufzeit: 1 Jahr
Kategorie: Unbedingt notwendige Cookies
comment_author_9c90e388e3e1be4a6c594fa6ac8a3eec
comment_author_email_9c90e388e3e1be4a6c594fa6ac8a3eec
comment_author_url_9c90e388e3e1be4a6c594fa6ac8a3eec
Name: Kommentar Einstellungen
Anbieter:
Eigentümer der Webseite (MEDtech Ingenieur)
Zweck:
Cookie wird angelegt, wenn Sie ein Kommentar auf MEDtech Ingenieur veröffentlichen wollen, um Sie als Autor identifizieren und den aktuellen Status Ihres Kommentars anzeigen zu können. Das Cookie enthält den angegebenen Namen. Das Cookie wird erst gesetzt, wenn Sie der Speicherung Ihrer personenbezogenen Daten zustimmen.
Laufzeit: 1 Jahr
Kategorie: Unbedingt notwendige Cookies
rmp-rate Name: RMP Rate
Anbieter: Eigentümer der Webseite (MEDtech Ingenieur)
Zweck: Cookie wird angelegt, wenn Sie eine Bewertung eines Blogbeitrags mithilfe des Sternebewertungssystems abgeben. Ihnen wird eine anonymisierte ID zugewiesen, um zu erkennen, ob Sie einen Artikel bereits bewertet haben oder nicht. Das Cookie wird nur verwendet, um zu verhindern, dass mehrfache Bewertung abgegeben werden und erst gesetzt, wenn Sie auf einen Stern klicken.
Laufzeit: 1 Jahr
Kategorie: Unbedingt notwendige Cookies
medtech-download-page Name: Download Page
Anbieter: Eigentümer der Webseite (MEDtech Ingenieur)
Zweck: Cookie wird angelegt, wenn Sie den Landing-Page Prozess erfolgreich durchlaufen haben. Dies geschieht nur, wenn Sie einen Content-Download von unserer Website anstreben.
Laufzeit: 1/2 Jahr
Kategorie: Unbedingt notwendige Cookies