Sécurité des actifs

1.1 Qu'est-ce qu'un actif ?

Toute organisation s'appuie sur trois types de ressources. Les materials sont les intrants consommés par un processus de production (composants, plastique, emballages). Les supplies sont les consommables qui font tourner l'activité (papier, encre, fournitures). Les assets, eux, restent dans l'organisation et portent une valeur durable : ce sont eux que la sécurité protège.

Un actif peut être tangible (serveur, bâtiment, support de stockage) ou intangible (idée, donnée, procédure, propriété intellectuelle). Le point central du Domaine 2 est que l'information a une valeur dès l'instant où elle est conçue, avant même d'être écrite. Une base de données illustre bien cette superposition : les données sont un actif intangible, le SGBD qui les gère en est un autre, le serveur qui l'héberge est un actif tangible, et la connaissance du procédé dans la tête de l'employé est un actif tacite.

Identifier les actifs, et particulièrement les actifs informationnels, est donc le premier acte de tout programme de sécurité. On ne peut pas protéger ce qu'on n'a pas recensé.

1.2 Classification vs categorization

Les deux mots sont souvent confondus, et c'est un piège d'examen récurrent. La classification s'intéresse d'abord à l'accès : elle reconnaît l'impact d'une compromission (confidentialité, intégrité, disponibilité, mais aussi authenticité, non-répudiation, vie privée, sûreté) et dérive des mandats de conformité de l'organisation. C'est le monde des labels 'Secret', 'Top Secret', 'Confidential'.

La categorization, elle, s'intéresse d'abord à l'impact : c'est le processus qui regroupe des ensembles de données aux sensibilités comparables et aux besoins de protection similaires imposés par la loi, les contrats ou la conformité. Les références officielles sont NIST SP 800-60 et FIPS 199, qui catégorisent l'impact en low, moderate, high.

Une formule à retenir : une classification n'est pas un label. Le label fait partie de l'implémentation des contrôles qui protègent l'information classée. Pendant longtemps, la conversation s'est limitée à la triade CIA ; le textbook insiste pour élargir aux actions CRUD (Create, Read, Update, Delete) car créer, mettre à jour et supprimer une donnée touche directement à son intégrité, sa disponibilité et son authenticité.

1.3 Schémas et niveaux : militaire et privé

Le schéma militaire/gouvernemental compte cinq niveaux, du plus sensible au moins sensible : Top Secret, Secret, Confidential, Sensitive but Unclassified (SBU), Unclassified. La compromission de chaque niveau est associée à un degré de dommage (exceptionally grave, serious, damage). Ces communautés privilégient la confidentialité avant tout.

Le schéma privé/commercial compte généralement quatre niveaux : Sensitive, Confidential, Private, Public, du plus au moins sensible. Il n'existe aucune nomenclature obligatoire : chaque organisation nomme ses niveaux. Le Center for Internet Security, par exemple, propose un schéma simple à trois niveaux (sensitive, business confidential, public) qui mappe sur low/medium/high.

La categorization, à l'inverse, n'a pas toujours d'ordre hiérarchique : on parle de catégories comme PII, PHI, proprietary, human safety critical, time-critical, compliance data. Un même actif peut porter plusieurs labels à la fois, par exemple 'human safety critical, HIPAA, highly restricted'.

1.4 Niveaux de sensibilité, labels et bénéfices

Au-delà du nom des niveaux, chaque niveau résume en un ou deux mots le préjudice possible si la donnée est compromise. Une échelle privée typique compte quatre crans. Highly restricted : la compromission pourrait menacer l'existence même de l'organisation, voire entraîner des pertes humaines, des dommages et les litiges qui suivent. Moderately restricted : perte d'un avantage concurrentiel temporaire, de revenus, ou perturbation d'investissements planifiés. Low sensitivity (souvent 'internal use only') : la compromission ne cause que des perturbations ou retards mineurs. Unrestricted public : donnée déjà publiée, aucun préjudice supplémentaire possible.

