Effektiv vorbeugen
Ein erster Schritt, um Risiken von den IT-Systemen fernzuhalten bzw. die Auswirkungen von Angriffen auf IT-Systeme zu begrenzen, sind präventive Maßnahmen. Man kann davon ausgehen, dass sich damit sicherlich mehr als 90 % der konventionellen Angriffe abhalten lassen. Ein aktueller Virenschutz auf z. B. einem Desktop-Rechner oder einem Laptop ist ein Beispiel dafür.

Die Notwendigkeit von präventiven Maßnahmen ist einleuchtend, aber dennoch sind diese Maßnahmen nicht immer möglich. So kann z. B. das Betriebssystem eines Medizinprodukts mit entsprechender Zulassung nicht einfach abgeschaltet oder ausgetauscht werden, weil der Hersteller des Betriebssystems diese Version nicht mehr unterstützt.

Sind Patches die Lösung?
Solange Hersteller, im Fall von erkannten Sicherheitslücken, z. B. Security Patches mit Mängeln oder negativen Einflüssen auf das IT-System selbst ausliefern, ist eine nicht bewertete Installation von Patches als Maßnahme zur Prävention zu hinterfragen. So lieferte z. B. Intel den ersten Patch für die Spectre/Meltdown-Sicherheitslücke [1] mit Fehlern aus, sodass die gepatchten Systeme teilweise spontan neu booteten. Auf der anderen Seite war z. B. das Schadprogramm WannaCry (Mai 2017) nur deshalb erfolgreich, weil einige Systeme noch nicht geschützt waren, obwohl die Sicherheitslücke im Microsoft Windows Betriebssystem (EternalBlue) schon seit Mitte April 2017 bekannt war und ein offizieller Patch dafür existierte. Patchen ist also ein zweischneidiges Schwert.

Bedeutung der Software
Software spielt im Zeitalter der Digitalisierung eine große Rolle, denn mit ihrer Hilfe können z. B. flexibel und schnell innovative Lösungen entwickelt werden, die durchaus ein disruptives Potenzial haben können (s. z. B. Airbnb, Uber). Marc Andreessen erklärte schon 2011 im The Wall Street Journal „Why Software is Eating the World" und erkannte damit schon frühzeitig deren gewaltiges Innovationspotenzial. Wir wollen uns an dieser Stelle der Diskussion um das disruptive Potenzial von Software entziehen und beschränken uns auf die Aussage, dass wir heute sehr viele Softwarelösungen im Einsatz haben und auch durchaus eine mehr oder weniger ausgeprägte Abhängigkeit von diesen Lösungen existiert. Diese quantitative Einschätzung stützt die Aussage, dass Software heute aber auch einen großen Beitrag zu existierenden Sicherheitslücken leistet (s. Kap. 08A07). Dem Angreifer reicht die Kenntnis einer einzigen Sicherheitslücke aus, um z. B. in ein Netzwerk einzudringen, während wir hingegen alle Lücken betrachten und schließen müssen. Sie dürfen davon ausgehen, dass Sicherheitslücken ganz gezielt ausgenutzt werden und diese daher in einem IT-Verbund Wegbereiter für erfolgreiche Angriffe sind. Im Darknet werden z. B. entsprechende (professionelle) Tools zum Kauf angeboten und sind damit auch für eine breite Masse verfügbar.

CVE-Datenbank
Im Internet existiert eine Datenbank, in der bekannte Sicherheitslücken (Vulnerabilites) und deren Beschreibung (Exposure) aufgeführt werden. In dieser Verwundbarkeitsdatenbank bekommt jede veröffentlichte Sicherheitslücke eine eindeutige, statische CVE-Kennung – Common Vulnerabilities and Exposures (CVE), eine kurze Beschreibung und mindestens eine Referenz zu einer öffentlichen Quelle dieser Information. Die Kennungen werden von der Mitre Corporation verwaltet, wobei der Inhalt der CVE-Datenbank jedem frei zugänglich ist. Die Abbildung 1 zeigt einen Ausschnitt der Ausgabe dieser Datenbank, wenn man z. B. nach „iPhone” sucht. Motivierte Leser können dieses Beispiel gern nachvollziehen [2], oder auch gerne nach anderen Produkten und Herstellern suchen.

Nimmt man z. B. CVE-2018-4172 unter die Lupe, dann erhält man die nachfolgenden Informationen, die auch noch einmal den sehr statischen Informationsgehalt einer in der CVE-Datenbank protokollierten Schwachstelle verdeutlichen (s. Abbildung 2).

