Suivre Chaque équipe de détection connaît ce moment. Une règle est écrite ou téléchargée, révisée, traduite dans le langage de requête du SIEM, et déployée. Le statut indique activé, le nombre de règles augmente, et le rapport de couverture devient un peu plus vert.
Rien de tout cela ne vous dit si la règle détectera l’attaque pour laquelle elle a été écrite. Une règle peut être bien écrite et ne rien trouver, car sa logique, ses données ou sa traduction sont silencieusement en désaccord avec la réalité. Et comme une règle qui ne déclenche jamais semble la même qu’une règle sans rien à attraper, le problème peut rester caché longtemps.
Cet article explique ce qui sépare une règle fonctionnelle d’une règle défaillante, où les règles se trompent habituellement, et ce que vous pouvez faire avec SOC Prime pour prouver qu’une règle fonctionne avant de la livrer et la maintenir fonctionnelle par la suite.
Ce que signifie réellement « fonctionner »
Une règle de détection fonctionnelle fait trois choses. Elle exprime la bonne logique pour le comportement qu’elle cible. Elle fonctionne sur des données qui contiennent réellement ce comportement. Et elle est correctement écrite pour la plateforme sur laquelle elle fonctionne. Si l’une de ces conditions échoue, la règle est défaillante, même si elle est activée et n’affiche aucune erreur.
Ce cadrage aide parce que chaque échec a une cause différente et une solution différente :
- Problèmes de logique résident dans la règle elle-même. Elle est trop étroite pour attraper des variations du comportement, ou si large qu’elle correspond à une activité normale.
- Problèmes de données résident dans l’environnement. Les événements dont la règle a besoin ne sont pas consignés, pas collectés, ou manquent des champs sur lesquels la règle repose.
- Problèmes de traduction résident dans le passage entre les langages. Le sens de la règle change lorsqu’elle est convertie en syntaxe de requête d’une plateforme.
La plupart des équipes vérifient soigneusement la première lors de l’écriture d’une règle. Ce sont la deuxième et la troisième où les règles ont tendance à se casser sans que personne ne le remarque.
Où les règles fonctionnelles se trompent
Une logique qui ne correspond pas au comportement. Une règle basée uniquement sur le nom de fichier d’un outil est facile à contourner en renommant le fichier. Une règle basée sur un motif de ligne de commande courant, sans filtrage, peut correspondre aux administrateurs toute la journée. Aucune de ces erreurs n’est visible lors du déploiement. La première apparaît lorsqu’un attaquant la contourne, la seconde comme un bruit d’alerte.
Les données qui ne sont pas là. Une règle de création de processus qui dépend des arguments de ligne de commande est inutile si la journalisation des lignes de commande n’est pas activée, car l’événement arrive sans le champ. Il en va de même pour une source de journal qui n’a jamais été intégrée, ou un agent qui a cessé d’envoyer. La règle fonctionne selon le calendrier, ne trouve rien, et semble saine.
Des champs qui signifient des choses différentes à différents endroits. Le même concept peut avoir différents noms selon les produits, et même les modèles de données de différents fournisseurs sont des contrats séparés. Splunk CIM et Microsoft Sentinel ASIM en sont un bon exemple : un champ qui existe dans l’un peut ne pas exister dans l’autre. Une traduction caractère par caractère produit une règle qui référence des champs que la destination ne populera jamais.
Une traduction qui change le sens. Les traducteurs automatiques gèrent bien la logique de sélection simple, mais les règles de corrélation et les fonctions propriétaires nécessitent généralement une revue humaine. Les plateformes diffèrent également dans la façon dont elles traitent les détails tels que la sensibilité à la casse, les jokers et les expressions régulières. Une règle peut être traduite « avec succès » et se comporter encore différemment de l’originale.
Des limites de la plateforme qui retirent de bonnes règles. Les SIEM limitent le nombre de règles pouvant être exécutées. Les équipes désactivent régulièrement les règles fonctionnelles pour faire de la place pour de nouvelles, de sorte que la couverture diminue sans que personne ne décide qu’elle devrait.
Pourquoi c’est important
Chacun de ces problèmes laisse le nombre de règles et le tableau de bord inchangés. Les chiffres de couverture qui comptent les règles déployées surestiment donc la protection, et le fossé fait généralement surface lors d’un incident, lorsque l’on découvre que la règle qui aurait dû déclencher ne pourrait jamais le faire.
Il y a un deuxième coût : une règle silencieuse est ambiguë. Si rien ne déclenche, est-ce que l’environnement est propre, est-ce que la télémétrie manque, ou est-ce que la logique est fausse ? Déterminer cela après coup signifie vérifier la logique, les données et la traduction l’une après l’autre. Il est beaucoup moins coûteux de rassembler des preuves tôt et de les garder à jour.
Comment SOC Prime vous aide à prouver qu’une règle fonctionne
La validation de détection est vraiment une chaîne de questions : de quoi cette règle a-t-elle besoin, mon environnement le fournit-il, la règle se comporte-t-elle comme prévu sur mes données, et sinon, que devrait-on changer ? SOC Prime soutient chaque étape.
Comprendre les exigences de détection
La validation commence avant tout test. SOC Prime fournit des informations contextuelles autour du contenu de détection, y compris son comportement prévu, les exigences en télémétrie, la cartographie MITRE ATT&CK, les faux positifs potentiels et d’autres métadonnées. Cela donne aux ingénieurs en détection un point de départ pour décider si une détection est applicable à leur environnement et quelles conditions préalables doivent être en place avant qu’elle ne soit testée. Une règle qui nécessite la journalisation des lignes de commande, par exemple, vous le dit dès le départ, au lieu de vous laisser le découvrir plus tard.
Évaluer la télémétrie disponible
Une fois que vous savez de quoi une règle a besoin, la prochaine question est de savoir si vous l’avez. Prime Hunt peut aider les équipes à évaluer la relation entre leurs données disponibles et la couverture de détection potentielle. Data Audit analyse les données de journal disponibles et les cartographie à MITRE ATT&CK pour identifier les lacunes potentielles de visibilité. Cela vous aide à déterminer si un manque de couverture de détection provient d’une télémétrie manquante plutôt que d’un contenu de détection manquant, qui sont deux problèmes très différents avec deux solutions très différentes.
Tester les détections par rapport aux données organisationnelles
Prime Hunt peut également exécuter des analyses de détection par rapport aux données des environnements connectés. Tester les détections par rapport à des données réelles vous donne des preuves de la façon dont le contenu se comporte dans votre environnement, plutôt que de vous fier uniquement à une validation théorique. Les résultats de l’analyse aident à identifier les détections qui produisent des correspondances pertinentes, et mettent en évidence celles qui nécessitent une enquête ou un ajustement supplémentaire.
Enquêter et améliorer la logique de détection
Lorsqu’une détection nécessite une modification, SOC Prime fournit des capacités d’ingénierie de détection via Prime Core et Prime Architect. Le contenu de détection peut être révisé, personnalisé, traduit et optimisé pour l’environnement cible. Cela prend en compte les différences de schémas, de mappages de champs, de langages de requête et de exigences spécifiques à l’environnement sans traiter chaque détection problématique comme une toute nouvelle tâche de développement.
En pratique, cela signifie :
- Traduisez pour la plateforme que vous utilisez. Toutes les règles Sigma sur la plateforme sont déjà traduites dans tous les langages et formats SIEM pris en charge, de sorte que vous pouvez prendre la requête pour votre pile et la déployer immédiatement. Pour tout ce qui est personnalisé, ou pour vos propres règles Sigma, utilisez l’espace de travail de traduction dans Prime Architect pour les convertir dans le langage de requête natif de votre SIEM, EDR, XDR ou data lake. Sigma reste la source, de sorte qu’une modification faite une fois peut être traduite à nouveau au lieu d’être éditée manuellement dans chaque plateforme.
- Mappez des tables, champs et valeurs selon votre schéma. Le mappage de champ personnalisé vous permet de définir des profils qui mappent vos tables, champs et valeurs non standard selon les valeurs par défaut. Créez un profil une fois, puis appliquez-le chaque fois que vous déployez une règle ou envoyez une requête.
- Ajoutez des filtres qui correspondent à votre environnement. Les filtres ajoutent des conditions à la logique de détection avant le déploiement pour inclure ou exclure des utilisateurs, hôtes ou autres ensembles d’éléments spécifiques. Ils empêchent une activité connue-bénigne de transformer une bonne règle en une règle bruyante, sans réécrire la règle elle-même.
- Enregistrez les paramètres de déploiement en tant que préréglages. Les préréglages stockent des paramètres tels que la période de requête, la sévérité et l’état de la règle, de sorte que les déploiements restent cohérents.
- Valider, optimiser et affiner. L’espace de travail de traduction valide et optimise également le contenu de détection. Il ne remplace pas l’examen : vérifiez chaque champ par rapport au schéma de destination, et examinez de près tout ce qui est signalé, en particulier la logique de corrélation et les fonctions spécifiques à la plateforme. Lorsqu’un changement va au-delà des mappages et des filtres, éditez le code directement, traduisez-le à nouveau, et enregistrez-le dans votre dépôt personnalisé en tant que mise à jour ou nouvelle règle.
- Recherchez et ajustez avec l’espace de travail assisté par IA. Utilisez-le pour rechercher le comportement qu’une règle cible et travailler sur les modifications de sa logique. Les ingénieurs restent en contrôle et examinent chaque modification avant de la livrer.
Identifier les lacunes de couverture
La validation de détection devrait aussi répondre à ce qui n’est pas détecté. Data Audit dans Prime Hunt fournit une analyse de couverture basée à la fois sur la télémétrie disponible et le contenu de détection. Cela aide les équipes à distinguer entre les lacunes causées par une visibilité insuffisante et celles causées par des règles de détection manquantes ou inappropriées. Cette distinction informe la prochaine action d’ingénierie : collecter plus de données, ajuster une détection existante, ou identifier et développer du contenu de détection supplémentaire.
Continuer à valider au fil du temps
L’efficacité de la détection change à mesure que les environnements et le contenu de détection évoluent. La validation récurrente avec Prime Hunt permet aux équipes de réévaluer les détections par rapport aux données actuelles plutôt que de se fier indéfiniment à un résultat de validation initial. Cela est particulièrement important dans les environnements où les configurations de journalisation, les schémas de données, l’infrastructure ou le contenu de détection changent fréquemment.
Preuve plutôt qu’hypothèse
Une règle déployée est une revendication. Une règle qui a été testée avec des données réelles est une preuve. La différence est facile à négliger, car les deux semblent identiques dans une liste de règles et restent silencieuses jusqu’à ce qu’une attaque survienne.
SOC Prime aide les équipes à combler cette lacune. Cela commence par des exigences de détection claires et un aperçu honnête de la télémétrie disponible, teste les détections par rapport à vos propres données, et vous donne les outils pour corriger ce qui ne convient pas. L’analyse de couverture montre ensuite si les lacunes restantes nécessitent plus de données, un meilleur ajustement ou un nouveau contenu, et la validation récurrente maintient la réponse à jour à mesure que votre environnement évolue. Commencez avec les règles qui comptent le plus, et découvrez lesquelles déclencheraient réellement.
