SecurityInsider
Le blog des experts sécurité Wavestone

Améliorer sa détection des attaques par un projet SIEM : des difficultés à anticiper !



Les cyber-attaques sont de plus en plus nombreuses et complexes. Penser que l’on pourra les éviter devient malheureusement utopique. Les entreprises n’ont plus le choix ; elles doivent être en mesure de les détecter au plus tôt et de réagir efficacement. C’est ainsi que le « SOC » (Security Operation Center) et le CERT (Computer Emergency Response Team) entrent en jeu… 
Ces deux structures font alors face à plusieurs défis. Parmi eux, un reste majeur : surveiller son système d’information et être en mesure de détecter des évènements suspicieux ! Pour ce faire, posséder un SIEM (Security Information and Event Management) devient indispensable.

Avant tout, qu’est-ce qu’un SIEM ? En quelques mots...

Un SIEM est un outil qui permet de détecter des évènements dits « redoutés » (i.e. évènements qui illustrent une éventuelle action malicieuse à l’origine d’une attaque). Ces évènements illustrent la plupart du temps des risques identifiés. Chaque détection génère une alerte qui devra être traitée avec une priorité dépendante de sa criticité (critique, majeure, mineure, etc.).
Légende :
Les logs : la détection se fait sur la base de journaux d’évènements (logs) provenant de divers équipements du système d’information surveillé (e.g. pare-feu, proxies, IDS, serveurs, applications, etc.).

Les règles : ce sont elles qui décrivent les évènements que l’on souhaite détecter. Exemples : « Un administrateur X échoue son authentification plus de cinq fois en moins de 15 secondes » ou encore « Un compte administrateur réalise une action depuis un poste situé en-dehors de la zone d’administration ».

Les IOC (Indicator Of Compromise) : ce sont des indicateurs (noms de fichier, adresses IP, URL, etc.) permettant la création de nouvelles règles de détection plus fines et pertinentes. Exemple : « Présence d’une pièce-jointe de mail au format CAB » ou encore « Accès à l’URL http://hackmeifyoucan1234.com/donotclickifyouwanttolive.htm ».
Ici, les IOC sont : le fichier au format « .CAB » et l’URL http://hackmeifyoucan1234.com/donotclickifyouwanttolive.htm.
Si l’une de ces deux règles génère une alerte, une investigation (simple levée de doute dans un premier temps) devra être menée pour déterminer les raisons d’un tel évènement.

Les alertes : souvent illustrées sous forme de « ticket » (i.e. une alerte génère un ticket contenant l’ensemble des informations utiles à l’investigation), elles permettent d’indiquer qu’une des règles implémentées dans le SIEM a été sollicitée (autrement dit, l’évènement redouté associé a eu lieu !).

Plusieurs de nos clients se lancent alors dans l’aventure !  Compte tenu de la complexité et de l’expertise pointue nécessaire à la gestion d’un tel outil, l’entreprise décide, la plupart du temps, de souscrire à un service auprès d’un prestataire spécialisé, autrement appelé « MSSP » (Managed Security Service Provider) ; ce dernier se chargera alors de toute la maintenance et l’exploitation de l’outil : un service « clef en main ».

Des difficultés récurrentes pouvant être en partie résolues par des actions simples

L’expérience montre que ce type de projet est délicat. Un certain nombre de difficultés sont régulièrement rencontrées ! Voyons ensemble lesquelles et ce qui peut être anticipé pour y pallier.

Les difficultés souvent rencontrées sur le plan organisationnel