Sicherheitslücken transparent machen
Bitte belasten Sie sich nicht mit der Frage, was das für eine Sicherheitslücke ist. Es geht hier lediglich um die Botschaft, dass zumindest einige Hersteller die Schwachstellen ihrer Produkte öffentlich dokumentieren. Die damit implizit verknüpfte Information, dass wohl nicht alle Hersteller in dieser Datenbank zu finden sind, ist prinzipiell nicht negativ zu bewerten. Ein Hersteller kann solche Informationen auch über seine Webseite bereitstellen. Wichtig ist erst einmal nur, dass solche Informationen transparent, qualifiziert und zeitnah bereitgestellt werden.

Mit Blick auf die Assets in Ihrem eigenen IT-Verbund (Anzahl, Art, Wert, Relevanz etc.) liegt es nahe, dass eine Anreicherung des CVE-Rohmaterials hilfreich ist, denn die CVE-Nummer dient primär nur der Buchführung. Um den Schweregrad einer Schwachstelle beurteilen zu können, sind weitere Informationen erforderlich; schließlich wollen Sie informiert darüber entscheiden, welche Maßnahmen Sie mit Blick auf eine identifizierte Schwachstelle treffen müssen. Über z. B. die National Vulnerability Database (NVD) des National Institute of Standards and Technology (NIST) erfolgt eine solche Anreicherung. Wenn Sie diese Datenbank nutzen [3] und in dieser nach CVE-2018-4172 suchen, dann erhalten Sie die nachfolgende Ausgabe (s. Abbildung 3).

Schweregrad
Eine Anreicherung fällt sicherlich sofort auf: die CVSS Severity. Dabei handelt es sich um eine Wichtung der Schwachstelle (Impact Rating) auf der Basis des Common Vulnerability Scoring System (CVSS), das als Methode zur formalen Wichtung des Schweregrads einer Schwachstelle verwendet wird. Das System verwendet definierte Metriken (z. B. Komplexität des Angriffs, Einfluss auf die drei Grundwerte der IT-Sicherheit etc.), über die ein Score berechnet und einer Sicherheitslücke zugeteilt wird. Die als Beispiel zur Verdeutlichung der Thematik herangezogene Sicherheitslücke hat einen CVSS Score von 4.5.

CVSS Score
Mit dem CVSS Score ist also keine Aussage zu dem mit einer Sicherheitslücke verbundenen Risiko verknüpft. Die Risikobewertung erfolgt zwar unter Einbeziehung des CVSS Scores, aber immer auch im Kontext Ihres Informationsverbunds. Durch den CVSS Score ist letztlich eine „objektive” Bewertung des Schweregrads einer Sicherheitslücke möglich.

Die Tabelle in Abbildung 4 ordnet den berechneten CVSS Score einem einfach zu verstehenden Rating zu.

Tipp!
Wer dieses zugegeben sehr trockene Thema weiter vertiefen möchte, findet die CVSSv3.0-Spezifikation auf der Seite des NIST [5]. Zudem kann der CVSS Online Calculator [6] zur Veranschaulichung der CVSS-Score-Kalkulation herangezogen werden. Wer als z. B. Lieferant von Software von seinem Kunden zur Klassifizierung des Schweregrads von Schwachstellen in der von ihm entwickelten Software aufgefordert wird, der kann diesen Kalkulator zu Rate ziehen.

Führt man das einleitende Beispiel fort und nimmt in der NVD-Datenbank die Sicherheitslücke CVE-2018-4172 unter die Lupe, so erhält man einen Steckbrief mit sehr vielen hilfreichen Informationen (s.  Abbildung 5), die zur Ableitung von kontextbezogenen Maßnahmen (der Kontext ist hier Ihr IT-Verbund) herangezogen werden können.

In Abbildung 6 ist die aktuelle Verteilung (Stand: Juli 2020) der CVSS-Schweregrade über verschiedene Hersteller und deren Produkte zu sehen.

Beispiel Microsoft
Für Microsoft wurden in 2019 insgesamt 131 kritische Sicherheitslücken (CVSS = 9 oder 10) erfasst. Dabei wird dieser Hersteller ab 1999 mit insgesamt 529 Produkten und 6.814 Sicherheitslücken geführt. Es ist an dieser Stelle anzumerken, dass mit diesem Beispiel keine Wertung des Herstellers verknüpft und die Wahl nur zufällig auf Microsoft gefallen ist. Für viele andere große Hersteller würde das Ergebnis ähnlich ausfallen. Ein konkretes Beispiel ist nur deshalb erforderlich, weil sich damit die Brisanz der Thematik besser veranschaulichen lässt.

