Sécurité réseau des collectivités : plan de 90 jours

La sécurité réseau des collectivités commence par le service public qui doit continuer à fonctionner. Une règle de pare-feu qui interrompt une réparation urgente de logement ou un traitement de recettes crée un problème immédiat, même si son intention est légitime. Un plan utile relie chaque action réseau à un responsable métier, une dépendance vérifiée et une décision de rétablissement.

Les fondamentaux de sécurité réseau du NCSC abordent inventaire, restrictions d’accès, architecture et surveillance. Ils expliquent aussi que la segmentation contrôle les échanges entre réseaux plus petits. Le programme proposé ci-dessous applique ces principes à un déroulement municipal original, avec des exemples fictifs qui ne décrivent aucun résultat client.

Son périmètre couvre les réseaux administratifs et applications de service public. Les systèmes industriels nécessitent une analyse spécialisée. Les responsabilités diffèrent entre collectivités françaises, conseils britanniques et autres municipalités européennes : cartographiez les services effectivement exploités, délégués ou mutualisés.

Partir du parcours usager pour retrouver les dépendances

Choisissez un parcours dont l’interruption a une conséquence compréhensible. Dans notre collectivité fictive, un habitant signale un défaut dangereux dans son logement. Un agent évalue le signalement, une entreprise reçoit un ordre d’intervention et l’habitant obtient une notification de rendez-vous. Le service aboutit lorsque la bonne équipe reçoit cet ordre, pas lorsque le portail affiche un succès.

Dessinez les dépendances : hébergement public, authentification des agents, gestion des dossiers, transfert des ordres, connexion du prestataire et notifications. Ajoutez les services communs, notamment DNS et chemin réseau entre application métier et serveur d’intégration. Distinguez les dépendances transportant des informations sur les habitants de celles qui permettent seulement une connexion.

Pour chaque dépendance, conservez une fiche courte :

Service : réparations urgentes des logements
Dépendance : transfert des ordres d’intervention
Responsable métier : responsable du service logement
Exploitant applicatif : équipe identifiée du prestataire
Exploitant réseau : infogérant de la collectivité
Signe de panne : ordre accepté mais non transmis
Secours : dispatch téléphonique validé, puis rapprochement
Créneau : convenu hors pic de traitement
Vérification : ordre fictif reçu puis annulé

Les dossiers de test ne doivent pas déclencher un déplacement réel. Le service logement valide leur identification et leur suppression. Une capture réseau ne permet pas à un ingénieur de déduire cette précaution métier.

Répétez l’exercice sur un premier ensemble limité : recettes, canal essentiel de contact avec les habitants et service logement sélectionné. Étendre des exemples validés est préférable à une cartographie générale que personne ne sait vérifier.

Attribuer chaque dépendance à des personnes capables de décider

Séparez responsabilité du service et capacité à modifier l’équipement. L’infogérant possède parfois le pare-feu, un autre prestataire administre l’application et la collectivité contrôle les identités. Aucun ne peut confirmer seul qu’une modification convient à l’ensemble du parcours usager.

Désignez qui accepte l’impact métier, qui réalise la modification et qui vérifie le résultat. Ajoutez des suppléants. Cet annuaire doit fonctionner hors horaires habituels et rester disponible si la plateforme collaborative de la collectivité tombe en panne.

Si un prestataire possède l’équipement, transmettez une demande délimitée par le canal convenu. Joignez fiche métier, source, destination, comportement attendu, tests de réception et déclencheur du retour arrière. Exigez la référence de configuration appliquée et les preuves de vérification. « Le prestataire gère le réseau » ne distingue pas une restriction approuvée d’une dépendance inconnue.

Traitez une responsabilité absente comme un risque métier, avec décideur et date de réexamen. Ne rendez pas tacitement l’équipe réseau responsable d’une application qu’elle ne peut administrer. Le cycle de contrôle des accès prestataires développe les mesures propres à ces interventions.

Une dépendance commune nécessite plusieurs validations métier. Modifier une authentification partagée peut affecter logement, médiathèques et centre de contact, même si la demande vient du logement. Joignez les services concernés au changement et prévoyez une transaction représentative pour chacun. Si un métier ne fournit ni test ni suppléant, rendez cette incertitude visible avant approbation. L’exploitant doit savoir s’il faut reporter la modification commune, séparer les interventions ou poursuivre selon une décision consignée. L’absence de réponse d’un autre service ne prouve pas que son activité continuera. Vérifiez également les créneaux où chaque équipe peut constater un échec et participer au rétablissement.

