Sécurité et gestion des risques

1.1 La triade CIA, authenticity et nonrepudiation

La triade CIA est le modèle mental fondateur de la sécurité de l'information. Confidentiality garantit que l'information n'est divulguée qu'aux parties autorisées disposant d'un need to know : une fuite de données clients viole la confidentialité. Integrity garantit que l'information reste complète et exacte, libre de toute modification non autorisée : si un attaquant altère un montant dans une base bancaire, c'est l'intégrité qui est touchée, même si la donnée reste lisible par tous. Availability garantit que l'information est accessible quand et où elle est nécessaire : un ransomware qui chiffre les fichiers attaque la disponibilité.

ISC2 a élargi ce modèle à cinq piliers en ajoutant authenticity et nonrepudiation. Authenticity assure que l'information est authentique : elle provient d'une source de confiance, vérifiable, et son émetteur avait l'autorité d'agir (les attaques de whaling exploitent justement un défaut d'authenticity). Nonrepudiation empêche qu'un acteur nie après coup une action qu'il a réalisée : une signature numérique sur un ordre médical ou un contrat de trading garantit que l'émetteur ne pourra pas dire « ce n'est pas moi ».

Piège classique : la confidentialité concerne la divulgation (qui peut lire), l'intégrité concerne la modification (qui peut écrire). Un même incident peut toucher plusieurs attributs, mais l'examen attend que vous identifiiez l'attribut principal en jeu.

1.2 Le cycle IAAAA et la distinction avec AAA

Tout accès à une ressource suit un enchaînement logique que l'on résume par l'acronyme IAAAA : Identification, Authentication, Authorization, Accountability, Auditing. Identification est l'affirmation d'une identité : l'utilisateur déclare « je suis alice » (un username, un identifiant de carte). Authentication prouve cette affirmation : alice fournit un mot de passe, un jeton ou une biométrie. Tant que l'authentification n'a pas réussi, aucune identité n'est validée.

Authorization détermine ensuite ce que l'identité authentifiée a le droit de faire : quels objets elle peut lire, écrire ou exécuter, selon le principe du least privilege. Accountability lie chaque action à l'identité responsable : c'est la capacité d'imputer une action à un individu, condition indispensable de la nonrepudiation. Auditing examine les journaux a posteriori pour vérifier, détecter les anomalies et fournir des preuves.

Le modèle AAA (triple-A) du contrôle d'accès regroupe Authentication, Authorization et Accounting (souvent assimilé à accountability). IAAAA est donc une vue plus complète qui ajoute explicitement l'Identification en amont et l'Auditing en aval. Piège d'examen : ne confondez pas Identification (déclarer qui l'on est) et Authentication (le prouver) ; et n'oubliez pas que l'accountability dépend d'une identification unique et fiable, sinon impossible d'imputer une action.

1.3 La risk triad : asset, vulnerability, threat et le risque

Le risque n'existe pas dans le vide : il naît de la rencontre entre trois éléments que l'on appelle la risk triad. Un asset est une ressource de valeur à protéger (données, système, personnel, réputation) ; sa valeur ou sa criticité dictent les safeguards que l'on déploie. Une vulnerability est une faiblesse exploitable (un système non patché, un datacenter sans alimentation de secours, un bâtiment non antisismique). Une threat est un événement potentiellement nuisible (séisme, panne, malware, employé malveillant).

Deux acteurs intermédiaires précisent le tableau. Le threat agent (ou threat actor) est l'entité qui déclenche la menace : un cybercriminel, une catastrophe naturelle, un initié. L'exploit est le moyen concret par lequel une vulnerability est utilisée pour réaliser la menace. Le risk est la probabilité qu'une threat exploite une vulnerability sur un asset, multipliée par l'impact résultant.

La formule conceptuelle Risk = Threat × Vulnerability × Asset capture l'essentiel : si l'un des facteurs vaut zéro, le risque est nul. Un système Linux n'a aucune vulnérabilité à Conficker, donc aucun risque face à ce ver, même si la menace existe ailleurs. Piège d'examen : une menace sans vulnérabilité correspondante ne crée pas de risque, et un actif sans valeur ne mérite pas de safeguard. Distinguez bien threat (l'événement) de threat agent (qui le porte) et de vulnerability (la faiblesse).

1.4 Defense in depth et les trois types de contrôles

La defense in depth (défense en profondeur) repose sur un principe simple : aucun contrôle unique n'est infaillible, il faut donc empiler plusieurs couches de protection indépendantes. Si un attaquant franchit une couche, la suivante l'arrête ou au moins le ralentit et le rend détectable. On parle aussi de layered security. Un exemple : un pare-feu (technical), complété par une politique d'accès (administrative) et un badge à l'entrée du datacenter (physical).

CISSP classe les contrôles selon trois grandes catégories par leur nature. Les contrôles administrative (ou managerial) sont des politiques, procédures, formations, contrats de travail, séparation des tâches : ils orientent le comportement humain. Les contrôles technical (ou logical) sont implémentés dans les systèmes : chiffrement, pare-feu, ACL, authentification, journalisation. Les contrôles physical protègent l'environnement matériel : clôtures, éclairage, serrures, gardes, systèmes anti-incendie.

Ces catégories par nature se combinent avec les fonctions des contrôles (preventive, detective, corrective, etc.), traitées dans un module ultérieur. Piège d'examen : une caméra de surveillance est un contrôle physical par nature mais detective par fonction ; un chiffrement est technical et preventive. Le questionnaire teste souvent votre capacité à classer un même contrôle sur deux axes différents. La defense in depth exige justement de mélanger les trois natures pour ne pas dépendre d'un seul rempart.

1.5 Due care vs due diligence et la négligence

Due care et due diligence sont deux concepts de gouvernance et de responsabilité juridique souvent confondus. La formule mnémonique la plus utile : due diligence c'est savoir ce qui est juste (knowing what is right), due care c'est faire ce qui est juste (doing the right thing). Autrement dit, la due diligence consiste à se renseigner, évaluer, planifier et comprendre les risques ; la due care consiste à agir de manière prudente et continue pour les traiter.

Concrètement, mener une analyse de risques, auditer un fournisseur, étudier les obligations réglementaires relève de la due diligence. Appliquer des correctifs, appliquer la politique de sécurité, former les employés, surveiller en continu relève de la due care. La due diligence précède et alimente la due care : on ne peut pas agir correctement sur des risques qu'on n'a pas d'abord identifiés.

Le lien avec la négligence est central pour l'examen. Une organisation qui ne fait preuve ni de due care ni de due diligence s'expose à des poursuites pour negligence : elle n'a pas agi comme un prudent person l'aurait fait dans les mêmes circonstances. Le prudent man rule (ou prudent person rule) est le standard de comparaison. Piège d'examen : si la question parle d'enquêter, d'évaluer ou de comprendre, pensez due diligence ; si elle parle d'agir, de maintenir ou d'appliquer dans la durée, pensez due care. Les deux ensemble protègent les dirigeants de l'accusation de negligence.

1.6 Privacy et safety : les attributs au-delà des cinq piliers

Les objectifs du manuel ISC2 (1.2) listent sept attributs à expliquer : confidentiality, integrity, availability, authenticity, nonrepudiation, mais aussi privacy et safety. Ces deux derniers sont souvent oubliés alors qu'ils sont testables. La privacy n'est pas un synonyme de la confidentiality : la confidentiality protège l'information contre une divulgation non autorisée, tandis que la privacy protège le droit d'un individu (le data subject) à contrôler la collecte et l'usage des données qui le concernent. On peut garder une donnée confidentielle tout en violant la privacy, par exemple en la traitant pour une finalité non consentie. La privacy s'appuie sur des cadres comme les huit principes OECD (collection limitation, data quality, purpose specification, use limitation, security safeguards, openness, individual participation, accountability) et le GDPR, qui encadre toute donnée concernant une personne dans l'UE/EEE.

La safety concerne la prévention ou le contrôle d'un dommage non voulu ou non autorisé envers les personnes ou les biens : elle relève du monde physique. La safety of information se rattache au fait que l'usage de l'information ne mette pas en danger des personnes. Exemple du manuel : la fuite d'une liste d'employés avec leurs adresses pendant qu'ils sont tous au séminaire annuel compromet la safety de ces employés et de leurs familles, au-delà d'une simple atteinte à la confidentiality.

Piège d'examen : ne confondez pas privacy (droit de l'individu sur ses données) et confidentiality (non-divulgation), ni safety (protection des personnes/biens, monde physique) et security (protection de l'actif). PII (personally identifiable information) est la donnée dont la protection fonde le droit à la privacy du data subject.

1.7 La valeur de l'information et le statut des modèles de sécurité

Le manuel ISC2 ouvre la section 1.2 par une idée structurante souvent négligée : l'information a de la valeur parce qu'elle sert à prendre des décisions, qui mènent à des actions, qui produisent des résultats. La sécurité de l'information est la science et la pratique consistant à s'assurer que l'information est correcte, complète et disponible pour soutenir ces décisions, qu'elle est produite de façon fiable et reproductible, et que ce qui doit rester secret le reste. Une information non sécurisée peut conduire à des actions causant des dommages matériels, des blessures, voire la mort. Cette mise en perspective justifie pourquoi on protège un actif informationnel : ce n'est pas la donnée en soi qui compte, mais l'usage décisionnel qu'elle permet.

Un second point de nuance est essentiel pour l'examen : la triade CIA et les cinq piliers ne sont pas la source des exigences de sécurité ; ce sont des aide-mémoire (memory-joggers) destinés à maintenir ces préoccupations au premier plan de la pensée des concepteurs et analystes. On ne dérive donc pas directement une liste de contrôles de la triade ; on l'utilise comme grille de questionnement.

Piège d'examen : si une question suggère que le modèle CIA est en soi une exigence réglementaire ou un standard de contrôles, c'est faux. Le modèle est un cadre conceptuel ; les requirements viennent des risques, des lois, des obligations métier. La popularité de la triade tient à sa simplicité, et les modèles étendus (cinq piliers, Parkerian) répondent à des menaces mieux financées et plus motivées.

2.1 Le (ISC)² Code of Ethics : préambule et 4 canons

Le (ISC)² Code of Ethics s'ouvre par un préambule qui pose le principe directeur : la sûreté et le bien-être de la société, le bien commun (common good), le devoir envers nos mandants (principals) et le devoir les uns envers les autres exigent que nous adhérions - et soyons vus comme adhérant - aux plus hauts standards éthiques. Le préambule conclut que l'adhésion stricte au Code est une condition de certification.

Suivent les 4 canons, dans cet ordre exact : (1) Protéger la société, le bien commun, la confiance et le crédit publics nécessaires, et l'infrastructure ; (2) Agir avec honneur, honnêteté, justice, responsabilité et en respectant la loi (act honorably, honestly, justly, responsibly, and legally) ; (3) Fournir un service diligent et compétent aux mandants (principals) ; (4) Faire avancer et protéger la profession.

L'ordre est PRESCRIPTIF : il sert d'arbitrage. En cas de conflit entre deux canons, le canon de rang supérieur prime sur le canon de rang inférieur. Ainsi, protéger la société (canon 1) l'emporte sur le devoir envers son employeur (canon 3) ; et agir légalement (canon 2) prime sur l'intérêt commercial de la profession (canon 4). C'est ce raisonnement hiérarchique - et non une simple récitation - que l'examen teste.

Piège classique : confondre l'ordre, par exemple placer « advance and protect the profession » avant « protect society ». Le bien-être de la société figure TOUJOURS en tête ; la profession ferme la marche.

2.2 RFC 1087 (IAB) et les autres codes professionnels

La RFC 1087 « Ethics and the Internet » est publiée par l'Internet Architecture Board (IAB). Elle ne décrit pas des canons positifs comme ISC2, mais déclare explicitement NON-ÉTHIQUES six catégories d'activités : (1) chercher un accès non autorisé à des ressources Internet ; (2) détruire l'intégrité de l'information ; (3) perturber l'usage normal d'Internet ; (4) gaspiller des ressources (humaines, capacité, etc.) par de telles actions ; (5) compromettre la vie privée (privacy) des utilisateurs ; (6) faire preuve de négligence dans la conduite d'expériences sur Internet.

La logique de la RFC 1087 recoupe la triade CIA : l'accès non autorisé et la compromission de la privacy touchent la confidentialité, la destruction d'intégrité touche l'integrity, la perturbation et le gaspillage touchent la disponibilité (availability). C'est un angle d'examen utile pour mémoriser la liste.

D'autres organisations maintiennent leurs propres codes : l'IEEE et l'ACM (informatique et ingénierie logicielle), l'ISACA (audit et gouvernance SI). Ils partagent l'esprit - intégrité, compétence, primauté de l'intérêt public - mais diffèrent par la portée et l'autorité. Point clé : seul le (ISC)² Code of Ethics conditionne la certification CISSP. La RFC 1087 et les codes IEEE/ACM/ISACA sont des références complémentaires, pas la base disciplinaire d'ISC2.

Piège classique : attribuer la liste des activités non-éthiques au (ISC)² Code of Ethics. Cette liste vient de la RFC 1087 / de l'IAB, à ne pas confondre avec les 4 canons.

2.3 Promouvoir l'éthique en pratique : signalement et conséquences

Promouvoir l'éthique (le verbe « promote » du Key Area A) dépasse l'adhésion personnelle : le professionnel doit aussi signaler les violations et désamorcer les conflits d'intérêts. Un conflit d'intérêts (conflict of interest) apparaît quand un intérêt personnel - lien familial, gain financier, animosité - peut compromettre l'objectivité. La réponse attendue est la divulgation (disclosure) et le retrait (recusal), pas la dissimulation.

Le signalement suit un processus formel. Chez ISC2, une plainte (complaint) déclenche une procédure : établissement des faits (finding of facts), possibilité pour le membre accusé de présenter une réfutation (rebuttal), puis examen par le comité d'éthique (ISC2 Ethics Committee). Le comité laisse le membre relire les conclusions et recommandations avant de les soumettre au conseil d'administration (board) d'ISC2, qui statue.

La conséquence ultime d'un manquement est la révocation de la certification : c'est le board d'ISC2, sur recommandation du comité d'éthique, qui décide de retirer ou non l'adhésion. Au-delà, un comportement non éthique détruit la confiance de l'organisation, qui ne pourra plus accepter les conseils de sécurité du professionnel.

Piège classique : croire que c'est le manager ou l'employeur qui « révoque » le CISSP. La révocation de la certification relève d'ISC2 (comité d'éthique + board), pas de l'employeur. L'employeur peut licencier ; seul ISC2 retire la certification.

2.4 L'organizational code of ethics et l'illustration Enron / SOX

Au-delà du (ISC)² Code of Ethics, il faut distinguer l'organizational code of ethics : un document de politique (policy document) approuvé et soutenu par le senior management de l'organisation. Là où le (ISC)² Code engage l'individu certifié, le code organisationnel engage tout le personnel et fixe les modes de comportement acceptables. Il est souvent fusionné avec les personnel policies globales et peut énoncer la mission et les core values de l'organisation.

Un organizational code définit concrètement ce qui est interdit : comportements discriminatoires et improductifs (harcèlement racial, religieux ou sexuel), pratiques commerciales déloyales (unfair trade practices) telles que le népotisme (nepotism), la corruption (bribery) et l'attribution de contrats en échange de faveurs. Certains codes sont aussi conçus pour assurer la conformité à la législation à laquelle l'organisation est soumise (compliance-driven).

Point d'application : l'éthique, comme tout le reste, doit être inscrite dans les policies and procedures, et l'ethics committee doit la réviser et la surveiller (review and monitor) en continu. Le professionnel de sécurité « set the example » : sa conduite devient la pratique de référence (tone at the top).

L'histoire éclaire l'enjeu. À la fin des années 1990 / début 2000, une série de scandales comptables - WorldCom, Adelphia, Enron - a conduit à des faillites. Le cabinet d'audit d'Enron, Arthur Andersen, fournissait à la fois de l'audit ET du business consulting : un conflit d'intérêts inhérent (les rôles sont adversariaux). Andersen a ensuite ordonné la destruction de documents pendant une enquête réglementaire. En réponse, le Congrès américain a créé le Sarbanes-Oxley Act (SOX) - exigeant davantage de transparence dans le reporting financier des sociétés cotées - et a amendé les Federal Rules of Evidence : un data owner ne peut plus détruire d'information une fois reçue la notification d'une action légale ou d'une enquête.

Piège classique : confondre l'organizational code of ethics (interne, approuvé par le management, sanctionné par l'employeur) avec le (ISC)² Code (qui conditionne la certification, sanctionné par ISC2). Et : Andersen a montré que disposer d'une politique de destruction des données ne rend pas la destruction éthique en pleine enquête - c'est précisément ce que SOX a corrigé.

3.1 Aligner la sécurité sur le métier

La security governance est le méta-processus qui relie les efficiences de l'organisation à ses goals et objectives : elle régit la manière dont les policies sont écrites, dont les gens sont formés et dont les actions sont menées. Règle fondatrice : le métier peut exister sans le département sécurité, mais le département sécurité n'a aucune raison d'exister sans le métier. La sécurité doit donc rehausser et soutenir les objectifs business, jamais les entraver inutilement.

Trois niveaux à ne pas confondre. Governance = le QUOI : le board / les directors / le top management définissent la direction, le risk appetite et les politiques ; ils sont accountable. Management = le COMMENT : les managers traduisent en programmes, allouent les ressources et restent responsible de l'exécution. Operations = le FAIRE : les équipes appliquent les contrôles au quotidien. Le risk appetite (niveau de risque que l'organisation accepte) est fixé par le top management, pas par l'opérationnel.

