Guichard Jean-Philip

Guichard Jean-Philip

Expert SSI - CEA

4 article(s)
Description

Diplômé de l'ENSICAEN en 2003, Jean-Philip Guichard occupe d'abord un poste de consultant SSI au sein du CESTI OPPIDA avant de rejoindre la direction centrale de la sécurité du CEA.

Pendant 10 ans, il participera alors à l'audit, la supervision, le durcissement et la réponse à incidents des différents systèmes d'information du CEA. Depuis 2016, au sein du centre de Cadarache, il travaille notamment sur la sécurité des systèmes industriels.

Signature
Expert SSI - CEA
Articles de l'auteur

Détection d'anomalies par ACP

Magazine
Marque
MISC
Numéro
111
Mois de parution
septembre 2020
Spécialité(s)
Résumé

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.

Collecte de logs d’installations industrielles isolées

Magazine
Marque
MISC
Numéro
100
Mois de parution
novembre 2018
Spécialité(s)
Résumé

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.

Détecter la persistance WMI

Magazine
Marque
MISC
Numéro
91
Mois de parution
mai 2017
Spécialité(s)
Résumé

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.

Utilisation de l'analyseur de performances en live forensic Windows

Magazine
Marque
MISC
Numéro
77
Mois de parution
janvier 2015
Spécialité(s)
Résumé

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.