Autorisierte Sicherheitsprüfung

Pentest-Vorbereitung

Ein Penetrationstest ist ein autorisierter Versuch, die Schutzmaßnahmen eines Systems zu umgehen. Dabei können Methoden realer Angreifer zum Einsatz kommen. Der Zweck bleibt defensiv. Scope und Sicherheitsregeln setzen klare Grenzen.

Gute Vorbereitung macht das Ergebnis brauchbar. Verantwortliche und Testende müssen sich vorab auf Fragestellung, Erlaubnis, Scope, Regeln und nächste Schritte einigen.

Ein Pentest beantwortet eine begrenzte Frage

Ein Pentest beantwortet nicht die breite Frage: 'Ist dieses System sicher?' Er beantwortet eine konkrete Frage. Kann ein normaler Nutzer fremde Kundendaten lesen? Kann ein kompromittiertes Konto Admin-Funktionen erreichen? Führt ein offener Dienst zu sensiblen Daten?

Ein Schwachstellenscan sucht nach bekannten Mustern. Ein Pentest verbindet Werkzeuge mit menschlichem Urteil und untersucht mögliche Angriffspfade innerhalb des vereinbarten Rahmens.

Dieser Rahmen ist keine bloße Bürokratie. Er macht den Test autorisiert. Alles außerhalb der schriftlichen Regeln bleibt außerhalb des Tests, auch wenn es technisch erreichbar ist.

Das Ergebnis soll klare Nachweise, umsetzbare Korrekturen und Erkenntnisse für künftige Arbeit liefern. Ein spektakulärer Fund allein reicht nicht.

So wird ein Penetrationstest vorbereitet und durchgeführt

Rechtliche und betriebliche Grenzen müssen so klar sein wie das technische Ziel. Diese Schritte führen von der ersten Frage bis zum Retest.

01 · Entscheidung klären
Halte fest, warum du den Test beauftragst und welche Entscheidung er unterstützen soll: ein Release, Nachweise für Kunden, eine wesentliche Architekturänderung oder die unabhängige Prüfung des eigenen Schwachstellenmanagements.
02 · Erlaubnis bestätigen
Ermittle die Verantwortlichen jedes Zielsystems und hol ausdrückliche schriftliche Freigaben ein. Cloud-, Hosting-, Zahlungs-, Identitäts- und andere Drittdienste können eigene Regeln oder Genehmigungen verlangen. Dass dir eine Anwendung gehört, erlaubt noch nicht den Test jeder Abhängigkeit.
03 · Scope aufbauen
Liste Anwendungen, APIs, Hostnamen, Adressen, Umgebungen, Rollen und wichtige Datenflüsse auf. Halte Ausschlüsse und geteilte Infrastruktur fest. Ein guter Scope beschreibt Systeme und Vertrauensgrenzen. Die URL einer Startseite reicht nicht aus.
04 · Testregeln vereinbaren
Halte Zeitraum, erlaubte Testarten, Rate Limits, verbotene Handlungen und Abbruchbedingungen fest. Regeln braucht es auch für Quelladressen, Kommunikation und Scope-Änderungen. Denial-of-Service, Social Engineering, Persistenz und destruktive Aktionen bleiben ohne ausdrückliche Freigabe ausgeschlossen. Bei echter Angreiferaktivität wird der Test pausiert und der Incident-Response-Prozess gestartet.
05 · Zugänge und Sicherheit vorbereiten
Stelle repräsentative Testkonten, Rollenbeschreibungen, korrekte Dokumentation, sichere Testdaten und eine technische Ansprechperson bereit. Entscheide bewusst zwischen Produktion und einer ausreichend realistischen Testumgebung. Prüfe Backups und Monitoring, und plane Rollback oder Eindämmung für unerwartete Auswirkungen.
06 · Nachweise schützen
Vereinbare den Umgang mit Zugangsdaten, Kundendaten, Screenshots, Request-Traces, Exporten und dem Bericht. Diese Daten müssen minimiert, verschlüsselt und sicher übertragen werden. Lege auch Aufbewahrung und Vernichtung fest. Testnachweise können selbst zum Sicherheitsproblem werden.
07 · Mit Checkpoints testen
Der Anbieter führt die vereinbarte Prüfung aus. Er hält die benannte Ansprechperson auf dem Laufenden. Kritische Funde und betriebliche Probleme werden sofort eskaliert. Entdeckungen außerhalb des Scopes werden gemeldet. Das Team verfolgt sie nicht ohne Freigabe weiter.
08 · Berichten und besprechen
Der Bericht braucht eine kurze Zusammenfassung, den genauen Scope, Grenzen, Methodik und nachvollziehbare Belege. Zu jedem bestätigten Fund gehören Risiko, betroffene Systeme und umsetzbare Korrekturen. Unbestätigte Beobachtungen müssen klar als solche markiert sein.
09 · Beheben und nachprüfen
Weise Verantwortliche und Fristen zu. Behebe die Ursachen und teste verwandte Pfade auf Regressionen. Ein Retest prüft vereinbarte Funde in einer späteren Version. Er wiederholt nicht den gesamten Auftrag. Auch die Abwesenheit anderer Schwächen kann er nicht belegen.

