Cybersécurité

Objectifs

1. Lire et appliquer les référentiels de sécurité qui engagent l'entreprise.
2. Repérer les failles applicatives les plus fréquentes et savoir les corriger.
3. Sécuriser l'accès, la configuration, les secrets et la chaîne logicielle.
4. Mettre en place une détection et une réponse à incident.
5. Préparer une mise en conformité auditable.

Public visé

Développeurs, responsables techniques et RSSI. Aucune expérience préalable en sécurité n'est requise.

Durée

40 heures. Chaque module se termine par un atelier où les mesures sont vérifiées sur une application réelle.

Avertissement

Ce cours est pédagogique. Il ne remplace pas un audit professionnel, et les techniques présentées ne doivent pas être utilisées en dehors d'un cadre autorisé : tester une application qui n'est pas la sienne est illégal.

Le Top 10 OWASP recense les risques applicatifs les plus fréquents. La version de référence est la 2025, qui a remplacé la 2021.

Rang	Risque
A01:2025	Contrôle d'accès défaillant
A02:2025	Mauvaise configuration de sécurité
A03:2025	Défaillance de la chaîne logicielle
A04:2025	Défaillances cryptographiques
A05:2025	Injection
A06:2025	Conception non sécurisée
A07:2025	Défaillances d'authentification
A08:2025	Défaillance d'intégrité des logiciels ou des données
A09:2025	Défaillance de journalisation et d'alerte
A10:2025	Mauvaise gestion des conditions exceptionnelles

Deux enseignements à retenir de cette évolution : la chaîne logicielle (A03) est entrée au classement, ce qui traduit le poids réel des dépendances et des systèmes de construction ; et la gestion des conditions exceptionnelles (A10) fait son apparition, alors qu'on la croyait traitée depuis des années.

NIS2

La directive (UE) 2022/2555 sur la sécurité des réseaux et des systèmes d'information devait être transposée en droit national le 17 octobre 2024.

• elle étend les obligations à des secteurs entiers qu'ils relevaient du périmètre précédent ;
• les entités concernées doivent s'enregistrer auprès de l'ANSSI ;
• elles doivent signaler les incidents de sécurité d'impact important ;
• des sanctions administratives sont prévues, pouvant atteindre un pourcentage du chiffre d'affaires mondial, avec interdiction temporaire d'exercer les responsabilités du dirigeant.

La transposition française étant encore en cours au moment de la rédaction, le cours ne prétend pas décrire le détail des textes : il faut se référer aux publications de l'ANSSI, qui publie par ailleurs un socle de mesures de référence.

RGPD

Le règlement européen 2016/679 s'applique à toute entité traitant des données de personnes physiques dans l'Union. Il n'est pas un référentiel technique mais un cadre d'obligations : registre des traitements, analyses d'impact,notification des violations sous 72 heures, et principes de protection dès la conception.

À retenir : une faille de sécurité et une non-conformité ne sont pas la même chose, mais elles se combinent. Une violation de données est d'abord un problème de conformité, ensuite une faille technique.

Avant de protéger quoi que ce soit, on écrit ce qu'on cherche à protéger, ce contre quoi, et ce qu'on accepte de perdre. Sans ce document, les mesures sont choisies au hasard.

Quoi protéger      : les données clients, la facturation, l'acces administrateur
Contre quoi         : une personne non autorisee, un voleur, une erreur interne
Perte acceptable   : indisponibilite de 2 h ; perte de donnees : aucune
Engins              : acces direct, vol de secret, injection, componente vulnerable

Le modèle de menace sert ensuite de critère d'arbitrage : quand deux mesures sont possibles, on retient celle qui traite la menace qu'on a identifiée.

C'est le premier risque du classement 2025. Il ne s'agit pas seulement d'oublier une vérification : c'est le cas classique où l'application vérifie l'accès sur l'écran mais pas sur l'API.

Vérifier côté serveur, à chaque requête

# FAIBLE : le controle est dans l'ecran, l'API reste ouverte
@app.route("/api/tickets")
def liste():
    return jsonify(Ticket.query.all())   # n'importe quel utilisateur voit tout

# CORRECT : le controle est dans la couche d'acces
@app.route("/api/tickets/<id>")
@require_authenticated
def detail(id):
    ticket = Ticket.query.get_or_404(id)
    if ticket.dossier_id != g.utilisateur.dossier_id:
        abort(403)          # on verifie la propriete, pas seulement l'identite
    return jsonify(ticket.serialize())

La règle : une donnée appartient à quelqu'un. La question n'est jamais « l'utilisateur est-il connecté ? » mais « cette donnée lui appartient-elle ? ».

