Sicherheitsereignisse (SIEM)

Status200 bewahrt Sicherheitsereignisse neben Ihren Logs, Traces und Metriken auf und gibt jedem dieselbe Form, OCSF (das Open Cybersecurity Schema Framework), egal in welchem Format es ankam. Senden Sie Ereignisse aus jeder Quelle, durchsuchen Sie sie, und finden Sie die wichtigen mit Sigma-Erkennungsregeln, Threat Intelligence und Monitoren. Was diese finden, wird zu Fällen, die Sie bearbeiten, und Playbooks reagieren darauf.

So funktioniert es#

Öffnen Sie Produkte → Sicherheitsereignisse, unter Observability. Sein Menü hat einen Abschnitt für jeden Teil der Sicherheit und für jede Sache darin eine eigene Seite:

Erkennungen, KI und Verbindungen, die man einmal einrichtet, bleiben eingeklappt, bis Sie sie öffnen. Neu bei Sicherheit? Erste Schritte mit Sicherheit richtet sie mit zwei Klicks ein.

Bevor Sie beginnen#

Sicherheitsdaten lesen nur die Rollen Project Owner und Project Admin sowie die drei Security-Rollen; andere Rollen sehen in Sicherheitsereignisse nichts. Siehe Rollen.

Sicherheitsereignisse senden#

1. Einen Ingestion-Schlüssel erstellen#

   Öffnen Sie Projekteinstellungen → Telemetrie & APM → Ingestion-Schlüssel und klicken Sie auf Aufnahmeschlüssel erstellen. Sicherheitsereignisse nutzen dieselben Schlüssel wie der Rest Ihrer Telemetrie.

2. Ihre Ereignisse senden#

   Senden Sie JSON an /security-events/v1/ingest, mit dem Schlüssel in x-status200-token:

   OCSFGoogle UDMGeneric JSON

   OCSF

   Bash

   curl -X POST "https://status200.ru/security-events/v1/ingest?format=ocsf" \
     -H "Content-Type: application/json" \
     -H "x-status200-token: YOUR_INGESTION_TOKEN" \
     -H "x-status200-service-name: my-security-source" \
     -d '{ "events": [ { "class_uid": 3002, "severity_id": 4, "status": "Failure", "message": "Failed logon for alice", "actor": { "user": { "name": "alice" } }, "src_endpoint": { "ip": "203.0.113.7", "hostname": "laptop-alice" } } ] }'

   Google UDM

   Bash

   curl -X POST "https://status200.ru/security-events/v1/ingest?format=udm" \
     -H "Content-Type: application/json" \
     -H "x-status200-token: YOUR_INGESTION_TOKEN" \
     -d '{ "events": [ { "metadata": { "event_type": "USER_LOGIN" }, "principal": { "hostname": "laptop-alice", "user": { "userid": "alice" }, "ip": ["203.0.113.7"] }, "security_result": [{ "severity": "HIGH", "action": ["BLOCK"] }] } ] }'

   Generic JSON

   Bash

   curl -X POST "https://status200.ru/security-events/v1/ingest" \
     -H "Content-Type: application/json" \
     -H "x-status200-token: YOUR_INGESTION_TOKEN" \
     -d '{ "events": [ { "severity": "high", "event_type": "ssh_brute_force", "message": "12 failed SSH logins in 60s", "username": "root", "hostname": "web-01", "src_ip": "203.0.113.7" } ] }'

   Der Endpunkt antwortet mit 200, sobald die Ereignisse in der Warteschlange stehen. Ein Ereignis ohne Zeitangabe, wie diese, wird auf den Moment seiner Ankunft gesetzt.

3. Sie unter Ereignisse finden#

   Öffnen Sie Produkte → Sicherheitsereignisse → Ereignisse. Die Ereignisse erscheinen innerhalb weniger Sekunden, mit Schweregrad, Klasse, Benutzer, Host und IP-Adressen ausgefüllt.

Formate#

Nennen Sie das Format mit ?format=, mit dem Header x-oneuptime-security-event-format oder mit einem Feld "format" auf oberster Ebene. Lassen Sie es weg, wird das Format jedes Ereignisses einzeln ermittelt, sodass ein Webhook Erkennungen und rohe Ereignisse mischen kann.

