BAS, ASM, Pentest, Red Teaming: Welche Prüfung leistet was?

Der Markt für Sicherheitsprüfungen ist unübersichtlich geworden. Neben dem klassischen Penetrationstest werben Anbieter mit Breach and Attack Simulation, Attack Surface Management, Continuous Penetration Testing, Purple Teaming, Red Teaming und – für Finanzunternehmen – Threat-Led Penetration Testing. Jedes Verfahren verspricht, Ihre Sicherheit zu prüfen. Jedes prüft etwas anderes. Und einige der automatisierten Werkzeuge werden mit dem Argument verkauft, sie ersetzten die manuellen Verfahren, was in dieser Allgemeinheit nicht stimmt.

Für Entscheider ist das ein Problem, weil die Verfahren sich in Kosten um den Faktor hundert unterscheiden und die Frage „Was brauchen wir?“ nicht mit „alles“ zu beantworten ist. Ein Unternehmen mit zwanzig öffentlich erreichbaren Systemen und einem Administrator braucht kein Red Teaming; ein Finanzinstitut unter DORA kommt mit einem Schwachstellenscanner nicht aus.

Dieser Beitrag ordnet sieben Verfahren nach dem, was sie tatsächlich leisten: welche Kontrollen sie prüfen, wie stark sie automatisiert sind, wie oft sie laufen, was sie kosten und für welchen Reifegrad sie passen. Am Ende steht eine Entscheidungshilfe nach Reife und Budget.

Die sieben Verfahren im Überblick

Schwachstellenscan

Ein Schwachstellenscan vergleicht Ihre Systeme automatisiert mit einer Datenbank bekannter Schwachstellen: fehlende Patches, veraltete Softwareversionen, unsichere Standardkonfigurationen. Er läuft intern und extern, wöchentlich oder täglich, und liefert eine Liste mit CVSS-Bewertungen. Was er nicht leistet: Schwachstellen verketten, Fehlkonfigurationen in der Berechtigungsstruktur erkennen, Geschäftslogik prüfen oder bewerten, ob eine Schwachstelle in Ihrer Umgebung tatsächlich ausnutzbar ist. Angesichts von durchschnittlich 119 neuen Schwachstellen pro Tag laut BSI-Lagebericht 2025 ist der Scanner dennoch unverzichtbar – als Grundlage des Patch-Managements, nicht als Sicherheitsprüfung.

Attack Surface Management

Attack Surface Management (ASM) beantwortet eine Frage, die dem Scan vorausgeht: Was gehört uns überhaupt, und was davon ist aus dem Internet erreichbar? Das Werkzeug inventarisiert kontinuierlich Domänen, Subdomänen, IP-Adressen, Cloud-Ressourcen, Zertifikate und exponierte Dienste und findet dabei regelmäßig Systeme, die niemand mehr auf dem Schirm hatte: Testumgebungen, vergessene Marketing-Seiten, Fernwartungszugänge von Dienstleistern. Der BSI-Lagebericht 2025 fand bei 47 Prozent der untersuchten IP-Adressen öffentlich erreichbare sensible Informationen. ASM prüft die Angriffsfläche auf Vollständigkeit, nicht auf Tiefe.

Breach and Attack Simulation

Breach and Attack Simulation (BAS) führt automatisiert und wiederholbar bekannte Angriffstechniken in Ihrer Umgebung aus – meist über Agenten auf Testsystemen – und prüft, ob Ihre Sicherheitswerkzeuge sie blockieren oder erkennen. Das Ergebnis ist eine Abdeckungsmatrix nach MITRE ATT&CK, die täglich oder wöchentlich aktualisiert wird. BAS ist damit ein Regressionstest für die Erkennung: Wenn eine Regel durch ein Update bricht oder eine EDR-Richtlinie versehentlich gelockert wird, zeigt BAS das am nächsten Tag. Was BAS nicht leistet: neue Angriffspfade finden, Fehlkonfigurationen im Active Directory kreativ ausnutzen, Menschen täuschen oder die Reaktion eines SOC unter Realbedingungen messen. Es prüft bekannte Techniken gegen bekannte Kontrollen.

Penetrationstest

