Architecture et ingénierie de la sécurité

1.1 Threat modeling et la mentalité de conception sécurisée

Le point de départ du Domaine 3 est une posture : intégrer la sécurité aussi tôt que possible dans tout processus de conception, de préférence dès la phase d'initiation (initiation phase). Concevoir la sécurité "at the design level and not as an afterthought" permet au système d'opérer aussi efficacement que possible sans prendre de risques inutiles. À l'inverse, ajouter la sécurité aux étapes tardives oblige à modifier la conception existante, ce qui pénalise les performances et fait grimper les coûts.

Le threat modeling (revu au Domaine 1.10) a un rôle à jouer dans chaque phase du cycle de vie, de l'analyse des exigences jusqu'à la détection et la réponse aux attaques en temps réel. Il offre une vue conceptuelle du fonctionnement de la cible en posant deux questions : "What needs protection and what does it need protection from?". En décomposant l'organisation en ses parties (chaque business unit ayant ses propres standards, systèmes et technologies, donc ses propres vulnérabilités), on aligne les menaces possibles sur ces éléments et on identifie plus vite les menaces existantes.

L'idée centrale est d'adopter la mentalité de l'attaquant. Le manuel l'illustre : donnez un téléphone neuf à un utilisateur ordinaire, il pense "What can it do?" ; donnez-le à un acteur malveillant, il pense "What can I make it do?". Comme nous testons spontanément dans notre propre cadre mental, il est essentiel de tester avec d'autres mentalités - malveillantes, mais aussi non averties (uninformed).

Point crucial pour l'examen : le threat modeling est une forme de test qui identifie les systèmes et services critiques et révèle où des vulnérabilités pourraient exister, mais il ne corrige PAS le problème. L'organisation doit ensuite intégrer les résultats dans son processus de remédiation. STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) est la méthodologie de référence pour catégoriser les menaces lors de cet exercice.

1.2 Least privilege, separation of duties et defense in depth

Least privilege consiste à accorder à un utilisateur le minimum de permissions nécessaires pour accomplir sa fonction explicite. Attention au piège : cela ne signifie PAS "peu de permissions". Un administrateur système a besoin d'un compte privilégié pour faire son travail et l'obtient ; un senior VP, pourtant individu de confiance, n'a pas besoin d'un compte privilégié pour faire le sien et ne l'obtient donc pas. Le critère est la fonction, pas le rang ni le degré de confiance.

Separation of duties (SoD) exige qu'une seule personne, un seul processus ou un seul système ne puisse pas accomplir à lui seul un processus sensible. Il faut des checks and balances : au moins deux moyens indépendants de vérifier l'autorisation de l'action et des acteurs. L'objectif est de réduire les possibilités de corruption et de vol. Exemple de la procurement : sans SoD, un manager peut obtenir un devis, créer un bon de commande, émettre un chèque et acheter seul - il peut facilement abuser de la confiance. Avec SoD, un purchasing manager signe le bon de commande, puis seul un comptable peut émettre le chèque après réception de ce bon signé. SoD dégrade nécessairement l'efficacité opérationnelle, mais renforce la sécurité ; elle est souvent efficace, peu coûteuse, et pourtant sous-utilisée.

Defense in depth (DiD), introduit par la NSA, est une approche en couches de la posture de sécurité, parfois appelée castle model : les joyaux de la couronne sont au cœur du château, protégés par des couches successives (gardes, murs, douve). Multiplier les couches dissuade l'attaquant et le pousse vers des cibles plus faciles. Le modèle original définit les couches : Data, Application, Host, Internal network, Perimeter, Physical, et Policies/procedures/awareness (contrôles administratifs contre les menaces internes).

Nuance d'examen : DiD est parfois jugé dépassé à l'ère du cloud, du BYOD et de l'edge/fog computing, et historiquement très vulnérable aux insider threats (au point que certains disent "defense in depth is dead" car trop statique). Comme concept de protection des actifs les plus précieux par couches, il reste utile, mais doit être re-rationalisé pour couvrir tous les types de contrôles - administratifs, techniques et physiques.

1.3 Secure defaults, fail securely et keep it simple

Secure defaults (secure by default) signifie que les paramètres de configuration par défaut du système doivent être les plus sécurisés possibles, même si cela dégrade l'expérience utilisateur. Sécurité et convivialité s'évaluent sur la base d'une analyse de risque et de tests d'utilisabilité, et un équilibre est nécessaire pour préserver les exigences de sécurité tout en atteignant les objectifs métier. Le professionnel doit conseiller et insister sur des secure defaults, qu'il soit du côté du fournisseur (vendor) ou du client (customer).

Fail securely : un système conçu pour échouer de façon sécurisée (fail-secure) basculera par défaut dans un état sécurisé en cas de plantage, réduisant l'exposition potentielle des données et les autres risques. L'approche fail-secure s'impose pour un système à fort potentiel d'exposition. Attention : la sécurité humaine doit être prise en compte. Exemple du manuel : pour les procédures d'évacuation incendie d'un site sensible, la sécurité des personnes prime, même au prix de l'exposition de données sensibles au personnel évacué. C'est l'arbitrage classique fail-secure vs fail-safe à connaître pour l'examen : la vie humaine d'abord.

Keep it simple (KISS) : la sécurité n'a pas à être complexe. Des procédures claires, courtes, directes et faciles à suivre clarifient ce qui est un comportement acceptable et ce qui ne l'est pas ; elles sont plus faciles à exécuter correctement et il est plus difficile de s'y tromper. Les conceptions simples sont aussi plus faciles à tester, valider et dont on peut démontrer l'exactitude (demonstrate correctness), bien davantage que des conceptions complexes et sophistiquées. La complexité est une ennemie de la sécurité.

1.4 Trust but verify, zero trust, privacy by design et shared responsibility

Trust but verify est la posture traditionnelle héritée du DiD : on authentifie l'utilisateur (humain ou non) une seule fois à son entrée dans l'environnement. Une fois authentifié, il peut circuler librement dans le bâtiment, le campus ou les réseaux internes. Les ressources sensibles restent protégées par des permissions et des contrôles d'autorisation, mais sans firewalls ni frontières supplémentaires, aucune nouvelle vérification d'authentification (pour confirmer que l'ID est bien ce qu'il prétend être) n'est effectuée. Beaucoup de petits LAN fonctionnent ainsi.

Zero trust part du constat que, dans un environnement trust but verify, un utilisateur a une fois entré une capacité quasi illimitée de se déplacer, de repérer les actifs et de trouver des vulnérabilités exploitables. En multipliant firewalls et dispositifs de contrôle de frontière à travers le réseau, on augmente le nombre d'occasions de détecter un fauteur de trouble avant qu'il ne nuise. Beaucoup d'architectures poussent cela à l'extrême par la microsegmentation des réseaux internes, qui impose une réauthentification fréquente de l'identifiant utilisateur. C'est la distinction d'examen : trust but verify = une authentification à l'entrée ; zero trust = vérification continue et frontières internes multipliées.

Privacy by design est une approche de conception publiée en 2009 par Ann Cavoukian, alors commissaire à l'information et à la vie privée de l'Ontario (Canada). Elle vise à garantir que le respect de la vie privée est pris en compte tout au long des phases de conception et de développement d'un système. Le concept a été adopté par le GDPR, la FTC américaine, le CPDP et d'autres régulateurs, en phase avec la montée des exigences de confidentialité dans la législation mondiale. Corollaire : privacy by default - les réglages les plus protecteurs de la vie privée sont actifs sans action de l'utilisateur.

Shared responsibility découle de l'essor du cloud : maintenir sécurité et conformité devient une responsabilité partagée entre le fournisseur et le client. Le client ne contrôle pas tout ce qui se passe dans le cloud ; mais on ne peut pas non plus tout mettre sur le fournisseur, car il ne contrôle ni les données stockées ni leur usage. Les deux parties doivent donc faire leur part selon des termes définis. Le contrat (souvent un service-level agreement, SLA) précise quelles responsabilités sont exclusives à chaque partie et lesquelles sont partagées.

1.5 Synthèse : choisir le bon principe de conception

L'objectif 3.1 demande d'expliquer l'importance des principes de conception sécurisée de base. Le "Check Your Understanding" du manuel les liste ensemble : least privilege, defense in depth, secure defaults, fail securely, separation of duties, keep it simple, trust but verify, zero trust, privacy by design et shared responsibility. À l'examen, on vous présente un scénario et vous devez désigner LE principe qui s'applique, pas réciter une définition.

Quelques repères de discrimination. Un utilisateur a trop de droits "au cas où" : least privilege. Un seul acteur peut lancer ET valider un paiement : separation of duties. Un nouvel équipement arrive avec tous les services activés : secure defaults. Un système doit basculer en état sûr en cas de crash, mais sans piéger les personnes : fail securely (avec arbitrage human safety). Une procédure est si alambiquée que les utilisateurs la contournent : keep it simple. L'utilisateur authentifié une fois circule partout : trust but verify ; on veut au contraire le revérifier en permanence et segmenter : zero trust. On veut intégrer la confidentialité dès la conception : privacy by design. Une donnée part chez un fournisseur cloud et il faut clarifier qui sécurise quoi : shared responsibility via le SLA.

Deux idées transverses unifient ces principes. D'abord, la sécurité s'intègre tôt (initiation phase) et par couches : defense in depth donne le cadre, les autres principes en sont des facettes. Ensuite, chaque principe est un compromis assumé : SoD et secure defaults dégradent l'efficacité ou l'expérience utilisateur, mais réduisent le risque - le rôle du professionnel est d'arbitrer ce compromis en connaissance de cause.

2.1 Ce qu'est un modèle de sécurité

Un modèle de sécurité définit des règles de comportement pour un système d'information afin de faire respecter des politiques de sécurité, qui portent typiquement sur la confidentiality, l'integrity, ou les deux. Le modèle fixe le comportement autorisé pour un ou plusieurs aspects du fonctionnement du système. Une fois implémenté, c'est la technologie qui applique ces règles pour garantir l'atteinte des objectifs de sécurité.

Il faut distinguer le modèle de son implémentation. Le modèle est un cadre conceptuel, mathématique : BLP, par exemple, ne définit aucune construction ou solution technique. Il se contente d'énoncer un ensemble de règles de haut niveau qui, correctement implémentées, empêchent l'exposition ou la divulgation non autorisée d'informations dans un système traitant plusieurs niveaux de classification. C'est pourquoi le manuel précise que les systèmes d'exploitation modernes implémentent des éléments de ces modèles, mais jamais de façon parfaite : ils visent une mise en oeuvre pratique cohérente avec un ou plusieurs modèles.

Deux familles structurent ce module. La première regroupe les modèles fondés sur un treillis (lattice-based) à plusieurs niveaux, qui contrôlent les flux d'information entre niveaux de classification ou d'integrity : BLP et Biba en sont les archétypes. La seconde regroupe les modèles qui décrivent comment les sujets, les objets et les droits sont créés, attribués et révoqués au niveau le plus élémentaire, là où les autres modèles supposaient simplement ce contrôle acquis : Graham-Denning et HRU.

À l'examen, la première question à se poser devant un modèle est toujours la même : vise-t-il la confidentiality ou l'integrity ? Cette boussole évite la plupart des erreurs.

2.2 Bell-LaPadula : la confidentiality

Le modèle Bell-LaPadula (BLP) traite la confidentiality dans un système multilevel security (MLS). Il définit deux constructions primaires : les sujets (parties actives) et les objets (parties passives). Les sujets reçoivent des clearances qui définissent les modes d'accès (read, write) qu'ils peuvent employer face aux objets. Le système BLP utilise des labels pour suivre clearances et classifications, et applique un jeu de règles limitant les interactions sujet-objet. C'était un modèle précoce : il ne fournit pas de correspondance un-à-un entre sujets et objets individuels, ce qui est pourtant un prérequis pour bâtir un système d'exploitation pratique.

BLP définit trois propriétés. La Simple Security property (SS) : un sujet ne peut pas lire ou accéder à un objet de classification supérieure, soit no read up. La Star property (notée *) : un sujet ne peut sauvegarder ou écrire que vers un objet de classification égale ou supérieure, soit no write down. La Strong Star property : un sujet ne peut écrire que vers des objets de même niveau de classification que lui, soit écriture latérale uniquement (no write down ET no write up).

La logique est intuitive une fois la confidentiality posée comme objectif. Interdire le no read up empêche un sujet peu habilité de lire un secret au-dessus de son niveau. Interdire le no write down empêche un sujet habilité de recopier un secret vers un niveau inférieur où des sujets moins habilités le liraient. BLP ne définit pas de constructions techniques : il énonce des règles de haut niveau qui, bien implémentées, préviennent l'exposition ou la divulgation non autorisée d'informations dans un système à niveaux multiples.

