putilov_denis - stock.adobe.com
Ce que tout RSSI devrait considérer avant une migration SIEM
Avant de commencer une migration SIEM, l'équipe de sécurité doit identifier les données, les règles, les flux de travail et les politiques qu'elle doit faire migrer vers le nouvel outil ou service. Voici comment commencer.
Aucune stratégie, plateforme ou service SIEM n'est parfait. Les besoins et les circonstances de l'entreprise changent. Les fournisseurs et les offres évoluent. De nouvelles options apparaissent. Inévitablement, de nombreuses organisations devront finalement migrer de leurs SIEM existants ou de leurs fournisseurs de SIEM vers de nouveaux.
Une fois qu'il a été décidé qu'un nouveau SIEM est nécessaire, le RSSI doit aborder la mise en œuvre de manière stratégique, en veillant à ce que les données, règles, scénarios et workflows importants restent disponibles pendant et après la transition. Une migration SIEM réussie et responsable minimise également les perturbations découlant de la découverte d'intégrations techniques oubliées et d'utilisations non documentées.
N'oubliez pas les données
La sève de toute opération de cybersécurité est la donnée : des données sur les entités dans l'environnement, des données sur ce que ces entités sont et ne devraient pas faire, des données sur la manière dont ces entités se comportent, des données sur l'infrastructure de cybersécurité elle-même et ainsi de suite.
Avant une migration SIEM, les CISO doivent élaborer des plans minutieux pour assurer que les données nécessaires de l'ancienne plateforme sont conservées et utilisables dans la nouvelle. Les données suivantes sont particulièrement importantes :
- Données comportementales des entités. Un environnement de confiance zéro exige trois types de données : des données de politique qui dictent quelles entités sont autorisées à communiquer entre elles ; des données d'identité qui déterminent si une entité est en fait qui ou ce qu'elle prétend être ; et des données comportementales qui montrent comment les entités agissent dans l'environnement et si ces actions dévient des normes de base. Bien que n'étant pas impliquées dans le maintien des données de politique ou d'identité, le SIEM est essentiel pour collecter les données comportementales. Lors du changement d'outils ou de fournisseurs, un RSSI doit s'assurer que l'équipe de sécurité peut conserver et transférer les données comportementales de base pour toutes les entités de l'environnement.
- Données d'application des politiques. Les journaux montrant l'application des politiques de sécurité sont importants pour les enquêtes sur les incidents, la réponse aux incidents et le rapport post-incident. Ces données doivent être transférées vers la nouvelle plateforme SIEM et rester disponibles pendant la migration. À chaque étape de la transition, il doit également être clair pour l'équipe de sécurité quelle plateforme — ancienne ou nouvelle — est la source faisant autorité.
- Données relatives à la conformité. De nombreuses organisations sont tenues par la loi ou la réglementation de conserver des données de journal pertinentes pour la cybersécurité. Par exemple, les services publics d'énergie et les fournisseurs de télécommunications doivent être en mesure de fournir des preuves qu'ils étaient, à un moment donné, conformes à des exigences de sécurité spécifiques dans leurs industries respectives. Assurez la continuité de la collecte des données relatives à la conformité et confirmez que les données historiques de l'ancienne plateforme seront disponibles après la migration — soit par ingestion dans le nouvel outil, soit par le biais d'une plateforme d'archivage.
Emportez avec vous les règles personnalisées, les scénarios et les workflows
Si les données sont la sève de la cybersécurité, l'automatisation devient rapidement son cœur battant. Certaines automatisations SIEM comprennent des éléments manifestement spécifiques au SIEM, tels que — peut-être à la demande d'un autre outil ou d'un opérateur humain, ou peut-être basées sur la fonctionnalité native d'analyse du comportement des utilisateurs et des entités du SIEM — l'instauration d'une surveillance supplémentaire sur une entité réseau qui agit de manière inhabituelle.
De manière moins évidente, de multiples facettes de l'automatisation et des connaissances des processus sont souvent désormais intégrées dans les systèmes et services SIEM, lesquels — comme de nombreux outils de cybersécurité — ont des frontières fonctionnelles poreuses. Les plateformes SIEM peuvent jouer un rôle clé dans la réponse aux incidents, par exemple, et peuvent également servir de référentiels de connaissances institutionnelles sous forme de flux de travail automatisés entre rôles ou équipes. Lors d'une migration SIEM, les RSSI doivent prêter attention à la préservation des informations importantes sur l'automatisation et les processus, telles que les suivantes :
- Règles de détection personnalisées. Les SIEM filtrent les données entrantes pour rechercher des événements et des anomalies notables. Toutes les règles d'analyse d'événements que l'organisation a développées, ou que le fournisseur de services a développées en son nom, doivent être documentées pour être répliquées dans la nouvelle plateforme.
- Préservation des scénarios et workflows spécifiques à l'organisation. Les scénarios de réponse aux incidents définissent les étapes que le personnel et les outils d'automatisation doivent suivre en cas d'incident de cybersécurité suspecté ou confirmé. Les flux de travail automatisent de nombreuses actions et processus dictés par les scénarios, ainsi que les processus opérationnels quotidiens. Assurez-vous que tous les flux de travail et composants de scénarios actifs et pertinents de l'ancienne plateforme SIEM sont répliqués dans la nouvelle. Notez que actifs et pertinents sont des considérations importantes. Une migration SIEM est une opportunité de supprimer les éléments inutiles en laissant derrière soi des workflows ou des scénarios qui ont été remplacés mais pas encore supprimés.
Minimiser les surprises : intégrations oubliées et utilisateurs inconnus
Une migration SIEM teste la capacité de l'organisation de cybersécurité à se connaître elle-même et l'entreprise dans son ensemble. Souvent, le processus de migration réel révèle des intégrations oubliées avec d'autres systèmes de cybersécurité ou des systèmes de gestion de réseau.
De même, il n'est pas rare que d'autres parties prenantes SIEM au sein de l'entreprise soient délogées par la transition. Par exemple, les développeurs d'applications peuvent s'appuyer discrètement sur le SIEM d'une manière auparavant non documentée et ne pas faire connaître leur cas d'utilisation jusqu'à ce que la migration le perturbe.
La découverte tardive d'un groupe dont les besoins auraient dû influencer les exigences pour le nouveau SIEM pourrait entraîner seulement un léger retard dans le calendrier de la migration. Soyez cependant averti, cette négligence peut facilement faire augmenter les dépenses, surtout si les fonctionnalités requises coûtent plus cher sur la nouvelle plateforme, ou si le nouveau SIEM ne peut pas répondre aux besoins du groupe — forçant une nouvelle série de sélection de produits.
John Burke est CTO et analyste de recherche chez Nemertes Research. Burke a rejoint Nemertes en 2005 avec près de deux décennies d'expérience en technologie. Il a travaillé à tous les niveaux de l'informatique, y compris en tant que spécialiste du support utilisateur final, programmeur, administrateur système, spécialiste de bases de données, administrateur réseau, architecte réseau et architecte système.
