Schwachstellenscan, Penetrationstest, Security Audit oder EASM: Welches Verfahren passt?
Dieser Text wurde mit künstlicher Intelligenz (KI) erstellt.
Das Wichtigste in Kürze
Ein Schwachstellenscan sucht im definierten technischen Scope automatisiert nach bekannten Schwächen und auffälligen Konfigurationen.
Ein Penetrationstest prüft mit klarer Autorisierung und vereinbarter Tiefe, ob und wie sich ausgewählte Schwächen praktisch nutzen oder kombinieren lassen.
Ein Security Audit bewertet Nachweise, Prozesse und Kontrollen gegen festgelegte Kriterien; technische Tests können Teil des Audits sein.
EASM beobachtet die externe Angriffsfläche wiederkehrend aus einer Outside-in-Perspektive und unterstützt Discovery und Priorisierung.
Die Verfahren beantworten unterschiedliche Fragen. Eine Kombination ist häufig sinnvoll, wenn Scope und Übergaben vorab feststehen.
Die Entscheidungsfrage kommt vor der Methode
Die Wahl zwischen Schwachstellenscan, Penetrationstest, Security Audit und External Attack Surface Management beginnt nicht bei einem Produktnamen. Sie beginnt bei der Frage, die beantwortet werden soll. Suchen Sie bekannte technische Schwächen in einem festgelegten Bestand? Wollen Sie die praktische Ausnutzbarkeit eines kritischen Systems prüfen? Benötigen Sie Evidenz zur Umsetzung definierter Kontrollen? Oder fehlt Ihnen eine aktuelle Sicht auf öffentlich erreichbare Assets?
NIST SP 800-115 ordnet technische Tests und Untersuchungen nach Zweck, Planung, Durchführung und Auswertung. Der Leitfaden betont Nutzen und Grenzen einzelner Techniken. Auch das BSI unterscheidet Prüftiefen und weist darauf hin, dass aktive Verfahren Systeme beeinträchtigen können. Daraus folgt eine zentrale Beschaffungsregel: Prüftiefe und Autorisierung müssen zum Informationsbedarf und zum Betriebsrisiko passen.
Die vier Verfahren liegen nicht auf einer einfachen Skala von schwach bis stark. Ein Audit beantwortet eine andere Frage als ein Penetrationstest. EASM hat einen anderen zeitlichen Charakter als ein punktueller Scan. Ein automatisierter Scan kann einen breiten bekannten Bestand regelmäßig prüfen, während ein manueller Test ausgewählte Angriffspfade tiefer untersucht.
Definieren Sie daher vor der Auswahl Scope, Schutzgüter, erwartete Entscheidung, zulässige Eingriffe und gewünschtes Ergebnisformat. Die folgende Matrix dient der Einordnung und ersetzt keine projektspezifische Leistungsbeschreibung.
Kriterium
Schwachstellenscan
Penetrationstest
Security Audit
EASM
Leitfrage
Welche bekannten technischen Schwächen oder Konfigurationsauffälligkeiten werden im Scope erkannt?
Lassen sich ausgewählte Schwächen unter vereinbarten Bedingungen praktisch nutzen oder verbinden?
Sind definierte Anforderungen und Kontrollen nachvollziehbar umgesetzt?
Welche extern sichtbaren Assets und Expositionen verändern sich?
Typischer Scope
Bekannte Hosts, Anwendungen oder Netze
Abgegrenzte Systeme, Anwendungen oder Szenarien
Organisation, Prozess, Kontrollbereich oder System
Internetexponierte Infrastruktur rund um bekannte Ausgangspunkte
Tiefe
Überwiegend automatisiert, je nach Verfahren authentifiziert oder extern
Gezielte manuelle und technische Prüfung mit vereinbarter Angriffstiefe
Dokumenten-, Interview-, Stichproben- und gegebenenfalls technische Prüfung
Wiederkehrende Outside-in-Discovery und Beobachtung
Autorisierung
Prüfauftrag und technische Freigabe erforderlich
Detaillierte Regeln, Freigaben, Grenzen und Notfallkontakte erforderlich
Auditauftrag, Kriterien, Zugang zu Evidenz und Ansprechpartnern
Klare organisatorische Zuordnung und zulässige nicht invasive Prüfung
Zeitpunkt
Regelmäßig und nach Änderungen
Vor Releases, nach wesentlichen Änderungen oder risikobasiert
Nach Auditprogramm, regulatorischem oder vertraglichem Anlass
Kontinuierlich oder wiederkehrend
Output
Technische Befundliste mit Evidenz und Priorität
Validierte Angriffspfade, Auswirkungen und Empfehlungen
Abweichungen, Nachweise und Bewertung gegen Kriterien
Asset-Inventar, externe Befunde, Trends und Priorisierungssignale
Ein Schwachstellenscan untersucht einen festgelegten technischen Bestand auf bekannte Schwächen, fehlende Sicherheitsaktualisierungen oder auffällige Konfigurationen. Je nach Werkzeug und Auftrag arbeitet er von außen, mit Zugangsdaten oder über installierte Komponenten. Authentifizierte Scans können interne Versions- und Konfigurationsinformationen einbeziehen. Externe Scans sehen primär die erreichbare Oberfläche.
Die Methode eignet sich für regelmäßige Prüfungen bekannter Assets, für Patch- und Konfigurationsprozesse sowie als Vorbereitung tieferer Tests. Automatisierung sorgt für wiederholbare Regeln und breite Abdeckung innerhalb des definierten Scopes. Sie erzeugt zugleich Prüfbedarf. Versionsmerkmale können falsch interpretiert werden, kompensierende Kontrollen bleiben möglicherweise unsichtbar und manche Anwendungslogik lässt sich nicht automatisiert bewerten.
Das BSI weist in seinem Leitfaden zu Penetrationstests auf False Positives automatisierter Methoden und auf mögliche Beeinträchtigungen bei invasiveren Prüfungen hin. Deshalb sollte der Auftrag festlegen, ob nur erkannt, aktiv bestätigt oder weiter untersucht werden darf. Produktive Systeme benötigen passende Zeitfenster, Abbruchkriterien und Ansprechpartner.
Ein guter Scanbericht trennt Beobachtung und Bewertung. Er nennt Asset, Zeitpunkt, Prüfmethode, Evidenz, Unsicherheit und empfohlene Validierung. Die Befundzahl allein ist keine Risikopriorität. Geschäftskritikalität, Erreichbarkeit und reale Auswirkung müssen ergänzt werden.
NIST beschreibt Penetration Testing als Sicherheitstest, bei dem Prüfer reale Angriffe nachbilden, um Wege zur Umgehung von Sicherheitsfunktionen zu erkennen. Häufig werden mehrere Schwächen kombiniert. Diese Tiefe kann zeigen, ob eine Annahme praktisch trägt und welche Auswirkung innerhalb der vereinbarten Grenzen erreichbar ist.
Ein Penetrationstest passt zu kritischen Anwendungen, wesentlichen Architekturänderungen, neuen externen Schnittstellen und konkreten Risikoszenarien. Für Webanwendungen bietet der OWASP Web Security Testing Guide einen strukturierten Rahmen. Der Test sollte auf einer aktuellen Architektur- und Scope-Beschreibung beruhen. Sonst investiert das Team möglicherweise viel Tiefe in ein nachrangiges Ziel.
Die Autorisierung ist zentral. Rules of Engagement benennen Systeme, erlaubte Techniken, Zeitraum, Testkonten, Umgang mit Daten, Notfallkontakte, Abbruchregeln und Berichtsweg. Geteilte Cloud- oder Provider-Infrastruktur kann zusätzliche Freigaben verlangen. Der Test darf nur innerhalb dieser Vereinbarung stattfinden.
Ein Penetrationstest liefert eine stichtagsbezogene Aussage über den untersuchten Scope und die eingesetzte Methode. Ein fehlender erfolgreicher Angriff beweist nicht, dass keine Schwäche existiert. Neue Releases und Konfigurationen verändern das Ergebnis. Nach der Behebung ist eine gezielte Nachprüfung sinnvoll.
Security Audit: Kontrollen und Nachweise gegen Kriterien prüfen
Ein Security Audit untersucht, ob definierte Anforderungen und Kontrollen nachvollziehbar umgesetzt sind. Die Kriterien können aus internen Richtlinien, Verträgen, Normen oder regulatorischen Anforderungen stammen. Prüfer betrachten Dokumente, Rollen, Prozessnachweise, Konfigurationen und Stichproben. Technische Tests können Evidenz liefern, sind aber nicht automatisch der alleinige Mittelpunkt.
Das Audit eignet sich, wenn eine Organisation Governance, Zuständigkeiten und Kontrollwirksamkeit beurteilen will. Beispiele sind Berechtigungsprozesse, Schwachstellenmanagement, Lieferantensteuerung oder Notfallvorsorge. Die Aussagekraft hängt vom Kriterienkatalog, Geltungsbereich, Prüfzeitraum und der Qualität der Stichproben ab.
Ein Auditbericht sollte Anforderung, geprüfte Evidenz, Abweichung und Bewertung nachvollziehbar verbinden. Er kann Empfehlungen oder Maßnahmen enthalten. Ein Audit ersetzt keine technische Tiefenprüfung, wenn die konkrete Ausnutzbarkeit einer Anwendung die Leitfrage ist. Umgekehrt beantwortet ein Penetrationstest nicht automatisch, ob ein organisationsweiter Prozess wirksam gesteuert wird.
Bei der Beschaffung muss klar sein, ob ein internes Review, ein unabhängiges Audit oder eine formale Zertifizierungsprüfung benötigt wird. Diese Leistungen unterscheiden sich bei Qualifikation, Unabhängigkeit, Bericht und möglicher Anerkennung. Der Begriff „Security Audit“ allein legt das nicht fest.
EASM: unbekannte externe Assets und Veränderungen beobachten
External Attack Surface Management betrachtet die internetexponierte Angriffsfläche aus einer Outside-in-Perspektive. Microsoft beschreibt EASM als kontinuierliche Discovery und Abbildung der externen Infrastruktur. Bekannte Domains, Hosts, IP-Bereiche oder Organisationsinformationen können Ausgangspunkte für die Zuordnung weiterer Kandidaten sein.
EASM passt, wenn das bekannte Inventar die externe Realität nicht zuverlässig abbildet oder wenn Veränderungen regelmäßig sichtbar werden sollen. Es kann auf neue Hosts, erreichbare Dienste, Zertifikatsbeziehungen, Sicherheitskonfigurationen und Technologiehinweise aufmerksam machen. Damit unterstützt es Discovery und Priorisierung vor einer gezielten Prüfung.
Die Methode hat Grenzen. Ein gefundener Kandidat gehört nicht automatisch zur Organisation. Öffentlich sichtbare Technologiehinweise bestätigen nicht zwingend die konkrete Version oder Ausnutzbarkeit. Interne Berechtigungen, Segmentierung und nicht erreichbare Systeme bleiben außerhalb der Sicht. EASM ersetzt deshalb weder authentifizierte Scans noch Penetrationstests oder Audits.
LocateRisk führt agentenlose Analysen öffentlich erreichbarer Angriffsflächen durch und ordnet Beobachtungen KPI-basiert ein. Ein Security Rating kann Veränderungen verdichten. Für eine Entscheidung müssen Asset-Zuordnung, Einzelbefunde und Geschäftskontext geprüft werden.
Verfahren kombinieren und sauber beauftragen
Ein abgestimmter Ablauf kann mit EASM beginnen, um unbekannte externe Assets und Veränderungen zu erkennen. Ein Schwachstellenscan prüft ausgewählte bekannte Systeme wiederholbar. Ein Penetrationstest validiert priorisierte Szenarien in größerer Tiefe. Ein Audit untersucht, ob der übergeordnete Prozess und definierte Kontrollen wirksam umgesetzt sind.
Diese Reihenfolge ist kein Pflichtmodell. Bei einem neuen kritischen Webportal kann ein Penetrationstest vor dem Produktivstart im Vordergrund stehen. Bei einem großen, historisch gewachsenen Internetbestand kann zunächst Discovery fehlen. Für einen vertraglichen Kontrollnachweis kann ein Audit die richtige erste Maßnahme sein.
Die Leistungsbeschreibung sollte Leitfrage, In-Scope- und Out-of-Scope-Systeme, Prüftiefe, Zugang, Testzeit, Sicherheitsgrenzen, Datenbehandlung, Validierung und Berichtsformat enthalten. Vereinbaren Sie zudem, wie kritische Befunde sofort gemeldet werden und wer Maßnahmen bestätigt. Für eine strukturierte Ausgangslage kann die IT-Risikoanalyse externe Evidenz und Priorisierung vorbereiten.
Bewerten Sie den Erfolg nicht nur nach Zahl der Funde. Geeignete Kriterien sind geklärte Asset-Zuordnungen, validierte Hochrisikoszenarien, Zeit bis zur Behandlung, Wiederholungsbefunde und nachgewiesene Wirksamkeit. Ein kostenloses Rating kann zeigen, welche externe Perspektive für den weiteren Prüfplan relevant ist.
Planen Sie auch die Übergabe zwischen den Verfahren. Ein EASM-Hinweis sollte mit eindeutiger Asset-Zuordnung an den Scan oder Test gelangen. Ein validierter Penetrationstest-Befund braucht einen Owner und eine Frist. Ein Audit sollte prüfen können, ob Behandlung und Nachkontrolle dokumentiert wurden. Einheitliche Asset-IDs, Risikoklassen und Statuswerte verhindern, dass dieselbe Beobachtung mehrfach ohne Zusammenhang bearbeitet wird.
Ein Schwachstellenscan sucht überwiegend automatisiert nach bekannten Schwächen im definierten Scope. Ein Penetrationstest untersucht mit vereinbarter Tiefe, ob und wie ausgewählte Schwächen praktisch genutzt oder zu Angriffspfaden verbunden werden können.
Nein. EASM entdeckt und beobachtet externe Assets und Expositionen. Ein Penetrationstest validiert ausgewählte Angriffsmöglichkeiten tiefer und unter detaillierten Autorisierungsregeln. EASM kann geeignete Ziele und Szenarien für die weitere Prüfung priorisieren.
Ein Audit passt, wenn definierte Anforderungen, Prozesse und Kontrollen gegen nachvollziehbare Kriterien geprüft werden sollen. Für die praktische Ausnutzbarkeit einer konkreten Anwendung ist häufig ein technischer Test geeigneter.
Er benötigt einen schriftlich abgegrenzten Auftrag mit Zielsystemen, erlaubten Techniken, Zeitraum, Testkonten, Datenregeln, Notfallkontakten und Abbruchkriterien. Abhängige Provider oder Cloud-Plattformen können zusätzliche Vorgaben machen.
Die Frequenz folgt Risiko und Veränderung. Scans und EASM eignen sich für wiederkehrende Prüfungen. Penetrationstests sind vor kritischen Releases, nach wesentlichen Änderungen oder risikobasiert sinnvoll. Audits folgen dem Kontroll- und Nachweisbedarf.
We use cookies to optimize our website and our service.
Functional
Immer aktiv
Die technische Speicherung oder der Zugang ist unbedingt erforderlich für den rechtmäßigen Zweck, die Nutzung eines bestimmten Dienstes zu ermöglichen, der vom Teilnehmer oder Nutzer ausdrücklich gewünscht wird, oder für den alleinigen Zweck, die Übertragung einer Nachricht über ein elektronisches Kommunikationsnetz durchzuführen.
Vorlieben
Die technische Speicherung oder der Zugriff ist für den rechtmäßigen Zweck der Speicherung von Präferenzen erforderlich, die nicht vom Abonnenten oder Benutzer angefordert wurden.
Statistics
Die technische Speicherung oder der Zugriff, der ausschließlich zu statistischen Zwecken erfolgt.Die technische Speicherung oder der Zugriff, der ausschließlich zu anonymen statistischen Zwecken verwendet wird. Ohne eine Vorladung, die freiwillige Zustimmung deines Internetdienstanbieters oder zusätzliche Aufzeichnungen von Dritten können die zu diesem Zweck gespeicherten oder abgerufenen Informationen allein in der Regel nicht dazu verwendet werden, dich zu identifizieren.
Marketing
Die technische Speicherung oder der Zugriff ist erforderlich, um Nutzerprofile zu erstellen, um Werbung zu versenden oder um den Nutzer auf einer Website oder über mehrere Websites hinweg zu ähnlichen Marketingzwecken zu verfolgen.
Deutsch 
English 
Français