Clonezilla est un outil d'images disques / partitions et de clonage. Il ressemble à True Image et Norton Ghost. Il peut vous aider à déployer une image système en réseau ou encore faire du backup et de la restauration après un incident. Clonezilla se compose de 3 éléments : live, lite server et SE (édition serveur). L'éditeur live est celle que l'on utilise par sa machine. 

Pour cloner un disque, il faut un disque source et un disque de destination. Il faut la place suffisante dans la destination pour cloner le disque source. Il faut installer Clonezilla sur un CD ou une clé USB pour pouvoir booter dessus. La prise en main n'est pas la plus facile et son interface nécessite un temps d'adaptation. Un outil tel que Carbon Copy Cloner sur macOS est plus simple d'utilisation. Clonezilla crée une copie identique de votre disque source (fichiers, configurations, etc.). 

L'avantage de clonezilla est qu'il supporte ext2, ext3, ext4, xfs, FAT, NTFS, UFS, HFS+, VMFS, etc. On peut donc cloner des disques Windows, Linux, macOS. Et vous pouvez même créer des clones bootables. A noter que l'outil ne supporte pas les volumes APFS (macOS). 

Si vous ne connaissez pas : https://sourceforge.net/projects/clonezilla/

Durant la conférence ElastiCon 2025 à Paris, nous avons rencontré Victor Vuillard (CTO et CSO de S3NS) et Nicolas Raux (architecture cybersécurité de S3NS).

François Tonic : Pouvez-vous présenter S3NS et le positionner sur le marché ?

Victor : S3NS, filiale de Thales en partenariat avec Google, est un fournisseur de cloud de confiance. Son objectif est d'offrir un cadre sécurisé en s’appuyant sur la technologie de Google Cloud Platform (GCP), mais avec une particularité essentielle : la plateforme est hébergée dans des datacenters en France et opérée par S3NS, une société française. Nous visons l’obtention de la qualification"Cloud de Confiance" de l’ANSSI, que nous espérons obtenir dès cet été. Cette qualification garantit que les données hébergées sont protégées contre toute ingérence étrangère, notamment des lois extraterritoriales comme le FISA ou le Cloud Act.

Dans quels contextes les outils Elastic sont-ils utilisés par S3NS ?

Victor : Une des contraintes pour nous est de devoir gérer un grand volume d’événements de sécurité provenant principalement de trois sources. Il y a tout d’abord l’inspectabilité. Parmi les valeurs ajoutées que nous apportons en matière de sécurité, il y a l’analyse de chaque mise à jour proposée par Google pour les services GCP. Nous recevons les mises à jour et réalisons d’une part une analyse binaire automatisée, d’autre part une analyse comportementale afin de remonter les données.

En parallèle, nous traitons l’ensemble des éléments issus de notre infrastructure d’administration ainsi que ceux provenant des milliers de serveurs cloud sur lesquels tournent les services. 

Compte tenu de l’importance de ces volumes de données, nous avons choisi une solution technique à la fois efficace et capable d’ingérer cette masse d’informations. Avec Elastic, nous pouvons monter en charge plus facilement qu’avec d’autres solutions. 

Un des soucis que l'on a aujourd'hui quand on parle de cybersécurité, notamment dans les infrastructures, c'est la quantité de logs que l'on va générer ou d'événements. Est-ce que les solutions d’Elastic peuvent vous aider à prioriser les vulnérabilités ? Ou tout le moins, donner une priorité à tel ou tel événement de sécurité ?

Nicolas : Oui, on peut tout à fait caractériser des sévérités sur des assets. On peut aussi prioriser selon le type de menace détectée. Il est aussi possible de croiser avec d’autres informations, par exemple, des données dites de Threat Intelligence. Ces données complémentaires peuvent être croisées avec les logs et nous donner un niveau de sévérité. Tout cela permet de traiter une alerte et de savoir si cette alerte est un incident réel ou non.

Donc il y a les faux-positifs à gérer ? 

Nicolas : Oui tout à fait. Il faut avoir la capacité de détecter ce qu’il se passe à l’instant T et gérer la notion de faux positifs. Chaque alerte nécessite une vérification, car une alerte n’est pas forcément un incident.  

Faut-il prioriser les alertes selon les équipes qui utilisent ces outils ?

Nicolas : Ce travail est plutôt réalisé en amont quand nous mettons en place les outils de détection. Il est réalisé avec les équipes métiers pour comprendre les besoins et quelles sont les applications majeures pour elles. C’est un travail conjoint pour avoir les bonnes métriques. Nous regardons aussi si les alertes remontées correspondent à leurs besoins et nous adaptons nos outils selon leurs retours.

Les clients vous demandent-ils comment vous gérez les logs, le type d’outils qui sont déployés ? Est-ce un avantage concurrentiel d’utiliser les outils d’Elastic ? 

Victor : Oui, c’est important, d’une manière générale, d’assurer la sécurité de notre infrastructure. Nos clients sont attentifs à la gestion des incidents. Sur les appels d’offres, ils ont des attentes particulières et/ou précises sur la sécurité, et Elastic nous apporte cette efficacité. Nous sommes aussi dans un modèle de responsabilités partagées. S3NS assure la sécurité de l’infrastructure pour les services IaaS, CaaS ou PaaS. Le client doit, de son côté, surveiller ce qu’il se passe chez lui. Côté client, nous n’avons pas la capacité de voir ce qu’il se passe. Il peut, avec les services que nous proposons, centraliser les journaux, les logs, et relayer les incidents. Le client peut également faire le choix d’utiliser une solution Elastic que nous pouvons héberger sur notre offre de confiance.

Est-ce que vous avez fait des benchmarks pour voir ce qu’il se passait avant l’utilisation d’outils tels que ceux d’Elastic et après leurs déploiements ?  Est-ce que vous gagnez du temps dans la résolution des incidents ?

Victor : Nous avons des indicateurs sur les scénarii de corrélations. Il existe des indicateurs du côté Elastic comme sur le temps de recherche, le temps d’injection de logs qui peuvent être utiles. Ils peuvent par exemple servir à dimensionner l’infrastructure de traitements. Les besoins peuvent évoluer.

Nicolas :  Elastic est un outil que l’on peut piloter et développer. Ce n’est pas forcément le cas avec d’autres outils qui ne sont pas assez ouverts. On peut développer des règles ou définir comment fonctionne une règle. C’est aussi la possibilité d’embarquer du machine learning dans le moteur de règles, et automatiser soit avec les fonctions offertes, soit en le développant nous-mêmes. C’est difficile à quantifier, mais ce que l’on a envie de faire, on peut le faire. C’est l’avantage d’une solution ouverte. Le gain est vraiment important.

Victor : pour nous, c’est important qu’Elastic soutienne le modèle open source. Même si nous avons choisi l’offre entreprise, nous avons la capacité à regarder le code, la logique de fonctionnement. C’est toujours bénéfique. 

Est-ce que vous participez à la communauté ? Vous développez vos propres plug-ins ?

Nicolas : Nous n’avons pas encore partagé. Mais oui, ce sont des choses que nous pourrions partager à l’avenir sur des éléments qui seront reproductibles ailleurs. 

Elastic travaille beaucoup sur les LLM et l’IA. Est-ce que vous utilisez ces fonctionnalités ?

Nicolas : Une des contraintes par rapport à l’IA est que les LLM sont généralement sur des clouds externes. Nous réfléchissons à cet usage mais dans ce cas en hébergeant nous-mêmes ces modèles. Parmi les cas d’usages, il y a le tri des alertes, l'aide à l’analyse ou encore l'aide à gérer notre base de connaissances.