Wir schließen die Artikelserie ab, die sich mit den Regeln der Korrelation befasst, die sofort einsatzbereit sind. Wir haben uns zum Ziel gesetzt, einen Ansatz zu formulieren, mit dem wir Korrelationsregeln erstellen können, die mit einem Minimum an Fehlalarmen „out of the box“ funktionieren können.


Bild: Software-Marketing

Alle wichtigen Punkte des Artikels sind in der Schlussfolgerung verfügbar. An derselben Stelle wird diese Methodik in Form eines grafischen Diagramms dargestellt .

Kurz darüber, was in früheren Artikeln passiert ist: Sie beschrieben, wie eine Reihe von Feldern eines normalisierten Ereignisses aussehen sollte - ein Diagramm ; welches Ereigniskategorisierungssystem verwendet werden soll; wie man mithilfe eines Kategorisierungssystems und eines Schemas den Prozess der Normalisierung von Ereignissen vereinheitlicht. Wir haben auch den Kontext der Implementierung von Korrelationsregeln untersucht und untersucht, was SIEM über das von ihm überwachte automatisierte System (AS) wissen sollte und warum.

Alle oben genannten Ansätze und Überlegungen sind die Blöcke, aus denen die Methodik zur Entwicklung von Korrelationsregeln aufgebaut ist. Es ist Zeit, sie zusammenzusetzen und das ganze Bild zu betrachten.

Die gesamte Methode zur Entwicklung von Korrelationsregeln besteht aus vier Blöcken:

• Vorbereitung von Quellen und Umgebung;
• Normalisierung von Ereignissen und deren Bereicherung;
• Anpassung der Korrelationsregeln an den Kontext von AS;
• Bildung einer Vereinbarung über Positive.

Quellen und Umgebungen vorbereiten

Korrelationsregeln gelten für Ereignisse, die Quellen generieren. In diesem Zusammenhang ist es äußerst wichtig, dass die für die Korrelationsregeln erforderlichen Quellen in den Lautsprechern vorhanden und korrekt konfiguriert sind.


Quellen und Umgebungen vorbereiten

Schritt 1 : Überlegen Sie sich die allgemeine Logik der Regel und verstehen Sie, welche Ereignisquellen benötigt werden. Wenn Sie von Grund auf neu entwickeln oder eine vorgefertigte Sigma- Korrelationsregel anwenden , müssen Sie anhand der Ereignisse verstehen, aus welchen Quellen sie funktionieren.

Schritt 2 : Stellen Sie sicher, dass alle erforderlichen Quellen im Unternehmen vorhanden sind und gesammelt werden können. Eine Situation ist möglich, wenn eine Regel eine Kette von Ereignissen aus mehreren Quellen des Formulars (Ereignis A aus Quelle 1) - (Ereignis B aus Quelle 2) - (Ereignis C aus Quelle 3) 5 Minuten lang bearbeitet. Wenn Ihr Unternehmen nicht über mindestens eine Quelle verfügt, wird eine solche Regel unbrauchbar, da sie niemals funktioniert. Sie müssen verstehen, ob es grundsätzlich möglich ist, Ereignisse aus den erforderlichen Quellen zu sammeln und ob Ihr SIEM diese bereitstellen kann. Beispielsweise schreibt die Quelle Ereignisse in eine Datei, die Datei wird jedoch verschlüsselt, oder es wird eine nicht standardmäßige Datenbank für die Speicherung der Quelle verwendet, auf die über den Standard-ODBC / JDBC-Treiber kein Zugriff gewährleistet werden kann.

Schritt 3 : Schließen Sie die Quellen an SIEM an. Egal wie banal es klingen mag, in diesem Schritt ist es notwendig, die Sammlung von Ereignissen zu implementieren. Es gibt oft viele Probleme. Zum Beispiel organisatorische Probleme, wenn das IT-Management die Verbindung zu geschäftskritischen Systemen kategorisch verbietet. Oder technisch gesehen, wenn der SIEM-Agent (SmartConnector, Universal Forwarder) ohne zusätzliche Einstellungen beim Sammeln von Ereignissen einfach die Quelle „tötet“, was zu einem Denial-of-Service führt. Dies kann häufig beobachtet werden, wenn hoch belastete DBMS an SIEM angeschlossen werden.

