Optimisez au maximum vos pare-feu : conseils avancés en matière de sécurité

Au-delà de la configuration par défaut

Les configurations par défaut des pare-feu existent pour une raison précise : elles permettent de faire fonctionner les systèmes rapidement, avec un minimum de friction. Toutefois, elles ne constituent qu’un point de départ, non une fin en soi. Les jeux de règles par défaut fournis avec la plupart des dispositifs pare-feu sont conçus pour fonctionner dans une grande variété d’environnements. Ils privilégient la connectivité plutôt que la sécurité, autorisant un accès étendu qui simplifie le déploiement initial. Conserver ces paramètres inchangés crée une exposition inutile.

Optimiser l’efficacité d’un pare-feu implique de dépasser les paramètres par défaut. Cela signifie comprendre les schémas spécifiques de trafic du réseau à protéger et adapter les règles en conséquence. Cela signifie appliquer le principe du moindre privilège non seulement en théorie, mais aussi dans la pratique : autoriser uniquement ce qui est explicitement requis et refuser tout le reste. L’effort requis est modeste comparé à l’amélioration de la sécurité obtenue.

Hygiène des jeux de règles : éliminer les éléments superflus accumulés

Les jeux de règles d’un pare-feu ont tendance à croître de façon organique au fil du temps. Une règle temporaire ajoutée pour une visite d’un fournisseur devient permanente. Une règle de test pour une nouvelle application reste en place longtemps après que l’application soit passée en production. Les exceptions s’accumulent, chacune ajoutant de la complexité et un risque potentiel. Le résultat est un jeu de règles que personne ne comprend entièrement et qui contient bien plus d’autorisations que nécessaire.

Des révisions régulières des jeux de règles permettent de résoudre ce problème. Le processus est simple : exporter le jeu de règles actuel, documenter précisément la fonction de chaque règle, vérifier si chaque règle est toujours nécessaire, puis supprimer ou resserrer celles qui ne le sont plus. La première révision produit souvent la plus forte réduction : de nombreuses organisations constatent qu’elles peuvent éliminer ou regrouper 20 à 30 % de leurs règles. Les révisions ultérieures détectent les petites accumulations avant qu’elles ne deviennent importantes.

La journalisation : l’outil de diagnostic sous-utilisé

Les journaux des pare-feu contiennent une mine d’informations souvent inexploitée dans de nombreux déploiements. Chaque connexion autorisée, chaque tentative bloquée et chaque correspondance avec une règle génère une entrée dans les journaux. Ces journaux documentent les schémas normaux de trafic, révèlent les activités inhabituelles et fournissent des preuves en cas de problème. Pourtant, de nombreuses organisations considèrent la journalisation comme une simple case à cocher pour la conformité, plutôt que comme un outil opérationnel.

Une gestion efficace des journaux commence par la compréhension de ce qui est journalisé. Tous les événements ne nécessitent pas le même niveau de détail. Journaliser chaque connexion autorisée dans un environnement à fort trafic crée des problèmes de stockage. En revanche, journaliser uniquement les connexions bloquées et les événements inhabituels fournit des renseignements exploitables sans surcharge inutile. L’essentiel consiste à configurer correctement les niveaux de journalisation : suffisamment détaillés pour être utiles, mais suffisamment sélectifs pour rester gérables. Des examens réguliers des journaux, même brefs, permettent de détecter des problèmes que les alertes automatisées pourraient manquer.

Inspection des protocoles industriels : Au-delà des règles basées sur les ports

Les règles classiques de pare-feu, fondées sur les numéros de port, n’offrent pas une protection adéquate pour les réseaux industriels. Un attaquant peut envoyer des commandes Modbus malveillantes via le port 502 — le port standard Modbus — et une règle basée sur le port les laissera passer sans problème. Le pare-feu détecte le bon port et autorise le trafic sans examiner son contenu.

Les dispositifs pare-feu industriels dotés d’une inspection sensible au protocole analysent le contenu des messages des protocoles industriels. Ils comprennent la structure des requêtes Modbus, l’ensemble des commandes Profinet et le format des données EtherNet/IP. Cette compréhension leur permet d’identifier des anomalies — par exemple, une commande Modbus d’écriture adressée à un registre en lecture seule, une séquence de commandes qui ne correspond pas aux schémas opérationnels habituels, ou un message dépassant des limites raisonnables de taille. Ces anomalies indiquent souvent soit une mauvaise configuration, soit une attaque en cours. L’inspection sensible au protocole permet de détecter les deux cas.