Exemple : un board fixe « zéro tolérance pour la fuite de données patients » (governance) ; le RSSI conçoit un programme de chiffrement et de DLP (management) ; l'équipe SOC surveille les alertes (operations). Piège d'examen : une décision de risk acceptance prise par un administrateur technique est invalide - l'acceptation du risque résiduel relève du senior management, pas de l'opérateur.

3.2 Rôles et responsabilités

Le Senior Manager (CEO, board) est ultimement accountable de la sécurité : il signe les policies et porte le risque devant les actionnaires et la loi. L'Information Security Officer / RSSI est fonctionnellement responsible : il conçoit, pilote et maintient le programme de sécurité. Distinction clé d'examen : accountable (le seul, en haut, qui répond du résultat) vs responsible (celui qui exécute, délégable).

Les rôles data. Le Data Owner (souvent un cadre métier) classifie la donnée et en définit la sensibilité ; il décide qui y accède. Le Custodian (Data Custodian / steward, souvent IT) préserve la CIA au quotidien : sauvegardes, droits techniques, chiffrement - il applique les décisions de l'owner, il ne les prend pas. Le User / Operator applique les règles et signe l'AUP (Acceptable Use Policy). L'Auditor évalue indépendamment et mesure l'écart entre la politique et la réalité.

Vocabulaire réglementaire (GDPR). Le Data Controller détermine les finalités et moyens du traitement (il décide POURQUOI et COMMENT) ; le Data Processor traite pour le compte du controller (il exécute, sur instruction). Piège : ne pas confondre Owner (interne, classifie) et Controller (notion légale, responsable du traitement) ; ni Custodian (interne, technique) et Processor (tiers, légal).

3.3 Control frameworks

ISO 27001 énonce les exigences d'un ISMS (Information Security Management System / SMSI) : c'est la norme certifiable - une organisation se fait auditer et certifier sur sa conformité. ISO 27002 est le recueil de bonnes pratiques de contrôles (le « comment » détaillé des mesures) ; elle n'est PAS certifiable. Piège classique : on se certifie ISO 27001, jamais ISO 27002.

COBIT (ISACA) est un framework de gouvernance et de gestion de l'IT, très utilisé par les auditeurs ; il relie les objectifs IT aux objectifs business. NIST SP 800-53 est un catalogue exhaustif de contrôles de sécurité et de privacy (pour les systèmes fédéraux US) : on part d'une baseline (Low/Moderate/High selon FIPS 199/200) puis on applique scoping (écarter les contrôles non pertinents) et tailoring (adapter le reste au contexte). ITIL est l'ensemble de bonnes pratiques de gestion des services IT (service delivery), mappé à ISO 20000. Les CIS Controls (au nombre de 18) sont une liste priorisée et concrète de contrôles défensifs, gratuite et orientée action.

Exemple : pour décrocher une certification reconnue à l'international, on vise ISO 27001 ; pour bâtir un programme fédéral US, on s'appuie sur NIST 800-53 ; pour aligner IT et gouvernance face aux auditeurs, COBIT. Piège : NIST 800-53 n'est pas « certifiable » comme ISO 27001 - c'est un catalogue, pas un schéma de certification.

3.4 Processus organisationnels impactant la sécurité

Certaines décisions business modifient profondément la posture de sécurité. Lors d'une acquisition, l'entreprise acheteuse hérite des legacy systems, policies, procedures et données de la cible - souvent mal sécurisés - et peut soudain tomber sous de nouvelles législations et régulations. Une merger (fusion) impose d'aligner la security governance de l'entité résultante. Une divestiture (cession) ou un spinoff oblige à évaluer ce qui doit partir, ce qui reste, et comment séparer les accès et les données sans rupture de confidentialité.

