Pentest oder Schwachstellenscan: vier Verfahren, vier Fragen
Scan, Penetrationstest, Red Team und Bug Bounty werden oft in einen Topf geworfen, beantworten aber unterschiedliche Fragen und haben unterschiedlichen Nachweiswert. Diese Seite grenzt sie ab, zeigt, was ISO 27001, NIS2 und Versicherer jeweils erwarten, und leitet daraus einen sinnvollen Rhythmus ab.
- 4 Verfahren Scan, Pentest, Red Team, Bug Bounty
- laufend Schwachstellenscans als Grundlage
- 1× jährlich Pentest, plus nach wesentlichen Änderungen
- 3 Adressaten ISO 27001, NIS2 § 30 BSIG, Versicherer
Was die vier Verfahren unterscheidet
Entscheidend sind die Frage, die beantwortet wird, der Grad an manueller Arbeit und der Nachweiswert des Ergebnisses.
| Verfahren | Beantwortet die Frage | Vorgehen | Ergebnis | Nachweiswert |
|---|---|---|---|---|
| Schwachstellenscan | Welche bekannten Schwachstellen haben unsere Systeme? | Automatisiert, signaturbasiert, breit. Erkennt Versionsstände, fehlende Patches, bekannte Fehlkonfigurationen. | Liste mit CVE-Nummern und CVSS-Werten, viele Treffer, darunter Fehlalarme. | Beleg für laufendes Schwachstellenmanagement, nicht für Angriffsresistenz. |
| Penetrationstest | Was könnte ein Angreifer in einem definierten Umfang tatsächlich erreichen? | Manuell geführt nach OWASP, PTES oder BSI-Leitfaden. Befunde werden verifiziert, ausgenutzt und zu Angriffspfaden verkettet. | Bericht mit Management-Summary, Befunden nach CVSS, Angriffspfaden, Empfehlungen; Retest nach Behebung. | Anerkannter Nachweis gegenüber Auditoren, Kunden und Versicherern, wenn Behebung und Retest dokumentiert sind. |
| Red Team | Erkennt und stoppt unsere Organisation einen realen Angriff? | Zielorientiert, verdeckt, über Wochen, gegen Technik, Menschen und Prozesse. Das Verteidigerteam ist nicht informiert. | Bericht über erreichte Ziele, Erkennungszeitpunkte, Reaktion der Organisation, Lücken in Erkennung und Prozessen. | Beleg für die Wirksamkeit von Erkennung und Reaktion; setzt reife Grundlagen voraus. |
| Bug Bounty | Was finden externe Sicherheitsforscher in unseren öffentlichen Systemen? | Offenes oder eingeladenes Programm, Meldungen werden gegen Prämie eingereicht. Kein definierter Umfang, keine garantierte Abdeckung. | Einzelmeldungen unterschiedlicher Qualität, laufend, ohne Gesamtbericht. | Ergänzung, kein Ersatz für Pentest-Nachweise. Zeigt Reife der Meldeprozesse. |
Warum ein Scan kein Pentest ist
Beide arbeiten mit denselben Schwachstellendatenbanken und CVSS-Werten. Der Unterschied liegt in dem, was danach passiert.
- Verifikation
Der Scan vermutet, der Pentest belegt
Ein Scanner meldet, dass eine Version anfällig sein könnte. Der Tester prüft, ob die Schwachstelle in Ihrer Konfiguration tatsächlich ausnutzbar ist. Das reduziert Fehlalarme und zeigt, welche der vielen Treffer wirklich zählen.
- Verkettung
Der Angriffspfad entsteht erst im Pentest
Drei mittlere Befunde können zusammen zum Domänen-Administrator führen. Ein Scanner sieht drei Einzeltreffer. Der Tester sieht den Weg. Diese Verkettung ist die wichtigste Erkenntnis eines Pentests und im Scan nicht abbildbar.
- Logik
Fehler, die keine Signatur haben
Berechtigungsfehler in Anwendungen, fehlerhafte Geschäftslogik, schwache Passwortrichtlinien, unsichere Delegationen im Active Directory: Dafür gibt es keine CVE-Nummer. Nur ein manueller Test findet sie.
- Bericht
Einordnung statt Liste
Der Scan liefert eine Liste, der Pentest eine Bewertung: Welche Frage wurde gestellt, was wurde erreicht, was ist die wichtigste Maßnahme? Das ist der Text, den Geschäftsführung, Auditoren und Versicherer lesen können.
Was ISO 27001, NIS2 und Versicherer erwarten
Keine der drei Anforderungen schreibt einen Pentest wörtlich vor. Alle drei verlangen aber Nachweise, für die ein Pentest mit Behebung und Retest das naheliegende Mittel ist.
- ISO 27001
Wirksamkeit und Schwachstellenmanagement
Die Norm verlangt, technische Schwachstellen zu handhaben und die Wirksamkeit der Maßnahmen zu bewerten. Scans belegen den laufenden Prozess, der Pentest mit Retest belegt die Wirksamkeit der technologischen Maßnahmen aus Anhang A und liefert Input für Risikobehandlung und Managementbewertung.
- NIS2, § 30 BSIG
Wirksamkeitsbewertung und Schwachstellenmanagement
Das NIS2-Umsetzungsgesetz nennt unter den zehn Maßnahmenbereichen die Bewertung der Wirksamkeit der Risikomanagementmaßnahmen sowie Sicherheit bei Erwerb, Entwicklung und Wartung einschließlich Schwachstellenmanagement. Ein regelmäßiger Pentest mit dokumentierter Behebung ist ein naheliegender Nachweis für beides.
- Cyberversicherung
Antragsfragen und Obliegenheiten
Versicherer fragen nach externen Sicherheitsprüfungen, Patch-Prozessen und Multi-Faktor-Authentifizierung. Ein aktueller Pentestbericht mit Retest beantwortet mehrere Fragen aus einer unabhängigen Quelle. Im Schadenfall kann der Nachweis regelmäßiger Prüfungen über die Regulierung entscheiden.
Was als Nachweis zählt: nicht der Bericht allein, sondern die Kette aus Scoping, Bericht, Maßnahmenplan, Behebung und Retest. Ein Pentestbericht ohne dokumentierte Behebung belegt gegenüber einem Prüfer vor allem, dass Sie von den Lücken wussten.
Wie oft welches Verfahren
Der Rhythmus folgt aus der Frage, die das Verfahren beantwortet. Scans laufend, Pentests periodisch und nach Änderungen, Red Team und Bug Bounty bei entsprechender Reife.
-
Schwachstellenscans
Automatisiert, wöchentlich oder kontinuierlich, auf alle erreichbaren Systeme. Mit Fristen für die Behebung je Schweregrad und Kennzahlen, wie viele Befunde innerhalb der Frist geschlossen wurden. Das ist die Grundlage, auf der jeder Pentest aufsetzt.
-
Penetrationstest
Mindestens einmal im Jahr für die Systeme, die im Ernstfall am meisten kosten. Regulatorische Vorgaben oder Kundenverträge können engere Rhythmen verlangen. Der Testzyklus sollte zum Auditkalender und zu den Ausschreibungsterminen passen.
-
Pentest nach wesentlichen Änderungen
Neue Anwendung oder API vor dem Go-live, Cloud-Migration, Umbau des Netzes, Zusammenschluss mit einem anderen Unternehmen, Wechsel des Identitätsdienstes. Änderungen erzeugen neue Angriffsflächen, die der Jahrestest erst Monate später sähe.
- Retest nach jedem Pentest fest einplanen
- Testfenster mit Release- und Wartungsplanung abstimmen
-
Red Team und Bug Bounty
Red Team, wenn Scans, Pentests und ein SOC oder MDR etabliert sind und die Frage nach Erkennung und Reaktion offen ist. Bug Bounty, wenn öffentliche Anwendungen vorhanden sind und die Organisation eingehende Meldungen zügig bearbeiten kann.
Welches Verfahren passt zu Ihrer Situation?
Sechs typische Ausgangslagen und das Verfahren, das dazu passt. Die Reihenfolge ist auch eine Reifegradfolge.
- Es gibt keinen regelmäßigen Scan und keine Inventarliste erreichbarer Systeme: zuerst Schwachstellenmanagement mit Scans aufbauen, dann testen.
- Scans laufen, aber niemand hat je manuell geprüft: externer Pentest, bei Kundenportalen mit Webanwendung.
- Ein Kunde, Auditor oder Versicherer fragt nach dem letzten Penetrationstest: Pentest mit Berichtsformat, das die Erwartung des Adressaten erfüllt, und Retest.
- Ein neues Portal oder eine API geht produktiv: Pentest der Anwendung vor dem Go-live, Grey Box mit Testkonten in allen Rollen.
- Pentests laufen jährlich, ein SOC oder MDR ist im Betrieb: Red Team, um Erkennung und Reaktion zu prüfen.
- Öffentliche Anwendungen, reife Meldeprozesse, Kapazität für laufende Bearbeitung: Bug Bounty als Ergänzung.
Vertiefung zu Penetrationstests
-
Arten von Penetrationstests
Extern, intern, Web/API, Cloud, Active Directory, Social Engineering, physisch. Black, Grey oder White Box und wann welche Art passt.
-
Ablauf eines Penetrationstests
Scoping, Permission to Attack, Aufklärung, Test, Bericht mit CVSS-Schweregraden, Abschlussgespräch und Retest.
-
Penetrationstests im Überblick
Testarten, Einordnung, Ablauf, Nachweise und der Selbsttest, ob Ihr Unternehmen bereit für einen Pentest ist.
Zur Abgrenzung der Verfahren
Unser Dienstleister liefert monatlich einen Scan-Bericht. Ist das unser Pentest?
Nein. Ein Scan-Bericht listet bekannte Schwachstellen anhand von Versionsständen und Signaturen. Er prüft nicht, ob eine Schwachstelle ausnutzbar ist, ob sich Befunde zu einem Angriffspfad verketten lassen oder ob die Logik einer Anwendung Fehler hat. Wenn ein Kunde, Auditor oder Versicherer nach einem Penetrationstest fragt, meint er die manuelle, methodische Prüfung mit Bericht und Retest.
Reicht ein Pentest, oder brauchen wir zusätzlich Scans?
Beides, in unterschiedlichem Rhythmus. Der Scan läuft laufend oder wöchentlich und ist die Grundlage des Schwachstellenmanagements: Er findet neue Lücken kurz nach ihrer Veröffentlichung. Der Pentest kommt periodisch und nach Änderungen und beantwortet, was ein Angreifer tatsächlich erreichen könnte. Ein Pentest in einer Umgebung ohne Scans findet vor allem das, was der Scan längst gezeigt hätte.
Wann ist ein Red Team sinnvoll?
Wenn die Grundlagen stehen: regelmäßige Scans, behobene Pentest-Befunde und ein SOC oder MDR-Dienst, der Angriffe erkennen soll. Ein Red Team prüft nicht Schwachstellen, sondern ob Ihre Organisation einen realen Angriff erkennt und stoppt. Ohne funktionierende Erkennung ist das Ergebnis absehbar und der Aufwand nicht gerechtfertigt.
Ist ein Bug-Bounty-Programm eine Alternative zum Pentest?
Eine Ergänzung, keine Alternative. Bug Bounty bringt viele Augen auf öffentlich erreichbare Systeme, aber ohne definierten Umfang, ohne garantierte Abdeckung und ohne Bericht, der als Nachweis dient. Für interne Netze, Active Directory und Cloud-Konfiguration ist es ungeeignet. Sinnvoll ist es für Unternehmen mit reifer Sicherheitsorganisation und öffentlichen Anwendungen, die eingehende Meldungen zügig bearbeiten können.
Was genau will ein Auditor sehen, wenn er nach dem Pentest fragt?
Die Kette: Scoping mit Begründung des Umfangs, Bericht mit Datum, Methodik und Befunden, Maßnahmenplan mit Verantwortlichen und Terminen, Nachweis der Behebung und den Retest-Bericht. Ein Bericht allein zeigt, dass Lücken gefunden wurden. Erst die Behebung mit Retest zeigt, dass das Schwachstellenmanagement funktioniert.
Edouard Jacques
Welches Verfahren beantwortet Ihre Frage?
Im kostenlosen Erstgespräch klären wir, wo Ihr Schwachstellenmanagement steht, welches Prüfverfahren jetzt sinnvoll ist und wie das Ergebnis zum Nachweis für ISO 27001, NIS2 und Versicherer wird.
- Einordnung: Scan, Pentest, Red Team oder erst das Fundament
- Rhythmus, der zu Auditkalender und Kundenverträgen passt
- Nachweiskette von Scoping bis Retest
Danke, wir rufen Sie an.
Sie hören innerhalb eines Werktags von uns, meist deutlich schneller. Wenn Sie lieber gleich einen festen Termin wählen möchten, geht das direkt im Kalender auf jamorie.eu.
Termin selbst wählen