Quelques enjeux pour votre SIEM

Cet article propose d’aborder la thématique du SIEM, afin d’échanger en toute simplicité sur la mise en place d'infrastructures qui cherchent à combiner les ingrédients de la réussite. De la collecte des logs jusqu'aux alertes réelles, comment réussir votre projet SIEM quand il contient quelques complexités ou spécificités : SCADA, IOT, multiples pays, réseaux immenses, infrastructures hétérogènes et distribuées, soucis de débits, liaisons non résilientes, intrusions existantes et inconnues, risques d'espionnage ou de sabotage internes et externes, visiteurs et menaces internes, problèmes organisationnels, faibles moyens, etc.

Cet article vise à offrir un retour d'expérience d'experts opérationnels, mais il doit aussi conserver une taille raisonnable ; nous prendrons donc la liberté de contourner certains détails ou éléments que le lecteur attentif reconnaitra. L'idée n'est donc pas d'aborder tous les points techniques possibles au monde, mais de partager une vue rapide globale. D’autres façons de penser ou discussions pourraient donc exister en dehors de cet article précisément.

1. Préparer son infrastructure

Lorsque vous composez une infrastructure SIEM, de nombreux défis techniques et humains s'imposent, et les outils seuls ne peuvent répondre à tous les besoins. Bien évidemment, dans le meilleur des mondes (possibles), on pourrait prendre son temps, analyser la totalité de l'infrastructure, ou même avoir des budgets et des équipes illimités.

En réalité, lorsqu'une entité souhaite mettre en place un projet SIEM, nous distinguons en général deux cas un peu extrêmes : ceux qui souhaitent un SIEM pour des raisons quelque part « externes » (risques autour de la GDPR, traçabilité/surveillance à justifier pour des problèmes de conformité, etc.), et ceux qui veulent un SIEM pour des usages « internes » (aspects opérationnels de lutte contre l'espionnage, etc.).

Les deux mondes savent se retrouver, mais les parties prenantes sont parfois distinctes, et le sponsor du projet pourra influencer des choix allant jusqu’à la technique. Après une danse complexe entre les acheteurs, les juristes, les dirigeants, les services IT, les équipes SSI, les prestataires, etc., on peut commencer à mettre en place son infrastructure efficace, en optimisant les coûts. Le but est d’éviter le projet se soldant au final par une gestion de faux positifs liés à des spectres techniques imparfaits. Cette efficience est complexe à trouver, et elle peut nécessiter de sacrifier quelques points grâce à une savante alchimie allant du management à la technique.

En guise d'exemples introductifs, voici des questions qui reviennent souvent sur ces aspects : à quoi bon collecter et stocker toutes les alertes de type SYSLOG qui proviennent :

• de switches réseaux avec de nombreuses traces inutiles indiquant que l'interface lambda est up ou down ?
• d'équipements qui n'ont même pas de traces utilisables pour de la cybersécurité (une borne wifi qui ne partage pas d’infos techniques utiles par exemple) ?

Ces deux questions sont assez anodines ou simples, mais c’est exactement le problème de certains projets SIEM : il faut savoir arbitrer, car le projet trop maximaliste pourrait s’éloigner de la réalité opérationnelle. On pourrait vouloir tout conserver, sans regarder le contenu, mais l’entreprise risquerait d’avoir besoin d’une base de stockage potentiellement coûteuse avec une utilité à prouver. Au-delà de ce sujet, ce qu’on illustre ici, c’est l’art du consensus : dans un projet SIEM réussi, on doit rassembler les différentes parties prenantes, avec des experts capables d’honorer et de comprendre les besoins de chacun et du groupe, afin de trouver les plus grands dénominateurs communs offrant la plus large assise de compromis, sur tous les paramètres. Petits exemples :

• les financiers et les dirigeants surveilleront avec justesse les dépenses voire les discours commerciaux ;
• les admins surveilleront l’arrivée d’agents ou de traces dans leurs systèmes, avec la crainte de performances amoindries ou de surplus inutile de travail et de reconfigurations ;
• les développeurs voudront utiliser le SIEM pour faire autre chose que de la sécurité comme du debug ou une « télémétrie propre » ;
• les admins réseaux craindront de voir les bandes passantes occupées par des flux nouveaux ou difficilement calculables à l’avance ;
• les employés seront rencontrés pour justifier la mise en place d’une traçabilité positive qui n’est pas là pour surveiller ce qu’il font, mais qui peut générer des craintes de dérives sur la surveillance ;
• les équipes de sécurité espèreront avoir enfin une vision sur leur parc…

