SIEM-Tiefen: Out-of-Box-Korrelationen. Teil 4. Systemmodell als Kontext von Korrelationsregeln

Stellen Sie sich die Situation vor: Sie haben viel Zeit damit verbracht, Korrelationsregeln zu schreiben und zu debuggen, und einen Tag später haben Sie festgestellt, dass sie nicht funktionieren. Wie sie sagen, ist das nie passiert und hier wieder! Dann stellt sich heraus, dass nachts das Netzwerk erneut aktualisiert und einige Server ersetzt wurden, die Korrelationsregeln berücksichtigen dies jedoch nicht. In diesem Artikel zeigen wir Ihnen, wie Sie SIEM beibringen können, sich an die sich ständig ändernde Infrastrukturlandschaft anzupassen.

Systemmodell als Kontext von Korrelationsregeln


Wir nähern uns immer mehr dem Ende der Artikelserie, die sich mit der Erstellung adaptiver Korrelationsregeln befasst, die sofort funktionieren. Der Artikel erwies sich als lang, wer will, kann sofort zu Schlussfolgerungen springen.

In dem Artikel „Methodik zum Normalisieren von Ereignissen“ haben wir Techniken zusammengefasst, mit denen das Problem des Datenverlusts und der falschen Normalisierung von Anfangsereignissen minimiert werden kann. Kann jedoch argumentiert werden, dass es möglich ist, Korrelationsregeln zu erstellen, die sofort funktionieren, wenn die Rolle von Normalisierungsfehlern verringert wird? Theoretisch ja, wenn das von SIEM überwachte Überwachungsobjekt statisch wäre und ausschließlich wie in der Leistungsbeschreibung beschrieben funktioniert. In der Praxis stellt sich jedoch heraus, dass es in der realen Welt nichts Statisches gibt.

Schauen wir uns also das Überwachungsobjekt genauer an. SIEM sammelt Protokolle aus Quellen, extrahiert daraus IP-Adressen, Benutzerkonten, Zugriff auf Dateien und Registrierungsschlüssel sowie Netzwerkinteraktionen. Wenn alles zusammengefasst ist, ist dies nichts weiter als eine Information über die Phasen des Lebenszyklus eines automatisierten Systems (im Folgenden - AS). Somit ist das SIEM-Überwachungsobjekt ein automatisiertes System als Ganzes oder ein Teil davon.

Ein Lautsprechersystem ist kein statisches Objekt, es ändert sich ständig: Neue Jobs und Server werden eingeführt, alte Geräte werden außer Betrieb genommen und durch neue ersetzt, Systeme „stürzen“ aufgrund von Fehlern ab und werden aus Sicherungen wiederhergestellt. Dynamiken auf Netzwerkebene, wie z. B. dynamische Adressierung oder Routing, verändern täglich das Gesicht der Lautsprecher. Wie überprüfe ich das? Versuchen Sie, in Ihrem Unternehmen ein vollständiges und aktuelles L3-Schema des Netzwerks zu finden, und erkundigen Sie sich bei den Netzwerkadministratoren, inwieweit es den aktuellen Stand der Dinge widerspiegelt.

Bei der Entwicklung von Korrelationsregeln versuchen Sie, davon auszugehen, wie die Sprecher hier und jetzt aussehen. Durch Testen der Korrelationsregeln verfeinern Sie sie auf einen Zustand, in dem sie mit der geringsten Anzahl von Fehlalarmen in der aktuellen Lautsprecherkonfiguration arbeiten können. Da sich die Sprecher ständig ändern, müssen die Korrelationsregeln früher oder später aktualisiert werden.

Lassen Sie uns nun die Aufgabe komplizieren und die Regeln berücksichtigen, die von externen Experten wie kommerziellen SOCs, Integratoren, die SIEM implementieren, oder Entwicklern von SIEM-Lösungen selbst bereitgestellt werden. Diese Regeln enthalten nicht die Funktionen Ihrer Lautsprecher - den Ausführungskontext - sie sind nicht für sie optimiert. Dieses Problem ist ein weiterer Stolperstein im Konzept der sofort einsatzbereiten Korrelationsregeln. Seine Lösung könnte sein, dass SIEM in sich selbst:

  1. Erstellt ein Modell der beobachteten Lautsprecher.
  2. Hält dieses Modell immer auf dem neuesten Stand.
  3. Ermöglicht die Verwendung dieses Modells als Ausführungskontext in den Korrelationsregeln.

