-- WEBONDISK OK --

08A09 Advanced Persistent Threats – Prävention, Detektion und Reaktion

In diesem Beitrag werden (technische) Maßnahmen vorgestellt, die letztlich das Ergebnis einer konzeptionell gesteuerten Sicherheitsstrategie sein können. Dabei stehen die Fähigkeiten Prävention, Detektion und Reaktion im Vordergrund, die im Zeitalter der Digitalisierung die Grundlage einer breitgefächerten Cyber-Security-Abwehr bilden. Es werden aber wie schon in den vorangegangenen Beiträgen nicht die technischen Details in den Vordergrund gestellt. Vielmehr werden die Lösungen und deren Ziele so vermittelt, dass das Thema für ein breites Leserpublikum verständlich und nachvollziehbar bleibt.
von:

1 Security: Umsetzung

Konkret und strukturiert arbeiten
In diesem Abschnitt werden Sicherheitsmaßnahmen vorgestellt, die nicht als konkrete technische Maßnahme, wie z. B. der Einsatz eines Virenscanners oder einer Next-Generation-Firewall, zu verstehen sind. Es sind vielmehr Konzepte und Maßnahmen, deren Notwendigkeit sich daraus ableitet, dass das Thema Sicherheit heute konzeptionell zu betrachten und zu betreiben ist. D. h., sie sind in einer Sicherheitsstrategie verwurzelt, die immer den konkreten Maßnahmen vorangestellt sein muss. Dieser Angang ist wichtig, da auch die Angreifer oft sehr strukturiert und professionell arbeiten (s. Phasen eines Angriffs, Kap. 08A08). Zudem stellt ein solcher Angang sicher, dass alle relevanten Bereiche betrachtet und somit dafür auch entsprechende Schutzmaßnahmen definiert werden können.

1.1 Schichtenmodell

Sicherheit in Schichten
Die Zeiten, in denen sich das Thema IT-Sicherheit über die Firewall am Perimeter Ihres Netzes (d. h. an der Grenze zum Internet oder an der Grenze zu anderen Netzen) definierte, sind schon lange vorbei. Zwischenzeitlich haben die Hersteller das Bild einer Zwiebel verwendet, um uns zu erklären, dass Sicherheit in Schichten aufgebaut werden muss. Letztlich meinten sie damit aber zunächst nur eine „Reihenschaltung” von Sicherheitsprodukten, ausgehend vom Perimeter über das Netzwerk hin zum Desktop – die ideale Handreichung zur Orchestrierung ihres Sicherheitsportfolios.
Defense-in-Depth
Sie können gerne weiterhin das Bild einer Zwiebel im Kopf behalten, wenn im nachfolgenden Textverlauf ein Schichtenmodell vorgestellt wird, dessen Schichten nicht einfach nur Produkte referenzieren, sondern das zur Implementierung einer modernen Defense-in-Depth (DiD)-Strategie herangezogen werden kann.
Tabelle 1: Mögliche Komponenten einer Defense-in-Depth-Strategie.
1
Prävention
 
Festlegung des Soll-Zustands
Umsetzen von aus der Sicherheitskonzeption abgeleiteten (technischen) Maßnahmen (z. B. Virenscanner, Firewalls etc.)
Schwachstellenmanagement
Härten von Systemen (z. B. nicht benötigte Dienste abschalten)
Patchen von Systemen
Risikobewertung
...
2
Sicherstellung von Produktivität und Arbeitsfähigkeit
 
Absichern der von den Endanwendern benötigten Systeme und Anwendungen (z. B. Virenscanner für Rechner, MDM-Lösungen für mobile Endgeräte ...)
Usability und Anforderungen an die IT-Sicherheit müssen im Einklang stehen.
Die Gewährleistung eines Sicherheitsniveaus bedingt nicht per Definition, dass Anforderungen und Innovationen in diesem Bereich abgelehnt werden müssen (s. z. B. Einsatz von mobilen Endgeräten).
Awareness und Akzeptanz für das Thema Sicherheit schaffen und die vor diesem Kontext erforderlichen Maßnahmen motivieren.
...
3
Herstellen einer „Sichtbarkeit”
 
Ist-Zustand: Was passiert in der eigenen IT-Umgebung?
Schwachstellenmanagement: Aufzeigen von bekannten und im eigenen Systemverbund existierenden Schwachstellen
Welche Kommunikationsbeziehungen: Wer kommuniziert mit wem?
Welche Geräte sind im Netz, welche Anwendungen werden verwendet und welche Dienste werden konsumiert?
Sammeln von sicherheitsrelevanten Events (z. B. die Events einer Firewall, einer Desktop-Security-Lösung)
...
4
Erkennen, Analysieren und Reagieren
 
Erfassen und korrelieren von sicherheitsrelevanten Ereignissen (Events) durch z. B. eine Security-Incident-Event-Management(SIEM)-Lösung
Erkennen, Analysieren und Reagieren (Threat Intelligence, Analytics, ML, AI)
Alarmierung
Sicherheitsbetrieb (SOC: Security Operations Center)
...
5
Tests
 
Penetrationstests
Trendanalysen auswerten
Awareness-Kampagnen, Social Engineering
Red Team (Angriff)
Purple Team (Verteidigung)
...
6
Austausch von Informationen
 
Kontinuierliche Zusammenarbeit von Unternehmen vor dem Kontext der Cyber Security
Austausch von Informationen z. B. zu aktuellen Alarmierungen und Angriffen
Unterstützung beim Betrieb der Sicherheit
Austausch von Threat Intelligence
...
Der Autor bittet zu entschuldigen, dass nachfolgend nicht alle in Tabelle 1 aufgeführten Begriffe erklärt werden. Letztlich soll die Tabelle lediglich zeigen, dass Sicherheit sich nicht nur über eine einzelne Maßnahme und auch nicht ausschließlich über das Thema Prävention definiert. Wer die Tabelle durch eine technische Brille bewertet, den bitte ich um Nachsicht, wenn durch diese Brille die Trennung einiger Themen etwas unscharf geraten zu sein scheint.
Prävention, Detektion, Reaktion
Das Thema Informationssicherheit muss im Zeitalter der Digitalisierung primär durch Prävention, Detektion und Reaktion adressiert werden. Warum? Weil Sie Angriffe abwehren müssen (Prävention), Ihnen das aber leider nicht dauerhaft zu 100 % gelingen wird und Sie sich fragen müssen, wie Sie die Zeit bis zur Aufdeckung eines erfolgreichen Angriffs verkürzen (Detektion) und zu diesem Zeitpunkt dann reagieren können (Reaktion).
Nachfolgend werden die in der vorangegangenen Tabelle aufgeführten Grundbausteine einer möglichen Defense-in-Depth-Strategie vorgestellt. Dabei steht wieder die in diesem Beitrag angestrebte Verständlichkeit und nicht das technische Detail im Vordergrund.
Kurz notiert
Am Ende werden die oben aufgeführten Bereiche natürlich durch Lösungen und Produkte besetzt. Das Modell selbst referenziert aber keine Produkte, sondern zeigt lediglich, welche Themen Sie im Rahmen Ihrer Sicherheitsaktivitäten berücksichtigen sollten.

