Attack Surface Management: Was ausserhalb Ihres Perimeters sichtbar ist

Attack Surface Management (ASM) ist die laufende Erkennung, Klassifizierung und Bewertung aller aus dem Internet erreichbaren Assets einer Organisation. Ziel ist es, exponierte Systeme, vergessene Subdomains, verwundbare Dienste und geleakte Credentials zu finden, bevor Angreifer sie ausnutzen. ASM ergänzt Vulnerability Management (bekannte Assets, tiefer Scan) durch die Aussensicht: was Angreifer über Sie erfahren, wenn sie mit einem leeren Blatt starten.

SOC as a ServiceAlleAttack Surface Management: Was ausserhalb Ihres Perimeters sichtbar ist

Abgrenzung zu Nachbarthemen

ASM reduziert, was Angreifer überhaupt sehen können. Threat Hunting sucht Angreifer, die trotzdem hereingekommen sind. Penetrationstest prüft ausgewählte Systeme tief und punktuell. Red Team Assessment simuliert einen realistischen Angriffsverlauf. ASM ist keine Alternative zu diesen Disziplinen, sondern deren Voraussetzung: ohne saubere Aussensicht wird der Pentest am falschen Perimeter angesetzt.

ASM vs. Vulnerability Management

Dimension	Vulnerability Management (klassisch)	Attack Surface Management
Startpunkt	Bekannter Asset-Inventar (CMDB, IP-Ranges).	Öffentlich sichtbare Aussensicht, keine Vorannahme.
Tiefe	Authentifiziert, tief, viele Details pro Asset.	Nicht authentifiziert, breit, Angreifer-Perspektive.
Blinde Flecken	Alles, was nicht im Inventar steht (Shadow IT, vergessene Domains).	Interne Systeme ohne Internet-Exposition.
Ergebnis	CVSS-Liste, patchbar.	Exponierte Dienste, Fehlkonfigurationen, geleakte Credentials, Schatten-Domains.
Ergänzung	Braucht ASM, um vollständig zu werden.	Braucht VM für die Tiefe pro bestätigtem Asset.

Was ASM in Schweizer Umgebungen typischerweise findet

Vergessene Subdomains aus alten Kampagnen oder Sub-Marken, die auf inaktive Cloud-Buckets zeigen (Subdomain-Takeover-Risiko).
Alte Fernzugriffe: RDP, SMB, offene Legacy-VPN-Konzentratoren, oft ohne MFA.
Fehlkonfigurierte S3-, Azure-Blob- oder GCS-Buckets mit lesbaren Objekten.
Exponierte Admin-Interfaces (Jenkins, GitLab, Prometheus, Grafana, Datenbank-Webshells).
Nicht mehr betreute Public-Test-Umgebungen aus Projekten oder Übernahmen.
Geleakte Zugangsdaten in Paste-Sites, Code-Repositories oder Combo-Lists mit CH-Domains.
OT- oder ICS-Assets mit unbeabsichtigter Internet-Exposition in Fertigungsumgebungen.
TLS-Zertifikate mit falschem Common Name, die auf nicht dokumentierte Systeme zeigen.

Was das für das SOC bedeutet

Jedes bisher unbekannte, aber bestätigte Asset gehört ins Log-Ingest oder muss stillgelegt werden. ASM ohne Rückkopplung in die Detection-Coverage produziert Reports, aber keine Sicherheitsverbesserung. Wird ein unentdecktes exponiertes System tatsächlich kompromittiert, kann daraus eine meldepflichtige Lage nach ISG entstehen, siehe [SOC & ISG-Meldepflicht](/de/soc/soc-isg-meldepflicht-24h).

Priorisierung: nicht alles Rote ist wichtig

Ein rohes ASM-Ergebnis kann tausende Findings zeigen. Die Kunst liegt in der Priorisierung nach realer Ausnutzbarkeit. Drei Achsen entscheiden:

Exponierung: ist der Dienst tatsächlich aus dem Internet erreichbar, oder liegt eine Firewall dazwischen, die nur beim Scan geschlossen war?
Ausnutzbarkeit: gibt es einen bekannten Exploit, wird die Schwachstelle in freier Wildbahn aktiv genutzt (CISA KEV, EPSS-Score)?
Geschäftswert: dient das Asset einem Kronjuwel-Prozess, oder ist es eine isolierte Marketing-Landingpage?

ASM als Prozess, nicht als Projekt

Kontinuierliche Discovery (mindestens wöchentlich), nicht Jahres-Scan. Angriffsflächen verändern sich mit jedem Deployment.
Trigger-basiertes Rescanning bei M&A, Domain-Änderungen, neuen Sub-Marken oder Cloud-Migrationen.
Verknüpfung mit Change- und CMDB-Prozessen: jedes bestätigte Asset wird eingetragen oder abgeschaltet.
Übergabe an das SOC: neue Assets in Log-Coverage, geleakte Credentials in Detection- und Reset-Workflows.

ASM und Schweizer Regulierung

ASM deckt direkt mehrere Kontroll-Erwartungen. ISO 27001 und SOC verlangt in Annex A.8.8 Umgang mit technischen Schwachstellen und in A.5.9 ein Inventar der Informationen und Werte. DORA-Anforderungen an das SOC fordert kontinuierliches Risiko-Monitoring der IKT-Assets. NIS2 Schweizer Töchter verlangt Schwachstellen- und Expositions-Management. Für den Fertigungssektor ist zusätzlich der Cyber Resilience Act relevant, weil exponierte OT-Interfaces regulatorisch heikel werden.