Kontext - Automatisiertes Systemmodell


Zunächst beschreiben wir die Zusammensetzung des Lautsprechermodells. Wenn wir uns der klassischen Definition eines Begriffs aus GOST 34.003-90 zuwenden , dann ist ein AS „ein System, das aus Personal und einer Reihe von Automatisierungstools für seine Aktivitäten besteht und Informationstechnologie zur Ausführung etablierter Funktionen implementiert“. Es ist wichtig, dass bei der Implementierung der Informationstechnologie Personal (Benutzer) und Automatisierungstools mit Daten arbeiten.

Da SIEM Informationen aus vielen verschiedenen Quellen sammelt, einschließlich IT, Informationssicherheit und Geschäftsanwendungen, sind alle Teile dieser Definition für uns direkt in den Ereignissen „sichtbar“.

Als nächstes beschreiben wir, wie das Modell aussieht, das für solche Entitäten wie ein Benutzer erstellt wurde, eine Reihe von Automatisierungstools (im Folgenden als Netzwerk- und Computersysteme bezeichnet) und Daten.

Leider ist es ziemlich schwierig, technologische Prozesse im Rahmen von SIEM zu modellieren, da eine solche Klasse von Lösungen dafür nicht vorgesehen ist. Ein Teil der Prozesse ist jedoch durch die Verhaltensmodelle dieser Entitäten sichtbar.

Allgemeines lautsprechermodell

Allgemeines Lautsprechermodell

Weiter werden wir jede Entität betrachten und auf Folgendes eingehen:

  • eindeutige Identifikation;
  • die Zusammensetzung des Modells;
  • Finden von Daten, die für das Modell benötigt werden;
  • die Art der Änderung der Entitätsdaten;
  • Aktualisieren von Daten im Modell, wenn sie sich ändern.

Benutzermodell


Identifizierung


Ein Benutzer eines AS sollte als eine bestimmte Person verstanden werden: ein Mitarbeiter eines Unternehmens, eines Auftragnehmers oder eines Freiberuflers. Es ist wichtig, dass er den Zugriff auf die Lautsprecher autorisiert hat.

Informationen über AS-Benutzer sind normalerweise in vielen Systemen fragmentiert. Um es zusammenzubauen, müssen Sie sich anstrengen. Schauen wir uns ein Beispiel an, wo und welche Informationen für einen bestimmten Benutzer gesammelt werden können.

  1. Microsoft Active Directory und Microsoft Exchange. Von ihnen können wir seinen Haupt-Domain-Login und seine E-Mail-Adresse herausfinden.
  2. Die Cisco Identity Services Engine (ISE) speichert ihre zweite Anmeldung für den Remotezugriff über VPN.
  3. Die Datenbank des internen Portals speichert das dritte Login.
  4. Wenn der Benutzer ein Datenbankadministrator ist, wird die vierte Anmeldung im DBMS gespeichert und möglicherweise nicht eine.
  5. HR-Datenbank, in der sein vollständiger Name gespeichert ist (falls das Active Directory zu faul war, um den Benutzer gemäß allen Regeln zu erreichen).

Wenn das Unternehmen nicht über Identity Management- oder User Rights Management-Lösungen verfügt, die zumindest irgendwie dazu beitragen, diese unterschiedlichen Identifikationsinformationen zusammenzuführen, müssen Sie dies manuell in SIEM selbst tun.

Zusammenfassend:

  1. SIEM erfordert eine einzelne Benutzer-ID.
  2. Wenn Benutzerkonten in einem Protokoll oder einem System angezeigt werden, müssen wir es eindeutig identifizieren und unsere eigene eindeutige Benutzerkennung anbringen.

Modellzusammensetzung