1.1.1 Prävention

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.
Kurz notiert
Wie viele IT-Assets (Anwendungen, Betriebssysteme, Hardware ...) umfasst Ihr IT-Verbund? Wer seine IT-Services gemäß ITIL orchestriert, der könnte diese Frage nach einem kurzen Blick in seine Configuration Management Database (CMDB) wohl sehr verbindlich beantworten. Wer aber seine Assets nicht kennt, der scheitert beim Thema Sicherheit schon in einem sehr frühen Stadium: Wie kann man etwas schützen, das man nicht kennt bzw. von dessen Existenz man nichts weiß?
Unabhängig davon, wie belastbar Ihre Antwort auf die zuvor gestellte Frage ausfällt, kann sie sicherlich wie folgt verallgemeinert werden: Es sind sehr viele IT-Assets. Natürlich haben nicht alle diese Systeme den gleichen Schutzbedarf, aber dennoch ist der Schutzbedarf festzustellen und dauerhaft zu gewährleisten. D. h., Sie müssen u. a. wissen, ob Ihre Systeme Schwachstellen (Vulnerabilities) aufweisen, und entsprechend dem jeweiligen Schutzbedarf das sich daraus ableitende Risiko bewerten. Daraus leiten sich dann die zu treffenden Maßnahmen ab. Diesem Gedanken und dem weiteren Verlauf dieses Beitrags folgend, werden Sie sehr schnell feststellen, dass Sie diesem Anspruch heute kaum noch gerecht werden können und auf eine Automatisierung dieser Aufgabe angewiesen sind.
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.
Abb. 1: Common Vulnerabilities and Exposures (CVE)
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).
Abb. 2: CVE-Beschreibung (Ausschnitt)
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).
Abb. 3: National Vulnerability Database (NVD)
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.
Abb. 4: CVSS Rating und CVSS Score [4]
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.
Abb. 5: CVE-Steckbrief
In Abbildung 6 ist die aktuelle Verteilung (Stand: Juli 2020) der CVSS-Schweregrade über verschiedene Hersteller und deren Produkte zu sehen.
Abb. 6: Aktuelle Verteilung der CVSS Scores (Juli 2020) [7]
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.
Abb. 7: Common Platform Enumeration (CPE)
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.
Abb. 8: Visualisierung von Schwachstellen
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.
Kurz notiert
Im Gegensatz zu einem Penetrationstest nutzt ein Vulnerability-Management-Tool die gefundenen Schwachstellen nicht aktiv aus. Es überprüft lediglich, welche der in seiner Datenbank geführten Schwachstellen in einem IT-Verbund existieren. Das Ergebnis zeigt letztlich das durch die Systeme des IT-Verbunds gegebene Risiko.
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.
Zwischenfazit
Das Thema Patch-Management ist leider zu einem zweischneidigen Schwert geworden. Das Einspielen eines Patch ist im Sinne einer präventiven Maßnahme natürlich absolut erforderlich. Solange aber die Hersteller im Rahmen ihrer Qualitätssicherung nicht verbindlich sicherstellen können, dass ein Patch z. B. auch wirklich die Sicherheitslücke schließt oder ohne Nebenwirkungen (Betriebsrisiko) eingespielt werden kann, darf ein Patch nicht in jeder produktiven Umgebung ohne vorangestellte Tests verwendet werden. An dieser Stelle wird die Notwendigkeit, einen Patch im Sinne der Beseitigung bzw. Minimierung des Risikos schnell einspielen zu müssen, ausgebremst. Das soll die Notwendigkeit eines z. B. Dreiklangs aus Test, Produktionsspiegel und Produktion nicht infrage stellen, aber wenn ein Patch zum Schließen einer sehr kritischen Sicherheitslücke sich erst z. B. im Produktionsspiegel bewähren muss, dann kann das mit Blick auf den Schutzbedarf der Produktion fatale Folgen haben, denn damit verschiebt sich der Zeitpunkt, zu dem der Patch auch in der Produktionsumgebung eingespielt werden kann.
Viele Administratoren sind aufgrund der steigenden Zahl an Sicherheitslücken und einer oft hohen Zahl an unterschiedlichen Geräten, die von dieser Lücke betroffen sind, mit dem Patchen als zusätzlicher Aufgabe zum Tagesgeschäft überfordert. Wenn zudem der risikolose Einsatz eines Patch in der jeweiligen Umgebung vor der Installation noch überprüft werden muss, dann führt das mit Blick auf zeitliche und fachliche Ressourcen zu einer gewaltigen Herausforderung. Hier ist deshalb eine (Teil-)Automatisierung erforderlich, die aber ohne entsprechendes Budget und Know-how nicht umgesetzt werden kann. Zudem existieren zwar die technischen Standards und Tools für eine solche Teilautomatisierung, aber mit Blick auf z. B. das IoT-Thema werden diese untergraben. So werden Sie viele IoT-Assets z. B. nicht in der CPE-Datenbank finden, bzw. werden deren Hersteller keinen Prozess zur Publizierung von Schwachstellen definiert haben. D. h., diese Assets entziehen sich z. B. dem standardisierten Namensformat. Dabei ist das NIST selbst für z. B. die Hersteller nicht die Hürde: Seit 2009 kann man beim NIST CPE Namensvorschläge einreichen.

1.1.2 Produktivität und Arbeitsfähigkeit sicherstellen

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).
Abb. 9: Zwei-Faktor-Authentifizierung
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.

1.1.3 Herstellen einer „Sichtbarkeit”

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.
Abb. 10: Der Netzwerkspeicher telefoniert nach Hause.
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.
Kurz notiert
Bei der Installation und Konfiguration von IT-Systemen kann es u. a. aufgrund von fehlenden Richtlinien oder Vorgaben immer wieder zu vermeidbaren Fehlern kommen. Es ist deshalb wichtig, dass solche Vorgaben und Richtlinien existieren. So können z. B. Härtungskonzepte dafür sorgen, dass IT-Systeme vor dem Kontext der Absicherung immer mit gleicher Qualität installiert und konfiguriert werden. So ein Konzept könnte z. B. auch festlegen, dass nicht verwendete Dienste deaktiviert und administrative Zugriffe eingeschränkt und protokolliert werden müssen.
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.
Abb. 11: Der Webserver wird zum Spammer Kurz notiert
Was ist normal und was ist nicht normal? Wer das Verhalten seiner IT-Systeme nicht kennt und überwacht, der wird diese Frage nicht beantworten können. Das Erkennen von Verhaltensanomalien ist heute aber ein wichtiger Bestandteil der IT-Sicherheit. In der Regel werden die Verhaltensmuster mithilfe einer reichlich mit Daten gefüllten Datenbank und entsprechender analytischer Intelligenz (Threat Intelligence) bewertet.

