# CyberHumanumEst, une guerre cyber autour des Riverchelles

Guillaume Bonfante, Jean-Philippe Auzelle, Rémi Badonnel, Sébastien Duval, Stéphane Gégout, Marion Gilson, Clément Joliot, Éric Koessler, Audrey Knauf, Nicolas Krommenacker, et al.

► To cite this version:

Guillaume Bonfante, Jean-Philippe Auzelle, Rémi Badonnel, Sébastien Duval, Stéphane Gégout, et al. CyberHumanumEst, une guerre cyber autour des Riverchelles. Rendez-Vous de la Recherche et de l'Enseignement de la Sécurité des Systèmes d'Information (RESSI) 2024, Centre de Recherche en Informatique, Signal et Automatique de Lille (Cristal, Université de Lille), May 2024, Eppe-Sauvage, France. hal-04988987

HAL Id: hal-04988987

https://hal.science/hal-04988987v1

Submitted on 13 Mar 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# CyberHumanumEst, une guerre cyber autour des
Riverchelles

Guillaume Bonfante

Jean-Philippe Auzelle

Rémi Badonnel

Sébastien Duval

LORIA, Université de Lorraine

Université de Lorraine

LORIA, Université de Lorraine

LORIA, Université de Lorraine

Stéphane Gégout

Marion Gilson

Clément Joliot

Col. Eric Koessler

Préfecture de Meurthe et Moselle

CRAN, Université de Lorraine

Sotéria-lab

Cdt de la Base de Défense de Nancy

Audrey Knauf

Nicolas Krommenacker

Sébastien Schmitt

Pierre Veutin

CREM, Université de Lorraine

CRAN, Université de Lorraine

CNRS, Université de Strasbourg

Soteria-Lab

**Abstract**—Nous présentons CyberHumanumEst, une cyber-guerre organisée autour du campus nancéien en sécurité informatique et en communication. Nous abordons les questions d'organisation d'un tel évènement, nous présentons le scénario type et nous discutons la dynamique de jeu pendant la semaine de combat dans les équipes d'étudiants.

**Index Terms**—cyber-security, cyberwarefare, training exercise

En janvier 2021, à l'orée du confinement, nous avons organisé une première cyber-guerre estudiantine entre deux écoles d'ingénieurs de Nancy, l'Ecole des Mines et Polytech Nancy. L'enthousiasme des étudiants a été un moteur profond de motivation pour renouveler l'expérience et l'enrichir. L'exercice est annuel, il s'est maintenant installé dans le paysage pédagogique local et même intégré dans certaines formations. Nous en sommes à la quatrième édition, début février 2024, c'est un bon moment pour partager quelques observations, et—éventuellement—quelques conseils, fruits de nos expériences passées.

La cyber-guerre s'intitule désormais cyberhumanumest (CHE). En quelques mots, elle réunit une centaine d'étudiants, elle dure une semaine, elle engage toute la place nancéienne des étudiants en cyber-sécurité. CHE est organisé par l'Université de Lorraine, la base de défense de Nancy et le COMCYBER. Les deux parties sont en charge de l'organisation générale, elles apportent également du personnel en support.

Les formations organisatrices sont les suivantes. Les écoles d'ingénieurs : Mines Nancy, Polytech Nancy, Télécom Nancy, les masters : informatique/SIRAV, information/communication/VSOC, de l'Université de Lorraine et l'IUT de Nancy-Brabois. Nous avons régulièrement des formations invitées (en 2024, une formation luxembourgeoise).

Mais commençons par décrire le "jeu" de manière globale, cela va nous servir de boussole pour les discussions à venir.

## I. LE SCÉNARIO

Trois pays sont en jeu, disons—les noms changeant d'année en année—les îles des Riverchelles, le Cryptanga et l'Anumeric. Les îles font un appel d'offre—ouvrir une mine,

réhabiliter les hopitaux, etc—qui est l'objet de la convoitise des deux autres. Toute la gamification est organisée autour de la compétition entre les deux concurrents, Cryptanga et Anumeric. Dès lors, l'objectif est en place, il devient possible de compter des points et de désigner un vainqueur—même si dans les faits, il n'y pas vraiment besoin de motiver les troupes, elles arrivent prêtes à en découdre.

