Rechercher

Gestion des vulnérabilités informatiques : l’analyse

En cybersécurité, la gestion des vulnérabilités se fait en plusieurs étapes.

Celles-ci peuvent être regroupées en deux temps clés : la détection puis l’analyse. Après un premier épisode sur les différentes manières d’identifier les vulnérabilités, attardons-nous sur leur analyse.

Etape 3 : analyser les données

Pour retrouver les deux premières étapes, cliquez ici

Une fois que la phase de collecte a identifié une ou plusieurs vulnérabilités, il faut traiter cette information :

  • en vérifiant qu’il ne s’agisse pas d’un faux positif (fausse alerte),
  • en évaluant l’impact et la vraisemblance de l’exploitation de la vulnérabilité sur le composant,
  • en évaluant les risques liés à cette vulnérabilité sur l’ensemble du SI (système d’information).

Pour attester que la vulnérabilité détectée est bien réelle, il faut collecter des informations sur ses caractéristiques et les comparer avec la configuration du composant que l’on pense vulnérable. Tous les composants ne sont en effet pas sensibles aux mêmes vulnérabilités : si pour certains, elles peuvent être critiques, pour d’autres, elles n’auront aucun impact. Par exemple, un patch (mise à jour) pourrait déjà avoir été installé, ou une configuration particulière du composant pourrait faire que celui-ci n’est pas vulnérable.

Il s’agit alors de tenter d’exploiter la vulnérabilité (de la tester) : le succès ou non de cette exploitation permet de dire si la vulnérabilité est bien présente sur le composant. On privilégiera alors les environnements de recette ISO production pour ne pas impacter les environnements de production.  Pour rappel, un environnement de recette ressemble à celui de production mais est utilisé pour passer en revue les fonctionnalités d’un composant. Un environnement ISO production est un environnement identique à l’environnement de production mais n’impacte pas les systèmes, les réseaux, les services et les applications qui sont utilisés en production.

Une fois la menace avérée, débute un travail plus ou moins important d’analyse du risque encouru par l’organisation : il faut déterminer comment agir pour le réduire. Cette analyse peut-être très brève si :

  • l’impact et la vraisemblance de l’exploitation sont critiques,
  • le périmètre reste restreint,
  • le correctif demeure facile à mettre en œuvre et sans impact.

Dans ces conditions, l’application de la remédiation doit être immédiate. En effet, une vulnérabilité qui permettrait à un attaquant de prendre facilement le contrôle d’un serveur qui a une fonction métier stratégique pour l’entreprise appelle à l’application d’un correctif ou la mise en œuvre de mesures urgentes. Dans ce cas de figure, certaines organisations choisissent de considérer la présence d’une vulnérabilité critique comme un évènement de sécurité et de la traiter via un processus de gestion des incidents, bien qu’il n’y ait pas nécessairement eu de compromission.

Le travail d’analyse peut également être plus long si :

  • la vulnérabilité est récente et peu maîtrisée,
  • elle concerne un large périmètre du SI,
  • les éditeurs n’ont pas de solutions clés en main pour résoudre de façon fiable le problème comme nous avons pu le voir dernièrement avec les vulnérabilités Meltdown et Spectre.

Dans l’analyse des vulnérabilités, il faut aussi déterminer les conséquences d’un correctif sur les autres briques du SI. Sur un périmètre donné, notamment quand l’exploitation de la vulnérabilité reste faible, il est parfois plus risqué de corriger. Une analyse en profondeur permet alors de prendre les bonnes décisions.

Etape 4 : prendre les bonnes décisions

La détection de vulnérabilités, suivie d’une analyse plus ou moins poussée n’aurait pas de sens sans nommer des personnes référentes pour décider des actions à mettre en œuvre.

Les informations et rapports doivent être remontés à des comités suivant un processus d’escalade clairement identifié et documenté. Les décisionnaires peuvent se réunir périodiquement pour traiter régulièrement les vulnérabilités plutôt faibles ou modérées dont le risque pour le SI reste mineur. Pour les vulnérabilités majeures, des comités exceptionnels peuvent avoir lieu. Ils sont composés d’un certain nombre d’acteurs que l’on trouvera dans différentes instances en fonction du niveau d’escalade choisi comme les officiers de sécurité, le RSSI* opérationnel, le RSSI d‘une filiale, le RSSI groupe, le directeur d’exploitation ou le DSI**.