1.1.4 Erkennen, analysieren und reagieren

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.
Anmerkung
Es ist leider oft zu beobachten, dass die Antriebsfedern für den Einsatz einer SIEM-Lösung primär die Notwendigkeit zur Erfüllung von Compliance-Anforderungen (z. B. PCI-DSS) sowie der Erwerb und die Aufrechterhaltung von Zertifizierungen (z. B. ISO/IEC 27001) sind. Diese Motivation wird, wenn es nur um die reine Existenz einer solchen Lösung geht, von mir als Checklisten-Security bezeichnet. Leider wird dabei vergessen, dass das SIEM-Produkt nur ein Tool in einem Werkzeugkasten ist, der zum Betrieb der Sicherheit erforderlich ist und dessen bestimmungsgemäßer Betrieb zudem auch noch klar definierte Prozesse und Menschen benötigt.

1.1.5 Tests

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.

1.1.6 Austausch von Informationen

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:
Ziel der Cyber-AZ
„Das Cyber-AZ soll die operative Zusammenarbeit optimieren und Schutz- und Abwehrmaßnahmen koordinieren. Dies geschieht auf Basis eines ganzheitlichen Ansatzes, der die verschiedenen Gefährdungen im Cyberraum zusammenführt: Cyber-Spionage, Cyber-Ausspähung, Cyber-Terrorismus und Cyber-Crime. Das Ziel: Schneller Informationsaustausch, schnelle Bewertungen und daraus abgeleitete konkrete Handlungsempfehlungen.”
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:
Energie
Gesundheit
Staat und Verwaltung
Ernährung
Transport und Verkehr
Finanz- und Versicherungswesen
Informationstechnik und Telekommunikation
Medien und Kultur
Wasser
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:
Förderung der Robustheit von IKT-Komponenten in kritischen Prozessen
Austausch über aktuelle Vorkommnisse
Gemeinsame Einschätzung und Bewertung der Cyber-Sicherheitslage
Erarbeitung gemeinsamer Dokumente und Positionen
Auf- und Ausbau von Krisenmanagementstrukturen
Koordinierte Krisenreaktion und -bewältigung
Durchführung von Notfall- und Krisenübungen
Gemeinsames Handeln gegenüber Dritten
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.
Anmerkung
CSSA ist ein sehr exklusiver Verein mit hohen Anforderungen an seine Mitglieder. Auf der Webseite ist u. a. die folgende Information zu finden: CSSA ist für europäische, weltweit tätige Wirtschaftsunternehmen zugänglich, die über Inhouse Cyber-Security-Ressourcen verfügen und sowohl die Bereitschaft als auch die Fähigkeit besitzen, relevante Informationen über Cyber-Angriffe und -Bedrohungen unter Gleichgesinnten zu teilen. Es bleibt also zu hoffen, dass sich zukünftig solche Vereine und Gremien z. B. branchenspezifisch bilden.
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.

1.2 Sicherheit betreiben

Cyber-Security-Reifegrad
Im Rahmen einer Cyber-Security-Strategie müssen die bereits vorgestellten Fähigkeiten Prävention, Detektion und Reaktion ausgebildet werden. Man kann hier durchaus von einem Reifegrad sprechen. Dieser lässt sich über ein Spinnendiagramm unter Abbildung der z. B. vom National Institute of Standards and Technology (NIST) – einer Bundesbehörde der Vereinigten Staaten – im Rahmen ihres Cyber Security Framework [13] definierten Funktionen (Identify, Protect, Detect, Respond und Recover) visualisieren (s. Abbildung 12). Dabei entspricht eine 0 dem niedrigsten und eine 5 dem höchsten Reifegrad.
Abb. 12: Der Cyber-Security-Reifegrad
NIST Framework
Das NIST Cyber Security Framework soll an dieser Stelle nicht weiter vertieft werden, zumal z. B. auch die ISO 27001 die Grundlagen für einen konzeptionellen Angang liefert. Es soll lediglich noch erwähnt werden, dass hier für jede der fünf Funktionen (z. B. Protect) Kategorien (z. B. Access Control) und Unterkategorien (z. B. Remote Access) definiert sind. Insgesamt sind es 28 Kategorien und 108 Unterkategorien. Damit wird gesteuert, welcher Bereich durch technische und organisatorische Maßnahmen abzudecken ist. Diese Methode ist durchaus vergleichbar mit den Referenzmaßnahmenzielen und Maßnahmen (Anhang A) der ISO/IEC 27001.
Egal ob man sich nun den Reifegrad seiner Cyber Security am NIST Framework verdeutlicht oder sein ISMS auf der Basis von z. B. ISO/IEC 27001 aufbaut, es wird immer ein unumstößliches Paradigma geben: Die Aufrechterhaltung der Sicherheit ist ein fortlaufender Prozess. In der Praxis ist allerdings zu sehen, dass Unternehmen, Organisationen, Institute und Behörden mit diesem Prozess und insbesondere im Kontext von Detektion und Reaktion oft überfordert sind. Diese Fähigkeiten müssen, wenn absolute Sicherheit ein Mythos ist, neben der Prävention aber ebenfalls ausgeprägt sein. Keine bzw. nicht adäquate Tools, nicht existierende bzw. unzulängliche Prozesse, fehlendes Know-how und fehlende Ressourcen sind hier allerdings keine Seltenheit. Somit ist die Fähigkeit, Security zu betreiben, nicht immer ausreichend ausgeprägt.
SOC
In den letzten Jahren hat sich der Begriff Security Operations Center (SOC) etabliert. In einem SOC werden die Anwendungen, Prozesse und Personen gebündelt, die für einen adäquaten Betrieb der Sicherheit erforderlich sind. Der Aufbau eines SOC ist, in Abhängigkeit vom angestrebten Reifegrad (Kontext: Detektion und Reaktion), mit einer nicht unerheblichen Investition verbunden. Wer sich kein eigenes SOC leisten kann oder will, der kann SOC-Dienste auch über externe Anbieter beziehen, die sich auf die Erbringung solcher Dienste für ihre Kunden spezialisiert haben.

2 2.0 und technische Lösungen

