Les tests de vulnérabilité

Domaine 6 du CISSP

Dans les domaines du CISSP, on demande… le sixième ! Le domaine 6 (évaluation et tests de sécurité) dépend du domaine 1 (gestion des risques), alimente le domaine 7 (opérations de sécurité) et soutient le domaine 8 (sécurité applicative).

Objectif

Le domaine 6 vise à vérifier que :

• Les contrôles de sécurité sont bien conçus.
• Ils sont mis en œuvre correctement.
• Ils fonctionnent comme prévu.
• Ils répondent aux exigences réglementaires et organisationnelles.

Stratégies d’évaluation

Avant de tester quoi que ce soit, il faut une approche structurée. Une stratégie d’évaluation inclut plusieurs éléments.

• Les objectifs (conformité ? robustesse ? maturité ?)
• Le périmètre (systèmes internes, cloud, applications, fournisseurs ?)
• Les méthodes (audit, scan automatisé, test manuel ?)
• La fréquence
• Les responsabilités

On ne teste pas au hasard. Une bonne pratique consiste à aligner les tests sur les résultats de l’analyse de risques, mais aussi sur les exigences réglementaires, les obligations contractuelles et les objectifs métiers.

Dans l'idéal, les évaluations sont indépendantes et objectives. C’est pourquoi les audits internes sont souvent séparés des équipes opérationnelles. Les audits externes renforcent quant à eux la crédibilité.

Types d’évaluation

Un audit ne cherche pas les failles techniques mais des écarts de conformité. Il peut être interne ou externe, de certification, réglementaire… Il évalue le respect de la politique de l'organisation, des standards (ISO 27001, NIST, etc.) et des obligations réglementaires.

Les étapes habituelles d’une mission sont la planification, la collecte de preuves, des entretiens, une analyse, la remise d’un rapport puis un suivi des non-conformités.

Tests de vulnérabilité

Les objectifs des scans sont d’identifier les failles connues, les versions obsolètes, les mauvaises configurations, les ports ouverts, les protocoles faibles…

Un scan de vulnérabilité fonctionne de façon automatique. Il peut être mensuel, hebdomadaire ou même continu et il génère un rapport. Attention, un scan automatisé ne comprend pas les logiques métier, ne détecte pas toujours les vulnérabilités complexes, peut générer des faux positifs et manquer des vulnérabilités zero-day. Le regard humain reste indispensable. Les types de scan sont :

• Le scan réseau : ports ouverts, services exposés (serveur web, messagerie, base de données…), protocoles faibles… En gros, il observe ce qui est exposé à l’extérieur.


• Le scan système : comment la machine est-elle configurée ? Il analyse la version du système d’exploitation, les mises à jour installées ou non, les paramètres de sécurité ou encore les comptes utilisateurs. C’est un peu comme inspecter si l’alarme est activée, si les caméras fonctionnent et si les clés ne traînent pas sur la table. En fait, on cherche surtout des correctifs manquants, des configurations faibles et des paramètres par défaut non sécurisés.


• Le scan applicatif : ici, on teste un site web ou une application en ligne. L’outil va essayer, par exemple, d’envoyer des données inhabituelles, de remplir des formulaires avec du code inattendu ou d’explorer des pages cachées. Exemple de faille cherchée : une injection SQL (manipulation de base de données).


• Le scan authentifié vs non authentifié : non authentifié, l’outil de se connecte pas. Il agit comme un inconnu devant la maison : il voit ce qui est exposé publiquement. Authentifié, il peut se connecter, lire certaines configurations et vérifier les mises à jour. C’est comme si l’inspecteur entrait avec l’autorisation du propriétaire. Ce type de scan est plus précis et détecte davantage de problèmes.


• Le scan de configuration ne cherche pas des failles mais vérifie si un système respecte une bonne pratique ou une norme. Exemples : mots de passe de 12 caractères minimum, chiffrement et journalisation activés. C’est un contrôle de conformité technique.


• Le scan cloud : dans le cloud, on vérifie notamment si des bases de données sont exposées publiquement, si des stockages sont accessibles sans mot de passe et si les droits d’accès sont trop larges. Ce type de scan est devenu très important dans les années 2020.


• Le scan de dépendances logicielles : comme aujourd'hui les applications utilisent beaucoup de bibliothèques externes, ce scan vérifie si celles-ci contiennent une vulnérabilité connue ou si une version obsolète est utilisée. C’est comme vérifier si une pièce achetée chez un fournisseur est défectueuse.

Tests d’intrusion (penetration testing)

Le test d’intrusion (surnommé pentest) simule une attaque réelle menée avec l’autorisation de l’organisation. L’idée n’est pas seulement de repérer des faiblesses théoriques, mais de vérifier si quelqu’un pourrait réellement en profiter pour entrer dans le système, accéder à des données ou perturber un service.

Contrairement au scan où des outils listent automatiquement des problèmes possibles, ce sont ici des spécialistes qui essaient de forcer les portes, non pas pour piéger l’équipe informatique mais pour montrer jusqu’où une attaque pourrait aller et quelles en seraient les conséquences.

Le livrable prend la forme d’un rapport expliquant ce qui a fonctionné, pourquoi c’était possible et comment corriger les points faibles. Cet exercice sert à prendre conscience du risque réel.

Tests de sécurité applicative

Les tests de sécurité applicative consistent à vérifier qu’un site web ou un logiciel ne comporte pas de failles qui pourraient être exploitées par un cyberattaquant.

Concrètement, on essaie d’utiliser l’application d’une manière inhabituelle : saisir des données inattendues dans un formulaire, enchaîner des actions plus vite que prévu ou tenter d’accéder à des pages qui ne devraient pas être visibles. L’application réagit-elle correctement ou se laisse-t-elle tromper ? C’est un peu comme tester un distributeur automatique en appuyant sur différents boutons pour vérifier qu’il ne donne pas un produit gratuitement par erreur.

Ces tests permettent de repérer les erreurs de conception ou de programmation avant qu’un véritable attaquant ne les découvre, puis d’améliorer la solidité du logiciel au fil du temps.

Journalisation et monitoring

L’évaluation ne se limite pas aux tests ponctuels. Il faut surveiller en continu.

Les logs sont des enregistrements automatiques d'événements qui se produisent sur un système informatique (connexion, erreur, modification, accès, etc.). On doit les vérifier : sont-ils activés ? Complets ? Horodatés correctement ? Protégés contre modification ?

Un SIEM est un outil qui centralise et analyse les logs provenant de nombreux systèmes (serveurs, applications, pare-feu, postes de travail…). Plutôt que de consulter chaque journal séparément, il rassemble tout au même endroit et cherche des comportements suspects, par exemple une connexion inhabituelle ou plusieurs tentatives d’accès échouées. Il génère des alertes pour prévenir les équipes de sécurité. L’avantage est une vision globale et en temps réel de ce qui se passe dans l’environnement informatique. En revanche, un SIEM mal configuré peut produire trop d’alertes inutiles, compliquant le travail des équipes.

Autres éléments du domaine 6

• La mesure à l’aide d’indicateurs : KPI (performance) et KRI (risque).
• Les tests de continuité et de reprise.
• L’évaluation des tiers (les fournisseurs mal protégés font courir un risque important).
• La gestion des résultats (corrections après audit et tests).