Les deux pays, le Cryptanga et l'Anumeric sont représentés chacun par une équipe d'étudiants d'une quarantaine de personnes. Chaque équipe a en charge une infrastructure informatique et la gestion des médias pour la composante informationnelle. Elle doit s'organiser pour gagner le contrat. Nous n'avons pas attribué d'étudiants pour les Riverchelles qui ne sont que le prétexte pour la bataille. Les deux équipes ont en même temps la possibilité de se défendre et d'attaquer. Mais quoi attaquer au fond ?

En plus des infrastructures informatiques, les deux pays gèrent des réseaux sociaux, un journal, un ou plusieurs opérateurs d'importance vitale (OIV). Tout peut être cible d'attaque : défigurer le journal du pays ennemi, corrompre des documents, casser l'OIV des opposants, et même emprisonner un adversaire.

<figure><img src="image_2.png" /></figure>

Chaque pays dispose d'une ambassade, séparée physiquement du reste de l'infrastructure. On y trouve par exemple des machines physiques, des points d'accès wifi, un poste de chiffrement, etc. L'OIV, composé de matériels physique, est également séparé de l'infrastructure.

Les deux pays sont pilotés par un triumvirat composé
de deux ingénieurs et d'un étudiant en veille stratégique et communication, les capitaines. Ils servent de point de liaison entre l'organisation et les équipes. Ils ont également le rôle d'assurer la gestion des troupes, de faire les choix stratégiques. Ils sont séparés physiquement des autres étudiants pendant la semaine, sauf des étudiants en charge de la lutte informatique d'influence (L2I) qui restent au contact direct.

Vient une troisième équipe, nommée APT-54, qui joue un rôle de pirates. L'équipe est composée d'une vingtaine d'étudiants. Ils ne doivent gérer ni infrastructure informatique ni journal, ni OIV. De ce fait, ils n'ont pas de travail de défense (ou un minimum: ils peuvent être attaqués eux-même). Leur objectif est de "gagner" le plus d'argent possible via des actes de vandalisme, de rançonnage, de vol d'informations, de destruction des infrastructures réseau, d'installation de malware, etc. Ils peuvent passer des contrats auprès des deux autres équipes.

## II. INFRASTRUCTURE

Chaque pays est donc en charge d'une infrastructure informatique composée chacune d'environ 100 machines. On y retrouve des services usuels comme un ActiveDirectory, mais aussi SMB, LDAP, DNS, RPC, RDP, des serveurs de fichiers (GIT, FTP), un serveur proxy. Ils sont cloisonnés via des routeurs et des commutateurs. En outre, on y trouve des applications comme du mail (via Zimbra), des réseaux sociaux, des bases de données, le site web du journal. Pour des raisons de capacités de disque et de coût en temps de calcul, la plupart des machines sont des machines sous linux, mais nous avons aussi des machines sous OS windows comme celle qui concerne l'AD. Voici un plan général du réseau d'un des deux pays.

<figure><img src="image_3.png" /></figure>

L'infrastructure est essentiellement virtuelle. Nous exploitons un cyber-range qui s'appuie sur un hyperviseur KVM mis à disposition par le COMCYBER. Le serveur central est composé de 2\*64 cœurs, de 2\*256G de RAM, de 2\*6To de disques RAID. Dans les faits, la seule limitation vient du nombre de cœurs, vu la relation directe au nombre de machines virtuelles. Sinon, nous n'avons pas eu de problème de charge, de bande passante ou de capacités de mémoire disque. Le cyber-range est connecté à un routeur pour toutes les connexions réseau vers les matériels physiques. Les connexions réseau sont virtuelles en majorité mais nous utilisons aussi des routeurs physiques, un routeur fortinet par exemple. Le matériel est transportable dans des caisses,

une facilité que nous avons exploitée sur plusieurs sites comme Polytech Nancy ou l'IUT. Dans la version multi-sites, le cyber-range a été interconnecté à un deuxième cyber-range du même type mis à disposition par TELECOM Nancy. L'ensemble de l'exercice est strictement cloisonné, nous n'avons pas d'accès sur le web.

<figure><img src="image_4.png" /></figure>