C’est évidemment un art complexe, où le responsable trouvera intéressant de s’entourer de personnes efficaces, humainement respectueuses et positives, en prévision des situations où les rouages historiques et les problèmes culturels (aspects internationaux) peuvent ralentir le projet.

2. Collecter les logs

2.1 Unifier les traces

Lorsque l’on souhaite collecter des logs, le premier problème qui peut exister, c’est la multiplicité des types de composants d’une infrastructure. Ils sont parfois tellement différents, qu’ils vont générer des traces (logs, événements) a priori incompatibles. Certains pionniers ont lancé des pistes pour tenter de les traiter de manière homogène.

Nous citerons déjà l’exemple d’une norme, même si elle est peu adoptée ou connue au niveau des outils commerciaux les plus déployés dans le monde. Elle s’appelle IDMEF, Intrusion Detection Message Exchange Format (RFC 4765, 4766 et 4767) et vise à formater l’ensemble des traces de manière unifiée afin d’optimiser échanges et analyses.

Dans la pratique, quand on a des moyens limités, et qu’on ne veut pas consommer du CPU pour trop retransformer ses propres messages bruts, on essaiera de travailler directement avec ces derniers, sans passer à une grande normalisation spécifique. Donc si vous n’aimez pas certains aspects de XML, vous pourriez ne pas apprécier l’enrichissement et le traitement natif de IDMEF.

Au-delà, que trouvons-nous réellement au niveau des formats propriétaires ? On citera les deux standards du marché : LEEF avec le produit IBM Qradar et CEF avec le produit HP ArcSight. Le lecteur consciencieux pourra étudier les autres formats ouverts (MITRE, DMTF), mais aussi se porter sur des analyses expertes associées, exemple : [FORMATS].

De manière générale, soyez rassurés, tous les produits SIEM vont de toute façon rassembler les traces intéressantes, dans leur format, afin de vous permettre de travailler dessus, que ce soit sur des types connus ou internes, le tout pour vous apporter la meilleure vitesse de traitement, et le meilleur stockage possible.

2.2 Les formats classiques

Supposons que l’on souhaite traiter des logs qui viennent de marques et outils différents : des serveurs, des stations, des routeurs, des switches, des access points, des points d’authentification, des proxies, des antivirus, des produits dans le Cloud… Comment récupérer ces traces et faire un travail efficace ?

En pratique, les solutions SIEM sont en général compatibles avec tous les formats classiques à supporter pour couvrir la plupart des parcs sans risque. En fonction de ses besoins, on s’intéressera donc à la compatibilité d’un SIEM avec des formats et des méthodes de récupérations de logs comme par exemple :

• le syslog, car il est majoritairement supporté par presque tous les produits : l’ancien format BSD (RFC 3164) et le format actuel de l’IETF (RFC 5424, 5425 et 5426) ;
• les événements de type Windows, si ce système d’exploitation est présent (les classiques événements systèmes/applications/sécurité, etc., mais aussi ceux des applications propriétaires intéressantes comme les logs du DNS voire du DHCP, etc.) ;
• les grands standards comme le W3C (Web), le JSON, le XML, le CSV, le traitement des formats de type Clef-Valeur où l’on appréciera le jeu sur les délimiteurs ou les échappements surtout quand on s’installe dans des environnements où n’importe quel type de traces est possible : UCS*, UTF*, etc. ;
• la lecture de lignes à lignes (logs de nombreuses applications) ou parfois la lecture de multilignes, souvent pratique pour gérer du propriétaire voire de l’inconnu ou du spécifique ;
• la possibilité de faire du SQL pour aller taper dans des bases ;
• la possibilité de récupérer des fichiers de traces à distance (FTP (?), SSH/SCP/SFTP, GET/POST…) pour leur traitement et incorporation ;
• les formats propriétaires vus précédemment comme CEF et LEEF.

2.3 D’autres formats

Moins utilisés dans les projets de SIEM faciles, mais parfois présents dans certaines expressions de besoins, on notera la présence de nombreux formats particuliers qui peuvent exister. Sans pouvoir tous les citer, on indiquera en exemple :

