4crypto.eu
Kompetenz · Offensive Tests · 2026

Penetrationstests 2026: Methoden, Umfang, TLPT und was Profis vom Scan unterscheidet

Autor: Dr. Adam Czubak Korrektorat: Alicja Czubak Lesezeit: 17 Min Aktualisiert: 2026-08-26

Ein Penetrationstest ist eine dokumentierte, kontrollierte Simulation eines realen Angriffs, durchgeführt von qualifizierten Testerinnen und Testern, um zu zeigen, welchen konkreten Schaden ein Angreifer in einer bestimmten Umgebung anrichten kann. Der Unterschied zum Schwachstellenscan liegt nicht in den Werkzeugen, sondern darin, dass ein Pentester einzelne Schwächen zu einer Kette verbindet, die zu einer konkreten geschäftlichen Folge führt - und das belegen muss.

Drei Rechtsakte haben den europäischen Markt für diese Leistungen in den vergangenen Jahren verändert. Die NIS2-Richtlinie [1] verlangt Verfahren zur Bewertung der Wirksamkeit von Risikomanagementmaßnahmen. Die DORA-Verordnung [2], anwendbar seit dem 17. Januar 2025, hat für einen Teil des Finanzsektors bedrohungsgeleitete Penetrationstests eingeführt. Der AI Act [3] wiederum hat eine völlig neue Arbeitskategorie geschaffen: das Testen der Robustheit von KI-Systemen. Der folgende Text ordnet die Begriffe, beschreibt die Methoden und zeigt, woran ein professioneller Bericht zu erkennen ist.

Pentest, Red Team, TLPT und Purple Team

Diese vier Begriffe werden oft synonym verwendet, obwohl sie Leistungen mit unterschiedlichem Zweck, Preis und Reifegrad beschreiben. Die Unterscheidung ist nicht akademisch: Von ihr hängt ab, ob die beauftragte Leistung die Frage beantwortet, die die Organisation tatsächlich hat.

Ein Pentest ist ein geplanter und mit dem Kunden abgestimmter Test in einem festgelegten Umfang - einer Webanwendung, eines internen Netzes, einer Active-Directory-Umgebung. Das Verteidigungsteam weiß in der Regel Bescheid, und das Ziel ist es, technische Lücken samt Ausnutzungsweg zu finden und zu beschreiben. Ein Red Team geht weiter: Das offensive Team spielt einen konkreten Angreifer und nutzt dessen gesamtes Repertoire, einschließlich Social Engineering und physischem Zutritt. Der entscheidende Unterschied ist, dass nicht mehr die Infrastruktur Gegenstand der Prüfung ist, sondern die Fähigkeit der Organisation, den Angriff zu erkennen und darauf zu reagieren - deshalb wird das Verteidigungsteam üblicherweise nicht informiert.

TLPT, bedrohungsgeleitete Penetrationstests, ist ein Red Team mit regulatorischem Rahmen. Das Verfahren beschreibt TIBER-EU [4], 2018 von der Europäischen Zentralbank veröffentlicht; DORA [2] hat daraus eine Pflicht für benannte Finanzunternehmen gemacht. Der Test stützt sich auf geprüfte Erkenntnisse über Bedrohungen gegen genau diese Institution, läuft unter förmlicher Beteiligung der Aufsicht ab und endet mit einem festgelegten Satz von Berichten. Ein Purple Team kehrt die Logik der anderen drei um: Offensive und Verteidigung arbeiten in Echtzeit zusammen, und das Ziel ist nicht die Überraschung der Verteidigung, sondern bessere Erkennung. Es ist der günstigste Weg, die Ergebnisse eines früheren Tests in eine echte Änderung der Monitoring-Konfiguration zu überführen.

Für die meisten Organisationen ist die sinnvolle Reihenfolge einfach. Kommunen und kleinere öffentliche Stellen beginnen mit einem externen und internen Pentest einmal jährlich. Stellen, die dem polnischen Cybersicherheitsgesetz unterliegen, ergänzen alle zwei bis drei Jahre ein im Umfang begrenztes Red Team, sobald sie ein Monitoring haben, das sich zu testen lohnt. Banken, Versicherer und Finanzmarktinfrastrukturen unter DORA müssen nach Artikel 26 der Verordnung mindestens alle drei Jahre TLPT durchführen.