Technische Lösungen
Wenngleich immer wieder betont werden muss, dass nicht jedes Risiko durch eine technische Maßnahme minimiert oder ausgeschlossen werden kann, münden die auf der Basis einer Sicherheitskonzeption ermittelten Maßnahmen am Ende natürlich auch in technische Lösungen und Produkte. Nachfolgend werden einige bekannte und heute als üblich zu bezeichnende Lösungen kurz vorgestellt. Dieser Abschnitt soll keinen technischen Deep Dive liefern. Wer sich aber dennoch der Technik komplett entziehen möchte, der kann an dieser Stelle direkt zum Fazit springen.

2.1 Referenzbild

Das an dieser Stelle aufgeführte Referenzbild soll Ihnen dabei helfen, die nachfolgend aufgeführten Security-Funktionen besser einordnen zu können.
Abb. 13: Referenzbild
Wichtig!
Mit Blick auf Abbildung 13 sind, insbesondere damit technische Experten sich nicht sofort in Diskussionen zu seiner Qualität und Sinnhaftigkeit verlieren, die folgenden Anmerkungen wichtig.
Das Bild zeigt Security-Funktionen und keine Produkte. D. h., diese Funktionen können als dediziertes Produkt, aber auch als in einem Produkt gebündelte Funktionen ausgeprägt sein.
Die im Bild zu sehende Tür ist als Kontrollinstanz zwischen Netzbereichen mit unterschiedlichen Sicherheitsanforderungen zu verstehen. Das kann der klassische Perimeter sein (d. h. der Übergang zum Internet), aber auch ein eventuell zwischen z. B. dem KIS und der Verwaltung erforderlicher Netzwerkübergang.
Ob eine Security-Funktion an den referenzierten Stellen erforderlich ist, entscheidet Ihre Sicherheitskonzeption und nicht der Autor dieses Dokuments. In der Abbildung wird lediglich die Aussage getroffen, dass die entsprechende Funktion an dieser Stelle implementiert sein kann.
Das Bild zeigt eine vereinfachte Sicht. Es erhebt – insbesondere mit Blick auf die Security-Funktionen – keinen Anspruch auf Vollständigkeit.
Bitte vergessen Sie nicht, dass sich Sicherheit nicht nur über technische Maßnahmen definiert.

2.2 Next-Generation-Firewall

Referenz
Die Next-Generation-Firewall hat in Abbildung 13 die Ziffer 1.
Was tut die NGFW?
Eine Next-Generation-Firewall (NGFW) regelt Kommunikationsbeziehungen, d. h., sie erlaubt oder verbietet sie. In den vergangenen Jahren bezog sich diese Regelung primär auf die Verbindungsebene: Aus z. B. dem Office-Netzwerk darf man auf einen Webserver im Intranet zugreifen. Mit dem Aufkommen der Next-Generation-Firewalls wurde diese Regelung weiter ausgebaut und kann u. a. die folgenden Aspekte berücksichtigen:
Für welche Anwender bzw. Anwendergruppen ist die Verbindung erlaubt?
Welche Anwendung(en) ist (sind) erlaubt?
Welche Webseiten bzw. -kategorien dürfen aufgerufen werden?
Wenn eine Verbindung zulässig ist (z. B. der User Arthur Dent darf Webseiten der Kategorie Business and Economy aufrufen), dann ist nicht auszuschließen, dass über die Kommunikation mit diesen Webseiten ein Angriff auf den Rechner von Arthur Dent ausgeführt wird. Diese wäre dann in diesem Fall sofort wieder zu unterbinden. Aus diesem Grund überwachen Next-Generation-Firewalls bei den aktiven Verbindungen auch den Datenstrom, so z. B.:
Wird über die Verbindung Malware übertragen?
Sind Kommunikation und ausgetauschte Datenpakete in irgendeiner Form auffällig?
Die Abbildung 14 zeigt beispielhaft, wie eine NGFW-Regel aufgebaut sein kann. So eine Regel hat immer eine Richtung (z. B. Source Network → Destination Network) und legt fest, welche Kommunikation geregelt und wie überwacht werden soll.
Abb. 14: Next-Generation-Firewall-Regel
Wenn man vom Regelwerk (Policies) einer Firewall spricht, dann wird damit lediglich zum Ausdruck gebracht, dass in der Regel mehrere Regeln der oben aufgeführten „Form” konfiguriert sind.
Anmerkung
Die Vorteile einer Next-Generation-Firewall sind nicht in jeder Umgebung interessant und hilfreich. So gibt es Umgebungen (z. B. klinisches Umfeld), in denen sehr viele „exotische” Anwendungen zum Einsatz kommen, die nicht unbedingt zum Standardrepertoire einer NGFW zählen. In so einer Umgebung ist zumindest die Kontrolle von Anwendungen mithilfe des Regelwerks einer Firewall kaum möglich. Einige Hersteller bieten deshalb die Möglichkeit, dass für solche Anwendungen dedizierte Erkennungsmuster eingespielt werden können. Die Existenz einer solchen technischen Möglichkeit darf aber nicht darüber hinwegtäuschen, dass die Erstellung solcher Erkennungsmuster nicht unbedingt zum Standard-Know-how-Profil eines Firewall-Administrators zählt und auch nicht immer als trivial zu bezeichnen ist.

2.3 Threat Intelligence