Common Platform Enumeration
Bevor wir diesen aus Sicht von einigen Lesern sicherlich als schwere Kost zu bezeichnenden Bereich der Schwachstellenanalyse wieder verlassen und uns auf das Fazit konzentrieren, soll an dieser Stelle noch eine Lücke geschlossen werden: Wenn die IT-Assets Ihres IT-Verbunds bekannt sind, wie lassen sich dann möglichst automatisiert und zielgerichtet die für diesen IT-Verbund aktuell bestehenden Schwachstellen ermitteln? NIST definiert dafür als Bestandteil der formalen CVE-Definition auch ein für die IT-Assets formales Namensformat. Dieses wird als Common Platform Enumeration (CPE) bezeichnet. Abbildung 7 verdeutlicht das generische Namensformat. Es zeigt einen Teil der Ausgabe, wenn man die CPE-Datenbank [8] nach Apple iOS durchsucht.

Schwachstellenmanagement
Es ist an dieser Stelle völlig ausreichend, wenn Sie verstehen, dass die in Ihrem IT-Verbund existierenden Assets im Sinne einer Abstraktionsebene durch standardisierte und einheitliche Namen beschrieben werden können. Diese Abstraktionsebene (d. h. Namen) ermöglicht es, die Assets Ihres IT-Verbunds mit Informationen aus anderen Datenbanken (z. B. einer Datenbank mit Schwachstellen) anzureichern. Diese Anreicherung kann natürlich automatisiert werden, was im Rahmen eines Schwachstellenmanagements (Vulnerability Management) von den dafür eingesetzten Tools geleistet wird. Letztlich liefern Ihnen solche Tools die Informationen, die für das Erkennen und Bewerten von Risiken erforderlich sind.

Einsatz eines Vulnerability-Management-Tools
Die Abbildung 8 zeigt beispielhaft, wie durch den Einsatz eines Vulnerability-Management-Tools die in einem IT-Verbund vorhandenen Schwachstellen aufbereitet und sichtbar gemacht werden können.

In diesem konkreten Fall handelt es sich um eine sehr kleine Testumgebung (sechs Rechner), wobei für die hier überwachten Windows- und Linux-Systeme insgesamt 1.446 Schwachstellen protokolliert werden. Davon haben 530 einen CVSS-Score im Bereich 8 bis 10, wobei 17 Schwachstellen quasi von Anfängern ausgenutzt werden können, da die entsprechenden Exploits einfach zu beziehen sind. Das Tool berücksichtigt neben der Verfügbarkeit von Exploits auch z. B. das Alter einer Schwachstelle. Damit leistet das Tool einen Beitrag zur Risikoanalyse, die letztlich auf der Basis der Informationen dieses Tools erfolgen muss. D. h., es ist nicht zwingend davon auszugehen, dass eine Schwachstelle mit einem CVSS-Score von z. B. 10 in diesem als Beispiel verwendeten IT-Verbund eine höhere Priorität als eine Schwachstelle mit einem CVSS-Score von z. B. 8 hat. Bei 1.446 existierenden Schwachstellen ist eine automatisierte Hilfestellung bei deren Priorisierung absolut willkommen, da damit auch eine Priorisierung der sich anschließenden Aktivitäten (z. B. Patchen) erfolgen kann.

In der Praxis treffe ich immer wieder auf Unternehmen, Organisationen und Behörden, die aus ihrer Sicht beim Thema Prävention sehr gut aufgestellt sind. D. h., z. B. das Patch-Management ist fester Bestandteil ihrer Cyber-Hygiene. Hier ist aber mahnend anzumerken, dass ein ganzheitliches Schwachstellenmanagement nicht auf ein Patch-Management reduziert werden sollte. So enthält ein Schwachstellenmanagement z. B. eine kontinuierliche Überprüfung der IT-Assets auf mögliche Schwachstellen. Erst damit kann man den Compliance-Richtlinien gerecht werden, die eine kontinuierliche Überwachung, Risikobewertung und ggf. Aktualisierung von betroffenen Systemen und Anwendungen fordern.

Zwei-Faktor-Authentifizierung erhöht Anwenderakzeptanz
Wie bereits erwähnt, entscheidet die IT-Sicherheit nicht, welche technischen Lösungen für z. B. ein Unternehmen im Kontext seiner Unternehmensstrategie relevant sind. Vielmehr muss sie dabei unterstützen, die Sicherheit der technischen Lösungen sicherzustellen, sodass die Anwender nicht nur Vertrauen in die eingesetzten Lösungen haben, sondern auch ihre Produktivität gewährleistet bleibt. So hat z. B. eine über das Smartphone umgesetzte Zwei-Faktor-Authentifizierung (2FA) eine höhere Anwenderakzeptanz, als z. B. der monatlich erzwungene Passwortwechsel. Stellen Sie sich vor, dass Sie sich bei einer Remote-Einwahl (VPN: Virtual Private Network) zunächst mit Benutzernamen und Passwort authentifizieren müssen und danach auf Ihrem Smartphone eine Meldung erscheint, die Sie zur Bestätigung der Einwahl auffordert. Damit wird das Smartphone zum zweiten Faktor, d. h., selbst wenn einem Angreifer Ihr Benutzerpasswort bekannt ist, muss er auch noch im Besitz Ihres Smartphones sein, um Ihren Account nutzen zu können (s. Abbildung 9).

