OWASP Top 10 und CWE Top 25 – zwei Perspektiven auf Software-Schwachstellen

Leave a Comment

Im Umfeld der Anwendungssicherheit tauchen zwei Referenzen besonders häufig auf: die OWASP Top 10 und die CWE Top 25 Most Dangerous Software Weaknesses. Beide Listen werden regelmäßig in Security-Guidelines, Schulungen oder Pentest-Berichten erwähnt und sollen typische Sicherheitsprobleme in Software sichtbar machen.

Auf den ersten Blick scheinen beide Listen dasselbe zu behandeln: häufige Schwachstellen in Software. Tatsächlich verfolgen sie jedoch unterschiedliche Ansätze. Während die OWASP Top 10 Sicherheitsrisiken für Webanwendungen beschreibt, listet die CWE Top 25 konkrete technische Schwachstellen in Software allgemein.

Die OWASP Top 10

Die OWASP Top 10 wird vom Open Web Application Security Project veröffentlicht und beschreibt die wichtigsten Sicherheitsrisiken für Webanwendungen.

Zu den bekannten Kategorien gehören unter anderem:

  • Broken Access Control
  • Cryptographic Failures
  • Injection
  • Security Misconfiguration

Die Kategorien sind bewusst relativ abstrakt formuliert. Sie beschreiben Risikobereiche in Webanwendungen, die sich aus typischen Schwachstellen, möglichen Angriffsvektoren und den daraus resultierenden Auswirkungen zusammensetzen.

Der Fokus der OWASP Top 10 liegt klar auf Webanwendungen und webbasierten Architekturen. Entsprechend spiegeln viele Kategorien typische Probleme moderner Webanwendungen wider.

Die Liste dient deshalb häufig als Orientierung für Web Application Security. Viele Organisationen nutzen sie beispielsweise für Secure-Development-Guidelines oder Security-Awareness-Schulungen.

Dabei gilt allerdings: Die OWASP Top 10 ist keine Testmethodik. Sie beschreibt Risiken, nicht konkrete Prüfverfahren oder technische Tests.

Die CWE Top 25

Die Common Weakness Enumeration (CWE) wird von MITRE gepflegt und stellt ein umfassendes Klassifikationssystem für Software-Schwachstellen dar.

Aus dieser Sammlung wird regelmäßig die Liste der CWE Top 25 Most Dangerous Software Weaknesses abgeleitet.

Im Gegensatz zur OWASP Top 10 beschreibt die CWE Top 25 konkrete technische Fehlerklassen im Code, zum Beispiel:

  • Out-of-bounds Write (CWE-787)
  • Use After Free (CWE-416)
  • Improper Input Validation (CWE-20)

Viele dieser Schwachstellen entstehen direkt im Code und betreffen insbesondere speicherunsichere Programmiersprachen oder systemnahe Software.

Im Unterschied zur OWASP Top 10 ist die CWE-Klassifikation nicht auf Webanwendungen beschränkt, sondern beschreibt Schwachstellen in Software allgemein. Sie kann daher sowohl für Webanwendungen als auch für Desktopsoftware, Systemsoftware oder Embedded-Systeme verwendet werden.

Risiko vs. technische Ursache

Der wichtigste Unterschied zwischen beiden Listen liegt im Abstraktionsniveau.

Die OWASP Top 10 beschreibt Sicherheitsrisiken für Webanwendungen.
Die CWE Top 25 beschreibt konkrete Schwachstellen im Code von Software allgemein.

Eine OWASP-Kategorie kann daher mehrere zugrunde liegende Schwachstellen umfassen.

Ein Beispiel verdeutlicht den Zusammenhang:
Das Risiko Injection kann durch unterschiedliche technische Ursachen entstehen, etwa durch unzureichende Eingabevalidierung oder unsichere Datenbankabfragen. Diese Ursachen lassen sich wiederum konkreten CWE-IDs zuordnen.

OWASP beantwortet damit eher die Frage:

