Je suis Sergey Rublev, chef du SOC (Security Operations Center) à Infosecurity.
Dans cet article, j'examinerai en détail l'ambitieux projet
Sigma Rules , dont la devise est: "Sigma pour les journaux est comme Snort pour le trafic et Yara pour les fichiers."
Il s'agira de trois aspects:
- Applicabilité de la syntaxe des règles Sigma pour maintenir une base de connaissances des scripts de détection des menaces
- Capacités des outils de génération de règles pour les systèmes SIEM en boîte
- Valeur pour le SOC du contenu actuel des référentiels publics des règles Sigma
Il était une fois, dans une galaxie lointaine
Tout a commencé il y a quelques années, lorsque les arbres étaient grands et que notre équipe de surveillance était encore petite. Nous avons été confrontés à de nombreuses questions, presque toutes les équipes qui évoluent en trois personnes passent par là.
Les raisons de l'apparition des questions sont différentes:
- Croissance d'équipe
- Rotation du personnel
- Un grand nombre de systèmes hétérogènes de surveillance
Si vous devez prendre en charge un support déjà configuré par quelqu'un SIEM, le nombre de questions augmente comme une avalanche.
Utiliser la bibliothèque de cas
L'expérience mondiale dans la construction de centres de surveillance a déjà trouvé une solution pour organiser le chaos et son nom est la bibliothèque d'études de cas. Le but de chaque cas est de décrire de manière exhaustive la solution à un problème dans le cadre de la surveillance de la sécurité de l'information.
La composition des connaissances fixée dans chaque cas peut varier; nous partons de l'ensemble suivant:
- Objectif - la tâche résolue par l'affaire
- Menace - menace que la règle de détection cherche à détecter.
- Parties prenantes - personnes intéressées par cette règle: IB / IT / Business
- Exigences en matière de données - l'ensemble de données requis pour identifier une menace
- Logique - Logique des règles de détection des menaces
- Testing - un algorithme pour tester l'exactitude de la règle de détection
- Priorité - priorité du traitement des événements par cas (généralement calculée à partir des dommages potentiels d'une menace mise en œuvre avec succès)
- Sortie - Une liste d'actions pour analyser l'alerte, une description des sorties correctes de la procédure d'analyse et la composition des données enregistrées dans les résultats d'analyse
Exemple de cas d'utilisation pour la tâche de détection de la communication avec le serveur de gestion de botnet (communément appelé C&C ou simplement C2):
L'exemple est grandement simplifié; en réalité, avec une description correcte, un cas se transforme en un document de plusieurs pages.
À ce moment, lorsque le nombre de cas dépassait plusieurs dizaines, nous avons commencé à chercher des outils prêts à l'emploi pour maintenir une telle base de connaissances, ayant de préférence, en plus de convivialité humaine, également une sorte d'interface conviviale pour le travail.
Projet Sigma
Le projet Sigma mérite certainement d'être examiné dans le contexte de la base de connaissances sur les règles de détection des incidents. Cela a commencé en 2016, et je l'ai suivi presque depuis le tout début.
En fait, le projet consiste en
- Sigma se règle
- Utilitaires pour convertir des règles en requêtes pour divers systèmes SIEM
La liste SIEM est impressionnante: presque toutes les solutions d'analyse d'événements populaires sont présentes. Plus sur tout en détail et dans l'ordre.
Syntaxe des règles
Les règles Sigma sont des documents YAML décrivant un scénario de détection d'une attaque spécifique. Syntaxiquement, les règles se composent des blocs suivants:
Informations méta
Partie descriptive pour structurer et simplifier la recherche des règles nécessaires.
title: Access to ADMIN$ Share description: Detects access to $ADMIN share author: Florian Roth falsepositives: - Legitimate administrative activity level: low tags: - attack.lateral_movement - attack.t1077 status: experimental
Je voudrais également noter que de nombreuses règles sont déjà fournies avec des liens vers la technique d'attaque selon la méthodologie MITRE ATT & CK.
Déclaration de source de données
Description de la source basée sur les événements dont la logique de détection est implémentée.
logsource: product: windows service: security
Il est syntaxiquement possible de décrire à la fois le service final d'un produit particulier et toute une catégorie de systèmes.
Traitement de la déclaration logique
Au niveau de la logique de détection, les éléments suivants sont décrits:
- Modèles recherchés
- Valeurs de certains champs du journal
- Calendrier
- Fonctions d'agrégation
La logique peut être triviale, par exemple, des conditions imposées à un ensemble de champs:
detection: selection: EventID: 5140 ShareName: Admin$ filter: SubjectUserName: '*$' condition: selection and not filter
et assez compliqué:
detection: selection1: EventID: - 529 - 4625 UserName: '*' WorkstationName: '*' selection2: EventID: 4776 UserName: '*' Workstation: '*' timeframe: 24h condition: - selection1 | count(UserName) by WorkstationName > 3 - selection2 | count(UserName) by Workstation > 3
Les moyens expressifs du langage, bien que non universels, sont encore assez larges et permettent de décrire un grand nombre de cas pour identifier des attaques.
Outils de développement de règles
En plus de votre éditeur de texte préféré pour YAML, l'interface utilisateur Web de SOC Prime est également disponible, ce qui vous permet à la fois de valider la syntaxe d'une règle déjà écrite et de créer des règles manuellement à partir de blocs graphiques.
Sigma comme outil de base de connaissances
Pour résumer un bref résumé.
Pour le moment, la syntaxe des règles se concentre principalement sur la description de la logique de détection des menaces et n'est pas destinée à une description complète du cas d'utilisation; en conséquence, il ne fonctionnera pas pour maintenir une bibliothèque à part entière en utilisant uniquement les règles Sigma.
Pour la structure de cas d'utilisation que nous avons choisie, Sigma n'en ferme que la moitié (objectif, exigences de données, logique et priorité).
Convertir en divers SIEM
Étant donné que nous sommes un fournisseur de services SOC, l'idée de garder tous nos développements selon les règles de corrélation dans un format universel et au stade de la mise en œuvre pour convertir au format SIEM souhaité nous a semblé très attrayante.
Le projet comprend des utilitaires de console pour générer des demandes d'événements au format de divers SIEM. Considérez ce qu'est la conversion et ce qui se trouve sous son capot.
La conversion se déroule en 3 étapes:
- Règles d'analyse - je pense que cela est clair: le document YAML est trié en blocs de composants
- Réduction à la taxonomie SIEM
La nécessité de cette étape est liée au fait que la normalisation dans les systèmes SIEM est implémentée de manière légèrement différente, de sorte que les déclarations des règles Sigma doivent être réduites à la taxonomie des événements du SIEM sélectionné. - Génération de demandes pour SIEM
Pour que cette étape fonctionne, un autre composant est requis - un backend pour ce SIEM.
En fait, le backend est un plug-in pour l'utilitaire de conversion, qui contient la logique de conversion au format de demande final dans SIEM. Les blocs de détection et de source de journal sont convertis en tenant compte du mappage de champs précédemment superposé, des informations supplémentaires spécifiques à SIEM sont ajoutées.
Par conséquent, le démarrage de l'utilitaire de conversion ressemble à ceci:
Les paramètres suivants sont transmis:
- SIEM cible
- La règle
- Fichier de mappage pour ce SIEM
SOC Prime dispose également d'une interface utilisateur prête à l'emploi pour la fonction de conversion (
uncoder.io )
Pièges de la conversion
- Après avoir étudié la mécanique de conversion, nous avons rencontré des limitations importantes, qui nous ont empêché de convertir tous les développements au format Sigma:
- Le convertisseur fonctionne uniquement sur demande. La règle de corrélation dans SIEM affecte plus d'aspects: fenêtre temporelle, agrégation, actions basées sur les résultats des alertes identifiées
- Les principales caractéristiques des SIEM individuels, telles que les listes actives, ne sont pas prises en compte.
- Détails insuffisants du mappage de champs - dans le cadre de la configuration du mappage, les champs de seulement quelques sources sont décrits; en conséquence, ayant des règles pour plusieurs dizaines de types de sources d'événements dans la base de données, vous devrez investir massivement dans l'écriture du mappage.
Base de règles
Voyons ce que contient la base de règles Sigma accessible au public. Actuellement, le contenu est activement ajouté à deux référentiels:
- Le référentiel principal du projet
- Marché de détection des menaces SOC Prime
Les règles dans les référentiels ont une intersection non nulle.
SOC Prime a un certain nombre de règles qui s'appliquent aux abonnements payants; je ne considère pas leur contenu dans cet article.
Pour l'analyse, nous avons besoin de la bibliothèque
sigmatools pour Python et de quelques compétences en programmation.
Pour analyser et charger des règles d'un répertoire dans un dictionnaire, vous pouvez utiliser le code suivant:
from sigma.parser.collection import SigmaCollectionParser import pathlib import itertools def alliter(path): for sub in path.iterdir(): if sub.name.startswith("."): continue if sub.is_dir(): yield from alliter(sub) else: yield sub def get_inputs(paths, recursive): if recursive: return list(itertools.chain.from_iterable([list(alliter(pathlib.Path(p))) for p in paths])) else: return [pathlib.Path(p) for p in paths] BASE_PATH = [r'sigma\rules'] path_list = get_inputs(BASE_PATH, True) rules_map = {} for sigmafile in get_inputs(BASE_PATH, True): f = sigmafile.open(encoding='utf-8') parser = SigmaCollectionParser(f) rule = next(iter(parser)) rules_map[rule['title']] = rule
En dédoublant les mêmes règles, l'image suivante émerge:
Dans le cadre d'une liste unique de règles, nous obtenons les distributions suivantes:
Par type de source d'événement:Un peu plus de statistiques
- Windows ~ 80%
- Sysmon ~ 53%
- Proxy ~ 8%
- Linux ~ 4%
Fondamentalement, le contenu actuel se concentre sur le système Windows et Sysmon, en particulier, les règles pour le reste des systèmes sont quelques-unes.
Par disponibilité de contenu:Il s'avère que les développeurs de règles Sigma ont marqué comme stable moins de 20% de toutes les règles existantes.
Pour résumer
Dans les sources accessibles au public, il existe un grand nombre de règles. Ils sont régulièrement mis à jour et les règles de détection des indicateurs, et parfois même le technicien des entreprises APT les plus en vue, apparaissent rapidement.
Il existe de nombreuses restrictions pour appliquer les règles dans la vie réelle:
- Il existe de nombreuses règles pour Microsoft Sysmon, qui est rarement utilisé en entreprise.
- Il existe de nombreuses règles qui effectuent réellement des vérifications IoC (hachages, adresses IP, URL, agents utilisateurs). De telles règles deviennent rapidement obsolètes et il existe des mécanismes plus efficaces pour trouver l'IoC que les règles.
- Beaucoup de contenu expérimental, respectivement, des exigences supplémentaires sont imposées sur les tests de haute qualité avant la mise en service.
Chez Infosecurity, nous utilisons le contenu des règles Sigma comme source supplémentaire de connaissances pour une détection plus efficace des incidents. Si nous trouvons quelque chose d'intéressant, nous le mettrons déjà en œuvre dans le cadre de nos règles de corrélation, qui prennent en compte à la fois le noyau sur lequel les règles fonctionnent (Apache Spark) et les spécificités des infrastructures et des moyens de protection que nous utilisons.