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.
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.
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.
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 | ||||||||||||||
| |||||||||||||||
2 | Sicherstellung von Produktivität und Arbeitsfähigkeit | ||||||||||||||
| |||||||||||||||
3 | Herstellen einer „Sichtbarkeit” | ||||||||||||||
| |||||||||||||||
4 | Erkennen, Analysieren und Reagieren | ||||||||||||||
| |||||||||||||||
5 | Tests | ||||||||||||||
| |||||||||||||||
6 | Austausch von Informationen | ||||||||||||||
|
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).
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 notiertAm 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.
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 notiertSolange 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.
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.
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)
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).
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.
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.
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.
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.
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.
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)
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.
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
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.
Kurz notiertIm 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
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.
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.
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.
Kurz notiertIn 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.
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.
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 notiertWas 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.
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.
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.
AnmerkungDie 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.
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.
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.
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.