Welche Sicherheitsrisiken treten in Webanwendungen besonders häufig auf?

Die CWE-Klassifikation beschreibt dagegen:

Welche konkreten Fehler im Code führen zu diesen Problemen?

Gegenüberstellung von OWASP Top 10 und CWE Top 25

Eine direkte 1:1-Zuordnung zwischen beiden Listen existiert nicht. Dennoch lassen sich typische Zusammenhänge darstellen. Die folgende Tabelle zeigt eine vereinfachte Gegenüberstellung häufiger Beziehungen.

OWASP KategorieTypische zugehörige CWE-Schwachstellen
Broken Access ControlCWE-284 Improper Access Control, CWE-862 Missing Authorization
Cryptographic FailuresCWE-327 Broken or Risky Crypto Algorithm, CWE-326 Inadequate Encryption Strength
InjectionCWE-89 SQL Injection, CWE-77 Command Injection, CWE-20 Improper Input Validation
Insecure DesignCWE-840 Business Logic Errors, CWE-602 Client-Side Enforcement of Server-Side Security
Security MisconfigurationCWE-16 Configuration Errors
Vulnerable and Outdated Componentshäufig indirekt über bekannte CVEs mit zugrunde liegenden CWEs
Identification and Authentication FailuresCWE-287 Improper Authentication, CWE-522 Insufficiently Protected Credentials
Software and Data Integrity FailuresCWE-494 Download of Code Without Integrity Check
Security Logging and Monitoring FailuresCWE-778 Insufficient Logging
Server-Side Request Forgery (SSRF)CWE-918 Server-Side Request Forgery

Gleichzeitig enthält die CWE Top 25 auch mehrere Schwachstellen, die sich nicht direkt einer OWASP-Kategorie zuordnen lassen. Dazu gehören beispielsweise klassische Speicherfehler wie:

  • CWE-787 Out-of-bounds Write
  • CWE-416 Use After Free
  • CWE-125 Out-of-bounds Read
  • CWE-190 Integer Overflow

Diese treten typischerweise eher in systemnaher Software als in klassischen Webanwendungen auf.

Bedeutung für Pentests

Für Pentests ist vor allem die OWASP Top 10 eine häufig genutzte Referenz. Die Liste beschreibt zentrale Sicherheitsrisiken, die bei der Prüfung von Webanwendungen typischerweise berücksichtigt werden.

Einige Pentest-Berichte strukturieren ihre Ergebnisse entlang der OWASP-Kategorien. Häufiger werden die Kategorien jedoch eher zur Einordnung von Schwachstellen oder zur Kommunikation von Risiken verwendet.

Die CWE-Klassifikation spielt im Pentest eine ergänzende Rolle. Sie hilft dabei, eine gefundene Schwachstelle technisch präzise zu klassifizieren. Viele Schwachstellenberichte enthalten daher zusätzlich eine zugehörige CWE-ID.

Ein typisches Mapping kann beispielsweise so aussehen:

OWASP Risiko
→ konkrete Schwachstelle
→ zugehörige CWE-ID

Beispiel:

Broken Access Control
→ fehlende Autorisierungsprüfung
→ CWE-284 Improper Access Control

Eine solche Zuordnung kann sowohl die Risikokommunikation gegenüber Stakeholdern als auch die technische Einordnung einer Schwachstelle erleichtern. In der Praxis erfolgt sie jedoch häufig nur auf Kundenwunsch. Der tatsächliche Mehrwert einer zusätzlichen Klassifizierung bleibt meist begrenzt.

PTES – Struktur für Pentests, aber kein vollständiger Standard

Leave a Comment

