Regulatorik

Penetrationstest nach MDR (Medizinprodukteverordnung)

Leave a Comment

Die MDR verlangt im Anhang I bei „Produkte, zu deren Bestandteilen programmierbare Elektroniksysteme gehören, und Produkte in Form einer Software“ unter Punkt 17.2 die Verifzierung und Validierung, dass das Produkt bzw die Software nach dem Stand der Technik entwickelt wurde – aus der Perspektive der IT-Sicherheit:

17.2 Bei Produkten, zu deren Bestandteilen Software gehört, oder bei Produkten in Form einer Software wird die Software entsprechend dem Stand der Technik entwickelt und hergestellt, wobei die Grundsätze des Software-Lebenszyklus, des Risikomanagements einschließlich der Informationssicherheit, der Verifizierung und der Validierung zu berücksichtigen sind.

MDR, Anhang I – Verordnung (EU) 2017/745 des Europäischen Parlaments und des Rates vom 5. April 2017 über Medizinprodukte, zur Änderung der Richtlinie 2001/83/EG, der Verordnung (EG) Nr. 178/2002 und der Verordnung (EG) Nr. 1223/2009 und zur Aufhebung der Richtlinien 90/385/EWG und 93/42/EWG des Rates (Text von Bedeutung für den EWR. )

Im Medical Device Coordination Group Document „MDCG 2019-16 Guidance on Cybersecurity for medical devices“ findet sich nun als Konkretisierung der vorherigen Verifzierung- und Validierungsbestimmung Penetration Testing als eine Möglichkeit:

MDR Annex I Section 17.2 and IVDR Annex I Section 16.2 require for devices that incorporate software or for software that are devices in themselves, that the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of the development life cycle, risk management, including information security, verification and validation. The primary means of security verification and validation is testing. Methods can include security feature testing, fuzz testing, vulnerability scanning and penetration testing. Additional security testing can be one by using tools for secure code analysis and tools that scan for open source code and libraries used in the product, to identify components with known issues.

Medical Device Coordination Group Document, MDCG 2019-16

Penetrationstest-Anforderungen des Microsoft 365-App-Compliance-Programms

Leave a Comment

Die Teilnahme am Compliance-Programm für Microsoft 365-Zertifizierungs von Apps für Teams-Anwendungen, SharePoint-Apps/Add-Ins, Office-Add-Ins und WebApps erfordert die Durchführung eines Penetrationstests. Bei der Erstdokumenteneinreichung muss ein Unternehmen Unterlagen und Nachweise einreichen. Neben anderen Doikumenten ist ein Bericht von einem Penetrationstest erforderlich, der innerhalb der letzten 12 Monate abgeschlossen wurde. Der Pentest muss der Live-Umgebung prüfen, die die Bereitstellung der App unterstützt, sowie alle zusätzlichen Umgebungen, die den Betrieb der App ermöglichen. Wenn Segmentierungskontrollen vorhanden sind, müssen diese ebenfalls getestet werden.

Die Pentest-Anforderungen von Microsoft sind:

  • Alle 12 Monate muss jährlich ein Applikations- und Infrastruktur-Pentest stattfinden.
  • Diese Tests müssen von einem renommierten unabhängigen Unternehmen durchgeführt werden.
  • Die Behebung identifizierter kritischer und hochriskanter Schwachstellen muss innerhalb eines Monats erfolgen nachdem Pentest-Bericht abgeschlossen ist.
  • Die gesamte externe Angriffsfläche (IP-Adressen, URLs, API-Endpunkte usw.) muss in den Umfang des Penetrationstests einbezogen und im Penetrationstestbericht dokumentiert werden.
  • Penetrationstests für Webanwendungen müssen alle typischen Schwachstellenklassen umfassen; zum Beispiel die aktuellsten OWASP Top 10 oder SANS Top 25 CWE.
  • Ein erneutes Testen identifizierter Schwachstellen durch das Penetrationstestunternehmen ist nicht erforderlich – Behebung und Selbstüberprüfung sind ausreichend, jedoch müssen während der Bewertung angemessene Nachweise für eine ausreichende Behebung erbracht werden. Das erneute Testen identifizierter Schwachstellen ist dennoch Best Practice in der Informationssicherheit.
  • Penetrationstestberichte werden am Ende überprüft, um sicherzustellen, dass es keine Schwachstellen gibt, die aus einer der folgenden Kategorien stammen:
    • Nicht unterstütztes Betriebssystem.
    • Standardmäßige, aufzählbare oder erratbare Administratorkonten.
    • SQL-Injection-Risiken
    • XSS
    • Sicherheitslücken bei Directory Traversal (Dateipfad).
    • Typische HTTP-Schwachstellen, z. B. Header-Response-Splitting, Request-Smuggling und Desync-Angriffe.
    • Offenlegung des Quellcodes (einschließlich LFI).
    • Jede kritische oder hoher Score nach CVSS-Richtlinien für das Patch-Management
    • Jede bedeutende technische Schwachstelle, die leicht ausgenutzt werden kann, um eine große Menge an EUII oder OUI zu kompromittieren.

