OWASP Top 10

Penetrationstests beim MPA Content Security Program

Leave a Comment

Das Content Security Program der Motion Picture Association (MPA) legt in ihren Content Security Best Practices Common Guidelines (Version 4.10 vom 8. Februar 2022) Sicherheitsanforderungen in drei Bereichen fest:

  • Management System
  • Physical Security
  • Digital Security

In den Anforderungen an das Management System wird in der Nummer MS-2.1 in der Kategorie Risk Management die Durchführung von Schwachstellen-Scans und externen Penetrationstests durchgeführt. Hierbei wird auf die Anfordeurngen DS-1.8 und DS-1.9 verwiesen.

In der Anforderung DS-1.9 (Firewall / WAN / Perimeter Security) wird die Durchführung jährlicher Penetrationstests aller externen IP-Adressen und Systemen verlangt. Die DS-1.8 verlangt zusätzlich die monatliche Durchführung von Schwachstellen-Scans.

Weiterhin findet man zusätzlich die Anforderung zur Durchführung von Webanwendungs-Penetrationstests (DS-15.9, Client Portal). Hier werden etwas detailreichere Anforderungen gestellt:

  • Der Pentest soll auch eventuelle APIs beinhalten.
  • Der Test soll sowohl mit als auch ohne valide Zugangsdaten durchgeführt werden.
  • Die typischen Guidlines wie z.B. die Veröffentlichungen von OWASP sollen beachtet werden, sodass auch XSS, SQL Injections, und CSRF gefunden werden kann.

Es wird dabei allgemein empfohlen, dass die Penetrationstests von einer unabhängigen dritten Stelle durchgeführt werden.

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.

Vergleich von PCI DSS 3.2.1 und 4.0: Anforderungen für Penetrationstests

Leave a Comment

Die aktuelle Version 3.2.1 und die neuere Version 4.0 des Sicherheitsstandards PCI DSS erfordern die Durchführung von Penetrationstests. Der PCI-Standard legt detaillierte Anforderungen fest, die ein Penetrationstest erfüllen muss. In PCI DSS 3.2.1 ist die Anforderung in Anforderung 11.3 und in PCI DSS 4.0 in Anforderung 11.4 geregelt.

Diese Anforderungen sind in beiden Versionen 3.2.1 und 4.0 grundsätzlich identisch:

  • basierend auf branchenweit akzeptierten Penetrationstestansätzen
  • Abdeckung des gesamten CDE-Perimeters und kritischer Systeme
  • Tests von innerhalb und außerhalb des Netzwerks
  • Validierung jeglicher Segmentierungs- und Scope-reduzierenden Kontrollen
  • Testen der Netzwerkschicht und der Anwendungsschicht
  • einschließlich Überprüfung und Berücksichtigung von Bedrohungen und Schwachstellen, die in den letzten 12 Monaten aufgetreten sind
  • alle 12 Monate und nach jeder wesentlichen Änderung muss der externe und der interne Pentest durchgeführt werden, sowie der Segmentierungstest
  • Service Provider müssen alle 6 Monate einen Segmentierungstest durchführen

Es gibt zwei Bereiche, bei die beiden Standard-Versionen auseinander gehen, während PCI 4.0 die ausgereiftere Version darstellt. So hat PCI 4.0 einen etwas anderen Ansatz für seine Anforderungen an den Penetrationstest der Anwendungsschicht:

  • PCI v3.2.1 inkludiert Requirement 6.5 für Anwendungstests um folgende Punkte zu prüfen:
    • injection flaws (e.g. SQL, LDAP, OS Commant, XPath)
    • buffer overflows
    • insecure crypto storage, insecure communications
    • improper error handling
    • XSS
    • improper access controls
    • CSRF
    • broken authentication and session management
    • sowie aktuellere Best Practices (e.g. OWASP Top 10)
  • PCI v4.0: inkludiert Requirement 6.2.4, sodass für Anwendungstests mindestens folgendes durchgeführt wird
    • injection attacks (including SQL, LDAP, XPath, command parameters, object fault or injectiontype flaws)
    • attacks on data and data structures (for example manipulating buffers, input data)
    • attacks on cryptography usage
    • attacks on business logic including XSS and CSRF
    • attacks on access control mechanisms

In PCI 4.0 muss der Segmentierungstest auch die Bestätigung der Wirksamkeit jeglicher Verwendung von Isolationstechniken für verschiedene Sicherheitsstufen umfassen (siehe Anforderung 2.2.3).

Natürlich muss der angewendete Penetrationstestansatz das Beheben und erneute Testen aller relevanten Schwachstellen umfassen, die zuvor identifiziert wurden – unabhängig von der Version des PCI-Standards.

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.