Sécurité du développement logiciel

1.1 Où vivent les vulnérabilités : ring model et pile OSI

Le Domaine 3 a introduit le ring model pour montrer comment des couches de fonctions s'empilent pour produire les architectures de systèmes et d'information dont les organisations dépendent. Le matériel embarque son propre logiciel, le firmware, gravé en ROM. Les systèmes d'exploitation pilotent des familles de matériels via des device drivers, sans que l'OS ait à manipuler les détails de bas niveau. C'est exactement la logique des couches 1 et 2 du modèle OSI : elles encapsulent les détails matériels et exposent aux couches supérieures les fonctions dont elles ont besoin. Couche après couche, le système se construit jusqu'à la couche 7, où l'utilisateur et ses applications consomment des services rendus par du logiciel s'exécutant sur de nombreux systèmes différents.

Le point clé, à retenir pour l'examen : chaque couche dépend des couches inférieures pour ses contrôles de sécurité encapsulés, mais elle HÉRITE aussi de leurs vulnérabilités. Si une erreur exploitable existe dans une couche basse (firmware, driver, pile réseau), toutes les couches au-dessus en héritent, qu'elles le sachent ou non. Inversement, les couches internes (ou basses) de l'anneau ou de la pile doivent être protégées des conséquences d'attaques visant des vulnérabilités situées au-dessus d'elles. La sécurité n'est donc jamais l'affaire d'une seule couche : c'est de la defense in depth verticale.

Du logiciel existe à chaque niveau de l'anneau, et ce logiciel dépend souvent de fichiers de configuration, de scripts et de valeurs d'initialisation (les valeurs par défaut). Un programme applicatif typique peut comporter des dizaines de milliers de fichiers d'exécutable, de données de paramètres, de scripts et d'autres données. Chacun de ces fichiers est une surface de risque potentielle : la vulnérabilité ne se cache pas seulement dans le code, mais aussi dans la configuration et les données qui pilotent ce code.

1.2 Threat modeling et STRIDE

Le threat modeling, tel que défini par l'OWASP, est le processus de sécurité par lequel des menaces potentielles - ou l'absence de safeguards - sont identifiées, catégorisées et analysées. Concrètement, on crée des abstractions du système pour repérer les frontières (perimeters) entre sous-systèmes et entre le système et son environnement externe. Logiciel, matériel, données et personnes sont autant de points de franchissement de ces frontières. Le threat modeling consiste à regarder un environnement, un système ou une application du point de vue de l'attaquant et à déterminer les vulnérabilités qu'il pourrait exploiter.

Le modèle le plus répandu est STRIDE, mnémonique de six catégories de menaces : Spoofing (usurper une identité), Tampering (modifier quelque chose sur disque, réseau, données ou code), Repudiation (nier avoir effectué une action), Information disclosure (exposer de l'information à quelqu'un de non autorisé), Denial of service (épuiser ou dégrader un service), et Elevation of privilege (obtenir des privilèges sans autorisation). En STRIDE, le professionnel décompose le système en composants pertinents, analyse la sensibilité de chaque composant à ces menaces, puis identifie des mitigations. D'autres modèles visent les mêmes fins : PASTA, LINDDUN (orienté privacy) et Trike.

La threat surface (surface de menace) est le total des points de franchissement pour une frontière donnée : ports TCP/IP, services de login, champs de saisie d'une page web, points de connexion pour médias amovibles. Chaque franchissement est une opportunité d'appliquer une technique de contrôle dans une stratégie globale de risk mitigation. Le data-centric threat modeling (NIST SP 800-154, 2016) déplace le focus du système vers la donnée : il modélise les mouvements, emplacements, exécutions et entrées/sorties autorisés des données, ce qui correspond directement à protéger les données in transit, at rest et in use.

Piège d'examen classique : le threat modeling sert à IDENTIFIER, CATÉGORISER et ANALYSER les menaces. Ce n'est PAS de la mitigation. La mitigation est l'étape qui suit, pas une étape du threat modeling lui-même. Confondre les deux est une erreur fréquente au QCM.

1.3 Mobile code et executable content

Les applications web étendent la surface de menace en prolongeant l'architecture de nos systèmes avec du mobile code, aussi appelé executable content. Le mobile code est un fichier (ou un ensemble de fichiers) envoyé par un système vers un ou plusieurs systèmes clients ; une fois ouvert par un logiciel déjà installé sur le client, il pilote l'exécution du logiciel du client ou est directement exécuté par le CPU du client. La distinction historique est nette : les architectures client-serveur traditionnelles gardaient le code en place (des fonctions différentes sur clients et serveurs) tandis que seules les données circulaient. Les architectures web, elles, DÉPENDENT du mobile code pour fonctionner.

À chaque connexion d'un navigateur à un serveur, le serveur télécharge sur le poste de l'utilisateur des fichiers contenant la logique de contrôle et les données nécessaires au rendu de la page, fournit des champs de saisie, valide ces saisies et renvoie des données au serveur. Les types de mobile code sont nombreux : les plus courants sont JavaScript, les Java Archive (fichiers JAR), les fichiers XML et les requêtes d'API. Les fichiers HTML de la page elle-même et les feuilles de style CSS sont aussi de l'executable content. Apps, applets, widgets, add-ons et add-ins de navigateurs en sont d'autres exemples. Les bots forment une classe émergente : ils utilisent des capacités limitées de machine learning pour assister les requêtes des utilisateurs, automatiser des workflows ou valider la qualité des saisies.

Presque toute action via une web app ouvre à la fois la surface de menace du client ET celle du serveur : le mobile code envoyé par le serveur doit franchir la threat surface du client pour être rendu, mais les données saisies dans les champs et renvoyées par un submit ou un post - qui peuvent elles-mêmes être du mobile code - traversent la threat surface du serveur. À retenir : la quasi-totalité des espèces de malware sont du mobile code, ou de l'executable content, ou exploitent les fonctionnalités systèmes et architecturales qui rendent le mobile code possible. Le mobile code n'est donc pas un risque parmi d'autres : c'est le mécanisme même que détourne la plupart des attaques web.

1.4 L'environnement logiciel et les trois perspectives temporelles

L'environnement logiciel, au sens large, regroupe tous les éléments, activités, informations, personnes et systèmes qui affectent la façon dont un logiciel est créé, utilisé, modifié et finalement retiré. Cet environnement peut se limiter à une organisation qui est seule créatrice et utilisatrice de son logiciel, ou s'étendre à tout un marché pour du logiciel COTS (commercial off-the-shelf). Il inclut quiconque peut lire ou faire du reverse engineering du code, ses utilisateurs, et même ceux qui subissent les effets du logiciel sans l'utiliser directement. Il englobe souvent des facteurs légaux, réglementaires et externes. Exemple parlant : pendant la pandémie de COVID-19, des patients ne pouvaient accéder à la télémédecine que lorsque l'environnement logiciel de facturation des assurances médicales avait été modifié pour le permettre. L'environnement logiciel est donc complexe et déborde largement du seul code.

Le modèle de cycle de vie ajoute une autre source de complexité : trois perspectives temporelles différentes. Premièrement, le design et le développement : c'est là que se créent le plus de vulnérabilités auto-infligées, qui peuvent ne pas être détectées au test et à l'assessment. La threat surface y est plus petite et plus facile à contrôler qu'à toute autre étape. Cette phase peut durer des jours, des mois ou des années.

Deuxièmement, le runtime en exploitation : à la fois les moments individuels d'usage par chaque utilisateur, et les jours, mois ou années pendant lesquels une version donnée est mise à disposition. C'est le moment où la threat surface est MAXIMALE et où le contrôle du risque est le plus difficile pour les développeurs, mainteneurs et équipes sécurité. Troisièmement, après remplacement ou retrait d'une version par une autre : le système s'étend à chaque nouvelle version et à chaque adaptation locale. La découverte d'une vulnérabilité dans n'importe quelle version encore en service peut mettre en danger la dernière édition comme les précédentes. Cette phase de support chevauchant s'étale souvent sur des années. À retenir pour l'examen : la threat surface n'est pas constante - elle est minimale au design, maximale au runtime, et persiste tant que d'anciennes versions restent déployées.

1.5 Le compromis temps/qualité et le coût des corrections tardives

Pendant des décennies, les organisations ont cru à un dilemme : avoir le logiciel vite et pas cher mais en sacrifiant des fonctions critiques comme la sécurité, ou bien plus tard, plus robuste et plus sûr, mais à coût bien plus élevé. La naissance d'internet reflète ce choix et la croyance implicite qu'il n'existait pas de terrain intermédiaire. C'est un faux dilemme : la plupart des vulnérabilités exploitables sont auto-infligées, créées comme erreurs de requirements, de design et de code, et non détectées par des erreurs de test, de vérification et d'assessment - puis laissées à trouver et exploiter par un attaquant. Beaucoup d'organisations ont évité ce faux dilemme en choisissant des approches qui satisfont le besoin métier avec du logiciel fiable, résilient et sûr.

La raison économique tient au coût croissant du changement tardif. Quand une erreur est trouvée et corrigée dans la phase où elle a été introduite, son coût est la référence : « 1x ». Trouvée une phase plus tard, le coût augmente ; trouvée en operations ou maintenance, il explose - non seulement à cause du rework, mais parce qu'elle impacte alors les objectifs métier et mission. La courbe va de 1x à une croissance quasi exponentielle. Sauter directement de l'idée au code (construction-only) paraît le moins cher mais ne l'est pas : l'analyse front-loaded de la sécurité, de la fiabilité et de la sûreté, plus déterminée et délibérée, vaut largement son effort.

Une grande partie de ces défauts vient des données. Les erreurs classiques persistent : mauvaise gestion des boucles et des conditions, mauvais types de données, mauvais usage des données/code d'un module par un autre, mauvaise gestion des cas spéciaux et exceptions, jeux de paramètres incomplets entre modules. Le problème central : une donnée d'entrée hors plage, incomplète, ou dans la plage mais incorrecte provoque un comportement anormal. D'où l'expression « garbage in, garbage out » - faire tourner une activité sans contrôle effectif de la qualité des données.

Le NIST Draft SP 800-154 - Guide to Data-Centric System Threat Modeling (2016) établit le data-centric threat modeling comme méthodologie : il se concentre sur les mouvements, emplacements, exécutions et entrées/sorties autorisés des données, ce qui correspond à protéger la donnée in transit, at rest et in use. Il rappelle qu'une entrée mal contrôlée peut exposer d'autres données, permettre l'exécution de code arbitraire, corrompre le stockage ou terminer l'application ; et qu'un mauvais usage des utilitaires système pour lire ou extraire des données peut être une étape d'exfiltration. Principe clé pour l'examen : protéger l'INFORMATION dans le système est la fin ; protéger le logiciel, le matériel, les personnes et les locaux n'en sont que les moyens.

2.1 Le SDLC waterfall classique : SLC vs SDLC et ses phases

Le software development life cycle (SDLC) classique, apparu dans les années 1950 et institutionnalisé dans des standards d'acquisition gouvernementaux comme le MIL-STD-2167 du Department of Defense, est le waterfall model. Quand on parle de 'le SDLC' sans précision, on désigne presque toujours ce modèle waterfall. C'est une approche par phases en série ou chaque phase est complétée et documentée avant que la suivante ne commence ; la transition d'une phase à l'autre est marquée par un événement de décision formel, souvent un milestone ou une approbation, avec identification, status accounting et résolution gérée des open items restants. Chaque item non résolu représente un risque pour le programme.

Les phases généralement admises du waterfall sont : project initiation and planning ; functional requirements definition ; system design specifications ; development and implementation ; documentation and common program controls ; testing and evaluation control (certification and accreditation) ; transition to production. Comme le mot 'development' l'indique, le SDLC se termine à l'implémentation (mise en production). Le system life cycle (SLC), lui, couvre toute la vie du système et ajoute deux phases au-delà : operations and maintenance support (après installation), puis decommissioning/disposal and system replacement.

Piège d'examen : ne confondez pas SLC et SDLC. Le SDLC se termine à la mise en production ; operations & maintenance et decommissioning appartiennent au SLC, pas au SDLC. Autre piège : dans un waterfall strict, plus une erreur est détectée tard, plus son cout de correction explose - l'impact maximal survient en phase operations & maintenance. Cela justifie l'effort 'front-loaded' d'analyse et de test du waterfall pour les systèmes à haute fiabilité (nucléaire, spatial, aviation).

2.2 La sécurité à chaque phase du SDLC

La sécurité n'est pas une phase : elle s'exécute en parallèle de chaque phase de la méthodologie. En project initiation and planning, la justification du projet est endossée par le management (objectifs, scope, cout, calendrier) ; la compréhension des security requirements commence ici, et les activités de sécurité avancent en parallèle. En functional requirements definition, on formalise les exigences fonctionnelles ET nonfonctionnelles (sécurité, fiabilité, sureté) avec tous les stakeholders (owners, compliance, privacy). Attention : le waterfall a du mal avec les nonfunctional requirements et les emerging properties, qui ne s'évaluent que par analyse - les ignorer est une fallacy de raisonnement. En system design specifications, on conçoit l'architecture, les outputs et les interfaces ; les flux de données (input, data flow, output) et les security features sont intégrés au design. En development and implementation, le code est écrit (from scratch, librairies approuvées, snippets) ; il faut des coding standards, des librairies validées, des règles strictes de code reuse, et surtout du temps alloué au code review avant de poursuivre.

La phase acceptance est un handover formel et structuré au client, mesuré par rapport au requirements specification baseline convenu. Plusieurs équipes indépendantes peuvent intervenir : l'IV&V (independent verification and validation) examine, teste et analyse le système à la direction du client, en se concentrant sur certaines exigences ou éléments critiques ; le SV&V (selected/specialized verification and validation) cible spécifiquement la sécurité, la fiabilité, la sureté ou d'autres propriétés émergentes ; l'OT&E (operational testing and evaluation) évalue le système tel que l'équipe d'exploitation l'utilisera réellement, avec les concepts et procédures fournis par le client. Caveat de risque : plus ces équipes indépendantes s'éloignent des exigences contractuelles, plus les problèmes trouvés sont des surprises couteuses à corriger.