• les logs de IBM AIX pour la partie audit (événements du kernel) ;
• les logs de Apple avec son format de fichiers Apple System Log (ASL) ;
• les logs des systèmes SUN pour la partie Basic Security Module utilisée au niveau des audits ;
• le GELF (Graylog Extended Log Format) qui se fait une place en cas d’adoption de Graylog, et de même le GROK lors de l’usage de Logstash ;
• le Netflow qui commence à se faire aussi une place dans certaines infrastructures de type SIEM, afin de mélanger les aspects réseaux pour répondre par exemple à la question : qui a parlé à qui, quand, combien de temps, avec quoi comme « flags » sur la session et quel protocole, ainsi que le nombre et la taille des paquets ;
• les traps SNMP, qui sont très utilisées dans le milieu de la supervision ;
• les logs compliqués issus du monde du Mainframe, toujours très présents dans certains milieux professionnels.

Enfin désormais, de nombreux logs sont mis à disposition dans le Cloud, mais il faut aller les récupérer régulièrement, avec des formats totalement propriétaires, parfois inconsistants. Si une entreprise a une stratégie, par exemple de messagerie et travail collaboratif totalement sous-traité chez un grand constructeur (étranger) qui est leader au niveau mondial, il est fortement conseillé d’aller au moins enregistrer régulièrement les traces de connexions aux boîtes aux lettres, aux répertoires de partage, etc. On sera surpris (ou pas) de se rendre compte que la boîte d’un admin du domaine, ou du PDG, est régulièrement lue la nuit depuis des adresses IP à plusieurs milliers de kilomètres de ces personnes.

2.4 Avec ou sans agent

On sera particulièrement sensible à différentes méthodes pour récupérer les traces à distance sur de multiples sources de données. On citera plusieurs méthodes :

• en mode « agent-less » : vous n’aurez pas besoin de mettre un agent sur la machine qui doit envoyer ses sources, et vous devrez en général juste reconfigurer la source pour qu’elle parle à votre SIEM. Le cas classique, c’est le SYSLOG, où vous allez indiquer à une source vers quelle adresse IP elle doit parler ;
• en mode « agent » : vous devez installer un outil de plus, qui aura pour mission sur la source de récupérer les traces et de les envoyer vers votre SIEM.

Sur certains systèmes d’exploitation, la version native agent-less par exemple avec SYSLOG ne vous conviendra pas, parce que vous avez besoin de renvoyer vos logs d’une façon particulière non supportée nativement, par exemple avec une couche de chiffrement type TLS non proposée par le produit.

Dans ce cas, vous aurez besoin de trouver un agent supporté sur cette plateforme, et c’est lui qui devra assumer l’émission des traces. Cela rajoute un processus non natif à déployer, qu’il faudra alors superviser : sa présence, sa consommation de ressources en local, etc. Certains n’aimeront pas ajouter des processus dans une infrastructure de production existante, et l’on comprendra alors que le mode « agent-less » demeure le plus natif et le plus simple, même s’il n’a peut-être pas certaines fonctionnalités d’un agent.

2.5 Risques sur les limites

Dans les projets SIEM, il peut y avoir une forte dimension économique, notamment sur ce sujet complexe de la récupération des traces. Sans rentrer dans les détails, on citera dans les risques à maitriser :

• le problème de la limite sur le nombre d’événements par seconde (EPS) captés par un SIEM : pouvez-vous accepter le risque de ne pas voir une attaque à cause des licences sur le nombre de lignes lues par votre SIEM ?
• le problème des corrélations : parfois limitées, optionnelles, voire non fournies ou à construire. Pouvez-vous uniquement collecter des traces de multiples sources, sans penser aux règles les plus utiles pour traiter les scenarii d’attaques les plus importants ?

On essaiera d’éviter de mathématiquement faire une intégration par parties, en focalisant sur l’ensemble du projet, et en gardant une cohérence sur l’émission d’un événement, jusqu’à son traitement, afin d’éviter de se retrouver à la fin avec des morceaux incompatibles avec les besoins initiaux.

Le test d’intrusion opportun, final ou régulier, par un tiers indépendant, aidera à valider certains choix, parfois même lors d’une phase d’appel d’offres.

2.6 Choisir son infrastructure

Bien évidemment, on devra déterminer avec la meilleure efficacité possible, une idée globale et détaillée sur les sources d’événements et les débits associés. Prenons un exemple fictif : vous avez des sites dans différents pays, avec des services d’authentification en local.

