External Attack Surface Management: Risiken identifizieren, Angriffsflächen minimieren

Geschätzte Lesezeit: 5 Minuten

External Attack Surface Management (EASM) ermöglicht Unternehmen einen Perspektivwechsel von der reinen Innenansicht zur externen Angreifer-Sicht, um Schatten-IT und vergessene Assets aufzudecken. Durch kontinuierliches Monitoring und die Simulation echter Reconnaissance-Taktiken werden Schwachstellen proaktiv geschlossen, bevor sie ausgenutzt werden können.

Inhaltsverzeichnis

Um External Attack Surface Management (EASM) erfolgreich in modernen IT-Umgebungen zu implementieren, ist ein fundamentaler Perspektivwechsel von der internen Perimeter-Sicht hin zur externen Angreifer-Sicht notwendig. Die massive Zunahme von Cloud-Native-Architekturen, SaaS-Abhängigkeiten und dezentraler Shadow IT führt dazu, dass klassische Asset-Datenbanken (CMDB) oft nur 60 bis 70 Prozent der tatsächlichen Infrastruktur abbilden. Was Administratoren nicht sehen, können sie nicht schützen. EASM dient in diesem Kontext als technisch versiertes Frühwarnsystem. Es entdeckt Internet-exponierte Assets, die Angreifer als Einstiegspunkte nutzen könnten – oftmals Testsysteme oder nicht abgeschaltete Dienste, die längst in Vergessenheit geraten sind. Durch die Simulation der Reconnaissance-Taktiken realer Angreifer ermöglicht dieser Ansatz eine aktive Steuerung gegen Schwachstellen, bevor automatisierte Bot-Netze diese kompromittieren.

Unbekannte und exponierte Assets identifizieren

Die Diskrepanz zwischen der dokumentierten CMDB und der tatsächlichen Realität in der Cloud stellt eine der größten Herausforderungen für die IT-Sicherheit dar. Durch die Dynamik von DevOps-Prozessen und kurzlebigen Container-Umgebungen entsteht oft erhebliche Schatten-IT. Ein reales Szenario illustriert dies: Ein DevOps-Team deployt temporär einen Kubernetes-Cluster in einer Public Cloud (AWS oder Azure) für Integrationstests. Nach Abschluss der Tests wird vergessen, den Load Balancer Service sauber zu deprovisionieren. Die Folge sind API-Endpunkte, die öffentlich erreichbar bleiben und oft ungeschützt sind.

Solche „Zombied Assets“ – dazu zählen auch verwaiste Marketing-Microsites oder alte Testsysteme mit veralteten TLS-Zertifikaten – dienen häufig als Einfallstor für Initial Access Broker. Um diese Risiken zu minimieren, ist eine präzise Asset-Erkennung notwendig, die über einfache IP-Range-Scans hinausgeht. Technisch versierte Teams nutzen dazu automatisierte Subdomain-Discovery via Certificate Transparency Logs und DNS-Bruteforce. Dies ermöglicht die Erfassung von Internet-exponierten Assets [1], die sich außerhalb der dokumentierten IP-Blöcke befinden. Tools wie Amass oder Masscan korrelieren diese Daten anschließend mit WHOIS-Informationen, um die Zugehörigkeit zur eigenen Organisation zweifelsfrei zu klären.

Die strategische Outside-in-Sicht etablieren

Eine effektive Sicherheitsstrategie setzt voraus, dass wir nicht nur prüfen, was intern konfiguriert wurde, sondern verifizieren, was das gesamte Internet sieht. Ein häufiges Problem in hybriden Netzwerken ist eine fehlerhafte NAT-Regel auf der Edge-Firewall. In der Praxis kommt es vor, dass für Wartungszwecke eine „Any“-Regel erstellt oder Port 3389 (RDP) temporär freigegeben wird. Wird die Deaktivierung vergessen, bleibt dieser Zugang weltweit offen. Interne Scanner, die hinter der Firewall sitzen, erkennen dieses Risiko oft nicht, da der Zugriffsweg für sie legitim erscheint.

Die Angreiferperspektive unterscheidet sich hierbei fundamental von klassischen Vulnerability Scans. Sie prüft nicht authentifiziert, sondern simuliert aggressive Reconnaissance-Techniken. Dabei werden HTTP-Header und Fehlermeldungen validiert, die Rückschlüsse auf Backend-Technologien (z.B. genaue Apache-Versionen) zulassen. Eine technische Empfehlung ist der regelmäßige Abgleich der externen Sicht mit internen Firewall-Regelwerken durch Diff-Analysen. Was von außen als „Open“ gemeldet wird, muss zwingend eine legitime Business-Rechtfertigung haben. Nur so lassen sich ungewollte Fernwartungszugänge [2] und Schatten-Regelwerke zuverlässig eliminieren.

Schwachstellen extern finden und kontextualisieren

Die reine Identifikation einer CVE ist ohne Kontext oft wenig zielführend und führt zu „Alert Fatigue“. Ein Beispiel: Ein extern erreichbarer Gitlab-Server weist eine kritische Remote Code Execution (RCE) Schwachstelle auf, wird vom internen Scanner jedoch als „niedriges Risiko“ eingestuft, da er fälschlicherweise als internes System getaggt wurde. EASM korrigiert diese Einschätzung, indem es die externe Erreichbarkeit validiert. Ebenso kritisch sind typische Incidents wie exponierte .git-Verzeichnisse oder .env-Dateien, die API-Keys im Klartext leaken (Information Disclosure).