Methoden: welches Rahmenwerk wählen

Es gibt keine einzige universelle Pentest-Methodik, und kein seriöser Anbieter beansprucht die Ausschließlichkeit einer einzelnen. In der Praxis werden mehrere kombiniert, weil jede einen anderen Teil der Arbeit gut beschreibt.

Am stärksten operativ ist PTES [6], das einen Test in sieben Phasen gliedert - von der Vorabstimmung über Aufklärung, Bedrohungsmodellierung, Schwachstellenanalyse und Ausnutzung bis zu Post-Exploitation und Bericht. Seine Stärke ist die Pre-Engagement-Phase, die genau das beschreibt, was am häufigsten vernachläßigt wird: Festlegung von Umfang, Rules of Engagement und Notfallverfahren. Das ältere OSSTMM 3 [7] von 2010 bringt etwas ein, was den anderen fehlt: eine formale Metrik der Angriffsfläche, mit der sich aufeinanderfolgende Tests zahlenmäßig und nicht nur beschreibend vergleichen lassen. NIST SP 800-115 [8] ist weniger detailliert, hat aber den Status einer anerkannten Referenz und ordnet Netztests gut; ihm ist ein eigener Artikel gewidmet.

Für die Anwendungsebene bleibt OWASP WSTG [9] in der Version 4.2 der Bezugspunkt - eine Prüfliste für Webanwendungen in zwölf Kategorien, von Aufklärung und Konfiguration über Authentisierung und Autorisierung bis zu Geschäftslogik, Client-Seite und API. Ihr mobiles Gegenstück ist das OWASP MASTG samt dem Anforderungsmodell MASVS. Für regulierte Tests liefert TIBER-EU [4] den Verfahrensrahmen, und der CREST-Standard [10] hilft, die Kompetenz des Anbieters zu prüfen.

Die praktische Wahl richtet sich also nach dem Prüfgegenstand und nicht nach der Vorliebe des Anbieters: die externe Angriffsfläche nach PTES ergänzt um WSTG, das interne Netz und Active Directory nach PTES und NIST SP 800-115, mobile Anwendungen nach MASTG, Tests für den Finanzsektor nach TIBER-EU. Die bloße Nennung einer Methodik sagt wenig, wenn im Bericht keine Spur davon zu sehen ist.

Wie viel soll die Testerin wissen

Die zweite Achse der Wahl ist der Umfang der Informationen, die vor Beginn übergeben werden. Im Modell Black Box gibt es nichts, und die Arbeit beginnt genau dort, wo ein realer Angreifer aus dem Internet steht. Dieses Modell bildet die Ausgangslage eines Angriffs am treuesten ab, doch ein erheblicher Teil der bezahlten Zeit geht für Aufklärung drauf, die die Organisation in einer Stunde hätte liefern können. Im Modell White Box liegen Architekturdokumentation, Quellcode und privilegierte Konten vor, was die höchste Abdeckung und die meisten Feststellungen bringt, allerdings auf Kosten des Realismus.

In der Praxis überwiegt Grey Box, bei dem Benutzerkonten und Grundwissen zur Architektur übergeben werden. Das entspricht dem häufigsten realen Szenario - einem Angreifer, der bereits fremde Zugangsdaten besitzt - und lässt das Budget in die Prüfung der Schutzmaßnahmen fließen statt in das Erraten. Die Regel ist einfach: Je stärker der Test die Erkennung messen soll, desto weniger Informationen; je stärker er die Vollständigkeit der Schutzmaßnahmen messen soll, desto mehr.

