Was ein Penetrationstest ist und wann ein Unternehmen ihn braucht

Schwachstellenscan, Audit und Penetrationstest sind drei verschiedene Arbeiten zu drei verschiedenen Preisen. Welche beantwortet Ihre Frage, und was das deutsche Recht tatsächlich verlangt.

Sie fragen ein Angebot für die Sicherheit Ihrer Website an und erhalten drei, die sich um das Zehnfache unterscheiden, und auf einem steht „Schwachstellenscan“, auf dem zweiten „Sicherheitsaudit“, auf dem dritten „Penetrationstest“, aber in allen dreien steht dasselbe Wort „Sicherheit“, das von dem, was sich unterscheidet, nichts sagt. Das ist nicht eine Arbeit in drei Stufen und nicht drei Preise für dasselbe, sondern drei verschiedene Arbeiten, die drei verschiedene Fragen beantworten, deshalb ist der erste Schritt nicht der Preisvergleich, sondern zu verstehen, auf welche dieser drei Fragen Sie tatsächlich eine Antwort wollen.

Dieser Artikel beantwortet zwei: was ein Penetrationstest ist, und ob er gerade für Ihr Unternehmen nötig ist. Die zweite Frage ist die wichtigere, weil für die meisten kleinen und mittleren Unternehmen in Deutschland kein Rechtsakt einen Penetrationstest namentlich verlangt, und ein Angebot, das das verschweigt, verkauft Ihnen die richtige Leistung im falschen Moment.

Wir schreiben das, obwohl wir ein Website-Sicherheitsaudit verkaufen, und darin liegt kein Widerspruch, weil ein Audit, in dem Platz für eine manuelle Prüfung ist, und ein Penetrationstest, den eine Regelung verlangt, nicht dieselbe Arbeit sind, und ein Unternehmen, das das zweite kauft, wenn es das erste gebraucht hätte, mehr bezahlt und weniger erfährt.

Drei Arbeiten, die unter ähnlichen Namen verkauft werden

Die Fachsprache ist hier unsauber, aber darunter liegt eine klare Grenze, die eine Standardisierungsstelle am besten benennt: NIST SP 800-115 definiert den Penetrationstest als Sicherheitstest, bei dem Prüfer echte Angriffe nachahmen, um Wege um den Schutz des Systems herum zu finden, und hält fest, dass dabei Kombinationen von Schwachstellen gesucht werden, nicht einzelne Befunde. Dieselbe Veröffentlichung beschreibt den Schwachstellenscan als Verfahren, mit dem Ressourcen und die dazu bekannten Schwachstellen ermittelt werden.

In der Praxis heißt das vier verschiedene Arbeiten, die jede für sich benannt gehören. Ein Schwachstellenscan ist automatisch, und dabei vergleicht ein Werkzeug Ihr System mit einer Datenbank bekannter Schwachstellen und liefert eine Liste. Eine Schwachstellenanalyse ist dieselbe Liste, die ein Mensch geprüft und geordnet hat, in der Regel ohne eine der gefundenen Schwachstellen auszunutzen. Ein Penetrationstest ist von Menschen geführte Arbeit, in der gefundene Schwachstellen ausgenutzt und zu einer Kette verbunden werden, um festzustellen, wie weit ein Angreifer wirklich kommt. Ein Compliance-Audit beantwortet eine ganz andere Frage: ob das System einem genannten Standard oder einer genannten Norm entspricht.

Die Grenze zwischen den ersten dreien zieht am klarsten der Zahlungskartenstandard, und er tut das nicht mit einer Definition, sondern mit dem Ziel: die Leitlinien des PCI Security Standards Council unterscheiden den Penetrationstest vom Scan nach dem Zweck: der Scan ermittelt, ordnet und berichtet Schwachstellen; der Test sucht Wege, sie auszunutzen, um den Schutz des Systems zu umgehen. In seinem Standard hält der Council beide Seiten fest: ein Scan allein ist kein Penetrationstest, und ein Test, der nur versucht, die Befunde des Scanners auszunutzen, ist ebenfalls nicht ausreichend.

Deshalb ist die Frage „brauchen Sie einen Penetrationstest“ keine Frage nach dem Budget, sondern danach, worauf Sie eine Antwort wollen: ob es in Ihrem System bekannte Schwachstellen gibt, oder ob jemand mit ihnen tatsächlich etwas anrichten kann.