Schritt 4 : Stellen Sie sicher, dass das Audit für die Quellen korrekt konfiguriert ist und die für die Korrelation erforderlichen Ereignisse in SIEM empfangen werden. Korrelationsregeln erwarten bestimmte Arten von Ereignissen. Sie müssen von der Quelle generiert werden. Es kommt häufig vor, dass zum Generieren der für die Regeln erforderlichen Ereignisse die Quelle zusätzlich konfiguriert werden muss: Die erweiterte Überwachung ist aktiviert und die Protokollausgabe in einem bestimmten Format ist konfiguriert.

Das Aktivieren der erweiterten Überwachung wirkt sich häufig auf den vom SIEM von der Quelle empfangenen Ereignisfluss (EPS) aus. Aufgrund der Tatsache, dass die Quelle selbst und SIEM im Zuständigkeitsbereich verschiedener Abteilungen liegen, besteht immer das Risiko, dass die erweiterte Prüfung deaktiviert wird und die erforderlichen Arten von Ereignissen nicht mehr bei SIEM eingehen. Dieses Problem kann teilweise erkannt werden, indem der Ereignisfluss für jede Quelle überwacht wird oder vielmehr Änderungen der Ereignisse pro Sekunde (EPS) überwacht werden.

Schritt 5 : Stellen Sie sicher, dass Ereignisse ausgeführt werden, und konfigurieren Sie die Quellenüberwachung. In jeder Infrastruktur treten früher oder später Fehler im Netzwerk oder in der Quelle selbst auf. Zu diesem Zeitpunkt verliert SIEM den Kontakt zur Quelle und kann keine Ereignisse empfangen. Wenn die Quelle passiv ist und ihre Protokolle in eine Datei oder Datenbank schreibt, gehen bei einem Fehler keine Ereignisse verloren, und SIEM kann sie empfangen, wenn die Kommunikation wiederhergestellt ist. Wenn die Quelle aktiv ist und Ereignisse beispielsweise über Syslog an SIEM sendet, ohne sie zusätzlich irgendwo zu speichern, gehen die Ereignisse bei einem Fehler verloren und Ihre Korrelationsregel funktioniert einfach nicht, da das gewünschte Ereignis nicht wartet. Wenn Sie tiefer graben, können Sie sehen, dass selbst bei der Arbeit mit einer passiven Quelle beim Wiederherstellen der Kommunikation nach einem Fehler keine Garantie dafür besteht, dass die Korrelationsregeln funktionieren, insbesondere bei solchen, die mit Zeitfenstern arbeiten. Betrachten Sie das oben beschriebene Regelbeispiel: (Ereignis A von Quelle 1) - (Ereignis B von Quelle 2) - (Ereignis C von Quelle 3) für 5 Minuten. Wenn nach Ereignis B ein Fehler auftritt und die Verbindung in einer Stunde wiederhergestellt wird, funktioniert die Korrelation nicht, da Ereignis C nicht in den erwarteten 5 Minuten eintrifft.

Unter Berücksichtigung dieser Funktionen sollten Sie die Überwachung der Quellen konfigurieren, aus denen Ereignisse erfasst werden. Diese Überwachung sollte die Verfügbarkeit von Quellen, die Aktualität des Eintreffens von Ereignissen aus ihnen und die Stärke des Flusses gesammelter Ereignisse (EPS) überwachen.

Das Auslösen des Überwachungssystems ist die erste Glocke, die vom Auftreten eines negativen Faktors spricht, der die Leistung aller oder eines Teils der Korrelationsregeln beeinflusst.

Normalisierung von Ereignissen und deren Bereicherung

Das Sammeln der für die Korrelation erforderlichen Ereignisse reicht nicht aus. Ereignisse, die bei SIEM eintreffen, müssen streng nach den anerkannten Regeln normalisiert werden. Wir haben in einem separaten Artikel über die Probleme der Normalisierung und die Bildung einer Normalisierungsmethode geschrieben. Im Allgemeinen kann dieser Block als Kampf gegen Müll rein , Müll raus ( GIGO ) charakterisiert werden .


Normalisierung und Bereicherung von Ereignissen

Schritt 6 und Schritt 7 : Kategorisierung von Ereignissen und Normalisierung von Ereignissen gemäß der Kategorie basierend auf der Methodik. Wir werden nicht näher darauf eingehen, da wir diese Schritte im Artikel „Methodik zur Normalisierung von Ereignissen“ ausführlich betrachtet haben.