Für eine typische Kommune mit einigen Dutzend Arbeitsplätzen und wenigen Servern ist Grey Box von innen und Black Box aus dem Internet die sinnvolle Kombination. White Box lohnt sich vor allem für Individualanwendungen, deren Geschäftslogik und Rechtemodell einzigartig sind; ohne diese Kenntnis kann die Testerin bestenfalls raten, welcher Übergang zwischen Prozessschritten ein Missbrauch ist.

Was der Bericht enthalten muss

Ein Pentest-Bericht ist keine nach CVSS sortierte Schwachstellenliste. Er ist ein Dokument für drei verschiedene Lesergruppen mit drei verschiedenen Fragen.

Die Geschäftsleitung braucht zwei Seiten ohne Fachjargon: wie viele Angriffspfade zu schwerwiegenden Folgen führen, wie das schlimmste realistische Szenario aussieht und wie die Gesamtwiderstandsfähigkeit einzuordnen ist. Das Sicherheitsteam braucht etwas anderes - eine Darstellung nach Angriffsketten statt nach Einzelfeststellungen. Eine Kette ist die Abfolge der Schritte vom Einstiegspunkt bis zur Folge, und erst sie zeigt, dass drei mittlere Schwachstellen zusammen eine kritische Wirkung entfalten können, die keine von ihnen allein hat. Das Team für die Behebung braucht wiederum eine Liste von Positionen mit Beschreibung, Nachweis, Reproduktionsschritten, Empfehlung und Zuordnung zu MITRE ATT&CK [5] und CWE.

Der beste Qualitätstest eines Berichts ist die Reproduzierbarkeit. Der Satz "es gelang, administrative Rechte zu erlangen" ist keine Feststellung; eine Feststellung ist eine Befehlsfolge mit Zeitstempeln, die jemand mit entsprechendem Zugang wiederholen und dasselbe Ergebnis sehen kann. Ein Red-Team-Bericht ergänzt eine Erkennungs-Zeitachse - minutengenau, was die Verteidigung bemerkt hat und was nicht. Das ist meist der wertvollste Teil des Dokuments, weil er konkrete Lücken im Monitoring benennt (siehe Artikel zum SOC). Ein TLPT-Bericht folgt der von TIBER-EU [4] vorgegebenen Struktur: Bedrohungsbericht, Testbericht, Zusammenfassung für die Aufsicht und Abschlussdokument mit Maßnahmenplan.

Die häufigsten Fehler

Der häufigste Fehler ist der Kauf eines Schwachstellenscans unter dem Namen Pentest. Einen automatischen Scanner laufen zu lassen und seine Ausgabe in ein Dokument zu übertragen ist einen Bruchteil des Preises eines Penetrationstests wert und erzeugt zugleich ein trügerisches Gefühl der Prüfung. Ein professioneller Test beginnt mit Bedrohungsmodellierung und manueller Verifikation; der Scanner ist darin ein Hilfsmittel, keine Inhaltsquelle. Automatisches Scannen hat seine eigene sinnvolle Rolle - beschrieben im Artikel zum Schwachstellenscan -, aber es ist eine ergänzende Rolle, die deutlich häufiger und günstiger ausgeführt wird.

Der zweithäufigste Fehler ist ein zu enger Umfang. Ein Auftrag, der auf eine einzige Webanwendung begrenzt ist, lässt DNS, Aufklärung aus offenen Quellen, das interne Netz und den Mitarbeitervektor außen vor. Nach dem DBIR 2026 [11] war der häufigste Erstzugangsvektor die Ausnutzung einer Schwachstelle mit 31 Prozent, vor dem Missbrauch von Zugangsdaten mit 13 Prozent - also genau die Bereiche, die ein solcher Umfang ausschließt.

Der dritte Fehler betrifft den Auftragnehmer. Die Berufsbezeichnung ist nicht geschützt, deshalb lohnt sich der Blick auf Zertifikate, Akkreditierung [10] und Erfahrung in einer Umgebung wie der eigenen. Ein Sonderfall ist die Vergabe an den eigenen IT-Dienstleister: günstiger und bequemer, aber das Ergebnis ist ein Bericht, der die Arbeit seines eigenen Verfassers bewertet - und damit genau die Funktion verliert, wegen der er beauftragt wurde.

