Im Abschnitt Methodik wird näher erläutert, wie Rapid7 Project Sonar^[3] nutzt, um das Internet nach gefährdeten Systemen und Geräten zu scannen. Bei jedem DB 320-Unternehmen wurden im Durchschnitt etwa 88 gefährdete Geräte festgestellt. Dieser Wert ist weder gut noch schlecht. Allerdings vergrößert jedes zugängliche System die Angriffsfläche eines Unternehmens und bietet Angreifern möglicherweise zusätzliche Gelegenheiten, in ein Netzwerk einzudringen. Anders ausgedrückt: Alle dem Internet exponierten Server und Geräte müssen richtig konfiguriert, verwaltet, gepatcht und geschützt werden, um das Risiko eines Cyberangriffs zu verringern. Es gibt keine Faustregel, anhand derer man einschätzen könnte, ab welcher Anzahl exponierter Dienste das Risiko zu hoch wird, denn zahlreiche Faktoren beinflüssen die Möglichkeiten eines Unternehmen, seine mit dem Internet verbundenen Ressourcen zu schützen. Dennoch: Je mehr Systeme exponiert sind, desto mehr Möglichkeiten bieten sich Angreifern, ganz gleich, wie gut diese Systeme geschützt sind.

In Abbildung 1 sind vier Sonderfälle mit mehr als 1.000 gefährdeten Diensten zu erkennen: Jeweils einer in den Bereichen Transport und Logistik, Automobil und Versicherung sowie zwei im Softwarebereich. Sofern Ihre Geschäftsprozesse erfordern, dass Ihre Assets aus dem Internet zugänglich bleiben sollen (wie es bei diesen Firmen der Fall zu sein scheint), sollten Sie über über etablierte Prozesse im Schwachstellenmanagement, Patching und Monitoring verfügen, um schnell auf festgestellte Sicherheitslücken oder auf Attacken reagieren zu können. Falls Ihre Geschäftsprozesse nicht der unmittelbare Grund für dieses Gefährdungspotenzial sind und/oder Sie nicht über einen reibungslos funktionierenden Identifikations- und Konfigurationsmangement-Prozess für Ihre Assets verfügen, sollte die Verringerung der Angriffsfläche Ihr oberstes Ziel sein, gefolgt vom Ausbau der genannten IT-/Sicherheitsbereiche.

Empfehlung: Verringern Sie Ihre Angriffsfläche: Unternehmen sollten sich zum Ziel setzen, nur Systeme und Geräte über das Internet zugänglich zu machen, wenn es für ihre Geschäftsprozesse erforderlich ist. Darüber hinaus müssen sie sicherstellen, dass solide Identifikations- und Konfigurationsmangement-Prozesse für ihre Assets vorhanden sind, um zu verhindern, dass die exponierten Systeme für Angreifer zum potenziellen Einfalltor ins Firmennetzwerk werden.

[3] Rapid7, Project Sonar, Rapid7, Project Sonar, https://www.rapid7.com/research/project-sonar (Letzter Zugriff: 12. Aug. 2019)

Phishing ist nach wie vor einer der am weitesten verbreiteten Angriffsvektoren für Cyberattacken gegen Unternehmen. Die Anti-Phishing Working Group (APWG), eine branchenübergreifende Überwachungsgruppe, hat im dritten Quartal 2018 die rekordverdächtige Anzahl von 250.000 Phishing-Meldungen gesammelt.^[4]</aLeider haben die meisten DB-320-Unternehmen noch keine modernen Schutzmaßnahmen gegen Phishing-Angriffe eingeführt.^[5]

Wie im Abschnitt Methodik beschrieben, kann anhand der DNS-Einträge festgestellt werden, wie gut ein Unternehmen seine E-Mail-Dienste gegen Spam und Phishing abgesichert hat. Hierzu werden die Einträge zum „Domain-based Message Authentication, Reporting and Conformance“ (DMARC) analysiert.^[6] DMARC ermöglicht Unternehmen,

• zu signalisieren, dass sie E-Mail-Authentifizierung verwenden, um zu beweisen, dass E-Mails nicht gefälscht sind,
• eine E-Mail-Adresse anzugeben, über die Informationen über E-Mail-Nachrichten gesammelt werden, die ihre Domain rechtmäßiger- oder unrechtmäßigerweise verwenden und
• eine Richtlinie für den Umgang mit Nachrichten festzulegen, deren Authentifizierung fehlschlägt (die Auswahlmöglichkeiten sind none, quarantine, und reject).

Sollten keine DMARC-Einträge oder ein DMARC-Eintrag mit dem Wert „none" vorliegen, ist diese erste Verteidigungslinie gegen Spam oder Phishing-Angriffe nicht vorhanden. Allerdings kann einnone-Eintrag auch darauf schließen lassen, dass sich ein Unternehmen auf dem Wege befindet, für E-Mail-Sicherheit zu sorgen und seine DMARC-Konfiguration einer Prüfung unterzieht, bevor es aktivere Schutzmaßnahmen für seine E-Mails ergreift.

Richtig konfigurierte DMARC-Einträge mit dem Wert quarantine oder reject weisen aktive E-Mail-Verteidigungsmaßnahmen auf. Abbildung 2 zeigt den Prozentsatz der DMARC-Nutzung (nach Konfigurationskategorie) für alle DB320-Unternehmen in einem jeweiligen Sektor. Grün gibt an, dass Unternehmen im betreffenden Sektor DMARC entweder implementiert haben oder sich auf dem Weg dorthin befinden. Leider deuten die Ergebnisse darauf hin, dass die große Mehrheit aller DB320-Unternehmen (73 %) noch keine modernen E-Mail-Sicherheitskonfigurationen eingeführt hat. Weitere 3 % weisen ungültige DMARC-Einträge auf, wodurch sich ihr Risiko, Opfer von Phishing-Attacken zu werden, stark erhöht. Bei lediglich 15 Unternehmen (5 %) war die DMARC-Konfiguration quarantine oder reject.