Die Prüfung passend zur Frage wählen

Security-Prüfungen überschneiden sich, beantworten aber unterschiedliche Fragen. Der Name allein sagt noch nicht, welche Nachweise ein Team bekommt.

Schwachstellenscan

Ein Schwachstellenscan sucht automatisch nach Systemen, Konfigurationsmerkmalen und bekannten Fehlern. Das Verfahren ist wiederholbar und eignet sich für breite Abdeckung. Die Ergebnisse müssen jedoch validiert werden. Meist zeigen sie nicht, wie sich Schwächen im fachlichen Kontext kombinieren lassen.

Penetrationstest

Eine zeitlich begrenzte Prüfung aus Werkzeugen und menschlicher Analyse. Sie untersucht, ob Schwächen innerhalb eines benannten Scopes Sicherheitskontrollen umgehen oder relevante Auswirkungen haben können. Sie geht tiefer und ist invasiver als ein regulärer Scan, bleibt aber eine Stichprobe.

Security-Review

Ein Security-Review prüft Anforderungen, Architektur, Konfiguration, Kontrollen oder Betriebspraktiken. Als Maßstab dienen definierte Risiken oder Standards. Der Begriff bezeichnet keine feste Methodik. Der Auftrag muss deshalb die geprüften Unterlagen und Umgebungen benennen.

Code-Review

Ein Code-Review prüft, wie Sicherheitsentscheidungen umgesetzt sind. Es kann unsichere Datenflüsse, fehlende Autorisierung und Logikfehler zeigen. Ob die produktive Konfiguration genauso arbeitet, belegt es nicht.

Red-Teaming

Red-Teaming bildet das Vorgehen eines passenden Angreifers über Menschen, Prozesse und Technik hinweg nach. Es prüft Prävention, Erkennung und Reaktion. Es soll meist nicht jede Schwachstelle einer Anwendung finden.

Incident Response

Arbeit nach einem tatsächlichen oder vermuteten schädlichen Ereignis: Auswirkungen bestätigen, eindämmen, Nachweise sichern, Ursache beseitigen und sicher wiederherstellen. Ein geplanter Pentest kann Kontrollen prüfen, ersetzt aber keine Reaktion auf einen laufenden Vorfall.

Fragen, die vor dem Test geklärt sein sollten

Ein guter Anbieter klärt diese Fragen vor dem Start und erklärt die wichtigsten Abwägungen.

Welche konkrete Frage soll der Test beantworten, und welche Risiken sind für uns besonders wichtig?
Welche benannte Person führt den Test durch, und welche relevante Erfahrung, Qualifikationen oder erforderlichen Akkreditierungen kann der Anbieter belegen?
Welche Methodik und Abdeckung sind vorgesehen, und was wird nicht geprüft?
Welche Konten, Dokumentation, Quelltexte, Architekturinformationen oder früheren Scanergebnisse verbessern die Prüfung?
Welche Handlungen sind verboten, gedrosselt oder brauchen eine neue Freigabe?
Wer ist während des Tests erreichbar, und wie schnell werden kritische Funde oder Betriebsstörungen eskaliert?
Wie werden Nachweise und Zugangsdaten geschützt, aufbewahrt, zurückgegeben und vernichtet?
Welche Berichte, Besprechungen, Behebungsunterstützung und Retests sind in Preis und Zeitplan enthalten?

Beispiel: Scope für eine kleine SaaS-Anwendung

Ein kleines Team bereitet eine Rechnungsplattform auf den ersten Unternehmenskunden vor. Vor dem Release will es Mandantentrennung und Admin-Zugriffe unabhängig prüfen lassen. Die konkrete Frage lautet: Kann ein externer Nutzer oder ein normales Mitglied auf fremde Datensätze oder privilegierte Funktionen zugreifen?

Der Scope nennt Webanwendung, öffentliche API, Authentisierungsablauf und Adminbereich. Die Prüfung läuft in einer produktionsnahen Staging-Umgebung. Das Team stellt synthetische Daten und mehrere Konten bereit. Dazu gehören Administration, Standardmitglied und gesperrtes Mitglied. Zahlungsanbieter, Unternehmens-E-Mail, Mitarbeiterkonten, Denial-of-Service und Social Engineering sind ausgeschlossen. Geteilte Drittsysteme brauchen eine separate Erlaubnis.

Die Testregeln legen Arbeitszeiten, Quelladressen, Request-Limit, Notfallkontakte und einen sofortigen Meldeweg für mandantenübergreifenden Zugriff oder Instabilität fest. Das Team prüft Backups und Logging, vereinbart verschlüsselte Nachweise mit fester Löschfrist und plant eine erreichbare Entwicklungsperson für kurzfristige Rückfragen ein.

