Selon le rapport « State of Open Source » d’OpenLogic, 96 % des organisations interrogées utilisent des solutions à code source ouvert (OSS). On trouve de telles solutions dans tous les segments du marché des technologies de l’information, y compris les outils d’infosécurité. Elles sont d’ailleurs souvent recommandées lors de la mise en place de systèmes SIEM.
À première vue, les solutions à code source ouvert semblent être un excellent choix. La fonction première d’un système SIEM est la collecte systématique de télémétrie et la corrélation, que vous pouvez configurer à l’aide d’outils de stockage et de traitement des données bien connus. Il vous suffit de rassembler toutes vos données à l’aide de Logstash, de connecter Elasticsearch, de construire les visualisations dont vous avez besoin avec Kibana, et le tour est joué ! Une recherche rapide vous permettra même de trouver des solutions SIEM à code ouvert prêtes à l’emploi (souvent basées sur les mêmes composants). Avec les SIEM, adapter à la fois la collecte et le traitement des données aux besoins spécifiques de votre organisation est toujours essentiel, et un système à code source ouvert personnalisé offre des possibilités infinies à cet égard. En outre, le coût de la licence est nul. Toutefois, le succès de cette entreprise dépend de votre équipe de développement, des particularités de votre organisation, du temps qu’elle est prête à attendre pour obtenir des résultats et du montant qu’elle est prête à investir dans un soutien continu.
Le temps c’est de l’argent
Une question clé (dont l’importance est constamment sous-estimée) est de déterminer combien de temps il faudra avant que le SIEM de votre entreprise ne soit pas seulement opérationnel, mais qu’il commence à apporter une réelle valeur ajoutée. Les données de Gartner indiquent qu’il faut en moyenne six mois pour mettre en œuvre un SIEM prêt à l’emploi, même avec toutes ses fonctionnalités, et qu’une entreprise sur dix y consacre un an. Et si vous créez votre propre SIEM ou si vous adaptez une solution à code source ouvert, vous devez vous attendre à ce que ce délai double ou triple. Lors de l’établissement du budget, multipliez ce temps par le taux horaire de vos développeurs. Il est également difficile d’imaginer qu’un SIEM à part entière puisse être mis en place par une seule personne talentueuse – votre entreprise devra disposer d’une équipe entière.
Un piège psychologique courant consiste à se laisser tromper par la rapidité d’élaboration d’un prototype. Il est possible de déployer une solution à code source ouvert prête à l’emploi dans un environnement de test en quelques jours seulement, mais la rendre de qualité industrielle peut durer des mois, voire des années.
Pénuries de compétences
Un SIEM doit collecter, indexer et analyser des milliers d’événements par seconde. La conception d’un système à forte charge, ou même l’adaptation d’un système existant, requiert des compétences particulières et très demandées. Au-delà des développeurs, le projet aurait besoin d’administrateurs informatiques, d’ingénieurs DevOps, d’analystes et même de concepteurs de tableaux de bord hautement qualifiés.
Les créateurs de SIEM doivent également surmonter le manque d’expérience pratique nécessaire pour rédiger des règles de normalisation efficaces, des logiques de corrélation et d’autres contenus fournis par les solutions SIEM commerciales. Bien entendu, même ce contenu prêt à l’emploi requiert des ajustements significatifs, mais il est à la fois plus rapide et plus facile de l’adapter aux normes de votre organisation.
Conformité
Pour de nombreuses entreprises, disposer d’un système SIEM est une exigence réglementaire. Les entités qui conçoivent elles-mêmes un SIEM ou mettent en œuvre une solution à code source ouvert doivent déployer des efforts considérables pour se mettre en conformité. Elles doivent elles-mêmes adapter les capacités de leur SIEM aux exigences réglementaires, contrairement aux utilisateurs de systèmes commerciaux, qui sont souvent dotés d’un processus de certification intégré et de tous les outils nécessaires pour assurer la mise en conformité.
Parfois, la direction peut vouloir mettre en œuvre un SIEM simplement pour « cocher une case », dans le but de minimiser les dépenses. Cependant, étant donné que la norme PCI DSS, le RGPD et d’autres cadres réglementaires locaux exigent une mise en œuvre complète et efficace du SIEM, et non sa présence symbolique, un système SIEM installé pour faire bonne figure échouerait à tout audit.
La mise en conformité n’est pas une question à prendre en compte uniquement au moment de la mise en œuvre. Si, pendant la maintenance et l’exploitation autonomes, certains composants de votre solution cessent de recevoir des mises à jour et atteignent leur fin de vie, vos chances de réussir un audit de sécurité s’amenuiseraient considérablement.
Dépendance du fournisseur ou dépendance des employés
La deuxième raison la plus importante pour laquelle les organisations envisagent une solution à code ouvert a toujours été la flexibilité dans l’adaptation à leurs besoins, ainsi que le fait de ne pas dépendre de la feuille de route de développement et des décisions en matière de licence d’un éditeur de logiciels.
Ces deux arguments sont convaincants et, dans les grandes organisations, ils peuvent parfois l’emporter sur d’autres facteurs. Cependant, il est important de faire ce choix en étant pleinement conscient du pour et du contre :
- Les SIEM à code source ouvert peuvent être plus simples à adapter à des entrées de données uniques.
- Avec un SIEM à code source ouvert, vous gardez un contrôle total sur la manière dont les données sont stockées et traitées.
- Le coût de la mise à l’échelle d’un SIEM à code source ouvert se compose principalement du prix du matériel supplémentaire et du développement des fonctionnalités requises.
- Aussi bien la configuration initiale que l’évolution future d’un SIEM à code source ouvert exigent des professionnels expérimentés qui connaissent bien les pratiques de développement et les réalités des SOC. Si les membres de l’équipe qui comprennent le mieux le système quittent l’entreprise ou changent de poste, l’évolution du système pourrait s’arrêter. Pire encore, le système pourrait se détériorer progressivement.
- Si le coût initial de mise en œuvre d’un SIEM à code source ouvert peut être inférieur en raison de l’absence de frais de licence, cette différence s’érode souvent pendant la phase de maintenance. Cela s’explique par les dépenses supplémentaires continues liées à l’emploi de personnel qualifié dédié exclusivement au développement du SIEM. Sur le long terme, le coût total de possession (TCO) d’un SIEM à code source ouvert s’avère souvent plus élevé.
Qualité du contenu
La pertinence du contenu de détection et de réponse est un facteur clé de l’efficacité d’un SIEM. Pour les solutions commerciales, les mises à jour des règles de corrélation, les guides pratiques et les flux de Threat Intelligence sont généralement fournis dans le cadre d’un abonnement. Ils sont développés par de grandes équipes de chercheurs et font l’objet de tests approfondis, et leur mise en œuvre requiert généralement très peu d’efforts de la part de votre équipe de sécurité interne. Avec un SIEM à code source ouvert, vous êtes livré à vous-même lorsqu’il s’agit de mises à jour : vous devez parcourir vous-même les forums communautaires, les dépôts GitHub et les fils d’information gratuits. Les règles doivent ensuite être examinées minutieusement et adaptées à votre infrastructure, ce qui augmente le risque de faux positifs. Par conséquent, la mise en œuvre des mises à jour dans un SIEM à code ouvert exige beaucoup plus d’efforts de la part de votre équipe interne.
L’éléphant dans la pièce : le matériel informatique
Pour lancer un SIEM, vous devez acquérir ou louer du matériel informatique, et, selon l’architecture du système, le coût peut varier considérablement. Peu importe que le système soit une solution à code ouvert ou une solution commerciale propriétaire. Cependant, si vous déployez vous-même une solution SIEM à code ouvert, vous courez le risque de prendre des décisions architecturales qui ne seront pas optimales. À long terme, une telle approche pourrait entraîner des coûts d’exploitation élevés et récurrents.
Nous couvrons le sujet de l’évaluation des besoins en matériel SIEM en détail dans un article séparé.
Le décompte final
Si l’idée d’une plateforme entièrement personnalisable et adaptable sans frais de licence est très séduisante, il y a un risque important qu’un tel projet demande beaucoup plus de temps et d’efforts à votre équipe de développement interne qu’une solution commerciale prête à l’emploi. Ce choix peut également entraver votre capacité à adopter rapidement des innovations et faire en sorte que votre équipe de sécurité se concentre non plus sur l’élaboration d’une stratégie de détection et de scénarios de réponse, mais sur la résolution de problèmes opérationnels. C’est pourquoi une solution commerciale gérée, soutenue par des experts et bien intégrée rejoint souvent plus étroitement les objectifs d’une organisation typique, à savoir une réduction efficace des risques et une budgétisation prévisible.
Les SIEM commerciaux permettent à votre équipe de tirer parti de règles, de guides et d’analyseurs de télémétrie prédéfinis, ce qui lui permet de se concentrer sur des projets propres à l’organisation, comme la recherche des menaces ou l’amélioration de la visibilité dans l’infrastructure cloud, au lieu de réinventer les fonctions de base d’un SIEM ou de lutter pour réussir un audit réglementaire avec un système développé en interne.