Was ist ein Penetrationstest?

Leave a Comment

Ein Penetrationstest ist im Prinzip ein strukturiert durchgeführter Angriff auf die IT-Infrastruktur eines Unternehms. Hierbei setzt ein Penetration Tester die gleichen Tools und Technicken ein, die auch ein Hacker in seinem Angriff verwendet. Allerdings unterscheidet sich dabei die Zielstellung zwischen einem böswilligen Hacker und einem professionellem Penetrationstester.

Ein Hacker versucht in der Regel in ein Unternehmen einzudringen, um sich Zugang zu deren IT-Systemen und Daten zu verschaffen. Hierzu benötigt er nur eine einzige kritische Schwachstelle, die er erfolgreich ausnutzen kann.

Unternehmen, die einen Penetrationstest beauftragen, wollen aber in der Regel primär nicht erfolgreich gehackt werden, sie wollen wissen, ob dieses möglich ist. Hierzu wird ein Penetrationstester versuchen alle Schwachstellen zu identifzieren, unabhängig von deren Kritikalität. Viele Schwachstellen werden dabei auch versucht auszunutzen, aber nicht alle. Denn manche weiterführende Angriffe stellen ein höheres Risiko für die angegriffen IT-Systeme dar.

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.

Penetrationstest Anbieter: Das Unternehmen binsec GmbH als Ihr Dienstleister für Pentests aus Frankfurt am Main

Leave a Comment

Die binsec GmbH ist ein von mir im Jahr 2013 mitgegründetes Beratungsunternehmen für Informationssicherheit aus Frankfurt am Main. Ich bin seit der Gründung der Geschäftsführer der binsec GmbH. Wir führen als Dienstleister Penetrationstests durch und beraten unsere Kunden auch in den Bereichen Sicherheitsmanagement und IT-Sicherheit.

Die binsec GmbH liegt über die binsec group GmbH vollständig in der Hand der drei Gesellschafter: Patrick Sauer, Florian Zavatzki und Dominik Sauer. Wir sind an der langfristigen Zufriedenheit unserer Kunden und Mitarbeiter interessiert: Kurzfristige Umsatz- und Gewinnmaximierung ist nicht unser Ziel.

Mein Team besteht aus erfahrenen, zertifizierten Spezialisten. Unser Fokus ist immer die Sicherheit der geschäftskritischen IT-Systeme und Informationen. Auch wenn wir Penetrationstests durchführen, behalten wir die Business-Aspekte im Blick.

Als Anbieter für Penetrationstests und Sicherheitsberatung sind wir in den letzten Jahren zur Top-Adresse als Pentest Dienstleister gerade im Großraum Frankfurt am Main geworden.

Mehr Information über unser Unternehmen und Dienstleistungen als Anbieter für Pentesting gibt es auf https://www.binsec.com.

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.

Warum Penetrationstests bei ISO27001-Zertifizierungen?

Leave a Comment

Im Rahmen der ISO 27001-Zertifizierung wollen Auditoren immer regelmäßiger den Bericht eines Penetrationstests sehen. Aber woher kommt diese Anforderung, wenn im Text der ISO 27001 das Wort Pentest oder Penetrationstest gar nicht vorkommt?

Die ISO 27001 ist die internationale Norm für den Aufbau und Betrieb eines ISMS (Informationssicherheits-Managementsystem). Im Anhang A enthält dieser Standard Kontrollziele bzw abstraktere Maßnahmen zur Umsetzung. Eine konkretere Erläuterung der einzelnen Punkte findet man in der Norm ISO 27002, diese entspricht in ihrem strukturellen Dokumentenaufbau den Kontrollzielen vom Anhang A der ISO 27001.

Im Anhang A der ISO 27001 findet man nun in Abschnitt A.18.2 die Anforderung „Information security reviews“ durchzuführen. In der ISO27002-Implementierungsrichtlinie für diese Maßnahme findet man nun die Durchführung von Schwachstellen-Scans und/oder Penetrationstest als Möglichkeit, dieser Anforderung gerecht zu werden.

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.

Common Vulnerability Scoring System (CVSS) – ein (subjektiv) einheitliches Bewertungsschema für Sicherheitslücken?

Leave a Comment

Es kann sehr fesselnd sein, in der Rolle eines Angreifers in fremde IT-Systeme einzudringen. Als Penetrationstester sollte dabei jedoch nie das eigentliche Ziel aus den Augen verloren werden: die Identifikation aller Einstiegspunkte bzw. Sicherheitslücken in einem Zielsystem. Die Liste von Schwachstellen kann sehr lang und unübersichtlich werden. Um einem Auftraggeber aber mitzuteilen, welche Schwachstellen zuerst adressiert bzw. behoben werden sollten, müssen die ermittelten Schwachstellen nach ihrem Risiko geordnet werden.

Grundsätzlich kann das Risiko einer Schwachstelle über zwei verschiedene Arten dargestellt werden. So kann entweder ein konkreter Zahlenwert ermittelt (bspw. 1.034,99 Euro) werden oder eine Aussage über die Schwere des Risikos getroffen (wie gering, mittel, hoch) werden. Der konkrete Zahlenwert ist das Ergebnis einer quantitativen Risikoanalyse. Diese eignet sich beispielsweise zur Bestimmung des Risikos eines Festplattenausfalls, da Festplatten einen konkreten Preis und eine durch­schnitt­liche Lebensdauer haben. Im Gegensatz dazu liegen einem Pentester bei Schwachstellen von IT-Systemen normalerweise nicht genug Informationen dieser Art vor, sodass diese Form der Risikoanalyse nicht empfehlenswert ist. Stattdessen kann aber eine qualitative Risikoanalyse vorgenommen werden, da immer Aussagen über die Eintrittswahrscheinlichkeit und das mögliche Schadensausmaß einer Schwachstelle getroffen und somit die Schwere des Risikos abgeschätzt werden kann. Wie bei einer Schätzung üblich, werden verschiedene Pentester zu unterschiedlichen Risikobewertungen gelangen, da ihre Wahrnehmung und Erfahrungen uneinheitlich sind – selbst, wenn sie sich auf dasselbe Bewertungsschema beziehen.

Jedoch benötigen gerade regulatorische Stellen wie das Regierungspräsidium Darmstadt ein einheitliches System, da sie konkrete Anforderungen und Maßnahmen definieren müssen. Infolgedessen fordern sie von Pentestern eine Risikobewertung nach dem Common Vulnerability Scoring System (CVSS) durchzuführen. Bei diesem handelt es sich um ein metrisches Bewertungsschema, welches einer Schwachstelle eine Punktzahl bzw. einen Score zwischen 0 und 10 zuweist – je höher der Score desto gravierender ist das Risiko einer Schwachstelle. Auch wenn das Risiko einer Schwachstelle beim CVSS anhand einer Vielzahl von Parametern berechnet wird (s. https://www.first.org/cvss/calculator/3.1), liegen Kenngrößen wie die Auswirkung einer erfolgreich ausgenutzten Schwachstelle auf die Integrität im Ermessen der Pentester. Somit können Risikoangaben wie der CVSS Score einem Auftraggeber zwar als Richtwert dienen, jedoch sollte intern immer eine eigene Schwachstellenbewertung vorgenommen werden.