Transition to production n'appartient pas au waterfall traditionnel (réalisée par l'organisation cliente) : security accreditation, formation/sensibilisation des utilisateurs, installation, conversions de données, parfois opérations parallèles. Operation and maintenance (phase SLC) : monitoring, continuité, redondance, correction de défauts, test des procédures backup/recovery, et recertification périodique - en particulier lors de changements significatifs (classification des données, environnement physique, nouveau matériel/OS/logiciel, nouvelles interfaces externes). Decommissioning : retrait du service et disposal propre du matériel et du logiciel. Piège : un changement en maintenance ne doit jamais désactiver ou affaiblir un contrôle de sécurité existant requis.

2.3 Modèles itératifs et autres : du structured programming au cleanroom

Le waterfall strict s'est révélé trop rigide : sur des programmes pluri-annuels (FAA, WWMCCS du DoD), le monde réel évoluait avant l'entrée en test et le requirements baseline n'était plus valide. Les modèles itératifs (Iterative development) répondent à cela en permettant des raffinements successifs des exigences, du design et du code, à condition d'un change control mécanisme et d'un scope maitrisé. Risque sécurité : dans un environnement changeant, il est difficile de garantir que les provisions de sécurité restent valides - si quelque chose change, les security requirements peuvent devoir changer aussi. Le Spiral method est une version imbriquée (nested) du waterfall : chaque phase est conduite en waterfall, mais on lui ajoute quatre sous-étapes basées sur le cycle de Deming PDCA (Plan, Do, Check, Act). La nouveauté clé : une risk assessment review (le Check) à chaque phase, avec révision des couts/calendriers et un point de décision continuer/annuler à chaque tour.

Plusieurs modèles 'lean' accélèrent la production. Le RAD (Rapid Application Development) est une forme raffinée de prototyping avec des limites de temps strictes par phase et des outils efficaces ; risque : des décisions trop rapides menant à un mauvais design. Le Prototyping construit une version simplifiée de l'application, la fait revoir, intègre le feedback, et itère jusqu'à satisfaction du owner. Le Modified Prototype Model (MPM) est une forme raffinée idéale pour le web : fonctionnalité de base déployée vite, maintenance enchainée juste après, application qui évolue avec l'organisation plutot que figée. Le Reuse model construit l'application à partir de composants existants déjà testés (idéal en OO) ; c'est sans doute l'approche la plus répandue mais souvent la plus mal gérée. Le Component-based development assemble des building blocks standardisés déjà testés pour la sécurité (largement remplacé par l'OOP).

D'autres méthodes complètent le tableau. Le Structured programming (années 1970, avant l'OOP) : usage intensif de subroutines et structures de blocs réutilisées, discipline, revues/approbations à chaque phase - principes toujours sains mais rarement utilisés tels quels. Le JAD (Joint Analysis Development) : techniques de facilitation impliquant tous les stakeholders à chaque phase critique. L'Exploratory model : exigences batîes avec les ressources disponibles et beaucoup d'hypothèses - la sécurité doit etre priorisée car la structure manque. Le CASE (Computer-Aided Software Engineering) : automatisation par langages formels à chaque étape avec base de données liant les phases (Space Shuttle Mission Control) - tombé en désuétude. Le Cleanroom mise sur la defect prevention plutot que la defect removal : écrire le code correctement du premier coup, la qualité par le design - meme logique que 'security baked in'. L'Extreme Programming (XP) : valeurs simplicité, communication, feedback ; développeurs travaillant toujours en paire ; petites releases pleinement intégrées ; owners et sécurité impliqués dans la définition des besoins en amont des développeurs.

Piège d'examen : Spiral = waterfall imbriqué avec PDCA et une revue de risque à chaque phase (à ne pas confondre avec un simple itératif). Cleanroom = defect PREVENTION (et non removal/correction).

2.4 Agile, Scrum et DevOps

L'Agile development répond à des équipes et des besoins qui grandissent et évoluent : il privilégie les petits environnements d'équipe, l'apprentissage collaboratif et itératif, le build, le test et le déploiement de capacités opérationnelles. Ses patterns - Scrum, sprint, ou SAFe - gèrent le changement et produisent des fonctions travaillantes, fiables et vérifiables. Un sprint est un cycle court et borné produisant un incrément livrable. Agile peut très bien traiter les considérations de sécurité, à condition que l'équipe agile travaille effectivement avec des experts en sécurité de l'information. Rappel du module 1 : Agile livre plus de logiciel fonctionnel, plus vite, mais on lui reproche à juste titre de ne pas livrer une meilleure qualité ni un logiciel plus sécurisé par défaut.

DevOps combine 'development' et 'operations' (et typiquement la quality assurance). Fondé sur des principes lean/agile, il fait collaborer business owners, dev, ops et QA pour livrer du logiciel en continu, afin que le business réagisse vite aux opportunités de marché et au feedback client. Google, IBM, Amazon et Microsoft en ont des implémentations qui pilotent leur coeur de métier. DevOps repose sur quatre principes communs : développer et tester contre des systèmes 'production-like' (capturer des comportements réalistes avant la mise en production) ; déployer avec des processus répétables et fiables (l'automatisation est essentielle : déploiement et test continus, automatisés, fréquents, ce qui abaisse le risque d'échec de déploiement) ; monitorer et valider la qualité opérationnelle (avancer le monitoring tot dans le cycle, avec des métriques significatives capturées à chaque déploiement) ; amplifier les boucles de feedback (créer des canaux pour que tous les stakeholders accèdent au feedback et agissent dessus).

Piège d'examen : DevOps n'est pas DevSecOps. DevOps priorise la livraison rapide de nouvelles versions au-dessus de tout ; la sécurité, la sureté et la résilience y sont souvent reléguées et déléguées à d'autres processus. C'est précisément cette lacune que DevSecOps corrige (voir leçon suivante).

2.5 DevSecOps et le shift-left

Pendant que DevOps se popularisait, les organisations soumises à des exigences de sécurité et de sureté plus strictes ont poussé une autre approche. Le terme SecOps a été forgé pour reprendre les lecons du waterfall classique et intégrer des activités de sécurité à chaque étape du processus. Là ou DevOps priorisait la livraison rapide au détriment de la sécurité, SecOps livre du code plus sécurisé en traitant les security requirements à chaque stade - au prix de plus de temps. DevSecOps fusionne ces deux modèles : il déplace le levier des security requirements vers la gauche de la timeline (le shift-left), offrant à chaque tour de cycle des opportunités plus précoces pour adresser et livrer les besoins de sécurité prioritaires en production.

Le shift-left est l'idée centrale : plutot que d'auditer la sécurité après le développement (post-hoc), on déplace les activités de sécurité - threat modeling, scanning, tests, monitoring - vers les phases amont de conception et d'exigences. La comparaison entre le schéma DevOps et le schéma DevSecOps montre l'inclusion explicite des préoccupations, activités et professionnels de sécurité tout au long du pipeline. Aspect clé : l'équipe de développement (qui doit inclure des membres sécurité) est responsable des tests de sécurité et de la résolution des problèmes de sécurité trouvés pendant le développement et le test. Beaucoup d'organisations adaptent en continu les principes DevSecOps à leur culture, co-adaptant culture et processus pour devenir plus orientés sécurité.

Piège d'examen (officiel Q8) : DevOps = livraison rapide, sécurité déléguée à d'autres processus ; DevSecOps = sécurité intégrée à chaque étape via le shift-left. Si la question oppose 'rapide mais sécurité externalisée' à 'sécurité intégrée tot et partout', la réponse 'intégrée à chaque étape' est DevSecOps.

2.6 Approches transverses : IPT et IPPD

Dans les années 1980, beaucoup d'organisations ont implémenté le waterfall de travers : des équipes séparées par phase, sans personne hormis l'équipe de gestion de projet ayant une vue d'ensemble. Après des échecs couteux, le constat s'est imposé qu'impliquer le bon savoir, la bonne expérience et les bonnes perspectives de bout en bout est une meilleure facon de développer des systèmes complexes. Deux approches transverses sont couramment utilisées : l'Integrated Product Team (IPT) et l'Integrated Product and Process Development (IPPD).

Un IPT est une équipe de stakeholders aux compétences variées travaillant ensemble pour atteindre un processus ou un produit défini. Il puise dans de nombreuses disciplines de l'organisation et du domaine métier/mission pour engager des points de vue divers de facon cohérente tout au long du system life cycle. Ses membres assurent une représentation suffisante de tous les stakeholders - owners, management, développeurs, designers, contractants, professionnels de sécurité - pour garantir une collaboration efficace atteignant le résultat exigé. L'idée maitresse est l'engagement des stakeholders et la diversité des points de vue tout au long du développement.

L'IPPD reconnait que, dans beaucoup de projets complexes, les bons choix de méthodologie de gestion, d'approche de fabrication et de stratégie de test/vérification ne peuvent pas etre faits tant que le projet est encore en cours de réflexion ; les technologies à haut risque ou les algorithmes non éprouvés peuvent nécessiter une exploration par des démonstrateurs avant de savoir spécifier des exigences claires. C'est une technique de management combinant les activités essentielles d'acquisition via des équipes qualifiées pour optimiser les processus de design, de fabrication et de supportabilité, depuis le concept jusqu'au support post-production. L'IPPD facilite des membres multi-compétences travaillant ensemble via le concept d'IPT : représentants de toutes les disciplines fonctionnelles - ingénierie, fabrication, management, finance, achat, légal, sécurité - réunis avec un team leader pour identifier et résoudre les problèmes et prendre des décisions saines et opportunes. Piège : l'IPPD optimise à la fois le produit ET les processus (design, fabrication, support), là ou l'IPT vise d'abord la diversité des stakeholders ; l'IPPD s'appuie sur l'IPT comme brique de base.

2.7 Choisir une méthodologie : sécurité de bout en bout et arbitrage du risque

Il n'existe pas de méthodologie universellement supérieure. Le choix doit etre basé sur les requirements de l'organisation : certains modèles conviennent mieux aux projets longs et complexes, d'autres aux projets courts. Une application peut nécessiter des activités spécifiques pour réussir, et l'organisation peut devoir respecter des standards ou processus imposés par son industrie ou par le gouvernement. Il est souvent judicieux de combiner plusieurs modèles pour développer correctement les exigences de facon cout-efficace. Point clé du manuel : ce n'est pas qu'un SDLC formalisé doive obligatoirement etre utilisé, mais bien que l'ensemble du processus de développement doit impliquer la sécurité. Le nombre et la nature des phases ne sont pas d'importance primordiale.

La règle universelle, valable dans tous les modèles : la sécurité doit etre incluse dès le début et maintenue jusqu'à la fin - non seulement du processus de développement, mais jusqu'à la fin du life cycle complet du système. La meilleure sécurité est toujours celle qui est concue dans le système, pas celle ajoutée après coup.

Les industries changent fréquemment d'avis sur leurs besoins de développement les plus urgents : parfois de la nouvelle fonctionnalité plusieurs fois par jour, parfois l'accent sur la sécurité, la sureté ou l'auditabilité. Le choix de méthodologie peut etre dicté par la perception qu'a le management d'une fenetre d'avantage concurrentiel ou, à l'inverse, d'une fenetre de risque/responsabilité accentuée - plus que par d'autres principes. Le professionnel de sécurité doit garder une sensibilité à ces glissements d'emphase incessants. Piège d'examen : la question 'quand impliquer la sécurité ?' a pour réponse 'immédiatement, dès le début' - jamais après l'initiation, le codage ou la définition des critères de test.

3.1 Le SW-CMM et ses cinq niveaux

Le Capability Maturity Model for Software (SW-CMM) a été publié par le Software Engineering Institute (SEI) en 1991. Bien que le développement logiciel ait beaucoup évolué depuis, le modèle reste utile : il permet à une organisation de mesurer sa capacité de développement actuelle et de formuler un plan d'amélioration. Le CMM est centré sur les processus de quality management et décrit un chemin évolutif qui va de processus chaotiques et non structurés vers des processus matures, disciplinés et optimisés. Chaque pas le long de ce parcours doit produire un logiciel meilleur, plus rapide et moins coûteux, où « meilleur » recouvre toute mesure de qualité choisie par la direction, y compris les caractéristiques de sécurité et de safety.

Les cinq niveaux s'enchaînent dans un ordre strict. Level 1 Initial : les bonnes pratiques peuvent être répétées mais restent ad hoc, chaotiques ; le succès dépend des individus. Level 2 Repeatable : les meilleures pratiques sont répétables et transférables rapidement entre les groupes de l'organisation, car elles sont définies de façon à franchir les frontières de projet ; c'est le niveau du basic project management. Level 3 Defined : les processus standard sont formalisés, tout nouveau développement suit des processus stricts et standardisés, bien compris et proactifs. Level 4 Managed : des objectifs quantitatifs et mesurables sont établis pour les tâches, des mesures chiffrées sont calculées et maintenues comme baseline, ce qui réduit les écarts par rapport aux objectifs. Level 5 Optimizing : les pratiques sont continuellement améliorées et optimisées, le feedback d'une phase impacte positivement les autres ; c'est le focus continuous improvement.

Piège d'examen : ne pas inverser Defined (niveau 3, processus standardisés et documentés) et Managed (niveau 4, mesures quantitatives). Retenez la progression mémotechnique « chaotique vers optimisé » et le couple distinctif Managed = on mesure, Optimizing = on améliore en continu.

3.2 SAMM, BSIMM et CMMI

Le Software Assurance Maturity Model (SAMM) est porté par l'OWASP. Développé à la fin des années 2000, c'est un open framework qui aide une organisation de toute taille à formuler et mettre en oeuvre une stratégie de sécurité applicative. Une organisation l'utilise pour évaluer ses pratiques de sécurité logicielle existantes ou pour construire un programme de sécurité par itérations successives. SAMM repose sur quatre fonctions cœur : Governance, Construction, Verification et Operation. Ces fonctions couvrent un large spectre d'activités : product management, recueil des exigences, architecture et design, quality assurance, déploiement et exploitation en production. Chaque fonction se décline en plusieurs security practices, et chaque pratique est découpée en trois niveaux de maturité, du niveau le plus bas (pratique non remplie) au plus haut (maîtrise complète de la pratique).