La mise en place de l'infrastructure est une tâche très lourde. La construction des machines virtuelles prend beaucoup de temps. L'automatisation est délicate. Il est souvent nécessaire de laisser des vulnérabilités. Or, les mises à jour automatiques ne sont pas paramétrées pour cela. Des outils comme Ansible pour le déploiement des machines peuvent devenir plus un problème qu'une solution. La seconde tâche qui est également extrêmement chronophage est la construction de la topologie du réseau. L'ensemble des services doit être anticipé, une gageure pour un tel exercice qui reste toujours en construction, par exemple pour exploiter de nouvelles attaques. En outre, pour éviter l'effet miroir, les topologies sont différentes entre les deux pays de sorte que connaître sa propre infrastructure ne permet pas de répliquer l'attaque sur le pays ennemi.

Enfin, il ne faut pas oublier l'infrastructure propre au jeu. Il faut prévoir par exemple un système de décompte des points. Nous avons utilisé plusieurs solutions, actuellement rootthebox. Nous avons également des serveurs git, ftp, etc. Ces machines peuvent être vues par les joueurs. Il leur est interdit d'y toucher. D'autre part, le cyber-range lui-même est physiquement protégé, les étudiants n'y ont pas accès.

## III. UNE SEMAINE INTENSE, PRÉPARATION

Même si le travail sur le cyber-range n'a lieu que pendant une semaine, l'exercice se déroule sur plusieurs mois. Il y a une phase de préparation, et seulement ensuite nous leur donnons accès au cyber-range. Au mois d'octobre, les étudiants sont réunis pour une première journée, le kickoff. Nous y présentons le scénario global (l'histoire de l'appel d'offre par exemple), les équipes sont constituées et enfin, nous leur proposons une activité de type CTF pour apprendre à se connaître. Nous avons opté pour des équipes mixtes (ingénieurs, techniciens, masters) qui enrichissent la dynamique du jeu.

Dès ce moment là, nous leur ouvrons un serveur discord afin qu'ils puissent échanger entre eux, sur leur organisation interne, l'attribution de rôles, pour s'auto-former mais aussi pour créer de la cohésion d'équipe. A cette fin, nous leur demandons par exemple de créer les visuels de leur équipe. La semaine est éprouvante, elle demande aux étudiants des
capacités humaines qu'ils n'ont pas souvent l'occasion de pratiquer : garder son calme, être tolérant, communiquer de manière positive. La période du mois d'octobre au mois de février leur permet de se préparer techniquement, mais aussi d'aller boire des verres ensemble. Cette période est intégrée plus formellement dans la formation du master VSOC sous la forme de projet tutorés.

La semaine de travail a lieu en début février. C'est la date qui s'avère la meilleure pour CHE. Les étudiants ingénieurs ainsi que les étudiants du BUT sont en fin de formation, leurs stages commencent un peu après cette période, c'est donc d'une certaine manière le *grand finale* de leur scolarité à l'Université. La semaine est décomposée en quatre phase,

* la découverte de l'environnement,

* l'attaque et défense,

* le retour d'expérience,

* la remise des prix.

La phase de découverte permet aux étudiants de compren-
dre l'environnement de travail. Elle dure une journée. Les
étudiants sont invités à cartographier leur réseau, à gérer
leur site, à exploiter les OIVs. Pendant cette journée, ils
sont assurés qu'il n'y aura pas d'attaques. Cela leur permet
d'avoir une pleine conscience des scénarios nominaux. Il est
absolument nécessaire qu'ils comprennent par la suite que leur
propre infrastructure est la cible d'une attaque.

Pour la seconde phase, les étudiants doivent gérer leur système comme au premier jour, mais ils ont également la possibilité de lancer une attaque. Nous l'organisons sur deux journée, y compris une nuit. Nous revenons plus en détail sur cette phase par la suite.

Lors du retour d'expérience (RETEX), chaque équipe fait une présentation de ce qu'elle a fait, de ses succès, de ses échecs. Elles présentent également la cartographie du réseau telle qu'elles le perçoivent. C'est une étape importante. Elle amène les étudiants à récolter *pendant les trois jours précédents* des informations pour le RETEX. Elle leur demande de mettre en forme les idées qu'ils ont pu avoir, de les synthétiser. Et bien sûr, c'est aussi un exercice de communication de crise. Pour un RETEX de bonne qualité, il est nécessaire de prévoir une demi-journée de préparation.

