On administre un parc de pare-feux Stormshield, on reçoit des centaines de milliers de lignes de logs par jour, et la question finit toujours par tomber : faut-il se contenter du SVC fourni par l’éditeur ou monter une architecture de visibilité plus large ? Derrière l’acronyme SVC Center, certains désignent le Stormshield Visibility Center lui-même, d’autres cherchent un centre de supervision capable d’aller au-delà. Cet article détaille les différences concrètes entre ces deux approches, du périmètre fonctionnel jusqu’à l’intégration SOC.
SVC comme source de télémétrie réseau, pas comme plateforme SOC
Le Stormshield Visibility Center est une appliance virtuelle qui collecte les journaux syslog des pare-feux Stormshield et les restitue dans une interface web basée sur Kibana et Elastic Search. On déploie la machine virtuelle, on configure la redirection syslog depuis chaque firewall SNS, et on obtient des tableaux de bord personnalisables pour visualiser les flux réseau, les connexions bloquées ou autorisées, et les règles de filtrage sollicitées.
Le périmètre s’arrête là. SVC ne corrèle pas les événements entre sources hétérogènes. Il ne remonte pas d’alertes enrichies par de la threat intelligence, ne déclenche pas de playbooks automatisés, et n’ingère pas les logs d’un EDR, d’un proxy ou d’un Active Directory. Son rôle reste celui d’un outil d’analyse de journaux pare-feu, pensé pour les gammes d’entrée et moyenne (du SN160 au SN910 selon la documentation VemoTech).
Quand on parle de « SVC Center » au sens large, on pense souvent à un centre de visibilité qui agrège la télémétrie de plusieurs couches de sécurité. La confusion vient du fait que SVC produit de la donnée réseau exploitable par un SIEM ou un XDR, mais il n’est pas lui-même un SIEM ni un XDR.
Ouverture API et export vers un SIEM tiers : ce que SVC permet vraiment
Depuis 2024, Stormshield a renforcé l’ouverture de son écosystème pour permettre l’export des événements pare-feu vers des plateformes SOC tierces. Concrètement, on peut rediriger les logs syslog collectés par SVC vers un SIEM externe (type Rapid7, SentinelOne ou un collecteur SOAR) via des connecteurs ou des flux syslog chaînés.
Cette capacité repositionne SVC dans une architecture de cybersécurité plus large :
- SVC centralise et normalise les journaux des firewalls Stormshield Network Security avant de les transmettre à une couche d’analyse supérieure.
- Le SIEM ou la plateforme XDR corrèle ces données réseau avec d’autres sources (endpoints, serveurs, cloud) pour produire des alertes contextualisées.
- Les tableaux de bord Kibana de SVC restent disponibles pour l’analyse locale rapide, le tuning de règles de filtrage ou le diagnostic d’un incident réseau spécifique.
Dans cette logique, SVC devient un capteur réseau au sein d’un SOC unifié, pas le centre de commandement. La distinction est importante pour dimensionner correctement son infrastructure de supervision.
Règles de filtrage et diagnostic opérationnel : le vrai terrain de jeu de SVC
Là où SVC se distingue, c’est sur le travail quotidien de l’administrateur réseau Stormshield. On déploie une nouvelle application, la matrice de flux est incomplète ou inexistante, et on a besoin de comprendre quels ports, quelles IP sources et destinations sont réellement sollicités.
La méthode classique consiste à poser des règles de filtrage permissives temporaires, laisser le trafic passer, puis analyser dans SVC les logs correspondants pour identifier précisément les flux légitimes. On affine ensuite les règles pour ne garder que les ouvertures strictement nécessaires. Ce workflow de durcissement progressif est le cas d’usage principal de SVC sur le terrain.
Configuration du firewall pour alimenter SVC
Le paramétrage passe par la redirection syslog depuis l’interface d’administration SNS vers l’adresse IP de l’appliance SVC. On accède ensuite au menu de configuration SVC en SSH (commande svc-configurator), on définit les sources syslog et le format de log attendu. Les retours varient sur la stabilité de l’ingestion selon le volume de logs et la version du firmware SNS, mais le processus reste documenté dans le guide d’administration officiel Stormshield.
Un centre de visibilité SOC complet n’offre pas ce niveau de granularité sur les règles pare-feu Stormshield. Il traite les alertes à un niveau supérieur, sans proposer le même workflow de tuning de politique de filtrage.
Choisir entre SVC seul et une architecture de visibilité étendue
Le choix dépend du périmètre de protection et de la maturité de l’équipe sécurité. Voici les critères concrets qui orientent la décision :
- Si le parc se limite à quelques pare-feux Stormshield et que le besoin porte sur l’analyse des flux réseau et le tuning de règles, SVC couvre le périmètre sans couche supplémentaire.
- Si on doit corréler les événements réseau avec des données endpoint, cloud ou applicatives, SVC doit alimenter un SIEM ou une plateforme XDR en amont.
- Si l’organisation dispose d’un SOC (interne ou externalisé), SVC sert de source de données réseau parmi d’autres, pas de console principale de supervision.
La question du licensing entre aussi en jeu. SVC est distribué avec les produits Stormshield Network Security, tandis qu’un SIEM tiers implique un coût supplémentaire lié au volume de données ingérées et au nombre de sources connectées. Le marché des outils de firewall management a évolué vers des modèles de tarification indexés sur le volume, ce qui rend la comparaison budgétaire indispensable avant de superposer les couches.
En résumé, SVC et un centre de visibilité SOC ne jouent pas sur le même terrain. Le premier est un outil d’exploitation réseau spécialisé Stormshield, le second une plateforme de détection et de réponse multi-sources. Bien positionner SVC comme capteur réseau dans une architecture plus large évite de lui demander ce qu’il n’a pas été conçu pour faire, et permet de tirer le meilleur de chaque brique de cybersécurité.
