Analyse des vulnérabilités ou tests d’intrusion

La sécurité réactive répond aux attaques après leur survenue ; la sécurité proactive détecte et corrige les faiblesses avant que les attaquants ne puissent les exploiter. Deux pratiques proactives complémentaires sont l’analyse des vulnérabilités et les tests d’intrusion. Toutes deux identifient les faiblesses de sécurité, mais elles diffèrent considérablement par leur portée, leur méthodologie, leurs exigences d’autorisation, leur niveau de risque et les éléments qu’elles fournissent à l’organisation. Il est essentiel de comprendre ces différences pour les candidats à Security+ et pour expliquer aux parties prenantes ce que chaque activité peut — et ne peut pas — révéler sur votre niveau de sécurité.

L’analyse des vulnérabilités est un processus automatisé qui vérifie les systèmes par rapport à une base de données de vulnérabilités connues. Les scanners comparent les numéros de version, les paramètres de configuration et les signatures des logiciels aux bases de données CVE et aux avis des fournisseurs afin d’identifier les faiblesses potentielles. L’analyse est généralement non intrusive : elle détermine qu’une vulnérabilité existe probablement en fonction de la version ou de la configuration, mais n’essaie généralement pas de l’exploiter. Les analyses peuvent être exécutées régulièrement (tous les jours, chaque semaine ou en continu) et à grande échelle sur des milliers de systèmes. Elles constituent une exigence de conformité dans le cadre de PCI-DSS (analyses externes trimestrielles par un ASV) et de nombreux autres frameworks.

Les tests d’intrusion constituent une tentative structurée et orientée vers un objectif visant à compromettre des systèmes en utilisant les mêmes techniques que des attaquants. Contrairement à l’analyse, le test d’intrusion exploite activement les vulnérabilités afin de confirmer qu’elles sont réelles et exploitables, et pas seulement présentes en théorie. Le testeur d’intrusion démontre l’impact réel : peut-il obtenir un accès privilégié ? Peut-il exfiltrer des données ? Peut-il se déplacer latéralement d’un système à un autre ? Les tests d’intrusion apportent une preuve de l’exploitabilité qui justifie l’urgence de la Remediation et révèlent souvent des chemins d’attaque complexes en plusieurs étapes qu’un Scanner automatisé ne peut pas identifier.

Effectuer un test d’intrusion sans autorisation est illégal : cela constitue un accès non autorisé au regard de lois telles que la CFAA (Computer Fraud and Abuse Act) aux US. Avant le début de tout test d’intrusion, un document relatif aux règles d’engagement (RoE) doit être signé. Il définit notamment : le périmètre (systèmes, plages d’IP et domaines concernés), la plage horaire (heures ouvrées ou non), les actions interdites (aucune attaque physique, aucun DoS contre la production), les contacts d’urgence et les signatures d’autorisation. Les lettres d’autorisation transportées par l’équipe de test d’intrusion prouvent son autorisation si elle est découverte par le personnel de Security. Ne commencez jamais un test sans autorisation écrite complète.

Les tests d’intrusion sont classés selon la quantité d’informations dont dispose le testeur sur la cible. Un test en boîte noire ne fournit aucune information préalable : le testeur commence comme le ferait un attaquant externe, en utilisant OSINT et l’analyse pour découvrir les cibles. C’est l’approche la plus réaliste, mais elle peut laisser passer des vulnérabilités internes. Un test en boîte blanche fournit toutes les informations : schémas réseau, code source, Credentials, ce qui permet un test approfondi mais moins réaliste. Un test en boîte grise fournit des informations partielles (par exemple, un compte d’utilisateur standard) et représente le scénario d’un initié dont le compte a été compromis ou de Credentials volées. La plupart des missions réelles sont menées en boîte grise ou en boîte noire.

Les tests d’intrusion ciblent différents points d’observation. Un test externe simule un attaquant sur Internet sans accès interne : il évalue les défenses périmétriques, les applications accessibles depuis Internet et la Security des courriels. Un test interne simule un acteur malveillant déjà présent dans le réseau (employé compromis ou rebond effectué par un logiciel malveillant) : il évalue les contrôles des déplacements latéraux, la Security des applications internes et le renforcement d’Active Directory. La plupart des organisations tirent profit des deux perspectives. De nombreuses compromissions réelles impliquent un attaquant externe qui obtient un accès initial puis se déplace à l’intérieur du réseau ; les deux types de tests réalisés ensemble sont donc plus utiles que l’un ou l’autre pris isolément.