Der Penetration Testing Execution Standard (PTES) beschreibt eine strukturierte Methodik für die Durchführung von Penetrationstests. Ziel des Standards ist es, typische Projektphasen eines Pentests zu definieren und damit einen nachvollziehbaren Ablauf von der Planung bis zur Dokumentation der Ergebnisse zu schaffen. Der Standard entstand um 2010 als gemeinschaftliche Initiative von Sicherheitsexperten. PTES wird bis heute häufig als Referenz genannt, wenn es um den generellen Ablauf eines Penetrationstests geht. In der Praxis dient er jedoch meist eher als konzeptioneller Rahmen als als vollständige technische Methodik.

Die PTES-Phasen

PTES unterteilt einen Penetrationstest in sieben typische Projektphasen.

Pre-Engagement Interactions
In dieser Phase werden organisatorische und rechtliche Rahmenbedingungen festgelegt. Dazu gehören insbesondere Scope, Testziele, Kommunikationswege sowie die sogenannten Rules of Engagement.

Intelligence Gathering
Hier werden Informationen über die Zielumgebung gesammelt. Dazu zählen beispielsweise öffentlich verfügbare Daten, DNS-Informationen, Subdomains oder Hinweise auf eingesetzte Technologien.

Threat Modeling
Auf Basis der gesammelten Informationen werden mögliche Angriffsszenarien bewertet. Ziel ist es, realistische Angriffspfade und besonders kritische Systeme zu identifizieren.

Vulnerability Analysis
In dieser Phase werden potenzielle Schwachstellen identifiziert. Dies erfolgt in der Regel durch eine Kombination aus automatisierten Scans und manuellen Analysen.

Exploitation
Gefundene Schwachstellen werden anschließend praktisch überprüft. Dabei wird untersucht, ob und in welchem Umfang eine Ausnutzung möglich ist.

Post-Exploitation
Nach erfolgreichem Zugriff wird analysiert, welche weiteren Auswirkungen möglich sind. Dazu gehören beispielsweise Privilege Escalation, Zugriff auf sensible Daten oder laterale Bewegungen im Netzwerk.

Reporting
Am Ende des Projekts werden alle Ergebnisse dokumentiert. Der Bericht beschreibt identifizierte Schwachstellen, deren Auswirkungen sowie mögliche Maßnahmen zur Behebung.

Die Phasen bilden damit eine sinnvolle Struktur für den Ablauf eines Penetrationstest-Projekts.

Kritische Betrachtung

Trotz seiner Bekanntheit ist PTES heute selten die alleinige methodische Grundlage für Penetrationstests.

Ein wesentlicher Grund ist die begrenzte technische Detailtiefe des Standards. Die beschriebenen Phasen definieren zwar den Ablauf eines Pentests, enthalten jedoch nur wenige konkrete Prüfmethoden. Für die praktische Durchführung sind daher zusätzliche technische Leitfäden und eigene Methodiken notwendig.

Hinzu kommt, dass der Standard seit seiner ursprünglichen Veröffentlichung nur begrenzt weiterentwickelt wurde. Einige technische Beispiele im PTES beziehen sich auf inzwischen veraltete Plattformen und Werkzeuge. So werden in den technischen Abschnitten beispielsweise ältere Windows-Versionen wie Windows XP oder Windows 7 als Referenzsysteme genannt.

Auch moderne IT-Architekturen werden im ursprünglichen PTES kaum behandelt. Themen wie Cloud-Infrastrukturen, containerisierte Plattformen oder komplexe Identity-Systeme spielen im Standard nur eine untergeordnete Rolle.

Darüber hinaus handelt es sich beim PTES nicht um einen formal gepflegten Industriestandard mit klar definierter Governance. Eine regelmäßige Aktualisierung durch eine Standardisierungsorganisation findet nicht statt. Dadurch entwickelt sich der Standard nicht weiter und bildet keine aktuellen technische Entwicklungen ab.

Hackeroo | Hacking, Penetration Testing, Red Teaming

Leave a Comment

Keine Agentur, kein Buzzword-Bingo, keine Compliance-Show. Sondern ein Team von echten Ethical Hackern, das Sicherheit aus der Perspektive realer Angreifer denkt:

Der Fokus liegt klar auf manuellem Security Testing: Web-Anwendungen, APIs, Infrastrukturen und Cloud-Umgebungen. Automatisierte Tools sind dabei nur der Einstieg. Die relevanten Findings entstehen durch Erfahrung, Kreativität und das Denken wie ein echter Angreifer.

Hackeroo richtet sich an Unternehmen, die mehr wollen als einen Scan-Bericht. Keine Checklisten, keine False Positives, sondern nachvollziehbare Schwachstellen mit echtem Impact. So, wie Angriffe in der Realität auch stattfinden würden.

Kurz gesagt: Automatisierte Tools melden vieles. Hackeroo findet das, was wirklich zählt. Zu einem fairen Preis.


TCP-Port 65536 in freier Wildbahn entdeckt

Leave a Comment

Bislang ging die globale Security-Community davon aus, dass TCP-Ports bei 65535 enden. Diese Annahme war weit verbreitet, dokumentiert und in praktisch jedem Scanner auf dem Markt implementiert. Sie basiert auf einem einfachen mathematischen Problem mit 0 und 1. Die Berechnung erschien schlüssig, ließ sich leicht umsetzen und wurde dadurch zu einem unhinterfragten Industriestandard. Über Jahrzehnte hinweg haben sich Scanner, Spezifikationen und Compliance-Frameworks darauf verlassen.

Nach umfangreichen Recherchen und mehreren bestätigten Sichtungen im Rahmen manueller Security-Assessments kann ich nun offenlegen, was viele vermutet, aber nie beweisen konnten:

TCP port 65536 existiert.

Port 65536 taucht genau in dem Moment auf, in dem automatisierte Tools selbstbewusst „keine Findings“ melden und zum nächsten Ziel übergehen. In vielen Fällen wurden die kritischsten Schwachstellen kurz nachdem Verkehr auf diesem Port „beobachtet“ wurde, identifiziert.

Administratoren, die versucht haben, 65536/tcp per Firewall-Regel zu blockieren, berichten von durchgehendem Misserfolg – die Firewalls erklären übereinstimmend, dass dieser Port außerhalb des zulässigen Bereichs liegt.

Weitere Untersuchungen laufen.

Arbeiten als Senior Penetration Tester: 3 Wochen on, 1 Woche off

Leave a Comment

Die binsec GmbH sucht aktuell Verstärkung im Bereich Penetration Testing (als Teilzeit) – und geht dabei einen Weg, der in der Branche eher selten ist:

Ein echtes 3-Wochen-on und 1-Woche-off-Arbeitsmodell.

Das bedeutet:

Du arbeitest drei Wochen ganz normal an Kundenprojekten – und bekommst anschließend eine komplette Woche frei, zusätzlich zu deinem regulären Urlaub. Keine Bereitschaft, keine Meetings, kein „nur mal kurz“: eine echte Off-Week.

Warum machen wir das?

Pentesting ist kognitiv fordernd. Gute Arbeit entsteht nur, wenn man regelmäßig Raum bekommt, runterzufahren. Wir wollen ein Umfeld, in dem man langfristig leistungsfähig bleibt und gleichzeitig ein Leben außerhalb der Arbeit führen kann. Für uns gehört das zu professioneller Arbeitskultur.

Wir suchen erfahrene Penetration Tester (m/w/d) die Lust haben auf:

  • echte technische Arbeit (ohne Scanner-Getue)
  • kurze Entscheidungswege
  • direktem, ehrlichem Austausch
  • Projekte mit Abwechslung
  • ein Arbeitsmodell, das Erholung ernst nimmt

Die vollständige Stellenanzeige findest du hier:

https://binsec.com/de/jobs/senior-penetration-tester/

Was wir in Web-Penetrationstests wirklich finden – ein 12-Monats-Realitätscheck

Leave a Comment

Alle paar Monate werde ich dieselbe Frage gestellt: „Was findet ihr eigentlich typischerweise in einem Web-Pentest?“

