Skip to main content

Chapitre 4.4 Quiz - Durcissement, Conformite et Operations Red/Blue Team

Mode Quiz - Toutes les reponses sont masquees. Tentez chaque question avant de reveler la reponse.

Question 1

Votre organisation obtient 45% lors d'une evaluation NIST CSF. Le RSSI demande quelle fonction prioriser en premier pour avoir le plus grand impact de reduction des risques. En utilisant la hierarchie des fonctions CSF et les controles defensifs du cours, justifiez votre reponse avec des exemples de controles specifiques.

Reveler la reponse

Reponse : Prioriser IDENTIFIER si le score est faible la, mais dans la plupart des organisations a 45% globalement, l'investissement a plus grand impact est generalement PROTEGER - specifiquement la Gestion des identites (PR.AA) et la Securite des donnees (PR.DS).

Raisonnement :

Les fonctions CSF ont un ordre de dependance logique : vous ne pouvez pas DETECTER ce que vous n'avez pas PROTEGE, et vous ne pouvez pas REPONDRE efficacement sans savoir ce que vous PROTEGEZ (IDENTIFIER). Cependant, l'impact de chaque fonction sur les resultats de violation dans le monde reel suit un ordre different :

Si IDENTIFIER est faible (pas d'inventaire des actifs, pas d'evaluation des risques) :

  • Vous ne savez pas quels systemes existent - vous ne pouvez pas les corriger - vous ne pouvez pas les surveiller
  • Corriger en premier : deployer la decouverte des actifs (balayage interne Nmap/Shodan), construire une CMDB
  • Impact : permet toutes les autres fonctions

Si PROTEGER est faible (lacune la plus courante a 45%) :

  • Pas de MFA - les attaques sur les identifiants reussissent trivialement (chapitres sur les identifiants du Module 3)
  • Pas de durcissement - Kerberoasting, relai SMB reussissent sans effort
  • Pas de moindre privilege - le mouvement lateral est sans restriction

Controles specifiques a plus grand impact de ce cours :

1. PR.AA-05 -- Moindre privilege + MFA
   Cout : Faible | Impact : Contrecarre T1078 (Comptes valides) -- technique ATT&CK numero 1

2. PR.IR-01 -- Segmentation reseau
   Cout : Moyen | Impact : Contrecarre tout mouvement lateral (Chapitre 3.3)
   Controle structurel -- l'attaquant avec des identifiants valides ne peut toujours pas atteindre les systemes sensibles

3. PR.DS-02 -- Donnees en transit chiffrees (application TLS)
   Cout : Faible | Impact : Contrecarre l'ecoute passive, l'intercept des identifiants

Pourquoi pas DETECTER en premier ? La detection sans protection signifie que vous detectez des attaques que vous ne pouvez pas prevenir assez rapidement pour arreter la violation. Un MTTD (temps moyen de detection) de meme 1 heure signifie qu'un environnement non protege est completement compromis avant que l'alerte soit traitee. Les controles de protection structurels (segmentation, MFA) arretent les attaques que la detection ne ferait qu'observer.