Les noms de ces propriétés, comme la Star (*), viennent du calcul des prédicats et de la théorie des ensembles, où ils s'appliquent à des ensembles comme des opérateurs mathématiques. À l'examen, retenez le couple BLP = confidentiality = no read up / no write down.

2.3 Biba : l'integrity, miroir de BLP

Le modèle Biba traite l'integrity des données ; il ne traite pas la confidentiality. Comme BLP, c'est un modèle lattice-based à niveaux multiples, qui décrit des interactions entre sujets et objets. Une différence de vocabulaire : Biba parle d'observe et modify là où BLP parle de read et write. Surtout, Biba assigne des niveaux d'integrity aux sujets et objets selon leur degré de confiance (trustworthiness), au lieu des niveaux de confidentiality de BLP. Le coeur du modèle est une approche multiniveau de l'integrity destinée à empêcher des sujets non autorisés de modifier des objets, et à maintenir l'état d'integrity courant des objets quand les sujets interagissent avec eux.

Biba définit trois propriétés. La Simple Integrity property (simple integrity axiom) : un sujet ne peut lire ou observer un objet d'integrity inférieure, soit no read down. La Star property (*) : un sujet ne peut modifier un objet d'integrity supérieure, soit no write up. La Invocation property : un sujet de niveau d'integrity inférieur ne peut demander l'accès à un objet d'integrity supérieure ; il ne peut s'adresser qu'à des objets de niveau égal ou inférieur.

Le contraste avec BLP est l'élément le plus testé. BLP protège la confidentiality : no read up, no write down. Biba protège l'integrity : no read down, no write up. Les règles sont inversées parce que les objectifs le sont. En integrity, lire vers le bas (no read down) éviterait qu'un sujet de haute integrity se contamine avec une donnée peu fiable ; écrire vers le haut (no write up) éviterait qu'un sujet peu fiable corrompe un objet de haute integrity. La Strong Star de BLP n'existe pas dans Biba, et l'Invocation property n'existe pas dans BLP.

Mnémonique : pour l'integrity, on ne lit pas plus bas que soi (on ne se salit pas) et on n'écrit pas plus haut que soi (on ne salit pas les autres).

2.4 Clark-Wilson et Brewer-Nash

Biba ne couvre qu'un seul des trois objectifs clés de l'integrity. Le modèle Clark-Wilson l'améliore en visant l'integrity au niveau transactionnel et en adressant trois grands objectifs d'integrity en environnement commercial. Pour le deuxième objectif, Clark et Wilson ont compris qu'il fallait empêcher des sujets autorisés de faire des modifications indésirables. Cela imposait que les transactions d'un sujet autorisé soient évaluées par une autre partie avant d'être validées dans le système : c'est la separation of duties, le pouvoir du sujet autorisé étant limité par un autre sujet habilité à évaluer et finaliser la transaction.

Pour la cohérence interne du système, Clark et Wilson recommandent une définition stricte des well-formed transactions : l'ensemble des étapes d'une transaction doit être soigneusement conçu et appliqué, et toute déviation du chemin attendu provoque l'échec de la transaction afin que l'integrity ne soit pas compromise. Pour contrôler toutes les interactions sujet-objet, le modèle établit un système de liens sujet-programme-objet (l'access triple) : le sujet n'a plus d'accès direct à l'objet ; il passe par un programme qui arbitre tous les accès, authentifie et identifie le sujet, et limite l'accès aux objets sous son contrôle. Chaque interaction suit alors un ensemble de règles défini.

Le modèle Brewer and Nash, ou Chinese Wall, vise un autre problème : prévenir le conflit d'intérêt quand un sujet accède à des objets d'informations sensibles appartenant à deux parties concurrentes. Le principe est qu'un utilisateur ne doit pas accéder aux informations confidentielles d'un client ET d'un de ses concurrents. Au départ, le sujet peut accéder à l'un ou l'autre ensemble d'objets ; mais dès qu'il accède à un objet lié à un concurrent, il est instantanément empêché d'accéder à tout objet du camp opposé, pour éviter qu'il ne partage l'information de façon inappropriée, même involontairement.

Ces murs éthiques (ethical walls) sont fréquents dans les services financiers, par exemple pour isoler le conseil d'entreprise du courtage et réduire l'opportunité comme la tentation d'abuser d'informations privilégiées. Brewer-Nash est inhabituel : ses règles de contrôle d'accès changent selon le comportement du sujet (les accès déjà effectués).

2.5 Graham-Denning et HRU : la gestion des droits

Là où BLP et Biba supposent que le contrôle des sujets et objets est acquis, le modèle Graham-Denning s'intéresse précisément à la façon dont les sujets et objets sont créés, dont les droits (rights ou privileges) sont attribués aux sujets, et dont la propriété (ownership) des objets est gérée. Il décrit le contrôle des sujets et objets au niveau le plus élémentaire.

Le modèle Graham-Denning comporte trois parties : un ensemble d'objets, un ensemble de sujets et un ensemble de droits. Un sujet se compose de deux choses : un processus et un domaine ; le domaine est l'ensemble des contraintes contrôlant comment les sujets peuvent accéder aux objets. Un sujet peut aussi être un objet à certains moments. L'ensemble des droits gouverne comment les sujets manipulent les objets passifs. Le modèle décrit huit droits de protection primitifs, appelés commandes, que les sujets exécutent pour influencer d'autres sujets ou objets. Les huit règles de base sont : créer des objets de façon sûre, supprimer des objets de façon sûre, créer des sujets de façon sûre, supprimer des sujets de façon sûre, provisionner les droits de read de façon sûre, provisionner les droits de grant access de façon sûre, provisionner les droits de delete access de façon sûre, et provisionner les droits de transfer access de façon sûre.

Le terme primitive protection rights y joue le rôle des permissions ou privileges d'autres modèles. Exemple : la suppression d'un objet est une action réalisée par un sujet (souvent via une tâche, un processus ou une autre entité logicielle) ; le système de contrôle d'accès ne doit pas l'autoriser sauf si le sujet en a le droit. Que ce droit soit accordé pour tous les objets, un sous-ensemble, ou objet par objet, dépend du modèle de contrôle d'accès choisi (DAC ou MAC, vus en Domaine 5).

Le modèle Harrison-Ruzzo-Ullman (HRU) est très proche de Graham-Denning : il comprend un ensemble de droits génériques et un ensemble fini de commandes, et s'intéresse aussi aux situations où l'on doit empêcher un sujet d'obtenir des privilèges particuliers, en l'empêchant d'accéder aux programmes ou sous-routines qui exécutent une commande donnée (par exemple accorder un accès en read).

3.1 Sélectionner et adapter les standards au contexte

La section 3.3 part d'une idée simple : on sélectionne des contrôles d'ingénierie système qui servent le contexte de l'organisation. Le mécanisme tient en deux temps. D'abord, on choisit des standards appropriés comme point de départ ; ensuite, on les adapte (tailoring) au contexte propre de l'organisation. Ce double mouvement donne confiance que l'organisation suit un chemin mature qui sert sa mission, plutôt que d'appliquer aveuglément un catalogue générique.

La security engineering elle-même est définie comme l'usage de méthodes d'ingénierie généralement acceptées pour appliquer des théories de sécurité système à des situations, problèmes ou besoins spécifiques, de façon pratique et efficace. Deux autorités la reconnaissent comme une specialty engineering discipline du systems engineering : l'International Council on Systems Engineering (INCOSE) et le NIST.

Le piège classique : penser qu'un standard se déploie tel quel. Non - le standard est un point de départ, le tailoring le rend pertinent pour le contexte (mission, contraintes, risque). C'est exactement la même logique que scoping/tailoring vue ailleurs dans le cursus : on part d'une baseline reconnue, puis on ajuste.

3.2 Sources de standards d'ingénierie de sécurité

La section 3.3 énumère des sources communément acceptées d'ingénierie et d'ingénierie de sécurité. Le INCOSE Systems Engineering Handbook présente les principes du systems engineering en termes d'affordability et de performance, dans le contexte de structures de gestion de projet formelles et informelles.

NIST SP800-160 (Systems Security Engineering) traite des actions engineering-driven nécessaires pour développer des systèmes plus sûrs et survivables, y compris les composants qui les composent et les services qui en dépendent. Il part d'un ensemble de standards internationaux établis pour le systems and software engineering (publiés par l'ISO, l'IEC et l'IEEE) et y infuse des techniques, méthodes et pratiques de systems security engineering. C'est le sens précis de engineering-driven : la sécurité est intégrée dans les activités d'ingénierie, pas ajoutée après.

Deux familles ISO complètent le tableau. ISO/IEC 15026 (série Systems and Software Engineering) se concentre sur l'assurance, l'intégrité et les concepts de sécurité des systèmes et logiciels. ISO/IEC/IEEE 15288 fournit un modèle global de cycle de vie d'ingénierie système ; c'est un prolongement de modèles antérieurs issus de divers standards militaires américains. Piège d'examen : ne pas confondre 15026 (assurance/intégrité/sécurité) et 15288 (modèle de cycle de vie global).

3.3 Les processus d'ingénierie de sécurité selon SP800-160

NIST SP800-160 définit des processus généraux d'ingénierie de sécurité, cohérents avec le INCOSE Systems Engineering Handbook et facilement reliables aux standards ISO, à quelques différences mineures près. Ils se rangent en quatre familles.

