Opérations de sécurité

1.1 Types d'investigations et eDiscovery

Toute investigation n'a pas la même finalité ni le même niveau de preuve. Une administrative investigation est interne à l'organisation : elle vise à établir des faits liés à une violation de politique ou à un dysfonctionnement RH ; son standard de preuve est faible et son issue va du rappel à l'ordre au licenciement. Une criminal investigation est menée par les forces de l'ordre lorsqu'une loi pénale est violée ; elle exige le standard de preuve le plus élevé (beyond a reasonable doubt) et peut conduire à des sanctions pénales. Une civil investigation oppose des parties privées (rupture de contrat, litige commercial) avec un standard plus faible (preponderance of evidence). Une regulatory investigation est conduite par une autorité (régulateur sectoriel, autorité de protection des données) pour vérifier la conformité à une réglementation, avec des sanctions administratives à la clé.

Le type d'investigation conditionne tout : qui mène, quelles preuves sont recevables, quelles obligations légales s'appliquent. Confondre une enquête interne avec une procédure pénale - ou inversement - expose l'organisation à invalider ses preuves ou à enfreindre les droits des personnes.

L'eDiscovery (electronic discovery) est le processus d'identification, de préservation, de collecte et de production d'informations stockées électroniquement (ESI) en réponse à une demande dans le cadre d'un litige ou d'une enquête. Le standard ISO 27050 encadre l'eDiscovery, en cohérence avec des modèles comme l'EDRM. Piège d'examen : l'eDiscovery n'est pas la forensique ; c'est le cadre de gestion de l'ESI à produire, alors que la forensique est l'analyse technique des supports. Une preservation obligation (legal hold) peut imposer de geler des données dès l'anticipation d'un litige, sous peine de spoliation.

1.2 Types de preuve, recevabilité et les quatre tenets

Porter un dossier numérique devant un tribunal soulève une question décisive : l'admissibility. Une preuve n'est utile que si la cour l'accepte. Or toute preuve altérée n'est pas automatiquement irrecevable, et toute preuve intacte n'est pas automatiquement acceptée : tout dépend de la manière dont elle a été documentée, préservée et présentée. C'est précisément pourquoi le manuel recommande de recourir à des professionnels dédiés de la forensique et de la collecte de preuves.

Le manuel énonce quatre tenets que le security professional doit respecter pour présenter une preuve, surtout devant une cour. Admissibility : seule une preuve acceptable par la cour peut être présentée ; c'est la cour qui signale ce qui est irrecevable. Accuracy : la preuve doit être vraie et claire. Comprehensibility : même si l'organisation cherche à raconter une histoire cohérente, elle ne peut pas dissimuler une preuve contraire à cette histoire ; retenir une preuve défavorable peut, dans certains cas, constituer une infraction. Objectivity : la preuve doit valoir par elle-même, sur une base factuelle ; sauf invitation de la cour ou du conseil, le professionnel ne doit pas introduire d'opinion subjective.

Piège d'examen : ne confondez pas admissibility (la cour accepte ou non) et accuracy (la preuve est exacte) ; et retenez que la comprehensibility interdit de cacher les éléments à décharge, ce qui surprend les candidats qui imaginent l'enquêteur comme un avocat partisan. La documentation est le fil rouge qui sécurise les quatre tenets.

Un principe fondateur eclaire pourquoi la preuve numerique existe : le Locard's exchange principle (principe d'echange de Locard) enonce que tout contact laisse une trace. Transpose au numerique, chaque action d'un attaquant (connexion, commande, transfert) depose des artefacts (logs, fichiers temporaires, entrees de registre, metadonnees) et en emporte d'autres. C'est ce qui rend l'investigation possible : il n'existe pas d'intrusion sans trace, seulement des traces que l'on n'a pas encore su collecter ou correler.

1.3 Order of volatility et préservation vs vitesse de réponse

Toutes les données ne survivent pas également au temps et aux manipulations. L'order of volatility classe les sources de preuve de la plus volatile à la plus durable, dictant l'ordre dans lequel les collecter. En haut de l'échelle se trouvent les registres et caches CPU, puis la mémoire RAM, puis l'état réseau et les tables de connexions, puis les fichiers temporaires et l'espace disque actif, et enfin les supports de stockage durables (disques, archives, sauvegardes). On collecte d'abord le plus volatile.

La volatilité de la RAM est un détail crucial mais souvent négligé. Les données en random-access memory sont extrêmement volatiles : dès qu'on coupe l'alimentation ou qu'on éteint le système, le contenu de la RAM devient irrécupérable par des moyens ordinaires. D'où un dilemme central : en cas d'incident, éteindre les machines peut stopper la propagation d'un malware, mais peut aussi détruire des preuves clés nécessaires à une investigation ultérieure.

C'est l'arbitrage entre speed of response (limiter le dommage et le risque) et préservation des preuves. La collecte de preuve est un processus sensible : agir trop vite pour contenir l'attaque peut effacer la mémoire vive ; agir trop lentement laisse le dommage s'étendre. Le bon réflexe forensique est souvent de capturer la RAM (memory dump) avant toute coupure, lorsque c'est compatible avec la sécurité des personnes et la limitation du risque. Piège d'examen : si une question oppose « éteindre vite pour stopper le malware » et « préserver la preuve volatile », le raisonnement attendu est de capturer le volatile d'abord, sauf danger immédiat. Order of volatility = ordre de collecte, du plus éphémère au plus durable.

1.4 Chain of custody, write-blocking et conduite des interviews

La chain of custody (chaîne de possession) est la traçabilité documentée d'une preuve depuis sa collecte jusqu'à sa présentation. Elle doit répondre aux questions impératives - qui, quoi, où, pourquoi, quand - pour chaque manipulation de la preuve. La documentation doit être si complète qu'une autre personne, partant du même matériel d'origine, pourrait suivre le processus documenté et aboutir à la même analyse. Elle inclut toutes les étapes : collecte/capture, analyse et stockage de la preuve.

La préservation de l'original est un principe cardinal. Le professionnel doit éviter toute modification non enregistrée ou involontaire. Cela passe par l'usage de la write-blocking technology, qui empêche toute écriture sur le support saisi pendant la copie ; par le contrôle des accès externes ; et par la maîtrise des émissions électromagnétiques. L'analyse doit, autant que possible, se faire sur des copies (bit-level copies) et non sur l'original. Tous ces efforts de préservation doivent eux-mêmes être documentés.