• Der Body kann ein Ereignis sein, ein Array von Ereignissen oder { "events": [...] }.
• Der Header x-status200-service-name nennt den Telemetrie-Dienst, zu dem die Ereignisse gehören. Ohne ihn gehören sie zu dem Dienst, der nach Produkt oder Anbieter des ersten Ereignisses benannt ist, oder zu Security Events.
• Nichts geht verloren, weil es sich nicht zuordnen ließ: Jedes Feld der Quelle landet in den Attributen des Ereignisses.

Felder von generischem JSON#

Ein generisches Ereignis wird anhand gängiger Feldnamen gelesen:

Ein Schweregradwort wird zu einer OCSF-Stufe: info wird als Informational gelesen, warning als Low, error als Medium, alert als Critical und emergency als Fatal.

Mit Fluent Bit weiterleiten#

Um Sicherheitslogs zu senden, die Sie schon sammeln, etwa von auditd, syslog oder Falco, fügen Sie Fluent Bit eine Ausgabe http hinzu:

[OUTPUT]
    Name             http
    Match            security.*
    Host             status200.ru
    Port             443
    tls              On
    URI              /security-events/v1/ingest
    Format           json
    Json_date_key    timestamp
    Json_date_format iso8601
    Header           x-status200-token YOUR_INGESTION_TOKEN
    Header           x-status200-service-name my-security-source
    Retry_Limit      5

Die Seite Einrichtungsanleitung, unter Verbindungen, hat diese Snippets mit Ihrem eigenen Host und Schlüssel ausgefüllt.

Sicherheitsereignisse in Ihren Logs finden#

Die Karte Ihre Protokolle oben auf Verbindungen macht die Logs, die Sie bereits an Status200 senden, zu einer Quelle. Ist Sicherheitsereignisse in Ihren Protokollen finden eingeschaltet, werden die neuen Logs des Projekts jede Minute gelesen, und jede SSH-Anmeldung, jeder sudo-Befehl, jeder Kubernetes-Audit-Eintrag, jede AWS-CloudTrail-Änderung und jeder Webangriff darin wird als Sicherheitsereignis gespeichert. Was jede Art abdeckt, steht unter Erste Schritte mit Sicherheit.

Ein Sicherheitsprodukt verbinden#

Verbindungen fragt ein Sicherheitsprodukt für Sie ab und importiert seine neuen Datensätze als Sicherheitsereignisse. Eine Verbindung enthält die Einstellungen des Produkts und verschlüsselte Zugangsdaten; ein Worker fragt sie in dem Intervall ab, das Sie festlegen, und überspringt bereits importierte Datensätze.

• Die eigenen Warnungen des Produkts ab der Stufe, die in Open Cases From eingestellt ist (Hoch und höher, sofern Sie keine andere Stufe wählen, oder Nie), eröffnen Fälle, gruppiert nach dem Benutzer, dem Host oder der Adresse, um die es jeweils geht.
• Eine Verbindung liest Datensätze nach dem Zeitpunkt, zu dem das Produkt sie erstellt hat, nicht nach der Zeit der Aktivität, die sie beschreiben. Eine SIEM-Regel, die stündlich läuft, erstellt Erkennungen lange nach den Ereignissen, auf die sie passte, und diese werden trotzdem importiert.
• Die erste Abfrage blickt 24 Stunden zurück, sodass eine neue Verbindung sofort aktuelle Datensätze zeigt.
• Verbindung testen in der Zeile der Verbindung prüft den Zugriff auf das Produkt und ob die eigenen Worker von Status200 laufen, und importiert nichts. Jetzt ausführen fragt sofort ab.

Was ein Ereignis enthält#

Jedes Ereignis wird mit typisierten Feldern und seinem Quell-Payload gespeichert:

Sicherheitsereignisse erkunden#

Ereignisse ist ein Telemetrie-Explorer wie die Explorer für Logs und Traces: ein Diagramm der Ereignisse des Zeitfensters nach Schweregrad, eine Seitenleiste mit Facetten, die Liste und ein Panel mit jedem Feld und Attribut des Ereignisses, das Sie öffnen. Zeitfenster, Filter und Suche stehen alle in der URL, sodass sich eine gefilterte Ansicht teilen lässt und ein Neuladen übersteht.

Suche#

Die Suchleiste spricht dieselbe Sprache wie die anderen Telemetrie-Explorer (siehe Suchsyntax):

Ein Feld ist entweder ein Kurzname (severity, class, category, activity, status, vendor, product, rule, user, host, ip, targetuser, targethost, targetip, processname, commandline, parentprocessname, observable, tactic, technique) oder der eigene Name des Felds, etwa severityName oder principalHost. Jeder andere Name wird als Quellattribut gelesen. observable:<value> findet jedes Ereignis, das einen Wert erwähnt, egal auf welcher Seite der Aktivität er stand.