Jours 1 à 15 : connaître les connexions et les services indispensables

Commencez par les éléments disponibles : inventaires, configurations de pare-feu, identités, documentation applicative et journaux représentatifs. Comparez-les. Un équipement absent de l’inventaire mais présent dans une route active ou un journal d’authentification doit être étudié avant d’être considéré comme obsolète.

Datez les observations et précisez leur niveau de confiance. La documentation décrit un fonctionnement prévu ; un journal montre un fonctionnement observé sur sa période. Aucun ne garantit qu’un export trimestriel ou une procédure d’urgence apparaît dans l’échantillon. Interrogez les métiers sur les traitements rares.

Tenez une liste courte des dépendances à éclaircir. Chaque entrée comporte question, responsable et preuve recherchée. Par exemple : « L’export des recettes utilise-t-il encore cette destination en fin de mois ? » Évitez le fichier interminable d’adresses IP inconnues sans priorité.

Recueillez aussi le statut de support et le responsable des mises à jour des équipements concernés. Une exposition urgente et confirmée peut imposer une action avant la fin de la cartographie. Utilisez alors la procédure d’incident ou de changement urgent, avec le responsable métier. Le calendrier de 90 jours ne justifie aucun report automatique.

Le premier résultat attendu est une carte permettant d’expliquer une panne. Mettez-la à l’épreuve : si le transfert des ordres perd sa connexion, qui le remarque, qui rétablit la liaison et comment les réparations urgentes continuent-elles ?

Jours 16 à 30 : réduire une exposition précise

Choisissez quelques modifications dont l’objectif et les conséquences sont explicites : route prestataire expirée, interface d’administration accessible depuis le réseau bureautique ou règle autorisant une plage beaucoup plus large que nécessaire.

Décrivez pour chacune le chemin indésirable et celui qui doit subsister. « Renforcer le logement » ne suffit pas. « Autoriser le serveur d’intégration vers le point d’accès approuvé et interdire l’interface d’administration depuis le réseau invité » permet une vérification.

Validez les dépendances avant de retirer l’ancien chemin. Si une règle paraît inutilisée, vérifiez que les journaux couvrent les refus, les traitements périodiques concernés et le trajet complet. Une absence de preuve appelle une observation ou un test encadré ; elle ne démontre pas que la règle est inutile.

Avant le créneau, identifiez la personne réalisant le retour arrière. Conservez la configuration précédente par un mécanisme approuvé et vérifiez qu’elle pourra joindre l’équipement même si la nouvelle règle coupe l’administration habituelle. Fixez un critère d’arrêt : transaction fictive échouée ou hausse inexpliquée des erreurs d’intégration.

Datez les exceptions et leur justification. Une autorisation accordée un mois à une application ancienne doit revenir devant un décideur, plutôt que devenir une route permanente sans propriétaire.

Jours 31 à 60 : démontrer le cloisonnement

Choisissez une frontière autour d’un service ou d’une fonction d’administration. Précisez les connexions qui la traversent, leur nécessité et le point où elles sont contrôlées. Des noms de VLAN distincts ne prouvent rien à eux seuls. La réception doit démontrer les chemins permis et interdits.

Réalisez des contrôles autorisés et non destructifs depuis des emplacements représentatifs. Pour le service logement fictif, le dossier de réception prévoit notamment :

• Un agent termine la transaction fictive convenue dans l’application habituelle.
• Le serveur d’intégration transmet cette transaction par la destination et le protocole prévus.
• Un poste de test du réseau invité ne peut atteindre l’interface d’administration.
• Le chemin prestataire atteint sa cible autorisée et échoue vers une cible du service recettes sans rapport avec l’intervention.
• DNS, authentification, supervision et sauvegarde restent fonctionnels dans le périmètre prévu.
• L’exploitant démontre le retour à la configuration précédente lors d’un exercice contrôlé ou d’une vérification de récupération équivalente.

Pour un refus, distinguez une décision du contrôle de sécurité d’une cible simplement indisponible. Conservez la référence de règle ou une autre preuve du mécanisme appliqué. Pour une action autorisée, observez aussi le résultat applicatif : une connexion établie ne prouve pas l’aboutissement du parcours usager.