Die übrigen drei Fehler betreffen das Umfeld des Tests. Ein Test in der Produktion ohne abgestimmten Notfallplan kann einen Dienst lahmlegen - alte Netztechnik reagiert mitunter empfindlich auf Verkehr, den niemand als Angriff bezeichnen würde. Ein Bericht ohne Nachtest ausgewählter Feststellungen lässt offen, ob die Korrekturen überhaupt gewirkt haben. Und nach jedem Test lohnt die Frage, was das eigene Monitoring von diesen Aktivitäten aufgezeichnet hat und welche Alarme ignoriert wurden; das ist die einzige Gelegenheit, die Erkennung an einem im Voraus bekannten Angriff zu messen.

Rechtsakte, die Tests verlangen

Keiner der in Polen geltenden Rechtsakte nennt das Wort "Pentest" ausdrücklich als allgemeine Pflicht, doch mehrere verlangen ein Ergebnis, das ohne einen solchen Test kaum zu erreichen ist. NIS2 [1] nennt in Artikel 21 Absatz 2 unter den Risikomanagementmaßnahmen sowohl den Umgang mit Schwachstellen (Buchstabe e) als auch Konzepte zur Bewertung der Wirksamkeit der ergriffenen Maßnahmen (Buchstabe f); in Polen gilt das novellierte Cybersicherheitsgesetz in der Fassung seit dem 3. April 2026 (siehe Artikel zu NIS2). Die DSGVO [12] verlangt in Artikel 32 Absatz 1 Buchstabe d ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit technischer und organisatorischer Maßnahmen, was Anwendungen mit personenbezogenen Daten einschließt.

Die konkretesten Anforderungen stellt der Finanzsektor. DORA [2] teilt das Testen in zwei Ebenen: ein Basisprogramm zum Test der digitalen operationalen Resilienz für alle erfassten Unternehmen sowie TLPT, mindestens alle drei Jahre verlangt von Unternehmen, die die zuständige Behörde benennt - in Polen die Finanzaufsicht KNF (siehe Artikel zu DORA). Außerhalb des Unionsrechts hat die Kartenbranche eigene Vorgaben: PCI DSS in der Version 4.0 verlangt Penetrationstests mindestens jährlich und nach wesentlichen Änderungen.

Die Norm ISO/IEC 27001:2022 [13] ist kein Rechtsakt, doch ihr Anhang A nennt Maßnahmen, deren Wirksamkeitsnachweis unmittelbar zu Tests führt - A.5.7 zur Bedrohungsaufklärung und A.8.29 zur Sicherheitsprüfung in Entwicklung und Abnahme. Eine eigene Kategorie bildet der AI Act [3], dessen Artikel 15 von Hochrisikosystemen ein angemessenes Maß an Genauigkeit, Robustheit und Cybersicherheit verlangt - nachzuweisen unter anderem durch adversariales Testen (siehe Artikel zum AI Act).

Am schnellsten wächst das Testen von Systemen auf Basis großer Sprachmodelle. Mit ihrem Einzug in die tägliche Arbeit ist eine Problemklasse entstanden, die ein klassischer Pentest nicht abdeckt: Prompt Injection über Eingabedaten, das Umgehen von Modellgrenzen, Datenabfluss aus dem Kontext und der Missbrauch von Rechten, die Integrationen erhalten haben. Der AI Act [3] gibt dieser Arbeit für Hochrisikosysteme eine regulatorische Grundlage, doch die Methoden sind hier merklich weniger reif als beim Testen von Webanwendungen.

Die zweite Richtung ist der Übergang vom Einzeltest zur laufenden Leistung im Abonnement, mit fortlaufend gelieferten Ergebnissen und Anbindung an das Ticketsystem. Das Modell bewährt sich bei häufig geänderten Anwendungen, wo ein jährlicher Testzyklus immer eine veraltete Version prüft. Es ersetzt jedoch keinen tiefen Test - es ändert die Häufigkeit, nicht die Tiefe.