Les labels de categorization, eux, ne s'ordonnent pas forcément du plus au moins grave : ils reflètent la source ou la nature de l'exigence. Exemples : human safety critical (risque de mort ou blessure), equipment/property safety critical (dommage matériel), PII critical (identifie une personne), private data (diffusion limitée par accord), proprietary data (logique métier interne), compliance data (exigences légales ou contractuelles spécifiques), time-critical data (un retard fait échouer une activité). Un même actif peut cumuler plusieurs labels, par exemple 'human safety critical, HIPAA, highly restricted'.

Bien classer apporte des bénéfices au-delà de la protection : sensibilisation des employés et clients à l'engagement de l'organisation, identification des informations critiques et de leur vulnérabilité à la modification, focalisation sur les contrôles d'intégrité, compréhension de la valeur de l'information, et respect des exigences légales.

1.5 Critères et enjeux de la classification

Pour fixer une classification, l'asset owner répond à une série de questions : qui doit accéder à la donnée et selon quels rôles ? Comment la donnée est-elle sécurisée par défaut (ouverte ou interdite) ? Combien de temps doit-elle être conservée (par exemple sept ans dans la finance) ? Comment sera-t-elle détruite ? Doit-elle être chiffrée ? Quel usage est approprié (interne, restreint, public) ?

La classification est conduite par l'asset owner parce qu'il comprend la valeur de l'actif. Il peut déléguer la tâche (la responsibility), mais jamais l'accountability : il reste comptable de la protection. L'analogie classique est celle du capitaine de navire, qui peut déléguer la conduite à un officier de quart mais reste responsable in fine du navire, de l'équipage et de la cargaison.

Les erreurs guettent : erreur humaine, méthodes incohérentes, décisions arbitraires ou capricieuses, labeling confus ou incomplet. Une classification incohérente donne l'impression que toutes les règles de sécurité sont arbitraires et détruit la confiance. Quand le data owner manque de connaissances, il a tendance à surclasser par prudence, ce qui gonfle inutilement les coûts ; un comité de classification réunissant les bonnes expertises corrige ce biais.

2.1 Marking, labeling et enforcement

Comme pour les actifs physiques, les actifs informationnels classés doivent être clairement marqués et étiquetés. Idéalement, les systèmes appliquent automatiquement ces labels - mais cela ne se produit en pratique que dans les systèmes à contrôle d'accès obligatoire (MAC). Les systèmes à contrôle d'accès discrétionnaire (DAC) n'appliquent pas les labels de façon uniforme, et le label peut se perdre quand l'information passe d'un système à un autre.

Un label de média doit indiquer la sensibilité de l'information, préciser si le média est chiffré, et peut contenir un point de contact et une période de rétention. Règle d'or déjà vue : un média trouvé sans label est étiqueté au plus haut niveau de sensibilité jusqu'à ce qu'une analyse prouve le contraire.

Le marquage traditionnel (étiquettes physiques, codes couleur) reste pertinent pour les supports amovibles et les documents papier. Côté numérique, les suites bureautiques commencent à utiliser le scan de mots-clés et l'analyse de sentiment pour repérer les labels incorrects, mais ces techniques ne sont pas encore généralisées.

2.2 Handling et storage des médias sensibles

Seul le personnel désigné doit accéder aux médias sensibles, et les procédures de manipulation doivent être diffusées et enseignées. Le professionnel de sécurité doit garder à l'esprit qu'un média non chiffré n'offre aucune traçabilité numérique : une vigilance renforcée s'impose.

Le stockage combine contrôles physiques et logiques. Les médias de sauvegarde devraient être chiffrés et conservés dans un contenant sécurisé (coffre). Une copie chiffrée hors site est recommandée pour la reprise d'activité, tandis que les sauvegardes sur site sont placées dans un coffre ignifuge. Dans tous les cas, le nombre de personnes ayant accès aux médias est strictement limité, et la separation of duties ainsi que la job rotation sont mises en place quand c'est rentable.

2.3 Déclassification et fin de vie

