Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Le laboratoire d’analyse forensique Alexandre Compastié Inria, Centre d’opérati

Le laboratoire d’analyse forensique Alexandre Compastié Inria, Centre d’opérations de sécurité (SOC) 2 Rue Simone IFF 75012 Paris Résumé L’analyse forensique consiste à rechercher des preuves sur des supports numériques pour comprendre un incident informatique passé ou en cours, de manière à y remédier et pouvoir prendre des décisions éclairées. Ces preuves sont des traces, des artefacts numériques qui fournissent des informations sur l’incident. Une fois agrégés, ils permettent de dégager un scénario factuel d’évènements et d’apporter des réponses à l’équipe en charge des investigations. Au travers de cet article, nous exposerons l’architecture technique ainsi que les composants sur lesquels repose le laboratoire forensique du centre d’opérations de sécurité d’Inria : – les moyens de collecte d’artefacts, qu’ils soient en mémoire, dans des traces de flux réseau, ou présents sur disque ; – les capacités de transfert et de stockage des artefacts précédemment récoltés ; – le traitement des artefacts et leur restitution dans un format facilitant les investigations. Ce dernier point comprend notamment l’analyse syntaxique des journaux, l’exploitation de règles de détection et l’intégration de l’information dans l’outil de recherche, en automatisant au mieux toute cette procédure. Enfin, nous ferons un retour d’expérience sur l’utilisation de cette solution par le SOC d’Inria lors de la résolution d’incidents de sécurité, en présentant les avantages en matière de capacité de traitement et les limites de cet outil. Mots-clefs Forensique, analyse, artefacts, collecte, traitement, stockage, compromission 1 Introduction L’adaptation continue de notre niveau de maturité en matière de sécurité des systèmes d’information (SSI) est essentielle pour faire face aux menaces auxquelles sont confrontés nos systèmes d’information. Cela implique la mobilisation de multiples acteurs, notamment les équipes opérationnelles de sécurité. Ainsi, pour assurer l’évolution de sa posture défensive, la compréhension de l’origine d’un incident, qui repose sur la capacité d’investigation de ces équipes, JRES 2022 – Marseille 1/10 est primordiale. Malheureusement, mener une levée de doute ou réaliser une analyse post-mortem, aussi appelée « analyse forensique » présente un coût humain important qui peut limiter la capacité à y recourir ; d’autant plus que l’interconnexion toujours croissante de nos infrastructures impose d’approfondir son enquête tout en élargissant ses moyens d’intervention. Afin de prolonger ses capacités d’analyse tout en préservant les ressources du service, l’emploi d’un outillage spécifique répondant au besoin de l’analyste et s’adaptant aux contraintes opérationnelles s’avère être une solution efficace dont nous présenterons les caractéristiques. 2 Un contexte d’investigation contraint Le SOC d’Inria opère avec trois contraintes majeures qui ont influé sur les besoins de l’équipe. Premièrement, le périmètre d’intervention est très large. En effet, on recense plus de 7000 postes clients et environ 850 machines virtualisées au sein du centre de données. Ces machines peuvent fournir des services socles de la direction des systèmes d’information (DSI), tels que le service messagerie électronique, de visioconférence, ou encore le service d’authentification d’Inria. À cela, il faut ajouter les machines de chacun des centres d’Inria servant aux différentes équipes dans le cadre de leurs projets de recherche. Deuxièmement, le contexte technique est très riche, et cela s’illustre par la prise en charge de trois systèmes d’exploitation (Windows, macOS et Linux) par la DSI. L’équipe de cybersécurité doit donc être en mesure de mener ses investigations, quel que soit le système employé, impactant naturellement le choix des outils concernant la collecte d’artefacts forensiques. Troisièmement, Inria étant réparti en neuf centres sur le territoire national et ses agents pouvant télétravailler, cela ajoute des difficultés supplémentaires à la collecte des données au cours des investigations. Par ailleurs, les membres du SOC étant eux-mêmes répartis sur différents centres, il est important que l’outil propose des fonctions collaboratives adaptées. 3 Présentation de la solution technique 3.1 Architecture simplifiée Le laboratoire forensique est composé de deux machines virtuelles. La première est utilisée pour le dépôt d’artefacts. Elle peut être contactée par n’importe quelle machine connectée au réseau interne d’Inria ou par des machines au travers du VPN d’Inria afin d’y déposer, depuis la machine analysée ou une machine intermédiaire, les artefacts collectés. La seconde machine est le centre d’analyses d’artefacts ; elle soumet les artefacts à une chaîne de traitements et aboutit à l’affichage d’une chronologie complète. JRES 2022 – Marseille 2/10 Figure 1 – Schéma d’architecture simplifié du laboratoire forensique Ces deux machines disposent de deux espaces de stockages séparés : l’un est partagé entre les machines tandis que l’autre est dédié au centre d’analyses. En effet, les données du centre d’analyses étant enrichies par les analystes au travers de leur investigation, elles nécessitent de fait un niveau de sensibilité supérieur. 3.2 Architecture logicielle Le laboratoire forensique est découpé en trois groupes de composants logiciels open source distincts : - les outils dédiés à la collecte d’artefacts, - les outils pour leur traitement, - les outils de restitution et d’analyse. a. Phase de collecte Le premier groupe contient les outils à déployer sur la station de travail ou le serveur pour lequel une levée de doute ou une analyse forensique est requise. Leurs fonctions sont d’extraire les traces laissées par l’attaquant. Nous récupérons jusqu’à quatre types d’artefacts différents selon le contexte d’exploitation. Les journaux systèmes et applicatifs, qui constituent un premier type d’artefacts, sont systématiquement extraits. Pour automatiser cette phase, nous utilisons l’outil FastIR Artifacts[1] de SekoiaLab qui propose plusieurs fonctionnalités s’intégrant au mieux à notre contexte. Premièrement, il s’agit d’un exécutable nécessitant peu de configuration pour fonctionner, ce qui est idéal pour un déploiement rapide. En effet, la liste des artefacts collectés est régulièrement mise à jour et repose sur la connaissance de la communauté au moyen du Digital Forensics Artifacts Repository[2]. Deuxièmement, l’outil s’exécute sur les trois systèmes d’exploitation pris en charge par l’institut, limitant donc le recours à des outils et procédures spécifiques selon le système étudié. Une capture des flux réseau peut constituer un autre type d’artefact. Elle s’effectue au moyen de JRES 2022 – Marseille 3/10 l’outil tcpdump. Cette capture réseau peut ensuite être analysée sur le poste d’investigation au moyen de l’outil d’analyse de flux Wireshark. Les règles de détection proposées par un IDS tel que Suricata peuvent aussi servir dans le cadre d’une levée de doute. Plus exceptionnellement, une capture mémoire avec LiME[3] peut être effectuée et rejoindre notre liste d’artefacts. Le traitement de celle-ci demande un investissement important et n’est pas automatisé. Notons qu’il s’agit d’une action intrusive sur le système puisqu’elle consiste à ajouter un module au noyau au système puis à accéder au contenu de la mémoire. Cette collecte est donc motivée par la réalisation d’une analyse forensique et non d’une levée de doute. Enfin, en cas de compromission avérée, il est possible de soumettre au laboratoire un dernier type d’artefact : une capture de disque obtenue par l’intermédiaire de l’outil dd ou par les outils de VMware s’il s’agit d’un serveur virtualisé. L’étape de collecte est plus longue, ainsi que le temps de traitement. Cependant, c’est l’option à privilégier pour disposer d’une flexibilité accrue au cours de l’investigation. Tous les artefacts sont exportés vers le dépôt forensique qui expose un serveur transfer.sh[4] offrant une solution clé en main de téléversement de fichier par curl. Ce dernier fait partie des paquetages par défaut, il est donc régulièrement installé sur les machines étudiées. Le transfert est sécurisé par HTTPS afin de limiter le risque d’exposition ou d’altération des éléments. Une fois l’échange terminé, le traitement automatique des artefacts s’initie. b. Phase de traitement Figure 2 – Processus général de la phase de traitement Le traitement des artefacts repose sur un outil, lui aussi open source, appelé Plaso[5]. Sa fonction est d’extraire les évènements de sécurité provenant de sources variées ; il peut s’agir d’un simple journal d’évènements, de répertoires entiers jusqu’à la copie d’un support de stockage d’une machine. Cela aboutit à la production d’une chronologie des différents évènements intervenus sur le système. Il s’agit d’un processus pouvant être long et dépendant des caractéristiques techniques du centre d’analyse et des données collectées. En effet, le traitement de l’outil est fortement parallélisé JRES 2022 – Marseille 4/10 et la vitesse d’exécution est directement impactée par le nombre de CPU et le type de stockage mis à disposition. Facteur évident, la taille des journaux ou la taille du support traité jouent un rôle essentiel. À la réception des artefacts sur le dépôt forensique, un script python développé en interne contacte le démon Docker du centre d’analyse. La communication est initiée une fois la reconnaissance mutuelle des certificats TLS réalisée. Un conteneur est créé à partir d’une image personnalisée de log2timeline/plaso sur le centre d’analyse et entame le traitement des artefacts présents sur le stockage partagé. Le temps de traitement est variable ; il oscille entre la demi-heure dans le cas de journaux de quelques gigaoctets et dépasse la journée dans le cas de supports de stockage importants. Certaines options peuvent être ajoutées, comme l’emploi de règles de détection Yara[6] ou encore le traitement des archives, allongeant encore un peu plus la durée cette étape. En pratique, ce temps de traitement n’est pas une perte sèche pour l’analyste, qui saura le mettre uploads/Management/ paper103-article-rev1787-20220224-163801.pdf