2 Découverte et auto-évaluation

2.1.1. Métiers pertinents ¶

• Tous les métiers : point de départ commun avant de parler sécurité.
• Exemples : développeur, admin systèmes/réseau, chef de projet.

2.1.2. Déroulement ¶

• Noter de 1 à 5 mon niveau sur chaque thème.
• Recopier le tableau, puis le remplir pendant la séance.

2.1.2.1. Questions de synthèse ¶

Thème le plus à l'aise : le facteur humain (5/5). Je suis beaucoup d'histoires de hacking, et le constat revient sans cesse : phishing et ingénierie sociale restent la faille la plus simple, bien avant la technique pure.

Thème à progresser en priorité : le confinement OS et réseaux (2/5). Je connais mal le sandboxing et la segmentation, alors que le sujet m'intéresse ; c'est là que la marge de progrès est la plus grande.

Entreprise vs développement logiciel : la distinction est claire pour moi. L'entreprise intègre plus de variables humaines, donc plus de points d'attaque et de défense. Elle tient aussi compte des contraintes de gestion : ressources, budgets, activités, politique interne. Pour mon projet, il s'agit d'analyser les menaces et d'appliquer la sécurité à chaque étape du cycle de vie, avec un confinement adapté aux risques et impacts.

2.1.3. Résultats ¶

Profil déséquilibré entre culture et technique :

• 5 : facteur humain.
• 4 : enjeux généraux, cryptographie, conscience dev, veille, envie d'appliquer.
• 3 : théorie, pratique, réflexes de dev sécurisé, gestion des risques.
• 2 : confinement OS et réseaux, mon seul vrai trou.

En bref, je sais pourquoi on se fait attaquer, je sais moins comment cloisonner proprement.

2.1.4. Interprétation des résultats ¶

Mon point d'appui est la sensibilisation, avec le réflexe de me méfier du maillon humain. Mon chantier est le confinement : sandboxing, segmentation, moindre privilège. Pour le projet de semestre, je vise donc la confidentialité et l'intégrité par la technique, pas seulement par la vigilance. Je mesurerai le progrès en refaisant cette grille en fin de module.

2.2.1. Métiers pertinents ¶

• Tous les métiers : chaque rôle arbitre entre ces critères à son niveau.
• Exemples : développeur, administrateur, RSSI.

2.2.2. Déroulement ¶

Critères rappelés en cours, notés en vrac.

Critères principaux :

• Confidentialité
• Intégrité
• Disponibilité

Critères secondaires :

• Identification :
  • Responsable / traçabilité → non-répudiation / imputabilité
  • Accès
• Authentification
• Sensibilisation
• Résilience

2.2.3. Résultats ¶

Les trois critères principaux (confidentialité, intégrité, disponibilité) forment le triangle du schéma. Quatre critères secondaires l'entourent et le rendent applicable : l'identification (avec traçabilité et accès), l'authentification, la sensibilisation et la résilience.

2.2.4. Interprétation des résultats ¶

Les critères secondaires sont plus concrets que la triade seule. Côté développeur, authentification et traçabilité apparaissent dans chaque login et chaque journal. Côté admin, la résilience se joue dans les sauvegardes et la reprise après incident. Pour le projet de semestre, je justifierai chaque mesure par le critère qu'elle protège.

2.3.1. Métiers pertinents ¶

Tous les métiers sont concernés, avec un poids différent selon le cas :

• Banque : RSSI, analyste risques.
• AlertSwiss, streaming : administrateur réseau.
• E-commerce : développeur.

2.3.2. Déroulement ¶

• Noter de 1 à 4 (maximum) la confidentialité (C), l'intégrité (I) et la disponibilité (A) de chaque cas.
• Recopier le tableau, puis le remplir.

Justification des notes :

• E-commerce (3/3/3) : I et A sont élevés, car une commande modifiée ou une minute d'indisponibilité coûte directement de l'argent. C est à 3 : données clients et paiement, sans atteindre le niveau d'une banque.
• Banque en ligne (4/4/4) : C et I sont prioritaires (données financières, exactitude des opérations). A est aussi à 4 dans mon évaluation, car l'accès continu est attendu. Les contraintes légales influencent ces objectifs, sans imposer à elles seules la note maximale.
• AlertSwiss (1/4/4) : C est à 1, les messages étant publics. I est à 4, car une fausse alerte peut provoquer une panique. A est à 4, car le message doit passer en pleine crise.
• Streaming (2/2/4) : C et I sont à 2 (catalogue public, image corrompue peu coûteuse). A est à 4, car un service qui rame fait fuir les abonnés.

2.3.3. Résultats ¶

La banque présente le profil maximal (4/4/4) et l'e-commerce un profil équilibré (3/3/3). AlertSwiss et le streaming partagent le même contraste : une confidentialité basse (1 et 2) face à une disponibilité à 4. Ce qui les sépare est l'intégrité, maximale pour AlertSwiss, moyenne pour le streaming.

2.3.4. Interprétation des résultats ¶

Chaque profil impose une priorité de conception différente :