Les Technical Processes traitent le système lui-même : business and mission analysis (comprendre le scope et les conséquences de perte d'actifs), stakeholder needs and requirements definition, system requirements definition, architecture definition, design definition, system analysis, implementation, integration et verification (produire des preuves que le système satisfait ses exigences de sécurité avec le niveau d'assurance qui s'applique). Les Technical Management Processes pilotent le projet : project planning, project assessment and control, decision management, risk management (identifier, analyser, traiter et surveiller les risques de sécurité), configuration management, information management, measurement et quality assurance.

Les Enabling Processes soutiennent l'organisation : life cycle model management, infrastructure management, portfolio management, human resources management, quality management et knowledge management. Enfin, les Agreement Processes encadrent les relations contractuelles : l'acquisition process garantit que les besoins de protection de l'acquéreur sont couverts par ses exigences ; le supply process garantit que le produit ou service fourni offre les fonctions de sécurité tout en respectant les contraintes exprimées par l'acquéreur. Piège : reconnaître à quelle famille appartient un processus donné (ex : configuration management = Technical Management ; acquisition = Agreement).

3.4 Change management, configuration management, policies et models

Le manuel insiste d'emblée : l'ingénierie, comme discipline, embrasse le change management et le configuration control. Quelle que soit l'activité d'ingénierie, elle tourne autour de la gestion de l'information sur le système qu'on fait advenir. Les besoins de mission ou métier en matière de safety, security, reliability et performance dictent (ou devraient dicter) le degré de détail et de formalisme de ces processus de change management. Le management doit déterminer le bon dosage entre change management formel et flexibilité/réactivité, selon la stratégie globale de gestion du risque.

Dans le cas WLDR University présenté par le manuel, le configuration management est ad-hoc entre les groupes IT du campus : pas de configuration standard, ni de capacité à déployer rapidement des contrôles en cas d'incident. La réponse attendue est d'implémenter des processus de configuration management pour garantir la configuration sécurisée de tous les systèmes et équipements réseau selon leurs exigences propres.

Enfin, security policies, models et architecture s'articulent dans le développement. Les systèmes démarrent en général par des énoncés de besoins métier ou de mission, souvent exprimés sous forme de policies. Une security policy définit ce que « sécurité » signifie pour un système donné, ce qui reflète presque toujours un compromis entre sécurité, opérabilité, coût et impact de risque. Les models représentent l'expérience acquise en construisant des systèmes similaires (équations, diagrammes de flux, séquences de tâches) ; les ingénieurs s'en servent comme points de départ pour élaborer itérativement une architecture du système désiré.

3.5 Critères d'évaluation historiques : TCSEC et ITSEC

Avant les standards internationaux actuels, deux familles de critères d'évaluation ont structuré la façon de noter la confiance d'un produit de sécurité. Le Trusted Computer System Evaluation Criteria (TCSEC), surnommé Orange Book, a été publié par le département de la Défense américain. Il repose sur le modèle de confidentialité Bell-LaPadula et évalue avant tout la protection de la confidentialité d'un système d'exploitation multi-utilisateurs. Son défaut majeur : il mélange fonctionnalité et assurance dans une même note, et n'aborde ni l'intégrité ni la disponibilité.

Le TCSEC classe les systèmes en divisions hiérarchiques. La division D désigne une protection minimale (échec à l'évaluation). La division C couvre la protection discrétionnaire avec C1 (discretionary security protection) et C2 (controlled access protection). La division B couvre la protection obligatoire (mandatory) avec B1 (labeled security protection), B2 (structured protection) et B3 (security domains). La division A, avec A1 (verified design), exige une conception vérifiée formellement. Le Red Book, ou Trusted Network Interpretation (TNI), étend ces idées aux réseaux, là où l'Orange Book ne couvrait que les systèmes isolés.

L'Information Technology Security Evaluation Criteria (ITSEC) est la réponse européenne. Son apport décisif est de séparer ce que le TCSEC confondait : d'un côté la fonctionnalité (functionality), notée F1 à F10, qui décrit ce que le produit fait ; de l'autre l'assurance (assurance), notée E0 à E6, qui décrit la confiance dans le fait qu'il le fait correctement. ITSEC traite aussi la confidentialité, l'intégrité et la disponibilité, là où le TCSEC se limitait à la confidentialité.

Piège d'examen : retenir que TCSEC = confidentialité seule, fonction et assurance mélangées, basé sur Bell-LaPadula ; ITSEC = fonction (F) ET assurance (E) séparées, européen, CIA complet. Le Red Book n'est pas un niveau mais l'extension réseau du TCSEC.

3.6 Common Criteria (ISO/IEC 15408)

Le Common Criteria (CC), standardisé sous ISO/IEC 15408, remplace et unifie les approches nationales antérieures, dont le TCSEC américain et l'ITSEC européen. Son objectif est de fournir un langage commun et reproductible pour évaluer la sécurité des produits IT, et de permettre une reconnaissance mutuelle des évaluations entre pays signataires via le Common Criteria Recognition Arrangement (CCRA) : un produit évalué dans un pays est reconnu dans les autres, ce qui évite de répéter l'évaluation.

Le vocabulaire du CC est central pour l'examen. La Target of Evaluation (TOE) est le produit ou système soumis à évaluation. Le Protection Profile (PP) exprime des besoins de sécurité génériques, indépendants d'un produit, formulés côté client ou côté communauté d'utilisateurs : c'est la demande (« voici ce dont une classe de produits a besoin »). Le Security Target (ST) est rédigé côté vendeur : il contient les revendications de sécurité d'un produit précis et explique comment celui-ci satisfait, le cas échéant, un ou plusieurs PP. C'est l'offre (« voici ce que mon produit fait »).

Le contenu des revendications se décompose en deux types d'exigences. Les Security Functional Requirements (SFR) décrivent les fonctions de sécurité attendues (ce que fait le produit). Les Security Assurance Requirements (SAR) décrivent les activités de vérification menées pour gagner confiance dans ces fonctions (à quel point on a vérifié). Cette séparation fonction/assurance hérite directement de l'esprit d'ITSEC.

Le niveau d'assurance global est résumé par un Evaluation Assurance Level (EAL), sur sept échelons : EAL1 (functionally tested), EAL2 (structurally tested), EAL3 (methodically tested and checked), EAL4 (methodically designed, tested, and reviewed), EAL5 (semiformally designed and tested), EAL6 (semiformally verified design and tested) et EAL7 (formally verified design and tested). Piège central : un EAL mesure la RIGUEUR de l'évaluation (l'assurance), pas la quantité de fonctionnalités ni une sécurité absolue. Un EAL élevé sur un PP faible ne garantit pas un produit sûr en valeur absolue.

3.7 Certification, accréditation et Authorization to Operate (ATO)

Évaluer un produit avec le Common Criteria ne suffit pas à autoriser sa mise en service dans une organisation : il faut un processus de décision. Ce processus repose sur deux étapes que l'examen oppose souvent. La certification est l'évaluation technique : on vérifie de façon détaillée que les contrôles de sécurité d'un système satisfont un ensemble d'exigences donné, dans un contexte d'exploitation précis. La certification produit des preuves, pas une décision.

L'accreditation (ou authorization) est l'acte managérial qui suit : une autorité désignée, l'Authorizing Official (AO), examine les résultats de certification et le risque résiduel, puis accepte formellement ce risque au nom de l'organisation. C'est une décision de gestion du risque, pas une analyse technique. Le piège classique inverse les deux : la certification regarde la technique, l'accreditation accepte le risque. Sans accreditation, un système certifié n'est pas autorisé.

Le NIST Risk Management Framework (RMF) encadre aujourd'hui cette logique pour les systèmes fédéraux américains, avec ses étapes (catégoriser, sélectionner, implémenter, évaluer, autoriser, surveiller). L'étape « autoriser » débouche sur une décision formelle de l'AO appelée Authorization to Operate (ATO). Trois issues sont possibles : un ATO accordé (le système peut être mis en service), un ATO conditionnel (autorisation accordée sous réserve de corriger certaines faiblesses dans un délai défini, parfois via un plan d'action), ou un denial of authorization to operate (refus : le risque résiduel est jugé inacceptable et le système ne doit pas opérer).

Enfin, une autorisation n'est jamais éternelle. Le RMF impose une surveillance continue (continuous monitoring) et une réévaluation périodique : changements significatifs du système, de l'environnement de menace ou expiration de l'autorisation déclenchent une nouvelle évaluation et une nouvelle décision de l'AO. Piège : l'ATO n'est pas un blanc-seing permanent ; il est conditionné dans le temps et révisable.

4.1 Modèles de sécurité conceptuels : state machine, information flow, noninterference

Au fil du temps, les concepteurs ont employé différents security models qui mettent l'accent sur des propriétés de sécurité distinctes. Beaucoup s'appuient sur les concepts de subjects et d'objects : un subject est un processus qui exécute des actions sur un object, et un object peut être un ensemble de données, une ressource matérielle ou logicielle, ou une personne - ce qui signifie qu'un object peut lui-même être un subject.

Le state machine model identifie l'état initial du système et l'état final dans lequel il doit se trouver une fois un processus terminé. Exemple du manuel : une security policy peut exiger que la copie d'un object n'introduise aucune déviation par rapport à l'original ; comparer un secure hash de l'original et de la copie démontre que l'opération a respecté cette policy.

L'information flow model étend le state machine model en se concentrant sur le mouvement de l'information à travers le système. Il décrit comment les privileges accordés aux subjects contraignent leur accès aux objects et les transformations qu'ils peuvent appliquer à ces objects. La sécurité s'évalue donc en termes de flux autorisés ou interdits, pas seulement d'états.

Le noninterference model garantit que les objects et subjects d'un niveau de sensibilité n'interagissent pas de façon inappropriée avec ceux d'autres niveaux. Chaque tentative d'accès aux données est indépendante des autres et approuvée, le cas échéant, par la security architecture. Surtout, les outputs du système ne doivent pas divulguer les security decisions ni les inputs qui les ont générés : un processus de login ne doit pas révéler les valeurs saisies (login ID, password) dans l'authentification qui résulte d'un login réussi.

4.2 Protection rings et processor states (Ring 0 à Ring 3)

Le ring model met l'accent sur les interactions entre les capacités de sécurité du matériel sous-jacent et leur usage par les couches logicielles. Selon le matériel, le logiciel et la conception du système, un nombre différent de rings peut être nécessaire ; dans beaucoup de cas, quatre rings suffisent. La figure du manuel présente le ring model du point de vue logiciel : les couches matérielles et leur firmware gravé sont contenues dans le Ring 0.

L'isolation des processus augmente à mesure que le logiciel s'exécute loin du Ring 0. De plus, chaque fois qu'une service request franchit une frontière de ring, la requête doit être évaluée au regard de la security policy pour déterminer si elle est appropriée. Ainsi, la demande d'une application de sauvegarder un fichier en stockage reçoit plus de scrutin de l'OS et du security kernel qu'une décision de l'OS de récupérer des emplacements mémoire inutilisés.

Ring 0 héberge les fonctions les plus sensibles de l'OS, typiquement des fonctions « trusted » soumises à une supervision limitée ; le security kernel surveille l'opération globale de l'OS et peut terminer le traitement en cas de compromission suspectée (l'écran bleu de Windows en est une manifestation). Ring 1 héberge les device drivers à accès direct au matériel, souvent soumis à une certification pour répondre aux exigences de sécurité de l'OS. Ring 2 offre de meilleures performances et capacités que les applications de Ring 3, pour des tâches réservées aux utilisateurs à privilèges étendus (formater des disques, établir des connexions réseau) ou pour des services rendus aux applications (par exemple des API de messagerie).

Ring 3 est l'endroit où s'exécutent les applications ; une isolation stricte des processus et une autorisation rigoureuse des service requests doivent y être imposées. L'échec d'une application en Ring 3 n'affecte pas les autres processus ni les fonctions système, et le système peut se rétablir proprement. Attention : ces exemples ne sont qu'illustratifs - certaines implémentations supportent quatre rings mais n'utilisent pas les Rings 1 et 2, ou réservent le Ring 1 aux tâches d'hyperviseur. Le modèle théorique ne décrit pas toujours pleinement un environnement donné, et en tirer parti exige une implémentation à la fois matérielle et logicielle. Ces niveaux reposent sur les processor states : des privileged mode instructions peuvent altérer directement l'état du matériel ou d'une tâche, via des flag bits spéciaux du CPU indiquant le niveau de privilège de la tâche courante.

4.3 Fondations système : memory management, isolation, virtualisation et sandboxing

Dès les années 1960, les ingénieurs sécurité avaient identifié une liste de fonctionnalités critiques pour bâtir des systèmes capables de respecter leur security policy. Ces éléments d'architecture ont une double nature : ils représentent des security policies de bas niveau que les composants doivent posséder, et ils offrent des design templates de haut niveau pour atteindre le comportement requis.

Les capacités natives attendues de tout élément destiné à un système sécurisé incluent : le memory management (usage efficace de la RAM, support de la mémoire virtuelle et ségrégation des espaces code/données d'une tâche) ; les abstraction layers, qui empêchent la logique d'une couche d'interférer avec ou d'observer le détail d'une autre, découplant la conception et facilitant la maintenance ; l'isolation et la ségrégation code/données, imposées par le matériel et l'OS, qui empêchent un processus de lire ou écrire dans l'espace code ou données d'un autre, empêchent l'exécution d'instructions chargées en espace données et l'écriture d'instructions dans un espace code (même le leur) ; les file systems attributes (read-only, execute-only) associant des permissions protectrices aux objects (sous Unix/Linux, tout device est traité comme un fichier) ; et le security kernel, qui surveille tous les programmes en exécution, y compris les OS, pour détecter erreurs ou alarmes annonçant une brèche, et peut forcer le programme dans un état sûr, l'arrêter, voire éteindre le système.

Une fois ces fonctionnalités présentes, des extensions vitales s'ajoutent. L'access control authentifie les requêtes de connexion d'un subject ou autorise l'accès aux objects, avec un accounting détaillé des actions tentées. Les virtual machines encapsulent un système opérationnel entier, interfaces vers périphériques et réseaux comprises ; les fonctionnalités de sécurité et de virtualisation du matériel et de l'OS imposent alors l'isolation requise des processus, données et devices.

Les sandbox environments tirent parti de la virtualisation pour un test et une évaluation isolés, qu'il s'agisse de systèmes en développement ou de malware suspecté. Enfin, les cryptographic systems renforcent l'isolation code/données, fournissent des digital signatures pour le code et les données, et protègent code et données at rest, in transit ou in use, via une combinaison d'éléments matériels et logiciels. Chacun de ces éléments d'architecture se rattache à un ou plusieurs security models.

4.4 Racines de confiance matérielles : TPM et HSM

Le Trusted Platform Module (TPM) est un type particulier de hardware security module (HSM) conçu pour être intégré dans d'autres produits et conforme à un standard spécifique du Trusted Computing Group. La plupart des serveurs et des appareils utilisateur - mais pas tous - peuvent être obtenus avec une puce TPM.

La spécification TPM impose que le module inclue : une génération de clés sécurisée (secure key generation), un stockage sécurisé (secure storage), des algorithmes de hachage, un générateur de nombres aléatoires (random number generator) et un cryptoprocesseur embarqué (onboard cryptoprocessor) capable d'exécuter les fonctions définies par le standard. La désignation TPM nécessite en outre une clé d'identité unique au device (device-unique identity key) servant à l'identification de l'appareil.

Le terme TPM désigne strictement un module conforme au standard TPM. De nombreux autres fabricants créent des modules équivalents appelés secure elements, secure enclaves ou termes similaires. Exploiter les facilités de stockage de clés et les fonctions cryptographiques de la puce TPM permet d'accélérer les traitements et de renforcer la posture de sécurité d'un appareil. Le HSM est la catégorie plus large : un module matériel dédié à la sécurité cryptographique (génération, stockage et usage protégés des clés), dont le TPM est une variante normalisée et intégrée. Cette racine de confiance matérielle ancre les capacités cryptographiques évoquées dans les leçons précédentes et sera approfondie dans les sous-domaines consacrés à la cryptographie.

4.5 Trusted Computing Base, reference monitor et security kernel

La trusted computing base (TCB) regroupe l'ensemble des composants - matériels, logiciels et firmware - critiques pour la sécurité d'un système : ce sont eux qui font respecter la security policy. Tout ce qui se trouve dans la TCB est de confiance, car sa défaillance pourrait compromettre la policy entière ; tout ce qui est hors TCB n'a pas besoin de l'être. La frontière qui sépare la TCB du reste du système est le security perimeter. Garder la TCB petite et bien définie est un objectif de conception majeur : plus elle est réduite, plus on peut la vérifier et la protéger.

Le reference monitor est un concept abstrait : c'est la composante qui médie TOUS les accès des subjects vers les objects. Aucune référence à un object ne doit échapper à son contrôle. Trois propriétés classiques sont exigées de lui : complete mediation (il est toujours invoqué - always invoked - et ne peut être contourné), tamperproof (il est isolé et protégé contre toute modification non autorisée), et verifiable (il est suffisamment petit et simple pour être analysé, testé et démontré correct - small enough to test). Le mnémonique NEAT des Common Criteria, proche mais distinct, énumère pour sa part quatre exigences : Non-bypassable, Evaluable, Always invoked, Tamperproof.

Le security kernel est l'implémentation concrète du reference monitor au sein de la TCB : c'est l'ensemble des mécanismes matériels, firmware et logiciels qui appliquent effectivement la médiation des accès. Là où le reference monitor est l'idée, le security kernel est le code et le circuit. C'est lui qui, en Ring 0, surveille et fait respecter les décisions d'accès. La distinction est un piège d'examen récurrent.

Même un système doté d'une TCB bien conçue peut fuir de l'information par des covert channels : des canaux de communication non prévus par la conception. Un storage covert channel transmet de l'information en écrivant dans un emplacement de stockage (un attribut de fichier, un secteur disque) lu par un autre processus ; un timing covert channel module le timing d'un événement observable (temps de réponse, utilisation CPU) pour signaler des bits à un complice. Les covert channels contournent la médiation normale et sont un thème classique des modèles de confiance.

4.6 Secure boot, measured boot et trusted execution

La sécurité d'un système commence avant même le chargement de l'OS : si la chaîne de démarrage est compromise (bootkit, firmware malveillant), toutes les protections logicielles bâties au-dessus deviennent caduques. D'où la notion de root of trust : un composant de confiance, idéalement ancré dans le matériel, à partir duquel la confiance se propage de proche en proche le long de la chaîne de démarrage (chain of trust).

Le secure boot vérifie la signature numérique de chaque composant de la chaîne de démarrage avant de l'exécuter. Dans l'écosystème UEFI, le firmware ne charge un bootloader, puis un noyau, que si leur signature correspond à une clé de confiance enregistrée dans le firmware. Un composant non signé ou modifié est refusé : secure boot empêche l'exécution de code non approuvé. Point clé : secure boot VÉRIFIE des SIGNATURES et bloque ce qui ne correspond pas ; il ne conserve pas nécessairement une trace de ce qui a été chargé.

Le measured boot, lui, MESURE : il calcule le hash de chaque étape (firmware, bootloader, noyau, drivers) et étend les Platform Configuration Registers (PCR) du TPM avec ces mesures. Le measured boot ne bloque rien en soi ; il produit un enregistrement cryptographique fiable de l'état de démarrage. Cet enregistrement permet la remote attestation : la machine peut prouver à un tiers (serveur d'attestation, contrôle d'accès réseau) que sa chaîne de démarrage est dans un état connu et approuvé, en présentant les valeurs des PCR signées par le TPM. C'est le lien direct avec le TPM vu à la leçon précédente.

Le trusted execution environment (TEE) prolonge l'idée au temps d'exécution : c'est une enclave isolée du reste du système, où code et données sensibles s'exécutent à l'abri même d'un OS compromis. Intel SGX (enclaves applicatives) et ARM TrustZone (mondes secure/normal) en sont les exemples canoniques. Le TEE s'appuie sur une root of trust matérielle pour garantir confidentialité et intégrité du code qui s'y exécute. Ensemble, root of trust, secure boot, measured boot et TEE forment une chaîne de confiance continue, du démarrage à l'exécution.

5.1 Systèmes client, serveur et distribués

Les systèmes client-based sont traditionnellement les endpoints par lesquels les utilisateurs accèdent aux services centralisés : postes de travail, ordinateurs portables, terminaux de point de vente ou appareils personnels. On les qualifie de thick ou thin selon la complexité des applications et de l'OS qu'ils exécutent localement ; un thick client dispose de stockage et de connectivité propres. La ligne entre thick et thin est floue et mouvante. Ces clients héritent des vulnérabilités de leur matériel, OS et applications (malware, mauvais usage, accidents) et sont exposés au vol ou à la perte, mettant en danger les données résiduelles. Leur exploitation peut servir de tremplin pour attaquer les serveurs auxquels ils se connectent. Les mitigations relèvent de la gestion d'endpoints : anti-malware et IDS/IPS sur l'hôte, endpoint management combiné au MDM pour gérer correctifs et perte/vol, et protections réseau (segmentation, firewalls, IDS) qui isolent client et réseau l'un de l'autre.

Les systèmes server-based remplissent une fonction précise (serveurs d'application, de fichiers, d'impression, DNS). Ils sont centralisés, à accès limité, et traitent un débit de données bien supérieur à un poste de travail, ce qui génère des volumes de logs massifs à analyser. Un piège majeur : on les laisse souvent en service de longues années, parfois avec des logiciels hors support, faute de redondance permettant de les arrêter pour appliquer les correctifs - même critiques. Être connecté au réseau les expose à des attaques distantes ; l'accès physique au serveur et à son fabric d'interconnexion ouvre une gamme quasi illimitée d'attaques, tout comme la chaîne logistique. La mitigation clé pour les serveurs non migrés vers le cloud est l'ajout de redondance abordable, qui supprime le besoin de différer les arrêts de maintenance et réduit donc le délai entre réception et application d'un correctif.

Dans un environnement distribué, nœuds et processeurs opèrent indépendamment ; stockage et traitement sont répartis sur plusieurs composants qui se synchronisent par messagerie. Presque toutes les formes de cloud sont des systèmes distribués, tout comme le peer-to-peer. Ils offrent souvent une forte redondance (réplication géographique des données) et un load balancing dynamique procurant une dégradation gracieuse en cas de panne. Leurs vulnérabilités : les systèmes distribués simples peuvent manquer de capacités de monitoring et de contrôle pour détecter à temps les pannes ou compromissions, et de contrôle d'accès suffisant pour gérer plusieurs niveaux de classification. La mitigation consiste à renforcer contrôle d'accès, monitoring de santé et IDS si l'infrastructure le permet ; sinon, à isoler physiquement, logiquement et administrativement le système distribué.

5.2 Bases de données : aggregation, inference, polyinstantiation

Un système de base de données s'articule autour d'un DBMS (database management system) et des ressources de calcul et de stockage qui l'hébergent. Il peut tourner sur un endpoint, un thick client, des serveurs ou des clusters, et la plupart fonctionnent aujourd'hui en environnement cloud ou distribué. Une base hérite des vulnérabilités de sa plateforme et y ajoute des vulnérabilités propres : entrées malformées (malformed inputs), déni de service, et contournement des contrôles d'accès. Comme elles contiennent de grandes quantités d'informations de valeur et exigent un débit transactionnel élevé, les bases sont des cibles de très haute valeur.

L'aggregation est l'assemblage de plusieurs éléments d'information, chacun non sensible pris isolément, dont la combinaison révèle une information sensible. Un utilisateur ayant un accès légitime à plusieurs champs anodins peut, en les agrégeant, reconstituer un secret auquel il n'aurait pas droit. L'inference est plus subtile : le sujet déduit une information sensible à partir d'informations auxquelles il a accès, par raisonnement, sans jamais y accéder directement. Le piège classique d'examen est de confondre les deux : l'aggregation combine des données pour atteindre un total sensible ; l'inference déduit ce qui n'est pas explicitement présent.

La polyinstantiation est la contre-mesure phare contre l'inference (et l'aggregation déductive). Elle consiste à autoriser plusieurs instances (versions) d'un même enregistrement, différenciées par le niveau de classification du sujet qui le consulte. Un utilisateur de bas niveau voit une version plausible mais factice, tandis que l'enregistrement réel reste réservé au niveau habilité. En présentant des valeurs divergentes selon l'habilitation, la polyinstantiation empêche le sujet de bas niveau de déduire l'existence ou la valeur de la donnée classifiée, et de détecter une incohérence qui trahirait un secret.

5.3 ICS/SCADA, systèmes embarqués et IoT

Les industrial control systems (ICS) surveillent et contrôlent les machines industrielles et les infrastructures critiques. Pour eux, les exigences de sûreté (safety) priment souvent sur celles de sécurité (security). Vus du haut vers le bas, ils comportent trois composants : le SCADA (supervisory control and data acquisition), assemblages d'équipements event-driven qui automatisent des processus géographiquement distribués (réseau électrique, oléoducs, traitement de l'eau, rail) ; les DCS (distributed control systems), confinés à une zone ou usine et orientés processus ; et les PLC (programmable logic controllers), contrôleurs industriels durcis temps réel pilotant capteurs et actionneurs. Les vulnérabilités propres aux composants embarqués des ICS : fonctionnalité et protection limitées, longue durée de vie (10 à 20 ans), forte sensibilité au DoS et aux mauvaises entrées, et surtout des attaques pouvant produire des effets physiques sur le monde réel. Ils sont souvent non surveillés en sites distants. Mitigations : infrastructure réseau isolée (air gaps ou firewalls), restrictions de connexion et monitoring, réseaux fortement segmentés ou microsegmentés (zero trust), canaux protégés et contrôle de configuration robuste.