Statt anekdotisch zu antworten, habe ich die aggregierten Daten der letzten 12 Monate aus unseren Webanwendungstests (inklusive angebundener APIs) bei der binsec GmbH ausgewertet. Das Ergebnis ist die untenstehende Grafik – und sie bestätigt die Muster, die sich seit Jahren wiederholen.

Konfigurationsfehler: Das ewige Low-Hanging-Fruit

Ein großer Teil der Findings entsteht durch einfache Konfigurationsfehler: unsichere Webserver-Defaults, fehlende Security-Header, veraltete TLS-Versionen oder schwache Cipher-Suites. Diese Schwachstellen sind leicht auffindbar und meist nicht kritisch, zeigen aber ein wiederkehrendes Problem: vielen Deployments fehlt eine grundlegende Sicherheitsbaseline. Eine einfache Checkliste würde die meisten dieser Probleme direkt vermeiden.

Session-Management: Alte Probleme in modernen Anwendungen

Fehler im Session-Handling treten überraschend häufig auf. Ein typisches Beispiel ist, dass beim Logout nur die Session im Browser entfernt wird, die serverseitige Session jedoch aktiv bleibt. Wird ein Session-Token kompromittiert, kann ein Angreifer die Session weiter nutzen – auch wenn der Nutzer sich bereits abgemeldet hat.

Wo die kritischen Schwachstellen liegen: Autorisierung

Die meisten kritischen Findings entstehen im Bereich der Autorisierung, insbesondere bei:

  • fehlender Objekt- und Ressourcenfreigabe,
  • unzureichender Rollenprüfung,
  • Privilege Escalation,
  • mangelnder Tenant-Isolation in SaaS-Systemen.

Moderne, frontend-lastige Anwendungen verstärken dieses Problem. Der Browser ruft im Hintergrund zahlreiche API-Endpunkte auf, und jeder einzelne Endpunkt benötigt eine explizite Zugriffskontrolle. Frameworks übernehmen diese Aufgabe selten automatisch. Die Implementierung erfolgt manuell. Manuelle Prozesse führen dabei zwangsläufig zu Inkonsistenzen.

Die Klassiker, die nicht aussterben

SQL Injection und Cross-Site Scripting (XSS) treten heute seltener auf, sind aber keineswegs verschwunden. ORMs, Prepared Statements und automatisches Escaping entschärfen viele Risiken, doch sobald jemand sie in der Entwicklung „nur kurz umgeht“, tauchen diese Klassiker wieder auf.

Business Logic: Selten, aber mit hoher Wirkung

Business-Logic-Schwachstellen sind weniger häufig, haben jedoch meist erhebliche Auswirkungen, wenn sie auftreten. Beispiele sind das Umgehen von Freigabeprozessen, das Manipulieren von Berechnungen oder das Überspringen notwendiger Validierungsschritte. Diese Schwachstellen erscheinen in keinem Scanner und erfordern ein tiefes Verständnis der Geschäftsprozesse.

Fazit

Die Daten bestätigen, was viele Sicherheitsteams längst wissen:

  • Die meisten Schwachstellen sind vermeidbar durch klare Konfigurationsrichtlinien und saubere Deployments.
  • Kritische Findings konzentrieren sich fast immer auf Autorisierungsfehler, nicht auf exotische Angriffstechniken.
  • Klassische Schwachstellen verschwinden nicht, solange schnelle Workarounds und Zeitdruck sichere Standards aushebeln.

Anforderungen an einen TISAX-Pentest

Leave a Comment

TISAX (Trusted Information Security Assessment Exchange) ist der branchenspezifische Sicherheitsstandard der Automobilindustrie – entwickelt vom VDA und betrieben durch die ENX Association. Er stellt sicher, dass Unternehmen nachweislich ein hohes Niveau an Informationssicherheit erfüllen und dieses vertrauenswürdig mit Partnern teilen können.