Wenn wir ein Modell einer Entität zusammenstellen, teilen wir es in zwei Blöcke. Der erste Block dient zum Speichern allgemeiner Informationen über die Entität, der zweite zum Kompilieren des Verhaltensmodells der Entität. Dieses Profil kann von Korrelationsregeln verwendet werden, um abnormale Abweichungen im Verhalten einer Entität zu identifizieren.

Das allgemeine Benutzermodell sollte mindestens Folgendes enthalten:

  • Einzelbenutzer-ID in SIEM
  • alle seine Kennungen aus verschiedenen Systemen, einschließlich:
    • externe und interne E-Mail-Adressen;
    • Vollständiger Name;
    • Lokales Betriebssystemkonto
    • Domain-Konto;
    • VPN-Konto
    • Proxy-Konto
    • DBMS-Konten
    • Konten in anderen Anwendungssystemen.
  • Organisationseinheit in Microsoft Active Directory, der der Benutzer angehört;
  • Microsoft Active Directory-Gruppen, denen der Benutzer angehört.

Das Verhaltensmodell eines Benutzers sollte mindestens Folgendes umfassen:

  • Art der verwendeten Verbindung (lokal, entfernt) und Art des Kommunikationskanals (verkabelt, drahtlos);
  • Geräte für den Zugriff auf das Unternehmensnetzwerk;
  • gebrauchte Anwendungen;
  • Geobindung, insbesondere für Remotebenutzer;
  • Unternehmensressourcen, mit denen sich der Benutzer verbindet;
  • an wen und welche Daten übertragen (Informationsflüsse).


Benutzermodell

Benutzermodell

Die Profilerstellung von Informationsflüssen ist eine schwierige Aufgabe, für die es SIEM häufig an bequemen und einfachen Mechanismen mangelt. Das Erstellen eines solchen Profils kann jedoch mit der Verwendung von E-Mail und gemeinsam genutzten Netzwerkressourcen beginnen.

Datenquellen für das Modell


Woher erhalten Sie die Daten, die zum Erstellen des Modells benötigt werden? Berücksichtigen Sie die beiden Hauptprinzipien für den Erhalt von Informationen, die in den meisten SIEMs verfügbar sind - aktive und passive Erhebungsmethoden.

Mit der aktiven Methode greift SIEM selbst auf Quellen zurück, die die zum Erstellen des Modells erforderlichen Daten enthalten.
Bei der passiven Methode wird das Modell basierend auf Daten von Ereignissen gefüllt, die in SIEM aus Quellen empfangen wurden.

In der Regel ist es besser, zwei Methoden zu kombinieren, um das vollständigste Modell zu erhalten.

Es ist wichtig zu verstehen, dass die im Rahmen des Modells gesammelten Daten ständig aktualisiert und im automatischen statt im manuellen Modus durchgeführt werden müssen. Für die Aktualisierung der Daten eignen sich genau dieselben Methoden, die für die erstmalige Erfassung verwendet werden.

Überlegen Sie, welche Quellen Daten für die Erstellung des Modells bereitstellen können und auf welche Weise Sie die erforderlichen Informationen daraus erhalten können.

Für allgemeines Modell


Für ein Verhaltensmodell


Modell für Netzwerk- und Computersysteme


Identifizierung


Mit Elementen von Netzwerk- und Computersystemen sind Workstations, Server- und Netzwerkgeräte sowie Tools für die Informationssicherheit gemeint. Derzeit werden sie in SIEM- und Vulnerability Management-Lösungen als Assets bezeichnet.

Es scheint ziemlich offensichtlich zu sein, dass solche Assets leicht durch IP-Adresse, MAC-Adresse, FQDN oder Hostnamen (im Folgenden als die ursprünglichen Identifikationsschlüssel bezeichnet) identifiziert werden können. Ist das immer so? Wie oben angegeben, finden in der AU ständig einige Änderungen statt. Sehen wir uns einige dieser Änderungen an und überlegen, wie sich unsere ursprünglichen Identifikationsschlüssel verhalten.

  1. Verwendung in einem DHCP-Netzwerk. Die IP-Adressen von Assets ändern sich.
  2. Knoten in einer Clusterkonfiguration wechseln. Je nach Art des Clusters können sich MAC und IP ändern.
  3. Wiederherstellen eines Systems von einer Sicherung auf einem anderen Server aufgrund eines kritischen Fehlers. MAC-Adressen ändern sich, manchmal IP, FQDN und Hostname.
  4. Geplanter Austausch, Modernisierung von Geräten oder Teilen von Lautsprechern. Fast alle Tasten können sich ändern.