Schritt 8 : Anreicherung von Ereignissen mit fehlenden und zusätzlichen Informationen gemäß der Kategorie. Eingehende Ereignisse enthalten häufig nicht immer Informationen in dem Umfang, in dem die Korrelationsregeln funktionieren. Ein Ereignis enthält beispielsweise nur die IP-Adresse des Hosts, es gibt jedoch keine Informationen zu seinem vollqualifizierten Domänennamen oder Hostnamen. Ein weiteres Beispiel: Ein Ereignis enthält eine Benutzer-ID, das Ereignis enthält jedoch keinen Benutzernamen. In diesem Fall sollten die erforderlichen Informationen aus externen Quellen - Datenbanken, Domänencontrollern oder anderen Verzeichnissen - extrahiert und dem Ereignis hinzugefügt werden.

Es ist wichtig zu beachten, dass die Kategorisierung von Ereignissen ganz am Anfang erfolgt - vor der Normalisierung. Zusätzlich zu der Tatsache, dass die Kategorie die Regeln für die Normalisierung des Ereignisses definiert, legt sie auch die Liste der Daten fest, die in externen Quellen gesucht werden müssen, wenn sie nicht im Ereignis selbst enthalten sind.

Anpassung der Korrelationsregeln an den AS-Kontext

Nachdem Sie die Eingabedaten (Ereignisse) vorbereitet und mit der Entwicklung von Korrelationsregeln fortgefahren haben, müssen Sie die Besonderheiten der eingehenden Ereignisse, des AS selbst und seiner Variabilität berücksichtigen. Mehr dazu im Artikel „Systemmodell als Kontext von Korrelationsregeln“ .


Anpassung der Korrelationsregeln an den AS-Kontext

Schritt 9 : Verstehen Sie die Häufigkeit von Ereignissen aus jeder Quelle und bestimmen Sie das Zeitfenster für die Korrelation. Sehr oft verwenden Korrelationsregeln Zeitfenster, wenn das Eintreffen eines bestimmten Ereignisses innerhalb eines bestimmten Zeitintervalls erwartet werden muss. Bei der Entwicklung solcher Regeln ist es wichtig, die Verzögerung beim Empfang von Ereignissen zu berücksichtigen. Sie werden normalerweise durch zwei Faktoren verursacht.

Erstens schreibt die Quelle selbst möglicherweise nicht sofort Ereignisse in die Datenbank, in eine Datei oder sendet sie über Syslog. Die Zeit dieser Verzögerung muss geschätzt und in der Regel berücksichtigt werden.

Zweitens verzögert sich die Übermittlung von Ereignissen an SIEM. Beispielsweise ist die Erfassung von Ereignissen aus der Datenbank so konfiguriert, dass die Anforderung von Ereignissen alle 10 Minuten ausgeführt wird. Natürlich ist das Korrelationsfenster von 5 Minuten in dieser Situation nicht die beste Lösung.

Das Problem verschärft sich, wenn eine Korrelationsregel entwickelt werden muss, die mit Ereignissen aus mehreren Quellen gleichzeitig funktioniert. In diesem Fall ist es wichtig zu verstehen, dass sie unterschiedliche Lieferzeiten haben können. Im schlimmsten Fall werden Ereignisse in zufälliger Reihenfolge mit einem Verstoß gegen die Chronologie angezeigt. In einer solchen Situation muss der Entwickler der Korrelationsregeln klar verstehen, zu welchem ​​Zeitpunkt das SIEM die Korrelation realisiert (in der Ereigniszeit oder wenn das Ereignis in SIEM eintrifft). Ich stelle fest, dass die Korrelation in der Zeit des Eintreffens von Ereignissen die technisch einfachste und gebräuchlichste Option für die Verarbeitung von Ereignissen im Pseudo-Echtzeitmodus ist. Diese Option verschärft jedoch nur die oben genannten Probleme und löst sie nicht.

Wenn Ihr SIEM eine Korrelation in der Ereigniszeit bereitstellt, gibt es höchstwahrscheinlich Mechanismen zum Neuordnen von Ereignissen, mit denen die tatsächliche Chronologie von Ereignissen wiederhergestellt werden kann.