La déclassification abaisse le niveau de sensibilité d'un actif. Les exigences de marquage, de handling et de stockage doivent alors être ajustées en conséquence, et l'owner joue un rôle central dans cette décision. Le processus peut s'appuyer sur des techniques d'obscurcissement comme la de-identification (retrait des identifiants) ou la tokenization (remplacement d'une valeur sensible par un jeton).

Les médias qui ne servent plus ou sont défectueux doivent être détruits plutôt que simplement jetés. Un enregistrement de la destruction est tenu, en cohérence avec les logs de manipulation des médias. Quand la sensibilité d'un média est inconnue, on applique des contrôles d'object reuse (réutilisation d'objet) plutôt que de le recycler tel quel : il faut s'assurer qu'aucun résidu exploitable ne subsiste.

3.1 L'IT Asset Management Life Cycle

Deux modèles de cycle de vie cadrent la sécurité de l'information : l'IT Asset Management Life Cycle (matériel, logiciel, données) et le Data Security Life Cycle (la donnée elle-même). Le premier comporte cinq grandes étapes.

Planning : aligner l'actif sur les objectifs, l'identifier et le valoriser (coût total d'acquisition et d'exploitation, revenus attendus, avantage concurrentiel, dommage potentiel en cas de compromission). C'est aussi le moment d'assigner les besoins de sécurité via classification et categorization. Acquiring : acquérir ou développer l'actif en intégrant dès la conception les exigences de sécurité identifiées. Deployment : mettre en service, former les utilisateurs et le support aux aspects de sécurité. Managing : exploiter et surveiller en continu (les contrôles fonctionnent-ils encore ? le paysage de menaces a-t-il changé ?), planifier la reprise et archiver. Retiring : retirer l'actif en traitant la destruction et la rémanence, et en sensibilisant le personnel.

Deux chemins mènent à la gestion : un chemin délibéré, piloté par les exigences, et un chemin de découverte (systems enumeration, baselining) pour les actifs préexistants. Les deux convergent sur la même première étape : faire l'inventaire.

3.2 Inventaire, ITAM et CMDB

L'inventaire d'actifs recense tous les actifs physiques et virtuels : matériel, logiciel, données. L'IT Asset Management (ITAM) est l'ensemble des pratiques de gouvernance et de gestion de ces actifs ; la norme de référence est l'ISO 19770.

Le Configuration Management Database (CMDB) va plus loin qu'une simple liste : il enregistre la marque, le modèle, le numéro de série, le type, la version de chaque actif. Il permet non seulement de tracer ce que l'on possède, mais aussi de savoir comment c'est configuré, et fournit un point de restauration (par exemple pour reconstruire le poste d'un utilisateur à la bonne version, matériel et logiciel compris).

Un point subtil souligné par le textbook : les outils d'énumération savent dire quelles applications sont installées et où résident les fichiers, mais ils ne savent pas repérer un actif informationnel au sens métier - par exemple 'le budget annuel', dispersé dans plusieurs bases, tableurs et e-mails. C'est pourquoi l'inventaire des actifs informationnels se construit aussi par le haut, à partir des processus métier critiques. Et le registre lui-même est un actif à protéger.

3.3 Ownership : owner accountable, custodian exécute

Identifier un propriétaire responsable est un acte central de la gestion d'actifs. L'asset owner (ou information owner, ou information steward) impose les exigences de sécurité et de qualité pour l'actif : il décide qui y accède et avec quel niveau de permission, combien de temps il est conservé, s'il peut être partagé. Il ne construit ni ne maintient lui-même les contrôles - c'est une fonction métier - mais il en est comptable (accountable).

Les responsabilités typiques de l'owner : déterminer l'impact de l'information sur la mission, en estimer le coût de remplacement, décider qui a besoin d'y accéder et selon quels critères de diffusion, et savoir quand l'information est inexacte ou doit être détruite.

Le data custodian, lui, exécute au quotidien : il protège, maintient et rend les données accessibles aux bons opérateurs. Ses tâches : respecter la politique de données, garantir l'accès en maintenant le niveau de sécurité, assurer la maintenance fondamentale (stockage, archivage), documenter, et valider la qualité par des audits périodiques. La règle d'examen : l'owner DÉCIDE, le custodian EXÉCUTE.

4.1 Le Data Security Life Cycle

La donnée traverse six grandes étapes. Create : génération ou acquisition de contenu - c'est le moment privilégié pour classer, car les contrôles dépendent de cette classification. Store : engagement sur un support, le plus souvent simultané à la création ; on applique chiffrement, contrôle d'accès, journalisation, redondance selon la classification. Use : la donnée est lue, traitée, modifiée ; c'est souvent l'état le plus vulnérable car elle est en clair ; on s'appuie sur DLP, DRM et contrôle d'accès. Share : l'information est partagée avec d'autres ; une fois partagée, elle échappe au contrôle de l'organisation, donc on ne partage que selon la classification et avec des destinataires autorisés ; DLP détecte les partages non autorisés, DRM maintient le contrôle. Archive : la donnée quitte l'usage actif pour un stockage long ; défis de conservation (le support sera-t-il encore lisible dans dix ans ?), protection maintenue selon la classification, exigences légales. Destroy : destruction défendable, selon des processus écrits, par du personnel habilité.

Ces étapes ne forment pas une séquence rigide : la création vient en premier et la destruction en dernier, mais stockage, usage, partage et archivage s'enchaînent dans n'importe quel ordre, autant de fois que nécessaire. Le modèle sert de cadre pour mapper les contrôles à chaque phase.

4.2 Les rôles de la donnée (GDPR et NIST)

La protection des données exige une distinction claire des rôles, de leurs accountabilities et de leurs responsibilities. NIST SP 800-18 et le GDPR en donnent des définitions comparables.

Data subject : la personne physique décrite ou identifiée par la donnée. Data controller : détermine les finalités et les moyens du traitement ; il est accountable, garant que toutes les obligations (GDPR ou autres) sont remplies ; il négocie avec les processors des accords de traitement (data processing agreements). Data processor : exécute les traitements pour le compte du controller (acquérir, utiliser, modifier, détruire) ; il peut être responsable de protéger la donnée, mais l'accountability reste au controller. Data owner : décide qui accède à quels niveaux, garantit qualité, intégrité et protection ; il prend ou délègue le rôle de controller. Data steward : responsable du contenu, du contexte et des règles métier de la donnée. Data custodian : protège la donnée tant qu'elle est sous sa garde (transport, stockage, traitement sûrs). Data protection officer (DPO) : conseille sur la conformité et fait l'interface avec les autorités de contrôle ; il devient obligatoire quand l'organisation traite des données sensibles (santé, génétique, origine, religion).

La hiérarchie d'accountability est la clé : le subject a une attente raisonnable de vie privée et d'intégrité ; le controller répond de tout ; le processor n'est jamais accountable à la place du controller.

4.3 Collection, localisation et maintenance

Data collection est la première phase : création et acquisition de contenu, mise à jour de l'existant. C'est là qu'on nomme les data owners et qu'on assigne les classifications, pour appliquer les bons contrôles au plus tôt. Les principes de secure defaults et de privacy by design s'appliquent dès cette phase.

Data location et localization deviennent critiques avec le cloud. Où stocker la donnée dépend de la législation locale, surtout pour les données personnelles traitées différemment selon les pays. Avant de collecter, on cartographie les exigences locales et globales : lieux de stockage autorisés, mécanismes de protection attendus, durées de rétention. Certaines lois de data localization peuvent même conditionner la décision d'opérer dans une région : l'expansion vers un nouveau marché peut être freinée par des exigences locales coûteuses.

Data maintenance vise à préserver confidentialité, intégrité et disponibilité tout au long de la vie de la donnée, via des contrôles adaptés à chaque état. La donnée at rest, en apparence la plus facile à protéger, demande malgré tout d'identifier tous les dépôts, de chiffrer, de gérer les accès et de sauvegarder. C'est aussi à cette phase qu'on arbitre l'éternel compromis functionality versus security.

5.1 Data retention : ni trop, ni trop peu

L'information ne doit être conservée que le temps requis. Des standards sectoriels, lois et règlements fixent des durées (par exemple sept ans dans la finance). En l'absence d'exigence externe, l'organisation définit sa propre politique de rétention, applicable aux copies papier comme numériques.

La rétention joue sur deux bornes. Les minimums sont imposés par la loi ou le contrat : conserver moins, c'est la non-conformité. Les maximums relèvent de la minimisation : conserver plus longtemps que nécessaire augmente le coût de stockage, le risque d'exposition et le 'bruit' lors des recherches, et peut violer des exigences externes. L'erreur classique consiste à prendre la durée de rétention la plus longue et à l'appliquer aveuglément à tout : c'est du gaspillage et du risque.

Une politique de rétention saine suit huit étapes : évaluer les exigences légales, contentieuses et métier ; classer les types d'enregistrement ; déterminer durées et pratiques de destruction ; rédiger et justifier la politique ; former le personnel ; auditer les pratiques de rétention et de destruction ; revoir périodiquement ; documenter politique, mise en oeuvre, formations et audits. Pour exécuter tout cela, un inventaire exact est indispensable (emplacement, durée, exigences de destruction de chaque actif).

5.2 Data remanence : ce qui reste

La data remanence est la représentation résiduelle d'une donnée sur un support après un effacement supposé. Une suppression insuffisante peut compromettre l'information. Presque tout équipement conserve des données après l'étape de traitement : les registres du CPU ou du GPU, la mémoire vive, les fichiers temporaires, la circuiterie d'affichage gardent des valeurs jusqu'à réécriture, de quelques millisecondes à plusieurs minutes après la coupure d'alimentation.

Le point crucial : effacer un fichier ne supprime pas réellement les données. Le système se contente de marquer l'entrée du répertoire comme supprimée et de remettre l'espace dans la liste des ressources libres ; les données restent physiquement présentes jusqu'à réécriture. C'est pourquoi un disque 'vidé' par une simple suppression reste récupérable avec des outils adaptés. Les fichiers temporaires sont une source de rémanence souvent négligée.

5.3 Méthodes de destruction et choix du support

La référence officielle est le NIST SP 800-88 (Guidelines for Media Sanitization). Les méthodes s'échelonnent par niveau d'assurance. Clearing : réécrire des motifs (souvent aléatoires) sur tout le support. Le 'zeroizing' (écrire des zéros) en est une variante, mais avec le risque qu'un bloc manqué reste récupérable. Le clearing protège contre une récupération par fonctions système normales et suffit dans beaucoup d'environnements opérationnels. Purging : éliminer fortement la probabilité de récupération, même en laboratoire. Le degaussing (champ magnétique puissant) en relève - mais il s'applique uniquement aux supports magnétiques (HDD, bandes) et détruit aussi la servo track, rendant le disque inutilisable. Destruction physique : broyage, incinération, pulvérisation, attaque à l'acide - le remède ultime à la rémanence.

Le piège majeur : le degaussing ne fonctionne PAS sur les SSD (mémoire flash, non magnétique). Pour un SSD, on privilégie le crypto-shredding (détruire les clés de chiffrement pour rendre les données inexploitables) ou la destruction physique. Enfin, la defensible destruction exige que tout cela soit conduit selon des processus écrits, par du personnel habilité, et tracé - sinon la destruction n'est pas juridiquement défendable.

6.1 Les trois états : at rest, in transit, in use

Data at rest : la donnée stockée sur un support, ni transmise ni traitée. Le risque est l'accès physique ou logique non autorisé au support. La protection de référence est le chiffrement (algorithmes limitant l'accès aux détenteurs de clés), complété par des contrôles d'accès, de la redondance et des sauvegardes. Supports amovibles et terminaux mobiles (laptops, tablettes, smartphones, wearables) doivent être chiffrés.