Referenz
Die Threat Intelligence hat in Abbildung 13 die Ziffer 7.
Es ist zu beobachten (Stand: 2020), dass viele Hersteller ihre Sicherheitslösungen (z. B. Next-Generation-Firewalls, Mail Gateways) mittlerweile durch eine sogenannte Threat Intelligence (TI) anreichern. Diese Intelligenz wird entweder direkt vom Hersteller selbst, oder über eine Threat-Intelligence-Plattform (TIP) bereitgestellt. Damit diese Quellen nicht abstrakt bleiben, sei noch erwähnt, dass es sich dabei überwiegend um Cloud-Lösungen handelt. Einige wenige dieser Lösungen können auch im IT-Verbund des Kunden (on-premises) bereitgestellt werden.
Threat Intelligence
Unter Threat Intelligence (TI) sind Lösungen zu verstehen, die auf der Basis von sehr großen, sicherheitsrelevanten Datenmengen (Big Data) und einer darauf aufsetzenden intelligenten Analyse z. B. aggregierte Echtzeitdaten bereitstellen, mit deren Hilfe Sicherheitsvorfälle entdeckt werden können. Threat Intelligence und Security Intelligence (SI) werden von den Herstellern oft synonym verwendet. Nachfolgend einige Beispiele:
Ihre Firewall kann Sie auf der Basis von TI-Daten darüber informieren, dass Rechner in Ihrem Netz den Kontakt zu einer bösartigen Instanz (z. B. einem Command and Control Server) aufgenommen haben.
Ihr Proxy kann Sie auf der Basis dieser TI-Daten darüber informieren, dass Ihr Browser während des Surfens im Internet von einer besuchten Webseite aufgefordert wurde, im Hintergrund Kontakt mit einer anderen Seite aufzunehmen, über die in der Vergangenheit Malware verteilt worden ist.
Ihr Netzwerk kann Sie auf der Basis dieser TI-Daten darüber informieren, dass bei einigen Rechnern Verhaltensmuster in der Kommunikation zu sehen sind, die für eine Infektion dieser Rechner sprechen.
Mithilfe von AI können die Muster einer Mail analysiert und auf der Basis des Schreibstils z. B. Hinweise gegeben werden, dass als Absender einer E-Mail zwar Ihr CIO angeben ist, der Schreibstil aber nicht zu ihm passt.
TI-Plattformen
Die Entwicklung von TI-Plattformen ist eine weitere Antwort auf die sich verändernde Bedrohungslage. Sie sind mittlerweile im Security-Produktportfolio von vielen Herstellern zu finden, die ihre bestehenden Sicherheitsprodukte um die Nutzung von SI-Daten erweitern. Als Beispiele zu nennen sind Angebote von IBM (QRadar) [14], Trend Micro (Advanced Threat Protection) [15], Cisco Systems (Talos) [16], FireEye (Threat Intelligence) [17].
Die aus diesen Plattformen gewonnenen Daten können aber nicht nur zum Erkennen von Sicherheitsvorfällen beitragen, sondern auch einen Beitrag zur erfolgreichen Abwehr von Angriffen leisten. Nachfolgend sind einige Beispiele zu TI-Daten und ihrer Verwendung aufgeführt. Die Beispiele sind so gewählt, dass die Anwendungen einfach zu verstehen sind und das Thema Security Intelligence für Sie transparent wird.
Anmerkung
Die nachfolgenden Screenshots wurden primär von den produktiv eingesetzten Lösungen eines Herstellers gemacht. Ich möchte hier noch einmal betonen, dass ich a) diese Lösungen nicht aktiv bewerben möchte und mir b) auch bewusst bin, dass ich in meiner Darstellung durch den Funktionsumfang dieses Herstellers beeinflusst und limitiert bin. Die Screenshots haben nur ein Ziel: Sie sollen die Nähe zur Praxis sicherstellen und den Lesefluss abwechslungsreich machen.

2.3.1 DNS

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).
Abb. 15: Manuelle DNS-Abfrage
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.
Abb. 16: DNS-Anfragen [18]
Abb. 17: DNS-Anfragen mit Klassifizierung Security Prevent
Abb. 18: DNS-Anfragen mit Klassifizierung Categories
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).
Anmerkung
Eine auf DNS aufsetzende Sicherheitsfunktion wird oft auch als First-Line-of-Defense bezeichnet. Dadurch wird implizit auch noch einmal signalisiert, dass die heutige Verteidigungsstrategie mehrere Sicherheitsfunktionen enthält. Sicherheitsfunktionen auf der Basis von DNS sind einfach umzusetzen und oft z. B. ein Funktionsbestandteil einer Firewall, eines Web Proxys, oder einer Desktop-Security-Lösung. Natürlich kann auch diese Sicherheitsfunktion versagen.

2.3.2 IP-Adressen

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.
Abb. 19: Blocken von IP-Adressen (Beispiel 1)
Abb. 20: Blocken von IP-Adressen (Beispiel 2)
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.
Anmerkung
Der auf einer Threat Intelligence aufbauende Schutz ist oft in Mail Gateways, Firewalls, Web Proxies und Desktop-Security-Lösungen integriert. Auch diese Lösung kann keinen absoluten Schutz bieten.

2.3.3 Malware und Hashfunktionen

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.
Abb. 21: Hashwert
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:
Ein Hashwert-Verfahren liefert – egal womit es „gefüttert” wird (z. B. das Telefonbuch von München, oder ein einziges Wort) – immer eine Ausgabe (den Hash) der gleichen Länge (bei z. B. SHA256 sind das 256 Bit). Es ist also auch ohne ein Studium der Mathematik klar, dass diese Verfahren nicht umkehrbar sind. D. h., Sie können ausgehend von einem Hash nicht auf die Eingabedaten zurückrechnen.
Eine kleine Änderung an den Eingabedaten (h an Stelle von H) bewirkt eine massive Änderung im Ergebnis.
Da der Hash nur eine endliche Länge hat, können zwei unterschiedliche Dateneingaben zum gleichen Ergebnis führen. Man spricht dann von einer Kollision. Die Kollisionswahrscheinlichkeit nimmt mit der Länge des Hashwerts ab.
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.
Abb. 22: SHA256: Abfrage der Datenbank
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.
Anmerkung
Bei einem neuen Angriff wird die Threat-Intelligence-Datenbank das File noch nicht kennen und somit wird es in diesem Moment auch nicht geblockt. Dennoch ist diese Lösung ein weiteres, hilfreiches Glied in unserer Sicherheitskette, zumal diese Funktion auf den Endgeräten auch keine lokal vorgehaltenen Erkennungsmuster erforderlich macht.
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.
Abb. 23: Eine Firewall blockt Malware

2.3.4 Malware und die Sandbox

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.
Abb. 24: Sandbox: Verhaltensindikatoren (das System kennt 984 verschiedene) [22] Anmerkung
Zeitverzögerung beachten
Eine Sandbox-Lösung ist in der Regel nicht nur eine kostenintensive Lösung, sie bedingt auch, wenn sie nur zur manuellen Analyse verwendet wird, dass entsprechende Prozesse etabliert werden und ein entsprechendes Know-how existiert: Wer lädt wann welche Files in die Sandbox und wer kann das Ergebnis interpretieren?
Die Sandbox als ein weiteres Glied in unserer Sicherheitskette zeigt noch einmal, dass wir das Auftreten eines Sicherheitsvorfalls akzeptieren müssen, denn wir können ihn nicht zu 100 % ausschließen. Wenn ein File an die Sandbox zur Analyse übergegeben wird, dann dauert es einen Moment (z. B. 5 Minuten), bis ein Ergebnis vorliegt. In dieser Zeit hat sich die Malware aber eventuell schon in Ihrem Netzverbund verbreitet. D. h., die Analyse kommt eigentlich zu spät (Detektion), zeigt Ihnen aber, wie die Malware in Ihrem Netzverbund agiert. Genau diese Informationen sind nun wichtig, um eine strukturierte Vorgehensweise einleiten zu können (Reaktion).
Um den technischen Experten gerecht zu werden, sei an dieser Stelle noch angemerkt, dass die Entwickler von schädlicher Software natürlich auch Experten sind. D. h., die Malware kann z. B. versuchen festzustellen, ob sie in einer speziellen Umgebung festsitzt. Sollte das der Fall sein, dann stellt sie sich schlafend und vermeidet somit, dass sie aufgrund ihres Verhaltens erkannt wird. Somit ist auch diese Lösung nicht unfehlbar.
Intrusion Prevention System (IPS)
Referenz
Die Intrusion-Prevention-System-Lösung hat in Abbildung 13 die Ziffer 4.
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.
Abb. 25: Blockieren einer Kommunikation durch Snort
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.
Anmerkung
IPS-Lösungen waren anfänglich nicht überall gleichermaßen beliebt, da selbst eine gepflegte und betreute IPS-Lösung auch produktive Kommunikationsströme blockieren kann. Solche falschen Entscheidungen bezeichnet man als False Positives. Mit heutigen Systemen kann die Zahl der False-Positives-Entscheidungen reduziert werden. Dennoch sind diese Systeme auch weiterhin als komplex zu bezeichnen.