Was jede davon beantwortet und was sie nicht sagt

Der Scan antwortet schnell und günstig, und seine Schwäche ist der Kontext, weil das Werkzeug nicht weiß, welche der hundert markierten Zeilen auf Ihrem Zahlungsformular liegt und welche in einer Testumgebung, die niemand vom Internet aus erreicht, und es weiß auch nicht, dass zwei für sich harmlose Fehler zusammen den Zugang zur Datenbank geben — deshalb ist die Liste der Beginn der Arbeit, nicht ihr Ergebnis.

Der Penetrationstest antwortet langsamer und teurer, und sein Wert liegt genau in der Kette, weil der Tester nicht nach „gibt es hier eine Schwachstelle“ sucht, sondern nach „was kann ich damit tun“ — ob man vom öffentlichen Formular zu Administratorrechten kommt, ob man aus dem Konto eines Kunden die Daten eines anderen sieht, ob man von der Testumgebung die Produktivdatenbank erreicht. Die Antwort auf diese Frage ist die, die eine Geschäftsleitung ohne Übersetzung versteht.

Ein Compliance-Audit tut weder das eine noch das andere, weil es prüft, ob das System einer Norm entspricht, und sein Ergebnis ein Urteil über die Konformität ist, keine Liste technischer Schwächen; genau deshalb kann ein Unternehmen ein Compliance-Audit bestehen und in derselben Woche gehackt werden, und darin liegt kein Widerspruch, weil zwei Dokumente zwei verschiedene Fragen beantworten.

Keine dieser Arbeiten ersetzt die übrigen, und keine von ihnen ist „besser“ als die anderen, deshalb ist die einzige sinnvolle Frage die, welche von ihnen gerade das beantwortet, was Sie tatsächlich wissen müssen.

Die Namensverwirrung ist kein bloßes Sprachproblem, und man sieht das, wenn man Märkte vergleicht: in Finnland, Schweden und Norwegen verkauft der Markt zwei Arbeiten — den Scan und den Penetrationstest — und die mittlere Variante hat keinen Namen; sie gilt als Ergebnis des Scans, nicht als eigene Leistung. In Deutschland ist es umgekehrt, weil dort ein Wort oft alle drei Arbeiten bezeichnet, den Test selbst eingeschlossen, und genau deshalb ist beim Vergleich von Angeboten der Name der schwächste mögliche Anhalt, und die einzige sichere Frage bleibt, ob die gefundenen Schwachstellen ausgenutzt werden.

Ob das Gesetz ihn gerade von Ihnen verlangt

Hier lohnt sich Genauigkeit, weil das die Stelle ist, an der Angebote am häufigsten übertreiben: in Deutschland verlangt kein Gesetz namentlich einen Penetrationstest von jedem Unternehmen, das eine Website betreibt.

Das BSI-Gesetz, das am 6. Dezember 2025 in Kraft getreten ist und die Richtlinie (EU) 2022/2555 umsetzt, legt Pflichten für besonders wichtige Einrichtungen und wichtige Einrichtungen fest: Risikomanagementmaßnahmen, eine verantwortliche Geschäftsleitung, Registrierung und die Meldung erheblicher Sicherheitsvorfälle. Einen Penetrationstest nennt das Gesetz selbst in keinem Paragraphen.

Tests nennt das BSI in seinen Hinweisen zu den Risikomanagementmaßnahmen, indem es „regelmäßige Tests (z. B. Penetrationstests, Notfallübungen)“ zu den bekannten Verfahren zählt, mit denen Einrichtungen die Wirksamkeit ihrer Maßnahmen bewerten — aber nur für die informationstechnischen Systeme, Komponenten und Prozesse, die sie für die Erbringung ihrer Dienste nutzen. Dasselbe Gesetz erlaubt dem Bundesamt, gegenüber besonders wichtigen Einrichtungen Audits, Prüfungen oder Zertifizierungen durch unabhängige Stellen anzuordnen.

Das sind zwei Bedingungen zusammen, nicht eine: ein Unternehmen, das keine betroffene Einrichtung ist, erhält aus diesem Punkt keine Pflicht, und eine betroffene Einrichtung, deren konkretes System den regulierten Dienst nicht trägt, ebenfalls nicht, deshalb ist der erste Schritt nicht die Anfrage eines Angebots, sondern die Einschätzung, ob Sie überhaupt in den Anwendungsbereich fallen.

Wie Sie erkennen, ob Sie betroffen sind