Data in transit (ou in motion) : la donnée qui circule, typiquement sur un réseau, sans être traitée. Le risque - identique à celui de la donnée at rest - est l'interception, la modification, l'indisponibilité. La protection est le chiffrement, au niveau donnée, réseau, ou les deux. Les interfaces web sensibles passent par TLS ; SSL, sous toutes ses formes, est considéré cassable et déprécié. L'e-mail n'est pas sûr par défaut (transmis en clair) : il faut PGP ou S/MIME. Hors web, on chiffre au niveau applicatif, ou à défaut au niveau réseau via IPSec ou des tunnels SSH.

Data in use : la donnée traitée par un logiciel, un matériel ou un utilisateur. C'est l'état le plus difficile à protéger car la donnée doit être en clair pour que sa structure et ses valeurs soient lisibles. Les contrôles principaux sont le contrôle d'accès, l'audit et la non-répudiation. Un exemple de risque trivial : l'over-the-shoulder attack, où un tiers lit l'écran d'un utilisateur.

6.2 Link vs end-to-end encryption

La donnée se chiffre sur un réseau selon deux approches. Le link encryption est réalisé par les opérateurs : il chiffre toutes les données le long d'un chemin de communication (liaison satellite, circuit téléphonique, ligne T-1), y compris les informations de routage. Conséquence : chaque noeud doit déchiffrer pour continuer à router, puis rechiffrer. Un attaquant compromettant un noeud peut donc voir le message en clair à ce point. En contrepartie, comme le routage est chiffré, le link encryption offre une meilleure confidentialité du trafic (traffic confidentiality) : il masque les informations d'adressage et prévient les inférences sur l'existence d'échanges entre deux parties.

