CISSP Domaine 2 — Asset Security : classification et cycle de vie pas-à-pas

Article principal de la série : Décrocher la certification CISSP 2026. Ce tutoriel approfondit le domaine 2 du CBK 2024, qui pèse 10 % de l’examen. Sujet souvent jugé léger en lecture, il devient piégeux à l’examen sur les frontières entre rôles, sur la sanitisation des supports et sur le scoping/tailoring des contrôles. Ce tutoriel déroule sept étapes pour le verrouiller.

Prérequis

• Avoir digéré le domaine 1 (CIA et hiérarchie politique-standard-procédure)
• Un livre de référence à jour (CBK 2024)
• Temps estimé : 15 à 20 heures sur deux semaines

Étape 1 — Comprendre l’objet du domaine 2

Le domaine 2 traite des actifs informationnels au long de leur cycle de vie. Un actif informationnel est défini par ISC2 comme toute chose ayant de la valeur pour l’organisation — données, mais aussi systèmes, logiciels, équipements, processus métiers et personnes. L’examen attend que vous soyez capable de raisonner sur ces actifs en termes de propriété, de classification, d’états (stockage, transit, utilisation), de cycle de vie, et de destruction sécurisée.

L’angle particulier de ce domaine est qu’il distingue clairement le propriétaire de la donnée — qui décide de sa classification et de qui peut y accéder — du gardien — qui la stocke et la protège techniquement. Cette distinction métier/technique alimente une partie significative des questions d’examen.

Étape 2 — Maîtriser les rôles de la donnée

Les rôles examinables sont au nombre de cinq et leurs frontières sont précises. Confondre owner et custodian coûte plusieurs points.

Le piège classique consiste à demander qui est responsable de la classification — c’est le data owner, jamais le custodian. Autre piège, qui décide du chiffrement — c’est le owner qui décide d’imposer le chiffrement par une politique, et le custodian qui implémente ce chiffrement techniquement. Tester votre compréhension : un consultant externe qui héberge votre CRM est un processor, votre directeur commercial qui en est légalement responsable est l’owner, et votre prospect dont les coordonnées sont stockées est le data subject.

Étape 3 — Maîtriser la classification

Deux échelles coexistent dans le CBK 2024 — une gouvernementale et une commerciale. Vous devez reconnaître l’origine de chaque libellé et la logique de l’organisation qui s’en sert.

Échelle gouvernementale américaine, du plus sensible au moins sensible : Top Secret, Secret, Confidential, Sensitive But Unclassified (SBU), Unclassified. Le critère de classification est le préjudice causé en cas de divulgation non autorisée — exceptionnellement grave, grave, identifiable, limité, inexistant.

Échelle commerciale, du plus sensible au moins sensible : Confidential / Proprietary, Private, Sensitive, Public. Les libellés varient selon les organisations — Restricted, Internal Use Only, Customer Confidential sont des variantes courantes. L’examen accepte les variations à condition que la hiérarchie soit cohérente avec le préjudice associé.

L’erreur fréquente est de classer une donnée selon son contenu apparent au lieu de son impact en cas de fuite. Une liste d’employés peut paraître anodine — elle est en réalité Private, car sa fuite expose au phishing ciblé et viole le RGPD. À l’inverse, un rapport interne marqué Confidential sur la couleur du futur logo n’est Internal qu’au sens commercial, pas un secret industriel au sens légal.

Étape 4 — Maîtriser les trois états de la donnée

La donnée vit dans trois états distincts qui appellent chacun ses contrôles spécifiques.

La donnée au repos (data at rest) est stockée sur disque, sauvegarde, archive. Elle se protège par le chiffrement intégral du volume (BitLocker, LUKS, dm-crypt, FileVault) ou au niveau base de données (TDE Oracle, Always Encrypted SQL Server). Les algorithmes attendus en 2026 sont AES-256 en mode XTS pour les volumes et AES-256-GCM pour les blocs applicatifs.

La donnée en transit (data in transit) circule sur réseau. Elle se protège par TLS 1.3 (RFC 8446) pour les communications applicatives, IPsec en mode tunnel pour les liaisons site-à-site, SSH pour l’administration. Les suites de chiffrement obsolètes (SSLv3, TLS 1.0, TLS 1.1) sont rejetées d’office à l’examen comme en production.