Der Penetrationstest ist die manuelle, tiefgehende Prüfung eines definierten Objekts – Webanwendung, Netzsegment, Cloud-Umgebung, Active Directory – durch erfahrene Tester, die Schwachstellen nicht nur finden, sondern ausnutzen, verketten und in ihrer tatsächlichen Auswirkung bewerten. Er findet, was Scanner nicht sehen: Logikfehler, Berechtigungsprobleme, Kettenangriffe über mehrere kleine Schwächen. Ein Pentest dauert ein bis drei Wochen, kostet im niedrigen fünfstelligen Bereich und ist der Standard für Compliance-Nachweise nach ISO 27001, PCI DSS 4.0 (Anforderung 11.4) und zunehmend NIS2.

Purple Teaming

Purple Teaming ist die offene Zusammenarbeit von Angreifern und Verteidigern: Technik für Technik wird ausgeführt, geprüft, ob sie geloggt, erkannt und blockiert wird, und die Erkennungsregel sofort angepasst. Im Vergleich zu BAS ist Purple Teaming manuell, anpassungsfähig und lernorientiert – es verbessert die Erkennung, statt sie nur zu messen. Es setzt voraus, dass es etwas zu verbessern gibt: SIEM oder EDR müssen vorhanden sein.

Red Teaming

Das Red Teaming simuliert einen realistischen, zielgerichteten Angriff auf die gesamte Organisation, verdeckt, über Wochen, mit dem Ziel, definierte Flags zu erreichen. Es prüft als einziges Verfahren alle drei Kontrollebenen gleichzeitig: Prävention, Erkennung und Reaktion inklusive der menschlichen Entscheidungen. Es ist das teuerste Verfahren – ab etwa 40 Personentagen – und liefert keine Vollständigkeit, sondern eine realistische Aussage über die Widerstandsfähigkeit als Ganzes.

Threat-Led Penetration Testing

TLPT ist das regulatorisch vorgegebene Red Teaming nach DORA (Verordnung (EU) 2022/2554, Art. 26 und 27) für von BaFin oder EZB benannte Finanzunternehmen: auf Produktivsystemen, mit externem Threat-Intelligence-Provider, mindestens drei Szenarien, aktive Phase mindestens zwölf Wochen, mindestens alle drei Jahre, mit Behördenbeteiligung durch das TLPT Cyber Team der Bundesbank. Der Gesamtzyklus dauert sechs bis zwölf Monate, die Kosten liegen im sechsstelligen Bereich. TLPT ist kein eigenes Verfahren, sondern Red Teaming mit festem Rahmen.

Vergleichstabelle

Die Tabelle zeigt ein Muster: Je höher die Automatisierung, desto häufiger kann das Verfahren laufen, desto enger ist aber auch das, was es prüft. Automatisierte Werkzeuge prüfen Bekanntes gegen Bekanntes; manuelle Verfahren finden das Unbekannte. Beide Kategorien haben ihren Platz, und keine ersetzt die andere.

Was Automatisierung leistet – und wo sie endet

BAS und ASM werden oft als Ersatz für Pentest und Red Teaming beworben. Das Argument klingt plausibel: kontinuierlich statt punktuell, günstiger pro Prüfung, keine Terminabhängigkeit. Für die Fragen, die diese Werkzeuge beantworten, stimmt es auch. Ob ein bekanntes Werkzeug zum Auslesen von Zugangsdaten vom EDR gestoppt wird, prüft BAS täglich und zuverlässig; ein Red Team prüft es einmal alle zwei Jahre.

Die Grenze liegt dort, wo Angreifer kreativ werden. Laut CrowdStrike Global Threat Report 2026 waren 82 Prozent der Erkennungen malware-frei – Angreifer nutzen legitime Werkzeuge, gestohlene Zugangsdaten und Fehlkonfigurationen, die in keiner Technikdatenbank stehen, weil sie spezifisch für Ihre Umgebung sind. Ein Dienstkonto mit zu vielen Rechten, eine Vertrauensstellung zu einer übernommenen Tochtergesellschaft, ein Wartungszugang eines Dienstleisters ohne MFA: Das findet kein Agent, der Standardtechniken abspielt. Das findet ein Mensch, der sich in Ihrer Umgebung umsieht und fragt, wie er von hier zum Ziel kommt.

