Angriffserkennung mit SIEM und VPN-Reporting Missbrauch von Remote Access verhindern

Autor / Redakteur: Elmar Török / Peter Schmitz

Lokale und Remote-Zugänge zum Netz müssen besonders gut vor Missbrauch geschützt werden. Ein optimal eingerichtetes und gewissenhaft gepflegtes Security Information und Event Management System (SIEM) kann Attacken frühzeitig erkennen und erhöht das Sicherheitsniveau des Unternehmens beträchtlich.

Firmen zum Thema

Ein SIEM-System ist nur so gut wie dessen Konfiguration. Es ist leicht, in der Fülle der Informationen von Firewalls, Anti-Virus-Scannern, Anmelde-Logs und Intrusion-Warnungen den Überblick zu verlieren.
Ein SIEM-System ist nur so gut wie dessen Konfiguration. Es ist leicht, in der Fülle der Informationen von Firewalls, Anti-Virus-Scannern, Anmelde-Logs und Intrusion-Warnungen den Überblick zu verlieren.
(Bild: fotohansel - Fotolia.com)

Benutzerzugänge zum Netz sind per se eine der am meisten gefährdeten Ressourcen in Unternehmen. Mit korrekten – gestohlenen – Credentials umgehen Angreifer die wichtigsten Abwehrmaßnahmen des Perimeters und befinden sich direkt im Herz des Netzwerks. Besonders Remote-Zugänge müssen aufmerksam auf Missbrauch überwacht werden. Wenn sich Mitarbeiter von außerhalb des lokalen Netzwerks einloggen, kann der Administrator einige der sonst üblichen Restriktionen, wie ein vorgegebenes Subnetz, nicht anwenden. Zudem sind Remote-Nutzer nicht im Gebäude anwesend, niemand kann durch einen Blick kontrollieren, ob sich unter dem Benutzernamen von Holger Müller auch wirklich Herr Müller eingeloggt hat.

Credentials als Sicherheitsrisiko

Selbst wenn der Weg ins Netz über ein VPN geschützt ist, gibt es keine absolute Sicherheit, dass der Zugang nicht kompromittiert wurde. Daher sollten alle Aktivitäten von VPN-Nutzern durch ein SIEM System sorgfältig analysiert und dokumentiert werden. Ein SIEM nimmt Events aus zahlreichen Quellen entgegen und kann aus den Hunderten von Einzelmitteilungen größere Zusammenhänge korrelieren. Für viele Branchen und Firmen ist ein SIEM ohnehin Pflicht. Diverse internationale Frameworks und Standards wie PCI, SOX, GLBA, FISMA und HIPAA bestimmen, dass Vorgänge im Netz automatisiert aufgezeichnet und in bestimmten Intervallen ausgewertet werden. Auch das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) verlangt in seinem Standard 100-1 die „Detektion von Sicherheitsvorfällen im laufenden Betrieb“.

Für die Betreiber Kritischer Infrastrukturen und Telekommunikationsunternehmen gelten mit dem 2015 neu in Kraft getretenen IT-Sicherheitsgesetz noch strengere Vorgaben. Diese Unternehmen müssen dem BSI erhebliche Störungen ihrer IT melden, sofern diese Störungen Auswirkungen auf die Verfügbarkeit kritischer Dienstleistungen haben können. Diese Meldepflicht betrifft zunächst nur die Betreiber von Kernkraftwerken und Telekommunikationsunternehmen. Für andere KRITIS-Betreiber tritt sie nach Verabschiedung einer Rechtsverordnung in Kraft, die festlegt, welche Unternehmen den Regelungen des Gesetzes unterliegen. Nicht alle Unternehmen müssen einen der genannten Standards und Frameworks einhalten, doch auch dann ist es sinnvoll, den Empfehlungen zu folgen und ein SIEM nebst entsprechenden Prozessen zu implementieren.

Best Practice-Erfahrungen für SIEM nutzen

Bis ein SIEM tatsächlich einen gewissen Grad an Autonomie bei der Abwehr von Gefahren erreicht hat, ist es allerdings ein steiniger Weg. Glaubt man Dr. Anton Chuvakin von Suse/Novell, passieren sieben der elf schlimmsten SIEM-Fehler bereits vor dem Kauf. Schlecht oder gar nicht definierte Anforderungen, keine Vorstellung über die Häufigkeit und Menge der zu loggenden Events, keine Kommunikation mit anderen Stakeholdern im Unternehmen, keine rechtliche Sichtweise, wenn persönliche Daten aufgezeichnet werden – die Liste der möglichen Fehler ist lang. Dabei ist die grundlegende Vorgehensweise weder komplex, noch erfordert sie im ersten Schritt hohe Investitionen. Zahlreiche Best Practice Guides, unter anderem vom SANS Institute und dem US-amerikanischen CERT, zeigen wie man es richtig macht. Um ein besonderes Augenmerk auf die Login-Vorgänge zu richten, müssen bei einem generell gut eingestellten SIEM die Erfassungskriterien und Korrelationen angepasst werden. Es ist leicht, in der Fülle der Informationen von Firewalls, Anti-Virus-Scannern, Anmelde-Logs und Intrusion-Warnungen den Überblick zu verlieren. Doch viele Attacken erzeugen außergewöhnliche Events, so dass es möglich ist, Gefahren zumindest bei einem Anfangsverdacht oder bei besonders gefährdeten Accounts zu erkennen.