Der Bericht belegt einen Fehler in der Mandantentrennung und beschreibt eine serverseitige Korrektur. Das Team repariert die gemeinsame Autorisierungsfunktion, ergänzt Regressionstests und beauftragt einen Retest. Der bestätigt die Korrektur im neuen Build. Eine Garantie für die gesamte Plattform ist das trotzdem nicht.

Häufige Fehler bei Scope und Einordnung

Fehler vor dem Test oder nach dem Bericht mindern den Nutzen. Sie senken die Sicherheit, begrenzen die Abdeckung oder verhindern wirksame Korrekturen.

Ohne vollständige Erlaubnis testen

Die Freigabe eines Anwendungsverantwortlichen deckt möglicherweise weder Hosting-Plattform und geteiltes Netz noch Lieferanten, Kundendaten oder Systeme einer anderen juristischen Person ab. Eigentum und Anbieterrichtlinien müssen vorher geklärt sein.

'Alles testen' als Scope schreiben

Ein unbestimmter Scope verbirgt Annahmen über Umgebungen, APIs, Rollen, mobile Clients und Drittdienste. Für Zeit, Sicherheit, Abdeckung und Preis fehlt beiden Seiten eine belastbare Grundlage.

Einen Scannerbericht als Pentest kaufen

Automatisierung kann eine breite, wiederholbare Erhebung unterstützen. Ein Penetrationstest braucht zusätzlich Kontextanalyse, sorgfältige Validierung und menschliche Untersuchung relevanter Pfade. Frag, wer diese Arbeit leistet und wie sie im Bericht sichtbar wird.

Produktion unvorbereitet prüfen

Ein Produktivtest kann Nachweise aus dem realen Betrieb liefern. Er kann aber die Verfügbarkeit beeinträchtigen oder echte Daten verändern. Die Entscheidung muss bewusst fallen. Betrieb, risikoarme Methoden sowie Abbruch- und Wiederherstellungswege gehören zur Planung.

Den Bericht als Zertifikat behandeln

Ein Bericht beschreibt die Untersuchung unter festgelegten Bedingungen. Ein sauberes Ergebnis bedeutet nur, dass diese Stichprobe kein Problem gezeigt hat. Es beweist nicht die Abwesenheit von Schwachstellen.

Funde beheben, aber nicht die Ursache testen

Nur die im Nachweis gezeigte Codezeile zu ändern kann denselben Autorisierungs- oder Validierungsfehler an anderer Stelle bestehen lassen. Behebe die gemeinsame Ursache, ergänze Regressionstests und lege fest, was der Retest prüft.

Freigabe, Koordination und Verantwortung

Die Systemverantwortlichen bleiben für Test und Risiken zuständig. Ein Anbieter kann Scope und Korrekturen empfehlen. Er darf seine Erlaubnis nicht selbst erweitern. Jede Aktivität braucht die Freigabe einer befugten Stelle. Externe oder intrusive Tests gehören in einen unterschriebenen Scope oder Vertrag. Bei Bedarf ist rechtliche Beratung nötig.

Ein Pentest ist eine zeitgebundene Stichprobe. Scope, Zugang, Umgebung, Zeit, Methode und Erfahrung prägen das Ergebnis. Ein bestätigter Fund beweist eine Schwachstelle unter diesen Bedingungen. Fehlende Funde beweisen keine vollständige Sicherheit.

Behandle Bericht und Nachweise als sensible Daten. Gib Korrekturen klare Verantwortliche und Prioritäten. Ein Retest muss nennen, welche Funde, Version und welches Datum er abdeckt.

Jedes Ziel und jede Aktivität schriftlich autorisieren
Technische Kontakte und Risikoverantwortliche benennen
Ausschlüsse als ausdrückliche Grenzen dokumentieren
Kritische Funde und Betriebsstörungen sofort eskalieren
Nachweise nach vereinbartem Zeitplan schützen und vernichten
Behebung und Umfang des Retests getrennt nachverfolgen

Das Wichtigste in Kürze

01Beginne mit der Entscheidung, die der Test unterstützen soll.
02Kläre Erlaubnis, Scope und Testregeln schriftlich vor dem Start.
03Wähle die Prüfart passend zur Frage.
04Bereite Konten, Kontakte, sichere Daten, Monitoring und Nachweise vor.
05Verlange klare Belege, Grenzen, Kontext und umsetzbare Korrekturen.
06Behandle das Ergebnis als datierte Stichprobe und prüfe behobene Funde erneut.

Quellen und weiterführende Literatur

Eine kompakte Auswahl an Primärquellen, Standards und öffentlich zugänglicher technischer Orientierung, auf die sich dieser Artikel stützt.