Dies ist der zweite Artikel in der Reihe, der sich mit der Methodik zum Erstellen von sofort einsatzbereiten Korrelationsregeln für SIEM-Systeme befasst. Im vorherigen Artikel haben wir uns diese Aufgabe gestellt, die Vorteile beschrieben, die sich aus der Implementierung ergeben, und die Hauptprobleme aufgelistet, die uns im Weg stehen. In diesem Artikel werden wir nach Lösungen suchen und mit dem Problem der Transformation des Modells der „Welt“ sowie seiner Manifestation im Stadium der Normalisierung von Ereignissen beginnen.



Das Problem der Transformation des Weltmodells wurde im ersten Artikel beschrieben. Erinnern wir uns kurz an sein Wesen: Wenn ein Phänomen an der Quelle von Ereignissen auftritt (z. B. beim Starten eines Prozesses im Betriebssystem), wird es in verschiedenen Formaten festgelegt, zuerst im Speicher, dann im Ereignisprotokoll des Betriebssystems und dann im SIEM-System. Jede Verarbeitungsstufe geht mit Datenverlust einher, da es auf Betriebssystemebene ein "Welt" -Modell gibt und im Betriebssystemprotokoll ein anderes, das durch eine Reihe von Feldern begrenzt ist, durch das Protokollschema. Somit gibt es eine Reflexion (Transformation) eines Modells mit einer großen Anzahl von Parametern zu einem anderen, mit einer kleineren Anzahl von Parametern. Das Normalisieren und Speichern eines Ereignisses in SIEM ist eine weitere Transformation, die auch bei Datenverlust auftritt, da SIEM auch über ein eigenes "Welt" -Modell verfügt.

Es ist schwierig, einen Weg zu finden, der die Transformation eines Modells in ein anderes ohne Verlust ermöglicht. In Kenntnis dieser Einschränkung ist es notwendig, einen solchen Ansatz zur Normalisierung und die Bildung einer Liste von Feldern des Ereignisschemas zu formulieren, in denen keine Informationen verloren gehen würden, was für die Korrelation und weitere Untersuchung von Vorfällen im Bereich der Informationssicherheit wichtig ist.

Im Rahmen von SIEM wird ein Modell durch ein Schema dargestellt - eine Reihe von Feldern, in die Daten aus dem Anfangsereignis in den Normalisierungsprozess passen. In Zukunft wird es von Spezialisten zur Erstellung von Korrelationsregeln verwendet. Damit Vorfallermittler und diejenigen, die für die Entwicklung von Korrelationsregeln verantwortlich sind, normalisierte Ereignisse eindeutig interpretieren, muss das Schema die grundlegenden Eigenschaften erfüllen:

• für Ereignisse jeglicher Art und Quellen einheitlich sein;
• Beschreiben Sie klar, wer mit wem und wie interagiert hat.
• Behalten Sie die Essenz und den Kontext der Interaktion.

Bei der Entwicklung von Normalisierungsregeln müssen Informationen über die Interaktion im Anfangsereignis gefunden und in speziell festgelegte Felder zerlegt werden. Dasselbe muss mit dem Kontext und der Essenz der Interaktion gemacht werden (mehr dazu im nächsten Artikel).

Es stellt sich die Frage: Ist es möglich, typische Schemata für Interaktionen zu identifizieren, die alle von allen möglichen IT- und Informationssicherheitsquellen verursachten Ereignisse erfüllen? Wenn ja, wie sehen diese Schemata aus?

Um die Antwort auf diese Fragen zu finden, müssen Sie sich an die Analyse wenden und versuchen, so viele Normalisierungsregeln wie möglich zu analysieren, die bereits in SIEM-Lösungen entwickelt wurden und funktionieren, um gemeinsame Muster zu identifizieren. Im Rahmen dieser Arbeiten konnten mehr als 3.000 Normalisierungsregeln aus mehr als 100 verschiedenen Quellen aus Lösungen wie MaxPatrol SIEM von Positive Technologies und Micro Focus ArcSight analysiert werden. Die Analyse ergab folgende Schlussfolgerungen:

1. Es gibt typische Interaktionsschemata.
2. In jedem einzelnen Ereignis gibt es in der Regel Informationen zur Interaktion auf Netzwerkebene und auf Anwendungsebene .
3. Typische Interaktionsmuster können auf verschiedenen Ebenen variieren, und dies muss berücksichtigt werden.

Kommunikationsschemata auf Netzwerk- und Anwendungsschicht

Wir beschreiben typische Schemata für jede Ebene. Zuvor müssen Sie die Entitäten hervorheben, die in Ereignissen immer vorhanden sind. Auf dieser Grundlage werden außerdem Interaktionsschemata erstellt. Dazu gehören:

• Betreff . Eine Entität, die ein Objekt betrifft. Beispiel: Ein Benutzer, der einen Registrierungsschlüssel ändert, oder ein Host mit IP 10.0.0.1, der ein Paket an einen Host mit IP 20.0.0.1 sendet.
• Objekt . Die vom Betreff betroffene Entität.
• Quelle In der Regel ein Host, der die Interaktion des Subjekts mit dem Objekt registriert und das Ereignis selbst generiert. Die Quelle ist beispielsweise eine Firewall, die die Übertragung von Paketen vom Host - dem Betreff mit IP 10.0.0.1 - zum Host - dem Objekt mit IP 20.0.0.1 - aufzeichnet.
• Sender Es gibt Fälle, in denen SIEM Ereignisse nicht direkt von der Quelle empfängt, sondern von einem Zwischenserver, über den diese Ereignisse übertragen werden. Das einfachste Beispiel ist ein Zwischen-Syslog-Server. Ein Beispiel ist komplizierter - wenn der Sender ein Verwaltungsserver sein kann, z. B. Kaspersky Security Center. In diesem Fall ist die Quelle ein spezifischer Agent von Kaspersky Endpoint Security.

Es können jedoch nicht alle Entitäten gleichzeitig in der Veranstaltung vertreten sein (dazu später mehr). Daher ist es wichtig, zunächst Vereinbarungen zu treffen, da in diesem Fall die entsprechenden Felder des Schemas ausgefüllt sind. Dies wird in Zukunft helfen, klar zwischen Fällen zu unterscheiden, in denen diese Felder aufgrund eines Fehlers eines Spezialisten, der Normalisierungsregeln entwickelt, nicht ausgefüllt wurden, aus Fällen, in denen das ursprüngliche Ereignis keine Daten über eine Entität enthielt.

Kommen wir zu Interaktionsmustern und Ereignisbeispielen. Aus Gründen der Übersichtlichkeit werden alle Beispiele auf der Grundlage von Dateiprotokollen, Syslog-Nachrichten oder Datensätzen in einer relationalen Datenbank angegeben. Sie können jedoch auch für andere Protokollformate verwendet werden, z. B. binär.

Netzwerkebene

Die primäre Kennung für Entitäten auf Netzwerkebene sind IP-Adressen. Es ist wichtig zu verstehen, dass es möglicherweise andere verwandte Kennungen gibt - MAC-Adressen auf Kanalebene, FQDN - auf Anwendungsebene. Es stellt sich die Frage: Sprechen sie über dieselbe oder eine andere Entität? Können sich diese Bezeichner im Laufe der Zeit mit derselben Entität ändern? Ein separater Artikel wird diesem Thema gewidmet sein. Lassen Sie uns nun auf die Tatsache eingehen, dass die Hauptkennung für Interaktionsmodelle auf Netzwerkebene die IP-Adresse ist.

Die typischen Interaktionsschemata dieser Ebene können also in zwei Klassen unterteilt werden - grundlegend und entartet.

Grundlegende Interaktionsschemata

Schema 1. Vollständiges Interaktionsschema

Im Rahmen dieses Modells können für den Fall, der am SIEM-Eingang empfangen wird, alle Hauptentitäten unterschieden werden: Subjekt, Objekt, Quelle, Sender. Im Interaktionsschema wirkt das Subjekt auf das Objekt. Dieser Effekt registriert (beobachtet) die Quelle und erzeugt ein Ereignis. Das Ereignis von der Quelle tritt in den Sender und von dort in das SIEM ein.