Das BSI-Gesetz zählt Unternehmen nicht namentlich auf, sondern beschreibt Sektoren und Größe, und die Pflicht, den eigenen Status zu bewerten, liegt beim Unternehmen selbst, was in der Praxis zwei Fragen bedeutet: ob Ihre Tätigkeit in eine der im Gesetz genannten Arten fällt, und ob die Größe des Unternehmens die vorgesehene Schwelle erreicht. Beide müssen Sie selbst beantworten, und die Antwort ist zu dokumentieren — genau deshalb ist der erste Aufwand auf diesem Feld in der Regel eine rechtliche Beratung, nicht eine technische Leistung.

Lautet die Antwort „nein“, gelten die weiteren Punkte zu den Systemen, die einen regulierten Dienst tragen, für Sie überhaupt nicht, und lautet die Antwort „ja“, kommt die zweite Frage, zu welchem dieser Systeme der Dienst tatsächlich gehört. Die Erwartung eines Penetrationstests hängt an diesen Systemen, nicht am Betroffenenstatus als solchem, und ein Unternehmen kann betroffen sein, ohne dass diese Erwartung auf eines seiner Systeme zutrifft.

Es gibt auch einen dritten Weg, der keine bestimmte Systemklasse voraussetzt: das Bundesamt kann gegenüber besonders wichtigen Einrichtungen im Einzelfall Audits, Prüfungen oder Zertifizierungen anordnen. Das ist keine planbare Pflicht, aber ein Grund zu wissen, wer auf Ihrer Seite auf ein solches Verlangen antworten würde.

Die übrigen Schwellen nennen Tests, nicht den Penetrationstest

Artikel 32 der Datenschutz-Grundverordnung verlangt ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der Sicherheitsmaßnahmen, und der Umfang der Anforderung hängt am Risiko. Das ist nicht dasselbe wie die Pflicht, einmal im Jahr einen Penetrationstest zu beauftragen, und ein Angebot, das Artikel 32 so darstellt, gibt die Verordnung lockerer wieder, als sie geschrieben ist. Die Pflicht nachzuweisen, dass überhaupt getestet wird, ist echt; die Pflicht, gerade diese Art der Tests zu wählen, folgt aus Artikel 32 nicht.

Anforderung 11.4 des Zahlungskartenstandards PCI DSS nennt den Penetrationstest ausdrücklich, alle zwölf Monate und nach wesentlichen Änderungen, aber das ist eine vertragliche Pflicht und betrifft, wie Sie Karten annehmen. Ein Internetshop, der Zahlungen vollständig an einen Zahlungsdienstleister weiterleitet und selbst keine Kartendaten verarbeitet, und alle anderen, in deren Umgebung Kartendaten gelangen, beantworten diese Anforderung unterschiedlich. Das ist eine Frage, auf die Ihr Acquirer antwortet, nicht ein Artikel.

Im Finanzsektor verlangt die Verordnung (EU) 2022/2554 regelmäßige Tests, und bedrohungsorientierte Penetrationstests (TLPT) sieht sie nur für diejenigen Institute vor, die die Aufsicht eigens bestimmt hat. Die Norm ISO/IEC 27001 verlangt das Management von Schwachstellen und Sicherheitstests, ohne den Penetrationstest namentlich zu fordern; die Behauptung, ohne ihn werde keine Zertifizierung erteilt, ist verbreitet und in der Norm nicht zu finden.

Trifft keine dieser Schwellen auf Sie zu, dann haben Sie keine rechtliche Pflicht, einen Penetrationstest zu beauftragen, und das heißt nicht, dass nichts zu tun wäre, sondern dass die Arbeit eine andere ist.

Wenn keine Schwelle überschritten ist

Für ein Unternehmen, das nicht betroffen ist, keine Kartendaten verarbeitet und nicht im Finanzsektor tätig ist, ist die sinnvolle Arbeit in der Regel die, die regelmäßig geschieht, nicht einmal in drei Jahren. Das sind Updates, für die es einen Verantwortlichen und eine Frist gibt; Backups, die jemand einmal wiederhergestellt und sich vergewissert hat, dass sie sich wirklich wiederherstellen; Multi-Faktor-Authentifizierung (MFA) für Administratorkonten, die das BSI-Gesetz für betroffene Einrichtungen gesondert nennt und die für alle anderen ebenso nützlich ist; und regelmäßiges Scannen, dessen Ergebnisse jemand tatsächlich liest.

