Ce playbook décrit comment utiliser le atelier de récits pour investiguer les récits liés aux comportements anormaux détectés par le producteur d'anomalies d'événements.
Pour plus de détails sur l'utilisation de l'atelier de récits pour analyser les anomalies des événements, voir Analyser les récits UEBA XOps pour l'utilisation et les anomalies des événements.
Ce playbook définit une approche systématique pour les ingénieurs SOC afin d'investiguer les incidents de sécurité potentiels liés à des comportements anormaux qui résultent en un nombre inhabituel d'événements. Il fournit un cadre pour recueillir des informations initiales, analyser le trafic réseau et tirer des conclusions sur la nature de la menace.
Il est applicable aux situations où le moteur fait remonter soit un pic de volume (de nombreux événements dans une fenêtre courte) soit un comportement jamais vu auparavant (un événement ou une application jamais observés auparavant). Les deux indications proviennent du même modèle analytique de comportement sous-jacent ; le flux de travail ci-dessous les couvre conjointement et indique où un rassemblement contextuel supplémentaire peut être nécessaire.
Les récits d’anomalies d'événements peuvent aider à identifier les menaces qui produisent des schémas de trafic anormaux ainsi que des mauvaises configurations du réseau qui pourraient poser des menaces de sécurité. Voici quelques exemples de ces types de menaces potentielles :
Activité menaçante liée à des schémas de trafic anormaux :
-
Tentatives d'exfiltration de données
-
Mouvement latéral au sein du réseau
-
Tentatives d'infection malveillante
Mauvaises configurations réseau qui pourraient poser des risques de sécurité
-
Violations de politique - Par exemple : tentatives d'accès non autorisées, transferts de données inattendus, ou connexions contournant les contrôles de sécurité établis
-
Ports ouverts et mauvais usage des protocoles - Les pics de trafic anormaux liés à des ports ou protocoles spécifiques indiquent souvent que ces paramètres ne sont pas alignés avec les meilleures pratiques et peuvent indiquer une mauvaise configuration
-
Échecs de segmentation du réseau - Une segmentation réseau mal configurée peut permettre un accès ou mouvement non autorisé entre des segments, ce qui peut être détecté comme des anomalies
Utilisez les widgets de Détails dans le récit pour recueillir des informations de base sur la menace potentielle et faire une évaluation initiale pour déterminer si une enquête supplémentaire est nécessaire. Examinez ces champs clés :
-
Description - Comprenez le type d'anomalie (y compris l'application, le moteur ou le comportement spécifique), et si l'accent est mis sur un site ou utilisateur spécifique
-
Période d'entraînement - Montre combien de temps le moteur a collecté les données de référence pour l'anomalie. Une période d'entraînement plus longue peut indiquer une base de référence bien établie, tandis qu'une période plus courte pourrait indiquer que les données sont limitées
-
Onglet Source - Liste le site ou l'utilisateur qui a généré le trafic. Quand le périmètre est un site entier, attendez-vous à ce que plusieurs hôtes soient impliqués.
Note
Astuce : Si l'anomalie affecte un site, identifier un hôte source unique peut être difficile, et l'anomalie pourrait s'étendre à plusieurs hôtes.
Le graphique de Distribution des Anomalies peut aider à identifier quelle règle de pare-feu, quelle signature IPS ou quelle règle Anti-Malware a généré les événements déclenchant le récit d’anomalie. Si plusieurs règles sont impliquées, priorisez celles qui ont causé les plus grands pics d'événements.
Les récits d'anomalies basés sur des événements peuvent provenir de n'importe quelle source de logs Cato, Firewall, IPS, DNS Protection, CASB, DLP, Sécurité des Applications, NGAM, et d'autres, donc le vecteur d'attaque probable et votre approche d'investigation devraient être ajustés pour correspondre au type d'événement spécifique.
Notez l'horodatage exact de l'anomalie. Ceci est essentiel pour analyser les événements connexes dans les étapes ultérieures de l'enquête.
Examinez ces widgets pour obtenir un contexte supplémentaire. Les widgets montrent les principales applications, serveurs, hôtes et cibles impliquées dans l'anomalie. Les données sont agrégées sur une période de 14 jours précédant le récit d'anomalie.
-
Principales Applications - Montre les applications avec le plus grand nombre d'événements.
-
Principaux serveurs/destinations - Montre les serveurs ou réseaux les plus consultés.
-
Principaux hôtes - Montre les principales adresses IP sources générant le trafic.
-
Cibles - Montre les destinations cibles pour le trafic anormal.
Note
Note : Ces widgets fournissent une vue d'ensemble et ne sont pas toujours indicatifs de la cause exacte de l'anomalie. Par exemple, les widgets indiquent que l'anomalie implique du trafic TOR, mais sans une IP de destination spécifique. Cela peut indiquer une activité TOR plus large plutôt qu'une cible malveillante unique.
Cette étape offre un contexte précieux en identifiant des détections supplémentaires associées au même comportement ou à l'hôte/site où cela a été observé. Réviser des récits similaires peut aider à déterminer si d'autres hôtes dans le réseau ont déclenché la même détection, révélant potentiellement un phénomène plus large affectant l'environnement.
Analyser les événements individuels est l'étape la plus critique de l'enquête. Cela vous permet d'explorer plus profondément l'anomalie pour comprendre la cause première.
Examinez les événements pertinents pour corréler les données liées au récit. Recherchez des éléments récurrents tels que des IP sources spécifiques, des domaines et des applications pour concentrer votre enquête. Par exemple, si l'anomalie est causée par un trafic TOR, et qu'une IP source ou un domaine spécifique montre une activité répétée, enquêtez davantage sur cet entité.
Voici des étapes exemples pour analyser des événements liés à un récit d'anomalies d'événements. Pour plus de détails sur le filtrage et le travail avec la page d'Événements, voir Analyser les Événements de votre réseau.
-
Affichez la page des événements pré-filtrée pour les événements liés au récit en cliquant sur Voir Tout sur la page du récit.
-
Sur la page des événements, configurez le filtre de plage de temps ou utilisez la souris pour sélectionner la plage de temps qui montre clairement un nombre anormal d'événements.
-
Ajoutez des champs pertinents à la page des événements. Cela offre une meilleure perspective des événements impliqués dans l'anomalie. Dans l'exemple ci-dessous, ces champs d'événements ont été ajoutés à la page : ID de signature, Application, Nom de domaine, IP source.
Vérifiez les champs ajoutés et essayez d'identifier la cause de l'anomalie. Dans cet exemple, les champs d'événements ajoutés montrent clairement que la cause de l'anomalie est un domaine spécifique.
-
Vérifiez les champs ajoutés et essayez d'identifier la cause de l'anomalie. Recherchez des éléments récurrents :
-
IP source / utilisateurs récurrents
-
Le même domaine ou destination à travers plusieurs événements
-
Apparition soudaine d'une application ou d'un pays inconnu.
Comparez le trafic au trafic organisationnel :
-
D'autres utilisateurs ont-ils des schémas de trafic similaires ?
-
Dans le cas d'une première occurrence de comportement suspect, est-ce quelque chose de commun au sein de l'organisation ? Ce comportement a-t-il été déclenché pour d'autres hôtes au sein de l'organisation ?
-
-
Dans l'exemple suivant, après avoir identifié sur la base des widgets et des événements que les réseaux Tor sont l'application la plus utilisée, et qu'il y a deux principales menaces IPS qui ont eu un pic d'événements, des filtres sont ajoutés pour l'Application et les Noms de Menaces spécifiques.
Les filtres ajoutés révèlent que ce trafic anormal est lié à une adresse IP source spécifique.
-
Des étapes de recherche supplémentaires peuvent maintenant être entreprises :
-
Vérifiez le nom du dispositif ou le nom de l'utilisateur corrélé à cette activité.
-
Enquêtez sur la cible et voyez si elle est liée à l'activité malveillante.
-
Inspectez le trafic présentant les mêmes caractéristiques pour d'autres utilisateurs sur le même site ou réseau pour obtenir un contexte plus large.
-
Le moteur XOps regroupe les événements de transfert de fichiers sous un seul parapluie, mais les applications de partage de fichiers cloud (par ex., Dropbox, SharePoint, S3) et l'accès aux fichiers basé sur SMB exposent des données d'enquête différentes :
-
Applications cloud – les événements montrent uniquement l'application et le volume ; les détails au niveau des objets résident sur la plateforme cloud elle-même
-
Trafic SMB – les événements incluent des métadonnées granulaires, telles que le nom et le chemin du fichier, permettant un examen plus approfondi.
-
Dans les anomalies basées sur le site, il peut y avoir des cas où il n'y a pas d'hôte ou de destination spécifique et l'anomalie est un phénomène large à travers le site.
-
Il peut y avoir des cas où l'application qui a causé l'anomalie ne figure pas parmi les cinq premières applications générant des événements anormaux.
-
Il y a des cas où l'anomalie est basée sur des événements IPS de renseignement sur les menaces (Réputation). Dans un tel cas, l'enquête devrait être plus ciblée sur la cible, vous devez utiliser le playbook suivant : Playbook de sécurité XOps - Communication de cible suspecte.
-
Dans le cas où vous n'êtes pas sûr si une anomalie spécifique pose une menace de sécurité, essayez de voir si ce trafic a eu lieu sur le même site ou sur des sites différents dans le passé. Cela peut aider à identifier si l'anomalie est simplement causée par un nouvel appareil.
Voici quelques exemples de conclusions pertinentes pour les récits d'anomalies d'événements :
-
Trafic anormal
-
Anomalie de fichiers bloqués
-
Anomalie de trafic IPS bloqué
-
Tentative d'exfiltration utilisant l'application {app name}
-
Anomalie de trafic vers cible malveillante
-
Effectuez une analyse complète de protection des terminaux (incluant Anti-Virus, EPP, EDR, etc.) et retirez tous les programmes inconnus et extensions de navigateur de la machine infectée.
-
Assurez-vous que le processus de retrait est minutieux et que tous les composants liés sont identifiés et supprimés.
-
-
Si vous identifiez un hôte ou un utilisateur spécifique comme source de l'anomalie, isolez-les du réseau immédiatement pour éviter tout dommage potentiel supplémentaire ou exfiltration de données.
-
Si nécessaire, mettez à jour ou créez des règles pour une politique de sécurité plus restrictive, spécialement si l'anomalie était causée par une application ou un trafic qui ne devait pas être autorisé.
-
Dans le cas où le récit est un faux positif, vous pouvez le classer comme Bénin/Informationnel et également l'ajouter à une règle de récits muets. Si le récit résulte d'une analyse légitime ou d'un test de pénétration, il est recommandé de l'ajouter à une règle de récits muets pour une plage de temps spécifique.
0 commentaire
Cet article n'accepte pas de commentaires.