Die dritte Richtung ist die Abkehr von generischen Tests hin zu Szenarien, die Angreifer abbilden, die sich für die konkrete Organisation tatsächlich interessieren. Im Finanzsektor übernimmt TIBER-EU [4] diese Rolle; in anderen Sektoren ist die von ENISA [14] veröffentlichte Bedrohungslage ein Ausgangspunkt, ergänzt um die Berichte von CERT Polska [15], die tatsächlich beobachtete Kampagnen gegen polnische Ziele beschreiben.

Was vor der Beauftragung zu klären ist

Über den Wert eines Tests entscheiden gut ein Dutzend Festlegungen, die vor der Vertragsunterzeichnung fallen. Es lohnt sich, sie in dieser Reihenfolge zu besprechen.

Beginnen Sie mit Umfang und Ziel. Der Umfang ist eine konkrete Liste von Adressen, Domänen, Anwendungen, Netzsegmenten und - falls Social Engineering dazugehört - Beschäftigtengruppen, samt einer ebenso klaren Angabe dessen, was draußen bleibt. Das Ziel wird oft übergangen, prägt aber die gesamte Arbeit: Ein Test zum Nachweis der Konformität sieht anders aus als einer zur Bewertung der Gesamtwiderstandsfähigkeit und wieder anders als die vertiefte Prüfung einer einzelnen Anwendung. Aus dem Ziel folgen das Zugriffsmodell und die gewählte Methodik, und beide Entscheidungen sollten im Bericht eine Spur hinterlassen.

Die zweite Fragengruppe betrifft den Auftragnehmer und die Durchführung. Klären Sie die Qualifikation der konkreten Personen, nicht nur die des Unternehmens, und halten Sie die Rules of Engagement schriftlich fest: Testzeiten, eine während des Tests erreichbare Ansprechperson, den Eskalationsweg und den Umfang erlaubter Handlungen. Gesondert zu entscheiden ist, ob gefundene Schwachstellen ausgenutzt werden dürfen, ob nach erlangtem Zugang eine Bewegung im Netz zuläßig ist und ob mit echten Daten gearbeitet wird - Entscheidungen von anderem Gewicht als ein bloßer Scan.

Die dritte Gruppe betrifft, was nach dem Test bleibt. Neben dem Berichtsformat sollte vorab geklärt sein, ob ein Nachtest der schwerwiegendsten Feststellungen im Preis enthalten ist und in welcher Frist, und es sollten Vertraulichkeit und Haftung geregelt werden: eine Geheimhaltungsvereinbarung, eine benannte verantwortliche Person auf Anbieterseite, eine Versicherung und ein Verfahren zur Löschung der während der Arbeit erhobenen Daten.

Häufig gestellte Fragen

Pentest oder Red Team - was ist die richtige Wahl?

Beim ersten offensiven Test ein Pentest. Sein Zweck ist es, technische Schwachstellen zu finden und zu beheben. Ein Red-Team-Einsatz lohnt sich erst nach den ersten zwei bis drei Pentests, wenn die Organisation ein reifes SOC und belastbare Verfahren hat und wissen will, wie sie sich in einer echten Krise verhalten würde.

Wie lange dauert ein Pentest einer Webanwendung?

Eine typische CMS-Anwendung: 5 bis 7 Personentage. Eine typische Individualanwendung wie ein Bürgerportal oder ein Patientenportal: 8 bis 15 Personentage. Eine große Fachanwendung: 15 bis 30 Personentage. Als Produkt mit festem Umfang ab 10 000 PLN netto; Individualarbeit wird einzeln kalkuliert.

Kann ein Pentest die Produktion beschädigen?

Bei professioneller Durchführung sehr selten und nur nach vorheriger Absprache, etwa bei einem Exploit oder einem Denial-of-Service-Test. Ein Standard-Pentest ist störungsfrei. In unserer Projekthistorie liegt die Quote unter einem Prozent; der typische Fall ist alte Layer-2-Netztechnik, die intensives ARP-Scanning nicht verträgt.