Das ist keine kleinere Form der Antwort, sondern eine andere Art von Arbeit. Die meisten Einbrüche, mit denen wir arbeiten, beginnen nicht mit einem ausgeklügelten Angriff, sondern mit einer nicht aktualisierten Komponente oder mit einem Passwort, das auch anderswo galt, und ein Penetrationstest, der alle drei Jahre stattfindet, schützt davor nicht. Wenn Ihre Website bereits gehackt wurde, ist die Reihenfolge eine andere, und das beschreibt ein eigener Artikel darüber, wie Sie eine gehackte Website wiederherstellen.

Ein Penetrationstest wird dann begründet, wenn es etwas zu verlieren gibt und wenn der Umfang des Verlusts größer ist als der Preis des Tests: ein System, in dem Daten anderer Menschen liegen, eine Integration, die Geld berührt, oder ein Auftraggeber, der einen Nachweis verlangt. Bis zu diesem Moment ist es die richtige Arbeit in der falschen Reihenfolge.

Was während des Tests geschieht

Die Arbeit beginnt mit der Festlegung des Prüfumfangs und endet mit einem Bericht, und dazwischen liegen drei Phasen, die man verstehen sollte, bevor man Angebote vergleicht, weil gerade sie erklären, warum ein Test kostet, was er kostet, und warum ein anderer für dasselbe System zehnmal weniger kostet.

Die erste Phase ist die Aufklärung, in der der Tester alles sammelt, was sich über das System von außen erfahren lässt — welche Adressen öffentlich sind, welche Technologien und Versionen sichtbar sind, wo Anmeldeformulare liegen, welche Dateien ohne Autorisierung erreichbar sind. In dieser Phase wird noch nichts ausgenutzt, aber genau hier sitzen am häufigsten Befunde, die niemand erwartet hat: eine vergessene Testumgebung, ein offenes Verzeichnislisting, ein Backup, das unter einer vorhersehbaren Adresse liegt.

Die zweite Phase ist die Prüfung selbst, in der automatische Werkzeuge laufen, damit Bekanntes nicht übersehen wird, die Entscheidungen aber ein Mensch trifft, der prüft, ob ein Befund echt ist, versucht, ihn auszunutzen, und schaut, was er damit gewinnt. Hier entsteht die Kette — Zugang zu einem Konto, von dort zu einer Funktion, die nicht erreichbar sein sollte, von dort zu Daten. Für sich ist keiner der Schritte dramatisch; zusammen sind sie eine Geschichte.

Die dritte Phase ist das Nachweisen und Festhalten, weil zu jedem Befund ein Beweis bleiben muss, den man wiederholen kann: welche Anfrage gesendet wurde, wie die Antwort lautete, was sich geändert hat. Ohne das ist der Bericht eine Meinung, und der Entwickler, der ihn erhält, verbringt einen Tag damit zu verstehen, was der Tester eigentlich gesehen hat.

Deshalb sind auch die Fristen, wie sie sind: der Test einer kleinen Website dauert ein paar Tage, ein System mit mehreren Rollen, Integrationen und Zahlungen aber Wochen, und ein Angebot, das einen vollständigen Penetrationstest an einem einzigen Tag verspricht, beschreibt nicht den Test, sondern einen Scan.

Warum Angebote sich um das Zehnfache unterscheiden

Wenn zwei Angebote für dieselbe Website um den Faktor zehn auseinanderliegen, liegt der Unterschied fast nie in der Marge und fast immer im Umfang und in der Methode: das eine bietet einen automatischen Scan mit einem Werkzeug, das in einer Stunde startet und dessen Bericht dasselbe Werkzeug erzeugt, das andere eine Woche menschlicher Arbeit, in der die Werkzeuge nur der Anfang sind, und genau diesen Unterschied verdeckt der Name „Sicherheitsprüfung“ in beiden Fällen.

Der zweite preisbildende Faktor ist die Komplexität des Systems, und die lässt sich beurteilen, bevor das Gespräch beginnt: eine öffentliche Website ohne Benutzerkonten ist eine Arbeit, ein System mit mehreren Rollen, Zahlungen, einer externen Integration und Daten, die Kunden gehören, eine ganz andere, weil jede Rolle eine eigene zu prüfende Grenze ist und jede Integration eine Stelle, an der zwei Systeme einander mehr vertrauen, als sie sollten.