Le end-to-end encryption est réalisé par l'utilisateur final : la donnée est chiffrée à l'origine et ne se déchiffre qu'à destination. Elle reste chiffrée à la traversée du réseau, mais les informations de routage restent visibles. Un VPN en est un exemple. Le compromis est inverse de celui du link encryption : meilleure protection du contenu de bout en bout, mais le routage reste observable.

6.3 Protéger la donnée in use : les enclaves

Protéger la donnée pendant son traitement est le défi le plus dur, puisqu'elle doit être déchiffrée pour être traitée. La piste industrielle est la secure enclave : une zone isolée du reste de l'architecture où le traitement a lieu. La donnée y reste traitée en clair, mais l'enclave est conçue pour être imperméable aux vulnérabilités et aux malwares présents ailleurs dans le système. Le mot 'enclave' désigne d'ailleurs un territoire isolé d'un autre.

Au-delà des enclaves, les contrôles classiques restent pertinents : contrôle d'accès strict, journalisation et audit pour détecter les usages anormaux, non-répudiation. La détection d'anomalies d'usage, combinée à des techniques forensiques, permet de débusquer fraude et abus. Le risque demeure : altération accidentelle ou malveillante, exposition non autorisée (l'over-the-shoulder attack en est l'exemple le plus simple).

