SIEM : La Banque de France fait l’expérience de la complexité de mise en oeuvre

Le choix d’une solution évolutive 

La contrainte des délais a conduit Jean-Marc Cir et ses équipes à se tourner vers le catalogue de l’Ugap et, partant, vers Sentinel de NetIQ. Cette solution a notamment été retenue pour son évolutivité, tant technique que commerciale : «elle s’appuie sur des collecteurs déportés et on peut donc faire évoluer l’architecture à mesure que l’on étend le périmètre couvert», mais également segmenter les rôles des serveurs entre consolidation et corrélation/présentation.  Des serveurs peuvent également être ajoutés pour gérer la croissance de la charge. En outre, «les licences sont facturées en fonction du nombre d’incidents par seconde traités» et donc, encore une fois, en fonction du périmètre concerné. Ce qui a permis à la Banque de France de commencer «avec une architecture vraiment minimaliste», centrée sur quelques serveurs Unix, quelques pare-feux, le système de gestion des identités des accès (IAM) et, surtout, l’application «très sensible» Target II - «un système reliant des banques centrales européennes et qui gère en temps réel toutes les opérations en règlement brut ». Pour l’heure, l’application traite 350 000 opérations par jour pour un volume de l’ordre de 200 Md€. 

Une mise en oeuvre difficile 

Compte tenu de la culture maison et de la sensibilité des applications, l’externalisation n’était pas envisageable. Mais le déploiement en interne n’a pas été un long fleuve tranquille. Jean-Marc Cir le reconnaît volontiers : «honnêtement, tout seul, ce n’est pas possible.» Et de saluer la disponibilité et la réactivité des équipes de NetIQ, tout en soulignant l’importance du «balisage du périmètre couvert» et de la «définition de l’architecture» : des étapes qu’il qualifie de «fondamentales. Si c’était à refaire, j’y consacrerai plus de temps, quitte à finir en retard ». 

Sentinel n’est ainsi pas livré sous forme d’appliance mais d’application. Et là, la configuration joue un rôle clé. Les services de NetIQ ont ainsi été fortement impliqués dans l’optimisation du système d’exploitation utilisé par le serveur Sentinel pour améliorer l’utilisation de la mémoire vive ou encore réduire les pertes de traces, notamment sur l’agent Snare pour Windows - utilisé dans l’attente de Sentinel 7.1. 

Mais les équipes de NetIQ sont également intervenues pour développer un parser de traces pour les équipements de Palo Alto - module désormais intégré à l’offre Sentinel et à son cycle de développement. Mais à la mise en production début janvier, la solution n’était pas encore totalement satisfaisante. Finalement, c’est un sous-dimensionnement de l’architecture qui a été diagnostiqué et il a été décidé de dissocier, sur deux serveurs, la collecte, d’une part, et le reporting et la présentation, d’autre part. Une architecture effectivement déployée depuis la fin mai. Entre temps, le module de présentation avait dû être désactivé. 

La version 7.1 de Sentinel devrait sensiblement améliorer la situation avec une capacité de traitement bien supérieure, à configuration égale, et l’intégration d’agents pour les serveurs Windows supportant le parsing, la compression et le chiffrement des traces remontées. 

De premiers résultats 

Si Jean-Marc Cir fait état de résultats pour l’heure limités, il souligne des apports techniques : «cela nous a permis d’identifier des manques d’optimisation dans la configuration de pare-feux qui renvoyaient des quantités considérables d’événements.» Un lot deux doit consister en un élargissement du périmètre, avec tous les serveurs Windows, les anti-virus, les IPS (Intrusion Prevention System), et plus généralement toute l’infrastructure sur laquelle reposent les accès à Internet. Et, pour fiabiliser l’ensemble, la Banque de France prévoit de mettre en place une architecture à haute disponibilité de type actif/actif et distribuée. Surtout, la corrélation des événements de sécurité est attendue avec ce second lot du projet.