Die IT-Sicherheit bewertet aber natürlich sehr wohl, ob die zur Umsetzung der Anforderungen eingesetzten Systeme, Dienste, Protokolle und Anwendungen dem erforderlichen Schutzbedarf auch gerecht werden, und kann aus diesem Anspruch heraus durchaus auch die Einführung z. B. einer Anwendung oder eines Features verhindern.

Sichtbarkeit bedeutet mehr Kontrolle
Wenn man die Systeme eines IT-Verbunds nicht auch mit Fokus auf das Thema Sicherheit überwacht, dann ist man im Blindflug unterwegs und kann auf sicherheitsrelevante Ereignisse nicht reagieren, weder manuell noch zukünftig vielleicht auch automatisiert. Was man nicht sieht, kann man auch nicht kontrollieren. Die nachfolgenden Beispiele sollen diese Kausalität untermauern. Auch hier möchte ich wieder die technisch versierten Leser um Nachsicht bitten, denn bei den folgenden Beispielen steht die Veranschaulichung und nicht der technische Tiefgang im Vordergrund.

Shellshock Exploit durch Lücke im Betriebssystem
In Abbildung 10 ist ein System mit der IP-Adresse 172.31.1.219 zu sehen, das – was sehr gut an den Nationalflaggen zu erkennen ist – Verbindungen in die weite Welt unterhält. Bei dem System handelt es sich um einen kleinen Netzwerkspeicher (NAS), der eigentlich keinen Anlass dazu haben sollte, mit dem Internet zu kommunizieren. Er macht es, weil auf ihm der sogenannte Shellshock Exploit ausgeführt und eine Musiktauschbörse installiert wurde. D. h., der kleine Netzwerkspeicher wurde gehackt, was durch eine Sicherheitslücke im Betriebssystem und aufgrund einer fahrlässigen Konfiguration seines Besitzers überhaupt erst möglich wurde.

Sicherheitslücke Netzwerkspeicher
Nehmen wir einfach mal an, dass Sie stolzer Besitzer eines privaten kleinen Netzwerkspeichers sind. Können Sie sicher sein, dass Sie diesen optimal gegen Angriffe geschützt haben und dieses Gerät in der Vergangenheit nicht ebenfalls schon erfolgreich angegriffen wurde? Sie erkennen sicherlich die Rhetorik dieser Frage. Selbst einige Unternehmen könnten diese mit Blick auf ihre IT-Systeme nicht qualifiziert beantworten.

Die Abbildung 11 zeigt eine interessante Auffälligkeit: Über das Netzwerk wurde innerhalb von zwei Tagen – was in diesem Unternehmen durchaus als nicht normal zu bezeichnen ist – ein Mailvolumen von 19,2 GB transferiert. Wenn man die Verursacher etwas genauer unter die Lupe nimmt, dann handelt es sich hier um einen Mailserver und um einen Webserver, der aus dem Internet erreichbar und gehackt worden ist. Nun versorgt er die ganze Welt mit Spammails.

Prävention erst der Anfang
Es ist sicherlich einleuchtend, dass eine hundertprozentige Sicherheit nicht existiert. Damit ist eine Sicherheitskonzeption, die sich ausschließlich auf Prävention stützt, nur eine Illusion von Sicherheit. Durch plakative Aussagen zu Cyberangriffen wie z. B. „Die Frage ist nicht ob, sondern wann!” oder „If targeted, you will be compromised” wird implizit die Notwendigkeit einer stärkeren Ausprägung von Erkennung, Analyse und resultierenden Maßnahmen angemahnt. Das bedeutet aber nicht, dass man aufgrund der verfehlten Zielerreichung (es gibt keine hundertprozentige Sicherheit) der Prävention nur noch wenig bzw. keine Aufmerksamkeit schenken muss. Wer seine präventiven Maßnahmen vernachlässigt, der gewährt auch amateurhaft agierenden Angreifern Einlass.

Den Überblick behalten
Die unterschiedlichen Sicherheitssysteme generieren – in unterschiedlichster Qualität und Ausprägung – Informationen und Alarme. Letztlich kann so eine wahre Flut an Informationen entstehen, die auch schnell der eigentlich angestrebten Sichtbarkeit entgegenwirken kann. D. h., letztlich müssen die gesammelten Daten korreliert, gefiltert und interpretiert werden. Dabei kann ein einzelnes Security Event oder auch eine bestimmte Verkettung von Security Events interessant sein. Hier kann Ihnen z. B. Security Information and Event Management (SIEM) helfen den Überblick zu bewahren und die Spreu vom Weizen zu trennen. Im Englischen lässt sich das etwas eleganter beschreiben: Find the Signal in the Noise.