7.1 Types de contrôles et défense en profondeur

Pour protéger les actifs, on combine trois grands types de contrôles. Les contrôles administratifs sont les politiques, procédures, standards et formations - le cadre humain et organisationnel. Les contrôles techniques (ou logiques) sont mis en oeuvre par la technologie : chiffrement, contrôle d'accès, DLP, journalisation. Les contrôles physiques protègent l'environnement : serrures, badges, caméras, contrôles environnementaux.

Les contrôles se rangent aussi par mode d'action (preventive, detective, corrective, deterrent, recovery, compensating), mais cette catégorisation n'est pas absolue : un même contrôle peut relever de plusieurs catégories selon son implémentation.

Le point clé pour la sécurité des actifs : s'appuyer sur un seul type ou une seule catégorie de contrôle, c'est créer un single point of failure. En combinant plusieurs types et catégories, on force l'attaquant à préparer plusieurs voies d'attaque au lieu d'une seule - c'est le principe de defense in depth, qui dissuade, ralentit et augmente les chances de détecter une attaque.

7.2 Baselines : le minimum de référence

Une baseline de sécurité est un niveau minimum de protection servant de point de référence. Elle garantit que toute évolution de la technologie ou de l'architecture reste au-dessus d'un seuil compris et accepté. Une fois les contrôles en place, tout se mesure par rapport à la baseline.

Les baselines se déclinent par niveau de classification. Si l'on classe en high, medium, low, on définit une baseline pour chacun : par exemple, niveau high = mots de passe forts + NDA + chiffrement symétrique 128 bits pour création, stockage et transmission + watermark + monitoring temps réel ; niveau low = simple processus d'accès approuvé par l'owner, pas de chiffrement, pas de labeling, pas de monitoring. Les baselines peuvent aussi être techniques (la configuration minimale d'une machine Windows avant raccordement au réseau) ou non techniques (port du badge, escorte des visiteurs). En résumé : une baseline est un point de référence cohérent, qui définit le minimum requis et se décline en configurations par architecture.

