Gains :
- Comprendre que l'intelligence artificielle résume et regroupe des milliers de lignes de journal, établit une chronologie et met en évidence des modèles suspects, mais l'analyste décide que l'événement est une véritable attaque avec le journal brut
- Capacité à appliquer une ligne de base (comportement normal) lors de l'évaluation d'une alarme SIEM et comment éliminer les faux positifs sans contexte et comment l'anomalie ne peut pas être interprétée
- Capacité à prendre l'habitude de vérifier la chaîne d'événements établie par l'intelligence artificielle dans le journal brut et de supprimer les fausses corrélations
Un analyste de sécurité passe la majeure partie de sa journée à lire des journaux. Un journal est une ligne de texte qui horodate ce qui s'est passé sur un système : qui s'est connecté à quel moment, quel fichier a été consulté, quelle connexion a été rejetée. Le problème n’est pas qu’il y ait trop peu de bûches, c’est qu’il y en a tellement que c’est étouffant. Une organisation de taille moyenne produit des centaines de millions de lignes de journaux par jour. Dans ce tas, la trace d’une véritable attaque est l’aiguille dans la botte de foin. SIEM (Security Information and Event Management - le système qui collecte et corrèle les journaux de différentes sources dans un seul centre et produit des alarmes basées sur des règles) est là pour trouver cette aiguille ; mais la plupart des alarmes générées par SIEM sont également des faux positifs (alarmes inutiles qui ne constituent pas réellement des menaces). Le véritable travail de l’analyste est d’extraire le vrai signal de ce bruit.
L’intelligence artificielle est une aide puissante dans ce tri. Il peut lire des milliers de lignes de journal en quelques secondes et les résumer en langage humain, regrouper des modèles récurrents, décrire une chaîne d'événements comme « d'abord ceci s'est produit, puis cela » et expliquer pourquoi une alarme semble suspecte. Mais l'IA ne sait pas ce que signifie le journal dans le contexte de l'établissement : « un accès à 3 heures du matin » est une agression dans un établissement, un quart de nuit normal dans un autre. Ainsi, l'IA résume et signale le journal, mais l'analyste décide si un événement est une véritable attaque et le vérifie avec le journal brut.
Étapes de l'analyse des journaux
Voici comment exécuter une analyse de journal/SIEM étape par étape avec l'IA :
- Collectez et anonymisez. Supprimez le fragment de journal concerné ; remplacez les adresses IP réelles, les noms d'utilisateur et les noms d'hôte internes par des espaces réservés (USER_A, IC_IP_1). N’exportez jamais de données brutes telles quelles vers un outil externe.
- Donnez le contexte. Indiquez à l'IA la source du journal (pare-feu, journal des événements Windows, serveur Web), quel est le comportement normal et ce que vous recherchez. L'analyse des journaux sans contexte est trompeuse.
- Résumer et regrouper. Demandez à l'IA de regrouper des milliers de lignes par types d'événements, d'extraire le nombre d'occurrences et de créer une chronologie.
- Faites signaler les modèles suspects. Mettez en surbrillance des modèles tels que « une connexion réussie après des connexions infructueuses », « de nombreux accès aux fichiers sur une courte période de temps », « une connexion réseau appartenant à un processus inconnu ».
- Vérifiez avec des preuves brutes. Recherchez et confirmez chaque modèle signalé par l'IA dans les lignes de journal réelles. Scannez également par vous-même les zones qui manquent à l'IA.
- Décision et enregistrement. Déclarez l'événement réel en tant qu'analyste, ouvrez un ticket et documentez que l'IA n'est qu'un accélérateur.
Quelques termes : La source du journal est le système qui produit le journal. La corrélation consiste à rassembler des événements provenant de différentes sources et à leur donner un sens (connexion VPN + accès aux fichiers + transfert de données = fuite possible). Une ligne de base est une mesure du comportement normal d'un système ; L'anomalie n'a de sens que par rapport à la ligne de base. UEBA (User and Entity Behavior Analytics) est une approche basée sur l'IA qui apprend le comportement normal de chaque utilisateur et signale les écarts.
tableau comparatif
Approche
Comment ça marche
point fort
faiblesse
SIEM basé sur des règles
Correction des règles "si-alors"
Transparent, explicable
Manque une attaque inconnue, beaucoup de faux positifs
Détection basée sur les signatures
Correspond à un mauvais modèle connu
Rapide sur menace connue
Aveugle aux attaques nouvelles/modifiées
Anomalie/UEBA (AI)
Trouve un écart par rapport à la normale
Peut capturer l'inconnu
Anomalie = pas d'attaque ; risque de faux positifs
Résumé avec l'IA
Résume la langue de connexion
Rapidité, lisibilité
Pas de contexte, risque d'hallucination
Analyste (humain)
Commentaires avec contexte
décision, responsabilité
Lent, se fatigue, n'évolue pas
La bonne configuration ne consiste pas à en choisir un mais à les superposer : le SIEM et la signature filtrent grossièrement le bruit, l'IA résume et met en évidence, l'analyste vérifie et décide.
trois mini-cases
Cas 1 : 50 000 lignes, 6 minutes. Un analyste anonymise 50 000 lignes de journaux d’accès d’un serveur Web à l’IA. L'IA en déduit qu'une seule IP externe a exploré les routes /admin avec 12 000 requêtes en 3 heures, essayé 480 paramètres différents et reçu 200 réponses 3 fois. L'analyste trouve ces 3 requêtes réussies dans le journal brut, vérifie qu'il s'agit d'une véritable attaque par énumération de chemin et bloque l'adresse IP. Lire 50 000 lignes à la main prendrait des heures ; Le résumé l'a réduit à 6 minutes, mais c'était la décision de l'analyste.
Cas 2 — Corrélation artificielle. Un autre analyste dit à l'IA : « décrivez la chaîne d'attaque dans ce journal ». L'IA construit une histoire fluide : "À 02h11, USER_B a élevé ses privilèges et exporté les données." L'analyste ouvre le journal brut avant de l'écrire dans le rapport ; alors que dans le journal, il n’y a ni élévation de privilèges ni transfert de données – le modèle intègre une chaîne d’événements typique dans « l’histoire de l’attaque ». L'analyste extrait la réclamation. Leçon : Chaque chaîne indiquée par l'IA doit être vérifiée dans le journal.
Cas 3 — Faux positif pour l’équipe de nuit. Un modèle UEBA signale qu'un utilisateur accédant à 900 fichiers à 3 heures du matin constitue une « anomalie à haut risque ». L'analyste vérifie le contexte : l'utilisateur est un opérateur de secours et ce travail s'exécute à 03h00 tous les soirs ; La ligne de base n’a pas été examinée. L'alarme est un faux positif. L'analyste définit la règle et ajoute cet opérateur à la liste d'exceptions. L'anomalie n'est pas toujours une attaque ; Sans contexte, l’alarme est du bruit.
Invite faible/Invite forte
Invite faible :
Examinez ce journal, dites-moi s'il y a une attaque.[10.14.2.7 - ahmet.yilmaz - 200 - /admin ...]
Cette invite contient l'adresse IP et l'utilisateur réels (violation de la vie privée), n'indique pas la source du journal et le comportement normal, ne demande pas à l'IA des preuves et une évaluation faussement positive. L'IA peut vous induire en erreur avec une seule phrase : « oui, il y a une attaque ».
Invite puissante :
Votre rôle : Assistant de l'analyste SOC préparant l'analyse DRAFT. Ne décidez pas, ne déclarez pas d'attaque. Il s'agit d'un journal d'accès anonymisé d'un serveur Web (les adresses IP et les utilisateurs sont masqués). Trafic normal : 100 à 300 requêtes/heure pendant les heures de bureau, principalement des itinéraires /produits et /carts. Votre tâche : (1) regrouper les événements par type et source, indiquer le nombre d'occurrences, (2) les modèles d'indicateurs qui s'écartent de la ligne de base, (3) montrer pour chaque indicateur sur quelles lignes de journal il est basé, (4) noter la probabilité d'un faux positif pour chacun et pourquoi. Insertion de la ligne de montage/IOC ; Marquez "[analyste vérifier]" là où vous n'êtes pas sûr. [journal anonyme ici]
L'affirmation forte limite le rôle, fournit un contexte et une base de référence, et nécessite un engagement avec des preuves et une évaluation des faux positifs.
Modèles d'invite copiables
MODÈLE DE RÉSUMÉ DU JOURNALLa [source du journal anonyme suivante : par ex. Résumez le journal [pare-feu] : (1) regroupez par types d'événements et indiquez le nombre d'occurrences de chaque groupe, (2) extrayez le nombre de sources/cibles uniques, (3) établissez une chronologie (premier-dernier événement, heures de pointe), (4) répertoriez les 5 anomalies importantes avec une ligne de preuves. Prise de décision; juste en résumé. Journal : [coller]
MODÈLE DE CORRÉLATION Corréler les événements anonymes au fil du temps et de l'entité et construire une chaîne possible d'événements ; MAIS, pour chaque étape, indiquez sur quelle ligne de journal elle est basée et marquez l'étape qui n'a aucune base comme "[aucune base - doit être vérifiée]". Écrivez également une explication alternative bien intentionnée. Événements : [coller]
MODÈLE D'ÉLIMINATION DES FAUX POSITIFSPour cette alarme, générez au moins 3 explications bien intentionnées (faux positifs) pour l'interprétation de l'attaque et notez le journal/preuve supplémentaire que je dois consulter pour vérifier chacune d'entre elles. Déterminez ensuite quelles preuves supplémentaires sont en faveur de l’attaque et lesquelles sont contre. Alarme : [coller]
MODÈLE D'EXTRACTION DE TIMELINE : Une seule chronologie chronologique est extraite de ces journaux anonymes : chaque ligne au format [heure] [entité] [événement] [journal source]. Ajout d'un événement sans horodatage. Ne comblez pas les lacunes ; S'il manque, écrivez "[manquant]". Journaux : [coller]
Erreurs courantes
- Analyse sans contexte. Les commentaires formulés sans mentionner la source du journal et le comportement normal (référence) sont trompeurs ; « anomalie » prend du sens avec le contexte.
- Ne pas vérifier la chaîne établie par l'IA. Le modèle peut relier des événements ordinaires à une histoire d’attaque ; Confirmez chaque étape dans le journal brut.
- Prendre une anomalie pour une attaque. Le signe de l'UEBA est une hypothèse ; Éliminez les causes innocentes telles que la sauvegarde, la maintenance, les nouveaux logiciels.
- Exporter des données brutes sans masquage. La véritable adresse IP/utilisateur/hôte est à la fois une violation du KVKK et un cadeau de carte réseau à l'attaquant.
- Ne vous fiez pas au résumé négatif et arrêtez de naviguer. Exécutez votre propre requête systématique (types d'incidents critiques, nouveaux IOC) même si l'IA dit "rien d'important".
Astuce : demandez toujours à "afficher la ligne de preuve" lorsque vous demandez à l'IA de résumer le journal. Ne prenez pas au sérieux toute conclusion sans éléments de preuve ; Cette règle élimine la plupart des hallucinations.
Attention : rejeter une alerte SIEM simplement parce que l'IA a déclaré un "faux positif" pourrait dissimuler une véritable attaque. Vérifiez également indépendamment l'alarme que l'IA qualifie de « sans importance » ; La décision de clôture appartient à l'analyste et est enregistrée.
En résumé
L’essence de l’analyse log et SIEM est d’extraire le signal réel d’un énorme tas de bruit. Dans ce tri, l’IA résume le journal en quelques secondes, regroupe les modèles, établit une chronologie et met en évidence le suspect – mais ne connaît pas le contexte institutionnel et peut inventer des événements. La configuration correcte est donc superposée : la règle/signature passe au crible, l'IA résume et signale, l'analyste vérifie avec le journal brut et prend une décision. Trois principes vous protègent : le contexte (aucune anomalie interprétée sans base de référence), la preuve (chaque résultat est lié à la ligne de log brute), le contrôle indépendant (ce que l'IA appelle la zone « propre » est également analysée). Et travaillez toujours de manière anonyme.
Tâche de candidature
Prenez un exemple de fragment de journal (soit anonymisé à partir de votre propre système, soit à partir d'un exemple d'ensemble de données). Tout d’abord, résumez-le à l’IA avec le modèle « Log Summarization ». Appliquez ensuite le modèle « Élimination des faux positifs » pour chacun des trois résultats les plus notables et vérifiez vous-même chaque résultat dans le journal brut. Enfin, notez les différences entre le résumé de l'IA et votre lecture brute : qu'est-ce que l'IA a manqué, qu'a-t-elle inventé, qu'a-t-elle réussi ?
liste de contrôle
- [ ] J'ai anonymisé le journal ; véritable IP/utilisateur/hôte masqué.
- [ ] J'ai donné à l'IA la source du journal et le comportement normal (ligne de base).
- [ ] J'ai demandé une ligne de journal de preuves pour chaque constatation et je l'ai vérifiée dans le journal brut.
- [ ] J'ai confirmé chaque étape de la chaîne d'événements établie par l'IA, éliminant ainsi la fabrication.
- [ ] J'ai considéré au moins une explication faussement positive pour chaque alarme.
- [ ] J'ai également scanné les zones que l'IA qualifie de « propres/sans importance ».
- [ ] En tant qu'analyste, j'ai pris la décision et le dossier de l'incident ; J'ai documenté l'IA comme un accélérateur.