Blick auf den Prozess
Die SIEM-Lösungen am Markt bieten oft auch eine prozessbezogene Sicht. D. h., wer durch diese Brille schaut, den interessiert nicht das technische Security Event, sondern dessen Auswirkung auf einen (geschäfts)relevanten Prozess.

Kontinuierliche Prüfung
Das Ziel eines Information Security Management System ist die Herstellung, die Aufrechterhaltung und die Kontrolle der Informationssicherheit, d. h., die Kontrollmechanismen und die sich daraus ableitenden Aktionen sorgen dafür, dass die Sicherstellung der Informationssicherheit ein fortlaufender Prozess bleibt (auch als z. B. Demingkreis oder PDCA-Zyklus bezeichnet). Dabei muss die Informationssicherheit auf der technischen Ebene (z. B. Penetrationstests), auf der Prozessebene (z. B. Dokumentationen) und der Awareness-Ebene (z. B. Awareness-Kampagnen) kontinuierlich geprüft werden.

Blind Spots finden
Einen sehr hohen Reifegrad hat das Thema Test sicherlich dann erreicht, wenn die eigene Cyber Security durch „Red Teams” auf der Basis von realen Angriffen (d. h. Angriffe, die sich an der Branche eines Unternehmens und den Taktiken, Techniken und Prozessen [TTP] ausrichten) und verteidigenden „Blue Teams” auf den Prüfstand gestellt wird. Während man auf der Basis der konzeptionellen Sicherheit die „White Spots” der eigenen Cyber-Security-Strategie aufdecken kann, können durch den Einsatz von Red/Blue Teams mögliche „Blind Spots” gefunden werden. Sollte Ihnen in diesem Zusammenhang der Satz „Wir spielen Krieg” in den Sinn kommen, dann ist dieser Vergleich nicht von der Hand zu weisen, denn letztlich hat die Bezeichnung der Teams ihre Wurzeln im militärischen Umfeld.

Reporting ist Teamwork
Nur gemeinsam sind wir stark. Diese Devise gilt auch im Kampf gegen die Angriffe auf unsere vernetzten IT-Systeme. So sind z. B. die Bundesbehörden dazu verpflichtet, das BSI über die versuchten oder erfolgten Angriffe sofort zu informieren, die für die Abwehr von IT-Sicherheitsgefahren – insbesondere auch bei anderen Behörden – relevant sind. Natürlich ermöglicht dieses Reporting eine konsolidierte Langzeitanalyse der IT-Sicherheitslage und natürlich lässt sich damit auch die Wirtschaftlichkeit der getroffenen Schutzmaßnahmen überprüfen. Letztlich ist das Reporting aber auch als eine Grundstufe der Zusammenarbeit zu verstehen: Der erkannte Angriff auf eine Bundesbehörde ermöglicht letztlich einen Schutz der anderen Bundesbehörden.

Cyber-AZ
Seit Juni 2019 existiert das Nationale Cyber-Abwehrzentrum (Cyber-AZ), eine zentrale Informations-, Kooperations- und Koordinationsplattform für Behörden. Die Aufgabe dieser Kooperationsplattform wird auf der Seite des BSI wie folgt beschrieben:

KRITIS-Meldepflicht
Mit dem Inkrafttreten des IT-Sicherheitsgesetzes im Juni 2015 wurde auch die Meldepflicht für die Betreiber von sogenannten kritischen Infrastrukturen (KRITIS) in den nachfolgenden Sektoren festgelegt:

UP KRITIS
Der UP KRITIS ist eine öffentlich-private Kooperation zwischen den Betreibern von solchen kritischen Infrastrukturen (Ausnahme: Staat und Verwaltung), deren Verbänden und den zuständigen staatlichen Stellen. UP KRITIS verfolgt dabei die folgenden Ziele:

Austausch und Analyse
Zum Beispiel der Verein Cyber Security Sharing & Analytics [9] wurde mit der Motivation gegründet, sich gemeinsam besser gegen Cyberangriffe und Bedrohungen zu schützen. Wie der Name schon vermuten lässt, geht es hier nicht nur um den Austausch von Informationen zu Angriffen, sondern auch um die Analyse dieser Angriffe. Erstgenanntes ist durchaus als sensibel zu bezeichnen, während die Analyse auch eine Zusammenarbeit auf dieser Ebene erforderlich macht.

Wer jetzt noch einen Nachschlag benötigt, dem sei der Besuch der Webseite der Allianz für Cyber-Sicherheit empfohlen [10].