Das folgende Ereignis erfasst die Auflösung der Netzwerkinteraktion zwischen Hosts durch die Stonesoft-Firewall (jetzt Forcepoint), während das Ereignis selbst nicht direkt in SIEM eingeht, sondern von einem zwischengeschalteten Syslog-Server.



Hier:
40.0.0.1 - Sender (Zwischen-Syslog-Server),
30.0.0.1 - Quelle (Firewall-Knoten),
10.0.0.1 - Betreff (Senden von UDP-Paketen),
20.0.0.1 - Ein Objekt (Empfang von UDP-Paketen).


Diagramm 2: Direktes Erfassungsdiagramm ohne Sender

Nicht immer im Interaktionsschema ist ein Sender. In der Regel ist es vorhanden, wenn ein Zwischenserver (z. B. ein Syslog-Server) zum Übertragen von Ereignissen verwendet wird oder wenn die Lösung, von der Ereignisse erfasst werden, über ein zentrales Verwaltungssystem verfügt, z. B. Kaspersky Security Center, Check Point Smart Console oder Cisco Prime. Bei diesem Schema fallen Ereignisse direkt von der Quelle in SIEM. Am allermeisten werden Ereignisse durch dieses spezielle Schema beschrieben. Ein Beispiel für ein solches Ereignis ist übrigens in Abbildung 1 zu sehen, wenn kein Zwischen-Syslog-Server vorhanden war und wir Ereignisse direkt von der Firewall erhalten haben.



Hier:
30.0.0.1 - Quelle (Firewall-Knoten),
10.0.0.1 - Betreff (Senden von UDP-Paketen),
20.0.0.1 - Ein Objekt (Empfang von UDP-Paketen).


Schema 3. Interaktion mit vielen Objekten

Dieses Interaktionsschema auf Netzwerkebene ist ziemlich selten und in der Regel typisch für Ereignisse von Netzwerkgeräten. In dem Schema interagiert ein Subjekt mit vielen Objekten. Eine ähnliche Interaktion ist bei Ereignissen vorhanden, die Multicast-, Unicast- oder Broadcast-Broadcasts beschreiben.

Beachten Sie, dass manchmal viele Objekte durch eine gemeinsame Kennung verbunden werden können - eine Subnetzadresse oder eine Broadcast-Adresse. Dies sollte beachtet werden, da Sie bei der Analyse von Ereignissen, auch auf der Ebene der Korrelationsregeln, die potenziell wichtige Interaktion leicht überspringen können, da in einem solchen Schema die Objektadresse hinter der Gruppenadresse verborgen ist.

Das folgende Beispiel zeigt ein Ereignis von einem IGMP-Relay-Server, über das eine Multicast-Mitgliedschaftsanforderung gesendet wird.



Hier:
30.0.0.1 - Quelle (IGMP-Relay-Server),
10.0.0.1 - Betreff (Antrag auf Mitgliedschaft in einer Gruppe),
224.0.0.252 - Das Objekt (Multicast-Adresse).

Entartete Systeme

Subjekt, Objekt und Quelle sind die grundlegenden Entitäten in der Gruppe der grundlegenden Interaktionsschemata. Es gibt jedoch Fälle, in denen eine der Entitäten in diesem Fall abwesend sein kann.


Schema 4. Interaktion ohne Objekt

Oft ist ein solches Muster typisch in Situationen, in denen das Subjekt eine Änderung seines inneren Zustands meldet - das heißt, es handelt gleichzeitig in der Rolle des Subjekts und des Objekts. Diese Interaktion kann beispielsweise bei Konfigurationsänderungen oder Malware-Erkennungsereignissen auf der Workstation beobachtet werden. Diese Informationen werden jedoch nicht vom Subjekt selbst aufgezeichnet, sondern von einem zentralen Managementsystem und in seinem Tagebuch gespeichert.

Das Beispiel zeigt, wie der Symantec Management Server erfasst, dass der von ihm verwaltete Symantec Endpoint Protection-Agent eine schädliche Datei auf seinem Host erkannt hat.