In einem kleinen Unternehmen können diese Änderungen äußerst selten sein und von den für SIEM zuständigen Experten durchgeführt werden. Was aber, wenn ein Unternehmen mit einem breiten Filialnetz? Und bei weitem nicht immer verfügt der IS-Dienst über eine gut etablierte Kommunikation mit dem IT-Dienst, was bedeutet, dass der SIEM-Experte möglicherweise nicht die erforderlichen Informationen über Änderungen im AS erhält.

Da Sie sich nicht separat auf IP, MAC, FQDN oder Hostname verlassen können, um ein Asset zu identifizieren, können Sie versuchen, das Asset sofort anhand aller 4 Parameter zu identifizieren. Hier stehen wir vor einem globalen Problem: SIEM bearbeitet Ereignisse und enthält fast nie alle Originalidentifikationsschlüssel gleichzeitig.

Wie kann es gelöst werden? Schauen wir uns einige Optionen an:

  1. Aktive Methode mit Lösungen der CMDB-Ebene (Configuration Management Database) . Informationen zu den Original-Identifikationsschlüsseln können von dort abgerufen werden. Aber enthält die CMDB alle Quellschlüssel der zur Identifizierung erforderlichen Assets? Und berücksichtigt es vor allem die oben beschriebenen Änderungen bei den Lautsprechern? Es ist auch wichtig, den Zeitpunkt der Aktualisierung von Daten in CMDB zu berücksichtigen, wenn die Daten Dutzende von Minuten oder Stunden hinter dem tatsächlichen Zustand des AS zurückbleiben. Diese Lösung ist höchstwahrscheinlich nicht für die Stream-Korrelation von Ereignissen in SIEM geeignet.
  2. Aktiver Weg mit Vulnerability Management-Lösung . Sie können die Berichte in SIEM hochladen, z. B. Micro Focus ArcSight. Aber gibt es eine Garantie dafür, dass ein Scanner eines Drittanbieters alle zur Identifizierung erforderlichen Daten liefert? Wie relevant werden sie sein, wenn Scans nicht öfter als einmal im Monat durchgeführt werden (Durchschnitt für große Unternehmen) und weit davon entfernt sind, die gesamte Infrastruktur abzudecken.
  3. Passiver Weg . Identifizieren Sie Assets aus Ereignissen trotz unvollständiger und ungenauer Daten. Ereignisse enthalten nicht alle Schlüssel, verschiedene Quellen senden unterschiedliche Schlüsselsätze. Dies ist jedoch der schnellste Weg, um Informationen über Änderungen an den Lautsprechern zu erhalten. Quellen erzeugen in der Regel Ereignisse in allen oben beschriebenen Situationen, mit Ausnahme des geplanten Austauschs von Geräten.
  4. Hybrider Weg . Nutzen Sie alle Ansätze gleichzeitig:
    • Die aktive Erfassung mit CMDB ermöglicht eine schnelle anfängliche Befüllung der SIEM-Assets.
    • Durch die Integration in das Vulnerability Management werden die fehlenden Informationen hinzugefügt.
    • Durch eine Analyse der Ereignisse können Sie das Modell schnell aktualisieren und dabei die Besonderheiten jeder Quelle einzeln berücksichtigen.

    Mit der Hybridmethode können Sie die Probleme der anderen ausgleichen, die Implementierung ist jedoch schwierig.

Im Moment habe ich nur mit zwei Lösungen gearbeitet, bei denen die Hersteller über das Fachwissen verfügten, um diesen Ansatz zu implementieren - IBM QRadar (allgemeine Beschreibung anhand der Referenz , Algorithmusdetails sind geschlossen) und Positive Technologies MaxPatrol SIEM (Algorithmusdetails sind geschlossen). Derzeit nutzen und verbessern beide Unternehmen weiterhin genau den Hybridansatz.

