Guichard Jean-Philip

Retour de vacances. L’analyse du SIEM après un mois d’absence montre que dix incidents ont été déclenchés sur la base des alertes automatiques et ont pu être gérés convenablement par la chaîne de traitement d’incidents. Tout est-il sous contrôle ? Un analyste aimerait rapidement s’en assurer en complétant cette supervision par sa propre analyse du mois écoulé. Mais par où commencer ? Il est inenvisageable de regarder un mois de logs « rapidement » et d’autant plus quand on ne sait pas précisément ce que l’on cherche… Une solution possible est de recourir à des outils statistiques qui permettent d’identifier des périodes d’activité atypiques sur lesquelles concentrer son analyse. L’analyse en composantes principales (ACP ou PCA en anglais) est une méthode statistique qui peut répondre relativement efficacement à cette problématique. L’article présente cette méthode et son apport dans la détection d’anomalies, en prenant comme exemple l’analyse de flux réseaux.

La mise en place d’un SOC est un projet bien moins technique qu’organisationnel. Dans le cadre de la supervision sécurité d’installations industrielles isolées, la collecte de logs peut cependant présenter quelques spécificités techniques qu’il semble intéressant d'aborder dans cet article.Les postes de supervision et les serveurs de contrôle-commande constituant un point d'entrée important vis-à-vis d'une malveillance informatique sur un système industriel, leurs journaux systèmes représentent une source d'informations intéressante à collecter. L'article propose un retour d'expérience sur la mise en œuvre d'une infrastructure de collecte des journaux Windows et de leurs transferts vers un SOC, dans le respect d'une exigence d'isolation.

Les mécanismes de démarrage automatique de programme disponibles sous Windows sont nombreux. Le nombre d’onglets de l’outil Microsoft « Autoruns » suffit pour s’en convaincre. Parmi ceux-ci, l’utilisation de la technologie WMI (Windows Management Instrumentation) à des fins de persistance malveillante semble prendre de l’importance depuis quelques années. Rappelons qu’un tel mécanisme implique un contexte post-compromission (avec privilèges administrateur dans le cas présent). La persistance WMI a été abordée dans un précédent article de MISC n°80 (« WMI : la menace silencieuse ») qui permet de prendre la mesure des limites de la journalisation standard à des fins de détection. En effet, le challenge n’est pas tant de détecter cette persistance lors d’une analyse sur incident : des méthodes et outils existent pour l’identifier (si elle est toujours active). La véritable difficulté est de pouvoir alimenter facilement un SIEM afin de la détecter lors de son installation et permettre une réaction avant que la bombe logique n’explose. Seul Windows 10 marque une avancée dans ce domaine et en permet une détection native. L’article présente un axe d’amélioration possible pour les versions antérieures de Windows, permettant d’être plus réactif vis-à-vis de cette menace.

Il est parfois nécessaire en traitement d'incident d'analyser une machine pour trouver le processus responsable d'une communication TCP ou UDP jugée suspecte. Les outils permettant d'afficher les communications actives des processus (netstat, resmon...) ne sont alors pas toujours adaptés. Par exemple lorsqu'il s'agit d'identifier l'origine d'une communication UDP ou dans le cas d'une communication nocturne qui implique une analyse a posteriori. Il faut alors pouvoir journaliser les événements de communications réseaux des processus de la machine. L'article présente une méthode simple basée sur un outil standard Windows : l'analyseur de performances.