Enfin, nous avons un jour pour la remise des prix. Afin
de récompenser tout le monde, nous avons prévu plusieurs
catégories. La meilleure attaque technique, la meilleure organi-
sation en défense, la meilleure lutte d'influence, les meilleurs
visuels, etc. Il y a évidemment un "grand" prix. C'est le jour
où les autorités et nos partenaires industriels sont présents.
Nous organisons pour eux et pour nos étudiants un forum des
métiers. Les entreprises, les services d'état ont un accès direct
à des étudiants formés en cyber-sécurité. Elles nous en sont
reconnaissantes.

IV. LUTTE INFORMATIQUE OFFENSIVE/DÉFENSIVE

L'objectif de chaque équipe reste de gagner le fameux
marché. Pour cela, ils sont amenés à organiser des attaques,
et en parallèle de s'en défendre. Le fait qu'il y ait un objec-
tif extérieur, qu'il ne s'agisse pas simplement de "défoncer

l'adversaire" produit des effets importants pour le jeu. Les étudiants établissent des stratégies, par exemple garder un reverse-shell ouvert sans l'exploiter pour gagner un effet de surprise. Contrairement à un CTF ou le flag est l'objectif, les étudiants vont organiser des kill-chains. De ce fait, ils sont rapidement amenés à considérer tous les aspects d'une attaque informatique : reconnaissance, construction d'un exploit, escalade de privilège, mouvements latéraux, implantation d'un malware, etc. Chaque étape est planifiée, éventuellement préparée dans un bac à sable. Une attaque réussie dans son intégralité amène des cris de joie qui témoignent de l'investissement des étudiants dans leur tâche.

Les durées des phases d'attaques sont variées. Un scan de réseau peut prendre quelques minutes s'il est peu intrusif, il peut être beaucoup plus long. Certains exercices sont particulièrement difficiles : nous leur proposons d'attaquer par exemple des échanges réseaux chiffrés, de faire du reverse sur la DLL "mindstorm" qui pilote les robots de lego, une réplique de l'attaque de stuxnet. L'échelle des gains est adaptée pour rendre compte de la difficulté.

Les équipes n'ont pas le droit de lancer une attaque sans l'aval de l'organisation qui joue le rôle de décideur final (les fictifs PDG ou président de la république). Cela nous permet de contrôler—au moins partiellement—les activités des deux équipes, mais surtout, cela rend compte des chaines de décisions réelles, avec les deux éléments : savoir remonter l'information pertinente pour que le décideur comprenne la situation, mais aussi pour rendre compte des lenteurs intrinsèques de ces chaînes. De la même manière, en défense, les étudiants peuvent patcher leur système mais ils doivent passer par la hiérarchie. A nouveau, cela permet de modéliser des structures décisionnelles intermédiaires comme un CSIRT ou une DSI qui vont prendre en compte l'aspect économique de l'intervention. Voici l'exemple d'un planning de train qui a été corrompu :

<figure><img src="image_5.png" /></figure>

Dans un premier temps, les étudiants doivent maîtriser leur
propre infrastructure, ils doivent la cartographier, ils doivent
reconnaître d'éventuelles failles. En effet, comme le temps de
l'exercice est très court, cela avantage évidemment l'attaque
sur la défense. Il est donc important de laisser aux équipes
un moment purement consacré à la défense. C'est la raison
pour laquelle les attaques sont interdites la première journée.
Ensuite, l'organisation gère partiellement la progression de
chaque équipe en donnant les autorisations d'attaque ou de
défense. Toutefois, si une équipe propose une correction
refusée par l'organisation, mais qu'elle se fait attaquer sur la
vulnérabilité, elle gagne suffisamment de points en défense en compensation.

En termes d'outillage, les machines de l'exercice des utilisateurs (côté défense, côté attaque) sont des machines sous linux avec une distribution kali. Les étudiants disposent donc dès le départ de la plupart des logiciels nécessaires comme nmap, wireshark, metasploit, etc. Si les machines sont déconnectées du web, les étudiants gardent la possibilité d'utiliser leurs machines personnelles pour y faire des recherches. Ils ne s'en privent pas pour retrouver le mot de passe par défaut des matériels reconnus (une caméra, une enceinte connectée, etc), comme source d'information : tutoriels, documentation technique. Ils utilisent également des services sur le cloud pour des calculs plus intensifs : inversion d'un hash, casse d'une clé courte.