Durch eine fundierte Risikoanalyse werden False-Positives reduziert und die tatsächliche Bedrohungslage geschärft. Dabei muss der CVSS-Score mit der realen Ausnutzbarkeit abgeglichen werden. Hierzu dient der Katalog der Known Exploited Vulnerabilities [3] der CISA als Referenz. Schwachstellen, die aktiv ausgenutzt werden und auf exponierten Systemen liegen, erfordern sofortige Priorisierung. Als technische Sofortmaßnahme empfiehlt sich das Deployment von WAF-Regeln als Hotpatching, bis das zugrunde liegende System, wie etwa administrativ versehentlich freigegebene Schnittstellen (z.B. Tomcat Manager), gepatcht oder isoliert ist.

Angriffsfläche reduzieren durch strenge Governance

Die Reduktion der externen Angriffsfläche erfordert strikte Governance-Prozesse, insbesondere im DNS- und Cloud-Umfeld. Ein unterschätztes Risiko ist der „Subdomain Takeover“. Hierbei zeigen Wildcard-DNS-Einträge auf Cloud-Ressourcen, die mittlerweile gelöscht wurden. Angreifer können diese Ressourcen unter demselben Namen registrieren und unter der vertrauenswürdigen Unternehmensdomain Phishing betreiben [siehe Quelle 4]. Ebenso gefährlich ist Shadow IT in Form von SaaS-Tools, bei denen Mitarbeiter Unternehmensdaten speichern, ohne dass diese Dienste hinter einem SSO oder CASB liegen.

Effektive Bedrohungsabwehr verlangt daher einen automatisierten „Clean-Up“-Prozess. Ungenutzte DNS-Einträge und IP-Reservierungen sollten getaggt und nach einer Grace-Period (z.B. 14 Tage) deaktiviert werden. Zudem muss die digitale Infrastruktur so segmentiert sein, dass Test- und Entwicklungsumgebungen niemals direkt im öffentlichen Adressraum operieren, sondern ausschließlich via VPN- oder SDP-Gateways erreichbar sind. EASM-Tools flaggen Abweichungen von dieser Policy als „nicht compliant“ und ermöglichen so ein schnelles Eingreifen.

Kontinuierliches Monitoring vs. Punktuelle Scans

In dynamischen Umgebungen sind punktuelle Scans unzureichend. Wenn ein DevOps-Team am Freitagabend eine Sicherheitsgruppe in AWS ändert und Datenbank-Ports öffnet, der nächste geplante Vulnerability Scan aber erst am Mittwoch läuft, beträgt das Angriffsfenster fünf Tage. Ähnlich verhält es sich, wenn ein SSL-Zertifikat unbemerkt durch ein unsicheres Self-Signed-Zertifikat ersetzt wird, was Man-in-the-Middle-Angriffe ermöglicht.

External Attack Surface Management setzt hier auf Event-Driven Alerting. Anstelle von Snapshots erfolgt ein kontinuierliches Monitoring in Echtzeit. Sobald ein neues Asset erkannt wird oder ein Port-Status von „Closed“ auf „Open“ wechselt, informiert ein Webhook das SIEM/SOAR-System [siehe Quelle 5]. Dies reduziert die Mean Time to Detect (MTTD) bei sicherheitskritischen Fehlkonfigurationen (Drift) drastisch von Tagen auf Minuten und schließt das Zeitfenster für Angreifer.

Fallstudie: Shadow IT erkennen und beheben

Ein konkretes Beispiel verdeutlicht die Notwendigkeit externer Sichtbarkeit. Ein Marketing-Dienstleister erstellte ohne IT-Freigabe eine Landingpage auf einem AWS S3-Bucket und konfigurierte diesen als „Public Read/Write“. Das EASM-Tool detektierte bei der routinemäßigen Überwachung einen neuen Hostnamen, der markenspezifische Schlüsselwörter enthielt, aber nicht im registrierten IP-Space des Unternehmens lag.

Da das Asset Schreibrechte für jedermann zuließ, war es massiv Schwachstellen extern ausgesetzt. Angreifer hätten Malware verteilen oder Inhalte manipulieren können. Die Reaktion erfolgte automatisiert: Benachrichtigung des Security Incident Response Teams, gefolgt von einem Takedown-Request beim Provider und der Integration der Domain in die Blocklist der Managed WAF, bis die Lücke geschlossen war.

Fazit: EASM als integraler Bestandteil der SecOps

External Attack Surface Management ersetzt kein internes Vulnerability Management, sondern schließt den kritischen Blind Spot für Assets, die sich der Kontrolle der zentralen IT entzogen haben. Die reine Datenerhebung ist jedoch wertlos ohne operationalisierte Prozesse. Gefundene Assets müssen zwingend in das Asset Management und Patch Management überführt werden. Für technische Entscheider ist EASM kein isoliertes Tool, sondern ein notwendiger Prozess, um die Hoheit über die eigene digitale Identität im Internet zurückzugewinnen und proaktiv zu agieren.

Quellen

  • [1] https://www.cisa.gov/guidance-identity-asset-and-network-security
  • [2] https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Fernwartung/fernwartung_node.html
  • [3] https://www.cisa.gov/known-exploited-vulnerabilities-catalog

📌 Die Beiträge auf dieser Website wurden – auf Basis der NetUSE-eigenen Wissendsdatenbank – in Teilen mithilfe künstlicher Intelligenz erstellt.

Veröffentlicht am

Veröffentlicht in