Les auteurs ont collaboré sur un projet SIEM « Infrastructures » pour un grand groupe français, pendant plusieurs années. Ce retour d'expérience met en exergue les facteurs de réussite, qu'ils soient techniques ou organisationnels. Cet article est garanti « 100 % product-less » ;-)
1. Introduction
Un SIEM est un outil dont la finalité est de disposer d'un système de supervision sécurité/surveillance global. Ce dispositif permet d'être informé en (quasi) temps réel des incidents de sécurité survenant sur son système d'information, et ce, quels que soient le ou les équipements ayant remonté l'information initiale. Par la même occasion, il permet de disposer de rapports globaux, reflets de tout ou partie des alertes précédemment levées. Il permet de faire des statistiques sur des plages de temps plus longs que le temps réel sur des indicateurs que l’administrateur aura préalablement choisis pour leur pertinence d’un point de vue sécuritaire et opérationnel.
L’un des révélateurs du succès d’un projet SIEM est la capacité de « passer à l’échelle » depuis un test fait en labo (et donc dans un environnement en modèle réduit). L’aborder sous l’angle exclusivement technique est sans doute périlleux : une adaptation à l’existant de chaque organisation, au travers d’une étude d’industrialisation, est un gage de succès.
1.1. De l'outillage industriel, kézako ?
Le traitement manuel des incidents de sécurité (à base de awk/sed/zgrep), s’il a fait la joie de générations d’administrateurs et experts de tout poil, devient aujourd’hui impossible à poursuivre, principalement en raison des volumes de données à traiter. En effet, de nombreuses organisations traitent aujourd’hui des volumes de traces en multiples de centaines de giga-octets quotidiens, rendant ces travaux manuels inadaptés aux volumes considérés dans un mode récurrent.
Il devient donc nécessaire d’avoir la capacité à traiter ces volumes :
- de sources de données hétérogènes (problématique de la tour de Babel) ;
- de données brutes (les meules de foin) ;
- d’alertes de sécurité issues du SIEM (les aiguilles dans les meules de foin) ;
tout en garantissant :
- des temps de traitement aussi courts que possible des alertes (une ou deux dizaines de minutes par alerte) ;
- l’efficacité des traitements (un taux de faux positif supérieur à 1 ou 2 % deviendra rapidement irritant pour les destinataires des alertes) ;
ce qui passe par :
- l'automatisation des tâches répétitives, notamment dans les actions de levées de doutes à réception d'alertes ;
- la réutilisation et l’interfaçage avec des composants ou fonctions existantes (par exemple, l'intégration et l'extension du système de gestion des incidents en place au lieu d’en proposer un nouveau ou d’utiliser celui fourni avec votre SIEM favori).
1.2. Alertes en temps réel, traitements en temps ouvrable
Un SIEM implique que les alertes, émises en temps réels, soient traitées rapidement ; ce qui implique un coût substantiel en homme pour un service opéré en 24x7.
L’une des manières de contrôler ce coût est de s’organiser pour s’affranchir de la présence physique d’onéreux experts sur ces plages horaires étendues. Par exemple, en documentant au travers d’un espace collaboratif (type wiki) le protocole détaillé de levée de doute associé à chaque alerte paramétrée dans le SIEM.
Ainsi, des profils non-experts, polyvalents, pourront prendre en charge la très grande majorité des alertes, escaladant vers une équipe d’astreinte les cas les plus complexes (ou les moins bien documentés…) pour un traitement immédiat ou en heures ouvrées.
On notera l’intérêt de définir à ce stade des arbres de décisions permettant à ces opérateurs d’agir en toute autonomie, ainsi que de prévoir en amont d’apporter toutes les automatisations possibles pour faciliter la tâche et limiter le risque d’erreur (en pensant que l’opérateur qui traitera une alarme un dimanche à 3h du matin devrait avoir à se poser le moins de questions possibles).
1.3. La qualité des sources de données
Les SIEM ingèrent des événements bruts (syslog, pcap, netflow, etc.). Ces événements peuvent éventuellement être enrichis avant utilisation dans les règles de corrélation (fonction fortement dépendante du produit utilisé). À titre d'exemple, on pourra vouloir faire une résolution DNS sur une adresse IP lue dans un log pour travailler plutôt sur le nom d'hôte en corrélation. Si ces fonctions d'enrichissement sont globalement disponibles sur la plupart des produits aujourd'hui existants, que faire lorsque l'on n'en dispose pas, ou qu'il s'agit carrément de construire un nouveau fichier de logs (ce qui était notre cas) ? Passage obligé par la case développement spécifique...
1.3.1 L'appairage de logs : what ?
Pour illustrer les défis techniques qui peuvent apparaître dans un projet SIEM, rien de mieux qu'un exemple.
Côté architecture, prenez une ferme de proxies par lesquels des dizaines de milliers d’utilisateurs quotidiens transitent pour aller surfer sur Internet. Entre les proxies et les utilisateurs, ajoutez un cluster de firewalls qui NAT systématiquement toutes les connexions de sorte que les proxies ne voient comme source qu'un ensemble de 5 IP appartenant aux firewalls. Adieu donc les règles de corrélation basées sur le nombre d'IP sources par comptes utilisateurs et assimilés.
L'appairage des logs est donc la construction d'un nouveau log (pseudo-log), en croisant les logs des proxies et des firewalls, de telle sorte que les IP des firewalls soient remplacées par les IP réelles des utilisateurs. Plutôt simple comme problématique, sauf quand on se rend compte qu'on a 100 Go de logs proxy (~ 100 millions de lignes de logs) et 50 Go de logs firewall par jour. Évidemment, c'est sans compter la multiplexation de sessions faites par les firewalls, le fait que les firewalls fonctionnent en secondes et les proxies en millisecondes, le fait que le premier enregistre en début de session alors que le second en fin de session, etc.
1.3.2 – Format des logs
Une ligne de log proxy, ça ressemble à ça :
"[20/Feb/2013:10:14:27 +0100]" - GET http://www.google.fr/ HTTP/1.1 200 59 200 11831 TCP_NC_MISS 11893 1041 125 192.168.5.4 7721 - "Search Engines/Portals" ICAP_NO_MODIFICATION text/html;%20charset=ISO-8859-1
Et une ligne de log firewall (checkpoint) :
CPmgtA 20Feb2013 10:14:26 accept 192.168.5.1 >eth1c0 rule: 14; rule_uid: {DE4DB33F-B1EE-5002FBC0FFEE}; SmartDefense profile: No Protection; service_id: http; src: 192.168.0.42; dst: 192.168.10.3; proto: tcp; xlatesrc: 192.168.5.4; NAT_rulenum: 18; NAT_addtnl_rulenum: 0; product: VPN-1 & FireWall-1; service: 80; s_port: 3640; xlatesport: 7721;
Pour appairer nos logs, plusieurs critères doivent être respectés :l'heure d'un enregistrement firewall doit correspondre à l'heure d'un enregistrement proxy (en tenant compte du temps de session) ;
l'adresse IP source vue par le proxy doit être une adresse IP translatée par le firewall. Même chose pour le port source et le port translaté.
On doit donc respecter la règle suivante pour appairer nos logs :
((P.date – P.durée_session) = F.date) ET (P.ip_source = F.ip_translatée) ET (P.port_source = F.port_translaté)
Avec l'exemple précédent, on obtient donc la nouvelle ligne de log suivante :
"[20/Feb/2013:10:14:26 +0100]" - GET http://www.google.fr/ HTTP/1.1 200 59 200 11831 TCP_NC_MISS 11893 1041 125 192.168.0.42 3640 - "Search Engines/Portals" ICAP_NO_MODIFICATION text/html;%20charset=ISO-8859-1
Facile... sauf que :
1. Les proxies journalisent la connexion en fin de session, tandis que le firewall le fait en début de session. À ce titre, il est intéressant de constater des sessions HTTP de plusieurs jours dans les logs proxy.... comme si le SSH pouvait être tunnelisé... ;)
2. Les firewalls ne journalisent pas toutes les sessions du fait de la réutilisation de sessions précédentes. La durée de vie maximale d'une session, dans notre contexte, était de 30 minutes... Autrement dit, dans notre recherche d'appairage, tant qu'on a pas de correspondance suivant la règle énoncée ci-dessus, on réessaye avec 1 seconde de décalage entre l'heure calculée desproxieset l'heure des firewalls, puis 2 secondes, puis 3... jusqu'à 30 minutes !
3. Certaines lignes de logs n'ont pas de correspondance : perte de logs lors de l'acheminement, défaut de log sur l'équipement source, session non loguée…
4. Certaines connexions ne se comportent pas de la même manière. À titre d'exemple, une session HTTP et une session FTP sont gérées différemment par le firewall, tandis que le proxy les journalise « de la même manière ». Dans notre contexte, les sessions FTP, en plus de voir leur IP NAT-ée, avaient également l'agréable amabilité de se présenter avec un port source PAT-é, mais par un autre équipement !
1.3.3 Architecture de dé-NAT-age
Plusieurs approches sont envisageables pour résoudre notre problématique, et celle que nous avons retenue à l’époque (1) a été de découper et normaliser les données avant de les insérer en base de données, pour notamment s'appuyer sur les fonctionnalités de croisement d'ensemble offertes par les SGBD. Avec la volumétrie affichée, deux astuces étaient nécessaires : bien configurer le SGBD pour le chargement massif des données (bulk load, désactivation de l’indexation au chargement), notamment la taille de différents buffers, et tirer parti du partitionnement des tables dans le SGBD, pour « cloisonner » les données par jour.
Une fois en base de données, la problématique est vulgairement l'exécution d'une requête SQL avec jointure. La requête SQL identifiée, il ne reste plus qu'à créer une procédure stockée pour gérer le cas où l'on doive remonter dans le temps (les fameuses 30 minutes), et le tour est joué.
De plus, grâce au SGBD, d'autres requêtes peuvent également être réalisées pour tirer parti de l'indexation. Les résultats ainsi produits, directement exploitables, sont envoyés au SIEM. De cette façon, le SIEM n'a qu'une fonction de « passe-plat » et d'alerting suivant les canaux préalablement identifiés et définis.
2. Les mains dans le SIEM
2.1. Mes outils sont prêts, je commence par où ?
Dans la grande majorité des entreprises, l'ennemi public numéro un est le malware, dans sa forme la plus large possible : code malveillant, backdoor, trojan, les biens nommées « APT » (fallait bien les caser quelque part dans l'article...), etc. Bref, avant de trouver des chinois, des roumains, ou des russes dans un système d'information, on doit chercher des malwares, signal caractéristique des attaques (non) ciblées qui font aujourd’hui leur nid dans les SI des organisations.
Qu'il soit ciblé ou non, le malware va éprouver l'irrésistible envie de communiquer vers l'extérieur, et notamment vers son canal de contrôle (C&C), généralement en HTTP(S). On peut donc, d'une façon macroscopique, identifier les grandes étapes suivantes :
1. Validation de la connectivité Internet ;
2. Connexion au C&C ;
3. Échange de données (récupération d'ordres, exfiltration de données, mises à jour, etc.).
À chacune de ces phases, le bon chasseur de botnet pourra surveiller un certain nombre d'indicateurs, dont :
- Des résolutions cycliques de noms de domaines en échec, synonymes de défauts de configuration ou de présence de malwares. Ces derniers essaieront soit de valider la connectivité Internet par le biais de la résolution de noms de domaines anodins (google.com, microsoft.com…), soit essaieront directement de contacter leur C&C.
- Les erreurs d’authentification sur des proxies (407 authentication failed).
- Toujours dans les logs proxies, des méthodes CONNECT, synonymes de connexions HTTPS, sur des IP, et/ou sur des ports exotiques, sont autant de bons indicateurs.
- Les user-agents sont également intéressants, notamment quand on voit du shockware flash utiliser massivement des méthodes POST...
- Les noms de domaines demandés peuvent être référencés dans certaines listes publiques de domaines malveillants (malwaredomainslist.com, *.abuse.ch, malc0de.com, etc.). Ces noms de domaines peuvent être analysés (le nombre de voyelles, le nombre de chiffres, l'entropie de Shannon, etc.) à la recherche de singularités permettant de les définir comme malveillants ou « suspects » ou être confrontés à des DGA connus (Domain Generation Algorithm).
- Etc.
On citera ici pêle-mêle les logs des serveurs DNS, les logs des serveurs proxies, et les logs (ou tickets) netflow comme principale, et indispensable, matière première.
2.2. ... et où dois-je éviter d'aller ?
Dans un SIEM, toutes les informations ne se valent pas, surtout en temps réel. La vigilance est donc de rigueur dans les informations qui seront remontées au SIEM, notamment pour une question d'intérêt des événements collectés, et surtout, pour des questions de performances (ou de licences !).
L'idée de remonter tous les logs dans une boite magique, qui, par le biais d'opérations de normalisation, d'agrégation, et, de corrélation, lèvera des alertes multi-périmètres quelle que soit la source de donnée initiale, est jolie sur le papier, mais dans la vraie vie ne fonctionne pas. D'une part, les alertes levées sont « sans valeur », car elles ne tiennent pas compte du contexte de l'entreprise (technique, organisationnel, politique, etc.), et d'autre part, on atteint vite les limites de performances du fait de volumétries élevées. Opérer un SIEM, c'est une attention permanente sur le coût en performance versus l'efficacité de la règle ; quitte à ne pas être exhaustif.
2.2.1. Détecter... mais pour quoi faire ?!
Une des règles d'or dans la création d'une règle de corrélation est de savoir quelle réponse sera apportée au déclenchement de l'alerte. En effet, on peut créer des règles pour quasiment tout et n'importe quoi, mais à quoi bon avoir un système qui génère beaucoup d'alertes si c'est pour ne pas les traiter (non, on ne parle pas des IDS ici...) ? Si l'on prend le cas d'un scan de port sur un firewall frontal internet, quelle réaction peut-on y apporter ? Est-il vraiment pertinent de déclencher l'action d'un opérateur pour éventuellement bloquer l'origine du scan, sachant qu'il suffira à « l'attaquant » de changer d'IP pour continuer son scan ? De plus, ce scan est-il réellement illégal ou dangereux dans notre contexte ?
2.2.2. Détecter l'indétectable ?
L'idée est séduisante : détecter toutes les menaces sur mon SI, notamment avec le superbe jeu de règles de corrélation livré par défaut avec ma nouvelle boite fraîchement achetée. Oui, mais non. Un SIEM c'est avant tout du filtrage et la mise en avant de certaines informations plutôt que d'autres. Autrement dit, si les traces des équipements surveillés ne contiennent pas d'informations, alors le SIEM ne pourra rien faire de plus. Il faut donc s'assurer que chaque équipement surveillé dispose du bon niveau d'informations. Si le niveau est trop bas (emergency), cela ne sera pas suffisant pour en tirer parti en corrélation, et si le niveau est trop haut (debug), cela nécessitera une capacité de traitement importante avec un risque fort de produire trop de bruit.
2.2.3. À chacun son métier
Prenons un cas d'usage, la détection des scans de ports, verticaux ou horizontaux peu importe. Pour ce faire, et suivant l'architecture technique, plusieurs sources de données peuvent être utilisées : les IDS/IPS qui déclencheront une alerte à détection d'un scan, les tickets netflow ou les logs des firewalls qui pourront être corrélés pour identifier ces scans en fonction de la source, des destinations, et des ports.
S'il est possible de faire l'un ou l’autre, il est plus intéressant de déléguer cette opération de détection à une sonde IDS/IPS qui d'une part dispose d'optimisations et de règles existantes pour ce faire, et d'autre part, sera certainement plus exhaustive et précise dans la détection. Il ne faut pas chercher à déporter les fonctionnalités des sondes IDS sur les SIEM, à chacun son utilité !
Malgré tout, le SIEM a l'avantage de pouvoir trouver des scans lents contrairement aux IDS/IPS, car ces derniers ne disposent pas de l'ensemble des logs. On notera toutefois qu'on touche ici aux limites des SIEM traditionnels et qu'on se rapproche plus de problématiques de Log Management et d'Analytics.
2.2.4. La comète de Haley
Il est toujours intéressant, intellectuellement parlant, d'imaginer pouvoir détecter des attaques complexes en décrivant des étapes successives, sauf qu'en réalité :
1. Un nombre important des outils aujourd'hui disponibles ne permettent tout simplement pas de décrire des successions d'étapes. La notion de scénario n'existe donc pas nécessairement, et certaines fois elle est implémentée n'importe comment.
2. Quand bien même c'est possible, il est peu probable que l'attaque que l'on tente de décrire se déroule réellement telle qu'imaginée. Un attaquant a généralement toute latitude de faire varier quelques octets ou de changer l'ordre de certaines opérations, notamment dans le but de passer sous les radars.
3. Des indicateurs simples peuvent être mis en place et ceux-ci feront nécessairement partie des attaques dites sophistiquées.
Les scénarios trop complexes sont donc à éviter, car ceux-ci seront déclenchés aussi souvent que les passages de la comète de Haley, et un enchaînement de deux étapes maximum sera dans la très grande majorité des cas suffisant. En effet, il sera certaines fois intéressant de corréler deux sources de données différentes, que ce soit dans le but d'éliminer des faux-positifs (confirmation par deux sources différentes), ou, pour produire des alertes de qualité : c'est-à-dire avec suffisamment d'informations pour qu'un analyste puisse commencer à investiguer.
A contrario, la logique inverse est dans certains cas intéressante : si une succession d'étapes n'est pas suivie, alors le comportement observé est suspect (déviance par rapport à une norme). À titre d'exemple, un utilisateur accède à une page de validation d'un compte après en avoir fait une demande d'ouverture.
2.3. Et pour la suite, je cherche quoi ?
Une fois que vous penserez avoir la maîtrise des malwares de votre SI, que vos utilisateurs respecteront scrupuleusement la Charte Informatique annexée au règlement intérieur et que vous aurez pris le temps de contempler votre œuvre, il vous restera probablement encore des étendues à conquérir !
La première sera sans doute d’assurer l’efficacité dans la durée de vos règles de corrélation. En effet, si vous prévoyez de contrôler l’absence de téléchargement de fichiers protégés par des droits d’auteurs en surveillant les accès à megaupload.com… vous avez probablement du souci à vous faire. C’est une constante : la chasse aux activités indésirables est un travail sans fin, il faut en permanence se tenir informé des dernières évolutions dans votre périmètre d’observation.
La seconde pourra être de ne plus se limiter aux logs seuls, mais d’essayer d’exploiter des artefacts plus synthétiques (exemple : tickets netflow / ipfix), voire même d’enrichir vos informations brutes en interagissant avec les machines à l’origine des alertes (l’utilisation automatisée de nmap et de certains de ses scripts permet de grandes choses, dans des environnements où les postes de travail récupèrent leurs adresses IP sur des serveurs DHCP dont les logs ne sont pas activés).
Enfin, la véritable légitimité de votre SIEM sera acquise quand vous saurez démontrer sa valeur directe. Cela implique :
- De mettre en place un dialogue et des interactions avec le cœur de métier : votre projet SIEM n’est pas qu’un projet technique ou un projet de surveillance périphérique ; il doit s’inoculer dans l’ADN de votre organisation.
- D’activer quand c’est possible des contrôles avec un retour sur investissement direct (exemple : lutte contre la fraude), et de prévoir la mise en place d’indicateurs percutants qui mettront en évidence la valeur produite par le SIEM.
3. Prenons du recul
3.1. Faire face à l'imprévu : quand on cherche... on trouve !
Un projet SIEM est souvent lancé pour adresser les problèmes de sécurité et se protéger des menaces qui se trouvent, c’est bien connu, à l’extérieur de l’organisation. Sauf que…
S’il peut effectivement être confortable d’imaginer que la menace est derrière « le Mur », il faut également penser à regarder l’intérieur. Volontaires ou pas, les traces d’activités inappropriées sont généralement bien présentes et il faut s’en occuper.
En effet, même si vous avez encore en persistance rétinienne des jolis camemberts animés en 3D vous décrivant les scans horizontaux, verticaux, dont vous êtes « victime » depuis Internet (oui, ces fameuses « attaques » dont les commerciaux des différents leaders & visionnaires de quadrants fantabuleux vous ont rabattu les oreilles)… la vraie vie sera sans doute un peu différente.
Car dès l’instant où vous démarrerez vos analyses, en cherchant, vous trouverez… des machines compromises, des utilisateurs aux habitudes hasardeuses, quand elles ne seront pas indésirables ou carrément illégales (on a beau avoir des solutions de filtrages, celles-ci ne sont pas infaillibles). À ce stade, il peut alors parfois être nécessaire de sortir de la sphère technique, pour se retourner vers les services RH, voire juridiques pour les situations les plus sévères.
La surprise causée par leur découverte pouvant significativement déstabiliser votre projet SIEM, il est recommandé d'avoir un appui solide du management et plus largement de la direction générale.
3.2. Avec mon SIEM, je suis le maître du monde (... ou pas)
La manipulation et le croisement au quotidien des sources de données qui se déversent dans un SIEM confèrent à ses opérateurs une grande capacité d’investigation. Il faut donc agir avec discernement, éthique et surtout dans le respect des différents règlements et textes applicables.
Au cas particulier, même si le débat n’est pas formellement tranché, une position raisonnablement prudente consiste à considérer les identifiants et les adresses IP comme des données à caractère personnel, au sens de la loi Informatique et Liberté du 6 janvier 1978. Et à ce titre d’en garantir la traçabilité des accès (qui accède à mes logs ? quelles recherches sont réalisées ? y a-t-il eu altération, volontaire ou non, de ces logs ? etc.)
Ces données (pour faire simple, tous les fichiers de logs) ainsi que les différentes transformations que vous leur ferez subir portent un nom : un traitement de DCP (Données à Caractère Personnel) qui doit pour être en conformité avec la loi faire l’objet d’une déclaration (dans de rares cas d’une autorisation) auprès de la CNIL (ou du CIL, le Correspondant Informatique et Libertés, pour les organisations qui en sont dotées).
Ce traitement devra par ailleurs apporter toutes les garanties de :
- transparence (en particulier, information préalable des personnels de son existence, par exemple au travers d’une charte d’utilisation des SI annexée au règlement intérieur) ;
- proportionnalité ;
- statistique et anonymat (on ne cherche jamais quelqu’un, mais avant tout quelque chose… même si on aboutit toujours finalement sur un individu, ou un terminal associé à un individu).
Finalement, il s'agit un travail d’équilibriste puisqu’il faut en savoir suffisamment pour protéger l’organisation que l’on doit défendre, sans pour autant s’accaparer les prérogatives des officiers de police judiciaire… tout en se tenant informé des évolutions régulières des jurisprudences et textes en vigueur.
3.3. Des collaborations encore frileuses
Depuis quelques années, la maturité des organisations évolue sur le sujet de la supervision/surveillance sécurité. Même si chaque contexte reste particulier, de nombreux cas d’usages forment un tronc commun qu’il est possible d’adapter à chaque organisation.
Toutefois, les travaux tournants autour de la consolidation et de l’analyse de logs sont aujourd’hui encore assez peu structurés et fédérés, laissant la porte ouverte à quelques prestataires de service aux qualités variables, qui vous assurent la protection contre tous les types d’APT.
On peut noter l’existence du « Club R2GS » qui organise chaque année au mois de décembre les « Assises du SIEM », mais la vision proposée reste de très haut niveau (avec l’objectif de proposer un standard qui devrait alimenter la future norme ISO 27044, cf https://en.wikipedia.org/wiki/Information_security_indicators).
Toutefois, l’échange d’informations opérationnelles, techniques, reste aujourd’hui limité à quelques listes de diffusion sectorielles très confidentielles et on touche du doigt les limites de la collaboration sur des sujets toujours sensibles.
4. Conclusion
Nous avons tenté au travers de cet article de présenter les facteurs de réussite d'un projet SIEM, qu'ils soient techniques ou organisationnels. On retiendra :
1. Il n'existe aucune solution miracle. Un produit ouvert qui permet de s'intégrer dans n'importe quel environnement est donc nécessaire.
2. Il faut connaître parfaitement le contexte de l'entreprise, dans sa globalité. Cela passe par la connaissance technique, mais pas uniquement. Il faut savoir écouter et trouver les personnes qui connaissent parfaitement le contexte. En premier lieu, ils savent ce qui devrait être amélioré et supervisé.
3. Il faut envisager les actions qui seront réalisées à l'apparition de chaque alerte de sécurité de sorte que seulement des alertes pertinentes et ayant un intérêt pour l'organisation soient mises en place.
4. Il faut un appui du management et de la direction générale.
5. Il faut savoir s'armer de patience, comme dans tout projet transverse.*6.Il faut composer avec des architectures existantes qui sont parfois difficiles à faire évoluer (non-respect de la RFC1918, par exemple).
7. Commencer modestement par les événements de sécurité « grossiers » avant d'aller chercher les bien nommées APT. Puis, par itérations successives, les scénarios de détection se complexifient et s’affinent de sorte que des attaques plus silencieuses sont détectées.
8. Faire simple !
Enfin, on regrettera que certaines organisations, notamment gouvernementales, qui traitent de gros volumes de données, ne communiquent pas sur ce sujet : en pleine vague du « Big Data », ça serait l'occasion...
Note
(1) Cette problématique date de 2009. Avec le recul et l'évolution des techniques, une architecture en Map-Reduce serait aujourd'hui certainement plus pertinente.