Einordnung im SOC-Betrieb

Wie ASM in einen laufenden SOC-Betrieb eingebettet wird, beschreibt SOC as a Service Schweiz. Für das Pentest-Zusammenspiel siehe Penetrationstest Schweiz, für die aktive Suche nach Angreifern Threat Hunting Schweiz.

Häufige Fragen

Ist ASM dasselbe wie ein externer Vulnerability-Scan?

Nein. Ein externer VA-Scan prüft bekannte IPs und Hosts auf bekannte Schwachstellen. ASM startet ohne Asset-Liste und findet zuerst, was überhaupt existiert (Discovery), bevor es bewertet. Die grössten Findings sind in der Regel vergessene Systeme, die im VA-Scope gar nicht auftauchen.

Ersetzt ASM einen Pentest?

Nein, es macht den Pentest zielgerichteter. ASM liefert die vollständige Aussensicht; der Pentest prüft ausgewählte Ziele tief. Ohne ASM prüft ein Pentest oft nur das, was in der CMDB steht, und übersieht die relevantesten Schatten-Assets. Siehe [Penetrationstest Schweiz](/de/services/penetrationstest-schweiz).

Wie oft sollte ASM laufen?

Mindestens wöchentlich für die Discovery, plus Trigger bei M&A, neuen Domains, Cloud-Migrationen und grösseren Releases. Quartalsweise Snapshot-Berichte sind eine Governance-Ergänzung, kein Ersatz für kontinuierliches Monitoring.

Wer soll ASM betreiben, interne IT oder SOC-Anbieter?

Die Discovery kann in beiden Modellen laufen. Der Wert entsteht erst, wenn Findings in Detection-Coverage, Change-Prozesse und Incident-Response einfliessen. Ein Managed-SOC-Modell mit ASM-Integration schliesst diese Rückkopplung von Haus aus. Zur Bewertung siehe [SOC-Anbieter Vergleich](/de/soc/soc-anbieter-vergleich-checkliste).

Wie erkennt ASM geleakte Zugangsdaten?

Durch die Überwachung von Paste-Sites, Code-Repositories, Combo-Lists und Dark-Web-Marktplätzen auf Muster mit CH-Domains und Firmen-Aliassen. Bestätigte Treffer lösen ein Passwort-Reset, eine Session-Invalidation und einen gezielten Threat Hunt aus. Siehe auch [Token-Diebstahl und Session Hijacking](/de/soc/token-diebstahl-session-hijacking).

Weiterlesen im Cluster

Threat Hunting Schweiz: Wenn Detection-Regeln nicht mehr reichen

Threat Hunting ist die hypothesen-getriebene Suche nach Angreifern, die durch bestehende Detection-Regeln schlüpfen. Es ergänzt SIEM- und EDR-Alarme, ersetzt sie nicht. Ziel ist es, die Dauer strukturell zu senken, in der Angreifer unentdeckt bleiben; laut Mandiant M-Trends 2026 liegt dieser Median bei 14 Tagen. Dafür suchen Analysten aktiv nach Tactics, Techniques und Procedures (TTPs), statt auf einen Alarm zu warten.

Penetrationstest Schweiz: Angriffsflächen finden, bevor Angreifer es tun

Ein Penetrationstest ist eine gezielte Angriffssimulation gegen definierte Systeme, ausgeführt von Schweizer Testern nach dokumentierter Methodik. Ergebnis ist keine Toolausgabe, sondern ein nachvollziehbarer Bericht mit priorisierten Findings, Beweiswert für Regulator und Versicherer, und Empfehlungen, die zur eigenen Umgebung passen. ANOMAL testet Web, Cloud, Active Directory, APIs und interne Netze.

Red Team Assessment: die Detection- und Response-Kette unter realer Last

Ein Red Team Assessment ist eine ziel-basierte, mehrwöchige Angriffssimulation gegen die gesamte Detection- und Response-Kette, nicht gegen einen einzelnen Scope. Das Ergebnis ist keine Schwachstellen-Liste, sondern eine verlässliche Aussage darüber, was SOC, EDR, Identity- und Cloud-Kontrollen in Kombination tatsächlich stoppen. ANOMAL führt Red-Team-Übungen nach MITRE ATT&CK durch, methodisch an TIBER-EU orientiert. Für systemrelevante Institute erachtet die FINMA Red-Teaming-Übungen als erforderlich (Aufsichtsmitteilung 03/2024) und nennt Rahmenwerke wie TIBER-EU und CBEST.

SOC-Anbieter vergleichen: die neutrale Auswahl-Checkliste

Ein SOC-Anbieter-Vergleich funktioniert nicht über Logos, sondern über nachprüfbare Kriterien: Datenumfang, Response-Autorität im Kunden-Tenant, Nachweis-Artefakte, Reaktionszeiten und Vertragswerk. Diese Seite listet die Fragen, mit denen Angebote nebeneinander gestellt werden. Bewusst ohne Namen, damit die Checkliste auch dann trägt, wenn ANOMAL nicht auf der Shortlist ist.

SOC as a Service in der Schweiz: Kompletter Leitfaden

SOC as a Service ist ein extern betriebenes Security Operations Center, das Ihre Umgebung rund um die Uhr überwacht, Angriffe erkennt und die Reaktion auslöst. Laut Mandiant M-Trends 2026 blieben Angreifer 2025 im Median 14 Tage unentdeckt. Mit einem SOC, das rund um die Uhr erkennt und bewertet, liegt die Erkennungszeit deutlich kürzer.

Kurzdefinitionen im Glossar nachschlagen