Le test systématique

Pour chaque point d'accès : lister ce que l'API expose, puis demander chaque ressource avec les identifiants d'un autre utilisateur. Ce contrôle, appelé test d'IDOR (référence directe non sécurisée), trouve plus de failles que l'analyse de code.

Une injection survient quand une donnée utilisateur est concaténée dans une commande interpretée : requête SQL, commande système, expression régulière, requête NoSQL.

Le principe

# Vulnerable : la saisie est concatenee dans la requete
cur.execute("SELECT * FROM users WHERE nom = '" + nom + "'")

# Correct : la requete est preparee, la valeur est un parametre lie
cur.execute("SELECT * FROM users WHERE nom = %s", (nom,))

La requête préparée n'est pas « le SQL le plus sûr » : c'est une frontière. Le moteur reçoit la structure d'un côté, les données de l'autre, et ne les mélange jamais.

Les autres vecteurs

• Système : ne jamais passer une saisie à un shell ; utiliser un appel direct au programme avec une liste d'arguments.
• NoSQL : un objet passé tel quel peut devenir un opérateur ; vérifier le type avant usage.
• Expressions régulières : une entrée utilisateur dans un motif peut provoquer un accès inattendu aux données, voire un déni de service.
• En-têtes et journaux : un retour à la ligne dans un journal permet d'y injecter une fausse entrée — c'est l'injection de journal.

Priorité : la requête préparée d'abord, la validation en second. Valider en déniant des caractères spécifiques est fragile ; la requête préparée tient quelle que soit la donnée.

• Mots de passe : hachage avec un algorithme lent et salé (bcrypt, Argon2, scrypt). Un algorithme rapide est une catastrophe : il accélère aussi l'attaque par force brute.
• Stockage des sessions : un jeton d'authentification doit être aléatoire, conservé côté serveur, invalidé à la déconnexion et à la réinitialisation du mot de passe.
• Limitation : après quelques échecs, la tentative doit être ralentie ou bloquée, sans laisser d'information sur l'existence du compte.
• Réinitialisation : le lien de réinitialisation doit être à usage unique et expirer rapidement.
• Multi-facteurs : activé par défaut sur les comptes à privilèges.

Deux erreurs classiques : un message d'erreur qui distingue « compte inconnu » de « mot de passe faux », et un mot de passe oublié qui ne change pas la session courante — l attaquant reste connecté.

1. Test d'IDOR : sur une application de votre atelier, listez les points d'accès qui exposent une ressource par identifiant et testez-les avec un autre compte.
2. Correction d'injection : réécrivez une recherche qui concatène, en requête préparée. Ajoutez un caractère spécial en entrée pour vérifier que la correction tient.
3. Revue d'authentification : relevez les messages d'erreur, la vitesse de réponse, la politique de mot de passe et la réinitialisation. Notez chaque écart.

Deuxième risque du classement 2025, et le plus facile à éviter : une configuration par défaut, un mode debug actif, un en-tête manquant.

• Environnement de production identifié clairement, avec une liste de contrôle avant mise en service.
• Mode debug et pages d'erreur détaillés désactivés : une trace d'exécution révèle la pile d'appels, la version et les chemins.
• Compte par défaut supprimé ou changé.
• Répertoires sensibles (administration, phpmyadmin, console) restreints par adresse.
• En-têtes HTTP de sécurité : politique de contenu, transport forcé, protection contre le clickjacking, référentiel de politiques.

Le réflexe : comparer la configuration de production à celle de développement, ligne par ligne. La différence est souvent le paramètre même du problème.

Le chiffrement ne sert qu'à deux choses : la confidentialité en transit et au repos, et l'intégrité. Tout le reste est du folklore.

• En transit : TLS partout, y compris entre services internes. Le réseau interne n'est pas un réseau de confiance.
• Au repos : base de données, sauvegardes, objet stocké.
• Les mots de passe ne se chiffrent pas : ils se hachent, avec un algorithme lent et un sel par utilisateur.
• Le secret ne se dérive pas du reste : une clé déduite du mot de passe est une clé faible.

Deux erreurs classiques : faire sa propre cryptographie, et réutiliser un mode de chiffrement sur toutes les données. Quand on emploie une bibliothèque éprouvée, on lit ce qu'elle documente sur le mode d'emploi, et on ne le change pas au hasard.

Un secret est toute valeur qui donne un accès : mot de passe, jeton, clé, certificat. Sa fuite est presque toujours due à trois erreurs.