Les Scanner de vulnérabilités sont imparfaits. Un faux positif survient lorsque le Scanner signale une vulnérabilité qui n’existe pas réellement, par exemple parce qu’un numéro de version semble vulnérable alors que le correctif a été rétroporté. Les faux positifs gaspillent les ressources consacrées à la Remediation et diminuent la confiance dans les résultats du Scanner. Un faux négatif survient lorsqu’une vulnérabilité réelle existe mais que le Scanner ne la détecte pas, par exemple parce qu’elle nécessite une authentification alors que l’analyse n’était pas authentifiée, ou parce qu’elle est récente et ne figure pas encore dans la base de données. Les analyses avec Credentials réduisent considérablement les faux positifs et les faux négatifs par rapport aux analyses non authentifiées.

Les programmes de Security modernes considèrent la gestion des vulnérabilités comme un processus continu plutôt que comme un événement périodique. L’analyse continue détecte les nouvelles vulnérabilités dès leur apparition (ainsi que lors de la publication de nouveaux CVE), au lieu d’attendre la prochaine fenêtre d’analyse planifiée. Le cycle de vie de la gestion des vulnérabilités comprend les étapes suivantes : découvrir, prioriser (selon le score CVSS et le contexte métier), corriger (appliquer un correctif, configurer ou accepter), vérifier (effectuer une nouvelle analyse pour confirmer la correction), puis établir un rapport. L’intégration de la gestion des correctifs garantit que les vulnérabilités découvertes déclenchent des flux de déploiement automatisé des correctifs. Les SLA définissent le délai dans lequel les vulnérabilités de chaque niveau de gravité doivent être corrigées (par exemple, Critical : 24 heures ; High : 7 jours).

Un test d’intrusion se conclut par un rapport complet, qui constitue le principal livrable. Le rapport comprend généralement : un résumé exécutif destiné aux responsables non techniques (niveau de RISK global, impact métier, principaux résultats) ; une section consacrée aux résultats techniques (descriptions détaillées des vulnérabilités, captures d’écran servant de preuves et étapes de reproduction) ; ainsi qu’une feuille de route de Remediation présentant des recommandations hiérarchisées. Les résultats sont généralement classés par niveau de RISK (Critical/High/Medium/Low) au moyen des scores CVSS, complétés par le contexte métier. Un bon rapport de test d’intrusion permet au client de reproduire et de vérifier chaque résultat, ainsi que de comprendre précisément quelle Remediation est requise.

Les programmes de chasse aux bogues rémunèrent des chercheurs externes en Security qui recherchent des vulnérabilités dans les systèmes d’une organisation et les signalent de manière responsable. Des plateformes telles que HackerOne, Bugcrowd et Intigriti mettent les organisations en relation avec des milliers de chercheurs en Security dans le monde. Les primes offrent une évaluation externe continue à grande échelle, le paiement n’étant effectué que pour les résultats validés. Elles complètent les tests d’intrusion internes en apportant des points de vue variés et des tests continus entre les évaluations formelles. Les résultats Critical sont généralement rémunérés entre 500 et plus de 50 000 dollars selon leur gravité et le programme. Les organisations définissent le périmètre et les règles de manière similaire aux règles d’engagement d’un test d’intrusion.

Pour l’examen Security+, vous devez clairement comprendre les principales différences. Analyse des vulnérabilités : automatisée, non destructive, avec une couverture étendue ; elle identifie les vulnérabilités potentielles, ne confirme pas leur exploitabilité, est fréquente ou continue et est réalisée par le personnel interne. Test d’intrusion : manuel (ou semi-automatisé), potentiellement perturbateur, avec une couverture ciblée et approfondie ; il confirme l’exploitabilité réelle et l’impact dans le monde réel, est périodique (trimestriel ou annuel) et nécessite généralement une expertise externe spécialisée ainsi qu’une autorisation formelle. Les deux approches sont complémentaires : l’analyse offre une couverture étendue, tandis que le test d’intrusion apporte de la profondeur. Un programme de Security mature utilise régulièrement les deux.

Vérifiez votre compréhension des concepts de CompTIA Security+ (SY0-701) présentés dans cette leçon.

Dans cette leçon, vous avez appris que l’analyse des vulnérabilités est automatisée, fréquente et non intrusive : elle identifie les vulnérabilités potentielles sans les exploiter ; tandis que le test d’intrusion est manuel, orienté vers un objectif et exploite activement les vulnérabilités afin de démontrer un impact réel et des chemins d’attaque. Les deux nécessitent une autorisation appropriée au moyen de documents relatifs aux règles d’engagement. L’analyse avec Credentials réduit considérablement les faux positifs et les faux négatifs par rapport aux analyses non authentifiées. Nous allons ensuite découvrir des outils d’analyse courants, notamment Nessus, OpenVAS et Nmap.