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…
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.
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...
Aucun commentaire:
Enregistrer un commentaire