Le BSIMM (Building Security In Maturity Model) joue un rôle complémentaire mais d'une autre nature. C'est un modèle descriptif, observationnel : il décrit ce que des firmes réelles font effectivement en matière de sécurité logicielle, en mesurant les activités observées sur le terrain. SAMM, à l'inverse, est prescriptif : il recommande ce qu'une organisation devrait faire pour progresser. Le piège est de confondre les deux logiques : SAMM dit « voici comment vous améliorer », BSIMM dit « voici ce que font les autres ». On compare souvent son score BSIMM à un benchmark sectoriel ; on suit son parcours SAMM comme une feuille de route.

Enfin, CMMI (Capability Maturity Model Integration) est le successeur générique du SW-CMM. Là où le SW-CMM ciblait spécifiquement le développement logiciel, CMMI généralise et intègre la démarche de maturité à d'autres domaines (services, gestion, acquisition). Pour l'examen, retenez la filiation SW-CMM (1991, logiciel) puis CMMI (modèle intégré plus large), et la distinction SAMM/BSIMM plutôt que les détails internes de CMMI.

4.1 Langages, traduction, librairies et IDE

Un programme écrit en langage source doit être traduit en instructions exécutables par la machine. On distingue les langages compilés (traduits intégralement en code machine avant exécution par un compiler) des langages interprétés (traduits ligne à ligne au moment de l'exécution par un interpreter). Entre les deux, certaines plateformes produisent un intermediate code : le code source Java est compilé en bytecode, puis exécuté par la machine virtuelle. Le repère de niveau utile à l'examen est l'échelle des générations : l'Assembly (langage de bas niveau, traité par un assembler) est le plus proche de la machine, où un énoncé correspond à une seule instruction processeur ; les langages de plus haut niveau (compilés ou interprétés) traduisent un seul énoncé en plusieurs instructions machine.

Une software library est un repository de code préécrit : classes, procédures, scripts et autres éléments programmatiques que le développeur appelle plutôt que de les réécrire. Il existe une hiérarchie de librairies : librairies de l'OS et du matériel (fournies par le vendor, mises à jour signées numériquement), librairies du langage de programmation (fournies par l'IDE ou les tool sets), development frameworks (comme .NET), librairies in-house, project-specific ou customer-specific (code éprouvé moissonné dans les projets internes), et librairies third-party open-source. Ces dernières vont de sources réputées à du code de pedigree incertain (blogs, forums) qu'il faut inspecter pour back doors, Trojans ou logic bombs avant tout reuse. Le software reuse échange du risque contre du temps : réutiliser trop vite sans inspection introduit une vulnérabilité exploitable ; inspecter à l'excès annule le gain de temps. Les junior programmers passent parfois plus de temps à chercher un snippet réutilisable qu'à écrire eux-mêmes un bon code.

Les programming tools (debuggers, build tools, source code editors, static code analysis tools, revision control, unit testing) sont souvent regroupés dans un IDE (Integrated Development Environment). Un IDE combine de nombreux outils dans un même environnement : il comprend typiquement un source code editor, des build automation tools et un debugger, et peut offrir un class browser, un object browser et un class hierarchy diagram pour le développement orienté objet. Les source code analysis tools cherchent les défauts de sécurité dans le code source (et parfois le code compilé) ; il est préférable de les utiliser dès les premières phases de développement pour corriger au plus près de l'introduction de l'erreur. Enfin, le sandbox protège l'exécution de mobile code : il limite mémoire et CPU et isole le code suspect. Dans le modèle Java, le Java security manager fait respecter les limites du sandbox ; les sandbox applets ne peuvent réaliser qu'un jeu d'opérations sûres, tandis que les privileged applets (signés par un certificat accepté par l'utilisateur) peuvent s'exécuter hors du sandbox avec un accès étendu au client.

4.2 Tests de sécurité applicative : SAST, DAST, IAST, RASP

Plusieurs approches d'analyse de sécurité applicative coexistent et se complètent. Le SAST (Static Application Security Testing) analyse le code source sans l'exécuter : il recherche les erreurs de programmation courantes, la conformité aux guidelines et templates, et les sources d'erreurs visibles dans le source. Comme il n'exécute pas le code, le qualifier de « security testing » est un léger abus de langage ; en revanche il est facile à déployer, passe bien à l'échelle, se lance tôt dans le cycle d'écriture et aide même au refactoring. Le DAST (Dynamic Application Security Testing) fait l'inverse : il exécute l'unité, le module ou l'application complète et injecte une variété de tests pour pousser le code au-delà de ses limites. C'est l'approche dite fuzz testing, qui lance des dizaines de milliers de cas de test contre l'application, là où le test manuel n'en couvrait que quelques-uns.

Le IAST (Interactive Application Security Testing) est une approche hybride : il amène le test aux applications web et mobiles, là où SAST et DAST peinent. Le IAST fonctionne avec des agents incorporés dans le logiciel testé, ce qui permet au moteur d'inspecter la logique de l'application jusque dans les library routines qu'elle appelle, en vérifiant leur usage correct. Sa limite est la couverture des applications serverless utilisant des interfaces non-HTTP. Le RASP (Runtime Application Security Protection) est davantage un outil de protection : ses agents et son instrumentation dans le code peuvent terminer l'exécution si une violation de sécurité potentielle est détectée pendant le test.

Ces outils ont des limites communes : beaucoup de vulnérabilités (problèmes d'authentication, d'access control, usage incorrect de la cryptographie) sont difficiles à trouver automatiquement ; les taux de false positives sont élevés (utiles pour affiner les outils) ; les problèmes de configuration échappent souvent à l'analyse car ils ne sont pas représentés dans le code ; et le code qui ne peut être compilé est difficile à analyser. Le piège d'examen est la paire SAST/DAST : SAST est statique, lit le code source, se place tôt dans le cycle (shift-left) ; DAST est dynamique, teste l'application en exécution par fuzz testing.

4.3 Séparation et contrôle des environnements

