Améliorer la détection des menaces avec SIGMA correlation est aujourd’hui possible dans SEKOIA.IO ! Dans cet article, nous discutons de ce qui peut être fait avec et pourquoi il était nécessaire.
Limites de STIX et de STIX Patterning
Lorsque nous avons créé notre moteur de détection des menaces, nous avons examiné les formats de données existants pour déterminer si nous pouvions en utiliser un. Parce que notre vision est que les renseignements sur les cybermenaces sont essentiels à la détection des menaces, nous nous sommes tournés vers STIX et avons découvert que c’était un bon candidat :
- les objets de données observés peuvent être utilisés pour décrire des événements
- STIX Patterning peut décrire des règles de détection.
Mais comme notre produit et notre utilisation les cas ont évolué, nous avons dû faire face à certaines limites.
Tout d’abord, les objets Observed Data que nous avons utilisés pour représenter les événements étaient loin d’être idéaux. Nous avons rencontré des problèmes pour indexer correctement les événements et le modèle STIX n’est pas adapté à la recherche. Pour ces raisons, nous avons décidé d’utiliser à la place Elastic Common Schema (ECS).
([process:command_line LIKE ‘quser%’] AND [process:command_line LIKE ‘dir%’] AND [process:command_line LIKE ‘net%’]) WITHIN 30 SECONDS
À première vue, ce modèle peut sembler faire ce que nous voulons. Mais il y a un problème majeur : il n’y a aucun moyen avec STIX Patterning de limiter la portée des événements auxquels cette logique de détection s’applique. Lorsque nous surveillons l’ensemble du périmètre, cela signifie en réalité : « quser » n’importe où et « dir » n’importe où et « net » n’importe où dans les 30 secondes. Ce que nous souhaitions vraiment, c’était appliquer cette logique au même nom d’hôte et potentiellement au même utilisateur.
Ne vous méprenez pas, nous pensons toujours que STIX est le meilleur moyen de modéliser Threat Intelligence et notre plateforme Threat Intelligence l’utilise intensivement. Mais pour une détection puissante, nous avions besoin d’autre chose.
Sigma à la rescousse !
À l’époque, il ne semblait pas y avoir de remplacement évident qui fournissait toutes les fonctionnalités que nous envisagions jusqu’à ce que cela sorte :
Sigma était déjà le format le plus adopté pour les règles de détection, donc l’ajout de ces caractéristiques de corrélation en ont fait l’option complète que nous recherchions. Cela a lancé un long processus de transition de notre logique de détection vers Sigma qui s’est terminé cette semaine avec la sortie de la prise en charge native des corrélations Sigma dans SEKOIA.IO. La principale amélioration de Sigma Correlations, par rapport à STIX Patterning, est l’ajout d’une fonction « group-by ». Notre exemple précédent pourrait être corrigé avec la règle suivante :
name:quser_recon
detection:
selection:
process.command_line|startswith:quser
condition:selection
–––
name:dir_recon
detection:
selection:
process.command_line|startswith:dir
condition:selection
–––
name:net_recon
detection:
selection:
process.command_line|startswith:net
condition:selection
–––
action:correlation
type:temporal
rule:
-quser_recon
-dir_recon
-net_recon
group-by:
-user.name
-log.hostname
timespan:30s
ordered:false
Sigma Correlations prend également en charge un type « event_count » pour faire correspondre plusieurs événements similaires. A titre d’exemple, voici une règle pour détecter lorsqu’un « user.name » échoue à se connecter plus de 5 fois en l’espace de 5 minutes :
–––
name:login_failed
detection:
selection:
event.category:authentication
event.outcome:failure
condition:selection
–––
action:correlation
type:event_count
rule:login_failed
group-by:user.name
timespan:5m
condition:
gte:5
Enfin, le «value_count» peut être utilisé pour créer des règles de détection basées sur nombre de valeurs uniques dans un champ. A titre d’exemple, voici une règle pour détecter lorsqu’un «user.name» ne parvient pas à se connecter à plus de 5 «log.hostname» en l’espace de 5 minutes :
name:login_failed
detection:
selection:
event.category:authentication
event.outcome:failure
condition:selection
–––
action:correlation
type:value_count
rule:login_failed
group-by:user.name
timespan:5m
field:log.hostname
condition:
gte:5
Différences notables
Nous sommes ravis de prendre désormais en charge les corrélations Sigma et Sigma dans SEKOIA.IO. Cela dit, quelques points rendent notre implémentation différente d’un support Sigma typique. Ils méritent d’être mentionnés :
- Nous utilisons directement des champs normalisés du format ECS à l’intérieur des règles.
- La spécification Sigma Correlations n’est pas encore incluse dans la version actuelle de Sigma. À notre connaissance, nous sommes les premiers à le soutenir.
- Nous avons ajouté une propriété « alias » à couvrir des cas d’utilisation plus complexes.
- Alors que Sigma est généralement utilisé pour convertir des règles en un langage de requête, notre prise en charge de Sigma est intégrée directement dans notre moteur de détection en temps réel. Cela signifie des détections plus rapides, vous permettant de réagir rapidement aux cyberattaques.
Des détails supplémentaires sur notre soutien à Sigma peuvent être trouvés dans notre documentation publique.
Lire aussi :
Échangez avec l’équipe
Vous souhaitez en savoir plus sur nos solutions de protection ? Vous voulez découvrir nos produits de XDR et de CTI ? Vous avez un projet de cybersécurité dans votre organisation ? Prenez rendez-vous et rencontrons-nous !