La donnée en utilisation (data in use) est la plus difficile à protéger : elle est déchiffrée en mémoire pour traitement. Les techniques de protection avancées sont le confidential computing avec enclaves TEE (Intel SGX, AMD SEV-SNP, ARM TrustZone) et les techniques de chiffrement homomorphe (encore peu déployées). L’examen ne demande pas l’implémentation, juste de savoir quel état est protégé par quelle approche.

Étape 5 — Pratiquer le cycle de vie complet

Le cycle de vie de la donnée d’ISC2 comporte six étapes obligatoires à retenir dans l’ordre : Create, Store, Use, Share, Archive, Destroy. Chaque étape appelle ses propres contrôles.

À la création, la donnée est marquée et classifiée selon la politique. Au stockage, elle est chiffrée au repos avec gestion des clés appropriée. À l’utilisation, le contrôle d’accès basé sur les rôles est appliqué et l’activité tracée. Au partage, les protocoles sécurisés et les DLP entrent en jeu pour empêcher la fuite. À l’archivage, la donnée est extraite des systèmes opérationnels et conservée selon la politique de rétention. À la destruction, on procède à une sanitisation conforme à la sensibilité (voir étape suivante).

La politique de rétention est un point souvent négligé. Elle découle du contexte légal : RGPD impose la minimisation et la destruction au-delà de la finalité, mais SOX exige sept ans de conservation des registres comptables, HIPAA six ans pour les données médicales aux États-Unis. Conserver trop longtemps est aussi risqué que pas assez : c’est exposer à une fuite massive sans bénéfice métier.

Étape 6 — Sanitiser correctement les supports

La sanitisation des supports est testée à plusieurs niveaux. La référence officielle a basculé en septembre 2025 sur NIST SP 800-88 Rev. 2, qui remplace Rev. 1 (retirée) et renvoie désormais à la norme IEEE 2883-2022 pour les techniques opérationnelles tout en gardant la trame Clear / Purge / Destroy. Trois niveaux de sanitisation existent : Clear, Purge, Destroy.

Deux pièges à éviter. Premier : sur SSD, la réécriture logique multipassage (style DoD 5220.22-M) n’est pas fiable à cause du wear leveling — il faut le block erase commande ATA Security Erase, ou mieux le cryptographic erase si le SSD est SED (Self-Encrypting Drive). Second : pour les supports optiques, seule la destruction physique est conforme — pas d’effacement logique possible.

Vous serez interrogé sur le choix du niveau à partir d’un contexte. Données classifiées Secret sortant du périmètre → Destroy (broyage industriel). HDD réutilisé en interne pour un projet différent → Clear acceptable. SSD revendu à un tiers → Purge minimum, idéalement crypto erase. Une question type vous demandera « quelle technique est la plus appropriée » et la bonne réponse est toujours la plus stricte adaptée au contexte.

Étape 5 bis — Marquage, étiquetage et prévention de fuite (DLP)

Une classification qui n’est pas matérialisée par un marquage et un étiquetage reste théorique. Le marquage est l’apposition visible de la classe (filigrane PDF, bannière d’en-tête courriel, label Microsoft Information Protection, métadonnée XMP sur image). L’étiquetage est la propriété machine-readable qui suit la donnée à travers les systèmes — métadonnée NTFS étendue, label cryptographique signé pour les fichiers chiffrés.

La mise en œuvre d’un Data Loss Prevention (DLP) industriel s’appuie sur ces étiquettes. Le DLP applique trois familles de contrôles : at rest (scan des baies de stockage et bases pour détecter des données mal placées), in motion (inspection du trafic réseau et des emails sortants), at endpoint (agent sur poste pour bloquer les copies vers clés USB, les uploads cloud non autorisés, les impressions). Trois moteurs de détection cohabitent : exact data match (empreinte exacte), indexed document match (similarité au document de référence), et policy match (expressions régulières ou classifieurs ML). L’examen ne demande pas de configurer un produit, mais de savoir associer chaque type de moteur à un cas d’usage.

Un piège fréquent oppose DLP et IRM (Information Rights Management). Le DLP bloque la fuite à la frontière. L’IRM, lui, embarque les droits dans la donnée elle-même — un PDF protégé reste protégé après exfiltration, car son ouverture nécessite une authentification au serveur de droits. Les deux sont complémentaires, jamais substituables.