Wenn Sie verstehen, dass das Zeitfenster zu groß ist, um eine Korrelation im Stream durchzuführen, müssen Sie den Retro-Korrelationsmechanismus verwenden, bei dem bereits gespeicherte Ereignisse gemäß dem Zeitplan aus der SIEM-Datenbank ausgewählt und die Korrelationsregeln durchlaufen werden.

Schritt 10 : Richten Sie einen Ausnahmemechanismus ein. In der realen Welt wird es immer ein Objekt mit speziellem Verhalten geben, das nicht von einer bestimmten Korrelationsregel behandelt werden sollte, da dies zu einem falsch positiven Ergebnis führt. Daher sollten in der Phase der Entwicklung der Regeln Mechanismen eingerichtet werden, um solche Objekte zu einer Ausnahme zu machen. Wenn Ihre Regel beispielsweise mit den IP-Adressen von Computern arbeitet, benötigen Sie eine Tabellenliste, in der Sie Adressen hinzufügen können, für die die Regel nicht funktioniert. Wenn eine Regel mit Benutzeranmeldungen oder Prozessnamen arbeitet, muss vorab mit Tabellenausschlusslisten in der Regellogik gearbeitet werden.

Mit diesem Ansatz können Sie Ausnahmen automatisch oder manuell Objekte zu Ausnahmen hinzufügen, ohne den Hauptteil der Regel neu schreiben zu müssen.

Schritt 11 : Definieren Sie die physischen und logischen Grenzen der Anwendbarkeit der Korrelationsregel. Bei der Entwicklung einer Korrelationsregel ist es wichtig, zunächst die Grenzen der Anwendbarkeit (Umfang) der Regel zu verstehen und zu verstehen, ob sie überhaupt existieren. Wenn Sie die Logik ausarbeiten und die Regel debuggen, müssen Sie sich auf die Besonderheiten dieses Bereichs konzentrieren. Wenn eine Regel mit Daten arbeitet, die über den Bereich dieses Bereichs hinausgehen, steigt die Wahrscheinlichkeit von Fehlalarmen.

Es können zwei Arten von Bereichen unterschieden werden: physische und logische. Der physische Bereich sind die Unternehmens- und angrenzenden Netzwerke, und der logische Bereich sind die Teile des AS, der Geschäftsanwendungen oder der Geschäftsprozesse. Beispiele für den physischen Bereich: DMZ-Segment, interne und externe Subnetze, RAS-Netzwerke. Beispiele für den logischen Geltungsbereich der Regeln: Prozesssteuerung, Buchhaltung, PCI-DSS-Segment, PD-Segment oder nur bestimmte Geräterollen - Domänencontroller, Zugriffsschalter, Kernrouter.

Sie können Bereiche für Korrelationsregeln über Tabellenlisten festlegen. Sie können entweder manuell oder automatisch gefüllt werden. Wenn Sie in Ihrem Unternehmen Zeit für das Asset Management (Asset Management) finden, sind möglicherweise alle erforderlichen Daten bereits in dem in SIEM erstellten AS-Modell enthalten. Durch die automatische Generierung solcher Tabellenlisten können Sie neue Assets, die im Unternehmen angezeigt werden, dynamisch in den Geltungsbereich aufnehmen. Wenn Sie beispielsweise eine Regel hatten, die ausschließlich mit Domänencontrollern funktioniert, wird das Hinzufügen eines neuen Controllers zur Domänengesamtstruktur im Modell behoben und fällt in den Geltungsbereich Ihrer Regel.

Im Allgemeinen können die für Ausnahmen verwendeten Tabellenlisten als schwarze Listen und die für den Geltungsbereich der Regeln verantwortlichen Listen als weiße Listen betrachtet werden.

Schritt 12 : Verwenden Sie das Lautsprechermodell, um den Kontext zu verdeutlichen. Bei der Entwicklung einer Korrelationsregel, die böswillige Aktionen identifiziert, ist es wichtig sicherzustellen, dass sie tatsächlich implementiert werden können. Wenn dies nicht berücksichtigt wird, erweist sich das Auslösen der Regel, die den potenziellen Angriff aufgedeckt hat, als falsch, da diese Art von Angriff möglicherweise einfach nicht auf Ihre Infrastruktur anwendbar ist. Ich werde mit einem Beispiel erklären:

