Ville du Parc — SISR, session Mai 2023

Mission A1 — Identifier des données personnelles et sensibles

La ville, responsable de traitement, doit respecter notamment :

• Finalité & licéité : collecter pour une finalité déterminée, explicite et légitime (état-civil, RDV), avec une base légale (mission de service public).
• Minimisation : ne collecter que les données strictement nécessaires.
• Information & droits : informer l’usager (finalité, durée) et garantir ses droits (accès, rectification, effacement) ; recueillir le consentement si requis.
• Sécurité & conservation : assurer confidentialité et intégrité (chiffrement, accès restreint), limiter la durée de conservation, désigner un DPO et tenir un registre des traitements.

En cas de violation de données : notification à la CNIL sous 72 h et information des personnes si le risque est élevé.

• Pour la mairie : atteinte à l’image et à la confiance des administrés ; sanctions juridiques et financières (sanctions de la CNIL, le RGPD laissant à chaque État le soin de fixer si une commune peut être mise à l’amende (art. 83.7), responsabilité du maire, coût de remédiation).
• Pour les usagers : usurpation d’identité (faux papiers, ouverture de comptes au nom de la victime) ; fraude / escroquerie (revente des données, démarchage, chantage) et atteinte à la vie privée.

Mission A2 — Évaluer les risques numériques

1. Infrastructure redondée : 2 salles serveurs et 2 cœurs de réseau sur 2 sites géographiques (PCA).
2. Cluster d’hyperviseurs ESX (6 serveurs physiques) avec basculement automatique en cas de panne d’un hôte.
3. Baies SAN en RAID 50 (2 × 200 To) répliquées en fibre entre les deux datacenters.
4. RSTP activé sur tous les commutateurs → topologie redondante sans boucle.
5. Sauvegardes Veeam chiffrées, avec empreinte d’intégrité, stockées hors-ligne sur 2 sites, restaurations testées régulièrement.
6. Locaux sécurisés : courant fort ondulé, double climatisation, contrôle d’accès badge + biométrie.

a) Conséquences DIC d’un rançongiciel sur les serveurs

Critère	Conséquence
Disponibilité	Très forte atteinte : les fichiers chiffrés rendent les serveurs et services indisponibles (état-civil, applications métiers), paralysie de la mairie.
Intégrité	Forte atteinte : les données sont chiffrées/modifiées, donc inexploitables sans la clé de déchiffrement.
Confidentialité	Atteinte limitée ici : le scénario EBIOS retenu (cyber-terroriste « bloquer le SI avec demande de rançon ») n’exfiltre pas les données ; Ryuk lui-même ne réalise pas d’exfiltration.

b) Gravité, vraisemblance et scénario de risque

D’après les ateliers EBIOS RM : gravité = 4/4 (évènement redouté « perte/destruction des données », impacts critiques) et vraisemblance = 4/4 (scénario opérationnel « hameçonnage → rançongiciel » jugé très vraisemblable). Dans la matrice (gravité 4, vraisemblance 4), c’est le scénario R2, situé dans la zone de risque maximal (à traiter en priorité).

c) Mesures déjà prises pour limiter ce risque (atelier 5)

• Sensibilisation à l’hameçonnage (statut Terminée) — coupe le vecteur initial.
• Surveillance renforcée des flux entrants/sortants (IOC) — En cours.
• Sauvegardes chiffrées et déconnectées (Veeam) — permettent de restaurer sans payer.
• Analyse des journaux d’évènements et audit de sécurité du SI — en cours / à lancer.

Solution	Gravité	Vraisemblance	Justification
Bac à sable (Sandbox)	inchangée	diminuée	Le programme non vérifié s’exécute dans un environnement isolé et éphémère : si c’est un rançongiciel, il n’atteint pas le système hôte et est détruit à la fermeture → l’infection a moins de chances d’aboutir. La gravité d’une infection « réelle » reste la même si elle survient malgré tout.
Application Guard	inchangée	diminuée	Les sites/fichiers non approuvés s’ouvrent dans un conteneur isolé distinct de l’OS → le vecteur d’entrée (pièce jointe / site malveillant) est cloisonné, réduisant la probabilité que le code malveillant s’exécute sur le poste.

Ces deux solutions agissent sur la vraisemblance (probabilité que l’attaque réussisse), pas sur la gravité (impact si elle aboutit malgré tout, ex. via un compte à privilèges).

