Événements de sécurité (SIEM)

Status200 conserve les événements de sécurité à côté de vos journaux, traces et métriques, et donne à chacun la même forme, OCSF (l'Open Cybersecurity Schema Framework), quel que soit le format dans lequel il est arrivé. Envoyez des événements depuis n'importe quelle source, recherchez-les, et repérez ceux qui comptent avec des règles de détection Sigma, du renseignement sur les menaces et des moniteurs. Ce qu'ils trouvent donne lieu à des dossiers à traiter, auxquels répondent des playbooks.

Fonctionnement#

Ouvrez Produits → Événements de sécurité, sous Observabilité. Son menu a une section pour chaque partie de la sécurité, et une page à part pour chaque chose qu'elle contient :

Détections, IA et Connexions, qu'on configure une fois, restent repliées jusqu'à ce que vous les ouvriez. Nouveau dans la sécurité ? Bien démarrer avec la sécurité la met en place en deux clics.

Avant de commencer#

Seuls les rôles Project Owner et Project Admin, ainsi que les trois rôles de sécurité, lisent les données de sécurité ; les autres rôles ne voient rien dans Événements de sécurité. Voir Rôles.

Envoyer des événements de sécurité#

1. Créer une clé d'ingestion#

   Ouvrez Paramètres du projet → Télémétrie & APM → Clés d'ingestion et cliquez sur Créer une clé d'ingestion. Les événements de sécurité utilisent les mêmes clés que le reste de votre télémétrie.

2. Envoyer vos événements#

   Envoyez du JSON à /security-events/v1/ingest avec la clé dans 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" } ] }'

   L'endpoint répond 200 dès que les événements sont en file d'attente. Un événement envoyé sans heure, comme ceux-ci, est placé au moment de son arrivée.

3. Les retrouver dans Événements#

   Ouvrez Produits → Événements de sécurité → Événements. Les événements apparaissent en quelques secondes, avec leur gravité, leur classe, l'utilisateur, l'hôte et les adresses IP renseignés.

Formats#

Indiquez le format avec ?format=, avec l'en-tête x-oneuptime-security-event-format ou avec un champ "format" de premier niveau. Si vous l'omettez, le format de chaque événement est déterminé séparément, si bien qu'un même webhook peut mêler détections et événements bruts.

• Le corps peut être un événement, un tableau d'événements ou { "events": [...] }.
• L'en-tête x-status200-service-name nomme le service de télémétrie auquel appartiennent les événements. Sans lui, ils appartiennent au service nommé d'après le produit ou le fournisseur du premier événement, ou à Security Events.
• Rien n'est écarté faute de correspondance : chaque champ de la source arrive dans les attributs de l'événement.

Champs du JSON générique#

Un événement générique est lu d'après des noms de champs courants :

Un mot de gravité devient un niveau OCSF : info se lit Informational, warning Low, error Medium, alert Critical et emergency Fatal.

Transférer avec Fluent Bit#

Pour envoyer des journaux de sécurité que vous collectez déjà, par exemple ceux d'auditd, de syslog ou de Falco, ajoutez à Fluent Bit une sortie http :

[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

La page Guide de configuration, sous Connexions, contient ces extraits avec votre propre hôte et votre clé déjà remplis.

Trouver des événements de sécurité dans vos journaux#

La carte Vos journaux, en haut de Connexions, fait des journaux que vous envoyez déjà à Status200 une source. Avec Trouver des événements de sécurité dans vos journaux activé, les nouveaux journaux du projet sont lus chaque minute, et chaque connexion SSH, commande sudo, entrée d'audit Kubernetes, modification AWS CloudTrail et attaque web qu'ils contiennent est stockée comme événement de sécurité. Voir Bien démarrer avec la sécurité pour ce que couvre chaque type.

Connecter un produit de sécurité#

Connexions interroge un produit de sécurité pour vous et importe ses nouveaux enregistrements comme événements de sécurité. Une connexion conserve les paramètres du produit et un identifiant chiffré ; un worker l'interroge à l'intervalle que vous fixez et ignore les enregistrements déjà importés.

• Les alertes propres au produit d'un niveau égal ou supérieur à Open Cases From (Élevé et au-dessus sauf si vous choisissez un autre niveau, ou Jamais) ouvrent des dossiers, regroupées selon l'utilisateur, l'hôte ou l'adresse qu'elles concernent.
• Une connexion lit les enregistrements selon le moment où le produit les a créés, pas selon le moment de l'activité qu'ils décrivent. Une règle SIEM qui s'exécute toutes les heures crée des détections bien après les événements correspondants, et elles sont tout de même importées.
• La première interrogation remonte 24 heures en arrière, donc une nouvelle connexion montre tout de suite des enregistrements récents.
• Tester la connexion, dans la ligne de la connexion, vérifie l'accès au produit et que les workers de Status200 tournent, sans rien importer. Run now interroge immédiatement.

Ce que contient un événement#

Chaque événement est stocké avec des champs typés et son payload source :

Explorer les événements de sécurité#

Événements est un explorateur de télémétrie comme ceux des journaux et des traces : un graphique des événements de la fenêtre par gravité, une barre latérale de facettes, la liste, et un panneau avec chaque champ et attribut de l'événement que vous ouvrez. La fenêtre, les filtres et la recherche sont tous dans l'URL, donc une vue filtrée se partage et survit à un rechargement.

Recherche#

La barre de recherche parle le même langage que les autres explorateurs de télémétrie (voir Syntaxe de recherche) :

Un champ est soit un nom court (severity, class, category, activity, status, vendor, product, rule, user, host, ip, targetuser, targethost, targetip, processname, commandline, parentprocessname, observable, tactic, technique), soit le nom propre du champ, comme severityName ou principalHost. Tout autre nom est lu comme un attribut de la source. observable:<value> trouve chaque événement qui mentionne une valeur, de quelque côté de l'activité qu'elle se trouve.

Facettes#

La barre latérale compte les événements de la fenêtre par Source, Gravité, Classe d'événements, Catégorie, Activité, Statut, Fournisseur, Produit, Règle de détection, Utilisateur source, Hôte source, Processus et Processus parent. Cliquez sur une valeur pour ne garder que ses événements, ou sur le signe moins à côté pour les exclure. Cliquez à nouveau pour annuler. Le graphique et chaque comptage décrivent exactement les événements de la liste.

Corréler#

Corréler dessine les événements autour d'un hôte, d'un utilisateur ou d'une adresse IP : leurs classes d'événements autour de ce que vous avez cherché, marquées par leur pire gravité, et les autres valeurs vues dans les mêmes événements sur l'anneau extérieur. Cliquez sur une classe pour lister ses événements, ou sur une valeur pour corréler ensuite sur elle. Chaque observable du panneau d'un événement dans Événements ouvre Corréler sur lui.

Règles de détection#

Une règle de détection est une règle Sigma, un format YAML ouvert pour décrire une activité suspecte, que Status200 exécute selon un calendrier sur vos événements. Quand elle correspond, elle ouvre un dossier ou s'y ajoute, ouvre une alerte, éventuellement un incident, et écrit un Detection Finding dans les événements. La Rule Library propose des règles prêtes à l'emploi pour démarrer.

Créer une règle#

Une première règle, qui correspond aux échecs de connexion venant de l'extérieur de 10.x.x.x :

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

Ce qu'une règle peut exprimer#

Status200 exécute le noyau booléen de Sigma :

• Les sélections sont des tables de champs (chaque champ doit correspondre ; une liste de valeurs correspond à l'une d'elles) ou des listes de mots-clés, qui correspondent n'importe où dans le message.
• Les conditions combinent des sélections avec and, or, not et des parenthèses, ou avec 1 of selection_*, all of selection_*, any of them et all of them.
• Modificateurs de champ : contains, startswith, endswith, all, re, cased, gt, gte, lt, lte, cidr, exists et windash. Le texte est comparé sans tenir compte de la casse, sauf si vous ajoutez cased.
• Un champ est un champ typé (principalUser), une graphie Sigma courante de l'un d'eux (CommandLine, src_ip, Hostname) ou n'importe quelle clé d'attribut, écrite comme dans l'événement (threat.matched).
• Image et CommandLine lisent le processus dont parle l'événement, celui qui a été lancé lors d'un lancement de processus (processPath, processCommandLine), et ParentImage et ParentCommandLine le processus qui l'a lancé (parentProcessPath, parentProcessCommandLine). principalProcess est le processus qui a agi, c'est-à-dire le parent lors d'un lancement.
• level fixe la gravité : informational, low, medium, high ou critical, et medium s'il manque. Les ID ATT&CK dans tags (attack.t1110, attack.ta0006) remplissent les champs MITRE du constat.

Les agrégations comme | count() by principalIp > 5 sont refusées à l'enregistrement : utilisez plutôt une règle de corrélation, ou Champ de regroupement et Seuil de nombre de correspondances. logsource est purement informatif et ne restreint rien : placez ce filtre dans une sélection, comme className: Authentication. Un timeframe est ignoré, car l'intervalle de la règle fixe sa fenêtre.

Règles de corrélation#

Une corrélation Sigma se déclenche sur plusieurs événements ensemble plutôt que sur un seul. Collez-la dans Sigma Rule (YAML) avec les règles qu'elle lit, sous forme de documents YAML séparés par ---, ou nommez des règles que le projet a déjà par leur name ou leur id Sigma. La Rule Library en propose des prêtes à l'emploi, comme des échecs de connexion suivis d'une réussite.

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

• Un groupe est la valeur des champs de group-by, comme une adresse. Les comptes sont glissants : une rafale que deux exécutions se partagent est quand même comptée en entier dans son timespan, qui dure au plus 24 heures.
• new_value est un type propre à Status200, car Sigma n'a pas de corrélation « vu pour la première fois » : il compare avec jusqu'à 30 jours d'historique. value_sum, value_avg, value_percentile et value_median sont refusés à l'enregistrement.
• La colonne Type de Règles de détection nomme le genre de chaque règle, et le formulaire dit en une phrase ce que la règle recherche.

Paramètres d'évaluation#

Le regroupement et le comptage distinct prennent les mêmes noms de champs que la règle. Avec eux, le seuil dit « autant, de la même chose, en une exécution », sans moniteur par-dessus :

Quand une règle s'exécute#

Status200 vérifie chaque minute quelles règles activées ont dépassé leur intervalle depuis leur dernière exécution. Chaque exécution lit les événements dont l'heure d'événement tombe entre l'exécution précédente et il y a deux minutes, puis avance. Ces deux minutes laissent le temps aux événements encore en route, comme une ligne de journal lue une minute après avoir été écrite :

• Les fenêtres se suivent bout à bout, elles ne glissent pas. Avec un intervalle de 10 minutes, des échecs à 09:58 et à 10:01 peuvent tomber dans des exécutions différentes et sont comptés séparément, donc gardez une marge en choisissant un seuil.
• Après une interruption, comme une panne du worker ou une règle réactivée, l'exécution suivante couvre toute l'interruption, jusqu'aux 24 dernières heures.
• Un événement qui arrive avec plus de deux minutes de retard, une fois qu'une exécution a couvert son heure, est stocké et consultable, mais cette règle ne le lit jamais.
• Chaque groupe qui atteint le seuil devient un Detection Finding, jusqu'à 10 000 par exécution. Des alertes, des incidents et des dossiers s'ouvrent pour les 100 aux comptages les plus élevés ; les autres partagent un dossier sur la règle, et la Dernière erreur de la règle indique combien de groupes ont correspondu.

Gravité#

Le level d'une règle est la gravité de ses constats : informational, low, medium, high et critical deviennent Informational, Low, Medium, High et Critical. Ses alertes et incidents prennent l'une des gravités de votre projet, dans cet ordre :

1. La Gravité de l'alerte (ou Gravité de l'incident) de la règle, si elle est réglée.
2. Votre gravité nommée d'après le niveau, comme High, quelle que soit la casse.
3. Par rang : les règles critical et high prennent votre gravité la plus élevée, les autres la plus basse.

Alertes et constats#

Chaque groupe déclenché ouvre une alerte intitulée [Detection] <rule name> — <group value>, ou [Detection] <rule name> pour une règle sans champ de regroupement. Tant qu'elle est ouverte, d'autres correspondances de ce groupe n'en ouvrent pas d'autre. Une règle ne voit que des correspondances et ne peut pas savoir qu'une attaque a cessé, donc ses alertes restent ouvertes jusqu'à ce que quelqu'un les résolve.

Un Detection Finding est un événement de sécurité de classe Detection Finding (classe OCSF 2004) du produit Status200 Detections, avec les tags MITRE de la règle, la valeur du groupe en premier dans observables, et ces attributs :

Les constats sont des événements ordinaires : recherchez-les dans Événements et pivotez dessus dans Corréler. Pour essayer une nouvelle règle sans bruit, désactivez toutes les actions sauf le constat jusqu'à ce que vous lui fassiez confiance.

Moniteurs d'événements de sécurité#

Un moniteur d'événements de sécurité compte les événements qui correspondent à ses filtres sur une fenêtre glissante et applique au comptage les critères habituels des moniteurs : il change le statut du moniteur, ouvre des alertes ou des incidents, et alerte l'astreinte. Créez-en un sous Moniteurs → Créer un moniteur, avec Événements de sécurité comme type ; il y est listé avec vos autres moniteurs.

Son formulaire affiche Surveiller les événements contenant ce texte, Surveiller les événements de sécurité pendant (durée), Gravité de l'événement et Classe d'événements. Filtrer par service de télémétrie et Filtrer par attributs attendent sous Plus de champs, dont l'en-tête montre ceux qu'un moniteur utilise. Ses critères vérifient Security Event Count.

Écrivez la détection elle-même comme une règle, avec son seuil. Utilisez un moniteur quand vous voulez une fenêtre glissante, un statut qui se rétablit seul, une page de statut ou des politiques d'astreinte différentes par critère.

Surveiller vos détections#

Les constats sont des événements, donc un moniteur peut surveiller les règles elles-mêmes :

• Tempêtes : un moniteur sur la classe Detection Finding, qui compte chaque constat. Vingt règles différentes qui se déclenchent en une heure sont un signal qu'aucune règle seule ne peut voir.
• Changements de rythme : filtrez sur le status200.detection.rule_id d'une règle. Une règle qui se déclenche chaque semaine et soudain cinquante fois par heure appelle une autre réponse.
• Silence : des constats qui tombent à zéro, alors que vous en voyez d'habitude quelques-uns, signifient le plus souvent qu'une source a cessé d'envoyer. Utilisez un critère qui vérifie un comptage inférieur à un nombre.

L'action Créer un moniteur dans la ligne d'une règle ouvre un nouveau moniteur déjà réglé ainsi : la classe Detection Finding, l'ID de la règle (jamais son nom, qu'un renommage changerait) et la dernière heure. Un tel moniteur compte des constats, un par groupe et par exécution, pas les événements qui se trouvent derrière. Pour exiger un nombre d'événements avant tout déclenchement, utilisez le Seuil de nombre de correspondances de la règle.

Renseignement sur les menaces#

Threat Intel s'abonne à des flux STIX/TAXII d'adresses IP, de domaines, d'URL, d'adresses e-mail et de hachages de fichiers malveillants connus. Les événements qui en mentionnent un sont marqués à l'arrivée par des attributs threat.*, sur lesquels les règles et les moniteurs peuvent filtrer, et chaque minute les événements récents sont confrontés aux flux, ouvrant alertes et constats comme une règle. Voir Renseignement sur les menaces.

Conservation et facturation#

Les événements de sécurité sont facturés par Go ingéré, comme le reste de votre télémétrie, et conservés selon votre conservation de télémétrie : la Conservation par défaut (jours) du projet, sous Paramètres du projet → Télémétrie & APM → Rétention des données, ou une conservation réglée sur le service de télémétrie auquel ils appartiennent. Quand la conservation d'un événement prend fin, il est supprimé.

Dépannage#

Étapes suivantes#