Les systèmes embarqués sont des microcontrôleurs intégrés directement dans des dispositifs mécaniques, électriques ou hydrauliques (automobiles, avions, appareils médicaux, électroménager). La frontière avec les ICS est floue : un ICS contient souvent des systèmes embarqués, et l'ICS lui-même peut être embarqué. Leur risque opérationnel est élevé : leur défaillance peut rendre le système hôte inopérant, et leur code réside parfois en mémoire morte non mise à jour. Vulnérabilités : erreurs de programmation, interfaces web exposées, authentification faible ou credentials codés en dur, mauvaise cryptographie, reverse engineering, malware et eavesdropping. Stuxnet a démontré la capacité d'attaquants sophistiqués à cibler ces systèmes. Mitigations : intégration au cadre de gestion des risques avec inventaire complet, patching dans la limite du support, secure coding, et third-party risk management car ils proviennent souvent de produits fournisseurs.

L'IoT prolonge la miniaturisation des systèmes embarqués couplée à la connectivité sans fil ubiquitaire. Ces appareils, du simple capteur d'état au dispositif calibré avec implications safety-of-life, ne sont plus isolés sur leurs propres réseaux et présentent donc une surface d'attaque élargie. Vulnérabilités : DoS aggravé par la dépendance aux protocoles sans fil (standards faibles ou propriétaires) et le transit multi-infrastructures ; sécurité physique du dispositif (vol, data remanence, reverse engineering, manipulation de l'environnement surveillé) ; et limites cryptographiques, tous les appareils n'ayant pas la puissance de calcul nécessaire.

5.4 Cloud : modèles de service, caractéristiques essentielles, VM sprawl

Assurer la sécurité d'un service cloud suppose d'évaluer chaque élément de l'organisation et de la technologie du fournisseur (CSP). Pour rester efficient, on s'appuie sur des audits standards menés par des tiers accrédités, en complétant selon les besoins propres. NIST définit le cloud comme un modèle d'accès réseau à la demande à un pool partagé de ressources configurables, provisionnables et libérables rapidement avec un effort de gestion minimal ; la définition ISO/IEC 17788 est similaire. NIST énonce cinq caractéristiques essentielles : on-demand self-service, broad network access, resource pooling (multi-tenant), rapid elasticity et measured service. ISO/IEC 17788 reprend les cinq et ajoute une sixième : multi-tenancy, où ressources physiques ou virtuelles sont allouées et contrôlées de sorte que le traitement et les données de différents tenants soient isolés et inaccessibles entre eux. C'est ce point que vise le Quiz Q3.