Mission B1 — Améliorer la stratégie des mots de passe

a) Impacts d’une expiration très courte (inférieure à 1 mois) vs longue / illimitée, selon le type de compte :

• Comptes utilisateurs (peu sensibles) : une expiration trop courte est contre-productive (recommandation R24 ANSSI) — les utilisateurs choisissent des mots de passe faibles, prévisibles ou réutilisés (incrément d’un chiffre), notent leurs mots de passe. Mieux vaut pas de délai + mot de passe robuste.
• Comptes à privilèges (très sensibles) : maintenir un délai d’expiration reste pertinent (recommandation R25) car la compromission d’un tel compte est critique ; un délai illimité laisse un secret valable indéfiniment en cas de fuite.

b) Délai préconisé pour les comptes à privilèges : entre 1 et 3 ans (R25), avec expiration immédiate en cas de suspicion de compromission.

Trois modifications : changer le groupe, tester PasswordLastSet (modification du mot de passe) au lieu de LastLogonDate, et passer la limite à −365 jours :

$groupe  = "Administrateurs de l'entreprise"          # au lieu de "Admins du domaine"
$membres = Get-ADGroupMember -Identity $groupe -Recursive

foreach ($un_membre in $membres) {
    $user         = Get-ADUser -Identity $un_membre.SamAccountName -Properties *
    $dateDerniere = $user.PasswordLastSet              # au lieu de LastLogonDate
    $limite       = (Get-Date).AddDays(-365)           # au lieu de -180
    if ($dateDerniere -lt $limite) {
        Write-Host "$($user.SamAccountName) - mot de passe inchangé depuis le $dateDerniere"
    }
}

Mission B2 — Renforcer la haute-disponibilité des services web

HAProxy répartit la charge (Round-Robin) entre plusieurs serveurs web : il absorbe les pics de trafic sans saturer un serveur unique, assure la continuité pendant pannes ou maintenance, et apporte de la sécurité (détection/blocage des DDoS et force brute, journalisation des intrusions). Il supprime le point de défaillance unique (SPOF) côté serveurs web.

Mais un HAProxy seul redeviendrait lui-même un SPOF : s’il tombe, tout le portail est inaccessible. On double donc les HAProxy (actif/passif avec IP virtuelle / VRRP) pour qu’un second répartiteur prenne le relais → haute disponibilité de bout en bout.

Un certificat émis par une AC publique reconnue est automatiquement validé par les navigateurs des administrés (chaîne de confiance pré-installée). Il garantit l’authentification du site (vrai portail, pas un site usurpé), le chiffrement des échanges (données personnelles, bancaires) et aucune alerte de sécurité côté usager. Un certificat auto-signé déclencherait un avertissement et casserait la confiance — inacceptable pour un service public ouvert au grand public.

Stratégie	Où placer le certificat	Jusqu’où le flux est chiffré
A — Terminaison TLS	Sur les serveurs HAProxy (le déchiffrement se fait au niveau du répartiteur)	Chiffré du client jusqu’au HAProxy ; en clair entre HAProxy et serveurs web (VLAN 55 interne). Permet à HAProxy d’inspecter/router le HTTP.
B — Pass-Through	Sur les serveurs web (le HAProxy ne déchiffre pas, il achemine)	Chiffré de bout en bout, du client jusqu’aux serveurs web ; HAProxy relaie le flux TLS sans le lire.

Les serveurs web ont migré dans le VLAN 55 SERVEURS_WEB. Il faut ouvrir le flux HTTPS/HTTP des HAProxy (DMZ) vers ce VLAN. À ajouter à la table (mode stateful, retour implicite) :

N°	Action	Protocole	Source	Port source	Destination	Port dest.
11	Pass	TCP	HAProxy (DMZ 172.16.0.0/16)	any	VLAN55 SERVEURS_WEB	https (443)

(Si terminaison TLS — stratégie A —, le backend peut être en http (80) : adapter le port destination en conséquence.)

Mission B3 — Sécuriser le réseau local de la bibliothèque

a) Évènements observés dans la capture Wireshark + cause probable

Des milliers de trames identiques : il s’agit d’une rafale de paquets SYN vers le serveur (10.15.0.253) sans le ACK final du 3-way handshake. C’est une attaque par inondation SYN (SYN flood), un déni de service (DoS) : le serveur réserve une connexion pour chaque SYN reçu et épuise sa table de connexions. Cause possible : un abonné malveillant branché physiquement sur une prise RJ45 de la bibliothèque.