Im Rahmen von TISAX ist die regelmäßige Durchführung von Penetrationstests ein zentraler Bestandteil des technischen Sicherheitsnachweises. Sie dienen dazu, die Wirksamkeit der implementierten Schutzmaßnahmen praktisch zu überprüfen und Sicherheitslücken frühzeitig zu erkennen. So wird sichergestellt, dass Unternehmen nicht nur Richtlinien erfüllen, sondern ihre Systeme tatsächlich gegen reale Angriffe abgesichert sind.

Im Katalog Information Security Assessment 6.0.2 (ISA6 DE 6.0.2) des VDA werden an zwei Stellen die Durchführung von Penetrationstest gefordert. Das erste mal im Punkt 5.2.6 Inwieweit werden IT-Systeme und -Dienste technisch überprüft (System- und Dienst-Audit)?

Grundsätzlich gilt: Es sind System- und Dienstaudits verbindlich durchzuführen, im Voraus zu planen und mit allen Beteiligten abzustimmen. Ihre Ergebnisse müssen nachvollziehbar dokumentiert, dem Management berichtet und für die Ableitung geeigneter Maßnahmen genutzt werden. Zusätzlich sollten System- und Dienstaudits regelmäßig und risikobewusst geplant sowie von qualifiziertem Fachpersonal mit geeigneten Werkzeugen durchgeführt werden – sowohl aus dem internen Netzwerk als auch vom Internet aus. Nach Abschluss ist zeitnah ein Auditbericht zu erstellen. Auch wenn ein Penetrationstest hilft, diese Anforderungen umzusetzen, kommt die konkrete Forderung danach erst bei den Zusatzanforderungen bei hohem Schutzbedarf:

Für kritische IT-Systeme oder -Dienste wurden zusätzliche Anforderungen an das System- oder Dienst-Audit identifiziert, die erfüllt werden (z. B. dienstspezifische Tests und Werkzeuge und/oder Penetrationstests, risikobasierte Zeitintervalle)

Die nächste Erwähnung findet im Punkt 5.3.1 Inwieweit wird Informationssicherheit bei neuen oder weiterentwickelten IT-Systemen berücksichtigt? statt.

Grundsätzlich gilt: Bei Planung, Entwicklung, Beschaffung und Änderung von IT-Systemen müssen die Anforderungen an die Informationssicherheit stets ermittelt, berücksichtigt und in Sicherheits-Abnahmetests überprüft werden. Lastenhefte sollten Sicherheitsvorgaben, bewährte Verfahren und Ausfallsicherheit enthalten und vor dem produktiven Einsatz geprüft werden. Der Einsatz produktiver Daten zu Testzwecken ist zu vermeiden oder durch gleichwertige Schutzmaßnahmen abzusichern. Bei den Zusatzanforderungen bei sehr hohem Schutzbedarf wird dann wieder auf einen Penetrationstest referenziert:

Die Sicherheit von für einen bestimmten Zweck speziell entwickelter Software oder von in erheblichem Umfang maßgeschneiderter Software wird geprüft (z. B. Penetrationstests), während der Inbetriebnahme, im Falle wesentlicher Änderungen und in regelmäßigen Abständen.

Die Anforderungen an einen Penetrationstest sind zur Erfüllung von 5.2.6 vergleichsweise unspezifisch. Wird keine eigene Softwareentwicklung betrieben – weder intern noch im Auftrag – beschränkt sich der Test in der Regel auf einen externen Penetrationstest zur Überprüfung öffentlich erreichbarer Dienste (z. B. der Website) sowie auf die Analyse des internen Netzwerks. Bei klassischen IT-Landschaften liegt der Fokus dabei meist auf dem Active Directory, der Firewall und den intern erreichbaren Systemen.

Die Durchführung erweiteter Pentests wie z.B. inklusive Social Engineering, Phishing, physische Sicherheitsüberprüfungen oder DDoS-Tests sind im überschaubaren Normalfall in der Regel nicht erforderlich.

PTDoc – Dokumentation und Berichtserstellung für Penetrationstests