7.3 Scoping et tailoring

On adopte rarement un framework tel quel : on le scope et on le tailore pour son contexte. Ces deux opérations sont distinctes et fréquemment confondues à l'examen.

Scoping : c'est le processus consistant à déterminer quels contrôles s'appliquent et à quels actifs, en retirant de la baseline générale les recommandations qui ne s'appliquent pas. Plusieurs considérations influencent l'application des contrôles ; le plan de sécurité du système doit identifier clairement les contrôles ayant fait l'objet d'un scoping et décrire les décisions prises, validées par l'autorité d'homologation (authorizing official).

Tailoring : c'est le processus consistant à modifier l'ensemble des contrôles pour qu'il colle aux caractéristiques et exigences spécifiques de l'organisation. Cela donne plus de flexibilité et évite des approches coûteuses ou inutilement complexes. Formellement, le tailoring inclut l'application du scoping, la spécification de contrôles compensatoires si nécessaire, et la définition de paramètres organisationnels. À retenir : scoping RETIRE ce qui ne s'applique pas, tailoring AJUSTE ce qui reste.

7.4 DLP, DRM et CASB

Le Data Loss Prevention (DLP) regroupe les contrôles assurant que certaines données restent conformes aux politiques. Il repose sur trois composants : discovery & classification (cartographier et classer automatiquement les données), monitoring (surveiller l'usage à travers les emplacements et plateformes, fonction clé), enforcement (interroger la donnée et comparer son emplacement, usage ou destination aux politiques, puis alerter, journaliser, bloquer, rerouter ou chiffrer). Le DLP dépend fortement d'une identification fiable de la donnée : sans discovery, classification et labeling préalables, il est beaucoup plus difficile à exploiter. C'est l'une des rares technologies efficaces contre l'insider threat.

Trois topologies de déploiement, alignées sur les états : Data in Motion (network/gateway DLP, près de la passerelle, surveille HTTP/HTTPS/SMTP/FTP), Data at Rest (storage DLP, là où la donnée est stockée), Data in Use (endpoint/client DLP, sur les postes). Le DRM (Digital Rights Management) chiffre la donnée dans le fichier lui-même (format-preserving) et contrôle son usage, sa modification et sa distribution tout au long de la vie de la propriété intellectuelle ; si le DLP ne s'intègre pas au DRM, il ne peut pas lire les fichiers protégés. Enfin, le CASB (Cloud Access Security Broker) est un point de contrôle entre le consommateur cloud (CSC) et le fournisseur (CSP) ; il assure quatre fonctions - visibility, data security, threat protection, compliance - et se déploie en forward proxy, reverse proxy ou via API.

7.5 Sélection des standards de conformité

Les organisations adoptent des standards (parfois appelés frameworks) pour structurer leur posture de sécurité, comprendre les contrôles de baseline et évaluer leur maturité. Selon l'activité, certains sont obligatoires (loi ou règlement) : PCI DSS pour les données de carte, HIPAA pour la santé, GDPR pour les données personnelles européennes. Côté frameworks de pilotage : NIST SP 800-37 (Risk Management Framework), NIST Cybersecurity Framework, NIST SP 800-53 (catalogue de contrôles), ISO 27001/27002 (SMSI), sans oublier des entités comme l'ENISA ou l'ITU.

Le professionnel doit connaître ce paysage et savoir que les exigences contractuelles ou légales peuvent dicter directement un contrôle (PCI DSS impose le chiffrement des données de carte, par exemple). On adopte rarement un framework intégralement : on en implémente des parties via scoping et tailoring, pour cibler les risques réellement pertinents sans gaspiller. La logique d'ensemble du Domaine 2 boucle ici : classer pour connaître la valeur, choisir une baseline selon cette valeur, scoper et tailorer pour l'adapter, et faire respecter le tout par les bons contrôles techniques et de conformité.