b) Conséquences sur les services de la bibliothèque

Le serveur, saturé, devient lent voire indisponible : l’application de gestion des prêts et le partage de fichiers entre employés ne répondent plus → interruption de service au guichet, impossibilité d’enregistrer prêts/retours.

a) Actions à entreprendre sur le commutateur pour sécuriser les 42 prises

1. Activer le port-security sur les 42 interfaces (fa0/1 à fa0/42), en mode access.
2. Apprendre automatiquement les MAC autorisées avec sticky (la 1ʳᵉ machine connectée) → pas de collecte manuelle des MAC.
3. Limiter à 1 adresse MAC par port (un seul poste par prise).
4. Définir une réaction en cas de violation (shutdown ou restrict).
5. Désactiver (shutdown) les 4 prises inutilisées (B39–B42, soit fa0/39 à fa0/42).

b) Commandes CISCO

! Sécuriser les prises utilisées B01 à B38 (fa0/1 à fa0/38)
Switch(config)# interface range fa0/1 - 38
Switch(config-if)# switchport mode access
Switch(config-if)# switchport port-security
Switch(config-if)# switchport port-security maximum 1
Switch(config-if)# switchport port-security mac-address sticky
Switch(config-if)# switchport port-security violation shutdown

! Désactiver les 4 prises inutilisées B39 à B42 (fa0/39 à fa0/42)
Switch(config)# interface range fa0/39 - 42
Switch(config-if)# shutdown

Mission C1 — Analyser et investiguer l’incident

a) Cause première probable : un courriel d’hameçonnage ouvert par un utilisateur du service état-civil, qui a cliqué sur un lien malveillant. Ce lien a déclenché le téléchargement de BazarLoader, première étape de la chaîne d’infection Bazar → Ryuk.

b) Qualification : incident de sécurité confirmé (pas un faux positif). Indicateurs de compromission relevés :

• Connexion sortante vers l’IP 34.217.209.239 = serveur C2 de BazarLoader (cf. document C3, port 443, GET /www/html/var/generic/doc).
• Journaux du poste MAIRIE-SERV-EC-PC06 : présence de C:\PerfLogs\P64.exe et de C:\PerfLogs\comps1524.txt — répertoire, exécutable et fichiers caractéristiques de Ryuk/UNC1878 (document C4).

L’absence de hash Ryuk connu et de clé de registre s’explique : l’attaque est au stade BazarLoader / pré-chiffrement (délai infection→chiffrement de 3 h à 5 jours), d’où l’intérêt d’avoir déconnecté le poste à temps.

c) Autres machines potentiellement impactées : Ryuk se propage latéralement en scannant les plages privées 10.0.0.0/8, 172.16.0.0/16 → 172.31.0.0/16 et 192.168.0.0/16 (ping ICMP puis énumération des partages SMB). À vérifier : tous les serveurs/postes joignables sur ces réseaux, surtout les serveurs de fichiers / partages, et tout hôte ayant joint 34.217.209.239 ou les C2 listés. On recherche les mêmes IOC (P64.exe, comps*.txt, C:\PerfLogs\) dans les journaux centralisés (10.50.1.100).

• Éradication : maintenir le poste isolé ; supprimer les fichiers malveillants (P64.exe, comps*.txt, clé de registre ...\Run\svchost et tâche planifiée), désactiver/réinitialiser les comptes potentiellement compromis (notamment le compte privilégié de propagation), passer un antivirus/EDR à jour.
• Retour à la normale (option la plus sûre) : réinstaller le poste à neuf (réimager) à partir d’une image saine, restaurer les données depuis une sauvegarde propre (Veeam déconnectée) antérieure à l’infection, réinitialiser les mots de passe des comptes concernés, puis remettre le poste en réseau sous surveillance renforcée (vérification d’absence de réinfection / de communication C2).

1. Filtrage de la messagerie : anti-spam/anti-phishing, bac à sable des pièces jointes, réécriture/analyse des URL, blocage des extensions dangereuses.
2. Authentification multifacteur (MFA) sur les comptes (surtout à privilèges) : limite l’impact d’identifiants volés.
3. Réduction de la surface & détection : moindre privilège (pas d’admin local), Application Guard / bac à sable, blocage des IOC connus sur les pare-feux/proxy, et simulations d’hameçonnage régulières pour mesurer et entretenir la vigilance.