1. Secret dans le dépôt : même supprimé ensuite, il reste dans l'historique et dans les clones. Le changer est la seule action qui vaut.
2. Secret en clair dans la configuration : il faut une source externe : coffre à secrets du fournisseur, coffre de l'hébergeur, gestionnaire de secrets — et une injection à l'exécution.
3. Secret dans les journaux : un secret écrit dans une trace est compromis, même si la trace est supprimée ensuite.

La règle de lecture : un secret ne doit jamais pouvoir être lu depuis le code, jamais apparaître dans un journal, et pouvoir être changé sans redéploiement de l'application.

1. Liste de contrôle : écrivez la liste de configuration de votre environnement de production, et vérifiez-la ligne par ligne.
2. Inventaire des secrets : listez tous les secrets utilisés par votre application, et indiquez pour chacun où il est stocké et s'il apparaît dans un journal.
3. Rotation : décrivez la procédure de rotation d'un secret, et vérifiez qu'elle peut être exécutée sans redéploiement complet.

Ce risque entre au Top 10 en 2025 : il traduit le poids réel des dépendances, des registres et des systèmes de construction. Une application n'est plus seulement son code : c'est son code plus tout ce qu'elle embarque.

Les trois surfaces

• Dépendances : une bibliothèque compromise se propage à toutes les applications qui l'utilisent.
• Registres et installateurs : un paquet publié puis retiré reste dans des caches et sur des machines.
• Systèmes de construction : c'est là que se décide ce qui est réellement compilé et publié.

Les mesures qui comptent

1. Verrouiller les versions et garder le fichier de verrouillage versionné : c'est ce qui rend une construction reproductible.
2. Réduire les dépendances : chaque dépendance est une surface d'attaque. Une petite bibliothèque stable vaut mieux qu'un ensemble instable et non maintenu.
3. Vérifier les signatures et empreintes des artefacts téléchargés, et échouer si elles diffèrent.
4. Analyser les vulnérabilités de façon automatique, avec un seuil qui bloque le déploiement.
5. Isoler la construction : l'environnement qui construit n'a pas accès aux secrets de production.

Cette entrée couvre la confiance accordée à un artefact, et la vérification de ce qu'on a downloaded.

• Mise à jour automatique : vérifier la signature avant d'appliquer, jamais après.
• Désérialisation : lire une donnée sérialisée venue de l'extérieur peut exécuter du code. Les chargeurs sûrs n'instancient que les classes autorisées.
• Intégrité des données au repos : un chiffrement sans authentification ne protège pas — un contenu chiffré reste modifiable, avec un risque de permutation. Il faut un mode qui authentique également.
• Signatures de code : signer l'artefact publié permet de vérifier qu'il vient bien de vous.

Entrée nouvelle du Top 10 2025, et pourtant ancienne cause de failles : le traitement de l'échec.

• Erreur masquée : un except qui ignore l'erreur transforme un problème visible en silence.
• Message trop détaillé : renvoyer une trace d'exécution à l'utilisateur facilite l'exploitation ; on journalise côté serveur, on répond « une erreur est survenue ».
• Opération à moitié faite : si la seconde étape échoue, la première a déjà été appliquée. C'est l'absence de transaction qui laisse le système dans un état incohérent.
• Échec non traité : un service qui s'interrompt sur une entrée imprévue devient un déni de service.

Le principe : l'échec est un chemin normal. Il se conçoit, se teste et se mesure, exactement comme le cas nominal.

1. Inventaire des dépendances : listez les dépendances directes et transitives de votre projet, et identifiez celles qui ne sont plus utilisées.
2. Traitement d'erreur : relevez tous les blocs qui masquent une erreur dans votre application et remplacez-les par un traitement explicite.
3. Transaction :Operations une opération en deux étapes dont la seconde peut échouer, et montrez ce qu'un traitement non transactionnel laisse derrière lui.

Neuvième risque du classement 2025. Une intrusion non détectée est une intrusion qui dure : la question n'est pas seulement « cela s'est-il produit ? » mais « combien de temps avant que je le sache ? ».

Ce qu'il faut journaliser

• connexions et échecs d'authentification ;
• changements de privilèges et création de comptes ;
• accès aux données sensibles et exports en masse ;
• modifications de configuration et de secrets ;
• échecs applicatifs inhabituels.

Ce qu'il ne faut pas journaliser

Mot de passe, jeton, carte bancaire, donnée personnelle complète. Un journal qui contient un secret devient une cible, et un journal plein de secrets coûte cher à protéger.

L'alerte

Un journal sans seuil d'alerte n'est qu'un fichier. Quelques signaux à surveiller en priorité : échecs d'authentification en rafale, accès inhabituels à des données sensibles hors heures ouvrées, et toute élévation de privilège.