Notre guide de détection des mouvements latéraux détaille les investigations entre systèmes. Ici, la question de réception est plus délimitée : ce compte ou ce poste peut-il traverser cette frontière au-delà de sa fonction approuvée ?

Évitez de modifier toutes les frontières simultanément. Testez un service, observez son activité habituelle et examinez les erreurs avec son responsable. Reportez les corrections de dépendances dans le changement suivant au lieu de reproduire une mauvaise règle partout.

Faire répondre les journaux à une question d’investigation

Avant d’acheter du stockage, choisissez une question utile. Par exemple : « Quelle identité interne ou prestataire a utilisé le chemin d’administration du logement entre la maintenance et le premier ordre échoué ? » Il faut alors rapprocher identité, accès distant, application et réseau.

Pour chaque étape, identifiez les champs disponibles : heure, fuseau, source, destination, compte, décision et référence de politique lorsque possible. Vérifiez la synchronisation des horloges et les effets de la traduction d’adresses. Une IP publique partagée ne désigne pas un agent sans éléments complémentaires.

Testez la recherche d’un événement connu. Notez son délai, la personne habilitée et l’éventuelle assistance nécessaire du prestataire. Le guide pour corréler une alerte IOC avec IP, DNS et processus explique la contribution propre à chaque type d’observation.

Définissez la conservation selon l’usage et la politique approuvée : période interrogeable, archives, délai de récupération, habilitations et suppression pour chaque source. Associez les responsables de gouvernance des données et les fonctions juridiques lorsque nécessaire. Tout conserver indéfiniment ne remplace pas l’identification des preuves utiles.

Énoncez les limites de couverture. « Aucune activité correspondante dans sept jours de journaux de passerelle » ne décrit ni les semaines antérieures, ni une autre route, ni une application sans audit. Pour réexaminer un renseignement récent dans des événements anciens, utilisez les distinctions temporelles du guide de rétrochasse IOC.

Jours 61 à 90 : exercer la continuité et décider du travail restant

Simulez une panne traversant les frontières contractuelles. Dans notre collectivité fictive, le prestataire applicatif répond, mais le contact réseau habituel est indisponible. Demandez au suppléant de retrouver la modification approuvée, les journaux et la procédure de retour arrière. Cet exercice révèle une difficulté différente du simple blocage d’un paquet.

Testez ensuite le fonctionnement de secours avec les agents du logement. Vérifiez comment les demandes urgentes sont enregistrées, qui autorise leur transmission téléphonique et comment les dossiers sont rapprochés après rétablissement. Évitez les fichiers personnels improvisés contenant les informations des habitants.

Évaluez le rétablissement selon l’interruption et le retard de traitement acceptés par le métier. Une connexion rétablie peut laisser des dossiers en attente ou des notifications en double. Ces conséquences font partie de la récupération, même lorsque le réseau fonctionne à nouveau.

Lors du bilan, présentez frontières vérifiées, transactions démontrées et dépendances encore inconnues. Comptez les services ayant un secours testé, les routes prestataires avec responsable actuel et les modifications disposant de preuves. Indiquez dénominateur et exclusions : trois services validés ne constituent pas une assurance sur tout le parc.

Le format du rapport de threat intelligence destiné à la direction aide lorsqu’un problème réclame une décision budgétaire ou métier. Précisez conséquence opérationnelle, options et échéance de décision.

Ajouter la réputation là où elle éclaire une action

Une destination publique associée à une activité suspecte nécessite du contexte avant tout changement. Notez date de connexion, fonction de la destination et date du renseignement. Hébergement partagé, réattribution d’une IP et changement d’infrastructure fournisseur peuvent modifier l’interprétation.

Pour une première vérification IsMalicious, choisissez une IP publique ou un domaine appartenant à la collectivité et dont l’évaluation est autorisée. Consultez le rapport d’indicateur, puis joignez le résultat daté à la fiche métier. N’envoyez ni nom interne, ni secret, ni paramètre d’URL propre à un habitant.

Si l’enrichissement répété est utile, définissez les besoins du pare-feu ou de la plateforme d’investigation existante : indicateurs acceptés, fraîcheur, expiration, responsable de révision et correction des faux positifs. Le protocole d’évaluation des flux aide à mesurer les décisions réellement améliorées.

La prochaine modification réseau doit laisser une trace concrète : service public identifié, approbateur nommé, action technique délimitée, preuve du fonctionnement attendu et personne capable de rétablir l’état précédent.