Facetten#

Die Seitenleiste zählt die Ereignisse des Zeitfensters nach Quelle, Schweregrad, Ereignisklasse, Kategorie, Aktivität, Status, Anbieter, Produkt, Erkennungsregel, Quellbenutzer, Quell-Host, Prozess und Übergeordneter Prozess. Klicken Sie auf einen Wert, um nur seine Ereignisse zu behalten, oder auf das Minus daneben, um sie auszuschließen. Ein erneuter Klick macht das rückgängig. Das Diagramm und jede Zählung beschreiben genau die Ereignisse in der Liste.

Korrelieren#

Korrelieren zeichnet die Ereignisse rund um einen Host, einen Benutzer oder eine IP-Adresse: ihre Ereignisklassen rund um das Gesuchte, markiert nach ihrem schlimmsten Schweregrad, und die anderen Werte aus denselben Ereignissen auf dem äußeren Ring. Klicken Sie auf eine Klasse, um ihre Ereignisse aufzulisten, oder auf einen Wert, um als Nächstes danach zu korrelieren. Jedes Observable im Panel eines Ereignisses unter Ereignisse öffnet Korrelieren dafür.

Erkennungsregeln#

Eine Erkennungsregel ist eine Sigma-Regel, ein offenes YAML-Format zur Beschreibung verdächtiger Aktivität, die Status200 nach Zeitplan gegen Ihre Ereignisse laufen lässt. Passt sie, eröffnet sie einen Fall oder ergänzt einen offenen, öffnet eine Warnung, wahlweise einen Vorfall, und schreibt einen Detection Finding zurück in die Ereignisse. Die Rule Library bietet fertige Regeln als Ausgangspunkt.

Eine Regel erstellen#

Eine erste Regel, die auf fehlgeschlagene Anmeldungen von außerhalb von 10.x.x.x passt:

title: Failed logon burst
description: Repeated authentication failures from one source.
level: high
tags:
  - attack.t1110
  - attack.ta0006
detection:
  selection:
    className: Authentication
    statusName: Failure
  filter_internal:
    principalIp|startswith: '10.'
  condition: selection and not filter_internal

Was eine Regel ausdrücken kann#

Status200 führt den booleschen Kern von Sigma aus:

• Selektionen sind Feld-Maps (jedes Feld muss passen; eine Liste von Werten passt auf jeden davon) oder Schlüsselwortlisten, die überall in der Nachricht passen.
• Bedingungen verknüpfen Selektionen mit and, or, not und Klammern, oder mit 1 of selection_*, all of selection_*, any of them und all of them.
• Feldmodifikatoren: contains, startswith, endswith, all, re, cased, gt, gte, lt, lte, cidr, exists und windash. Text wird ohne Beachtung der Groß- und Kleinschreibung verglichen, sofern Sie nicht cased hinzufügen.
• Ein Feld ist ein typisiertes Feld (principalUser), eine gängige Sigma-Schreibweise davon (CommandLine, src_ip, Hostname) oder ein beliebiger Attributschlüssel, so geschrieben wie im Ereignis (threat.matched).
• Image und CommandLine lesen den Prozess, um den es im Ereignis geht, beim Start eines Prozesses den gestarteten (processPath, processCommandLine), und ParentImage und ParentCommandLine den Prozess, der ihn gestartet hat (parentProcessPath, parentProcessCommandLine). principalProcess ist der handelnde Prozess, beim Start also der übergeordnete.
• level legt den Schweregrad fest: informational, low, medium, high oder critical, und medium, wenn es fehlt. ATT&CK-IDs in tags (attack.t1110, attack.ta0006) füllen die MITRE-Felder des Befunds.

Aggregationen wie | count() by principalIp > 5 werden beim Speichern abgelehnt: Nutzen Sie stattdessen eine Korrelationsregel oder Nach Feld gruppieren und Schwellenwert der Trefferanzahl. logsource ist nur informativ und schränkt nichts ein: Setzen Sie diesen Filter in eine Selektion, etwa className: Authentication. Ein timeframe wird ignoriert, weil das Intervall der Regel ihr Fenster festlegt.

Korrelationsregeln#

Eine Sigma-Korrelation schlägt bei mehreren Ereignissen zusammen an statt bei einem. Fügen Sie sie mit den Regeln, die sie liest, in Sigma-Regel (YAML) ein, als YAML-Dokumente getrennt durch ---, oder nennen Sie Regeln, die das Projekt schon hat, über ihren Sigma-name oder ihre id. Die Rule Library hat fertige, etwa fehlgeschlagene Anmeldungen, auf die eine erfolgreiche folgt.