Darf unser eigener IT-Dienstleister den Pentest durchführen?

Unabhängigkeit ist vorzuziehen, weil sie Interessenkonflikte reduziert; sie ist jedoch keine allgemeine gesetzliche Vorgabe für jeden Pentest. Ein IT-Dienstleister kann den Test durchführen, wenn Aufgaben getrennt, Kompetenzen nachgewiesen und der Interessenkonflikt transparent behandelt werden. Bestimmte Vorschriften, Verträge oder Prüfungsrahmen können dennoch externe oder organisatorisch unabhängige Testende verlangen.

Was gilt als erfolgreicher Pentest?

Keine kritischen Feststellungen können ein valides Ergebnis sein und beweisen für sich allein weder Sicherheit noch einen mangelhaften Test. Erfolg bemisst sich an einem angemessenen Umfang, einer geeigneten Methodik, belastbaren Nachweisen und ausreichender Abdeckung sowie an der anschließenden risikobasierten Behebung und Nachprüfung. Eine allgemein vertretbare Sollzahl hoher oder kritischer Feststellungen gibt es nicht.

Was genau ist TLPT nach DORA?

Threat-Led Penetration Testing nach TIBER-EU [4] - die Simulation eines realen Angreifers auf Grundlage von Bedrohungsinformationen zum konkreten Kunden. Erforderlich für Finanzunternehmen, die die zuständige Behörde benennt, in Polen die KNF. Zyklus: mindestens alle drei Jahre. Dauer: 12 bis 30 Wochen. Kosten: 200 000 bis 800 000 PLN, unter Beteiligung der Aufsicht.

Umfasst ein Red-Team-Einsatz Social Engineering und physischen Zutritt?

Das ist möglich, jedoch nur, wenn Social Engineering und physischer Zutritt in den schriftlichen Rules of Engagement ausdrücklich enthalten sind. Die Genehmigung sollte zulässige Handlungen, Orte, Zeiträume, Eskalationskontakte und Abbruchbedingungen festlegen. Sie belegt die Zustimmung des Auftraggebers im vereinbarten Umfang; eine Befragung oder vorläufige Festnahme kann sie nicht ausschließen, und Handlungen außerhalb des Umfangs deckt sie nicht ab.

Was tun, wenn ein Pentest keine kritischen Feststellungen ergab?

Das ist ein Ergebnis, das weiterhin eingeordnet werden muss. Vor einer Schlussfolgerung sind insbesondere folgende Punkte zu prüfen:

  1. Unzureichende Kompetenz - eine Junior-Kraft mit einem Scanner statt erfahrener Pentester. Prüfen Sie Methodik und ihre Spuren im Bericht.
  2. Zu enger Umfang - ein reiner Webanwendungstest lässt Netzvektor, Active Directory und Lieferkette außen vor.
  3. Die Umgebung bildet die Produktion nicht ab - getestet wurde auf einem sterilen Entwicklungs- oder Staging-System ohne echte Daten und Konfiguration.
  4. Zu wenig Zeit - zwei bis drei Personentage für eine Enterprise Web App reichen nicht.

PTES [6] und NIST SP 800-115 [8] geben Hinweise zur Dokumentation von Umfang, Randbedingungen und Testplan. Null kritische Feststellungen können eine widerstandsfähige Umgebung widerspiegeln, aber auch aus einer zu engen Abdeckung oder einem ungeeigneten Testdesign folgen; der Bericht sollte eine Unterscheidung ermöglichen.

Reicht ein Black-Box-Test einer Webanwendung aus?