## V. LUTTE INFORMATIONNELLE OFFENSIVE/DÉFENSIVE

Rappelons que la lutte informatique d'influence est en charge de déstabiliser l'adversaire par ses différentes communications sur les médias (presses et réseaux sociaux) mais aussi de riposter en cas d'attaque informationnelle. Les étudiants élaborent pour cela des narratifs avec trois objectifs SALEURS : conforter les convaincus, convaincre les indécis, et marginaliser les réfractaires. Les différentes stratégies à opérer consistent à limiter l'impact des crises frappant son camp, exploiter les crises frappant l'adversaire et créer des crises chez l'adversaire, le tout, au sein d'un réseau social interne.

De ce fait, la lutte d'influence produit une dynamique sur l'ensemble de l'exercice. Les informaticiens vont pouvoir nourrir la L2I de faits, d'informations difficilement contestables par l'adversaire. Ils peuvent également donner accès à des canaux de communication imprévus comme un compte sur un réseau social ennemi. Trouver un document compromettant n'est pas juste un "flag", cela devient une "news" avec toute la charge émotionnelle associée. C'est un élément de motivation pour l'ensemble des étudiants. La L2I peut également participer en attaque, par exemple en envoyant des faux document, ou en forgeant des mails de phishing. Voici un exemple de faux document rédigé par les étudiants :

Prix et versement par l'acquérisseur
La présente vente, soumise aux droits d'enregistrement que l'acquérisseur acquittera en sus du prix le jour de la signature de l'acte authentique, est consentie et acceptée moyennant le prix principal de 1 000 000 €.

L'acquérisseur

Phil Anthrope

<figure><img src="image_6.png" /></figure>

Le vendeur

NATE STUX

<figure><img src="image_7.png" /></figure>

Un des organisateurs suit en permanence l'activité dans le domaine. Il évalue les deux équipes. En outre, il gère les fuites d'informations, fuites ayant l'objectif de créer de l'activité de recherche en source ouverte. Pour l'organisation, c'est la possibilité de donner des indications aux joueurs. En particulier, cela permet d'équilibrer l'avancement de chaque équipe. En contre-partie, il est absolument nécessaire de produire des flux conséquents pour noyer les informations importantes. Nous

utilisons à cette fin l'outil chatgpt qui permet d'avoir des posts autant que des réponses naturels.

## VI. UN EXEMPLE D'ATTAQUE

Commençons par le scénario nominal. L'ambassadeur du Cryptanga est chargé de reporter une mesure de salinité à l'OIV du Cryptanga. A cette fin, il doit lire tous les quarts d'heures la valeur du capteur qu'il renvoie à l'infrastructure de son propre pays via un canal peu sécurisé (un e-mail avec une pièce jointe chiffrée au format zip afin d'assurer la confidentialité de l'information). Ensuite, l'infrastructure reporte à l'OIV le message via un réseau privé. Le capteur n'est pas directement visible par l'ambassadeur. Il doit se déplacer pour en récupérer la valeur. L'envoi est codifié : l'ambassadeur écrit un document Word qui contient la donnée. Le document suit un modèle (template) bien spécifique. La pièce est attachée à un courrier électronique à destination de l'infrastructure. Le mot de passe qui sert au chiffrement du fichier zip est mis à jour toutes les 6 heures via un canal privé, fortement sécurisé, techniquement une liaison radio chiffrée. L'opérateur de l'OIV, à la réception du document, le dézippe (avec le mot de passe temporaire), et met à jour l'automate en fonction du paramètre et enfin, rend compte de l'opération auprès de sa blue-team.

Un tel scénario offre de nombreux angles d'attaque. Par exemple, pour gagner du temps, il est attendu que l'ambassadeur utilise un robot mobile pour chercher la valeur du capteur. Cela lui évite de quitter son poste. Il est alors possible de hacker le robot (à base de raspberry) qui est faiblement protégé. L'ambassadeur sera amené à envoyer une fausse valeur, et sera sanctionné.

Il est aussi possible de s'attaquer à la transmission du mot de passe sur le canal radio. En récupérant quelques couples clairs-chiffrés d'entiers dans la corbeille de l'ambassadeur (ou via de l'espionnage), les attaquants peuvent reconnaître le protocole de chiffrement/déchiffrement : c'est un AES-128 en mode CTR. À l'analyse, ils peuvent découvrir que le nonce est de valeur fixe. Cette information est suffisante pour une attaque cryptographique relativement simple à retrouver sur le web.