Le risque majeur des M&A : l'organisation acquéreuse hérite des vulnérabilités de la cible. Cas réel cité par le CBK : Marriott a acquis Starwood en 2016 ; un système de réservation Starwood était déjà compromis depuis 2014 - la brèche n'a été découverte qu'après l'acquisition, exposant des centaines de millions de clients. D'où l'importance d'une due diligence de sécurité AVANT la signature.

Gouvernance de ces processus : un governance committee (souvent obligatoire en non-profit) encadre les décisions ; la transformation digitale et la réorganisation introduisent aussi des risques (comptes orphelins, données non migrées). Piège d'examen : la due diligence doit précéder l'intégration ; intégrer d'abord puis « auditer ensuite » revient à importer les compromissions de la cible dans son propre réseau.

3.5 Hiérarchie documentaire

La documentation de sécurité se structure en strates. La Policy est le document de plus haut niveau : elle exprime l'intention et la direction, est émise et signée par le senior management, et reste stable et générale (le « pourquoi »). Elle est obligatoire (mandatory).

Sous la policy : le Standard impose des choix précis et uniformes (technologies, configurations) - il est obligatoire. La Baseline définit le niveau minimum de sécurité à atteindre (un plancher de configuration) - obligatoire. La Procedure décrit le pas-à-pas détaillé d'exécution d'une tâche - obligatoire dans son périmètre. La Guideline, elle, est une recommandation : flexible et facultative, elle conseille sans contraindre (le « si vous voulez »).

Mémo examen : Policy > Standard / Baseline > Procedure sont obligatoires ; seule la Guideline est facultative. Piège récurrent : « Un standard est une suggestion » est FAUX (c'est obligatoire) ; « une guideline est obligatoire » est FAUX (c'est facultatif). Autre piège : la policy ne contient pas les détails techniques - ceux-ci descendent dans les standards et procedures pour que la policy reste stable dans le temps.

3.6 Due care, due diligence et alignement métier

Aligner la sécurité sur le métier, c'est ajuster plans et ressources aux goals et objectives : dépenser du temps, du matériel ou de l'argent sur des activités non essentielles est un signe de mauvais alignment. Le manuel rappelle que le security practitioner doit d'abord comprendre comment l'organisation fonctionne et ses objectifs, puis seulement déterminer comment la sécurité s'y insère pour rehausser ces fonctions. La BIA (business impact analysis, vue en 1.8) est la forme reconnue qui capture cet alignment entre goals, ressources et risques. Une gouvernance mal alignée produit des policies qui freinent inutilement la productivité, imposent des coûts indus et entravent l'intention stratégique.

Deux devoirs légaux et éthiques structurent cet effort. Due care = prendre toutes les actions raisonnables et prudentes pour planifier et accomplir une tâche ou une responsabilité, sur tout son cycle de vie (de la conception à la mise au rebut). C'est le fait de mettre en place les systèmes qui contrôlent ou préviennent les threat events. Due diligence = prendre toutes les actions raisonnables et prudentes pour surveiller, contrôler, gérer et, si besoin, réorienter les plans et actions dont on est responsable ; c'est rester attentif à l'environnement et aux nouveaux risques. Formule du manuel : "constant vigilance" exprime la due diligence ; on prête attention aux alarmes que les systèmes (due care) génèrent. Mémo de management : "you cannot manage what you do not measure".

Deux notions juridiques affinent ces devoirs. Prudent actions = ce que des personnes de formation, d'expérience et d'autorité comparables feraient dans les mêmes circonstances. Reasonable actions = décisions à la justification claire, logique et défendable après coup (agir sur une intuition n'est pas reasonable). Piège d'examen central : publier une policy ne suffit PAS comme due diligence ; pour satisfaire le devoir légal, l'organisation doit aussi disposer d'une capacité documentée et active de monitoring et d'enforcement vérifiant qu'elle respecte sa propre policy. La due diligence inclut aussi la revue de sécurité des vendors/suppliers avant de les utiliser et les background checks du personnel.

3.7 Frameworks étendus : RMF, FedRAMP, SABSA et catégories

Au-delà du noyau ISO 27001/27002-COBIT-NIST 800-53-ITIL-CIS, le manuel détaille plusieurs frameworks à connaître. Famille ISO 27000 : 27001 (exigences ISMS, certifiable), 27002 (catalogue de contrôles, advisory), 27003 (guide d'implémentation), 27005 (risk management). Action n°1 de 27001 : lire 27002 et justifier l'inclusion/exclusion de chaque contrôle - cet exercice produit la Statement of Applicability (SoA).

L'écosystème NIST/FIPS s'articule en cascade. Une FIPS est une exigence, une SP (Special Publication) est une guideline qui aide à la satisfaire. FIPS 199 catégorise le système (Low/Moderate/High selon C-I-A) ; NIST SP 800-60 explique comment réaliser cette catégorisation ; FIPS 200 impose des contrôles minimaux selon la catégorie ; NIST SP 800-53 fournit le catalogue de contrôles satisfaisant FIPS 200. Le NIST RMF (SP 800-37) transforme l'ancien Certification & Accreditation en un processus en six étapes (Categorize, Select, Implement, Assess, Authorize, Monitor) ; il n'est obligatoire que pour le fédéral US mais est largement adopté dans le privé et n'offre PAS de certification privée. FedRAMP applique cette logique au cloud : le JAB (Joint Authorization Board) accorde des autorisations provisoires réutilisables, et des 3PAO (Third-Party Assessment Organizations) vérifient indépendamment les contrôles d'un CSP.

SABSA (Sherwood Applied Business Security Architecture) est une méthodologie d'architecture de sécurité business-driven, risk- et opportunity-focused, qui supporte de façon traçable les objectifs métier (avantages : value-assured, prioritized, scalable, agile, open source, auditable). Enfin, le manuel distingue des CATÉGORIES de frameworks : privacy (PMF, ex-GAPP de l'AICPA, intègre GDPR/TSC) ; risk/ERM (ISO 31000, ISO 27005, COSO ERM, ISACA Risk IT, NIST SP 800-37) ; cybersecurity (ISO 270XX, HITRUST CSF pour HIPAA, CSA STAR pour le cloud avec ses 3 tiers et le CAIQ) ; et les Security Control Frameworks (SCF) qui donnent les pratiques minimales d'implémentation (PCI DSS, SWIFT CSCF, NIST, COBIT, CIS). Outil transverse : la gap analysis compare les contrôles en place à ce qu'exige un SCF. Piège : NIST RMF/800-53 et SABSA ne délivrent pas de certification privée comme ISO 27001.

Le NIST Cybersecurity Framework (CSF) structure quant à lui la sécurité autour de cinq fonctions : Identify, Protect, Detect, Respond, Recover. Largement adopté, il sert de langage commun pour piloter et communiquer la posture de sécurité au niveau direction.

4.1 Déterminer la conformité - lois, regulations, contrats, standards

La première compétence est de classer une obligation. Une loi (law) est votée par un législateur et a force contraignante sur tous. Une regulation est édictée par une agence sous l'autorité d'une loi et a aussi force de loi. Un contrat est un engagement entre parties (ex : adhérer à PCI-DSS pour traiter des cartes). Un standard est un référentiel technique ou de bonnes pratiques, contraignant seulement s'il est imposé par une loi ou un contrat.

Panorama des régimes majeurs. SOX (Sarbanes-Oxley) : loi US visant l'intégrité du reporting financier des sociétés cotées, après les scandales comptables. PCI-DSS : standard privé du PCI Security Standards Council imposé par contrat à quiconque stocke, traite ou transmet des données de carte. SOC 1/2/3 (AICPA, sous SSAE 18) : rapports d'attestation - SOC 1 sur le contrôle interne lié au reporting financier (ICFR), SOC 2 sur les Trust Services Criteria (security, availability, confidentiality, processing integrity, privacy), SOC 3 version publique allégée du SOC 2.

HIPAA : loi US protégeant les données de santé (PHI). GDPR/RGPD : règlement UE, droits étendus des personnes, notification de breach sous 72 heures, sanctions jusqu'à 4 % du chiffre d'affaires mondial annuel. FISMA : loi imposant un programme de sécurité aux agences fédérales US et à leurs sous-traitants, articulé avec le NIST RMF.

Piège d'examen : ne confondez pas la nature des instruments. PCI-DSS n'est pas une loi - sa force vient du contrat avec les réseaux de paiement. Un rapport SOC n'est pas une certification de sécurité absolue mais une attestation d'un auditeur sur des contrôles à une date ou sur une période donnée.

4.2 Systèmes et catégories de droit

Les systèmes juridiques diffèrent selon les pays. Le common law (anglo-saxon) s'appuie sur la jurisprudence et le précédent. Le civil law (droit continental) repose sur des codes écrits exhaustifs. Le customary law découle des coutumes et traditions, et le religious law tire ses règles d'un texte sacré. Beaucoup de pays sont hybrides.

Au sein du common law, on distingue trois catégories utiles à l'examen. Le droit criminel (criminal law) protège la société : l'État poursuit, le burden of proof est « au-delà du doute raisonnable » (beyond a reasonable doubt), la sanction peut être l'emprisonnement. Le droit civil (civil law au sens « tort ») règle les litiges entre parties privées : le standard est la « prépondérance de la preuve » (preponderance of the evidence), la sanction est financière (dommages-intérêts). Le droit administratif/réglementaire (administrative/regulatory law) est édicté par les agences : il a force de loi, son burden of proof est généralement bas.

Exemple : un employé détourne des fonds. L'État peut le poursuivre au pénal (prison) ; l'entreprise peut aussi le poursuivre au civil pour récupérer l'argent (dommages). Les deux actions coexistent avec des standards de preuve différents.

Piège d'examen : le burden of proof le plus élevé est celui du criminel (beyond a reasonable doubt). Le civil et le regulatory se contentent de la preponderance of evidence, donc plus faible. Ne mémorisez pas seulement les noms, mais l'ordre de sévérité.

4.3 Cybercrime et data breaches

Le cybercrime désigne tout délit où l'ordinateur intervient comme outil de l'infraction (ex : fraude, phishing) ou comme cible de l'infraction (ex : intrusion, déni de service). Cette distinction outil/cible structure la qualification juridique et le type d'enquête.

Il faut distinguer breach et data disclosure. Un breach (violation de sécurité) est la perte de contrôle, de confidentialité ou d'intégrité d'un système ou d'une donnée. Une data disclosure est la divulgation effective de données à une partie non autorisée. Tout breach n'entraîne pas nécessairement une disclosure, mais une disclosure traduit presque toujours un breach. Les lois de notification (GDPR, lois d'État US) imposent souvent d'alerter régulateurs et personnes concernées sous délai.

Lois emblématiques. Aux US, le Computer Fraud and Abuse Act (CFAA) criminalise l'accès non autorisé ou excédant l'autorisation à un système protégé. De nombreux pays ont des textes équivalents ; le défi est l'extraterritorialité, car une attaque traverse souvent plusieurs juridictions.

Piège d'examen : un breach n'est pas synonyme de divulgation de données. Le scénario peut décrire un système compromis sans exfiltration prouvée ; la bonne réponse parle de breach (perte de contrôle) et non de disclosure. Attention aussi à ne pas confondre l'obligation de notification (déclencheur juridique) avec la simple détection technique.

4.4 Propriété intellectuelle, import/export et transborder

Quatre régimes de propriété intellectuelle sont à maîtriser. Le trademark (marque) protège un signe distinctif (nom, logo, slogan) identifiant l'origine d'un produit ; renouvelable indéfiniment tant qu'il est utilisé. Le patent (brevet) protège une invention nouvelle, utile et non évidente ; durée typique de 20 ans en échange d'une divulgation publique. Le copyright protège l'expression d'une oeuvre (code, texte, image), pas l'idée ; durée généralement de la vie de l'auteur plus 70 ans. Le trade secret protège une information confidentielle ayant une valeur économique (formule, algorithme) ; durée illimitée tant que le secret est maintenu, mais aucune protection si le secret fuite.

L'infringement (contrefaçon) est l'usage non autorisé : utiliser une marque protégée, fabriquer un produit breveté, copier une oeuvre, ou s'approprier un secret. Le DRM (Digital Rights Management) ajoute des contrôles techniques pour faire respecter les licences (ex : verrou empêchant la copie).

Les contrôles import/export limitent la circulation de biens sensibles. Le Wassenaar Arrangement coordonne le contrôle des dual-use goods (biens à double usage civil/militaire), dont certaines technologies de chiffrement. Le transborder data flow désigne le transfert de données à travers les frontières ; il est encadré par des régimes comme le GDPR qui restreignent les transferts vers des pays sans protection adéquate.

Piège d'examen : pour protéger un algorithme secret, le trade secret peut surpasser le patent. Le brevet exige une divulgation publique et expire après 20 ans ; le trade secret reste protégé indéfiniment tant qu'il n'est pas révélé. Le choix dépend du risque de rétro-ingénierie et de la durée de l'avantage recherché.

4.5 Vie privée et principes OECD

La privacy concerne la protection des PII (Personally Identifiable Information), toute donnée permettant d'identifier une personne. L'organisation qui collecte des PII assume des obligations : minimiser la collecte, sécuriser, informer, et permettre l'exercice des droits des personnes.

Les huit principes OECD (1980, révisés) constituent le socle international le plus cité. 1) Collection Limitation : collecter de façon licite et loyale, idéalement avec le consentement. 2) Data Quality : données pertinentes, exactes, à jour. 3) Purpose Specification : finalité annoncée avant la collecte. 4) Use Limitation : ne pas utiliser au-delà de la finalité déclarée sans consentement ou base légale. 5) Security Safeguards : protéger par des mesures raisonnables. 6) Openness : transparence sur les pratiques. 7) Individual Participation : la personne peut consulter, contester, corriger ses données. 8) Accountability : le data controller répond du respect de tous ces principes.