Le développement logiciel s'appuie sur trois environnements clés : l'environnement de development (où analystes et programmeurs écrivent, compilent et testent initialement l'application), l'environnement de quality assurance (QA, où utilisateurs et équipe qualité réalisent les functional tests, idéalement sur une configuration simulant la production au plus près) et l'environnement de production. D'autres environnements existent (test, staging), mais l'enjeu de sécurité est identique : contrôler comment chaque environnement accède à l'application et aux données, puis maintenir les environnements séparés et isolés. Les personnes travaillant dans un environnement doivent être restreintes à celui-ci : il est généralement admis qu'un développeur ne doit jamais avoir accès à la production. Les blended environments combinent un ou plusieurs de ces environnements individuels et sont les plus difficiles à contrôler, donc risqués.

Les mesures de protection classiques sont l'isolation physique de chaque environnement, la séparation physique ou temporelle des données, des access control lists, des content-dependent access controls, des role-based constraints, l'accountability et la separation of duties. La virtualisation généralise cette isolation : on définit des environnements virtuels contenant le bon mélange de virtual machines (avec OS, plateformes applicatives et supports) pour chaque configuration testée. Tout cela n'est que l'application du least privilege à la sécurité du processus de développement, première étape indispensable vers un logiciel plus sûr.

Pour exécuter un programme, il faut un runtime system : l'ensemble des composants matériels et logiciels permettant à une application de tourner, quel que soit le langage. Tout langage a un runtime system, qu'il soit compilé, interprété ou invoqué via API. Le JRE (Java Runtime Environment) en est l'exemple : il comprend la JVM (Java virtual machine), les classes cœur de la plateforme et les librairies de support nécessaires pour exécuter un programme Java. Le runtime system est aussi la passerelle par laquelle le programme interagit avec le runtime environment, qui détient les valeurs d'état accessibles pendant l'exécution. Enfin, la sécurité des code repositories est un asset à protéger comme un autre : combinaison de contrôles d'accès logiques et physiques, plus protection de l'intégrité et de la disponibilité du contenu. L'offshoring du développement complique cette protection, car le code et l'environnement peuvent échapper à l'inspection directe de l'entreprise.

4.4 Déploiement plus sûr : TCB, reference monitor, security kernel

La phase de déploiement offre des leviers de sécurité via le bon choix de matériel, d'OS et de configuration. Au cœur de cette sécurité se trouve la Trusted Computing Base (TCB) : l'ensemble des composants hardware, software et firmware d'une architecture responsables du support de la security policy et de l'isolation des objets. Quand elle est conçue et codée correctement, toutes les fonctions de sécurité du système forment la TCB. Celle-ci peut contenir des trusted paths (canaux de communication sûrs entre l'utilisateur ou le programme et la TCB, que la TCB protège de toute compromission) et des trusted shells (tout ce qui se passe dans le shell reste confiné à ce canal).

Le reference monitor est l'élément qui fait respecter la sécurité entre les subjects (utilisateurs) et les objects (données ou ressources). C'est une machine abstraite qui médie, ou contrôle, tous les accès des subjects aux objects, garantissant que tout subject tentant d'accéder à un object dispose des droits appropriés. Le reference monitor est un concept ; son implémentation concrète est le security kernel. Le security kernel est constitué de tous les composants de la TCB (software, hardware, firmware) et implémente le mécanisme du reference monitor ainsi que la security policy. Dans une architecture en couches, le kernel se situe au niveau le plus bas et primitif : c'est la petite portion de l'OS par laquelle passent toutes les références à l'information et tous les changements d'autorisation.

Pour être implémenté correctement, le security kernel doit satisfaire trois exigences fondamentales : completeness (tout accès à l'information doit passer par le kernel), isolation (le kernel doit être protégé de tout accès non autorisé) et verifiability (le kernel doit être prouvé conforme à ses spécifications de design). Pour mesurer la confiance dans les capacités de sécurité de la TCB, on recourt à des evaluation criteria comme le TCSEC (Trusted Computer System Evaluation Criteria) et les Common Criteria actuels. Au-dessus de ce noyau viennent les approches cryptographiques : PKI (public key infrastructure) et signatures numériques, gestion des certificats et des clés, HSM (hardware security modules) pour le stockage robuste des clés, intégration avec l'access control et l'identity management. Une règle négative s'impose : ne jamais laisser développeurs ou administrateurs concevoir leurs propres solutions cryptographiques. Les politiques doivent aussi couvrir le shadow IT et le BYOx (bring your own everything), souvent portés par des citizen developers.

4.5 Contrôles DBMS comme sécurité logicielle

Le DBMS (database management system) fournit des contrôles de sécurité pour empêcher les accès non autorisés et les modifications inappropriées par des utilisateurs autorisés, sur la base de l'identification, de l'authentication, de l'authorization et de l'accountability. Le premier mécanisme est le lock control : le DBMS contrôle qui peut lire et écrire les données, en posant des verrous sur des rows ou des objects. Quand deux processus tentent d'accéder simultanément à une même ressource qui ne peut traiter qu'une requête à la fois sans casser l'intégrité, un deadlock peut survenir : le système ne peut libérer la ressource pour aucune des transactions et les refuse toutes deux. Pour l'éviter, le DBMS donne un write lock à une transaction (par exemple sur le dernier siège d'un vol) et met l'autre en file d'attente. Les locks peuvent être granulaires : par table, row, record ou même field.

D'autres contrôles d'accès DBMS complètent les locks. Le view-based access control divise logiquement la base : un trusted front end attribue à chaque type d'utilisateur une view qui masque les données sensibles non autorisées, avec une granularité possible sur les rows et les columns. Le grant and revoke gère les permissions : un utilisateur doté de la grant authority peut accorder des permissions à d'autres ; sans l'option grant, il ne peut pas transmettre cette autorité. La caractéristique de sécurité notable est l'effet cascade du revoke : révoquer les droits d'un utilisateur révoque aussi tous les droits qu'il avait lui-même accordés. La metadata sert aussi de gatekeeper : le data dictionary est un repository central d'informations sur les bases de l'entreprise (sensibilité, classification) ; il ne contrôle pas directement les accès mais éclaire la gestion du risque.

L'OLTP (Online Transaction Processing) gère un volume élevé de transactions en temps réel contre les bases, avec de nombreux utilisateurs concurrents (réservations aériennes, finance, retail). Il s'appuie sur les exigences de concurrency et d'atomicity du DBMS (le test ACID : atomicity, consistency, isolation, durability). L'OLTP agit comme un système de monitoring : il détecte l'abort d'un processus, le redémarre et annule une transaction si nécessaire. Deux features de sécurité importantes : le transaction log enregistre l'information d'une transaction avant traitement, puis la marque comme traitée ; en cas de panne, la transaction est récupérée et réappliquée via le log. Le checkpoint restart utilise les logs pour redémarrer la machine en rejouant jusqu'au dernier checkpoint (dernière bonne transaction connue), toutes les transactions suivantes étant réappliquées avant de rouvrir l'accès aux données.

4.6 Configuration management, change management et CI/CD

Le configuration management (CM) consiste à surveiller et gérer les changements apportés à un programme ou à sa documentation. Son but est de garantir l'intégrité du code, sa disponibilité et l'usage de la bonne version de chaque composant (code, design documents, documentation, control files). Le CM revoit chaque changement à travers quatre activités : identifying (identifier les changements), controlling (chaque changement passe par une documentation revue et approuvée par une personne autorisée, le change management ou RFC, request for change), accounting (enregistrer et reporter la configuration tout au long des procédures) et auditing (vérifier le changement et s'assurer qu'il n'affecte pas la security policy). Un CM plan définit les configuration items sous CM, leur nommage, comment ils entrent et sortent de l'ensemble contrôlé, comment un item peut changer et comment les outils CM appliquent ces règles. Dans un projet, le CM limite les changements au scope ; un CM défaillant mène au scope creep, où les exigences changent en continu et le projet ne se termine jamais.

Le Software Configuration Management (SCM) applique ces principes au code source : version control, branching et merging permettant à plusieurs équipes de travailler sans conflits, et builds stables. C'est l'outil approprié quand une organisation gère mal ses versions, contrairement à un simple document management system qui n'offre ni branching ni merging.

Le Continuous Integration (CI) et le Continuous Delivery (CD) automatisent et coordonnent les processus du pipeline, depuis l'écriture du code jusqu'à l'exécution du logiciel fini en production. Le pipeline enchaîne : codage d'un software unit, unit test, build et intégration des unités en sous-systèmes, puis en application complète, suivie d'autres tests, et enfin déploiement du build package. Le piège d'examen distingue les deux : la CI intègre et teste fréquemment le code dans le repository ; le CD déploie en production. Bien menés avec une forte implication de l'équipe sécurité, CI/CD sont des briques majeures d'une approche DevSecOps, rendant le change management plus seamless, auditable et applicable. Deux défis de sécurité : la chaîne CI/CD elle-même doit passer un security assessment, et elle peut alimenter la pression à livrer plus vite au détriment de la sécurité. Enfin, la granularité des contrôles doit adresser à la fois le programme et l'utilisateur : si un utilisateur ne peut accéder à un objet X mais dispose d'un programme qui le peut, les mécanismes de sécurité sont contournés (low granular system). La réponse est least privilege, separation of duties et limites d'accès raisonnables.

5.1 Arbitrer assurance, coût et besoins métier

Évaluer l'efficacité de la sécurité logicielle, c'est d'abord faire du risk management appliqué. Chaque étape, de la naissance d'une idée jusqu'au retrait du système, vise à atteindre une confiance suffisante : le logiciel est assez sûr, assez sécurisé, assez rapide pour les besoins des utilisateurs, et reste dans le budget et les délais. Comme les systèmes deviennent plus distribués et reposent sur des protocoles, interfaces et code open-source partagés, l'arbitrage entre le risque d'une brèche et la complexité, la difficulté et le coût d'un développement plus sûr devient chaque jour plus délicat.

Le professionnel de la sécurité n'est qu'un conseiller : la sécurité ne dicte pas ce que fait le business, elle lui permet d'opérer en sécurité. Pour comparer le risque aux besoins métier, l'entreprise suit quatre étapes. Discover : consulter les parties prenantes (entretiens, questionnaires, groupes de travail) sur ce qu'elles font et les outils qu'elles utilisent ; cette phase se répète souvent pour obtenir des réponses cohérentes. Evaluate : évaluer ces réponses, car les dirigeants articulent rarement clairement ce qu'ils font et les réponses sont souvent erronées. Agree : formuler des hypothèses pour réconcilier les visions ; si tous s'accordent, produire les business plans. Document : consigner le processus et le plan, qui deviennent le modèle de travail.

Piège d'examen : ce processus à quatre étapes ne tient pas compte du risque - il reflète ce que le business dit avoir besoin. Une fois la décision prise et implémentée, c'est l'équipe de sécurité (hors security architect) qui doit rendre le plan sûr. Et pour piloter cela, le principe « if you can't measure it, you can't manage it » impose des processus de configuration management (CM) et de configuration control (CC) robustes : sans mesure, pas de management de la sécurité.

5.2 Auditing et logging des changements

Le change management et le change control doivent d'abord décider du niveau de granularité auquel les éléments du système sont définis, énumérés, gérés et contrôlés. Cela établit l'ensemble des configuration items (CIs) formellement soumis aux décisions de CM et à l'enforcement et l'audit de CC. Tout le processus dépend des autres processus de sécurité du système pour empêcher rigoureusement la falsification du contenu d'un CI.

Un CI logiciel doit être identifiable de manière unique, et cet identifiant est lié aux processus de version control utilisés pendant l'intégration et la livraison. L'énumération du système doit révéler les CIs précis et l'identification de leur version. Sans ce niveau de spécificité et de granularité, l'énumération perd sa capacité à produire des findings exploitables en audit : on ne peut pas affirmer qu'un système correspond à son baseline si l'on ne sait pas exactement de quels éléments versionnés il est composé.

Le change control repose traditionnellement sur des change logs, alimentés par les logs des systèmes de fichiers et applications tenus par les OS, par les agents des systèmes de CM/CC, ou d'autres moyens. L'audit parcourt ensuite ces change logs pour vérifier que le résultat de tous les changements loggés correspond au baseline énuméré du système actuel. Piège d'examen : l'audit ne se contente pas de constater des changements, il vérifie qu'ils ramènent bien à l'état autorisé attendu (le baseline). C'est ainsi qu'on assess l'efficacité de la sécurité par auditing et logging - la réponse au scénario du profil 8.3.

5.3 Software assurance : processus, résultat et types d'évaluation

Le software assurance (ou software quality assurance) détermine qu'un système : accomplit toutes les fonctions prévues et requises ; n'accomplit aucune fonction non prévue ou non autorisée ; est exempt de vulnérabilités de sécurité, exploitables ou non ; et est protégé contre l'insertion d'erreurs dans le design, le code, la forme, la fonction et les données à tout moment du cycle de vie. C'est à la fois un processus - l'ensemble planifié et systématique d'activités pour collecter des données sur le logiciel, les évaluer et déterminer sa qualité globale - ET un résultat : la confiance que les parties prenantes peuvent avoir dans la capacité du logiciel à remplir leurs besoins en sécurité. Cette confiance est comparable à une garantie d'aptitude.

Beaucoup de besoins de sécurité s'évaluent mal par le software quality assurance car les analystes les voient comme des nonfunctional requirements. Les functional requirements sont les choses précises que le système doit faire (traiter correctement une transaction d'achat) : du code est écrit pour les accomplir. Les nonfunctional requirements sont des caractéristiques de forme globale ou des attributs de comportement résultant de la conception ; la plupart des besoins de sécurité ont été considérés comme nonfunctional - aucun code spécifique n'est écrit car il n'y a pas de « fonction » à exécuter. La sécurité est aussi une emerging property : elle découle de l'ensemble du design plutôt que d'un module isolé. Les processus efficaces s'organisent autour de workflows (tâches, déclencheurs, reporting) et de métriques basées sur des use cases, benchmarks de performance de sécurité dans des situations connues.

Il existe quatre types d'évaluation du risque logiciel à connaître. Certification & accreditation : analyse en amont des besoins, requirements et design, avec acceptance testing par rapport au baseline ; coûteuse, elle tombe en désuétude. Risk management frameworks : NIST, ISO et autres cadres formalisés couvrant tout le cycle de décision du risque. Software process CMMs : modèles du SEI caractérisant les processus métier de bout en bout par leur fiabilité, répétabilité et atteinte de métriques de qualité. Software quality assurance (software assurance) : comme la C&A, elle établit dans quelle mesure le logiciel respecte ses requirements sans exposer l'organisation à des risques indus. Le fil rouge est une question de due diligence : quelle confiance peut-on avoir que le logiciel est sûr, sécurisé et apte à l'usage ?

5.4 Certification & Accreditation (Security Authorization)

La certification & accreditation, parfois appelée Security Authorization, sépare deux décisions distinctes. La certification est le processus formel d'évaluation des capacités de sécurité du logiciel ou du système contre un ensemble prédéterminé de standards ou de politiques de sécurité ; elle peut aussi examiner dans quelle mesure le système remplit ses functional requirements liés à la sécurité. En d'autres termes, la certification est l'analyse technique complète de la sécurité du système, dont le résultat contient une analyse des capacités et contre-mesures techniques et non techniques et de la mesure dans laquelle le système répond aux exigences.

L'accreditation est la décision formelle de management portant sur les résultats de la certification, utilisée comme autorisation de mise en production. Elle requiert généralement une designated accrediting authority (DAA) qui revoit et approuve, et autorise le système en production pour une période donnée. Piège d'examen : certification = analyse technique (le « quoi » et le « comment » de la sécurité) ; accreditation = décision/autorisation de management (le « go » business). Le management peut accréditer un système qui a échoué à la certification, ou refuser d'accréditer un système certifié conforme - la décision finale est managériale, pas technique.

Il existe deux types d'accreditation. La provisional accreditation vaut pour une période déterminée et liste les changements requis pour atteindre la full accreditation. La full accreditation implique qu'aucun changement n'est requis pour la décision. Pour un test valable, l'application doit être testée dans un environnement simulant au plus près la production, en testant les capacités de sécurité et en simulant les problèmes de sécurité susceptibles de survenir - c'est la première phase du processus de C&A. Usage : surtout les environnements gouvernementaux (et leurs agences clientes), qui ont des exigences strictes de C&A et d'authorization to operate ; la plupart des organisations commerciales n'y voient pas de bénéfice face au fardeau administratif.

5.5 Testing, verification et security assessment

Le testing utilise un système (ou ses composants) de manière scriptée et contrôlée pour vérifier qu'un jeu d'entrées et de conditions initiales produit les résultats requis. Il intervient à de nombreuses étapes pour vérifier la justesse du design, de l'implémentation et l'aptitude à l'usage, y compris les caractéristiques de sécurité. L'acceptance testing (à l'origine « functional testing ») est un test formel mené par les équipes end-user du client pour déterminer s'il accepte le système : il répond à « peut-on l'utiliser pour nos besoins métier ? ». Il se distingue des unit tests, écrits et menés par les développeurs eux-mêmes, qui répondent à « se comporte-t-il selon les functional requirements ? ». Chaque test (un case) donne un pass ou fail ; accepter un système avec des écarts connus et un plan de résolution est courant.

Le regression testing vérifie qu'un changement ou ajout n'a pas affecté négativement les fonctionnalités existantes : attraper les bugs accidentellement réintroduits dans un nouveau build et s'assurer que des bugs déjà éradiqués le restent. Le regression testing de sécurité vérifie qu'un nouveau lot de modifications n'a pas ré-exposé le système à des vulnérabilités exploitables déjà connues - il arrive qu'un patch de sécurité défasse les mitigations d'une mise à jour précédente. Le security assessment testing, incluant l'ethical penetration testing, s'applique tout au long de la vie opérationnelle ; il évalue l'état présent du système et son usage réel, qui a souvent évolué au-delà des requirements d'origine, et inspecte que les contrôles de sécurité intégrés fonctionnent encore face aux menaces actuelles.

Les bonnes pratiques de test data sont des classiques d'examen. Ne jamais utiliser de données de production (privacy, need-to-know) ; si c'est inévitable, le data owner doit donner son accord et des usage controls stricts sont négociés. Inclure des données aux limites des plages acceptables, entre les deux, et au-delà du prévu, avec du fuzz testing (données aléatoires, non « attendues »). Tester aussi avec des known good data pour vérifier le comportement attendu. Faire du bounds checking de taille de champ, d'heure et de date pour prévenir les buffer overflows. Sanitiser les données de test pour ne pas exposer de données sensibles aux testeurs non autorisés. Revoir les données avant et après chaque test, et maintenir en permanence une séparation claire entre environnements de test et de production.

Les tests se classent aussi selon la connaissance interne dont dispose le testeur. Le black-box testing ne suppose aucune connaissance du code interne et exerce le systeme de l'exterieur (proche du DAST et du pentest externe). Le white-box testing dispose d'un acces complet au code source et a la conception (proche du SAST et de la code review). Le grey-box testing combine les deux : une connaissance partielle (par exemple des comptes ou des schemas) pour cibler les tests. Choisir le bon mix selon le risque et la criticite renforce la couverture.

6.1 Acquisition via développement third-party : les quatre phases

Quand une organisation confie à un tiers le développement d'un système, la customisation d'un logiciel existant ou le tailoring d'une plateforme commerciale, le processus d'acquisition devient le levier pour imposer le software assurance. La sécurité doit être designed in dès le départ : la meilleure sécurité est toujours celle conçue dans l'application, pas ajoutée après coup. La nature du contrat (open-ended ou fixed) reflète le degré d'incertitude sur le développement, le test et l'acceptance test ; un baseline contractuel entièrement fixe est souvent trop optimiste car peu de projets logiciels sont livrés à temps, dans le budget et avec toutes les exigences satisfaites.

Le software assurance pendant l'acquisition suit quatre phases. (1) Planning : on identifie le besoin, on fait le sizing/scoping, des risk assessments, on compare des implémentations alternatives, on estime le ROI comparé au hurdle rate interne (un projet qui ne dépasse pas ce taux de rentabilité minimal doit avoir une raison dominante pour être approuvé), puis on rédige les exigences logicielles du Statement of Work (SOW) et la stratégie d'acquisition avec critères de sélection des bidders. (2) Contracting : on émet la sollicitation ou Request for Proposal (RFP) accompagnée du SOW et des terms and conditions (conditions d'acceptance, prequalification, certifications), on évalue les propositions, puis on négocie et on attribue le contrat. (3) Monitoring, acceptance and deployment : on établit le planning de travail, on applique le change management / configuration control, et on revoit et accepte les deliverables - les assurance case deliverables doivent prouver la conformité aux stratégies de risk mitigation du contrat. (4) Ongoing use and support : le sustainment (risk management, assurance case management, change management) puis le disposal ou decommissioning.

Piège d'examen : un fournisseur qui revendique un CMM élevé n'est pas automatiquement sûr. La plupart des CMMs n'adressent pas explicitement la safety et la security ; un supplier au process mature peut donc ne pas exercer les pratiques critiques de software assurance. Le security professional doit vérifier que le software assurance est réellement intégré aux capacités de process du fournisseur, à la hauteur des besoins de risk mitigation de l'organisation.

Quand l'organisation depend d'un logiciel sur mesure dont elle ne possede pas le code source, un software escrow (sequestre de code source) protege la continuite : un tiers de confiance (escrow agent) conserve le code source et la documentation, et les libere au client selon des conditions contractuelles predefinies, typiquement la faillite du fournisseur, l'arret du support ou un manquement grave. C'est un controle cle de supply chain a negocier des la phase de contracting, au meme titre que le SOW et l'assurance case.

6.2 Open source et systèmes orphaned

L'open-source software est du code source rendu disponible à tous, généralement développé par et pour la communauté sous des licences variées favorisant l'adoption. Les partisans pensent que l'ouverture améliore la sécurité, ce qu'exprime la Linus's law : avec suffisamment d'yeux sur le code, tous les bugs deviennent apparents ("with enough eyeballs, all bugs are shallow"). L'idée est que la revue par d'autres développeurs identifie et corrige vite les vulnérabilités. Les critiques objectent que rien ne garantit que tous les défauts seront trouvés, quel que soit le nombre de relecteurs ; publier le code ne supprime pas les vulnérabilités, et présumer automatiquement la fiabilité crée un faux sentiment de sécurité. Des programmeurs malhonnêtes peuvent trouver des failles sans les divulguer, parfois pour les exploiter ou faire chanter l'éditeur.

Le débat n'est pas tranché, mais un principe est admis : la "security by obscurity" ne marche pas. Cacher une technologie ne la protège pas durablement. Que le programme soit fourni en source ou seulement en exécutable, l'observation, le reverse engineering, le disassembly, le trial and error et le hasard peuvent révéler des vulnérabilités. L'open source n'est donc ni intrinsèquement plus sûr ni intrinsèquement plus dangereux : il demande une évaluation propre.

Un cas particulier est le logiciel orphaned. Une organisation se retrouve parfois bloquée avec des éléments que le fabricant d'origine ne supporte plus et pour lesquels aucun support tiers efficace n'existe. En 2019 et 2020, des cabinets médicaux au Royaume-Uni ont dû rester sous Windows XP car remplacer les dispositifs cliniques XP-dépendants dépassait leur budget. Piège d'examen : ne confondez pas legacy et orphaned. Un système legacy est encore supporté (en interne ou par un tiers) et reste, dans la limite du raisonnable, remédiable. Un technological orphan est globalement insupportable ; il devra être remplacé ou abandonné. Même sans code source ni documentation, l'évaluation reste utile : les données CVE révèlent des vulnérabilités potentielles que l'on peut parfois mitiger autrement. À terme, refactoring le processus métier entier qui dépend de la technologie orpheline est souvent la meilleure option.

6.3 Mergers and acquisitions : risques hérités

Lors d'un merger ou d'une acquisition (M&A), le nouveau propriétaire hérite à la fois des bons et des actifs douteux de l'organisation absorbée : systèmes d'information, infrastructures IT, données et personnes. L'évaluation de sécurité des architectures combinées est difficile. Les différences de culture organisationnelle se traduisent par des attentes et standards de documentation différents, ce qui peut rendre incompatibles ou incomplets le configuration management et l'identification des baselines, les inventaires d'actifs (énumération des systèmes, licences logicielles, niveaux de révision) et les inventaires de risques avec leurs stratégies de contrôle.

Le risque le plus dangereux est souvent invisible : l'organisation acquise peut apporter un legacy non documenté de data breaches, intrusions, malware et identités/contrôles d'accès compromis. La connaissance tacite de ces risques a parfois déjà quitté l'entreprise avec les employés partis avant le rachat. Le cas Marriott (2016-2020) illustre ce piège : en absorbant les opérations et l'infrastructure IT d'autres chaînes hôtelières, l'entreprise a hérité d'expositions préexistantes.

Piège d'examen : la sécurité est rarement prioritaire dans une M&A. L'organisation acquéreuse subit une forte pression de maîtrise des coûts pour absorber et rentabiliser la nouvelle activité, et a peu d'appétit pour allouer des ressources à une évaluation de sécurité approfondie des propriétés considérées. Le security professional doit donc anticiper : exiger une due diligence de sécurité avant la signature, et traiter les identités héritées et les CM incompatibles comme des risques de premier ordre, pas comme un détail post-fusion.

6.4 Commodity systems et COTS : due diligence

La grande majorité des logiciels en service dans une organisation sont des produits commerciaux vendus ou licenciés comme des commodities : ce sont les COTS (commercial-off-the-shelf), firmware ou produits embarqués - firmware de cartes mères ou de contrôleurs, OS, applications autonomes, suites bureautiques, plateformes applicatives. L'organisation n'est qu'un client parmi des milliers et n'a presque jamais le capital pour influencer le développeur afin qu'il satisfasse ses besoins spécifiques de sécurité. Par nature one-size-fits-all, la sécurité d'un COTS est souvent trop générique, voire inexistante.

Le security professional n'est pas pour autant désarmé : le choix du produit, et même du revendeur, peut et doit être influencé par des considérations de sécurité. Exploitez les données CVE - pour le produit visé mais aussi pour les autres produits du même vendeur. Recherchez la réputation du vendeur : réactivité aux rapports de vulnérabilité, rapidité d'émission de mises à jour, et usage de paquets de mise à jour signés (signed update packages) pour les distribuer. La même due care qui maintient le système sûr en exploitation doit servir de due diligence avant d'endosser la décision d'achat, de location ou de licence.

Piège d'examen (CYU 8.4) : le COTS est-il plus dangereux que le bespoke développé en interne ? La réponse attendue est oui : le caractère one-size-fits-all augmente le potentiel de failles de sécurité, car la sécurité y est générique ou absente. Elle peut être prise en compte, mais seulement après un risk assessment approfondi. Ne tombez pas dans le raisonnement inverse ("le COTS a forcément subi des tests rigoureux") qui est faux.

6.5 Services managés et cloud : responsabilité partagée

Les services managés permettent à une organisation de se concentrer sur son cœur de métier, de libérer ses ressources IT internes et d'obtenir des capacités qui auraient sinon demandé des équipes internes. Les prestataires sont des tiers appelés managed service providers (MSP). Les possibilités sont nombreuses : un système ERP (enterprise resource planning) en est un exemple ; un prestataire spécialisé dans le security monitoring et l'incident response s'appelle un managed security service provider (MSSP).

Les services cloud livrent à la demande, via internet, des capacités qui évitent au client d'acquérir et de maintenir l'infrastructure. Les offres as-a-service incluent Software as a Service (SaaS), Platform as a Service (PaaS) et Infrastructure as a Service (IaaS). Dans tous ces modèles, la sécurité et la conformité relèvent d'une shared responsibility entre le fournisseur et le client : plus on monte vers le SaaS, plus le fournisseur prend en charge la pile (matériel, runtime, application) ; plus on descend vers l'IaaS, plus le client conserve la responsabilité (OS, middleware, données, configuration). Les bénéfices sont l'efficacité, la réduction des coûts, la flexibilité et la scalabilité à la demande ; le plus notable pour le business est le passage de capital expenditure (CapEx) à operational expenditure (OpEx).

Piège d'examen : la shared responsibility ne signifie pas que le fournisseur assume toute la sécurité. En IaaS, le client reste responsable du système d'exploitation, des données et de la configuration ; une mauvaise configuration d'un bucket de stockage est la faute du client, pas du fournisseur. Sachez situer la frontière de responsabilité selon le modèle SaaS / PaaS / IaaS.

6.6 Supply chain : SCA et SBOM

Le raisonnement de l'objectif 8.4 - on dépend de logiciel qu'on n'écrit pas - se prolonge dans les pratiques modernes de software supply chain risk management. Une application n'est plus un bloc monolithique : elle agrège des dizaines voire des centaines de composants tiers et open source (bibliothèques, frameworks, conteneurs). Chacun apporte ses propres vulnérabilités et ses propres licences. Gérer ce risque suppose de savoir précisément ce que l'on embarque.

Le Software Composition Analysis (SCA) est l'outillage qui scanne automatiquement les dépendances d'un projet pour identifier les composants tiers, les corréler aux vulnérabilités connues (CVE) et signaler les problèmes de licence. Il prolonge la logique CVE de la due diligence COTS, mais appliquée aux composants internes du produit plutôt qu'au produit acheté entier. Le Software Bill of Materials (SBOM) est l'inventaire formel et lisible par machine de tous ces composants et de leurs versions - une nomenclature logicielle. Son but : quand une vulnérabilité majeure frappe une bibliothèque répandue, l'organisation peut interroger ses SBOM pour savoir en minutes quels produits sont affectés, au lieu d'auditer le code à l'aveugle.

Piège d'examen : ne confondez pas SCA et SAST. Le SAST (static application security testing) analyse votre propre code source à la recherche de défauts ; le SCA analyse les composants tiers que vous réutilisez. SBOM n'est pas un outil de scan mais une liste d'ingrédients ; c'est la transparence qui rend la réponse aux incidents de supply chain rapide et fiable.

7.1 Du source code au code exécutable

Le processus de développement traduit les idées des utilisateurs en un jeu d'instructions et de données qu'un ordinateur exécute. Cette traduction empile plusieurs couches, chacune s'éloignant du "business speak" des utilisateurs pour se rapprocher des chiffres binaires manipulés par le hardware. Quatre formes de code structurent cette descente. Le source code est un ensemble d'instructions écrites sous forme lisible par l'humain (mots, nombres, opérateurs, ponctuation) qui suit la syntax (structure) et la semantics (sens) d'un langage donné ; plusieurs programmes source corrects et complets peuvent implémenter le même design. L'executable code, aussi appelé object code, est la représentation binaire du jeu d'instructions machine que le CPU et le hardware cible exécutent directement.

L'intermediate code se situe entre le source code lisible et les valeurs binaires chargeables en mémoire. Son usage principal est d'offrir la machine independence ou portabilité : comme les CPUs ont des jeux d'instructions différents, un logiciel spécialisé (runtime engine) est requis pour chaque type de CPU. Le Java P-Code (bytecode) et le Microsoft Common Intermediate Language (CIL) sont les deux exemples canoniques. L'arbitrary code, lui, n'est pas une forme de langage : dire qu'une vulnérabilité permet l'"arbitrary code execution" signifie seulement que l'attaquant peut tromper le CPU pour qu'il exécute un jeu d'instructions différent de celui prévu par les concepteurs.

Les outils de traduction se répartissent selon ce qu'ils produisent (Figure 8.13). Les assemblers traduisent une instruction en une instruction machine et produisent des fichiers d'executable code (.exe) ; bénéfices : protection du source code, exécution répétable, vue directe du hardware, exécution rapide. Les compilers traduisent une instruction en de nombreuses instructions, produisent aussi des .exe ; vue orientée business logic, vitesse modérée. Les interpreters traduisent une instruction en de nombreux opcodes intermediaires sous forme de flux temps réel, traduits au runtime (système runtime Java) ; bénéfice clé : portabilité accrue entre architectures et debug/traceback au niveau de l'instruction. Piège d'examen : la plupart des vulnérabilités exploitables sont introduites au niveau du source code (erreurs de traduction du design vers le langage), rarement par les outils eux-mêmes - même si des versions infestées de malware de ces outils existent.

7.2 Faire exécuter des instructions à la machine

Aux débuts de la programmation, les développeurs codaient directement le programme objet (machine ou binaire) en écrivant les opcodes en binaire, puis en chargeant ces chaînes en mémoire pour exécution. L'assembly language a facilité ce travail : il existe une correspondance directe entre les mnemonics assembleur et des opcodes précis (MOV pour move, CMP pour compare, DEC pour decrement, ADD), mais les fichiers sont formatés de façon relativement lisible plutôt que comme des suites de nombres hexadécimaux ou binaires. L'assembly est dit low-level car une ligne (un statement) se traduit, dans presque tous les cas, en une seule instruction machine, et il est spécifique à un CPU donné.

Les high-level languages élèvent le niveau d'abstraction : le source code y est plus compréhensible pour l'humain. Un programmeur compétent y exprime des opérations complexes de façon concise, et s'il respecte des frameworks de codage standard, son code reste lisible et donc maintenable. La Figure 8.14 résume les chemins de l'idée humaine à l'exécution machine. Les compiled languages (FORTRAN, Modula) imposent deux étapes : on écrit le source code lisible, puis on le compile en object code (parfois via linkers et utilitaires) ; le source ne peut pas être exécuté directement. Les interpreted languages raccourcissent le cycle : l'interpreter traduit le source en langage machine au moment de l'exécution.

Le compromis est clair. Un programme compilé est natif pour le CPU, s'exécute directement depuis l'object code et tourne donc bien plus vite ; certains compilers optimisent en plus le code. Un programme interprété paie en performance car la traduction est refaite à chaque exécution, mais il gagne en portabilité : tant qu'un interpreter existe pour la plateforme cible, l'application tourne sur des machines variées (les scripting languages en sont l'exemple). Piège d'examen : ne confondez pas "compilé = rapide mais lié à la plateforme" et "interprété = portable mais plus lent" ; l'examen teste régulièrement cette opposition vitesse/portabilité.

7.3 Procédural vs objet et générations de langages

Deux façons de penser le travail structurent la programmation. Le procedural thinking raisonne en séquences d'étapes (avec branches conditionnelles, boucles, contrôles de séquence) : le procedural programming met l'accent sur le flux logique des étapes. Une procédure est un ensemble de logiciel qui réalise une fonction précise, demande des entrées spécifiques et produit des sorties définies (y compris des signaux d'erreur), et peut en appeler ("call") d'autres. L'object-oriented thinking raisonne en paquets nommés d'idées, d'étapes, de données et de logique : chaque paquet n'a pas besoin de connaître l'intérieur des autres. L'object-oriented programming (OOP) définit un object comme un ensemble de logiciel offrant des methods, internes à l'objet, que du code externe peut demander d'exécuter. Les deux approches encouragent le code reuse, l'ajout/modification de fonctionnalité, le refactoring, le data modeling, les data quality standards et les security practices (bibliothèques préapprouvées).

Les langages se classent aussi par level of abstraction (proximité du binaire) et par data type enforcement : la capacité d'un langage à empêcher des opérations sur des types incompatibles. On ne peut pas additionner "3" à un nom de personne ; ajouter 3 à une date suppose de trancher s'il s'agit de jours, mois ou années. Un strong typing protège donc le programmeur des erreurs de type. S'ajoutent le data protection / data hiding (empêcher un module de lire ou altérer les données privées d'un autre) et le code protection / logic hiding (empêcher de lire ou altérer le code source, intermédiaire ou exécutable d'un autre module).

Les générations de langages structurent l'historique. 1GL : machine language, opcodes, object code exécutés directement par le CPU - rares aujourd'hui, sauf reverse engineering de malware et craft de payloads binaires. 2GL : assembly language, symboles abrégeant les instructions, interaction directe avec le hardware (kernels, device drivers) - précieux aussi pour les attaquants. 3GL : HOLs utilisant des mots significatifs (COBOL, FORTRAN, BASIC, Java, C). 4GL : report generators, application generators, plateformes "codeless" drag-and-drop, scripting languages. 5GL : natural language interfaces, langages logiques ou contraint-based, parfois appuyés sur l'IA (NLP, machine learning), largement tombés en désuétude dès les années 1990. Piège d'examen : retenez le mapping 1GL machine, 2GL assembly, 3GL HOL, 4GL générateurs/codeless, 5GL langage naturel, et que chaque génération introduit des contrôles de sécurité et de fiabilité absents de la précédente.

Deux metriques de qualite de conception structurent le decoupage en modules ou objets : le coupling (couplage) mesure le degre de dependance entre modules, et la cohesion mesure a quel point les elements d'un meme module concourent a une seule responsabilite. L'objectif de conception est un low coupling (modules independants, modifiables isolement) et une high cohesion (chaque module fait une chose et la fait bien). Un code a fort couplage et faible cohesion est fragile : une modification se propage partout, la reutilisation securisee devient impossible et la surface d'attaque augmente. L'encapsulation favorise directement low coupling et high cohesion.

7.4 Concepts orientés objet et systèmes OO distribués

L'OOP renverse la perspective : on s'intéresse aux objects à manipuler plutôt qu'à la logique qui les manipule. Un object est un bloc d'instructions offrant des methods de travail sur des données ; il encapsule à la fois les données et les instructions de traitement, et se réutilise dans tout programme qui en a besoin (Java, Python, C++, C#, Ruby, Smalltalk). Quatre caractéristiques dominent. L'encapsulation : une classe ne définit que les données qui la concernent, et une instance ne peut pas accéder accidentellement à d'autres données - c'est le data hiding. L'inheritance : on définit des subclasses partageant tout ou partie des caractéristiques de la super class ; si la sécurité est bien implémentée dans la classe haute, les sous-classes en héritent. Le polymorphism : un objet peut "prendre plusieurs formes" selon son usage, donc une modification ne se propage pas à toutes les applications - mais attention, des methods sécurisées peuvent être perdues à travers le polymorphism, à évaluer soigneusement.

La polyinstantiation est la caractéristique OO la plus utile à la sécurité. Elle crée une nouvelle version d'un objet sous le même identifier/key, de sorte que différents processus utilisateurs ont leur copie locale ; elle permet à différentes versions de la même ressource d'exister à différents niveaux de classification. Elle empêche ainsi des utilisateurs ou processus de niveau inférieur de connaître l'existence d'un niveau supérieur. C'est précisément ce qui prévient l'inference : l'inference est la capacité d'un utilisateur à déduire une information plus sensible en observant une information autorisée. La polyinstantiation contre les inference attacks contre les bases de données en laissant coexister plusieurs versions à des classifications distinctes.

Les distributed OO systems découpent l'application en composants logiques répartis sur plusieurs machines, qui communiquent et s'appellent à la demande, code téléchargé depuis des machines distantes de façon transparente. Exemples : CORBA, Java RMI, EJB (modèle Sun fournissant un environnement proche de CORBA via des API et s'appuyant sur RMI), et DCOM. Pour standardiser la localisation, l'initiation et l'envoi de requêtes aux objets, l'Object Management Group (OMG) a créé l'Object Request Broker (ORB), pièce centrale de CORBA (Figure 8.15). L'ORB s'intercale entre client et serveur, indépendamment du processeur ou du langage ; côté sécurité, il traite toutes les requêtes et peut appliquer les politiques. Le CORBA security service couvre quatre types de policies : access control, data protection, non-repudiation, auditing. Piège d'examen : associez ORB à CORBA/OMG, et retenez que polyinstantiation est la réponse au mot-clé "inference".

7.5 Qui écrit votre code source ? Le spectre de confiance

Demander "qui écrit votre code source ?" revient à demander comment on assure la sécurité et l'intégrité de sa supply chain logicielle. Les fournisseurs se rangent sur un spectre de confiance décroissant. En haut, les major hardware and systems vendors disposent en général de processus robustes et fiables garantissant l'intégrité et la sécurité de leurs produits. Viennent ensuite les applications software providers, parfois de grandes entreprises servant des millions d'utilisateurs, dont les mises à jour et le support sûrs renforcent la trustworthiness. Les third-party developers produisent du logiciel sur mesure ou tailorent un produit commercial, mais ne doivent être engagés que si l'on s'accorde sur la façon de fournir et d'évaluer la sécurité. Les in-house developers travaillent dans un cadre formalisé de quality assurance, configuration management et security assessment, offrant autant de contrôle et d'accountability que l'organisation veut bien y investir.

Les couches suivantes deviennent de moins en moins sûres. Les open-source providers offrent un support après téléchargement variable, parfois nul, et pas toujours via des moyens vérifiables comme des téléchargements signés (avec aussi shareware ou freeware). Les citizen programmers - membres de l'organisation qui codifient leur savoir en scripts ou programmes 4GL, souvent à partir d'exemples trouvés en ligne et légèrement modifiés - opèrent presque toujours hors de portée des processus de software quality, de configuration management ou de security assessment, avec peu d'égard pour la sécurité. Tout en bas, le mobile code est la forme la moins intrinsèquement fiable : les propriétaires du système récepteur n'ont aucune visibilité ni influence sur son développement.

Le mobile code (aussi appelé executable content, mobile agents, downloadable code, active capsules) déplace le code lui-même, pas seulement les données, souvent sans action ni consentement explicite de l'utilisateur. Distinction d'examen : les mobile agents migrent d'hôte en hôte à des moments et des endroits qu'ils choisissent, avec une forte autonomie, donc difficiles à contrer s'ils sont malveillants ; les applets sont téléchargés suite à une action utilisateur puis exécutés du début à la fin sur sa machine (ActiveX, Java applets, scripts dans le navigateur). Comme le code finira par tourner localement, deux contrôles limitent le risque : faire tourner le code dans un environnement restreint où il ne peut nuire (sandbox), et utiliser une authentification cryptographique (certificats et signatures) pour authentifier la provenance du code. Le sandbox limite l'accès aux ressources système (file system, CPU, réseau).

7.6 Buffer overflow et erreurs d'entrée exploitables

Un buffer est une zone contiguë de stockage utilisée pour transférer des données d'un device, programme ou processus à un autre. Une condition de buffer overflow existe quand ce buffer reçoit plus de données qu'il n'a été conçu pour en contenir : trop de texte dans une boîte de dialogue, une URL beaucoup trop longue, un paquet réseau surdimensionné. L'application déborde alors la mémoire allouée au buffer et écrit l'excédent dans la mémoire système, qui peut être réservée au traitement des instructions. Si l'attaque est menée habilement, l'excédent contient des instructions en langage machine : au prochain pas d'exécution, le code de l'attaquant s'exécute (Figure 8.16). Souvent un code négligent laisse une boucle écrire au-delà des 16 octets déclarés du buffer ; la vulnérabilité existe si la source peut pousser plus de 16 octets sans que le logiciel ne s'en aperçoive, écrivant le 17e octet hors du buffer. Le résultat visé est de placer les instructions de l'attaque en mémoire et de les faire exécuter - c'est l'arbitrary code execution, qui sert typiquement à élever les privilèges.

Le buffer overflow est techniquement une forme de malformed input. Un logiciel sûr doit faire deux choses : n'accepter une entrée que si elle passe une série de constraint checks bien définis (sinon la rejeter), et ne jamais mal se comporter, échouer anormalement ou autoriser l'arbitrary code execution quand l'entrée ne respecte pas toutes les contraintes. Les malformed input attacks fournissent des données incohérentes pour provoquer un dysfonctionnement : une app bancaire peut accepter un retrait maximal de £10 000, mais tenter d'en saisir £11 000 ne doit jamais la faire planter. Le defensive programming traduit la business logic sur les entrées acceptables et dangereuses en code qui traite les bonnes et bloque sûrement les injections. Subtilité : une URL sur liste de blocage exprimée en ASCII plutôt qu'en Unicode peut échapper au firewall alors que le navigateur la convertira sans peine.

Les contrôles contre l'incomplete parameter checking vont au-delà du test de chaque paramètre isolément : le logiciel récepteur doit tester l'ensemble des valeurs pour cohérence, validité et complétude (une false invoice attack peut utiliser un customer ID inexistant mais conforme au format). Les buffer overflows se préviennent à plusieurs niveaux : enforcer le bounds checking (interdire l'accès au-delà du buffer), utiliser un langage à strong typing isolant le code des données, et détecter/intercepter proprement les erreurs (même un divide-by-zero peut ouvrir une exploitation). Deux attaques d'injection découlent du même défaut : la SQL injection, où des structures syntaxiques trompent les filtres qui voient la requête comme un commentaire et non une instruction, renvoyant plus d'informations que prévu ; et le cross-site scripting (XSS), où un site acceptant des entrées d'utilisateurs (un blog) ne détecte pas que l'entrée est un active scripting exécuté ensuite chez d'autres utilisateurs.

7.7 Covert channels et réutilisation de mémoire

Un covert channel (ou covert path) est un canal de communication entre deux processus ou plus qui transfère de l'information en violant une politique ou une exigence de sécurité. Il emprunte souvent des moyens de transmission qu'on ne considère pas comme des communications, ce qui le rend indétectable ou non bloqué par les méthodes de sécurité routinières. Il se crée de deux façons : wittingly, par la conception coopérative et délibérée des deux processus pour créer et gérer le canal ; ou unwittingly, par un processus hostile exploitant des expositions d'information jusque-là non reconnues du système cible. En facilitant le passage furtif d'information, les covert channels servent à exfiltrer des données sensibles mais aussi de mécanisme de command-and-control dans une attaque par advanced persistent threat (APT).

Deux types s'opposent. Le covert storage channel (CSC) implique l'usage direct ou indirect (lecture/écriture) d'un emplacement de stockage par un processus, et l'usage du même emplacement par un autre : emplacements mémoire, secteurs disque partagés, cache, ou bits inutilisés dans les en-têtes de trafic réseau. Le CSC peut violer la politique directement (si le processus hostile opère à un niveau de sécurité inférieur) ou indirectement (maillon d'un pipeline d'exfiltration). Le covert timing channel (CTC) modifie la temporisation du comportement d'une ressource pour transmettre de l'information à un processus observateur, comme moduler de l'information sur un train d'impulsions ; exemple : étirer le temps de réponse à un handshake juste avant le timeout pour signaler. Les CTC sont souvent difficiles à détecter. Tout covert channel s'appuie sur une ressource partagée : on les identifie en conception en repérant les ressources partagées susceptibles d'abus, puis on décide lesquels mitiger (redesign, access controls plus stricts).

Le memory or object reuse pose un risque connexe. La gestion mémoire alloue, désalloue puis réalloue des sections à différents processus (RAM, cache, disque). Si de l'information résiduelle subsiste quand une section est réassignée, le processus suivant peut lire et réutiliser ces données : c'est un memory leak, exemple typique de CSC (le plus souvent unwitting). Cela vaut pour toute ressource où l'on peut stocker : mémoire principale, file storage, buffers matériels, et surtout le fichier de pagination/swap, souvent laissé non protégé et riche en informations sensibles. Les data remanence controls limitent voire éliminent ce risque : du hardware/firmware jusqu'aux applications, tout élément doit garantir que le contenu de ses ressources mémoire est randomisé, mis à zéro (zeroed) ou autrement écrasé (overwritten) avant d'être alloué à un autre processus. Piège d'examen : memory leak et page/swap non protégé sont des exemples de CSC, pas de CTC.

7.8 Vecteurs d'attaque temporels : TOCTOU, race conditions, backdoors

Les attaques contre les systèmes distribués s'appuient souvent sur deux leviers complémentaires. Le social engineering manipule émotionnellement une victime (déception, intimidation, abus de hiérarchie, exploitation de la culpabilité ou du désir d'aider) pour obtenir une information ou un accès et contourner les contrôles ; il pave la voie aux attaques techniques plus sophistiquées. La formation et l'awareness des end-users sont la première et meilleure ligne de défense, au-delà du seul phishing par email.

Le Time of Check vs Time of Use (TOCTOU) exploite un changement de la control information entre le moment où les fonctions de sécurité vérifient une variable et le moment où cette variable est utilisée. Exemple : un employé connecté le matin est licencié, son compte est désactivé, mais comme il ne s'est pas déconnecté, sa session conserve ses privilèges - d'où l'importance du deprovisioning. Dans la Figure 8.17, le Process 1 valide les credentials pour ouvrir le fichier A (non sécurisé) et le Process 2 accède au fichier ; l'attaquant redirige le Process 2 vers un fichier sécurisé (paie) après l'autorisation mais avant l'exécution. Contre-mesure : le software locking (verrou sur le fichier/ressource) empêche la substitution du fichier pendant la validation d'accès.

Une race condition existe quand deux tâches dépendent chacune de l'achèvement de l'autre pour leur entrée, et doivent s'exécuter dans le bon ordre (Process 1 puis Process 2). Si un attaquant perturbe cet ordre, il manipule le résultat combiné : par exemple forcer le processus d'authorization à s'exécuter avant l'authentication accorderait l'accès sans authentifier l'identité. La parade est d'imposer des atomic operations et de ne pas découper les tâches critiques. La différence est subtile mais cruciale : dans une race condition, l'attaquant contrôle le résultat en forçant deux processus à s'exécuter hors séquence ; dans un TOCTOU, l'attaquant s'insère entre deux processus en cours d'exécution pour rediriger le second. La between-the-lines attack relève d'une autre famille : l'attaquant exploite des lignes de télécommunication tapées (piggyback sur une ligne en cours) pour injecter de fausses données - à ne pas confondre avec un backdoor, une race condition ou un buffer overflow. Enfin, trapdoor, backdoor et maintenance hook désignent un moyen caché de transfert de contrôle laissé dans le code, qui offre une entrée non prévue contournant l'authentification.

8.1 Menaces aux bases de données et data warehouses

Les bases de données et data warehouses présentent une surface d'attaque riche. La menace phare est le couple aggregation / inference. L'aggregation consiste à combiner des données non sensibles issues de sources séparées pour produire une information sensible : un utilisateur assemble deux fragments non classifiés et obtient un ensemble classifié auquel il n'a pas droit, car la sensibilité du tout dépasse celle des parties. L'inference va plus loin : c'est la capacité à déduire une information plus sensible que celle à laquelle on est autorisé. Pouvoir agréger ouvre souvent la voie à l'inference.

Les autres menaces : les bypass attacks contournent les contrôles du front end (DBMS et query engine) en passant par d'autres voies que l'interface ou la CLI ; la compromission des database views, quand un utilisateur accède à des vues restreintes ou en modifie une (la view limite ce que l'on voit, pas les opérations possibles) ; les routes d'accès alternatives mais non équivalentes, car le modèle en couches offre plusieurs chemins vers la même donnée (view, requête directe, accès direct aux fichiers) dont tous ne sont pas protégés ; la data contamination par des entrées malformées au niveau champ, enregistrement, transaction ou fichier.

Le deadlocking (ou 'deadly embrace') survient quand deux processus concurrents détiennent chacun un verrou sur un objet et attendent le verrou de l'autre ; le système abort l'une des transactions (idéalement la moins coûteuse à roll back) pour débloquer la situation. Viennent ensuite le DoS (requête ou table scan qui sature les tables), la modification incorrecte (problème d'integrity), l'interception des données en transit lors d'un accès distant, les query attacks (outils ou SQL malformé pour contourner le trusted front end et ses views), l'accès physique/logique direct au serveur, le TOCTOU (du code change la donnée entre l'approbation de la requête et son affichage) et les attaques web (pages statiques ou dynamiques exposant des données sensibles via 'show code'). Piège : aggregation et inference sont les termes que l'examen attend ici, ne les confonds pas avec une simple unauthorized access.

8.2 L'environnement base de données et data warehouse

Une base de données est un dépôt d'information organisée et précieuse. Historiquement, les organisations géraient des fichiers, difficiles à maintenir et propices aux erreurs et incohérences. Les architectures de bases ont répondu à ce problème, avec le DBMS (Database Management System) en leur coeur : une suite d'applications qui gère les bases et leur environnement. Le coeur du DBMS est le database engine, application centrale qui réalise les fonctions CRUD (create, read, update, delete) et rend les données disponibles pour affichage ou export, en garantissant confidentiality, integrity et availability.

La base elle-même est une vaste collection structurée de tables de données persistantes et liées. Du point de vue de l'OS, c'est un ensemble d'espaces fichiers gérés par le DBMS, non lisibles utilement comme un fichier normal par d'autres applications. L'environnement complet peut inclure des VM, des composants middleware entre applications et engine, des utilitaires et de plus en plus un front end web. Chaque composant ajouté augmente la complexité et les exigences de sécurité : on sécurise une architecture en sécurisant chacun de ses composants.

Quand les organisations ont multiplié les bases, elles ont regroupé les données dans des data warehouses pour offrir un contexte plus riche à l'analytique, au trending et au reporting. Un data lake désigne de grandes collections de données non encore mises au format commun d'un warehouse ; un data farm est un endroit où l'analytique prédictive génère des données entre des points connus ou observés. L'ensemble de ces sources interconnectées via internet est appelé, de façon lâche, big data. Piège : data lake = données brutes non structurées en commun ; data warehouse = données intégrées et structurées pour l'analyse.

8.3 Modèles hiérarchique, réseau et graphe

Un database model décrit les relations entre les entités de données et fournit le cadre d'organisation. Tout modèle doit satisfaire des exigences minimales : transaction persistence (l'état après transaction est durable), fault tolerance and recovery via rollback (annuler proprement les transactions incomplètes ou invalides) et shadowing (réappliquer les transactions à une version antérieure, à l'aide du transaction logging), sharing entre plusieurs utilisateurs simultanés sans nuire à l'integrity, et security controls (confidentiality, integrity, availability, access controls, view definitions). À ne pas confondre : un database model décrit l'organisation/structure/architecture offerte par le DBMS, alors qu'un data model décrit les types de données propres à une organisation (un data model 'customer' liste name, address, etc.).

Le modèle hierarchical est le plus ancien (années 1950-60). Il stocke les données en enregistrements porteurs de valeurs de champs, regroupe les instances d'un même enregistrement en record type, et crée les liens via des relations parent-enfant en structure d'arbre. Puissant et adaptable pour organiser des données dissemblables, mais difficile à étendre quand de nouvelles fonctions métier apparaissent.

Le modèle network (aussi appelé CODASYL, 1959, à l'origine de COBOL) représente les données en réseau d'enregistrements et de sets reliés par des linked lists. Les record types équivalent aux tables du relationnel, et les set types expriment les relations entre deux record types. Plus performant que le hierarchical pour certaines fonctions, mais moins flexible que le relationnel. Il trouve aujourd'hui deux usages forts : le stockage haute performance/haut volume en parallèle (clouds, moteurs de recherche) et les graph databases. Le modèle graph représente noeuds (objets) et arcs étiquetés décrivant la nature de la connexion ; Neo4J est utilisé en détection d'insider threat, anti-blanchiment et contact tracing COVID-19. Piège : 'network' ne désigne pas un réseau informatique mais un réseau de liens entre enregistrements.

8.4 Le modèle relationnel, l'object-oriented et le test ACID

Le modèle relationnel structure les données en tables (ou relations) à deux dimensions : des colonnes représentent les variables, des lignes contiennent les instances de données, organisées en normal forms qui permettent de lier les tables entre elles. Il offre trois éléments : les structures de données (tables/relations), les règles d'integrity sur les valeurs admissibles, et les agents de manipulation fournissant la base mathématique relationnelle. Vocabulaire à maîtriser : chaque table est un set (ensemble non ordonné) ; chaque ligne est un tuple (record) contenant des attributes (fields), un par colonne ; l'un des attributes est désigné comme primary key, d'autres peuvent aussi être des keys. On retrouve un tuple par recherche de valeurs ou via le primary index ; un filtrage produit un sous-ensemble ; un join relie deux tables ou plus via des attributes spécifiés. Le relationnel est devenu dominant dans les DBMS.

Le modèle object-oriented (OO) stocke les données sous forme d'objets, collections d'éléments publics et privés assortis des opérations (methods) exécutables sur eux. Comme l'objet porte ses propres opérations, tout appel à la donnée a potentiellement accès à toute la gamme des fonctions, d'où une exigence de sécurité forte. Le modèle OO ne requiert pas forcément un langage de haut niveau comme SQL puisque les fonctions sont contenues dans les objets, ce qui évite le surcoût de langage. L'évolution naturelle, le modèle object-relational, est un hybride combinant les avantages du relationnel et de l'OO et offrant un chemin de migration.

Les modèles sont souvent évalués via le test ACID : Atomicity (la transaction est tout ou rien, indivisible), Consistency (la transaction respecte les contraintes d'integrity et laisse la base cohérente), Isolation (les transactions concurrentes restent invisibles les unes aux autres jusqu'à leur achèvement) et Durability (les effets validés sont permanents). Piège central : Isolation = invisibilité jusqu'à la fin, à ne pas confondre avec Atomicity (tout ou rien), Consistency (contraintes d'integrity) ou Durability (permanence).

8.5 Langages d'interface et connexion aux bases

Les langages d'interface (souvent appelés query languages) permettent aux utilisateurs, administrateurs et applications de demander des services au DBMS. La connexion doit toujours passer par authentication et authorization. SQL, créé chez IBM au début des années 1970 pour le relationnel, reste la lingua franca des bases. Il établit trois concepts : schemas (structure de la base, dont les access controls), tables (colonnes et lignes) et views (down-selections de lignes/colonnes créées dynamiquement par utilisateur, qui implémentent les politiques de sécurité et la granularité d'accès, par exemple separation of duties ou data classification). SQL se décompose en trois sous-langages : DDL (Data Definition Language) pour créer bases, tables, views et keys, réservé aux administrateurs ; DML (Data Manipulation Language) pour interroger, insérer, supprimer et mettre à jour les données ; DCL (Data Control Language) pour établir et contrôler l'accès aux données. Le DCL portant l'aspect contrôle de sécurité, le security professional doit y prêter attention.

Les markup languages ne sont pas des langages de programmation : ils expriment la mise en forme des données. HTML décrit la disposition d'une page. XML, le plus reconnu après HTML, assure stockage et transport de données en réseau et sert d'interface entre les pages web (front end) et les bases (back end) ; il est un exemple de mobile code et sert souvent à définir des metadata. XML embarqué doit être inspecté et encadré par des frameworks de confiance.

Pour connecter les applications aux bases : ODBC (Open Database Connectivity, de Microsoft) est le moyen dominant d'accès standardisé ; il traduit les commandes applicatives vers le système de base cible, permettant de changer de DBMS avec peu de modifications, mais comme il opère en entité système il est vulnérable (identifiants en clair, données en cleartext, vérification d'accès parfois insuffisante, aggregation entre sources). JDBC (Java Database Connectivity, de Sun) connecte les programmes Java aux bases, directement ou via ODBC. OLE DB, fondé sur le COM (Component Object Model), relie des données entre divers DBMS et fonctionne en middleware client ou serveur. ADO (ActiveX Data Objects, de Microsoft) est une interface de haut niveau qui simplifie l'usage d'OLE DB (front-end client ou objet métier en middle-tier), critiquée pour son accès non restreint au système, atténué par le sandboxing des navigateurs récents. Enfin, l'approche tiered (3-tier : presentation, business logic, data) renforce la sécurité car l'utilisateur ne touche pas directement la donnée mais passe par la couche business logic ; le risque est de perdre les fonctions de sécurité de la base dans la traduction par la couche intermédiaire. Piège : ODBC ne s'appuie pas sur HTTP, contrairement aux REST APIs.

8.6 Accès via internet, analytique et knowledge discovery

Le metadata est l'information qui décrit une autre information, littéralement 'data about the data'. Il fournit une méthode systématique de description des ressources et améliore la précision de recherche. Il révèle des relations invisibles entre données, permet de corréler des données jugées non liées et donne les clés des données critiques d'un data warehouse. Comme le warehouse est généralement au plus haut niveau de classification alors que ses utilisateurs ne le sont pas, les données non publiques doivent être retirées du metadata : on abstrait les corrélations sans exposer les données sous-jacentes. Les données du warehouse sont exploitées via OLAP, data mining ou KDD.

L'OLAP (Online Analytical Processing) permet à l'analyste de formuler des requêtes puis d'en définir d'autres selon les résultats, en parcourant les données ('roaming') pour présenter ensuite l'information au management. Le data mining lance des requêtes sur le warehouse pour révéler relations, patterns, corrélations et tendances cachés, à l'aide de techniques mathématiques et statistiques. Risques : atteinte à la vie privée si l'on mine des données individuelles, et data contamination quand des erreurs de collecte/transformation/chargement produisent des relations inexactes. Aspect positif : miner les audit logs pour repérer des événements anormaux. Le knowledge management gère efficacement l'information et les ressources de l'entreprise pour produire de la business intelligence, en s'appuyant souvent sur le data warehouse et désormais sur l'IA.

Le KDD (Knowledge Discovery in Databases) est une méthode mathématique, statistique et de visualisation pour identifier des patterns valides et utiles et en dériver une information signifiante, généralement obtenue par des techniques d'IA plutôt que des requêtes standards. Ses approches incluent le modèle probabiliste (graphes, incertitude), l'approche statistique (découverte de règles, dont OLAP est un exemple), la classification (regroupement par similarité, suppression des redondances) et l'analyse de déviation et de tendance (filtrage, ex. un IDS). Côté contre-mesure d'inference, la polyinstantiation crée plusieurs versions d'un enregistrement à différents niveaux de classification, empêchant la déduction d'information sensible. Les contrôles de sécurité du KDD : protéger la knowledge base comme toute base, vérifier régulièrement que les sorties correspondent aux entrées attendues, soumettre les changements de règles à un change control, relancer des requêtes si une sortie paraît suspecte, intégrer le risque dans les décisions et établir une baseline de performance attendue. Piège : KDD = visualisation et identification de patterns pour la décision ; data mining = extraction des relations cachées.

9.1 Environnement des applications web et OWASP Top 10

L'environnement des applications web est l'endroit où une application tourne sur un serveur et expose l'interface par laquelle les utilisateurs interagissent avec l'organisation. Comme il est accessible à tout l'internet, il devient une cible privilégiée : les statistiques montrent que la plupart des attaques visent désormais la couche applicative (le serveur web lui-même, les scripts maison, les front-ends e-commerce) plutôt que les plateformes sous-jacentes. Une fois l'application compromise, l'attaque de l'OS et du reste de l'architecture devient généralement possible. Un site est facilement aspiré par des outils de traversal qui suivent chaque lien pour en faire une copie locale : le même transfert de mobile code qui sert le navigateur légitime sert aussi la reconnaissance technique de l'attaquant.

Les sites souffrent d'erreurs de conception classiques : tenter de réinventer (coder soi-même) le contrôle d'accès et l'authentification, vouloir concevoir sa propre cryptographie, faire du hard-coding de credentials ou de données sensibles dans les pages ou les scripts, mal gérer le contrôle d'accès, et surtout coder une input validation absente ou défaillante. Chaque page, chaque lien, chaque opération GET ou POST est un point de la threat surface qu'un attaquant peut découvrir et exploiter. Les attaques les plus fréquentes sont : DoS et DDoS, man-in-the-middle (MITM), SQL injection, cross-site scripting (XSS) et cross-site request forgery (CSRF).

Les stratégies de protection émergent des leçons douloureuses : un processus de security sign-off pour les serveurs web, le hardening de l'OS (retrait des comptes et configurations par défaut, permissions correctes, patches à jour), des vulnerability scans avant déploiement, le déploiement d'IDS/IPS, des application proxy firewalls, la désactivation de la documentation et des librairies inutiles, la sécurisation ou le retrait des interfaces d'administration, l'accès limité aux hôtes autorisés avec authentification forte (MFA), le non hard-coding des credentials, l'account lockout, le logging étendu et le chiffrement de tout le trafic d'authentification.

Le Open Web Application Security Project (OWASP) est la ressource de référence pour le développement web sécurisé. Il fournit de nombreux projets (Zed Attack Proxy, Web Security Testing Guide, Cheat Sheet Series, Security Knowledge Framework) mais le professionnel de la sécurité doit avant tout connaître le OWASP Top 10 des vulnérabilités d'applications web et savoir les mitiger. Piège d'examen : OWASP n'est pas un outil, c'est un projet/communauté ; et le Top 10 est une liste de catégories de risques, pas un classement de produits.

9.2 Défenses du code web et secure coding standards

Du fait de l'accessibilité des systèmes web, l'input validation devient la défense essentielle : il faut valider toute donnée entrante (et la sortie). Les application proxy firewalls aident mais doivent gérer les exploits connus - buffer overflows, problèmes d'authentification, scripting, passage de commandes à la plateforme sous-jacente (SQL vers le moteur de base de données), problèmes d'encodage (Unicode) et encodage/traduction d'URL. La règle d'or : le plus grand défi survient quand une donnée passe de n'importe quoi à n'importe quoi d'autre - la validation doit être adéquate à ce moment précis. À l'input validation s'ajoute l'output encoding, qui neutralise les données avant de les renvoyer au navigateur (défense centrale contre XSS).

Le session management mérite une attention particulière car HTTP est un protocole stateless : la sensation d'attachement au serveur est portée par d'autres technologies (cookies, données d'URL) qui doivent être protégées et validées. Si des cookies sont utilisés, ils doivent toujours être chiffrés. La validation temporelle fait partie du session management : il faut interdire les cookies, numéros de session ou données d'URL séquentiels, calculables ou prédictibles, et toujours utiliser des indicateurs aléatoires et uniques. Comme pour tout environnement applicatif, on valide tout l'input et l'output, on fait fail secure (closed), on garde l'application aussi simple que possible, on emploie pen testing et secure network design, et on applique le defense in depth (DiD). À ne jamais faire : cacher les pages sécurisées, faire confiance aux données du client, ou faire confiance automatiquement aux données d'autres serveurs ou partenaires.

Les secure coding guidelines & standards encouragent les développeurs à suivre un ensemble de règles déterminées par les besoins de l'organisation, plutôt que de coder selon leur préférence ou leur familiarité. Des standards existent par langage (C, C++, Java, Perl) et proviennent de groupes comme la division CERT du SEI et l'OWASP. Le strong data typing aide l'exécution sûre : un langage type-safe (strongly typed) insère de la logique à la compilation empêchant le misuse d'un type de donnée - arrays qui restent in bounds, pointeurs toujours valides, impossibilité de placer du code dans une string puis de l'exécuter (ce qui prévient les injections). Java fait du static type checking ; en C/C++, l'accès mémoire par pointeurs est l'une des principales sources de vulnérabilités, d'où l'intérêt de contrôler ou restreindre leur usage.

Deux dernières pratiques. D'abord, limiter le reuse aux trusted libraries : réutiliser un snippet est tentant mais risqué car le programmeur peut mal comprendre ce que fait le code, ou le code peut ne pas fonctionner correctement - les équipes doivent fixer des limites fermes au reuse et des politiques sur les librairies approuvées. Ensuite, faire respecter les standards a deux faces : administrative (instruire, motiver, engager l'équipe) et technique (exploiter les fonctionnalités des IDE, des systèmes de configuration management et change tracking, et au besoin des audits d'usage). Piège d'examen : input validation et output encoding sont les deux défenses fondamentales du code web - les distinguer, l'une filtre ce qui entre, l'autre neutralise ce qui sort.

9.3 Sécurité des API REST et options d'authentification

Les API (Application Programming Interfaces) sont les connecteurs qui permettent à des composants différents de communiquer - tel un messager qui transporte l'information entre les applications d'un système pour qu'il fonctionne de façon transparente. L'IoT en est l'exemple parfait : quand un bracelet de fitness envoie votre temps de jogging à un site, quand vous déverrouillez une voiture depuis une app, quand vous changez la température de votre thermostat depuis le bureau, une API travaille en coulisse. Ces API doivent être gérées et sécurisées, sinon de mauvais messages influencés par des attaquants peuvent atteindre les applications. Le cadre fédérateur est la data governance : un développement structuré et contrôlé des API qui sécurise tous les échanges de données dès le début du cycle de vie.

Les sites et apps web existent sous deux formes : stateful (les deux parties suivent une séquence partagée, comme la négociation d'une session HTTPS) et stateless (pas de synchronisation requise, comme UDP). Representational State Transfer (REST) n'est pas une architecture mais un style architectural pour bâtir des services au-dessus du web ; il utilise du simple HTTP pour permettre l'interaction via des URLs simplifiées. C'est justement parce que REST repose sur du HTTP simple que protéger les services REST devient délicat : c'est faisable, mais cela demande un travail rigoureux et cohérent à l'échelle de l'entreprise.

Les recommandations REST : employer les mêmes mécanismes de sécurité que pour toute application web (si vous filtrez le XSS sur le front, faites-le aussi pour vos API, idéalement avec les mêmes outils) ; ne pas réinventer sa propre solution de sécurité mais utiliser un framework peer-reviewed ; ne pas se contenter d'une authentification à clé unique (sauf API publique gratuite en read-only) ; ne jamais transmettre de clés statiques non chiffrées ; et idéalement utiliser HMAC (hash-based message authentication code) avec SHA-2 ou SHA-3, en évitant SHA-1 et MD5 à cause de leurs faiblesses connues.

Trois options d'authentification pour les API REST. Basic authentication avec TLS : la plus simple à implémenter (incluse dans la plupart des frameworks) mais la moins sûre ; à ne jamais utiliser sans TLS, sinon le couple login/mot de passe se déduit facilement. OAuth 1.0a : la plus sûre des trois, elle utilise une signature cryptographique (typiquement HMAC-SHA1) combinant le token secret, un nonce et d'autres infos ; son grand avantage est que le token secret n'est jamais transmis sur le réseau, ce qui en fait la seule des trois utilisable sans TLS (TLS reste recommandé selon la sensibilité). OAuth 2 : l'évolution suivante, elle supprime les signatures - plus besoin d'algorithmes cryptographiques pour les générer - car tout le chiffrement est désormais assuré par TLS, qui devient obligatoire. À considérer aussi : KMIP V1.1 et les HSM pour la gestion des clés et certificats, et la OWASP REST Security Cheat Sheet (qui recommande des session tokens pour protéger l'authentification des sniffers). Piège d'examen : OAuth 1.0a signe (utilisable sans TLS) ; OAuth 2 ne signe plus et exige TLS.

REST n'est pas la seule famille d'API : SOAP (Simple Object Access Protocol) est un protocole plus ancien, base sur XML, strict et fortement type, qui transporte des messages via une enveloppe XML et integre WS-Security (signature, chiffrement, tokens au niveau du message). SOAP est stateful et adapte aux transactions critiques ou aux contrats formels (WSDL) ; REST est leger, stateless, s'appuie sur les verbes HTTP et JSON, et domine le web et le mobile. Piege d'examen : SOAP porte sa propre securite de message (WS-Security) independante du transport, alors que REST s'appuie sur TLS pour proteger les donnees en transit.

9.4 Taxonomie des logiciels malveillants (malware)

Le malware compromet l'intégrité d'un système, souvent en s'attachant à des programmes ou fichiers exécutables et en délivrant un payload (charge utile) qui efface des données, en altère, ouvre des covert channels ou exfiltre des informations - on parle de negative payload. Le malware réussit largement grâce à sa composante de social engineering. Au cœur de la taxonomie : le virus, programme écrit pour se copier et se disperser sans la coopération de l'utilisateur ; la définition de Fred Cohen (1984) le décrit comme un programme qui modifie d'autres programmes pour y inclure une version de lui-même. Point clé d'examen : un virus exige une action de l'utilisateur (double-clic sur une pièce jointe, lancement d'un programme) pour infecter. Les types de virus incluent : file infectors (infectent fichiers programme/objet ; les system infectors visant l'OS en sont une sous-catégorie), boot sector infectors (remplacent le master boot record), macro viruses (via VBA dans Word/Excel, infectent des fichiers de données comme NORMAL.DOT), script viruses (fichiers autonomes .vbs interprétés, ex. LoveLetter), multipartite (infectent plusieurs types d'objets ou se reproduisent de plusieurs façons, ex. Nimda), companion viruses (créent une copie avec une autre extension, ex. .COM avant un .EXE) et email viruses (exploitent les fonctions de la messagerie, ex. Melissa).

Le worm se reproduit et se propage comme un virus mais s'en distingue fondamentalement : il se propage SANS action de l'utilisateur, traversant les réseaux de son propre chef en exploitant des vulnérabilités connues. N'ayant besoin d'aucune intervention humaine, il se répand bien plus vite (mondialement en heures voire minutes). Le premier worm marquant fut le Morris Internet Worm de 1988. Le trojan (cheval de Troie) prétend faire une chose utile tout en exécutant une action malveillante non documentée ; il ne se reproduit pas. Le Remote Access Trojan (RAT) est installé à distance après mise en production pour donner à l'attaquant un contrôle complet du poste cible sans alerte ; il n'est pas viral (ne se propage pas seul) mais peut être déposé comme payload d'un virus, et fait souvent du poste un membre d'un botnet. Les DDoS zombies sont des machines compromises au milieu, ignorant qu'elles participent à une attaque DoS distribuée.

La logic bomb reste dormante jusqu'à une condition précise (date, état d'une base) puis active son negative payload ; difficile à implanter après coup, elle est codée dans une application en développement ou maintenance, n'implique ni reproduction ni social engineering, et un exemple classique est le salami scam (siphonner des fractions de centime sur de nombreuses transactions). Spyware et adware sont à la frontière du légitime : initialement outils marketing traçant les habitudes de navigation, devenus intrusifs, on les nomme souvent PUP/PUA (potentially unwanted programs/applications) pour cibler l'absence de consentement plutôt que le préjudice. Le hoax est une fausse alerte de virus poussant à la transmettre à tous ses contacts (sorte de spam auto-entretenu). Les pranks et Easter eggs (fonctions cachées) sont des farces sans intention malveillante mais consomment des ressources et compliquent l'intégrité.

Le botnet est un réseau de bots automatisés agissant ensemble vers un but souvent malveillant ; sa nature distribuée et des techniques comme le fast-flux (rotation rapide de noms de domaine et d'adresses IP) le rendent difficile à détecter et neutraliser ; les bots sont généralement déposés par des trojans. Enfin, le ransomware chiffre les fichiers de la victime et vend la clé de déchiffrement (souvent en Bitcoin) ; une variante, le living off the land (attaque sans malware), n'utilise pas de malware mais des capacités natives du système (comme les outils de chiffrement du système de fichiers) pour le même résultat. Piège d'examen : virus = action utilisateur requise et modifie d'autres programmes ; worm = propagation autonome via le réseau, sans action utilisateur.

9.5 Software-Defined Security (SDS) et Zero Trust

La Software-Defined Security (SDS) est un changement de paradigme majeur dans la façon de penser et de sécuriser les architectures de systèmes d'information. En termes simples, c'est la différence entre le modèle client-serveur reposant sur un serveur on-premise et un modèle entièrement cloud, sans architecture sur site au-delà du point de présence internet et des points d'accès locaux. Le modèle client-serveur étendu à l'internet imposait une pensée périmétrique, des défenses en couches (DiD) et il faisait confiance aux entités se déplaçant latéralement à l'intérieur d'une couche. Vers 2018, le marché clamait que le defense in depth is dead pour signaler le besoin de SDS face à des attaquants sophistiqués. La nuance, vite apportée : ce ne sont pas les couches qui posent problème, mais le fait que le DiD traditionnel n'a aucun contrôle effectif sur le mouvement latéral dans une couche, ni de défense réelle contre la menace interne.

Pour une entreprise mondiale (50 sites, 10 000 utilisateurs, assets en cloud, microsegmentation exigeant des centaines de firewalls, routeurs, NIPS/NIDS pilotés par des SIEM et SOAR), le passage à SDS apporte plusieurs avantages : il centralise le control plane de tous les segments réseau, réduisant l'overhead tout en permettant des changements rapides à l'échelle de l'entreprise ; il favorise des appliances de sécurité virtualisées, réduisant la dépendance au matériel et aux fournisseurs ; il rend les politiques de sécurité on-demand, agiles et adaptables ; il peut éliminer d'anciens protocoles convergés comme MPLS via des overlays virtuels ; et il fait passer la threat intelligence de réactive à prédictive en combinant apprentissage machine et humain. SDS proprement implémentée offre aussi un tremplin vers une gestion holistique des risques toutes sources.

Il faut souligner que les éléments traditionnels au niveau composant n'ont pas disparu : il reste à gérer l'accès aux services internet de couche 2 et, surtout, le problème fondamental de l'identity management et de l'access control. Chaque utilisateur, humain ou non humain, et chaque device, entité logicielle ou processus doit être soumis à la suite complète de contrôles IAM - c'est le socle sur lequel SDS doit reposer avant de devenir holistique. Plusieurs idées sont désormais établies au cœur de la SDS : l'identity management est absolument vital ; ce sont les entités (pas seulement les utilisateurs) qui doivent être le niveau auquel l'identité est définie et tracée ; la défense doit devenir proactive ; les systèmes doivent être agiles ; l'access management doit descendre jusqu'à l'asset de plus bas niveau ; et la Zero Trust Architecture (ZTA) à la fois habilite SDS et est requise par elle. La ZTA recourt à la microsegmentation et aux fonctions IAM ; ce n'est pas un simple relabeling du DiD - par exemple, on définit des segments très localisés par type d'IoT, avec des trusted agents servant de brokers entre un segment IoT et le reste (des capteurs d'entrepôt n'ont aucune raison d'accéder aux systèmes RH ou finance).

SDS et assessment posent deux questions fondamentales et intriquées : (1) les systèmes dont l'organisation dépend fonctionnent-ils comme requis pour répondre aux besoins de conformité ET à la réalité de l'environnement de menace actuel ? (2) les processus SDS et de sécurité en place fonctionnent-ils correctement ? La première relève du Domaine 6 ; la seconde est un cas particulier du problème d'évaluation de sécurité d'un tiers - confier toutes ses capacités de sécurité aux mains virtuelles d'une installation SDS exige un degré de confiance considérable, et ce système doit être traité comme un asset mission-critical de grande valeur. Le choix d'un fournisseur SDS, en interne ou en service managé, doit intégrer les besoins d'assessment et de conformité dès le départ. Piège d'examen : SDS et ZTA ne signifient pas que le périmètre ou les couches sont morts ; ils corrigent l'angle mort du DiD - le mouvement latéral - en plaçant l'identity management au centre.