On voudra (peut-être) éviter d’engorger son réseau mondial, ses liaisons distantes où la bande passante est couteuse (satellite, etc.), tout cela pour ramener du SYSLOG indiquant que le service d’impression vient de démarrer sur la machine d’un stagiaire. On pourra préférer monter des points de collecte astucieusement choisis afin de limiter les effets de bords en cas de coupure, ou pour les aspects bande passante.

Au niveau résilience, il n’est pas rare de devoir assumer des situations complexes. Par exemple, dans certains pays, les liaisons peuvent tomber : sur un navire en mer, sur une usine qui subit temporairement une tempête de sable, ou tout simplement sur des situations classiques de pannes au niveau réseau. Pour tenir compte de la perte d’un brin réseau, cela pourra être parfois plus complexe de passer sur un lien de backup, car ce dernier sera parfois bridé au niveau flux, donc on ne pourra plus agir de la même manière. Il sera parfois très intéressant de faire tourner les corrélations au plus proche des sources pour aller construire les alertes de sécurité. Ces dernières devront être conservées dans un cache de données.

3. Stocker les logs

3.1 Compression, indexation, intégrité

Sans rentrer dans les détails de chaque solution technique possible, une fois la collecte en place, vous aurez forcément des choix à faire sur la façon de les stocker. En organisant de façon efficace ces enregistrements, on prépare déjà la réponse au problème de l'utilisation des logs.

• Si l'on stocke trop de choses, on risque de mettre plus de temps à travailler sur ces éléments.
• Si l'on n'en stocke pas assez, on risque de perdre des données utiles le jour où un incident arrive.
• Si l'on souhaite gagner en efficacité avec une indexation pour habilement creuser dans ces stockages par la suite, on peut aussi parfois rencontrer des préjudices sur la taille occupée.

Bien évidemment, quand on regarde le coût du stockage, on se rend compte qu'il est peut-être très intéressant de compresser ces données plutôt que de tout enregistrer de manière brute.

Néanmoins, pour des raisons juridiques, il faut s'assurer que ce stockage soit effectué sans abimer l’intégrité de ces traces, sans quoi des soucis au niveau preuves existeraient. Heureusement, la compression n'est pas un danger, mais si l'on souhaite ajouter des mécanismes de signatures des messages stockés, pour des raisons essentiellement juridiques ou de confiance (exemple : via du HMAC), on peut rencontrer de vrais problèmes de performances.

Sur un petit réseau, avec peu de logs à stocker, c'est raisonnablement atteint, mais cela coûte un certain temps d’intégration ; sur un grand réseau, avec de très nombreuses données en entrée, le coût de cette signature sera reporté sur le hardware à utiliser (CPU, voire réseau), ainsi que la résilience associée, car certaines solutions nécessitent un aller/retour vers une entité qui signe, et cette dernière devient alors Single Point Of Failure potentiel.

Ce n’est donc pas impossible, et c'est même intéressant (sur papier) de signer tous les logs, mais au niveau opérationnel, pour ceux qui veulent une solution efficace et mesurée par rapport aux vrais risques de sécurité, quand on a réellement beaucoup de traces et d'autres problèmes à traiter, des choix sont à faire.

3.2 Stockage et hardware

Quand on manipule autant de données, on peut aussi souhaiter s'assurer de ne rien perdre. Il faudra alors regarder les aspects coûts :

• souhaite-t-on faire des sauvegardes des disques contenant les traces ?
• souhaite-t-on minimiser le risque de panne sur les disques contenant les traces avec des solutions de type RAID ou autre ?