Point clé : c'est le data controller qui reste accountable, même lorsqu'il sous-traite le traitement à un data processor. Externaliser une activité n'externalise pas la responsabilité légale.

Piège d'examen : la question oppose souvent data controller et data processor. Le processor agit pour le compte du controller, mais l'accountability finale - et donc la sanction - vise le controller. Ne choisissez pas le sous-traitant comme responsable du respect des principes OECD ou du GDPR.

4.6 Types d'investigation, forensique et chain of custody

Quatre types d'investigation se distinguent par leurs acteurs, leur burden of proof et leur finalité. L'administrative investigation est interne à l'organisation, vise à éclairer une décision de gestion (RH, conformité interne) et a un burden of proof faible. La criminal investigation est menée avec les forces de l'ordre, vise une condamnation pénale et exige le burden of proof le plus élevé (beyond a reasonable doubt). La civil investigation soutient un litige entre parties privées et repose sur la preponderance of evidence. La regulatory investigation est conduite par un régulateur pour vérifier la conformité à une réglementation, avec un burden of proof généralement bas.

Le choix du type oriente la rigueur de collecte. Une enquête susceptible de devenir criminelle doit dès le départ respecter les standards forensiques les plus stricts, car on ne peut pas reconstituer la rigueur après coup. Standards de référence : ISO/IEC 27037 (identification, collecte, acquisition, préservation des preuves numériques), ISO/IEC 27043 (principes des processus d'investigation), et NIST SP 800-86 (intégration du forensique à la réponse à incident).

L'admissibilité des preuves dépend de leur pertinence, leur fiabilité et leur légalité d'obtention. La chain of custody documente qui a manipulé chaque élément, quand, où et pourquoi, depuis la collecte jusqu'au tribunal. Une chain of custody rompue peut rendre une preuve irrecevable, même si elle est techniquement valable.

Piège d'examen : après un incident, si une criminal investigation démarre, traitez immédiatement la scène selon les standards les plus élevés. Le piège classique propose de « commencer en interne puis voir » - mais une collecte bâclée détruit la valeur probante. Quand le pénal est plausible, alignez-vous sur son exigence.

4.7 Licences logicielles et controles import/export (ITAR, EAR, Wassenaar)

Le logiciel est une forme de propriete intellectuelle : l'acheteur n'acquiert pas une copie mais un droit d'usage encadre par une licence. Le CISSP doit reconnaitre quatre grands modeles. La licence contractual (negociee) est un accord ecrit signe entre les parties, avec des clauses sur mesure (perimetre, duree, nombre de postes) ; c'est la forme la plus solide juridiquement. La licence shrink-wrap tire son nom de l'emballage plastique : l'acceptation des termes est reputee acquise des l'ouverture du paquet, sans signature. La licence click-through (aussi click-wrap) demande a l'utilisateur de cliquer "J'accepte" avant d'installer ou d'utiliser le logiciel ; le consentement est l'acte du clic. Enfin, l'EULA (End-User License Agreement), notamment pour les services cloud, definit les limites d'usage : qui peut utiliser, comment, pour combien de temps, et si l'oeuvre derivee est autorisee et protegee.

Le point d'examen est que le EULA fait payer le droit d'usage, pas la propriete de la copie. Definir clairement use limitations (qui, comment, combien de temps) est essentiel ; dans certains pays de l'UE, l'accord de licence doit etre enregistre aupres d'un office national de la propriete intellectuelle. Le DRM ajoute des controles techniques (verrous, geolocalisation, "phone home") pour faire respecter la licence, ce qui souleve des debats sur le fair use.

Les controles import/export limitent la circulation des technologies sensibles, en particulier la cryptographie. Au-dela du Wassenaar Arrangement (deja vu : 42 pays, dual-use goods et chiffrement), deux regimes US sont incontournables. L'ITAR (International Traffic in Arms Regulations), administre par le Department of State, encadre les articles et services strictement militaires inscrits sur l'US Munitions List. L'EAR (Export Administration Regulations), administre par le Department of Commerce (BIS), couvre les biens commerciaux et dual-use, dont une grande partie du chiffrement, via la Commerce Control List. La Militarily Critical Technologies List (MCTL) detaille en outre des technologies exigeant une autorisation d'export specifique.

Piege d'examen : ne reduisez pas l'import/export au seul Wassenaar. Distinguez ITAR (militaire pur, Department of State) de l'EAR (commercial et dual-use, Department of Commerce). Des pays comme la Russie, la Chine et la Coree du Nord imposent en plus de fortes restrictions sur l'usage de la cryptographie par leurs citoyens, ce qui peut rendre illegale l'introduction d'un simple appareil chiffrant en voyage.

4.8 Panorama des lois de privacy (US et international)

La privacy americaine est dite sectorielle : il n'existe pas de loi federale unique, mais un patchwork de textes par secteur, complete par des lois d'Etat et supervise pour le commerce general par la FTC (Federal Trade Commission). Trois textes federaux reviennent a l'examen. HIPAA protege les donnees de sante (PHI). Le GLBA (Gramm-Leach-Bliley Act) protege les donnees financieres des clients des institutions financieres. COPPA (Children's Online Privacy Protection Act) protege les donnees des enfants de moins de 13 ans en ligne. Au niveau des Etats, la CCPA (California Consumer Privacy Act, 2018) est la protection la plus forte des US, sans toutefois etre jugee adequate au sens du GDPR ; CalOPPA imposait deja la publication d'une politique de confidentialite.

Deux textes encadrent la surveillance. L'ECPA (Electronic Communications Privacy Act) protege les communications electroniques contre l'interception. Le Fourth Amendment protege contre les fouilles et saisies abusives, mais uniquement face au gouvernement : il ne contraint pas ce qu'une organisation privee fait de ses propres donnees, et celle-ci peut remettre volontairement des informations a l'Etat sur simple demande. L'USA PATRIOT Act (2001) a etendu les pouvoirs de search and seizure, en autorisant des national security letters servies sans intervention d'un juge ni subpoena, et interdit souvent de divulguer au data subject qu'une telle lettre a ete recue.

A l'international, les transferts hors UE dependent des adequacy decisions du GDPR (Japon, Nouvelle-Zelande, Argentine, Canada sont approuves ; les US ne le sont pas). Les dispositifs US successifs - Safe Harbor puis Privacy Shield - ont ete invalides par la CJEU (Schrems II, 2020) car n'offrant pas une protection suffisante face a la surveillance US. Restent les Standard Contractual Clauses (SCC, petites entreprises) et les Binding Corporate Rules (BCR, grands groupes, approuvees par une autorite de controle), eux-memes fragilises par Schrems II. L'EU Digital Markets Act vise les "gatekeepers" (Amazon, Apple, Meta, Microsoft) avec des amendes jusqu'a 10 % du CA mondial (20 % en recidive).

De nombreux pays ont des lois GDPR-like : Bresil (LGPD), Argentine, Chili (privacy declaree droit constitutionnel), Colombie, Australie (Notifiable Data Breaches : breach a declarer sous 30 jours au-dela de AU 3 M de CA), Afrique du Sud (POPIA). La data localization impose de stocker certaines donnees sur le territoire national : la Russie exige que toute donnee relative a un citoyen russe reside physiquement sur des serveurs en Russie, ce qui force des data centers locaux. Les Cross-Border Privacy Rules (CBPR) de l'APEC et le right to be forgotten (droit a l'effacement, GDPR) completent ce paysage mouvant.