Les interviews suivent des bonnes pratiques précises : enregistrer quand c'est possible (en notifiant la personne et en consignant la notification, selon les lois locales) ; ne jamais mener un entretien seul (multiparty interviews) ; préserver les droits du sujet, l'informer qu'il peut refuser l'entretien (même si ce refus peut entraîner un licenciement) et, si la loi ou le contrat l'exige, lui permettre d'être accompagné. Piège d'examen : un write-blocker garantit l'intégrité (donc l'admissibility), pas la confidentialité ; et la chain of custody se brise dès qu'un maillon de traçabilité manque, rendant la preuve attaquable.

1.5 Le cycle forensique NIST et la forensic readiness

Une fois l'investigation lancée, elle se déroule en quatre phases, conformes au modèle simplifié du NIST (SP 800-86, Guide to Integrating Forensic Techniques into Incident Response), illustrées en Figure 7.11. Collection : la scène est sécurisée ; les données liées à l'événement sont identifiées, étiquetées, enregistrées et collectées, en préservant leur intégrité. Examination : les données sont soumises à des outils et techniques forensiques pour identifier et extraire l'information pertinente tout en protégeant son intégrité. Analysis : les résultats de l'examen sont inspectés pour obtenir l'information qui répond aux questions ayant déclenché l'investigation. Reporting : on rapporte les résultats, en décrivant les actions menées, en déterminant les actions complémentaires nécessaires et en recommandant des améliorations du processus forensique.

Cette conduite repose sur plusieurs prérequis organisationnels. L'organisation doit disposer d'un programme forensique structuré et doté de ressources, avec le soutien et l'autorité nécessaires. Les personnes ayant des responsabilités forensiques doivent être désignées et formées en amont de l'incident, avec les bons outils. Les pratiques doivent se conformer au système juridique de la juridiction concernée. Enfin, les processus métier doivent être structurés avant l'incident pour soutenir l'analyse forensique : c'est la forensic readiness.

La collecte exige des outils spécialisés (copies bit-level de disques, capture de l'état système, copie des journaux) qui doivent être maintenus et reconnus comme méthodes valides par le système juridique. La virtualisation et le cloud compliquent l'identification et la collecte, imposant souvent de coordonner avec un fournisseur. Piège d'examen : l'ordre NIST est Collection -> Examination -> Analysis -> Reporting ; ne confondez pas examination (extraire l'information) et analysis (l'interpréter au regard des questions de l'enquête).

1.6 Standards forensiques ISO et recours aux professionnels certifiés

Le modèle simplifié du NIST est cohérent avec une famille de standards ISO qui couvre le cycle de vie de la preuve numérique, illustrée en Figure 7.10. ISO/IEC 27037 porte sur l'identification, la collecte, l'acquisition et la préservation des preuves numériques : c'est la norme de référence sur le terrain de collecte. ISO/IEC 27041 traite de l'assurance et de la garantie d'adéquation des méthodes d'investigation. ISO/IEC 27042 porte sur l'analyse et l'interprétation des preuves numériques. ISO/IEC 27043 décrit les principes et processus généraux d'investigation des incidents. ISO/IEC 27050, enfin, encadre l'eDiscovery (gestion de l'ESI à produire). Des standards nationaux existent aussi, influencés par les règles de preuve et systèmes juridiques propres à chaque juridiction.

La plupart des organisations n'ont pas de professionnels forensiques formés à demeure : c'est une discipline très spécifique, exigeant formation et expérience, pour une activité rare dans la plupart des métiers. Face à un besoin de forensique, la tentation est de confier la tâche à un membre de l'équipe sécurité ou de l'IT : ce n'est pas recommandé. Mieux vaut recourir à un contractant externe certifié - et licencié si nécessaire.

Dans certaines juridictions (par exemple les États du Texas et du Michigan aux États-Unis), l'analyse forensique ne peut être réalisée comme service rémunéré que si l'analyste est licencié par l'État, au titre de la profession de private investigator. Il faut donc intégrer toutes les lois applicables dans la politique de collecte, d'analyse et de présentation des preuves. Rappel des premiers intervenants : en cas d'incendie, d'intervention policière ou médicale, les first responders ont des priorités supérieures (la safety of human life) qui peuvent les amener à perturber la scène ; et beaucoup d'anomalies sont d'abord traitées par le help desk, non comme une scène de crime potentielle. Piège d'examen : externaliser vers un professionnel certifié/licencié n'est pas un luxe, c'est ce qui sécurise l'admissibility et respecte les contraintes juridiques locales.

2.1 Pourquoi journaliser : events, precursors, indicators et IoC

La journalisation n'est pas une formalité de conformité : c'est la mémoire de l'organisation. Sans logs, impossible de détecter une attaque en cours, de reconstruire la séquence d'un incident, ni de produire les preuves recevables d'une enquête forensic. Les signaux capturés par les systèmes, applications et équipements réseau permettent de reconstituer un enchaînement d'événements pour le troubleshooting, la recovery et l'investigation légale post-incident. C'est aussi la base de l'accountability vue au Domaine 1 : sans trace, aucune action n'est imputable.

Tout part de l'event, c'est-à-dire tout fait observable dans un système. Les events (ou les signaux qu'ils produisent) se classent ensuite en deux familles. Un precursor est un signal suggérant un possible changement de conditions, interne ou externe, susceptible de modifier le threat landscape : une montée de tensions sociales, des griefs d'employés ou de clients devenant viraux sur les réseaux sociaux. Les precursors servent à ajuster en quasi temps réel les seuils d'alarme et la sensibilité des capteurs, voire à durcir le niveau de challenge exigé lors de l'authentification. Un indicator, lui, suggère qu'une action non autorisée est sur le point de se produire, est en cours, ou a déjà eu lieu.

Le cas le plus critique est l'indicator of compromise (IoC) : un signal qu'une intrusion, un malware ou un ensemble d'événements hostiles prédéfinis se produit ou s'est produit. Exemples : une tentative de contournement d'une allowed/blocked list (signe d'installation de malware), ou des connexions depuis des IP ou des régions où aucun utilisateur authentifié ne devrait se trouver. Les IoC doivent être traités en priorité immédiate par les humains du SOC. Piège d'examen : un precursor anticipe un changement de contexte, un indicator signale une activité non autorisée, et un IoC est un indicator de haute confiance prouvant qu'une compromission est en cours ou avérée.

Tout journaliser sans filtre noie l'analyste sous le bruit. Le clipping level est le seuil au-dessous duquel des evenements repetitifs et benins ne declenchent pas d'alerte : par exemple, tolerer trois echecs d'authentification avant de signaler le quatrieme. Bien regle, il reduit les faux positifs et fait ressortir les anomalies reelles ; mal regle, il masque une attaque lente (low and slow) sous le seuil. Le clipping level se definit a partir d'une baseline d'activite normale et s'ajuste avec l'experience.

2.2 Le cycle de log management : NIST SP 800-92 et ISO 27001 A.12.4

Tout framework de sécurité traite la journalisation d'une manière ou d'une autre. Deux références dominent l'examen. NIST SP 800-92, Guide to Computer Security Log Management, décrit une pratique de log management largement applicable à tout système d'information. ISO 27001 aborde le sujet dans son Annexe A, contrôle A.12.4 Logging and Monitoring. Connaître ces deux ancrages permet de répondre aux questions qui demandent la source normative d'une bonne pratique de journalisation.

Un programme de log management bien structuré couvre un cycle de vie complet : conformité et standards de logging ; politiques de logging à travers le cycle de vie des systèmes et de l'information ; infrastructure de logging ; génération, collecte et normalisation des logs ; protection des logs de leur création à leur disposition (archivage ou destruction défendable) ; enfin revue, analytique et reporting. Chaque étape a sa logique de sécurité : la normalisation rend comparables des formats hétérogènes, la protection garantit l'intégrité et la non-altération des preuves, l'archivage et la destruction défendable répondent aux exigences de rétention légale.

La plupart des indicators et certains precursors peuvent être capturés et journalisés par le matériel, les OS, les applications et les équipements de gestion réseau. Mais accumuler des logs ne suffit pas : sans collecte centralisée, normalisation et revue, le volume noie l'analyste. C'est précisément le rôle d'un SIEM (Security Information and Event Management), qui agrège, normalise, corrèle et stocke ces logs - sujet d'un module ultérieur. Piège d'examen : la protection des logs « de la création à la disposition » inclut la destruction défendable (defensible destruction), pas seulement l'archivage ; et NIST SP 800-92 est LE guide dédié au log management, à ne pas confondre avec SP 800-137 (continuous monitoring).

2.3 L'intrusion : CIANA+PS, zero trust, insiders et outsiders

Une entrée non autorisée dans l'environnement d'une organisation, en particulier dans ses systèmes d'information, peut affecter tous les éléments de la triade CIA, ou du jeu élargi CIANA+PS (Confidentiality, Integrity, Availability, Nonrepudiation, Authenticity + Privacy, Safety). L'intrusion n'est donc pas qu'une affaire de confidentialité : un attaquant qui pousse des applications en fail state pour en prendre le contrôle attaque aussi l'availability. L'examen attend que vous reliiez une intrusion donnée au bon attribut compromis, parfois plusieurs à la fois.

Traditionnellement, « intrusion » désignait l'accès non autorisé d'attaquants externes, par opposition aux menaces internes. Cette vision est aujourd'hui jugée naïve au regard de la croissance de l'insider threat. À mesure que les systèmes se complexifient et adoptent les principes d'une zero trust architecture, l'intrusion doit être redéfinie comme tout mouvement ou toute tentative non authentifiée et non autorisée d'entrer dans une zone, un système, un sous-système, un domaine ou un sous-domaine contrôlé, par un user (humain ou non humain) ou un subject au sens du contrôle d'accès.

Certains tenants du zero trust soutiennent que les mots « insider » et « outsider » détournent l'attention des vrais enjeux : la bonne implémentation du contrôle d'accès. Dans une organisation cloisonnée par des ethical walls séparant des zones sensibles, un Subject 1 autorisé pour une zone mais pas pour les autres est à la fois « insider » de l'organisation et « outsider » de ces autres zones. En termes d'IAM, les étiquettes insider/outsider ne portent aucun sens : seul compte l'état authentifié et autorisé du subject vis-à-vis de la ressource. Piège d'examen : sous zero trust, on ne raisonne pas « interne vs externe » mais « authentifié et autorisé, ou non » pour chaque tentative d'accès, indépendamment de la position réseau.

2.4 IDS vs IPS et leur placement (Figure 7.1)

Deux classes conceptuelles de mécanismes anti-intrusion existent. Un IDS (intrusion detection system) surveille l'environnement et reconnaît automatiquement les tentatives malveillantes d'accès non autorisé, puis alerte un humain (souvent au SOC ou à l'IT) pour analyse et suite à donner : il détecte mais n'agit pas. Un IPS (intrusion prevention system) surveille de même mais agit automatiquement dès qu'il reconnaît une tentative malveillante, et notifie ensuite qu'une action a été prise. La plupart des solutions modernes peuvent fonctionner en mode IDS ou IPS, l'organisation choisissant le comportement optimal. La distinction d'examen est nette : IDS = détecter et alerter ; IPS = détecter et bloquer.

Le placement se décline en trois familles, illustrées par la Figure 7.1. Le perimeter placement positionne le capteur en bordure du réseau, dans la DMZ, pour inspecter le trafic entrant et sortant ; selon la technologie, il travaille avec les gateways ou en tient lieu. Le host-based installe des agents HIDS/HIPS sur les endpoints pour détecter le trafic suspect entre hôtes : c'est une couche de defense in depth si l'attaquant a franchi le périmètre, et cela peut aussi révéler des menaces internes. Le network-based place des éléments NIDS/NIPS en divers points du réseau pour surveiller le trafic interne et repérer l'activité malveillante latérale.

L'organisation n'est pas limitée à un seul placement : combiner plusieurs emplacements est recommandé, ce que montre la Figure 7.1 avec NIPS en DMZ (north-south) et NIDS sur les segments LAN internes (east-west). Pièges d'examen : un IPS mal réglé peut bloquer une transaction légitime (perte de disponibilité), là où un IDS au pire génère une alerte à trier ; et le host-based protège un hôte précis, tandis que le network-based surveille un segment - on les combine, on ne les oppose pas.

2.5 Méthodes de détection, threat hunting, MITRE ATT&CK et trade-offs

Un IDS/IPS détecte l'activité malveillante de plusieurs façons. La deviation apprend une baseline d'activité normale pour l'organisation, puis traite tout écart comme suspect. La signature reconnaît des patterns d'attaque connus dans le trafic et l'activité. Le pattern matching scanne le trafic à la recherche de motifs de valeurs prédéfinis (fragments de noms, de mots, combinaisons ou proximités, fréquences d'occurrence, watermarks) pouvant trahir une fuite de données sensibles, qu'elle soit east-west (latérale) ou north-south (vers ou depuis l'extérieur). L'heuristic pousse plus loin : des algorithmes de machine learning enrichissent en continu la connaissance de l'environnement, forme avancée de l'analyse par déviation. Piège classique : la signature ne détecte que le connu (faible contre une menace zero-day) ; la deviation/heuristic peut détecter l'inconnu mais au prix de faux positifs.

La détection moderne se prolonge en threat hunting proactif, devenu une mission à part entière avec l'essor du Wi-Fi nouvelle génération, de l'IoT et du edge/fog computing. Le threat modeling construit des patterns ou typologies décrivant le comportement des threat actors et leurs actions ; nombre de ces typologies sont publiées par MITRE, notamment via le framework ATT&CK (attack.mitre.org). Ces typologies alimentent l'EDR (endpoint detection and response) et le XDR (extended detection and response), qui couvrent une portée temporelle plus large que les HIDS/NIDS classiques : leurs case files peuvent s'étendre sur des mois ou des années, et leurs modèles ML s'appuient sur l'expérience de toute la communauté cyber, filtrable selon le contexte propre de l'organisation. EDR et XDR partagent beaucoup avec le user and entity behavior modeling (UEBA).

Tout système impose des trade-offs. Maintenance : les systèmes par signature exigent des mises à jour régulières des signatures, ceux par baseline une mise à jour à chaque évolution du référentiel. Overhead : tout déploiement pèse sur la productivité, la capacité et la performance, d'où le choix de protéger en priorité les actifs de grande valeur. False positives : chaque réponse a un coût (perte de fonctionnalité ou effort de traitement), à mettre en regard du bénéfice de risque évité. Agility : les attaquants apprennent plus vite que les défenseurs, même si le partage communautaire (cas SUNBURST/SolarWinds) peut rééquilibrer. Learning period : tout outil qui doit « apprendre » la norme génère beaucoup de faux positifs au début. Latency : les IDS/IPS ajoutent souvent une latence notable au trafic. Piège d'examen : pondérer le coût des réponses (faux positifs compris) face au bénéfice attendu est une décision de gestion du risque, pas un réglage purement technique.

3.1 Le SIEM : SEM + SIM, et ses sept fonctions

Une organisation typique fait tourner une multitude de systèmes de détection (firewalls, IDS, IPS, hôtes Windows et UNIX) répartis dans les segments réseau et sur les hôtes critiques. Le nombre et la diversité de ces sources rendent le travail de surveillance ingérable à la main. Le SIEM (Security Information and Event Management) répond à ce problème en centralisant la donnée de sécurité dans une interface unique. Le terme SIEM est en réalité un descripteur marketing qui fusionne deux familles d'outils antérieures : le SIM (Security Information Management), orienté collecte et analyse a posteriori des logs, et le SEM (Security Event Management), orienté détection et réponse aux incidents en temps réel. Comprendre cette filiation explique pourquoi un SIEM fait à la fois de l'archivage historique et de l'alerte temps réel.

Les fonctions communes d'un SIEM sont au nombre de sept. Aggregation : il collecte les informations de tout l'environnement (firewalls, IDS/IPS, outils de performance IT, équipements réseau, hôtes/endpoints, anti-malware) dans un dépôt centralisé. Normalization : il harmonise des formats hétérogènes en une représentation standardisée, évitant à l'analyste de répéter des revues de log sur chaque système. Correlation : il assigne mathématiquement poids et probabilité aux activités pour estimer automatiquement qu'un flux de logs constitue une attaque réelle, et si elle touche plusieurs hôtes ou réseaux. Secure storage : il archive de façon sécurisée des logs précieux à la fois pour l'organisation et pour les attaquants.

Les trois dernières fonctions : Analysis (analyses automatisées par scripts et heuristiques), Reporting (restitution historique et courante de l'activité), et Real-time monitoring (surveillance et détection de menaces en temps réel permettant une réaction rapide). La Figure 7.2 montre des serveurs physiques, mais en pratique toutes ces fonctions tournent souvent sur des VMs hébergées en cloud privé on-premises, public ou hybride.

Piège d'examen : ne confondez pas les composants. Le SEM capture les événements temps réel (il peut servir de brique au DLP) ; le SIM gère l'information de log dans la durée. Le SIEM est leur somme, pas un troisième modèle distinct.

3.2 SIEM-as-a-service : répartition des responsabilités

Comme pour les modèles de service cloud, le SIEM en tant que service (qui n'a pas encore d'acronyme universellement reconnu) confronte l'organisation à un ensemble total de responsabilités et de fonctions à assurer, mais avec différentes façons de répartir ces responsabilités entre l'interne et un prestataire tiers. La chaîne défensive complète suit les mêmes étapes que n'importe quel système IT : identification et analyse des besoins, build/buy/rent, déploiement et exploitation. Le curseur de répartition peut se positionner à plusieurs endroits du spectre.

Self-hosted, self-managed : l'organisation fait tout elle-même, ce qui exige un éventail intimidant de compétences clés à maintenir en interne. Cloud SIEM, self-manage : un MSSP (Managed Security Services Provider) hébergé en cloud gère la couche opérationnelle intermédiaire (collecte et agrégation des données SIEM) ; l'organisation conserve le placement et l'exploitation des capteurs de détection, puis la corrélation et les actions de réponse. La gestion globale de la chaîne menace-vulnérabilité-réponse reste chez l'organisation.

Hybrid self-hosted : l'organisation choisit, installe et maintient les systèmes SIEM, capteurs et matériels ; le MSSP partage avec elle la collecte, l'agrégation et la corrélation, en partenaire du processus global. SIEM as a Service : le prestataire prend en charge toutes les tâches jusqu'au point où l'organisation répond aux données SIEM ou les exploite dans sa gestion d'incident et ses autres processus de sécurité.

Piège d'examen : plus on délègue, moins on a besoin de compétences internes, mais la responsabilité finale de l'usage des données et de la décision de réponse incombe presque toujours à l'organisation, sauf dans le modèle SIEMaaS le plus complet. C'est une déclinaison directe du modèle de responsabilité partagée du cloud appliquée à la sécurité.

3.3 SOAR : orchestration, automatisation et réponse

Beaucoup d'incidents ont des causes connues et des solutions bien définies. Automatiser ces réponses allège la charge des équipes de réponse aux incidents et accélère le recovery. Le SOAR (Security Orchestration, Automation, and Response) est comparable, à certains égards, au CI/CD : les deux s'appuient massivement sur les données de processus détaillées générées par les nombreux outils de leur domaine, et les deux apportent un degré supérieur d'automatisation et d'intégration. Le CI/CD le fait pour l'intégration, le test et la livraison des unités logicielles ; le SOAR rend un service analogue aux professionnels de sécurité en rassemblant toutes les données de monitoring et de contrôle et en les intégrant dans des workflows qui automatisent des processus qui exigeraient sinon une coordination humaine.

Le SOAR repose sur trois processus principaux. Security Orchestration : réunir les divers « îlots d'automatisation de sécurité » déjà en place (next-generation firewalls, SIEMs, autres stacks technologiques), souvent fournis par des éditeurs différents, ce qui rend l'orchestration manuelle difficile et chronophage ; des workflows spécifient les séquences de tâches de chaque activité d'orchestration. Security Automation : transformer ces workflows en exécution conditionnellement déclenchée de playbooks ou de runbooks.

La distinction playbook / runbook est un point d'examen classique. Les playbooks sont généralement des séquences linéaires de tâches. Les runbooks contiennent une logique conditionnelle qui contrôle l'exécution de branches et de suites d'activités. Certains systèmes SOAR appliquent même différents degrés de ML au développement, à l'exécution et au suivi de performance des runbooks et des playbooks. Security Response : fournir l'ensemble complet de ces capacités d'orchestration et d'automatisation pour renforcer la réponse aux incidents.

Piège d'examen : playbook = linéaire, runbook = conditionnel (logique de branchement). Et le SOAR n'invente pas la détection : il orchestre et automatise la réponse à partir de données que le SIEM et les autres outils ont déjà produites.

3.4 Continuous monitoring et ISCM (NIST SP 800-137)

Le continuous monitoring, formalisé sous le nom d'Information Security Continuous Monitoring (ISCM) et couplé à l'automatisation, est désormais la norme des opérations d'entreprise. L'ISCM maintient une conscience permanente de la sécurité de l'information, des vulnérabilités et des menaces pour soutenir les décisions de gestion des risques. Il part du principe que les actifs informationnels sont exposés aux risques 24 heures sur 24, 7 jours sur 7, toute l'année (jours fériés et arrêts d'activité inclus), et que l'organisation doit planifier, financer, maintenir et surveiller ses systèmes dans cette perspective.

Le NIST SP 800-137 fournit un cadre en six phases pour mettre en œuvre une stratégie ISCM (Figure 7.3). Le terme ISCM n'est pas employé par l'ISO, mais le concept y est exprimé dans l'ISO/IEC 27004:2016 (Monitoring, Measurement, Analysis and Evaluation) comme « mesure quantitative continue de la pertinence de l'ISMS ». D'autres référentiels - COBIT (Control Objectives for Information and Related Technology) et PCI DSS (Payment Card Industry Data Security Standard) - attendent également une surveillance continue de la performance des contrôles.

La différence avec le passé est subtile mais testable. Auparavant, les frameworks suggéraient que ces phases pouvaient se chevaucher ou que certaines survenaient plus souvent que d'autres. Dans l'ISCM, ces phases sont toutes conduites en continu tout au long de la journée, en se chevauchant, à mesure que des événements font apparaître de nouveaux précurseurs et indicateurs. Les processus métier qui rendent l'ISCM possible incluent des inventaires exhaustifs, l'établissement de métriques de performance pour les contrôles, des processus de réponse aux incidents, et des activités d'amélioration continue des processus. Encore faut-il disposer des outils et de l'infrastructure pour collecter, analyser et reporter sur l'environnement surveillé.

Piège d'examen : ISCM = NIST SP 800-137 (six phases), continu et permanent ; le terme n'est pas ISO, mais ISO 27004, COBIT et PCI DSS portent le même esprit de surveillance continue. Ne reliez pas ISCM à l'ISO directement.

3.5 Egress monitoring et DLP : sortir n'est pas anodin

Selon que le risque provient du trafic entrant ou sortant, des outils différents s'appliquent. L'ingress monitoring surveille et évalue tout le trafic entrant et les tentatives d'accès ; ses outils de logging et d'alerte incluent firewalls, gateways, serveurs d'authentification distante, IDS/IPS, solutions SIEM et anti-malware, qui doivent être maintenus et patchés (signatures, configurations). L'egress monitoring régule la donnée quittant l'environnement IT. Le terme employé est « DLP » - un descripteur marketing sans définition standard, parfois « data leak protection » ou « data loss protection » - utilisé ici comme synonyme d'egress monitoring.

Le DLP compare la donnée qui sort au regard d'un rule set pour décider si l'action est autorisée. Ce rule set peut reposer sur trois mécanismes. Signature : certains types de données suivent des chaînes facilement identifiables (un DLP réglé contre l'egress de cartes bancaires cherche et séquestre toute chaîne de 15 à 20 caractères numériques). Pattern matching : le DLP cherche des motifs, par exemple deux mots commençant chacun par une majuscule pour restreindre l'export de noms propres, ou la fréquence d'un mot dans un document pour bloquer la sortie d'information propriétaire. Labeling : les actifs sensibles sont étiquetés (« copyright », « proprietary », « confidential ») et reconnus par l'outil.

Le DLP se déploie selon trois états des données. Data at rest : agents placés dans les emplacements de stockage (bases, archives). Data in motion : logiciel inspectant le trafic sortant. Data in use : agents installés sur les endpoints, crucial en BYOD et en cloud où l'utilisateur traite la donnée de l'organisation sur ses propres appareils. L'effort global de protection inclut data discovery/classification, monitoring (email et pièces jointes, copie sur média portable, FTP, publication web, applications/API) et enforcement, calibré selon l'appétit risque/bénéfice : training (rappel de politique), attribution (l'utilisateur confirme son intention et accepte la responsabilité), ou stringency/prevention (blocage, verrouillage du compte, alerte au management).

Piège d'examen : DLP = egress (sortie), pas ingress. Les fonctions que le DLP sert (compliance, security, training/awareness, due diligence, asset management) ne sont pas ses états (at rest / in motion / in use) ni ses mécanismes de règle (signature / pattern / labeling). Un défi actuel : déployer DLP et ISCM dans une zero trust architecture, pas seulement au périmètre.

3.6 Threat intelligence, UEBA et limites du monitoring

La threat intelligence est le processus structuré d'identification des menaces de l'organisation, à partir de sources externes et internes. La threat intelligence externe inclut la recherche open-source, le threat modeling et l'information fournie par des tiers : éditeurs, entités gouvernementales, ou ISAC (Information Sharing and Analysis Centers) et organisations similaires ; elle révèle des menaces déjà identifiées ailleurs. La threat intelligence interne résulte de la surveillance des systèmes et activités de l'environnement : logs système/événement/application, reporting d'incidents, résultats d'investigations forensiques, CMDB et inventaires (qui repèrent des cibles attrayantes), et l'environnement IAM (privilèges élevés, activité inhabituelle). Les grandes organisations structurent cela en un intelligence cycle ; l'exemple de référence est le cycle de renseignement du FBI (Figure 7.4), qui organise la collecte, le raffinement et la diffusion.

L'UEBA (User and Entity Behavior Analytics) ajoute le « e » d'entity (Gartner, 2017) à l'analyse comportementale historiquement centrée utilisateur. La raison : un attaquant sophistiqué utilise plusieurs identifiants utilisateurs volés en se déplaçant latéralement, mais souvent depuis une poignée d'identités au niveau device (adresse MAC ou IP). L'UEBA s'appuie sur le ML et l'IA et comporte trois composants : use cases, analytics et data (Figure 7.5, le « policier » et la « loupe » jouant l'analytics et l'intervention). Il construit un template de comportement normal par observation dans le temps, peuplé de use cases représentant des typologies d'attaque connues (malicious insider, identité compromise, zero-day) - le framework MITRE ATT&CK fournit beaucoup de ces use cases pour entraîner l'UEBA.

L'enforcement de l'UEBA se règle entre strict (plus de false positives, gêne le travail légitime) et loose, main légère sur le « kill switch » (plus de false negatives, peut laisser passer un intrus). L'UEBA s'appuie sur les données du logging et du SIEM et est souvent une fonction analytique de l'environnement SIEM : la distinction paraît floue car les deux exploitent les mêmes données. Ils sont en fait complémentaires - le SIEM assure réponse aux incidents et automatisation, l'UEBA se concentre sur l'analyse de gros volumes ; l'activité anormale détectée par l'UEBA est passée au SIEM pour action. Certains analystes estiment que SIEM et UEBA convergent au point de rendre la distinction caduque.

Enfin, le monitoring n'est jamais parfait. Les attaquants déjouent la corrélation en manipulant les horloges système ou en supprimant les logs, ou exécutent leurs attaques lentement pour ne pas franchir les seuils d'alerte. Les environnements de logging legacy ne chiffraient ni n'authentifiaient le trafic de log, vulnérable à un tampering indétectable. Le cloud pose des défis propres : forte virtualisation, dépendance aux API et à la bonne volonté du CSP de partager les logs, coût prohibitif d'extraction des logs. L'exemple le plus frappant est SolarWinds / SUNBURST : l'attaquant opérait dans des environnements surveillés par l'IDS Einstein 2 du DHS sans déclencher d'alerte, en retardant l'initialisation du payload, en s'appuyant sur des systèmes de confiance et des certificats numériques suggérant la légitimité. La leçon : automatisation, IA et collecte massive ne suffisent pas ; il faut du personnel formé pour relier les événements à leur sens pour le risque.

4.1 Configuration Items, change set et CMDB

La configuration management est la discipline qui établit et maintient l'état connu et approuvé d'un système. Son unité élémentaire est le Configuration Item (CI) : tout composant nommé, possédé et géré par le processus de change management. Un CI peut être un serveur, un paquet logiciel, un fichier de configuration, un script de déploiement, du mobile code ou un contenu exécutable. Le manuel insiste : la change management ne concerne pas que le logiciel ; matériel, firmware, données, wetware (la connaissance tacite des humains) et connaissance explicite (procédures, formations, supports) doivent tous être évalués pour l'impact d'un changement et gérés ensemble comme CIs d'un même change package.

Un change set (ou change package) regroupe l'ensemble des CIs affectés par un changement donné, afin de les approuver et de les déployer de manière cohérente. Cette notion de regroupement est indépendante de la méthodologie de développement utilisée : qu'on travaille en cascade ou en agile, on bundle les changements en paquets pour les besoins de développement, de test, de déploiement et de release planning.

La Configuration Management Database (CMDB) est le référentiel qui recense les CIs, leurs attributs et leurs relations. Les outils de provisioning y inscrivent automatiquement la création ou le déploiement d'un système, en précisant le script approuvé utilisé. La CMDB est donc la source de vérité qui relie configuration et change management : sans elle, impossible de savoir quel est l'état approuvé ni ce qui a réellement changé.

Piège d'examen : un CI n'est pas qu'un objet technique. Une procédure ou un savoir-faire humain (wetware) peut être un CI ; l'oublier conduit à sous-estimer l'impact d'un changement organisationnel.

4.2 Les cinq types de baselines

Une baseline est un inventaire total et de référence des composants d'un système à un instant donné. Elle sert de point de comparaison : tout écart par rapport à la baseline est un changement à expliquer. Le manuel distingue cinq types de baselines, et l'examen attend que vous sachiez les énumérer et les différencier.

La enumerated baseline est l'inventaire exhaustif de tous les composants d'un système (le « total inventory »). La configuration baseline fige l'état de configuration approuvé : valeurs de paramètres, services activés, réglages de durcissement. La build ou deployment baseline est l'image de référence à partir de laquelle on construit et déploie une instance, souvent reçue d'une supply chain puis validée. La modification, update ou patch baseline capture l'état après application de correctifs ou de mises à jour, et sert à fabriquer un deployment package adapté à l'environnement local. Enfin, la security baseline définit l'ensemble minimal de contrôles de sécurité, dicté par une exigence de conformité ou défini en interne par l'organisation.

Le security baselining mérite une attention particulière : il fixe le minimum de contrôles que tout système doit satisfaire. Le manuel rappelle de rester focalisé sur la façon dont les autorités de conformité ou les partenaires contractuels perçoivent les menaces et la réponse minimale attendue, plutôt que de se laisser dicter par le seul paysage de menaces externe.

Piège d'examen : la question 7.3 Check Your Understanding porte exactement sur cette énumération. Ne confondez pas la build/deployment baseline (image de construction) avec la modification/patch baseline (état après correctifs) ; et rappelez-vous que la security baseline est un sous-ensemble orienté contrôles, pas l'inventaire complet.

4.3 Automatisation : CIS, SCAP, gold images et IaC/CI-CD

Gérer manuellement une security baseline sur un seul système est simple, mais la complexité explose avec le nombre de systèmes, la diversité des besoins métier et des exigences de conformité, et la multiplication des CIs. Déterminer le bon span of control de la baseline (de un à des milliers de systèmes) devient un enjeu de gestion à part entière. Cette complexité a conduit les organisations à automatiser le baselining.

Des catalogues et outils de référence existent. Les CIS benchmarks fournissent des configurations durcies par technologie ; le manuel cite aussi le Microsoft Security Compliance Toolkit, le NIST macOS security framework, le Secure Host Baseline du gouvernement américain et l'IT-Grundschutz du BSI allemand. Le Security Content Automation Protocol (SCAP) standardise l'expression et l'évaluation de la conformité : des outils vendor évaluent un système au regard de la baseline, ingèrent les changements de configuration via SCAP, et peuvent restreindre l'exploitation du système tant que la baseline n'est pas satisfaite, tout en fournissant un reporting de conformité.

Dans le cloud, l'approche a évolué. On s'appuyait sur des gold images, configurées proprement puis copiées à la demande. Mais l'image sprawl - la prolifération incontrôlée d'images divergentes - a rendu cette méthode ingérable en entreprise. Désormais, le provisioning et la promotion des changements de configuration en production via Infrastructure as Code (IaC) et CI/CD garantissent un déploiement cohérent des baselines. Les scripts ou « recipes » sont eux-mêmes suivis comme CIs et approuvés pour déploiement.

Piège d'examen : les gold images ne sont pas la « bonne réponse moderne ». Le manuel les présente comme dépassées par l'image sprawl ; la réponse attendue en environnement cloud est le provisioning par IaC/CI-CD, où les recipes sont des CIs versionnés et approuvés.

4.4 Change Management Board, span of control et Figure 7.6

La plupart des organisations disposent d'une hiérarchie d'autorités d'approbation, calibrée selon le niveau de risque que présente un changement. Le Change Management Board (CMB), aussi appelé Configuration Control Board (CCB), supervise de façon centralisée les activités liées au changement : il structure l'engagement des parties prenantes, formalise l'approbation, et garantit que les changements sont correctement dotés en ressources et implémentés. Les responsabilités et le span of control du CMB varient fortement d'une organisation à l'autre.

Le périmètre d'intérêt du CMB peut englober tous les aspects de la change management qui concernent l'équipe sécurité. La Figure 7.6 illustre que ces activités - provisioning, baselining, patch, configuration et vulnerability management - se chevauchent. Certaines organisations ne distinguent pas ces activités, d'autres les cloisonnent en silos distincts ; le CMB les coordonne dans le contexte des pratiques de change management plus larges. Le CMB doit aussi viser l'amélioration continue des processus et des outils qu'il contrôle, l'automatisation fournissant les métriques pour mesurer les gains.

Un indicateur d'efficacité clé est le niveau de déviation du parc de production par rapport aux baselines, ainsi que le nombre d'exceptions accordées : un nombre croissant d'exceptions signale que les baselines ne répondent plus aux besoins métier et doivent être réévaluées. Enfin, le manuel est catégorique : la senior management reste la clé. Si la direction s'exempte elle-même de la conformité ou refuse d'imposer les standards, le message est clair - la change management ne compte pas. À l'inverse, son exemplarité garantit l'application cohérente des contrôles.

Piège d'examen : le rôle décisif de la senior management n'est pas symbolique. L'examen valorise la réponse « tone at the top » : sans exemplarité de la direction, aucun outil ni CMB ne suffit.

4.5 Change management vs change control, regression testing, standards et niveaux ITIL

La change management est la discipline qui fait passer du current state au future state. Elle comprend trois grandes activités : décider de changer, faire le changement, et confirmer qu'il a été correctement accompli. La change management se concentre sur la décision de changer et aboutit aux approbations données aux équipes de support, développeurs et utilisateurs pour démarrer les modifications. La change control désigne, elle, les processus comptables détaillés qui identifient chaque composant affecté puis vérifient que les actions appropriées ont bien été menées. Le regression testing confirme que le comportement du système n'a été altéré que par le changement approuvé, sans comportement anormal supplémentaire.

Certaines cultures séparent change management et change control en deux processus distincts, d'autres non. De même, le caractère formel ou non du regression testing - intégré au processus ou « laissé à l'utilisateur final » - dépend des pratiques locales, sauf exigence contractuelle ou de conformité explicite. Point essentiel : la change management ne concerne pas que les bug fixes ou la fermeture de vulnérabilités. Ajouter une fonctionnalité ou changer l'apparence d'un affichage sont aussi des changements ; tout changement doit être managé.

Plusieurs standards encadrent la pratique. NIST SP 800-128 guide la configuration management orientée sécurité ; ISO 27001 Annexe A 12.1.2 fait de la change management un contrôle nécessaire pour les changements affectant la sécurité de l'information ; PRINCE2 et le PMBOK du PMI l'abordent sous l'angle de la gestion de projet. Le plus largement adopté côté IT est ITIL v4, sous le nom de Change Enablement, qui fournit des lignes directrices larges adaptables à la culture et aux contraintes de chaque organisation.

ITIL distingue trois niveaux de changement selon l'urgence et le risque : les standard changes (relativement peu risqués, suivant des procédures établies, souvent pré-approuvés), les emergency changes (à implémenter immédiatement), et les normal changes (tous les autres). Cette flexibilité reflète que chaque organisation a des processus d'approbation différents selon le risque. Piège d'examen : un standard change n'est pas « un changement ordinaire » - c'est un changement de faible risque, répétable et pré-autorisé. Le « changement ordinaire » est précisément le normal change.

4.6 Le cycle de la RFC au rollback : phases majeures et release/deployment

Toutes les pratiques majeures de change management traitent un noyau commun d'activités qui démarre par une Request for Change (RFC) et progresse à travers les étapes de développement, de test et de release jusqu'à la mise à disposition des utilisateurs. Chaque étape est soumise à une décision formalisée et produit des enregistrements documentant ses résultats.

La Change Initiation produit la RFC, qui peut naître de suggestions d'utilisateurs, de tickets help desk ou d'autres entrées. Elle couvre l'identification des besoins de changement, l'évaluation des risques, la priorisation et la documentation de la RFC. La Change Review and Approval évalue la complétude des RFCs, les affecte au bon processus d'autorisation selon le risque, organise les revues de parties prenantes et l'allocation des ressources, puis prononce approbations ou rejets - tous documentés. L'Implementation and Evaluation planifie et teste le changement, vérifie les procédures de rollback, implémente, évalue le bon fonctionnement et documente le changement en production. Le rollback plan définit l'autorité de retour arrière, qui peut être immédiat ou planifié comme un changement ultérieur si le monitoring révèle des performances insuffisantes. La Release and Deployment Planning and Control gère les mouvements entre environnements (prototypage, développement, intégration, tests d'acceptation, security assessment).

Trois termes sont régulièrement confondus à l'examen. Le deployment est le déplacement contrôlé, inventorié et géré d'un système entre environnements (par exemple de l'intégration développeur vers le test système). La delivery est le déploiement dans l'environnement de l'utilisateur final pour son usage. La release est le mouvement d'un système ou change package vers la production pour un usage immédiat par les utilisateurs finaux.

Piège d'examen : ne réduisez pas la vérification du rollback à une formalité. Vérifier les procédures de rollback fait partie de l'Implementation and Evaluation, avant l'implémentation. Et retenez la réponse de la 7.9 Check Your Understanding : toutes les phases du processus exigent une documentation exacte et complète, pas seulement l'initiation.

5.1 Defense in depth comme cadre des modèles de contrôle d'accès

Aucun modèle de contrôle d'accès n'est suffisant à lui seul. La defense in depth (défense par couches) consiste à superposer plusieurs modèles et mécanismes - RBAC, MAC, DAC, MFA, zero trust - de sorte qu'une défaillance d'une couche soit rattrapée par la suivante. Appliquée au contrôle d'accès, elle intègre des politiques administratives, des mécanismes techniques (ACL, authentification, journalisation) et des barrières physiques en un dispositif cohérent.

La Figure 7.7 du manuel illustre cette intégration : les principes fondamentaux (least privilege, need-to-know, separation of duties) y sont implémentés à travers les différentes couches plutôt que par un seul contrôle. Par exemple, le besoin d'en connaître se traduit administrativement par une NDA, techniquement par du RBAC sur un domaine virtuel isolé, et physiquement par un local sécurisé.

Le message clé pour les opérations de sécurité : on ne choisit pas UN principe contre les autres, on les combine en couches. Piège d'examen : croire qu'un mécanisme unique (par exemple le seul RBAC) suffit à appliquer le least privilege ET le need-to-know. C'est la combinaison de couches qui réalise réellement la défense en profondeur.

5.2 Least privilege, need-to-know et two-person integrity

Le least privilege (moindre privilège) impose que chaque sujet ne reçoive que les droits strictement nécessaires à sa fonction, ni plus ni moins. Exemple type : un employé chargé de saisir les factures fournisseurs (invoice clerk) doit pouvoir créer une facture, mais pas approuver un paiement ni modifier la liste des fournisseurs. Limiter ses droits réduit la surface d'erreur et de fraude.

Le need-to-know (besoin d'en connaître) est le pendant côté information : un sujet n'accède qu'aux informations dont il a un besoin légitime et démontré pour accomplir sa tâche. La distinction d'examen est cruciale : le least privilege porte sur les actions/permissions (que puis-je faire), le need-to-know porte sur l'information (que puis-je connaître). On peut avoir le privilège de lire un répertoire sans avoir le besoin d'en connaître chaque fichier.

Le need-to-know se met en oeuvre par des dispositifs comme l'ethical wall (muraille de Chine séparant des équipes en conflit d'intérêts), des NDA juridiquement contraignantes, et techniquement par de la virtualisation combinée à du RBAC : pour des clients concurrents servis par la même entreprise, on isole chaque client dans des réseaux, serveurs et données virtuels distincts, l'accès étant restreint par RBAC aux seuls intervenants validés ayant signé la NDA.

La two-person integrity (intégrité à deux personnes) ajoute une exigence : certaines actions ne peuvent être accomplies sans qu'au moins deux individus soient impliqués, afin qu'aucun ne puisse agir seul sur un actif critique. Piège d'examen : ne confondez pas least privilege (étendue des droits) et need-to-know (étendue de l'information).

5.3 Separation of duties et les workflows d'approbation

La separation of duties (SoD, séparation des tâches) signifie qu'aucune personne ne peut accomplir seule un processus sensible de bout en bout. Son but est de réduire les chances de fraude en exigeant la collusion d'au moins deux acteurs. L'exemple classique est l'achat bifurqué (bifurcated purchasing) : le responsable des achats signe le bon de commande (purchase order, PO) mais ne peut pas émettre de chèque ; le comptable peut émettre le chèque, mais seulement sur la base d'un PO signé par un responsable.

Des seuils renforcent le dispositif : les paiements dépassant des limites prédéfinies, ou des transmissions de fonds inhabituelles, exigent l'approbation d'un responsable plus senior. Cette SoD, appliquée par les mécanismes de contrôle d'accès des applications financières et de leurs bases de données, participe à la défense contre les whaling attacks - des attaques de phishing visant à tromper des dirigeants pour qu'ils autorisent de gros virements vers des entités inconnues.

Mettre en place une SoD commence par la conception du workflow et des tâches : on identifie les étapes critiques nécessitant l'approbation d'une deuxième, voire d'une troisième personne. Cela requiert des control flows (l'information remonte vers l'approbateur, qui approuve, rejette ou renvoie l'action vers une autorité supérieure) et des control loops, qui doivent être examinés de près pour s'assurer qu'ils sont correctement conçus. On choisit ensuite le bon assortiment de technologies de contrôle d'accès pour les implémenter. Piège d'examen : la SoD ne prévient pas la fraude par collusion ; c'est la collusion qui la contourne, raison pour laquelle on la complète par job rotation et mandatory vacations.

5.4 Privileged account management (PAM) et just-in-time identity

Les comptes à privilèges (privileged accounts) disposent de permissions supérieures à celles des utilisateurs normaux. Plusieurs classes les utilisent : les systems administrators (responsables des OS, du déploiement applicatif et de la performance), le help desk / support IT (qui doivent voir ou manipuler endpoints, serveurs et plateformes applicatives), les security analysts (qui peuvent exiger un accès rapide à toute l'infrastructure), ainsi que des comptes créés par client ou par projet pour donner à une équipe un contrôle accru sur ses données et applications.

Cette délégation suppose une grande confiance, car un abus de ces privilèges peut nuire à l'organisation. Les mesures de mitigation typiques sont : un logging plus détaillé que pour les comptes ordinaires (dissuasion et contrôle administratif auditables) ; un contrôle d'accès plus strict, avec MFA pour tous et une authentification renforcée avant l'octroi des privilèges ; la just-in-time (JIT) identity, qui restreint l'usage des privilèges aux tâches précises et aux moments où l'utilisateur les exécute ; le traitement des comptes à privilèges comme temporaires (durée limitée à un besoin et à un projet, de quelques jours à quelques mois) ; une vérification de confiance plus poussée (background checks approfondis, NDA plus strictes, politiques d'usage acceptable renforcées, acceptation d'enquêtes financières, réévaluations périodiques) ; et un audit accru de l'activité.

Le PAM illustre le granularity-of-controls problem (problème de granularité des contrôles). À un extrême, un paradigme zero trust qui valide chaque action atomique a un coût réel ; à l'autre, une authentification unique au premier sign-on autorisant ensuite toutes les actions est une architecture de total trust, bien trop risquée. Le professionnel de sécurité recommande où placer ce threshold knob (curseur de seuil) lors de la planification, de l'implémentation et de l'usage opérationnel temps réel. Piège d'examen : la JIT identity ne supprime pas les comptes à privilèges, elle limite leur fenêtre d'usage à l'instant et à la tâche.

5.5 Job rotation et mandatory vacations

Le job rotation (rotation des postes) fait changer régulièrement les employés de rôles et de tâches. Cela renforce la sécurité de plusieurs manières : un employé impliqué dans une malversation peut être démasqué lorsque son remplaçant prend le poste après la rotation ; l'organisation n'a pas de single point of failure, car de nombreux agents auront acquis l'expérience opérationnelle de la plupart des processus métier (atout pour la continuité d'activité et la reprise après sinistre) ; et le moral comme la cohésion d'équipe s'améliorent par le partage des compétences, créant un climat où chacun protège les autres et l'organisation.

Les systèmes de contrôle d'accès jouent ici un rôle essentiel. La stratégie de rotation doit décrire clairement comment un individu acquiert et perd des tâches assignées, ainsi que les autorités associées, lors de sa transition d'un rôle à l'autre. Une collaboration entre la human resources management (HRM) et l'IAM (provisioning) reflète ces changements dans les systèmes et les privilèges. L'access accounting et les audits d'usage des comptes vérifient que la passation de tâches a bien été effectuée du point de vue des tentatives d'accès.

Les mandatory vacations (congés obligatoires) visent à réduire la fraude et l'embezzlement (détournement) et à révéler des malversations. Le concept vient du secteur financier : chaque employé doit prendre plusieurs jours consécutifs de congé pendant qu'un collègue couvre ses responsabilités, ce qui accroît les chances de détecter une malversation commise par l'absent. Certaines organisations vont plus loin avec un forced vacation program imposant des congés à des dates précises. L'aspect le plus souvent négligé : il faut suspendre temporairement tout ou partie des privilèges d'accès de l'employé en congé, et placer des seuils d'alarme rehaussés sur l'usage de son identité et des ressources qu'il utilise habituellement. Piège d'examen : si l'accès reste actif pendant le congé, le mécanisme perd son intérêt de détection.

5.6 Dual control et service-level agreements (SLA)

Le dual custody, aussi appelé dual control (double contrôle), offre une architecture de contrôle d'accès plus sûre en exigeant que deux personnes ou plus accomplissent simultanément des actions séparées pour réaliser une action critique. De nombreux systèmes militaires, par exemple, ne peuvent armer et tirer une arme sans deux actions distinctes (tourner une clé, saisir une commande) effectuées par deux personnes physiquement isolées à une ou deux secondes d'intervalle ; les overrides de processus critiques pour la sûreté reposent souvent sur du dual control.

Un autre usage protège des informations très sensibles ou des actifs physiques uniques : on les place dans un local spécialement construit, en exigeant qu'au moins deux personnes y maintiennent une vigilance ou y interviennent conjointement. Ces zones sont appelées no lone zones (zones sans isolé) ; les laboratoires de R&D y recourent souvent. Dans un usage plus courant, les banques chiffrent les données de cartes via des hardware security modules (HSM) : déchiffrer ces informations exige des actions indépendantes de deux administrateurs de sécurité (parfois plus) physiquement présents au HSM. Distinction d'examen : la separation of duties répartit des étapes successives entre plusieurs personnes, tandis que le dual control exige des actions simultanées de plusieurs personnes pour une même action.

Le service-level agreement (SLA) est un accord documenté et juridiquement contraignant entre un fournisseur de service et un ou plusieurs clients. Il définit le niveau de service attendu et les pénalités si ces niveaux ne sont pas atteints. Un SLA peut couvrir diverses métriques : disponibilité (availability), fiabilité (reliability) et temps de réponse (response time). Point clé : avoir un SLA ne garantit pas que le fournisseur le respectera toujours. Le client obtient l'assurance de conformité par des revues, des assessments et du monitoring. Piège d'examen : un SLA est un engagement assorti de pénalités, pas une garantie technique de disponibilité.

6.1 Gestion des médias : inventaire, classification et politiques

Gérer activement les actifs organisationnels commence par un inventaire à jour de ces actifs. On ne protège bien que ce que l'on connaît : sans inventaire fiable des supports (disques, bandes, clés USB, sauvegardes), aucun contrôle de protection ne peut être appliqué de façon exhaustive. Protéger une information de valeur ou sensible en tant qu'actif exige de la défendre contre disclosure, alteration et destruction, quels que soient son emplacement et son format.

La classification de la donnée doit être traitée au plus tôt dans le data life cycle, idéalement au moment où la donnée est collectée ou générée. Classer tard, c'est laisser circuler des données non marquées dont on ignore le niveau de protection requis ; classer tôt, c'est conditionner tout le reste du cycle (marquage, handling, stockage, sanitization). C'est un piège d'examen classique : la bonne réponse à « quand classifier ? » est toujours « le plus tôt possible », à la création.

Lorsqu'elles sont développées, documentées et maintenues, les media protection policies and procedures donnent le ton, fixent une direction et décrivent une suite d'actions pas à pas pour la protection des médias. Ces contrôles doivent adresser plusieurs exigences : marking and labeling, handling, storage et destruction, afin de protéger l'information sensible tout au long de sa vie.

6.2 Marquage, étiquetage et limites de distribution

Les médias contenant de l'information sensible doivent être marqués de façon appropriée. Le marking n'est pas un détail administratif : il informe les subjects (utilisateurs, transporteurs, destinataires) des exigences spécifiques de handling et de protection nécessaires, et, le cas échéant, indique les limites de distribution. Une bande de sauvegarde étiquetée « Confidentiel - usage interne » dit immédiatement à qui la manipule quel niveau de soin appliquer et à qui elle ne doit pas être remise.

Il faut distinguer le marking (l'information de classification rendue visible, lisible par l'humain, sur l'étiquette ou l'emballage) du labeling au sens des métadonnées, mais dans le manuel D7 les deux servent le même but : porter à la connaissance de quiconque manipule le support le traitement requis. Sans marquage, un support sensible se confond avec un support banal et tombe hors du périmètre des contrôles de handling et de distribution.

Le marquage est ainsi le point d'articulation entre la classification (faite en amont) et les contrôles opérationnels qui suivent : il traduit une décision de classification en consigne pratique de manipulation. Piège d'examen : le marquage n'applique pas lui-même la protection, il informe et déclenche les contrôles de handling, de stockage et de distribution appropriés.

6.3 Contrôles de protection : stockage, accès, handling, environnement, transport

La protection physique et opérationnelle des médias repose sur cinq familles de contrôles complémentaires. Le storage consiste à ranger les médias dans des zones verrouillées (locked areas) et, plus généralement, dans des locaux physiquement sécurisés. L'access est restreint selon les rôles : on accorde l'accès selon les principes de need-to-know et on journalise chaque accès (logging), ce qui rend possible l'accountability ultérieure.

Le handling impose de manipuler les médias, lorsque c'est pertinent, avec un niveau de soin qui évite d'exposer le support à des sources de contamination. La protection environnementale (environment) défend le média contre diverses conditions : chaleur (heat), humidité (humidity), liquides, poussière (dust) et fumée (smoke), en tenant aussi compte des menaces d'intempéries extrêmes, inondations (floods), séismes (earthquakes) et incendies (fires). Un coffre ignifuge et climatisé répond directement à ces exigences.

Le transport des médias hors de la zone contrôlée, lorsqu'il a lieu, doit garantir l'accountability : on sait à tout moment qui détient le support, par qui il est passé, et on trace la chaîne de responsabilité. Piège d'examen : ces contrôles ne sont pas alternatifs mais cumulatifs - c'est une application directe de la defense in depth aux supports physiques. Restreindre l'accès ne dispense pas de protéger contre le feu, et vice versa.

6.4 Sanitization, restriction des types de médias et chiffrement

La sanitization peut être requise avant la mise au rebut, en fin de cycle de vie. Elle est particulièrement importante si le média quitte le contrôle de l'organisation ou s'il sera recyclé pour un usage futur. La sanitization doit s'effectuer avec des outils et techniques appropriés, commensurate (proportionnés) à la security category ou à la classification du support. Selon la catégorisation, il peut exister des exigences spécifiques pour reviewing, approving, tracking, documenting et verifying les actions de sanitization et de disposal : un support secret ne se traite pas comme un support public, et chaque étape doit laisser une trace.

Pour des raisons de conformité aux politiques, l'usage de certains types de médias (par exemple les flash drives) peut être restreint ou totalement interdit dans certains environnements ou sur certains systèmes. Ces restrictions s'appliquent par des contrôles techniques (blocage des ports USB, allowlisting de périphériques, DLP), et non par la seule consigne écrite. De même, si la conformité l'exige, l'usage de devices non autorisés et non conformes peut être prohibé.

La donnée sensible peut être exposée à la fois data at rest et data in transit. Les données sensibles reposant sur des backup media, des clés USB, des disques externes peuvent être soumises au chiffrement, par politique interne ou mandat externe. Le chiffrement est un contrôle technique majeur, valable quel que soit l'état de la donnée (au repos ou en transmission) : c'est la réponse transverse qui protège la confidentialité même si le support est volé ou intercepté.

6.5 NIST SP 800-53 Media Protection, 800-88 et data remanence

Le NIST SP 800-53 regroupe les contrôles de protection des médias dans une famille dédiée, Media Protection (MP). Selon le manuel D7, les contrôles liés à la protection des médias incluent : policies and procedures, access, marking, storage, transport, sanitization, use et downgrading. Cette liste est la réponse officielle à la question « Check Your Understanding » 7.5.2 et structure tout ce module : chaque leçon précédente correspond à un ou plusieurs de ces contrôles. Le downgrading (déclasser un support vers un niveau inférieur) et le use (encadrer l'usage autorisé d'un type de média) complètent storage, transport et sanitization déjà vus.

En complément du manuel, le NIST SP 800-88 (Guidelines for Media Sanitization, supplément CBK/cheat) définit une échelle de sanitization à trois niveaux, par sévérité croissante. Clear applique des techniques logiques standard (réécriture, reset) pour empêcher une récupération par des outils simples. Purge applique des techniques plus poussées (cryptographic erase, degaussing pour les supports magnétiques) rendant la récupération infaisable même en laboratoire. Destroy détruit physiquement le support (broyage, incinération, pulvérisation), seule garantie absolue, mais qui interdit toute réutilisation. Le choix monte l'échelle avec la classification et le devenir du support.

La notion sous-jacente est la data remanence (rémanence des données, concept CBK) : les données ne disparaissent pas réellement quand on les « supprime » ou qu'on formate un disque ; des résidus magnétiques ou électroniques subsistent et peuvent être récupérés. Toute la sanitization vise précisément à neutraliser cette rémanence. Piège d'examen : un simple delete ou format ne sanitize pas - il ne supprime que les pointeurs, la donnée reste récupérable jusqu'à un clear, purge ou destroy adapté.

7.1 Event vs incident, standards et obligations de reporting

Un event est un changement d'état d'un système ; il devient un incident dès qu'il existe une possibilité de harm. Cette distinction n'est pas qu'académique : elle conditionne le déclenchement du processus de réponse et, surtout, des obligations légales de notification. Les organisations matures disposent de pratiques établies pour la détection, l'évaluation, l'escalade, la communication, la recovery et l'apprentissage.

Les processus de réponse à incident sont mandatés par de nombreux cadres réglementaires. Le GDPR de l'UE impose des délais stricts pour notifier une violation de données personnelles (PII). Aux États-Unis, la HIPAA Breach Notification Rule encadre la notification des compromissions de données de santé ; au Canada, le PIPEDA (Personal Information Protection and Electronic Documents Act) impose une obligation légale de notification des compromissions. Les opérateurs d'infrastructures critiques sont typiquement tenus par la loi nationale de signaler les cyberincidents aux autorités. Point d'examen majeur : sous le Gramm-Leach-Bliley Act (GLBA), les organismes de services financiers américains doivent désormais signaler à leurs régulateurs toute intrusion cyber de leur infrastructure dans un délai de 36 heures.

Les frameworks de sécurité traitent aussi l'incident response comme un contrôle essentiel. Parmi les standards qui l'imposent : PCI DSS, COBIT, les SOC Trust Services Criteria (SOC 2), la directive NIS 2016/1148 de l'UE et les régulations de la Banque centrale européenne. Piège d'examen : les délais, conséquences et procédures diffèrent selon les juridictions, mais l'obligation légale, elle, est claire pour chacune. Le professionnel ne maîtrise pas seul ces enjeux : il doit engager le legal counsel et les dirigeants.

7.2 Cycles de vie : NIST SP 800-61 et ISO/IEC 27035

Plusieurs référentiels guident la conduite de l'incident management, mais chaque organisation doit adapter son approche à ses obligations de conformité, sa mission, sa structure et sa culture. Les divergences portent surtout sur le nombre d'étapes ; le fond reste cohérent.

NIST SP 800-61 (Computer Security Incident Handling Guide) structure les activités en un cycle à quatre phases (Figure 7.8) : Preparation ; Detection and Analysis ; Containment, Eradication, and Recovery ; Post-Incident Activity. Notez que le cycle est itératif : les enseignements de la dernière phase réalimentent la Preparation, renforçant la posture pour les incidents futurs.

ISO/IEC 27035 (Information Security Incident Management) codifie le processus en cinq phases (Figure 7.9) : Planning and Preparation ; Detection and Reporting ; Assessment and Decision ; Response ; Lessons Learned. La correspondance avec NIST est directe : la phase Response d'ISO recouvre le triptyque Containment/Eradication/Recovery de NIST, et Lessons Learned correspond au Post-Incident Activity. Là où NIST fusionne Detection et Analysis, ISO sépare la Detection/Reporting de l'Assessment/Decision pour insister sur la décision de qualifier un event en incident.

Piège d'examen : si une question demande le standard ISO/IEC définissant la gestion d'incident en cinq phases, c'est ISO 27035. Si elle demande le cycle en quatre phases, c'est NIST SP 800-61. Ne confondez pas non plus ces standards de cycle de vie avec les standards purement forensiques (ISO 27037, 27041, 27042, 27043, 27050) traités au Module 1.

7.3 Culture, risk appetite et le rôle du SOC/CSIRT

Aucune réglementation ne peut effacer le poids de la culture organisationnelle. La personnalité des dirigeants et conseillers, formels ou informels, fixe un ton et une compréhension tacite qui déterminent à la fois comment l'organisation se prépare à la réponse à incident et avec quelle rigueur elle suivra ses propres préparatifs le moment venu. Cette culture établit le contexte des discussions sur la risk tolerance et le risk appetite ; elle peut peser plus que les processus de gouvernance formalisés.

Ce facteur a des effets concrets et parfois néfastes. La crainte de perdre la face, la réputation ou la confiance du marché peut pousser les équipes soit à étouffer une investigation pour reprendre vite l'exploitation, soit à la surchauffer en exigeant des conclusions rapides plutôt qu'exactes et défendables. Les lois, standards et régimes de conformité ne suppriment pas cet élément culturel ; au mieux, ils posent des guide rails pour garder l'organisation sur une trajectoire saine.

Beaucoup d'organisations disposent d'un Security Operations Center (SOC) ; d'autres confient cette fonction aux opérations réseau ou systèmes. Quel que soit son rattachement, son rôle premier est d'aider les dirigeants à prendre des décisions éclairées sur les actions d'urgence. Point d'examen capital : le SOC ne décide pas unilatéralement d'activer un site de secours ou d'arrêter l'exploitation. Il escalade l'événement et le besoin de décision urgente vers les managers responsables désignés - ou vers l'échelon supérieur en leur absence. Le SOC (ou CSIRT) agit en temps réel selon ses procédures, mais remonte toujours le fait d'avoir agi.

7.4 Preparation, Detection et Analysis

Avant tout incident, l'organisation doit disposer d'une politique de réponse bien définie. Cette politique identifie les obligations de conformité, les responsabilités de reporting et les attentes de notification ; elle assigne, dote en ressources et communique les activités. Elle doit surtout préciser comment les incidents sont priorisés, car cela conditionne l'escalade, le partage d'information et l'autorité de décision. La préparation inclut la formation des intervenants, l'acquisition anticipée des logiciels spécialisés (pour que les responders aient l'expérience des outils), des fournitures et des zones de stockage. Chacun doit connaître ses responsabilités pour qu'un event soit correctement évalué et escaladé.

La Detection est l'étape la plus critique : repérer les premiers signes d'une kill chain en action. Il faut traquer alarmes, indicators of compromise (IoC) et même precursors. Les types d'events suspects à surveiller : buffer overflows en entrée (tentatives d'injection SQL), détection d'infection par l'antivirus, noms de fichiers à caractères inhabituels ou non imprimables, équipement sans définitions de malware à jour tentant de se connecter, redémarrage non planifié, host non géré rejoignant le réseau, modification d'un élément sous configuration baseline, échecs de login répétés depuis une IP inconnue, hausse d'e-mails rebondis ou en quarantaine, déviations inhabituelles du trafic réseau. Les IDS/IPS, pare-feux et systèmes de logging détectent ces events, mais doivent être réglés (signatures, seuils) pour minimiser les false positives.

L'Analysis est souvent le point faible : la détection capte les events à temps, mais la qualification en incident traîne faute d'analyse rapide. L'event correlation est ici décisif et repose sur de bonnes pratiques de log et configuration management : synchroniser le temps (time sync), normaliser les informations DNS, inventorier les adresses MAC acceptables. Ces données permettent d'associer un event à un autre. Une fois l'event qualifié d'incident, il faut le prioriser selon son impact et l'urgence, puis le documenter en reporting standardisé et le suivre jusqu'à résolution.

7.5 Response, Mitigation, Recovery et root cause analysis

NIST 800-61 nomme ces activités Containment, Eradication and Recovery ; ISO 27035 les regroupe sous Response. Le cœur est le même : isoler les dégâts, éliminer la cause, restaurer les systèmes. Attention : vos actions pendant cette phase peuvent renforcer ou anéantir la capacité légale de l'organisation à répondre, car les recours juridiques dépendent de preuves préservées. Documentation, communication, décisions d'escalade et evidence preservation s'appliquent partout.

La Mitigation combine deux tâches logiquement distinctes mais souvent menées ensemble : containment et eradication. Le containment, c'est la quarantine : isoler les éléments suspects pour empêcher la propagation et examiner plus sûrement le causal agent. Tactiques typiques : déconnecter logiquement ou physiquement des systèmes/segments, couper des serveurs clés (DNS, DHCP, contrôle d'accès), couper les liens vers l'ISP, désactiver le Wi-Fi et les accès distants, fermer des connexions vers des services connus ou tous les services externes, couper extranets/VPN, suspendre l'accès fédéré des partenaires, désactiver des utilisateurs ou applications internes. Les mitigation sets de MITRE (enterprise et mobile) sont utiles avant, pendant ou après pour refermer une faille. L'eradication identifie et retire chaque instance du causal agent : pour un malware, nettoyer toute mémoire CPU, tout stockage local et cloud, ainsi que les backups, parfois jusqu'au reformatage bas niveau. Containment et eradication se chevauchent souvent.

La Recovery rétablit l'infrastructure, les applications, les données et les workflows à leur état normal d'avant incident, idéalement après la fin de l'eradication. La Remediation regroupe les changements de configuration urgents pour limiter la récurrence (ajuster seuils et alarmes, reset des mots de passe). Chaque étape de recovery doit être validée comme correctement réalisée. Enfin, éliminer la source est aussi essentiel qu'en traiter les effets : sans cela, l'équipe répare éternellement le même problème. D'où la root cause analysis appliquée en phase de response, avec des techniques formelles (Figure 7.13) : Pareto (80 % de la valeur via 20 % de l'effort), Five Whys (demander « pourquoi ? » jusqu'à la cause), Fishbone/Ishikawa (visualiser les causes), FMEA (Failure Mode Effects Analysis, identifier systématiquement les défaillances de composants), Fault Trees (logique booléenne pour identifier les défaillances).

7.6 Reporting, Review et amélioration continue

L'une des dernières tâches de l'équipe de réponse est de signaler que les opérations de recovery sont terminées. Cette notification est un point de transition majeur. Point d'examen capital : l'équipe de réponse notifie au management que les systèmes sont prêts pour un usage normal, puis ce sont le management et les leaders qui décident de faire repasser l'organisation de l'état « incident response » à l'exploitation normale. Le SOC ne prend pas cette décision et n'en porte pas les responsabilités : c'est le management. Une fois la notification endossée et diffusée à ceux qui doivent agir, le SOC bascule vers les activités post-incident.

Le Review repose sur une documentation et une gestion des preuves rigoureuses. Si l'organisation envisage des sanctions civiles ou pénales, cette phase peut être différée ou conduite de façon à ne pas compromettre l'action légale ; sinon, le review doit être mené rapidement et de manière cohérente. Une réunion lessons-learned clarifie la séquence des événements et identifie les axes d'amélioration, mais l'organisation doit en fixer le ton. Si les participants pensent que le processus débouchera sur une punition, ils participeront moins. Une réunion lessons-learned n'est pas une inquisition : c'est un événement d'apprentissage, non punitif, et le management doit honorer cette attente.

Une fois les leçons documentées et reportées, le rapport alimente l'amélioration des processus - ce qui est particulièrement délicat, car les leçons soulignent souvent le besoin pour le management de se comporter différemment. L'introspection est difficile, et tous les niveaux de management doivent évaluer leur propre volonté de changer. Piège fréquent : produire force comptes rendus et changements de contrôles administratifs ne garantit pas que l'organisation apprenne vraiment. L'apprentissage doit se traduire par des changements de comportement vérifiables (verifiable changes in behavior). Communication, documentation et volonté de changer les processus défaillants sont critiques.

8.1 Firewalls, NGFW, IDS/IPS et les décisions temps réel du SOC

La valeur opérationnelle des firewalls ne se surestime pas : un environnement de menaces en évolution rapide oblige l'organisation à évaluer en permanence leur performance et à modifier les règles selon les nouveaux vecteurs d'attaque. Le SOC doit être prêt à prendre des décisions en temps réel face à un changement de menace ou d'architecture. Ces besoins immédiats peuvent justifier un processus d'approbation distinct du circuit habituel, mais une documentation, des tests et un déploiement corrects doivent rester cohérents avec les exigences de change management de l'organisation.

Les firewalls de quatrième génération et next-generation (NGFW) absorbent désormais beaucoup de fonctions des anciennes générations d'IDS et d'IPS, en solutions host-based ou network-based. Le candidat doit reconnaître les fonctions de base d'un IDS (détecter et alerter) et d'un IPS (détecter et bloquer activement), sans se focaliser sur le shopping de produits spécifiques. L'examen attend la compréhension du principe, pas un comparatif commercial.

Une subtilité importante : comme un NGFW se reconfigure tout seul à partir de ses algorithmes de machine learning et d'IA, appliquer une approche de change management traditionnelle bride l'efficacité du dispositif. Il faut plutôt intégrer le NGFW à l'infrastructure de logging de l'organisation pour tracer ses performances : la surveillance de ses changements automatiques fait partie de la stratégie de monitoring, et non d'une procédure de changement classique qui figerait l'adaptation.

Piège d'examen : ne confondez pas IDS (détecte et alerte) et IPS (détecte et agit en bloquant). Et retenez que pour les dispositifs auto-adaptatifs, le bon réflexe est le logging/monitoring, pas le gel par un change control rigide.

8.2 Allowed listing vs blocked listing

Le filtrage des activités à partir de listes d'éléments autorisés ou bloqués est l'un des contrôles les plus efficaces pour minimiser les compromissions par malware. Pendant des décennies, on a parlé de whitelisting et de blacklisting ; les termes allowed et blocked sont aujourd'hui préférés, même si d'anciens et certains nouveaux travaux conservent l'ancienne terminologie.

L'allowed listing n'autorise l'exécution que des éléments préalablement approuvés et bloque tous les autres. Ce contrôle figure dans les frameworks ISO et NIST ; NIST fournit le SP 800-167 (Guide to Application Whitelisting) pour accompagner sa mise en œuvre. Les listes logicielles autorisées détectent et empêchent toute tentative de charger et d'exécuter un fichier programme, et alertent le personnel de sécurité si le code n'est pas préapprouvé. Le concept d'interdire l'exécution de logiciels non autorisés s'étend aussi aux actions utilisateur, aux ports et protocoles, aux adresses IP/plages, aux sites web et aux adresses MAC. L'organisation peut vérifier l'intégrité des programmes autorisés via des signatures numériques, des checksums cryptographiques ou des fonctions de hachage, avant exécution ou au démarrage du système.

La technique est efficace lorsque le nombre d'applications permises est faible : par nature, elle bloque les menaces inconnues, ce qui est un atout majeur. Mais à mesure que la diversité des systèmes et des missions augmente, l'allowed listing peut devenir trop restrictive pour les besoins métier. À l'inverse, le blocked listing interdit explicitement les applications listées ; tout ce qui n'est pas listé est admis, sous réserve des autres contrôles. Cette approche est particulièrement efficace contre des menaces spécifiques et connues, et sert souvent à écarter des nuisance applications qui consomment des ressources.

Piège d'examen : allowed listing = deny by default, idéal en environnement homogène et bloque l'inconnu ; blocked listing = allow by default, efficace contre des menaces connues mais inopérant contre l'inconnu. Les produits d'allowed listing et d'anti-malware convergent et intègrent désormais des fonctions l'un de l'autre.

8.3 Services de sécurité tiers et due diligence contractuelle

Une organisation pour laquelle la sécurité n'est pas un core competency peut recourir à des services externes. L'exemple du manuel : un distributeur agricole n'a ni l'expertise ni les outils pour bâtir un programme de sécurité complet ; cela peut faire sens économiquement, sa compétence étant de vendre des produits agricoles, pas de sécuriser des données. Les services couramment offerts incluent : threat intelligence (veille open-source ou investigations propres sur les menaces visant une région, un secteur, un produit ou un client précis) ; network monitoring (surveillance à distance ou sur site, car détecter des attaques réseau exige analyse et expertise) ; physical security (services de gardiennage évitant l'embauche et les coûts de personnel) ; network management (souvent chargé de fonctions de sécurité - enforcement de la politique d'usage, monitoring, patch management, inventaire d'actifs, hébergement cloud) ; et audit (vérification/validation, scans de vulnérabilités, certification de conformité, maintenance de configuration).

Quel que soit le service, la due diligence est obligatoire pour confirmer la capacité réelle du prestataire à tenir les termes du contrat - d'autant plus que la sécurité exige une confiance forte. Les activités de due diligence comprennent : revue de la gouvernance (politique et procédures de sécurité du prestataire) ; SLAs (accord explicite sur ce qui constitue une exécution complète et exacte) ; NDAs (le prestataire protège les données du client et s'engage à ne pas en tirer parti à son profit) ; insurance/bonding (assurance responsabilité et, parfois, performance ou surety bond garantissant l'achèvement du travail et l'indemnisation en cas de négligence) ; audit/testing (autoriser le client à mener audits sur site, monitoring de performance ou pénétration tests) ; strong contract language (termes opposables et légitimes dans toutes les juridictions, revus par les conseils juridiques des deux parties) ; et regulatory approval (informer et obtenir l'accord des régulateurs si le service affecte la conformité).

Le secteur public diffère nettement du privé : les règles de procurement sont complexes et servent d'autres objectifs que le meilleur service au coût le plus bas (préférences pour certains groupes, contraintes politiques comme les embargos, développement de l'industrie locale, et forte accountability sur l'argent public). Repères : aux États-Unis, les Federal Acquisition Regulations (FAR) - des milliers de pages, non directement applicables aux États et sous-juridictions ; au Canada, les Government Contracting Regulations augmentées du manuel SACC (Standard Acquisition Clauses and Conditions) ; dans l'UE, les Public Procurement Policies fixant des minima augmentés par les exigences nationales.

Piège d'examen : la due diligence porte sur la capacité réelle du prestataire (governance, SLA, NDA, assurance, audit, langage contractuel, régulateurs), pas seulement sur le prix. Et n'oubliez pas que le contracting public obéit à des règles propres (FAR, SACC, EU procurement), distinctes du privé.

8.4 Sandboxing, honeypots et honeynets

Lorsque le SOC reconnaît une menace, des décisions s'imposent en temps réel ou quasi réel. L'organisation doit disposer de politiques pour évaluer la menace et décider de recourir à un environnement de test isolé - une sandbox - afin de séparer la menace du reste du réseau. Les sandboxes sont souvent implémentées en environnement virtuel : faciles à provisionner, et si l'environnement est compromis, le dommage reste minime. Limite à connaître : de nombreux attaquants savent détecter qu'ils sont dans une sandbox et adaptent leur comportement pour échapper à l'analyse. Le sandboxing sert aussi à isoler une activité potentiellement malveillante avant de présenter l'information à l'utilisateur : plusieurs moteurs de messagerie, notamment Office365 de Microsoft, savent sandboxer les messages et faire détoner (detonating) les URLs ; si une activité inappropriée est détectée, le lien est désactivé avant l'affichage du message.

Un honeypot est une machine présente sur le réseau mais ne contenant ni donnée sensible ni donnée de valeur ; plusieurs honeypots reliés en réseau ou sous-réseau forment un honeynet. Les honeypots servent à distraire et occuper les intrus pour retarder leur accès aux données de production, et offrent l'occasion d'observer l'attaque en direct (sans risque appréciable) afin de mieux cerner sa nature, d'identifier éventuellement l'attaquant, d'évaluer ses outils et compétences, et de recueillir des preuves utiles pour une action légale. Ils sont typiquement placés dans la DMZ et doivent imiter l'architecture d'un environnement réel, avec des actifs simulés mimant le contenu de la production, pour convaincre l'attaquant qu'il s'agit d'une cible authentique. Certains prestataires offrent des réseaux simulés entiers (des centaines de devices, faux comptes, fausses données de carte).

Point de gouvernance crucial : honeypots et honeynets ne sont généralement pas faits pour appâter ou attirer les acteurs malveillants. Si chercheurs en sécurité et fournisseurs anti-spam les structurent parfois exactement pour cela, il est contre-productif pour la plupart des organisations de solliciter activement des attaques contre leur infrastructure. Enfin, dans presque toutes les juridictions, le hackback (hacker en retour l'attaquant qui vous a hacké) est illégal, souvent lourdement puni : aux États-Unis et au Royaume-Uni, c'est un piratage comme un autre, passible de poursuites pénales (felony), même si certaines juridictions, dont les États-Unis, envisagent de l'autoriser dans des circonstances limitées.

Piège d'examen : sandbox = isolement d'analyse (mais détectable par l'attaquant) ; honeypot = leurre placé en DMZ pour observer et collecter des preuves, pas pour appâter ; hackback = illégal. Ne confondez pas l'objectif défensif d'observation du honeypot avec une démarche offensive.

8.5 Anti-malware : approches, zero-day et reputation monitoring

Une stratégie DiD réaliste intègre des solutions anti-malware (matérielles, logicielles ou mixtes), sur les devices réseau, les systèmes individuels et les endpoints mobiles. La plupart des frameworks identifient l'anti-malware d'endpoint comme un composant nécessaire de la defense in depth, géré via des plateformes dédiées intégrées au logging, au SOC et au SIEM ; l'intégration étroite à un SIEM ou SOAR est vitale. Comme le malware se propage largement par social engineering, la sensibilisation, l'éducation et la formation de tous les membres sont la première ligne de défense : email, pièces jointes et supports amovibles sont des vecteurs majeurs. Beaucoup de professionnels abandonnent la formation annuelle (longues vidéos cliquables) au profit du microtraining - de courtes séquences d'une minute réparties dans l'année - combiné au phishing awareness testing pour mesurer l'efficacité. Pour les PME, le manuel renvoie à des mesures de cyber hygiene de bon sens, dont l'Implementation Group 1 (IG1) du CIS pour le segment SOHO.

Tout l'antivirus est essentiellement réactif : il n'existe que parce que les malwares l'ont précédé. Il faut distinguer le scanning par signature connue des mesures génériques. Le manuel décrit trois approches, rapprochées (sans être identiques) des types d'IDS : known signature scanning (comme un IDS signature-based) - cherche des chaînes caractéristiques de virus connus, sait souvent nettoyer l'objet (mais le remplacement est plus sûr) ; activity monitoring (comme un IDS rule-based ou anomaly-based) - surveille et signale les activités suspectes, par exemple un appel de formatage de disque ou une altération de fichiers programme par un autre programme que l'OS ; et change detection (comme un IDS statistical-based) - compare régulièrement fichiers et configurations via un checksum ou CRC, parfois un hash/digest. La change detection est aussi appelée integrity-checking, mais le terme peut induire en erreur : si l'intégrité était déjà compromise avant l'établissement de la baseline, la technique est inopérante ; elle a aussi la plus forte probabilité de fausses alarmes car elle ignore si un changement est malveillant ou autorisé. À part, les heuristic scanners analysent du code inconnu en cherchant des sections suspectes (proches de l'activity monitoring), au prix de nombreux faux positifs.

Un zero-day (ou zero-hour) tire son nom de l'effet de surprise : un attaquant découvre une vulnérabilité non rapportée, développe un exploit et l'utilise avant toute défense ; le compte à rebours oppose black hats (attaquants), white hats (défenseurs) et gray hats (white hats utilisant des techniques offensives dans un cadre légal et éthique, comme l'ethical penetration testing). Pendant la zero-hour, aucun moteur antivirus ne protège un visiteur d'un site hébergeant du nouveau contenu malveillant. La parade : le web reputation monitoring, qui évalue les sites et leur attribue un score de réputation, typiquement de 0 à 100. Les cinq bandes citées en exemple : High Risk (1-20), Suspicious (21-40), Moderate Risk (41-60), Low Risk (61-80), Trustworthy (81-100) - de quoi bloquer, prudemment autoriser ou autoriser l'accès.

Enfin, les outils ML/AI repèrent des patterns malveillants non préétablis par les rule sets, KPIs et KRIs, et alertent sur davantage de menaces ; ils doivent être tunés pour les besoins de l'organisation, sous peine de décisions inadaptées et de coûts excessifs. Revers : ML/AI sont aussi accessibles aux attaquants (projets open-source), d'où un arms race permanent. Piège d'examen : signature -> connu ; activity monitoring/heuristique -> comportement et inconnu ; change detection -> intégrité par CRC/hash mais fausses alarmes et baseline potentiellement déjà corrompue.

8.6 Patch management : défis et processus

Les faiblesses identifiées par risk assessment, threat modeling ou scanning se traitent par des changements de configuration, des correctifs logiciels ou des modifications de l'environnement (règles de firewall, réglages DLP). Distinction d'examen : le vulnerability management met l'accent sur la détection et l'évaluation des faiblesses, puis confie souvent la remédiation à un autre processus selon l'effort requis ; le patch management est la part qui applique et vérifie les correctifs. Toute modification du logiciel de production suit les procédures de change management de l'organisation.

Patcher est nécessaire mais comporte ses propres défis : interoperability (un correctif peut entrer en conflit avec un système interdépendant et provoquer une panne ; les vendors ne peuvent anticiper tous les environnements) ; poorly-crafted patches (un correctif mal conçu peut dégrader les performances, créer des problèmes d'interopérabilité, voire introduire de nouvelles vulnérabilités - risque accru pour le reactive patching) ; required downtime (le reboot fréquent interrompt les opérations et génère des coûts) ; virtualization-specific concerns (en cloud, la pratique a migré vers l'immutable infrastructure : on applique le correctif à une instance entièrement neuve et on bascule la charge, en CI/CD avec des outils comme Puppet, Chef ou Ansible déployant des baselines de sécurité) ; et timing (les organisations multi-fuseaux risquent une application non uniforme des correctifs).

Le secteur a répondu par un processus standard de patch ; chaque organisation crée sa propre politique en tenant compte de ces étapes (Figure 7.14) : recevoir la notification (vendor, tiers anti-malware/threat intel, ou actualités - veille au moins quotidienne) ; déterminer l'applicabilité/évaluation (tous n'utilisent pas le produit pareil ; le change management exige une analyse d'applicabilité et d'urgence) ; déterminer les impacts potentiels sur les autres systèmes et les risques additionnels ; tester sur un test bed isolé air-gapped reproduisant les interdépendances de la production (sans réplication 1:1), en testant aussi les procédures de rollback ; effectuer un full backup avant application (pour pouvoir revenir en arrière sans perte) ; appliquer selon les instructions du vendor, les best practices et le processus formel ; confirmer l'installation sur toutes les cibles avec des outils automatisés, vérifier que le correctif performe et mettre à jour les métriques de monitoring ; solliciter le user feedback (le help desk est partie prenante) ; rollback vers l'état antérieur si le correctif échoue ou a des effets inacceptables, selon des critères définis dans la Request for Change (RFC) et déclenchés automatiquement ; et tout documenter, en intégrant les enregistrements de patch à l'asset inventory.

Piège d'examen : ne confondez pas vulnerability management (détecter/évaluer) et patch management (appliquer/vérifier). Et retenez l'ordre logique - notifier, évaluer l'applicabilité, mesurer l'impact, tester en air-gapped, sauvegarder, appliquer, confirmer, recueillir le feedback, rollback si besoin, documenter - le test sur un bed isolé et le full backup précèdent toujours l'application en production.

9.1 La stratégie de stockage 3-2-1 et les supports

Des sauvegardes exactes et complètes sont l'instrument central de la continuité d'activité et de la reprise après sinistre (BCDR) : c'est la facette availability de la triade CIA mise en pratique. La donnée de sauvegarde doit être stockée de façon à être disponible quand on en a besoin. La protection minimale, affinée par des décennies d'expérience, se résume dans la stratégie 3-2-1.

Trois chiffres, trois exigences. « 3 » : trois copies de la donnée, c'est-à-dire l'original plus deux sauvegardes. « 2 » : deux types de support différents, par exemple bande magnétique, lecteurs WORM (Write Once, Read Many), disques amovibles ou cloud. Le choix du support dépend du coût de stockage, de la vitesse de backup et de restore, de la compatibilité avec les pratiques héritées (legacy) et des garanties d'intégrité offertes. « 1 » : une copie offsite, hors site, car on ne peut pas répliquer une infrastructure à l'intérieur de l'infrastructure même que l'on cherche à protéger.

Les lecteurs WORM méritent une attention particulière à l'examen : leur propriété « écriture unique, lectures multiples » empêche toute altération ultérieure et constitue donc un support de choix pour la rétention réglementaire et la protection contre le ransomware ou la falsification.

Piège d'examen : 3-2-1 = trois copies, deux types de média, une copie offsite. Ne le confondez pas avec « trois emplacements » ou « deux emplacements » : la formulation correcte porte sur le nombre de copies, le nombre de types de support et une copie hors site, pas sur le nombre de lieux.

9.2 Emplacements de sauvegarde : onsite, offsite et cloud

L'endroit où le support est rangé structure toute la stratégie de sauvegarde. Trois grands choix existent. Onsite : l'organisation garde le contrôle total et la responsabilité de la donnée, stockée dans la production facility et immédiatement disponible pour une reprise. Le coût peut être proportionnellement plus élevé, surtout si une PME n'a ni la capacité datacenter ni les compétences internes pour sécuriser correctement ses backups.

Offsite : la donnée est transportée vers un lieu suffisamment éloigné et robuste pour ne pas être affecté par une défaillance catastrophique du site de production. Elle s'expose alors à un risque supplémentaire en transit et peut nécessiter des contrôles additionnels pour garantir son utilisabilité à l'arrivée ; l'organisation perd parfois une part de la gouvernance de sécurité au profit du prestataire. Le transport peut être physique (déplacement du support) ou s'appuyer sur le data vaulting, qui utilise les réseaux de données pour transférer l'information vers un support distant.

Cloud Backup-as-a-Service : certains CSP offrent la sauvegarde en service. Cela diffère des approches physiques onsite/offsite car la donnée est répliquée plusieurs fois à l'intérieur de l'environnement du CSP et reste disponible à la demande. Ces services proposent typiquement des niveaux online (accès quasi immédiat) et near-line (accès différé, moins coûteux), avec des coûts et disponibilités distincts.

Piège d'examen : data vaulting désigne le transfert offsite par le réseau, à ne pas confondre avec un simple transport physique de bandes. Online et near-line sont deux niveaux de service cloud, pas deux types de sauvegarde.

9.3 Types de sauvegarde et l'archive bit

Les approches de sauvegarde diffèrent par le temps nécessaire au backup et au restore, et par leur effet sur l'archive bit. Dans la plupart des OS, le système de fichiers signale qu'un fichier a changé via cet archive bit : il vaut 1 à la création du fichier, une tâche de sauvegarde le remet (« flip ») à 0 pour indiquer que le fichier a été archivé, et tout fichier créé ou modifié ensuite repasse le bit à 1.

Full : toute la donnée de l'environnement est copiée. C'est l'option la plus coûteuse et la plus longue, mais la plus complète ; elle remet l'archive bit à 0 (Figure 7.15). Differential : on copie toute la donnée modifiée ou créée depuis la dernière full (bit à 1), mais sans réinitialiser le bit à 0 (Figure 7.16). Conséquence : chaque differential est cumulative et grossit jusqu'à la prochaine full. Incremental : on copie tous les fichiers nouveaux ou modifiés depuis la dernière full ou la dernière incremental, puis on remet l'archive bit à 0 (Figure 7.17). Chaque incremental ne capture donc qu'un sous-ensemble défini, de taille gérable.

Le compromis est central pour l'examen. L'incremental rend le backup le plus rapide (peu de données chaque soir) mais le restore le plus lent : il faut la dernière full plus toutes les incremental successives. La differential rend le backup plus lourd au fil de la semaine (cumul) mais le restore plus simple : la dernière full plus une seule differential.

Piège d'examen : c'est la réinitialisation de l'archive bit qui distingue differential (ne le remet PAS à 0, donc cumulative) et incremental (le remet à 0, donc non cumulative). Mémorisez : differential ne touche pas le bit, incremental le remet à 0.

9.4 Journaling, snapshot, CDP et le nombre de versions

Deux stratégies de sauvegarde regardent la donnée plutôt que les fichiers. Le journaling, conçu à l'origine pour la reprise granulaire des bases de données, écrit chaque transaction dans un log au moment du commit ; ces journaux permettent de faire « rouler » une instance jusqu'à la dernière transaction validée. Il est aujourd'hui répandu dans les systèmes de fichiers (NTFS, HFS+) et offre une grande fiabilité face aux coupures momentanées de courant ou de connexion au stockage. Le journaling n'affecte pas l'archive bit. Le snapshot, propre aux environnements virtualisés, capture un miroir des blocs de données sans interrompre la production ; il reste habituellement sur le support de production jusqu'à sa copie ailleurs, et ses temps de restauration sont très rapides. Le snapshot capture l'archive bit dans sa position de production (il ne le modifie pas). On le confond souvent avec le cloning ou le mirroring, qui protègent la donnée mais offrent surtout un failover temps réel si le stockage primaire tombe.

La Continuous Data Protection (CDP) est une forme de snapshotting : à chaque changement d'un bloc, le bloc est snapshotté, ce qui permet une reprise à un point de transaction précis, rapidement et finement. La duplication a un coût en performance, mais la granularité de reprise vaut l'effort dans certains environnements.

Combien de versions garder ? Réutiliser le même volume en écrasant chaque sauvegarde précédente ne laisse qu'UNE version : la donnée modifiée entre deux backups est irrécupérable, et un processus défaillant fait de la production le seul exemplaire exact - le backup devient un single point of failure. À l'inverse, créer une nouvelle version à chaque fois consomme un volume considérable et sème la confusion sur la version la plus récente. Il faut trouver un juste milieu : assez de versions pour ne pas perdre toute capacité de reprise, sans rendre la gestion ingérable.

Validation : après chaque sauvegarde, quel que soit le type, l'organisation doit valider que la copie est complète et exacte, généralement via un integrity check et, selon la taille du jeu, par échantillonnage (sampling).

Piège d'examen : journaling et snapshot n'affectent pas l'archive bit ; CDP snapshotte chaque bloc modifié ; n'oubliez jamais l'étape de validation, car un backup non vérifié peut être un single point of failure silencieux.

9.5 Sites de reprise et haute availability

Si l'environnement de production normal ne fonctionne plus, l'organisation a besoin d'une capacité de traitement alternative. Les types de sites se classent par leur délai d'activation. Mirrored : le site miroir fonctionne en parallèle de la production, traitant chaque transaction simultanément, si bien qu'à tout instant deux copies complètes et à jour existent en deux lieux séparés ; option la plus chère, réservée aux besoins de disponibilité maximale. Hot : site pleinement opérationnel avec tout le matériel, le logiciel et la donnée pour reprendre instantanément les fonctions critiques ; activation en minutes à heures. Warm : comme un hot mais sans la version courante des données et sans certains aspects fonctionnels prêts au failover instantané (eau, électricité raccordées mais à activer) ; activation en heures à jours. Cold : local vide sans matériel/logiciel/données, utilities éventuellement raccordées mais inactives ; option la moins chère mais activation en semaines voire mois, très dépendante de la supply chain IT. Mobile : installation portable montée sur un véhicule, pour un nombre très limité d'utilisateurs critiques, mais déployable n'importe où. Cloud : la donnée est chez un CSP, on reprend depuis n'importe quel lieu disposant d'un accès large bande.

Deux outils contractuels complètent ces options, surtout dans le secteur public : le JOA (joint operating agreement) et le MOU (memorandum of understanding), par lesquels deux organisations partagent un site si l'environnement de l'une est perturbé - efficace pour un impact localisé (un incendie d'un bâtiment) mais pas pour un sinistre métropolitain, qui touche souvent les deux partenaires. Le site alternatif doit être assez loin pour échapper au sinistre primaire, mais assez proche pour que le personnel clé l'atteigne en crise. On prévoit aussi des relocation kits (build courant des actifs IT critiques, version courante des données, clés de chiffrement, contacts), tenus à jour par l'équipe BCDR via le change management.

Pour minimiser le downtime, on recourt aussi à des multiple processing sites : contrairement au mirroring (deux copies complètes), ils fournissent collectivement assez de capacité pour soutenir les fonctions critiques, avec réplication des applications et données et prise en compte de la bande passante, des dépendances matérielles et des contraintes légales (data localization, privacy).

Côté system resilience et haute availability (HA), plusieurs techniques. Des spare components suffisants en inventaire permettent de remplacer tout élément du chemin critique (mais trop de spares coûte cher). Le clustering combine des systèmes (stockage, traitement, réseau) pour fournir une capacité constante : en active-active tous les nœuds traitent une part de la charge (load balancing), en active-passive un nœud reste inactif et n'est activé qu'en cas de fail. Le power enfin : un UPS fournit un courant temporaire immédiat le temps d'un arrêt propre (batteries deep-cycle, ou Flywheel Energy Storage cinétique, ou supercapacitors) ; un generator produit du courant local à partir de carburant (risque incendie/explosion et gaz toxiques) et doit être couplé à un transfer switch qui détecte la perte du secteur et démarre le générateur automatiquement.

Piège d'examen : associez le délai d'activation au type de site - minutes/heures = hot, heures/jours = warm, semaines/mois = cold. Le UPS ne sert qu'à un arrêt propre ou au relais vers un générateur, jamais à une autonomie longue.

La resilience d'un systeme repose sur trois leviers que l'examen associe souvent : la high availability (HA) maximise le temps de service via la redondance, la fault tolerance permet de continuer a fonctionner malgre la panne d'un composant (sans interruption percue), et la Quality of Service (QoS) garantit aux flux critiques la bande passante, la latence et la priorite necessaires meme en cas de congestion. HA vise la disponibilite, fault tolerance vise la continuite sans coupure, QoS vise la performance garantie des services prioritaires.

9.6 Stockage : RAID, SAN et NAS

Au-delà du cloud, deux options de stockage méritent considération : les RAID et le stockage centralisé. Un RAID (redundant array of independent disks) augmente la disponibilité en virtualisant un volume sur plusieurs disques, afin qu'un jeu de données ne soit pas perdu si un disque tombe. Écrire la donnée sur plusieurs disques s'appelle le striping ; certaines configurations ajoutent des parity bits permettant de reconstituer le jeu complet si un disque échoue (les données stripées des disques voisins, combinées aux parity bits, comblent le trou).

Les niveaux à connaître (Figure 7.18). RAID 0 : striping sans parité, performances optimisées mais AUCUNE redondance. RAID 1 : mirroring, donnée dupliquée sur deux disques identiques ; si l'un tombe, son miroir prend le relais. RAID 2 : technique héritée, plus guère utilisée. RAID 3 et 4 : striping plus un disque de parité dédié - RAID 3 stripe à l'octet, RAID 4 au bloc ; le disque de parité dédié est un single point of failure, peu adapté à la HA. RAID 5 : données ET parité stripées sur plusieurs disques, offre la HA. RAID 6 : striping plus DEUX jeux de parité, tolère la perte de DEUX disques tout en gardant les performances de RAID 5. RAID 0+1 : on stripe (RAID 0) puis on mirrore (RAID 1). RAID 1+0 (« RAID 10 ») : on stripe sur deux jeux de disques dupliqués simultanément ; préférable à RAID 0+1. RAID 15 et 51 : combinent RAID 1 et RAID 5 (striping de parité + mirroring de tous les disques), réservés aux environnements très sensibles vu leur coût et leur impact sur la productivité.

Le stockage centralisé évite que la donnée éparpillée sur les endpoints soit perdue ou difficile à archiver, mais il crée un single point of failure et une cible unique s'il n'est pas protégé : centraliser exige donc redondance et backups sécurisés. Deux méthodes (Figure 7.19). Le SAN (storage area network) est un réseau de baies de stockage fournissant du volume aux serveurs ; il s'appuie sur des protocoles dédiés comme Fibre Channel et iSCSI, et présente le stockage comme des volumes (espace disque brut) montés sur l'OS comme un disque attaché - on raisonne en blocs. Le NAS (network-attached storage) est un serveur de fichiers centralisé accédé par de nombreux utilisateurs ; il maintient la hiérarchie de fichiers et présente la donnée sous forme de fichiers. Beaucoup de NAS (comme des SAN) utilisent iSCSI, qui gère l'espace de stockage en blocs logiques via des protocoles internet.

Piège d'examen : SAN = accès bloc (volumes bruts, Fibre Channel/iSCSI) ; NAS = accès fichier (le serveur gère la hiérarchie). Pour la tolérance de panne : RAID 0 = zéro redondance, RAID 5 = un disque, RAID 6 = deux disques, et RAID 10 est préféré à RAID 0+1.

10.1 Déclencher la réponse BCDR : critères et autorité

La continuité d'activité et la reprise après sinistre (BCDR) sont parfois l'environnement le plus stressant qu'une organisation rencontre, et c'est précisément pourquoi un plan BCDR bien rodé sert de meilleur entraînement au combat possible. L'esprit est celui des forces armées : « hard in training, easy in battle » - un entraînement dur, intense et répété conditionne les équipes à survivre et à agir sous pression. Chaque organisation adapte son plan BCDR à ses besoins propres, mais des principes communs structurent un processus type.

Déclencher la réponse a un coût considérable et un impact significatif, financier comme opérationnel, souvent absent du budget courant. La décision d'activer le plan doit donc reposer sur des criteria for initiating the response action : il est impossible de prévoir tous les contingency events, mais un jeu de lignes directrices guide la personne qui décidera le moment venu. Ces critères incluent typiquement la valeur monétaire (dollar value) des actifs affectés, le nombre d'utilisateurs touchés, la durée attendue d'indisponibilité (downtime) et la menace sur la santé et la sécurité des personnes (human health and safety).

La personne autorisée à prendre cette décision doit être de confiance et disposer d'un degré élevé d'autorité et de vision : il s'agit en général d'un membre de la senior management, voire du dirigeant de l'organisation. Pour décider correctement et au bon moment, elle s'appuie sur une information chain : un processus formel d'escalade des informations liées à l'incident, des sources professionnelles externes (agences gouvernementales, fournisseurs de threat intelligence payants) et des moyens informels (services d'actualité, réseaux sociaux).

Piège d'examen : l'autorité de déclencher la réponse - et de déclarer un disaster - n'appartient jamais à n'importe quel employé ni au seul service informatique ; elle est réservée à des cadres dirigeants pré-désignés. Inversement, ce sont les critères objectifs (montant, utilisateurs, downtime, safety) qui justifient la décision, pas l'intuition.

10.2 Le personnel BCDR : critical-path vs responders

Au-delà du cadre dirigeant qui autorise la réponse, le plan doit désigner précisément les personnes impliquées. Le manuel distingue deux populations. Les critical path personnel sont les personnels essentiels au maintien des fonctions opérationnelles de l'organisation pendant le contingency event. Ils ne gèrent pas forcément la réponse : ils ont des production tasks à assurer. Ils doivent être formés à leur rôle de crise : rejoindre l'alternate operating site, accéder aux archives de données, journaliser les transactions effectuées pendant la contingence.

Les responders sont les personnels qui pilotent le processus de réponse. Ils proviennent typiquement de plusieurs fonctions : IT (administrateurs, architectes, techniciens), Security (expertise spécifique cruciale), Legal (le general counsel garantit le respect réglementaire et la due diligence, et oriente la collecte/préservation des preuves pour d'éventuelles actions pénales ou civiles), HR (accès aux données privées des employés pour contacter le personnel ou les familles), Finance/accounting (suivi des coûts et transactions financières pendant l'événement), Public relations/communications (voix uniforme vers l'extérieur) et Management (un dirigeant supervise, approuve les dépenses et décide de la fin de la contingence).

Le point examinable majeur concerne l'affectation : nommer des individus précis a des avantages (ils peuvent être formés et s'entraîner), mais crée des points of failure. Pendant un disaster, l'organisation ne peut pas compter sur la présence de chaque individu. Il vaut donc mieux assigner des offices/departments aux tâches, et cross-train le personnel de ces bureaux pour qu'il assume les tâches de contingence au besoin. Un bon plan détaille chaque bureau assigné au point que n'importe quel membre, sans exposition préalable au sujet, puisse suivre les instructions et accomplir les tâches.

Piège d'examen : confondre critical-path personnel (qui font tourner l'activité) et responders (qui gèrent la crise) ; et croire qu'il faut nommer des individus plutôt que des bureaux cross-trained.

10.3 Communications, évaluation de l'impact et restauration

L'organisation doit maîtriser deux types de communications de contingence : interne et externe. En interne, il faut joindre tout le personnel pour l'informer des actions attendues (évacuer si l'on est sur site, rester chez soi si l'on n'est pas encore arrivé, rejoindre un site alternatif pour les responders et critical personnel). Deux modes existent : la push capability (messages automatiques envoyés à tout le personnel) et l'access capability (un clearinghouse central, par exemple un site web, que chacun peut consulter). Les canaux normaux pouvant être indisponibles (mobile, texto, Internet), des moyens alternatifs de mass communication doivent être une priorité. Les coordonnées d'urgence des employés étant rarement à jour, des tests et mises à jour réguliers s'imposent. Senior management doit arbitrer le compromis entre diffuser largement l'information et exposer des informations sensibles hors des canaux autorisés.

En externe, l'organisation devra joindre forces de l'ordre/secours, régulateurs, public/médias et partenaires (vendors, clients, end customers). Trois éléments sont cruciaux : un single voice (une voix unique optimale, car des déclarations multiples se contredisent et nourrissent la défiance), des trained communications professionals (capables d'informer sans admettre de responsabilité ni créer de liability), et la gestion d'une developing situation (mieux vaut dire « la situation évolue, l'information est encore incertaine » que publier des données qui devront être corrigées, surtout sur le timing de résolution).

L'assessment vise à calculer l'impact total de la contingence : il combine les dommages de l'événement lui-même et le coût des efforts de réponse (total impact = damage + response cost). Réalisé par les équipes comptables et d'audit avec l'appui des SME (valeur des actifs) et des RH (heures de production), il sert ensuite aux poursuites pénales, aux actions civiles, au reporting des investisseurs et à l'information des régulateurs.

Enfin, la restoration vise la reprise complète des opérations normales : retour au site primaire ou création d'un nouveau site primaire (beaucoup d'organisations conservent l'alternate site devenu le nouveau primaire). La restauration des données est à haut risque : réimporter l'archive et le journal des transactions de contingence peut endommager l'archive, l'enregistrement et l'environnement de production. Le timing est critique : revenir trop tôt menace la santé/sécurité ; rester trop longtemps en contingence coûte cher (sites alternatifs onéreux, personnel non productif payé, ou départs si non payé). La décision de revenir au normal revient à senior management.

10.4 Training, awareness et lessons learned continus

Un plan BCDR n'a de valeur que si les personnes savent l'exécuter. Le manuel distingue deux niveaux. Le personnel assigné à des tâches BCDR (responders, critical path et leurs suppléants/alternates) doit recevoir une formation formelle pour son rôle, ce qui inclut la participation à tous les tests. À l'échelle de toute l'organisation, l'ensemble du personnel doit être exposé à des awareness activities qui le préparent aux actions d'urgence : formation formelle (à l'embauche ou lors des tests annuels) complétée par une information informelle récurrente (newsletters, rappels, affiches).

Le processus de lessons learned est souvent mal compris. La vision classique consiste à attendre que tout soit revenu à la normale, puis à relire les journaux et à tirer les enseignements. Or l'une des leçons majeures de la pandémie de COVID-19 est que ce processus d'évaluation active, de décision, de direction et de revue des enseignements doit être continu (ongoing). La due diligence exige d'une équipe de management prudente qu'elle tire chaque leçon possible d'une expérience douloureuse : voyez le coût d'un événement disruptif comme des frais de scolarité (tuition) payés pour mieux se préparer la fois suivante.

Intégrer l'apprentissage des leçons au quotidien (jour après jour, semaine après semaine) du processus de gestion d'incident ou de disaster présente un avantage concret : les souvenirs et impressions sont plus frais, les preuves et artefacts sont plus proches de leur état au moment de l'événement, et l'analyse est plus révélatrice. On apprend aussi de ses réponses déjà engagées alors qu'il reste du chemin vers le « new normal ». Des événements disruptifs comme une pandémie peuvent imposer des mesures supplémentaires de santé et sécurité au travail ; des sources comme l'OMS (WHO) et les CDC américains fournissent des guidelines et bonnes pratiques.

Piège d'examen : les lessons learned ne sont pas une étape finale unique mais un processus continu ; et l'awareness vise tout le personnel, alors que le training formel vise les personnels assignés au BCDR.

10.5 Les cinq types de tests DR, classés par intensité

Tester ses plans permet d'identifier les écarts et de les corriger vite, pour ne pas gaspiller un temps précieux le jour d'un vrai disaster. Le professionnel de sécurité doit connaître les bénéfices et risques de chaque type de test. Le manuel les classe par intensité, coût et impact croissants.

Read-through / tabletop : activité contrôlée et isolée de role-playing réunissant uniquement les personnels chargés du DR et un modérateur, autour d'une salle de réunion avec tous les documents DR. Le modérateur présente une situation déclenchant une réponse DR ; les participants décrivent verbalement leurs actions et peuvent consulter les documents. C'est le test le moins intrusif et le moins cher ; excellent pour former des personnels nouveaux ou peu familiers et pour repérer les lacunes du plan.

Walk-through : similaire au tabletop, mais au lieu de rester autour de la table, les participants se déplacent vers chacun des lieux qu'ils devront visiter lors de la réponse. Ils peuvent encore se référer aux guides écrits et sont supervisés. Plus utile que le tabletop pour évaluer les limites physiques et établir le timing des activités ; à peine plus cher.

Simulation : un walk-through plus complexe et plus impliquant, pouvant mobiliser tout le personnel d'un bureau dans une situation d'urgence scriptée (un fire drill avec évacuation en est un exemple). Plus coûteux et plus perturbant pour la productivité (le travail est interrompu), mais plus de personnes y gagnent expérience et formation.

Parallel : pour les organisations qui utilisent des alternate operating sites. On mobilise réellement personnels et ressources vers le site alternatif et on y conduit les opérations - généralement un service ou une équipe à la fois. Bien plus cher et plus impactant que les précédents, mais offre l'assurance que la solution de repli fonctionne réellement.

Full interruption : implique toute l'organisation dans une situation scriptée mimant un vrai contingency event. Toutes les ressources, personnels et activités BCDR sont engagés. C'est de loin l'option la plus chère, au plus fort impact ; un grand soin est requis pour éviter que l'exercice ne devienne un vrai disaster. Réservé aux organisations qui ont les moyens de le planifier et l'exécuter correctement.

Communiquer les résultats du test aux parties intéressées (internes et externes : clients, partenaires, régulateurs) fait partie de l'exercice. Les rapports décrivent l'objectif, les aspects testés et surtout la pertinence de la stratégie DR. Ces résultats documentés sont des artefacts que les clients exigent souvent pour leur due diligence fournisseur, et qui sont examinés lors des audits SOC et ISO 27001.

10.6 BCP, BIA et les métriques MTD, RTO, RPO (et WRT)

La business continuity planning (BCP) est une activité prudente, souvent obligatoire, qui prépare l'organisation à des événements disruptifs et altérants pour l'activité : catastrophes naturelles, épidémies, conflits géopolitiques, perte de personnel critique. L'objectif est d'assurer que l'organisation puisse continuer à fonctionner pendant et après une crise. Des standards nationaux et internationaux servent de guide ou de point de départ : NIST SP 800-34 (national, US) et ISO 22301 (international).

La Business Impact Analysis (BIA) identifie d'abord les fonctions mission-essential, puis analyse l'effet d'une disruption sur ces fonctions. Elle se mène en engageant les parties prenantes - surtout les mission/process owners, managers et personnels de département - pour déterminer la criticité de chaque processus ou service. La BIA produit des estimations temporelles, les fameuses MTD, RTO et RPO, pour lesquelles l'organisation peut s'appuyer sur des templates NIST.

Le MTD (Maximum Tolerable Downtime) est la durée totale d'interruption qu'un dirigeant accepte pour un processus métier ; il englobe toutes les considérations d'impact. Sans MTD, les planificateurs manquent de direction pour choisir une méthode de reprise et calibrer le niveau de détail des procédures. Le RTO (Recovery Time Objective) est la durée maximale pendant laquelle une ressource système peut rester indisponible avant un impact inacceptable sur les autres ressources, les processus métier et le MTD : il guide le choix des technologies de reprise. Le RPO (Recovery Point Objective) est le point dans le temps, avant la disruption, jusqu'auquel les données doivent être récupérées (sur la base de la sauvegarde la plus récente) : il dicte la fréquence des sauvegardes et borne la perte de données acceptable. Ces objectifs sont souvent communiqués aux clients dans un SLA.

Complément du CBK ISC2 (hors manuel D7) : le WRT (Work Recovery Time) est le temps nécessaire, une fois le système techniquement restauré (fin du RTO), pour reconfigurer, valider et reprendre le travail métier normal. La relation clé à retenir : MTD = RTO + WRT. Le RTO ne peut donc jamais dépasser le MTD, et il doit même lui laisser de la marge pour le WRT.

Le plan (BCP) doit être maintenu : revu, mis à jour et révisé ; certains éléments (listes de contacts) demandent des mises à jour plus fréquentes. Tester le BCP est crucial et, pour la conformité, doit avoir lieu à intervalles programmés - typiquement au minimum annuellement - et lors de changements organisationnels ou environnementaux significatifs. Les tests réutilisent les types vus pour le DR (tabletop, fonctionnel, full-scale).

Piège d'examen : choisir un site de repli, c'est comparer son temps de reprise au RTO/MTD - un hot site (reprise quasi immédiate) pour un RTO très court, un cold site seulement si le RTO/MTD le tolère. Et ne confondez pas RTO (temps pour rétablir le service) avec RPO (quantité de données perdue, exprimée en temps).

11.1 Le périmètre : du property line aux zones protégées

La fonction première d'un système de contrôle d'accès est de garantir que seules les personnes autorisées pénètrent dans les zones contrôlées, et de réguler le flux des matériels qui y entrent et en sortent. Le public concerné est large : employés, visiteurs, clients, fournisseurs, grand public. Chaque application appelle des mesures différentes, calibrées sur des objectifs de sécurité, de coût et d'exploitation propres.

Le contrôle s'organise de l'extérieur vers l'intérieur, en couches concentriques. Il peut débuter dès la security property line, englobant par exemple les parkings, puis se resserrer sur les entrées du bâtiment, puis sur n'importe quelle zone interne selon la direction du management. On le calibre toujours sur le risque identifié et la valeur protectrice recherchée. Les protected areas typiques sont les entrées de plain-pied, les lobbies, les quais de chargement (loading docks), les ascenseurs et les zones internes sensibles abritant des données clients, de l'information propriétaire ou classifiée.

Historiquement, l'accès reposait sur des clés physiques. L'évolution vers les systèmes électroniques simplifie la gestion des droits : on révoque un badge en un clic, là où une clé perdue imposait de rechanger les serrures. Le professionnel de la sécurité doit souvent plaider pour de bonnes pratiques de facilities management et pour l'intégration des contrôles physiques avec les contrôles logiques et techniques - le bâtiment moderne étant un véritable system of systems.

Complément CPTED (provenance cheat) : le Crime Prevention Through Environmental Design conçoit l'environnement pour décourager l'intrusion via trois leviers : natural surveillance (visibilité, éclairage, fenêtres orientées vers les accès), natural access control (chemins et entrées canalisant les flux), et territoriality (marquages, clôtures basses, aménagement signalant une appropriation des lieux). Piège d'examen : CPTED relève de la prévention par le design, pas d'un capteur.

11.2 Badges, enrollment station et types de cartes

Pour reconnaître un employé autorisé, le système a besoin d'une enrollment station : c'est le poste où l'on assigne et active le dispositif d'accès. Le plus souvent, un badge est produit et émis avec les identifiants de l'employé, l'enrollment station définissant les zones précises qui lui seront accessibles. En environnement haute sécurité, l'enrôlement peut aussi capturer des caractéristiques biometric. Le principe de fonctionnement est une comparaison : le système confronte le badge de la personne à une base vérifiée. Si l'authentification réussit, il émet les signaux qui ouvrent la porte ou le portail.

Ces systèmes sont typiquement intégrés aux logging systems de l'organisation pour documenter l'activité d'accès, autorisée comme non autorisée. Cette journalisation est essentielle : c'est elle qui fournit la traçabilité (accountability) en cas d'incident.

Une variété de types de cartes permet d'adapter le système à différents environnements. Les barcode cards portent un code-barres lisible optiquement, peu coûteux mais facile à copier. Les magnetic stripe cards stockent les données sur une piste magnétique, comme une carte bancaire classique. Les proximity cards sont lues sans contact à courte distance (RFID), pratiques pour les flux importants. Les smart cards embarquent une puce capable de traitement et de stockage chiffré, offrant le niveau de sécurité le plus élevé. Les hybrid cards combinent plusieurs technologies (par exemple proximity pour l'accès physique et puce à contact pour l'authentification logique).

Piège d'examen : la proximity card identifie sans contact mais n'est pas une smart card ; seule cette dernière effectue un traitement cryptographique embarqué.

11.3 CCTV, capteurs extérieurs et contrôles internes en couches

La CCTV (closed-circuit TV) relie un réseau de caméras à des enregistreurs pour surveiller l'environnement. Elle est normalement intégrée au programme de sécurité global et monitorée de façon centralisée. Souple, elle excelle là où l'accès est difficile ou lorsqu'un forensic record est requis. Mais elle a des limites : le placement doit assurer la couverture sans porter atteinte aux expectations of privacy des individus. Historiquement câblée en coaxial dédié (coûteuse, sans redondance), elle est aujourd'hui souvent en IP/sans fil : installation moins chère, mais les caméras deviennent des équipements réseau exposés à de nombreuses attaques réseau.

À l'extérieur, plusieurs motion sensors complètent la CCTV : infrared, microwave, et lasers visant des récepteurs accordés. D'autres capteurs s'intègrent aux portes, portails et turnstiles. Les tentatives d'escalade de clôture se détectent par strain-sensitive cables et autres vibration sensors. Bien intégrés, ces capteurs périmétriques alertent dès qu'un intrus traverse un espace ouvert ou tente de percer la ligne de clôture.

À l'intérieur, l'approche en couches reste de mise. Le card reader contrôle l'accès à une pièce précise. Le Balanced Magnetic Switch (BMS) utilise un champ magnétique ou un contact mécanique pour décider si une alarme se déclenche (typiquement sur une porte ou fenêtre ouverte). Les acoustic sensors écoutent passivement les espaces. Les infrared linear beam sensors projettent un faisceau IR d'un émetteur vers un réflecteur : l'interruption du faisceau signale un passage. Les passive infrared (PIR) détectent les signatures de chaleur d'un intrus en comparant les récepteurs IR au niveau de fond habituel. L'automatic request to exit détecte automatiquement une personne approchant en direction de la sortie. Enfin, les dual-technology sensors combinent deux principes (par exemple PIR + microwave) : l'alarme n'est levée que si les deux concordent, ce qui réduit fortement les false alarms.

Complément CBK : mantraps, turnstiles et sally ports n'autorisent qu'une personne (ou véhicule) à la fois entre deux portes verrouillées, contrant le tailgating ; HVAC en positive pressure pousse l'air vers l'extérieur pour empêcher l'entrée de contaminants ou de fumée.

11.4 Sûreté en voyage et duress codes

Protéger l'information suppose de protéger les personnes qui la traitent. Les individus deviennent des cibles, surtout à l'étranger, où les risques diffèrent fortement de leur environnement habituel. Trois grandes menaces de voyage : le kidnapping for ransom (dans certains pays, un véritable modèle économique, d'où des polices d'assurance ransom et une préparation des modalités de gestion en amont) ; la surveillance par les foreign intelligence services (interrogatoire des contacts locaux, copie des passeports et appareils à la frontière ou à l'hôtel, fouille ou surveillance des chambres, parfois un local complaisant qui « tombe » sur vous) ; et les réseaux de facial recognition qui pistent les déplacements dans l'espace public, le personnel hôtelier rapportant aussi les mouvements.

Aspects de sûreté à considérer en déplacement ou en télétravail : ne pas emporter ce dont on n'a pas besoin (information, argent, électronique sont plus en sécurité à la maison) ; si on doit l'emporter, protéger légalement l'information, sachant que l'encryption peut être limitée par la loi de certaines juridictions ; mettre en place un secure remote access (lui aussi parfois restreint selon les juridictions) ; anticiper les jurisdictional/cross-border concerns sur les données franchissant les frontières ; assurer la personnel protection (orientation locale, formation, assurance médicale/vie, protection physique) ; et organiser la condition monitoring avec check-ins quotidiens, qui doit aussi déterminer si la personne agit sous contrainte.

Le duress code répond précisément à ce dernier point. Une personne menacée ou entravée dans ses mouvements doit pouvoir signaler discrètement sa situation, avec des code words autres que « je suis sous contrainte », intégrables dans une conversation normale et mémorisables sous stress extrême. Le code doit pouvoir être transmis par plusieurs canaux. Le personnel doit être formé et entraîné aux actions à mener. Les duress codes changent régulièrement, mais si une personne transmet un code expiré, un processus de réponse doit tout de même être déclenché : un code périmé peut révéler une véritable détresse.

Le 2FA renforce la sûreté : formé avant le départ, le voyageur doit pouvoir recevoir codes de vérification ou push notifications sur une trusted platform, ce qui mitige le spoofing. La social media exige aussi de la vigilance : éviter de révéler des informations exploitables pour pister déplacements ou activités, et désactiver le location-reporting des applications.

11.5 Insider threat, gestion des urgences et MDM

L'insider threat désigne le risque provenant de l'intérieur de l'organisation. Il se matérialise quand une personne disposant d'une connaissance interne et d'autorisations en use, sciemment ou non, au détriment de l'organisation. Des indicateurs existent (comportements préoccupants observables), mais la détection reste difficile, précisément parce que l'acteur est légitime.

En gestion des urgences, une règle prime sur toutes : la sécurité des personnes est la priorité absolue. Tout plan d'urgence et de BCDR doit la placer au sommet ; aucune activité de protection des actifs ne doit mettre le personnel en danger. Le programme de sensibilisation doit couvrir : des systèmes de fire detection/suppression conçus d'abord pour protéger la santé humaine, avec des deluge systems sur toutes les voies d'évacuation et des fire marshals (et suppléants) formés et entraînés par zone ; une évacuation pratiquée régulièrement, tous connaissant sorties et procédures ; une coordination préalable avec les entités externes (forces de l'ordre, pompiers, secours médicaux) pour établir communication et familiarité avant l'événement ; la prise en compte des menaces localisées (catastrophe naturelle, météo) dans le plan et les seuils de déclenchement ; et, si la réponse implique de relocaliser du personnel critique vers un site distant, un budget permettant aussi de relocaliser les familles.

Complément CBK sur les classes de feu : Classe A (combustibles solides ordinaires : bois, papier - extinction par eau), Classe B (liquides/gaz inflammables - CO2 ou clean agents), Classe C (équipements électriques sous tension - surtout PAS d'eau ; CO2 ou clean agent), Classe D (métaux combustibles - agents secs spécifiques), Classe K (huiles et graisses de cuisine - agents chimiques humides). Les agents d'extinction incluent l'eau (dry pipe et wet pipe selon que la tuyauterie est remplie, et pre-action pour limiter les déclenchements accidentels en salle informatique), le CO2 et les FM-200/clean agents qui n'endommagent pas l'électronique.

Enfin, la Mobile Device Management (MDM). Il est déconseillé d'emporter un appareil dans une zone où ses équipements sont menacés : un téléphone coûteux n'est qu'une cible pour le vol, voire saisi ou copié. Mieux vaut acheter un burner phone bon marché et le détruire après usage. Le MDM permet de déployer et contrôler centralement les applications et mises à jour, et surtout de remote wipe (effacer) ou de bricking (rendre totalement inutilisable) un appareil perdu ou volé, selon les besoins de sécurité.