2.4 Herausforderung: Verschlüsselte Verbindungen

HTTP(S)
Es ist sicherlich Tim Berners-Lee geschuldet, dass auch Menschen ohne IT-Kenntnisse mit dem Begriff HTTP etwas anfangen können, denn er hat sich 1989 dafür entschieden, dass die erste Webseite mit http:// aufzurufen ist. Nicht minder bekannt dürfte HTTPS sein, denn letztlich stellen wir heute beim Aufruf von vielen Webseiten dieses Kürzel voran. HTTP und HTTPS sorgen dafür, dass z. B. der Inhalt einer Webseite vom Webserver zu unserem Rechner transferiert wird.

2.4.1 Aufbau einer verschlüsselten Verbindung

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.
Abb. 26: Aufbau einer verschlüsselten Verbindung

2.4.2 Die Problematik

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.
Abb. 27: Das eigentliche Problem der Verschlüsselung
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.

2.4.3 Aufbrechen von Verbindungen

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.
Anmerkung
Da nicht alle verschlüsselten Verbindungen aufgebrochen und analysiert werden können, ist das Augenmerk auch weiterhin auf das Thema Desktop Security (z. B. in Form von Virenscannern) zu richten. Allerdings ist die HTTPS-Thematik auch noch einmal ein verständlicher Beleg dafür, dass eine absolute Sicherheit nicht herstellbar ist.
Wenn wir davon ausgehen, dass auch Angreifer zunehmend verschlüsselte Verbindungen nutzen werden, die nicht unbemerkt durch unsere Sicherheitssysteme aufgebrochen werden können, dann bleibt eine Erkenntnis: Die Sicherheitssysteme an den Netzübergängen (z. B. Firewall oder Proxy) können ihre Aufgabe nicht mehr vollumfänglich erfüllen: Was sie nicht sehen, können sie nicht kontrollieren.
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.

2.5 Mobile Geräte

Herausforderung Tablet und Smartphone
Wir müssen an dieser Stelle sicherlich nicht auf Studien verweisen, um zu betonen, dass mobile Endgeräte wie z. B. Tablets oder Smartphones mittlerweile weit verbreitet und als valides Arbeitsmittel zu berücksichtigen sind. Mit Blick auf das Thema Sicherheit werden diese Geräte aber oft als eine Herausforderung empfunden, da sie sich nicht immer über die klassischen Tools der IT-Abteilungen einbinden und kontrollieren lassen.
Beispiel iPhone
Das folgende einfache Beispiel soll das Security-Dilemma illustrieren. Ein iPhone z. B. bietet Ihnen viele Sicherheitseinstellungen (z. B. PIN, Sperrbildschirm etc.). Diese werden lokal konfiguriert, was Ihre IT-Abteilung vor eine Herausforderung stellt, denn diese würde die Einstellungen gerne zentral und einheitlich definieren, umsetzen und kontrollieren wollen, mal abgesehen davon, dass aus Ihrer Sicht diese lokalen Einstellungen keine ausreichenden Schutz- und Kontrollmöglichkeiten bieten. Mit dem Apple Configurator stellt Apple ein Tool zur Verfügung, das die Konfiguration von (Sicherheits-)Profilen ermöglicht (vgl. Abbildung 28). D. h., man kann z. B. administrativ festlegen, mit welchen Wireless LANs sich ein iPhone verbinden darf. Dazu gesellen sich weitere Einstellungen, die lokal auf dem Gerät nicht verfügbar sind.
Abb. 28: Beispiel: Apple Configurator (Version 2)
Dennoch wird Ihre IT-Abteilung auch mit diesem Tool nur bedingt glücklich sein, denn ein erstelltes Profil muss via USB, Mail etc. an ein iPhone übergeben und auf diesem dann installiert werden. Das ist natürlich weit entfernt von einer angestrebten Vereinfachung und Automatisierung. Eine unbefriedigende Situation, die man oft auch z. B. im Umfeld von Handheld-Scannern vorfindet.
Mobile Device Management
Mit einem Mobile Device Management (MDM) können die Profile für mobile Endgeräte wie z. B. Windows Mobile, iOS oder Android zentral gesteuert und auf die Geräte übertragen werden. Sobald ein mobiles Endgerät vom MDM aufgenommen wurde (den entsprechenden Prozess bezeichnet man oft als On-Boarding), ist es unter seiner vollen Kontrolle. D. h., es können z. B. Compliance-Anforderungen sichergestellt, der Datenbestand auf dem Endgerät aus der Ferne gelöscht (Remote Wipe) und die Installation von Apps kontrolliert werden. Abbildung 29 zeigt ein paar Parameter die verdeutlichen, wie weitreichend diese Kontrolle sein kann.
Abb. 29: MDM-Profil Anmerkung
Mobile Endgeräte dürfen im Rahmen einer Sicherheitskonzeption nicht unberücksichtigt bleiben. Die zunehmende Zahl an Angriffen auf mobile Endgeräte, der Abfluss von Daten durch „Leaky” Apps, die Nutzung von unsicheren WLANs, nicht verschlüsselte Daten, der einfache physische Zugriff auf diese Geräte oder auch der mögliche Verlust der Geräte (z. B. im Zug liegen gelassen) sprechen für diese Empfehlung.

2.6 Cloud Access Security Brokers