La norme IEC 62443 exige explicitement ce type d’application restreinte des flux de données entre zones. Les règles basées sur les ports ne satisfont pas aux exigences de la norme. L’inspection sensible au protocole, elle, y répond. Les organisations soumises à des obligations de conformité doivent vérifier que leurs dispositifs pare-feu prennent en charge cette fonctionnalité et qu’elle est correctement configurée.

Redondance et basculement : prévoir l’inévitable

Les dispositifs pare-feu finiront inévitablement par tomber en panne. Les alimentations électriques se dégradent. Les mises à jour du micrologiciel échouent. Des erreurs de configuration empêchent l’accès des administrateurs. La question n’est pas de savoir si une panne se produira, mais bien de savoir si le réseau reste protégé lorsqu’elle se produit.

Les configurations à haute disponibilité résolvent ce problème en couplant des dispositifs pare-feu selon des architectures actif-passif ou actif-actif. Dans une configuration actif-passif, un dispositif gère l’ensemble du trafic tandis que le second reste en attente. En cas de défaillance du dispositif actif, le dispositif passif prend le relais avec une interruption minimale. Dans une configuration actif-actif, le trafic est réparti entre les deux dispositifs, assurant à la fois l’équilibrage de charge et la redondance.

L’effort de configuration n’est pas négligeable. Les tables d’état doivent être synchronisées entre les dispositifs afin que les connexions actives subsistent lors d’un basculement. Le routage doit tenir compte du changement de dispositif actif. Les tests doivent vérifier que le basculement fonctionne comme prévu. Cet effort porte toutefois ses fruits lorsque, à 2 h du matin, une alimentation électrique tombe en panne et que la production se poursuit sans interruption.

Un scénario concret : l’accès à distance, bien mis en œuvre

Une entreprise de distribution d’eau desservant une zone métropolitaine de taille moyenne devait offrir un accès à distance aux fournisseurs d’équipements et aux entrepreneurs chargés de la maintenance. La solution initiale reposait sur un appareil VPN doté de règles d’accès larges : tout utilisateur authentifié pouvait accéder à n’importe quel dispositif du réseau OT. Ce dispositif fonctionnait, mais créait une exposition importante. Un compte fournisseur compromis aurait permis d’accéder à l’ensemble du système de commande.

L’entreprise a repensé son architecture d’accès à distance en utilisant des pare-feu dotés de contrôles d’accès granulaires. Chaque fournisseur n’a reçu l’accès qu’aux systèmes spécifiques qu’il devait prendre en charge. Les entrepreneurs chargés de la maintenance ne pouvaient atteindre que les équipements situés aux sites dont ils assuraient le service. Le pare-feu appliquait ces restrictions au niveau du réseau, complétant l’authentification fournie par le VPN par des règles d’autorisation limitant les actions concrètes autorisées pour chaque utilisateur authentifié. Ce nouveau dispositif a considérablement réduit la surface d’attaque, sans ajouter de complexité pour les utilisateurs légitimes.

Surveillance et alertes qui aident réellement

Les dispositifs pare-feu génèrent des alertes pour une raison précise : attirer l’attention sur des événements nécessitant une enquête. Or, la fatigue liée aux alertes est bien réelle. Trop d’alertes, surtout de faible qualité, conduisent à ignorer les notifications et à manquer des incidents. Une alerte efficace exige un réglage fin : réduction des faux positifs, hiérarchisation des événements critiques et garantie que les alertes parviennent aux bonnes personnes.

Commencez par classer les alertes selon leur gravité. Les modifications de configuration, les connexions administratives et les défaillances critiques exigent une attention immédiate. Des échecs répétés de connexion depuis des adresses externes justifient une enquête, mais pas nécessairement une alerte à 2 h du matin. Les pics de trafic vers des destinations inhabituelles se situent quelque part entre ces deux extrêmes. Cette classification doit refléter la tolérance au risque et les contraintes opérationnelles de l’organisation. Une usine fonctionnant 24 heures sur 24 a des besoins en matière d’alertes différents de ceux d’un réseau de bureau actif uniquement en journée.

Des sessions régulières d’analyse des alertes, menées hebdomadairement ou mensuellement, permettent d’identifier des tendances que les alertes individuelles ne révèlent pas. Une série d’alertes de faible gravité provenant de sources différentes peut, prise dans son ensemble, indiquer une attaque coordonnée. Ce processus d’analyse fournit également des retours utiles pour l’ajustement des paramètres : les alertes qui s’avèrent systématiquement sans pertinence peuvent être supprimées ou reconfigurées.