• Banque : prioriser C et I, tout en maintenant A.
• AlertSwiss : protéger l'authenticité du message et sa diffusion en pleine crise.
• Streaming : dimensionner l'infrastructure pour absorber la charge du soir.

Le lien avec ISO 27001 est direct : la note dépend du contexte, comme dans l'analyse de risques, et la SoA (déclaration d'applicabilité) trace ensuite ce choix.

2.4.1. Métiers pertinents ¶

• Admin systèmes et réseau : infrastructures critiques, OT.
• Développeur : cloud, logiciels.
• RSSI : entreprise.
• DPO : dossiers patients, fiscalité.
• Ma position : côté dev, je construis une partie des services que les autres protègent.

2.4.2. Déroulement ¶

Secteur public :

• Défense et sécurité nationale : armée, renseignement, police, protection civile.
• Santé publique : hôpitaux, services d'urgence, dossiers patients.
• Administrations et collectivités : état civil, fiscalité, vote, services en ligne.
• Éducation et recherche : universités, laboratoires, données scientifiques.
• Infrastructures critiques : énergie, eau, transports, télécommunications.
• Justice : tribunaux, casiers, preuves numériques.

Secteur privé :

• Entreprises : PME et grands groupes, secrets industriels, SI interne, postes de travail.
• Objets protégés : contrats, comptabilité, propriété intellectuelle, continuité d'activité.

Domaines transverses, au global :

• Santé et pharmaceutique : dispositifs médicaux, essais cliniques, brevets, chaînes de production.
• Informatique et technologique : cloud, logiciels, matériel, opérateurs télécoms, prestataires.
• Finance et assurance : banques, paiements, données clients.
• Industrie et énergie : OT (technologies opérationnelles), SCADA, chaînes logistiques.

Qui est concerné ?

• Moi : mes comptes, mes appareils, mes projets de développement.
• Nous : l'entreprise ou l'équipe où je travaille, ses clients et ses fournisseurs.
• Tout le monde : chaque citoyen utilise des services dont la compromission a un impact collectif.

2.4.3. Résultats ¶

Le secteur public couvre la défense, la santé, l'état civil, la justice et les infrastructures critiques (énergie, transports). Le secteur privé protège le SI interne, les contrats, la comptabilité et la propriété intellectuelle. Les domaines transverses relient les deux : dispositifs médicaux, cloud, banques, SCADA. Je suis concerné à chaque échelle : moi par mes comptes et mes projets, nous par mon équipe et ses clients, tous par les services collectifs que chaque citoyen utilise.

2.4.4. Interprétation des résultats ¶

Aucun secteur ne fonctionne sans sécurité. Hôpital, banque et chaîne logistique protègent des objets différents, mais une compromission bloque leur activité de la même façon. Côté dev, chaque ligne de code atterrit dans un de ces secteurs : une faille dans une app de vote ou de paiement ne reste jamais théorique. À l'échelle nationale et des alliances, la cybersécurité conditionne le fonctionnement de la société, car une compromission peut toucher des services essentiels dans plusieurs pays à la fois.

Pour le projet de semestre, le périmètre se fixe en trois questions :

• Qui utilise le service ?
• Que protège-t-il ?
• Que coûterait une compromission à chaque échelle ?

2.5.1. Métiers pertinents ¶

Tous les métiers sont concernés : RSSI, auditeur, chef de projet, développeur. La sensibilisation n'est pas un bonus, c'est une mesure de réduction du risque.

2.5.2. Déroulement ¶

2.5.2.1. Risques et biais cognitifs liés au cerveau ¶

Les heuristiques sont des raccourcis du cerveau, utiles au quotidien mais dangereux en sécurité. Elles produisent six types de biais :

2.5.2.2. Stratégies générales ¶

• Red teaming : simuler l'attaque pour briser la confirmation.
• Diversité cognitive : mélanger profils et expériences pour contrer l'ancrage.
• Hypothèses écrites : documenter ce qu'on suppose et pourquoi, cela expose l'ancrage.
• Processus standardisés : cadres comme l'ISO 27001 réduisent la dépendance à la mémoire individuelle.
• Psychological safety : permettre de signaler une erreur sans sanction, cela limite la confirmation et l'attribution fondamentale.

Références : Biais cognitif, Heuristique de jugement.

2.5.2.3. Risques liés à une personne ou à une culture ¶

Personne particulière :

• Traits : confiance excessive (Dunning-Kruger), anxiété, faible motivation → biais amplifiés.
• État : fatigue, stress, surcharge → tous les biais s'aggravent.
• Compétences : un expert réseau peut sous-estimer la cryptographie.

Stratégies individuelles : évaluation objective (tests, audits), adaptation des tâches, suivi de la charge, mentorat.

Culture :

• Culture du silence ou du blâme : on cache les erreurs, on renforce la confirmation.
• Culture hiérarchique : on ose pas contredire un supérieur → ancrage renforcé.
• Biais d'in-group : plus de confiance envers son propre groupe, vigilance réduite face à l'extérieur.
• Perception du risque : prévention collective vs. responsabilité individuelle.

