Dans cette série de billets, nous allons illustrer l'ensemble des services de notre solution SOC-as-a-service à travers un exemple concret. Nous allons également aborder les problèmes couramment rencontrés sur le terrain et expliquer comment nous y remédions.
Définition des sources de données utilisés pour la détection
Les bons outils
Collecte et Compréhension des données
La création d'une règle de détection
La création d'une investigation
L'automatisation de la remédiation
Dans ce second billet, nous allons décrire comment identifier les sources de données nécessaires à la détection, les bonnes questions à se poser, les problèmes liés à la volumétrie et comment les éviter.
2 - Les sources de données utiles à la détection et à l'investigation
L'objectif est de définir les sources de logs pouvant générer des données utiles à la détection. Pour simplifier l'attaque que nous avons exécuté dans le précédent post, nous avons lancé une commande PowerShell encodée en Base64 sur la machine de la victime, qui a initié une connexion vers notre serveur HTTPs malveillant.
Les sources de données à prendre en compte sont donc les suivantes :
Logs Windows : Event Code, Powershell, Sysmon.
Logs de Firewalls
La connaissance de la donnée
Analysons maintenant ces sources de logs. En ce qui concerne les logs Windows EventCode, l'évènement 4688 "A New process has been created" est particulièrement pertinent, car il permet de savoir quand un processus est exécuté par ou exécute PowerShell.
Cependant, pour obtenir la commande lancée, il faut activer la fonction "command line process creation". Cette option permet d'obtenir la ligne de commande tapée, même si elle est encodée. Si un script est exécuté, on ne verra plus rien, seulement PowerShell appeler un fichier.
On peut voir dans le résultat de la commande que si celle-ci est encodée, elle s'affichera encodée. Mais on aura quand même accès aux paramètres de commandes "-NoP -NonI -W Hidden -enc". Par contre si maintenant, on exécute un script on ne verra plus rien ; simplement PowerShell appeler un fichier.
Mais c'est déjà un bon départ, regardons maintenant du côté des logs PowerShell. Il faut savoir qu'ils ne sont pas activés par défaut. Il faut donc activer cette fonctionnalité dans les paramètres de logging Windows, en particulier l'option "Script Block Logging de Powershell".
Script Block Logging de Powershell
Cela permet de générer des logs PowerShell dans les journaux d'évènements Windows, où l'on trouvera tout ce qui s'exécute, y compris le contenu d'un script, ainsi que les commandes en clair.
Il nous reste un dernier endroit où regarder et cette fois, ça va être Sysmon.
Les logs Sysmon nécessite l'installation d'un utilitaire.
Sysmon est un outil développé par Microsoft qui permet de collecter des informations détaillées sur l'activité système, notamment les processus, les fichiers et les connexions réseaux. Et dans notre cas, va être particulièrement utile pour la détection de cette menace.
La configuration va se faire en modifiant le fichier sysmonconfig.xml. Ce fichier contient des règles qui définissent les types d'événements à surveiller et les actions à effectuer en cas de détection.
Ce qui est intéressant de noter ici c'est que Sysmon permet d'inclure (limiter la volumétrie) mais aussi d'exclure des évènements (réduire les faux positifs).
Dans notre exemple, l'évènement qui va nous intéressé dans la détection de notre attaque, c'est EventID 3 : Network connection
Et plus particulièrement toutes les connexions qui vont être initié par Powershell.
On va donc ajouter les lignes suivantes à notre configuration sysmonconfig.xml
<RuleGroup name="Network connection initiated by PowerShell">
<NetworkConnect onmatch="include" />
<Image condition="end with">powershell.exe</Image>
</NetworkConnect>
</RuleGroup>Dans une entreprise, il sera important d'automatiser le déploiement de Sysmon afin d'assurer que tous les systèmes soient configurés de manière identique, mais surtout faciliter le déploiement. Pour cela, il est possible d'utiliser une stratégie de groupe (GPO) sur un domaine Active Directory pour déployer Sysmon sur l'ensemble des machines.
Il est crucial de mettre en place une politique de logging solide pour assurer la sécurité de votre parc informatique.
Chez Warlog, nous avons développé un script d'installation qui peut être facilement déployé à l'aide de GPO. Le script installe Sysmon, notre agent de collecte et configure l'ensemble pour envoyer les données à nos outils de détection. En plus des données de sécurité, notre agent de collecte transmet également des données de télémétrie sur lui-même et sur le système déployé, ce qui nous permet de surveiller l'état de santé de la chaîne de collecte et d'identifier les systèmes sur lesquels ils sont déployés.
- Les logs des équipements réseaux : Firewalls, Proxys, IPS/IDS.
Il est également important de collecter les logs des équipements réseaux tels que les firewalls, les proxys et les IPS/IDS, car une alerte seule ne suffit pas. Les analystes ont besoin de contexte pour enquêter et comprendre les incidents.
En cas de confirmation d'un incident dans notre exemple, il sera crucial de pouvoir remonter l'historique des connexions vers le serveur HTTP ne serait-ce que pour déterminer si d'autres machines du réseau ont été infectées. Il est crucial d'avoir une expertise technique solide pour identifier les données à collecter et comprendre leur contenu. De plus, une collaboration efficace entre les différentes équipes impliquées est indispensable pour réussir l'intégration d'une source de collecte. En effet, cela peut parfois demander l'intervention de plusieurs intervenants. Il est également primordial de choisir une solution technique adaptée (voir notre article de blog) pour répondre aux objectifs de collecte de données de sécurité.
Dans le cas contraire, les solutions de contournement nécessaires peuvent être chronophages et coûteuses en termes de développement, de maintenance et de processus.
Enfin, il ne faut pas oublier qu'une politique de logging doit être régulièrement mise à jour pour faire face aux évolutions des menaces et que l'outil doit être facilement configurable à distance pour garantir une surveillance constante et efficace.
Yorumlar