Ebenso wenig misst Automatisierung die Reaktion. Ob ein SOC-Analyst einen Alarm um zwei Uhr nachts richtig einordnet, ob der Incident-Response-Plan unter Druck funktioniert, ob die Geschäftsführung erreichbar ist – das zeigt nur ein verdeckter Test mit echten Menschen auf beiden Seiten.

Entscheidungshilfe nach Reife und Budget

Die folgende Zuordnung nimmt an, dass das Budget begrenzt ist und jeder Euro dort eingesetzt werden soll, wo er den größten Erkenntnisgewinn bringt.

1. Kleines Budget, geringe Reife. Schwachstellenscan intern und extern, dazu ein ASM-Werkzeug oder zumindest eine manuelle Inventur der externen Angriffsfläche. Findings abarbeiten. Ein externer Pentest der ein bis zwei kritischsten Systeme, sobald das Budget es erlaubt. Kein Red Teaming – es gäbe nichts zu messen.
2. Mittleres Budget, Grundlagen vorhanden. Jährlicher Pentest der kritischen Systeme und des Active Directory, Scanner und ASM laufen kontinuierlich. Parallel Aufbau von zentralem Logging und EDR. Sobald SIEM oder EDR stehen: ein erster Purple-Teaming-Sprint, der die Erkennung gegen die häufigsten Ransomware-Techniken prüft.
3. Mittleres Budget, Erkennung vorhanden. Pentests und Purple-Teaming-Sprints laufen. BAS als Regressionstest, wenn das Budget eine weitere Lizenz hergibt. Erster Assumed-Breach-Test, der prüft, wie weit ein Angreifer von einem kompromittierten Client kommt und ob das SOC reagiert.
4. Größeres Budget, Reaktion etabliert. Full-Scope Red Teaming alle ein bis drei Jahre, dazwischen Purple Teaming zur Schließung der Detection Gaps und BAS zur Absicherung. Pentests für alle neuen und geänderten Systeme. ASM und Scanner als Dauerbetrieb.
5. Reguliertes Finanzunternehmen. TLPT nach DORA, sobald die Aufsicht das Institut benennt, mindestens alle drei Jahre. Vorbereitend alles aus Stufe vier, damit der Test auf Produktivsystemen keine Überraschungen bringt, die ein Assumed-Breach-Test zwei Jahre vorher gezeigt hätte.

Für die meisten Mittelständler liegt der Sweet Spot zwischen Stufe zwei und drei: ein jährlicher Pentest als Fundament und Compliance-Nachweis, Purple Teaming zum Aufbau der Erkennung, ein Assumed-Breach-Test als erster verdeckter Realitätscheck. Unser Beitrag zur Reifegradprüfung vor dem Red Teaming hilft bei der Einordnung.

Fazit

Schwachstellenscan, Attack Surface Management und Breach and Attack Simulation prüfen automatisiert, häufig und günstig – aber nur Bekanntes gegen Bekanntes. Penetrationstest, Purple Teaming und Red Teaming prüfen manuell, seltener und teurer – dafür finden sie das, was spezifisch für Ihre Umgebung ist, und messen die Reaktion echter Menschen. TLPT ist Red Teaming mit regulatorischem Rahmen. Die richtige Kombination hängt vom Reifegrad ab, nicht von der Größe: Erst Inventar und Scan, dann Pentest, dann Erkennung aufbauen, dann unter Realbedingungen messen. Als Fundament dieser Reihenfolge steht für fast jedes Unternehmen der Penetrationstest; welches Objekt Sie zuerst prüfen sollten, klären wir gern in einem Erstgespräch.

Quellen

• BSI, Die Lage der IT-Sicherheit in Deutschland 2025 – Schwachstellen pro Tag, Anteil IP-Adressen mit exponierten Informationen, bsi.bund.de
• CrowdStrike, Global Threat Report 2026 – Anteil malware-freier Erkennungen
• Verordnung (EU) 2022/2554 (DORA), Art. 26 und 27; Delegierte Verordnung (EU) 2025/1190, eur-lex.europa.eu
• PCI Security Standards Council, PCI DSS 4.0, Requirement 11.4
• MITRE ATT&CK Enterprise, attack.mitre.org

Häufige Fragen zum Thema