À ce moment là, les attaquants peuvent glisser de fausses mises à jour du mot de passe pour bloquer la transmission du relevé du capteur.

Mais il y a un autre scénario plus ambitieux. Les attaquants peuvent accéder à un exemplaire du courrier par espionnage. S'ils parviennent à avoir accès au poste de l'ambassade en exploitant une clé USB piégée, ils seront en mesure d'envoyer un courrier à la blue-team avec un mot de passe correct et une usurpation d'identité. En outre, le courrier peut être formaté pour être porteur d'un dropper de malware, dropper qui s'exécute sur le poste de l'opérateur de l'OIV sans que ce dernier ne s'en rende compte. Le dropper modifie la DLL qui pilote l'automate, ce qui dérègle son fonctionnement. Il est attendu que l'équipe attaquante profite du dysfonctionnement de l'OIV pour la lutte informationnelle.
## VII. L'AUTO-ORGANISATION ESTUDIANTINE

Nous avons déjà abordé le sujet plus tôt, mais revenons sur l'organisation interne des étudiants. Dès la première édition, nous avons constaté que c'est un élément clé pour la dynamique du jeu. Il y a plusieurs facteurs à prendre en compte.

Premier point, les étudiants viennent d'horizons différents. Par défaut, ils vont avoir tendance à se regrouper par formation. Au bout d'un moment, ils se rendent bien compte que leurs compétences sont complémentaires, mais cela peut arriver trop tard dans le jeu. Il est donc important de la part de l'organisation d'assurer une "mixité" minimale à l'intérieur des équipes. Les quelques mois de préparation en amont contribuent à casser la glace entre les étudiants.

Deuxième point, les étudiants vont s'organiser de manière hiérarchique. Certains vont donc donner des ordres à d'autres. Et ça peut mal se passer. Typiquement, pour les ingénieurs, CHE est un entrainement aux responsabilités. Ils vont prendre une place hiérarchique "supérieure" vis à vis des étudiants du BUT ou de M1. Ces derniers peuvent alors être frustrés si les décisions sont prises sans eux, alors qu'ils se sentent (et sont) plus compétents que les autres dans leur domaine (faites faire des branchements de routeurs à des ingénieurs et à des techniciens, on voit la différence). Là aussi, il est important de préparer (surtout) les ingénieurs à l'exercice.

Troisième point. Nous avons une majorité d'étudiants scientifiques et un petit nombre d'étudiants qui viennent des sciences humaines. Le choc culturel est compliqué. La première année, les communicants étaient séparés physiquement des informaticiens, pas beaucoup, de part et d'autre d'un mur avec une porte ouverte. Il a fallu installer tout le monde dans la même pièce pour que les étudiants se parlent.

Quatrième point. Nous avons donc des capitaines qui ont un rôle différent des autres. Séparés physiquement des étudiants informaticiens, leurs seules informations passent par les membres de l'équipe sur le terrain. Ce simple fait va produire des effets majeurs : les capitaines peuvent avoir rapidement une idée complètement fausse de la situation. C'est très amusant pour l'organisation et tout à fait formateur pour les étudiants, mais cela peut conduire à des révoltes dans les équipes (nos capitaines sont-ils idiots ou quoi ?). C'est la raison pour laquelle les enseignants choisissent les capitaines. Ils sont sélectionnés pour leur contact avec les autres, leur bienveillance et leur sens de l'écoute. Enfin, comme ils sont en charge de la restitution à l'occasion du RETEX, mieux vaut qu'ils aient de bonnes qualités d'expression.

## VIII. QUELQUES PRINCIPES D'ORGANISATION

L'organisation d'un évènement comme CHE dépasse les capacités de l'Université de Lorraine. Le partenariat avec la base de défense est indispensable. Inversement, la base de défense y trouve son intérêt. C'est pour elle l'occasion de se présenter auprès d'un public auquel elle a peu accès en temps normal. En outre, CHE participe de la diffusion de bonnes pratiques en cyber-sécurité, cela va dans le sens de la résilience du pays face à la menace cyber.