Périmètre de supervision
L’évolution du périmètre de surveillance est souvent mal organisée : que souhaitons-nous surveiller en premier ? Le périmétrique ? L’interne ? Réseau/système/application ? Quelle technologie à prioriser ? etc. Les prochaines étapes sont difficiles à anticiper, aucune stratégie n’est mise en place sur les prochains mois/années. Généralement, personne ne sait ce qui est surveillé aujourd’hui, ni ce qui le sera demain.
Réversibilité en cas de changement de MSSP
Après plusieurs années, si l’entreprise cliente venait à changer de fournisseur MSSP, serait-elle en mesure de le faire sans perte ? A-t-elle par exemple un référentiel de l’ensemble des règles de supervision à jour et détaché de toute technologie SIEM ? En combien de temps pourrait-elle obtenir un nouveau service fonctionnel chez un autre prestataire ?
Organisation de chaque acteur
Les responsabilités de chaque acteur ne sont pas bien définies et formalisées. Entre le MSSP, les équipes de traitement, le CERT, etc., des étapes redondantes et/ou absentes sont ainsi constatées ; la productivité est impactée.
Évaluation du service de son MSSP
Le service proposé par le MSSP ressemble en partie « à une boîte noire » pour l’entreprise cliente ; comment peut-elle s’assurer de la qualité de service de son prestataire (si ce n’est par le biais du respect des SLA) ?

Des solutions à envisager...

Établir une stratégie d’évolution progressive du périmètre de supervision
Chaque nouvelle étape doit être scrupuleusement validée avant que la suivante puisse débuter. Il faut prioriser le périmètre de supervision en fonction des besoins. Une bonne pratique peut être de lotir : les six premiers mois, supervision du lot 1 (proxies, anti-virus / anti-APT / IDS / IPS, etc., Domain Controllers Windows), une fois opérationnel, supervision d’un lot 2 (pare-feu périmétriques, VPN / connexions partenaires, serveurs d’authentification Linux), etc.
Définir et formaliser le rôle de chaque acteur et initier des scénarios fictifs pour s’exercer
Il faut éviter la redondance des actions. Chaque acteur doit connaître son plan d’action dans la chaine de traitement (évènement > détection > alerte > traitement > reporting). Le formaliser est recommandé.
Établir un processus d’intégration de la supervision aux projets SI
Dans ce processus, il est bon de pérenniser des actions destinées à assurer un plan de réversibilité. Par ailleurs, la réflexion « Dois-je surveiller ce nouveau projet ? Comment ? » doit être intégrée dans les étapes d’élaboration d’un nouveau projet.
Garder en interne un référentiel technique de la supervision et évaluer régulièrement le service de son MSSP
Le service du MSSP ne doit pas être une « boite noire » pour le client. Il faut prévoir dès que possible un plan de réversibilité afin de limiter les pertes en cas de changement de MSSP. Tracer automatiquement chaque demande d’ajout, suppression ou modification auprès du MSSP peut-être déjà une première étape.
Faire de la threat intelligence !
Un SIEM dépourvu d’indicateurs de compromission reste limité. Des IOC doivent lui être fournis régulièrement ! Ils doivent être pertinents et d’actualité.

Des difficultés souvent rencontrées sur les règles et journaux d'évènements

Recette technique des règles
Il est difficile de s’assurer qu’une règle fonctionne à 100% et qu’elle saura ainsi détecter l’évènement redouté associé. Plus globalement donc, une difficulté majeure dans un projet SIEM reste de s’assurer que l’outil remplit ses objectifs de détection. La différence entre la théorie et la pratique …
Standardisation des logs
La journalisation n’est encore pas commune et mature pour certains éditeurs de solutions. Les journaux d’évènements sont donc régulièrement inexploitables en l’état par le SIEM ; des modifications sont ainsi à prévoir dès la source (modification du code de l’application) entraînant parfois une impossibilité de surveiller le périmètre souhaité.
Volumétrie des logs
Il est complexe d’anticiper la volumétrie des flux de logs collectés. Quelle est la sollicitation des équipements : le jour, la nuit, la semaine, le week-end, etc. ? Quelle est la verbosité des journaux d’évènements ? Le nombre d’informations dans chaque log ? Une compression du flux est-elle envisageable ? Cette volumétrie est-elle stable dans le temps ?
Corrélation[1]
La corrélation est-elle finalement pertinente ? Les retours d’expérience montrent que les règles qui fonctionnent correctement n’en font souvent pas appel. Deux raisons à ce constat :
  • la corrélation est complexe à mettre en place, il s’agit d’un concept plutôt théorique que pratique ;
  • la corrélation fait l’objet de limitations techniques : saturation mémoire, désynchronisation des logs due à des latences réseaux, etc.

Des solutions à envisager…