Hier:
30.0.0.1 - Quelle (Symantec Management Server),
10.0.0.1 - Betreff (Symantec Endpoint Protection Agent).


Schema 5. Kombination der Rolle des Subjekts und des Objekts in der Quelle

Das letzte entartete Interaktionsschema ist typisch für eine Situation, in der SIEM Ereignisse von einer Quelle empfängt, die eine Änderung ihres internen Status melden: z. B. Neukonfiguration eines Geräts oder einer Software, Aktivieren oder Deaktivieren eines Netzwerkports. In einem solchen Schema stimmt die Rolle der Quelle mit der Rolle des Subjekts und des Objekts überein. Im Gegensatz zum vorherigen Schema treten hier Ereignisse in SIEM direkt auf.

In diesem Beispiel meldet ein Cisco IOS-basierter Switch, dass seine Schnittstelle in den UP-Status übergegangen ist.



Hier ist 30.0.0.1 die Quelle (Schalter).

Anwendungsebene

Auf dieser Ebene gibt es Interaktionen bereits bekannter Entitäten: Subjekt, Objekt. Alle Informationen über die Quelle und den Sender verbleiben jedoch direkt auf Netzwerkebene und werden auf Anwendungsebene nicht wiedergegeben.

Die meisten Arten von Ereignissen beinhalten Interaktionen gleichzeitig auf Netzwerkebene und Anwendungsebene. Wir stellen jedoch fest, dass Ereignisse, die direkt von der Anwendungssoftware generiert werden, z. B. 1C: Enterprise, Microsoft SQL Server oder Oracle Database, ausschließlich Interaktionen auf Anwendungsebene enthalten können.

Darüber hinaus wird auf Anwendungsebene eine zusätzliche Ressourcenentität angezeigt.

Eine Ressource ist eine Zwischeneinheit, durch die das Subjekt ohne direkte Interaktion Einfluss auf das Objekt ausübt. Zum Beispiel, indem Sie Alex die Rechte gewähren, Bob auf die MyFile zuzugreifen. Hier ist Alex das Subjekt, Bob ist das Objekt, MyFile ist die Ressource. Bitte beachten Sie, dass Alex in diesem Beispiel nicht direkt mit Bob interagiert.

Wichtig : Ereignisse auf Anwendungsebene können sowohl zusätzliche Parameter des Betreffs und des Objekts als auch die Ressource selbst enthalten. Zusätzliche Parameter einer solchen Ressource wie einer „Datei“ können beispielsweise das Verzeichnis sein, in dem sie sich befindet, oder ihre Größe.
In diesem Fall werden Betreff, Objekt und Ressource anhand des Namens oder der eindeutigen Kennung identifiziert: E-Mail-Adresse, Dateiname, Verzeichnisname, Tabellenname in der Datenbank.

Berücksichtigen Sie zusätzliche Interaktionsmuster, die für die Anwendungsebene spezifisch sind.


Abbildung 6. Ressourceninteraktion

In diesem Diagramm wirkt das Subjekt indirekt über eine Zwischenressource auf das Objekt. Ereignisse mit einem solchen Schema sind in der Regel in den Datenbanküberwachungsprotokollen oder bei der Arbeit mit Zugriffsrechten auf Dateien und Verzeichnisse auf Betriebssystemebene deutlich sichtbar.

Das Beispiel zeigt einen Eintrag aus der Überwachungsdatenbank der Oracle-Datenbank. Es behebt den Vorgang des Widerrufs einer Rolle von einem Benutzer.



Hier:
"ALEX" - Betreff (Benutzername, der die Rolle zurückzieht),
"BOB" - Objekt (Name des Benutzers, der widerrufen wird),
"ROLLE" - Ressource (Name der widerrufenen Rolle).


Abbildung 7. Interaktion mit vielen Ressourcen

Sowohl auf Anwendungsebene als auch auf Netzwerkebene gibt es solche Arten von Ereignissen, bei denen der Betreff über viele Ressourcen sofort mit dem Objekt interagiert. Es ist sehr selten, aber es gibt Zeiten, in denen die Anzahl der Objekte auch mehr als eins beträgt. Diese Arten von Ereignissen werden beim Korrigieren von Massenvorgängen angezeigt. Sie können beispielsweise einem Benutzer Zugriff auf mehrere Dateien gewähren oder die in der Richtlinie enthaltenen Regeln ändern.

