Évaluation des vulnérabilités à partir du guide Kali Linux par OnWorks

Passer au contenu

<Précédent | Table des matières | Suivant>

11.2.1. Évaluation de la vulnérabilité‌

A vulnérabilité est considérée comme une faiblesse qui pourrait être utilisée d'une manière ou d'une autre pour compromettre la confidentialité, l'intégrité ou la disponibilité d'un système d'information. Dans une évaluation de vulnérabilité, votre objectif est de créer un inventaire simple des vulnérabilités découvertes dans le environnement cible. Ce concept d'environnement cible est extrêmement important. Vous devez vous assurer de rester dans le périmètre du réseau cible de votre client et des objectifs requis. Sortir du cadre d'une évaluation peut entraîner une interruption de service, un abus de confiance avec votre client ou des poursuites judiciaires contre vous et votre employeur.

En raison de sa relative simplicité, un test de vulnérabilité est souvent effectué régulièrement dans des environnements plus matures dans le cadre de la démonstration de leur diligence raisonnable. Dans la plupart des cas, un outil automatisé, comme ceux de l'analyse de vulnérabilité7 et applications Web8 catégories du site Kali Tools et du menu Applications de bureau Kali, est utilisé pour découvrir les systèmes en direct dans un environnement cible, identifier les services d'écoute et les énumérer pour découvrir autant d'informations que possible telles que le logiciel serveur, la version, la plate-forme, etc. .

Ces informations sont ensuite vérifiées pour les signatures connues de problèmes ou de vulnérabilités potentiels. Ces signatures sont constituées de combinaisons de points de données destinées à représenter des problèmes connus. Plusieurs points de données sont utilisés, car plus vous utilisez de points de données, plus l'identification est précise. Il existe un très grand nombre de points de données potentiels, y compris, mais sans s'y limiter :

• Version du système d'exploitation : il n'est pas rare qu'un logiciel soit vulnérable sur une version du système d'exploitation mais pas sur une autre. Pour cette raison, l'analyseur tentera de déterminer, aussi précisément que possible, quelle version du système d'exploitation héberge l'application ciblée.

• Niveau de correctif : plusieurs fois, des correctifs pour un système d'exploitation seront publiés qui n'augmentent pas les informations de version, mais modifient quand même la façon dont une vulnérabilité répondra, voire éliminera complètement la vulnérabilité.

• Architecture de processeur : de nombreuses applications logicielles sont disponibles pour plusieurs architectures de processeur telles qu'Intel x86, Intel x64, plusieurs versions d'ARM, UltraSPARC, etc.

5https://en.wikipedia.org/wiki/Executable_space_protection#Windows 6https://en.wikipedia.org/wiki/Address_space_layout_randomization 7http://tools.kali.org/category/vulnerability-analysis 8http://tools.kali.org/category/web-applications‌‌‌

Dans certains cas, une vulnérabilité n'existera que sur une architecture spécifique, donc connaître cette information peut être critique pour une signature précise.

• Version du logiciel : la version du logiciel ciblé est l'un des éléments de base qui doit être capturé pour identifier une vulnérabilité.

Ceux-ci, et de nombreux autres points de données, seront utilisés pour constituer une signature dans le cadre d'une analyse de vulnérabilité. Comme prévu, plus il y a de points de données qui correspondent, plus la signature sera précise. Lorsque vous traitez des correspondances de signature, vous pouvez avoir quelques résultats potentiels différents :

• True Positive : la signature est mise en correspondance et elle capture une véritable vulnérabilité. Ces résultats sont ceux que vous devrez suivre et corriger, car ce sont les éléments dont les individus malveillants peuvent profiter pour nuire à votre organisation (ou à celle de votre client).

• Faux positif : la signature est appariée ; cependant, le problème détecté n'est pas une véritable vulnérabilité. Dans une évaluation, ceux-ci sont souvent considérés comme du bruit et peuvent être assez frustrants. Vous ne voulez jamais rejeter un vrai positif comme un faux positif sans une validation plus approfondie.

• True Negative : la signature n'est pas appariée et il n'y a aucune vulnérabilité. C'est le scénario idéal, vérifier qu'une vulnérabilité n'existe pas sur une cible.

• False Negative : la signature ne correspond pas mais il existe une vulnérabilité. Aussi mauvais que soit un faux positif, un faux négatif est bien pire. Dans ce cas, un problème existe mais le scanner ne l'a pas détecté, vous n'avez donc aucune indication de son existence.

Comme vous pouvez l'imaginer, l'exactitude des signatures est extrêmement importante pour des résultats précis. Plus il y a de données fournies, plus il y a de chances d'avoir des résultats précis à partir d'une analyse automatisée basée sur les signatures, c'est pourquoi les analyses authentifiées sont souvent si populaires.