Étape 6 bis — Vie privée et exigences RGPD côté actif

Le domaine 2 contient une portion de protection des données personnelles que l’examen aborde de façon transverse. Le RGPD distingue le responsable du traitement (data controller) et le sous-traitant (data processor) — confusion régulière au CISSP où la terminologie ISC2 parle de owner et custodian. Faites le mapping mental : controller ≈ owner sur les aspects légaux ; processor ≈ custodian sur les aspects techniques.

Les principes RGPD examinables sont la licéité du traitement (six bases légales possibles, dont consentement et intérêt légitime), la minimisation (collecter seulement ce qui est nécessaire), la limitation de finalité (ne pas réutiliser à autre chose), la durée limitée (rétention proportionnée), l’intégrité et confidentialité, et la responsabilité documentée. Le Data Protection Impact Assessment (DPIA) devient obligatoire pour les traitements à risque élevé — c’est l’équivalent d’un BIA orienté vie privée. Un candidat qui sait expliquer le DPIA en deux phrases gagne une question.

Cas pratique. Une RH veut conserver les CV des candidats non retenus « au cas où » pendant cinq ans. Au regard du RGPD, c’est non — la finalité (recruter sur le poste X) est éteinte, la conservation est disproportionnée. Une politique conforme : conservation pendant deux ans maximum après consentement explicite du candidat, suppression automatique sinon, possibilité de demande d’effacement à tout moment.

Étape 7 — Scoping et tailoring des contrôles

Le scoping consiste à déterminer quels contrôles d’un catalogue (NIST SP 800-53, ISO 27002) s’appliquent à un système donné — c’est filtrer le catalogue pour ne garder que ce qui est pertinent. Le tailoring consiste à adapter ces contrôles aux spécificités du système — paramètres, intensité, exceptions documentées.

Exemple concret. Un catalogue contient 1 200 contrôles. Pour un système de paie SaaS, vous appliquez d’abord un scoping qui en retient peut-être 350 (les autres ne s’appliquent pas à un SaaS hébergé). Ensuite, le tailoring précise sur ces 350 contrôles les paramètres exacts : longueur de mot de passe, durée de session, fréquence de rotation, exceptions documentées. Le résultat est un référentiel sur mesure mais traçable au catalogue d’origine — c’est ce qui fait la valeur de la démarche pour les auditeurs.

L’examen oppose souvent scoping et tailoring dans une question piège. Retenir la formule : scoping filtre, tailoring ajuste.

Étape 8 — Auto-évaluation

Tirez 20 questions ciblées sur le domaine 2 dans votre simulateur. Visez 80 % de réussite. Les zones les plus piégeuses sont : la frontière owner/custodian, le choix du niveau de sanitisation, l’ordre du cycle de vie, la distinction scoping/tailoring et les états de la donnée. Trois auto-évaluations consécutives au-dessus de 80 % en moins d’une semaine constituent le signal de réussite.

Erreurs fréquentes

Tutoriels frères

• Retour au guide principal : Décrocher la certification CISSP 2026
• Précédent : Domaine 1 — Security and Risk Management
• Suite : Domaine 3 — Security Architecture and Engineering

Ressources et références

• NIST SP 800-88 Rev. 2 — Guidelines for Media Sanitization (septembre 2025)
• ISO/IEC 27002:2022 — Contrôles de sécurité de l’information
• RFC 8446 — TLS 1.3
• NIST CMVP — Cryptographic Module Validation Program

Foire aux questions

Le data steward est-il toujours requis ?

Non. Dans les petites structures, le rôle de steward est souvent porté par l’owner lui-même. ISC2 le distingue conceptuellement, mais l’examen accepte qu’un même individu cumule plusieurs rôles si la séparation des tâches le permet.

Que faire d’un SSD défectueux qui ne répond plus aux commandes ATA ?

Destruction physique obligatoire. Pas de retour fournisseur sans destruction préalable si le SSD a contenu des données classifiées. Garder une trace écrite du processus de destruction (numéro de série, date, méthode, signataire).

Combien d’années conserver les logs de sécurité ?

Cela dépend du contexte légal applicable. Une règle de pouce raisonnable : 12 mois minimum opérationnel, 7 ans pour les logs liés à des transactions financières (alignement SOX), au minimum la durée de la procédure judiciaire si une investigation est en cours.