Utiliser Splunk pour gérer les vulnérabilités

Bonjour,

Ces derniers jours ont été riches en informations et en notifications sur la vulnérabilité http.sys de Microsoft. L’installation de correctifs était donc une priorité pour beaucoup d’entreprises et d'équipes.

Récemment, Verizon a également publié son rapport annuel de violations de données. Parmi les grandes tendances observées, les vulnérabilités qui ne sont pas encore corrigées ni isolées dans les systèmes représentent l’un des plus grands facteurs de risque de ces 20 dernières années.

Pourquoi les malfaiteurs connaissent-ils encore un tel succès avec cette méthode d'attaque ? J’imagine que, dans bien des cas, il n’y a pas de processus établi de gestion des incidents. Saviez-vous que vous pouviez mettre en place ce processus de sécurité (qui mobilise généralement plusieurs équipes et responsables de systèmes dans les grandes entreprises) avec Splunk ?

Vous pouvez importer les rapports de recherche de vulnérabilités de Nessus, Qualys et d'autres fournisseurs connus dans Splunk, qui va ensuite les décomposer en événements pour veiller à ce que chaque vulnérabilité d'un système puisse être traitée et explorée séparément si nécessaire.

Le processus d’examen de vulnérabilités :

Pour garantir l’atténuation des risques, il faut mettre en place un processus reproductible. Le graphique ci-contre illustre une bonne pratique pour la conception de ce processus.

Exécution de la recherche de vulnérabilités

Vous allez procéder à des recherches régulières à l’aide du détecteur de vulnérabilités. Veillez à les surveiller attentivement. Vous pouvez utiliser le Tableau de bord Opérations de vulnérabilités pour superviser et suivre l'état de vos recherches dans votre environnement.

Vulnérabilité localisée

Une fois la recherche exécutée, les résultats sont traités dans Splunk. Une vue d’ensemble détaillée de la situation actuelle peut s'avérer utile dans ce domaine, et le Tableau de bord Centre des vulnérabilités vous offre cette visibilité via une vitrine unique.

Notification au propriétaire de l’actif

C’est l’une des étapes clés et il existe différentes manières de procéder. Cela implique généralement l’équipe responsable de certaines opérations sur un serveur spécifique, que ce soit l'équipe réseau, l’équipe d'applications web ou autre. Tout dépend du type de vulnérabilité et de technologie.

1. Processus manuel
   • L’analyste de sécurité envoie un e-mail au responsable de l’actif et l’informe de la vulnérabilité et des hôtes concernés, puis discute des étapes à suivre pour éliminer la vulnérabilité.
   • Une fois ces étapes convenues, l’événement peut être supprimé ou clos. Si la vulnérabilité est encore présente à la prochaine recherche, il sera rouvert.
2. Utilisation du framework d'événement notable Splunk
   • Il est possible de configurer une recherche de corrélation afin qu’un événement notable soit créé pour chaque nouvelle vulnérabilité. Lorsqu’une nouvelle vulnérabilité est détectée, l’analyste de sécurité peut examiner l’événement et l’affecter au responsable du système/actif/service.

Élimination de la vulnérabilité

Le responsable du système doit, s'il est avisé, examiner l’impact de la vulnérabilité sur son service et décider quelle est la meilleure correction à apporter à court et à long termes. Pour une correction à court terme, on pensera à une reconfiguration, au blocage temporaire du port vulnérable concerné ou la désactivation de la fonctionnalité. Une correction à long terme consiste généralement à appliquer les correctifs du fournisseur ou à mettre le système à niveau.

Ce processus peut prendre du temps. Vous avez donc la possibilité de supprimer des événements spécifiques pour éviter de recevoir une alerte pour la même vulnérabilité lors de votre prochaine analyse.

Test de contrôle

Si une vulnérabilité a été patchée ou corrigée, elle doit encore être validée pour garantir la réussite de l’opération. Cette étape peut être réalisée à l’aide du même détecteur de vulnérabilités qui effectuera une recherche ciblée, ou en attendant le prochain cycle de recherche si vous pouvez vous permettre d'attendre.

Comment expliquer cela à la direction :

Lors de la Splunk .Conf, Mark Graff, RSSI de NASDAQ, a présenté des statistiques très impressionnantes sur la vitesse à laquelle leurs équipes avaient pu réagir à la vulnérabilité Heartbleed.

Lors de la présentation « Systèmes vulnérables et attaques », ils ont montré avec quelle rapidité ils avaient patché leurs systèmes. Les événements d'attaque proviennent de leurs systèmes de protection du réseau, qui sont en première ligne devant leurs systèmes. Les résultats étaient impressionnants : on pouvait voir l’efficacité de leur approche et la vitesse à laquelle ils devaient agir. Les quelques attaques des premiers jours étaient des tests de validation. 48 heures après, des activités externes ont commencé à exploiter la vulnérabilité.

Si vous voulez savoir à quoi ressemblent des événements de vulnérabilité spécifiques à un niveau plus technique, et comment créer une recherche de corrélation personnalisée dans Enterprise Security, je vous recommande une session .Conf de Randal T. Rioux, Chef de la Paranoïa numérique et Ministre de la Guerre chez Splunk ;-).

_{*Cet article est une traduction de celui initialement publié sur le blog Splunk anglais.}