Referenz
Die Cloud-Access-Security-Broker-Lösung hat in Abbildung 13 die Ziffer 6.
SaaS Dienste
Sie kennen z. B. Office 365, AWS, Azure, ServiceNow, Salesforce, Dropbox oder Google Drive nicht bzw. arbeiten in einem Unternehmen, einer Organisation oder einer Behörde, die sich bisher diesen sogenannten SaaS-Diensten, einer Disziplin des Cloud Computings, entzogen hat? Dann können Sie diesen Abschnitt gerne überspringen, denn an dieser Stelle soll nicht für eine Akzeptanz dieser Services geworben werden, sondern ich gehe schlicht und ergreifend von deren reger Nutzung aus.
Cloud Diversity
Mit der steigenden Akzeptanz für SaaS-Dienste setzt zeitgleich ein Effekt ein, der am Markt als Cloud Diversity bezeichnet wird. D. h., auch in der Cloud gibt es nicht die viel zitierte eierlegende Wollmilchsau, sondern wir bedienen uns unterschiedlicher SaaS-Dienste. Dieser Effekt ist im Rahmen einer Sicherheitskonzeption zu berücksichtigen, denn daraus leiten sich neue Gefahren ab, die man nicht mit den bekannten Sicherheitsfunktionen adressieren kann. Es geht dabei primär nicht um einen sicheren Zugriff in die Cloud (die Cloud ist nur ein weiteres Ziel und diese Thematik damit hinreichend bekannt), sondern um die Tatsache, dass man nicht sieht, was innerhalb der Cloud passiert: Sind z. B. nicht gewünschte Anwendungen integriert (Sie erinnern sich vielleicht an das API-Thema, s. Kap. 08A08, Abschnitt 1.5.8), fließen plötzlich viele Daten in Richtung eines Anwenders ab, oder werden die Anmeldedaten eines Anwenders an unterschiedlichen Orten verwendet (zeitgleich oder in einer Entfernung zueinander, die in der Zeit zwischen den Anmeldungen eigentlich nicht bewältigt werden kann)?
Cloud Access Security Broker
Lösungen von sogenannten Cloud Access Security Brokers (CASB) können diese erforderliche Kontrolle und Sichtbarkeit auf zwei unterschiedlichen Wegen herstellen (vgl. Abbildung 30). Dabei werden so gewonnene Informationen natürlich wieder über eine spezialisierte Threat Intelligence analysiert und bewertet.
API
a)
API Mode
Die CASB-Lösung kommuniziert über ein API mit der SaaS-Lösung. Hier entscheidet die Auslegung des API, welche Informationen bereitgestellt und in welcher Geschwindigkeit diese von der SaaS-Lösung verfügbar gemacht werden (z. B. die Zahl der fehlgeschlagenen Anmeldungen). Um den API Mode nutzen zu können, muss das CASB-Produkt den SaaS-Dienst unterstützen, und die Integration über das SaaS-API muss explizit konfiguriert werden.
Proxy
b)
Proxy Mode
Die CASB-Lösung agiert als Proxy. D. h., die Anwender nutzen die CASB-Lösung als Proxy, oder ein bestehender Proxy leitet die Kommunikation mit den SaaS-Diensten an die CASB-Lösung als Upstream Proxy weiter. Im Gegensatz zum CASB API Mode ist die Lösung hier in den Kommunikationsweg integriert. Da dazu aber keine API-Integration erforderlich ist, können über diesen Ansatz auch SaaS-Dienste entdeckt werden, die die Anwender zwar nutzen, die aber nicht freigegeben sind (die sogenannte Shadow IT).
Abb. 30: Das CASB-Prinzip: API vs. Proxy Mode
Dabei kann es sein, dass sich eine CASB-Lösung auf einen der beiden Wege beschränkt oder sogar beide Wege anbietet. Die Abbildung 31 zeigt das CASB Dashboard der Firma Skyhigh, wobei der dargestellte Inhalt so gewählt ist, dass noch einmal der Begriff Sichtbarkeit betont wird: Zu sehen sind alle von den Anwendern verwendeten SaaS-Dienste und deren vom CASB-Produkt vorgegebene Risikoklassifizierung. Damit wird die Aufmerksamkeit sehr schnell auf z. B. nicht gewollte SaaS-Dienste gelenkt.
Abb. 31: CASB-Steuerzentrale (Dashboard) Anmerkung
CASB-Lösungen sind auf dem Security-Markt noch recht junge Lösungen. Der kurze Ausflug soll verdeutlichen, dass sich mit dem Thema Cloud auch Bedrohungspotenziale verändern und auf die Zunahme der Nutzung von Cloud-Diensten nicht nur mit klassischen Maßnahmen reagiert werden kann.

2.7 Die Kette

Kill Chain
Sicherlich sind die vorgestellten Lösungen und Komponenten isoliert, d. h. ohne konkretes Anwendungsszenario nicht leicht zu verstehen und zu bewerten. Deshalb sollen sie abschließend noch an der bereits vorgestellten Kill Chain (s. Kap. 08A08, Abschnitt 2) für Ransomware (Beispiel von Cisco Systems) ausgerichtet werden. In Abbildung 32 zunächst noch einmal die konkreten Phasen dieser Kill Chain.
Abb. 32: Phasen der Ransomware Kill Chain
Eine Zuordnung der zuvor vorgestellten Produkte und Lösungen könnte wie in Tabelle 2 dargestellt aussehen.
Tabelle 2: Beispielhafte Ausrichtung der Komponenten und Lösungen
Kill Chain Phase
Mögliche Sicherheitsmaßnahme
Der Angreifer bedient sich zur Auslieferung seiner schädlichen Software einer Social-Media- oder Phishing-E-Mail-Kampagne. Ziel ist es, dass der Anwender auf einen Link klickt.
Mail Security
Reputation von URLs in E-Mails
Spam-Analyse
AI (Wording, Schreibstil ...)
Der Anwender klickt auf den in der E-Mail enthaltenen bösartigen Link. Über den Webbrowser wird nun eine Verbindung zu einem für diesen Angriff vorbereiteten System aufgebaut.
Web Proxy, Firewall
Threat Intelligence: DNS-Anfragen, IP-Zieladressen
Download und Installation der Ransomware
Web Proxy
Anti-Malware
SHA256 (File Reputation)
Sandbox (File-Analyse)
Threat Intelligence: DNS-Anfragen, IP-Zieladressen
Firewall
Intrusion Prevention System (IPS)
SHA256 (File Reputation)
Sandbox (File-Analyse)
Threat Intelligence: DNS-Anfragen, IP-Zieladressen
Alle an der Kill Chain ausgerichteten Sicherheitssysteme können Meldungen und Alarme generieren, die z. B. von einer Security-Incident-Event-Management(SIEM-)-Lösung analysiert und verdichtet werden.

3 Fazit