Zusammenarbeit auf technischer Ebene
Letztlich kann das Thema Zusammenarbeit auch auf der technischen Ebene verdeutlicht werden. So ist es heute über sogenannte STIX/TAXII-Feeds möglich, dass z. B. eine Firewall des Herstellers X die zum Erkennen von Angriffen erforderlichen Informationen (im einfachsten Fall eine auffällige IP-Adresse) von Drittanbietern beziehen kann. Im Internet haben sich bereits mehrere Plattformen etabliert (z. B. [11] oder [12]), die gegen Einwurf kleiner Münzen die Feeds unterschiedlicher Quellen anbieten. Um hier den Aspekt der Zusammenarbeit auf den Punkt zu bringen: Eine Firewall von z. B. Checkpoint kann einen Angriff auf der Basis eines Musters erkennen, dass letztlich z. B. der Hersteller AlienVault bereitgestellt hat.

Der Domain Name Service (DNS) ist für die Namensauflösung zuständig. D. h., über ihn kann die zu einem Namen zugehörige IP-Adresse ermittelt werden. Das passiert meist unbemerkt im Hintergrund (z. B. wenn Sie in Ihrem Webbrowser die Webseite von Google aufrufen), ist aber dennoch extrem wichtig, da wir uns ohne diesen Dienst nicht so einfach im Internet (und auch nicht in unseren eigenen Netzen) „bewegen” könnten.

nslookup
Wer den DNS-Service manuell testen möchte, der kann dies z. B. mit dem Programm „nslookup” über die Eingabeaufforderung seines Windows-Betriebssystems tun (s. Abbildung 15).

Wie schützen DNS-Dienste?
Was hat das aber nun mit dem Thema Sicherheit zu tun? DNS als zentraler Dienst (Network Core Service) ist in der Regel jeder Kommunikationsbeziehung vorangestellt. Wenn ein DNS-Dienst nicht nur für die Auflösung eines Namens in eine IP-Adresse zuständig ist, sondern eine Datenbank mit „auffällig” gewordenen Namen und IP-Adressen führt, dann kann er die Namensauflösungen steuern und die Anwender vor der Kommunikation mit solchen Zielen schützen. D. h., Sie rufen über Ihren Webbrowser z. B. die Seite „www.britishairways-com.win” auf, der DNS-Dienst prüft den Namen mithilfe einer von ihm verwalteten Security-Intelligence-Datenbank und stellt fest, dass Sie diese Seite besser nicht aufrufen sollten (der Dienst hat Recht, deshalb nehmen Sie bitte Abstand davon). In diesem Fall verweigert Ihnen der DNS-Dienst die Antwort oder liefert eine IP-Adresse aus, die auf eine Webseite mit einer Warnmeldung führt. In beiden Fällen wird der „normale” Anwender davor geschützt, mit dieser Webseite zu kommunizieren.

Auch schädliche Software nutzt für u. a. Phone-Home-Aktivitäten (in Anlehnung an E.T.: Nach Hause telefonieren) den DNS-Dienst. D. h., über den DNS-Dienst kann die Namensauflösung verhindert und zudem auch ein Hinweis generiert werden, dass sich auf dem Rechner, von dem diese Anfragen ausgehen, eventuell Malware befindet.

An den DNS-Dienst werden täglich sehr viele Anfragen nach Namensauflösung (sogenannte DNS Requests) geschickt. Dadurch kann dieser Dienst – insbesondere dann, wenn er um die Funktion Sicherheit angereichert wird – sehr viele Informationen liefern (das Thema Sichtbarkeit). Die Abbildungen 16, 17 und 18 verdeutlichen diese Aussage.

In Abbildung 16 wird die Zahl der DNS-Anfragen bezogen auf die Zeit angezeigt, wobei die Anfragen klassifiziert werden. Die Klassifizierung „Security Prevent” z. B. bedeutet, dass die Anfrage geblockt wurde, da das Ziel z. B. der Kategorie Malware zugehörig ist (s. Abbildung 17). Dagegen wird mit der Klassifizierung „Categories” die Namensauflösung von Webseiten klassifiziert, die gegen die Unternehmensrichtlinien verstoßen. Dazu zählt z. B. die Unterbindung des Aufrufs von Seiten mit pornografischen Inhalten (s. Abbildung 18).

Anwendung von IP-Adressen
Letztlich basiert jede netzwerkgestützte Kommunikation auf IP-Adressen, und nicht immer ist dieser Kommunikation eine Namensauflösung vorangestellt. Deshalb kann eine Threat-Intelligence-Datenbank z. B. auch zur Klassifizierung von IP-Adressen verwendet werden. In den beiden folgenden Bildern sind zwei Anwendungsbeispiele zu sehen.

Abbildung 19 entstammt einer Next-Generation-Firewall. Es zeigt Verbindungen (jede Zeile entspricht einer Verbindung), die auf der Basis der Reputation der Ziel-IP-Adresse geblockt wurden. In Abbildung 20 sind Verbindungen zu einem Mail Gateway zu sehen, die auf der Basis der Reputation der Quellen-IP-Adresse geblockt wurden. D. h., das entsprechende System wurde daran gehindert, Post einzuwerfen.

