Certaines entreprises utilisent des solutions cloud de gestion des informations et des événements de sécurité (SIEM) , tandis que d’autres utilisent un SIEM installé dans un centre de données local. Ces SIEM sur site peuvent fonctionner sur des serveurs Windows, des serveurs Linux, ainsi que dans des machines virtuelles (VM) ou des conteneurs. Même si les vulnérabilités de sécurité propres à chacune de ces instances seront uniques et fortement dépendantes de la configuration, vous pouvez tout de même vérifier votre sécurité à l’aide de la même checklist, dont nous formerons l’acronyme VIDA DUCA pour les étapes ci-dessous :
- Vulnérabilités
- Intégrations
- Paramètres par défaut
- Alertes
- Sources de données
- Utilisateurs
- Configurations
- Niveaux d’accès
Chaque élément de la checklist rappelle qu’il faut traiter une source potentielle de vulnérabilités. Cette checklist doit être utilisée lors de l’installation initiale, puis pour les mises à jour régulières et périodiques (trimestrielles, annuelles). Son application aidera votre équipe à se concentrer sur les moyens par lesquels la sécurité de l’implémentation du SIEM de votre entreprise pourrait être compromise.
Découvrez notre sélection des meilleures solutions SIEM
Vulnérabilités
Des vulnérabilités peuvent se trouver dans n’importe quel programme, application ou système. Pour les systèmes (serveurs, VM, etc.) qui hébergent votre SIEM, les vulnérabilités proviennent le plus souvent d’erreurs ou de problèmes négligés lors de l’installation. Il faudra atténuer les vulnérabilités non corrigées, et des correctifs devront être appliqués avant d’exposer votre système SIEM à des connexions externes.
Vous pouvez utiliser des tests d’intrusion et des tests de vulnérabilité pour localiser les vulnérabilités connues, mais de nouvelles vulnérabilités zero-day pourraient encore être découvertes à l’avenir. Malheureusement, la plupart des entreprises ne disposent pas des ressources nécessaires pour tester minutieusement les logiciels ou le matériel à la recherche de vulnérabilités. Vous devrez donc peut-être compter sur des chercheurs pour découvrir les vulnérabilités et les signaler. Une fois le signalement effectué, vos fournisseurs (SIEM, système d’exploitation, etc.) peuvent publier des correctifs et des mises à jour, qui doivent être appliqués dès que possible pour éliminer ces vulnérabilités.
À lire également : Tester et évaluer les systèmes SIEM : analyse de Rapid7 InsightIDR
Intégrations
Pour être utiles, les SIEM doivent s’intégrer à de nombreux systèmes différents : terminaux, IoT, serveurs, équipements réseau, VM, ressources cloud, et bien plus encore. Chaque type d’appareil doit pouvoir envoyer ses journaux au SIEM pour analyse, et chaque système nécessite une intégration. Si certains appareils peuvent s’intégrer directement, beaucoup d’autres nécessitent l’écriture de code spécifique pour extraire et ingérer les données des journaux.
Cet élément de la checklist nous rappelle qu’il faut considérer chaque point d’intégration comme un point de défaillance potentiel du SIEM, qui doit faire l’objet d’une double vérification. Vous devez contrôler la sécurité de l’intégration et tester votre code au moyen d’un test d’intrusion ou d’une revue de code.
Dans un souci de pragmatisme, il est préférable de donner la priorité aux systèmes présentant les risques les plus élevés. Quelle intégration se connecte aux actifs ou processus métier les plus précieux ? Lesquelles se connectent au plus grand nombre de sous-systèmes similaires ?
Paramètres par défaut
De nombreux SIEM sont fournis avec des configurations par défaut, dont certaines peuvent être manifestement incorrectes et peu sûres. Vous devez examiner attentivement tous les paramètres par défaut conservés et évaluer leur impact sur la sécurité.
Tous les paramètres par défaut ne sont pas évidents. Vous devrez peut-être explorer en profondeur les menus imbriqués d’options ou vérifier les fichiers de configuration liés au logiciel. Assurez-vous d’aborder ce sujet avec votre fournisseur de SIEM lors de l’installation, afin de savoir quoi vérifier ultérieurement. Demander à votre fournisseur une checklist de ses paramètres par défaut à suivre constitue une requête tout à fait raisonnable.
Alertes
Après la configuration initiale, vous commencerez à ingérer des données et le système commencera à produire des alertes. Félicitations ! Le vrai travail peut maintenant commencer. Les SIEM existent pour générer des alertes, et vous devez faire en sorte que ces alertes soient utiles.
En matière d’alertes, vous devez prendre en compte quatre questions principales dans le cadre d’un cycle itératif.
- Quelles alertes êtes-vous censé recevoir ?
- Quelles alertes recevez-vous réellement ?
- Quelles alertes souhaitez-vous recevoir ?
- À partir de combien d’alertes y en a-t-il trop ?
Commencez par examiner les paramètres du SIEM. Vous savez quelles alertes, selon vous, ont été configurées, mais les recevez-vous réellement ? Ces alertes vous informent-elles effectivement de ce que vous aviez prévu ?
Lorsque vous examinez les alertes, appliquez la même hiérarchisation fondée sur les risques que lors de l’intégration. Recevez-vous des alertes concernant les actifs les plus précieux ? Recevez-vous des alertes lorsqu’un élément menace le processus métier le plus important ? Si ce n’est pas le cas, vous devez ajouter ce qui manque.
Vous pouvez également simuler des événements pour vérifier que les alertes attendues sont bien déclenchées. Si ce n’est pas le cas, pourquoi ? Le problème vient-il du paramètre ou de la simulation ? Répétez l’opération jusqu’à recevoir régulièrement les alertes souhaitées pour tous les systèmes requis.
Le coût constitue également un facteur majeur pour les alertes. Les SIEM facturent souvent leurs services en fonction du volume de données transmis au système ; de nombreuses organisations choisissent donc de filtrer les alertes avant de les envoyer au SIEM. Vous devrez examiner ces filtres de présélection et vous assurer que les données et alertes écartées sont réellement inoffensives, et non des éléments sur lesquels vous devriez entraîner vos algorithmes d’intelligence artificielle (IA).
Une fois que vous commencez à recevoir les alertes souhaitées, vous devez vérifier le volume d’alertes que vos analystes de sécurité devront surveiller et traiter. Générez-vous tellement d’alertes que certaines sont ignorées ? Existe-t-il des alertes non critiques qui ne font qu’ajouter du bruit ? Pour éviter de générer trop d’alertes, envisagez d’autres alertes potentielles qui pourraient être plus utiles à surveiller.
Une fois votre SIEM correctement réglé, vous pouvez le tester avec une équipe violette. Dans ce type de test, une partie de l’équipe joue le rôle traditionnel de l’équipe rouge et tente de déclencher des alertes. Ensuite, la partie de l’équipe qui jouait le rôle de l’équipe bleue s’assoit avec l’équipe rouge et examine les résultats. Les alertes se sont-elles déclenchées comme prévu ? Le SIEM ou l’équipe de sécurité ont-ils interprété les données et les alertes comme ils auraient dû le faire ? Toute anomalie doit être examinée et corrigée.
Sources de données
Notre SIEM utilise les données qu’il reçoit pour prendre des décisions. De mauvaises données peuvent entraîner de mauvaises décisions ou des alertes manquées. Lorsque vous démarrez le SIEM, vous ne pouvez pas supposer que vos terminaux sont en bon état. Certaines alertes du SIEM peuvent être déclenchées uniquement par une modification de l’état d’un terminal ; si les terminaux démarrent dans un état compromis et le restent, aucune alerte ne sera générée.
Les contrats intelligents des systèmes blockchain présentent un problème similaire. Ils parlent du problème de l’« oracle ». Si votre source de données, votre « oracle », est corrompue, incorrecte ou contaminée, vous ne pouvez tout simplement pas faire confiance à vos contrats intelligents pour s’exécuter correctement.
Vous pouvez renforcer votre confiance dans la qualité des données transmises au SIEM grâce à des audits de vérification des terminaux. Dans un premier temps, cela peut nécessiter l’audit de chaque système, mais les personnes disposant de peu de temps ou effectuant une mise à jour annuelle ultérieure peuvent plutôt vérifier un échantillon aléatoire de systèmes.
La corruption des données n’est pas la seule manière d’obtenir de mauvais résultats. Si les mauvais fichiers journaux sont récupérés ou si des fichiers journaux incomplets sont générés par vos terminaux, votre SIEM peut parvenir à des conclusions trompeuses. La plupart des SIEM utilisent des algorithmes d’IA ou d’apprentissage automatique (ML) pour apprendre à partir des données. Si ces algorithmes reçoivent le mauvais type de données, cela peut créer des biais difficiles à corriger.
Les membres des équipes informatiques et de sécurité ne sont généralement pas des data scientists et peuvent ne pas comprendre comment les paramètres des fichiers journaux peuvent fausser les algorithmes du SIEM. Pour gérer ce problème, vous devrez intégrer des data scientists à votre équipe ou communiquer avec votre fournisseur de SIEM. Cette communication doit avoir lieu dès les premières phases de la configuration.
Utilisateurs
Le nombre d’utilisateurs de votre SIEM doit être limité, et celui des utilisateurs administrateurs doit l’être encore davantage. Pour déterminer qui sont vos utilisateurs, tenez compte de leur nombre, de leur type d’accès et de leur formation.
Vous aurez peut-être besoin de nombreux utilisateurs pour contribuer à l’intégration et à la mise en œuvre de tous les systèmes lors de l’installation initiale, mais beaucoup d’entre eux n’auront pas besoin d’un accès permanent. Le nombre d’utilisateurs permanents doit être limité aux experts internes et externes qui doivent modifier, vérifier ou gérer le SIEM.
Certains utilisateurs peuvent uniquement avoir besoin de vérifier que les flux de données sont corrects et ne nécessiter durablement qu’un niveau d’accès en lecture seule basique. D’autres peuvent devoir ajuster les alertes ou modifier les algorithmes du SIEM et nécessiter un niveau d’accès supérieur (voir la section Accès ci-dessous). Comme pour le nombre d’utilisateurs, les utilisateurs disposant d’un accès spécifique doivent être évalués attentivement au début, puis vérifiés périodiquement (chaque trimestre, chaque année, etc.).
Les utilisateurs doivent également être formés avec soin en fonction du niveau auquel ils seront censés intervenir. Une formation approfondie doit être dispensée initialement pour garantir une configuration correcte du SIEM, puis actualisée périodiquement afin de présenter les nouvelles fonctionnalités du SIEM ou de comprendre les types d’alertes générés par les algorithmes d’IA/ML.
Configurations
Les SIEM peuvent être déployés de trois façons :
- Installés sur des serveurs, des VM ou des conteneurs dans le centre de données local
- Installés sur des serveurs, des VM ou des conteneurs cloud
- Sous-traités à un fournisseur de services SIEM (auquel vous envoyez les données)
Quel que soit le choix effectué, les erreurs de configuration peuvent anéantir les capacités et la sécurité du SIEM. En cas d’externalisation, les difficultés liées à la configuration peuvent parfois être transférées au fournisseur de services, mais dans vos propres centres de données, ces responsabilités incombent à votre équipe.
Vous devez verrouiller l’environnement qui héberge le logiciel SIEM comme vous le feriez pour toute autre fonction critique de l’entreprise, telle que Active Directory ou le service de noms de domaine (DNS). Si un acteur malveillant parvient à accéder à vos machines locales, il peut probablement modifier le flux de données entrant dans le SIEM et celui des alertes qui en sortent, ce qui perturberait les processus de sécurité.
Vous devez également vérifier les configurations de votre programme SIEM. De même que vous avez vérifié les paramètres par défaut, vous devez contrôler une deuxième fois les paramètres que vous avez volontairement modifiés. Les avez-vous modifiés correctement pour répondre à vos besoins ? Vous devez vérifier ces paramètres avant la mise en production.
Vous devez également continuer à vérifier les paramètres. Ces paramètres d’installation sont-ils toujours adaptés à l’entreprise lors de votre contrôle, deux ans plus tard ? Votre entreprise ne sera pas statique ; votre SIEM devra donc peut-être lui aussi être ajusté pour suivre son évolution.
Niveaux d’accès
Lors de la mise en place d’un SIEM, ou de tout logiciel sophistiqué, plusieurs niveaux d’accès sont possibles. Du compte utilisateur de base au niveau d’accès administrateur le plus élevé, chaque compte offre un éventail de contrôles et d’accès aux paramètres de sécurité.
Lorsque vous définissez les accès au SIEM, vous devez appliquer le principe du moindre privilège et du zero trust. Pour le mettre en œuvre, vous devez également connaître les niveaux d’accès disponibles dans votre logiciel.
Une fois les possibilités établies, vous devez créer un comparatif des niveaux d’accès : quels paramètres et configurations peuvent être modifiés à chaque niveau d’accès, et quel niveau convient à chaque type d’utilisateur ? Une fois définis, les niveaux d’accès doivent être réexaminés périodiquement afin de vérifier que les mises à jour logicielles n’ont pas modifié la compréhension du fonctionnement du logiciel sous-jacent ni de ses autorisations.
À lire également : Les meilleurs logiciels de gestion des accès à privilèges (PAM)
Réussir la mise en place de son SIEM
Les SIEM sont des outils remarquablement utiles. Ils sont flexibles, puissants et peuvent fournir des informations essentielles sur l’état de l’infrastructure d’une organisation. Toutefois, une mise en œuvre inadéquate peut induire les équipes de sécurité en erreur, leur faire perdre du temps à traquer de fausses alertes et leur faire manquer des menaces de sécurité importantes. Utiliser cette checklist peut être un moyen pratique d’examiner systématiquement la mise en œuvre et les paramètres d’un SIEM, et d’éviter des problèmes ultérieurs.
Pour aller plus loin : Une société d’investissement a créé son propre SIEM. Voici comment.