In diesem Beispiel erfasst die Lösung zum Schutz virtueller Umgebungen vGate Security Code das Hinzufügen neuer Richtlinien zum Satz.



Hier:
"Admin @ VGATE" - Betreff (Name des Benutzers, der die Richtlinien ändert)
"Basis" - Objekt (Richtliniensatz)
"Installieren und Aufrechterhalten der Integrität des Dateisystems", "Überprüfen der Einstellungen des SNMP-Agenten", "Deaktivieren der automatischen Installation von VMware Tools" - Ressourcen (Namen der hinzugefügten Richtlinien)

Das Modell des Interaktionskanals zwischen Subjekt und Objekt

Bei allen Schemata haben wir verschiedene Entitäten (Subjekte, Objekte, Ressourcen, Quellen, Sender) unterschieden und den sogenannten Interaktionskanal zwischen ihnen festgestellt. Lassen Sie uns näher auf die vorletzte Komponente des großen „Weltmodells“ eingehen, mit dem SIEM arbeiten muss - auf die Modelle des Interaktionskanals zwischen Subjekt und Objekt. Denken Sie daran, dass die letzte Komponente der Kontext der Interaktion ist (der nächste Artikel wird diesem Thema gewidmet sein).

Es gibt also zwei Entitäten, die miteinander interagieren. Im Rahmen dieser Interaktion werden Daten von einer Entität zu einer anderen übertragen. Dies können Netzwerkpakete mit Daten, Dateien oder Verwaltungsbefehlen sein. In diesem Fall kann der gebildete Kanal in Form einer "Pipe" dargestellt werden, entlang derer ein gerichteter Daten- und Befehlsfluss stattfindet. Ein solches Modell ist auf Netzwerkebene deutlich sichtbar, auf Anwendungsebene jedoch weniger ausgeprägt (siehe Beispiel ).


Datenkanalmodell

Basierend auf einem solchen Modell kann jedes Ereignis, das das SIEM empfängt, Informationen enthalten, die Folgendes beschreiben:

• Die Parameter des Kanals selbst sind die "Pipe",
• Die über diese „Pipe“ übertragenen Daten.

Typischerweise wird ein Kanal durch Parameter wie Sitzungskennung, Datenübertragungsprotokoll, Kanalaufbauzeit, Abschlusszeit, Dauer beschrieben. Daten in Ereignissen sind durch das von den Verschlüsselungsalgorithmen verwendete Format, die Anzahl der übertragenen Pakete und die Anzahl der übertragenen Bytes gekennzeichnet.

Stellen Sie sich ein Beispiel für ein Ereignis vor, das Daten zum Interaktionskanal enthält. Hier ist ein Ereignis der Cisco Identity Services Engine (ISE), eines Prozessmanagementsystems zum Identifizieren und Steuern des Zugriffs, das die Netzwerksitzung eines Benutzers als Teil des Abrechnungsverfahrens (Abrechnung) aufzeichnet.




Hier:
"Acct-Session-Id = 1A346216", "Acct-Session-Time = 50", "Service-Type = Framed", "Framed-Protocol = PPP" - Kommunikationskanalparameter,
"Acct-Input-Octets = 43525", "Acct-Output-Octets = 122215", "Acct-Input-Packets = 234", "Acct-Output-Packets = 466" - Parameter der über den Kanal übertragenen Daten.

Ein Beispiel für Modelle der Interaktion von Entitäten und Kanal in einem Ereignis

Daher untersuchten wir die Interaktionsschemata von Netzwerkebenen und -anwendungen sowie das Modell des Interaktionskanals. Als nächstes zeigen wir ein Beispiel dafür, wie in einem Fall die Interaktionsschemata verschiedener Ebenen kombiniert und Informationen über das Kanalmodell verwendet werden.

Hier sehen wir ein Ereignis von der Firewall - die Cisco Adaptive Security Appliance (ASA), bei der eine ausgehende TCP-Verbindung behoben ist.