Also:

  1. Workstations, Netzwerk- und Servergeräte müssen auf hybride Weise identifiziert werden, wobei Daten aus CMDB, Vulnerability Management-Systemen und Ereignisse aus den Quellen selbst aggregiert werden.
  2. Für die korrekte Kombination und Aktualisierung der zur Identifizierung gesammelten Informationen sind Expertenmechanismen erforderlich, die die Merkmale jeder Quelle berücksichtigen.

Modellzusammensetzung


Computersysteme, einschließlich der darauf installierten System- und Anwendungssoftware, enthalten viele Informationen, die zur Verbesserung der Genauigkeit der Korrelationsregeln erforderlich sind.

Genau wie das Benutzermodell besteht das Modell von Netzwerk- und Computersystemen aus einem gemeinsamen und verhaltensbezogenen Teil.

Die Zusammensetzung des allgemeinen Modells von Netzwerk- und Computersystemen sollte mindestens Folgendes umfassen:

  • Hardware (einschließlich externer Geräte);
  • abgewickelte Benutzer;
  • installierte Dienste und deren Bündel mit offenen Ports;
  • installierte Software und deren Version;
  • installierte Updates;
  • bestehende Schwachstellen;
  • geplante Aufgaben
  • Liste der Software für den Start;
  • Routing-Tabellen;
  • gemeinsam genutzte Netzwerkressourcen.

Die Zusammensetzung des Verhaltensmodells von Netzwerk- und Computersystemen sollte mindestens Folgendes umfassen:

  • Netzwerkinteraktionen von L3 und L4 (mit welchen Interaktionen und nach welchen Protokollen);
  • Die durchschnittliche Datenmenge, die pro Woche übertragen wird.
  • welche Benutzer verwenden;
  • von welchen Knoten aus die Fernsteuerung implementiert wird;
  • Statistiken über den Betrieb von Sicherheitsfunktionen für diesen Host (Netzwerk und lokal).

Modell für Netzwerk- und Computersysteme
Modell für Netzwerk- und Computersysteme

Datenquellen für das Modell


Die Informationserfassung für dieses Modell ist auf zwei Arten möglich: aktiv und passiv.

Betrachten Sie das allgemeine Modell:

Für allgemeines Modell


Für ein Verhaltensmodell


Geschütztes Datenmodell


Identifizierung


Fahren wir mit der letzten Komponente des Kontexts fort - dem geschützten Datenmodell.

In den meisten Fällen wird SIEM nicht zur Überwachung geschützter Daten verwendet, da es hierfür Lösungen für die DLP-Klasse (Data Leak Prevention) gibt. Dieses Wissen hilft jedoch, die Bedeutung des Vorfalls genauer einzuschätzen. Wenn Sie beispielsweise eine Korrelationsregel schreiben, ist es hilfreich zu wissen, dass der Vorfall nicht nur an einer Arbeitsstation auftritt, sondern auch an der Station, an der derzeit der Finanzbericht für das Jahr oder andere vertrauliche Informationen gespeichert sind.

Die Identifizierung vertraulicher Informationen wird von einer Fingerabdrucksuchmaschine in der DLP-Lösung selbst implementiert. Die Spezifität des Mechanismus erlaubt es nicht, ihn innerhalb von SIEM zu implementieren. In Bezug auf die Identifizierung geschützter Daten ist es daher möglich, nur eine enge Integration mit Lösungen der DLP-Klasse zu verwenden.

Modellzusammensetzung


Aufgrund der Tatsache, dass DLP den größten Teil der Überwachung und des Schutzes vertraulicher Informationen implementiert, ist die Zusammensetzung des Modells in SIEM recht kompakt.

Das allgemeine Modell geschützter Daten sollte mindestens Folgendes enthalten:

  • Auf welchen Assets werden vertrauliche Informationen gespeichert?
  • welche Benutzer Zugriff auf vertrauliche Informationen haben.

