Die Landkarte der Sicherheitsüberprüfungen: Welche Prüfung beantwortet welche Frage?

In Teil 1 dieser Serie ging es um die falsche erste Frage: Viele Unternehmen wählen eine Prüfart, bevor sie geklärt haben, was sie eigentlich herausfinden wollen. Heute geht es um die richtige Reihenfolge – erst die Frage, dann die Prüfung.

Denn die verschiedenen Prüfarten sind keine austauschbaren Varianten desselben Produkts. Jede beantwortet eine andere Frage. Und sortiert man sie nach diesen Fragen, wird aus dem Begriffsdschungel eine Landkarte.

Frage 1: „Sind wir angreifbar?"

Das ist die Frage nach Schwachstellen – in Systemen, Anwendungen und Konfigurationen. Hier liegen die meisten technischen Prüfarten, und sie unterscheiden sich vor allem in Tiefe und Aufwand:

Schwachstellenscan: Automatisiert, breit, wiederholbar. Findet bekannte Schwachstellen und offensichtliche Fehlkonfigurationen im gesamten Netz – aber ohne Verifikation und ohne Verkettung. Der Scan sagt euch, wo potenzielle Lücken liegen, nicht, wie weit ein Angreifer damit käme. Dafür kostet er einen Bruchteil dessen, was manuelle Prüfungen kosten, und lässt sich regelmäßig wiederholen.
Vulnerability Assessment: Scan plus manuelle Bewertung. Die Ergebnisse werden verifiziert, priorisiert und in euren Kontext eingeordnet – ohne aktive Ausnutzung. Der sinnvolle Mittelweg, wenn ein roher Scan-Report euer Team überfordern würde.
Attack Surface Management / Threat Exposure Management: Der kontinuierliche Blick von außen: Was ein Angreifer im Internet über euch findet, wird laufend erfasst – von exponierten Systemen und Diensten über vergessene Subdomains bis zu OSINT-Informationen wie geleakten Zugangsdaten. Es baut auf automatisierten Scans auf, geht aber darüber hinaus: Die Ergebnisse werden verifiziert, sodass ihr an echten Exposures arbeitet statt an Rauschen. Die Antwort auf eine Frage, die sich viele zu selten stellen: Wie sehen wir eigentlich von außen aus – und zwar heute, nicht zum Zeitpunkt des letzten Pentests?
Penetrationstest: Manuell, zielgerichtet, mit Ausnutzung und Verkettung von Schwachstellen. Ein Pentest beantwortet, was der Scan offenlässt: Was kann ein Angreifer mit den Schwachstellen tatsächlich erreichen? Dafür ist er auf ein definiertes Ziel begrenzt – eine Anwendung, ein Netzsegment, eine API, eine Mobile App. Tiefe statt Breite.
Source Code Review: Der Blick in den Quellcode findet, was dynamische Tests kaum erreichen: Logikfehler, unsichere Kryptografie, versteckte Hintertüren in Abhängigkeiten. Besonders wertvoll für eigenentwickelte Software – und als fester Bestandteil eines SSDLC.
Threat Modeling und Architektur-Review: Die präventive Variante derselben Frage: Sind wir angreifbar – by design? Statt fertige Systeme zu testen, wird die Architektur analysiert, bevor (oder während) gebaut wird. Die günstigste Schwachstelle ist die, die nie in Produktion geht. Und auch nachträglich lohnt sich ein Threat Modeling: Für bestehende Systeme schafft es eine strukturierte Übersicht über Architektur und Angriffsoberfläche – und liefert damit wertvollen Input für die Auswahl und den Zuschnitt weiterer Assessments.

Frage 2: „Würden wir einen Angriff bemerken – und richtig reagieren?"

Hier geht es nicht mehr um einzelne Schwachstellen, sondern um eure Organisation als Ganzes: Erkennung, Reaktion, Prozesse, Menschen.