title: Failed sign-ins, then a success from the same address
level: high
correlation:
  type: temporal_ordered
  rules:
    - failed_sign_ins
    - successful_sign_in
  group-by:
    - principalIp
  timespan: 10m
---
title: Five failed sign-ins
name: failed_sign_ins
correlation:
  type: event_count
  rules:
    - failed_sign_in
  group-by:
    - principalIp
  timespan: 10m
  condition:
    gte: 5
---
title: Failed sign-in
name: failed_sign_in
detection:
  selection:
    className: Authentication
    statusName: Failure
  condition: selection
---
title: Successful sign-in
name: successful_sign_in
detection:
  selection:
    className: Authentication
    statusName: Success
  condition: selection

• Eine Gruppe ist der Wert der Felder in group-by, etwa eine Adresse. Die Zählung ist rollierend: Ein Schub, den zwei Läufe aufteilen, zählt innerhalb seines timespan trotzdem ganz, und der ist höchstens 24 Stunden lang.
• new_value ist ein eigener Typ von Status200, weil Sigma keine Korrelation „zuerst gesehen“ kennt: Er vergleicht mit bis zu 30 Tagen Verlauf. value_sum, value_avg, value_percentile und value_median werden beim Speichern abgelehnt.
• Die Spalte Typ in Erkennungsregeln nennt die Art jeder Regel, und das Formular sagt in einem Satz, wonach die Regel sucht.

Auswertungseinstellungen#

Gruppierung und eindeutige Zählung nehmen dieselben Feldnamen wie die Regel. Mit ihnen sagt der Schwellenwert „so viele, vom selben Ding, in einem Lauf“, ohne Monitor obendrauf:

Wann eine Regel läuft#

Status200 prüft jede Minute, welche aktivierten Regeln ihr Intervall seit ihrem letzten Lauf hinter sich haben. Jeder Lauf liest die Ereignisse, deren Ereigniszeit zwischen dem vorigen Lauf und vor zwei Minuten liegt, und geht dann weiter. Die zwei Minuten lassen Ereignissen Zeit, die noch unterwegs sind, etwa einer Logzeile, die eine Minute nach dem Schreiben gelesen wird:

• Die Fenster liegen lückenlos hintereinander, sie gleiten nicht. Bei einem Intervall von 10 Minuten können Fehlschläge um 09:58 und 10:01 in verschiedene Läufe fallen und werden getrennt gezählt, also lassen Sie bei der Wahl eines Schwellenwerts Spielraum.
• Nach einer Lücke, etwa einem Worker-Ausfall oder einer wieder eingeschalteten Regel, deckt der nächste Lauf die ganze Lücke ab, bis zu den letzten 24 Stunden.
• Ein Ereignis, das mehr als zwei Minuten zu spät ankommt, nachdem ein Lauf seine Zeit schon abgedeckt hat, wird gespeichert und ist durchsuchbar, aber diese Regel liest es nie.
• Jede Gruppe, die den Schwellenwert erreicht, wird zu einem Detection Finding, bis zu 10.000 pro Lauf. Warnungen, Vorfälle und Fälle öffnen sich für die 100 mit den höchsten Zählungen; die übrigen teilen sich einen Fall zur Regel, und Letzter Fehler der Regel nennt, wie viele Gruppen passten.

Schweregrad#

Das level einer Regel ist der Schweregrad ihrer Befunde: informational, low, medium, high und critical werden zu Informational, Low, Medium, High und Critical. Ihre Warnungen und Vorfälle nehmen einen der Schweregrade Ihres Projekts, in dieser Reihenfolge:

1. Der Warnungsschweregrad (oder Vorfallsschweregrad) der Regel, wenn gesetzt.
2. Ihr Schweregrad, der nach der Stufe benannt ist, etwa High, unabhängig von der Schreibweise.
3. Nach Rang: Regeln mit critical und high nehmen Ihren höchsten Schweregrad, die anderen Ihren niedrigsten.

Warnungen und Befunde#

Jede auslösende Gruppe öffnet eine Warnung mit dem Titel [Detection] <rule name> — <group value>, oder [Detection] <rule name> bei einer Regel ohne Gruppierfeld. Solange sie offen ist, öffnen weitere Treffer dieser Gruppe keine neue. Eine Regel sieht nur Treffer und kann nicht erkennen, dass ein Angriff aufgehört hat, also bleiben ihre Warnungen offen, bis jemand sie behebt.