Les modèles de service décrivent la part de gestion entre CSP et consommateur. NIST identifie trois modèles, ISO/IEC 17789 quatre catégories ; les trois premiers coïncident. En SaaS, le consommateur utilise l'application du fournisseur sans gérer l'infrastructure sous-jacente. En PaaS, il déploie ses propres applications créées avec les langages et outils du fournisseur, sans gérer l'infra mais en contrôlant ses applications. En IaaS, il provisionne calcul, stockage et réseau pour exécuter un logiciel arbitraire (y compris les OS), avec contrôle sur OS, stockage et applications. Cette gradation définit la responsabilité partagée : plus on descend vers IaaS, plus la part du consommateur grandit. ISO/IEC 17789 ajoute NaaS (Network as a Service), et l'offre s'étend à IDaaS, SECaaS, CaaS, CompaaS, DSaaS. Les modèles de déploiement (private, community, public, hybrid, plus GovCloud) décrivent quant à eux les relations métier.

Trois vulnérabilités cloud méritent l'attention : l'exposition accrue aux communications externes ; la misconfiguration, car beaucoup d'organisations manquent de compétences et présument à tort que le CSP couvre toute la sécurité, alors que le consommateur reste responsable de son propre stockage et traitement ; et le fait de devenir outdated, le SLA devant clarifier ce que le CSP maintient et ce qui revient au consommateur. Côté virtualisation, le VM sprawl (image management) est un piège classique : sans mécanismes de contrôle et politiques, des images VM peuvent être chargées et laissées actives, copiées vers d'autres zones ou exfiltrées (Quiz Q2). Autres vulnérabilités : VM escape (un acteur exploite des credentials d'une VM pour attaquer l'environnement), faiblesses matérielles de l'hyperviseur (type Meltdown/Spectre) et knowledge gap. Mitigations : change management appliqué aux VM et IAM granulaire (RBAC/ABAC) protégeant l'hyperviseur des workloads de production.

5.5 Conteneurs, microservices et serverless

La conteneurisation fournit une couche de services OS partagés pour réduire la taille et la complexité des VM individuelles en environnement cloud. Elle diminue les ressources nécessaires, raccourcit le temps de démarrage d'un processus et standardise les OS. Des technologies open-source comme Docker et Kubernetes côtoient des approches propriétaires ; l'adoption a été rapide grâce à la portabilité des conteneurs entre clouds. Vulnérabilités : images non sécurisées (une image de base vulnérable rend le conteneur vulnérable), conteneurs au privilège excessif (flag privileged), communication non restreinte entre conteneurs, processus malveillants et isolation insuffisante vis-à-vis de l'hôte. Mitigations : image management (limiter le nombre et la configuration des images contre l'image sprawl), immutable infrastructure (ne jamais patcher une instance en cours d'exécution mais régénérer depuis une master image), granular security (privilèges minimaux par conteneur), microsegmentation et firewalls, et configuration correcte par du personnel formé, d'autant que les plateformes évoluent constamment.

Les microservices sont une implémentation de l'architecture orientée services (SOA) pour le cloud : des protocoles légers transportent l'information entre applications très isolées. Convertir une application en microservices revient à découper un gros programme en objets gérés comme threads d'exécution séparés, selon le principe « faire une seule chose et bien la faire ». Avantages : maintenance simplifiée (périmètre limité par service), conversion de traitements batch en temps réel sans refonte totale, et scaling dynamique bien plus aisé que sur des systèmes monolithiques. Vulnérabilités : authorization (un microservice mal développé tourne souvent à privilège élevé par commodité, dangereux s'il est compromis), quality of service (un microservice mal structuré consomme plus de ressources, ex. lancer une VM entière pour un service éphémère) et DoS (la dépendance aux protocoles légers comme REST expose toute faiblesse du protocole). Mitigations : services d'authentification/autorisation (OAuth 2.0, SAML) avec least privilege sur les comptes de service, exécution en conteneurs ou serverless, et API gateways pour protéger l'accès.

L'architecture serverless étend les responsabilités du CSP pour abstraire entièrement l'infrastructure physique et logique. Souvent appelée Function as a Service (FaaS), elle rend le CSP responsable de l'élasticité, réallouant les ressources selon la charge. Les services sont accédés comme des fonctions réagissant à des événements (autres fonctions, requêtes externes, mise à jour de fichier, entrée de log, transaction BDD), souvent via une API gateway. Newcomer du cloud, beaucoup de ses schémas d'attaque rejoignent ceux des autres architectures (le sujet est détaillé par la Cloud Security Alliance). Vulnérabilités spécifiques : injection malveillante dans la fonction (entrées malformées causant DoS ou divulgation), configuration non sécurisée (options multipliées par les fournisseurs pour se différencier) et cross-execution data persistency (données conservées entre exécutions non protégées ni purgées). Mitigations : former le personnel à la configuration de l'environnement fournisseur et appliquer un secure coding avec tests statiques, dynamiques et interactifs.

5.6 Edge vs fog computing, HPC et systèmes distribués

Pour que le cloud offre des ressources virtualisées à coût réduit, l'information doit migrer vers le data center, ce qui impose une forte latence et soulève des enjeux de confidentialité. Le edge et le fog computing rapprochent le traitement des sources de données pour y répondre. Le fog computing place une couche de ressources de calcul plus près des sources d'entrée, fournissant hébergement applicatif et gestion des dispositifs, et optimise ainsi le déplacement de l'information vers le cloud. Le edge computing englobe aussi les endpoints, souvent des systèmes embarqués, au bord du réseau ; d'abord à emplacements fixes, il intègre désormais des appareils mobiles via le sans-fil.

La distinction, formalisée par NIST SP 500-325, porte sur le niveau de traitement. Le fog est hiérarchique : il exécute des applications dans une architecture multi-couches qui découple et maille les fonctions matérielles et logicielles, permettant des reconfigurations dynamiques, et il adresse en plus du calcul et du réseau le stockage, le contrôle et l'accélération du traitement. Le edge, lui, exécute des applications spécifiques en un emplacement logique fixe et fournit un service de transmission directe, limité à un petit nombre de dispositifs périphériques. Le piège d'examen (Quiz Q5) : fog = hiérarchique et multi-couches ; edge = local, fixe, peu de dispositifs. Leurs vulnérabilités : compromission réseau (le edge dépend fortement du réseau ; DoS et coupure physique de connectivité) et surface d'attaque accrue (multiplier les dispositifs augmente le risque qu'un seul mal configuré serve de tête de pont). Mitigations : monitoring réseau et réponse à incident renforcés, et inventaire/responsabilité durcis pour limiter le sprawl et les dispositifs rogue ou obsolètes.

Le high-performance computing (HPC) répond aux problèmes exigeant bien plus de ressources que la normale : modélisation d'explosions nucléaires, du changement climatique ou de séismes, via un nombre massif de processeurs travaillant simultanément. Longtemps réservé aux agences gouvernementales, il est désormais offert commercialement, souvent couplé au cloud, en maximisant l'usage productif des ressources - ce qui peut conduire à compromettre certains contrôles de sécurité traditionnels pour gagner en performance. Les défis particuliers portent sur l'intégrité et la disponibilité. Vulnérabilités : contraintes de latence (les outils traditionnels IDS/IPS ou firewalls imposeraient un coût de latence inacceptable aux processus parallèles) et improper workloads (un HPC compromis peut voir son temps consommé par des charges non autorisées, comme le supercalculateur russe détourné pour miner du Bitcoin en 2018). Mitigations : conception architecturale appropriée (enclaves de calcul sécurisées, détection au périmètre pour compenser des contrôles internes réduits) et monitoring/logging adaptés malgré leur coût en calcul. Enfin, les systèmes distribués (vus en L1) sous-tendent presque toutes ces architectures cloud et restent un fil conducteur transverse.

6.1 Vocabulaire et fondements : du plaintext au cryptosystem

Au coeur de tout système de chiffrement, on transforme un jeu de données original, le plaintext, en une forme inintelligible, le ciphertext. Le plaintext peut être n'importe quoi de représentable numériquement (fichiers exécutables, images, requêtes, enregistrements de base de données) : ce n'est pas forcément du texte humainement lisible. Attention à ne pas confondre plaintext avec cleartext, qui désigne une information laissée volontairement en clair (par exemple les en-têtes de paquets IP).

Un encryption system (ou cryptosystem) est l'ensemble du matériel, des logiciels, des algorithmes, des paramètres de contrôle et des méthodes opérationnelles qui fournissent les services de chiffrement. L'algorithm est la méthode de transformation ; la key (clé) est le paramètre secret qui paramètre cette méthode. Les anciens cryptographes appelaient ces paramètres les cryptovariables d'un système : la clé est la cryptovariable par excellence.

Le work factor est l'effort qu'un attaquant doit dépenser pour casser le chiffrement. Il est lié à la taille de la clé : une clé de 16 bits définit un key space de 65 536 valeurs, une clé de 256 bits un nombre à 78 chiffres en base 10. Mais la taille seule ne suffit pas : Elliptical curve cryptography fournit une force comparable avec une clé bien plus courte. La force de clé résulte donc de la combinaison de la longueur de clé ET de l'algorithme.

Deux principes fondateurs encadrent la discipline. Le principe de Kerckhoffs : un système bien conçu doit rester sûr même si tout, sauf la clé, est connu de l'adversaire ; la security by obscurity est par nature défaillante. Le corollaire de Claude Shannon (1949) le résume : the enemy knows your system. On ne peut protéger que les clés, et c'est précisément ce qu'il faut faire.

6.2 Encoding vs encryption vs hashing

Ces trois transformations sont régulièrement confondues à l'examen, alors qu'elles répondent à des besoins distincts. L'encoding (encodage) est une simple correspondance de symboles vers des nombres ou un autre format : associer A=0, B=1 ... Z=25, ou utiliser un jeu de caractères comme Unicode-8 ou Unicode-16. L'encodage ne vise PAS le secret : il est réversible sans clé et n'apporte aucune confidentialité ni intégrité.

L'encryption (chiffrement) transforme le plaintext en ciphertext à l'aide d'un algorithme ET d'une clé. Elle vise la confidentialité (et, selon les schémas, contribue à l'authenticité ou à la non-répudiation). Elle est réversible UNIQUEMENT avec la bonne clé : c'est la possession de la clé qui distingue celui qui peut déchiffrer de celui qui ne le peut pas.

Le hashing (hachage) applique une fonction à sens unique qui produit, à partir d'un message de longueur quelconque, une sortie de longueur fixe appelée message digest. Le hachage ne utilise PAS de clé cryptographique (même si on parle de hachage cryptographique) et n'est pas réversible : il vise l'intégrité, pas la confidentialité. On vérifie l'intégrité en recalculant le digest et en le comparant : un seul bit modifié change le digest.

Deux propriétés sont essentielles. Le hachage doit être collision resistant : il doit être difficile de trouver deux entrées différentes produisant le même digest. Et il doit être deterministic : une même entrée produit toujours le même digest. De façon symétrique, le chiffrement doit garantir l'absence de collisions (deux plaintexts distincts donnent deux ciphertexts distincts) et un déchiffrement déterministe (un ciphertext ne donne qu'un seul plaintext).

6.3 Chiffrement symétrique : DES, 3DES, AES, modes et one-time pad

Le chiffrement symétrique utilise la même clé pour chiffrer et déchiffrer ; le déchiffrement est simplement l'inverse exact du chiffrement. Tous les algorithmes classiques sont symétriques et combinent souvent substitution (remplacer des bits par d'autres selon une cryptovariable) et transposition (changer la position des bits). Deux caractéristiques d'architecture définissent ces systèmes : block versus stream. Un système stream chiffre un symbole à la fois ; un système block traite des groupes de longueur fixe (la taille de bloc se mesure typiquement en octets de 8 bits).

L'histoire des standards éclaire l'examen. Le Data Encryption Standard (DES), soumis par IBM, est adopté en 1977 comme standard fédéral pour les documents non classifiés. Sa clé trop courte (56 bits) l'a condamné : 3DES (Triple DES) a prolongé DES mais devait être retiré (vers 2023 selon NIST). NIST a lancé la compétition Advanced Encryption Standard (AES) en 2000 ; en novembre 2001, FIPS 197 approuve une variante de l'algorithme Rijndael. AES reste le seul algorithme cryptographique publié publiquement capable de protéger des données classifiées jusqu'au niveau top-secret aux États-Unis.

D'autres algorithmes symétriques sont à connaître : Blowfish et Twofish (Bruce Schneier), RC4 (stream, utilisé dans WEP et SSL/TLS, banni de TLS par la RFC 7465 en 2015), RC5 et RC6 (Ron Rivest, paramétrables), IDEA (clé 128 bits, blocs 64 bits), CAST et SAFER (variante utilisée comme block cipher dans Bluetooth). Le running key cipher illustre l'usage de l'arithmétique modulaire : Ciphertext = plaintext + key (modulo 26) pour l'alphabet latin.