Anticiper et ne pas négliger la faisabilité de la collecte et de l’exploitation des logs souhaités
Il faut standardiser au maximum les collectes des logs (notamment par un format tel que syslog). Il faut également créer une infrastructure dédiée à cet effet (log management) et ainsi penser à la volumétrie et à la capacité des bandes-passantes. Enfin, il faut prévoir de réaliser des tests sur des échantillons et déterminer la faisabilité de leur exploitation (ne pas hésiter à contacter les éditeurs pour leur proposer des modifications dans la journalisation des évènements). Plusieurs retours d’expérience montrent qu’ils sont à l’écoute pour monter en maturité sur le sujet.
Personnaliser certaines règles du SIEM pour couvrir des risques spécifiques
L’ensemble des règles « classiques » ne suffit pas, il faut aller un cran plus loin. Pour chaque risque identifié, notamment illustré par un évènement redouté, il faut pouvoir élaborer une règle SIEM permettant de le détecter. Dans ce sens, les recettes techniques doivent en priorité être réalisées sur ce type de règles ; la probabilité de l’erreur d’implémentation est en effet plus importante que sur des règles plus communes.

Les difficultés souvent rencontrées sur les alertes

Volumétrie des alertes générées par le SIEM
Comme expliqué ci-dessus, le SIEM possède souvent des règles génériques, mal construites, englobant ainsi des évènements qui ne sont pas redoutés, ni malicieux. De nombreux faux-positifs sont alors générés. Les équipes de traitement deviennent alors vite débordées par des sujets qui n’ont pas lieu d’être. Le risque est simple : qu’un réel incident ne soit pas traité dans cet amas de fausses alertes…
Traitement des alertes
Chaque alerte générée par le SIEM doit être traitée. Selon sa typologie, ce ne sont pas les mêmes personnes qui sont en mesure de qualifier la situation et de procéder au plan d’actions associé. Beaucoup de temps est souvent perdu à définir « qui doit faire quoi » pendant qu’un incident de sécurité majeur est peut-être en cours…
Compétences techniques des équipes
Afin d’être traitées correctement, certaines alertes nécessitent une expertise technique pointue. Cette expertise n’est pas systématiquement présente dans les équipes. Sur certaines alertes, des erreurs de qualification ou d’investigation peuvent ainsi être commises.

Des solutions à envisager…

Faire de la réduction des alertes générées une priorité
Avant d’étoffer son périmètre de surveillance (rajout de nouvelles règles, rajout de nouveaux flux de logs, etc.), il est impératif de s’assurer des pourcentages d’alertes « faux-positifs », « incidents de production », « sujets bénins », etc. et de le réduire au maximum en supprimant les règles non pertinentes ou en affinant celles trop génériques. Rappelez-vous, avant d’avancer, il faut s’assurer que ce que l’on a, fonctionne !
Assurer le maintien des compétences
Garder des équipes informées des dernières nouveautés et dotées d’une compétence technique adéquate, est primordial ! Une veille interne et des sessions de formation / remise à niveau régulières sont donc à prévoir.

Plusieurs expériences chez nos clients montrent qu’un projet SIEM, mis en œuvre dans l’urgence, ne fonctionne jamais correctement ou tout au moins, ne remplit pas ses objectifs ! L’entreprise pense alors posséder des moyens efficaces de détection mais découvre qu’elle se trompe aux premières séries de tests, ou pire, à la première attaque avérée… Il faudra alors procéder progressivement, étape par étape. Le respect de ces quelques conseils permettra d’éviter les principaux pièges.


[1] La corrélation : dans la théorie, c’est le fait d’analyser plusieurs flux de logs en parallèle, provenant de différents équipements de technologies différentes, afin d’y trouver une relation logique entre eux. En guise d’exemple, l’évènement « un utilisateur s’authentifie sur un poste Windows, accède à une URL, télécharge un malware qui se fait bloquer par son anti-virus » pourra être tracé de bout en bout grâce à la corrélation des flux de logs provenant des serveurs Windows, des proxies web et des consoles anti-virus. Dans la pratique, faire de la corrélation est très complexe...

Baptistin BUCHET

Aucun commentaire:

Enregistrer un commentaire