Avec une analyse authentifiée, le logiciel d'analyse utilisera les informations d'identification fournies pour s'authentifier auprès de la cible. Cela offre un niveau de visibilité plus profond sur une cible que ce qui serait autrement possible. Par exemple, lors d'une analyse normale, vous ne pouvez détecter que des informations sur le système qui peuvent être dérivées des services d'écoute et les fonctionnalités qu'ils fournissent. Cela peut parfois représenter pas mal d'informations, mais cela ne peut rivaliser avec le niveau et la profondeur des données qui seront obtenues si vous vous authentifiez auprès du système et examinez de manière exhaustive tous les logiciels installés, les correctifs appliqués, les processus en cours, etc. . Cet éventail de données est utile pour détecter des vulnérabilités qui, autrement, n'auraient peut-être pas été découvertes.

Une évaluation de la vulnérabilité bien menée présente un instantané des problèmes potentiels dans une organisation et fournit des métriques pour mesurer les changements au fil du temps. Il s'agit d'une évaluation assez légère, mais même quand même, de nombreuses organisations effectueront régulièrement des analyses de vulnérabilité automatisées en dehors des heures de bureau pour éviter les problèmes potentiels pendant la journée, lorsque la disponibilité du service et la bande passante sont les plus critiques.

Comme mentionné précédemment, une analyse de vulnérabilité devra vérifier de nombreux points de données différents afin d'obtenir un résultat précis. Toutes ces différentes vérifications peuvent créer une charge sur le système cible et consommer de la bande passante. Malheureusement, il est difficile de savoir exactement combien de ressources seront consommées sur la cible car cela dépend du nombre de services ouverts et des types de

chèques qui seraient associés à ces services. C'est le coût d'une analyse ; il va occuper les ressources du système. Il est important d'avoir une idée générale des ressources qui seront consommées et de la charge que le système cible peut supporter lors de l'exécution de ces outils.

Fils d'analyse La plupart des scanners de vulnérabilité incluent une option pour définir threads par analyse, ce qui équivaut au nombre de vérifications simultanées qui se produisent en même temps. L'augmentation de ce nombre aura un impact direct sur la charge de la plate-forme d'évaluation ainsi que sur les réseaux et les cibles avec lesquels vous interagissez. Ceci est important à garder à l'esprit lorsque vous utilisez ces scanners. Il est tentant d'augmenter les threads afin de terminer les analyses plus rapidement, mais n'oubliez pas l'augmentation substantielle de la charge associée à cette opération.

Lorsqu'une analyse de vulnérabilité est terminée, les problèmes découverts sont généralement liés aux identifiants standard de l'industrie tels que le numéro CVE9, ID EDB10, et les avis aux fournisseurs. Ces informations, ainsi que le score de vulnérabilités CVSS11, est utilisé pour déterminer une cote de risque. Outre les faux négatifs (et les faux positifs), ces cotes de risque arbitraires sont des problèmes courants qui doivent être pris en compte lors de l'analyse des résultats de l'analyse.

Les outils automatisés utilisant une base de données de signatures pour détecter les vulnérabilités, tout léger écart par rapport à une signature connue peut altérer le résultat ainsi que la validité de la vulnérabilité perçue. Un faux positif signale à tort une vulnérabilité qui n'existe pas, tandis qu'un faux négatif est effectivement aveugle à une vulnérabilité et ne la signale pas. Pour cette raison, on dit souvent qu'un scanner est aussi bon que sa base de règles de signature. Pour cette raison, de nombreux fournisseurs proposent des ensembles de signatures multiples : un qui peut être gratuit pour les utilisateurs à domicile et un autre assez cher et plus complet, qui est généralement vendu aux entreprises.

L'autre problème souvent rencontré avec les analyses de vulnérabilité est la validité des cotes de risque suggérées. Ces cotes de risque sont définies sur une base générique, en tenant compte de nombreux facteurs différents tels que le niveau de privilège, le type de logiciel et la pré- ou post-authentification. Selon votre environnement, ces évaluations peuvent être applicables ou non, elles ne doivent donc pas être acceptées aveuglément. Seuls ceux qui connaissent bien les systèmes et les vulnérabilités peuvent valider correctement les cotes de risque.

Bien qu'il n'y ait pas d'accord universellement défini sur les cotes de risque, la publication spéciale NIST 800-3012 est recommandé comme référence pour l'évaluation des cotes de risque et de leur exactitude dans votre environnement. NIST SP 800-30 définit le risque réel d'une vulnérabilité découverte comme une combinaison de la probabilité d'occurrence et de l'impact potentiel.

9https://cve.mitre.org 10https://www.exploit-db.com/about/ 11https://www.first.org/cvss‌‌‌

12http://csrc.nist.gov/publications/PubsSPs.html#800-30