Für eine klassische CMS-Anwendung wie WordPress oder Drupal: ja, Black Box genügt meist. Für eine Individualanwendung - Bürgerportal, Patientenportal, Fachverfahren - nein: empfohlen sind Grey Box oder White Box, denn:

  • Geschäftslogik und Autorisierung sind die Bereiche, in denen Black Box am schwächsten abschneidet. Die Kategorien Business Logic Testing und Authorization Testing im OWASP WSTG [9] setzen Kenntnis von Rollen, Rechten und vorgesehenem Ablauf voraus. Ohne dieses Wissen kann die Testerin nur raten, welcher Übergang zwischen Schritten ein Missbrauch und welcher ein normaler Pfad ist.
  • PTES [6] empfiehlt im Abschnitt Threat Modeling Zugang zur Architekturdokumentation bei Individualanwendungen.
  • Der Aufwand verlagert sich bei einem Black-Box-Test auf Aufklärung und Funktionskartierung, sodass innerhalb desselben Budgets weniger Zeit für vertiefte Prüfungen bleibt.

Bewährte Praxis: Grey Box mit zwei bis drei Konten unterschiedlicher Rollen, dazu Black Box als eigener Teil zur Validierung der External Attacker Perspective.

Ist ein Pentest von OT- und SCADA-Geräten sicher?

Nur mit einem eigens OT-erfahrenen Team und der Methodik IEC 62443 [16]. Aktives Testen von Steuergeräten wie SPS und RTU kann sie physisch beschädigen - Pufferüberläufe in alter Firmware, Denial of Service gegen einen Watchdog, Race Conditions. Die Leitlinien von ICS-CERT und NIST SP 800-82 Rev. 3 (auch im SOC-Artikel zitiert) lauten:

  • Passiver Modus - Mitschnitt des Verkehrs, statische Konfigurationsanalyse - in der Produktion.
  • Aktiver Pentest vorzugsweise auf einem repräsentativen Prüfstand oder während einer geplanten Abschaltung. Tests in der Produktion erfordern eine dokumentierte Risikobewertung, ausdrückliche Genehmigung, abgestimmte Schutzmaßnahmen und zum industriellen Prozess passende Abbruchbedingungen.
  • Zusammenarbeit mit dem Anlagenbetrieb - Testende ohne Kenntnis des technologischen Prozesses können eine Notabschaltung auslösen.
Die Testerin will ein Implantat im Netz platzieren - ist das legal und sicher?

Ja in beiderlei Hinsicht, unter drei Bedingungen:

  1. Schriftliche Genehmigung in den Rules of Engagement, mit Typ des Implantats (C2-Beacon, Persistence-Agent), Ort im Netz, Laufzeit und Entfernungsmechanismus. Ohne sie droht ein Verstoß gegen die Artikel 267 bis 269b des polnischen Strafgesetzbuchs.
  2. Isolierte C2-Umgebung - der Verkehr des Implantats darf nicht ungeschützt ins offene Internet gelangen.
  3. Ein Cleanup-Verfahren - nach dem Test wird das Implantat entfernt und die Entfernung nachgewiesen, über C2-Protokolle und eine Prüfung auf dem Endgerät. PTES [6] verlangt das im Abschnitt Post-Exploitation Cleanup ausdrücklich.

Ein Implantat ist Standardtechnik in Red Team und TLPT [4]. Ohne es lässt sich die Erkennung von Persistence nicht prüfen (MITRE ATT&CK TA0003 [5]).

Worin unterscheidet sich ein Pentest einer mobilen Anwendung von einem Web-Pentest?

Die wichtigsten methodischen Unterschiede nach dem OWASP MASTG (Mobile Application Security Testing Guide):

  • Statische Codeanalyse (APK oder IPA) als erster Schritt - Obfuskation, fest einkodierte Geheimnisse, schwache Kryptografie.
  • Dynamische Analyse - Runtime-Hooking mit Frida, Umgehung von Anti-Debug und Certificate Pinning.
  • Backend-API - oft der größere Teil der Angriffsfläche, geprüft nach OWASP WSTG [9].
  • Datenablage - Analyse von SharedPreferences und UserDefaults, temporären Dateien und Keychain.

Aufwand: typischerweise das 1,5- bis 2-Fache eines Web-Pentests vergleichbarer Komplexität.

Brauchen Sie Beratung in diesem Bereich?

Eine kostenlose 30-60 minütige Beratung. Ohne Verpflichtungen. Wir besprechen Bedarf, Umfang und einen groben Zeitplan.