Virenscanner als Basis
Sicherlich ist Ihnen das Thema Malware (schädliche Software) im Zusammenhang mit dem Virenscanner ein Begriff und (hoffentlich) z. B. auf Ihrem Desktop Rechner zu finden. Solche Systeme arbeiten üblicherweise mit sogenannten Signaturen, über die basierend auf diesen Mustern z. B. schädliche Programme erkannt werden. Diese Systeme haben heute weiterhin ihre Daseinsberechtigung, werden aber durch Threat Intelligence erweitert bzw. ergänzt. Dazu wird – sobald ein File bewegt wird (z. B. durch Kopieren) – in einer Datenbank der Fingerabdruck (SHA256-Hashwert) dieses Files abgefragt.

Hashwertevergleich
Bevor das Verständnis schon direkt an Begriffen scheitert, soll die Abbildung 21 verdeutlichen, was Sie sich unter einem Hashwert (Fingerabdruck) vorstellen können. In der einen Bildhälfte sind die Hashwerte (es gibt verschiedene Hashfunktionen) für den Ausruf „Hello World” zu sehen, während in der anderen Hälfte das Ergebnis für „hello World” zeigt. Daraus lassen sich die folgenden Erkenntnisse gewinnen:

Hashwert bei Datentransfer
Kehren wir zu unserem eigentlichen Thema zurück. Soll z. B. über eine Firewall ein File transferiert werden, so ermittelt sie quasi on the fly dessen Hashwert und schickt diesen zur Threat-Intelligence-Datenbank. Dort wird geprüft, ob der Hashwert (und damit indirekt auch das File) bekannt ist. Ist der Wert bekannt, dann bekommt die Firewall die Information, ob das zugehörige File als schädlich klassifiziert ist.

Sie können dieses Verfahren mithilfe von über das Internet kostenfrei zur Verfügung gestellten Diensten testen. Zunächst benötigen Sie eine Webseite, die Ihnen die Onlineberechnung des SHA256-Werts anbietet (z. B. [19]). Ich nehme allerdings Abstand davon, Sie hier zu einem Upload von vertraulichen Dokumenten animiert zu haben. Mit dem gewonnenen Hashwert besuchen Sie z. B. die Seite von Virus Total [20] oder Cisco Talos [21] und fragen dort die Reputation des Hashwerts ab. Ist der Hashwert dort bekannt, dann kann das Ergebnis wie in Abbildung 22 dargestellt aussehen.

Es ist an dieser Stelle anzumerken, dass Sie sich bei Virus Total den Umweg über den Hashwert sparen können: Dort wird Ihnen auch die Möglichkeit eines File Uploads angeboten.

Malware erkennen
Die Abbildung 23 ist dem Logbuch einer Firewall entnommen. Sie zeigt, dass ein Anwender daran gehindert wurde, über einen Download ein File zu beziehen, das als W32.Trojan.Agent klassifiziert wurde. Allerdings musste die Firewall das File dafür nicht über z. B. einen Virenscanner analysieren. Vielmehr hat sie nur dessen SHA256-Wert an die Threat-Intelligence-Cloud übergeben und wurde von dieser in Echtzeit darüber informiert, dass es sich bei diesem File um eine bekannte Malware handelt.

Ein weiterer Bestandteil einer Threat-Intelligence-Lösung kann eine sogenannte Sandbox sein. Vielleicht erinnern Sie sich noch daran, dass wir Sabine (d. h. natürlich ihre Bewerbungsunterlagen) in die Sandbox zur Analyse geschickt hatten (s. Kap. 08A08, Abschnitt 1.5.3)? Aus didaktischen Gründen wurde dieser manuelle Ansatz gewählt. In der Praxis bedingt so ein manueller Ansatz einen etablierten Prozess und entsprechende Ressourcen. Dieser Bedarf kann entfallen, wenn Systeme wie z. B. ein Web Proxy oder eine Firewall die zu transferierenden Files automatisch an die Sandbox übergeben.

Sandbox
Wenn wir die Flughöhe von 10.000 km auch an dieser Stelle nicht verlassen wollen, dann ist eine Sandbox wie folgt zu beschreiben: Die vermeintlich schädliche Software wird außerhalb des Systems des Anwenders in einer eigenen Umgebung ausgeführt. Diese Umgebung erlaubt es der Software, sich frei zu entfalten. D. h., sie kann z. B. Änderungen auf ihrem Wirtsystem ausführen und kann ungefiltert mit Systemen im Internet kommunizieren. Allerdings werden alle ihre Aktivitäten aufgezeichnet und mit den in einer Datenbank abgelegten Verhaltensmustern verglichen. So ist es möglich, eine Software auf der Basis einer Mehrheitsentscheidung als gefährlich einzustufen (z. B. wenn 90 % der Indikatoren als verdächtiges Verhalten erkannt werden). Diese Entscheidung wird in Abbildung 24 verdeutlicht.