Piege d'examen : ne confondez pas les regimes US sectoriels (HIPAA = sante, GLBA = finance, COPPA = enfants) et ne dites jamais que les US disposent d'une loi federale generale equivalente au GDPR. Sachez que Safe Harbor et Privacy Shield ont ete invalides (Schrems), que les US n'ont pas d'adequacy decision, et que le data controller reste accountable des transferts internationaux.

Au Canada, la loi-cadre est le PIPEDA (2000). Dans l'UE, la vie privée des communications électroniques relève aussi de l'ePrivacy Directive (2002/58/EC), antérieure et complémentaire au RGPD.

5.1 Fondamentaux et terminologie du risque

Le risk repose sur un triad : asset, threat, vulnerability. Un asset est tout ce qui a de la valeur pour l'organisation (donnees, systemes, personnes, reputation), et c'est sa valeur (asset value, AV) qui dicte le niveau de protection raisonnable. Une threat est un evenement potentiellement nuisible - naturel (seisme, inondation), technique (panne electrique, malware) ou humain (employe mecontent). Une vulnerability est une faiblesse qui permet a une threat de causer un dommage (datacenter sans onduleur, OS non patche). Retenez le principe d'exclusion : un systeme Linux n'a aucune vulnerability au ver Conficker, donc aucun risk associe - pas de vulnerability, pas de risk.

La formule conceptuelle de l'inherent risk est : Threat x Vulnerability x Asset value. C'est le risk brut, AVANT tout control. Aucun control n'elimine totalement le risk : il subsiste toujours un control gap (la part que le control ne couvre pas). Le residual risk est donc : (Threat x Vulnerability x Asset value) x control gap, autrement dit ce qui reste APRES l'application des controls. Piege classique : ne confondez pas residual risk et risk acceptance. Le residual risk est une quantite ; l'acceptance est une decision (l'organisation choisit de ne rien faire de plus).

L'exposure factor (EF) est la fraction de valeur d'un asset detruite par une occurrence d'un risk event : un asset totalement detruit a un EF de 1.0, un systeme triple-redondant qui perd un nud a un EF d'environ 1/3. Cote tolerance, distinguez risk appetite (le niveau de risk que l'organisation est prete a rechercher pour atteindre ses objectifs) et risk tolerance (l'ecart acceptable autour de ce niveau pour un risk donne). L'acceptable risk est le minimum de risk que l'organisation accepte de porter. Tous ces risks identifies, evalues et traites sont consignes dans le risk register, le registre central qui trace chaque risk, son owner, son traitement et son statut.

5.2 Le processus d'analyse de risque NIST SP 800-30

Le NIST SP 800-30, Risk Management Guide for Information Technology Systems, decrit un processus d'analyse de risque structure en six etapes. Le suivre garantit que l'analyse est repetable et defendable devant la direction.

Etape 1 - System Characterization : delimiter le perimetre (scope) de l'effort et decrire les systemes analyses (donnees, interfaces, frontieres). Etape 2 - Threat Identification : recenser les sources de menace pertinentes. Etape 3 - Vulnerability Identification : recenser les faiblesses exploitables. Ces deux etapes alimentent la formule Risk = Threat x Vulnerability x Asset.

Etape 4, en trois temps : 4a Control Analysis (analyser les controls/safeguards deja en place ou planifies pour reduire le risk), puis 4b Likelihood Determination et Impact Analysis (croiser probabilite et impact pour faire ressortir les risks critiques : haute probabilite x fort impact). Etape 5 - Countermeasure Recommendations : recommander des controls selon des criteres de cout (achat, conception, implementation, modifications d'environnement, compatibilite avec les autres countermeasures, maintenance, support, effet sur la productivite). Etape 6 - Document results : rapporter les constats au senior management et aux sponsors. Piege : l'analyste recommande (etape 5), mais la decision de traitement et la documentation finale remontent au management (etape 6) - l'analyste ne decide pas seul.

5.3 Analyse qualitative et matrice Probability x Impact

L'analyse qualitative est scenario-based : pour chaque menace majeure pesant sur un asset, l'equipe construit un scenario What if ? et evalue l'exposure et le potentiel de perte si la menace se realisait. Elle n'assigne aucun montant en dollars ; elle produit un classement relatif a partir d'echelles subjectives. C'est sa force (rapide, peu de donnees, facile a communiquer) et sa faiblesse (subjectivite).

L'outil central est la matrice Probability x Impact. Une echelle de probabilite type va de Frequent (A) -> Probable (B) -> Occasional (C) -> Remote (D) -> Improbable (E). Une echelle d'impact type va de Negligible (1) -> Marginal (2) -> Important/Critical (3-4) -> Catastrophic (5). Le croisement classe chaque scenario en Low / Medium / High / Very High risk. Exemple : un scenario Frequent x Catastrophic tombe en Very High risk et exige une action immediate ; un scenario Improbable x Negligible tombe en Low risk et peut souvent etre accepte.

Piege d'examen majeur : on n'additionne ni ne moyenne jamais des cotations qualitatives. Une echelle 1-10 trompe l'utilisateur en laissant croire qu'un risk note 8 est quatre fois plus grave qu'un risk note 2, ce qui est faux - ce sont des ordinaux, pas des grandeurs arithmetiques. Pour faire de l'arithmetique (comparer une perte attendue au cout d'un control), il faut basculer en quantitatif.

5.4 Analyse quantitative : SLE, ALE, ARO

L'analyse quantitative assigne des valeurs monetaires reelles, ce qui permet de faire de l'arithmetique et de comparer directement une perte attendue au cout d'une safeguard - le langage que comprend la direction. Trois grandeurs cles s'enchainent.

Le single loss expectancy (SLE) est la perte attendue d'UNE occurrence : SLE = AV x EF, ou AV est l'asset value et EF l'exposure factor (fraction <1 detruite par l'evenement). L'annual rate of occurrence (ARO) est le nombre de fois par an ou l'evenement est attendu. L'annual loss expectancy (ALE) est la perte attendue sur un an : ALE = SLE x ARO.

Exemple chiffre. Un vehicule vaut AV = 5 000 $. En cas de collision, le dommage attendu est EF = 20 % (0,2). Ce type de collision survient une fois tous les 4 ans, soit ARO = 0,25. On calcule : SLE = 5 000 x 0,2 = 1 000 $ ; ALE = SLE x ARO = 1 000 x 0,25 = 250 $. Decision : la regle est de comparer l'ALE au cout annuel de la safeguard. Si une assurance coute 200 $/an (< ALE de 250 $), la transferer est rationnel ; si elle coute 400 $/an (> ALE), payer la safeguard reviendrait a depenser plus que la perte attendue - mieux vaut accepter ou chercher moins cher. Regle d'or : ne jamais depenser plus pour traiter un risk que le cout du risk lui-meme. Piege : EF s'exprime en fraction, ARO peut etre < 1 (evenement plus rare qu'annuel), et l'ARO n'est PAS le SLE.

5.5 Traitement du risque : Avoid, Transfer, Mitigate, Accept

Une fois un risk priorise, l'organisation choisit un traitement parmi quatre options (mnemo MART : Mitigate, Avoid, Reduce/Transfer, Transfer). Risk avoidance : cesser l'activite exposee (fermer un magasin en zone a haute criminalite, deplacer une usine hors d'une zone d'ouragans). On y recourt quand l'impact potentiel est trop eleve pour etre compense par les benefices. Risk mitigation (reduce, renommee Modify par ISO 27005) : prendre des mesures de remediation ou deployer des controls (technical, physical, administrative) pour reduire la probabilite ou l'impact. Quoi qu'on fasse, il reste toujours du residual risk.

Risk transference (renommee Sharing par ISO 27005) : payer un tiers pour absorber l'impact financier - typiquement une assurance, dont la prime depend de la probabilite/impact, des controls en place et de l'historique de sinistres. Point capital : le transfert deplace l'impact financier, il n'elimine PAS le risk. L'organisation reste exposee operationnellement et garde sa responsabilite legale et reputationnelle ; l'assureur paie une fraction, pas la totalite, et exige souvent la preuve d'un programme de securite raisonnable. Risk acceptance : conduire l'activite sans action supplementaire, parce que l'impact ou la probabilite est negligeable, ou que le benefice depasse le risk. Attention : acceptance signifie que l'organisation ne fait rien de plus - a ne pas confondre avec residual risk.

Decision et signature : prioriser et choisir le traitement sont des decisions metier qui relevent du senior management (le risk owner). Le professionnel securite conseille, mais c'est le risk owner qui signe formellement l'acceptation d'un risk. Piege recurrent : si une question demande qui accepte le risk, la reponse est le business/senior management, jamais l'analyste ou le CISO seul.

5.6 Types et categories de controls sur la timeline d'incident

Deux axes orthogonaux classent les controls. D'abord le control TYPE - comment il est implemente : administrative (politiques, separation of duties, job rotation), technical/logical (firewalls, IDS, ACL, biometrie), physical (cloture, eclairage, suppression incendie). Ensuite la control CATEGORY - quelle fonction il remplit, repartie en sept categories situees sur la timeline d'un incident.