Der dritte ist, was Sie nach dem Test erhalten und wie lange der Auftragnehmer dabei bleibt: ein Bericht ohne Prioritäten, ohne Belege und ohne erneute Prüfung kostet weniger, weil er weniger Arbeit ist, und für ein Unternehmen, das die Befunde danach beheben muss, entscheiden genau diese drei Dinge, ob das Dokument zur Aufgabenliste wird oder zu einem Ordner, den niemand mehr öffnet.

Deshalb lassen sich Angebote nach dem Preis nur vergleichen, wenn der Prüfumfang gleich geschrieben ist, und der einfachste Weg dahin ist, den Umfang selbst zu schreiben und alle zu bitten, darauf anzubieten, statt jedem Auftragnehmer zu erlauben, den seinen selbst zu definieren.

Wann ein Test veraltet

Das Ergebnis eines Penetrationstests beschreibt ein bestimmtes System an einem bestimmten Datum, was offensichtlich ist, und dennoch entsteht genau hier der größte Teil des Missverständnisses zwischen Auftragnehmer und Auftraggeber, weil ein Bericht, der ein Jahr alt ist, Code beschreibt, der sich seither Dutzende Male geändert hat.

Die geschriebenen Intervalle räumen das selbst ein: das BSI spricht von „regelmäßigen“ Tests ohne festen Kalender im Gesetz, und im Zahlungskartenstandard steht neben dem Jahresintervall „nach wesentlichen Änderungen“, sodass der Kalender, wo er steht, nur das Minimum ist, der eigentliche Grund zu testen aber eine Änderung.

Praktisch heißt das, dass ein neuer Testgrund eine Änderung ist, die die Angriffsfläche verändert: eine neue öffentliche Funktion, eine neue Integration mit einem externen System, ein Wechsel der Authentifizierung, der Umzug auf anderes Hosting, eine neue Benutzerrolle mit weiteren Rechten. Ein Farbwechsel oder eine Textkorrektur wird zu keinem solchen Grund, so sichtbar sie auch ist.

Der andere Grund ist, dass sich die Umgebung geändert hat, nicht Ihr Code: eine Schwachstelle in einem Framework, das Sie nutzen, wird nach dem Test bekannt, und ein Test, der sie nicht erwähnte, hat sich nicht geirrt, weil es sie damals noch nicht gab. Deshalb sind regelmäßiges Scannen und ein Updateprozess das, was zwischen den Tests geschieht, und der Test ersetzt sie nicht.

Ohne Erlaubnis des Eigentümers sind dieselben Handlungen rechtswidrig

Ein Penetrationstest unterscheidet sich technisch nicht von einem Angriff, und das Einzige, was sie unterscheidet, ist ein Dokument: die Erlaubnis des Eigentümers, in der Prüfumfang, Zeit und Grenzen genannt sind, und die schriftlich festzuhalten sich lohnt, auch wenn das Gesetz diese Form nicht ausdrücklich verlangt. Ohne sie sind dieselben Handlungen dieselben Handlungen, und das hat rechtliche Folgen — in Deutschland ist der unbefugte Zugang zu besonders gesicherten Daten nach § 202a des Strafgesetzbuches strafbar.

Praktisch heißt das, dass derjenige die Erlaubnis erteilt, dem das System gehört, nicht derjenige, der es betreut. Läuft Ihre Website bei einem Hosting-Anbieter, muss auch der Anbieter wissen, dass der Test stattfindet, weil sonst seine Abwehr ihn stoppt oder Ihr Konto sperrt. Enthält das System eine Komponente eines Dritten, die Sie nicht steuern, gehört sie nicht in den Prüfumfang.

Die Grenzen des Umfangs müssen vorher geschrieben werden, nicht danach, und auf dieser Liste steht, welche Adressen im Umfang sind und welche nicht, ob wir die Produktivumgebung oder eine Kopie testen, was geschieht, wenn der Test den Dienst unterbricht, und wer auf Ihrer Seite nachts erreichbar ist; dieses Gespräch dauert eine Stunde und löst den größten Teil der Streitigkeiten, die sonst mitten im Test entstehen.

Was ein Test nicht ist: Red-Team, Bug-Bounty und Konformitätsprüfung

Neben dem Penetrationstest gibt es mehrere Arbeiten, die gern denselben Namen tragen, und die Unterschiede zwischen ihnen sind nicht akademisch, sondern praktisch — sie entscheiden, was Sie beauftragen und was Sie erhalten.

