Chapitre 1 : Comprendre la cybersécurité et les risques

Accéder au laboratoire pratique et aux trois nouveaux exercices corrigés

Objectifs du chapitre

• Distinguer menace, vulnérabilité et risque.
• Relier une mesure de sécurité à un besoin concret.
• Définir un périmètre de travail autorisé.

1. Protéger une activité avant de protéger une machine

La cybersécurité rassemble les moyens humains, techniques et organisationnels qui protègent les systèmes numériques et les activités qui en dépendent. Elle concerne un téléphone, une application, un réseau, des comptes en ligne et les informations qu’ils manipulent. Un antivirus est un outil parmi d’autres : il ne décide pas qui peut consulter un dossier, ne forme pas les utilisateurs et ne garantit pas une restauration après un incident.

Notre fil conducteur est GeniusCampus, un centre de formation fictif. Il utilise une plateforme de cours, des dossiers d’inscription, une messagerie et un service de paiement. Un incident peut empêcher les cours, exposer les coordonnées des étudiants ou modifier des notes. Pour raisonner correctement, on commence par demander : quelle activité doit continuer, quelles données sont importantes et qui en est responsable ?

Un actif est un élément ayant de la valeur pour l’activité : fichier, serveur, compte, savoir-faire ou service. Un système d’information inclut aussi les personnes et les procédures. Le départ d’un salarié sans fermeture de ses accès est donc un problème de sécurité, même si aucun logiciel ne contient de faille.

2. Les trois objectifs : confidentialité, intégrité et disponibilité

Ces objectifs se complètent. Chiffrer une sauvegarde aide la confidentialité ; disposer d’une copie testée aide la disponibilité. Si la clé de chiffrement est perdue, une sauvegarde intacte devient inutilisable. Il faut donc examiner aussi les dépendances et les compromis. Ajouter une authentification forte peut sécuriser une connexion, mais une procédure de récupération mal préparée peut bloquer tous les enseignants.

L’authenticité concerne l’identité de l’origine d’une information. La traçabilité permet de retrouver une action et son contexte. Elles aident à expliquer un incident, mais un journal peut lui-même être incomplet ou altéré. Un événement enregistré ne constitue pas automatiquement une preuve suffisante.

3. Comprendre le scénario de risque

Une menace est une cause possible de dommage : escroquerie, vol d’un ordinateur, panne ou erreur. Une vulnérabilité est une faiblesse : logiciel non corrigé, partage public, compte inutilisé encore actif. Le risque décrit un scénario où cette faiblesse et cette menace peuvent produire un impact. On ne confond donc pas la présence d’une faille avec la certitude d’un incident.

Exemple : un ancien compte enseignant reste actif avec un mot de passe réutilisé. Une personne obtient ce mot de passe à la suite d’une fuite sur un autre site, se connecte et télécharge des dossiers. L’actif est le dossier étudiant ; la faiblesse est la gestion des accès ; la conséquence est une divulgation. Révoquer les comptes au départ et activer le MFA réduit ce scénario, sans régler toutes les autres causes de fuite.

Pour un premier atelier, on peut classer la vraisemblance et l’impact sur trois niveaux : faible, moyen, fort. Ce classement facilite une discussion ; ce n’est pas une mesure scientifique ni une probabilité calculée. On note les hypothèses : exposition à Internet, historique d’incidents, facilité d’exploitation, durée d’arrêt acceptable et sensibilité des données.

4. Choisir des mesures et un responsable

Une mesure préventive réduit la possibilité d’un incident ; une mesure de détection révèle un comportement suspect ; une mesure de réaction limite les dommages ; une mesure de reprise rétablit l’activité. Sur le même scénario, on peut donc combiner un accès limité, une alerte de téléchargement inhabituel, une procédure de révocation et une restauration vérifiée. C’est la défense en profondeur.

GeniusCampus tient un registre simple : actif, scénario, impact, mesure, responsable et date de vérification. « Sécuriser le serveur » n’est pas une action vérifiable. « Retirer les comptes des personnes parties, puis contrôler la liste chaque mois » décrit une action, une preuve et une fréquence. Un risque restant après les mesures est appelé risque résiduel ; il doit être connu et assumé par un responsable compétent.

5. Une pratique responsable

Apprendre à observer des systèmes n’autorise pas à tester ceux d’un tiers. Les exercices de ce cours se font sur vos propres fichiers, sur des données fictives ou dans un environnement explicitement autorisé. Pour un atelier collectif, définissez le périmètre, la durée, les comptes, les actions permises et le contact à prévenir en cas d’imprévu. Évitez de copier des données personnelles réelles dans un laboratoire.

À retenir : une bonne mesure se justifie par un scénario, protège un objectif et possède un moyen de vérification. Le but est de réduire les risques à un niveau adapté à l’activité, en gardant les services utilisables.

Exercices et corrigés