Avant l'incident (planification et defense) : Directive (oriente le comportement attendu - politique, panneaux Personnel autorise uniquement), Deterrent (decourage l'attaquant - cloture electrifiee, banniere d'avertissement), Preventive (empeche l'evenement - controle de changement, login par mot de passe, cloture de 8 pieds), Compensating (control alternatif quand le control prevu ne satisfait pas l'exigence - defense in depth en couches). Pendant/apres detection : Detective (signale qu'un evenement s'est produit - detecteur de mouvement, antivirus, supervision). Apres l'incident : Corrective (corrige - un IDS qui modifie dynamiquement l'ACL d'un routeur, reboot, extincteur), Recovery (ramene a la normale - restauration de backups, serveur redondant).

Piege central de l'examen : ne confondez JAMAIS type et category. Un firewall est de type technical et de categorie preventive ; une politique est de type administrative et de categorie directive ; un extincteur est de type physical et de categorie corrective. Une meme cellule combine donc toujours un type ET une categorie. Autre piege : Compensating n'est pas une categorie temporelle mais un control de substitution, choisi quand on ne peut pas implementer le control primaire.

5.7 Surveillance continue, SCA, KPI et frameworks

Selectionner et implementer des controls ne suffit pas : il faut les surveiller dans la duree. Le Security Control Assessment (SCA) est l'evaluation periodique de l'efficacite des controls et comporte trois methodes complementaires : Examine (revoir documents, configurations, politiques), Interview (questionner le personnel) et Test (eprouver le control en conditions reelles). On retient souvent le triptyque Examine / Interview / Test.

La surveillance s'appuie sur des key performance indicators (KPI) qui quantifient la performance des controls dans la duree et alimentent le reporting vers la direction, les regulateurs et les parties prenantes. L'objectif est l'amelioration continue : verifier en permanence que l'organisation ameliore sa gestion du risk et le return on investment (ROI) des controls. Le Risk Maturity Model (RMM) evalue la robustesse du programme de securite et trace un plan d'amelioration continue selon le niveau de maturite atteint.

Cote referentiels, plusieurs risk frameworks structurent la demarche : ISO 31000:2018 (gestion du risque generale, tous domaines), ISO 27005:2018 (gestion du risque specifique a la securite de l'information, alignee sur ISO 27001), et cote NIST, le NIST RMF (Risk Management Framework, decrit par SP 800-37) qui s'appuie notamment sur SP 800-30 pour l'analyse de risque. ISO Guide 73:2009 fournit le vocabulaire commun. Piege : ISO 31000 est generaliste (entreprise), tandis qu'ISO 27005 est dedie a la securite de l'information ; ne les confondez pas, et ne confondez pas SP 800-30 (guide d'analyse de risque) avec SP 800-37 (le processus RMF complet).

5.8 Choix qualitatif/quantitatif, FAIR, cost-benefit d'une safeguard et frameworks

Savoir calculer un ALE ne dit pas QUAND choisir l'approche quantitative plutot que qualitative. Le manuel ISC2 tranche par contexte. Le qualitatif convient face a la Newness (activite, marche ou organisation trop neufs pour disposer d'un historique mesurable), a l'Uniqueness (produits ou facon de faire si singuliers qu'aucune comparaison sectorielle n'existe), au manque de temps, d'argent ou de talent pour mener les mesures, et a l'absence de methode de mesure fiable. Le quantitatif convient quand les processus metier lies au risk sont bien compris, que des techniques de mesure d'une precision et fiabilite suffisantes existent, et que l'experience produit un echantillon assez grand pour etre statistiquement significatif. Piege : cette derniere exigence (echantillon significatif) est aussi l'argument contre le quantitatif a outrance - sans donnees suffisantes, le resultat n'est pas significatif ; les partisans du quantitatif repliquent que meme deux ou trois mesures a un chiffre significatif en disent plus que des estimations qualitatives anecdotiques.

L'alternative quantitative mise en avant par le manuel est la methode FAIR (Factor Analysis of Information Risk) : elle rend la plupart des taches d'evaluation quantitatives des le depart et le reste, de facon numeriquement simple et geree simplement. FAIR est integree au NIST CSF et a HITRUST, et compatible avec ISO 31000, COBIT et COSO. C'est l'antidote au defaut logique du qualitatif (impossible de moyenner cinq High, trois Medium et un Low pour obtenir une note de portefeuille).

Le terme risk exposure a trois sens a distinguer. L'exposure window mesure dans le temps la probabilite d'occurrence d'un risk event (on n'est pas expose au risk d'accident de la route en dormant chez soi ; une entreprise soutenant des causes politiques voit sa probabilite de menace grimper a l'approche d'une election) - utile aux systemes de risk-based access control. L'exposure factor (EF) est la fraction (<1) de valeur d'un asset reduite par une seule occurrence (deja vu : 1.0 = destruction totale). L'exposure estimate decrit qu'un risk est categoriquement bien plus bas ou plus haut qu'un autre pour une organisation donnee (une societe sans lien avec un pays a une exposure faible aux risks de ce pays).

Cote selection des controls, le NIST RMF (etape Select) offre deux approches. Le baseline control selection part de control baselines (jeux de controls predefinis pour un groupe ou une communaute) puis taille par retrait (top-down) - cela donne de la consistance a large echelle. L'organization-generated control selection ne part d'aucun jeu predefini : l'organisation choisit ses controls par son propre processus (bottom-up), pertinent pour un systeme tres specialise (arme, dispositif medical, smart meter). Les deux derivent ensuite des exigences via un processus d'ingenierie systeme cycle de vie (ISO 15288, NIST SP 800-160 Vol 1).

La selection se decide par cost-benefit analysis. Distinction cle du manuel : un safeguard reduit l'impact/probabilite AVANT la realisation du risk, un countermeasure les reduit APRES. On compare le cout d'acquisition, de deploiement et de maintenance du control a sa capacite a reduire l'impact/probabilite ET au cout du risk s'il se realise. Tout control a un impact negatif (cout monetaire ou perte de capacite/confort utilisateur) : il faut peser cet operational impact contre le benefice. Regle d'or elargie : dans la plupart des cas, ne pas depenser bien plus a mitiger, transferer ou eviter un risk que le pire impact possible - meme une decision d'acceptation se prend a la lumiere de ce trade-off. Pratiquement, la valeur d'une safeguard sur un an se mesure : ALE avant safeguard - ALE apres safeguard - cout annuel de la safeguard ; un resultat positif justifie le control.

Enfin, deployer des controls de plusieurs types ET categories qui se chevauchent constitue la defense in depth (layered defense), pour deux raisons : eviter qu'une seule defaillance (ex. coupure de courant neutralisant tous les controls technical, ou une vulnerability nouvelle sur l'unique control) n'expose totalement ; et forcer l'attaquant a preparer plusieurs moyens d'attaque, ce qui en reduit le nombre. Le tout doit etre reporte : le reporting sert deux finalites sur deux timelines - en temps quasi reel il informe les managers de la posture et emet alertes/alarmes lors d'un incident ; periodiquement il rend des comptes (accountability) a la direction, et parfois aux regulateurs voire aux law enforcement, avec l'accord de l'organisation. Au-dela des risk frameworks deja vus (ISO 31000, ISO 27005, NIST SP 800-30/800-37), le manuel cite aussi NIST SP 800-39, COBIT, SABSA et PCI ; ISO Guide 73 fournit le vocabulaire et COSO/COBIT encadrent la gouvernance.

6.1 Concepts du threat modeling

Le threat modeling est une technique qui consiste à examiner un environnement, un système ou une application du point de vue d'un attaquant afin de déterminer les vulnerabilities qu'il est susceptible d'exploiter, puis d'identifier les countermeasures adaptées. L'attack surface est l'ensemble des zones où un attaquant peut potentiellement déclencher une compromission : plus elle est large, plus le risque est élevé. Réduire l'attack surface (désactiver des services, fermer des ports, retirer des comptes) est une stratégie défensive de premier ordre.