Das Verhaltensmodell geschützter Daten sollte mindestens Folgendes enthalten:

  • zwischen welchen Vermögenswerten werden vertrauliche Informationen übertragen;
  • zwischen denen Benutzer vertrauliche Informationen übertragen werden.


Geschütztes Datenmodell

Geschütztes Datenmodell

Datenquellen für das Modell


Um ein Modell geschützter Daten zu erstellen, stehen zwei Methoden zum Abrufen von Informationen zur Verfügung - aktiv und passiv.

Betrachten Sie das allgemeine Modell:

Für allgemeines Modell


Für ein Verhaltensmodell


Modellimplementierungsmechanismen in SIEM


Mal sehen, wie es möglich ist, ein Lautsprechermodell in SIEM zu implementieren. Dazu müssen auf SIEM-Ebene zwei Hauptprobleme angegangen werden:

  1. So implementieren Sie die aktive und passive Datenerfassung.
  2. Wo und in welcher Form soll das Modell aufbewahrt werden?

Die aktive Datenerfassung für das Modell erfolgt in der Regel über SIEM-Integrationsmechanismen mit Sicherheitsscannern. Die aktive Erfassung kann auch durch Herunterladen von Daten aus externen Quellen, z. B. Datenbanken, erfolgen.

Die passive Erfassung erfolgt durch Analyse von Ereignissen, die das SIEM durchlaufen.

In der Regel werden in SIEM der aktuellen Generation zum Speichern der obigen Modelldaten die Tabellenlisten / Aktive Liste / Referenzsatzmenge und dergleichen verwendet. Bei aktiver Datenerfassung werden geplante Aufgaben erstellt, um sie aus externen Quellen auszufüllen. Bei der passiven Erfassung werden separate Korrelationsregeln erstellt, innerhalb derer die Daten des Ereignisses in die Tabellenliste eingefügt werden, wenn die erforderlichen Ereignisse auftreten (Benutzererstellung, Entfernen der Software, Dateiübertragung usw.).

Im allgemeinen Fall enthalten alle modernen SIEM-Lösungen alle notwendigen Elemente zum Erstellen und Füllen der Daten des beschriebenen AC-Modells.

Die Historizität des Modells


Die AS ändert sich ständig. Es ist wichtig zu berücksichtigen, wenn nicht in den Korrelationsregeln selbst, da sie nahezu in Echtzeit arbeiten und mit dem aktuellen Status der AS arbeiten, dann bei der Untersuchung eines Vorfalls. Minuten, Stunden und manchmal Monate können vom Beginn eines Vorfalls bis zu seiner Untersuchung vergehen. Bei einigen Angriffen können zwischen der Einführung eines Angreifers in das System und der SIEM-Erkennung seiner Aktivitäten bis zu 6 Monate vergehen ( Kosten einer Datenverletzungsstudie von Ponemon für 2018 ). Während dieser Zeit kann sich die Landschaft des Systems dramatisch ändern: Benutzer werden hinzugefügt und entfernt, die Gerätekonfiguration wurde geändert, die für die Untersuchung des Vorfalls wichtigen Geräte wurden außer Betrieb gesetzt und die vom Angreifer von einem Host kopierten Daten wurden auf einen anderen übertragen. Daher ist es während der Untersuchung wichtig, das Systemmodell in dem Zustand zu betrachten, in dem es sich zum Zeitpunkt des Vorfalls befand, und nicht in dem aktuellen Zustand, als wir gerade mit der Untersuchung begonnen haben.

: , SIEM, , .

Modellwechsel im Laufe der Zeit




Schlussfolgerungen


:

  1. , , .
  2. .
  3. SIEM .
  4. :
    • ;
    • , ;
    • .
  5. , , :
    • ;
    • .
  6. , . .
  7. .
  8. , , , .
  9. SIEM .



:

SIEM: « ». 1: ?

SIEM: « ». 2. «»

SIEM: « ». 3.1.

SIEM: « ». 3.2.

SIEM: « ». 4. ( )

SIEM: « ». 5.

Source: https://habr.com/ru/post/de441098/


All Articles