Quand on parle d’un SOC, on pense souvent à l’entité qui détecte les incidents et y répond. Cependant, ces incidents n’arrivent pas par magie entre les mains des analystes. Avant même d’être une ou plusieurs alertes de sécurité, un incident est d’abord un simple log perdu parmi des milliards d’autres. La véritable colonne vertébrale d’un SOC commence avant tout par son infrastructure de collecte.
Il existe un grand nombre de solutions pour mettre en place une telle infrastructure, et il est parfois difficile de choisir celle qui répondra parfaitement aux attentes. La solution la plus connue et probablement la plus répandue actuellement reste Logstash. Parmi ses concurrents directs, on peut notamment citer Fluentd (et sa version allégée Fluent Bit) ou Vector (projet open source racheté par Datadog en 2021). En plus de ces applications, il existe aussi des alternatives proposées par certains éditeurs pour faciliter le transfert vers leurs propres solutions, comme le Splunk Forwarder ou le Sekoia Forwarder.
Découvrez les coulisses techniques d’un choix d’architecture crucial avec Loïc Ruat, notre consultant au sein du pôle cyberdéfense – SOC.
Quelles considérations et quels besoins ?
Dans le cas d’un SOC MSSP (Managed Security Service Provider), il est nécessaire de prendre en compte des contextes très variés. Chaque client amène son lot de technologies et de contraintes spécifiques auxquelles l’infrastructure de collecte doit savoir s’adapter. C’est pourquoi le choix technologique est crucial.
Pour chaque contexte, il existe une solution parfaitement adaptée, mais cette dernière n’est pas forcément la meilleure dès lors que l’on passe à une autre technologie ou un autre client. Ce qu’un SOC MSSP recherche avant tout, c’est l’harmonisation de ses solutions afin de faciliter la gestion des problèmes. Ce besoin se rencontre avec celui des bénéficiaires, lesquels attendent un niveau de disponibilité au plus proche des 100%. C’est pourquoi il a fallu trouver une solution reine, qui soit assez flexible pour s’adapter à tous les besoins.
Les choix historiques du SOC Synetis
Lors de la création du SOC Synetis, le choix s’était porté sur Logstash : une solution open source disposant d’une communauté active et, surtout, la plus mature du marché à cette époque. Le cas de figure était simple : les logs arrivent des équipements et sont redirigés vers des instances Logstash par des serveurs qui se chargent du load balancing (dans notre cas, Nginx).
Une fois dans Logstash, deux possibilités s’ouvrent :
- Soit ils visent un SIEM On-Premise : les logs doivent être encapsulés avec un en-tête Syslog et enrichis avec le nom du client pour permettre au SIEM de reconnaître leur provenance.
- Soit les logs sont envoyés vers des solutions XDR cloud : ils doivent alors répondre aux contraintes de la solution, la plupart du temps envoyés par appels d’API HTTP.
C’est là l’une des forces de Logstash, mais aussi l’une de ses faiblesses. Si ses capacités d’enrichissement sont très puissantes, elles sont gourmandes en ressources, au point de créer parfois un retard de traitement. C’est notamment le cas lors de la collecte sur des firewalls, qui ont tendance à envoyer de gros volumes de logs en des temps très courts. En plus d’être peu scalable, le monitoring des différents traitements est assez compliqué et nécessite des développements annexes, ce qui rend la solution peu fiable sur le long terme.
Dans l’optique de croissance du SOC, il était alors nécessaire de trouver une nouvelle solution pour remplacer Logstash. Parmi les solutions à observer, deux ont retenu notre attention : Fluent Bit et Vector.
Fluent Bit
De prime abord, Fluent Bit semblait être le choix le plus simple et rapide à mettre en place. Une architecture conteneurisée, des configurations en YAML, une communauté qui semble active. Les premières configurations se font assez simplement et le transfert des logs est extrêmement rapide. Fluent Bit permet la prise en charge des logs via fichier, flux HTTP ou encore TCP/UDP. Dans notre cas, la majorité des logs réceptionnés par le SOC Synetis passe par des tunnels IPSec.
C’est sur l’output HTTP que l’expérience utilisateur s’est dégradée. Contrairement au flux TCP brut, l’envoi vers une API dans le cloud impose des contraintes de structure et de taille. Nous nous sommes rapidement heurtés à une limitation structurelle de Fluent Bit : la gestion rigide de ses buffers internes pour les requêtes sortantes. Pour chaque log (ou groupe de logs), Fluent Bit doit encapsuler la donnée dans une requête POST. Cependant, la taille maximale du buffer de sortie HTTP est souvent limitée par des paramètres globaux difficilement ajustables sans impacter la stabilité du moteur.
Dans notre cas, dès que les logs dépassaient une certaine taille — ce qui arrive fréquemment avec des événements enrichis ou des logs denses —, Fluent Bit se retrouvait incapable de traiter la charge. Résultat : les logs étaient soit tronqués, perdant ainsi toute valeur pour une analyse de sécurité, soit purement et simplement rejetés, créant des ruptures de visibilité critiques pour un SOC.
Une rigidité de configuration face aux besoins du SIEM
Au-delà de la taille des données, c’est le manque de granularité qui nous a freinés. Là où un outil d’observabilité moderne devrait permettre de manipuler finement les retries, la compression et surtout la mise en mémoire tampon par destination, Fluent Bit reste assez binaire. Face aux API, nous avions besoin d’une souplesse que l’outil ne pouvait nous offrir sans une ingénierie complexe qui venaient alourdir une architecture initialement choisie pour sa légèreté.
Cette opacité sur la gestion de la mémoire lors de pics de charge a fini par transformer ce qui devait être un « simple » forwarder en une boîte noire imprévisible. Comme expliqué plus haut, la flexibilité est l’un des facteurs de décision les plus importants, et les difficultés rencontrées avec Fluent Bit peuvent être un frein majeur à l’intégration des différents clients.
Vector : l’agilité et la performance au rendez-vous
C’est après cette expérience mitigée avec Fluent Bit que notre regard s’est tourné vers Vector. Conçu en Rust, cet outil promettait d’allier la légèreté d’un forwarder à la puissance de traitement d’un moteur de parsing complet. Si le passage de Logstash à Fluent Bit s’était avéré complexe, l’adoption de Vector a radicalement changé la donne.
Une gestion des buffers et une fiabilité à toute épreuve
Contrairement aux limitations structurelles et aux buffers « boîte noire » de Fluent Bit, Vector offre un contrôle total sur sa gestion mémoire. Il propose nativement des mécanismes de mise en mémoire tampon sur disque. En cas de pic de charge ou de micro-coupure de l’API de destination, Vector stocke les logs de manière sécurisée et gère les stratégies de retry. Plus de logs tronqués, plus de pertes de visibilité critiques : la robustesse de l’outil garantit l’intégrité de notre chaîne de collecte.
Une documentation claire et une prise en main accélérée
Le déploiement d’une nouvelle technologie s’accompagne souvent d’une phase de recherche douloureuse. Ce ne fut pas le cas avec Vector, notamment grâce à sa documentation claire, exhaustive et truffée d’exemples concrets.
Pourquoi ne pas avoir choisi les agents éditeurs ?
Une question légitime pourrait se poser : pourquoi ne pas avoir simplement utilisé les agents spécifiques fournis par les éditeurs de nos solutions XDR et SIEM ?
Comme dit auparavant, deux considérations majeures entrent en compte. D’une part la centralisation autour d’un pipeline de collecte majeure, implémentant de la redondance, intégrée à nos processus de PCA/PRA et 100% maîtrisée par l’équipe, aux heures de bureau comme en dehors. D’autre part, la flexibilité est l’un des critères les plus importants. Bien qu’il y ait quelques exceptions, les forwarder d’éditeurs visent à permettre une collecte vers leur propre solution, les rendant peu interopérables avec des solutions concurrentes. En ce sens, Vector nous permet de nous adapter aux demandes des clients, et ce quelle que soit la technologie au bout, avec un objectif de fiabilité au plus proche de l’excellence.
Synetis, une prestation SOC conçue pour être robuste et scalable de bout en bout
Avec ces choix d’architectures réfléchis de bout en bout, le SOC Synetis est plus que jamais prêt à accompagner la croissance de ses partenaires avec une visibilité et une fiabilité optimale, quelles que soient leurs tailles ou leurs contraintes organisationnelles comme techniques.
L’évolution de notre infrastructure de collecte reflète la maturité croissante de notre organisation avec une capacité de traitement récemment augmentée d’un facteur de 10, tout en augmentant la fiabilité de l’ensemble de la chaîne.
En investissant dans un SOC externalisé (ou en cogestion), il est nécessaire de prendre en considération tous les aspects de la prestation, jusqu’aux choix de collecte. Chez Synetis, soyez assuré d’y retrouver fiabilité mais aussi transparence quant à nos convictions et notre stratégie. Que vous ayez une idée claire de votre projet SOC ou que vous cherchiez du conseil dans ce domaine, nos équipes sont à votre disposition pour vous accompagner.
Externalisez la détection pour vous concentrer
sur votre stratégie de sécurité
Loïc RUAT
Consultant sécurité
Cyberdéfense – SOC