La réponse à incident se prépare à froid. En pleine crise, personne n'improvise bien : les décisions se prennent à partir d'un document écrit avant.

1. Préparer : qui décide, qui intervient, comment joindre l'ANSSI ou le client, comment préserver les preuves.
2. Détecter et qualifier : périmètre, données concernées, impact.
3. Contenir : isoler sans détruire les traces.
4. Éradiquer et corriger : la cause, pas seulement le symptôme.
5. Réagir : information des personnes concernées, notification aux autorités si obligatoire.
6. Apprendre : retours d'expérience écrits, mesures ajoutées au guide de production.

Deux échéances à connaître : le RGPD impose de notifier une violation de données à l'autorité de contrôle dans les meilleurs délais et, lorsque le risque est élevé, aux personnes concernées ; NIS2 impose aux entités concernées de signaler les incidents d'impact important à l'ANSSI, selon les règles nationales de notification.

Le réflexe de départ, avant toute analyse : préserver les preuves. Redémarrer une machine ou purger des journaux fait perdre ce qui désigne la cause.

La référence publique pour décrire le comportement d'un attaquant est MITRE ATT&CK, qui organise ses techniques en tactiques. L'intérêt n'est pas la liste : c'est la méthode.

Sur une machine compromise, on regarde ce que le processus fait réellement : les processus lancés, les connexions sortantes, les clés d'accès lues, les comptes utilisés. La plupart des intrusions ne restent pas sur la machine d'entrée : elles se déplacent latéralement vers d'autres machines, ce qui n'apparaît sur aucun pare-feu puisqu'il s'agit de trafic autorisé par des identifiants volés.

La parade tient en deux points : principe du moindre privilège — un compte de service ne fait que ce qu'il lui faut — et surveillance des comptes — un usage inhabituel d'un compte service doit remonter.

1. Plan d'incident : écrivez la procédure de réponse à incident de votre application : qui fait quoi, dans quel ordre, et à quoi on ne touche pas.
2. Revue des journaux : relevez ce que votre application journalise aujourd'hui, et complétez la liste manquante.
3. Exercice de crise : simulez la compromission d'un compte de service et décrivez les trois premiers gestes, sans rien détruire.

Le projet porte sur une application de votre choix, et vise un résultat vérifiable : un rapport de conformité et des mesures effectivement appliquées.

Les cinq livrables

1. Modèle de menace : ce qu'on protège, contre quoi, et ce qu'on accepte de perdre.
2. Revue sur le Top 10 2025 : pour chacune des dix entrées, l'état, la preuve et la mesure prévue.
3. Tests d'accès : tests d'IDOR et élévation de privilège réellement exécutés, avec le résultat obtenu.
4. Inventaire des secrets et de la chaîne logicielle : dépendances, versions verrouillées, surface d'attaque.
5. Plan de durcissement : mesures priorisées par effort et par impact, avec une échéance par mesure.

Critères de réussite

• chaque ligne du rapport renvoie à une preuve reproductible, pas à une impression ;
• les cinq risques les plus probables sont traités en premier, pas les plus visibles ;
• le plan est réalisable : chaque mesure a un responsable et une échéance ;
• le rapport pourrait être lu par un auditeur externe sans oral.

La conformité se prépare comme un projet, pas comme une déclaration. Trois constats utiles :

1. Le périmètre se décide tôt : savoir si l'entité relève de NIS2 conditionne tout le reste. La France n'ayant pas encore achevé sa transposition, on se réfère aux publications de l'ANSSI, qui propose un enregistrement en ligne et un socle de mesures.
2. Les preuves priment sur les déclarations : ce qui est demandé, ce sont des traces : registres, comptes rendus, journaux, tests, rapports.
3. La sécurité des données est un obligation de moyen : on ne garantit pas qu'aucune violation n'aura lieu, on montre qu'on a fait ce qu'il fallait pour la prévenir et la traiter.

Deux référentiels ne sont pas obligatoires mais servent de structuration : ISO/IEC 27001 pour le système de management, et le référentiel CIS Controls pour les mesures techniques de référence.

Évaluation

• Quiz à la fin de chaque module.
• Atelier : test d'accès et correction sur une application de votre choix.
• Projet final : rapport et plan de durcissement, évalués sur la qualité des preuves.
• Revue : chaque atelier est relu, les remarques portent sur des points vérifiables.

Grille du projet

• méthodique : le modèle de menace précède les mesures
• précis : chaque constat est prouvé
• priorisé : l'effort et l'impact sont explicites
• actionnable : qui fait quoi, et pour quand