Le one-time pad (chiffre de Vernam) est le seul système considéré incassable s'il est correctement implémenté : la clé est aussi longue que le message, parfaitement aléatoire et utilisée une seule fois. Les session keys utilisées sur internet sont une forme de one-time pad. Avantages du symétrique : rapide, léger, économe en mémoire. Inconvénients majeurs : il dépend totalement d'une infrastructure de génération et de distribution de clés, et il ne peut, seul, assurer ni l'intégrité ni la non-répudiation.

6.4 Chiffrement asymétrique : RSA, ECC, Diffie-Hellman-Merkle, ElGamal

Le chiffrement asymétrique utilise un algorithme et une clé fondamentalement différents pour chiffrer et déchiffrer. Il repose sur des trapdoor functions (fonctions à trappe ou à sens unique) : faciles à calculer dans un sens, extrêmement coûteuses dans l'autre. Deux familles de problèmes mathématiques sous-tendent les algorithmes courants : les discrete logarithms (utilisés par ECC, ElGamal, Diffie-Hellman-Merkle et d'autres) et le prime factoring (factorisation de très grands nombres premiers, utilisé uniquement par RSA).

Chaque partie dispose d'une key pair : une private key gardée secrète et une public key diffusable librement. Le principe est celui du zéro connaissance préalable : deux parties sans secret commun peuvent malgré tout établir un secret partagé. Diffie, Hellman et Merkle publièrent en 1976 le premier algorithme d'échange de clés fondé sur ce principe (brevet 1977, désormais expiré). RSA (Rivest, Shamir, Adleman, 1977) offre chiffrement ET signatures, et fournit non-répudiation, intégrité et authentification de la source. ElGamal s'appuie sur Diffie-Hellman mais ajoute confidentialité et signatures.

Elliptic Curve Cryptography (ECC) possède la plus haute force par bit de longueur de clé de tous les algorithmes asymétriques. Cette propriété est centrale à l'examen : ECC obtient une sécurité équivalente avec des clés bien plus courtes. À titre d'exemple du manuel, une classification top-secret demande une clé ECC de 384 bits là où RSA exige 7680 bits. D'où l'intérêt d'ECC pour les smart cards, le sans-fil et tout contexte limité en puissance, bande passante ou stockage.

Avantages de l'asymétrique : il résout le problème de distribution des clés (échange sur un canal non fiable sans partage préalable), il passe bien à l'échelle (chaque partie n'a besoin que de sa key pair) et il apporte non-répudiation, contrôle d'accès et intégrité. Inconvénient majeur : il est très lent, donc impraticable pour chiffrer de grandes quantités de données (inefficace au-delà d'environ 64 Ko). On le réserve à l'intégrité, l'authentification et la non-répudiation.

6.5 Chiffrement hybride et le problème du nombre de clés

Aucune des deux familles n'est idéale seule : le symétrique est rapide mais peine à distribuer ses clés, l'asymétrique distribue bien mais est lent. Le chiffrement hybride combine les forces des deux. Le schéma type : on utilise le chiffrement asymétrique pour produire et transporter une session key, qui sert ensuite à chiffrer symétriquement le contenu pour cette session uniquement. SSL et TLS sont des systèmes hybrides ; presque tout utilisateur d'internet en invoque les services à chaque page sécurisée.

Déroulé concret (Alice vers Bob) : Alice chiffre le message avec une clé symétrique, sans se soucier de la taille puisque le symétrique est rapide. Elle produit un ciphertext message (CTM). Pour transmettre la clé symétrique sur un canal non fiable, elle la chiffre avec la public key de Bob, produisant un ciphertext key (CTK). Bob déchiffre le CTK avec sa private key, récupère la clé symétrique, puis déchiffre le CTM. On obtient ainsi la rapidité du symétrique ET la sécurité de distribution de l'asymétrique.

Le problème du nombre de clés explique pourquoi le symétrique seul ne passe pas à l'échelle. Dans un système purement symétrique, chaque paire d'utilisateurs a besoin de sa propre clé unique. Pour N utilisateurs, le nombre de clés requis est N(N-1)/2. La croissance est quadratique : une organisation de 10 000 utilisateurs aurait besoin de près de 500 millions de clés, un cauchemar de gestion. L'asymétrique résout ce problème : chaque partie n'a besoin que de sa propre key pair, soit une croissance linéaire.

Un dernier point opérationnel : la distribution des clés se fait soit in-band (sur le même canal que le trafic chiffré), soit out-of-band (par un autre moyen). Historiquement, beaucoup de systèmes dits military-grade n'ont pas été cassés en attaquant les clés elles-mêmes, mais en subvertissant le processus de distribution. C'est un risque dans les deux cas, et cela rappelle que la sécurité réside dans la gestion des clés, pas dans le secret de l'algorithme.

6.6 Hachage, collisions et génération de nombres aléatoires

Une fonction de hachage applique une opération à sens unique qui produit, à partir d'un message de longueur quelconque, un message digest de longueur fixe. Recalculer le digest sur une copie et le comparer permet de vérifier l'intégrité : si un seul bit a changé, le digest diffère. Les fonctions de hachage n'utilisent pas de clé cryptographique ; elles sont renforcées par des générateurs de nombres aléatoires via des seed values (graines) ou des salt values (sels).

Une fonction de hachage doit satisfaire cinq exigences : être uniformly distributed (sortie imprévisible), collision resistant (difficile de trouver deux entrées donnant le même digest), impossible to invert (irréversible), computed on the entire message (calculée sur tout le message), et deterministic (même entrée, même sortie). La collision est le risque central : deux messages produisant le même digest. Augmenter la taille du digest améliore la résistance aux collisions.

Exemples d'algorithmes à connaître : MD5 (Rivest, 1992, digest 128 bits) est désormais déconseillé car des collisions y sont calculables, ce qui le rend impropre aux communications sûres et aux signatures. SHA-1 (NIST, digest 160 bits) est plus robuste que MD5 mais a lui aussi subi des attaques en collision. La famille SHA-2 (SHA-224 à SHA-512) offre des digests de 224 à 512 bits ; SHA-3 (2015) a une structure très différente et peut se substituer à SHA-2 si nécessaire.

Les Random et Pseudorandom Number Generators (RNG/PRNG) sont une source récurrente de problèmes. La plupart des processus cryptographiques s'appuient sur des nombres aléatoires comme seeds, salts ou autres cryptovariables, pour la génération de clés comme pour les fonctions de hachage. Or un logiciel ne peut produire de vrai hasard : un PRNG ne fournit qu'une suite à probabilité d'occurrence raisonnablement aléatoire. Les vulnérabilités des PRNG (clumping, prévisibilité de la prochaine valeur) ont causé de nombreux exploits. Les implémentations matérielles exploitent des phénomènes physiques (bruit thermique, désintégration radioactive, impacts de rayons cosmiques) pour s'approcher du vrai aléatoire.

7.1 Signatures numériques et non-répudiation

Une signature numérique est un bloc de données produit en deux temps : on hache d'abord le message avec une fonction de hachage, ce qui donne un condensé (message digest) dépendant du contenu ; on chiffre ensuite ce condensé avec la clé privée de l'émetteur. C'est ce condensé chiffré qui constitue la signature. Elle est ajoutée au message en clair (non chiffré) et envoyée au destinataire.

À la réception, le vérificateur déchiffre la signature avec la clé publique de l'émetteur pour récupérer le condensé d'origine, puis recalcule lui-même le condensé du message reçu et compare bit à bit. S'ils correspondent, trois propriétés sont établies en même temps : l'intégrité (le message n'a pas été altéré, même d'un seul bit), l'authentification de la source (seul le détenteur de la clé privée a pu produire la signature) et la non-répudiation (l'émetteur ne peut pas nier avoir signé).

Il faut bien distinguer signer de chiffrer. Signer ne protège PAS la confidentialité : le message reste lisible, et n'importe qui possédant la clé publique de l'émetteur peut déchiffrer le condensé. Pour obtenir confidentialité ET preuve d'origine, on imbrique deux opérations (on signe avec sa clé privée, puis on chiffre le tout avec la clé publique du destinataire). La non-répudiation au sens strict exige des signatures numériques : le chiffrement symétrique seul ne peut pas la fournir, car la clé est partagée.

La non-répudiation rend trois services : empêcher l'émetteur de nier l'envoi, vérifier l'intégrité, et empêcher le destinataire de prétendre avoir reçu un message différent. Le NIST a publié FIPS 186-4 (Digital Signature Standard, DSS) qui normalise la terminologie et les algorithmes approuvés. Les usages sont nombreux : mises à jour logicielles signées par l'éditeur et validées par un trusted installer, pilotes signés, smart contracts, documents et contrats, processus apostille/notario, et préservation de la chain of custody en investigation numérique.

7.2 PKI : CA, RA, VA et chaîne de confiance

Une clé publique n'est qu'une chaîne de nombres : en soi, elle n'a aucun lien avec une personne ou une organisation. Le problème est donc d'assurer de façon fiable qu'une clé publique correspond bien à la clé privée du signataire et à son identité. La public key infrastructure (PKI) résout cela : elle publie les clés publiques liées à une entité, certifie qu'une clé publique est rattachée à un individu ou une organisation, et vérifie qu'une clé publique est valide et correcte. Le coeur de la PKI est son mécanisme de certificats.

L'autorité de certification (certificate authority, CA) est le tiers de confiance qui atteste qu'un propriétaire de certificat possède bien une clé publique donnée. Pour cela, la CA signe numériquement le certificat de l'entité avec sa propre clé privée. Il y a une root CA dans un système PKI ; elle peut déléguer son autorité à des CA subordonnées pour partager la charge d'émission et de validation. Cette délégation établit une hiérarchie de confiance : un utilisateur fait confiance à une CA subordonnée parce que cette confiance remonte, in fine, jusqu'à la root CA. C'est la chaîne de confiance.

L'autorité d'enregistrement (registration authority, RA) accepte et valide les informations d'identification soumises par un utilisateur qui demande une clé publique et un certificat. La RA peut faire partie de l'équipe de la CA ou être une organisation distincte ; elle ne signe pas les certificats. Une autre entité, l'autorité de validation (validation authority, VA), fournit l'authentification de la validité d'un certificat (qu'il n'a pas expiré ni été révoqué).

La PKI repose sur la confiance accordée à la CA. Le cas DigiNotar (2011) illustre le risque : un attaquant a émis des dizaines de faux certificats, utilisés pour des attaques man-in-the-middle contre des utilisateurs de Gmail en Iran. Quand une CA racine est compromise, c'est toute la confiance dérivée qui s'effondre, obligeant navigateurs et organisations à publier des correctifs d'urgence et à mettre à jour les listes de révocation. La PKI utilise l'algorithme de négociation de clés Diffie-Hellman-Merkle pour permettre à deux parties de dériver un secret partagé (session key) sans le transmettre.

7.3 Certificats X.509 v3 et révocation

Le standard X.509 de l'UIT, qui fait partie de la famille X.500 applicable aux annuaires, définit comment émettre des certificats, leur contenu, ainsi que leurs processus d'expiration et de révocation ; il définit aussi comment vérifier qu'une clé publique appartient bien au propriétaire du certificat. La version 3 de X.509 est la plus utilisée aujourd'hui.

Un certificat X.509 contient notamment : l'algorithme utilisé pour la signature, le nom de l'émetteur (nom X.500 de la CA), la période de validité (dates de début et de fin), le nom du sujet (propriétaire de la clé publique), les informations de clé publique du sujet (clé, algorithme, paramètres), des identifiants uniques optionnels d'émetteur et de sujet, un champ Extensions qui autorise des extensions définies par l'utilisateur (user-defined extensions) - caractéristique clé de la v3 - et enfin la signature numérique de la CA, c'est-à-dire le hash du certificat chiffré avec la clé privée de la CA.

Un certificat émis peut devenir non fiable : par exemple si le souscripteur a falsifié son identité auprès de la CA, ou si le titulaire pense que sa clé privée a été perdue ou compromise. Dans ce cas la CA révoque (invalide définitivement) le certificat et publie un avis de révocation. Les motifs typiques sont : clé compromise, changement de finalité, cessation d'activité ou changement de nom de l'organisation.

Deux mécanismes de révocation coexistent. La certificate revocation list (CRL) est une liste de certificats révoqués que le client télécharge périodiquement depuis la CA pour comparer les numéros de série ; son défaut est la taille croissante (bande passante, latence), si bien que de nombreux navigateurs ne la supportent plus par défaut. L'online certificate status protocol (OCSP) interroge la CA pour un seul certificat et renvoie un statut (good, revoked, unknown ou code d'erreur) ; plus efficace que la CRL, il n'est cependant pas pleinement sûr - vulnérable au man-in-the-middle et susceptible d'introduire des délais.

7.4 Cycle de vie des clés, escrow et recovery