Sicherheit muss geplant sein
Die drei in Gänze zugegeben sehr langen und umfassenden Beiträge der Reihe zu Advanced Persistent Threats haben Ihnen – zumindest ist das meine Hoffnung als Autor – gezeigt, dass Sicherheit ein sehr wichtiges, Branchen und Technologie übergreifendes Thema ist. Natürlich gibt es keine absolute Sicherheit, aber dennoch können wir nicht einfach resignieren. Dies wäre nur zulässig, wenn unsere Resignation Hand in Hand mit der Abschaltung unsere IT-Systeme geht. Letztgenanntes ist im Sinne einer pauschalen, aus dem Bauch heraus getriebenen Maßnahme ebenso unsinnig wie konzeptlos umgesetzte Sicherheitslösungen.
Threats werden bedrohlicher
Die Angriffe auf unsere IT-Verbünde werden immer professioneller. Die Spitze der Evolution sind APT-Angriffe. Sie sind als gezielte Kampagne ausgelegt und oft darauf ausgerichtet, dass Daten längere Zeit unbemerkt abfließen können. Ein Parasit tötet seinen Wirt nicht, er nutzt ihn dauerhaft aus. Aber natürlich kann man dem entgegenhalten, dass das eigene Unternehmen, die eigene Organisation oder die jeweilige Behörde für keinen Angreifer so interessant ist, dass er diesen Aufwand betreiben wird. Wenn diese Aussage informiert getroffen wird, d. h. das zu erreichende Sicherheitsniveau diese Aussage rechtfertigt, dann ist diese Aussage sicherlich zu vertreten. Dennoch ist zu beachten, dass auch andere, weniger zielgerichtete Angriffe immer professioneller und komplexer werden, bzw. professionelle Angriffstools über z. B. das Darknet einer breiten Masse bereitgestellt werden. Dabei ist nicht nur der Datendiebstahl, sondern auch die Schädigung Ihrer IT-Systeme ein Ziel.
Ein IT-Verbund ist ein sehr komplexes System, das heute nicht mehr durch isolierte Sicherheitsmaßnahmen (z. B. durch Firewalls am Perimeter) geschützt werden kann. Vielmehr ist hier eine Sicherheitskonzeption erforderlich. Diese stellt sicher, dass im Vorfeld Angriffsszenarien und Schadenszenarien analysiert werden und auf dieser Basis, mit Blick auf das zu erreichende Sicherheitsniveau, informierte Entscheidungen bezüglich der erforderlichen Maßnahmen getroffen werden können. Für jede neu einzuführende und IT-gestützte Lösung ist im Vorfeld eine Sicherheitskonzeption zu erstellen. Der Ansatz, eine Lösung erst in Betrieb zu nehmen und dann erst über das Thema Sicherheit nachzudenken, hat heute keine Existenzberechtigung mehr.
Ganzheitlich agieren
Letztlich mündet eine Sicherheitskonzeption in Maßnahmen, die natürlich u. a. auch durch technische Lösungen umgesetzt werden müssen. An dieser Stelle kommen auch die Hersteller ins Spiel. Diese sind mit Blick auf das Thema Sicherheit aber nicht auf die Hersteller von IT-Sicherheitslösungen einzuschränken. Vielmehr müssen hier alle Komponenten eines IT-Verbunds auf den Prüfstand: z. B. Anwendungen, Betriebssysteme, Rechner/Server, Netzwerkkomponenten und Endgeräte.
Bei der Entwicklung dieser Komponenten ist darauf zu achten, dass relevante Sicherheitsoptionen integriert und grundsätzlich ab Werk auch schon aktiviert sind (Privacy-by-Design und Privacy-by-Default). Es ist aber hinreichend bekannt, dass vor dem Kontext Sicherheit bei einigen Komponenten die Quality Assurance schlicht und ergreifend nicht vorhanden ist. D. h., erforderliche Sicherheitsoptionen stehen nicht zur Verfügung, Patches werden nicht oder nur sporadisch zur Verfügung gestellt. Insofern müssen auch die Hersteller ihre Hausaufgaben machen.
Best Practice
Externe Steuerungen durch z. B. das IT-Sicherheitsgesetz und die DSGVO sind absolut und diskussionslos notwendig, bieten aber keine Best Practices und konkreten Maßnahmen. D. h., es fehlt die Übersetzung in Lösungen. Hier sind die jeweils maßgebenden Organe, Gremien und Branchen gefordert.
Cloud
Die Cloud wird bei der Umsetzung von Sicherheitsmaßnahmen nicht nur ein zentrales, sondern auch ein differenzierendes Element sein. Alle über die Cloud bereitgestellten Informationen (z. B. die Reputation von IP-Adressen, die Erkennung von Kampagnen, automatisch generierte Signaturen etc.) lassen sich in dieser Qualität nur über große Datenmengen, kombiniert mit einer intelligenten Analyse, bereitstellen. Die Sicherheitslösungen wie z. B. Firewalls werden mittelfristig zu ausführenden Instanzen, die automatisiert und in Echtzeit über eine Threat Intelligence Cloud gesteuert werden.
Fazit
Was ich Ihnen mit auf den Weg geben möchte und was meine Beitragsserie hoffentlich anschaulich und verständlich motiviert hat:
Unterschätzen Sie das Thema nicht.
Verschaffen Sie sich ein Bild von den Risiken und bewerten Sie diese. Es gibt hier durchaus einfache Modelle, die Sie dabei unterstützen können.
Sorgen Sie dafür, dass Sie die richtigen Fähigkeiten und Kompetenzen in Ihrem Security-Team haben.
Bleiben Sie dran. Sicherheit ist kein Ziel, das man erreicht, sondern ein Zustand, den man aufrechterhalten muss.
Widmen Sie dem Betrieb der Sicherheit die erforderliche Aufmerksamkeit.
Entwickeln Sie Sicherheitsmaßnahmen ausgehend von einer Sicherheitskonzeption (Top-down). Ein Bottom-up-Angang ist aus meiner Sicht allerdings unter gewissen Umständen durchaus zulässig, sofern er einer Methode und Best Practices folgt.
Vergessen Sie bitte nicht den gesunden Menschenverstand.
Security-Bewusstsein muss allen mit auf den Weg gegeben werden.
Security muss von Anfang an und in jedem Projekt Ihr Begleiter sein (Security-by-Design).
Checklisten sind wichtige Helferlein. Wenn Ihre Sicherheitsambitionen aber nicht darüber hinausgehen, dann wird Ihr Sicherheitsbestreben schnell zu einer Phrase.
Ja, Sicherheitsmaßnahmen sind auch manchmal unbequem.

Weiterlesen und „IT-Servicemanagement digital“ 4 Wochen gratis testen:

  • IT-Servicemanagement nach ISO 20000, IT Governance und IT Compliance
  • Zugriff auf über 220 Fachbeiträge und 160 Arbeitshilfen
  • Onlinezugriff – überall verfügbar


Sie haben schon ein Abonnement oder testen bereits? Hier anmelden

Ihre Anfrage wird bearbeitet.
AuthError LoginModal