Das Beispiel zeigt deutlich, dass es innerhalb eines Ereignisses Entitäten auf Netzwerkebene und auf Anwendungsebene gibt. Auf Netzwerkebene ein Interaktionsschema zwischen Subjekt und Objekt, das von der Quelle festgelegt wird. Es gibt keinen Sender.

Hier:
30.0.0.1 - Quelle (Cisco ASA),
10.0.0.1 - Betreff (die Adresse desjenigen, der die Verbindung herstellt),
20.0.0.1 - Ein Objekt (die Adresse des Objekts, mit dem sie verbunden sind).

Auf Anwendungsebene ein einfaches Schema, in dem nur das Subjekt und das Objekt vorhanden sind:
"ALEX" - Betreff (Benutzername, der verbindet),
"BOB" - Das Objekt (der Name des Benutzers, mit dem er eine Verbindung herstellt).

Auch in diesem Fall gibt es eine Beschreibung des Datenübertragungskanals, aber keine Beschreibung der Daten selbst:
"TCP" ist das Protokoll, auf dessen Grundlage der Kanal erstellt wurde.
"136247" ist die Kanalsitzungskennung .

Schlussfolgerungen

Wie können die von uns hervorgehobenen typischen Interaktionsschemata helfen?

• Erstens sollte ein Experte beim Schreiben von Korrelationsregeln und beim Analysieren von Ereignissen verstehen, welche Entitäten in jedem Ereignis vorhanden sind, das bei SIEM eintrifft. Dazu ist es im Stadium der Normalisierung von Ereignissen erforderlich, die Entitäten klar zu unterscheiden: Subjekt, Objekt, Ressource, Quelle und Sender.
• Zweitens ist es bei der Normalisierung wichtig zu berücksichtigen, dass das Ereignis Informationen sowohl über die Interaktion der Netzwerkebene als auch der Anwendungsebene enthält. Diese beiden Wechselwirkungen können gleichzeitig in einem Ereignis vorhanden sein.
• Drittens ist die Wechselwirkung selbst eine zusammengesetzte Struktur, in der Informationen über den gebildeten Kanal und über die über diesen Kanal übertragenen Daten vorliegen.

Daher sollte das Modell der „Welt“, das in SIEM erstellt und durch eine Reihe von Feldern (ein Schema) dargestellt wird, Abschnitte zur Beschreibung enthalten:

1. Auf Netzwerkebene :
   
   • Betreff;
   • Das Objekt;
   • Quelle;
   • Sender
   • Kanal der Interaktion;
   • Über den Kanal übertragene Daten.
   
   
2. Auf Anwendungsebene :
   
   • Betreff;
   • Ein Objekt oder eine Vielzahl von Objekten;
   • Eine Ressource oder mehrere Ressourcen.
   
   

Für jede Entität muss eine Reihe von Eigenschaften definiert werden, die sie eindeutig identifizieren. Auf Netzwerkebene werden Entitäten durch IP, MAC oder FQDN identifiziert. Auf Anwendungsebene nach Name oder ID. Das Schema muss über dedizierte Felder zum Speichern dieser Bezeichner verfügen.

Es gibt entartete Interaktionsschemata, in denen eine Entität mehrere Rollen gleichzeitig kombinieren kann. Bei der Normalisierung solcher Ereignisse muss die Regel zum Ausfüllen aller Felder des Schemas, die für die gesamte Gruppe von Entitäten verantwortlich sind, explizit definiert werden. In Zukunft wird dies den Korrelationsregeln helfen, einen Teil der Interaktionen nicht zu verpassen.

Lassen Sie uns erklären: Nehmen wir den Fall, die Rolle des Subjekts und des Objekts in der Quelle zu kombinieren. , , , , .

, . , .

, , :


,

— «» SIEM , . , , Alex , — , , , . , . , - , , SIEM .

, , . , , .

---

:

SIEM: « ». 1: ?

SIEM: « ». 2. «» ( )

SIEM: « ». 3.1.

SIEM: « ». 3.2.

SIEM: « ». 4.

SIEM: « ». 5.