Gains :
- Comprenez comment la chasse aux menaces commence par une hypothèse testable, et non par une alarme, et comment l'intelligence artificielle aide à la génération d'hypothèses et à la rédaction de requêtes.
- Possibilité d'appliquer que le signal contraire/rare mis en évidence par l'intelligence artificielle ne signifie pas automatiquement une intention malveillante, et que l'hypothèse doit être confirmée par des preuves brutes.
- Possibilité de vérifier les numéros techniques MITRE ATT&CK et les identifiants d'événements fournis par l'intelligence artificielle avec la source officielle et d'éliminer les détails techniques fabriqués
La surveillance de sécurité classique fonctionne selon la logique « attendez l'alarme, regardez quand elle arrive ». Mais les attaquants les plus dangereux essaient de ne pas tirer la sonnette d’alarme : ils utilisent des outils légitimes (c’est ce qu’on appelle « exploiter », c’est-à-dire abuser d’outils qui existent déjà sur le système, tels que PowerShell, WMI), se déplacer lentement et interférer avec le trafic normal. C'est pourquoi la chasse aux menaces est née : sans attendre une alarme, "s'il y avait un attaquant non détecté actuellement dans mon organisation, où serait-il ?" Rechercher des traces de manière proactive avec la question : La chasse aux menaces commence par une hypothèse, pas par une alarme.
L’intelligence artificielle est très utile à deux égards dans la chasse aux menaces. La première est la génération d'hypothèses : donnez une technique d'attaque et demandez « Si cette technique était utilisée dans mon institution, sur quels logs et selon quel schéma laisserait-elle une trace ? » vous pouvez demander. La seconde est l’extraction de signaux : elle peut mettre en évidence les éléments rares, aberrants, « différents de la normale » dans le Big Data. Mais l’IA ne sait pas ce qui est normal pour votre organisation et peut tomber dans le piège de penser qu’une hypothèse est « prouvée ». Dans la chasse aux menaces, l’IA est un partenaire mental et un scanner ; Le chasseur (analyste) décide si la proie trouve une menace réelle et si celle-ci sera signalée.
Étapes de la chasse aux menaces
- Hypothéser. Une phrase concrète et testable : « Un attaquant peut analyser le réseau interne en dehors des heures de bureau avec un compte compromis. » Vous pouvez utiliser l’IA pour le brainstorming ici.
- Identifiez la source de données. Quel journal prouve/réfute l’hypothèse ? (Par exemple, journaux de pare-feu et DNS pour l'analyse réseau, journaux d'identité pour l'élévation de privilèges.)
- Concevez la requête. La requête qui recherchera le modèle ciblé (langage de requête SIEM, KQL, SQL-like). L'IA aide à rédiger les requêtes ; mais vous examinez la requête et l'exécutez.
- Extrayez le résultat. Filtrez le signal réel à partir de centaines de lignes de sortie. Ici, l'IA effectue le regroupement et la synthèse.
- Confirmez ou infirmez. Confirmez avec des preuves brutes et un contexte si la trace trouvée est réellement malveillante ou innocente.
- Documentez le résultat et transformez-le en une détermination. Convertissez le modèle réel trouvé en une règle de détection permanente ; Si l’hypothèse échoue, enregistrez-le également (un résultat négatif constitue également une information).
Termes : TTP (Tactiques, Techniques, Procédures — modèle comportemental de l'attaquant). MITRE ATT&CK est une bibliothèque énumérée et documentée de techniques d'attaquants (par exemple T1078 « Comptes valides ») ; Il fournit un langage commun dans la chasse aux menaces. IOC (Indicator of Infringement — mauvaise adresse IP, hachage, domaine). Le bruit blanc (liste blanche/bien connu) est un comportement normal connu pour sacrifier des proies.
Tableau des approches de chasse aux menaces
Approche
point de départ
Apport de l'IA
Attention
Chasse basée sur des hypothèses
"S'il y avait un tel attaquant..."
Génération d'hypothèses, description du modèle
L'hypothèse n'est pas une preuve
Chasse basée sur le CIO
Mauvais indicateur connu
Faire correspondre les IOC aux journaux
Un CIO ancien/incorrect induit en erreur
Recherche basée sur TTP/ATT&CK
Une technique (numéro T)
Conversion de la technique en modèle de journal
Technique ≠ modèle unique
Chasse basée sur les anomalies
Écart statistique
Mettre en évidence la valeur aberrante
Contrarian ≠ mauvaise foi
Analyse de fréquence de pile
"Quel est le plus rare ?"
Trouver l'événement rare
Rare ≠ dangereux
trois mini-cases
Cas 1 — Trouver le rare. Un chasseur pourrait se demander : « Quel processus du réseau interne s'exécute sur le moins d'ordinateurs mais établit le plus de connexions réseau ? » établit son hypothèse. L'IA met en évidence un modèle à partir des données anonymisées de connexion de processus : un processus nommé svchost32.exe, vu sur seulement 2 machines, se connecte à 340 adresses externes différentes. Le chasseur examine cela ; Il trouve un malware qui imite le svchost.exe légitime. L’IA filtre le rare ; Le chasseur a posé le diagnostic et l'intervention.
Cas 2 — La chasse ratée (mais précieuse). Un chasseur a demandé : « pourrait-il y avoir un téléchargement massif de données en dehors des heures de bureau ? » établit son hypothèse ; AI rédige le brouillon de requête pertinent. Résultat : 3 utilisateurs ont téléchargé la nuit, mais tous les trois sont des employés de bureau à l'étranger et travaillent pendant les heures de bureau en raison des différences de fuseau horaire. L'hypothèse est réfutée. Le chasseur documente cela comme un « résultat négatif » et note ces 3 utilisateurs comme exceptions pour les chasses futures. Même la chasse infructueuse nous a permis de mieux connaître l'institution.
Cas 3 — Piège technique artificiel. Un chasseur demande à l'IA "Comment rechercher la technique T1055 dans mon organisation ?" dit. L'IA écrit une requête et une affirmation convaincantes selon lesquelles « T1055 génère l'ID d'événement suivant » ; mais l'ID d'événement qu'il a donné est erroné et le modèle constitue une sous-technique ATT&CK. Avcı ouvre l'enregistrement MITRE ATT&CK, confirme la description technique et les sources réelles du journal, et corrige l'ID d'événement incorrect. Leçon : Vérifiez tous les détails techniques fournis par l'IA (ID d'événement, numéro T, champ de journal) auprès de la source officielle.
Invite faible/Invite forte
Invite faible :
Découvrez s'il y a un attaquant sur mon réseau.
Cette affirmation est sans hypothèse, sans données, illimitée et invérifiable. L'IA produit une liste générale ou inventée ; cela ne sert à rien.
Invite puissante :
Votre rôle : assistant qui donne des idées et des schémas au chasseur de menaces. Ne décidez pas, ne dites pas « il y a une menace ». Mon hypothèse : "Un compte compromis peut analyser les ports internes en dehors des heures de bureau." Générez ce qui suit : (1) répertoriez les sources de journaux qui prouveront et DÉFUSERont cette hypothèse, (2) décrivez le modèle concret à rechercher (quels champs, quels seuils), (3) rédigez un brouillon d'un exemple de requête et commentez chaque ligne, (4) notez quelles explications innocentes seront éliminées dans le résultat résultant. Suggérez la technique MITRE ATT&CK appropriée, mais marquez le numéro T et l'ID d'événement comme "[doit être vérifié par MITRE]", ne l'inventez pas.
L'affirmation forte commence par une hypothèse concrète, établit l'équilibre entre preuves et réfutations, explique la question et laisse les détails techniques à la vérification.
Modèles d'invite copiables
MODÈLE DE GÉNÉRATION D'HYPOTHÈSESPour mon institution [entité : par ex. Générer des hypothèses testables de chasse aux menaces dans le contexte de [Active Directory / cloud / endpoint]5. Pour chaque hypothèse : (1) quel comportement de l'attaquant il cible, (2) quelle source de journal fournira des preuves/réfutations, (3) le modèle attendu. Faites des phrases testables, pas des phrases générales.
MODÈLE DE TECHNIQUE MODÈLE Je rechercherai la technique d'attaque suivante dans mon établissement [nom de la technique]. Générez : (1) enregistrez les zones où la technique laisse généralement sa marque, (2) les modèles concrets et les seuils à rechercher, (3) les situations innocentes (faux positifs) qui pourraient déclencher ce modèle. Offrez un numéro T MITRE ATT&CK pertinent mais avec l'indicateur « [Doit être vérifié à partir de MITRE] » ; ne donnez pas d’ID/numéro d’événement fabriqué.
MODÈLE DE PROJET DE REQUÊTERédigez un brouillon de requête [SIEM/KQL/SQL] qui recherche le modèle suivant : [description du modèle]. Commentez chaque ligne, expliquez quel champ vous filtrez et pourquoi, et marquez les risques de performances. Je vais examiner la requête et l'exécuter ; ne présumez pas que vous l’exécuterez. Laissez les noms de champs marqués "[corriger au schéma]" selon le schéma que je connais.
MODÈLE D'ÉLIMINATION DES RÉSULTATSLe résultat de ma recherche a donné les lignes suivantes (anonymes) : [coller]. Regroupez-les et pour chaque groupe, écrivez (1) un scénario malveillant, (2) au moins 2 explications innocentes et (3) des preuves supplémentaires à rechercher pour différencier. Prise de décision; Ne me laisse pas te séparer. Cochez « [aucun fondement] » pour une affirmation qui n'a aucune preuve.
Erreurs courantes
- Chasse sans hypothèses. Dire « trouver quelque chose » pousse l’IA à deviner et à inventer ; La chasse commence par une phrase concrète et testable.
- Prendre une hypothèse pour une preuve. La chasse teste une possibilité ; La trace trouvée ne constitue pas une « menace » tant qu’elle n’est pas confirmée par des preuves brutes.
- Considérant automatiquement le contraire comme mauvais. Le rare/outlier est souvent innocent (maintenance, nouveau logiciel, travail ponctuel) ; Filtrez avec le contexte.
- Ne pas vérifier les détails techniques. L'IA peut faire correspondre l'ID d'événement, le numéro T et le champ de journal ; Confirmez avec MITRE ATT&CK et la documentation du produit.
- Jeter les prises gaspillées. Le résultat négatif est aussi la connaissance : mieux connaître l’organisation, réduisant ainsi les futurs faux positifs ; document.
Astuce : Une bonne hypothèse de chasse aux menaces doit être « testable » : une affirmation concrète qui peut s'avérer vraie ou fausse. « Y a-t-il quelque chose de mauvais dans mon réseau ? » ne peut pas être testé ; « Le compte X s'est-il connecté à plus de 50 IP internes en dehors des heures de bureau ? » peut être testé.
Attention : La chasse aux menaces s'effectue uniquement sur les systèmes pour lesquels vous êtes autorisé à le faire. Demander à l'IA de « sonder » une autre organisation, une personne ou un réseau pour lequel vous n'avez pas d'autorisation est une tentative d'obtenir un accès non autorisé et sort du cadre de ce module.
En résumé
La chasse aux menaces consiste à rechercher de manière proactive les traces d'un attaquant caché sans attendre une alarme, et elle commence par une hypothèse et non par une alarme. L’IA offre deux contributions puissantes dans ce processus : générer des hypothèses testables et des brouillons de requêtes, et filtrer les signaux rares/aberrants du Big Data. Mais l’IA ne sait pas ce qui est normal pour votre organisation, elle peut inventer des détails techniques et tomber dans le piège de confondre une hypothèse avec des preuves. La chasse comporte donc six étapes (hypothèse, données, requête, extraction, vérification, document) et à chaque étape la décision appartient au chasseur. À contre-courant ≠ mauvais, hypothèse ≠ preuves, détails techniques fournis par l'IA ≠ corrects ; le tout confirmé par des preuves brutes et MITRE ATT&CK.
Tâche de candidature
Obtenez 5 hypothèses de chasse aux menaces de l'IA avec le modèle « Génération d'hypothèses » pour votre propre organisation (ou un exemple d'environnement). Choisissez le plus testable, rédigez une requête avec les modèles « Pattern Technique » et « Query Draft », validez chaque ligne de la requête et chaque numéro T suggéré dans MITRE ATT&CK. Notez le résultat (l'hypothèse a-t-elle été confirmée, réfutée, qu'avez-vous appris) dans une courte note de chasse.
liste de contrôle
- [ ] J'ai commencé ma chasse avec une hypothèse concrète et testable.
- [ ] J'ai identifié des sources de journaux qui prouveront et réfuteront l'hypothèse.
- [ ] J'ai examiné chaque ligne du brouillon de requête et je l'ai adapté à mon propre schéma.
- [ ] J'ai vérifié la technique MITRE ATT&CK proposée et les identifiants d'événements auprès de la source officielle.
- [ ] J'ai confirmé chaque signal avec des preuves brutes et un contexte ; Je n’ai pas automatiquement considéré le contraire comme mauvais.
- [ ] J'ai également documenté l'hypothèse qui a échoué (le résultat négatif est une information).
- [ ] Je chassais uniquement sur les systèmes pour lesquels j'étais autorisé à chasser.