La gestion des clés (key management) couvre tout ce qui touche à la génération, l'enregistrement, la transcription, la distribution, l'installation, le stockage, le changement et l'usage des clés, jusqu'à l'élimination des matériels et des équipements qui en conservent des traces. C'est le contrôle total des clés cryptographiques. D'après le principe de Kerckhoffs, l'algorithme est public : ce sont les clés qui font la force du système. C'est pourquoi la gestion des clés est l'activité la plus critique - les attaques contre les clés sont bien plus probables et plus efficaces que celles contre les algorithmes. Trois corpus la cadrent : NIST SP 800-57 (pratiques de gestion, gouvernance, détails d'implémentation en Parties 1 à 3), ISO 11770 (génération, stockage, distribution, suppression, archivage du matériel de clés) et ANSI X9.24 pour les banques et institutions financières.

Le cycle de vie suit des étapes. Génération : de préférence par des systèmes automatisés qui garantissent des clés fortes et l'application de la politique ; la qualité des générateurs de nombres aléatoires (RNG/PRNG) est critique car des seeds ou salts prévisibles affaiblissent tout. Stockage : modules matériels (HSM) inviolables, smart cards protégées par passphrase, key wrapping des clés de session avec des KEK, fractionnement et stockage en lieux séparés, certains dispositifs s'autodétruisant en cas d'attaque. Distribution : il faut acheminer la clé sans qu'un tiers ne la déduise (key distribution problem) ; on protège la clé de session avec une key encrypting key (KEK) par key wrapping, in-band (même canal que le trafic chiffré) ou out-of-band (autre canal). Expiration : toute clé doit avoir une date d'expiration pour limiter le temps offert à la cryptanalyse. Révocation puis destruction : en fin de cycle, la clé doit être détruite de façon à empêcher sa reconstruction ; les archives chiffrées exigent toutefois que les clés restent disponibles et soutenues par des certificats valides tant que les données ont de la valeur.

La session key est une clé symétrique éphémère, à usage unique pour une session (une forme de one-time pad) ; on la génère de préférence automatiquement, par négociation entre points d'extrémité (Diffie-Hellman-Merkle, KINK). Réutiliser une session key trop longtemps la met en péril : trop de chiffrement avec la même clé facilite l'attaque. À la fin, les session keys doivent être détruites pour empêcher leur récupération.

Key recovery est un mécanisme de secours assurant à l'organisation un accès continu à ses propres données chiffrées si une clé est perdue ou endommagée. Le key escrow en est une forme : les clés sont déposées (vaulted) auprès d'un tiers de confiance ou d'une RA. La multiparty key recovery découpe une clé en plusieurs parts confiées à des entités distinctes (dual control). Attention : un mécanisme de récupération imposé par un gouvernement (backdoor ou lawful code breaking) signifie que l'algorithme n'est plus sûr pour tous, ce qui a été largement rejeté.

8.1 Attaques sur la clé et l'algorithme

Les attaques fondées sur le chiffré (ciphertext-based) commencent par collecter des copies de messages chiffrés interceptés en transit. La quasi-totalité des supports (radio, réseaux numériques, RTC, voire documents imprimés) se laisse intercepter et copier, souvent sans trace. Leurs deux buts : révéler le clair protégé et retrouver la clé.

Le ciphertext-only attack est l'un des plus difficiles car l'attaquant ne dispose que de données inintelligibles qu'il soupçonne d'être un message chiffré important. Il devient plus simple en accumulant assez de chiffré pour chercher des motifs et des statistiques. La frequency analysis est ici décisive : elle exploite les fréquences connues des lettres et des mots d'une langue (en anglais, le « e » domine, « the » est le trigramme le plus courant). Décrite dès le 9e siècle par Al-Kindi, elle reste l'arme de prédilection contre les chiffrements par substitution.

Le known plaintext attack suppose que l'attaquant possède à la fois le clair et le chiffré d'un même message. Comme l'algorithme est toujours réputé connu, le but est de trouver la relation entre les deux : la clé. Une clé trouvée déchiffre tous les messages chiffrés avec elle. Le chosen plaintext attack va plus loin : l'attaquant choisit le clair et obtient le chiffré correspondant, en connaissant l'algorithme ou en disposant du cryptosystème. Sa variante adaptative laisse modifier les entrées de façon répétée. L'exemple historique : la ruse de Midway en 1939-1945, où la Navy a fait émettre en clair un faux message (« Midway manque d'eau douce ») pour confirmer que « AF » désignait Midway.

Le chosen ciphertext attack est le symétrique : l'attaquant accède au dispositif de déchiffrement et soumet des chiffrés choisis pour observer les clairs et déduire la clé ; la version adaptative permet de modifier le chiffré avant chaque passage (lunchtime attacks, à très faible work factor). Enfin, linear cryptanalysis (un known plaintext utilisant une approximation linéaire du block cipher) et differential cryptanalysis (un chosen plaintext qui introduit de petites variations du clair pour observer les variations du chiffré) ciblent directement la structure de l'algorithme ; combinées, elles augmentent les chances de succès. L'algebraic attack exploite, elle, la structure mathématique de certains block ciphers.

8.2 Attaques sur l'implémentation

Les implementation attacks sont aujourd'hui parmi les plus courantes et populaires, car elles sont faciles et s'appuient sur des éléments du système EXTÉRIEURS à l'algorithme. Souvent, la faiblesse n'est pas dans la mathématique mais dans la manière dont la cryptographie est mise en oeuvre.

Le brute force attack essaie une clé après l'autre dans le key space en espérant tomber sur la bonne avant d'y passer trop de temps. Plus la clé est longue, plus le key space (nombre de valeurs possibles) explose, et plus le work factor monte : au-delà de 128 bits, l'attaque devient souvent impraticable. Pourtant la sécurité d'une grande clé est trompeuse : des PRNG faibles qui agglutinent les clés, le cracking massif via VM/botnets dans le cloud, une mauvaise gestion des clés de session, des faiblesses connues des algorithmes, la chance pure, l'informatique quantique et le social engineering réduisent tous le work factor réel. La dictionary attack et la rainbow table (table de hachés précalculés et triés) accélèrent fortement l'attaque des fichiers de mots de passe hachés mal protégés. Le factoring attack vise spécifiquement RSA en factorisant le produit de grands nombres premiers, et les travaux de Shor (1994) suggèrent que le quantique le rendrait redoutable.

Les side channel attacks sont des attaques passives exploitant un attribut PHYSIQUE de l'implémentation (consommation électrique, émanations électromagnétiques). Le timing attack mesure les variations de durée des opérations pour deviner la structure interne et réduire l'espace de recherche ; sa défense type est de PADDER les messages à une longueur standard pour que toutes les opérations s'exécutent en temps constant, indépendamment du secret traité. Le probing attack observe (ou modifie) la circuiterie autour du module cryptographique pour en extraire des indices sur la clé ou l'algorithme.

La fault analysis attack force le système en état d'erreur, puis compare les résultats erronés aux résultats sains pour deviner la clé. La fault injection injecte des données fautives connues, ou, sur du matériel, du bruit sur les lignes d'entrée/sortie/alimentation, voire des ondes radio dans les circuits. L'attacking the random number generator exploite un RNG trop prévisible pour anticiper les vecteurs d'initialisation. Enfin, les temporary files : tout cryptosystème écrit des fichiers temporaires ; s'ils ne sont pas effacés et écrasés de façon sécurisée après chaque opération, ils peuvent être lus et compromettre la cryptanalyse.

8.3 Attaques sur le système et l'humain

Tout cryptosystème, comme tout contrôle de sécurité, repose en dernier ressort sur des humains pour être implémenté et exploité correctement. C'est l'une des plus grandes vulnérabilités. Le social engineering est l'usage de la tromperie ou de l'intimidation (coercition, corruption, déception) pour obtenir d'une personne des informations qu'elle n'est pas autorisée à divulguer, sans moyen technique. Historiquement, c'est l'attaque la plus EFFICACE contre les systèmes cryptographiques, et elle reste centrale dans le plan d'une menace persistante avancée (APT). La compromission de RSA en 2011 le prouve : deux courriels de phishing, un classeur Excel exploitant une vulnérabilité zero-day d'Adobe Flash, un backdoor installé, puis le réseau de plusieurs sous-traitants de défense américains touché, et environ 66 millions de dollars pour remplacer tous les tokens SecurID. La seule défense est une vigilance permanente : awareness, education, training.

Le birthday attack s'appuie sur le paradoxe des anniversaires : dans un groupe de 23 personnes, la probabilité que deux partagent la même date dépasse 50%. Appliqué au hachage, il cherche deux messages produisant le MÊME message digest (une collision). L'idée clé : il est bien plus facile de trouver DEUX messages qui collisionnent que de trouver un message correspondant à un digest donné (préimage). Les experts le considèrent comme un type de brute force, car l'attaquant hache des messages jusqu'à obtenir une collision ; les bons algorithmes de hachage y résistent au maximum.

La man-in-the-middle (MITM) attack insère un tiers hostile dans le canal entre émetteur et destinataire pour intercepter, altérer les données, ou se faire passer pour l'un auprès de l'autre, en restant indétecté. Idéalement, l'attaquant s'insère AVANT le début de session : une demande de clé publique peut être détournée en renvoyant sa propre clé publique. Elle vise systèmes symétriques, asymétriques et hybrides. La replay attack rejoue des fichiers ou entrées capturés pour perturber le traitement ; sans horodatage, jetons à usage unique ou codes de séquence, le système traite des doublons et accorde un accès. Le pass the hash en est une déclinaison : NTLM/SMB passaient autrefois les identifiants en clair, puis des hachés moissonnés et rejoués lors d'un handshake challenge-réponse (TGS/TGT inclus).

Enfin, le ransomware et les ransom attacks : entre 2016 et 2018, ils ont augmenté de plus de 350% et sont reconnus comme la deuxième menace après les insiders. La réponse repose sur quatre familles de stratégies : Denial (sauvegardes saines et vérifiées, anti-malware, formation), Detection (surveillance comportementale, signatures, leurres), Containment (empêcher la propagation et la réinfection) et Response and recovery (la décision stratégique majeure : payer ou non, à décider AVEC le conseil juridique avant l'incident, car payer un acteur sous sanctions peut engager une strict liability). Certaines attaques sont « living off the land », sans malware dédié (par ex. Bitlocker détourné).

9.1 CPTED et conception du site

Le CPTED (Crime Prevention through Environmental Design) aborde le crime par des moyens organisationnels (les personnes), mécaniques (technologie et matériel) et naturels (architecture et flux de circulation). Sa logique est passive : en dirigeant le flux des personnes, en signalant par des indices discrets qui doit ou ne doit pas se trouver dans un espace, et en donnant de la visibilité aux zones autrement cachées, on réduit la probabilité qu'un délit y soit commis. Le CPTED s'associe au concept des broken windows : là où la négligence règne, le crime augmente ; à l'inverse, un espace ordonné et entretenu décourage les mauvais comportements.

Trois principes structurent l'approche. La surveillance naturelle (natural surveillance) rend les zones visibles - éclairage, surtout autour des portes, et lignes de vue dégagées - pour que tout comportement anormal soit détecté. Le contrôle naturel des accès (natural access control) canalise les visiteurs : on les dirige vers une entrée unique avec un accueil capable de déterminer l'objet de la visite et la destination ; arbustes et haies dissuadent d'emprunter certains chemins. Le renforcement territorial (territorial reinforcement), aussi appelé territorialité, distingue espaces publics et privés au moyen de portes et serrures, de signalétique, d'uniformes du personnel et du placement des accueils et postes de garde ; cette notion d'appropriation perçue indique que les propriétaires sont attentifs.

Les aménagements doivent rester accueillants sans transformer l'installation en forteresse : eau et végétation sont à la fois esthétiques et utiles à la sécurité. Les zones critiques (salles serveurs) doivent être isolées du trafic public et des employés, en les plaçant à l'écart des chemins fréquentés. Attention aux faux contrôles : une porte ouverte par un garde via un bouton peut être contournée par intimidation ou social engineering, et des alarmes de contact signalent une porte maintenue ouverte.

La planification du site couvre aussi le site alternatif : il doit être assez éloigné pour ne pas subir le même sinistre que le site primaire, mais assez proche pour que le personnel clé y accède en crise. Il doit être géographiquement distinct, fournir une capacité de traitement, et faire l'objet de sa propre évaluation des risques (catastrophes naturelles, défaillances structurelles, attaques). L'engagement de l'équipe sécurité doit avoir lieu dès la phase de conception (concept of operations), avant l'acquisition du bâtiment : plus la sécurité intervient tard, plus le coût de remédiation est élevé.

9.2 Salle serveur et datacenter : HVAC et énergie

La salle serveur exige un niveau de protection physique supérieur au reste de l'installation. Son trafic humain est plus élevé : la sécurité des points d'accès et le suivi (monitoring/enregistrement) des entrées sont critiques. Quand l'espace est partagé entre unités ou entreprises, le verrouillage au niveau du rack ou de l'équipement devient essentiel. Attention au détournement d'usage : convertir un bureau en salle serveur sans renforcer les planchers ni dimensionner la climatisation met en danger le bâtiment et ses occupants. Le câblage (cable plant) doit être inventorié, repéré et protégé : un plan de câblage mal géré augmente la charge incendie et peut faire céder les chemins de câbles.

Les standards de datacenter permettent d'évaluer et comparer les installations. Le Uptime Institute Tier Classification System note de Tier I (infrastructure de base) à Tier IV (site tolérant aux pannes, fault-tolerant) ; c'est un standard de fait, non imposé par la loi. ANSI/TIA 942-A se concentre sur le câblage et la fiabilité réseau (note 1 à 4). ANSI/BICSI 002 couvre les corps de métier MEP (mécanique, électrique, plomberie) plus la protection incendie. La norme européenne EN 50600 évalue une Availability Class sur quatre niveaux, en plusieurs parties (construction, distribution électrique, contrôle environnemental, câblage, systèmes de sécurité).

Le HVAC maintient la plage de température recommandée par l'ASHRAE pour l'uptime et la durée de vie matérielle : entre 18 °C et 27 °C (64 °F à 81 °F). L'ASHRAE recommande trois capteurs de température par rack (haut, milieu, bas), car le refroidissement représente souvent plus de la moitié du coût d'exploitation d'un datacenter. Le flux d'air gère aussi les contaminants (poussières, fumées) et l'air respirable (capteurs de CO2, prises d'air frais).

L'énergie doit être livrée constamment et de qualité constante : les fluctuations réduisent la durée de vie des systèmes, les coupures les arrêtent. La résilience repose sur deux briques complémentaires. L'UPS (onduleur) fournit l'énergie batterie le temps que les générateurs démarrent et se stabilisent : c'est une couverture de COURT terme. Les générateurs de secours, dimensionnés pour la charge critique (les ressources de calcul) et l'infrastructure de support, assurent le LONG terme tant que le carburant est disponible. La redondance dual-feed (deux alimentations depuis des sous-stations distinctes, transfer switches) accroît encore la résilience. Comme pour les sauvegardes de données, le basculement vers l'alimentation de secours doit être testé.

9.3 Incendie : classes, détection et suppression

La maîtrise du feu suit une approche en couches - prévention, détection, suppression - évaluée au niveau du bâtiment, de la salle et de l'enclos (rack). La prévention est la plus importante : respect des codes de construction, réduction de la charge incendie (papier, encombrement, matériaux inflammables), inspections régulières, interdiction de fumer. Les datacenters subissent des exigences additionnelles du fait de leurs dangers propres.

La détection commence par les détecteurs ponctuels (spot-type) : l'ionisation mesure le courant électrique entre deux plaques chargées quand la fumée passe, le photoélectrique mesure les variations de lumière dues aux particules. Les modèles récents combinent ionisation, photoélectrique, monoxyde de carbone, chaleur et flamme pour élargir la détection et réduire les fausses alarmes. Les détecteurs aspirants (aspirating) respirent en continu un échantillon d'air : ces systèmes VESDA (Very Early Smoke Detection Apparatus) sont intégrés aux reprises d'air et au plenum sous les planchers techniques ; leur extrême sensibilité permet plusieurs niveaux d'alarme - un seuil bas déclenche un avertisseur, un seuil haut lance la suppression complète.

Le feu se classe en cinq types (les lettres varient selon les pays) : Classe A (solides combustibles ordinaires : papier, bois, plastique), Classe B (liquides inflammables), Classe C (feux électriques), Classe D (métaux inflammables), Classe K (équipement de cuisine commerciale). Pour datacenters et bureaux, les préoccupations principales sont A, B et C. Choisir le bon agent selon la classe est crucial : un agent inadapté est inefficace ou dangereux.

Deux grandes familles de suppression. Les systèmes à base d'EAU, surtout efficaces sur la Classe A, sûrs pour les personnes et peu coûteux, mais ils endommagent les équipements : wet pipe (eau dans les tuyaux, têtes activées par la chaleur, le plus courant), dry pipe (gaz pressurisé, eau libérée après activation d'une tête, utile contre le gel), pre-action (combine wet et dry, exige souvent un capteur ET une tête), deluge (têtes ouvertes, toutes activées simultanément), et la mousse AFFF. Les systèmes à base de GAZ sont efficaces contre les Classes A, B et C : ils inhibent la réaction chimique, réduisent la chaleur ou surtout abaissent l'oxygène ; ils exigent l'évacuation des personnes et la fermeture des portes (risque d'asphyxie). Exemples : FM-200, CO2, Argonite, Inergen, hydrofluorocarbures et l'ancien Halon (retiré du commerce). Pour les espaces équipés occupés, les liquides non conducteurs et non toxiques comme le Novec 1230 protègent les Classes A, B et C sans danger d'eau ni d'asphyxie. Les systèmes pré-équipés dans les racks localisent la source et concentrent la suppression sur la zone touchée.

9.4 Périmètre, mantraps et contrôle d'accès physique

La défense physique s'organise en couches successives, à l'image d'un château fort : une clôture solide forme la première ligne, l'entrée du bâtiment la deuxième, puis la segmentation interne (étage, niveau ou section à accès restreint) constitue la troisième. Comme à Conwy Castle, le fossé restreint les chemins d'approche et les canalise vers un passage prédéfini, ce qui permet de concentrer la défense sur des zones précises plutôt que de défendre tout le site. Un point d'entrée unique crée un goulet d'étranglement qui permet d'identifier les visiteurs et d'autoriser ou refuser l'accès.

Les contrôles d'accès physiques privilégient des éléments robustes. Les portes doivent être à âme pleine (solid core) : les portes creuses (hollow core) offrent peu de sécurité, se forcent facilement et freinent mal le feu. Les fenêtres ne doivent pas jouxter les portes (une vitre brisée donnerait accès à la serrure) ; on emploie du verre feuilleté (laminated glass) et des protections (grilles, écrans). Les serrures à clé restent le moyen le plus courant de sécuriser un espace. Les tourniquets (turnstiles) et les mantraps (sas) sont une méthode économique pour contrôler l'accès et limiter le flux : un mantrap n'ouvre la seconde porte qu'après fermeture de la première, ce qui empêche le tailgating (passage en cascade).

Les zones de travail à accès restreint protègent les espaces où s'effectue un travail très sensible. Les SCIF (Sensitive Compartmented Information Facilities) imposent des protections extrêmes : portes solides ou métalliques résistant à la pénétration et insonorisées, connexions électriques dédiées au seul environnement sécurisé, conduits isolés ou protégés contre l'intrusion et le monitoring audio/RF, protections acoustiques empêchant l'écoute extérieure, protections visuelles (extérieurs banals, fenêtres déconseillées et traitées contre l'observation visuelle, acoustique et RF), et des IDS avec capteurs dans murs, sols et plafonds. Ces dispositifs, nés du travail de sécurité nationale, servent aussi à protéger la propriété intellectuelle la plus sensible des entreprises.

Les salles de stockage de preuves sont des zones à accès strictement limité, fortement surveillées, avec casiers ou conteneurs individuels par enquête, afin de garantir la chain of custody (chaîne de possession). Un manquement à la chaîne de possession peut rendre la preuve irrecevable en justice. Quant aux services utilitaires (électricité, télécom, eau, gaz), leur compromission peut rendre l'installation inutilisable : on prévoit une redondance appropriée, des contrôles de bâtiment avec capteurs de fuite et alarmes, et des plans de contingence priorisant les systèmes essentiels.

9.5 Cycle de vie : du besoin au déploiement sécurisé

La gestion du cycle de vie du système d'information est la gestion holistique et de long terme des capacités dont une organisation a besoin. Même un système réussi finira par exiger une réarchitecture et une réécriture, parce que les besoins évoluent. Le cycle de vie recouvre les activités pour créer, gérer, puis finalement retirer et remplacer un système.

Tout part des besoins et exigences des parties prenantes. La documentation de sécurité logicielle comporte une cartographie des parties prenantes (stakeholder map) et une matrice de traçabilité des exigences (requirements traceability matrix). Les exigences fonctionnelles capturent les processus métier et les abuse cases ; les exigences non fonctionnelles portent les exigences de sécurité et de performance, dont beaucoup proviennent des lois de confidentialité et des standards. L'analyse des exigences ajoute les misuse cases : contrairement aux use cases, elles exigent d'adopter la perspective d'un acteur malveillant.

La conception architecturale pèse les solutions selon leur capacité à satisfaire les exigences ; le système doit être auto-défensif (self-defending). Le threat modeling énumère les attaques contre lesquelles se défendre. Les principes d'architecture sécurisée s'appliquent ici : open design (la sécurité ne doit pas reposer sur le secret de la conception), complete mediation (toute requête d'accès est vérifiée, fondement du zero trust), least common mechanism (minimiser les mécanismes partagés entre sujets, sources d'échanges non autorisés), compartmentalization, et réutilisation de bibliothèques éprouvées avec un secrets manager pour éviter les credentials codés en dur. La microsegmentation et le zero trust (NIST SP 800-207) cherchent un équilibre entre le modèle déconseillé authenticate once, trust forever et l'extrême trust nothing.

Le développement structure l'environnement pour réussir : bibliothèques à jour et vérifiées, IDE avec linter, dépôt de code appliquant automatiquement l'analyse statique (SCA/SAST) pour un retour immédiat au développeur - corriger un bug à l'écriture coûte plusieurs ordres de grandeur de moins qu'en production. Langages à jour et sûrs (type safe, sans débordement de tampon), formation au secure coding (OWASP Top 10). L'intégration vérifie l'exécution correcte entre systèmes amont et aval ; les systèmes legacy peuvent élargir la surface d'attaque et gagnent à être isolés en enclaves réseau. La vérification et validation ajoute, contre chaque exigence de la matrice de traçabilité, des preuves de test : SAST, DAST, tests d'intrusion, en s'appuyant sur l'OWASP ASVS. Enfin, la transition/déploiement pousse le code testé en production sous change control, de plus en plus via CI/CD : la continuous integration construit et teste à chaque fusion ; la continuous delivery déplace le code entre environnements avec un déploiement manuel en production, tandis que la continuous deployment publie automatiquement tout changement ayant passé tous les tests. La question fondamentale du CISSP : le code passé en production correspond-il au code testé ?

9.6 Exploitation, change/configuration management et mise hors service

Une fois le système en production, l'exploitation et la maintenance (operations and maintenance/sustainment) visent à surveiller la santé de l'application, y compris le monitoring de la fraude et des autres attaques. Les release notes listent les erreurs connues et leurs contournements, ce qui permet au support de répondre aux utilisateurs. Les processus des service managers intègrent le plan de réponse aux incidents du nouveau système dans une enveloppe ITSM complète (sauvegarde, tests de reprise, DR). Pendant la production, tout nouveau code doit être testé via les mêmes processus de transition vers la production : la sécurité n'est jamais finie.

Le change control (gestion des changements) encadre toute modification poussée en production. C'est le garde-fou central du cycle de vie : il garantit que les changements sont évalués, approuvés, tracés et réversibles. Le déploiement passe par lui, de plus en plus automatisé par le pipeline CI/CD. Mais le CISSP garde le focus sur l'intégrité et la sécurité du processus de bout en bout : la question fondamentale demeure de savoir si le code arrivé en production correspond au code testé, et les contrôles de sécurité sur les systèmes de gestion du code doivent refléter le plus haut niveau de classification des données traitées par ce code.

La gestion de configuration repose, à mesure que les zero days émergent, sur une base de données de gestion de configuration (CMDB, configuration management database). Elle inventorie les composants et leurs versions, ce qui permet, dès qu'une vulnérabilité est publiée, d'identifier rapidement les systèmes affectés et d'organiser leur remédiation. Sans CMDB, l'organisation ignore où se trouvent ses actifs vulnérables.

Enfin, la mise hors service (retire and replace). Le cycle de vie inclut explicitement le retrait et le remplacement du système quand les besoins ont changé. Sur le plan des données, la 3.9 rappelle que les copies physiques doivent être correctement détruites à la fin de leur période de rétention et de leur vie utile. La protection ne s'arrête donc pas à l'exploitation : un actif décommissionné doit voir ses supports sécurisés ou détruits, ses clés de chiffrement gérées et retirées, et ses accès révoqués. Le principe directeur reste constant sur tout le cycle : la confidentialité, l'intégrité et la disponibilité doivent être préservées de la conception jusqu'à la destruction.