2 Un data lake de sécurité est un référentiel central qui stocke de grands volumes de télémétrie de sécurité, comme les journaux, les événements des postes de travail, les flux réseau et les pistes d’audit cloud, dans des formats ouverts sur un stockage évolutif, afin que de nombreux outils puissent l’interroger. Il est apparu parce que les plateformes SIEM traditionnelles peinent à absorber le coût d’ingestion et de conservation de tout ce que collectent désormais les équipes de sécurité. Plutôt que de faire passer chaque journal par le SIEM et de l’y garder pendant des années, les organisations conservent l’historique complet dans le data lake et utilisent le SIEM pour la détection en temps réel sur les données les plus importantes. Cet article explique ce qu’est un data lake de sécurité, son lien avec le SIEM, les formats et l’architecture qu’il utilise généralement et les critères qui déterminent son emplacement : cloud public, sur site ou les deux. Pour les exigences de conservation des journaux qui orientent souvent la décision, voir combien de temps conserver les journaux de sécurité. Pourquoi les data lakes de sécurité existent La télémétrie de sécurité a crû bien plus vite que les budgets de sécurité. La détection et réponse sur les terminaux (EDR), les journaux d’audit cloud, les fournisseurs d’identité, les applications SaaS et les sondes réseau produisent tous de grands volumes de données. Les plateformes SIEM sont souvent facturées au volume ingéré ou à la puissance de calcul, et garder un an ou plus de données volumineuses consultables peut coûter très cher. Il en résulte un compromis bien connu : les équipes abandonnent des sources de données, raccourcissent la conservation ou filtrent agressivement, puis manquent des données nécessaires lors des enquêtes. Un data lake de sécurité sépare le stockage de l’analytique, pour que les données puissent être conservées à un coût raisonnable et interrogées au besoin. Data lake de sécurité et SIEM Un SIEM et un data lake de sécurité remplissent des fonctions différentes : Le SIEM se concentre sur la corrélation en temps réel, les règles de détection, les alertes, la gestion des incidents et la recherche rapide dans les données récentes. Le data lake de sécurité se concentre sur le stockage à long terme et économique de grands volumes de télémétrie, l’interrogation flexible, la chasse aux menaces sur de longues périodes et l’alimentation de l’analytique ou du machine learning. Beaucoup d’organisations utilisent les deux : les données à forte valeur alimentent le SIEM pour la détection, tandis que toutes les données, sources à forte valeur comprises, arrivent dans le data lake pour la conservation et la chasse aux menaces. Certaines plateformes SIEM interrogent désormais directement les données du data lake. Comment se construit un data lake de sécurité La couche de stockage À la base se trouve le stockage objet, qui offre un faible coût au téraoctet, une montée jusqu’au pétaoctet et l’API S3 qu’attendent les moteurs analytiques. Le stockage objet permet aussi l’immuabilité, essentielle pour les preuves de sécurité. Des formats de fichiers et de tables ouverts Les données sont généralement stockées dans des formats en colonnes comme Apache Parquet, qui se compressent bien et permettent aux requêtes de ne lire que les colonnes nécessaires. Les formats de tables ouverts ajoutent des fonctions comme l’évolution du schéma, le partitionnement et le voyage dans le temps aux fichiers stockés en mode objet, ce qui rapproche le data lake d’une base de données tout en gardant les données dans des formats ouverts. Voir les formats de tables ouverts sur S3 sur site. Un schéma commun Les données de sécurité proviennent de nombreuses sources aux noms de champs différents. Les normaliser selon un schéma commun rend possibles les requêtes croisées. L’Open Cybersecurity Schema Framework (OCSF), projet open source soutenu par plusieurs éditeurs de sécurité, est une option très discutée, et certaines organisations utilisent les schémas définis par leur SIEM ou leurs propres standards. Le pipeline d’ingestion Les pipelines collectent les données des sources, les analysent et les normalisent, les enrichissent d’informations de contexte comme les actifs et les identités, puis les écrivent dans le data lake dans les formats retenus. Ils peuvent aussi acheminer une partie des données vers le SIEM. La couche de requête et d’analytique Moteurs SQL, notebooks, outils de chasse aux menaces et plateformes de machine learning interrogent le data lake. Comme les données sont dans des formats ouverts, plusieurs moteurs peuvent lire les mêmes données sans les copier. Ce que permet un data lake de sécurité Une conservation plus longue à moindre coût, au service de la conformité et des enquêtes sur les intrusions de longue durée. La chasse aux menaces sur des mois ou des années de données. Des enquêtes sur incident qui remontent jusqu’à la compromission initiale. L’ingénierie de détection, en testant de nouvelles règles sur les données historiques. L’analytique et le machine learning sur de grands jeux de données. La liberté de choix des outils, sans dépendance à un seul éditeur d’analytique. Où placer un data lake de sécurité ? Cloud public Le stockage objet cloud et les services de requête managés permettent de démarrer rapidement et conviennent aux organisations dont la télémétrie est surtout native du cloud. Les points d’attention sont le coût de stockage récurrent à mesure que les données grossissent, les frais de requête et de transfert, la résidence des données et l’effort nécessaire pour déplacer plus tard de gros volumes. Sur site Un stockage objet sur site garde les données de sécurité dans les installations de l’organisation, ce qui compte pour les secteurs réglementés, l’administration et les organisations soumises à de fortes exigences de souveraineté. Les coûts sont prévisibles, sans frais par requête ni frais de sortie lorsque les analystes lancent de grandes recherches. Cela demande une planification de la capacité et de l’exploitation. Les principes de conception généraux sont présentés dans l’analytique big data et le stockage objet (en anglais). Hybride Beaucoup d’organisations combinent les deux : la télémétrie cloud arrive dans un data lake cloud, la télémétrie sur site dans un data lake sur site, ou l’un sert d’archive à long terme à l’autre. Les formats ouverts rendent ces architectures hybrides possibles, car les données peuvent être interrogées sur place ou déplacées sans conversion. Les critères qui déterminent l’emplacement L’origine de la majeure partie de la télémétrie et le coût de son déplacement. Les exigences de résidence et de souveraineté des données. La durée de conservation et le volume, qui déterminent le coût de stockage à long terme. Les schémas de requêtes : de grandes recherches fréquentes favorisent un stockage sans frais par requête. Les compétences et l’infrastructure existantes. La sécurité du data lake lui-même, y compris qui peut y accéder et comment il est isolé. Sécuriser le data lake de sécurité Un data lake rempli de télémétrie de sécurité est une cible de grande valeur. Il contient des informations sur l’infrastructure, les utilisateurs et les défenses de l’organisation. Les protections comprennent : Un contrôle d’accès strict, selon le moindre privilège et séparé de l’administration de la production. L’immuabilité (en anglais) des données brutes, pour que les attaquants ne puissent pas effacer les preuves. Le chiffrement au repos et en transit, avec une gestion des clés (en anglais) rigoureuse. La journalisation d’audit des accès au data lake lui-même. La minimisation des données et des limites de conservation pour les données personnelles. Le lien avec les niveaux de stockage du SIEM De nombreuses plateformes SIEM peuvent déjà placer les données tièdes sur un stockage objet et ne garder qu’un cache sur leurs indexeurs. Un data lake de sécurité peut compléter ce dispositif en conservant des données brutes ou normalisées dans des formats ouverts, pour d’autres outils et une conservation plus longue. Certaines organisations utilisent la même plateforme de stockage objet pour les deux, avec des buckets et des politiques distincts. Les facteurs de coût à modéliser L’économie d’un data lake de sécurité repose sur quelques variables. La capacité de stockage croît avec l’ingestion et la conservation, même si la compression en colonnes réduit souvent fortement le volume par rapport aux journaux bruts. Le calcul pour les requêtes est utilisé par rafales, pendant les chasses et les enquêtes, plutôt qu’en continu. Le traitement des pipelines ajoute un coût proportionnel à l’ingestion. Dans le cloud public, les frais de requêtes et de transfert peuvent être importants pour les gros balayages ; sur site, les principaux coûts sont le matériel, l’énergie et l’exploitation, répartis sur la durée de vie de la plateforme. Une comparaison utile consiste à calculer le coût par téraoctet conservé et par an dans le data lake et dans le SIEM, pour les mêmes données. Ce chiffre justifie généralement de déplacer vers le data lake les sources volumineuses à plus faible valeur, tout en gardant dans le SIEM les sources essentielles à la détection. Par où commencer Une démarche pragmatique : Identifier les sources volumineuses qui coûtent cher à conserver dans le SIEM. Définir les exigences de conservation et de schéma. Mettre en place un stockage objet et un format de table ouvert. Construire les pipelines pour quelques sources et valider les requêtes. Acheminer les données essentielles à la détection vers le SIEM et toutes les données vers le data lake. Étendre progressivement les sources, l’analytique et la conservation. Liste de contrôle : planifier un data lake de sécurité Définir les rôles du data lake aux côtés du SIEM. Choisir des formats ouverts et un schéma commun. Sélectionner un stockage objet évolutif qui prend en charge l’immuabilité. Décider d’un emplacement cloud, sur site ou hybride selon le coût, la résidence et les schémas de requêtes. Construire des pipelines d’ingestion avec normalisation et enrichissement. Sécuriser le data lake par le contrôle d’accès, le chiffrement et la journalisation d’audit. Fixer la conservation par type de données et automatiser la suppression. Tester chasses et enquêtes sur de longues périodes. En résumé Un data lake de sécurité donne aux équipes de sécurité un accès abordable et durable à toute leur télémétrie dans des formats ouverts, en complément d’un SIEM centré sur la détection en temps réel. Il repose sur un stockage objet, dans le cloud, sur site ou les deux, et le bon emplacement dépend de l’origine des données, des exigences de résidence, du volume conservé et de la fréquence à laquelle les analystes interrogent l’historique. Construisez-le avec des formats ouverts, protégez-le aussi soigneusement que n’importe quel système de production et laissez-lui porter la charge de conservation que le SIEM ne peut pas assumer. Questions fréquentes Qu’est-ce qu’un data lake de sécurité ? Un référentiel central de télémétrie de sécurité, stockée dans des formats ouverts sur un stockage évolutif et interrogée par plusieurs outils pour la chasse aux menaces, les enquêtes et l’analytique. Un data lake de sécurité remplace-t-il un SIEM ? En général non. La plupart des organisations utilisent le SIEM pour la détection en temps réel et le data lake pour la conservation à long terme et l’analyse étendue. Quels formats utilisent les data lakes de sécurité ? Le plus souvent des formats de fichiers en colonnes comme Parquet, des formats de tables ouverts et un schéma commun comme OCSF. Un data lake de sécurité doit-il être dans le cloud ou sur site ? Cela dépend de l’origine de la télémétrie, des exigences de résidence, des volumes de données et des schémas de requêtes. Beaucoup d’organisations adoptent une approche hybride. Comment protéger un data lake de sécurité ? Par un contrôle d’accès strict, l’immuabilité des données brutes, le chiffrement, la journalisation d’audit et la minimisation des données. Pour aller plus loin Conservation des journaux de sécurité Data lake ou entrepôt de données (en anglais)