1. Angenommen, wir haben eine Korrelationsregel, die Remote-RDP-Verbindungen zu Servern erkennt.
2. Die Firewall ruft den Versuch auf, eine Verbindung zum TCP-Port 3389 des myserver.local-Servers herzustellen.
3. Die Regel wird ausgelöst und Sie beginnen, einen potenziellen Vorfall mit hoher Priorität zu analysieren.

Während der Untersuchung stellen Sie schnell fest, dass myserver.local 3389 geschlossen ist und von keinem Dienst geöffnet wurde und Linux vorhanden ist. Dies ist ein falsches Positiv, für dessen Untersuchung Sie Zeit gebraucht haben.

Ein weiteres Beispiel: IPS sendet ein Signatur-auslösendes Ereignis, wenn versucht wird, die Sicherheitsanfälligkeit CVE-2017-0144 auszunutzen. Während der Untersuchung stellt sich jedoch heraus, dass der entsprechende Patch auf dem angegriffenen Computer installiert ist und nicht auf einen solchen Vorfall mit der höchsten Priorität reagiert werden muss.
Die Verwendung von Daten aus dem Lautsprechermodell hilft, dieses Problem zu lösen.

Schritt 13 : Verwenden Sie Entitätskennungen, nicht deren Quellschlüssel. Wie bereits im Artikel „Systemmodell als Kontext von Korrelationsregeln“ beschrieben, können sich die IP-Adresse, der vollqualifizierte Domänenname und sogar der MAC eines Assets ändern. Wenn Sie also die Quellkennungen des Assets in der Korrelationsregel oder in der Tabellenliste verwenden, besteht nach einer Weile eine hohe Wahrscheinlichkeit, dass aus einem völlig banalen Grund falsch positive Ergebnisse empfangen werden. Beispielsweise hat der DHCP-Server diese IP einfach an einen anderen Computer ausgegeben.

Wenn Ihr SIEM über einen Mechanismus zum Identifizieren von Assets, zum Verfolgen ihrer Änderungen und zum Arbeiten mit deren Identifikatoren verfügt, sollten Sie Identifikatoren verwenden, nicht die Quellschlüssel des Assets.

Bildung einer positiven Vereinbarung

Wenn wir uns dem letzten Block zum Erstellen der Korrelationsregel nähern, erinnern wir uns, dass das Ergebnis der Regel ein in SIEM angesprochener Vorfall ist. Verantwortliche Fachkräfte müssen auf einen solchen Vorfall reagieren. Obwohl der Zweck dieser Artikelserie nicht die Berücksichtigung des Vorfallreaktionsprozesses umfasst, sollte beachtet werden, dass ein Teil der Informationen über den Vorfall bereits in der Phase der Erstellung der entsprechenden Korrelationsregel generiert wird.

Als nächstes betrachten wir die grundlegenden Punkte, die bei der Konfiguration der Parameter zum Auslösen der Korrelationsregel und zum Generieren eines Vorfalls berücksichtigt werden müssen.


Bildung einer positiven Vereinbarung

Schritt 14 : Bestimmen Sie die Bedingungen für die Aggregation und das Herunterfahren bei einer großen Anzahl von Fehlalarmen. Wenn Sie sich in der Debugging-Phase und während des Funktionierens nicht an diese Technik halten :), können Fehlalarme der Regeln auftreten. Es ist gut, wenn es ein oder zwei Fahrten pro Tag gibt, aber was ist, wenn eine Regel Tausende oder Zehntausende von Fahrten hat? Dies deutet natürlich darauf hin, dass die Regel weiterentwickelt werden muss. Es muss jedoch sichergestellt werden, dass in solchen Situationen ein derart massives falsches Positiv:

1. Die SIEM-Leistung wurde nicht beeinflusst.
2. Bei der Masse der Fehlalarme gingen wirklich wichtige Vorfälle nicht verloren. Es gibt sogar eine separate Art von Angriff, die darauf abzielt, die böswilligen Hauptaktivitäten hinter vielen falschen Aktivitäten zu verbergen.

Probleme dieser Art können gelöst werden, wenn beim Erstellen einer Korrelationsregel auf der Ebene des gesamten Systems als Ganzes oder für jede Regel einzeln Bedingungen für die Aggregation von Vorfällen und Bedingungen für eine Notabschaltung der Regel festgelegt werden können.

