aus Netzwerk Insider Ausgabe Juni 2019
Die Grundlage für eine umfassende und nachhaltige Informationssicherheit bildet ein sogenanntes Information Security Management System (ISMS), in dem Organisation, Rollen und Verantwortlichkeiten sowie ein Richtlinienapparat für die Informationssicherheit festgelegt werden.
Hierzu gehören auch Prozesse zur Erstellung, Umsetzung und Pflege von Sicherheitskonzepten sowie zur Erkennung und Behandlung von Sicherheitsvorfällen und Schwachstellen. Ein ISMS hat also einen erheblichen operativen Anteil (Security Operations, kurz: SecOps). Typischerweise werden diese operativen Elemente der Informationssicherheit als spezieller kontinuierlicher Verbesserungsprozess (KVP, engl. Continuous Improvement Process) realisiert.
Abbildung 1 illustriert einen solchen KVP anhand des Cybersecurity Framework des National Institute of Standards and Technology (NIST), das die folgenden Elemente spezifiziert [1]:
Wichtig ist dabei insbesondere der systematische Umgang mit Risiken, die sich beispielsweise aus unzureichend umgesetzten Maßnahmen oder aus Schwachstellen ergeben, die nicht schnell genug beseitigt werden können. Hierzu ist für die Informationssicherheit ein Risikomanagement erforderlich. Außerdem wird die Informationssicherheit durch Schnittstellen zu IT-Prozessen zum integralen Bestandteil der Prozesslandschaft.
Im Folgenden werden die wesentlichen Elemente der operativen Informationssicherheit genauer hinsichtlich folgender Fragestellungen betrachtet: Welche Anforderungen stellen anerkannte Standards und mit welchen Techniken können diese Anforderungen umgesetzt werden? Welche Kernprozesse sind für die operative Informationssicherheit notwendig und welche Schnittstellen zu anderen (IT-)Prozessen sind erforderlich? Welche Werkzeuge werden in der operativen Informationssicherheit eingesetzt? Wir werden uns dabei primär auf die Bereiche Detektion und Reaktion konzentrieren.
1. Relevante Standards zur Informationssicherheit
Wichtige Standards im Umfeld der Informationssicherheit, die natürlich auch die operativen Aspekte der Informationssicherheit berücksichtigen, sind ISO 27001 und ISO 27002 sowie der IT-Grundschutz des Bundesamts für Sicherheit in der Informationstechnik (BSI). Sehr hilfreiche Informationen liefert außerdem das bereits erwähnte “Framework for Improving Critical Infrastructure Cybersecurity” des NIST.
ISO 27001 und ISO 27002 und weitere Standards der Serie ISO 27xxx
Der Standard ISO 27001 spezifiziert Anforderungen „für die Einrichtung, Umsetzung, Aufrechterhaltung und fortlaufende Verbesserung“ eines ISMS. ISO 27001 legt hierzu auf einem vergleichsweise hohen Niveau einen umfassenden Satz von Sicherheitsmaßnahmen fest, der alle wesentlichen Bereiche der IT abdeckt (siehe Anhang A von ISO 27001):
Zu diesen Maßnahmen im Anhang A von ISO 27001 liefert der Standard ISO 27002 dann Umsetzungsempfehlungen. In den folgenden Kapiteln werden insbesondere für die Bereiche Detektion und Reaktion relevante Maßnahmen exemplarisch genauer betrachtet. Für die operative Informationssicherheit sind beispielsweise die Maßnahmen zu den Themen Betriebssicherheit (ISO 27001 A.12) und Handhabung von Informationssicherheitsvorfällen (ISO 27001 A.16) besonders wichtig.
Eine weitere Hilfestellung zur Umsetzung der Sicherheitsmaßnahmen liefern die anderen Standards der Serie ISO 27xxx. Manche dieser Standards sind eher von technischen Sicherheitsmaßnahmen geprägt, wie z.B. der Standard ISO 27033, der sich speziell mit der Absicherung von Kommunikationsnetzen beschäftigt. Andere Standards adressieren organisatorische Themen. Der Standard ISO 27035 „Information security incident management“ befasst sich beispielsweise mit der Behandlung von Sicherheitsvorfällen und beschreibt Organisation, Prozess-Schritte und notwendige Schnittstellen.
Warum ist ISO 27001 nun so wichtig? IT-Landschaften können nach ISO 27001 zertifiziert werden. Solche oder vergleichbare Zertifizierungen werden auch bei Ausschreibungen von IT-Dienstleistungen oft gefordert. Außerdem müssen kritische Infrastrukturen nach dem IT-Sicherheitsgesetz den Nachweis der nachhaltigen Umsetzung eines umfassenden ISMS erbringen, was durch eine entsprechende Zertifizierung z.B. nach ISO 27001 erleichtert wird.
BSI IT-Grundschutz
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat mit Erscheinen seines IT-Grundschutz-Kompendiums im Februar 2018 seinen IT-Grundschutz modernisiert[2]. Im Februar 2019 erfolgte dann ein erstes der jährlichen Updates des IT-Grundschutz-Kompendiums. Das IT-Grundschutz-Kompendium umfasst die in Abbildung 2 gezeigten System- und Prozessbausteingruppen:
Die wichtigen Bereiche Detect und Response der operativen Informationssicherheit deckt primär die Bausteingruppe DER Detektion und Reaktion ab und umfasst die folgenden Bausteine:
Ohne dass man hier in die Details der Bausteine eingehen muss, macht bereits die Zusammenstellung der Bausteine mehr als deutlich, dass gerade die Behandlung von Sicherheitsvorfällen ein ausgesprochen komplexes Thema ist. Während vielleicht die meisten Vorfälle mit einem überschaubaren Aufwand behandelt werden können, sind auch weitreichende Sicherheitsvorfälle zu berücksichtigen. Eine IT könnte beispielsweise Opfer eines zielgerichteten Angriffs (Advanced Persistent Threat, APT) werden, mit der Folge, dass höchst sensible Daten abfließen oder durch einen Stillstand der IT auch Unternehmensprozesse stillstehen und im Extremfall auch kritische Infrastrukturen, wie z.B. eine Stromversorgung signifikant gestört werden [3]. Ein Sicherheitsvorfall kann also durchaus auch zu einem Notfall eskalieren, und auch dies muss in den Vorgehensweisen und Prozessen zur operativen Informationssicherheit berücksichtigt werden.
2. Detect & Respond: Erkennung und Behandlung von Schwachstellen und Sicherheitsvorfällen
Für die Sicherheit der IT einer Institution ist es natürlich von entscheidender Bedeutung, dass man die eigenen Schwächen kennt, denn nur so kann zielgerichtet über eine Risikobetrachtung mit dem potentiellen Schaden umgegangen werden.
ISO 27001 fordert hier in Maßnahme A.12.6.1 „Handhabung von technischen Schwachstellen“, dass Information über technische Schwachstellen verwendeter Informationssysteme rechtzeitig eingeholt wird, die Gefährdung der Organisation durch derartige Schwachstellen bewertet wird und angemessene Maßnahmen ergriffen werden, um das dazugehörige Risiko zu behandeln.
Schwachstellenmanagement als Prozess
Kernelement ist dabei ein Prozess, der für die systematische Erfassung und Bewertung von Schwachstellen bzw. Verwundbarkeiten, die Planung von Korrekturmaßnahmen und die Kontrolle von Umsetzung und Wirksamkeit der Maßnahmen sorgt. Ein solcher Prozess zum Schwachstellenmanagement (Vulnerability Management) ähnelt dabei durchaus einem Prozess zur Behandlung von Sicherheitsvorfällen, nur handelt es sich hier um einen proaktiven Prozess, denn der Schaden ist (zunächst) noch nicht eingetreten.
Eine typische Regelung im Schwachstellenmanagement ist: Der jeweilige IT-System- oder Anwendungsverantwortliche ist für die systematische Sammlung von Informationen hinsichtlich Schwachstellen des von ihm betreuten Systems und für das Einspielen von Patches zuständig. Das sagt sich so leicht. Immer wieder kommt es vor, dass Administratoren und sonstige Systemverantwortliche nicht über Schwachstellen ihrer Systeme genügend informiert sind, geschweige denn einen in der Informationssicherheit spezifizierten Prozess zum Schwachstellenmanagement überhaupt kennen. Hier liegt das eigentliche Problem: Alle Beteiligten an der IT müssen aktiv und eigenverantwortlich mitmachen!
Security-Tests
Im Schwachstellenmanagement ist es außerdem üblich, exponierte und kritische Anwendungen (insbesondere Web-Anwendungen) einem Penetrationstest oder zumindest einem Test mit einem Schwachstellen-Scanner zu unterziehen, bevor die Anwendung in Produktion geht und über das Internet erreichbar ist. Daneben werden auch oft produktive Systeme in regelmäßigen Abständen oder auf Stichprobenbasis über einen Schwachstellen-Scanner geprüft, denn es werden schließlich immer neue Schwachstellen bekannt und es kommt durchaus vor, dass es beispielsweise nicht gelingt, einen Patch schnell genug einzuspielen. Hier ist es wichtig, die Systeme genau zu kennen, die noch einen veralteten Patch-Level aufweisen, um bei Bedarf mit ergänzenden Sicherheitsmaßnahmen diese Systeme besser zu schützen. Dies kann beispielsweise durch Mikrosegmentierung [4] oder durch den zusätzlichen Einsatz von Funktionen eines Intrusion Prevention System (IPS) auf einer Firewall erfolgen.
Gesteuert werden diese Security-Tests oft von den Mitarbeitern in der operativen Informationssicherheit (SecOps-Team). Security Tests müssen jedoch nicht nur im Prozess zum Schwachstellenmanagement verankert werden, sondern auch in den Prozessen zur Entwicklung und Abnahme von IT-Anwendungen. Dementsprechend sehen moderne Standards für die Softwareentwicklung neben Vorgaben für die Berücksichtigung der Informationssicherheit bei Entwurf und Design (Secure Coding) auch Security Tests sowohl auf Quelltext- bzw. White-Box- als auch auf Black-Box-Level bis hin zu Penetrationstests vor. Mit dem Security Development Lifecycle (SDL) hat beispielsweise Microsoft die Informationssicherheit konsequent in den eigenen Entwicklungs- und Wartungsprozess integriert [5]. Am besten ist es also, Schwachstellen zu vermeiden bzw. möglichst frühzeitig zu erkennen, also Security by Design.
Der Einsatz der beschriebenen Testmethoden wird auch in den oben genannten Standards zur Informationssicherheit gefordert:
Prozess zur Behandlung von Sicherheitsvorfällen
Die wesentlichen Prozess-Elemente bei der Behandlung von Sicherheitsvorfällen sind:
Schon die Erkennung eines Sicherheitsvorfalls kann problematisch sein. Der Befall eines PCs mit einem Verschlüsselungstrojaner fällt schnell auf, ein professioneller Lauschangriff hinterlässt möglicherweise dagegen kaum Spuren. Wenn ein potentieller Sicherheitsvorfall entdeckt wird, ist die nächste Frage, ob die Meldewege definiert und allen Mitarbeitern bekannt sind. „Wie erkenne ich Sicherheitsvorfälle und wie verhalte ich mich bei einem solchen Vorfall?“ sind typische Themen einer Sensibilisierungskampagne. Wenn der Sicherheitsvorfall nun gemeldet ist, gilt es schnellstmöglich die mit dem Vorfall verbundenen Schäden und Risiken zu minimieren. Hier ist es besonders wesentlich, dass die Mitarbeiter, die den Vorfall bearbeiten, auch mit den notwendigen Berechtigungen ausgestattet sind. Auch dies ist leicht gesagt: Wo ist die Grenze, ab der der Bearbeiter dann doch erst einen Entscheider hinzuziehen muss (z.B. Komplettabschaltung der IT)? Sind die Befugnisse definiert und dem betreffenden Personal bekannt?
Spätestens an dieser Stelle wird deutlich, dass ein Prozess zur Behandlung von Sicherheitsvorfällen durch eine Vielzahl von Schnittstellen geprägt ist, wie in Abbildung 3 dargestellt. Ein Sicherheitsvorfall kann wie schon angedeutet z.B. zu einem Notfall werden oder zu einem normalen Incident heruntergestuft werden. In beiden Fällen sind Schnittstellen zu den jeweiligen Prozessen erforderlich. Außerdem sind Schnittstellen zum Risikomanagement und zum Schwachstellenmanagement notwendig, um ggf. Risiken und Schwachstellen in den betroffenen Systemen zu melden. Je nach Vorfall werden auch forensische Techniken benötigt, um Beweise zu sichern. Hier wird man auch Zielkonflikte ausbalancieren müssen, denn eine möglichst schnelle Beseitigung eines Vorfalls kann durchaus (ob beabsichtigt oder nicht) auch Beweise vernichten.
So negativ Sicherheitsvorfälle sein mögen, aus ihnen kann entscheidendes Wissen gewonnen werden, um künftig besser gewappnet zu sein, denn „nach dem Vorfall ist vor dem Vorfall“! Daher sind neben der Analyse und der Dokumentation eines Vorfalls auch die Schaffung einer Wissensdatenbank (zumindest für „interessante“ Vorfälle) und die Rückkopplung zur Erstellung und Pflege von Sicherheitskonzepten notwendig. Und auch hier ist klar: Wie oft in der Informationssicherheit haben wir es mit einem KVP zu tun. Neben dem Standard ISO 27035 bilden insbesondere die oben schon erwähnten Bausteine DER.2.1, DER.2.2 und DER.2.3 des BSI IT-Grundschutz-Kompendiums eine sehr gute Grundlage für die umfassende und nachhaltige Implementierung des KVP zur Behandlung von Sicherheitsvorfällen. Erwähnenswert ist in diesem Zusammenhang in jedem Fall aber auch der „Computer Security – Incident Handling Guide“ des NIST [6].
Instrumente zur Detektion und Analyse von sicherheitsrelevanten Ereignissen
Die Ereignis-Logs der verschiedenen IT-Systeme, die z.B. Anmeldeversuche, Änderungen von Einstellungen, Fehler und sonstige Ereignisse protokollieren, sind natürlich wesentliche Quellen, um sicherheitsrelevante Ereignisse erkennen, analysieren und die Ursachen ermitteln zu können. Daher fordern die Standards zur Informationssicherheit auch entsprechend eine solche Protokollierung und mindestens eine regelmäßige Prüfung der Logs (siehe z.B. in ISO 27001 die Maßnahme A.12.4.1 Ereignisprotokollierung). Solche Protokolle sollten an zentraler Stelle gesammelt werden, denn nur so ist es leicht möglich, Vorkommnisse system- und anwendungsübergreifend zu analysieren. Hierzu werden Log-Management-Werkzeuge eingesetzt. Auf diese Weise kann dann auch eine kontinuierliche Überwachung und Auswertung geschaffen werden. Siehe hierzu auch Anforderung DER.1.A11 „Nutzung einer zentralen Protokollierungsinfrastruktur für die Auswertung sicherheitsrelevanter Ereignisse“ des BSI IT-Grundschutz-Kompendiums.
Besonders wichtig ist die Protokollierung administrativer bzw. allgemein privilegierter Zugriffe auf die IT-Landschaft. Dies gilt insbesondere für Zugriffe von externen Dienstleistern. Hier geht es nicht nur um die Protokollierung der Sitzungsdaten, sondern auch um die Aufzeichnung der Aktivitäten des Administrators. ISO 27001 fordert dies in A.12.4.3: „Tätigkeiten von Systemadministratoren und Systembedienern werden aufgezeichnet und die Protokolle sind geschützt und werden regelmäßig überprüft“. Eine solche Funktion zur Protokollierung administrativer bzw. privilegierter Zugriffe ist meist auch Bestandteil von Lösungen zum Privileged Access Management (PAM), die als weitere Funktionen beispielsweise auch eine sichere Verwaltung von Credentials (Passwörter) und eine Kontrolle von Zugriffsberechtigungen ermöglichen [7].
Auf Basis solcher Ereignis-Logs und anderer Datenquellen (z.B. PAM) ermöglicht ein sogenanntes Security Information and Event Management (SIEM) eine automatisierte Echtzeitanalyse von Ereignissen zur Erkennung und Analyse von Anomalien und Sicherheitsvorfällen. Eine solche Funktion ist insbesondere für die Überwachung von Systemen mit hohem Schutzbedarf von Bedeutung und entsprechend in DER.1.A15 „Zentrale Detektion und Echtzeitüberprüfung von Ereignismeldungen“ im IT-Grundschutz-Kompendium empfohlen.
Log-Management und SIEM haben sich als wesentliche Instrumente für Detektion und Analyse von sicherheitsrelevanten Ereignissen erwiesen. In den folgenden Kapiteln 4 und 5 werden diese Werkzeuge daher genauer betrachtet.
Security Operation Center
Wie eben beschrieben benötigen wir eine zentrale Stelle, an der sicherheitsrelevante Informationen und Ereignisse zusammenlaufen, protokolliert und kontinuierlich in Echtzeit analysiert werden. Hier sollten auch Schwachstellen in der IT systematisch erfasst und in die Analyse mit einbezogen werden. Dabei sollte auch die Information vorliegen, welche Risiken hinsichtlich der Informationssicherheit bestehen, welche Sicherheitsmaßnahmen umzusetzen sind und wie der Umsetzungsstatus ist. Bei Feststellung von Sicherheitsvorfällen kann von dieser zentralen Stelle aus unmittelbar reagiert werden, Sofortmaßnahmen können eingeleitet werden und im Nachgang auf Basis des gesammelten Datenmaterials können forensische Analysen durchgeführt werden. Wir brauchen also einen Leitstand für die Informationssicherheit, ein sogenanntes Security Operation Center (SOC). Im SOC muss ein möglichst vollständiges Bild der aktuellen Bedrohungslage für die überwachte IT vorliegen.
Hierzu benötigt ein SOC neben den Schnittstellen zu Prozessen und Werkzeugen in den Bereichen Incident Management, Notfallmanagement und Risikomanagement auch Schnittstellen zum konventionellen Monitoring und zum Configuration Management (inklusive Zugriff auf die entsprechende Dokumentation, z.B. CMDB).
Ein SOC kann als eigenständige, besonders geschützte Struktur getrennt von anderen IT-Managementumgebungen realisiert werden. Dabei muss man allerdings beachten, dass eine Vielzahl von Schnittstellen zur überwachten IT und zum konventionellen Monitoring von Netzwerk, Servern und Anwendungen bestehen. Außerdem werden gewisse Komponenten automatisch mehrfach überwacht, wie es etwa bei einer Firewall der Fall ist. Eine Firewall ist zunächst eine Netzkomponente wie ein Switch. Verfügbarkeit und Fehlermeldungen würden daher auch im Monitoring des Netzwerks und nicht nur im SOC erfasst.
Trotz all der Technik und maschinellen Intelligenz im SOC, ist es letztendlich der menschliche Analyst im SOC, der entscheiden muss, ob für eine festgestellte Schwachstelle Handlungsbedarf besteht oder, ob es sich bei einem gemeldeten Ereignis tatsächlich um einen Sicherheitsvorfall handelt. In diesem Fall muss vom SOC aus eine entsprechende Reaktion über ein Incident Management System / Ticketing System angestoßen und nachverfolgt werden. Je nach Organisation der jeweiligen Institution kann es auch sein, dass die Mitarbeiter im SOC selbst aktiv werden. In diesem Fall ist es erforderlich, dass vom SOC neben rein lesenden Zugriffen auch weitergehende administrative Zugriffe auf gewisse IT-Komponenten (z.B. Sicherheitskomponenten) möglich sind. Die Organisation eines SOC ist typischerweise in mehrere Level (Tiers) unterteilt:
Die notwendige Kompetenz der Mitarbeiter im SOC ist also nicht zu unterschätzen, denn tiefgehende Kenntnisse der fachlichen und betrieblichen Prozesse, der IT-Architekturen, der genutzten Systeme und Anwendungen können notwendig sein, um gemeldete Ereignisse überhaupt zu verstehen und schnell richtig einzuschätzen. Außerdem ist es typisch, dass ein SOC 24 x 7 besetzt ist, denn auch die Angreifer schlafen nicht. Die Konsequenz ist, dass ein SOC sehr personalintensiv ist und auch in einer kleinen Ausbaustufe mehrere Vollzeitkräfte benötigt. Ein richtiges SOC können sich daher insbesondere kleine und mittelständische Unternehmen oft nicht leisten, auch wenn deren IT vielleicht sogar einen sehr hohen Schutzbedarf hat.
Daher ist der Betrieb eines SOC durch einen externen Dienstleister im eigenen Rechenzentrum, im Rechenzentrum des Dienstleisters (z.B. das Cyber Defense Center der Deutschen Telekom) oder als Cloud-Dienst nicht unüblich. Oft ist an dieser Stelle das Argument, dass man die notwendige Kompetenz für die Informationssicherheit nicht mehr selbst bereitstellen kann und daher auf einen Dienstleister angewiesen ist. Nur muss an dieser Stelle berücksichtigt werden, dass ein SOC einen tiefgehenden Zugriff auf die IT hat und eng mit der gesamten IT-Prozesslandschaft und sogar auch mit Geschäftsprozessen verknüpft sein muss, und genau hier liegt die Schwierigkeit beim Outsourcing eines SOC.
Automatisierte Reaktion
Wenn ein SIEM einen Sicherheitsvorfall entdeckt, ist es grundsätzlich auch möglich, dass das SIEM nicht nur einen Alarm auslöst, sondern auch sofort selbstständig aktiv wird. Eine Aktion könnte sein, dass ein System, von dem ein Angriff ausgeht, durch eine Schnittstelle zu einer Lösung für die Network Access Control (NAC) automatisiert in ein Quarantäne-Netz bzw. eine Quarantäne-Mikrozone verschoben wird. Eine andere Aktion könnte sein, dass an einer Firewall für das entsprechende System eine Policy dynamisch konfiguriert wird, die die Kommunikation für das System stärker einschränkt oder über die Aktivierung einer Intrusion-Prevention-Funktion stärker hinsichtlich Anomalien und Angriffsmustern kontrolliert. Der Vorteil liegt auf der Hand: Die Auswirkungen des Sicherheitsvorfalls würden schneller, als es ein menschlicher Security Analyst jemals könnte, gemildert bzw. im Idealfall der Sicherheitsvorfall in Sekundenbruchteilen behoben werden.
Nun ist klar, dass es nicht nur passieren kann, dass ein Angriff trotz SIEM unentdeckt bleibt. Es kann genauso ein eigentlich gutartiges Verhalten durch ein SIEM fälschlicherweise als Angriff gewertet werden. Ein solcher False Positive in Verbindung mit einer automatisierten Reaktion kann durchaus fatale Folgen haben. Automatismen sind also mit entsprechender Vorsicht einzusetzen und in vielen Fällen wird man auf die menschliche Intelligenz nicht verzichten wollen.
3. Einsatz von Schwachstellen-Scannern
Die gängigen Schwachstellen-Scanner erkennen Sicherheitslücken von diversen Komponenten. Diese beinhalten sowohl Server als auch Netzwerk- und Sicherheitskomponenten sowie Appliances. Durch die zunehmende Verbreitung von IoT-Geräten werden auch diese mittlerweile von Schwachstellen-Scannern unterstützt, sofern sie über das reguläre (IP-)Netzwerk erreichbar sind.
Produktbeispiele sind unter anderem Nessus, Qualys und das Open Vulnerability Assessment System (OpenVAS).
Der Ablauf eines typischen Schwachstellen-Scans, der auch die Sicht eines potentiellen Angreifers simuliert, teilt sich normalerweise in folgende Schritte auf:
Wichtig hierbei ist, dass Schwachstellen-Scanner nur bekannte Sicherheitslücken erkennen. Ein Schwachstellen-Scanner ist kein Wundermittel, das auch alle Zero-Day-Exploits erkennt!
In den folgenden Abschnitten soll kurz erläutert werden, wie die einzelnen Arbeitsschritte funktionieren.
Erkennen von erreichbaren Systemen: Die Erkennung von erreichbaren Systemen funktioniert im Allgemeinen über ICMP Echo Requests (Pings). Dabei kann man entweder eine Liste von Zielen (IP-Adressen) oder ganze Subnetze überprüfen lassen (siehe Abbildung 4). Sollten Systeme auf Pings nicht reagieren, so gibt es auch die Möglichkeit, ein Ziel als immer erreichbar zu markieren, so dass auch ohne vorherigen Erreichbarkeitstest sowohl Port- als auch Schwachstellen-Scans durchgeführt werden.
Port-Scan: Alle erreichbaren Systeme werden darauf überprüft, welche Dienste sie anbieten. Dabei ist ein Dienst in der Regel mit jeweils mindestens einem Netzwerk-Port (TCP oder UDP) gleichbedeutend. Ein Schwachstellen-Scanner überprüft eine Liste von vorgegebenen Ports auf Erreichbarkeit und trifft Annahmen zu den darüber erreichbaren Diensten (siehe Abbildung 5). Dabei sind sowohl die Portlisten als auch die Korrelation zu üblichen Diensten variabel und wirken sich stark auf die Dauer eines Port-Scans aber auch auf die Dauer des eigentlichen Schwachstellen-Scans aus.
Schwachstellen-Scan: Mit den Ergebnissen der vorherigen Schritte können dann die vorhandenen Schwachstellen überprüft werden (siehe Abbildung 6). Wie bereits erwähnt können hier im Allgemeinen nur bereits bekannte Schwachstellen erkannt werden. Welche bekannten Sicherheitslücken überprüft werden können hängt dabei maßgeblich vom Hersteller des jeweiligen Tools ab. Sowohl die Geschwindigkeit, mit der bekannte Lücken eingepflegt werden, als auch die Genauigkeit der Tests spielen hier eine Rolle bei der Wahl des richtigen Anbieters.
Agenten-basierter Scan und Scan mit Login-Daten: Als Alternative oder als Ergänzung eines klassischen Black-Box-Scan über das Netz können auch Agenten auf dem Zielsystem oder Login-Daten für das jeweilige Ziel eingesetzt werden. Diese sammeln die Daten direkt auf dem Zielsystem und melden diese an den zentralen Schwachstellen-Scanner. Dabei werden hauptsächlich die Versionen der installierten Software mit einer Liste von bekannten Schwachstellen abgeglichen. Diese Art der Überprüfung ist normalerweise schneller als ein Scan von außen. Das Beispiel per Login ist in Abbildung 7 dargestellt. Der Vorteil hier ist, dass nicht nur von außen erreichbare Dienste, sondern auch interne Abhängigkeiten auf Sicherheitslücken überprüft werden. Dies ermöglicht, auch mögliche indirekte Angriffe auf weitere Software besser zu erkennen. Ein solcher Scan per Login ist in vielen Fällen auch auf Netzwerkkomponenten und Appliances möglich, ein Einsatz von Agenten ist im Allgemeinen nur auf Servern und/oder Endgeräten möglich, sofern der Hersteller des Schwachstellen-Scanners für das jeweilige Betriebssystem einen Agenten anbietet.
Konfigurations- und Compliance-Checks: Einige Lösungen (z.B. Nessus) sind in der Lage, die Konfiguration von Servern und Netzwerkkomponenten zu überprüfen. Die eigentliche Überprüfung funktioniert per Login, überprüft allerdings nicht den Versionsstand der installierten Software, sondern die Konfiguration von (dem Scanner bekannten) Diensten. Beispiele hierfür sind Netzwerk-Switches oder Firewalls. Dabei werden die ermittelten Konfigurationen einerseits auf sicherheitsrelevante Aspekte überprüft. Eine typische Einstellung, die hier als unsicher eingestuft wird, ist die Aktivierung von Telnet zur Administration von Netzwerkkomponenten. Andererseits können Konfigurationsparameter gegen eine Liste von guten oder schlechten („known good“ und „known bad“) Werten abgeglichen werden. Grundlage der Prüfungen sind dabei auch die Empfehlungen der Hersteller für sichere Konfigurationen ihrer Produkte. Dabei muss aber beachtet werden, dass solche Tests im Allgemeinen nicht umfassend sind und anfällig für False Positives und False Negatives sein können.
Darstellung der Ergebnisse: Die im Rahmen eines Scans ermittelten Schwachstellen müssen dem Nutzer und den Systemverantwortlichen verständlich dargestellt werden. Dazu unterstützen alle gängigen Scanner die Erstellung von Reports mit diversen Filtereinstellungen. Typischerweise werden die Administratoren der Scanner-Infrastrukturen alle Informationen erhalten wollen. Das evtl. involvierte Management ist aber normalerweise nur an kritischen Sicherheitslücken interessiert, die eine unmittelbare Bedrohung für den produktiven Betrieb darstellen. Ein Systemadministrator möchte vielleicht wissen, welche ausnutzbaren Schwachstellen auf seinem System vorhanden sind, ohne Meldungen beachten zu müssen, die lediglich Informationen zum System beinhalten. Dazu erlaubt ein Schwachstellen-Scanner sowohl eine Filterung nach System als auch nach Schwere der Sicherheitslücke. Für Letzteres hat sich die Nutzung des Common Vulnerability Scoring System (CVSS) durchgesetzt.
Mögliche Architekturen für den Aufbau des Schwachstellen-Scanners
Nach der Erläuterung der Funktionsweise eines Schwachstellen-Scanners ergibt sich die Frage: Wo in meinem Netz positioniere ich meinen Schwachstellen-Scanner?
Da ein Schwachstellen-Scan weitreichenden Netzzugriff ggf. auf viele Zielsysteme benötigt, muss auch die Positionierung des Schwachstellen-Scanners genau geplant sein. Es wird dabei davon ausgegangen, dass das Netz segmentiert ist, die Kommunikation zwischen den Segmenten mit einer Firewall geschützt wird und zumindest die folgenden Netzwerkbereiche existieren:
Die häufigsten Architekturen für die Positionierung des Schwachstellen-Scanners sind:
Zentraler Scanner: Hier wird ein Scan-System eingesetzt, das im Managementnetz (ggf. in einem eigenen Segment) verortet ist und auf der Firewall entsprechend weitreichenden Zugriff auf alle Zielsysteme erhält. Bei einer Lizenzierung pro Scanner ist dies die günstigste Option, allerdings muss die Hardware evtl. größer dimensioniert werden.
Satelliten-Scanner in jedem Netzsegment: Hier befindet sich in jedem Netzsegment ein „kleiner“ Scanner, der die Ziele in seinem Segment scannt und die Ergebnisse an einen zentralen Management-Server im Managementnetz übermittelt. Diese Lösung minimiert den Traffic zur internen Instanz und benötigt keine weitreichenden Freischaltungen zwischen verschiedenen Segmenten. Je nach Lizenzierungsmodell können hier allerdings hohe Kosten auftreten.
Vulnerability-Scanning-as-a-Service: Dies entspricht einem Schwachstellen-Scan aus der Cloud. Externe Scans aus der Sicht des Angreifers sind hiermit sehr einfach umsetzbar, allerdings muss für die Überprüfung von internen Systemen ein Cloud-Konnektor lokal installiert werden, welcher dann Zugriff auf die internen Systeme erhält. Die Aktualität der Schwachstellendatenbank ist hier am ehesten gegeben. Die Lizenzierung erfolgt im Allgemeinen pro Scan-Ziel und kann so bei einer großen Anzahl von Systemen sehr kostenintensiv werden.
Betriebliche Aspekte beim Einsatz von Schwachstellen-Scannern
Das Wissen über die vorhandenen Sicherheitslücken, wie es im ersten Unterkapitel beschrieben ist, ist zwar der technisch aufwendigere Aspekt, aber betrieblich ist der Umgang mit den gefundenen Schwachstellen wesentlich komplexer.
Ein besonders aufwendiger Aspekt, speziell bei der Einführung von Schwachstellen-Scans in bestehenden Umgebungen, ist die Klassifizierung der existierenden und neuen Systeme. Diese Klassifizierung beinhaltet:
Die Durchführung der Scans muss ebenfalls klar definiert und dokumentiert werden, um eine Vergleichbarkeit von aufeinanderfolgenden Scans zu ermöglichen. Der vielleicht wichtigste Aspekt beim Einsatz eines Schwachstellen-Scanners ist aber der Umgang mit den gefundenen Schwachstellen jenseits des reinen Reports. Hier muss bewertet werden, wer für das Schließen einer Sicherheitslücke verantwortlich ist und welche Fristen eingehalten werden müssen.
4. Log Management
Log-Management (LM) ist ein Begriff, der die Zusammenführung, Speicherung und Verwaltung von Log-Daten beschreibt. Die hierzu gesammelten Daten sind oft textbasiert und entstammen verschiedenen Quellen innerhalb einer IT-Infrastruktur. Als Quellen dienen sowohl über IP erreichbare Geräte eines Netzwerks als auch Anwendungsinstanzen. Zum automatisierten Management von Log-Daten werden spezielle LM-Lösungen angeboten.
LM-Lösungen können in verschiedenen Betriebsformen realisiert werden. Üblich ist der Betrieb als lokal installierte Software. Alternativ werden auch vermehrt Cloud-Lösungen angeboten. Neben kommerziellen Produkten ist auch ein vergleichsweise großes Angebot an freier Software verfügbar.
Von Komponenten der IT-Infrastruktur erzeugte Log-Daten fließen (z.B. per Syslog) von der Quelle zum zentralen LM und werden dort gespeichert. Dabei werden sie entweder direkt von der Quelle oder über einen speziellen Kollektor bezogen. Dieser dient als eine dem LM vorgeschaltete Instanz, die die Log-Daten an das zentrale LM weiterleitet. Der Kollektor kann dabei auch als funktionale Schnittstelle genutzt werden, die die Rohdaten zur Weiterverarbeitung umformatiert oder vorab filtert. Die gesammelten Log-Daten werden in einer Datenbank oder in einer Ordnerstruktur abgelegt. Zur effizienteren Durchsuchbarkeit wird von den Rohdaten häufig ein Index erstellt. Hierbei handelt es sich um eine zusätzliche Datenstruktur, die das Durchsuchen der Daten um ein Vielfaches beschleunigt. Häufig werden die Rohdaten zur Einsparung von Speicherplatz komprimiert.
Dem operativen Benutzer des LM wird eine Oberfläche zur Verfügung gestellt, mit der auf gespeicherte Informationen zugegriffen werden kann. Ein wesentlicher Bestandteil sind Suchfunktionen, die auch komplexe Abfragen ermöglichen. Zusätzlich können oft Dashboards erstellt werden, auf denen Trendanalysen, statistische Auswertungen oder Alarme dargestellt werden können. Der Zugriff auf die Oberfläche wird üblicherweise durch die Abfrage von Zugangsdaten gesichert.
Produktbeispiele für LM-Lösungen sind: Graylog, Quest InTrust und Splunk.
5. Security Information and Event Management (SIEM)
SIEM beschreibt eine Technologie zur Überwachung von sicherheitsrelevanten IT-In-
frastrukturen und Systemen. Ziel ist sowohl das Management von sicherheitsbezogenen Log-Daten als auch die Detektion von Angriffen und anderen Sicherheitsvorfällen. Ein SIEM bezieht dazu Daten aus zu überwachenden Geräten. In einem SIEM werden oft von zumindest folgenden Systemen die Ereignis-Logs erfasst:
Deren aufgezeichnete Daten werden in einer zentralen Komponente gesammelt, konsolidiert und analysiert. Dies ermöglicht eine zunächst ähnlich zu einer LM-Lösung übersichtliche und einheitliche Darstellung von Informationen aus verschiedenen Quellen und unterschiedlichen Formaten. Entscheidend ist jedoch für ein SIEM die Fähigkeit, Log-Daten system- und anwendungsübergreifend zu korrelieren und zu analysieren.
Im Laufe der Zeit haben sich SIEM-Lösungen stetig weiterentwickelt, um aktuellen Anforderungen weiterhin gerecht werden zu können. Ähnlich zu Firewalls hat sich auch hier der Begriff „Next-Gen SIEM“ etabliert [8]. Next-Gen SIEM-Lösungen sollen durch den Einsatz von Big-Data-Techniken einen wirkungsvollen Schutz vor modernen Cyber-Attacken bieten. Hierbei spielt vor allem der Einsatz von KI eine entscheidende Rolle.
Produktbeispiele sind: IBM QRadar, Splunk, LogRythm und Micro Focus ArcSight.
Technische Funktionsweise
Die allgemeine Architektur eines SIEM-Systems zeigt die Abbildung 8. Es ist deutlich, dass es eine sichtbare Ähnlichkeit zu LM-Lösungen gibt, jedoch ist z.B. die Normalisierung unterschiedlicher Quellen eine entscheidende Eigenschaft.
Auf technischer Ebene sammelt ein SIEM zur Analyse Log-Daten aus verschiedenen Quellen. Diese umfassen laufende Anwendungen, Systeme und Endgeräte (Server aber ggf. auch Clients). Besonders interessant sind hierbei Sicherheitskomponenten wie z.B. Firewalls und Gateways sowie Infrastruktur-Komponenten wie Router und Switches. Die dort generierten Log-Daten werden über Kollektoren oder andere Schnittstellen an die zentrale Instanz des SIEM weitergeleitet.
Die Rohdaten, die in unterschiedlichen Formaten vorliegen können, werden anschließend normalisiert. Dazu werden die Daten inhaltlich ausgewertet und anhand eines gemeinsamen Formats neu strukturiert. Einerseits ermöglicht dies eine einheitliche und übersichtliche Darstellung der Informationen. Andererseits ist es durch die Zusammenführung einfacher, Querbezüge zwischen den Daten herzustellen. Bei der Analyse der Daten kommen, ähnlich wie bei einer Firewall, Regelwerke zum Einsatz. Über Regeln können Bedingungen definiert werden, ab wann ein Ereignis als problematisch, kritisch oder verdächtig einzustufen und wie dabei zu reagieren ist. Informationen werden bei der Analyse nicht nur isoliert betrachtet, sondern zu einem umfassenderen Gesamtbild kombiniert. Dies geschieht durch die Korrelation von Ereignissen. Während manche Ereignisse an unterschiedlichen Orten einzeln unauffällig erscheinen, können sie gemeinsam betrachtet dabei helfen, kritische Vorfälle zu identifizieren [9].
Werden Vorfälle entdeckt, kann je nach Schwere unterschiedlich reagiert werden. Die Art der zu treffenden Maßnahme kann dabei als Teil des Regelwerks festgeschrieben werden. Unkritische oder zunächst harmlose Vorkommnisse können beispielsweise lediglich gespeichert werden, sodass sie in Zukunft noch einmal berücksichtigt werden können. Eine Benachrichtigung des zuständigen Administrators wäre hierbei noch nicht nötig. Problematische Ereignisse dagegen können Warnungen hervorrufen und veranlassen, dass z.B. eine E-Mail an einen Administrator geschickt wird. Dieser kann sich zeitnah um das Problem kümmern. Wird ein Angriffsversuch erkannt, könnte ein Alarm außerdem via SMS an den Administrator versendet werden, sodass er sofort aktiv wird.
Funktionsumfang
Der Funktionsumfang eines SIEM setzt sich aus Security Information Management (SIM) und Security Event Management (SEM) zusammen.
SIM behandelt vorwiegend den Umgang mit Log-Daten aus verteilten Quellen. SIM ist mit LM vergleichbar, bezieht sich jedoch konkret auf den Bereich Informationssicherheit. Sinngemäß liegt jedem SIEM auch ein spezialisiertes LM zugrunde.
SEM befasst sich mit Echtzeit-Überwachung und Incident Management unter sicherheitstechnischen Aspekten. Der Benutzer soll dadurch ein Werkzeug erhalten, das kontinuierlich ein aktuelles Lagebild der IT-Infrastruktur liefert. Hierdurch sollen Probleme rechtzeitig erkannt und Reaktionszeiten auf ein Minimum reduziert werden. Probleme umfassen dabei kritische und verdächtige Ereignisse sowie Angriffe und Angriffsversuche. Der Begriff „Echtzeit“ ist hier insofern zu verstehen, dass Ereignisse unmittelbar nach ihrem Auftreten analysiert werden. Im Optimalfall meldet das überwachte System betreffende Informationen unverzüglich an das SIEM, welches sie sofort verarbeitet. Die Zeitspanne vom Auftreten des Ereignisses bis zu dessen Erkennung wird hierbei wesentlich durch die Dauer anfallender Rechenoperationen, Lese- und Schreibzugriffe sowie Übertragungsgeschwindigkeiten bestimmt. Ist das überwachte System oder das SIEM so konfiguriert, dass Informationen nur in periodischen Zeitintervallen übertragen werden, fallen hierfür zusätzlich entsprechende Zeitenspannen an.
Der zuvor dargelegte Umfang der Basisfunktionen wird von SIEM-Lösungen zumeist um zusätzliche Funktionen erweitert. Beispiele sind:
Lizenzmodelle
Die Lizenzierung einer SIEM-Lösung erfolgt üblicherweise auf Basis des Volumens an Rohdaten bzw. der Anzahl von Ereignissen, die pro Zeiteinheit vom SIEM verarbeitet werden. Bei Überschreiten des lizenzierten Volumens verhalten sich die verschiedenen Produkte sehr unterschiedlich.
Beispiel QRadar: Die Kosten für IBM QRadar werden in Abhängigkeit von der eingehenden Datenrate berechnet. Möglich ist eine Lizenzierung per Events / s (EPS) oder Flows / min (FPM). Die dazu spezifizierte Rate legt den maximal möglichen Zustrom an Rohdaten in das SIEM fest. Wird der Wert überschritten, wird der Zustrom gedrosselt, sodass das Maximum nicht überstiegen werden kann. Die überschüssigen Daten werden dabei gepuffert. Sinkt die Datenrate wieder unter den Schwellwert, werden mit der übrigen Bandbreite die zwischengespeicherten Daten aus dem Puffer gelesen und verarbeitet bis dieser wieder leer ist.
Fließen Daten für mehr als 50% der Zeit gedrosselt ein, liefert QRadar eine entsprechende Benachrichtigung. Bis auf die Drosselung hat das Überschreiten des Limits keine weiteren Folgen. Die Drosselung selbst führt jedoch dazu, dass Daten nur noch verzögert verarbeitet werden können. Dies kann zur verspäteten Erkennung und Meldung von Problemen führen und die Korrelation von gewissen Ereignissen verhindern, wenn diese auf einem zeitlichen Intervall basiert.
Beispiel Splunk: Hier werden die Lizenzkosten anhand der Menge der einfließenden Rohdaten pro Tag berechnet. Der Hersteller bietet hierbei einen automatischen Rabatt an, wobei der Preis für ein Gigabyte proportional zur gesamten Menge abnimmt, für die die Lizenz gekauft wird. Lizenzen können individuell ab 1 GB pro Tag erworben werden, das Modell sieht kein Maximum vor. Die für die Lizenz festgelegte tägliche Datenmenge darf nur in begrenztem Umfang überschritten werden. Eine einmalige Überschreitung zieht keine Folgen nach sich, jedoch wird eine Benachrichtigung ausgegeben. Geschieht dies innerhalb von 30 Tagen fünfmal oder öfter, können die von Splunk gespeicherten Daten jedoch nicht mehr durchsucht werden. Hierbei werden die Rohdaten weiterhin gespeichert und indexiert, lediglich der Zugriff wird verweigert. Die Sperrung wird erst aufgehoben, wenn in einem Zeitraum von 30 Tagen die festgelegte Datenmenge nicht mehr überschritten oder eine neue Lizenz mit höherem Limit aktiviert wird.
Solche Lizenzmodelle erschweren die Planung eines SIEM, denn zunächst ist bei der Beschaffung eines SIEM oft unklar, mit welcher Ereignisrate bzw. welchem Rohdatenvolumen zu rechnen ist. Wenn nicht bereits ein LM-Werkzeug im Einsatz ist und man dies als Basis für eine Schätzung nutzen kann, schätzt man typischerweise für die verschiedenen Typen von IT-Komponenten das Volumen eines einzelnen Systems ab und rechnet dann auf die zu überwachende IT-Landschaft hoch. Außerdem kann sich bei einem Sicherheitsvorfall, z.B. bei einem Angriff oder bei der Ausbreitung eines Wurms bzw. eines Verschlüsselungstrojaners im Netz, im Vergleich zur Normalsituation die Rate an Ereignissen und damit das Rohdatenvolumen drastisch (und praktisch nicht im Vorfeld kaum einschätzbar) erhöhen. Als Konsequenz plant man dann zusätzlich zu dem geschätzten Volumen einen vergleichsweise großzügigen Puffer für das lizenzierte Rohdatenvolumen ein.
6. Fazit
Ein Richtlinienapparat zur Informationssicherheit ist ohne effektive und effiziente SecOps nur Papier. Die eigentliche Musik der Informationssicherheit spielt nämlich genau hier, d.h. bei einem SecOps-Team, das hilft proaktiv Schwachstellen zu vermeiden, bestehende Schwachstellen zu entdecken, diese zu schließen bzw. risikominimierende Sicherheitsmaßnahmen zu entwickeln und Sicherheitsvorfälle zu erkennen und effektiv zu beseitigen.
Inzwischen verfügen wir über bewährte Standards (insbesondere ISO 27xxx und BSI IT-Grundschutz), die helfen ein solides Management von Schwachstellen und Sicherheitsvorfällen aufzubauen und über Werkzeuge, wie z.B. Schwachstellen-Scanner, LM- und SIEM-Lösungen, die ein SecOps-Team bei der Arbeit im SOC unterstützen. Jedoch ist der Aufwand für die Planung eines solchen SOC und die effektive Nutzung des Werkzeugapparats immens.
Ein SecOps-Team muss mit einem erheblichen Know-how höchst komplexe Vorfälle system- und anwendungsübergreifend analysieren und insbesondere verstehen können. Bei dem typischen Personalnotstand in der IT ist der Aufbau eines SecOp-Teams oft eine Quadratur des Kreises. Natürlich denkt man dann schnell an das Outsourcen von SecOps, und Dienstleister haben hier auch durchaus ein sehr interessantes Portfolio. Es bleibt jedoch dabei: Die Kompetenz für die jeweiligen Geschäftsprozesse muss lokal bleiben, und dies gilt auch für die damit verbundene IT-Landschaft. Dies bedeutet zwingend: Operative Informationssicherheit kann nur zu einem gewissen Grad sinnvoll outgesourct werden.
7. Abkürzungen
APT Advanced Persistent Threat
BSI Bundesamt für Sicherheit in der Informationstechnik
CERT Computer Emergency Response Team
CMDP Configuration Management Database
CVSS Common Vulnerability Scoring System
DER Detektion und Reaktion
DMZ Demilitarisierte Zone
EPS Events per Second
FPM Flows per Minute
ICMP Internet Control Message Protocol
IoC Indicator of Compromise
IoT Internet of Things
IPS Intrusion Prevention System
ISMS Information Security Management System
ISO International Organization for Standardization
KI Künstliche Intelligenz
KVP Kontinuierlicher Verbesserungsprozess
LM Log Management
NAC Network Access Control
NIST National Institute of Standards and Technology
PAM Privileged Access Management
SDL Security Development Lifecycle SecOps Security Operations
SEM Security Event Management
SIM Security Information Management
SIEM Security Information and Event Management
SOC Security Operation Center
TCP Transmission Control Protocol
UDP User Datagram Protocol
8. Verweise
[1] Siehe https://www.nist.gov/cyberframework
[3] Die Inhalte im Artikel „Abwehr zielgerichteter Angriffe – die Paradedisziplin der Informationssicherheit“ in Der Netzwerk Insider vom Mai 2017 sind (leider) immer noch höchst aktuell!
[4] Siehe hierzu „Moderne Zonenkonzepte erfordern Mikrosegmentierung“ in Der Netzwerk Insider vom April 2019
[5] Siehe https://www.microsoft.com/en-us/securityengineering/sdl
[6] Siehe http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf
[7] Siehe hierzu „Best Practice für die sichere Administration der IT“ in Der Netzwerk Insider vom Mai 2018
[8] Siehe z.B. https://securityboulevard.com/2018/03/nextgen-siem-isnt-siem/
[9] Siehe z.B. http://docs.splunk.com/Documentation/SplunkCloud/latest/Search/Abouteventcorrelation
[10] Siehe hierzu auch „Künstliche Intelligenz erobert die IT“ in Der Netzwerk Insider vom Dezember 2018
ComConsult GmbH
Pascalstraße 27
DE-52076 Aachen
Telefon: 02408/951-0
Fax: 02408/951-200
E-Mail: info@comconsult.com
Sie müssen den Inhalt von reCAPTCHA laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von Facebook. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von Instagram. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von X. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr Informationen