Anrufen: +48 691 122 312 office@4crypto.eu

Verwandte Inhalte

Weitere Kompetenzbereiche

Compliance und Regulierung

Bibliografie und Quellen

Alle zitierten Quellen sind öffentlich zugänglich. ISO/IEC-Normen, IETF-RFCs, EU-Richtlinien und nationale Rechtsakte verweisen auf die Originaldokumente.

  1. [1]regulationParlament Europejski, Rada UE (2022). Dyrektywa (UE) 2022/2555 (NIS2) w sprawie środków na rzecz wysokiego wspólnego poziomu cyberbezpieczeństwa. Dziennik Urzędowy UE, L 333, 27.12.2022 · https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32022L2555
  2. [2]regulationParlament Europejski, Rada UE (2022). Rozporządzenie (UE) 2022/2554 (DORA) w sprawie operacyjnej odporności cyfrowej sektora finansowego. Dziennik Urzędowy UE, L 333, 27.12.2022 · https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32022R2554
  3. [3]regulationParlament Europejski, Rada UE (2024). Rozporządzenie (UE) 2024/1689 (AI Act) ustanawiające zharmonizowane przepisy dotyczące sztucznej inteligencji. Dziennik Urzędowy UE, L seria, 12.7.2024 · https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32024R1689
  4. [4]guidelineEuropean Central Bank (2018). TIBER-EU Framework: Threat Intelligence-Based Ethical Red Teaming. ECB · https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html
  5. [5]standardMITRE Corporation (2024). MITRE ATT&CK Framework v15 (Enterprise, Mobile, ICS). MITRE · https://attack.mitre.org/
  6. [6]guidelinePTES Team (2014). Penetration Testing Execution Standard (PTES). pentest-standard.org · http://www.pentest-standard.org/
  7. [7]guidelineHerzog, P. (ISECOM) (2010). Open Source Security Testing Methodology Manual (OSSTMM) 3. Institute for Security and Open Methodologies · https://www.isecom.org/OSSTMM.3.pdf
  8. [8]standardScarfone, K., Souppaya, M., Cody, A., Orebaugh, A. (2008). NIST SP 800-115: Technical Guide to Information Security Testing and Assessment. National Institute of Standards and Technology · DOI: 10.6028/NIST.SP.800-115
  9. [9]guidelineOWASP Foundation (2024). OWASP Web Security Testing Guide (WSTG) v4.2. OWASP · https://owasp.org/www-project-web-security-testing-guide/
  10. [10]guidelineCREST (2023). CREST Defensible Penetration Test Standard. CREST International · https://www.crest-approved.org/
  11. [11]reportVerizon Business (2026). 2026 Data Breach Investigations Report (DBIR). Verizon, wydanie 19. Zbiór obejmuje incydenty zarejestrowane od 1 listopada 2024 r. do 31 października 2025 r. · https://www.verizon.com/business/resources/reports/dbir/
  12. [12]regulationParlament Europejski, Rada UE (2016). Rozporządzenie (UE) 2016/679 (RODO) w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych. Dziennik Urzędowy UE, L 119, 4.5.2016 · https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32016R0679
  13. [13]standardInternational Organization for Standardization (2022). ISO/IEC 27001:2022 - Information security, cybersecurity and privacy protection - Information security management systems - Requirements. ISO/IEC · https://www.iso.org/standard/27001
  14. [14]reportEuropean Union Agency for Cybersecurity (ENISA) (2025, wersja 1.2 z 9 stycznia 2026 r.). ENISA Threat Landscape 2025. ENISA · https://www.enisa.europa.eu/publications/enisa-threat-landscape-2025
  15. [15]reportCERT Polska / NASK (2024). Raport roczny CERT Polska 2023. NASK PIB, Warszawa · https://cert.pl/uploads/docs/Raport_CP_2023.pdf
  16. [16]standardInternational Electrotechnical Commission (2018). IEC 62443 - Industrial communication networks - Network and system security. IEC · https://www.iec.ch/cyber-security
4crypto.eu