Leave a Comment

Die binsec GmbH setzt für ihre Penetrationstests auf PTDoc®, ein spezialisiertes Tool zur strukturierten Durchführung von Penetrationstests und professionellen Berichtserstellung. Entwickelt wurde PTDoc von der binsec systems GmbH.

Die Idee zu PTDoc entstand während des Wachstums des binsec-Teams: Wie lässt sich die Qualität konstant hochhalten, obwohl einzelne Penetrationstester unterschiedliche persönliche Schwerpunkte setzen? Und wie stellt man sicher, dass das Ergebnis eines Pentests immer identisch bleibt – unabhängig davon, welcher Senior Penetration Tester den Auftrag durchführt?

Vor PTDoc stand binsec vor der typischen Herausforderung: Soll man Berichte in Word schreiben oder mit LaTeX erstellen? Anfangs fiel die Entscheidung auf LaTeX, wodurch zwar technisch saubere, aber optisch eher „typische“ LaTeX-Dokumente entstanden. Mit PTDoc hat sich dies grundlegend geändert – heute werden daraus professionell gestaltete Reports, die im Hintergrund weiterhin auf umfangreichem LaTeX-Code basieren, jedoch über eine komfortable Oberfläche gesteuert werden können.

Kernidee des Tools ist es, für unterschiedliche Zielsysteme – etwa Active Directory, mobile Anwendungen (z. B. Android Apps) oder Netzwerke – eine einheitliche und standardisierte Vorgehensweise bereitzustellen. Das binsec-Team pflegt und erweitert die Methodik kontinuierlich und integriert etablierte Standards wie den OWASP Testing Guide, MASVS oder OSSTMM. Auf diese Weise wird eine gleichbleibend hohe Qualität sowie die exakte Wiederholbarkeit von Penetrationstests sichergestellt.

In den letzten Jahren hat sich gezeigt, dass durch diese strukturierte Vorgehensweise regelmäßig Schwachstellen identifiziert werden, die bei vorherigen Tests übersehen wurden. Ein Kunde formulierte es sogar so, dass er alle früheren Prüfungen anderer Anbieter nicht mehr als „richtige“ Penetrationstests bezeichnet.

PTDoc deckt alle drei Phasen der Pentest-Dokumentation ab:

  • Durchführung des Tests – das strukturierte Abarbeiten der definierten Vorgehensweise.
  • Erstellung der Findings – inklusive Beschreibung für den Management-Teil, detaillierter technischer Analyse, Risikobewertung (qualitativ per Ampelsystem oder quantitativ per CVSS) sowie Verwaltung von Screenshots und Evidences.
  • Berichtsgenerierung – automatische Erstellung eines konsistenten, revisionssicheren Berichts.

Auch das Nachtesten ist integriert: Stellt der Pentester fest, dass ein Kunde eine Schwachstelle behoben hat, dokumentiert er den Proof of Fix direkt im Finding. Beim erneuten Berichtsbau wird das Finding automatisch als behoben markiert und auch die Management-Zusammenfassung entsprechend aktualisiert.

Darüber hinaus unterstützt PTDoc die Erstellung von deutschen und englischen Berichten. Damit ist es für Kunden besonders einfach, Reports auf Wunsch auch in beiden Sprachen zu erhalten.

Fazit: Mit PTDoc können sich Pentester vollständig auf ihre eigentliche Arbeit – die Durchführung des Tests – konzentrieren. Gleichzeitig ist das Erstellen der Berichte einfach und schnell geworden, sodass Kunden ihre Ergebnisse zeitnah nach Abschluss des Pentests erhalten.

NIS2 und Penetrationstests – Pflicht oder Kür?

Leave a Comment