Ces comités sont prévus pour :

  • informer et consulter les participants,
  • analyser les risques et la faisabilité des remédiations,
  • prendre les décisions pour traiter les vulnérabilités,
  • valider un plan d’action.

Etape 5 : Plan Do Check Act

Le plan d’action est élaboré grâce au travail commun des différentes équipes en charge des composants impactés. Ce sont elles qui sauront le mieux comment déployer le correctif (environnement de recette, pré-production, population pilote, production…). Pour chaque action, doivent figurer au minimum :

  • le ou les composants cibles,
  • le responsable et les différents acteurs,
  • l’action à mener (de manière suffisamment détaillée pour empêcher toute mauvaise interprétation).

Les organisations fonctionnent souvent avec un outil de ticketing qui permet d’attribuer à un individu, un groupe, ou plus largement à une entité la responsabilité d’une action. Il est recommandé de suivre l’avancement du plan d’action dans un tableau de bord de la sécurité afin notamment de pouvoir en reporter l’état aux différents comités et responsables.

Le risque zéro n’existant pas, une attaque peut arriver alors que le plan d’action est en train d’être mis en œuvre.  Savoir quels systèmes sont patchés et quels autres sont encore faillibles se révèle alors d’une grande importance.

Le suivi doit s’accompagner d’un contrôle qui vise à vérifier que les mesures sont correctement appliquées et ne présentent pas de régression en matière de sécurité ou d’altération de performance. Ces contrôles peuvent être appliqués sur l’ensemble des composants vulnérables, ou sur un panel d’échantillons représentatifs selon le contexte. Un audit (ou contre-audit s’il a déjà eu lieu), peut être un moyen adéquat pour effectuer cette vérification et identifier les éléments qui permettront d’agir en conséquence.

Etape 6 : apprendre et devenir meilleur

Il y a souvent matière pour l’organisation à capitaliser sur des problématiques de sécurité, y compris sur les vulnérabilités, surtout si elles ont échappé au radar.

Elles peuvent être l’occasion :

  • d’élargir le périmètre de veille,
  • de travailler la mise à jour des bases de connaissances technologiques plus régulièrement,
  • de cibler de nouveaux périmètres d’audit,
  • d’étendre les scans automatiques de sécurité,
  • d’amender le processus de patch management en vigueur,
  • de revoir le choix des outils de gestion et de distribution de patchs si ceux-ci n’ont pas l’efficacité attendue.

Les vulnérabilités détectées peuvent être intégrées au programme de sensibilisation des équipes techniques pour travailler à éviter de reproduire les mêmes erreurs à l’avenir. Elles peuvent servir aux différentes équipes en charge de la sécurité et notamment :

  • aux auditeurs, qui pourront rejouer ces tests sur d’autres composants ou s’en inspirer pour mener des attaques plus élaborées,
  • aux équipes CERT/CSIRT***, qui, dans leurs activités de threat hunting auront de nouveaux scénarios à explorer et de nouvelles traces à analyser,
  • aux équipes SOC****, qui pourront travailler sur l’intégration de nouveaux indicateurs de compromission ou affiner ceux existants.

Conclusion

PME, administrations ou grands groupes, chacun développera sa propre approche de la gestion des vulnérabilités et se doit de l’améliorer continuellement au regard de l’actualité et de son propre contexte. A l’évidence, une TPE ne fera pas ce que fait un groupe du CAC 40.

L’agilité sera à privilégier autant que possible, ne serait-ce que pour des raisons d’efficience, alors qu’à certains endroits, davantage de cadre s’imposera pour répondre aux contraintes de l’environnement et du contexte.

 

Glossaire :

*RSSI : responsable de la sécurité des systèmes d’information

**DSI : directeur des systèmes d’information

***CERT : computer emergency response team / CSIRT : computer security incident response team

****SOC : security operation center