Nous avons un comité de pilotage qui réunit de manière collégiale l'ensemble des composantes qui ont construit CHE. Le fait que chacun soit représenté est un élément important. Du fait de la médiatisation de l'évènement, il peut y avoir concurrence entre les composantes. Le comité essaie de mettre en valeur chacune au mieux. On y décide des participants, des lieux, des dates mais aussi du scénario général de l'exercice.

Il y a quatre dimensions dans l'organisation de CHE. Premier point, le pilotage de la communication, en particulier la gestion des médias, la publicité, la mise à jour du site, etc. Cette tâche est pilotée par un enseignant chercheur assisté des chargés de communication des composantes.

Deuxième point, l'organisation de la logistique. Il faut penser à réserver les salles, nourrir une centaine d'étudiants, leur proposer un couchage pour la nuit sur place, gérer les réseaux sociaux, installer le matériel informatique, assurer qu'il y ait du courant (de l'ordre de 40kW).

Troisième point, la gestion des partenariats. L'exercice demande un budget de l'ordre de 40k€ par an. Cela couvre l'achat des repas, des sweats, du petit matériel, des frais de transports, etc. Il est largement couvert par les partenaires industriels. Néanmoins, là aussi, il est important de désigner une personne ayant cette responsabilité.

Enfin, dernier point, le scénario et la construction de kill-chains. Chaque année, nous renouvelons le stock d'attaques. Premièrement, parce que certaines ne sont plus à jour. Deuxièmement, pour donner des éléments de surprise chez les étudiants. Troisièmement, pour l'illustration concrète des attaques vues en cours. Mais aussi, il faut bien le dire pour le fun.

A l'issue de chaque exercice, nous avons organisé un RETEX interne. Environ une semaine après, quand tout est encore chaud dans les esprits, on revient sur les points positifs, les soucis rencontrés, les menaces, les opportunités à envisager. La rencontre est importante, et il est encore plus important que les participants y contribuent à coeur ouvert.

Concernant les personnels, en sus des composantes d'enseignement directement impliquées au sein de l'Université, deux laboratoires sont à l'oeuvre, le laboratoire d'informatique, le LORIA, et le laboratoire d'automatique, le CRAN et le CREM. Si on réunit les personnels de la base de défense et ceux de l'université, une douzaine de personne travaillent sur l'exercice à l'année (essentiellement la préparation des attaques, le maintien en condition opérationnel du terrain de jeu, et l'organisation), nous avons le renfort d'une vingtaine de personnes pendant la semaine d'exercice.

## IX. CONCLUSION

CHE est un bel évènement. Même si nous en sommes à la quatrième édition, nous en sommes encore à une phase de construction. Tous les ans, nous améliorons nos processus. Quelques éléments semblent se stabiliser.

Le début février semble la période optimale. Les étudiants sont en fin de scolarité, ils sont au maximum de leur compétence, c'est à ce moment qu'ils profitent le plus de l'exercice.
Par le passé, nous avons travaillé en multi-sites. Technique-
ment, c'est faisable. Cela n'obère pas la dynamique du jeu. La
contrepartie, c'est que cela multiplie les besoins de personnel
encadrant. Il n'y a pas tant de volontaires que ça pour passer
une nuit avec les étudiants.

La construction de l'infrastructure prend beaucoup de
temps. Et cela reste vrai après plusieurs éditions. Une petite
modification sur une machine, un nouveau service amène
rapidement à revoir l'infrastructure générale. C'est à prévoir
pour une organisation comme la notre.

La nuit reste une expérience intense. Les étudiants sont
directement confrontés aux problèmes de fatigue, de manque
de lucidité, de changement de caractère. Le repas du soir laisse
des souvenirs marquants.

Il faut aider les étudiants à communiquer entre eux. Chaque
année, nous avons dû remettre de l'huile dans certains rouages.
Les capitaines ont du mal à comprendre qu'ils font fausse route
et qu'ils ont une image fausse de la réalité. C'est tout un art
que de les remettre sur des rails.

En conclusion, au dire des étudiants, CHE est un élément
incroyablement formateur. Ils sont très fiers d'y participer,
il suffit de les voir le jour des récompenses. Et certains et
certaines nous ont déjà recontacté pour y contribuer comme
organisateur.

X. REMERCIEMENTS

Les auteurs remercient l'ensemble des personnes impliquées
dans CHE. Sans elles, un tel exercice ne pourrait pas être
réédité tous les ans. Merci encore !