Red Teaming: Eine zielorientierte Angriffssimulation über Wochen, gegen Technik, Menschen und Prozesse gleichzeitig – mit definierten Zielen („Crown Jewels") statt einer Scope-Liste. Ein Red Teaming misst nicht, wie viele Schwachstellen ihr habt, sondern ob eure Verteidigung als System funktioniert. Genau deshalb ist es die falsche Wahl, wenn die Grundlagen fehlen – dazu mehr in Teil 3.
Purple Teaming: Die kollaborative Variante: Angriffstechniken werden gemeinsam mit eurem Blue Team durchgespielt, Erkennungslücken werden direkt geschlossen statt nur dokumentiert. Wenn euer Ziel Verbesserung der Erkennung ist (und nicht deren Prüfung), ist Purple Teaming oft der effizientere Weg.
Phishing-Simulation und Social Engineering: Der Faktor Mensch, isoliert betrachtet – als eigenständige Prüfung oder als Baustein eines Red Teamings.

Frage 3: „Erfüllen wir Anforderungen?"

Die dritte Gruppe von Prüfungen misst nicht gegen Angreifer, sondern gegen Standards und Vorgaben:

Audit (z. B. ISO 27001, TISAX, BSI IT-Grundschutz): Prüft Prozesse, Dokumentation und Nachweise gegen einen Standard. Ein bestandenes Audit belegt, dass euer Managementsystem funktioniert – nicht, dass eure Systeme einem Angriff standhalten. Beides zu verwechseln ist einer der teuersten Irrtümer in der Praxis.
Gap-Analyse und Reifegradbewertung: Der Ist-Soll-Abgleich gegen ein Framework oder eine Regulierung (NIS2, CRA, DORA) – typischerweise der Einstieg, bevor Zertifizierung oder Umsetzungsprojekt starten.
Konfigurationsaudit / Härtungs-Review: Der Abgleich einzelner Systeme gegen Benchmarks wie CIS oder BSI-Vorgaben. Technisch, aber ohne Angriffssimulation – und oft der schnellste Weg, ein Netz messbar sicherer zu machen. Genau diese Prüfung hätte dem Unternehmen aus der AD-Anekdote in Teil 1 mehr gebracht als das beauftragte Assessment.

Die drei teuersten Verwechslungen

Aus dieser Landkarte ergeben sich die Abgrenzungen, die in der Praxis am häufigsten schiefgehen:

Scan ≠ Pentest. Wer einen „Pentest" kauft und einen kommentierten Scan-Report bekommt, hat zu viel bezahlt. Wer einen Pentest beauftragt, obwohl noch nie gescannt und gepatcht wurde, auch – der Pentester findet dann nur, was der Scan günstiger gefunden hätte. Die Drucker-Anekdote aus Teil 1 lässt grüßen.
Pentest ≠ Red Teaming. Ein Pentest sucht möglichst viele Schwachstellen in einem definierten Scope. Ein Red Teaming sucht einen Weg zum Ziel – und testet dabei vor allem eure Erkennung und Reaktion. Wer „alle Schwachstellen der Webanwendung" will, braucht einen Pentest, kein Red Teaming.
Audit ≠ technische Sicherheit. Ein Zertifikat an der Wand hält keinen Angreifer auf. Umgekehrt ersetzt der beste Pentest kein funktionierendes Managementsystem, das Sicherheit dauerhaft verankert.

Vom Ziel zur Prüfart

Als Kurzform der Landkarte – wenn ihr euer Ziel kennt, findet ihr hier die passende Prüfung:

„Wir wollen einen Überblick über unsere Schwachstellen" → Schwachstellenscan bzw. Vulnerability Assessment
„Wir wollen laufend wissen, wie wir von außen aussehen" → Attack Surface Management / Threat Exposure Management
„Wir wollen wissen, ob unsere neue Anwendung einem Angriff standhält" → Penetrationstest, ergänzt um Source Code Review
„Wir entwickeln Software und wollen Sicherheit von Anfang an" → Threat Modeling und Architektur-Review im SSDLC
„Uns fehlt der Überblick über unser eigenes System und seine Architektur" → Nachträgliches Threat Modeling, das Architektur und Angriffsoberfläche strukturiert sichtbar macht – bei extern erreichbaren Systemen ergänzt um Attack Surface Management
„Wir wollen wissen, ob wir einen echten Angriff überstehen würden" → Red Teaming – sofern die Grundlagen stehen
„Wir wollen unsere Erkennung und Reaktion verbessern" → Purple Teaming
„Wir brauchen einen Nachweis für Kunden, Partner oder Regulierer" → Audit bzw. Gap-Analyse
„Wir wollen schnell und messbar sicherer werden" → Härtungs-Review mit klaren Umsetzungsmaßnahmen

Was auf dieser Landkarte noch fehlt, ist die zweite Dimension: euer Reifegrad. Denn dieselbe Prüfung, die für das eine Unternehmen genau richtig ist, ist für das andere rausgeworfenes Geld.

Genau darum geht es demnächst in Teil 3: Die Reifegrad-Treppe – welche Prüfung auf welcher Stufe sinnvoll ist und woran ihr erkennt, wo ihr steht.

Ihr seid unsicher, welche Frage ihr eigentlich beantworten wollt – oder welche Prüfung dazu passt? Genau diese Einordnung ist Teil meiner Beratung: bei der Auswahl der wirksamsten Maßnahmen im SSDLC ebenso wie in der Security-Beratung zur Erhöhung eurer Resilienz. Meldet euch gerne, bevor ihr beauftragt.