Eine Red-Team-Übung prüft nicht das System, sondern die Abwehr: ob Ihre Leute und Prozesse einen Angriff bemerken und was sie tun. Der Umfang ist weiter, die Dauer länger, und ein Teil des Werts liegt genau darin, dass die verteidigende Seite nicht weiß, dass eine Übung stattfindet. Für ein Unternehmen, das nichts zu bemerken hat, weil niemand die Protokolle liest, ist diese Arbeit verfrüht.

Bug-Bounty ist ein Modell, kein Test: Sie veröffentlichen Regeln und zahlen für Befunde denen, die sie einsenden. Das kann finden, was ein einzelner Tester übersehen hat, gibt aber weder eine Garantie des Umfangs noch eine Frist noch einen Bericht, den man Vergabeunterlagen beilegen kann.

Bedrohungsorientierte Penetrationstests (TLPT) sind eine eigene, beaufsichtigte Arbeit im Finanzsektor, und sie sind in einer Verordnung der Europäischen Union definiert. Ist Ihr Unternehmen kein von der Aufsicht bestimmtes Finanzinstitut, hat dieser Begriff in Ihrem Angebot nichts zu suchen.

Eine weitere Grenze, die gern verwischt wird, ist die zwischen „Black-Box“, „White-Box“ und „Grey-Box“ — wie viel der Tester über das System schon zu Beginn weiß. Das ist eine Branchenvereinbarung, keine gesetzliche Anforderung, und sie hat unmittelbare Wirkung auf den Preis und darauf, was der Test finden wird. Ein Tester ohne Zugang ahmt einen Fremden nach; ein Tester mit Konto und Dokumentation erreicht in derselben Zeit mehr. Keine der Varianten ist die richtigere; die Frage ist, wovor Sie sich fürchten.

Was Sie erhalten und wie Sie es lesen

Das Ergebnis des Tests ist ein Bericht, und sein Wert liegt in den Prioritäten, nicht in der Zahl der Befunde, weil ein Bericht mit hundert Zeilen, in denen nicht steht, womit man anfängt, genau so unbrauchbar ist wie der Ausdruck eines Scanners. Ein guter Bericht sagt zu jedem Befund, was ein Angreifer damit tun kann, wie leicht, und was konkret zu ändern ist.

Das Zweite, das zu verlangen ist, ist eine Prüfung nach den Korrekturen, weil ein Befund, der behoben ist, und ein Befund, von dem jemand denkt, er sei behoben, sich voneinander unterscheiden, und der einzige Weg, das festzustellen, ist, noch einmal zu prüfen. Wir tun das innerhalb von dreißig Tagen nach den Korrekturen, und diese Frist lohnt sich, von jedem Auftragnehmer zu verlangen.

Das Dritte ist, was Ihr Entwickler mit dem Bericht tun wird. Ein Befund, der mit einer CVE-Nummer und ohne Kontext beschrieben ist, bedeutet für den Entwickler Suche; ein Befund, dem die konkrete Anfrage und die Stelle im Code beigefügt sind, bedeutet eine Korrektur. Macht ein Unternehmen die Entwicklung und ein anderes den Test, ist dieser Unterschied der, der entscheidet, ob die Korrekturen in einer Woche oder in einem Quartal geschehen.

Das Vierte ist, was im Bericht nicht stehen darf: die Behauptung, das System sei jetzt sicher. Ein Test zeigt, was im vereinbarten Umfang am vereinbarten Datum gelungen ist. Er beweist nicht, dass es nichts anderes gibt, und ein Auftragnehmer, der das verspricht, verkauft Ihnen Beruhigung.

Es gibt noch einen Grund, warum es sich lohnt, dieses Gespräch früher zu beginnen, als nötig scheint: ein Test, der eine Woche vor der Inbetriebnahme stattfindet, findet dasselbe, was er drei Monate früher gefunden hätte, aber für die Behebung der Befunde bleiben weder Zeit noch Budget, und in der Praxis endet das mit einer Liste, die man als Risiko hinnimmt, nicht mit Korrekturen, deshalb ist die Logik, vor der Inbetriebnahme zu testen, so geschrieben, wie sie ist, und dieselbe Logik gilt auch für diejenigen, die diese Anforderung nicht bindet.

