🛡️ Cybersécurité — Les enjeux — Guide ultra détaillé
Guide HTML pédagogique et opérationnel, au format IDEO‑Lab en thème clair. Objectif : expliquer les enjeux réels de la cybersécurité — business, techniques, humains, juridiques et organisationnels — avec scénarios, checklists, indicateurs, playbooks et cadres de référence.
Positionnement : la cybersécurité doit être comprise comme une capacité de résilience et de confiance. Elle protège la continuité d’activité, les données, les identités, les processus, les clients, la conformité et la réputation. Un programme cyber mature ne se contente pas d’empiler des outils : il relie les menaces, les actifs critiques, les contrôles, les preuves, les indicateurs et les décisions de direction.
Lecture rapide
- 24 chapitres couvrant les enjeux majeurs.
- Chaque chapitre contient vue d’ensemble, risques, scénario, contrôles, KPI, playbook, maturité et questions d’atelier.
- Usage conseillé : support de formation, préparation d’entretien, cadrage RSSI, sensibilisation direction, base de roadmap cyber.
1
🧭
Vue d’ensemble des enjeux
Pourquoi la cybersécurité est devenue un sujet stratégique, économique, juridique, opérationnel et humain.
StratégieRisqueRésilience
2
🧨
Panorama des menaces modernes
Ransomware, phishing, vol d’identifiants, exploitation de vulnérabilités, supply chain, DDoS, fraude et IA offensive.
ThreatsRansomwareSupply chain
3
🗺️
Actifs critiques & surface d’attaque
Inventaire, dépendances, exposition Internet, shadow IT, données, identités et chemins d’attaque.
InventaireASMShadow IT
4
⚖️
Gestion du risque cyber
Passer d’une logique purement technique à une logique de risques métier, de priorisation et d’arbitrage.
RiskImpactPriorisation
5
🏛️
Gouvernance & cadres de référence
NIST CSF 2.0, CIS Controls, ISO 27001, politiques, rôles, preuves et pilotage exécutif.
NIST CSFGRCCIS
6
🧠
Facteur humain & culture sécurité
Sensibilisation, phishing, habitudes, processus métier, responsabilité partagée et réduction des erreurs évitables.
HumainPhishingCulture
7
🪪
Identité, IAM & Zero Trust
Identités humaines, machines, MFA, SSO, PAM, moindre privilège, comptes à privilèges et segmentation logique.
IAMMFAZero Trust
8
🗄️
Données, confidentialité & protection
Classification, chiffrement, DLP, privacy, sauvegardes, rétention, exfiltration et valeur stratégique de la donnée.
DataPrivacyDLP
9
🧱
Sécurité applicative & OWASP
SDLC sécurisé, OWASP Top 10, revues de code, SAST/DAST, secrets, dépendances et défauts de conception.
AppSecOWASPSDLC
10
🔌
API Security
Inventaire API, BOLA, authentification, autorisation, schémas, rate limiting, GraphQL, REST et abus automatisés.
APIBOLARate limit
11
☁️
Cloud, SaaS & Kubernetes
Responsabilité partagée, IAM cloud, CSPM, CNAPP, conteneurs, Kubernetes, secrets, IaC et erreurs de configuration.
CloudSaaSK8s
12
🌐
Réseau, segmentation & accès distant
Segmentation, pare-feu, VPN/ZTNA, DNS, egress filtering, exposition, DDoS, latéralisation et contrôle des flux.
NetworkZTNASegmentation
13
💻
Endpoint, serveurs & EDR/XDR
Postes, serveurs, mobiles, EDR, durcissement, patching, privilèges locaux et visibilité comportementale.
EDRHardeningPatch
14
🧯
Ransomware, extorsion & continuité
Prévention, détection, sauvegardes, segmentation, exfiltration, crise, restauration et négociation.
RansomwareBackupsCrisis
15
🔗
Supply chain, tiers & CI/CD
Prestataires, dépendances open source, SBOM, build pipelines, secrets, mises à jour, contrats et risques hérités.
Supply chainSBOMCI/CD
16
🤖
IA, automatisation & nouveaux risques
IA défensive, IA offensive, données d’entraînement, prompt injection, deepfakes, fuite de données et gouvernance.
AILLMPrompt injection
17
🏭
OT, IoT & systèmes industriels
Sécurité des environnements industriels, IoT, disponibilité, sûreté, segmentation et contraintes opérationnelles.
OTIoTSafety
18
📡
Détection, SOC, SIEM & CTI
Logs, use cases, SIEM, SOAR, XDR, threat intelligence, détection engineering et qualité des alertes.
SOCSIEMDetection
19
🚨
Réponse à incident & gestion de crise
Préparation, triage, containment, éradication, communication, preuves, juridique et retour d’expérience.
IRCrisisForensic
20
🛟
Résilience, PRA/PCA & continuité
RTO/RPO, sauvegardes, restauration, modes dégradés, dépendances critiques et exercices réalistes.
PRAPCABackups
21
📜
Conformité, NIS2, DORA, RGPD
Obligations européennes, preuves, notification, gouvernance, résilience, données personnelles et relation juridique.
NIS2DORARGPD
22
📊
Métriques, tableaux de bord & pilotage
Mesurer la réduction du risque, la maturité, la couverture, les délais, les incidents et l’efficacité des contrôles.
KPIKRIsDashboard
23
🗓️
Roadmap 30/60/90 jours
Plan d’action concret pour structurer rapidement une démarche cyber pragmatique et progressive.
RoadmapQuick winsMaturité
24
🧪
Cas pratiques & exercices
Scénarios réalistes pour former, tester les contrôles, entraîner la crise et améliorer les réflexes.
ExercicesTabletopSimulation
🧭 Vue d’ensemble des enjeux
Positionnement.
Pourquoi la cybersécurité est devenue un sujet stratégique, économique, juridique, opérationnel et humain.
Pourquoi la cybersécurité est devenue un sujet stratégique, économique, juridique, opérationnel et humain.
La cybersécurité n’est plus un sujet réservé à l’équipe informatique : elle conditionne la continuité d’activité, la confiance client, la valeur de la donnée, la conformité, la réputation et parfois la sécurité physique.
Les organisations modernes dépendent de services cloud, APIs, SaaS, identités fédérées, chaînes CI/CD, partenaires, prestataires, mobiles et télétravail : la frontière traditionnelle du SI a disparu.
L’enjeu central consiste à réduire la probabilité d’un incident majeur, à limiter son impact, puis à restaurer rapidement les services essentiels quand l’attaque réussit malgré les contrôles.
Lecture synthétique
| Axe | Détail |
|---|---|
| Ce qu’il faut protéger | Actifs, données, identités, processus, réputation, continuité. |
| Ce qu’il faut décider | Priorités, risques acceptés, moyens, responsabilités, preuves attendues. |
| Ce qu’il faut mesurer | Couverture, délai, qualité de détection, efficacité de réponse, impact résiduel. |
Risques principaux
- Perte de chiffre d’affaires après interruption de service
- Atteinte à la réputation et perte de confiance
- Vol de données sensibles ou stratégiques
- Sanctions réglementaires et coûts juridiques
- Blocage opérationnel par ransomware ou sabotage
- Effets de chaîne sur clients, fournisseurs et partenaires
Lecture impact métier
Point critique : un risque cyber devient prioritaire quand il touche un service essentiel, une donnée sensible, une identité à privilège, une obligation réglementaire ou une dépendance fournisseur difficile à remplacer.
| Risque | Impact typique |
|---|---|
| Perte de chiffre d’affaires après interruption de service | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Atteinte à la réputation et perte de confiance | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Vol de données sensibles ou stratégiques | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Sanctions réglementaires et coûts juridiques | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Blocage opérationnel par ransomware ou sabotage | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Effets de chaîne sur clients, fournisseurs et partenaires | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
Scénario réaliste
Une PME très digitalisée confie son CRM, sa messagerie, ses sauvegardes et son hébergement à plusieurs fournisseurs SaaS. Un vol de compte administrateur permet à un attaquant d’exfiltrer les données clients, d’effacer des configurations et de bloquer la facturation. L’impact n’est pas seulement technique : ventes, support, juridique, communication et direction sont immédiatement concernés.
Chaîne d’attaque probable
Reconnaissance → accès initial → persistance → élévation → mouvement latéral → action sur objectif → extorsion / sabotage / fraude
Signaux faibles à surveiller
- Connexion inhabituelle ou impossible travel
- Volume anormal de lectures ou exports
- Création de compte, token ou règle de transfert
- Utilisation d’outils d’administration hors fenêtre
- Accès depuis IP, device ou pays atypique
- Modification de configuration sensible
Mesures de maîtrise
- Cartographier les services essentiels
- Identifier les actifs et dépendances critiques
- Définir une gouvernance cyber lisible
- Prioriser les risques selon impact métier
- Mettre en place une défense en profondeur
- Tester les plans de crise et de reprise
Matrice prévention / détection / réponse
| Phase | Exemples |
|---|---|
| Prévenir | Réduire exposition, durcir configuration, limiter privilèges, former, automatiser les contrôles. |
| Détecter | Collecter logs utiles, créer use cases, surveiller comportements, corréler signaux. |
| Répondre | Isoler, révoquer, restaurer, communiquer, documenter, améliorer. |
Règle : aucun contrôle ne doit rester purement déclaratif. Il faut une preuve observable : configuration, log, rapport de test, ticket, capture, exercice ou métrique.
Indicateurs à suivre
- Services critiques avec propriétaire identifié
- Temps maximum admissible d’interruption par service
- Pourcentage d’actifs inventoriés
- Taux de couverture MFA sur comptes sensibles
- Temps de détection moyen
- Temps de restauration testé
Comment les interpréter
| Indicateur | Lecture |
|---|---|
| Services critiques avec propriétaire identifié | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Temps maximum admissible d’interruption par service | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Pourcentage d’actifs inventoriés | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Taux de couverture MFA sur comptes sensibles | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Temps de détection moyen | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Temps de restauration testé | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
Attention : un KPI sans seuil, sans propriétaire et sans décision associée devient vite décoratif.
Plan d’action concret
- Lister les processus métiers vitaux
- Associer à chaque processus ses applications, données, comptes et prestataires
- Évaluer l’impact d’une indisponibilité de 4h, 24h, 72h
- Définir les scénarios catastrophes réalistes
- Attribuer des responsables métiers et techniques
- Tester un exercice de crise simple en moins d’une demi-journée
Livrables attendus
- Cartographie ou registre mis à jour
- Liste des décisions et propriétaires
- Actions priorisées avec échéance
- Preuves de configuration ou de test
- Indicateurs de suivi
- Retour d’expérience après exercice ou incident
Le playbook doit pouvoir être exécuté par une équipe réelle, pas seulement compris par un expert sécurité.
Échelle de maturité
| Niveau | Description |
|---|---|
| Niveau 1 — réactif | Contrôles ponctuels, dépendance aux personnes, preuves faibles, actions après incident. |
| Niveau 2 — structuré | Actifs et responsabilités définis, contrôles prioritaires, logs et procédures minimales. |
| Niveau 3 — piloté | KPI/KRI, automatisation partielle, revues périodiques, exercices et amélioration continue. |
| Niveau 4 — résilient | Mesure du risque, tests réguliers, détection avancée, réponse orchestrée, culture intégrée. |
Quick wins
- Nommer un owner
- Documenter le périmètre
- Activer logs
- Supprimer l’exposition inutile
Industrialisation
- Automatiser contrôles
- Définir SLA
- Créer preuves
- Tester régulièrement
Excellence
- Mesurer réduction de risque
- Simuler incidents
- Adapter aux menaces
- Améliorer par RETEX
Questions de cadrage à poser en atelier
- Qui est propriétaire de cet enjeu : métier, IT, sécurité, juridique ou direction ?
- Quel actif ou processus serait le plus touché si ce domaine échouait demain ?
- Quelles preuves montrent que les contrôles fonctionnent réellement ?
- Quel incident réaliste permettrait de tester ce domaine en moins de 2 heures ?
- Quelles exceptions existent et qui accepte le risque résiduel ?
- Quel indicateur simple permet de suivre la progression mois après mois ?
Atelier recommandé : 45 minutes avec métier + IT + sécurité. Objectif : sortir avec 5 décisions, 5 actions et 5 preuves attendues.
🧨 Panorama des menaces modernes
Positionnement.
Ransomware, phishing, vol d’identifiants, exploitation de vulnérabilités, supply chain, DDoS, fraude et IA offensive.
Ransomware, phishing, vol d’identifiants, exploitation de vulnérabilités, supply chain, DDoS, fraude et IA offensive.
Les menaces modernes sont industrialisées : kits de phishing, infostealers, accès initiaux revendus, ransomware-as-a-service, automatisation de scans et exploitation rapide des vulnérabilités exposées.
Les attaquants n’ont pas toujours besoin de casser la cryptographie : ils volent des identifiants, abusent de droits excessifs, exploitent une mauvaise configuration, ou compromettent un prestataire.
Le risque augmente avec l’exposition numérique : API publiques, VPN, interfaces d’administration, dépôts Git, buckets cloud, dépendances open source, SaaS mal gouvernés.
Lecture synthétique
| Axe | Détail |
|---|---|
| Ce qu’il faut protéger | Actifs, données, identités, processus, réputation, continuité. |
| Ce qu’il faut décider | Priorités, risques acceptés, moyens, responsabilités, preuves attendues. |
| Ce qu’il faut mesurer | Couverture, délai, qualité de détection, efficacité de réponse, impact résiduel. |
Risques principaux
- Credential stuffing et comptes compromis
- Ransomware avec double ou triple extorsion
- Fraude au président et deepfake vocal
- Exploitation de CVE sur équipements exposés
- DDoS applicatif contre portails publics
- Compromission de dépendances ou outils de build
- Exfiltration discrète avant chiffrement
Lecture impact métier
Point critique : un risque cyber devient prioritaire quand il touche un service essentiel, une donnée sensible, une identité à privilège, une obligation réglementaire ou une dépendance fournisseur difficile à remplacer.
| Risque | Impact typique |
|---|---|
| Credential stuffing et comptes compromis | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Ransomware avec double ou triple extorsion | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Fraude au président et deepfake vocal | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Exploitation de CVE sur équipements exposés | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| DDoS applicatif contre portails publics | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Compromission de dépendances ou outils de build | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
Scénario réaliste
Un attaquant obtient un cookie de session via un infostealer installé sur le poste personnel d’un collaborateur. Il contourne le mot de passe, accède à un SaaS interne, découvre des exports clients, puis tente une extorsion sans même déployer de malware dans le réseau interne.
Chaîne d’attaque probable
Reconnaissance → accès initial → persistance → élévation → mouvement latéral → action sur objectif → extorsion / sabotage / fraude
Signaux faibles à surveiller
- Connexion inhabituelle ou impossible travel
- Volume anormal de lectures ou exports
- Création de compte, token ou règle de transfert
- Utilisation d’outils d’administration hors fenêtre
- Accès depuis IP, device ou pays atypique
- Modification de configuration sensible
Mesures de maîtrise
- MFA résistante au phishing pour comptes critiques
- EDR/XDR sur postes et serveurs
- Supervision des connexions anormales
- Durcissement des services exposés
- Gestion rapide des vulnérabilités exploitées
- Segmentation et moindre privilège
- Sauvegardes isolées et testées
Matrice prévention / détection / réponse
| Phase | Exemples |
|---|---|
| Prévenir | Réduire exposition, durcir configuration, limiter privilèges, former, automatiser les contrôles. |
| Détecter | Collecter logs utiles, créer use cases, surveiller comportements, corréler signaux. |
| Répondre | Isoler, révoquer, restaurer, communiquer, documenter, améliorer. |
Règle : aucun contrôle ne doit rester purement déclaratif. Il faut une preuve observable : configuration, log, rapport de test, ticket, capture, exercice ou métrique.
Indicateurs à suivre
- Comptes sans MFA
- Temps de correction des vulnérabilités critiques exposées
- Taux de postes couverts EDR
- Nombre d’alertes d’authentification anormale
- Exercices phishing réussis/échoués
- Restauration sauvegarde testée
Comment les interpréter
| Indicateur | Lecture |
|---|---|
| Comptes sans MFA | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Temps de correction des vulnérabilités critiques exposées | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Taux de postes couverts EDR | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Nombre d’alertes d’authentification anormale | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Exercices phishing réussis/échoués | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Restauration sauvegarde testée | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
Attention : un KPI sans seuil, sans propriétaire et sans décision associée devient vite décoratif.
Plan d’action concret
- Classer les menaces par probabilité et impact
- Identifier les chemins d’attaque les plus courts
- Contrôler les accès exposés internet
- Vérifier les journaux d’authentification
- Définir une stratégie anti-ransomware
- Simuler un vol d’identifiants et mesurer la réaction
Livrables attendus
- Cartographie ou registre mis à jour
- Liste des décisions et propriétaires
- Actions priorisées avec échéance
- Preuves de configuration ou de test
- Indicateurs de suivi
- Retour d’expérience après exercice ou incident
Le playbook doit pouvoir être exécuté par une équipe réelle, pas seulement compris par un expert sécurité.
Échelle de maturité
| Niveau | Description |
|---|---|
| Niveau 1 — réactif | Contrôles ponctuels, dépendance aux personnes, preuves faibles, actions après incident. |
| Niveau 2 — structuré | Actifs et responsabilités définis, contrôles prioritaires, logs et procédures minimales. |
| Niveau 3 — piloté | KPI/KRI, automatisation partielle, revues périodiques, exercices et amélioration continue. |
| Niveau 4 — résilient | Mesure du risque, tests réguliers, détection avancée, réponse orchestrée, culture intégrée. |
Quick wins
- Nommer un owner
- Documenter le périmètre
- Activer logs
- Supprimer l’exposition inutile
Industrialisation
- Automatiser contrôles
- Définir SLA
- Créer preuves
- Tester régulièrement
Excellence
- Mesurer réduction de risque
- Simuler incidents
- Adapter aux menaces
- Améliorer par RETEX
Questions de cadrage à poser en atelier
- Qui est propriétaire de cet enjeu : métier, IT, sécurité, juridique ou direction ?
- Quel actif ou processus serait le plus touché si ce domaine échouait demain ?
- Quelles preuves montrent que les contrôles fonctionnent réellement ?
- Quel incident réaliste permettrait de tester ce domaine en moins de 2 heures ?
- Quelles exceptions existent et qui accepte le risque résiduel ?
- Quel indicateur simple permet de suivre la progression mois après mois ?
Atelier recommandé : 45 minutes avec métier + IT + sécurité. Objectif : sortir avec 5 décisions, 5 actions et 5 preuves attendues.
🗺️ Actifs critiques & surface d’attaque
Positionnement.
Inventaire, dépendances, exposition Internet, shadow IT, données, identités et chemins d’attaque.
Inventaire, dépendances, exposition Internet, shadow IT, données, identités et chemins d’attaque.
On ne protège correctement que ce que l’on connaît. L’inventaire des actifs est donc une brique fondamentale : applications, serveurs, SaaS, APIs, domaines, certificats, comptes, données, flux et dépendances.
La surface d’attaque réelle dépasse souvent le périmètre officiel : environnements de test oubliés, sous-domaines non documentés, anciens VPN, dépôts publics, comptes prestataires, services cloud créés hors processus.
La cartographie doit être vivante : un inventaire annuel ne suffit pas dans un SI qui change chaque semaine.
Lecture synthétique
| Axe | Détail |
|---|---|
| Ce qu’il faut protéger | Actifs, données, identités, processus, réputation, continuité. |
| Ce qu’il faut décider | Priorités, risques acceptés, moyens, responsabilités, preuves attendues. |
| Ce qu’il faut mesurer | Couverture, délai, qualité de détection, efficacité de réponse, impact résiduel. |
Risques principaux
- Serveur oublié non patché
- Sous-domaine pointant vers un service abandonné
- Bucket cloud public par erreur
- Token API dans un dépôt Git
- Certificat expiré sur service critique
- Ancien compte prestataire toujours actif
- Application de test exposée sans authentification
Lecture impact métier
Point critique : un risque cyber devient prioritaire quand il touche un service essentiel, une donnée sensible, une identité à privilège, une obligation réglementaire ou une dépendance fournisseur difficile à remplacer.
| Risque | Impact typique |
|---|---|
| Serveur oublié non patché | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Sous-domaine pointant vers un service abandonné | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Bucket cloud public par erreur | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Token API dans un dépôt Git | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Certificat expiré sur service critique | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Ancien compte prestataire toujours actif | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
Scénario réaliste
Une équipe marketing crée rapidement une landing page avec un outil SaaS, connecte un sous-domaine officiel et importe une base prospects. Le service n’apparaît ni dans l’inventaire IT, ni dans le registre RGPD, ni dans la supervision. Six mois plus tard, une mauvaise configuration expose les exports.
Chaîne d’attaque probable
Reconnaissance → accès initial → persistance → élévation → mouvement latéral → action sur objectif → extorsion / sabotage / fraude
Signaux faibles à surveiller
- Connexion inhabituelle ou impossible travel
- Volume anormal de lectures ou exports
- Création de compte, token ou règle de transfert
- Utilisation d’outils d’administration hors fenêtre
- Accès depuis IP, device ou pays atypique
- Modification de configuration sensible
Mesures de maîtrise
- Inventaire automatisé des actifs
- Découverte externe ASM/EASM
- Processus de création de services
- Étiquetage propriétaire / criticité / données
- Revue régulière des sous-domaines et DNS
- Contrôle des secrets dans dépôts
- Décommissionnement documenté
Matrice prévention / détection / réponse
| Phase | Exemples |
|---|---|
| Prévenir | Réduire exposition, durcir configuration, limiter privilèges, former, automatiser les contrôles. |
| Détecter | Collecter logs utiles, créer use cases, surveiller comportements, corréler signaux. |
| Répondre | Isoler, révoquer, restaurer, communiquer, documenter, améliorer. |
Règle : aucun contrôle ne doit rester purement déclaratif. Il faut une preuve observable : configuration, log, rapport de test, ticket, capture, exercice ou métrique.
Indicateurs à suivre
- Pourcentage d’actifs avec propriétaire
- Sous-domaines non rattachés à un service
- Actifs exposés sans classification
- Secrets détectés dans dépôts
- Comptes inactifs non désactivés
- Services sans logs centralisés
Comment les interpréter
| Indicateur | Lecture |
|---|---|
| Pourcentage d’actifs avec propriétaire | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Sous-domaines non rattachés à un service | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Actifs exposés sans classification | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Secrets détectés dans dépôts | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Comptes inactifs non désactivés | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Services sans logs centralisés | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
Attention : un KPI sans seuil, sans propriétaire et sans décision associée devient vite décoratif.
Plan d’action concret
- Exporter les domaines et sous-domaines
- Relier chaque exposition à une application et un propriétaire
- Classer données et criticité
- Identifier les chemins vers actifs sensibles
- Supprimer ou isoler les services orphelins
- Créer un rituel mensuel de revue de surface
Livrables attendus
- Cartographie ou registre mis à jour
- Liste des décisions et propriétaires
- Actions priorisées avec échéance
- Preuves de configuration ou de test
- Indicateurs de suivi
- Retour d’expérience après exercice ou incident
Le playbook doit pouvoir être exécuté par une équipe réelle, pas seulement compris par un expert sécurité.
Échelle de maturité
| Niveau | Description |
|---|---|
| Niveau 1 — réactif | Contrôles ponctuels, dépendance aux personnes, preuves faibles, actions après incident. |
| Niveau 2 — structuré | Actifs et responsabilités définis, contrôles prioritaires, logs et procédures minimales. |
| Niveau 3 — piloté | KPI/KRI, automatisation partielle, revues périodiques, exercices et amélioration continue. |
| Niveau 4 — résilient | Mesure du risque, tests réguliers, détection avancée, réponse orchestrée, culture intégrée. |
Quick wins
- Nommer un owner
- Documenter le périmètre
- Activer logs
- Supprimer l’exposition inutile
Industrialisation
- Automatiser contrôles
- Définir SLA
- Créer preuves
- Tester régulièrement
Excellence
- Mesurer réduction de risque
- Simuler incidents
- Adapter aux menaces
- Améliorer par RETEX
Questions de cadrage à poser en atelier
- Qui est propriétaire de cet enjeu : métier, IT, sécurité, juridique ou direction ?
- Quel actif ou processus serait le plus touché si ce domaine échouait demain ?
- Quelles preuves montrent que les contrôles fonctionnent réellement ?
- Quel incident réaliste permettrait de tester ce domaine en moins de 2 heures ?
- Quelles exceptions existent et qui accepte le risque résiduel ?
- Quel indicateur simple permet de suivre la progression mois après mois ?
Atelier recommandé : 45 minutes avec métier + IT + sécurité. Objectif : sortir avec 5 décisions, 5 actions et 5 preuves attendues.
⚖️ Gestion du risque cyber
Positionnement.
Passer d’une logique purement technique à une logique de risques métier, de priorisation et d’arbitrage.
Passer d’une logique purement technique à une logique de risques métier, de priorisation et d’arbitrage.
La sécurité absolue n’existe pas. La gestion du risque consiste à décider consciemment quels risques réduire, transférer, accepter ou éviter, en fonction des impacts métier et des moyens disponibles.
Une vulnérabilité critique sur un serveur exposé qui traite des données sensibles n’a pas la même priorité qu’une vulnérabilité équivalente sur un environnement isolé et sans données.
La maturité cyber se voit dans la capacité à arbitrer : vulnérabilités, projets, budgets, exceptions, délais de correction, risques résiduels et responsabilités.
Lecture synthétique
| Axe | Détail |
|---|---|
| Ce qu’il faut protéger | Actifs, données, identités, processus, réputation, continuité. |
| Ce qu’il faut décider | Priorités, risques acceptés, moyens, responsabilités, preuves attendues. |
| Ce qu’il faut mesurer | Couverture, délai, qualité de détection, efficacité de réponse, impact résiduel. |
Risques principaux
- Backlog de vulnérabilités non priorisé
- Décisions cyber prises sans impact métier
- Exceptions sécurité jamais révisées
- Comités de risques purement documentaires
- Investissements orientés outils plutôt que réduction de risque
- Absence de propriétaire du risque résiduel
Lecture impact métier
Point critique : un risque cyber devient prioritaire quand il touche un service essentiel, une donnée sensible, une identité à privilège, une obligation réglementaire ou une dépendance fournisseur difficile à remplacer.
| Risque | Impact typique |
|---|---|
| Backlog de vulnérabilités non priorisé | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Décisions cyber prises sans impact métier | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Exceptions sécurité jamais révisées | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Comités de risques purement documentaires | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Investissements orientés outils plutôt que réduction de risque | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Absence de propriétaire du risque résiduel | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
Scénario réaliste
Le scanner remonte 2 000 vulnérabilités. Sans contexte métier, l’équipe traite au hasard. En reliant exposition Internet, criticité applicative, exploitabilité, données traitées et présence de compensating controls, le backlog devient une feuille de route réaliste.
Chaîne d’attaque probable
Reconnaissance → accès initial → persistance → élévation → mouvement latéral → action sur objectif → extorsion / sabotage / fraude
Signaux faibles à surveiller
- Connexion inhabituelle ou impossible travel
- Volume anormal de lectures ou exports
- Création de compte, token ou règle de transfert
- Utilisation d’outils d’administration hors fenêtre
- Accès depuis IP, device ou pays atypique
- Modification de configuration sensible
Mesures de maîtrise
- Méthode de scoring contextualisée
- Comité de risques opérationnel
- Registre des risques cyber
- Propriétaire métier par risque majeur
- Processus d’acceptation documentée
- Révision périodique des exceptions
- Alignement avec NIST CSF / ISO 27001 / CIS
Matrice prévention / détection / réponse
| Phase | Exemples |
|---|---|
| Prévenir | Réduire exposition, durcir configuration, limiter privilèges, former, automatiser les contrôles. |
| Détecter | Collecter logs utiles, créer use cases, surveiller comportements, corréler signaux. |
| Répondre | Isoler, révoquer, restaurer, communiquer, documenter, améliorer. |
Règle : aucun contrôle ne doit rester purement déclaratif. Il faut une preuve observable : configuration, log, rapport de test, ticket, capture, exercice ou métrique.
Indicateurs à suivre
- Risques critiques sans plan de traitement
- Âge moyen des vulnérabilités critiques exposées
- Exceptions expirées non revues
- Risques acceptés sans propriétaire
- Pourcentage de risques réévalués trimestriellement
- Écart entre risque brut et risque résiduel
Comment les interpréter
| Indicateur | Lecture |
|---|---|
| Risques critiques sans plan de traitement | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Âge moyen des vulnérabilités critiques exposées | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Exceptions expirées non revues | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Risques acceptés sans propriétaire | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Pourcentage de risques réévalués trimestriellement | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Écart entre risque brut et risque résiduel | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
Attention : un KPI sans seuil, sans propriétaire et sans décision associée devient vite décoratif.
Plan d’action concret
- Définir échelles impact/probabilité
- Ajouter contexte métier aux vulnérabilités
- Prioriser top 20 risques concrets
- Attribuer un owner et une échéance
- Décider réduire/accepter/transférer/éviter
- Revoir mensuellement les risques critiques
Livrables attendus
- Cartographie ou registre mis à jour
- Liste des décisions et propriétaires
- Actions priorisées avec échéance
- Preuves de configuration ou de test
- Indicateurs de suivi
- Retour d’expérience après exercice ou incident
Le playbook doit pouvoir être exécuté par une équipe réelle, pas seulement compris par un expert sécurité.
Échelle de maturité
| Niveau | Description |
|---|---|
| Niveau 1 — réactif | Contrôles ponctuels, dépendance aux personnes, preuves faibles, actions après incident. |
| Niveau 2 — structuré | Actifs et responsabilités définis, contrôles prioritaires, logs et procédures minimales. |
| Niveau 3 — piloté | KPI/KRI, automatisation partielle, revues périodiques, exercices et amélioration continue. |
| Niveau 4 — résilient | Mesure du risque, tests réguliers, détection avancée, réponse orchestrée, culture intégrée. |
Quick wins
- Nommer un owner
- Documenter le périmètre
- Activer logs
- Supprimer l’exposition inutile
Industrialisation
- Automatiser contrôles
- Définir SLA
- Créer preuves
- Tester régulièrement
Excellence
- Mesurer réduction de risque
- Simuler incidents
- Adapter aux menaces
- Améliorer par RETEX
Questions de cadrage à poser en atelier
- Qui est propriétaire de cet enjeu : métier, IT, sécurité, juridique ou direction ?
- Quel actif ou processus serait le plus touché si ce domaine échouait demain ?
- Quelles preuves montrent que les contrôles fonctionnent réellement ?
- Quel incident réaliste permettrait de tester ce domaine en moins de 2 heures ?
- Quelles exceptions existent et qui accepte le risque résiduel ?
- Quel indicateur simple permet de suivre la progression mois après mois ?
Atelier recommandé : 45 minutes avec métier + IT + sécurité. Objectif : sortir avec 5 décisions, 5 actions et 5 preuves attendues.
🏛️ Gouvernance & cadres de référence
Positionnement.
NIST CSF 2.0, CIS Controls, ISO 27001, politiques, rôles, preuves et pilotage exécutif.
NIST CSF 2.0, CIS Controls, ISO 27001, politiques, rôles, preuves et pilotage exécutif.
La gouvernance transforme la cybersécurité en système pilotable : rôles, politiques, objectifs, risques, budgets, preuves, comités, contrôles, responsabilités et amélioration continue.
Le NIST CSF 2.0 structure les résultats cyber autour de six fonctions : Govern, Identify, Protect, Detect, Respond, Recover. La fonction Govern rappelle que le pilotage cyber doit être aligné sur les objectifs de l’organisation.
Les CIS Controls donnent une approche très opérationnelle et priorisée de l’hygiène cyber : inventaire, configuration, vulnérabilités, accès, logs, email, sauvegardes, formation, réponse à incident.
Lecture synthétique
| Axe | Détail |
|---|---|
| Ce qu’il faut protéger | Actifs, données, identités, processus, réputation, continuité. |
| Ce qu’il faut décider | Priorités, risques acceptés, moyens, responsabilités, preuves attendues. |
| Ce qu’il faut mesurer | Couverture, délai, qualité de détection, efficacité de réponse, impact résiduel. |
Risques principaux
- Politiques non appliquées
- Absence de preuves pour audit
- Rôles flous entre IT, sécurité, métiers
- Budget cyber non relié aux risques
- Contrôles achetés mais non exploités
- Comités qui ne décident rien
Lecture impact métier
Point critique : un risque cyber devient prioritaire quand il touche un service essentiel, une donnée sensible, une identité à privilège, une obligation réglementaire ou une dépendance fournisseur difficile à remplacer.
| Risque | Impact typique |
|---|---|
| Politiques non appliquées | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Absence de preuves pour audit | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Rôles flous entre IT, sécurité, métiers | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Budget cyber non relié aux risques | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Contrôles achetés mais non exploités | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Comités qui ne décident rien | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
Scénario réaliste
Une entreprise dispose de nombreux outils mais ne sait pas répondre simplement à trois questions : quels sont ses actifs critiques, quels risques sont acceptés, et qui décide en cas de crise. La gouvernance doit d’abord clarifier ces responsabilités avant d’ajouter des technologies.
Chaîne d’attaque probable
Reconnaissance → accès initial → persistance → élévation → mouvement latéral → action sur objectif → extorsion / sabotage / fraude
Signaux faibles à surveiller
- Connexion inhabituelle ou impossible travel
- Volume anormal de lectures ou exports
- Création de compte, token ou règle de transfert
- Utilisation d’outils d’administration hors fenêtre
- Accès depuis IP, device ou pays atypique
- Modification de configuration sensible
Mesures de maîtrise
- Charte de gouvernance cyber
- Cartographie des responsabilités RACI
- Politiques courtes et applicables
- Registre de risques et plans de traitement
- Contrôles prioritaires CIS
- Tableaux de bord exécutifs
- Audits internes et amélioration continue
Matrice prévention / détection / réponse
| Phase | Exemples |
|---|---|
| Prévenir | Réduire exposition, durcir configuration, limiter privilèges, former, automatiser les contrôles. |
| Détecter | Collecter logs utiles, créer use cases, surveiller comportements, corréler signaux. |
| Répondre | Isoler, révoquer, restaurer, communiquer, documenter, améliorer. |
Règle : aucun contrôle ne doit rester purement déclaratif. Il faut une preuve observable : configuration, log, rapport de test, ticket, capture, exercice ou métrique.
Indicateurs à suivre
- Politiques revues dans l’année
- Risques critiques avec décision formelle
- Contrôles CIS implémentés par niveau
- Audits avec preuves disponibles
- Actions de comité clôturées
- Budget relié aux risques majeurs
Comment les interpréter
| Indicateur | Lecture |
|---|---|
| Politiques revues dans l’année | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Risques critiques avec décision formelle | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Contrôles CIS implémentés par niveau | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Audits avec preuves disponibles | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Actions de comité clôturées | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Budget relié aux risques majeurs | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
Attention : un KPI sans seuil, sans propriétaire et sans décision associée devient vite décoratif.
Plan d’action concret
- Choisir un cadre principal de pilotage
- Traduire le cadre en contrôles opérationnels
- Nommer propriétaires et preuves attendues
- Définir un tableau de bord direction
- Organiser une revue mensuelle courte
- Faire évoluer les politiques à partir des incidents réels
Livrables attendus
- Cartographie ou registre mis à jour
- Liste des décisions et propriétaires
- Actions priorisées avec échéance
- Preuves de configuration ou de test
- Indicateurs de suivi
- Retour d’expérience après exercice ou incident
Le playbook doit pouvoir être exécuté par une équipe réelle, pas seulement compris par un expert sécurité.
Échelle de maturité
| Niveau | Description |
|---|---|
| Niveau 1 — réactif | Contrôles ponctuels, dépendance aux personnes, preuves faibles, actions après incident. |
| Niveau 2 — structuré | Actifs et responsabilités définis, contrôles prioritaires, logs et procédures minimales. |
| Niveau 3 — piloté | KPI/KRI, automatisation partielle, revues périodiques, exercices et amélioration continue. |
| Niveau 4 — résilient | Mesure du risque, tests réguliers, détection avancée, réponse orchestrée, culture intégrée. |
Quick wins
- Nommer un owner
- Documenter le périmètre
- Activer logs
- Supprimer l’exposition inutile
Industrialisation
- Automatiser contrôles
- Définir SLA
- Créer preuves
- Tester régulièrement
Excellence
- Mesurer réduction de risque
- Simuler incidents
- Adapter aux menaces
- Améliorer par RETEX
Questions de cadrage à poser en atelier
- Qui est propriétaire de cet enjeu : métier, IT, sécurité, juridique ou direction ?
- Quel actif ou processus serait le plus touché si ce domaine échouait demain ?
- Quelles preuves montrent que les contrôles fonctionnent réellement ?
- Quel incident réaliste permettrait de tester ce domaine en moins de 2 heures ?
- Quelles exceptions existent et qui accepte le risque résiduel ?
- Quel indicateur simple permet de suivre la progression mois après mois ?
Atelier recommandé : 45 minutes avec métier + IT + sécurité. Objectif : sortir avec 5 décisions, 5 actions et 5 preuves attendues.
🧠 Facteur humain & culture sécurité
Positionnement.
Sensibilisation, phishing, habitudes, processus métier, responsabilité partagée et réduction des erreurs évitables.
Sensibilisation, phishing, habitudes, processus métier, responsabilité partagée et réduction des erreurs évitables.
Le facteur humain n’est pas “le maillon faible” par nature : il devient faible quand l’organisation lui impose des outils compliqués, des procédures floues, des alertes incompréhensibles et des objectifs contradictoires.
La culture sécurité vise à rendre les bons comportements faciles : signaler un email suspect, utiliser un gestionnaire de mots de passe, vérifier une demande urgente, appliquer MFA, refuser les contournements dangereux.
Une bonne sensibilisation est continue, contextualisée, mesurable, non culpabilisante et reliée aux métiers.
Lecture synthétique
| Axe | Détail |
|---|---|
| Ce qu’il faut protéger | Actifs, données, identités, processus, réputation, continuité. |
| Ce qu’il faut décider | Priorités, risques acceptés, moyens, responsabilités, preuves attendues. |
| Ce qu’il faut mesurer | Couverture, délai, qualité de détection, efficacité de réponse, impact résiduel. |
Risques principaux
- Phishing réussi sur comptes sensibles
- Fraude au virement
- Partage de secrets par messagerie
- Contournement de procédures pour gagner du temps
- Fatigue MFA et validation réflexe
- Non-déclaration d’incidents par peur de sanction
Lecture impact métier
Point critique : un risque cyber devient prioritaire quand il touche un service essentiel, une donnée sensible, une identité à privilège, une obligation réglementaire ou une dépendance fournisseur difficile à remplacer.
| Risque | Impact typique |
|---|---|
| Phishing réussi sur comptes sensibles | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Fraude au virement | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Partage de secrets par messagerie | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Contournement de procédures pour gagner du temps | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Fatigue MFA et validation réflexe | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Non-déclaration d’incidents par peur de sanction | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
Scénario réaliste
Un collaborateur reçoit un message Teams prétendant venir du support IT avec une demande MFA urgente. S’il a appris seulement une formation annuelle générique, il clique. S’il a reçu des simulations réalistes, un bouton de signalement simple et une culture non punitive, il escalade rapidement.
Chaîne d’attaque probable
Reconnaissance → accès initial → persistance → élévation → mouvement latéral → action sur objectif → extorsion / sabotage / fraude
Signaux faibles à surveiller
- Connexion inhabituelle ou impossible travel
- Volume anormal de lectures ou exports
- Création de compte, token ou règle de transfert
- Utilisation d’outils d’administration hors fenêtre
- Accès depuis IP, device ou pays atypique
- Modification de configuration sensible
Mesures de maîtrise
- Formations courtes et fréquentes
- Simulations phishing ciblées
- Canal de signalement simple
- MFA résistante au phishing pour profils sensibles
- Procédures anti-fraude à double validation
- Communication post-incident sans blâme
- Champions sécurité par équipe
Matrice prévention / détection / réponse
| Phase | Exemples |
|---|---|
| Prévenir | Réduire exposition, durcir configuration, limiter privilèges, former, automatiser les contrôles. |
| Détecter | Collecter logs utiles, créer use cases, surveiller comportements, corréler signaux. |
| Répondre | Isoler, révoquer, restaurer, communiquer, documenter, améliorer. |
Règle : aucun contrôle ne doit rester purement déclaratif. Il faut une preuve observable : configuration, log, rapport de test, ticket, capture, exercice ou métrique.
Indicateurs à suivre
- Taux de signalement phishing
- Délai moyen de signalement
- Taux de réussite des simulations
- Comptes sensibles couverts MFA forte
- Incidents détectés par utilisateurs
- Participation aux micro-formations
Comment les interpréter
| Indicateur | Lecture |
|---|---|
| Taux de signalement phishing | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Délai moyen de signalement | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Taux de réussite des simulations | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Comptes sensibles couverts MFA forte | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Incidents détectés par utilisateurs | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Participation aux micro-formations | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
Attention : un KPI sans seuil, sans propriétaire et sans décision associée devient vite décoratif.
Plan d’action concret
- Identifier 5 comportements critiques
- Créer des messages simples par population
- Déployer un bouton de signalement
- Simuler une fraude réaliste
- Récompenser les signalements utiles
- Mesurer et ajuster par métier
Livrables attendus
- Cartographie ou registre mis à jour
- Liste des décisions et propriétaires
- Actions priorisées avec échéance
- Preuves de configuration ou de test
- Indicateurs de suivi
- Retour d’expérience après exercice ou incident
Le playbook doit pouvoir être exécuté par une équipe réelle, pas seulement compris par un expert sécurité.
Échelle de maturité
| Niveau | Description |
|---|---|
| Niveau 1 — réactif | Contrôles ponctuels, dépendance aux personnes, preuves faibles, actions après incident. |
| Niveau 2 — structuré | Actifs et responsabilités définis, contrôles prioritaires, logs et procédures minimales. |
| Niveau 3 — piloté | KPI/KRI, automatisation partielle, revues périodiques, exercices et amélioration continue. |
| Niveau 4 — résilient | Mesure du risque, tests réguliers, détection avancée, réponse orchestrée, culture intégrée. |
Quick wins
- Nommer un owner
- Documenter le périmètre
- Activer logs
- Supprimer l’exposition inutile
Industrialisation
- Automatiser contrôles
- Définir SLA
- Créer preuves
- Tester régulièrement
Excellence
- Mesurer réduction de risque
- Simuler incidents
- Adapter aux menaces
- Améliorer par RETEX
Questions de cadrage à poser en atelier
- Qui est propriétaire de cet enjeu : métier, IT, sécurité, juridique ou direction ?
- Quel actif ou processus serait le plus touché si ce domaine échouait demain ?
- Quelles preuves montrent que les contrôles fonctionnent réellement ?
- Quel incident réaliste permettrait de tester ce domaine en moins de 2 heures ?
- Quelles exceptions existent et qui accepte le risque résiduel ?
- Quel indicateur simple permet de suivre la progression mois après mois ?
Atelier recommandé : 45 minutes avec métier + IT + sécurité. Objectif : sortir avec 5 décisions, 5 actions et 5 preuves attendues.
🪪 Identité, IAM & Zero Trust
Positionnement.
Identités humaines, machines, MFA, SSO, PAM, moindre privilège, comptes à privilèges et segmentation logique.
Identités humaines, machines, MFA, SSO, PAM, moindre privilège, comptes à privilèges et segmentation logique.
L’identité est devenue le nouveau périmètre. Dans un environnement cloud et SaaS, l’accès aux comptes, tokens, secrets, rôles et permissions vaut souvent plus qu’un accès réseau traditionnel.
Zero Trust ne signifie pas acheter un produit : c’est un modèle où chaque accès est explicitement vérifié, limité, contextualisé, journalisé et réévalué.
Les comptes à privilèges, comptes de service, clés API et tokens CI/CD sont des cibles prioritaires : ils doivent être inventoriés, protégés et surveillés.
Lecture synthétique
| Axe | Détail |
|---|---|
| Ce qu’il faut protéger | Actifs, données, identités, processus, réputation, continuité. |
| Ce qu’il faut décider | Priorités, risques acceptés, moyens, responsabilités, preuves attendues. |
| Ce qu’il faut mesurer | Couverture, délai, qualité de détection, efficacité de réponse, impact résiduel. |
Risques principaux
- Comptes admin sans MFA forte
- Permissions cloud trop larges
- Comptes de service non rotés
- Secrets CI/CD exposés
- MFA push fatigue
- Absence de revue d’accès
- Droits conservés après mobilité ou départ
Lecture impact métier
Point critique : un risque cyber devient prioritaire quand il touche un service essentiel, une donnée sensible, une identité à privilège, une obligation réglementaire ou une dépendance fournisseur difficile à remplacer.
| Risque | Impact typique |
|---|---|
| Comptes admin sans MFA forte | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Permissions cloud trop larges | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Comptes de service non rotés | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Secrets CI/CD exposés | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| MFA push fatigue | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Absence de revue d’accès | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
Scénario réaliste
Un développeur conserve un token cloud très permissif dans une ancienne variable CI. Après compromission du dépôt, l’attaquant déploie des ressources, lit des secrets et crée un compte persistant. La faille n’est pas une vulnérabilité applicative classique mais une gouvernance d’identité insuffisante.
Chaîne d’attaque probable
Reconnaissance → accès initial → persistance → élévation → mouvement latéral → action sur objectif → extorsion / sabotage / fraude
Signaux faibles à surveiller
- Connexion inhabituelle ou impossible travel
- Volume anormal de lectures ou exports
- Création de compte, token ou règle de transfert
- Utilisation d’outils d’administration hors fenêtre
- Accès depuis IP, device ou pays atypique
- Modification de configuration sensible
Mesures de maîtrise
- SSO centralisé
- MFA phishing-resistant pour admins
- PAM pour privilèges élevés
- RBAC/ABAC et moindre privilège
- Revue périodique des droits
- Rotation des secrets et tokens
- Détection d’anomalies d’authentification
- Just-in-time access
Matrice prévention / détection / réponse
| Phase | Exemples |
|---|---|
| Prévenir | Réduire exposition, durcir configuration, limiter privilèges, former, automatiser les contrôles. |
| Détecter | Collecter logs utiles, créer use cases, surveiller comportements, corréler signaux. |
| Répondre | Isoler, révoquer, restaurer, communiquer, documenter, améliorer. |
Règle : aucun contrôle ne doit rester purement déclaratif. Il faut une preuve observable : configuration, log, rapport de test, ticket, capture, exercice ou métrique.
Indicateurs à suivre
- Comptes privilégiés sans MFA forte
- Rôles cloud wildcard
- Secrets âgés non rotés
- Comptes orphelins
- Droits non revus depuis 90 jours
- Alertes impossible travel
- Accès JIT vs permanents
Comment les interpréter
| Indicateur | Lecture |
|---|---|
| Comptes privilégiés sans MFA forte | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Rôles cloud wildcard | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Secrets âgés non rotés | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Comptes orphelins | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Droits non revus depuis 90 jours | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Alertes impossible travel | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Accès JIT vs permanents | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
Attention : un KPI sans seuil, sans propriétaire et sans décision associée devient vite décoratif.
Plan d’action concret
- Inventorier identités humaines et machines
- Séparer comptes nominaux et comptes de service
- Classer privilèges critiques
- Activer MFA forte sur périmètre sensible
- Réduire permissions excessives
- Mettre en place une revue trimestrielle
Livrables attendus
- Cartographie ou registre mis à jour
- Liste des décisions et propriétaires
- Actions priorisées avec échéance
- Preuves de configuration ou de test
- Indicateurs de suivi
- Retour d’expérience après exercice ou incident
Le playbook doit pouvoir être exécuté par une équipe réelle, pas seulement compris par un expert sécurité.
Échelle de maturité
| Niveau | Description |
|---|---|
| Niveau 1 — réactif | Contrôles ponctuels, dépendance aux personnes, preuves faibles, actions après incident. |
| Niveau 2 — structuré | Actifs et responsabilités définis, contrôles prioritaires, logs et procédures minimales. |
| Niveau 3 — piloté | KPI/KRI, automatisation partielle, revues périodiques, exercices et amélioration continue. |
| Niveau 4 — résilient | Mesure du risque, tests réguliers, détection avancée, réponse orchestrée, culture intégrée. |
Quick wins
- Nommer un owner
- Documenter le périmètre
- Activer logs
- Supprimer l’exposition inutile
Industrialisation
- Automatiser contrôles
- Définir SLA
- Créer preuves
- Tester régulièrement
Excellence
- Mesurer réduction de risque
- Simuler incidents
- Adapter aux menaces
- Améliorer par RETEX
Questions de cadrage à poser en atelier
- Qui est propriétaire de cet enjeu : métier, IT, sécurité, juridique ou direction ?
- Quel actif ou processus serait le plus touché si ce domaine échouait demain ?
- Quelles preuves montrent que les contrôles fonctionnent réellement ?
- Quel incident réaliste permettrait de tester ce domaine en moins de 2 heures ?
- Quelles exceptions existent et qui accepte le risque résiduel ?
- Quel indicateur simple permet de suivre la progression mois après mois ?
Atelier recommandé : 45 minutes avec métier + IT + sécurité. Objectif : sortir avec 5 décisions, 5 actions et 5 preuves attendues.
🗄️ Données, confidentialité & protection
Positionnement.
Classification, chiffrement, DLP, privacy, sauvegardes, rétention, exfiltration et valeur stratégique de la donnée.
Classification, chiffrement, DLP, privacy, sauvegardes, rétention, exfiltration et valeur stratégique de la donnée.
Les données sont au cœur des enjeux cyber : données personnelles, secrets industriels, contrats, codes sources, logs, données financières, données médicales, modèles IA, jeux d’entraînement et exports métiers.
Protéger les données suppose de savoir où elles résident, qui y accède, comment elles circulent, combien de temps elles sont conservées, comment elles sont sauvegardées et comment elles peuvent être exfiltrées.
La confidentialité seule ne suffit pas : intégrité, disponibilité, traçabilité, minimisation et cycle de vie sont tout aussi importants.
Lecture synthétique
| Axe | Détail |
|---|---|
| Ce qu’il faut protéger | Actifs, données, identités, processus, réputation, continuité. |
| Ce qu’il faut décider | Priorités, risques acceptés, moyens, responsabilités, preuves attendues. |
| Ce qu’il faut mesurer | Couverture, délai, qualité de détection, efficacité de réponse, impact résiduel. |
Risques principaux
- Données sensibles dans exports non maîtrisés
- Partage public involontaire
- Logs contenant secrets ou données personnelles
- Sauvegardes non chiffrées
- Absence de purge/rétention
- Données copiées vers SaaS non validés
- Exfiltration lente non détectée
Lecture impact métier
Point critique : un risque cyber devient prioritaire quand il touche un service essentiel, une donnée sensible, une identité à privilège, une obligation réglementaire ou une dépendance fournisseur difficile à remplacer.
| Risque | Impact typique |
|---|---|
| Données sensibles dans exports non maîtrisés | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Partage public involontaire | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Logs contenant secrets ou données personnelles | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Sauvegardes non chiffrées | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Absence de purge/rétention | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Données copiées vers SaaS non validés | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
Scénario réaliste
Un analyste exporte chaque semaine un fichier clients pour alimenter un outil de reporting. Le fichier circule par email, finit dans un espace partagé externe, puis est indexé par un outil tiers. L’incident ne vient pas d’un malware mais d’un flux de données non gouverné.
Chaîne d’attaque probable
Reconnaissance → accès initial → persistance → élévation → mouvement latéral → action sur objectif → extorsion / sabotage / fraude
Signaux faibles à surveiller
- Connexion inhabituelle ou impossible travel
- Volume anormal de lectures ou exports
- Création de compte, token ou règle de transfert
- Utilisation d’outils d’administration hors fenêtre
- Accès depuis IP, device ou pays atypique
- Modification de configuration sensible
Mesures de maîtrise
- Classification des données
- Data ownership
- Chiffrement au repos/en transit
- DLP sur flux critiques
- Contrôle des exports
- Purge et rétention
- Journalisation des accès
- Backups chiffrés et isolés
- Minimisation des données
Matrice prévention / détection / réponse
| Phase | Exemples |
|---|---|
| Prévenir | Réduire exposition, durcir configuration, limiter privilèges, former, automatiser les contrôles. |
| Détecter | Collecter logs utiles, créer use cases, surveiller comportements, corréler signaux. |
| Répondre | Isoler, révoquer, restaurer, communiquer, documenter, améliorer. |
Règle : aucun contrôle ne doit rester purement déclaratif. Il faut une preuve observable : configuration, log, rapport de test, ticket, capture, exercice ou métrique.
Indicateurs à suivre
- Dépôts contenant données sensibles
- Exports non justifiés
- Données sans propriétaire
- Sauvegardes testées/chiffrées
- Incidents DLP par canal
- Accès massifs aux données
- Données hors durée de rétention
Comment les interpréter
| Indicateur | Lecture |
|---|---|
| Dépôts contenant données sensibles | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Exports non justifiés | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Données sans propriétaire | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Sauvegardes testées/chiffrées | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Incidents DLP par canal | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Accès massifs aux données | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Données hors durée de rétention | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
Attention : un KPI sans seuil, sans propriétaire et sans décision associée devient vite décoratif.
Plan d’action concret
- Identifier catégories sensibles
- Cartographier flux et lieux de stockage
- Mettre des règles d’accès par besoin métier
- Chiffrer et journaliser
- Limiter exports et partages
- Tester scénarios d’exfiltration
Livrables attendus
- Cartographie ou registre mis à jour
- Liste des décisions et propriétaires
- Actions priorisées avec échéance
- Preuves de configuration ou de test
- Indicateurs de suivi
- Retour d’expérience après exercice ou incident
Le playbook doit pouvoir être exécuté par une équipe réelle, pas seulement compris par un expert sécurité.
Échelle de maturité
| Niveau | Description |
|---|---|
| Niveau 1 — réactif | Contrôles ponctuels, dépendance aux personnes, preuves faibles, actions après incident. |
| Niveau 2 — structuré | Actifs et responsabilités définis, contrôles prioritaires, logs et procédures minimales. |
| Niveau 3 — piloté | KPI/KRI, automatisation partielle, revues périodiques, exercices et amélioration continue. |
| Niveau 4 — résilient | Mesure du risque, tests réguliers, détection avancée, réponse orchestrée, culture intégrée. |
Quick wins
- Nommer un owner
- Documenter le périmètre
- Activer logs
- Supprimer l’exposition inutile
Industrialisation
- Automatiser contrôles
- Définir SLA
- Créer preuves
- Tester régulièrement
Excellence
- Mesurer réduction de risque
- Simuler incidents
- Adapter aux menaces
- Améliorer par RETEX
Questions de cadrage à poser en atelier
- Qui est propriétaire de cet enjeu : métier, IT, sécurité, juridique ou direction ?
- Quel actif ou processus serait le plus touché si ce domaine échouait demain ?
- Quelles preuves montrent que les contrôles fonctionnent réellement ?
- Quel incident réaliste permettrait de tester ce domaine en moins de 2 heures ?
- Quelles exceptions existent et qui accepte le risque résiduel ?
- Quel indicateur simple permet de suivre la progression mois après mois ?
Atelier recommandé : 45 minutes avec métier + IT + sécurité. Objectif : sortir avec 5 décisions, 5 actions et 5 preuves attendues.
🧱 Sécurité applicative & OWASP
Positionnement.
SDLC sécurisé, OWASP Top 10, revues de code, SAST/DAST, secrets, dépendances et défauts de conception.
SDLC sécurisé, OWASP Top 10, revues de code, SAST/DAST, secrets, dépendances et défauts de conception.
La sécurité applicative vise à réduire les failles dans le code, la conception, les dépendances, les configurations et les flux métier.
Les familles OWASP rappellent que les risques majeurs ne se limitent pas à l’injection : contrôle d’accès, erreurs cryptographiques, mauvaise configuration, composants vulnérables, journalisation insuffisante et SSRF restent structurants.
Une bonne AppSec est intégrée au cycle de développement : conception, threat modeling, codage, tests, CI/CD, revue, déploiement et observation production.
Lecture synthétique
| Axe | Détail |
|---|---|
| Ce qu’il faut protéger | Actifs, données, identités, processus, réputation, continuité. |
| Ce qu’il faut décider | Priorités, risques acceptés, moyens, responsabilités, preuves attendues. |
| Ce qu’il faut mesurer | Couverture, délai, qualité de détection, efficacité de réponse, impact résiduel. |
Risques principaux
- Broken access control
- Injection SQL/NoSQL/command
- XSS et injection de contenu
- Secrets dans code source
- Dépendances vulnérables
- Mauvaise configuration headers/TLS/CORS
- Journalisation insuffisante
- SSRF vers metadata cloud
Lecture impact métier
Point critique : un risque cyber devient prioritaire quand il touche un service essentiel, une donnée sensible, une identité à privilège, une obligation réglementaire ou une dépendance fournisseur difficile à remplacer.
| Risque | Impact typique |
|---|---|
| Broken access control | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Injection SQL/NoSQL/command | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| XSS et injection de contenu | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Secrets dans code source | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Dépendances vulnérables | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Mauvaise configuration headers/TLS/CORS | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
Scénario réaliste
Une application protège bien l’authentification mais oublie l’autorisation objet par objet. Un utilisateur authentifié modifie un identifiant dans l’URL et consulte les factures d’un autre client. Le WAF ne suffit pas : le défaut est logique et doit être corrigé dans le code.
Chaîne d’attaque probable
Reconnaissance → accès initial → persistance → élévation → mouvement latéral → action sur objectif → extorsion / sabotage / fraude
Signaux faibles à surveiller
- Connexion inhabituelle ou impossible travel
- Volume anormal de lectures ou exports
- Création de compte, token ou règle de transfert
- Utilisation d’outils d’administration hors fenêtre
- Accès depuis IP, device ou pays atypique
- Modification de configuration sensible
Mesures de maîtrise
- Threat modeling léger
- Revues de code ciblées sécurité
- SAST/DAST/IaC scanning
- Tests d’autorisation métier
- Gestion des secrets
- Validation centralisée des entrées
- Headers de sécurité
- SBOM et dependency scanning
- Journalisation des événements sensibles
Matrice prévention / détection / réponse
| Phase | Exemples |
|---|---|
| Prévenir | Réduire exposition, durcir configuration, limiter privilèges, former, automatiser les contrôles. |
| Détecter | Collecter logs utiles, créer use cases, surveiller comportements, corréler signaux. |
| Répondre | Isoler, révoquer, restaurer, communiquer, documenter, améliorer. |
Règle : aucun contrôle ne doit rester purement déclaratif. Il faut une preuve observable : configuration, log, rapport de test, ticket, capture, exercice ou métrique.
Indicateurs à suivre
- Failles critiques par application
- Temps de correction AppSec
- Secrets bloqués en CI
- Couverture des tests d’autorisation
- Dépendances vulnérables critiques
- Applications sans owner AppSec
- Déploiements avec scan réussi
Comment les interpréter
| Indicateur | Lecture |
|---|---|
| Failles critiques par application | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Temps de correction AppSec | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Secrets bloqués en CI | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Couverture des tests d’autorisation | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Dépendances vulnérables critiques | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Applications sans owner AppSec | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Déploiements avec scan réussi | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
Attention : un KPI sans seuil, sans propriétaire et sans décision associée devient vite décoratif.
Plan d’action concret
- Former développeurs aux failles fréquentes
- Ajouter checklists de conception
- Scanner à chaque merge
- Bloquer secrets en pre-commit/CI
- Tester contrôle d’accès au niveau objet
- Organiser une revue AppSec mensuelle
Livrables attendus
- Cartographie ou registre mis à jour
- Liste des décisions et propriétaires
- Actions priorisées avec échéance
- Preuves de configuration ou de test
- Indicateurs de suivi
- Retour d’expérience après exercice ou incident
Le playbook doit pouvoir être exécuté par une équipe réelle, pas seulement compris par un expert sécurité.
Échelle de maturité
| Niveau | Description |
|---|---|
| Niveau 1 — réactif | Contrôles ponctuels, dépendance aux personnes, preuves faibles, actions après incident. |
| Niveau 2 — structuré | Actifs et responsabilités définis, contrôles prioritaires, logs et procédures minimales. |
| Niveau 3 — piloté | KPI/KRI, automatisation partielle, revues périodiques, exercices et amélioration continue. |
| Niveau 4 — résilient | Mesure du risque, tests réguliers, détection avancée, réponse orchestrée, culture intégrée. |
Quick wins
- Nommer un owner
- Documenter le périmètre
- Activer logs
- Supprimer l’exposition inutile
Industrialisation
- Automatiser contrôles
- Définir SLA
- Créer preuves
- Tester régulièrement
Excellence
- Mesurer réduction de risque
- Simuler incidents
- Adapter aux menaces
- Améliorer par RETEX
Questions de cadrage à poser en atelier
- Qui est propriétaire de cet enjeu : métier, IT, sécurité, juridique ou direction ?
- Quel actif ou processus serait le plus touché si ce domaine échouait demain ?
- Quelles preuves montrent que les contrôles fonctionnent réellement ?
- Quel incident réaliste permettrait de tester ce domaine en moins de 2 heures ?
- Quelles exceptions existent et qui accepte le risque résiduel ?
- Quel indicateur simple permet de suivre la progression mois après mois ?
Atelier recommandé : 45 minutes avec métier + IT + sécurité. Objectif : sortir avec 5 décisions, 5 actions et 5 preuves attendues.
🔌 API Security
Positionnement.
Inventaire API, BOLA, authentification, autorisation, schémas, rate limiting, GraphQL, REST et abus automatisés.
Inventaire API, BOLA, authentification, autorisation, schémas, rate limiting, GraphQL, REST et abus automatisés.
Les APIs exposent directement les objets métier et les données. Elles sont souvent consommées par mobiles, partenaires, frontends SPA, intégrations internes et automatisations.
Le risque API majeur n’est pas uniquement l’injection : l’autorisation par objet, par fonction, par rôle et par contexte est centrale.
La sécurité API nécessite un inventaire vivant, des schémas, une authentification robuste, une autorisation serveur, du rate limiting, une détection d’abus et une observation fine.
Lecture synthétique
| Axe | Détail |
|---|---|
| Ce qu’il faut protéger | Actifs, données, identités, processus, réputation, continuité. |
| Ce qu’il faut décider | Priorités, risques acceptés, moyens, responsabilités, preuves attendues. |
| Ce qu’il faut mesurer | Couverture, délai, qualité de détection, efficacité de réponse, impact résiduel. |
Risques principaux
- BOLA / IDOR
- Broken authentication
- Broken function level authorization
- Endpoints oubliés
- Consommation non restreinte de ressources
- Mass assignment
- GraphQL introspection abusive
- Tokens longue durée non révoqués
Lecture impact métier
Point critique : un risque cyber devient prioritaire quand il touche un service essentiel, une donnée sensible, une identité à privilège, une obligation réglementaire ou une dépendance fournisseur difficile à remplacer.
| Risque | Impact typique |
|---|---|
| BOLA / IDOR | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Broken authentication | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Broken function level authorization | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Endpoints oubliés | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Consommation non restreinte de ressources | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Mass assignment | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
Scénario réaliste
Une API mobile expose `/api/orders/{id}`. Le client masque les commandes des autres utilisateurs, mais le backend ne vérifie pas la propriété de l’objet. En changeant l’ID, un attaquant récupère les commandes d’autres clients.
Chaîne d’attaque probable
Reconnaissance → accès initial → persistance → élévation → mouvement latéral → action sur objectif → extorsion / sabotage / fraude
Signaux faibles à surveiller
- Connexion inhabituelle ou impossible travel
- Volume anormal de lectures ou exports
- Création de compte, token ou règle de transfert
- Utilisation d’outils d’administration hors fenêtre
- Accès depuis IP, device ou pays atypique
- Modification de configuration sensible
Mesures de maîtrise
- Inventaire des endpoints
- Schémas OpenAPI/GraphQL validés
- Autorisation côté serveur par objet
- Scopes OAuth/OIDC minimaux
- Rate limiting par identité et par route
- Validation des champs autorisés
- Détection d’anomalies API
- Tests BOLA automatisés
Matrice prévention / détection / réponse
| Phase | Exemples |
|---|---|
| Prévenir | Réduire exposition, durcir configuration, limiter privilèges, former, automatiser les contrôles. |
| Détecter | Collecter logs utiles, créer use cases, surveiller comportements, corréler signaux. |
| Répondre | Isoler, révoquer, restaurer, communiquer, documenter, améliorer. |
Règle : aucun contrôle ne doit rester purement déclaratif. Il faut une preuve observable : configuration, log, rapport de test, ticket, capture, exercice ou métrique.
Indicateurs à suivre
- APIs sans propriétaire
- Endpoints non documentés
- Routes sans rate limit
- Tests BOLA en échec
- Tokens non expirants
- Erreurs 401/403 anormales
- Volume API par client
Comment les interpréter
| Indicateur | Lecture |
|---|---|
| APIs sans propriétaire | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Endpoints non documentés | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Routes sans rate limit | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Tests BOLA en échec | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Tokens non expirants | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Erreurs 401/403 anormales | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Volume API par client | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
Attention : un KPI sans seuil, sans propriétaire et sans décision associée devient vite décoratif.
Plan d’action concret
- Découvrir toutes les APIs publiques et internes
- Associer chaque API à un owner
- Définir schéma et criticité données
- Tester BOLA/BFLA
- Configurer rate limits
- Surveiller séquences d’appels anormales
Livrables attendus
- Cartographie ou registre mis à jour
- Liste des décisions et propriétaires
- Actions priorisées avec échéance
- Preuves de configuration ou de test
- Indicateurs de suivi
- Retour d’expérience après exercice ou incident
Le playbook doit pouvoir être exécuté par une équipe réelle, pas seulement compris par un expert sécurité.
Échelle de maturité
| Niveau | Description |
|---|---|
| Niveau 1 — réactif | Contrôles ponctuels, dépendance aux personnes, preuves faibles, actions après incident. |
| Niveau 2 — structuré | Actifs et responsabilités définis, contrôles prioritaires, logs et procédures minimales. |
| Niveau 3 — piloté | KPI/KRI, automatisation partielle, revues périodiques, exercices et amélioration continue. |
| Niveau 4 — résilient | Mesure du risque, tests réguliers, détection avancée, réponse orchestrée, culture intégrée. |
Quick wins
- Nommer un owner
- Documenter le périmètre
- Activer logs
- Supprimer l’exposition inutile
Industrialisation
- Automatiser contrôles
- Définir SLA
- Créer preuves
- Tester régulièrement
Excellence
- Mesurer réduction de risque
- Simuler incidents
- Adapter aux menaces
- Améliorer par RETEX
Questions de cadrage à poser en atelier
- Qui est propriétaire de cet enjeu : métier, IT, sécurité, juridique ou direction ?
- Quel actif ou processus serait le plus touché si ce domaine échouait demain ?
- Quelles preuves montrent que les contrôles fonctionnent réellement ?
- Quel incident réaliste permettrait de tester ce domaine en moins de 2 heures ?
- Quelles exceptions existent et qui accepte le risque résiduel ?
- Quel indicateur simple permet de suivre la progression mois après mois ?
Atelier recommandé : 45 minutes avec métier + IT + sécurité. Objectif : sortir avec 5 décisions, 5 actions et 5 preuves attendues.
☁️ Cloud, SaaS & Kubernetes
Positionnement.
Responsabilité partagée, IAM cloud, CSPM, CNAPP, conteneurs, Kubernetes, secrets, IaC et erreurs de configuration.
Responsabilité partagée, IAM cloud, CSPM, CNAPP, conteneurs, Kubernetes, secrets, IaC et erreurs de configuration.
Le cloud déplace une partie de la responsabilité mais ne supprime pas la responsabilité client : identités, configuration, données, réseau, chiffrement, logs et workloads restent à gouverner.
Les erreurs cloud les plus fréquentes sont souvent simples : permissions trop larges, stockage public, secrets exposés, logs désactivés, workloads trop privilégiés, réseau ouvert.
Kubernetes ajoute un plan de contrôle, des images, des secrets, des rôles, des admission controllers, des politiques réseau et des workloads éphémères : la visibilité doit être automatisée.
Lecture synthétique
| Axe | Détail |
|---|---|
| Ce qu’il faut protéger | Actifs, données, identités, processus, réputation, continuité. |
| Ce qu’il faut décider | Priorités, risques acceptés, moyens, responsabilités, preuves attendues. |
| Ce qu’il faut mesurer | Couverture, délai, qualité de détection, efficacité de réponse, impact résiduel. |
Risques principaux
- Bucket public
- Rôle cloud admin trop large
- Absence de CloudTrail/logs équivalents
- Secrets dans variables ou manifests
- Image container vulnérable
- Pod privilégié
- Cluster Kubernetes exposé
- IaC non revu
Lecture impact métier
Point critique : un risque cyber devient prioritaire quand il touche un service essentiel, une donnée sensible, une identité à privilège, une obligation réglementaire ou une dépendance fournisseur difficile à remplacer.
| Risque | Impact typique |
|---|---|
| Bucket public | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Rôle cloud admin trop large | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Absence de CloudTrail/logs équivalents | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Secrets dans variables ou manifests | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Image container vulnérable | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Pod privilégié | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
Scénario réaliste
Un développeur crée un rôle cloud avec `*:*` pour débloquer un déploiement. Le rôle reste en production, utilisé par une pipeline CI. Après compromission du token CI, l’attaquant dispose d’un accès quasi total au compte cloud.
Chaîne d’attaque probable
Reconnaissance → accès initial → persistance → élévation → mouvement latéral → action sur objectif → extorsion / sabotage / fraude
Signaux faibles à surveiller
- Connexion inhabituelle ou impossible travel
- Volume anormal de lectures ou exports
- Création de compte, token ou règle de transfert
- Utilisation d’outils d’administration hors fenêtre
- Accès depuis IP, device ou pays atypique
- Modification de configuration sensible
Mesures de maîtrise
- Landing zone sécurisée
- IAM least privilege
- CSPM/CNAPP
- Scan IaC en CI
- Images signées/scannées
- Secrets manager
- Network policies Kubernetes
- Audit logs centralisés
- Admission control
- Segmentation comptes/projets
Matrice prévention / détection / réponse
| Phase | Exemples |
|---|---|
| Prévenir | Réduire exposition, durcir configuration, limiter privilèges, former, automatiser les contrôles. |
| Détecter | Collecter logs utiles, créer use cases, surveiller comportements, corréler signaux. |
| Répondre | Isoler, révoquer, restaurer, communiquer, documenter, améliorer. |
Règle : aucun contrôle ne doit rester purement déclaratif. Il faut une preuve observable : configuration, log, rapport de test, ticket, capture, exercice ou métrique.
Indicateurs à suivre
- Rôles wildcard
- Ressources publiques non justifiées
- Images critiques vulnérables
- Clusters sans audit logs
- Secrets en clair
- Findings CSPM critiques ouverts
- Workloads privilégiés
Comment les interpréter
| Indicateur | Lecture |
|---|---|
| Rôles wildcard | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Ressources publiques non justifiées | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Images critiques vulnérables | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Clusters sans audit logs | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Secrets en clair | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Findings CSPM critiques ouverts | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Workloads privilégiés | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
Attention : un KPI sans seuil, sans propriétaire et sans décision associée devient vite décoratif.
Plan d’action concret
- Définir baseline cloud
- Activer logs et guardrails
- Scanner IaC avant déploiement
- Réduire rôles à privilèges
- Séparer environnements
- Auditer clusters et images
- Mettre en place remédiation continue
Livrables attendus
- Cartographie ou registre mis à jour
- Liste des décisions et propriétaires
- Actions priorisées avec échéance
- Preuves de configuration ou de test
- Indicateurs de suivi
- Retour d’expérience après exercice ou incident
Le playbook doit pouvoir être exécuté par une équipe réelle, pas seulement compris par un expert sécurité.
Échelle de maturité
| Niveau | Description |
|---|---|
| Niveau 1 — réactif | Contrôles ponctuels, dépendance aux personnes, preuves faibles, actions après incident. |
| Niveau 2 — structuré | Actifs et responsabilités définis, contrôles prioritaires, logs et procédures minimales. |
| Niveau 3 — piloté | KPI/KRI, automatisation partielle, revues périodiques, exercices et amélioration continue. |
| Niveau 4 — résilient | Mesure du risque, tests réguliers, détection avancée, réponse orchestrée, culture intégrée. |
Quick wins
- Nommer un owner
- Documenter le périmètre
- Activer logs
- Supprimer l’exposition inutile
Industrialisation
- Automatiser contrôles
- Définir SLA
- Créer preuves
- Tester régulièrement
Excellence
- Mesurer réduction de risque
- Simuler incidents
- Adapter aux menaces
- Améliorer par RETEX
Questions de cadrage à poser en atelier
- Qui est propriétaire de cet enjeu : métier, IT, sécurité, juridique ou direction ?
- Quel actif ou processus serait le plus touché si ce domaine échouait demain ?
- Quelles preuves montrent que les contrôles fonctionnent réellement ?
- Quel incident réaliste permettrait de tester ce domaine en moins de 2 heures ?
- Quelles exceptions existent et qui accepte le risque résiduel ?
- Quel indicateur simple permet de suivre la progression mois après mois ?
Atelier recommandé : 45 minutes avec métier + IT + sécurité. Objectif : sortir avec 5 décisions, 5 actions et 5 preuves attendues.
🌐 Réseau, segmentation & accès distant
Positionnement.
Segmentation, pare-feu, VPN/ZTNA, DNS, egress filtering, exposition, DDoS, latéralisation et contrôle des flux.
Segmentation, pare-feu, VPN/ZTNA, DNS, egress filtering, exposition, DDoS, latéralisation et contrôle des flux.
Le réseau reste fondamental, même dans le cloud. Il définit les chemins possibles de propagation, d’exfiltration, d’administration et de communication entre services.
La segmentation limite l’impact quand un poste, un serveur ou un compte est compromis. Elle doit être pensée par criticité, flux métier et niveau de confiance.
Les accès distants évoluent : VPN traditionnel, ZTNA, SASE, bastions, PAM et accès conditionnel doivent être alignés avec l’identité.
Lecture synthétique
| Axe | Détail |
|---|---|
| Ce qu’il faut protéger | Actifs, données, identités, processus, réputation, continuité. |
| Ce qu’il faut décider | Priorités, risques acceptés, moyens, responsabilités, preuves attendues. |
| Ce qu’il faut mesurer | Couverture, délai, qualité de détection, efficacité de réponse, impact résiduel. |
Risques principaux
- Flat network facilitant mouvement latéral
- VPN exposé vulnérable
- Admin interfaces accessibles largement
- Absence d’egress filtering
- DNS non monitoré
- DDoS sans plan de mitigation
- Flux interzones non documentés
Lecture impact métier
Point critique : un risque cyber devient prioritaire quand il touche un service essentiel, une donnée sensible, une identité à privilège, une obligation réglementaire ou une dépendance fournisseur difficile à remplacer.
| Risque | Impact typique |
|---|---|
| Flat network facilitant mouvement latéral | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| VPN exposé vulnérable | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Admin interfaces accessibles largement | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Absence d’egress filtering | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| DNS non monitoré | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| DDoS sans plan de mitigation | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
Scénario réaliste
Après compromission d’un poste utilisateur, l’attaquant scanne le réseau interne et découvre des partages SMB, consoles d’administration et bases de données accessibles depuis un VLAN utilisateur. Une segmentation efficace aurait bloqué la progression.
Chaîne d’attaque probable
Reconnaissance → accès initial → persistance → élévation → mouvement latéral → action sur objectif → extorsion / sabotage / fraude
Signaux faibles à surveiller
- Connexion inhabituelle ou impossible travel
- Volume anormal de lectures ou exports
- Création de compte, token ou règle de transfert
- Utilisation d’outils d’administration hors fenêtre
- Accès depuis IP, device ou pays atypique
- Modification de configuration sensible
Mesures de maîtrise
- Segmentation par zones
- Pare-feu applicatifs et réseau
- ZTNA ou accès conditionnel
- Bastions admin
- Egress filtering
- DNS security
- DDoS protection
- Cartographie des flux
- Microsegmentation pour actifs critiques
Matrice prévention / détection / réponse
| Phase | Exemples |
|---|---|
| Prévenir | Réduire exposition, durcir configuration, limiter privilèges, former, automatiser les contrôles. |
| Détecter | Collecter logs utiles, créer use cases, surveiller comportements, corréler signaux. |
| Répondre | Isoler, révoquer, restaurer, communiquer, documenter, améliorer. |
Règle : aucun contrôle ne doit rester purement déclaratif. Il faut une preuve observable : configuration, log, rapport de test, ticket, capture, exercice ou métrique.
Indicateurs à suivre
- Flux interzones non validés
- Interfaces admin exposées
- Accès VPN sans MFA
- Taux de règles firewall obsolètes
- Trafic egress inconnu
- Alertes DNS suspectes
- Tests de segmentation réussis
Comment les interpréter
| Indicateur | Lecture |
|---|---|
| Flux interzones non validés | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Interfaces admin exposées | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Accès VPN sans MFA | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Taux de règles firewall obsolètes | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Trafic egress inconnu | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Alertes DNS suspectes | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Tests de segmentation réussis | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
Attention : un KPI sans seuil, sans propriétaire et sans décision associée devient vite décoratif.
Plan d’action concret
- Cartographier flux réels
- Définir zones de confiance
- Bloquer interfaces admin hors bastion
- Activer MFA accès distant
- Limiter egress
- Tester mouvement latéral
- Revoir règles firewall chaque trimestre
Livrables attendus
- Cartographie ou registre mis à jour
- Liste des décisions et propriétaires
- Actions priorisées avec échéance
- Preuves de configuration ou de test
- Indicateurs de suivi
- Retour d’expérience après exercice ou incident
Le playbook doit pouvoir être exécuté par une équipe réelle, pas seulement compris par un expert sécurité.
Échelle de maturité
| Niveau | Description |
|---|---|
| Niveau 1 — réactif | Contrôles ponctuels, dépendance aux personnes, preuves faibles, actions après incident. |
| Niveau 2 — structuré | Actifs et responsabilités définis, contrôles prioritaires, logs et procédures minimales. |
| Niveau 3 — piloté | KPI/KRI, automatisation partielle, revues périodiques, exercices et amélioration continue. |
| Niveau 4 — résilient | Mesure du risque, tests réguliers, détection avancée, réponse orchestrée, culture intégrée. |
Quick wins
- Nommer un owner
- Documenter le périmètre
- Activer logs
- Supprimer l’exposition inutile
Industrialisation
- Automatiser contrôles
- Définir SLA
- Créer preuves
- Tester régulièrement
Excellence
- Mesurer réduction de risque
- Simuler incidents
- Adapter aux menaces
- Améliorer par RETEX
Questions de cadrage à poser en atelier
- Qui est propriétaire de cet enjeu : métier, IT, sécurité, juridique ou direction ?
- Quel actif ou processus serait le plus touché si ce domaine échouait demain ?
- Quelles preuves montrent que les contrôles fonctionnent réellement ?
- Quel incident réaliste permettrait de tester ce domaine en moins de 2 heures ?
- Quelles exceptions existent et qui accepte le risque résiduel ?
- Quel indicateur simple permet de suivre la progression mois après mois ?
Atelier recommandé : 45 minutes avec métier + IT + sécurité. Objectif : sortir avec 5 décisions, 5 actions et 5 preuves attendues.
💻 Endpoint, serveurs & EDR/XDR
Positionnement.
Postes, serveurs, mobiles, EDR, durcissement, patching, privilèges locaux et visibilité comportementale.
Postes, serveurs, mobiles, EDR, durcissement, patching, privilèges locaux et visibilité comportementale.
Les endpoints restent une porte d’entrée majeure : phishing, macros, navigateurs, extensions, outils d’administration légitimes détournés, infostealers, scripts et accès distants.
La protection endpoint combine hygiène de base, durcissement, patching, réduction des privilèges, EDR/XDR, isolation, logs et capacité de réponse rapide.
Un EDR mal déployé ou non surveillé n’apporte qu’une illusion de sécurité : il faut des règles, des playbooks et des équipes capables d’agir.
Lecture synthétique
| Axe | Détail |
|---|---|
| Ce qu’il faut protéger | Actifs, données, identités, processus, réputation, continuité. |
| Ce qu’il faut décider | Priorités, risques acceptés, moyens, responsabilités, preuves attendues. |
| Ce qu’il faut mesurer | Couverture, délai, qualité de détection, efficacité de réponse, impact résiduel. |
Risques principaux
- Postes sans EDR actif
- Administrateurs locaux excessifs
- Patching retardé
- Macros et scripts non contrôlés
- Outils légitimes détournés
- Absence d’inventaire logiciel
- Serveurs exposés sans durcissement
Lecture impact métier
Point critique : un risque cyber devient prioritaire quand il touche un service essentiel, une donnée sensible, une identité à privilège, une obligation réglementaire ou une dépendance fournisseur difficile à remplacer.
| Risque | Impact typique |
|---|---|
| Postes sans EDR actif | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Administrateurs locaux excessifs | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Patching retardé | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Macros et scripts non contrôlés | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Outils légitimes détournés | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Absence d’inventaire logiciel | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
Scénario réaliste
Un infostealer est exécuté sur un poste non durci. Il vole cookies, mots de passe navigateur et tokens SaaS. Même sans privilèges admin, il ouvre la porte à une compromission d’identités cloud.
Chaîne d’attaque probable
Reconnaissance → accès initial → persistance → élévation → mouvement latéral → action sur objectif → extorsion / sabotage / fraude
Signaux faibles à surveiller
- Connexion inhabituelle ou impossible travel
- Volume anormal de lectures ou exports
- Création de compte, token ou règle de transfert
- Utilisation d’outils d’administration hors fenêtre
- Accès depuis IP, device ou pays atypique
- Modification de configuration sensible
Mesures de maîtrise
- EDR/XDR généralisé
- Hardening OS et navigateurs
- Patching priorisé
- Gestion des privilèges locaux
- Contrôle applications/scripts
- Inventaire logiciel
- Isolation réseau des endpoints à risque
- Réponse EDR automatisée
Matrice prévention / détection / réponse
| Phase | Exemples |
|---|---|
| Prévenir | Réduire exposition, durcir configuration, limiter privilèges, former, automatiser les contrôles. |
| Détecter | Collecter logs utiles, créer use cases, surveiller comportements, corréler signaux. |
| Répondre | Isoler, révoquer, restaurer, communiquer, documenter, améliorer. |
Règle : aucun contrôle ne doit rester purement déclaratif. Il faut une preuve observable : configuration, log, rapport de test, ticket, capture, exercice ou métrique.
Indicateurs à suivre
- Couverture EDR
- Postes en retard patch critique
- Admins locaux non justifiés
- Alertes EDR non traitées
- Logiciels non approuvés
- Postes hors inventaire
- MTTR endpoint
Comment les interpréter
| Indicateur | Lecture |
|---|---|
| Couverture EDR | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Postes en retard patch critique | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Admins locaux non justifiés | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Alertes EDR non traitées | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Logiciels non approuvés | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Postes hors inventaire | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| MTTR endpoint | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
Attention : un KPI sans seuil, sans propriétaire et sans décision associée devient vite décoratif.
Plan d’action concret
- Vérifier couverture EDR
- Lister privilèges locaux
- Durcir navigateurs et Office
- Prioriser patches exploités
- Créer playbook isolation poste
- Tester investigation et containment
Livrables attendus
- Cartographie ou registre mis à jour
- Liste des décisions et propriétaires
- Actions priorisées avec échéance
- Preuves de configuration ou de test
- Indicateurs de suivi
- Retour d’expérience après exercice ou incident
Le playbook doit pouvoir être exécuté par une équipe réelle, pas seulement compris par un expert sécurité.
Échelle de maturité
| Niveau | Description |
|---|---|
| Niveau 1 — réactif | Contrôles ponctuels, dépendance aux personnes, preuves faibles, actions après incident. |
| Niveau 2 — structuré | Actifs et responsabilités définis, contrôles prioritaires, logs et procédures minimales. |
| Niveau 3 — piloté | KPI/KRI, automatisation partielle, revues périodiques, exercices et amélioration continue. |
| Niveau 4 — résilient | Mesure du risque, tests réguliers, détection avancée, réponse orchestrée, culture intégrée. |
Quick wins
- Nommer un owner
- Documenter le périmètre
- Activer logs
- Supprimer l’exposition inutile
Industrialisation
- Automatiser contrôles
- Définir SLA
- Créer preuves
- Tester régulièrement
Excellence
- Mesurer réduction de risque
- Simuler incidents
- Adapter aux menaces
- Améliorer par RETEX
Questions de cadrage à poser en atelier
- Qui est propriétaire de cet enjeu : métier, IT, sécurité, juridique ou direction ?
- Quel actif ou processus serait le plus touché si ce domaine échouait demain ?
- Quelles preuves montrent que les contrôles fonctionnent réellement ?
- Quel incident réaliste permettrait de tester ce domaine en moins de 2 heures ?
- Quelles exceptions existent et qui accepte le risque résiduel ?
- Quel indicateur simple permet de suivre la progression mois après mois ?
Atelier recommandé : 45 minutes avec métier + IT + sécurité. Objectif : sortir avec 5 décisions, 5 actions et 5 preuves attendues.
🧯 Ransomware, extorsion & continuité
Positionnement.
Prévention, détection, sauvegardes, segmentation, exfiltration, crise, restauration et négociation.
Prévention, détection, sauvegardes, segmentation, exfiltration, crise, restauration et négociation.
Le ransomware moderne vise souvent l’extorsion globale : vol de données, chiffrement, menace de publication, pression clients, interruption opérationnelle et parfois harcèlement ciblé.
La meilleure défense repose sur la réduction de l’intrusion initiale, la limitation du mouvement latéral, la détection précoce, les sauvegardes isolées et un plan de crise testé.
Le sujet principal n’est pas seulement “éviter le chiffrement” mais maintenir une capacité de décision et de reprise quand une partie du SI est compromise.
Lecture synthétique
| Axe | Détail |
|---|---|
| Ce qu’il faut protéger | Actifs, données, identités, processus, réputation, continuité. |
| Ce qu’il faut décider | Priorités, risques acceptés, moyens, responsabilités, preuves attendues. |
| Ce qu’il faut mesurer | Couverture, délai, qualité de détection, efficacité de réponse, impact résiduel. |
Risques principaux
- Initial access via VPN/RDP/phishing
- Vol d’identifiants AD/cloud
- Désactivation sauvegardes
- Chiffrement massif
- Exfiltration avant impact
- Pression juridique et médiatique
- Restauration trop lente ou non testée
Lecture impact métier
Point critique : un risque cyber devient prioritaire quand il touche un service essentiel, une donnée sensible, une identité à privilège, une obligation réglementaire ou une dépendance fournisseur difficile à remplacer.
| Risque | Impact typique |
|---|---|
| Initial access via VPN/RDP/phishing | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Vol d’identifiants AD/cloud | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Désactivation sauvegardes | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Chiffrement massif | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Exfiltration avant impact | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Pression juridique et médiatique | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
Scénario réaliste
Un compte VPN compromis donne accès au réseau. L’attaquant élève ses privilèges, découvre les serveurs de sauvegarde, exfiltre des données puis chiffre les partages. Les sauvegardes existent mais n’ont jamais été testées à grande échelle.
Chaîne d’attaque probable
Reconnaissance → accès initial → persistance → élévation → mouvement latéral → action sur objectif → extorsion / sabotage / fraude
Signaux faibles à surveiller
- Connexion inhabituelle ou impossible travel
- Volume anormal de lectures ou exports
- Création de compte, token ou règle de transfert
- Utilisation d’outils d’administration hors fenêtre
- Accès depuis IP, device ou pays atypique
- Modification de configuration sensible
Mesures de maîtrise
- MFA accès distant
- Segmentation
- EDR + alertes comportementales
- Sauvegardes 3-2-1-1-0
- Immutabilité / offline backups
- PAM et durcissement AD
- Runbook de crise
- Exercices de restauration
- Détection exfiltration
Matrice prévention / détection / réponse
| Phase | Exemples |
|---|---|
| Prévenir | Réduire exposition, durcir configuration, limiter privilèges, former, automatiser les contrôles. |
| Détecter | Collecter logs utiles, créer use cases, surveiller comportements, corréler signaux. |
| Répondre | Isoler, révoquer, restaurer, communiquer, documenter, améliorer. |
Règle : aucun contrôle ne doit rester purement déclaratif. Il faut une preuve observable : configuration, log, rapport de test, ticket, capture, exercice ou métrique.
Indicateurs à suivre
- Sauvegardes restaurées avec succès
- Temps de restauration par service
- Comptes privilégiés exposés
- Alertes exfiltration
- Services sans backup immutable
- Couverture MFA VPN
- Résultats exercices ransomware
Comment les interpréter
| Indicateur | Lecture |
|---|---|
| Sauvegardes restaurées avec succès | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Temps de restauration par service | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Comptes privilégiés exposés | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Alertes exfiltration | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Services sans backup immutable | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Couverture MFA VPN | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Résultats exercices ransomware | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
Attention : un KPI sans seuil, sans propriétaire et sans décision associée devient vite décoratif.
Plan d’action concret
- Identifier actifs nécessaires à la reprise
- Tester restauration d’un service critique
- Isoler sauvegardes et identités backup
- Préparer messages de crise
- Définir cellule décisionnelle
- Simuler un incident ransomware de 4 heures
Livrables attendus
- Cartographie ou registre mis à jour
- Liste des décisions et propriétaires
- Actions priorisées avec échéance
- Preuves de configuration ou de test
- Indicateurs de suivi
- Retour d’expérience après exercice ou incident
Le playbook doit pouvoir être exécuté par une équipe réelle, pas seulement compris par un expert sécurité.
Échelle de maturité
| Niveau | Description |
|---|---|
| Niveau 1 — réactif | Contrôles ponctuels, dépendance aux personnes, preuves faibles, actions après incident. |
| Niveau 2 — structuré | Actifs et responsabilités définis, contrôles prioritaires, logs et procédures minimales. |
| Niveau 3 — piloté | KPI/KRI, automatisation partielle, revues périodiques, exercices et amélioration continue. |
| Niveau 4 — résilient | Mesure du risque, tests réguliers, détection avancée, réponse orchestrée, culture intégrée. |
Quick wins
- Nommer un owner
- Documenter le périmètre
- Activer logs
- Supprimer l’exposition inutile
Industrialisation
- Automatiser contrôles
- Définir SLA
- Créer preuves
- Tester régulièrement
Excellence
- Mesurer réduction de risque
- Simuler incidents
- Adapter aux menaces
- Améliorer par RETEX
Questions de cadrage à poser en atelier
- Qui est propriétaire de cet enjeu : métier, IT, sécurité, juridique ou direction ?
- Quel actif ou processus serait le plus touché si ce domaine échouait demain ?
- Quelles preuves montrent que les contrôles fonctionnent réellement ?
- Quel incident réaliste permettrait de tester ce domaine en moins de 2 heures ?
- Quelles exceptions existent et qui accepte le risque résiduel ?
- Quel indicateur simple permet de suivre la progression mois après mois ?
Atelier recommandé : 45 minutes avec métier + IT + sécurité. Objectif : sortir avec 5 décisions, 5 actions et 5 preuves attendues.
🔗 Supply chain, tiers & CI/CD
Positionnement.
Prestataires, dépendances open source, SBOM, build pipelines, secrets, mises à jour, contrats et risques hérités.
Prestataires, dépendances open source, SBOM, build pipelines, secrets, mises à jour, contrats et risques hérités.
La supply chain étend votre risque à vos fournisseurs, dépendances, bibliothèques, images, outils CI/CD, dépôts, extensions, intégrateurs, MSP et services cloud.
Une compromission en amont peut contaminer des clients en aval. Inversement, un prestataire avec accès privilégié peut devenir un point d’entrée dans votre SI.
La sécurité de la chaîne logicielle exige inventaire, provenance, signature, revues, isolation, droits minimaux et détection des comportements anormaux.
Lecture synthétique
| Axe | Détail |
|---|---|
| Ce qu’il faut protéger | Actifs, données, identités, processus, réputation, continuité. |
| Ce qu’il faut décider | Priorités, risques acceptés, moyens, responsabilités, preuves attendues. |
| Ce qu’il faut mesurer | Couverture, délai, qualité de détection, efficacité de réponse, impact résiduel. |
Risques principaux
- Dépendance open source compromise
- Package typosquatting
- Token CI/CD volé
- Pipeline modifiée
- Prestataire avec accès persistant
- Mise à jour malveillante
- Absence de SBOM
- Secrets dans logs de build
Lecture impact métier
Point critique : un risque cyber devient prioritaire quand il touche un service essentiel, une donnée sensible, une identité à privilège, une obligation réglementaire ou une dépendance fournisseur difficile à remplacer.
| Risque | Impact typique |
|---|---|
| Dépendance open source compromise | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Package typosquatting | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Token CI/CD volé | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Pipeline modifiée | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Prestataire avec accès persistant | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Mise à jour malveillante | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
Scénario réaliste
Une dépendance mineure utilisée par un outil interne est compromise. La pipeline CI récupère automatiquement la nouvelle version et exécute du code malveillant qui exfiltre des secrets de build.
Chaîne d’attaque probable
Reconnaissance → accès initial → persistance → élévation → mouvement latéral → action sur objectif → extorsion / sabotage / fraude
Signaux faibles à surveiller
- Connexion inhabituelle ou impossible travel
- Volume anormal de lectures ou exports
- Création de compte, token ou règle de transfert
- Utilisation d’outils d’administration hors fenêtre
- Accès depuis IP, device ou pays atypique
- Modification de configuration sensible
Mesures de maîtrise
- SBOM
- Verrouillage versions
- Dependency scanning
- Signature artefacts
- OIDC CI/CD court terme
- Secrets manager
- Revues fournisseurs
- Accès tiers limités et expirants
- Isolation des runners
- SLSA/in-toto selon maturité
Matrice prévention / détection / réponse
| Phase | Exemples |
|---|---|
| Prévenir | Réduire exposition, durcir configuration, limiter privilèges, former, automatiser les contrôles. |
| Détecter | Collecter logs utiles, créer use cases, surveiller comportements, corréler signaux. |
| Répondre | Isoler, révoquer, restaurer, communiquer, documenter, améliorer. |
Règle : aucun contrôle ne doit rester purement déclaratif. Il faut une preuve observable : configuration, log, rapport de test, ticket, capture, exercice ou métrique.
Indicateurs à suivre
- Dépendances critiques non maintenues
- Secrets accessibles en CI
- Fournisseurs sans évaluation sécurité
- Accès tiers permanents
- Builds non reproductibles
- Images non signées
- Alertes supply chain
Comment les interpréter
| Indicateur | Lecture |
|---|---|
| Dépendances critiques non maintenues | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Secrets accessibles en CI | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Fournisseurs sans évaluation sécurité | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Accès tiers permanents | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Builds non reproductibles | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Images non signées | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Alertes supply chain | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
Attention : un KPI sans seuil, sans propriétaire et sans décision associée devient vite décoratif.
Plan d’action concret
- Lister composants et fournisseurs critiques
- Classer accès tiers
- Scanner dépendances et images
- Réduire secrets CI
- Signer artefacts clés
- Mettre expiration sur accès prestataires
- Préparer retrait rapide d’une dépendance compromise
Livrables attendus
- Cartographie ou registre mis à jour
- Liste des décisions et propriétaires
- Actions priorisées avec échéance
- Preuves de configuration ou de test
- Indicateurs de suivi
- Retour d’expérience après exercice ou incident
Le playbook doit pouvoir être exécuté par une équipe réelle, pas seulement compris par un expert sécurité.
Échelle de maturité
| Niveau | Description |
|---|---|
| Niveau 1 — réactif | Contrôles ponctuels, dépendance aux personnes, preuves faibles, actions après incident. |
| Niveau 2 — structuré | Actifs et responsabilités définis, contrôles prioritaires, logs et procédures minimales. |
| Niveau 3 — piloté | KPI/KRI, automatisation partielle, revues périodiques, exercices et amélioration continue. |
| Niveau 4 — résilient | Mesure du risque, tests réguliers, détection avancée, réponse orchestrée, culture intégrée. |
Quick wins
- Nommer un owner
- Documenter le périmètre
- Activer logs
- Supprimer l’exposition inutile
Industrialisation
- Automatiser contrôles
- Définir SLA
- Créer preuves
- Tester régulièrement
Excellence
- Mesurer réduction de risque
- Simuler incidents
- Adapter aux menaces
- Améliorer par RETEX
Questions de cadrage à poser en atelier
- Qui est propriétaire de cet enjeu : métier, IT, sécurité, juridique ou direction ?
- Quel actif ou processus serait le plus touché si ce domaine échouait demain ?
- Quelles preuves montrent que les contrôles fonctionnent réellement ?
- Quel incident réaliste permettrait de tester ce domaine en moins de 2 heures ?
- Quelles exceptions existent et qui accepte le risque résiduel ?
- Quel indicateur simple permet de suivre la progression mois après mois ?
Atelier recommandé : 45 minutes avec métier + IT + sécurité. Objectif : sortir avec 5 décisions, 5 actions et 5 preuves attendues.
🤖 IA, automatisation & nouveaux risques
Positionnement.
IA défensive, IA offensive, données d’entraînement, prompt injection, deepfakes, fuite de données et gouvernance.
IA défensive, IA offensive, données d’entraînement, prompt injection, deepfakes, fuite de données et gouvernance.
L’IA transforme la cybersécurité dans les deux sens : elle aide à trier les alertes, détecter des anomalies, enrichir le renseignement, générer des règles et assister l’analyse ; elle aide aussi les attaquants à automatiser social engineering, reconnaissance, génération de leurres et adaptation.
Les systèmes IA introduisent leurs propres actifs : prompts, modèles, datasets, embeddings, vecteurs RAG, outils, agents, connecteurs et permissions.
La sécurité IA doit traiter la confidentialité des données, l’intégrité des modèles, la traçabilité des sorties, les abus d’outils et les attaques de type prompt injection ou data poisoning.
Lecture synthétique
| Axe | Détail |
|---|---|
| Ce qu’il faut protéger | Actifs, données, identités, processus, réputation, continuité. |
| Ce qu’il faut décider | Priorités, risques acceptés, moyens, responsabilités, preuves attendues. |
| Ce qu’il faut mesurer | Couverture, délai, qualité de détection, efficacité de réponse, impact résiduel. |
Risques principaux
- Prompt injection
- Exfiltration via outil connecté
- Fuite de données sensibles dans prompts
- Poisoning de données ou embeddings
- Deepfake social engineering
- Automatisation d’attaques low-cost
- Dépendances modèles non vérifiées
Lecture impact métier
Point critique : un risque cyber devient prioritaire quand il touche un service essentiel, une donnée sensible, une identité à privilège, une obligation réglementaire ou une dépendance fournisseur difficile à remplacer.
| Risque | Impact typique |
|---|---|
| Prompt injection | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Exfiltration via outil connecté | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Fuite de données sensibles dans prompts | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Poisoning de données ou embeddings | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Deepfake social engineering | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Automatisation d’attaques low-cost | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
Scénario réaliste
Un assistant interne RAG a accès à des documents RH et financiers. Un utilisateur injecte une consigne dans un document indexé demandant à l’assistant de révéler des informations sensibles. Le problème vient du mélange entre données non fiables, récupération documentaire et droits d’accès trop larges.
Chaîne d’attaque probable
Reconnaissance → accès initial → persistance → élévation → mouvement latéral → action sur objectif → extorsion / sabotage / fraude
Signaux faibles à surveiller
- Connexion inhabituelle ou impossible travel
- Volume anormal de lectures ou exports
- Création de compte, token ou règle de transfert
- Utilisation d’outils d’administration hors fenêtre
- Accès depuis IP, device ou pays atypique
- Modification de configuration sensible
Mesures de maîtrise
- Classification données avant IA
- Contrôle d’accès au niveau document
- Filtrage prompts/outils
- Journalisation des requêtes sensibles
- Évaluation adversariale
- Isolation des agents
- Validation humaine pour actions critiques
- Inventaire modèles/datasets
- Politiques d’usage IA
Matrice prévention / détection / réponse
| Phase | Exemples |
|---|---|
| Prévenir | Réduire exposition, durcir configuration, limiter privilèges, former, automatiser les contrôles. |
| Détecter | Collecter logs utiles, créer use cases, surveiller comportements, corréler signaux. |
| Répondre | Isoler, révoquer, restaurer, communiquer, documenter, améliorer. |
Règle : aucun contrôle ne doit rester purement déclaratif. Il faut une preuve observable : configuration, log, rapport de test, ticket, capture, exercice ou métrique.
Indicateurs à suivre
- Connecteurs IA avec accès large
- Prompts contenant données sensibles
- Documents RAG sans ACL
- Actions agent sans validation
- Tests prompt injection échoués
- Incidents deepfake signalés
- Modèles non inventoriés
Comment les interpréter
| Indicateur | Lecture |
|---|---|
| Connecteurs IA avec accès large | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Prompts contenant données sensibles | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Documents RAG sans ACL | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Actions agent sans validation | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Tests prompt injection échoués | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Incidents deepfake signalés | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Modèles non inventoriés | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
Attention : un KPI sans seuil, sans propriétaire et sans décision associée devient vite décoratif.
Plan d’action concret
- Inventorier usages IA
- Classer données accessibles aux modèles
- Désactiver outils dangereux par défaut
- Limiter accès RAG par ACL
- Créer tests adversariaux
- Former équipes aux deepfakes
- Superviser requêtes et actions sensibles
Livrables attendus
- Cartographie ou registre mis à jour
- Liste des décisions et propriétaires
- Actions priorisées avec échéance
- Preuves de configuration ou de test
- Indicateurs de suivi
- Retour d’expérience après exercice ou incident
Le playbook doit pouvoir être exécuté par une équipe réelle, pas seulement compris par un expert sécurité.
Échelle de maturité
| Niveau | Description |
|---|---|
| Niveau 1 — réactif | Contrôles ponctuels, dépendance aux personnes, preuves faibles, actions après incident. |
| Niveau 2 — structuré | Actifs et responsabilités définis, contrôles prioritaires, logs et procédures minimales. |
| Niveau 3 — piloté | KPI/KRI, automatisation partielle, revues périodiques, exercices et amélioration continue. |
| Niveau 4 — résilient | Mesure du risque, tests réguliers, détection avancée, réponse orchestrée, culture intégrée. |
Quick wins
- Nommer un owner
- Documenter le périmètre
- Activer logs
- Supprimer l’exposition inutile
Industrialisation
- Automatiser contrôles
- Définir SLA
- Créer preuves
- Tester régulièrement
Excellence
- Mesurer réduction de risque
- Simuler incidents
- Adapter aux menaces
- Améliorer par RETEX
Questions de cadrage à poser en atelier
- Qui est propriétaire de cet enjeu : métier, IT, sécurité, juridique ou direction ?
- Quel actif ou processus serait le plus touché si ce domaine échouait demain ?
- Quelles preuves montrent que les contrôles fonctionnent réellement ?
- Quel incident réaliste permettrait de tester ce domaine en moins de 2 heures ?
- Quelles exceptions existent et qui accepte le risque résiduel ?
- Quel indicateur simple permet de suivre la progression mois après mois ?
Atelier recommandé : 45 minutes avec métier + IT + sécurité. Objectif : sortir avec 5 décisions, 5 actions et 5 preuves attendues.
🏭 OT, IoT & systèmes industriels
Positionnement.
Sécurité des environnements industriels, IoT, disponibilité, sûreté, segmentation et contraintes opérationnelles.
Sécurité des environnements industriels, IoT, disponibilité, sûreté, segmentation et contraintes opérationnelles.
Les environnements OT et IoT ont des contraintes différentes de l’IT classique : disponibilité, sécurité physique, cycles longs, équipements legacy, fenêtres de maintenance réduites et protocoles spécialisés.
L’objectif n’est pas seulement de protéger des données, mais d’éviter interruption de production, dommage matériel, risque humain, sabotage ou manipulation de processus.
La convergence IT/OT augmente les risques : accès distants, supervision centralisée, passerelles, maintenance fournisseur et intégration cloud.
Lecture synthétique
| Axe | Détail |
|---|---|
| Ce qu’il faut protéger | Actifs, données, identités, processus, réputation, continuité. |
| Ce qu’il faut décider | Priorités, risques acceptés, moyens, responsabilités, preuves attendues. |
| Ce qu’il faut mesurer | Couverture, délai, qualité de détection, efficacité de réponse, impact résiduel. |
Risques principaux
- Équipement legacy non patchable
- Accès distant fournisseur mal contrôlé
- Réseau OT trop plat
- Protocoles non authentifiés
- Inventaire incomplet
- IoT avec mots de passe par défaut
- Impact physique d’un incident cyber
Lecture impact métier
Point critique : un risque cyber devient prioritaire quand il touche un service essentiel, une donnée sensible, une identité à privilège, une obligation réglementaire ou une dépendance fournisseur difficile à remplacer.
| Risque | Impact typique |
|---|---|
| Équipement legacy non patchable | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Accès distant fournisseur mal contrôlé | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Réseau OT trop plat | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Protocoles non authentifiés | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Inventaire incomplet | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| IoT avec mots de passe par défaut | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
Scénario réaliste
Un prestataire de maintenance conserve un accès distant permanent vers une ligne de production. Son compte est compromis, puis l’attaquant accède à des systèmes de supervision. L’incident crée un risque d’arrêt industriel, pas seulement un incident informatique.
Chaîne d’attaque probable
Reconnaissance → accès initial → persistance → élévation → mouvement latéral → action sur objectif → extorsion / sabotage / fraude
Signaux faibles à surveiller
- Connexion inhabituelle ou impossible travel
- Volume anormal de lectures ou exports
- Création de compte, token ou règle de transfert
- Utilisation d’outils d’administration hors fenêtre
- Accès depuis IP, device ou pays atypique
- Modification de configuration sensible
Mesures de maîtrise
- Inventaire passif OT
- Segmentation IT/OT stricte
- Bastion fournisseur
- MFA et accès temporaires
- Monitoring industriel
- Sauvegarde configurations automates
- Gestion des changements
- Plan de réponse spécifique OT
- Tests hors production
Matrice prévention / détection / réponse
| Phase | Exemples |
|---|---|
| Prévenir | Réduire exposition, durcir configuration, limiter privilèges, former, automatiser les contrôles. |
| Détecter | Collecter logs utiles, créer use cases, surveiller comportements, corréler signaux. |
| Répondre | Isoler, révoquer, restaurer, communiquer, documenter, améliorer. |
Règle : aucun contrôle ne doit rester purement déclaratif. Il faut une preuve observable : configuration, log, rapport de test, ticket, capture, exercice ou métrique.
Indicateurs à suivre
- Actifs OT inventoriés
- Accès fournisseurs actifs
- Flux IT/OT autorisés
- Équipements avec mots de passe défaut
- Sauvegardes configurations testées
- Alertes réseau OT
- Exercices OT réalisés
Comment les interpréter
| Indicateur | Lecture |
|---|---|
| Actifs OT inventoriés | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Accès fournisseurs actifs | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Flux IT/OT autorisés | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Équipements avec mots de passe défaut | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Sauvegardes configurations testées | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Alertes réseau OT | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Exercices OT réalisés | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
Attention : un KPI sans seuil, sans propriétaire et sans décision associée devient vite décoratif.
Plan d’action concret
- Cartographier actifs et flux OT
- Identifier accès fournisseurs
- Créer zone démilitarisée OT
- Mettre bastion et MFA
- Collecter logs sans perturber production
- Définir procédures d’arrêt sûr
- Tester restauration configurations
Livrables attendus
- Cartographie ou registre mis à jour
- Liste des décisions et propriétaires
- Actions priorisées avec échéance
- Preuves de configuration ou de test
- Indicateurs de suivi
- Retour d’expérience après exercice ou incident
Le playbook doit pouvoir être exécuté par une équipe réelle, pas seulement compris par un expert sécurité.
Échelle de maturité
| Niveau | Description |
|---|---|
| Niveau 1 — réactif | Contrôles ponctuels, dépendance aux personnes, preuves faibles, actions après incident. |
| Niveau 2 — structuré | Actifs et responsabilités définis, contrôles prioritaires, logs et procédures minimales. |
| Niveau 3 — piloté | KPI/KRI, automatisation partielle, revues périodiques, exercices et amélioration continue. |
| Niveau 4 — résilient | Mesure du risque, tests réguliers, détection avancée, réponse orchestrée, culture intégrée. |
Quick wins
- Nommer un owner
- Documenter le périmètre
- Activer logs
- Supprimer l’exposition inutile
Industrialisation
- Automatiser contrôles
- Définir SLA
- Créer preuves
- Tester régulièrement
Excellence
- Mesurer réduction de risque
- Simuler incidents
- Adapter aux menaces
- Améliorer par RETEX
Questions de cadrage à poser en atelier
- Qui est propriétaire de cet enjeu : métier, IT, sécurité, juridique ou direction ?
- Quel actif ou processus serait le plus touché si ce domaine échouait demain ?
- Quelles preuves montrent que les contrôles fonctionnent réellement ?
- Quel incident réaliste permettrait de tester ce domaine en moins de 2 heures ?
- Quelles exceptions existent et qui accepte le risque résiduel ?
- Quel indicateur simple permet de suivre la progression mois après mois ?
Atelier recommandé : 45 minutes avec métier + IT + sécurité. Objectif : sortir avec 5 décisions, 5 actions et 5 preuves attendues.
📡 Détection, SOC, SIEM & CTI
Positionnement.
Logs, use cases, SIEM, SOAR, XDR, threat intelligence, détection engineering et qualité des alertes.
Logs, use cases, SIEM, SOAR, XDR, threat intelligence, détection engineering et qualité des alertes.
La détection transforme les signaux du SI en alertes exploitables : authentifications, endpoints, réseau, cloud, DNS, emails, applications, APIs, bases de données et outils d’administration.
Un SOC mature ne se contente pas d’accumuler des logs : il définit des cas d’usage, mesure leur efficacité, réduit les faux positifs, relie aux menaces réelles et industrialise la réponse.
La threat intelligence doit être actionnable : indicateurs, tactiques, techniques, comportements, secteurs ciblés et hypothèses de détection.
Lecture synthétique
| Axe | Détail |
|---|---|
| Ce qu’il faut protéger | Actifs, données, identités, processus, réputation, continuité. |
| Ce qu’il faut décider | Priorités, risques acceptés, moyens, responsabilités, preuves attendues. |
| Ce qu’il faut mesurer | Couverture, délai, qualité de détection, efficacité de réponse, impact résiduel. |
Risques principaux
- Logs non collectés sur actifs critiques
- Alertes trop nombreuses ou inutiles
- Absence de détection cloud/IAM
- Use cases non testés
- IoC statiques sans contexte
- SOAR automatisant de mauvais signaux
- Pas de mesure du temps de détection
Lecture impact métier
Point critique : un risque cyber devient prioritaire quand il touche un service essentiel, une donnée sensible, une identité à privilège, une obligation réglementaire ou une dépendance fournisseur difficile à remplacer.
| Risque | Impact typique |
|---|---|
| Logs non collectés sur actifs critiques | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Alertes trop nombreuses ou inutiles | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Absence de détection cloud/IAM | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Use cases non testés | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| IoC statiques sans contexte | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| SOAR automatisant de mauvais signaux | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
Scénario réaliste
L’entreprise a un SIEM coûteux, mais ne collecte pas les logs de l’IdP ni du cloud. Lors d’un vol de compte, les signaux existent dans les consoles fournisseurs mais ne sont jamais corrélés.
Chaîne d’attaque probable
Reconnaissance → accès initial → persistance → élévation → mouvement latéral → action sur objectif → extorsion / sabotage / fraude
Signaux faibles à surveiller
- Connexion inhabituelle ou impossible travel
- Volume anormal de lectures ou exports
- Création de compte, token ou règle de transfert
- Utilisation d’outils d’administration hors fenêtre
- Accès depuis IP, device ou pays atypique
- Modification de configuration sensible
Mesures de maîtrise
- Stratégie de logging priorisée
- Use cases alignés MITRE ATT&CK
- Détection IAM/cloud
- EDR/XDR intégré
- Threat hunting périodique
- Tuning faux positifs
- SOAR pour actions répétables
- Tests purple team
- Journalisation API
Matrice prévention / détection / réponse
| Phase | Exemples |
|---|---|
| Prévenir | Réduire exposition, durcir configuration, limiter privilèges, former, automatiser les contrôles. |
| Détecter | Collecter logs utiles, créer use cases, surveiller comportements, corréler signaux. |
| Répondre | Isoler, révoquer, restaurer, communiquer, documenter, améliorer. |
Règle : aucun contrôle ne doit rester purement déclaratif. Il faut une preuve observable : configuration, log, rapport de test, ticket, capture, exercice ou métrique.
Indicateurs à suivre
- Sources critiques connectées
- Use cases testés
- MTTD
- Faux positifs par règle
- Alertes non traitées
- Couverture ATT&CK
- Temps d’enrichissement
- Taux d’automatisation utile
Comment les interpréter
| Indicateur | Lecture |
|---|---|
| Sources critiques connectées | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Use cases testés | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| MTTD | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Faux positifs par règle | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Alertes non traitées | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Couverture ATT&CK | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Temps d’enrichissement | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
Attention : un KPI sans seuil, sans propriétaire et sans décision associée devient vite décoratif.
Plan d’action concret
- Lister incidents à détecter absolument
- Identifier logs nécessaires
- Écrire règles simples et testables
- Créer playbook triage
- Mesurer faux positifs
- Organiser un hunt mensuel
- Améliorer règles après chaque incident
Livrables attendus
- Cartographie ou registre mis à jour
- Liste des décisions et propriétaires
- Actions priorisées avec échéance
- Preuves de configuration ou de test
- Indicateurs de suivi
- Retour d’expérience après exercice ou incident
Le playbook doit pouvoir être exécuté par une équipe réelle, pas seulement compris par un expert sécurité.
Échelle de maturité
| Niveau | Description |
|---|---|
| Niveau 1 — réactif | Contrôles ponctuels, dépendance aux personnes, preuves faibles, actions après incident. |
| Niveau 2 — structuré | Actifs et responsabilités définis, contrôles prioritaires, logs et procédures minimales. |
| Niveau 3 — piloté | KPI/KRI, automatisation partielle, revues périodiques, exercices et amélioration continue. |
| Niveau 4 — résilient | Mesure du risque, tests réguliers, détection avancée, réponse orchestrée, culture intégrée. |
Quick wins
- Nommer un owner
- Documenter le périmètre
- Activer logs
- Supprimer l’exposition inutile
Industrialisation
- Automatiser contrôles
- Définir SLA
- Créer preuves
- Tester régulièrement
Excellence
- Mesurer réduction de risque
- Simuler incidents
- Adapter aux menaces
- Améliorer par RETEX
Questions de cadrage à poser en atelier
- Qui est propriétaire de cet enjeu : métier, IT, sécurité, juridique ou direction ?
- Quel actif ou processus serait le plus touché si ce domaine échouait demain ?
- Quelles preuves montrent que les contrôles fonctionnent réellement ?
- Quel incident réaliste permettrait de tester ce domaine en moins de 2 heures ?
- Quelles exceptions existent et qui accepte le risque résiduel ?
- Quel indicateur simple permet de suivre la progression mois après mois ?
Atelier recommandé : 45 minutes avec métier + IT + sécurité. Objectif : sortir avec 5 décisions, 5 actions et 5 preuves attendues.
🚨 Réponse à incident & gestion de crise
Positionnement.
Préparation, triage, containment, éradication, communication, preuves, juridique et retour d’expérience.
Préparation, triage, containment, éradication, communication, preuves, juridique et retour d’expérience.
La réponse à incident est une capacité organisationnelle, pas seulement une procédure technique. Elle réunit sécurité, IT, métiers, juridique, communication, direction, fournisseurs et parfois autorités.
Le premier enjeu est de décider vite sans détruire les preuves : qualifier, contenir, préserver, communiquer, restaurer et documenter.
Une crise cyber est souvent confuse : informations incomplètes, pression médiatique, équipes fatiguées, incertitudes juridiques et arbitrages métier.
Lecture synthétique
| Axe | Détail |
|---|---|
| Ce qu’il faut protéger | Actifs, données, identités, processus, réputation, continuité. |
| Ce qu’il faut décider | Priorités, risques acceptés, moyens, responsabilités, preuves attendues. |
| Ce qu’il faut mesurer | Couverture, délai, qualité de détection, efficacité de réponse, impact résiduel. |
Risques principaux
- Pas de cellule de crise définie
- Décisions improvisées
- Preuves effacées par remédiation précipitée
- Communication externe incohérente
- Dépendance à des contacts non disponibles
- Pas de registre des actions
- Retour d’expérience non appliqué
Lecture impact métier
Point critique : un risque cyber devient prioritaire quand il touche un service essentiel, une donnée sensible, une identité à privilège, une obligation réglementaire ou une dépendance fournisseur difficile à remplacer.
| Risque | Impact typique |
|---|---|
| Pas de cellule de crise définie | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Décisions improvisées | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Preuves effacées par remédiation précipitée | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Communication externe incohérente | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Dépendance à des contacts non disponibles | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Pas de registre des actions | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
Scénario réaliste
Une alerte EDR indique un mouvement latéral possible. L’équipe redémarre des machines pour “nettoyer”, mais détruit des artefacts utiles. Sans playbook, containment et forensic entrent en conflit.
Chaîne d’attaque probable
Reconnaissance → accès initial → persistance → élévation → mouvement latéral → action sur objectif → extorsion / sabotage / fraude
Signaux faibles à surveiller
- Connexion inhabituelle ou impossible travel
- Volume anormal de lectures ou exports
- Création de compte, token ou règle de transfert
- Utilisation d’outils d’administration hors fenêtre
- Accès depuis IP, device ou pays atypique
- Modification de configuration sensible
Mesures de maîtrise
- Plan IR testé
- Rôles cellule de crise
- Canal de crise hors SI principal
- Runbooks par scénario
- Préservation preuves
- Contacts prestataires/assureur/avocat
- Modèles de communication
- Post-mortem sans blâme
Matrice prévention / détection / réponse
| Phase | Exemples |
|---|---|
| Prévenir | Réduire exposition, durcir configuration, limiter privilèges, former, automatiser les contrôles. |
| Détecter | Collecter logs utiles, créer use cases, surveiller comportements, corréler signaux. |
| Répondre | Isoler, révoquer, restaurer, communiquer, documenter, améliorer. |
Règle : aucun contrôle ne doit rester purement déclaratif. Il faut une preuve observable : configuration, log, rapport de test, ticket, capture, exercice ou métrique.
Indicateurs à suivre
- Temps d’activation cellule
- Contacts de crise à jour
- Exercices réalisés
- Runbooks testés
- Actions IR tracées
- Temps de containment
- Leçons post-incident clôturées
Comment les interpréter
| Indicateur | Lecture |
|---|---|
| Temps d’activation cellule | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Contacts de crise à jour | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Exercices réalisés | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Runbooks testés | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Actions IR tracées | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Temps de containment | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Leçons post-incident clôturées | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
Attention : un KPI sans seuil, sans propriétaire et sans décision associée devient vite décoratif.
Plan d’action concret
- Déclarer incident et niveau de gravité
- Activer cellule adaptée
- Stabiliser et préserver preuves
- Contenir sans effacer inutilement
- Communiquer factuellement
- Restaurer par priorités métier
- Réaliser retour d’expérience avec actions
Livrables attendus
- Cartographie ou registre mis à jour
- Liste des décisions et propriétaires
- Actions priorisées avec échéance
- Preuves de configuration ou de test
- Indicateurs de suivi
- Retour d’expérience après exercice ou incident
Le playbook doit pouvoir être exécuté par une équipe réelle, pas seulement compris par un expert sécurité.
Échelle de maturité
| Niveau | Description |
|---|---|
| Niveau 1 — réactif | Contrôles ponctuels, dépendance aux personnes, preuves faibles, actions après incident. |
| Niveau 2 — structuré | Actifs et responsabilités définis, contrôles prioritaires, logs et procédures minimales. |
| Niveau 3 — piloté | KPI/KRI, automatisation partielle, revues périodiques, exercices et amélioration continue. |
| Niveau 4 — résilient | Mesure du risque, tests réguliers, détection avancée, réponse orchestrée, culture intégrée. |
Quick wins
- Nommer un owner
- Documenter le périmètre
- Activer logs
- Supprimer l’exposition inutile
Industrialisation
- Automatiser contrôles
- Définir SLA
- Créer preuves
- Tester régulièrement
Excellence
- Mesurer réduction de risque
- Simuler incidents
- Adapter aux menaces
- Améliorer par RETEX
Questions de cadrage à poser en atelier
- Qui est propriétaire de cet enjeu : métier, IT, sécurité, juridique ou direction ?
- Quel actif ou processus serait le plus touché si ce domaine échouait demain ?
- Quelles preuves montrent que les contrôles fonctionnent réellement ?
- Quel incident réaliste permettrait de tester ce domaine en moins de 2 heures ?
- Quelles exceptions existent et qui accepte le risque résiduel ?
- Quel indicateur simple permet de suivre la progression mois après mois ?
Atelier recommandé : 45 minutes avec métier + IT + sécurité. Objectif : sortir avec 5 décisions, 5 actions et 5 preuves attendues.
🛟 Résilience, PRA/PCA & continuité
Positionnement.
RTO/RPO, sauvegardes, restauration, modes dégradés, dépendances critiques et exercices réalistes.
RTO/RPO, sauvegardes, restauration, modes dégradés, dépendances critiques et exercices réalistes.
La résilience cyber reconnaît que certains incidents réussiront. L’enjeu devient alors de maintenir ou restaurer les fonctions vitales dans des délais acceptables.
RTO et RPO ne doivent pas rester des sigles théoriques : ils doivent être définis par service critique, testés et reliés aux sauvegardes, dépendances et ressources humaines.
Les modes dégradés sont essentiels : comment facturer, livrer, communiquer ou produire quand un système central est indisponible ?
Lecture synthétique
| Axe | Détail |
|---|---|
| Ce qu’il faut protéger | Actifs, données, identités, processus, réputation, continuité. |
| Ce qu’il faut décider | Priorités, risques acceptés, moyens, responsabilités, preuves attendues. |
| Ce qu’il faut mesurer | Couverture, délai, qualité de détection, efficacité de réponse, impact résiduel. |
Risques principaux
- Sauvegardes non restaurables
- RTO irréalistes
- PCA non connu des métiers
- Dépendance à un seul fournisseur
- Pas de procédure papier ou alternative
- Restauration sans priorités
- Backups compromis avec production
Lecture impact métier
Point critique : un risque cyber devient prioritaire quand il touche un service essentiel, une donnée sensible, une identité à privilège, une obligation réglementaire ou une dépendance fournisseur difficile à remplacer.
| Risque | Impact typique |
|---|---|
| Sauvegardes non restaurables | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| RTO irréalistes | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| PCA non connu des métiers | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Dépendance à un seul fournisseur | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Pas de procédure papier ou alternative | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Restauration sans priorités | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
Scénario réaliste
Le CRM est indisponible 48h. La sauvegarde existe, mais la restauration complète prend 5 jours, l’équipe ne sait pas quelles données restaurer en priorité et les commerciaux n’ont aucun mode dégradé documenté.
Chaîne d’attaque probable
Reconnaissance → accès initial → persistance → élévation → mouvement latéral → action sur objectif → extorsion / sabotage / fraude
Signaux faibles à surveiller
- Connexion inhabituelle ou impossible travel
- Volume anormal de lectures ou exports
- Création de compte, token ou règle de transfert
- Utilisation d’outils d’administration hors fenêtre
- Accès depuis IP, device ou pays atypique
- Modification de configuration sensible
Mesures de maîtrise
- Analyse d’impact métier BIA
- RTO/RPO par service
- Backups isolés/immutables
- Tests de restauration
- Modes dégradés
- Plan de communication clients
- Priorisation de reprise
- Redondance fournisseurs critiques
Matrice prévention / détection / réponse
| Phase | Exemples |
|---|---|
| Prévenir | Réduire exposition, durcir configuration, limiter privilèges, former, automatiser les contrôles. |
| Détecter | Collecter logs utiles, créer use cases, surveiller comportements, corréler signaux. |
| Répondre | Isoler, révoquer, restaurer, communiquer, documenter, améliorer. |
Règle : aucun contrôle ne doit rester purement déclaratif. Il faut une preuve observable : configuration, log, rapport de test, ticket, capture, exercice ou métrique.
Indicateurs à suivre
- Services avec RTO/RPO validés
- Tests de restauration réussis
- Temps réel de restauration
- Écart RTO vs réalité
- Backups immutables
- PCA connu des métiers
- Dépendances critiques sans alternative
Comment les interpréter
| Indicateur | Lecture |
|---|---|
| Services avec RTO/RPO validés | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Tests de restauration réussis | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Temps réel de restauration | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Écart RTO vs réalité | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Backups immutables | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| PCA connu des métiers | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Dépendances critiques sans alternative | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
Attention : un KPI sans seuil, sans propriétaire et sans décision associée devient vite décoratif.
Plan d’action concret
- Identifier 10 processus vitaux
- Définir RTO/RPO métier
- Tester restauration sans prévenir largement
- Documenter mode dégradé
- Prioriser ordre de reprise
- Faire exercice annuel transverse
Livrables attendus
- Cartographie ou registre mis à jour
- Liste des décisions et propriétaires
- Actions priorisées avec échéance
- Preuves de configuration ou de test
- Indicateurs de suivi
- Retour d’expérience après exercice ou incident
Le playbook doit pouvoir être exécuté par une équipe réelle, pas seulement compris par un expert sécurité.
Échelle de maturité
| Niveau | Description |
|---|---|
| Niveau 1 — réactif | Contrôles ponctuels, dépendance aux personnes, preuves faibles, actions après incident. |
| Niveau 2 — structuré | Actifs et responsabilités définis, contrôles prioritaires, logs et procédures minimales. |
| Niveau 3 — piloté | KPI/KRI, automatisation partielle, revues périodiques, exercices et amélioration continue. |
| Niveau 4 — résilient | Mesure du risque, tests réguliers, détection avancée, réponse orchestrée, culture intégrée. |
Quick wins
- Nommer un owner
- Documenter le périmètre
- Activer logs
- Supprimer l’exposition inutile
Industrialisation
- Automatiser contrôles
- Définir SLA
- Créer preuves
- Tester régulièrement
Excellence
- Mesurer réduction de risque
- Simuler incidents
- Adapter aux menaces
- Améliorer par RETEX
Questions de cadrage à poser en atelier
- Qui est propriétaire de cet enjeu : métier, IT, sécurité, juridique ou direction ?
- Quel actif ou processus serait le plus touché si ce domaine échouait demain ?
- Quelles preuves montrent que les contrôles fonctionnent réellement ?
- Quel incident réaliste permettrait de tester ce domaine en moins de 2 heures ?
- Quelles exceptions existent et qui accepte le risque résiduel ?
- Quel indicateur simple permet de suivre la progression mois après mois ?
Atelier recommandé : 45 minutes avec métier + IT + sécurité. Objectif : sortir avec 5 décisions, 5 actions et 5 preuves attendues.
📜 Conformité, NIS2, DORA, RGPD
Positionnement.
Obligations européennes, preuves, notification, gouvernance, résilience, données personnelles et relation juridique.
Obligations européennes, preuves, notification, gouvernance, résilience, données personnelles et relation juridique.
La conformité ne remplace pas la sécurité, mais elle impose des exigences de gouvernance, de preuve, de notification, de responsabilité et de maîtrise des risques.
En Europe, NIS2 élargit le niveau d’exigence cyber pour de nombreux secteurs critiques ou importants, tandis que DORA encadre la résilience opérationnelle numérique du secteur financier.
Le RGPD impose une attention particulière aux violations de données personnelles : qualification, notification, information des personnes selon le risque, documentation et relation avec les sous-traitants.
Lecture synthétique
| Axe | Détail |
|---|---|
| Ce qu’il faut protéger | Actifs, données, identités, processus, réputation, continuité. |
| Ce qu’il faut décider | Priorités, risques acceptés, moyens, responsabilités, preuves attendues. |
| Ce qu’il faut mesurer | Couverture, délai, qualité de détection, efficacité de réponse, impact résiduel. |
Risques principaux
- Confusion conformité = sécurité réelle
- Absence de preuves auditables
- Incident non notifié dans les temps
- Contrats fournisseurs incomplets
- Registre de traitement non aligné avec réalité
- Risques tiers mal suivis
- Direction non impliquée
Lecture impact métier
Point critique : un risque cyber devient prioritaire quand il touche un service essentiel, une donnée sensible, une identité à privilège, une obligation réglementaire ou une dépendance fournisseur difficile à remplacer.
| Risque | Impact typique |
|---|---|
| Confusion conformité = sécurité réelle | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Absence de preuves auditables | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Incident non notifié dans les temps | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Contrats fournisseurs incomplets | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Registre de traitement non aligné avec réalité | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Risques tiers mal suivis | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
Scénario réaliste
Un incident expose des données personnelles via un prestataire. L’organisation découvre que le contrat ne précise pas correctement les délais de notification, que le registre des traitements est incomplet et que la preuve des mesures de sécurité est dispersée.
Chaîne d’attaque probable
Reconnaissance → accès initial → persistance → élévation → mouvement latéral → action sur objectif → extorsion / sabotage / fraude
Signaux faibles à surveiller
- Connexion inhabituelle ou impossible travel
- Volume anormal de lectures ou exports
- Création de compte, token ou règle de transfert
- Utilisation d’outils d’administration hors fenêtre
- Accès depuis IP, device ou pays atypique
- Modification de configuration sensible
Mesures de maîtrise
- Cartographie obligations applicables
- Registre de preuves
- Processus notification incident
- Clauses sécurité fournisseurs
- Gouvernance direction
- Tests de résilience
- DPIA/PIA si nécessaire
- Lien GRC-juridique-DPO-RSSI
Matrice prévention / détection / réponse
| Phase | Exemples |
|---|---|
| Prévenir | Réduire exposition, durcir configuration, limiter privilèges, former, automatiser les contrôles. |
| Détecter | Collecter logs utiles, créer use cases, surveiller comportements, corréler signaux. |
| Répondre | Isoler, révoquer, restaurer, communiquer, documenter, améliorer. |
Règle : aucun contrôle ne doit rester purement déclaratif. Il faut une preuve observable : configuration, log, rapport de test, ticket, capture, exercice ou métrique.
Indicateurs à suivre
- Obligations sans propriétaire
- Preuves manquantes
- Contrats critiques sans clauses cyber
- Exercices de notification
- Incidents qualifiés RGPD
- Actions audit ouvertes
- Risques tiers non réévalués
Comment les interpréter
| Indicateur | Lecture |
|---|---|
| Obligations sans propriétaire | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Preuves manquantes | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Contrats critiques sans clauses cyber | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Exercices de notification | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Incidents qualifiés RGPD | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Actions audit ouvertes | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Risques tiers non réévalués | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
Attention : un KPI sans seuil, sans propriétaire et sans décision associée devient vite décoratif.
Plan d’action concret
- Identifier périmètre légal applicable
- Nommer propriétaires conformité
- Relier obligations à contrôles techniques
- Préparer modèles notification
- Tester un incident fictif
- Centraliser preuves
- Réviser contrats critiques
Livrables attendus
- Cartographie ou registre mis à jour
- Liste des décisions et propriétaires
- Actions priorisées avec échéance
- Preuves de configuration ou de test
- Indicateurs de suivi
- Retour d’expérience après exercice ou incident
Le playbook doit pouvoir être exécuté par une équipe réelle, pas seulement compris par un expert sécurité.
Échelle de maturité
| Niveau | Description |
|---|---|
| Niveau 1 — réactif | Contrôles ponctuels, dépendance aux personnes, preuves faibles, actions après incident. |
| Niveau 2 — structuré | Actifs et responsabilités définis, contrôles prioritaires, logs et procédures minimales. |
| Niveau 3 — piloté | KPI/KRI, automatisation partielle, revues périodiques, exercices et amélioration continue. |
| Niveau 4 — résilient | Mesure du risque, tests réguliers, détection avancée, réponse orchestrée, culture intégrée. |
Quick wins
- Nommer un owner
- Documenter le périmètre
- Activer logs
- Supprimer l’exposition inutile
Industrialisation
- Automatiser contrôles
- Définir SLA
- Créer preuves
- Tester régulièrement
Excellence
- Mesurer réduction de risque
- Simuler incidents
- Adapter aux menaces
- Améliorer par RETEX
Questions de cadrage à poser en atelier
- Qui est propriétaire de cet enjeu : métier, IT, sécurité, juridique ou direction ?
- Quel actif ou processus serait le plus touché si ce domaine échouait demain ?
- Quelles preuves montrent que les contrôles fonctionnent réellement ?
- Quel incident réaliste permettrait de tester ce domaine en moins de 2 heures ?
- Quelles exceptions existent et qui accepte le risque résiduel ?
- Quel indicateur simple permet de suivre la progression mois après mois ?
Atelier recommandé : 45 minutes avec métier + IT + sécurité. Objectif : sortir avec 5 décisions, 5 actions et 5 preuves attendues.
📊 Métriques, tableaux de bord & pilotage
Positionnement.
Mesurer la réduction du risque, la maturité, la couverture, les délais, les incidents et l’efficacité des contrôles.
Mesurer la réduction du risque, la maturité, la couverture, les délais, les incidents et l’efficacité des contrôles.
Une cybersécurité non mesurée devient vite une collection d’opinions. Les métriques doivent aider à décider, prioriser et améliorer, pas seulement produire des graphiques.
Il faut distinguer KPI opérationnels, KRI de risque, métriques de conformité et indicateurs exécutifs. Trop d’indicateurs tue la lisibilité.
Les bons tableaux de bord montrent les tendances, les écarts, les priorités et les décisions attendues.
Lecture synthétique
| Axe | Détail |
|---|---|
| Ce qu’il faut protéger | Actifs, données, identités, processus, réputation, continuité. |
| Ce qu’il faut décider | Priorités, risques acceptés, moyens, responsabilités, preuves attendues. |
| Ce qu’il faut mesurer | Couverture, délai, qualité de détection, efficacité de réponse, impact résiduel. |
Risques principaux
- Vanity metrics sans décision
- Tableaux trop techniques pour la direction
- Absence de tendance historique
- Indicateurs manipulables
- Pas de seuils d’alerte
- Métriques isolées sans owner
- Focalisation sur quantité d’alertes plutôt que risque
Lecture impact métier
Point critique : un risque cyber devient prioritaire quand il touche un service essentiel, une donnée sensible, une identité à privilège, une obligation réglementaire ou une dépendance fournisseur difficile à remplacer.
| Risque | Impact typique |
|---|---|
| Vanity metrics sans décision | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Tableaux trop techniques pour la direction | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Absence de tendance historique | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Indicateurs manipulables | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Pas de seuils d’alerte | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Métriques isolées sans owner | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
Scénario réaliste
Le SOC annonce 20 000 alertes traitées, mais la direction ne sait pas si le risque diminue. En reformulant autour du temps de détection, couverture des actifs critiques, incidents évités, vulnérabilités exposées et restauration testée, le dashboard devient utile.
Chaîne d’attaque probable
Reconnaissance → accès initial → persistance → élévation → mouvement latéral → action sur objectif → extorsion / sabotage / fraude
Signaux faibles à surveiller
- Connexion inhabituelle ou impossible travel
- Volume anormal de lectures ou exports
- Création de compte, token ou règle de transfert
- Utilisation d’outils d’administration hors fenêtre
- Accès depuis IP, device ou pays atypique
- Modification de configuration sensible
Mesures de maîtrise
- Définir audience par dashboard
- Limiter indicateurs clés
- Associer chaque KPI à une action
- Mesurer couverture, délai, qualité
- Suivre tendances
- Relier métriques aux risques
- Revue mensuelle décisionnelle
Matrice prévention / détection / réponse
| Phase | Exemples |
|---|---|
| Prévenir | Réduire exposition, durcir configuration, limiter privilèges, former, automatiser les contrôles. |
| Détecter | Collecter logs utiles, créer use cases, surveiller comportements, corréler signaux. |
| Répondre | Isoler, révoquer, restaurer, communiquer, documenter, améliorer. |
Règle : aucun contrôle ne doit rester purement déclaratif. Il faut une preuve observable : configuration, log, rapport de test, ticket, capture, exercice ou métrique.
Indicateurs à suivre
- MTTD/MTTR
- Couverture EDR/MFA/logs
- Vulnérabilités critiques exposées
- Restauration testée
- Incidents par cause racine
- Exceptions expirées
- Actions de réduction du risque clôturées
Comment les interpréter
| Indicateur | Lecture |
|---|---|
| MTTD/MTTR | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Couverture EDR/MFA/logs | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Vulnérabilités critiques exposées | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Restauration testée | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Incidents par cause racine | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Exceptions expirées | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Actions de réduction du risque clôturées | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
Attention : un KPI sans seuil, sans propriétaire et sans décision associée devient vite décoratif.
Plan d’action concret
- Créer dashboard direction 1 page
- Créer dashboard opérationnel par domaine
- Définir seuils rouge/orange/vert
- Supprimer indicateurs inutiles
- Associer action à chaque alerte rouge
- Revoir mensuellement la tendance
Livrables attendus
- Cartographie ou registre mis à jour
- Liste des décisions et propriétaires
- Actions priorisées avec échéance
- Preuves de configuration ou de test
- Indicateurs de suivi
- Retour d’expérience après exercice ou incident
Le playbook doit pouvoir être exécuté par une équipe réelle, pas seulement compris par un expert sécurité.
Échelle de maturité
| Niveau | Description |
|---|---|
| Niveau 1 — réactif | Contrôles ponctuels, dépendance aux personnes, preuves faibles, actions après incident. |
| Niveau 2 — structuré | Actifs et responsabilités définis, contrôles prioritaires, logs et procédures minimales. |
| Niveau 3 — piloté | KPI/KRI, automatisation partielle, revues périodiques, exercices et amélioration continue. |
| Niveau 4 — résilient | Mesure du risque, tests réguliers, détection avancée, réponse orchestrée, culture intégrée. |
Quick wins
- Nommer un owner
- Documenter le périmètre
- Activer logs
- Supprimer l’exposition inutile
Industrialisation
- Automatiser contrôles
- Définir SLA
- Créer preuves
- Tester régulièrement
Excellence
- Mesurer réduction de risque
- Simuler incidents
- Adapter aux menaces
- Améliorer par RETEX
Questions de cadrage à poser en atelier
- Qui est propriétaire de cet enjeu : métier, IT, sécurité, juridique ou direction ?
- Quel actif ou processus serait le plus touché si ce domaine échouait demain ?
- Quelles preuves montrent que les contrôles fonctionnent réellement ?
- Quel incident réaliste permettrait de tester ce domaine en moins de 2 heures ?
- Quelles exceptions existent et qui accepte le risque résiduel ?
- Quel indicateur simple permet de suivre la progression mois après mois ?
Atelier recommandé : 45 minutes avec métier + IT + sécurité. Objectif : sortir avec 5 décisions, 5 actions et 5 preuves attendues.
🗓️ Roadmap 30/60/90 jours
Positionnement.
Plan d’action concret pour structurer rapidement une démarche cyber pragmatique et progressive.
Plan d’action concret pour structurer rapidement une démarche cyber pragmatique et progressive.
Une roadmap cyber efficace commence par les fondamentaux : actifs, identités, sauvegardes, exposition, vulnérabilités critiques, logs et responsabilités.
Les 30 premiers jours visent la visibilité et les risques évidents. Les 60 jours stabilisent les contrôles prioritaires. Les 90 jours installent la gouvernance, les tests et l’amélioration continue.
La roadmap doit rester réaliste : mieux vaut dix actions critiques terminées que cinquante chantiers ouverts sans preuve.
Lecture synthétique
| Axe | Détail |
|---|---|
| Ce qu’il faut protéger | Actifs, données, identités, processus, réputation, continuité. |
| Ce qu’il faut décider | Priorités, risques acceptés, moyens, responsabilités, preuves attendues. |
| Ce qu’il faut mesurer | Couverture, délai, qualité de détection, efficacité de réponse, impact résiduel. |
Risques principaux
- Programme trop ambitieux non exécuté
- Outils achetés avant diagnostic
- Actions non priorisées
- Pas de propriétaire
- Pas de preuves
- Quick wins non consolidés
- Dépendance à une seule personne
Lecture impact métier
Point critique : un risque cyber devient prioritaire quand il touche un service essentiel, une donnée sensible, une identité à privilège, une obligation réglementaire ou une dépendance fournisseur difficile à remplacer.
| Risque | Impact typique |
|---|---|
| Programme trop ambitieux non exécuté | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Outils achetés avant diagnostic | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Actions non priorisées | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Pas de propriétaire | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Pas de preuves | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Quick wins non consolidés | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
Scénario réaliste
Une entreprise veut “faire de la cybersécurité” mais hésite entre EDR, SIEM, pentest, ISO, MFA et sensibilisation. Une roadmap 90 jours permet de commencer par ce qui réduit vraiment le risque immédiat.
Chaîne d’attaque probable
Reconnaissance → accès initial → persistance → élévation → mouvement latéral → action sur objectif → extorsion / sabotage / fraude
Signaux faibles à surveiller
- Connexion inhabituelle ou impossible travel
- Volume anormal de lectures ou exports
- Création de compte, token ou règle de transfert
- Utilisation d’outils d’administration hors fenêtre
- Accès depuis IP, device ou pays atypique
- Modification de configuration sensible
Mesures de maîtrise
- 30 jours : inventaire, MFA admin, sauvegardes, exposition
- 60 jours : patching priorisé, logs, EDR, accès tiers
- 90 jours : playbooks IR, dashboard, exercices, politiques
- Responsables et preuves
- Révision hebdomadaire courte
Matrice prévention / détection / réponse
| Phase | Exemples |
|---|---|
| Prévenir | Réduire exposition, durcir configuration, limiter privilèges, former, automatiser les contrôles. |
| Détecter | Collecter logs utiles, créer use cases, surveiller comportements, corréler signaux. |
| Répondre | Isoler, révoquer, restaurer, communiquer, documenter, améliorer. |
Règle : aucun contrôle ne doit rester purement déclaratif. Il faut une preuve observable : configuration, log, rapport de test, ticket, capture, exercice ou métrique.
Indicateurs à suivre
- Actions 30 jours terminées
- Actifs critiques inventoriés
- Admins protégés MFA
- Backups restaurés
- Vulnérabilités critiques traitées
- Sources logs critiques
- Exercice IR réalisé
Comment les interpréter
| Indicateur | Lecture |
|---|---|
| Actions 30 jours terminées | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Actifs critiques inventoriés | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Admins protégés MFA | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Backups restaurés | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Vulnérabilités critiques traitées | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Sources logs critiques | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Exercice IR réalisé | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
Attention : un KPI sans seuil, sans propriétaire et sans décision associée devient vite décoratif.
Plan d’action concret
- Semaine 1 : cadrer risques et actifs critiques
- Semaine 2 : sécuriser identités prioritaires
- Semaine 3 : vérifier backups et exposition
- Semaine 4 : dashboard initial
- Jours 31-60 : durcir et superviser
- Jours 61-90 : tester, documenter, industrialiser
Livrables attendus
- Cartographie ou registre mis à jour
- Liste des décisions et propriétaires
- Actions priorisées avec échéance
- Preuves de configuration ou de test
- Indicateurs de suivi
- Retour d’expérience après exercice ou incident
Le playbook doit pouvoir être exécuté par une équipe réelle, pas seulement compris par un expert sécurité.
Échelle de maturité
| Niveau | Description |
|---|---|
| Niveau 1 — réactif | Contrôles ponctuels, dépendance aux personnes, preuves faibles, actions après incident. |
| Niveau 2 — structuré | Actifs et responsabilités définis, contrôles prioritaires, logs et procédures minimales. |
| Niveau 3 — piloté | KPI/KRI, automatisation partielle, revues périodiques, exercices et amélioration continue. |
| Niveau 4 — résilient | Mesure du risque, tests réguliers, détection avancée, réponse orchestrée, culture intégrée. |
Quick wins
- Nommer un owner
- Documenter le périmètre
- Activer logs
- Supprimer l’exposition inutile
Industrialisation
- Automatiser contrôles
- Définir SLA
- Créer preuves
- Tester régulièrement
Excellence
- Mesurer réduction de risque
- Simuler incidents
- Adapter aux menaces
- Améliorer par RETEX
Questions de cadrage à poser en atelier
- Qui est propriétaire de cet enjeu : métier, IT, sécurité, juridique ou direction ?
- Quel actif ou processus serait le plus touché si ce domaine échouait demain ?
- Quelles preuves montrent que les contrôles fonctionnent réellement ?
- Quel incident réaliste permettrait de tester ce domaine en moins de 2 heures ?
- Quelles exceptions existent et qui accepte le risque résiduel ?
- Quel indicateur simple permet de suivre la progression mois après mois ?
Atelier recommandé : 45 minutes avec métier + IT + sécurité. Objectif : sortir avec 5 décisions, 5 actions et 5 preuves attendues.
🧪 Cas pratiques & exercices
Positionnement.
Scénarios réalistes pour former, tester les contrôles, entraîner la crise et améliorer les réflexes.
Scénarios réalistes pour former, tester les contrôles, entraîner la crise et améliorer les réflexes.
Les exercices transforment une politique en réflexes. Ils révèlent les dépendances cachées, les contacts obsolètes, les procédures floues et les hypothèses irréalistes.
Un bon exercice est concret, limité dans le temps, orienté décision, non punitif et suivi d’actions de correction.
Les scénarios doivent couvrir phishing, ransomware, fuite de données, compte cloud compromis, API exploitée, fournisseur attaqué et indisponibilité d’un service critique.
Lecture synthétique
| Axe | Détail |
|---|---|
| Ce qu’il faut protéger | Actifs, données, identités, processus, réputation, continuité. |
| Ce qu’il faut décider | Priorités, risques acceptés, moyens, responsabilités, preuves attendues. |
| Ce qu’il faut mesurer | Couverture, délai, qualité de détection, efficacité de réponse, impact résiduel. |
Risques principaux
- Plans jamais testés
- Équipes surprises par rôles de crise
- Canaux de communication indisponibles
- Décisions lentes
- Absence de preuves post-exercice
- Scénarios trop théoriques
- Corrections non suivies
Lecture impact métier
Point critique : un risque cyber devient prioritaire quand il touche un service essentiel, une donnée sensible, une identité à privilège, une obligation réglementaire ou une dépendance fournisseur difficile à remplacer.
| Risque | Impact typique |
|---|---|
| Plans jamais testés | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Équipes surprises par rôles de crise | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Canaux de communication indisponibles | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Décisions lentes | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Absence de preuves post-exercice | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
| Scénarios trop théoriques | Impact possible : interruption, perte de données, fraude, sanction, réputation, coût opérationnel. |
Scénario réaliste
Pendant un exercice tabletop, on simule la compromission d’un compte administrateur cloud. L’équipe découvre qu’elle ne sait pas rapidement révoquer toutes les sessions, lister les tokens actifs, isoler un compte cloud et communiquer avec les métiers.
Chaîne d’attaque probable
Reconnaissance → accès initial → persistance → élévation → mouvement latéral → action sur objectif → extorsion / sabotage / fraude
Signaux faibles à surveiller
- Connexion inhabituelle ou impossible travel
- Volume anormal de lectures ou exports
- Création de compte, token ou règle de transfert
- Utilisation d’outils d’administration hors fenêtre
- Accès depuis IP, device ou pays atypique
- Modification de configuration sensible
Mesures de maîtrise
- Tabletop trimestriel
- Tests techniques ciblés
- Purple team léger
- Simulations phishing
- Restauration réelle
- Exercice fournisseur
- Post-mortem et actions
- Mesure de temps de décision
Matrice prévention / détection / réponse
| Phase | Exemples |
|---|---|
| Prévenir | Réduire exposition, durcir configuration, limiter privilèges, former, automatiser les contrôles. |
| Détecter | Collecter logs utiles, créer use cases, surveiller comportements, corréler signaux. |
| Répondre | Isoler, révoquer, restaurer, communiquer, documenter, améliorer. |
Règle : aucun contrôle ne doit rester purement déclaratif. Il faut une preuve observable : configuration, log, rapport de test, ticket, capture, exercice ou métrique.
Indicateurs à suivre
- Exercices réalisés
- Actions post-exercice clôturées
- Temps de mobilisation
- Temps de révocation accès
- Temps de restauration
- Participation métiers
- Lacunes récurrentes
Comment les interpréter
| Indicateur | Lecture |
|---|---|
| Exercices réalisés | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Actions post-exercice clôturées | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Temps de mobilisation | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Temps de révocation accès | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Temps de restauration | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Participation métiers | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
| Lacunes récurrentes | Vert si couvert et testé ; orange si partiel ; rouge si inconnu, non propriétaire ou non testé. |
Attention : un KPI sans seuil, sans propriétaire et sans décision associée devient vite décoratif.
Plan d’action concret
- Choisir scénario prioritaire
- Préparer injects réalistes
- Définir observateurs
- Jouer 2 heures maximum
- Noter décisions et blocages
- Produire plan d’action 10 points
- Rejouer après correction
Livrables attendus
- Cartographie ou registre mis à jour
- Liste des décisions et propriétaires
- Actions priorisées avec échéance
- Preuves de configuration ou de test
- Indicateurs de suivi
- Retour d’expérience après exercice ou incident
Le playbook doit pouvoir être exécuté par une équipe réelle, pas seulement compris par un expert sécurité.
Échelle de maturité
| Niveau | Description |
|---|---|
| Niveau 1 — réactif | Contrôles ponctuels, dépendance aux personnes, preuves faibles, actions après incident. |
| Niveau 2 — structuré | Actifs et responsabilités définis, contrôles prioritaires, logs et procédures minimales. |
| Niveau 3 — piloté | KPI/KRI, automatisation partielle, revues périodiques, exercices et amélioration continue. |
| Niveau 4 — résilient | Mesure du risque, tests réguliers, détection avancée, réponse orchestrée, culture intégrée. |
Quick wins
- Nommer un owner
- Documenter le périmètre
- Activer logs
- Supprimer l’exposition inutile
Industrialisation
- Automatiser contrôles
- Définir SLA
- Créer preuves
- Tester régulièrement
Excellence
- Mesurer réduction de risque
- Simuler incidents
- Adapter aux menaces
- Améliorer par RETEX
Questions de cadrage à poser en atelier
- Qui est propriétaire de cet enjeu : métier, IT, sécurité, juridique ou direction ?
- Quel actif ou processus serait le plus touché si ce domaine échouait demain ?
- Quelles preuves montrent que les contrôles fonctionnent réellement ?
- Quel incident réaliste permettrait de tester ce domaine en moins de 2 heures ?
- Quelles exceptions existent et qui accepte le risque résiduel ?
- Quel indicateur simple permet de suivre la progression mois après mois ?
Atelier recommandé : 45 minutes avec métier + IT + sécurité. Objectif : sortir avec 5 décisions, 5 actions et 5 preuves attendues.
🧾 Cheat-sheet — Cybersécurité : les enjeux
Formule centrale
Cyber = Risque métier + Risque technique + Risque humain + Risque fournisseur + Risque réglementaire
- La cybersécurité protège la confiance, la continuité, les données et la capacité d’agir.
- Le but n’est pas zéro incident, mais une exposition maîtrisée et une reprise rapide.
- Un bon programme cyber relie menaces, actifs, contrôles, preuves et décisions.
Triade et résilience
| Pilier | Sens |
|---|---|
| Confidentialité | Empêcher divulgation non autorisée |
| Intégrité | Empêcher modification frauduleuse ou erreur non détectée |
| Disponibilité | Maintenir services et données accessibles |
| Résilience | Continuer ou reprendre malgré incident |
Contrôles transverses
| Domaine | Exemples | Bénéfice |
|---|---|---|
| Inventaire | Actifs, comptes, SaaS, APIs, données, dépendances | Base de toute priorisation |
| Identité | MFA, SSO, PAM, moindre privilège, revues | Réduit vol de comptes et escalade |
| Protection | EDR, hardening, patch, chiffrement, segmentation | Réduit probabilité et blast radius |
| Détection | Logs, SIEM, XDR, use cases, CTI | Réduit le temps avant réaction |
| Réponse | Runbooks, cellule de crise, containment, forensic | Réduit durée et dégâts |
| Récupération | Backups, PRA/PCA, tests, modes dégradés | Réduit interruption métier |
Priorité 1
- MFA sur comptes critiques
- Sauvegardes testées
- Inventaire actifs exposés
- Correction vulnérabilités exploitées
Priorité 2
- EDR/XDR et logs critiques
- Revue accès tiers
- Segmentation
- Détection IAM/cloud
Priorité 3
- Threat modeling
- SBOM
- Exercices crise
- Tableaux de bord direction
Réflexe crise
Qualifier → Activer cellule → Contenir → Préserver preuves → Communiquer → Restaurer → RETEX
- Toujours garder un canal de communication hors SI principal.
- Ne pas effacer les preuves par remédiation précipitée.
- Prioriser la restauration par impact métier, pas par ordre technique historique.
- Documenter toutes les décisions importantes.
Questions à poser à la direction
- Quels services ne peuvent pas être arrêtés plus de 24h ?
- Quelles données exposées créeraient une crise majeure ?
- Quels risques cyber sommes-nous prêts à accepter formellement ?
- Quels fournisseurs peuvent interrompre notre activité ?
- Avons-nous déjà restauré réellement nos systèmes critiques ?
- Qui parle aux clients, autorités, presse et partenaires en cas de crise ?
📚 Références & cadres utilisés
Note : ce guide est pédagogique. Les obligations légales exactes doivent être confirmées avec les équipes juridiques, DPO, conformité ou conseil spécialisé selon le pays, le secteur et le statut de l’organisation.
| Référence | URL | Utilité dans le guide |
|---|---|---|
| NIST Cybersecurity Framework 2.0 | https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf | Gouvernance, identification, protection, détection, réponse, récupération. |
| ENISA Threat Landscape 2025 | https://www.enisa.europa.eu/publications/enisa-threat-landscape-2025 | Tendances de menace, incidents, ciblage des infrastructures numériques européennes. |
| CISA Secure by Design | https://www.cisa.gov/securebydesign | Responsabilité des éditeurs, réduction des défauts par conception, sécurité produit. |
| OWASP Top 10:2025 | https://owasp.org/Top10/2025/0x00_2025-Introduction/ | Risques applicatifs Web majeurs, document de sensibilisation AppSec. |
| OWASP API Security Top 10 2023 | https://owasp.org/API-Security/editions/2023/en/0x11-t10/ | Risques API : BOLA, authentification, autorisation, inventaire, consommation non restreinte. |
| CIS Controls v8 | https://www.cisecurity.org/controls/v8 | Contrôles priorisés pour hygiène cyber, inventaire, vulnérabilités, accès, monitoring. |
| Directive NIS2 — Commission européenne | https://digital-strategy.ec.europa.eu/en/policies/nis2-directive | Cadre européen de cybersécurité pour secteurs critiques et entités importantes. |
| DORA — Regulation (EU) 2022/2554 | https://eur-lex.europa.eu/eli/reg/2022/2554/oj | Résilience opérationnelle numérique du secteur financier. |
| GDPR breach notification — European Commission | https://commission.europa.eu/law/law-topic/data-protection/rules-business-and-organisations/obligations/what-data-breach-and-what-do-we-have-do-case-data-breach_en | Notification des violations de données personnelles et responsabilités. |
Guide généré le 2026-07-07 — thème clair IDEO‑Lab — contenu pédagogique à adapter au contexte réel, aux risques sectoriels et aux exigences juridiques applicables.