{"id":6368,"date":"2025-12-31T03:54:00","date_gmt":"2025-12-31T03:54:00","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=6368"},"modified":"2025-12-31T03:54:00","modified_gmt":"2025-12-31T03:54:00","slug":"external-attack-surface-management-easm-mit-diesen-vier-schritten-minimieren-sie-das-cyberrisiko","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=6368","title":{"rendered":"External Attack Surface Management (EASM): Mit diesen vier Schritten minimieren Sie das Cyberrisiko"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n
\n

IT-Security-Verantwortliche sollten die Angriffsfl\u00e4che permanent analysieren und sch\u00fctzen. Dazu m\u00fcssen sie stets im Blick haben, welche Assets \u00fcber das Internet erreichbar sind.<\/p>\n

Foto: NicoElNino \u2013 shutterstock.com<\/p>\n<\/div>\n

Von IoT-Devices \u00fcber Cloud<\/a>-basierte Infrastrukturen, Web-Applikationen und Firewalls bis hin zu VPN-Gateways: Die Anzahl unternehmenseigener Assets, die mit dem Internet verbunden sind, steigt exponentiell an. Sie erm\u00f6glichen beispielsweise den Zugriff auf Daten, Sensoren, Server, Onlineshops, Webseiten oder andere Anwendungen. Allerdings w\u00e4chst mit jedem zus\u00e4tzlichen Asset die externe Angriffsfl\u00e4che \u2013 und damit das Risiko f\u00fcr erfolgreiche Cyberattacken. <\/p>\n

Asset Discovery reicht nicht aus<\/h3>\n

Diese externe Angriffsfl\u00e4che \u00e4ndert sich bei vielen Unternehmen oftmals im Tagestakt, ist \u00e4u\u00dferst komplex und stellt die Security-Verantwortlichen vor erhebliche Herausforderungen. Sie m\u00fcssen stets im Blick haben, welche (neuen) Assets \u00fcber das Internet erreichbar sind, und sich \u00fcber entdeckte Sicherheitsl\u00fccken informieren. CISOs ben\u00f6tigen deshalb ein feines Gesp\u00fcr f\u00fcr m\u00f6gliche Schwachstellen und Fehlkonfigurationen. Au\u00dferdem sollten sie \u00fcber ein Team verf\u00fcgen, das wei\u00df, wie es gefundene Bedrohungen abwenden kann und welche Ma\u00dfnahmen zu ergreifen sind. Aber welche Sicherheitsl\u00fccke soll \u00fcberhaupt zuerst geschlossen werden? Ein effektiver Schutz der unternehmenseigenen IT-Infrastruktur ben\u00f6tigt ein mehrstufiges Konzept f\u00fcr External Attack Surface Management (EASM), das auch eine Abw\u00e4gung des individuellen, tats\u00e4chlichen Risikos der Schwachstellen umfasst. Dieser iterative Prozess l\u00e4sst sich grob in vier aufeinander folgende Schritte einteilen.<\/p>\n

Schritt 1: Assets identifizieren und klassifizieren<\/h3>\n

Nur wer alle Assets<\/a> kennt, kann sich effektiv sch\u00fctzen und die Angriffsfl\u00e4che aktiv managen. Doch die Identifizierung ist leichter gesagt als getan. Das gilt f\u00fcr mittelst\u00e4ndische Unternehmen und noch viel mehr f\u00fcr gro\u00dfe Konzerne mit zahlreichen Untergesellschaften. Sie tun sich oftmals schwer, alles extern Erreichbare im Blick zu behalten. Dazu tr\u00e4gt auch die Schatten-IT bei, in der Mitarbeitende entgegen den geltenden Compliance-Regeln ohne das Wissen und ohne die offizielle Zustimmung durch die interne IT-Abteilung zum Beispiel nicht freigegebene Software-Anwendungen installieren oder Cloud-Dienste nutzen. Um dennoch eine stichhaltige \u00dcbersicht \u00fcber alle relevanten Assets zu erhalten, m\u00fcssen Verantwortliche die externe Angriffsfl\u00e4che regelm\u00e4\u00dfig automatisiert \u00fcberpr\u00fcfen. Im Idealfall werden dabei nicht nur alle relevanten Assets identifiziert, sondern auch den entsprechenden Unterorganisationen, T\u00f6chtern & Co. zugeordnet. External Attack Surface Management<\/a> geht dabei weit \u00fcber klassisches Asset Discovery und Vulnerability Scanning hinaus. Es nimmt auch \u201cblinde Flecken\u201d ins Visier \u2013 etwa vergessene Cloud Assets sowie nicht mehr genutzte oder fehlerhaft konfigurierte IT- und IoT-Infrastrukturen.<\/p>\n

Schritt 2: Risikoerkennung<\/h3>\n

Um festzustellen, welche Anf\u00e4lligkeiten bestehen und welches Gef\u00e4hrdungspotenzial sich dadurch f\u00fcr das eigene Unternehmen ergibt, werden diverse Testverfahren auf verschiedenen Ebenen durchgef\u00fchrt. Ob die potenzielle Gefahr von bestimmten Anwendungen ausgeht, l\u00e4sst sich beispielsweise mit Dynamic Application Security Testing (DAST<\/a>) in Erfahrung bringen. Zudem sollte \u00fcberpr\u00fcft werden, ob sicherheitsrelevante Daten, beispielsweise f\u00fcr die Steuerung einer Produktionsanlage, eventuell bereits unbeabsichtigt \u00fcber das Internet einsehbar sind. Ein weiteres Sicherheitsrisiko sind nicht autorisierte Anmeldungen. Hier kommt Credentials Testing zum Einsatz. Zudem sollten Unternehmen permanent im Auge behalten, ob ihre Assets von bereits bekannten und ver\u00f6ffentlichten Sicherheitsl\u00fccken betroffen sind.<\/p>\n

Schritt 3: Risikobewertung<\/a><\/h3>\n

Alle entdeckten Schwachstellen bergen ein gewisses Risiko, doch dieses ist nicht immer gleich hoch. Um es realistisch bewerten und klassifizieren zu k\u00f6nnen, stehen drei Metriken im Mittelpunkt.<\/p>\n

Erstens die Exploitability<\/strong> mit der zentralen Frage: Gibt es f\u00fcr die spezielle Sicherheitsl\u00fccke tats\u00e4chlich bereits bekannte Angriffsvektoren, oder ist sie bisher eher theoretischer Natur und noch nicht konkret ausgenutzt worden?<\/p>\n

Zweitens die Attractiveness<\/strong> f\u00fcr Angreifer. Hier ist die Frage: Befindet sich die Sicherheitsl\u00fccke auf einem Asset oder Zielsystem, das f\u00fcr eine Attacke interessant ist? Eine zentrale Datenbank ist hier beispielsweise wesentlich lohnenswerter als ein Asset einer Unterorganisation, das keinen Zugriff auf andere Systeme erlaubt.<\/p>\n

Die dritte Metrik ist die Discoverability<\/strong>, die umschreibt, wie schnell und einfach ein Asset einem Unternehmen als potenziellem Ziel zugeordnet werden kann. Befindet es sich beispielsweise direkt auf der Website oder ist es als weitgehend unbekanntes Risiko bei einer Tochterorganisation \u201cversteckt\u201d?<\/p>\n

Schritt 4: Priorisierung und Remediation<\/h3>\n

Um das externe Cyberrisiko der von au\u00dfen erreichbaren Angriffsfl\u00e4che effektiv klein zu halten, ist der wichtigste Faktor eine m\u00f6glichst kurze Reaktionszeit f\u00fcr tats\u00e4chlich kritische Risiken. Das gilt f\u00fcr das Erkennen, aber nat\u00fcrlich auch f\u00fcr das rechtzeitige Schlie\u00dfen relevanter Schwachstellen. Doch was tun, wenn das Dashboard mehr Probleme zeigt, als Personal zu Verf\u00fcgung steht, um sie zu beheben? Dann m\u00fcssen die Schwachstellen sinnvoll priorisiert werden, um das Gesamtrisiko f\u00fcr erfolgreiche Angriffe so schnell und so stark wie m\u00f6glich zu minimieren. So ist beispielsweise der direkte ungesch\u00fctzte Zugriff von au\u00dfen auf eine Kundendatenbank ohne Authentisierung in der Regel sicherlich deutlich kritischer als eine bisher nur theoretisch ausnutzbare Schwachstelle auf einer IP-Kamera. Es geht f\u00fcr das Security Operations Team<\/a> also nicht in erster Linie darum, schnell m\u00f6glichst viele L\u00fccken zu schlie\u00dfen, sondern die relevantesten. Und oft bergen lediglich circa zehn L\u00fccken den gr\u00f6\u00dften Teil \u2013 und zwar bis zu 90 Prozent \u2013 des gesamten externen Cyberrisikos eines Unternehmens in der aktuellen Woche. Ist die Remediation abgeschlossen, sollte die Wirksamkeit der Ma\u00dfnahmen, bestenfalls automatisiert, von au\u00dfen revalidiert werden.<\/p>\n

Ein Fallbeispiel: Fatales Change Management<\/h3>\n

Die Vorteile des EASM-Konzepts lassen sich an einem Fallbeispiel illustrieren: Um Anfragen nach dem \u201cRecht auf Vergessen\u201d effizient bearbeiten zu k\u00f6nnen, muss ein E-Commerce-H\u00e4ndler umfangreiche Code-\u00c4nderungen umsetzen. Aufgrund des hohen Programmieraufwands bekommt das interne Team Unterst\u00fctzung von externen Entwicklern. Damit die Bereitstellung der Infrastruktur f\u00fcr die externen Kolleginnen und Kollegen m\u00f6glichst unkompliziert und gleichzeitig Compliance<\/a>-konform ablaufen kann, richtet der Vertragspartner einen Jenkins<\/a>-Server ein. Einige Tage sp\u00e4ter wird eine Firewall-\u00c4nderungsanforderung in dem Subnetz verarbeitet, in dem der Jenkins-Server bereitgestellt wurde.<\/p>\n

Was der zust\u00e4ndige Entwickler allerdings nicht realisiert: Diese \u00c4nderung macht den Jenkins-Server \u00fcber das Internet zug\u00e4nglich. Da er jedoch nicht durch die Unternehmens-IT verwaltet wird, gibt es auch keine Sicherheits\u00fcberwachung. Der Server ist also nicht geh\u00e4rtet und das Standardkennwort wurde nicht ge\u00e4ndert. Ein Angreifer entdeckt den weitgehend ungesch\u00fctzten Server, schafft es, sich anzumelden und \u00fcber ein Groovy-Skript die Shell in der Jenkins-Skriptkonsole auszuf\u00fchren. Anschlie\u00dfend verschafft er sich Root-Rechte und findet private SSH-Schl\u00fcssel f\u00fcr die Bereitstellung von Assets sowie API-Schl\u00fcssel f\u00fcr Quellcode-Repositories. Diese verwendet er f\u00fcr den Zugriff auf die Code-Repositories und st\u00f6\u00dft so auf AWS-API-Schl\u00fcssel. <\/p>\n

Mit diesem kompromittiert er mehrere Terabyte an Daten, die in S3-Buckets gespeichert sind, darunter auch personenbezogene Informationen (PII) von Kunden. Was als Projekt zur Umsetzung von Datenschutzvorschriften begann, f\u00fchrt am Ende zu einer Offenlegung genau der Daten, die urspr\u00fcnglich besser gesch\u00fctzt werden sollten. Um einen solchen erfolgreichen Angriff in Zukunft zu verhindern, denken die Verantwortlichen dar\u00fcber nach, die bisher j\u00e4hrlichen Penetrationstests<\/a> ab sofort in jedem Quartal durchzuf\u00fchren. Dieser gut gemeinte, letztlich aber leider wenig zielf\u00fchrende Vorschlag zeigt das h\u00e4ufigste Problem in Bezug auf EASM, n\u00e4mlich mangelndes Risikobewusstsein.<\/p>\n

Wer die externe Angriffsfl\u00e4che effektiv sch\u00fctzen und das externe Cyberrisiko minimieren m\u00f6chte, muss \u00f6ffentlich sichtbare Cloud Assets und Anwendungen eines Unternehmens inklusive aller Unterorganisationen kontinuierlich \u2013 und aus Effizienz- und Kostengr\u00fcnden m\u00f6glichst automatisiert \u2013 pr\u00fcfen und \u00fcberwachen.<\/p>\n\n

<\/div>\n\n

Dann f\u00e4llt die oben beschriebene Konfigurations\u00e4nderung und das implementierte Standardpasswort f\u00fcr den von au\u00dfen zug\u00e4nglichen Jenkins-Server direkt auf und in den internen Systemen wird automatisch eine entsprechende Risikomeldung ausgel\u00f6st. Eine gute EASM-L\u00f6sung liefert dar\u00fcber hinaus auch wichtige Informationen zu effektiven Pr\u00e4ventionsma\u00dfnahmen, um \u00e4hnliche Vorf\u00e4lle k\u00fcnftig zu verhindern. Denn unter Umst\u00e4nden kennt der zust\u00e4ndige Sicherheitsanalyst Jenkins nicht, fordert deshalb \u201cnur\u201d ein neues Passwort an und betrachtet den Vorgang und das Risiko damit als erledigt. Erst wenn er dar\u00fcber informiert wird, dass Jenkins-Server niemals \u00fcber das Internet erreichbar sein sollten, und es sich grunds\u00e4tzlich empfiehlt, die Standard-Anmeldedaten zu \u00e4ndern, l\u00e4sst sich das externe Cyberrisiko verringern. Zudem kann das System den Analysten warnen, dass Angreifer m\u00f6glicherweise bereits eingebrochen sind und eine gr\u00fcndlichere Untersuchung angebracht w\u00e4re. Dar\u00fcber hinaus lassen sich mit der kontinuierlichen \u00dcberwachung durch EASM die getroffenen Ma\u00dfnahmen validieren \u2013 als wirksam oder eben nicht.<\/p>\n

Sicherer mit stetigem und zentralem EASM<\/h3>\n

Das ist nur ein Beispiel, das zeigt: F\u00fcr einen effektiven Schutz der aus dem Internet erreichbaren Angriffsfl\u00e4che reichen Einzelma\u00dfnahmen wie halbj\u00e4hrlich durchgef\u00fchrte Penetrationstest oder Vulnerability-Scans nicht aus. Auch der Einsatz eines \u201cFlickenteppichs\u201d aus Punktl\u00f6sungen und -prozessen wiegt IT-Verantwortliche oft in falscher Sicherheit, denn nach offiziellen Vorgaben ist alles in Ordnung \u2013 aber nur, weil kritische Assets und Sicherheitsl\u00fccken durchs Raster fallen k\u00f6nnen. Ein effektives EASM geht \u00fcber reine Compliance-Standards hinaus und minimiert das externe Cyberrisiko auf Basis zweier Aspekte. <\/p>\n

Der erste ist Kontinuit\u00e4t<\/strong>:<\/strong> Es muss regelm\u00e4\u00dfig sichergestellt werden, dass alle externen Assets korrekt erfasst und hinsichtlich ihres Risikostatus auf dem neuesten Stand sind. Der zweite ist Einheitlichkeit:<\/strong> Wer bei einzelnen Teilschritten wie Erkennung und Klassifizierung bis hin zur Risikobewertung, -priorisierung und Remediation mit Insell\u00f6sungen \u201cnachbessert\u201d, optimiert damit nicht zwangsl\u00e4ufig auch den Gesamtprozess. Eine effektive Verringerung des externen Cyberrisikos kann \u00fcber eine zentrale Plattforml\u00f6sung f\u00fcr EASM erfolgen, die alle vier Phasen abdeckt. Sie identifiziert und analysiert \u2013 beispielsweise in einem w\u00f6chentlichen Turnus \u2013 automatisch alle relevanten Assets und minimiert so die Wahrscheinlichkeit, dass wichtige Risiken \u00fcbersehen werden. <\/p>\n

Anschlie\u00dfend gibt sie IT-Verantwortlichen konkrete Handlungsempfehlungen, indem sie kontinuierlich aufzeigt, welche die f\u00fcr das Unternehmen derzeit jeweils wichtigsten Sicherheitsl\u00fccken sind, die umgehend geschlossen werden m\u00fcssen. Damit das effektiv und binnen k\u00fcrzester Zeit geschehen kann, sollte sich die EASM-L\u00f6sung zudem \u00fcber entsprechende Schnittstellen in bestehende Prozesse und Systeme integrieren lassen. Das erm\u00f6glicht eine nahtlose Weitergabe aller relevanten Informationen und sorgt daf\u00fcr, dass die kritischen Risiken schneller intern verstanden und Remediation-Ma\u00dfnahmen zeitnah getroffen werden k\u00f6nnen. <\/p>\n

Am Ende kommt es jedoch auch immer auf die Verantwortlichen im Unternehmen an. Denn eine technische L\u00f6sung kann zwar eine schnelle MTTD (Medium Time To Detection) garantieren und relevante Informationen bereitstellen, die letztlich relevante MTTR (Medium Time To Remediation) h\u00e4ngt allerdings von der Reaktionsschnelligkeit der zust\u00e4ndigen Abteilungen ab. Wenn Technologie und Mensch \u201cHand in Hand\u201d arbeiten, sind die oben genannten vier Schritte f\u00fcr Unternehmen ein probater Weg, um das externe Cyberrisiko zu minimieren. (jm)<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

IT-Security-Verantwortliche sollten die Angriffsfl\u00e4che permanent analysieren und sch\u00fctzen. Dazu m\u00fcssen sie stets im Blick haben, welche Assets \u00fcber das Internet erreichbar sind. Foto: NicoElNino \u2013 shutterstock.com Von IoT-Devices \u00fcber Cloud-basierte Infrastrukturen, Web-Applikationen und Firewalls bis hin zu VPN-Gateways: Die Anzahl unternehmenseigener Assets, die mit dem Internet verbunden sind, steigt exponentiell an. Sie erm\u00f6glichen beispielsweise den […]<\/p>\n","protected":false},"author":0,"featured_media":998,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-6368","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/6368"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=6368"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/6368\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/998"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=6368"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=6368"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=6368"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}