Analyse des Paketstroms
Ein Intrusion Prevention System (IPS) analysiert den Paketstrom z. B. auf Fehler in den Paketen, auf Bitmuster in den Paketen oder auf die erwartete Sequenz der Pakete. Die Überprüfung erfolgt auf der Basis von IPS-Signaturen. Eine sehr bekannte Open-Source-IPS-Lösung ist Snort [23], das auch eine eigene Syntax zur Erstellung von Signaturen (Snort Rules) definiert. Wenn eine solche Signatur greift, dann kann das System die entsprechende Kommunikation stoppen oder zumindest einen Alarm generieren. Abbildung 25 zeigt die auf der Basis der Snort-Signatur 1:000001:1 ausgelösten Alarmierungen.

Die für die Alarme verantwortliche Signatur ist ebenfalls in der Abbildung zu sehen. Es handelt sich um eine unsinnige Signatur, die einen Alarm generiert, sobald ausgehend von der IP-Adresse 172.31.1.146 eine TCP-Verbindung aufgebaut wird. Diese Signatur wurde von mir erstellt und disqualifiziert mich für den Status eines Snort-Experten. Glücklicherweise gibt es auch intelligentere IPS-Signaturen. Aktuell existieren z. B. mehr als 45.000 offizielle Snort-Signaturen.

HTTPS = Verschlüsselt
Im Vergleich zu HTTP gibt es bei HTTPS aber einen nicht ganz unwichtigen Unterschied beim Transferieren der Daten: Bei HTTPS werden die Daten verschlüsselt übertragen und sind damit – auch für eine Firewall – nicht lesbar. Die Abbildung 26 zeigt grob, wie Sie sich den Aufbau einer solchen verschlüsselten Verbindung vorstellen müssen. Der Client fordert beim Server eine Verbindung an. Beide verhandeln über diese Verbindung zunächst die kryptografischen Algorithmen und das Schlüsselmaterial, bevor dann die weitere Kommunikation für die Augen von Dritten verschleiert wird.

Das Problem liegt nun natürlich auf der Hand: Die Firewall kann keine Anwendungen erkennen und wird damit wieder rein auf eine Kontrolle der Kommunikationsbeziehungen reduziert. Um dem Veto der technisch versierten Leser gleich vorzubeugen: Ja, ein paar Anwendungen können auch erkannt werden, obwohl die eigentlichen Daten der Anwendung verschlüsselt übertragen werden. Die Diskussion der entsprechenden Abhängigkeiten sowie die dafür relevanten Informationen, die während der unverschlüsselten Phase der Kommunikation (s. Abbildung 26), oder über das Zertifikat des Servers ausgetauscht werden, dürften aber die meisten Leser langweilen. Dafür hätte ich sogar vollstes Verständnis.

Der sich aufgrund der Zunahme von HTTPS einstellende Blindflug hat ernstzunehmende Konsequenzen, da – wie in Abbildung 27 zu sehen – potenzielle Sicherheitslücken entstehen.

Die zwischen Quelle (z. B. Webserver) und Ziel (z. B. Desktop) verschlüsselten Verbindungen können mithilfe der dazwischenliegenden Systeme (z. B. Firewall oder Proxy) nicht analysiert werden, und die benötigte Sichtbarkeit kann nicht hergestellt werden. D. h., z. B. Malware kann ungehindert zum Desktop vordringen, und vertrauliche Daten können ungefiltert ins Internet abfließen.

Es ist allerdings technisch möglich, dass Security-Instanzen wie z. B. Firewall oder Proxy die verschlüsselten Verbindungen aufbrechen und somit die Sichtbarkeit und Kontrolle wiederherstellen können. Es gibt aber auch Fälle, bei denen das aus technischen bzw. auch aus organisatorischen Gründen nicht möglich bzw. nicht gewünscht ist.

Ressourcenintensive Lösungen
Es gibt mittlerweile technische Lösungen, die auf der Basis von z. B. Mustern im Datenfluss (IP-Pakete) oder der Art und Weise, wie eine verschlüsselte Verbindung aufgebaut wurde (Zertifikate, kryptografische Verfahren ...), versuchen zu erkennen, ob die verschlüsselte Verbindung suspekt ist und ob darüber ein Angriff durch z. B. schädliche Software eingeleitet wird. Diese Lösungen binden das Netzwerk in die Analyse mit ein, da die Daten zwischen Quelle und Ziel natürlich immer über Netzwerke transferiert werden. Allerdings sind diese Lösungsansätze sehr ressourcenintensiv, sodass dafür neue Netzwerkkomponenten zum Einsatz kommen müssen.