Le sequencement correct : IDENTIFIER (connaitre vos actifs) -> PROTEGER (reduire la surface d'attaque) -> DETECTER (attraper ce qui passe a travers) -> REPONDRE (contenir et recuperer) -> GOUVERNER (maintenir durablement).

Question 2

Une equipe rouge obtient l'acces Administrateur de domaine en 6 heures via cette chaine : email d'hameconnage -> cradle de telechargement PowerShell -> Kerberoasting de svc-backup -> spray de mot de passe avec le mot de passe craque -> DA via DCSync. Pour chacune des cinq etapes, nommez le controle structurel le plus efficace qui aurait brise la chaine a ce point.

Reveler la reponse

Reponse : Briser chaque maillon de la chaine d'attaque :

Etape 1 - Email d'hameconnage -> cradle de telechargement PowerShell

Controle : Passerelle de securite email avec sandboxing des pieces jointes/liens + regle de reduction de surface d'attaque bloquant les applications Office/script de lancer PowerShell.

# Regle ASR : bloquer Office de lancer des processus enfants
Add-MpPreference -AttackSurfaceReductionRules_Ids `
  "d4f940ab-401b-4efc-aadc-ad5f3c50688a" `
  -AttackSurfaceReductionRules_Actions Enabled

Meme si l'email d'hameconnage est livre, PowerShell ne peut pas etre lance depuis la macro du document. Le cradle de telechargement ne s'execute jamais.

Etape 2 - Cradle de telechargement PowerShell atteignant C2

Controle : Proxy de sortie avec inspection TLS bloquant les domaines non categorises/nouveaux.

# Squid avec ssl-bump -- inspecter TLS sortant, bloquer les destinations inconnues
# Les nouveaux domaines C2 enregistres quelques jours avant l'attaque ne sont pas categorises
# La politique de refus par defaut des nouveaux domaines brise le rappel du cradle de telechargement

Le payload PowerShell ne peut pas telecharger sa deuxieme etape - le rappel C2 est bloque.

Etape 3 - Kerberoasting de svc-backup

Controle : Compte de service gere par groupe (gMSA) pour svc-backup - mot de passe auto-rotant de 240 caracteres rend le craquage computationnellement infaisable.

New-ADServiceAccount -Name "svc-backup" `
  -DNSHostName "svc-backup.corp.local" `
  -ManagedPasswordIntervalInDays 30

Le ticket TGS est toujours requestable, mais le mot de passe gere de 240 caracteres ne peut pas etre craque avec aucune liste de mots ou attaque par masque.

Etape 4 - Spray de mot de passe avec le mot de passe craque

Controle : MFA sur toutes les connexions interactives, y compris l'authentification de compte de domaine vers les serveurs.

Meme avec le mot de passe de svc-backup, chaque tentative d'authentification necessite un deuxieme facteur que l'attaquant ne possede pas. Le spray de mot de passe produit des echecs d'authentification - aucun acces accorde.

Etape 5 - DCSync via DA

Controle : Modele d'administration par niveaux - les comptes DA utilisables uniquement depuis des Postes de travail a acces privilegie (PAW), et le compte compromis (svc-backup) ne devrait jamais avoir de chemin vers DA.

Niveau 0 : DC, gestion AD -> comptes DA uniquement, PAW requis
Niveau 1 : Serveurs -> comptes d'administration de serveurs
Niveau 2 : Postes de travail -> comptes de support informatique
Pas de mouvement lateral entre les niveaux

svc-backup est un compte Niveau 1/2 sans chemin vers le Niveau 0 (DA). Meme completement compromis, il ne peut pas effectuer DCSync.

Resume : N'importe lequel de ces controles aurait brise la chaine. La defense en profondeur signifie que l'attaquant doit vaincre les cinq simultanement - une tache exponentiellement plus difficile.

Question 3

Vous redigez les Regles d'Engagement pour une evaluation red team d'un reseau hospitalier. L'hopital dispose d'un systeme de surveillance des patients en direct connecte au meme reseau que les postes de travail. Listez cinq interdictions explicites qui doivent figurer dans les ROE, et expliquez la logique juridique et de securite des patients pour chacune.

Reveler la reponse

Reponse :

Interdiction 1 - Aucun test, acces ou interaction avec les systemes de surveillance des patients, de support vital ou de dispositifs medicaux

Justification : Les dispositifs medicaux (ventilateurs, pompes a perfusion, moniteurs cardiaques) fonctionnent selon des planifications critiques en temps reel. Toute perturbation reseau, injection de paquets ou trafic inattendu pourrait provoquer un dysfonctionnement du dispositif. Le deces du patient est une consequence previsible. Responsabilite juridique : responsabilite penale pour negligence quelle que soit l'autorisation. Cette interdiction est absolue - aucune exception pour l'observation "passive".

Interdiction 2 - Aucune attaque par deni de service, inondation de paquets ou actions pouvant degrader les performances reseau

Justification : Dans un hopital, la degradation du reseau affecte directement les systemes cliniques. Les retards d'acces au DME (Dossier Medical Electronique), les ralentissements du systeme d'imagerie ou les pannes du systeme d'appel infirmiere sont des evenements de securite des patients. Meme les techniques de balayage "legeres" (balayages ICMP, scans SYN) peuvent surcharger le materiel reseau de qualite medicale non concu pour des volumes de trafic adversariaux. Juridique : les reseaux hospitaliers dans la plupart des juridictions sont des infrastructures critiques protegees.

Interdiction 3 - Aucun acces, exfiltration ou interaction avec les Informations de sante protegees (PHI)

Justification : HIPAA (aux Etats-Unis) et les reglementations equivalentes dans le monde imposent des exigences strictes sur l'acces aux PHI. L'acces non autorise aux PHI - meme dans le cadre d'un test d'intrusion autorise - cree des obligations de signalement reglementaire et une responsabilite civile/penale potentielle. Les ROE doivent interdire explicitement de toucher aux donnees PHI. Si un test necessite de demontrer l'acces a un partage sensible, un fichier de test (pas de vraies PHI) doit etre pre-place la par l'equipe informatique de l'hopital.

Interdiction 4 - Aucun test d'acces physique, ingenierie sociale du personnel clinique ou filature dans les zones cliniques

Justification : L'ingenierie sociale des infirmieres, medecins ou personnel clinique cree des risques de securite des patients (distraction pendant les soins), des violations potentielles de HIPAA (divulgation verbale) et une responsabilite significative pour la firme de test. Le personnel clinique n'est pas un personnel conscient de la securite - il est forme pour prioriser les soins aux patients. Les tests physiques dans les zones cliniques risquent de contaminer les environnements steriles ou de perturber la prestation des soins.

Interdiction 5 - Aucun test en dehors des heures de bureau sans approbation ecrite explicite pour chaque fenetre de test hors heures

Justification : Les effectifs informatiques hospitaliers sont reduits en dehors des heures de bureau, ce qui signifie que la reponse a un probleme inattendu cause par les tests (meme benin) est plus lente. Tout incident pendant les tests necessitant une reponse informatique sera en competition avec la reponse aux incidents cliniques. L'approbation des tests hors heures garantit qu'un personnel informatique adequat est d'astreinte et que l'equipe d'astreinte est notifiee.

Exigence obligatoire supplementaire pour les ROE hospitalieres : Une ligne de deconfliction dotee en personnel 24h/24 pendant l'engagement qui connecte directement l'equipe rouge au RSSI et au gestionnaire informatique clinique d'astreinte. Si une activite de test provoque un comportement reseau inattendu, l'equipe rouge s'arrete immediatement et appelle la ligne directe - avant toute investigation sur la cause.

Question 4

Vos metriques de securite montrent : MTTD = 18 jours, MTTR = 72 heures, conformite SLA de patch = 61%, taux TP des alertes = 8%. Classez ces quatre metriques par urgence de remediation et decrivez une action concrete pour chacune qui produirait la plus grande amelioration dans les 90 jours.

Reveler la reponse

Reponse :

Rang 1 (Plus urgent) - MTTD = 18 jours

Un temps moyen de detection de 18 jours est catastrophique. Chaque jour de temps de presence est un jour de plus de mouvement lateral, de collecte d'identifiants et d'acces aux donnees. La mediane industrielle du MTTD est d'environ 16 a 21 jours (IBM Cost of a Data Breach 2023) - etre a la mediane n'est pas une position defensible. Cela conditionne toutes les autres metriques : vous ne pouvez pas repondre a ce que vous n'avez pas detecte.

Action a 90 jours : Deployer Elastic Agent ou EDR equivalent avec la telemetrie de creation de processus, connexion reseau et authentification sur tous les points de terminaison - en particulier les postes de travail (le vecteur d'acces initial le plus courant). Configurer immediatement les trois detections a plus haute fidelite : (1) commandes PowerShell encodees, (2) connexions reseau NTLM avec authentification NTLM, (3) nouvelles taches planifiees. Meme trois regles bien ajustees reduiront materiellement le MTTD.

# Reduction cible du MTTD : 18 jours -> < 3 jours en 90 jours
# Metrique a suivre : temps depuis le premier evenement malveillant (par analyse forensique)
#                    jusqu'a la premiere alerte dans le SIEM pour cet evenement

Rang 2 (Urgent) - Taux TP des alertes = 8%

A 8% de taux TP, les analystes passent 92% de leur temps sur le bruit. Cela provoque directement un MTTD eleve - les vraies alertes sont noyees. La fatigue d'alerte amene egalement les analystes a reduire la qualite des investigations et a manquer des indicateurs subtils. C'est la cause profonde d'un MTTD long dans la plupart des organisations.

Action a 90 jours : Identifier les 5 regles au volume le plus eleve par nombre d'alertes. Pour chacune, interroger le SIEM pour toutes les dispositions FP des 30 derniers jours - trouver le modele FP commun (utilisateur, processus, hote specifique) et ajouter un filtre Sigma cible. Objectif : reduire le volume FP de 60% sans supprimer aucune regle generant des TP. Taux TP cible : > 25% dans les 90 jours.

Rang 3 - Conformite SLA de patch = 61%

61% de conformite signifie que 39% des vulnerabilites critiques restent non corrigees au-dela de la fenetre SLA. Ce sont des vulnerabilites connues, publiques avec des patchs disponibles - les attaques les moins coûteuses pour tout adversaire. C'est particulierement critique pour les systemes exposes sur Internet.

Action a 90 jours : Implementer le patching automatise pour les postes de travail et les serveurs non critiques via WSUS/SCCM/Ansible - supprimant le goulot d'etranglement humain pour la majorite du volume de patches. Pour les serveurs critiques necessitant un controle des changements, creer un processus de changement accelere de 72 heures pour les vulnerabilites CVSS 9.0+. Cible : > 90% de conformite dans les 90 jours.

Rang 4 - MTTR = 72 heures

Un MTTR de 72 heures est eleve mais moins urgent que les autres - vous ne pouvez repondre qu'apres la detection. L'amelioration du MTTD ameliore automatiquement le MTTR significatif (temps de la violation a la confinement). De plus, un MTTR de 72 heures reflete souvent des retards de processus (approbations, chaines de notification) plutot que des limitations techniques.

Action a 90 jours : Implementer des playbooks SOAR pour les 3 types d'alertes principaux - automatiser les 30 premieres minutes d'investigation (enrichissement IOC, recherche d'actifs, decision de confinement initiale). La premiere reponse automatisee comprime le MTTR pour la plupart des incidents de heures a minutes. Cible : < 4 heures de MTTR pour les alertes de severite HAUTE dans les 90 jours.

Justification de l'ordre de priorite : MTTD -> Taux TP -> SLA de patch -> MTTR, car reduire le MTTD necessite d'ameliorer le taux TP (vous ne pouvez pas detecter rapidement ce qui est noye dans le bruit), et le SLA de patch reduit la surface d'attaque qui cree les incidents necessitant une detection et une reponse rapides.

Fin du Quiz 4.4 - Durcissement, Conformite et Operations Red/Blue Team