KRITIS-Penetrationstest: Anforderungen BSI Gesetz

Leave a Comment

Penetrationstests sind für Betreiber kritischer Infrastrukturen verpflichtend. Im BSI-Gesetz unter dem Paragraph „8a Sicherheit in der Informationstechnik Kritischer Infrastrukturen“ werden Unternehmen verpflichtet, angemessene organisatorische und technische Maßnahmen zum Schutz ihrer kritischen Infrastruktur zu treffen:

Gesetz über das Bundesamt für Sicherheit in der Informationstechnik (BSI-Gesetz – BSIG)
§ 8a Sicherheit in der Informationstechnik Kritischer Infrastrukturen

(1) Betreiber Kritischer Infrastrukturen sind verpflichtet, spätestens bis zum ersten Werktag, der darauf folgt, dass diese erstmalig oder erneut als Betreiber einer Kritischen Infrastruktur nach der Rechtsverordnung nach § 10 Absatz 1 gelten, angemessene organisatorische und technische Vorkehrungen zur Vermeidung von Störungen der Verfügbarkeit, Integrität, Authentizität und Vertraulichkeit ihrer informationstechnischen Systeme, Komponenten oder Prozesse zu treffen, die für die Funktionsfähigkeit der von ihnen betriebenen Kritischen Infrastrukturen maßgeblich sind. Dabei soll der Stand der Technik eingehalten werden.

Quelle: https://www.gesetze-im-internet.de/bsig_2009/__8a.html

Die Ausführungen im eigentlichen Gesetz sind typisch allgemein und abstrahiert gehalten. Auch wenn im Wortlaut des §8a keine Penetrationstests für KRITIS-Unternehmen vorgesehen werden, werden Pentests in der BSI-Veröffentlichung der umzusetzenden Maßnahmen gefordert.

Konkretisierung der Anforderungen an die gemäß § 8a Absatz 1 BSIG umzusetzenden Maßnahmen

Der KRITIS-Betreiber lässt mindestens jährlich Penetrationstests durch qualifiziertes internes Personal oder externe Dienstleister durchführen. Die Penetrationstests erfolgen nach einer dokumentierten Testmethodik und umfassen die für den sicheren Betrieb der kritischen Dienstleistung als kritisch definierte Infrastruktur-Komponenten, die im Rahmen einer Risiko-Analyse als solche identifiziert wurden. Art, Umfang Zeitpunkt/Zeitraum und Ergebnisse werden für einen sachverständigen Dritten nachvollziehbar dokumentiert. Feststellungen aus den Penetrationstests werden bewertet und mindestens bei mittlerer bis sehr hoher Kritikalität in Bezug auf die Vertraulichkeit, Integrität oder Verfügbarkeit der kritischen Dienstleistung nachverfolgt und behoben. Die Einschätzung der Kritikalität und der mitigierenden Maßnahmen zu den einzelnen Feststellungen werden dokumentiert.

Quelle: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/KRITIS/Konkretisierung_Anforderungen_Massnahmen_KRITIS.html

Somit sind für KRITIS-Betreiber jährliche Penetrationstests zwingend notwendig. Erfahrungsgemäß haben die wenigsten KRITIS-Betreiber qualifiziertes internes Personal zur Durchführung von professionellen Penetrationstests und müssen den Pentest von einem externen Unternehmen bzw. Dienstleister durchführen lassen.

i-Kfz: Anforderungen an Penetrationstests vom Kraftfahrt-Bundesamt (KBA)

Leave a Comment

Die „Mindestsicherheitsanforderungen an dezentrale Portale und Zulassungsbehörden“ zur „internetbasierten Fahrzeugzulassung (i-Kfz)“ vom Kraftfahrt-Bundesamt (KBA) sind außerordentlich umfangreich. Sie beinhalten neben der Architektur des i-Kfz-Systems, seiner Schnittstellen und daraus abgeleiteten Sicherheitsanfordeurngen unter anderem auch Anforderungen an die Durchführung eines Penetrationstests.

Zur Prüfung der Wirksamkeit der implementierten Sicherheitsmaßnahmen verlangt das KBA als Penetrationstest die Durchführung von:

  • IS-Kurzrevision (wenn keine ISO 27001/IT-Grundschutz-Zertifizierung vorhanden)
  • IS-Webcheck
  • IS-Penetrationstest

Alle o.g. Tests sind dabei als White-Box-Test durchzuführen und es darf nur fachlich qualifiziertes und unabhängiges Personal eingestetzt werden.