Stratégies culturelles : post-mortems sans blâme, formation interculturelle, leadership exemplaire (la direction montre l'exemple), adaptation locale des messages.

Références : Biais de groupe, Psychological safety.

2.5.2.4. Activité 4 : Que faire pour limiter ces risques de prise de décision ? ¶

• Écrire les hypothèses avant de décider : noter ce qu'on suppose et pourquoi, puis relire à deux, ce qui rend l'ancrage visible.
• Faire relire par un profil différent : un dev relit l'analyse d'un admin, ou l'inverse ; le red teaming joue le même rôle contre la confirmation.
• Appliquer une procédure écrite : checklists et cadres type ISO 27001 pour les actions critiques, au lieu de compter sur la mémoire.
• Signaler sans être sanctionné : post-mortem sans blâme, erreurs remontées vite, car le silence coûte plus cher que l'aveu.
• Surveiller la charge : pauses, rotation des tâches de vigilance, alertes hiérarchisées, car un opérateur fatigué clique et ignore.

2.5.3. Résultats ¶

J'ai identifié six familles de biais, du sensori-moteur à la personnalité, chacune avec une stratégie précise. Les risques individuels tiennent à la fatigue, au Dunning-Kruger et à l'expertise partielle ; les risques collectifs, à la culture du blâme et à une hiérarchie qui verrouille la contradiction. Les mitigations suivent la même découpe : mentorat et suivi de charge pour l'individu, post-mortems sans blâme et leadership exemplaire pour le collectif. J'en retiens cinq réflexes : hypothèses écrites, relecture croisée, procédures, signalement sans sanction, gestion de la charge.

2.5.4. Interprétation des résultats ¶

Le facteur humain explique l'échec de mesures techniques pourtant correctes : un admin en surcharge ignore une alerte, un utilisateur confiant clique sur un lien. Comme ces risques varient selon la personne et la culture, la sécurité est un système sociotechnique, pas juste des pare-feu. La prochaine étape consiste à intégrer ces observations au projet de semestre : charge cognitive, culture d'équipe, diversité des points de vue.

2.6.1. Métiers pertinents ¶

DevSecOps.

2.6.2. Résultats ¶

Mon expérience passe exclusivement par des pipelines CI/CD GitLab, sans intervention manuelle sur les vérifications. À chaque intégration, les outils d'analyse des langages vérifient compilation, style et typage, et remontent aussi une partie des vulnérabilités de sécurité. Je consulte en complément les rapports GitHub chaque semaine.

Je me suis positionné sur la roadmap DevSecOps de roadmap.sh (captures ci-dessous) : les nœuds barrés sont acquis, le reste est à explorer.

2.6.3. Interprétation des résultats ¶

• Partie 1, socle acquis : langages et scripting, triade CIA, cryptographie de base, réseau, secure coding, monitoring et identité, conteneurs.
  • Exception crypto : design et failover d'une PKI non acquis.
• Partie 2, trois blocs presque entièrement non acquis :
  • Incident Response : cycle IR, forensics, containment, root cause analysis.
  • Secure Architecture : defense in depth, zoning réseau, IDS/IPS, anti-DDoS, SBOM, durcissement du pipeline, risque des dépendances.
    • Exceptions acquises : Zero Trust, Secure API Design, Supply Chain Security.
  • Enterprise Operations : automatisation SOAR, EDR, stratégie de réponse.

Ce bilan recoupe mon auto-évaluation : une culture générale solide, une lacune sur le cloisonnement et l'opérationnel. Mon expérience CI/CD automatise la détection, mais ne couvre ni la réponse à incident ni l'architecture à grande échelle. La feuille de route en découle : socle acquis, deux blocs à construire, exploitation à viser.

Prochaine étape : prioriser Secure Architecture et Incident Response, puis compléter par du DAST, de l'analyse de dépendances et une revue de conception en amont.

2.7.1. Métiers pertinents ¶

• Analyste OSINT : collecte des indices.
• RSSI : arbitrage.
• Administrateur WordPress : mises à jour.
• SOC : surveillance.
• Équipe blue : applique les contrôles.
• Équipe red : décrit seulement les scénarios de l'adversaire.

2.7.2. Déroulement ¶

• Cadre : site fictif de Ricardo, autorisation écrite, périmètre limité aux sources passives.
• Sources croisées : index publics, pages d'archives, certificats, annonces du propriétaire.
• Méthode : qualifier chaque indice, partager uniquement les informations nécessaires.
• Règle : une concordance reste une hypothèse à confirmer par le propriétaire, jamais une preuve de vulnérabilité.

2.7.3. Temps 1 : Recensement passif de serveurs WordPress ¶

• Rapprocher les signaux publics, contrôler les dates, supprimer les doublons.
• Conserver pour chaque ressource : source, indice, niveau de confiance.
• Faire confirmer les correspondances par le propriétaire.
• Aucun scan actif, aucune cible réelle testée.

2.7.4. Temps 2 : Attaque générique puis ciblée ¶

La campagne générique recherche des erreurs de configuration, des composants obsolètes et des accès d'administration. Le WAF et les journaux signalent alors une activité répétée, et je vérifie les faux positifs avant de conclure. L'attaque ciblée utilise ensuite l'inventaire pour choisir le serveur le plus exposé ; MFA, moindre privilège et segmentation limitent l'accès et le mouvement vers la base. La réponse simulée enchaîne analyse, isolation et restauration. La simulation reste théorique : aucune commande, payload, credential ni exploitation réelle.

2.7.5. Résultats ¶

• Un inventaire vérifiable de ressources candidates.
• Un scénario montrant l'effet de chaque protection : mises à jour, MFA, moindre privilège, segmentation, WAF, sauvegardes, alertes.
• Une simulation contenue, avec des écarts conservés et le besoin d'une réponse préparée.

2.7.6. Interprétation des résultats ¶

La détection vient du croisement d'indices, pas d'une source isolée. La protection améliore la détection, limite la portée d'un incident et réduit le temps de rétablissement, mais elle ne garantit pas l'absence de compromission. Je retiens trois contrôles essentiels : un inventaire à jour, des faux positifs vérifiés, une restauration testée.

2.7.7. Références ¶

• WordPress : Hardening WordPress
• NIST SP 800-61 Rev. 3 : Incident Response Recommendations

2.8.1. Métiers pertinents ¶

• RSSI : pilote les mesures, arbitre les priorités.
• SOC, blue team : appliquent au quotidien.
• Développeur : sécurise le code et les dépendances.
• Chef de projet : planifie les backups et les playbooks.

2.8.2. Déroulement ¶

Sept menaces, deux recommandations clés pour chacune :

2.8.2.1. Phishing ¶

• Bilan 2024 (antiphishing.ch) :
  • 975 309 signalements (+79 % sur un an) ;
  • 20 872 sites de phishing confirmés (+108 % sur un an) ;
  • ces chiffres décrivent les signalements centralisés par le portail, pas toutes les tentatives.
• Tendance : attaques en temps réel imitant M365 et SharePoint, contournant parfois la 2FA simple.
• Réflexes :
  • ne jamais saisir un mot de passe via un lien, passer par un favori ;
  • activer la 2FA ou FIDO2 partout ;
  • signaler chaque tentative.
• Si compromis : changer le mot de passe, déposer plainte.
• Côté domaine : configurer SPF, DKIM et DMARC.

2.8.2.2. Ransomware ¶

• Trois portes d'entrée : patch manquant, RDP ou VPN sans 2FA, macro piégée.
• Règle : ne pas payer la rançon.
• Prévention : backup 3-2-1 offline et testé, macros bloquées par défaut.
• Si une machine est chiffrée :
  • l'isoler du réseau ;
  • analyse forensique avant toute réinstallation ;
  • vérifier les déchiffreurs gratuits de No More Ransom.

2.8.2.3. DDoS ¶

• Mécanisme : saturation d'un service par botnets ou amplification.
• But : l'indisponibilité, pas le vol.
• Doctrine OFCS : tenir la charge avec le FAI et la mitigation ; ne pas payer en cas d'extorsion.
• Préparation :
  • contacts FAI et CDN prêts à l'avance ;
  • SYN-cookies, WAF, filtrage GeoIP ;
  • site de secours et playbook écrit.

2.8.2.4. Data leaks ¶

• Origines : backup exposé, base exposée, exfiltration après intrusion.
• Règle : ne pas payer.
• Réaction :
  • isoler les systèmes concernés ;
  • inventorier les données touchées ;
  • notifier le PFPDT (art. 24 nLPD) via databreach.edoeb.admin.ch ;
  • notifier l'OFCS sous 24 h si infrastructure critique.
• Prévention : aucune base sur Internet, moindre privilège strict, chiffrement des données sensibles.

2.8.2.5. Supply chain ¶

• Doctrine : pas de page OFCS dédiée ; elle vient de CISA et de l'ESF.
• Mesures :
  • exiger un SBOM (SPDX ou CycloneDX) avec un VEX ;
  • vérifier le SDLC et le SSDF du fournisseur ;
  • cartographier les fournisseurs selon NIST SP 800-161 ;
  • limiter chaque composant au moindre privilège.

2.8.2.6. Menaces de l'écosystème open source ¶

• Menaces propres :
  • typosquatting (diango au lieu de django) ;
  • dependency confusion entre registre public et privé ;
  • mainteneurs compromis.
• Cas marquants : Log4Shell, xz-utils.
• Mesures :
  • miroir interne avec allowlist ;
  • lockfiles verrouillés, pas de mise à jour à l'aveugle ;
  • scan SCA (Dependabot, Trivy) ;
  • évaluation avant adoption, signatures Sigstore vérifiées ;
  • SBOM à chaque build.

2.8.2.7. Microsoft Exchange ¶

• Trois familles de failles critiques :
  • ProxyLogon : CVE-2021-26855, 26857, 26858, 27065 ; exploité par Hafnium pour déposer un webshell SYSTEM.
  • ProxyShell : CVE-2021-34473, 34523, 31207.
  • ProxyNotShell : CVE-2022-41040, 41082.
• Impact suisse : le NCSC a informé plus de 4 500 entités exposées ; alerte historique reprise par l'OFCS.
• Mesures :
  • appliquer les mises à jour cumulatives (CU) et de sécurité (SU) sans délai ;
  • contrôler avec HealthChecker et Test-ProxyLogon.ps1 ;
  • traiter un serveur non patché comme à risque élevé, l'isoler pour investigation.

2.8.3. Résultats ¶

Trois groupes de menaces :

• Socle OFCS : phishing, ransomware, DDoS, leaks, avec des réflexes directs.
• Confiance fournisseurs : supply chain et open source déplacent la confiance vers les dépendances.
• Patch critique : Exchange montre ce qui arrive quand un patch critique dort.

Chaque menace tient en deux recommandations : un réflexe humain et une mesure technique. Leur point commun est la préparation : backups testés, contacts prêts, inventaires à jour.

2.8.4. Interprétation des résultats ¶

Ces menaces se rangent sur la triade CIA : la confidentialité contre les leaks, l'intégrité contre le ransomware et la supply chain, la disponibilité contre le DDoS. Aucune mesure seule ne suffit : c'est la défense en profondeur, où chaque couche rattrape la précédente. Le tout s'entretient en cycle PDCA : patcher, tester, auditer, corriger. J'en tire trois habitudes pour le projet de semestre : un SBOM à chaque build, des backups testés et un playbook écrit avant l'incident.

2.8.5. Références ¶

Phishing :

• OFCS - Phishing
• antiphishing.ch
• Cybermalveillance - Hameçonnage

Ransomware :

• OFCS - Ransomware
• CISA - Ransomware Guide

DDoS :

• OFCS - DDoS
• OFCS - Attaque DDoS : que faire

Data leaks :

• OFCS - Fuite de données
• Portail de notification PFPDT
• BACS - Fuite de données autorités

Supply chain :

• CISA - Defending Against Software Supply Chain Attacks (PDF)

Open source :

• CISA - Open Source Software Security Principles

Exchange :

• OFCS - Faille Exchange
• CERT-FR - Alerte CERTFR-2021-ALE-004

2.9.1. Métiers pertinents ¶

• RSSI : arbitre le vocabulaire et les priorités.
• SOC, blue team : détectent et répondent aux incidents.
• Red team : simule l'attaquant en pentest.
• CERT : coordonne la réponse.
• Développeur, admin : appliquent les correctifs, contrôlent le Shadow IT.

2.9.2. Déroulement ¶

Ma source principale est le Hucency - Glossaire de la cybersécurité (55 définitions, sourcées ANSSI, CNIL, Cybermalveillance, ENISA). J'ai reformulé les définitions dans les grandes lignes, sans les recopier.

2.9.2.1. Six concepts extraits du glossaire ¶

Précision que je ne connaissais pas avant lecture : Emotet et Log4Shell montrent deux échelles. Emotet est une menace persistante qui mute (botnet loué à d'autres attaquants), tandis que Log4Shell est une faille supply chain où une seule bibliothèque omniprésente compromet tout l'écosystème.

2.9.2.2. Red team, blue team, purple team ¶

Le cycle est le suivant : la red team attaque, la blue team détecte et répond, puis la purple team compare l'attaque aux alertes, ajuste les règles SIEM/EDR et rejoue le scénario jusqu'à une détection fiable.

2.9.3. Résultats ¶

Les six termes se rangent en trois groupes, plus les équipes :

• L'attaque : APT, drive-by download, Emotet.
• L'organisation de la défense : le CERT collecte les signalements et coordonne la réponse.
• Le terrain qui facilite l'attaque : Log4Shell (dépendance omniprésente), Shadow IT (usages non contrôlés).
• Qui fait quoi : red, blue et purple team (attaquer, défendre, faire progresser les deux).

2.9.4. Interprétation des résultats ¶

Aucun acteur ne couvre seul la triade CIA, ce qui relève de la défense en profondeur : le CERT coordonne, la blue team opère au quotidien, la red team vérifie et la purple team boucle l'amélioration. Pour le projet de semestre, j'en tire deux réflexes : nommer chaque risque avec le bon terme (APT, drive-by, Shadow IT) et associer chaque mesure à son équipe (qui détecte, qui teste, qui corrige).

2.10.1. Métiers pertinents ¶

• RSSI : porte le cadre, rend compte à la direction.
• Risk manager : chiffre les risques sur la grille CIA.
• SOC, blue team : détection et réponse.
• Admin, développeur : appliquent la protection.
• Auditeur : vérifie la récupération par les tests de restauration.
• DPO : rejoint le RSSI sur la confidentialité et la notification.

2.10.2. Déroulement ¶

L'affirmation testée est que les piliers CIA et Identifier / Protéger / Détecter-Répondre / Récupérer donnent un cadre assez concret pour décider. Je la défends devant ma direction en trois temps : fixer les priorités avec CIA, organiser l'action avec les fonctions, puis trancher trois décisions de RSSI.

2.10.2.1. 1. La triade CIA fixe le quoi protéger ¶

• Confidentialité : limite qui voit.
• Intégrité : personne ne modifie sans droit.
• Disponibilité : accès quand il faut.

Je repars des quatre cas de l'exercice 3, dont les notes imposent déjà des arbitrages.

Premier apport du cadre : à disponibilité égale (4), les budgets diffèrent. AlertSwiss investit dans l'authenticité, le streaming dans la capacité. Sans la grille CIA, je répartirais mal le budget.

2.10.2.2. 2. Les fonctions organisent le comment agir ¶

Les fonctions viennent du NIST Cybersecurity Framework (CSF) : Identifier, Protéger, Détecter, Répondre, Récupérer. Le CSF 2.0 ajoute Gouverner (stratégie et supervision par la direction). Je garde les cinq de l'énoncé, Gouverner servant de chapeau.

L'ordre est imposé : on ne protège bien que ce qu'on a identifié, on ne répond bien que si on détecte, et on ne récupère que si on a préparé. La boucle de retour vers Identifier porte l'amélioration continue.

2.10.2.3. 3. Trois décisions de RSSI qui prouvent le cadre ¶

Décision 1 : arbitrage budgétaire. Je dois choisir entre un WAF et un coffre de backups offline. Pour la banque, l'intégrité des soldes impose les deux. Pour le streaming (C/I faibles), la disponibilité fait passer la capacité avant le chiffrement avancé. Chaque franc est justifié par le critère qu'il protège, comme la SoA d'ISO 27001 trace chaque mesure.

Décision 2 : ransomware un vendredi soir. Le SOC signale une machine chiffrée, ce qui déclenche la chaîne Détecter → Répondre → Récupérer :

1. Isoler la machine.
2. Interdire le paiement (doctrine OFCS et CISA).
3. Mener la forensique avant réinstallation.
4. Restaurer depuis le backup testé.
5. Notifier le PFPDT si des données clients fuient.

Sans playbook écrit à l'avance, je négocie sous stress, et le biais de jugement (activité 4) décide à ma place.

Décision 3 : reporting à la direction. Je rapporte des risques sur CIA et l'avancement des cinq fonctions, pas des CVE. Par exemple : confidentialité des dossiers patients couverte à 80 %, détection encore manuelle, test de restauration réussi en juin. C'est le langage de la fonction Gouverner : la direction comprend, arbitre et signe, ce qui pèse pour viser ISO 27001.

2.10.3. Résultats ¶

Les deux piliers sont complémentaires, sans recouvrement. CIA donne le quoi, c'est-à-dire les priorités (banque 4/4/4, AlertSwiss 1/4/4, streaming tiré par la disponibilité). Les fonctions donnent le comment : identifier avant de protéger, détecter avant de répondre, préparer avant de récupérer. Les trois décisions montrent le cadre en action : un arbitrage budgétaire tracé dans la SoA, une réponse ransomware jouée au playbook, un reporting traduit en risques pour la direction. Chaque pilier seul laisse un angle mort : CIA sans fonctions reste théorique, et des fonctions sans CIA répartissent l'effort à l'aveugle.

2.10.4. Interprétation des résultats ¶

Je n'ai pas à choisir entre les cadres, je les empile : CIA porte l'analyse de risques, les fonctions portent le plan d'action et ISO 27001 porte la preuve (PDCA, SoA). Comme pour la défense en profondeur (activité 2), chaque fonction rattrape la précédente. Le facteur humain (activité 4) reste la condition de tenue : procédures écrites, alertes hiérarchisées et post-mortems sans blâme rendent les fonctions tenables par des humains fatigués.

Pour le projet de semestre, la méthode tient en trois gestes : noter chaque actif en C/I/A, rattacher chaque mesure à une fonction, tracer l'écart dans une mini-SoA. Une liste d'outils devient ainsi une posture défendable devant un auditeur ou une direction.

2.10.5. Références ¶

• NIST, Cybersecurity Framework (CSF) 2.0 : Gouverner, Identifier, Protéger, Détecter, Répondre, Récupérer
• ISO, ISO/CEI 27001 (SMSI, SoA, PDCA)
• OFCS (BACS) : phishing, ransomware, DDoS, fuite de données
• CISA, Ransomware Guide (ne pas payer, backups offline)
• Cybermalveillance.gouv.fr : réflexes et guides pour les entreprises

2.11.1. Métiers pertinents ¶

• Admin cloud, exploitant hyperviseur : isolation et patching des nœuds.
• Architecte sécurité : choix du runtime et des profils de confinement.
• SOC, blue team : détection runtime.
• RSSI : arbitre entre exposition multi-tenant et coût des redémarrages.

2.11.2. Déroulement ¶

Risque propre à l'opérateur cloud. Les conteneurs partagent le noyau de l'hôte : une seule faille noyau casse la multi-tenancy. L'attaquant s'évade du conteneur ou de la VM, puis compromet l'hyperviseur ou le nœud hôte.

Pourquoi c'est difficile à contenir en 2026. Le fuzzing assisté par IA, l'industrialisation des proofs of concept (PoC) et l'évolution rapide du noyau accroissent la pression sur les mainteneurs. Les chiffres de CVE par version varient selon la source et la période ; les ~2 000 cités par certaines analyses sont un instantané à vérifier, pas une constante.

LPE (Local Privilege Escalation) récentes. Copy Fail, Dirty Frag et Dirty Clone sortent souvent avec un PoC public. Le délai entre publication et exploitation varie, et l'impact dépend du noyau, de la configuration et de l'isolation. Le passage conteneur → root est donc un scénario à reproduire et à réduire, pas une conséquence systématique.

Agents autonomes. Des recherches décrivent des agents capables d'adapter des PoC publics. Évasion, root sur l'hôte et mouvement latéral dépendent toutefois de la vulnérabilité et des mesures en place : ce scénario n'est pas systématique.

2.11.3. Résultats ¶

Un cycle mensuel de patch ne suffit pas toujours. Je propose un plan en quatre étapes : réduire, isoler, patcher à chaud, surveiller.

Étape 1 : réduire la surface du noyau (hardening). La plupart des failles récentes visent des modules réseau ou des filesystems inutiles en production cloud. Les actions :

• Bloquer leur chargement via modprobe.d.
• Désactiver les protocoles non requis et les vieux filesystems.
• Couper les fonctions à risque comme io_uring si aucune architecture ne l'exige.
• Restreindre les appels système par des profils Seccomp stricts.
• Interdire clone3, unshare ou keyctl aux charges clientes.

Étape 2 : durcir l'isolation (sandboxing). Docker / containerd classique partage le noyau hôte : si le noyau tombe, l'hôte tombe. Pour les charges non dignes de confiance, je passe à gVisor ou Kata Containers. gVisor intercepte et émule les syscalls en espace utilisateur ; Kata Containers place chaque conteneur dans une micro-VM avec son propre noyau.

Étape 3 : moderniser le patching. Redémarrer des milliers d'hyperviseurs ralentit chaque correctif. Le live-patching (KernelCare, Kpatch, Livepatch) charge un correctif en mémoire sans redémarrage immédiat, lorsque correctif et système le permettent. Il ne couvre que les correctifs compatibles et ne supprime pas tous les risques. Les changements structurels passent donc par un pipeline d'infrastructure : drain du nœud, mise à jour, test, redémarrage ou redéploiement progressif.

Étape 4 : détecter au runtime via eBPF. Un outil CNAPP / CWPP basé sur eBPF (Cilium Tetragon, Falco) observe le noyau en temps réel. Il alerte sur une élévation de privilèges sans fichier modifié et signale une structure socket anormale.

2.11.4. Interprétation des résultats ¶

Le plan applique la défense en profondeur, chaque étape rattrapant la précédente. Le hardening réduit l'exposition, le sandboxing confine les charges non fiables, le live-patching réduit la fenêtre d'exposition si le correctif est compatible, et la détection eBPF signale les comportements suspects à l'exécution.

Côté opérateur, la triade CIA se lit ainsi : la confidentialité repose sur la séparation des tenants, l'intégrité sur le blocage de l'élévation conteneur → root, et la disponibilité est maintenue pendant le patching si le live-patch est compatible, sinon par drain ou redémarrage. Le moindre privilège et le Zero Trust imposent qu'aucun workload client n'obtienne par défaut un syscall sensible.

Le plan suit le cycle PDCA :

• Plan : inventaire des modules et des syscalls.
• Do : déploiement des profils et runtimes.
• Check : Tetragon et audits.
• Act : live-patch et SoA.

Côté ISO 27001, ce plan se trace vers la gestion des vulnérabilités techniques et la sécurité des environnements de développement et d'exploitation. Le certificat ne prouve pas l'absence de CVE noyau ; il prouve qu'un système de patching et de surveillance tourne en continu.

J'en retiens trois réflexes pour le projet de semestre : un runtime isolé pour tout workload non digne de confiance, Seccomp strict par défaut, et le live-patching si compatible, avec drain ou redémarrage pour les changements structurels.

2.11.5. Références ¶

Sources de l'analyse :

• Tom's Hardware : le noyau frôle 2 000 CVE par version, chasseurs IA sur 40 M de lignes, mainteneurs submergés
• LinuxSecurity : état de la sécurité du noyau Linux 2025
• Host.it : CVE noyau Linux, IA et patch sans redémarrage

Isolation et détection :

• gVisor : isolation par interception des syscalls
• Kata Containers : conteneur dans une micro-VM
• eBPF : observation du noyau en temps réel
• Falco : détection runtime cloud-native
• Cilium Tetragon : sécurité runtime basée sur eBPF

2.12.1. Métiers pertinents ¶

Ce standard ne parle pas qu'aux techniciens :

• RSSI, responsable sécurité : portent le SMSI (système de management de la sécurité de l'information), rendent compte à la direction.
• Risk manager, analyste risques : l'analyse de risque est leur point de départ.
• Auditeur interne, auditeur de certification : vérifient la conformité sur preuves.
• Admin systèmes et réseau, développeurs, DPO : appliquent les mesures de l'annexe A, chacun sur sa partie.
• Direction : sans son engagement écrit, la certification ne passe pas.

2.12.2. Résultats ¶

Portée générale, périmètre choisi. La norme s'adresse à toute organisation (entreprise, administration, ONG, petite ou grande), et rien ne la limite à l'informatique. Chaque organisation choisit son périmètre de SMSI : toute l'entreprise, un site, un département, un produit. Tout le reste ne s'applique qu'à l'intérieur de ce périmètre déclaré.

Quatre familles de mesures. L'annexe A (version 2022) liste 93 mesures, réparties ainsi :

• Organisation : politiques, rôles, classification de l'information, gestion des incidents.
• Personnes : recrutement, sensibilisation, processus de départ.
• Physique : accès aux locaux, protection du matériel.
• Technique : contrôle d'accès logique, cryptographie, sécurité réseau, développement sécurisé, correctifs.

La sécurité ne se joue donc pas que dans les pare-feu.

Gestion du risque top-down. La direction pose les enjeux, on identifie ensuite actifs et risques sur C, I, A, et on choisit les mesures seulement après. Rien n'est obligatoire par défaut, d'où la Déclaration d'applicabilité (SoA) : on justifie, mesure par mesure, ce qu'on applique, ce qu'on écarte, et pourquoi. L'ordre est imposé : pas de mesures avant les risques, pas de risques hors périmètre, et la SoA comme trace écrite du choix.

Obligations de management plus que détails techniques. Les clauses 4 à 10 décrivent le système : périmètre, rôles, planification, non-conformités, revue de direction. La norme dit quel processus mettre en place, pas quel outil acheter ni quel chiffrement utiliser.

Pensée pour la certification. Un tiers (Bureau Veritas, BSI, SQS) audite l'organisation et délivre un certificat de trois ans, avec un audit de suivi chaque année. Entre-temps, les audits internes et la roue PDCA (Plan, Do, Check, Act) entretiennent le système. Le certificat a un double usage : preuve de confiance pour les clients, boucle d'amélioration en interne.

Un coût réel. Il n'existe pas de chiffre unique, tout dépend du périmètre. Il faut payer l'audit externe et souvent un accompagnement, mais le coût principal est le temps interne : documentation, analyse de risques, formation. S'y ajoutent parfois des mises à niveau techniques non prévues.

Prévention et réaction. La norme couvre les deux versants : la prévention (analyse de risques, politiques, durcissement, sensibilisation), puis la détection et la réaction (journaux, surveillance, détection d'anomalies, réponse aux incidents testée et suivie).

Pas de niveau numéroté. Contrairement à CMMI, il n'y a pas de note de 1 à 5. La maturité se voit dans la durée : indicateurs suivis, revues régulières, actions correctives (clause 10) qui aboutissent.

Références : document de groupe, ISO/CEI 27001, Wikipedia FR, page officielle ISO.

2.12.3. Interprétation des résultats ¶

La norme est lourde sur le papier, mais je comprends son succès : elle adapte l'effort aux vrais risques, tout en obligeant à écrire ce choix dans la SoA. On ne peut pas dire "on fait de la sécurité" sans le montrer.

Elle colle au rôle de RSSI et d'auditeur. Pour un admin ou un dev, elle fournit un cadre, pas une recette ; les consignes précises se trouvent dans ISO 27002, qui détaille les mesures. Elle applique le PDCA à la sécurité : planifier avec les risques, déployer, contrôler (audits, logs), corriger (clause 10). Ce n'est donc pas un contrôle ponctuel avant un audit client.

Conformité n'est pas sécurité réelle : le certificat prouve qu'un système existe et qu'il est suivi, pas l'absence d'incident. Enfin, vu le coût en temps et en documentation, la direction doit le vouloir, sinon cela reste un classeur vide.

2.13.1. Résultats ¶

• Exercice 1 : auto-évaluation remplie, point faible en confinement OS/réseaux.
• Exercice 2 : critères principaux CIA et secondaires rappelés et schématisés.
• Exercice 3 : triade CIA notée et comparée sur quatre cas, avec graphique.
• Exercice 4 : secteurs public/privé et échelles moi/nous/tous recensés.
• Activité 1 : positionnement DevSecOps via CI/CD GitLab et roadmap.
• Activité 3 : OSINT et veille collective autorisée, recensement de serveurs WordPress, simulation d'attaque générique et ciblée, recul sur les protections.
• Activité 4 : six familles de biais cognitifs, mitigations individuelles et collectives.
• Travail personnel : ISO 27001 décortiqué, schéma Direction → Risques → SoA → Mesures.

2.13.2. Interprétation des résultats ¶

Je retiens trois repères pour le semestre. D'abord, la triade CIA n'est pas abstraite : chaque cas (banque 4/4/4, AlertSwiss 1/4/4, streaming, e-commerce) impose sa priorité de conception, et ISO 27001 oblige à tracer ce choix dans la SoA. Ensuite, la sécurité est un système sociotechnique : biais cognitifs et culture d'équipe font échouer les mesures techniques, d'où les réflexes d'hypothèses écrites, de relecture croisée et de post-mortems sans blâme. Enfin, côté pratique, mon CI/CD couvre surtout des contrôles statiques et les vérifications des langages ; il manque encore le confinement (2/5), le DAST et l'analyse de dépendances.

La prochaine étape consiste à évaluer le projet de semestre avec la grille CIA + SoA + facteur humain. L'activité 3 y ajoute la veille OSINT autorisée, qui complète la détection à condition de valider les faux positifs et de tester les protections. La chaîne est donc : cadrer avec CIA et SoA, intégrer l'humain, puis pratiquer en CI/CD.