Article principal de la série : Décrocher la certification CISSP 2026. Ce tutoriel approfondit le domaine 6 du CBK 2024 — 12 % de l’examen. Il porte sur l’évaluation systématique de la posture de sécurité : audits, scans de vulnérabilité, tests d’intrusion, revues de code, indicateurs et rapports. Le défi pour le candidat est de distinguer chaque type d’évaluation et de savoir quand l’utiliser.
Prérequis
- Domaines 1 à 5 maîtrisés
- Familiarité avec au moins un scanner de vulnérabilité (Nessus, OpenVAS, Qualys)
- Temps estimé : 15 à 20 heures sur deux semaines
Étape 1 — Distinguer les types d’évaluations
Le vocabulaire d’évaluation est testé à l’examen avec une précision pénible. Quatre familles à différencier.
| Évaluation | Objectif | Profondeur |
|---|---|---|
| Scan de vulnérabilité | Identifier des faiblesses connues | Automatique, large mais superficiel |
| Pentest | Démontrer l’exploitabilité réelle | Manuel et profond, sur périmètre restreint |
| Audit | Vérifier la conformité à un référentiel | Documentaire et entretiens |
| Évaluation des contrôles | Mesurer l’efficacité opérationnelle | Combine documentation, tests et observation |
Un piège classique demande lequel choisir pour prouver qu’un risque résiduel existe avant un déploiement. La bonne réponse est le pentest — lui seul valide qu’une faiblesse théorique est réellement exploitable. À l’inverse, pour produire un rapport demandé par un commissaire aux comptes, c’est l’audit qui répond — pas le pentest, qui n’a pas vocation à attester de la conformité.
Étape 2 — SOC 1, SOC 2 et SOC 3
Les rapports SOC (System and Organization Controls) sont produits par un cabinet comptable indépendant selon les normes AICPA. Vous devez distinguer leur portée et leur public.
| Rapport | Portée | Audience |
|---|---|---|
| SOC 1 | Contrôles impactant le reporting financier | Auditeurs externes financiers |
| SOC 2 | Contrôles sur les 5 Trust Services Criteria (Sécurité, Disponibilité, Confidentialité, Intégrité de traitement, Vie privée) | Clients de services cloud, sous-traitants |
| SOC 3 | Résumé public d’un SOC 2 | Marketing, grand public |
Chaque rapport existe en Type I (point dans le temps, conception des contrôles) ou Type II (sur une période de 6 à 12 mois, efficacité opérationnelle). Le SOC 2 Type II est l’attente standard pour un fournisseur SaaS B2B en 2026 — un SOC 2 Type I seul est jugé insuffisant par les grands comptes.
Étape 3 — Scan de vulnérabilité authentifié et non authentifié
Un scan non authentifié simule la vue d’un attaquant externe sans credentials — il identifie les services exposés, leurs versions, et les vulnérabilités publiquement détectables. Un scan authentifié utilise des credentials privilégiés sur les hôtes pour énumérer les patches manquants, les configurations faibles et les CVE applicables à l’inventaire logiciel.
Le scan authentifié est plus complet — il découvre typiquement deux à dix fois plus de vulnérabilités que le scan non authentifié. À l’examen, si la question demande la profondeur maximale, la réponse est scan authentifié. Si elle demande la vue attaquant, c’est non authentifié.
Trois métriques à connaître sur les vulnérabilités. CVSS 4.0 (Common Vulnerability Scoring System, publié novembre 2023) est le scoring standard sur 10 : Base, Threat (anciennement Temporal), Environmental, Supplemental. CVE (Common Vulnerabilities and Exposures) est l’identifiant unique d’une faille. EPSS (Exploit Prediction Scoring System, FIRST.org) prédit la probabilité d’exploitation dans les 30 jours — utile pour prioriser au-delà du CVSS brut.
Étape 4 — Méthodologie de pentest
Les standards examinables sont PTES (Penetration Testing Execution Standard) et NIST SP 800-115. Tous deux structurent le pentest en phases que vous devez connaître dans l’ordre.
| Phase | Activité | Livrable |
|---|---|---|
| Pre-engagement | Scope, ROE, autorisations légales | Rules of Engagement signées |
| Reconnaissance | OSINT, énumération passive et active | Inventaire des assets |
| Scanning | Découverte de services et de vulnérabilités | Liste priorisée |
| Exploitation | Validation par exploitation | Preuves (screenshots, logs) |
| Post-exploitation | Pivot, élévation, persistance simulée | Cartographie de l’impact |
| Reporting | Rédaction et restitution | Rapport exécutif et technique |
Trois variantes opèrent selon la connaissance partagée. Black box : l’équipe n’a aucune information préalable, simulation d’attaquant externe. Gray box : connaissance partielle, simulation d’un utilisateur authentifié. White box : connaissance complète, accès au code source et à la documentation. Le ratio coût/couverture varie : black box couvre la surface visible, white box couvre la profondeur du code.
Une variante moderne très examinée est le Red Team, qui se distingue du pentest classique par sa durée (semaines à mois), son objectif (atteindre une cible définie, dite crown jewel) et son réalisme (techniques d’attaquant avancé, évasion de la détection). Le Red Team est complémentaire du Blue Team (équipe de défense) et du Purple Team (collaboration des deux pour améliorer la détection).
Étape 5 — Revue de code et tests applicatifs
Trois familles d’outillage à connaître. SAST (Static Application Security Testing) analyse le code source sans l’exécuter — détecte les patterns de vulnérabilité, intègre dans le pipeline CI/CD. SonarQube, Checkmarx, Snyk Code, Semgrep sont des références. DAST (Dynamic Application Security Testing) attaque l’application en cours d’exécution avec des charges connues — ZAP by Checkmarx (rebrand de l’historique OWASP ZAP en septembre 2024 après reprise par Checkmarx), Burp Suite, Acunetix. IAST (Interactive Application Security Testing) hybride : un agent instrumente l’application pendant ses tests fonctionnels et corrèle les flux suspects.
Le piège examen oppose souvent SAST et DAST. SAST trouve les vulnérabilités tôt dans le SDLC (à chaque commit), mais a un taux de faux positifs élevé. DAST trouve les vulnérabilités tard (après déploiement en environnement de test) mais avec un taux de faux positifs faible. La combinaison SAST + DAST + SCA (Software Composition Analysis sur les dépendances tierces) constitue le triptyque AppSec moderne.
La revue manuelle de code reste indispensable pour les logiques métiers complexes et les flux d’authentification. Aucun outil ne remplace un humain qualifié sur ces sujets — l’examen le mentionne explicitement.
Étape 6 — Indicateurs et tableaux de bord
Vous devez distinguer trois familles d’indicateurs. KGI (Key Goal Indicator) mesure l’atteinte d’un objectif (ex : « réduire de 80 % les incidents critiques sur 12 mois »). KPI (Key Performance Indicator) mesure la performance d’un processus (ex : « MTTR moyen des incidents critiques »). KRI (Key Risk Indicator) mesure l’évolution d’un risque (ex : « nombre de vulnérabilités critiques non patchées > 30 jours »).
Pour un programme sécurité enterprise, un tableau de bord équilibré combine indicateurs de couverture (% d’actifs scannés, % de comptes en MFA), indicateurs de performance (MTTD, MTTR, taux de complétude des plans d’action) et indicateurs de risque (nombre d’incidents par niveau, exposition externe). La fréquence d’actualisation va du temps réel (SOC) au mensuel (Comex). La traduction de ces métriques en tableau de bord destiné au COMEX est détaillée côté management dans la série CISM, avec exemples de KPI défendables devant un comité exécutif.
Étape 7 — Programme d’audit et plan annuel
Un programme d’audit sécurité formalise un plan annuel qui priorise les domaines à auditer selon le risque, la criticité métier, les obligations réglementaires et les conclusions des audits précédents. Le plan classique combine audits internes (équipe interne), audits externes (cabinet indépendant) et audits réglementaires (contraintes légales : RGPD, PCI DSS Qualified Security Assessor).
La méthodologie d’audit suit cinq étapes : planification (scope, équipe, calendrier), exécution (entretiens, revue documentaire, tests de contrôles), analyse (écarts vs référentiel), restitution (rapport, plan d’action), suivi (vérification de la mise en œuvre des correctifs). L’auditeur doit conserver son indépendance — il ne peut pas auditer un système qu’il a lui-même conçu ou opéré.
Étape 8 — Gestion des données de test
Un piège récurrent à l’examen : la donnée de production ne doit jamais être utilisée telle quelle dans un environnement de test. Trois techniques de protection : anonymisation (suppression irréversible des identifiants), pseudonymisation (remplacement par un identifiant sans lien, réversible avec une table de correspondance — couvert par le RGPD), masquage (remplacement à la volée à la requête).
La data minimization impose de ne charger en environnement de test que les données strictement nécessaires aux scénarios. Pour les bases volumineuses, un sous-ensemble représentatif (subset) avec masquage déterministe (deux fois le même input produit le même output, pour préserver les jointures) est l’approche industrielle.
Étape 9 — Revue des journaux et corrélation
La revue des journaux est testée à l’examen comme un contrôle de détection à part entière. Trois sources critiques à journaliser et conserver : authentifications (réussies et échouées), changements de privilèges et de configuration, accès aux données sensibles. La durée de rétention doit être alignée sur les obligations légales applicables — par défaut, 12 mois opérationnels minimum, jusqu’à 7 ans pour les flux financiers (SOX).
Les logs doivent être centralisés dans un dépôt protégé en écriture (WORM ou append-only) pour résister à un attaquant qui voudrait effacer ses traces. Les architectures modernes combinent un syslog agrégateur, un pipeline d’ingestion avec normalisation (Logstash, Vector, Fluent Bit), et un magasin recherchable (OpenSearch, ClickHouse, Loki). Le SIEM ajoute par-dessus la corrélation de règles et le scoring d’alertes.
La revue manuelle des journaux n’est ni réaliste ni efficace au-delà de quelques milliers d’événements par jour. La UEBA (User and Entity Behavior Analytics) est la couche d’analyse comportementale qui détecte les écarts par rapport au profil normal — utilisateur qui accède à 10 fois plus de fichiers que d’habitude, machine qui se connecte à un pays inhabituel, compte de service qui exécute des commandes interactives. Le coût opérationnel est l’ajustement des seuils pour limiter les faux positifs.
Étape 10 — Bug bounty et coordinated disclosure
Les programmes de bug bounty incitent des chercheurs externes à signaler des vulnérabilités contre récompense financière. Plateformes de référence : HackerOne, Bugcrowd, Intigriti, YesWeHack. Le programme définit le périmètre (in-scope), les exclusions (out-of-scope), la grille de récompenses par sévérité et les règles de divulgation. Cinq erreurs classiques de programme : périmètre trop étroit (chercheurs frustrés), grille trop faible (talent qui part ailleurs), absence de SLA de réponse (délais > 30 jours), divulgation publique uniquement après patch sans crédit chercheur, conditions juridiques agressives qui dissuadent la participation.
La coordinated vulnerability disclosure (CVD, ex-responsible disclosure, ISO/IEC 29147) encadre le processus de signalement par un tiers en dehors de tout programme : l’organisation publie un canal de réception (security.txt à la racine du domaine selon RFC 9116), accuse réception sous 72 heures, corrige sous un délai raisonnable (typiquement 90 jours), crédite le chercheur dans la publication de la CVE. Le standard ISO/IEC 29147:2018 codifie cette pratique et est cité dans le CBK 2024.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| Confondre pentest et audit | Vocabulaire flou | Pentest = exploitabilité ; audit = conformité |
| Accepter un SOC 2 Type I comme suffisant | Méconnaissance Type I vs II | SOC 2 Type II sur 6-12 mois pour B2B |
| Lire CVSS comme priorité absolue | Score brut ignorant le contexte | Combiner CVSS + EPSS + exposition réelle |
| Utiliser la donnée de prod en test | Facilité opérationnelle | Anonymisation ou masquage obligatoires |
| Confondre KPI et KRI | Acronymes proches | KPI = performance ; KRI = risque |
Tutoriels frères
- Retour au guide principal : Décrocher la certification CISSP 2026
- Précédent : Domaine 5 — Identity and Access Management
- Suite : Domaine 7 — Security Operations
Ressources et références
- CVSS v4.0 — Common Vulnerability Scoring System
- EPSS — Exploit Prediction Scoring System
- PTES — Penetration Testing Execution Standard
- NIST SP 800-115 — Technical Guide to Information Security Testing
- AICPA — SOC pour service organizations
- OWASP Web Security Testing Guide v4.2
Foire aux questions
Pentest interne ou externe en 2026 ?
Les deux. Un pentest externe annuel par un cabinet indépendant pour la posture exposée, un pentest interne semestriel pour le réseau interne et les applications critiques, des Red Team annuels pour les organisations matures. C’est complémentaire, pas substituable.
Pourquoi pas remplacer l’audit par un scan automatique ?
L’audit vérifie l’existence et l’efficacité des contrôles, pas seulement leur configuration technique. Une politique correcte sur papier mais non appliquée dans les faits ne passe pas un audit, même si le scan est vert. Les deux sont complémentaires.
Faut-il un SOC 2 pour un éditeur SaaS B2B en 2026 ?
Pour vendre à des grands comptes US et européens, oui — c’est devenu un prérequis contractuel quasi systématique au-delà d’un certain volume. Un SOC 2 Type II coûte entre 30 000 et 100 000 USD selon la taille et la complexité, plus un travail de préparation de 6 à 12 mois.
CVSS 3.1 ou CVSS 4.0 en 2026 ?
CVSS 4.0 (publié novembre 2023) est la norme cible et est utilisé par NVD pour les nouveaux CVE. CVSS 3.1 reste largement déployé sur les bases existantes — la transition est progressive. Lire les deux est attendu d’un candidat CISSP 2026.
Prérequis pratique : avant d’aller plus loin, préparer son environnement Burp Suite.