Da keine direkten Scans durchgeführt werden, werden DNS-Einträge nicht von der Opt-out-Liste von Project Sonar (siehe nächster Abschnitt) beeinflusst. Wir können uns daher einen umfassenderen Eindruck der E-Mail-Sicherheitskonfigurationen aller DB320-Unternehmen verschaffen, als es mit aktiven Scans nach gefährdeten Diensten der Fall wäre. Im Abschnitt Weitere Schritte (S. #) werden zusätzliche Maßnahmen zur Ausweitung des Untersuchungsspektrums beschrieben, mit deren Hilfe man einen vollständigeren Eindruck vom Stand der E-Mail-Sicherheit gewinnen kann.

Anders als bei den fehlerhaften DMARC-Einträgen im Nikkei-225-ICER (Verwendung von SPF-Einträgen in einem DMARC-Kontext) handelte es sich bei den ungültigen DMARC-Einträgen in der DB-320-Liste um technische Fehlkonfigurationen. Diese traten sowohl in den DMARC-Einträgen selbst als auch im Zusammenspiel zwischen DMARC-Einträgen und den Einstellungen in SPF-Einträgen sowie anderen Einträgen abhängiger Dienste auf. Dies unterstreicht, wie wichtig es ist, über Prozesse zu verfügen, mit denen eingangs und dann in regelmäßigen Abständen neu geprüft wird, ob die jeweiligen E-Mail-Sicherheitskonfigurationen Wirkung zeigen.

Empfehlung: Verwenden Sie DMARC DMARC ist bereits seit mehreren Jahren verfügbar und wird von fast allen größeren E-Mail-Anbietern unterstützt. Ursprünglich wurde DMARC zum Schutz gegen Phishing-Attacken verwendet, die sich gegen externe Kunden eines Unternehmens richten. Doch mittlerweile mach es DMARC Angreifern auch viel schwieriger, interne E-Mail-Adressen zu fälschen. Die Planung und Bereitstellung einer angemessen restriktiven DMARC-Konfiguration braucht Zeit. Dies zeigt sich an den drei DMARC-Stufen. Diese Zeitinvestition kann jedoch die interne und externe E-Mail-Sicherheit eines Unternehmens erheblich verbessern.

[4]Phishing Activity Trends Report, http://docs.apwg.org/reports/apwg_trends_report_q3_2018.pdf (11. Dez. 2018)

[5]Zumindest für ihre in der DB-320-Liste aufgeführte primäre Domain. Bei diesen Firmen wird zwar auf Markenseiten gegebenenfalls DMARC verwendet, doch um Vergleichbarkeit mit der Methodik früherer Berichte zu gewährleisten, wurden nur die „Hauptdomains“ der jeweiligen Firmen untersucht.

[6]DMARC, https://dmarc.org (Letzter Zugriff: 12. August 2019)

[7]Auf der CyberUK 2019 merkte das britische NCSC an, dass der Übergang von „No DMARC“ zu „reject“ für Unternehmen mit komplexer oder vielschichtiger E-Mail-Kommunikation gut und gerne 18 Monate in Anspruch nehmen kann.

Eines der wesentlichen Ziele der Industry Cyber Exposure Reports ist, Einblicke in die weltweite Qualität von Cybersicherheitsmaßnahmen zu ermöglichen. Damit verbunden ist die Hoffnung, dass dieser externe Gesamtüberblick spürbar positive Veränderungen zur Folge haben wird, die die Online-Welt für uns alle sicherer machen.

Seit der Veröffentlichung unseres ersten ICER, der sich mit den Fortune 500-Unternehmen befasste, ist nun ein knappes Jahr vergangen. Zu diesem Anlass haben wir nun einen schnellen Blick auf den Schlüsselaspekt DMARC (E-Mail-Sicherheit) geworfen, um zu sehen, ob es Verbesserungen gegeben hat. Spoileralarm: Die gab es tatsächlich!

Bevor wir uns eingehender mit den Ergebnissen befassen, muss angemerkt werden, dass wir die DMARC-Prüfungsmethodik seit dem Fortune 500-Bericht von 2018 verändert haben. Damals prüften wir für jede Gruppe von Mail-Domains oder Apex-Domains (je nachdem, wie die jeweiligen Unternehmen ihre DNS-Einträge konfiguriert hatten), ob DMARC vorhanden und die entsprechende Syntax gültig war. Leider liegt DMARC nicht im Vakuum eines einzelnen DNS-TXT-Eintrags vor, sondern erfordert die genaue Konfiguration verschiedener DNS-Eintragstypen, damit das System funktioniert. Mit dem FTSE 250-ICER begann Rapid7 Labs erstmals damit, MX, SPF, DKIM und DMARC bei jedem Unternehmen vollständig zu überprüfen. Durch diese erweiterte Prüfung konnte im Rahmen des Nikkei 225-ICER ein ernstes, häufig auftretendes Konfigurationsproblem festgestellt werden. Zudem wurden, nachdem die gleiche Methodik auf den Domain-Korpus der Fortune 500-Unternehmen angewendet wurde, bei einigen dieser Domains verschiedene Arten von Problemen identifiziert.

Wie in der Abbildung zu sehen ist, haben 92 Unternehmen in ihrer primären E-Mail-Domain eine DMARC-Konfiguration angelegt, die mindestens den Wert „none“ aufweist. Ein Großteil dieser Unternehmen hat inzwischen eine richtige DMARC-Konfiguration eingerichtet. Angesichts der Flut schlechter Nachrichten im Bereich der Cybersicherheit ist dies eine ermutigende Meldung.

Leider folgen schlechte Nachrichten den guten häufig auf dem Fuße: Bei unseren DMARC-Prüfungen stellten wir fest, dass neun Einträge ungültig waren. Anders als bei den Ergebnissen der Nikkei 225-Unternehmen waren die Fehler hier verschiedenartig und nuanciert – von falschen Konfigurationen für die DMARC-Upstream-Reporting über die Verwechslung von DKIM und DMARC bis hin zu DMARC-Syntaxfehlern. Ungültige DMARC ist noch ein wenig schlimmer als nicht vorhandene DMARC, da Unternehmen eventuell fälschlicherweise davon ausgehen, dass ihre E-Mail-Systeme nun viel sicherer seien.

An der folgenden Abbildung können Sie ablesen, welche Branchen bei der Aufrüstung der E-Mail-Sicherheit am besten abschneiden. Die relativ großen Veränderungen in der „none“-Kategorie sind sehr erfreulich und signalisieren, dass 59 Fortune 500-Unternehmen im Gegensatz zu vorher nun konkrete Maßnahmen ergreifen, um ihre Anti-Phishing-Maßnahmen zu verbessern.

Rapid7 Labs begann im Rahmen des FTSE 250-ICERs^[8]mit der Untersuchung der SSL-/TLS-Konfiguration, als auffiel, dass viele FTSE-Unternehmen keine automatische Aktualisierung von HTTP-Anfragen durchführten. Zuvor verfügten die Unternehmen, aus denen sich die Datensätze für die Fortune 500- und ASX 200-Studien zusammensetzten, alle über primäre Webserver-Konfigurationen, durch die sichergestellt war, dass Sitzungen automatisch aktualisiert wurden, um SSL/TLS (d. h. „HTTPS“) zu verwenden, falls die ursprüngliche Verbindung über Klartext-HTTP hergestellt wurde.

Leider aktualisieren 21 DB 320-Unternehmen (6 %) HTTP-Anfragen nicht automatisch zu HTTPS (Abb. 3), was Besucher anfällig für verschiedene Formen eines Man-in-the-Middle-Angriffs macht.^[10]

Nur weil eine Website über automatische HTTPS-Aktualisierung verfügt, bedeutet das nicht, dass ihre HTTPS-fähigen Seiten richtig konfiguriert sind. Abbildung 4 zeigt eine Heatmap der HTTP-Header, die bei den untersuchten Websites mit übertragen wurden. In orangefarbener Schrift dargestellte Zeilenheader sollten entfernt oder so eingestellt werden, dass sie so wenige Informationen wie möglich preisgeben. Durch solche Metadaten können Angreifer sehr viel über mit dem Internet verbundene Assets in Erfahrung bringen.

Grüne Schrift weist auf Header hin, die als notwendig betrachtet werden.^[11] Diese können Verteidigungsschichten gegen Cross-Site Scripting und böswillige Verwendung von iframes aufbauen, die sich gegen Besucher Ihrer Website richten. Zudem können sie Sie alarmieren, falls der Versuch unternommen wird, über Ihre Website schädliche Ressourcen zu laden. Zusammengefasst liegt die Nutzung dieser wichtigen Header in allen Branchen zwischen 0 und ganz knappen 10 %.

Empfehlung: Nutzen Sie HTTPS und stellen Sie eine richtige Header-Konfiguration sicher Es handelt sich hier um einen eklatanten Konfigurationsfehler, den alle betroffenen DB 320-Unternehmen so bald wie möglich beheben sollten. HTTPS ist der Branchenstandard für alle namhaften Domains. Viele Browser kennzeichnen das Klartext-HTTP-Protokoll als „nicht sicher“^[12]. Stellen Sie zusätzlich zur HTTPS-Unterstützung sicher, dass Sie alle Ihnen zur Verfügung stehenden Konfigurationsmaßnahmen einsetzen, um Ihre Website und deren Besucher zu schützen.

[8]  https://blog.rapid7.com/2019/06/11/rapid7-releases-industry-cyber-exposure-report-ftse-250/ (11. Juni 2019)

[9]  17 Websites wiesen automatische JavaScript-Sondierungen ab.

[10] Man-in-the-Middle-Angriffe (MITM) https://www.rapid7.com/fundamentals/man-in-the-middle-attacks/ (Last (Letzter Zugriff: 12. August 2019)

[11]  Das OWASP Secure Headers Project, https://www.owasp.org/index.php/OWASP_Secure_Headers_Project (Letzte Änderung: 7. Jan. 2019 )

[12]  Alle Chromium-basierten Browser wie Google Chrome, Brave und die jüngsten Versionen von Microsoft Edge markieren HTTP als „nicht sicher“, und Mozilla-Browser wie Firefox markieren HTTP-Seiten als „nicht sicher“, wenn sie Formularelemente enthalten. Es wird davon ausgegangen, dass sich Mozilla-Browser bis Ende 2019 genau so verhalten werden wie Chromium-Browser.

Viele der Daten für diesen Bericht wurden durch aktive Scans und DNS-Abfragen gesammelt. Zusätzlich betreibt Rapid7 jedoch ein globales passives Sensornetzwerk mit dem Namen „Project Lorelei“.^[13] Das Lorelei-Sensorennetzwerk wird im Abschnitt Methodik im Detail beschrieben. Kurz gesagt handelt es sich dabei um eine Reihe von Honeypots mit Diensten wie HTTP/HTTPS, Telnet, SMB und so weiter, auf denen kein legitimer Internet-Traffic zu erwarten wäre.

Abbildung 5 zeigt die täglichen einmaligen Verbindungen mit dem Lorelei-Sensornetzwerk für alle Unternehmen in einem jeweiligen Sektor. Idealerweise sollte diese Tabelle leer sein. Sie zeigt allerdings Kontrolllücken in elf von 19 Sektoren in diesem Datensatz. Einige Sektoren, beispielsweise Industrie und Software, scheinen aus systemischen Gründen leicht erhöhte Fehlerquoten aufzuweisen. Doch das ist nur ein Teil des Gesamtbildes, da zahlreiche moderne Netzwerke sich hinter einer einzigen Internetadresse verbergen, über die Hunderte bis Tausende von Mitarbeitern, Dienstleistern und Geräten kommunizieren.

Abbildung 5 ist hilfreich, um das Vorliegen der Lücken zu demonstrieren. Doch um ihren Umfang zu beschreiben, brauchen wir eine andere Darstellung. Statt der Einzelverbindung zeigt Abbildung 6 die Gesamtzahl der täglichen Verbindungen mit Project Lorelei für alle Unternehmen in den untersuchten Branchensektoren. Bitte beachten Sie, dass die Y-Achse der einzelnen Grafiken nicht einheitlich ist. Durch diese freie Skalierung können wir einen näheren Blick auf jede Branche werfen, um mögliche Muster und Problembereiche zu erkennen. Wir können festhalten: Nur weil eine Branche eine geringe Zahl einzelner Knoten aufweist, die sich mit den Lorelei-Sensoren verbinden, heißt das nicht, dass diese inaktiv sind. Häufungen in dieser Ansicht könnten auf eine großflächige Malware-Infizierung innerhalb eines Unternehmens (d. h. Dutzende, Hunderte oder Tausende infizierter Systeme, die sich mit dem Internet verbinden) oder die Einbindung einiger weniger Systeme in DoS-Kampagnen hindeuten.

Einige Verbindungen stellen ernsthaftere Bedrohungen dar als andere. Vier der am häufigsten auftretenden Verbindungstypen, die Unternehmen mit Lorelei herstellen, sind besonders gefährlich. Wie in Abbildung 7 zu sehen ist, zeichnete Lorelei in der ersten Jahreshälfte 2019 täglich Verbindungen auf, die darauf hindeuten, dass mehrere Unternehmen von den folgenden Angriffsarten betroffen waren:

• Mit SMB in Verbindung stehende Malware (z. B. WannaCry, WannaMine und NotPetya);
• DNS-DoS-Attacken;
• E-Mail Brute-Force Angriffe;
• Brute-Force-Angriffe auf Klartext-Anmeldedaten in Telnet/FTP/IMAP/LDAP; und
• Brute-Force-Angriffe auf die SSH-verschlüsselten Anmeldedaten.

Empfehlung: Behalten Sie die Egress-Filter im Auge

Mit einem gewissen Maß an Honeypot-Traffic ist stets zu rechnen. Immerhin sind im modernen Internet zahlreiche opportunistische Angreifer unterwegs, die es auf die schwächsten Ziele abgesehen haben. Im Falle des beobachteten fehlgeleiteten Traffics muss betont werden, dass Netzwerkverbindungsfehler immer wieder passieren. Nichtsdestotrotz, aus dem unzweifelhaft aus DB 320-Quellen stammenden Traffic lässt sich ablesen, dass diese Unternehmen unzureichendes Egress-Filtering betreiben. Netzwerkadministratoren sind es gewohnt, reibungslose und unterbrechungsfreie Konnektivität sicherzustellen und Korrekturmaßnahmen vorzunehmen, wenn Verbindungen ausfallen. Umgekehrt ist es aber auch ihre Aufgabe, zu verhindern, dass fehlgeleiteter und schadhafter Traffic ihre Domains verlässt. Die Regeln für ausgehenden Traffic sollten sowohl aus dem Datenzentrum als auch aus den Tiefen des LANs regelmäßig geprüft und getestet werden, um zu vermeiden, dass eine Fehlkonfiguration unabsichtlich zu einem Sicherheitsverstoß von innen führt.

[13] Rapid7 Project Lorelei, https://www.rapid7.com/research/project-Lorelei/ (Letzter Zugriff: 12. August 2019)

Ohne Frage hat sich das Internet zum Rückgrat des internationalen Handels in praktisch jeder Branche und Region entwickelt. Diese umfangreiche Vernetzung hat zur Folge, dass kein Unternehmen isoliert agiert. Heutzutage ist es fast unmöglich ist, eine Website, einen Geschäftsprozess oder ein digitales Shopsystem zu betreiben, ohne in irgendeiner Form auf Drittparteien zurückzugreifen. Je größer die digitale Präsenz eines Unternehmens, desto höher die Wahrscheinlichkeit, dass Details solcher Abhängigkeiten durchsickern, und zwar durch die exponierten Metadaten, die für die Verbindung zwischen solchen Diensten sowie deren Betrieb und nötig sind.

Dies hat leider zur Folge, dass jedes DB 320-Unternehmen verwundbar für gezielte Phishing-Angriffe ist, und zwar auf Grundlage der Metadaten von Drittanbieterdiensten, die in DNS-Einträgen offengelegt werden. Zudem setzt jedes DB 320-Unternehmen sich selbst und die Besucher seiner Website durch die Nutzung unsachgemäß konfigurierter Drittanbieterdienste einem Risiko aus. Nur drei der untersuchten Primärwebsites sorgten durch die Verwendung von Content Security Policies^[14] immerhin für ein Mindestmaß an Schutz vor Drittparteirisiken.

Wenn ein Unternehmen zur Ergänzung seiner Online-Assets Ressourcen Dritter verwendet, trägt es die mit diesen Ressourcen verbundenen Risiken mit. Verwundbare Drittanbieter-Ressourcen können als Einfallvektor für einen Angriff auf ein sie nutzendes Unternehmen verwendet werden. Im September 2018 beispielsweise stellten Sicherheitsexperten fest, dass viele Websites aufgrund ihrer Abhängigkeit von externen Content Delivery Networks (CDNs) anfällig für webbasierten Kreditkartenbetrug („Skimming“) waren.^[15] Ein weiteres Beispiel war die Verwendung eines kompromittierten CDNs durch die Syrische Elektronische Armee im Jahr 2015, um die Webpräsenz eines großen Nachrichtenmediums zu übernehmen und so personalisierte Push-Nachrichten an dessen Leser zu versenden.^[16]

Im Rahmen dieser Studie wird das Vorliegen einer Gefährdung durch Drittanbieterrisiken folgendermaßen definiert:

• Ein untersuchtes Unternehmen greift für den Aufbau seiner eigenen Websites und Anwendungen erkennbar auf Ressourcen von Drittanbietern zurück; oder
• ein untersuchtes Unternehmen enthüllt durch potenziell vertrauliche Artefakte in den öffentlichen Metadaten, welche Leistungen von Drittanbietern es aktiv verwendet.

Im Abschnitt Methodik wird näher beschrieben, wie Attribute von Drittparteirisiken gesammelt und analysiert werden.

Die Heatmaps in Abbildung 8 bis 11 zeigen die am häufigsten verwendeten externen Drittparteiquellen aller Branchen. Die Farben repräsentieren eine normierte Wertung. Das bedeutet, dass die Farben nicht nach Gesamtzahl vergeben werden, sondern anhand der Anzahl der in der jeweiligen Branche vorhandenen Firmen ein normierter Indexwert berechnet wird. Um einen Vergleich anhand beider Messarten zu ermöglichen, wird neben den normierten Indexwerten auch die entsprechende Anzahl aufgeführt.

Seit dem Nikkei-225-ICER haben wir Tag-Manager^[17] aus der Liste der Drittanbieterdienste gestrichen. Richtig eingesetzt stellen diese kein zusätzliches Risiko dar, sondern können vielmehr zum Schutz der Website und ihrer Besucher beitragen.

Von einigen der aufgeführten Drittanbieterdienste ist anzunehmen, dass sie sehr gut gegen Cyberangriffe geschützt sind und dass sich die Gefährdungslage für Unternehmen durch ihre Verwendung nicht wesentlich vergrößert. Beispielsweise ist es höchst unwahrscheinlich, dass Google Analytics in einer Weise kompromittiert werden könnte, die es Angreifern ermöglicht, es als Einfallvektor für gegen seine Kunden gerichtete illegale Aktivitäten zu nutzen. Die weitreichende Nutzung von Drittanbieterdiensten wie DoubleClick, in dessen Netzwerk regelmäßig schädliche Werbeanzeigen festgestellt werden, vergrößert allerdings das gemeinsame Risiko in allen Sektoren.

Abbildung 13 legt den Fokus auf den zweiten Aspekt des Drittanbieterrisikos: Die Nachvollziehbarkeit der Nutzung von fremden Anwendungen und Cloud-Services.

DNS-Einträge können nicht nur Verbindungsadressen wie <www.rapid7.com> enthalten, sondern auch sichere E-Mail-Konfigurationen preisgeben, wie im Abschnitt Verteidigungsmaßnahmen gegen Phishing näher beschrieben wurde. Des Weiteren können DNS-Einträge Rückschlüsse darauf zulassen, welche Drittanbieter ein Unternehmen nutzt – von der Anwendungsentwicklung über das Hosting von Cloud-Umgebungen bis hin zum Filesharing.

Über Verifikationsinformationen, die in frei definierbaren TXT-Einträgen gespeichert werden, kann man beispielsweise erfahren, welche Dienste verwendet werden. Tabelle 1 enthält einen Auszug aus den DNS-TXT-Einträgen für rapid7.com zur Veranschaulichung:

Tabelle 1: Auszug DNS-TXT-Einträge rapid7.com

Die Experten von Rapid7 haben im Rahmen dieser Studie anhand der mit Project Sonar gesammelten DNS-Daten die TXT-Einträge der DB 320-Unternehmen untersucht. Dabei wurden nur Domain-Namen mit hohem Bekanntheitsgrad verwendet (eine erweiterte Untersuchung zusätzlicher Domains wird unter Weitere Schritte behandelt), und Abbildung 14 konzentriert sich ausschließlich auf die am meisten verbreiteten oder bekanntesten Drittanbieterdienste.

Wenig überraschend wird in jedem Branchensektor zu einem gewissen Grad Microsoft Office 365 verwendet, und es ist höchst unwahrscheinlich, dass Microsoft Opfer eines nichtstaatlichen Angriffs werden könnte, der aus Office 365 ein Einfalltor für gegen Unternehmen gerichtete Aktivitäten machen würde. Auch Google Apps wird von den DB 320-Unternehmen häufig genutzt, ebenso wie fast alle anderen bedeutenden Ressourcen.

Sobald Unternehmen Dienste abseits der etablierten und widerstandsfähigen Anbieter nutzen, erhöht sich das Risiko erfolgreicher Phishing- und sonstiger Attacken durch aufmerksame, fähige Angreifer, die einfach nur ein paar DNS-Anfragen stellen müssen, um eine Liste möglicher Ziele zu erstellen.

Empfehlung: Reduzieren Sie Ihre Gefährdung durch Drittanbieter Einzeln betrachtet mögen diese Ergebnisse nicht sehr bedrohlich wirken. Tatsächlich werden viele dieser „Validierungs“-Einträge nur einmal benötigt und können entfernt werden, nachdem die anfängliche Validierung durchgeführt wurde. Diese Einträge belegen, dass jemand der wahre Eigentümer einer Domain ist, da theoretisch nur der wahre Eigentümer DNS-Einträge hinzufügen, ändern oder löschen kann. Betrachtet man all diese Einträge als Ganzes, kann man möglicherweise einen Drittanbieterdienst finden, der von einer großen Zahl an Unternehmen genutzt wird, oder einen hochspezialisierten Dienstanbieter, den nur eine Handvoll Firmen nutzt. Diese können attraktive Ziele für Cyberkriminelle darstellen, die mehrere Unternehmen zugleich ins Visier nehmen wollen, was die Absicherung dieser Dienste zu einem umso wichtigeren Anliegen macht.

[14] Content Security Policies, https://content-security-policy.com/ (Letzter Zugriff: 12. Aug. 2019) Kevin Beaumont, „Magecart – new tactics leading to massive unreported fraud“, DoublePulsar, 19. Sept. 2018, https://doublepulsar.com/magecart-new-tactics-leading-to-massive-unreported-fraud-5211c9883dea

[16]  Thu Pham, „Malicious Hackers Take Over Media Sites via Content Delivery Network Providers“, Duo Security, 19. Mai 2015, https://duo.com/blog/malicious-hackers-take-over-media-sites-via-content-delivery-providers

[17] Tag management system, https://en.wikipedia.org/wiki/Tag_management_system (Letzter Zugriff: 12. Aug. 2019)

Die Art der exponierten Dienste steht in direktem Zusammenhang mit dem Ausmaß der Gefährdung (d h. einige Dienste sind weniger „sicher“ als andere). Abbildung 14 zeigt, dass auch DB 320-Unternehmen nicht gegen Angriffe gefeit sind, die diese beiden extrem verwundbaren Dienste zum Ziel haben: Telnet und die Windows File Sharing.

Server Message Block (SMB) sticht als einer der gefährlichsten Dienste hervor, die Systeme angreifbar machen. SMB ist ein All-in-One-Protokoll für die Dateifreigabe und Remoteverwaltung, das in der Regel unter Windows läuft und seit Jahrzehnten für Researcher wie Angreifer ein attraktives Ziel darstellt. MS03-049 in 2003, MS08-067 (Conficker) in 2008 und MS17-010 (EternalBlue) in 2017 hatten ihren Ursprung allesamt in der Komplexität dieses Protokolls und seiner zentralen Bedeutung für das Windows-Netzwerk.^[18] Erst kürzlich bildeten SMB-Schwachstellen das Kernstück der WannaCry- und NotPetya-Attacken, die ganze Netzwerke lahmlegten, erhebliche Störungen kritischer Geschäftsprozesse zur Folge hatten und dadurch bei vielen Firmen Umsatzeinbußen im Bereich von mehreren Millionen Dollar verursachten.^[19]

Die Gefährdung durch ungeschützte Telnet-Dienste ist mit der durch SMB vergleichbar. Telnet stammt noch aus der Anfangszeit des Internets. Der offizielle „moderne“ Standard wurde 1983 entwickelt.^[20] Es handelt sich dabei um ein Klartextprotokoll für die direkte Anmeldung auf Servern und Netzwerkgeräten, in aller Regel mit dem Zweck, unmittelbar auf der Betriebssystemebene des entsprechenden Geräts Befehle und Skripte auszuführen. Telnet-Dienste sind seit Langem dafür berüchtigt, immer wieder Schwachstellen aufzuweisen, die Unternehmen dem Risiko aussetzen, dass ihre Benutzerdaten gestohlen, ihr Traffic aktiv oder passiv abgehört oder per Remoteverbindung Code in ihrem System ausgeführt wird. Die Klartextform des Protokolls hat zur Folge, dass ein Angreifer in einer entsprechenden Position im Netzwerk alle Benutzernamen, Passwörter oder übertragenen Daten mitlesen kann. Endpunkte mit gestohlenen, schwachen oder einfachen Standard-Passwörtern können „gekapert“ und direkt über ihr Betriebssystem dazu gebracht werden, schadhaften Code auszuführen.

Die positive Erkenntnis ist, dass nur in einigen wenigen Branchen einzelne Unternehmen existieren, bei denen diese problematischen Dienste einer offenen Gefährdung ausgesetzt sind. In einer idealen Welt wären Telnet und SMB sicherlich bereits ganz aus dem modernen Internet verschwunden. Allerdings haben die DB 320-Unternehmen beim Schutz gegen SMB- und Telnet- Gefährdungen sowohl absolut als auch relativ das bislang beste Ergebnis erzielt, besonders im Vergleich zu den Fortune 500.^[21]

Empfehlung: Beseitigen Sie offen zugängliches SMB und Telnet: Auch wenn diese Dienste – insbesondere Windows SMB – unter den DB 320-Unternehmen nur sehr selten zu finden sind: Es gibt keine sichere Möglichkeit, SMB-Dienste im öffentlichen Internet anzubieten. Entsprechend arbeitet Microsoft daran, die SMB-Gefährdung regulärer Desktop- und Laptop-Nutzer schrittweise zu minimieren. Zum Beispiel wird in der aktuellen Microsoft-Dokumentation ausdrücklich empfohlen, SMB an Perimeterfirewalls zu blockieren. Windows 10-Rechner sperren den Zugang zu Port 445 automatisch.^[22] Selbst wenn SMB auf nur einem Gerät genutzt wird, kann dies ausreichen, um ein gesamtes Firmennetzwerk mit WannaCry, NotPetya oder deren moderneren Varianten zu infizieren (oder sogar erneut zu infizieren).

Heutzutage gibt es weder technische noch praktische Gründe dafür, einen Telnet-Dienst zu nutzen. Telnet wurde vom Secure Shell (SSH) Transport Layer Protocol abgelöst, das Transportverschlüsselung gewährleistet und die Verwendung digitaler Zertifikate zur Authentifizierung von Verbindungen ermöglicht.^[23] Sollte ein Gerät wirklich nicht in der Lage sein, SSH anstelle von Telnet auszuführen, ist es zu unsicher, um mit ihm eine Verbindung ins öffentliche Internet herzustellen – erst recht nicht unter Verwendung eines 40 Jahre alten, nicht verschlüsselbaren Protokolls. Zu beachten ist, dass rund ein Viertel (80) aller DB 320-Unternehmen SSH-Dienste zugänglich machen, ohne Telnet-Dienste offenzulegen. Es scheint also, dass die Stärke dieses Protokolls in gewissem Maße anerkannt wird.

[18]  Rapid7, National Exposure Index 2018, „Inappropriate Services“, S. 14, 7. Juni 2018, https://www.rapid7.com/globalassets/_pdfs/research/rapid7-national-exposure-index-2018.pdf.

[19]  Bob Rudis, „No More Tears? WannaCry, One Year Later“, Rapid7, 14. Mai 2018, https://blog.rapid7.com/2018/05/14/no-more-tears-wannacry.

[20]  J. Postel und J. Reynolds, Telnet Protocol Specification, Internet Engineering Task Force, Mai 1983, https://tools.ietf.org/html/rfc854.

[21]  Rapid7, Industry Cyber-Exposure Report: Fortune 500, S. 13–14, 11. Dez. 2018.

[22]  Microsoft, Richtlinien für die Sperrung bestimmter Firewall-Ports, um zu verhindern, dass SMB-Datenverkehr die Unternehmensumgebung verlässt, 31. August 2016, https://support.microsoft.com/en-us/help/3185535/guidelines-for-blocking-specific-firewall-ports-to-prevent-smb-traffic.

[23] T. Ylonen und C. Lonvick, The Secure Shell (SSH) Transport Layer Protocol, The Internet Society, Jan. 2006, https://tools.ietf.org/html/rfc4253 (Letzter Zugriff: 12. Aug. 2019)

Die richtige Konfiguration, regelmäßige Patches und die Verwendung unterstützter Versionen Ihrer Betriebssysteme und internetseitigen Anwendungen können einen wesentlichen Beitrag zum Schutz gegen Angreifer leisten. Verwenden Unternehmen aktualisierte Softwareversionen nicht, vergrößern sie damit das Risiko eines Angriffs auf bekannte Schwachstellen, die nicht mit einem Patch behoben werden. Leider verwenden die meisten DB 320-Unternehmen ältere und häufig nicht länger unterstützte Versionen der drei erfolgreichsten Webserver: Microsoft Internet Information Services (IIS), Apache HTTPD und nginx von F5.

Microsoft IIS

Microsofts IIS war laut Netcraft^[24] im August 2019 der drittbeliebteste Webserver weltweit. Bei deutschen Großunternehmen ist er jedoch der Spitzenreiter. Abbildung 15 zeigt, dass Project Sonar 2.764 IIS-Server mit zuordenbaren Versionsnummern in 169 Unternehmen aus 18 der 19 DB 320-Branchen gefunden hat.

Abbildung 16 zeigt die Versionsverteilung (d. h. wie viele unterschiedliche IIS-Instanzen in einem einzelnen Unternehmen vorhanden sind) von IIS-Servern über die DB 320-Branchen. Bei etwas mehr als 39 % wird nur eine einzige IIS-Version verwendet. Fast 32 % jedoch verwenden mehr als drei unterschiedliche Versionen. Diese Versionsunterschiede sowie die Weiterverwendung von IIS-Versionen, die das Ende ihrer Lebensdauer erreicht haben, machen den Schutz und die Verwaltung komplexer und vergrößern die Wahrscheinlichkeit, dass IIS-Server mit älteren Versionen zu einem Zugang für Angreifer werden.

Apache HTTPD

Bei Apache ist das Thema Webserver-Versionen noch ein Stück weit komplexer. Abbildung 17 zeigt, dass Project Sonar 2.272 Apache-Server mit 53 unterschiedlichen Versionsnummern in 158 Unternehmen in 17 der 19 DB 320-Branchen gefunden hat. Die Versionsverteilung der Apache-Server (Abbildung 18) zeigt, dass bei fast der Hälfte aller Unternehmen (47 %) nur eine einzige Version von Apache HTTPD offen liegt. Dagegen sind es bei gut 35 % drei oder mehr unterschiedliche Versionen. Wie bereits erwähnt kompliziert sich die Verwaltung dadurch zusätzlich.

Allein die Verwendung unterschiedlicher Softwareversionen ist schon beunruhigend. Die meisten entdeckten Versionen sind allerdings auch bereits weit älter als ein Jahr alt. Das lässt darauf schließen, dass Unternehmen ihre Apache-Installationen nicht auf dem neuesten Stand halten. Anders als bei IIS müssen Unternehmen für die Katalogisierung und Identifikation der Versionen und Patch-Level von Apache-Servern Schwachstellenmanagement-Tools von Drittanbietern einsetzen. Die Apache Foundation bringt regelmäßig neue Versionen heraus, die neue Funktionen enthalten, Probleme beheben und Sicherheitslücken schließen. Hinzu kommt, dass es sich bei Apache HTTPD um Open-Source-Software handelt. Potenzielle Angreifer haben also vollen Zugriff auf den Quellcode und können dadurch leichter Schwachstellen entdecken und Exploits entwickeln.

nginx

In der Netcraft-Erhebung vom August 2019 mag der nginx-Webserver zwar Spitzenreiter sein, doch unter den DB 320-Unternehmen belegt er lediglich den dritten Platz bei den von Project Sonar entdeckten Servern (insgesamt 982). Abbildung 19 zeigt, dass 53 unterschiedliche Versionsnummern in 99 Unternehmen aus 17 der 19 DB 320-Branchen gefunden wurden.

Die nginx-Ergebnisse in Abbildung 20 entsprechen in etwa denen bei Apache: 50 % aller Unternehmen verwenden eine einzige Version, rund 32 % drei oder mehr Versionen.

Obwohl man argumentieren könnte, dass es für ein kompetentes IT-Team durchaus im Bereich des Möglichen liegt, den Schutz mehrerer Versionen einer einzigen Webserver-Plattform sicherzustellen, wird die Lage komplizierter, wenn mehr als ein Technologieanbieter mit im Spiel ist. Fast die Hälfte aller DB 320-Unternehmen nutzt zwei oder mehr unterschiedliche Technologieanbieter für ihre mit dem Internet verbundenen Webserver (Tabelle 2). Die Kombination aus unterschiedlichen Anbietern und unterschiedlichen Versionen erhöht deutlich das Risiko, Schwachstellen in der Konfiguration zu übersehen, die potenzielle Angreifer nur allzu gern aufspüren und auszunutzen.

Tabelle 2: DB 320 – gleichzeitig genutzte Anbieter^[25]

Empfehlung: Bemühen Sie sich um Versionskonsistenz Es mag trivial und offensichtlich klingen, dass Server gepatcht und instand gehalten werden müssen. Doch in großen Unternehmen kann es eine sehr komplexe Aufgabe sein, die Änderungskontrolle sowie die Ausfallzeiten von möglicherweise zum Kerngeschäft gehörenden Diensten zu planen. So mühsam diese Aufgabe auch sein mag: Für Unternehmen ist es lebensnotwendig, stets einen Überblick über ihre Angriffsfläche zu pflegen und Hand in Hand mit ihren Geschäfts- und Anwendungsteams dafür zu sorgen, dass unterstützte und gepatchte Softwareversionen verwendet werden.

[24]  Netcraft August 2019 Web Server Survey, https://news.netcraft.com/archives/2019/08/15/august-2019-web-server-survey.html (Letzter Zugriff: 12. Aug. 2019)

[25]  Aufmerksame Leser mit einem Taschenrechner oder genug Fingern zum Abzählen werden feststellen, dass die mittlere Spalte nur auf 214 Unternehmen kommt. Der Grund: Die restlichen Websites verwenden ein CDN wie Cloudflare oder Akamai, das die zugrunde liegende Servertechnologie maskiert. Diese Versionen klammern wir aus, da wir die Komplexität der Server dahinter nicht einordnen können.

Der Industry Cyber Exposure Report beschreibt mehrere auf öffentlich verfügbaren Internetverbindungen basierende Möglichkeiten, die Gefährdung spezifischer Unternehmen und Branchen durch bestimmte Cybersicherheitsrisiken zu messen. Obwohl die Ergebnisse dieser Untersuchung keinesfalls einen Gesamteindruck von der Cybersicherheit eines Unternehmens liefern, muss betont werden, dass sie auf ein erhebliches Gefährdungsniveau unter den Unternehmen des Deutsche Börse Prime Standard 320 hindeuten:

• Die Angriffsfläche von DB 320-Unternehmen beträgt im Durchschnitt 88 Server/Geräte. Bei vielen Unternehmen sind es rund 300 Systeme/Geräte. Mehr Systeme bedeuten mehr Gelegenheiten für opportunistische und gezielte Angriffe.
• Die überwiegende Mehrheit aller DB 320-Unternehmen (91 %) verwendet keine modernen E-Mail-Sicherheitskonfigurationen. Weitere 3 % weisen ungültige DMARC-Einträge auf, was ihr Risiko vergrößert, Opfer von Phishing-Attacken zu werden. Um sich zu schützen, sollten Unternehmen ihre DMARC-Konfigurationseinstellungen überprüfen und verstärken.
• Bei den meisten DB 320-Unternehmen in allen Branchen lagen im Hinblick auf das Patch-/Versionsmanagement für geschäftskritische Systeme mit Verbindung zum Internet ernsthafte Mängel vor. Unternehmen müssen dem Konfigurations- und Patch-Management hohe Priorität einräumen, damit sie nicht Opfer bekannter Schwachstellen in veralteter Software werden.
• 6 % der DB 320-Unternehmen schreiben für ihre primären Domains nicht die Verwendung von HTTPS vor und setzten die Besucher ihrer Websites damit dem Risiko eines Man-in-the-Middle-Angriffs aus.
• Dutzende Drittanbieterdienste werden von mehreren DB 320-Unternehmen genutzt. Dadurch vergrößert sich das Risiko, dass eine Schwachstelle bei einem dieser Drittanbieter zur Kompromittierung mehrerer Unternehmen führen könnte. Unternehmen müssen sicherstellen, dass ihre externen Dienstanbieter entsprechende Maßnahmen zur Verstärkung ihrer eigenen Sicherheit ergreifen. Zudem sollten sie beim Bezug solcher externer Dienste zu Hilfsmitteln wie Integritätssignaturen für Subressourcen greifen, um die Wahrscheinlichkeit einer Kompromittierung mehrerer Unternehmen zu verringern.
• Extrem bedrohte Dienste wie Telnet und Windows-Dateifreigabe kamen im DB 320-Korpus praktisch nicht vor. Es gab allerdings eine Ausnahme, d. h. sie waren vorhanden. Jedes Vorkommen erhöht die Anfälligkeit für eine Ausnutzung der Schwachstellen von SMB. Um die Gefährdung einzudämmen, sollten Unternehmen Port 445 blockieren, wo immer es möglich ist, und von Telnet zu SSH wechseln.

DB 320-Unternehmen verfügen in der Regel über umfangreiche Ressourcen und Zugang zu ausgezeichnetem technischen Fachwissen. Die Ergebnisse legen daher nahe, dass die Gefährdungslage bei Tausenden von Unternehmen, die kleiner sind als die DB 320, noch gravierender ist. Das digitale Ökosystem könnte von einem kontinuierlichen Austausch mit wichtigen Stakeholdern über die Gründe für diese fortdauernde Gefährdung sowie über mögliche Schritte zur Eindämmung der damit verbundenen Risiken für die Cybersicherheit sehr profitieren.

Dieser Bericht dokumentiert die Ergebnisse einer Untersuchung zur Gefährdung von Unternehmen durch bestimmte Cybersicherheitsrisiken. Die dafür verwendeten Daten wurden durch die Interaktion mit öffentlich zugänglichen Systemen über das Internet gewonnen. Die gewonnenen Daten wurden dann genutzt, um die Gefährdungslage der DB 320-Unternehmen nach Branchensektor zusammengefasst zu beziffern. Die Messung der Gefährdung auf dieser Ebene kann dabei helfen, gezielte Schritte zur Eindämmung von Cyberrisiken zu ergreifen, den Informationsaustausch zum Thema Cybersicherheit innerhalb der jeweiligen Branchen zu verbessern und Maßnahmen, mit denen Unternehmen sich vor künftigen Risiken schützen können, bekannter zu machen.

Seit 2016 hat Rapid7 jährlich die Gefährdungslage durch bestimmte Cyberrisiken in ausgewählten Ländern gemessen und entsprechende Berichte erstellt.^[26] Diese Informationen geben wir auf Länderebene an Computer Emergency Response Teams (CERTs) weiter, welche die Informationen zur Gefährdungslage näher untersuchen und Schritte zur Verringerung der erkennbaren Gefährdungen für ihre kritischen Dienste unterstützen können. Zur Erstellung dieser Berichte verwendet Rapid7 seine internetweite Scan-Plattform Project Sonar^[27] sowie das passive Sensornetzwerk Project Lorelei^[28], um zu ermitteln, ob Online-Assets verwundbare Internetdienste preisgeben oder verdächtige ausgehende Verbindungen herstellen. Anschließend fassen wir die Ergebnisse auf nationaler Ebene zusammen.

Die Zusammenfassung der Gefährdungsdaten auf nationaler Ebene verläuft relativ unkompliziert. Wir verwenden regelmäßig aktualisierte, hochwertige Datenbanken, die Länderstandorte mit über 98 % Genauigkeit mit Internetadressen in Verbindung bringen.^[29] Um die Gefährdung detaillierter zu messen, ist allerdings zusätzliche Arbeit erforderlich. Für eine umfangreichere Messung der Gefährdungslage eines spezifischen Unternehmens kann der in dessen Besitz befindliche und für seinen Geschäftsbetrieb genutzte Internetadressbereich analysiert werden. Wurde das Unternehmen einer Reihe von Internetadressen zugeordnet, lässt sich die Gefährdung durch bestimmte Cybersicherheitsrisiken durch öffentlich zugängliche Daten berechnen, die durch aktive Scans und passive Sensoren gewonnen werden. Im Abschnitt Methodik (S. #) werden die Schritte folgender Prozesse beschrieben:

• Zuordnung von Internetadressen und primären Internet-Domains zu DB-320-Unternehmen;
• Verwendung der Daten aus den aktiven Scans von Project Sonar zur Identifikation vorliegender Gefährdungen durch verwundbare Dienste und Systeme im dem jeweiligen Unternehmen zugeordneten Internetadressbereich;
• Vertiefung der Gefährdungsmessung durch die Ermittlung der Häufigkeit und Art der Interaktionen des zugeordneten Adressbereichs mithilfe des globalen passiven Sensorennetzwerks Project Lorelei von Rapid7;
• Ergänzung der direkt ermittelten Gefährdungslage durch Schlussfolgerungen über weitere Gefährdungen. Zu diesen Zwecken haben wir die „Metadaten“ der Unternehmen zugeordneten Internetadressbereiche untersucht, z. B. E-Mail-Sicherheitskonfigurationen aus DNS-Einträgen sowie erkennbare Versionsinformationen von Betriebssystemen und Anwendungen.

Der Messvorgang lässt sich in drei Hauptbereiche unterteilen, von denen jeder in einem der folgenden Abschnitte behandelt wird:

• Inferentielle Messungen mithilfe öffentlich zugänglicher DNS-Einträge, unter denen die Messung des Schutzes eines Unternehmens gegen Phishing-Attacken die größte Signifikanz besitzt;
• aktive Messungen mit Project Sonar von Rapid7, die sowohl die Erkennung öffentlich zugänglicher Systeme und Dienste als auch der Inhalte, die diese Systeme und Dienste offen legen, mit einschließen; und
• passive Messungen umit Project Lorelei von Rapid7, welches aufzeichnet, wann Systeme innerhalb eines Firmennetzwerks Verbindung zu dieser Ansammlung von Honeypots aufbauen und welche Aktionen sie über diese Verbindungen auszuführen versuchen.

Aktive Messung mit Project Sonar

Project Sonar scannt ein breites Spektrum von Diensten im Internet. Ein „Dienst“ kann dabei einen Web-, Mail-, Datei- oder Datenbankserver, Netzwerkgeräte oder sogar Kameras sowie andere Arten von Servern bezeichnen, die Anfragen über das Internet empfangen. Reagiert ein Dienst an einer bestimmten Internetadresse positiv auf eine Sondierung, wird das entsprechende Ergebnis zusammen mit den Antwortdaten erfasst. Ja nach Dienst können diese Antwortdaten detaillierte Versions- und Konfigurationsinformationen enthalten.

Rapid7 befolgt alle rechtlichen Einschränkungen, die für Internet-Scans gelten. Entsprechend kommen bei den Sondierungen im Rahmen von Project Sonar niemals Anmeldedaten, Exploits für bekannte Schwachstellen oder Datenpakete, die den Dienst gegebenenfalls schädigen könnten, zum Einsatz. Dabei ist unerheblich, wie offensichtlich oder bekannt diese Passwörter oder Exploits sind. Zwar sind die Bandbreite dessen, was wir scannen können sowie die Auswahl an Dienst-Metadaten, die wir abrufen können, dadurch an einigen Stellen eingeschränkt. Aber nichtsdestotrotz können wir ein breites Spektrum nützlicher Informationen erfassen.

Darüber hinaus hat sich Rapid7 eine weitere Einschränkung selbst auferlegt: Den „Opt-out“-Prozess. Unternehmen können bei Rapid7 beantragen, spezifische Internetadressbereiche aus den Project-Sonar-Scans auszunehmen. Rapid7 folgt solchen Aufforderungen und setzt die Adressbereiche auf eine schwarze Liste, für deren Einträge der Scanvorgang untersagt ist (Abbildung 21).

Anders als bei den Fortune-500-Unternehmen im ICER von 2018 hatte im zweiten Quartal 2019 keines der DB-320-Unternehmen einen Eintrag in der Opt-out-Liste.^[30]

Messungen mit Project Lorelei

Im Kern handelt es sich bei Project Lorelei um eine Ansammlung von fast 250 nicht öffentlich bekannt gemachten Systemen, die verschiedene Fake-Dienste wie HTTP, SMB, SSH und viele andere hosten. Diese Honeypots werden genauestens auf ungebetene Verbindungen untersucht, tun aber selbst nichts, um derlei Verbindungen zu provozieren oder anzulocken. Abgesehen von internetweiten Scanversuchen gibt es für ein Unternehmen keinen Grund, der eine Verbindung zum Lorelei-Sensornetzwerk rechtfertigen würde. Die von Lorelei aufgezeichneten Aktivitäten sind also ein qualitativ hochwertiger Indikator dafür, dass ein Unternehmen keine Kontrolle über seine ausgehenden Verbindungen hat. Dies lässt wiederum darauf schließen, dass der Traffic dieses Unternehmens für schädliche Aktivitäten genutzt oder durch falsch konfigurierte Dienste verursacht wird. Wenn also Kontakt mit Lorelei hergestellt wird, liegt im jeweiligen Unternehmen eine Gefährdung vor.

Messung des Webserver-Drittparteirisikos

Um einen Eindruck davon zu gewinnen, wie hoch das Drittparteirisiko mit dem Internet verbundener Webserver/Dienste ist, können wir die Ressourcen untersuchen, die beim Ladevorgang einer Website in den Browser geladen werden. Project Sonar übernimmt diese Aufgabe im großen Maßstab mithilfe eines virtuellen Webbrowsers, der die Seiten bekannter Domains der in der Studie behandelten Organisationen aufruft und die Aktivitäten beim Ladevorgang einer Seite protokolliert.

Diese Websites laden eine große Menge Drittparteiressourcen. Daher wäre eine vollständige Liste nur schwer verständlich und kaum visualisierbar. Daher wurde das Untersuchungsergebnis auf die am häufigsten auftretenden Drittparteiressourcen in der gewonnenen Liste reduziert.

[26]  Rapid7, National Exposure Index, 7. Juni 2018 (Letzter Zugriff: 12. Aug. 2019)

[27] Rapid7, Project Sonar, https://www.rapid7.com/research/project-sonar (Letzter Zugriff: 12. Aug. 2019)

[28]  Rapid7, Project Lorelei, https://www.rapid7.com/research/project-lorelei/ (Letzter Zugriff: 12. Aug. 2019)

[29] MaxMind, https://www.maxmind.com (Letzter Zugriff: 12. Aug. 2019)

[30]  Rapid7, Industry Cyber-Exposure Report: Fortune 500, S. 10–11, 11. Dez. 2018, (Letzter Zugriff: 12. Aug. 2019)

Die im Rahmen dieses Berichts angewendeten Verfahren und Prozesse zur Gefährdungsanalyse sind die ersten Schritte zur Ermittlung der allgemeinen „Cybergesundheit“ einer Branche und basieren auf einer Teilmenge möglicher Internettelemetriemessungen. Etwaige Mängel des Messvorgangs wurden ermittelt und werden in diesem Abschnitt behandelt.

Verbesserung der Zuordnung von Internet-Assets zu Organisationen

Der gebräuchlichste Internet-Protocol (IP)-Adressbereich (Version 4, IPv4) ist vollständig belegt. Entsprechend gibt es keine verfügbare „Reserve“ an IP-Adressblöcken, die einer Organisation zugewiesen werden könnten. Allerdings nutzen Unternehmen, die aktuell IPv4-Adressbereiche besitzen, diese nicht in vollem Umfang. Die Knappheit dieser begrenzten Ressource hat zur Entstehung eines Marktes zum An- und Verkauf von IPv4-Adressbereichen geführt.^[31] Während einige Unternehmen Anteile ihrer IPv4-Adressbereiche an Dritte verkauft haben, bleiben andere im Besitz ihrer Adressbereiche und vermieten diese selbstständig an andere Akteure. Diese Praxis kann zu Zuordnungsfehlern führen und ist besonders verwirrend, wenn mit Unternehmen verbundene Adressbereiche so an externe Hosting- und/oder Cloud-Anbieter vermietet werden, dass keine Zuordnung möglich ist.

Für diesen Bericht gingen die Researcher von Rapid7 sowohl beim Versuch einer vorläufigen Zuordnung als auch bei der Identifikation von Zuordnungsanomalien anfangs manuell vor und verglichen die Nutzung von Adressbereichen und die Zusammensetzung von Diensten mit der bekannter Hosting- und Cloud-Anbieter. Wie im Abschnitt Methodik (S. #) beschrieben wurde dieser Ansatz durch die Verwendung direkt zuordenbarer Ressourcen aus den DNS-Einträgen der Unternehmen sowie durch die Ableitung unternehmenseigener IPv4-Adressbereiche aus diesen Einträgen ergänzt. Es sind weitere Schritte geplant, um die Zuordnung der IP-Adressbereiche zu verbessern und diese Klassifizierung zu automatisieren. Dies wird uns ermöglichen, die Adressblöcke von Hosting- und Cloud-Anbietern herauszufiltern.

Vermeidung blinder Flecke durch Opt-outs

Untersuchungen wie dieser Bericht sind auf kontinuierliche, minimalinvasive Scans angewiesen, wie sie Project Sonar von Rapid7 ermöglicht. Entsprechend leidet die Community der Internet-Researcher darunter, wenn eine große Anzahl Firmen sich dafür entscheidet, von diesen Scans ausgenommen zu werden. Es gibt zwei Möglichkeiten, wie die negativen Auswirkungen der durch Opt-outs entstehenden blinden Flecke für Project Sonar künftig begrenzt werden können. Als verantwortungsvolle Internetbürger halten wir bei Rapid7 am Opt-out-Prozess fest. Eventuell wird das aktuelle Verfahren jedoch dahingehend überarbeitet, dass das Opt-out zu einem jährlichen Prozess wird. Unternehmen müssten jedes Jahr neu ihren Wunsch äußern, dass ihre IPv4-Adressbereiche auf der Opt-out-Liste verbleiben sollen. Daraus würde sich die Gelegenheit ergeben, die Vorteile der Scans durch Project Sonar erneut zu betonen. Zudem könnte man die Länge der Opt-out-Liste reduzieren, und die statistische Integrität der Untersuchungen wäre gesichert.

Die zweite Möglichkeit bestünde in einer simplen Erweiterung des Untersuchungsbereiches auf zusätzliche Angehörige einer Branche, und zwar unabhängig davon, wo sich deren Hauptsitz befindet. Zu diesem Zweck können andere bekannte Unternehmenslisten wie Inc. 5000, S&P 500, ASX 200, FTSE 250 oder DAX 30 herangezogen werden, um den Untersuchungsbereich für jede Branche deutlich zu erweitern und den Anteil nicht untersuchter IPv4-Adressbereiche auf (möglicherweise) unter 1 % zu reduzieren. Die zuvor beschriebenen Verbesserungen der Zuordnungsgenauigkeit und die Erweiterung der Reichweite sind wichtig, um die Tauglichkeit und Wirksamkeit des Prozesses sicherzustellen.

Verwendung zusätzlicher DNS-Einträge

Im Rahmen der E-Mail-Sicherheitsanalysen wurden bekannte DNS-Domains der Unternehmen in der DB-320-Liste verwendet. Die meisten dieser Unternehmen verfügen über Tochtergesellschaften und Marken mit eigenen DNS-Domains. Um den Bereich der Gefährdungsanalyse zu erweitern, wurden diese Marken-Domains ebenfalls überprüft. Wir werden weiter an der Entwicklung eines auf maschinellem Lernen basierenden Webcrawling- und Data-Mining-Prozesses arbeiten, um solche „Zusatzdomains“ zu identifizieren und ihre Daten in den in diesem Bericht beschriebenen Analysevorgang einbinden zu können.

Erweiterung der Ressourcensicherheitsanalyse

Die weiteren Bemühungen zum Aufspüren zusätzlicher Domainnamen werden sich direkt auf die für diesen Bericht verwendeten E-Mail-Sicherheitsanalysen auswirken. Darüber hinaus hat dieser Bericht nur einen Aspekt der E-Mail-Sicherheit in Augenschein genommen – DMARC. Daneben existieren noch weitere Ressourceneinträge, die andere E-Mail-Sicherheitskonfigurationen beschreiben. Ein Beispiel ist das Sender Policy Framework (SPF), das zusätzlichen Schutz gegen Spam bietet und Angreifer daran hindert, E-Mail-Domains für ihre Zwecke zu verwenden. Dieses wird in künftige Analysen mit einbezogen werden.

Andere Arten von DNS-Einträgen ohne Bezug zu E-Mails lassen ebenfalls Rückschlüsse auf bestimmte Sicherheits- und Gefährdungsaspekte zu. Auch diese Informationen werden untersucht und in künftige Analysen mit aufgenommen.

Analyse der mit Drittparteien verbundenen Risiken und Abhängigkeiten

Abschließend ist es möglich, eine Gesamtansicht der potenziellen Gefährdungslage der allgemeinen Internetpräsenz eines Unternehmens zu erstellen und die mit der Abhängigkeit von Drittparteien verbundene Gefährdung aller Firmen abzubilden. Hierzu wird neben weiteren indirekten, öffentlichen Maßnahmen eine Analyse der allgemeinen Konfiguration der DNS-Einträge eines Unternehmens durchgeführt, festgestellt, wie die IPv4-Netzwerke eines Unternehmens im Internet miteinander verknüpft sind und ermittelt, welche Drittparteiressourcen ein Unternehmen zum Betrieb seiner Webdienste und -anwendungen einsetzt.

[31] IPv4 Brokers, ARIN IPv4 Market Prices & Transfer Statistics, https://ipv4brokers.net/arin-ipv4-prices-transfer-statistics/ (Letzter Zugriff: 12. Aug. 2019)

Warum Deutsche Börse Prime Standard 320?

Die Zusammenfassung der Gefährdung spezifischer Branchen der deutschen Wirtschaft stellt eine spezielle Herausforderung dar. Erstens wächst die Anzahl der IP-Adressbereiche stetig. IPv4 allein unterstützt mehr als 4,2 Milliarden Adressen (von denen ein bestimmter Teil nicht zuweisbar ist), ganz zu schweigen vom IPv6-Adressbereich, der um ein Vielfaches größer ist. Diese Adressen werden verschiedenen Regierungen, Firmen und Dienstanbietern in aller Welt zugewiesen. Zweitens hält dynamische Infrastruktur (Cloud) zunehmend Einzug, wodurch es für Firmen immer häufiger üblich ist, IP-Adressbereiche für das Hosting der eigenen Dienste von anderen Firmen zu mieten. Traditionelle Methoden der Zuordnung von IP-Adressen zu bestimmten Unternehmen (beispielsweise durch die Verwendung des Suchtools WHOIS) werden dadurch unvollständig, da es sich beim Eigentümer der IP-Adresse möglicherweise nicht um den Eigentümer des Dienstes handelt, dessen Gefährdung untersucht wird.^[32]

Anstatt IP-Adressen Unternehmen zuzuordnen und die Branchen der Deutsche Börse Prime Standard 320 herauszufiltern, konzentrieren wir uns auf die Liste aus dem dritten Quartal 2019. Wir verwenden sie als repräsentative Auswahl, der wir globale IP-Adressbereiche und auf dynamischer Infrastruktur gehostete Dienste zuordnen, welche dann gefiltert werden.

Für die Auswahl der Liste der Deutsche Börse Prime Standard 320 aus dem dritten Quartal 2019 gab es verschiedene Gründe. Erstens handelt es sich um eine sehr breit aufgestellte Liste (siehe Tabelle 3), die Firmen anhand bewährter Grundsätze^[33] aufnimmt. Zusammengefasst machen die Unternehmen der Liste rund 6 % (Bruttoeinkommen) des deutschen Bruttoinlandsproduktes aus und beschäftigen weltweit sieben Millionen Menschen. Darüber hinaus haben 90 % (289) der aufgeführten Unternehmen ihren Sitz in Deutschland, was die Erstellung eines auf Deutschland konzentrierten Überblicks der Gefährdungslage und die Entwicklung von Modellen potenzieller wirtschaftlicher Auswirkungen gestattet.

Tabelle 3: Zusammenfassung DB-320-Konstituenten

Sechs Unternehmen (1&1 Drillisch, 3U Net, ecotel, freenet, QSC und Telefónica) bieten Cloud-, Internet- und/oder Mobilfunkdienste an. Entsprechend weisen sie internetseitige Unternetze von großem Umfang auf. Bei der Datenanalyse der anfänglichen Sondierung für den Bericht wurde schnell ersichtlich, dass die internetseitigen IPv4-Adressbereiche für Dienstanbieter- und firmeninterne Zwecke sich ausreichend stark überlagerten, um bei der Zählung der Geräte in diesen Netzwerkbereichen mit Sonar oder Lorelei die Ergebnisse zu verfälschen. Aus diesem Grund haben wir diese Bereiche ausgelassen. Die Primärdomains und Unternehmenswebsites jedoch wurden in die endgültige Analyse mit aufgenommen.

Um der Entanonymisierung der einzelnen DB-320-Unternehmen vorzubeugen, wurden „Verbraucher“, „Konsumgüter“ sowie „Lebensmittel und Getränke“ zur Metabranche „Konsumgüter und Nahrungsmittel“ und „Bau“ sowie „Industrie“ zur Meta-Industrie „Bau und Industrie“ zusammengefasst.

DB-320-Unternehmen sind sehr attraktiv für talentierte Bewerber und beschäftigen auf allen Ebenen Spitzenpersonal. Dies schließt interne und externe Beschäftigte im Netzwerk- und System-Management sowie fachkundige und erfahrene Mitarbeiter für die Entwicklung und den Betrieb von Anwendungen mit ein. Bei vielen dieser Unternehmen sind Mitarbeiter in Gremien vertreten, die Gruppen, welche sich mit der Entwicklung von IT- und Internetstandards befassen, führen und anleiten. Ein großer Teil der Unternehmen besteht seit mehr als 20 Jahren und verwendete bereits frühzeitig Internet-Technologien. Anders ausgedrückt: Sollte sich herausstellen, dass diese Gruppe von Unternehmen in einer bestimmten Weise gefährdet ist, könnte dies darauf hindeuten, dass die Lage bei Unternehmen von kleinerem Format noch gravierender ist.

Methodik der Zuordnung von Internet-Assets und Metadaten zu Unternehmen

Die Internet Assigned Numbers Authority (IANA) koordiniert die Steuerung wichtiger Schlüsselelemente für den reibungslosen Betrieb des Internets.^[34] Zwei für den Zuordnungsprozess zentrale Governance-Elemente sind Internet-Adressbereiche (oder IP-Adressen) und Domainnamen (das System, welches Webadressen wie http://www.beispiel.com/ in Internetadressen umwandelt, um Systemen eine Verbindung mit Internetressourcen zu ermöglichen).

Zuordnung von Internet-Adressbereichen zu einem Unternehmen

IANA delegiert die Verwaltung von Internet-Adressbereichen an eine überschaubare Menge globaler und regionaler Internet-Registries. Diese Registries delegieren bestimmte Internet-Adressblöcke weiter an nationale und „lokale“ Registries und koordinieren die mit diesen Zuteilungen verbundenen Metadaten. Die Registries auf nationaler und lokaler Ebene schließlich koordinieren die Internetanbieter (ISPs), die Benutzern und Unternehmen Internetadressen zuweisen.

Die mit diesen zugewiesenen Internetadressen verknüpften Metadaten wie beispielsweise der Name des Unternehmens, Standortinformationen, Kontaktpunkte und möglicherweise der zuständige Internetanbieter werden in einem System verteilter Datenbanken, dem so genannten WHOIS-Service, gespeichert. Der WHOIS-Service ist eine öffentlich zugängliche Datenquelle, über die Benutzer Informationen über eine IP-Adresse abrufen können. Dies schließt auch das Unternehmen, dem diese Adresse gehört, sowie dessen Kontaktpunkt mit ein. Jede Registry betreibt eine eigene WHOIS-Datenbank.^[35] Einzelpersonen können WHOIS für interaktive Suchanfragen an diese Systeme nutzen. Zudem werden WHOIS-Informationen in großem Umfang an Organisationen weitergegeben, die die Daten für technische Untersuchungen benötigen.

Wenn ein Unternehmen seine mit dem Internet verbundenen Ressourcen selbst verwalten möchte, stellt es eine Anfrage beim lokalen Internetanbieter oder der lokalen Registry und bekommt einen oder mehrere Blöcke zusammenhängender Internetadressen zur Verwendung zugewiesen. Die Metadaten dieser Zuweisung werden im entsprechenden WHOIS-Service gespeichert. Zur Veranschaulichung sind in Tabelle 4 die Adressblockzuweisungen für Rapid7 aufgeführt.

Tabelle 4: Zusammenfassung WHOIS-Eintrag Rapid7

Anders als bei den Unternehmen im Fortune-500-ICER erwies es sich angesichts des Detailreichtums der RIPE-Netzwerkzuteilungsdatenbank^[36] bei den DB-320-Unternehmen als weitaus einfacher, zur Ermittlung der im Firmenbesitz befindlichen Adressbereiche die IANA-Registry-Methode zu verwenden. Über 90 % der Unternehmen wiesen identifizierbare Einträge in der RIPE-IPv4-Registry auf. Das bedeutet nicht, dass den anderen 10 % keine Adressblöcke zugewiesen wurden. Vielmehr bedeutet es, dass es beim Versuch, diese Blöcke zuzuordnen, zu hohen Fehlerquoten kam.

Wie bereits erwähnt wurde darauf geachtet, IPv4-Adressbereiche von Unternehmen auszulassen, die auch als Internet- oder Cloud-Dienstanbieter für Endnutzer oder Firmen tätig sind.

Zuordnung von DNS-Einträgen zu Unternehmen

Auch für DNS-Einträge gibt es eine vergleichbare Registrierung mit entsprechendem Datenbankservice, die mit WHOIS vergleichbar ist. Dieser Service ist allerdings viel dezentralisierter und gibt den jeweiligen Unternehmen die direkte Kontrolle über alle zugrunde liegenden Einträge einer Domain. Sobald ein Domain-Name zugewiesen wurde (z. B., „rapid7.com“), richtet ein Unternehmen seinen eigenen DNS-Server ein (oder verwendet den eines DNS- oder Cloud-Dienstleisters). Anschließend veröffentlicht es die Einträge, die DNS-Namen einem breiten Spektrum von Eintragsarten und Werten zuordnen, und hält diese auf dem neuesten Stand. Unternehmen können nach Belieben Einträge hinzufügen, ändern oder löschen.

„A“-Einträge (Adressen) ordnen Namen Internetadressen zu (z. B. wird <www.rapid7.com> aktuell der Adresse 13.33.37.212 zugeordnet). Es ist allerdings auch möglich, einem Internetnamen andere Informationen zuzuordnen.

„TXT“-Einträge (Text) ermöglichen die Speicherung frei definierbarer Textstrings mit Internetnamen. Es existieren verschiedene Formstandards mit Regeln für die Erstellung speziell formatierter Texteinträge, mit denen zusätzliche Metadaten zur jeweiligen Internetnamen-Ressource oder dem rechtmäßigen Eigentümer der Domain vermittelt werden.

DMARC^[37] und SPF^[38] sind zwei zentrale TXT-Einträge, anhand derer man die „Sicherheit“ der E-Mail-Konfiguration ablesen kann. Mithilfe dieser Standards kann ein Unternehmen kommunizieren, welche Systeme für das Versenden von E-Mails in seinem Namen autorisiert sind und wie mit gefälschten E-Mails zu verfahren ist, die von Angreifern oder Spammern gesendet werden. Fehlende, unsachgemäße oder zu freigiebige Konfigurationen dieser Einträge setzen Unternehmen dem Risiko aus, Opfer von Spam und Phishing-Angriffen zu werden. Da Phishing für Angreifer, die im Netzwerk eines Unternehmens Fuß fassen, seit einigen Jahren das häufigste Mittel der Wahl ist, erhöhen mangelnde Sorgfalt und Aufmerksamkeit im Hinblick auf die richtige DMARC- und SPF-Konfiguration die Wahrscheinlichkeit, dass ein gegen das Unternehmen gerichteter Angriff Erfolg hat, erheblich. Jeder kann diese und andere Einträge aus dem DNS abfragen. Im Rahmen unserer Untersuchungen zur Cybersicherheit des gesamten Ökosystems führt Rapid7 Monat für Monat Millionen von DNS-Abfragen durch und speichert mit Zeitstempeln versehene Ergebnisse in einer umfangreichen historischen Datenbank, die groß angelegte Abfragen und die Nachverfolgung von Veränderungen über bestimmte Zeiträume ermöglicht.

Die DB-320-Liste aus dem dritten Quartal 2019 enthält die bekannten Primärdomains der Unternehmen auf dieser Liste. „www.volkswagenag.com“ beispielsweise ist die bekannte Domain des Autoherstellers Volkswagen. Diese Seiten wurden von Project Sonar systematisch gescannt und die zugehörigen DNS-Namen für die jeweiligen Unternehmen wurden verwendet, um das Vorhandensein von DMARC und SPF zu ermitteln.

[32] ICANN WHOIS, https://whois.icann.org/en (Letzter Zugriff: 12. Aug. 2019)

[33] Deutsche Börse Prime Standard, https://www.deutsche-boerse-cash-market.com/dbcm-en/primary-market/market-structure/segments/prime-standard (Letzter Zugriff: 12. Aug. 2019)

[34] Internet Assigned Numbers Authority, https://www.iana.org/ (Letzter Zugriff: 12. August 2019)

[35] RIPE WHOIS Database Index, https://www.ripe.net/about-us/ (Letzter Zugriff: 12. Aug. 2019)

[36] RIPE Database, https://apps.db.ripe.net/db-web-ui/#/fulltextsearch (Letzter Zugriff: 12. Aug. 2019)

[37] The DMARC Standard, https://dmarc.org/ (Letzter Zugriff: 12. Aug. 2019)

[38] RFC 7208, Sender Policy Framework, Apr. 2014 https://tools.ietf.org/html/rfc7208 (Letzter Zugriff: 12. Aug. 2019)

Rapid7 (Nasdaq: RPD) arbeitet an fortschrittlichen Sicherheitslösungen durch unsere Insight-Cloud, die auf Transparenz, Analytik und Automatisierung setzt. Unsere Lösungen vereinfachen komplizierte Sachverhalte und ermöglichen es Sicherheitsteams, effektiver mit IT und Entwicklung zusammenzuarbeiten, um Sicherheitslücken zu schließen, schädliche Aktivitäten zu erkennen, Angriffe zu untersuchen und abzuwehren sowie Abläufe zu automatisieren. Über 7.200 Kunden bauen auf die Technologien, die Dienstleistungen und die Forschung von Rapid7, um ihre Sicherheit zu verbessern und ihre Unternehmen sicher voranzubringen. Für weitere Informationen besuchen Sie unsere Website und unseren Blog oder folgen Sie uns auf Twitter.