Essayez de répondre avant de déplier les corrigés. Les situations et données sont fictives.

Sources officielles et approfondissements

Repères consultés le 14 octobre 2026. Les cas GeniusCampus et les schémas sont des exemples pédagogiques originaux.

• NIST : Présentation du CSF 2.0

Laboratoire 1 : Installer le laboratoire et définir le périmètre

Objectif : Mettre en place un environnement de formation local et produire une fiche de périmètre vérifiable. Durée indicative : 45 à 60 minutes.

NKILItech souhaite former son équipe sur une application volontairement vulnérable. WebGoat fournit cet environnement pédagogique ; il ne faut pas le confondre avec le portail de production. Le périmètre de cet atelier comprend uniquement votre instance locale, des comptes inventés et les fichiers fournis. Aucun test ne vise un site tiers.

Prévoir Docker opérationnel, un navigateur distinct des usages professionnels et une machine de laboratoire isolée. Utiliser un moteur Docker à jour, au minimum 28 pour éviter l’ancienne limite des publications sur localhost signalée dans sa documentation. Télécharger l’image avant d’isoler la machine du réseau ; ne pas créer de redirection de ports ou de tunnel public.

Manipulations guidées

1. Créer une fiche indiquant : responsable, machine de laboratoire, cibles 127.0.0.1:8080 et :9090, données fictives, date, méthode d’arrêt et preuves attendues. Exclure explicitement les applications réelles de NKILItech.
2. Contrôler Docker avec docker version. Télécharger l’image officielle puis relever son digest : il identifie la version réellement utilisée même lorsque le nom de l’image évolue.
3. Lancer la commande ci-dessous dans un terminal dédié. Garder les publications sur 127.0.0.1. WebGoat utilise /WebGoat/ et WebWolf /WebWolf/ ; attendre le démarrage avant de créer un compte de formation.
4. Dans un second terminal, vérifier docker port nkilitech-webgoat. Les deux ports doivent être associés à 127.0.0.1, pas à 0.0.0.0. Si un port est déjà pris, arrêter et comprendre le conflit plutôt qu’élargir l’écoute.
5. À la fin, utiliser docker stop nkilitech-webgoat. Le paramètre --rm retire le conteneur éphémère après son arrêt ; les progrès qui ne sont pas sauvegardés ailleurs peuvent disparaître. Conserver vos notes sans mots de passe ni cookies.

docker version
docker pull webgoat/webgoat
docker image inspect webgoat/webgoat --format '{{index .RepoDigests 0}}'
docker run --rm -it --name nkilitech-webgoat -p 127.0.0.1:8080:8080 -p 127.0.0.1:9090:9090 webgoat/webgoat
# Dans un second terminal :
docker port nkilitech-webgoat
# Adresses à ouvrir dans le navigateur :
# http://127.0.0.1:8080/WebGoat/
# http://127.0.0.1:9090/WebWolf/
# En fin de séance :
docker stop nkilitech-webgoat

Résultats attendus et preuves à conserver

Fiche de périmètre, digest de l’image, ports publiés, capture de l’accueil local et constat d’arrêt. Cette préparation ne prouve pas que toutes les leçons sont réussies.

Limites de la démonstration

Docker et WebGoat ne sont pas nécessaires aux exercices Python hors ligne. Une publication sur localhost réduit l’exposition mais ne remplace pas l’isolation de la machine ; les autres processus locaux restent dans le périmètre de confiance.

Télécharger les ateliers Python complets, le journal fictif et le modèle de rapport · Mode d’emploi et code complet

Trois exercices d’application corrigés

1. Pourquoi préciser 127.0.0.1 ?

Comparer -p 8080:8080 et -p 127.0.0.1:8080:8080.

Voir le corrigé 1

La première forme publie normalement sur toutes les adresses de l’hôte ; la seconde limite la publication à la boucle locale. Pour une application volontairement vulnérable, conserver cette restriction et l’isolation du laboratoire.

2. Préparer la reproductibilité

Pourquoi noter un digest et pas seulement webgoat/webgoat ?

Voir le corrigé 2

Le nom sans digest peut désigner une image différente lors d’un téléchargement ultérieur. La fiche doit enregistrer la version ou le digest réellement utilisé ainsi que les titres de leçons observés.

3. Vérifier la fin de séance

Le navigateur ne répond plus. Cela suffit-il à prouver que le conteneur est arrêté ?

Voir le corrigé 3

Non. Le navigateur peut avoir un problème distinct. Contrôler docker ps et le résultat de docker stop. Avec --rm, le conteneur arrêté disparaît ; l’image téléchargée reste disponible.

Références du laboratoire

• Installation officielle WebGoat
• Publication des ports Docker

Complément original PandaCodeur, cas NKILItech fictif. Les interfaces de WebGoat peuvent évoluer : relever la version et le titre de la leçon suivie.