Le threat modeling exige une abstraction non technique de la cible avant d'entrer dans le détail. On utilise pour cela un data flow diagram (ou dataflow diagram / workflow diagram) : une vue conceptuelle de la façon dont les données et les processus circulent dans la cible, du début à la fin. Cette abstraction permet à l'équipe de repérer où (dans le temps, l'espace et le processus) un attaquant pourrait agir.

Trois approches structurent l'analyse. L'approche attacker-centric part des acteurs susceptibles de nuire (ex : analyse AML, profilage des menaces) et déroule leurs objectifs et capacités. L'approche asset-centric part des actifs de valeur à protéger (ex : PHI, PII) et remonte vers les menaces qui les ciblent. L'approche software-centric (ou system-centric) représente le système comme un ensemble de processus interconnectés via des diagrammes d'architecture, que les analystes évaluent composant par composant ; c'est la plus utile pour la plupart des environnements de systèmes d'information.

Piège d'examen : le threat modeling est une forme de testing ; il identifie qu'un problème existe mais ne le corrige pas. La remédiation est une étape ultérieure, distincte.

6.2 Le processus de threat modeling

Le threat modeling suit un processus ordonné. Première étape, l'assessment scope : on identifie les actifs critiques à protéger. Cette étape est étroitement liée aux priorités du BIA (Business Impact Analysis) ; ce qui est critique pour la continuité d'activité l'est aussi pour la protection. On ne modélise pas tout indistinctement : le scope cadre l'effort.

Deuxième étape, identifier les threat agents et les attaques possibles : qui ou quoi veut attaquer ? On considère les insiders comme les outsiders, et les menaces malveillantes comme accidentelles. Troisième étape, comprendre les countermeasures existantes : un audit de ce qui est déjà en place et de son efficacité réelle. Sans cet état des lieux, on risque de proposer des contrôles redondants ou de surestimer la protection.

Quatrième étape, identifier les vulnerabilities exploitables, en priorité celles qui touchent le chemin critique défini par le BIA. Cinquième étape, prioriser les risques identifiés : le threat modeling fonctionne par priorités, car on ne peut pas tout protéger. Tout residual risk laissé en l'état doit être justifié et accepté formellement. Sixième étape, identifier les countermeasures pour réduire le risque : on complète la posture défensive en déployant des contrôles contre les vulnerabilities priorisées (IDS/IPS, firewalls, access control, biometrics, etc.).

Piège d'examen : le scope et la priorisation s'appuient sur le BIA. Une question qui demande "par quoi commencer" dans le threat modeling attend généralement l'identification/priorisation des actifs critiques, pas le déploiement immédiat de countermeasures.

6.3 Méthodologies : STRIDE, DREAD, PASTA

STRIDE est un système de classification des menaces issu du Microsoft Security Development Lifecycle (SDLC), utilisé pour informer les développeurs des menaces pendant le développement. Ses six catégories : Spoofing identity (usurpation d'identité), Tampering with data (altération non autorisée des données), Repudiation (l'attaquant peut nier ou dissimuler sa participation), Information disclosure (divulgation accidentelle ou malveillante de données), Denial of service (atteinte à la disponibilité, axe A de la triade CIA) et Elevation of privilege (l'attaquant gagne un niveau de contrôle pour désactiver ou détruire la cible). STRIDE catégorise : il dit de quel type de menace il s'agit.

DREAD est un modèle de scoring : Damage, Reproducibility, Exploitability, Affected users, Discoverability. On note chaque dimension pour obtenir un score relatif qui aide à prioriser les menaces. STRIDE et DREAD sont complémentaires : l'un classe, l'autre quantifie.

PASTA (Process for Attack Simulation and Threat Analysis) est une méthodologie en sept étapes, dite risk-centric, qui aligne les objectifs métier sur l'analyse technique des menaces et simule des attaques pour évaluer le risque réel. Elle va de la définition des objectifs jusqu'à l'analyse de risque et de l'impact.

À connaître aussi (au moins par leur nom) : OCTAVE (vue du risque global des systèmes IT à l'échelle de l'organisation, variantes OCTAVE et OCTAVE-S), TRIKE, VAST, CORAS, LINDDUN (orienté privacy) et NIST SP 800-154 (guide de data-centric threat modeling). ATASM (Architecture, Threats, Attack Surfaces, Mitigations) est une autre approche citée.

Piège d'examen : ne confondez pas STRIDE (catégorisation des menaces) et DREAD (scoring/priorisation). PASTA se distingue par son caractère risk-centric et ses 7 étapes.

6.4 Supply Chain Risk Management (SCRM)

Aucune organisation ne fonctionne seule : elle dépend de suppliers, vendors, contractors et customers. Le SCRM applique à cette chaîne les mêmes méthodologies de risk management que l'organisation applique à ses opérations internes. Historiquement, les supply chain risks visaient des actifs tangibles (incendies, catastrophes naturelles), mais les technologies de l'information et de la communication sont tout aussi vulnérables, accidentellement comme malicieusement, en particulier pour les critical systems.

Les risques se répartissent en trois familles. Hardware : matériel acheté (serveurs, postes, caméras, systèmes legacy d'usine) pouvant être contrefait ou altéré ; un Silicon Root of Trust et un Software Bill of Materials (SBOM) aident à en vérifier l'intégrité. Software : logiciels du commerce comportant bugs ou fonctions mal conçues, exploitables ; un défaut inconnu du vendeur exploité par un attaquant est un zero-day. Services / Cloud : attaquer un petit fournisseur partagé par de grandes entreprises est souvent plus facile que d'attaquer ces grandes entreprises directement.

Les bonnes pratiques d'acquisition imposent des exigences de cybersécurité comme condition d'attribution du contrat, et privilégient l'achat auprès des OEM (Original Equipment Manufacturers), de leurs sources de confiance et de leurs revendeurs autorisés (authorized resellers), pour éviter le matériel contrefait. Attention aux 4th parties : les sous-traitants de vos propres fournisseurs élargissent la chaîne et le risque au-delà de votre visibilité directe.

Exemples types : Target (2013, accès via un tiers HVAC vers les terminaux de paiement), XCodeGhost (2015, compilateur XCode contrefait), et surtout SolarWinds/Sunburst (2020) : un outil de supervision réseau légitime, infecté à la source, a distribué le malware Sunburst à des milliers d'organisations - illustration parfaite du software supply chain attack.

Piège d'examen : compromettre un seul fournisseur de services pour atteindre tous ses clients (SolarWinds) est l'argument central du SCRM. Le tiers le plus faible définit souvent le niveau de sécurité réel.

6.5 Évaluation des tiers et due diligence

Avant toute supply chain agreement contraignante, le security professional doit conduire une due diligence sur le tiers. Elle combine trois activités : l'on-site assessment (visite et inspection des lieux du fournisseur), le document exchange (échange de documentation : politiques, certifications, rapports d'audit) et le process/policy review (revue des processus et politiques pour vérifier que le fournisseur suit un cadre de contrôles de sécurité acceptable). Le security professional doit s'impliquer dans les trois afin de comprendre les risques de la transaction. Des assurances externes complètent l'évaluation : audits ISO, CSA STAR pour le cloud, ou attestations AICPA (SOC).

Les minimum security requirements se définissent dès la phase de requirements gathering du projet. Une bonne pratique est de rédiger un Statement of Requirements couvrant : une spécification synthétique des besoins pour le management, un énoncé des objectifs clés, une description de l'environnement d'exploitation, le contexte et les références, ainsi que les contraintes majeures de conception.

Deux documents structurent la relation. Le SLR (Service Level Requirements) décrit le service attendu du point de vue du client : c'est l'expression du besoin, en amont. Le SLA (Service Level Agreement) est l'accord signé entre le tiers et le client, documentant le service IT fourni, les service level targets (cibles mesurables) et les responsabilités respectives du fournisseur et du client. En clair : le SLR exprime ce que l'on veut, le SLA engage contractuellement sur ce qui sera fourni et mesuré.

Les clauses contractuelles renforcent la gouvernance : droit d'audit (right to audit) permettant de vérifier la conformité du fournisseur, obligation de notification en cas d'incident ou de breach, exigences de sous-traitance (encadrer les 4th parties) et clauses de jurisdiction quand le tiers opère sous une réglementation différente.

Piège d'examen : la due diligence se fait AVANT la signature du contrat ; le right to audit et le SLA encadrent la phase d'exécution. Et ne confondez jamais SLR (besoin, côté client) et SLA (accord signé, bilatéral, mesurable).

6.6 Reduction analysis (decomposition) et prioritisation

Une fois le data flow diagram dessine, l'etape decisive du threat modeling software-centric est la reduction analysis, aussi appelee decomposition. Decomposer signifie casser le systeme en ses elements constitutifs pour rendre visibles les endroits exacts ou un attaquant peut agir. Cinq elements sont a identifier systematiquement.

D'abord les trust boundaries : toute frontiere ou le niveau de confiance ou de privilege change (entre Internet et le DMZ, entre le DMZ et le reseau interne, entre l'application et la base de donnees). C'est a ces frontieres que se concentrent les menaces, car les donnees y passent d'une zone de confiance a une autre. Ensuite les data flow paths : le chemin que suivent les donnees a travers le systeme, d'un point a un autre. Puis les input points (ou entry points) : tout endroit ou des donnees externes entrent dans le systeme (formulaires, API, uploads, parametres) ; ce sont les portes par lesquelles l'attaquant injecte. Ensuite les privileged operations : les actions qui exigent des droits eleves (changer une config, creer un compte admin, acceder a une cle) et qui sont des cibles de choix pour l'elevation of privilege. Enfin la description de la security stance / approach : la posture de securite et les hypotheses de l'application (politiques, dependances, controles supposes en place), qu'il faut expliciter pour ne pas la prendre pour acquise.

La decomposition alimente directement la prioritisation, car le threat modeling fonctionne par priorites : on ne peut pas tout traiter. Deux methodes simples et frequemment testees. La premiere : Probability x Damage Potential, qui combine la probabilite qu'une menace se concretise et l'ampleur du dommage si elle se concretise, pour obtenir un risk ranking. La seconde : un classement qualitatif High / Medium / Low, plus rapide quand les donnees chiffrees manquent. DREAD est une variante de scoring plus fine de cette logique.

Deux methodologies completent le paysage au-dela de STRIDE/DREAD/PASTA. VAST (Visual, Agile, and Simple Threat modeling) est concu pour passer a l'echelle dans des organisations agiles : il distingue application threat models (orientes developpeurs, via process flow diagrams) et operational threat models (orientes infrastructure et architectes), et s'integre dans les pipelines DevOps. Trike est une methodologie orientee risk management et audit, qui s'appuie sur un requirements model assignant un niveau de risque acceptable a chaque actif et genere des threat models a partir de ce modele.

Piege d'examen : rappelez-vous que le threat modeling, decomposition incluse, est une forme de testing. Il revele ou se trouvent les trust boundaries faibles, les input points exposes et les privileged operations a risque, mais il ne corrige rien : la remediation est une etape ulterieure et distincte.

7.1 Continuité d'activité et BIA

La business continuity (BC) regroupe les actions, processus et outils qui permettent à l'organisation de poursuivre ses critical operations pendant une contingence ; la disaster recovery (DR) couvre la remise en état pour revenir aux opérations normales. On les traite ensemble sous le terme BCDR. Tout part du Business Impact Analysis (BIA), l'effort qui détermine la valeur de chaque asset, les menaces probables et le potentiel de réalisation de ces menaces. Le BIA révèle le critical path : l'ensemble des activités sans lesquelles l'organisation ne peut survivre. Exemple : un assureur dont les systèmes tombent peut continuer à émettre des polices manuellement - workaround coûteux mais viable.

Le BIA est avant tout un management process. Il exige le senior leadership support, car ce sont les dirigeants qui fixent le niveau de risque tolérable (risk appetite / risk tolerance) et arbitrent les coûts. Les risques à évaluer dépassent le technique : impact financial (perte de revenu), reputational (perte de confiance client), et regulatory (HIPAA impose un data backup plan et un emergency operations mode ; non-conformité = pénalités). Plusieurs méthodes alimentent le BIA : survey des asset owners (proche du terrain mais biaisé), financial audit (exhaustif mais valeur variable dans le temps), retours clients, benchmarks sectoriels.

Le BIA priorise ensuite les Critical Business Functions. Une grille classique distingue : Critical (l'arrêt menace immédiatement la survie - ex : moteur de paiement), Essential (nécessaire à court terme mais tolère une brève interruption), Supporting (assiste les fonctions critiques sans être vital - ex : reporting interne), Nonessential (peut être suspendu longtemps - ex : audit interne, recrutement). Piège d'examen : le BIA n'est pas un plan de reprise ; il fournit les données (critical path, valeurs, dépendances) qui alimentent le BCP/DRP. Confondre BIA et BCP est une erreur classique.

7.2 Les trois sorties clés du BIA : MTD, RTO, RPO

Le BIA produit trois paramètres de contrôle que le senior management transmet aux concepteurs du BCDR. Le Maximum Tolerable Downtime (MTD), aussi appelé Maximum Allowable Downtime (MAD) ou Maximum Allowable Outage (MAO), est la durée maximale pendant laquelle un processus métier peut être interrompu sans causer un dommage significatif ou inacceptable à la mission. C'est un plafond : au-delà, l'organisation subit un préjudice grave. Exemple : pour une plateforme de trading, le MTD peut être de quelques heures ; pour un site vitrine, plusieurs jours.

Le Recovery Time Objective (RTO) est la durée cible pour rétablir la disponibilité du critical path après une interruption. Contrainte fondamentale : RTO <= MTD. Régler le RTO égal ou supérieur au MTD vide l'objectif de son sens, car on dépasserait le seuil de dommage. Attention : « recovery » ici n'est pas le retour aux opérations normales, mais le retour à une disponibilité fonctionnelle temporaire du critical path. Plus le RTO est court, plus la solution BCDR coûte cher : c'est un arbitrage coût/rapidité.

Le Recovery Point Objective (RPO) mesure la quantité de données que l'organisation peut perdre sans préjudice inacceptable. Il s'exprime en unités de temps (minutes, heures, jours), généralement l'écart entre le dernier bon backup et l'instant de l'incident - pas en gigaoctets. Pour une banque, le RPO tend vers zéro (aucune transaction perdue) ; pour d'autres secteurs, plus de tolérance. Sur la timeline : RPO regarde vers le passé (données perdues avant l'incident), RTO regarde vers le futur (temps pour se rétablir après). À noter aussi le Work Recovery Time (WRT), période de rattrapage des transactions accumulées. Piège d'examen : RTO = temps, RPO = données (exprimées en temps). Confondre les deux est l'erreur la plus fréquente.

7.3 Sécurité du personnel : le cycle de vie

L'humain est un double tranchant : source d'erreurs et de malveillance, mais aussi première ligne de défense. On adresse l'insider threat le plus tôt possible, avant même l'accès aux données. Le candidate screening précède l'embauche : job description précise (référence pour évaluer la performance et fonder un éventuel licenciement), vérification des references, de l'employment history, background check (criminel, diplômes, certifications) et, pour les postes très sensibles, financial profile (révèle une instabilité exploitable). Une fois embauché, l'accès suit le least privilege et idéalement un modèle RBAC où les droits découlent du rôle décrit.

À l'embauche, on fait signer les employment agreements : employee handbook (politiques et standards, réception confirmée), employment contract (termes, paie, performance), Nondisclosure Agreement (NDA, non-divulgation pendant et après l'emploi), Acceptable Use Policy (AUP, usage approuvé des assets) et Code of Conduct. Ces documents sont signés au plus tard à l'onboarding, idéalement en présence d'un représentant, chaque partie en conservant copie. L'onboarding inclut la revue du contrat et de la job description, la formation initiale de sécurité et la remise sécurisée des accès (ID/mot de passe, badges, tokens).

La termination doit être tout aussi codifiée. On distingue le friendly (départ amiable, ex : démission, retraite) - on peut mener un exit interview pour comprendre les raisons et rappeler les obligations NDA - et l'unfriendly (licenciement, départ conflictuel) qui exige des contrôles renforcés et rapides. Dans tous les cas : verrouiller immédiatement les comptes IT pour empêcher toute modification de dernière minute, récupérer le matériel et les access control items (badge, clés, tokens), revoir les termes du NDA, et escorter la personne hors des locaux si le poste n'est pas distant. Piège d'examen : pour un administrateur licencié sans préavis (unfriendly), la révocation des accès doit précéder ou accompagner l'annonce, jamais l'inverse ; un admin prévenu trop tôt peut saboter ou exfiltrer.

7.4 Contrôles des tiers internes : vendor, consultant, contractor

Les tiers internes - vendor, consultant, contractor, sous-traitants, visiteurs - obtiennent un accès physique ou logique sans relever du même contrôle RH que les employés. Ils représentent un vecteur d'insider threat souvent sous-estimé. Le principe directeur reste le least privilege : l'accès est limité au strict nécessaire, pour la durée strictement requise, et révoqué dès la fin de mission. Avant tout accès, on procède à une vérification d'identité fiable et, selon la sensibilité, à un background check, qui peut être exigé du tiers ou de son employeur.

Sur le plan contractuel, le tiers signe un NDA spécifique (souvent distinct de celui des employés, parfois mutual NDA / two-way NDA quand l'échange d'informations sensibles est bilatéral) et accepte une AUP couvrant l'usage des assets auxquels il accède. Le contrat doit codifier les obligations de sécurité, la propriété des livrables et les conditions de fin d'accès. Pour les sous-traitants accédant aux systèmes, l'organisation peut imposer des people-facing instructions explicites et des activités de monitoring et surveillance.

Les contrôles opérationnels typiques : escorte physique pour les visiteurs et intervenants dans les zones sensibles, monitoring de l'activité (screen sharing supervisé, enregistrement de session, journalisation), et restriction d'accès aux seuls systèmes concernés. Toute surveillance doit respecter strictement les lois applicables, qui varient fortement selon les juridictions. Piège d'examen : un consultant n'est pas un employé ; ne lui appliquez pas par défaut les mêmes contrôles d'onboarding, mais un dispositif dédié (NDA spécifique, escorte, monitoring renforcé, accès temporaire) - et n'oubliez pas de révoquer ses accès à la fin de la prestation, faute de quoi vous laissez des comptes orphelins exploitables.

7.5 Programme de sensibilisation : Awareness, Training, Education

Un programme de sécurité humaine relève de la due care (fournir une formation efficace) et de la due diligence (vérifier qu'elle fonctionne). L'examen distingue trois types d'activités d'apprentissage. Awareness (« le pourquoi », pour tous) attire et engage l'attention en faisant prendre conscience d'un enjeu ; elle façonne croyances et comportements (signalétique, écrans de veille, newsletters, rappels). Training (compétences liées au rôle) construit la proficiency sur un ensemble de tâches précises : reconnaître un phishing et appliquer la bonne réponse. Education (compréhension profonde) explique les causes et concepts pour un public ciblé, souvent associée aux certifications. Mnémonique : Awareness change ce que l'on remarque, Training ce que l'on sait faire, Education ce que l'on comprend.

Le programme cible particulièrement le social engineering (phishing, vishing, smishing). Méthodes : Computer-Based Training (CBT, à son rythme, standardisé, mais risque de click-through - efficace couplé à de faux phishing tests), formation live (contre le click-through, crée du rapport), communications régulières, reward mechanisms (récompenser le bon comportement plutôt que punir), gamification (engagement et rétention accrus, ex : OWASP Cornucopia) et Security Champions (volontaires de chaque métier diffusant les bons réflexes). Le contenu doit être revu périodiquement (lois, politique, nouvelles attaques, nouveaux outils).

La due diligence impose de mesurer l'efficacité via des métriques liées aux objectifs. Exemples : taux de clic sur les campagnes de phishing simulé (baisse attendue dans le temps), taux de complétion des modules, attestation signée (preuve d'acknowledgement), nombre de signalements d'incidents, résultats aux évaluations. Piège d'examen : ne confondez pas les trois niveaux. Un module CBT obligatoire sur « comment reconnaître un phishing » est du Training, pas de l'Education ; une affiche rappelant de verrouiller son écran est de l'Awareness. La question type donne un exemple et demande de nommer le niveau - la bonne réponse dépend du verbe : sensibiliser (Awareness), rendre capable (Training), faire comprendre en profondeur (Education).

7.6 Contrôles anti-fraude RH : SoD, least privilege, job rotation, mandatory vacation, dual control

Au-delà du cycle joiner-mover-leaver, la sécurité du personnel repose sur une famille de contrôles administratifs qui réduisent l'insider threat et la fraude. On les classe en préventifs (ils empêchent l'abus de survenir) et détectifs (ils le révèlent après coup). Le manuel ouvre d'ailleurs le sujet sur le two-person integrity control, preuve que ces mécanismes sont au cœur du Domaine 1.

Les contrôles préventifs. La separation of duties (SoD) découpe une transaction sensible en plusieurs étapes confiées à des personnes distinctes, de sorte qu'aucun individu seul ne puisse la mener de bout en bout (ex : qui crée un fournisseur ne peut pas approuver son paiement). Le least privilege accorde le minimum de droits nécessaires à la fonction, idéalement via RBAC. Le need-to-know va plus loin : même habilité, on n'accède qu'aux informations strictement requises pour la tâche du moment (least privilege porte sur les permissions système, need-to-know sur la connaissance). Le dual control / two-person control (parfois nommé two-person integrity ou règle des deux personnes) exige l'action simultanée de deux personnes pour une opération critique (ex : deux clés pour un coffre, double validation d'un virement). Attention : SoD répartit des étapes différentes entre des personnes ; dual control exige deux personnes pour la même étape.

Les contrôles détectifs et hybrides. La job rotation (rotation des postes) fait tourner les personnes entre fonctions ; elle complique la fraude durable (un complot devient instable) et révèle des malversations quand un remplaçant découvre les anomalies, tout en réduisant le single point of knowledge. La mandatory vacation (congé imposé) force un employé à s'absenter une période continue pendant laquelle un tiers occupe son poste : une fraude qui exige une présence quotidienne pour être maintenue (falsification de comptes, lapping) finit par se révéler. Job rotation et mandatory vacation sont surtout détectifs (et dissuasifs), tandis que SoD, least privilege, need-to-know et dual control sont préventifs. Piège d'examen : ne confondez pas les trois. SoD = découper une tâche entre plusieurs personnes (préventif) ; job rotation = changer les gens de poste dans le temps (détectif) ; mandatory vacation = éloigner la personne pour qu'un autre découvre la fraude (détectif). Si la question demande "quel contrôle révèle une fraude qu'un employé dissimule en restant à son poste", la réponse est mandatory vacation.

7.7 BCMS et standards de continuité : ISO 22301, NIST SP 800-34, BC vs DR

Une organisation qui veut formaliser sa continuité peut construire son Business Continuity Plan (BCP) de zéro ou s'appuyer sur des standards reconnus, soit en référence, soit en les adoptant intégralement. Connaître ces référentiels et la notion de Business Continuity Management System (BCMS) - le système de management qui pilote la continuité comme un processus permanent, et non comme un document figé - est attendu à l'examen.

Les standards à retenir. NIST SP 800-34 (Contingency Planning Guide for Federal Information Systems) fournit instructions et recommandations pour la planification de contingence des systèmes fédéraux. La série ISO 22300 définit les exigences et lignes directrices d'un BCMS : ISO 22300 (vocabulary, le glossaire), ISO 22301 (requirements, la norme certifiable qui fixe les exigences d'un BCMS), ISO 22313 (guidance, l'aide à la mise en oeuvre de 22301) et ISO/TS 22315 (guidelines for business impact analysis, le BIA). Mnémonique : 22301 = ce qu'il faut faire (requirements, certifiable) ; 22313 = comment le faire (guidance). L'organisation peut en plus devoir satisfaire des exigences de continuité d'origine légale, réglementaire ou contractuelle (ex : HIPAA impose data backup plan et emergency operations mode ; certaines places financières imposent un BCP).

BC vs DR : la distinction que l'examen teste. Ce sont deux éléments séparés. La Business Continuity (BC) est la capacité de l'organisation à maintenir ses core functions et à continuer de délivrer produits et services pendant une disruption majeure - c'est le volet métier et organisationnel. La Disaster Recovery (DR) est la manière dont cette continuité est techniquement réalisée et restaurée : technologies, infrastructure, outils nécessaires ; le DR fait partie du BCP. En clair : BC = rester opérationnel côté métier ; DR = remettre en état les systèmes et revenir à la normale. Les deux partent d'une policy et s'appuient sur le BIA, qui fixe le scope et l'ampleur des plans. Enfin, après avoir identifié le critical path, on capture toutes les external dependencies (supply chain, prestataires, cloud) et on construit un stakeholder map alimentant un communications plan ; pour une opération dans le cloud, le plan doit prévoir les failure modes de perte d'un data center local, d'une région, voire du provider SaaS global (le plus difficile à récupérer). Piège d'examen : ne pas réduire la BC à la DR. Si la question oppose "continuer à fonctionner" (BC) à "restaurer les systèmes" (DR), ou demande quelle norme est certifiable (ISO 22301), gardez la distinction nette.