Everest — SISR, session 2025

Mission A1 — Audit de l’authentification (Active Directory)

1. Comptes à privilèges trop nombreux / mal maîtrisés (membres des groupes d’administration) → surface d’attaque élevée sur le domaine.
2. Politique de mots de passe faible (mots de passe anciens, jamais expirés, comptes inactifs non désactivés) → comptes facilement compromis.
3. Mécanismes Kerberos/d’authentification faibles (ex. comptes avec délégation, chiffrement faible, Kerberoasting possible) → vol d’identifiants. (On justifie chaque point par le score/élément du rapport.)

Si toutes les machines partagent le même compte administrateur local et le même mot de passe, alors la compromission d’un seul poste (récupération du condensat) permet à l’attaquant de se connecter en administrateur sur toutes les autres machines (propagation latérale, attaque pass-the-hash). Un seul maillon faible compromet tout le parc.

LAPS attribue à chaque machine un mot de passe administrateur local unique, renouvelé automatiquement et stocké dans l’AD. On configure : activation de la gestion du mot de passe, complexité (majuscules/minuscules/chiffres/spéciaux), longueur suffisante, durée de vie/expiration (rotation régulière), et restriction des lecteurs autorisés (seuls les administrateurs habilités peuvent lire le mot de passe). Justification : chaque poste a un secret distinct → fin de la propagation latérale.

Mission A2 — Interconnexion VPN IPSEC

• Accès Internet direct depuis KliK : moins de latence, ne charge pas le lien VPN ni le lien Internet de Lyon (meilleures performances).
• Navigation via le VPN jusqu’à Lyon : filtrage et contrôle centralisés (un seul point de sortie sécurisé, journalisation et politique de sécurité uniformes).

a) Pour contrôler/limiter Internet : déployer un proxy filtrant (listes d’autorisation/interdiction) et journaliser l’activité via le pare-feu.

b) Recommandation CNIL : le contrôle de la connexion Internet des salariés doit rester proportionné, faire l’objet d’une information préalable des salariés (et consultation du CSE), sans surveillance individuelle permanente et excessive.

Mission A3 — Administration réseau (Cisco Meraki)

1. Dépendance au cloud Cisco : l’administration (et la configuration) passe par le cloud Meraki ; une panne ou une compromission du cloud impacte la gestion de tous les équipements.
2. Surface d’attaque externe : les données de configuration sont hébergées chez l’éditeur et l’accès se fait via Internet → exposition supplémentaire, perte de maîtrise par rapport à un équipement administré localement et isolé.

Selon l’alerte CERT-FR, l’exploitation peut permettre une prise de contrôle de l’équipement, un accès non autorisé au réseau d’Everest (rebond vers les ressources internes), une fuite de données de configuration et/ou un déni de service (coupure de l’accès Internet des sites concernés).

Mission B1 — Gérer les risques (Syslog)

a) L’attaque par rejeu sur le serveur de journaux a une gravité importante (atteinte à l’intégrité de la preuve), mais une probabilité faible si les recommandations ANSSI sont appliquées → on qualifie la criticité selon l’échelle AFNOR en croisant ces deux axes.

b) Le niveau de risque AFNOR qui en découle est modéré (gravité forte × vraisemblance faible).

Syslog en mode natif (souvent UDP, en clair) est vulnérable :

• Falsification/injection de journaux → atteinte à l’intégrité (un attaquant peut effacer ses traces ou injecter de faux événements).
• Perte de messages / inondation → atteinte à la disponibilité (journaux manquants, collecteur saturé).

Les certificats permettent :

• l’authentification (le client et le serveur de collecte prouvent leur identité) ;
• la confidentialité (les journaux sont chiffrés en transit via TLS) ;
• l’intégrité (toute altération du flux est détectée).

a) Si tous les journaux sont transmis : risque de saturation (volume, bande passante, stockage) et de bruit noyant les événements importants.

b) Si seules les erreurs sont transmises : on perd le contexte et des événements de sécurité utiles (connexions, élévations de privilèges) → angles morts dans l’analyse.

a) Erreur de fonctionnement du noyau : facility kern (0), severity err (3) → PRI = 0 × 8 + 3 = 3. Sélecteur : kern.err.

b) Élévation de privilèges (événement de sécurité grave) : facility authpriv (10), severity alert (1) → PRI = 10 × 8 + 1 = 81. Sélecteur : authpriv.alert.

Mission B2 — Positionnement du serveur de journaux

À Bordeaux : les équipements émetteurs (périphériques : pare-feu, commutateurs, serveurs) et un relais local qui agrège et transmet. À Lyon : le collecteur central (serveur NEPTUNE) qui reçoit et stocke. Le relais assure la résilience en cas de coupure du lien vers Lyon.

Placer le serveur de collecte dans un VLAN dédié (réseau d’administration/logs), cloisonné par filtrage : seuls les flux Syslog (TLS) entrants et l’administration sécurisée y sont autorisés.

Utiliser un filtrage basé sur la source (nom d’hôte / adresse IP de l’émetteur) : on crée une règle (template) qui range chaque message dans un dossier par agence selon l’hôte d’origine. Justification : l’arborescence par agence facilite l’exploitation et l’attribution.

a) Le serveur de supervision (SIEM) exploite et corrèle les journaux fournis par le serveur de journalisation → ils collaborent (collecte ↔ analyse/alerte).

b) Deux arguments pour séparer les deux fonctions : sécurité/intégrité des preuves (un serveur de logs dédié et durci préserve la valeur probante, indépendamment de la supervision) et répartition de la charge (volumes de logs élevés → ne pas pénaliser la supervision).

Sur Cisco IOS, une gravité strictement inférieure à 5 correspond au niveau warnings (4) et au-dessous :

configure terminal
 logging host <IP_NEPTUNE>        ! collecteur central à Lyon
 logging trap warnings            ! niveaux 0 à 4 (gravité < 5)
 logging on
end

Mission B3 — Sauvegardes

• 2 supports différents : si un type de support se corrompt, l’autre reste intègre.
• 1 copie hors site : protège contre un sinistre local (incendie, vol).
• 1 copie hors ligne / immuable : protège contre le rançongiciel (la sauvegarde déconnectée ne peut pas être chiffrée).
• 0 : zéro erreur après test de restauration (la sauvegarde est vérifiée).

Ces éléments limitent le risque de corruption des supports de sauvegarde et garantissent une restauration fiable.

Les journaux contenant l’identifiant, la date/heure de connexion et les opérations des internautes sont des données personnelles : il faut une durée de conservation limitée et proportionnée, une information des personnes (finalité de la journalisation), un accès restreint et sécurisé, et la minimisation des données collectées.