En général, l'arbitrage n'est pas (que) technique, mais aussi financier sur ce point, et perdre ses logs bruts serait un souci. Il faut a minima avoir les alertes de sécurité stockées ailleurs (tickets d'incidents, alertes correspondant à des analyses de logs brutes, etc.) quitte à amoindrir la panne critique sur les silos de données brutes en frontal sur le terrain.

3.3 Chiffrement et robustesse

Sur un exemple fictif, imaginons ce qu’il se passe quand vous administrez des serveurs SIEM sur des sites à risque, voire dans des pays lointains, par exemple des lieux où vous ne maitrisez pas tous les paramètres, le matériel, les hyperviseurs, le personnel (stagiaires, sous-traitants, nationalités diverses, habilitations non-mandataires, affaires d’espionnage, forte concurrence).

Par défaut, on préfèrera ne pas déployer de SIEM sur des systèmes d'exploitation qui n'ont ni les zones de données chiffrées, ni les zones systèmes chiffrées, sans quoi on baisse le niveau de garantie sur les attaques locales.

De même, les applications et les systèmes d'exploitation ne devraient pas utiliser des couches vulnérables, et il est conseiller de durcir son infrastructure système. On évitera d’avoir des Appliances où tout tournerait sans limitation avec un seul compte (root). Si l’on doit monter un SIEM avec des produits ou des systèmes d’exploitation peu sécurisés, cela peut marcher, mais c'est à nouveau la surface d'exposition qui est plus grande et il vaut mieux toujours minimiser les risques, car on ne sait jamais où on sera ciblé. On fera en sorte de mettre en place de zones différentes, avec des contrôles avancés et réfléchis. On pourra lire les conseils du [PDIS] de l’ANSSI par exemple, avec ses enclaves et sa recherche de maximisation au niveau sécuritaire, en adaptant à sa situation officielle et à ses moyens envisageables.

4. Analyser et alerter

4.1 Analyser les logs

Supposons désormais que l’on dispose de traces intéressantes issues du terrain, stockées de manière intelligente avec des informations utiles et protégées, on voudra pouvoir travailler sur ces éléments, par exemple pour rechercher les preuves d'intrusions ou d’attaques.

Certaines traces sont assez faciles à analyser, car elles correspondent immédiatement à un problème. Parfois, il faudra choisir ce qui est acceptable ou non dans une entité, sachant que cela peut aussi dépendre du contexte.

Prenons un exemple simple : une tête de pont VPN d’une entreprise se met à faire du promiscuous. Cela se passe la nuit. S’agit-il d’une intrusion avec une personne en train d’intercepter les flux déchiffrés de vos employés ?

Peut-être que des admins sont en train de travailler officiellement dessus, par exemple pour comprendre une panne, ou pour effectuer une migration, une optimisation, une surveillance. Même si l’on regarde si un administrateur s’est logué officiellement, peut-être que sa session est compromise ou que son poste de travail sert de rebond pour aller vers les machines sensibles ?

Hélas, tout ce qui touche au contexte n’est pas toujours une information visible dans les logs de manière facile, et aller chercher les réponses à toutes les questions peut s’avérer très couteux, et l’efficacité réelle face aux attaques actuelles est réduite.

4.2 De l’utilité réelle de certaines corrélations

Par exemple, pour savoir si des personnes sont dans un bâtiment, avez-vous envie de coupler réellement votre contrôle d’accès avec un SIEM ? Ou pour savoir si une personne est en période de congés ou d’absence, il vous faudra probablement un accès direct ou via des API vers des aspects liés aux bases de données RH, mais avez-vous envie de relier votre SIEM avec de telles informations (et aurez-vous le droit dans certains pays, ou avec certaines représentations d’employés, etc.) ?

Il vaut peut-être mieux dépenser des forces sur des problèmes plus importants de sécurité, comme s’assurer que l’on ne peut pas vous pirater facilement sur les postes de travail, les sites web avec des bases de données à risque, etc., plutôt que de monter des usines à données, très complexes à tenir dans le temps. Chacun choisira en fonction de son contexte, et de son envie de réalisme technique : présence de plusieurs sources, corrélations complexes, efficacité réelle versus les attaques du moment, coût de la maintenance (formats qui peuvent changer dans les traces de constructeurs du jour au lendemain, etc.).

En général, il faut plusieurs types de corrélations, tels des rouages de différentes tailles : des rapides pour les points resserrés dans le temps ; de plus larges pour d'autres formes d'attaques. Par exemple, quand on manipule plusieurs millions de données par jour, la recherche de scans lents, comme des attaques en force brute assez long, est moins facile. Il faut de bons algorithmes, mais aussi des ressources au niveau matériel. La plupart des détections utilisent des seuils, et si l'on a positionné une détection d'erreurs d'authentification par exemple à 10 par minute pour un compte donné, alors un pirate qui serait en dessous, pourrait être invisible. Cela explique l'idée d'une logique de rouages avec différentes vitesses.

Dans le meilleur des cas, le SIEM est livré avec des règles de corrélations par défaut, qui fonctionnent globalement déjà dans de nombreux environnements classiques, afin de trouver toutes les traces habituelles d’impuretés techniques et attaques classiques pour Windows, Unix, etc. Cela évite de complexes soucis d'intégrations où l'on doit parler en mode scénario d'attaques, et manquer par la suite les vraies intrusions techniques.

4.3 Alertes post-corrélations

Nous avons évoqué précédemment les soucis de remontée des alertes en cas de panne, mais il faudra aussi s’intéresser à la façon de remonter ces dernières. On ne parle plus des logs bruts, mais des informations consolidées, qui indiquent réellement un risque technique.

Par exemple, on devra choisir si l’on doit assumer une couche de chiffrement des alertes émises ou non. Dans le cadre des réseaux classifiés ou sur des infrastructures sensibles (OIV, OSE), on voudra séparer les aspects collectes avec des diodes ou des ruptures protocolaires de confiance, pour limiter voire interdire la remontée dans les éléments de supervision, voir [PDIS].

4.4 Surveillance

Enfin, on souhaitera disposer d’une console, unifiée ou non, pour assumer une gestion de traces hétérogènes et une vraie cybersurveillance. Les fonctionnalités avancées de filtrages et les requêtes sur les alertes ou sur les données brutes seront très utiles pour des équipes de type SOC.

L’objectif global sera de tendre vers une capacité permettant de répondre à cette question : qui a fait quoi, quand, comment, où, vers où, voire pourquoi, pour n’importe quelle taille d’infrastructure surveillée. Les capacités de génération de rapports et de statistiques utiles dans certaines réunions de synthèse ne devraient pas freiner les enjeux techniques. Il faudra donc trouver des outils offrant des réponses à vos besoins en fonction de vos moyens : justifier la conformité, détecter des attaques, etc.

D’autres articles de ce dossier MISC abordent ces sujets de surveillance : ces aspects SOC ne seront donc pas abordés plus en détail ici, même si d’autres sujets organisationnels seraient utiles à prendre en compte, comme notamment les matrices RACI pour savoir qui gère quoi sur un projet SIEM, etc.

Conclusion

Avant de dépenser votre énergie, votre motivation et vos moyens, l’humble auteur tentera ici de conclure qu’il ne faut pas croire qu’un SIEM va contribuer seul à lutter contre les cyberattaques.

Discutez avec les nombreux experts offensifs de n’importe quelle société, et ils vous partageront leurs pensées sur ces composants défensifs, le SIEM classique ou le NIDS classique. Hélas, il existe de nombreux arguments qui ne sont pas scientifiques, qui essaient de promouvoir le traitement des logs comme une solution absolue, mais tout le monde sait déjà que quand une machine est compromise, il n’y a pas toujours de trace utile pour savoir que c’est le cas, et la plupart des attaques ne laissent ainsi pas de lignes de logs, donc même en mettant toutes ses forces dans un grand SIEM, pour centraliser beaucoup de choses et les traiter, on restera limité aux capteurs initiaux sur les systèmes et applications. Quand on n’a pas de bons logs, de bonnes règles de corrélation, et de bons analystes, alors l’infrastructure de surveillance n'est pas très efficace.

Monter un projet SIEM, ressemble à traiter des « tuyaux » de données, un peu comme dans un cas complexe de plomberie/voirie, où l’on souhaite organiser les traitements, les contrôles, la robustesse, la résilience, ou même la surveillance.

On pensera ainsi à essayer d’assurer le chiffrement ou la robustesse, à déterminer et à organiser les seules données à conserver de manière à optimiser leur usage futur, et à éviter les surcoûts inutiles en mélangeant efficacité et rigueur.

Bien évidemment, des différences existent suivant la taille d’un SIEM. Quand vous traitez des milliards de logs d’un proxy d’un grand compte au niveau mondial, avec toutes les requêtes vers Internet, découvrir une opération d’espionnage sera complexe compte tenu de toutes les possibilités pour se cacher même sur des sous-domaines de grands sites parmi les plus visités du monde.

Remerciements

Je remercie les membres des activités SIEM et SOC de [TEHTRIS].

Références

[TEHTRIS] Site officiel de la société TEHTRIS : https://tehtris.com

[FORMATS] Guillaume Hiet, Hervé Debar, Selim Menouar, et Vérène Houdebine, « Étude comparative des formats d’alertes », CC&ESAR (Computer & Electronics Security Applications), novembre 2015

[PDIS] PDIS – Référentiel d’exigences, sur le site officiel de l’ANSSI : https://www.ssi.gouv.fr