Die neue NIS2-Richtlinie der EU ist seit Anfang 2023 in Kraft. Sie betrifft nicht mehr nur klassische KRITIS-Betreiber, sondern auch eine breite Palette „wichtiger Einrichtungen“, darunter:

  • mittelgroße und große Unternehmen in Energie, Transport, Finanzwesen, Gesundheitswesen,
  • Hosting-Provider, Rechenzentren, DNS-Dienste,
  • (fast) jedes Tech-Unternehmen, das „wesentliche Dienste“ erbringt.

Die NIS2 schreibt Penetrationstests nicht explizit vor, verlangt aber Maßnahmen, deren Umsetzung ohne Penetrationstests kaum sinnvoll und prüfbar ist. Artikel 21 der Richtlinie definiert eine zentrale Pflicht:

Die Mitgliedstaaten stellen sicher, dass wesentliche und wichtige Einrichtungen geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen ergreifen, um die Risiken für die Sicherheit der Netz- und Informationssysteme, die diese Einrichtungen für ihren Betrieb oder für die Erbringung ihrer Dienste nutzen, zu beherrschen und die Auswirkungen von Sicherheitsvorfällen auf die Empfänger ihrer Dienste und auf andere Dienste zu verhindern oder möglichst gering zu halten.

Die Richtlinie nennt Penetrationstests nicht namentlich, aber sie impliziert sie mehrfach, nämlich durch die regelmäßige Prüfungen der Wirksamkeit der Maßnahmen und nach dem Stand der Technik ist das eben die Durchführung eines Penetrationstests.

Datenschutz beim Pentest: Was an personenbezogenen Daten wirklich anfällt

Leave a Comment

Was genau an personenbezogenen Daten bei einem Penetrationstest verarbeitet wird, hängt stark vom Testgegenstand ab. Grundsätzlich kann man aber die folgenden Kategorien unterscheiden.

1. Ansprechpartner beim Kunden

Ohne geht’s nicht: Der Pentester braucht Ansprechpersonen. Typischerweise werden hier Name, Position, dienstliche Mailadresse und Telefonnummer verarbeitet – in Mails, im Kalender, im Bericht. Diese Informationen sind meist ohnehin öffentlich (z. B. im Impressum oder auf LinkedIn) und dienen nur der Kommunikation. Sie werden immer verarbeitet, sind aber unkritisch.

2. Weitere Mitarbeitende des Unternehmens

Sobald das Zielsystem ein internes Netzwerk ist – vor allem mit Active Directory –, kommt man an weiteren personenbezogenen Daten kaum vorbei. Namen, Benutzernamen, oft auch Passwort-Hashes oder sogar Klartextpasswörter landen temporär auf dem Pentest-System. Das ist kein Zufall, sondern Teil der Aufgabe: Rechteausweitung, horizontale Bewegungen, Domäne-Übernahmen.

Was dabei wichtig ist: Es besteht keinerlei Grund, personenbezogene Daten dauerhaft zu speichern oder auf weitere Systeme des Dienstleisters zu übertragen. Alles, was lokal verarbeitet wird, bleibt lokal. Nur der Bericht enthält Auszüge – und auch da gilt: So wenig wie nötig. Identitäten lassen sich anonym oder pseudonymisiert darstellen.

3. Kundendaten des Auftraggebers

Wenn produktive Systeme getestet werden – zum Beispiel ein Onlineshop – kann es passieren, dass echte Kundendaten kurz sichtbar werden. Ziel ist es nicht, diese Daten zu speichern, sondern Schwachstellen zu identifizieren: Kann man z. B. fremde Bestellungen einsehen? Wenn ja, werden einzelne Datensätze für den Moment verarbeitet. Das lässt sich nicht vermeiden, ist aber so minimalinvasiv wie möglich.

Empfehlung: AV-Vertrag bei produktiven Daten

Sobald interne Systeme oder produktive Umgebungen getestet werden, sollte ein Vertrag zur Auftragsverarbeitung abgeschlossen werden. Entscheidend ist: Datenminimierung. Der Pentest soll nicht Daten sammeln, sondern Schwachstellen aufzeigen. Und das geht auch, ohne ganze Datenbanken zu kopieren.