Der Vorfallaggregationsmechanismus ermöglicht es nicht, Millionen identischer Vorfälle zu erstellen, sondern neue Vorfälle an einen zu „kleben“, sofern sie identisch sind. In extremen Fällen, in denen selbst die Aggregation von Vorfällen eine erhebliche Belastung darstellt, wird empfohlen, die Korrelationsregel so einzustellen, dass sie sich automatisch ausschaltet, wenn die angegebene Anzahl von Vorgängen pro Zeiteinheit (Minute, Stunde, Tag) überschritten wird.

Schritt 15 : Definieren Sie die Regeln zum Generieren des Namens des Vorfalls. Dieser Punkt wird häufig vernachlässigt, insbesondere wenn sie keine Regeln für ihr Unternehmen entwickeln, z. B. wenn ein Drittunternehmen für die Implementierung von SIEM und die Entwicklung von Regeln verantwortlich ist. Der Name der Korrelationsregel sowie der von ihr erzeugte Vorfall sollten kurz sein und das Wesen einer bestimmten Regel klar widerspiegeln.

Wenn in Ihrem Unternehmen mehr als eine Person mit Vorfällen und Korrelationsregeln arbeitet, wird empfohlen, Namensregeln zu entwickeln. Sie müssen vom gesamten Team, das mit SIEM zusammenarbeitet, verstanden und akzeptiert werden.

Schritt 16 : Definieren Sie die Regeln für die Gestaltung der Wichtigkeit des Vorfalls. Bei den meisten SIEM-Lösungen in der letzten Phase der Erstellung eines Vorfalls können Sie dessen Bedeutung und Bedeutung festlegen. Einige Entscheidungen berechnen die Wichtigkeit sogar automatisch, basierend auf dem Kontext des Vorfalls und den daran beteiligten Objekten.

Für den Fall, dass Ihr SIEM ausschließlich automatisch die Wichtigkeit von Vorfällen berechnet, lohnt es sich, anhand dessen, welche und nach welcher Formel es berechnet wird, herauszufinden. Wenn die Wichtigkeit beispielsweise auf der Grundlage der Wichtigkeit der an dem Vorfall beteiligten Vermögenswerte berechnet wird, müssen Sie die Probleme der Vermögensverwaltung in einem Unternehmen im Voraus ernst nehmen.

Wenn Sie die Wichtigkeit eines Vorfalls manuell festlegen, wird empfohlen, eine Berechnungsformel zu entwickeln, die mindestens Folgendes berücksichtigt:

1. Die Bedeutung des Umfangs, in dem die Regel funktioniert. Beispielsweise kann ein Vorfall in der geschäftskritischen Zone von Systemen kritischer sein, als wenn genau derselbe Vorfall in der Zone geschäftskritischer Systeme aufgetreten ist.
2. Die Bedeutung der an dem Vorfall beteiligten Assets und Benutzerkonten.
3. Die Wiederholung dieses Vorfalls im Unternehmen.

Ebenso wie bei der Benennung von Vorfällen ist es wichtig, dass alle interessierten Parteien die Regeln, nach denen die Bedeutung eines Vorfalls gebildet wird, klar und gleichermaßen verstehen.

Schlussfolgerungen

Zusammenfassend fasse ich die Ergebnisse unserer Artikelserie zusammen und stelle fest, dass es meiner Meinung nach möglich ist, Korrelationsregeln zu erstellen, die sofort funktionieren. Die Lösung kann eine Verschmelzung von organisatorischen und technischen Ansätzen sein. SIEM selbst muss in der Lage sein, etwas zu tun, aber Spezialisten, die es betreiben, müssen etwas tun und wissen.

Zusammenfassend:

1. Die Methode besteht aus folgenden Blöcken:
   
   • Quellen und Umgebungen vorbereiten.
   • Normalisierung von Ereignissen und deren Bereicherung.
   • Anpassung der Korrelationsregeln an den AS-Kontext.
   • Abschluss einer Vereinbarung über Positive.
2. Jede Einheit hat organisatorische und technische Komponenten.
3. , SIEM, .
4. , , SIEM-.
5. . .

, « »

, , . — . .

---

:

SIEM: « ». 1: ?

SIEM: « ». 2. «»

SIEM: « ». Teil 3.1.

SIEM: « ». 3.2.

SIEM: « ». 4.

SIEM: « ». 5. ( )