Als IS-Wecheck ist dabei ein nicht invasiver Schwachstellenscan (definierte Prüftiefe) mit manueller Validierung der Schwachstellen vorgesehen. Hierbei soll auf die OWASP Top 10 geprüft werden sowie die entsprechenden Module vom IS-Webcheck durchgeführt werden: „Modul 1 – Schwachstellensuche“, „Modul 2 – Schwachstellentest“, „Modul 3 – Logische Fehler/Konfigurationsfeher“ sowie „Modul 4 – Exploits (optional)“. Der Test ist dabei über das Internet durchzuführen und die Filterung eines vorgeschalteten Sicherheitsgateways ist dabei zu deaktivieren.

Im IS-Penetrationstest wird primär die technische Angriffsoberfläche einer Institution nach außen hin untersucht. Als Prüftiefe ist hier ein technischer Sicherheitsaudit in Kombination mit einem nicht-invasiven Schwachstellen-Scan definiert. Im Scope sind dabei mindestens alle Netzwerkelemente, Sicherheitsgateways, Server, Webanwendungen, relevante Clients und Infrastruktureinrichtungen zu prüfen, sofern technisch möglich und sinnvoll. Dabei sind folgende Module durchzuführen: „Modul 1 – konzeptionelle Schwächen“, „Modul 2 – Umsetzung Härtungsmaßnahme“, „Modul 3 – Bekannte Schwachstelle“ und „Modul 4 – Exploits (optional)“.

Hierbei ist zu erwähnen, dass die geforderte Prüftiefe erfahrungsgemäß eher als nicht-invasiver Penetrationstest ausgelegt werden sollte. Der Einsatz eines typischen automatisierten Schwachstellen-Scanners ist zur Analyse der gestellten Anforderungen technisch nicht ausreichend.

Anforderungen an DiGa-App-Pentests – Penetrationstest für digitale Gesundheitsanwendungen im Fast-Track-Verfahren

Leave a Comment

Um in das Verzeichnis erstattungsfähiger digitaler Gesundheitsanwendungen (DiGa) aufgenommen zu werden, muss das Fast-Track-Verfahren beim BfArM durchlaufen werden. Mit dem Digitale–Versorgung–und–Pflege–Modernisierungs–Gesetz (DVPMG) kam in den entsprechenden Leitfaden die Anforderung hinein, dass Antragsteller einen Penetrationstest für ihre DiGa-Anwendung durchführen lassen müssen.

Im DiGa-Leitfaden selbst findet man die konkreten Anforderungen an den eigentlichen Penetrationstest:

Penetrationstests: Mit dem DVPMG wurde diese Anforderung für alle DiGA in die DiGAV aufgenommen. Die Sicherheit der Daten über den gesamten Anwendungsprozess und alle erdenklichen Nutzungsszenarien hinweg sicherzustellen, ist essentielle Anforderung an DiGA.
Penetrationstests ermöglichen die Nachbildung möglicher Angriffsmuster und können so dazu beitragen, Sicherheitslücken aufzudecken. Für die Produktversion, für die eine Aufnahme in das DiGA-Verzeichnis beantragt wird, muss für alle Komponenten ein Penetrationstest durchgeführt worden sein. Diese Tests sind anforderungsbezogen zu wiederholen, z. B. wenn neue Schnittstellen in das Internet hinzukommen. Als Basis für die Testkonzeption sind das Durchführungskonzept für Penetrationstests des BSI sowie die jeweils aktuellen OWASP Top-10 Sicherheitsrisiken heranzuziehen. Dem BfArM muss auf Verlangen ein Nachweis über die Durchführung der entsprechenden Tests vorgelegt werden.

https://www.bfarm.de/SharedDocs/Downloads/DE/Medizinprodukte/diga_leitfaden.pdf
(Stand: 18.03.2022)

Im Prinzip kann man die Anforderungen an einen DiGa-Pentest somit wie folgt zusammen fassen:

  • Durchführungskonzept für Penetrationstests des BSI
  • OWASP Top-10
  • für alle Komponenten
  • anforderungsbezogen zu wiederholen (z. B. neue Schnittstellen)

Jetzt hatte ich bereits mehrere Diskussionen mit Herstellern von DiGA-Apps, dass diese nur die eigentliche Mobile App (also in der Regel die iOS und die Android-Version) prüfen lassen wollen. Nicht im Scope enthalten soll jedoch eine dahinterliegende API sein, über die teilweise Business-Funktionalität realisiert wird, die Nutzer-Authentifizierung abwickelt und als zentraler Speicherort für Gesundheitsdaten dienen soll.

Klar, eine „App“ und eine „API“ sind zwei unterschiedliche Dinge und die Verordnung spricht von digitalen Gesundheitsanwendungen (ergo Apps). Allerdings führt diese Auslegung der Verordnung nicht ans Ziel und ist einfach falsch. Der Penetrationstest soll „die Sicherheit der Daten über den gesamten Anwendungsprozess“ hinweg sicherstellen und der Penetrationstest muss für „alle Komponenten“ durchgeführt werden. Das heißt natürlich, dass auch Backend-Systeme und APIs im Hintergrund im Scope des Penetrationstest sind und nicht nur die eigentliche Mobile App aus dem Android- oder Apple-Store.