Und das Letzte, das klar gesagt gehört: ein Penetrationstest ist kein Nachweis, dass das System sicher ist, sondern ein Nachweis, dass an einem bestimmten Datum in einem bestimmten Umfang eine bekannte Fähigkeit keinen Weg über etwas Bestimmtes hinaus gefunden hat, und deshalb ist der wertvollste Teil des Berichts oft nicht die Liste der Befunde, sondern die Beschreibung dessen, was versucht wurde und nicht gelang, weil genau dieser Teil dem nächsten Tester nach drei Jahren sagt, wo es sich nicht lohnt, bei null zu beginnen.

Was vor dem Gespräch vorzubereiten ist

Damit ein Angebot überhaupt vergleichbar ist, muss der Auftragnehmer den Prüfumfang kennen, deshalb bereiten Sie eine Liste der Adressen und Systeme vor, die dazugehören, sagen Sie, ob wir die Produktivumgebung oder eine Kopie testen, sagen Sie, was im System ist, an das man nicht rühren darf, und nennen Sie einen Menschen, der erlauben kann, den Test zu stoppen.

Produktivumgebung oder Kopie

Das ist die Frage, die Preis und Risiko entscheidet, weil ein Test in der Produktivumgebung zeigt, was tatsächlich erreichbar ist, und genau deshalb etwas beschädigen kann: überlasten, die Datenbank mit Testdatensätzen füllen, Kunden echte E-Mails schicken oder in einer Abwehr hängen bleiben, die den Tester sperrt und danach auch einen Teil Ihrer Nutzer.

Ein Test auf einer Kopie ist sicherer und zugleich unvollständiger, weil eine Kopie selten identisch ist: oft fehlen die echten Integrationen, das echte Datenvolumen und die echte Konfiguration, und gerade in der Konfiguration sitzt häufig das Problem. Wählen Sie eine Kopie, schreiben Sie auf, womit sie sich von der Produktivumgebung unterscheidet, weil diese Liste auch die Liste dessen ist, was der Test nicht geprüft hat.

Der Mittelweg, den wir am häufigsten nutzen: Lesevorgänge in der Produktivumgebung, Schreibvorgänge und potenziell zerstörerische auf einer Kopie, mit einem zuvor vereinbarten Fenster und einem Menschen, der stoppen kann. Das ist kein Kompromiss um des Preises willen, sondern ein Weg, die Antworten beider Varianten zu bekommen, ohne die Arbeit zu unterbrechen.

Nützlich ist auch die Gegenteilsliste, nämlich das, was nicht im Prüfumfang liegt, weil stillschweigend angenommene Grenzen die sind, über die man später streitet. Dienste Dritter, die Sie nicht betreiben, gehören nicht hinein, und sie ohne Erlaubnis dieser Dritten zu testen ist dasselbe Problem, von dem der vorige Abschnitt handelt. Nutzt Ihre Website ein externes Zahlungsfenster, ein externes Chatfenster oder externe Analytics, sind das fremdes Eigentum, und ein Angebot, das verspricht, sie „auch zu prüfen“, verspricht, was es nicht darf.

Sagen Sie schließlich, was mit den Befunden danach geschieht: wer sie behebt, in welcher Frist, und ob der Auftragnehmer nach den Korrekturen noch einmal prüft. Ein Test ohne diese Vereinbarung endet oft mit einem Dokument, das niemand öffnet, und das ist die teuerste mögliche Fassung: bezahlt für Wissen, das nicht genutzt wird.

Sagen Sie auch, welche Antwort Sie suchen, weil „wir müssen eine Anforderung erfüllen“ und „wir wollen wissen, ob jemand an Kundendaten herankommt“ zwei verschiedene Arbeiten zu zwei verschiedenen Preisen sind, und ein Auftragnehmer, der nicht fragt, welche von ihnen die Ihre ist, wird die anbieten, die ihm bequemer ist.

Wenn Sie nicht sicher sind, auf welcher Seite der Schwelle Sie stehen, lohnt es sich, damit zu beginnen. Das Website-Sicherheitsaudit beantwortet die Frage nach den bekannten Schwachstellen in der Regel günstiger und schneller als manuelle Expertenarbeit, und sein Ergebnis sagt auch, ob ein Penetrationstest der nächste Schritt ist. Ein Gespräch über den Prüfumfang sollte mit einer Beschreibung des Prozesses beginnen, nicht mit einer Liste von Technologien, weil den Umfang das bestimmt, was Sie verlieren, wenn das System versagt.