Ein Detection Finding ist ein Sicherheitsereignis der Klasse Detection Finding (OCSF-Klasse 2004) vom Produkt Status200 Detections, mit den MITRE-Tags der Regel, dem Gruppenwert an erster Stelle in observables und diesen Attributen:

Befunde sind gewöhnliche Ereignisse: Durchsuchen Sie sie unter Ereignisse und korrelieren Sie sie unter Korrelieren. Um eine neue Regel leise auszuprobieren, schalten Sie jede Aktion außer dem Befund ab, bis Sie ihr trauen.

Monitore für Sicherheitsereignisse#

Ein Monitor für Sicherheitsereignisse zählt die Ereignisse, die auf seine Filter passen, über ein gleitendes Fenster und wendet die üblichen Monitorkriterien auf die Zählung an: Er ändert den Status des Monitors, öffnet Warnungen oder Vorfälle und alarmiert die Bereitschaft. Erstellen Sie einen unter Monitore → Monitor erstellen, mit Sicherheitsereignisse als Typ; dort wird er mit Ihren anderen Monitoren aufgeführt.

Sein Formular zeigt Ereignisse überwachen, die diesen Text enthalten, Sicherheitsereignisse überwachen für (Zeit), Ereignisschweregrad und Ereignisklasse. Nach Telemetrie-Dienst filtern und Nach Attributen filtern warten unter Weitere Felder, dessen Kopf die zeigt, die ein Monitor nutzt. Seine Kriterien prüfen Security Event Count.

Schreiben Sie die Erkennung selbst als Regel, mit ihrem Schwellenwert. Nutzen Sie einen Monitor, wenn Sie ein gleitendes Fenster wollen, einen Status, der sich von selbst erholt, eine Statusseite oder unterschiedliche Bereitschaftsrichtlinien pro Kriterium.

Ihre Erkennungen beobachten#

Befunde sind Ereignisse, also kann ein Monitor die Regeln selbst beobachten:

• Stürme: ein Monitor auf die Klasse Detection Finding, der jeden Befund zählt. Zwanzig verschiedene Regeln, die in einer Stunde auslösen, sind ein Signal, das keine einzelne Regel sehen kann.
• Ratenänderungen: Filtern Sie auf die status200.detection.rule_id einer Regel. Eine Regel, die wöchentlich auslöst und plötzlich fünfzigmal pro Stunde auslöst, braucht eine andere Reaktion.
• Stille: Befunde, die auf null fallen, wo Sie sonst ein paar sehen, bedeuten meist, dass eine Quelle nicht mehr sendet. Nutzen Sie ein Kriterium, das auf eine Zählung unter einer Zahl prüft.

Die Aktion Monitor erstellen in der Zeile einer Regel öffnet einen neuen Monitor, der schon so eingerichtet ist: die Klasse Detection Finding, die ID der Regel (nie ihr Name, den eine Umbenennung ändern würde) und die letzte Stunde. Ein solcher Monitor zählt Befunde, einen pro Gruppe und Lauf, nicht die Ereignisse dahinter. Um eine Anzahl von Ereignissen zu verlangen, bevor irgendetwas auslöst, nutzen Sie den Schwellenwert der Trefferanzahl der Regel.

Threat Intelligence#

Threat Intel abonniert STIX/TAXII-Feeds bekannter bösartiger IP-Adressen, Domains, URLs, E-Mail-Adressen und Datei-Hashes. Ereignisse, die einen davon erwähnen, werden beim Eintreffen mit threat.*-Attributen markiert, auf die Regeln und Monitore filtern können, und jede Minute werden aktuelle Ereignisse mit den Feeds abgeglichen und öffnen Warnungen und Befunde wie eine Regel. Siehe Threat Intelligence.

Aufbewahrung und Abrechnung#

Sicherheitsereignisse werden pro aufgenommenem GB abgerechnet, wie der Rest Ihrer Telemetrie, und für Ihre Telemetrie-Aufbewahrung behalten: die Standardaufbewahrung (Tage) des Projekts unter Projekteinstellungen → Telemetrie & APM → Datenaufbewahrung, oder eine Aufbewahrung, die am Telemetrie-Dienst festgelegt ist, zu dem sie gehören. Endet die Aufbewahrung eines Ereignisses, wird es gelöscht.

Fehlerbehebung#

Nächste Schritte#