Automatisierte SIEM-Signatur für Risikogruppe

Das CERT beschreibt in einem Whitepaper die Vorgehensweise, um Attacken über einen Remote-Zugang für Risikogruppen, in diesem Fall interne Mitarbeiter, automatisch zu erkennen. Um die Risikogruppe vorab einzugrenzen, wurde nach Auffälligkeiten selektiert. Innentäter zeigen oft im Vorfeld Anzeichen für ihre Unzufriedenheit, die später möglicherweise zu Sabotage oder Datendiebstahl führt. In der CERT Studie wurden dafür ernsthafte Streitigkeiten mit Vorgesetzten und Kollegen genannt, bereits dokumentierter Missbrauch von Firmenressourcen und frühere Disziplinarstrafen.

Mitarbeiter die ein oder mehrere solcher Kriterien erfüllten, wurden der Risikogruppe zugewiesen. Für das Profil der Angriffe analysierten die IT-Sicherheitsprofis etwa 150 versuchte und erfolgreiche Attacken aus der Vergangenheit. Während die Uhrzeit, zu der die Angriffe stattfanden selten aufschlussreich war – sie verteilten sich gleichmäßig auf innerhalb und außerhalb der Arbeitszeit – nutzten über 50% der Angreifer einen VPN-Zugang im Gegensatz zum lokalen Access. Das VPN selbst war natürlich kein Indiz für einen Angriff, vielmehr die Aktivitäten, die danach stattfanden. Dazu gehörten auch die eingesetzten Protokolle und Anwendungen. Für aktive Angriffe, die nicht nur Datendiebstahl zum Ziel hatten, kamen entweder SSL, RDP oder Telnet zum Einsatz. Die Signatur für das SIEM enthielt also eine Regel, die VPN-Sessions überwachte, wenn sie von einem Mitglied der Risikogruppe aufgebaut, und danach SSL, Telnet oder RDP als Protokoll genutzt wurde.

Technische Anzeichen für Angriffe aufspüren

Auch ohne konkrete Risikogruppe weisen zahlreiche Parameter auf einen gerade stattfindenden Angriff hin. Beispielsweise sehr viele Login-Versuche an einer Ressource, jedes Mal mit einem anderen Benutzernamen, oder eine Handvoll gescheiterter Login-Versuche, die von einem erfolgreichen Login abgeschlossen werden. Verdächtig sind auch eine Vielzahl von Login-Versuchen auf allen erreichbaren Systemen mit den gleichen Credentials oder Login-Anfragen zu unüblichen Zeiten oder Orten für den Benutzer. Um Auffälligkeiten zu erkennen, ist es entscheidend eine Baseline zu haben, die den Normalzustand im Netz darstellt. Wichtige Standard-Reports, die in Bezug auf lokale und remote-Logins relevante Eckdaten wiedergeben, sind beispielsweise die Systeme mit den meisten gescheiterten Logins, das systemweite Verhältnis von geglückten zu gescheiterten Logins, ein Trendreport über die Anzahl gescheiterter Logins pro Stunde sowie eine Liste der User, deren Login an mehr als einem System misslang.

Kompetenzen und Prozesse im Vorfeld unternehmensweit klären

Wichtig sind neben der technischen Detektion auch die legalen und unternehmenspolitischen Vorgaben. Sind die Kompetenzen und Prozesse soweit geklärt, dass die Abwehr ohne Zeitverzögerung und im Rahmen der gesetzlichen Vorgaben starten kann? Gerade wenn Standorte im Ausland mit anderer Rechtslage beteiligt sind, können sich schwer zu vereinbarende Interessenkonflikte zwischen Datenschutz und Sicherheitsbelangen ergeben. Die IT-Abteilung allein kann diese Entscheidungen nicht treffen, muss aber die möglichen technischen Maßnahmen so aufbereiten, dass das Management die Folgen erkennen und ausgewogene Entscheidungen treffen kann, die die Interessen des Unternehmens optimal schützen.

(ID:43940693)