Securite : evaluation et tests

1.1 Assessment, audit, testing : trois mots, trois realites

Le vocabulaire de l'evaluation prete a confusion car des metiers differents emploient des termes proches. Trois notions doivent etre nettes.

Un assessment est une evaluation large des controles au regard des attentes du management. Sa portee, son calendrier et son reporting sont fixes par le management ; il precede souvent un audit pour reperer et corriger les faiblesses.

Un audit est une revue structuree d'informations, d'observations et de donnees pour mesurer la conformite a un standard defini. Les preuves examinees s'appellent des artifacts (log, politique, resultat d'interview). L'audit formel exige des evaluateurs independants, exterieurs a la chaine de management responsable du systeme : cette independance garantit l'absence d'influence indue qui fausserait le jugement.

Un test (testing) compare le comportement reel d'un systeme, d'un processus ou d'une activite, dans des conditions definies, a son comportement attendu. Le test est une brique qui peut servir un assessment ou un audit, mais aussi fonctionner seul comme monitoring de securite. Point cle : il faut definir la performance attendue AVANT de tester, sinon on ne peut pas conclure.

Enfin, une evaluation est formal (vs un standard legal, reglementaire ou contractuel, par des independants) ou informal (pour obtenir des observations et un apercu, sans visee directe de conformite). L'informal sert souvent a donner au management un avant-gout de ce qu'un audit formel revelerait.

1.2 Anatomie d'un finding et perspectives de test

Le resultat d'un audit se presente sous forme de findings, compiles dans un rapport remis a l'organisation commanditaire. Un finding type comporte cinq elements : Condition (ce que l'audit a constate), Criteria (le standard de mesure), Cause (pourquoi l'ecart existe), Effect (l'ecart et son importance) et Recommendation (l'action corrective). La precision du finding depend de l'integrite des artifacts : ils doivent refleter l'etat reel du controle au regard de son objectif.

Le test se mene selon une perspective interne ou externe. Le test interne suppose l'identite d'un insider de confiance ou d'un attaquant ayant deja franchi le perimetre (cf. NIST SP 800-115) ; il couvre configuration applicative, authentification, controle d'acces et hardening, et peut inclure de l'escalade de privileges. Les menaces internes restent une source majeure de compromission. Le test externe adopte le point de vue d'un individu non fiable hors du perimetre, pour reperer les faiblesses exploitables de l'exterieur.

Regle pratique : si externe ET interne sont prevus, executer l'externe d'abord, car l'information disponible pour le test interne est generalement plus riche. La distinction interne/externe s'estompe avec le zero trust et la deperimeterisation, qui appliquent les controles selon les seuls privileges necessaires a une tache.

1.3 Standards et frameworks d'evaluation

Standards et frameworks entretiennent un cercle vertueux avec les lois et les attentes du marche : tous incitent aux bonnes pratiques. Plusieurs reperes structurent l'evaluation de securite.

NIST Risk Management Framework (RMF, SP 800-37 Rev. 2) sert de reference pour les agences federales US et nombre de leurs contractants. Deux compagnons utiles : SP 800-53 Rev. 5 (controles de securite et de privacy) et SP 800-171 (protection de l'information non classifiee controlee chez les non-federaux).

NIST Cybersecurity Framework (CSF) offre un modele de maturite volontaire, pilote par le risque, plus simple et incremental ; il met l'accent sur la detection d'un incident. ISO 27000 sert de cadre d'audit pour evaluer un ISMS et est largement adopte hors des Etats-Unis.

Enfin, le cadre AICPA d'evaluation des controles, connu par ses rapports SOC, evalue une organisation au regard des Trust Services Criteria. Au-dela, beaucoup d'organisations relevent de plusieurs frameworks sectoriels a la fois : PCI DSS (cartes), IEC 62443 (controle industriel), Cyber Essentials (UK), NERC CIP (infrastructures critiques US), CSA STAR (cloud), SWIFT CSCF (finance). Le NCSC britannique propose en outre 12 principes de securite de la supply chain (comprendre les risques, etablir le controle, verifier, amelioration continue).

1.4 Rapports SOC : 1, 2, 3 et Cybersecurity

Le cadre SOC (Service Organization Control), defini par la norme SSAE 18 (partiellement mise a jour par SSAE 20), permet a un prestataire d'attester de ses controles aupres de ses clients. Quatre rapports, a ne pas confondre.

SOC 1 atteste des controles internes sur le reporting financier (ICFR). Il ne peut pas couvrir disaster recovery ni privacy.

SOC 2 (aussi appele rapport Trust Services Criteria) evalue les controles de securite selon cinq criteres : Security, Availability, Processing Integrity, Confidentiality, Privacy (mnemo CIANA+P). Il est confidentiel et peut ne couvrir qu'un sous-ensemble des criteres selon les besoins du prestataire.

SOC 3 fournit un resume public et moins technique d'un SOC 2 : c'est une vitrine diffusable, souvent sur le site du fournisseur.

SOC for Cybersecurity cible specifiquement le programme de cybersecurite (plans, processus, services) sur la base des TSC 2017.

Deux types s'appliquent aux SOC 1 et SOC 2. Type I evalue la conception (suitability of design) des controles a un instant T : c'est une expression de due care. Type II evalue en plus l'efficacite operationnelle des controles sur une periode (generalement 6 a 12 mois) : c'est l'expression de la due diligence. SOC 2 Type II est generalement prefere, et c'est le rapport a demander a un fournisseur tiers integral aux operations. SOC 3 et SOC for Cybersecurity sont de type unique.

1.5 Trust Services Criteria et normes d'attestation

Les Trust Services Criteria (TSC) sont les criteres utilises par l'auditeur pour evaluer la pertinence de la conception et l'efficacite operationnelle des controles relatifs a la securite, la disponibilite, l'integrite de traitement, la confidentialite et la privacy. Developpes par l'AICPA et le CICA, ils ont ete realignes en 2017 sur les 17 principes du framework COSO. Le critere Security est le critere commun obligatoire ; les autres sont ajoutes selon les besoins du prestataire.

Cote normes d'attestation, l'AICPA emet les SSAE, standards de conformite que les auditeurs certifies appliquent quand une organisation les engage pour attester de ses controles. L'ancienne SAS 70 (Type I et Type II) a ete remplacee par SSAE 16 puis SSAE 18, en s'inspirant de la norme internationale ISAE 3402. Un rapport SSAE 18 / ISAE 3402 comporte typiquement cinq sections : l'opinion de l'auditeur, l'attestation ecrite par l'organisation, la description des controles et objectifs, les tests d'efficacite operationnelle, et les informations complementaires.

Leçon de la SAS 70 : elle etait conçue pour l'ICFR, mais beaucoup l'ont detournee pour des besoins de securite, disponibilite et privacy. Les rapports SOC clarifient desormais l'usage. Enfin, la collecte de preuves (field work) peut se faire sur site ou a distance, sur des actifs on-premises, cloud ou hybrides ; le modele de responsabilite partagee du cloud aide a determiner qui est responsable de quel controle.

2.1 Trois methodes : testing, examination, interview

L'evaluation d'un controle se mene par toute combinaison de testing, examination et interview ; on peut y ajouter modelisation, simulation et analyse. Chaque methode mesure la conformite d'un systeme a ses exigences et specifications. La selection adequate des methodes conditionne le niveau d'assurance.

L'examination consiste a revoir, inspecter, observer ou analyser un objet d'evaluation (specifications, mecanismes, activites). Un controle administratif comme une politique se verifie en lisant le document ; un processus metier s'observe (execution des backups, port du badge). L'examen ne demande pas a l'assesseur de diriger l'operation ni d'interagir avec les parties prenantes. La revue de documentation de performance reelle (registres d'acces, transactions, logs) est l'un des outils les plus precieux.

L'interview sert a identifier l'ecart frequent entre le processus documente et la pratique reelle. Les sujets a interviewer sont definis lors du chartering et nommes dans la pre-audit checklist ; profondeur et largeur doivent etre clarifiees. La documentation des interviews (questionnaires, enregistrements avec consentement, notes) doit etre securisee selon sa classification.

Le testing compare le comportement reel au comportement attendu sous conditions definies. Historiquement cantonne au developpement, il sert aujourd'hui tout au long de la vie operationnelle d'un systeme. Un controle complet peut exiger plusieurs methodes : un simple examen ne suffit pas toujours, des tests ou interviews additionnels peuvent etre necessaires. L'organisation doit etablir le need to know de l'assesseur, sans lui donner un acces illimite hors perimetre.

2.2 Cadrer et echantillonner l'evaluation

Les activites d'evaluation sont planifiees par la security assessment policy, qui fixe les regles de planification, conduite et reporting. Le management fournit une direction de haut niveau : il faut identifier comment le contexte a change depuis la derniere evaluation, selon trois elements cles - le threat landscape, la business logic et le regime de conformite. Cela conduit a un ensemble cible et reduit d'evaluations a mener (tailoring).

L'evaluation s'adapte ensuite au controle evalue, selon son type, la profondeur visee et les particularites de l'exigence de conformite. Comme on ne peut rarement tout examiner, on s'appuie sur un echantillon. Le statistical sampling repose sur les lois de probabilite pour inferer la performance d'un controle sur l'ensemble de la population. Le judgmental sampling (aussi purposive ou authoritative) s'appuie sur l'expertise de l'assesseur pour choisir les systemes ou evenements, en priorisant ceux qui presentent le plus de risque.

L'organisation ne peut ignorer ses obligations de confidentialite, integrite et disponibilite pendant l'evaluation : meme s'il est pratique de donner un acces illimite a l'assesseur, ce privilege peut depasser le perimetre.

2.3 Revue des logs

Tous les grands frameworks insistent sur la pratique du logging. ISO 27001:2013 controle 12.4.1 exige que les event logs (activites utilisateurs, exceptions, fautes, evenements de securite) soient produits, conserves et regulierement revus. NIST SP 800-92 (Guide to Computer Security Log Management) traite la revue des logs comme une composante du log management. La revue sert non seulement la security assessment, mais aussi l'identification d'incidents, de violations de politique, de fraudes et de problemes operationnels au plus pres de leur survenue. La relecture d'audit logs historiques peut determiner si une vulnerabilite identifiee a deja ete exploitee.

Plusieurs reglementations imposent des revues diligentes : GLBA (protection des donnees clients des institutions financieres), HIPAA (revues regulieres des audit logs, retention 6 ans), SOX (revue reguliere des logs pour detecter les violations), PCI DSS (tracer tout acces aux ressources reseau et aux donnees cartes).

Le log management suit quatre pratiques cles : prioriser le log management dans toute l'organisation ; etablir des politiques et procedures ; creer et maintenir une infrastructure de logs securisee (un SIEM aide au stockage et a l'analyse, capable d'absorber les pics lors d'un incident, d'un pentest ou d'un scan) ; fournir un support adequat (formation, outils) au personnel. La securite des logs (ISO 12.4.2) protege contre l'alteration et l'acces non autorise ; les logs peuvent contenir des donnees sensibles (mots de passe, contenus d'emails) et doivent etre proteges en confidentialite et integrite, avec une retention conforme. Les rootkits visent souvent a alterer les logs pour effacer leurs traces.

2.4 Compliance test vs substantive test

Les tests se classent en deux familles. Le compliance test determine, de l'avis de l'assesseur, si le controle existe et fonctionne correctement. Exemple : comparer un echantillon d'employes habilites a acceder a un systeme avec la liste des utilisateurs nommes ; le resultat attendu est que les deux listes soient identiques.

Le substantive test evalue le bon fonctionnement du processus lui-meme. Dans le meme exemple, le testeur execute une operation d'onboarding pour donner acces a un nouvel utilisateur, tente une transaction autorisee avec ces credentials, puis offboarde l'identite ; il revoit ensuite les logs pour verifier que toutes les transactions ont ete correctement executees et tracees. Le substantive test apporte un degre d'assurance superieur que le processus se comporte comme prevu, mais prend plus de temps et de ressources.

A distinguer du compliance testing au sens large (aussi appele conformity testing), qui valide qu'un systeme a ete conçu et configure pour repondre aux exigences de securite de l'organisation : c'est la bonne reponse quand la question porte sur la validation vis-a-vis de standards definis. A noter enfin : le substantive test est aussi la technique par laquelle un auditeur obtient des preuves a l'appui de son opinion.

3.1 Vulnerability assessment et CVSS

Le vulnerability assessment est une tache essentielle de l'evaluation de la securite d'un systeme. Une vulnerability est une faiblesse qui, si elle est exploitee, peut compromettre la confidentialite, l'integrite ou la disponibilite d'un actif. Attention : l'existence d'une faiblesse ne signifie pas qu'elle est exploitable par une menace. Une vulnerability n'est pas un exploit.

Les scanners de vulnerabilites automatisent l'identification des vulnerabilites connues dans les configurations, parametres et logiciels. Ils peuvent etre authenticated (avec des credentials, vue interne plus precise) ou unauthenticated (vue d'un attaquant externe). Ils detectent aussi l'usage de protocoles non securises comme FTP - meme si des compensating controls (segmentation reseau, restriction d'usage) peuvent attenuer le risque. L'evaluation des vulnerabilites identifiees consiste a analyser leur impact selon les configurations et circonstances uniques de l'organisation, et a gerer les false positives (alertes erronees).

Pour prioriser, on s'appuie sur le CVSS (Common Vulnerability Scoring System), qui note la severite technique de 0 a 10 : None (0), Low (0.1-3.9), Medium (4.0-6.9), High (7.0-8.9), Critical (9.0-10). Le CVSS mesure la severite intrinseque ; il se complete utilement de l'EPSS, qui estime la probabilite d'exploitation. La priorisation SLA typique reserve les delais les plus courts aux vulnerabilites Critical et High.

3.2 Penetration testing ethique : RoE et scope

Le penetration testing simule les actions d'un threat actor en utilisant l'information dont il disposerait. C'est un processus controle, regi par des Rules of Engagement (RoE) qui detaillent les circonstances de la tentative. Utile pour determiner si les controles sont efficaces, il presente un risque significatif s'il est mal conduit. Les RoE definissent le perimetre, les methodes, les contraintes, les individus autorisant le test, les procedures de signalement d'incident et les limites de responsabilite (liability).

Point juridique majeur : sans contrat signe, le testeur s'expose a des poursuites penales et civiles dans de nombreuses juridictions, et peut etre tenu responsable des perturbations causees. C'est pourquoi on parle d'ethical penetration testing : le test est lie a une base contractuelle, legale et ethique. Les attaquants sophistiques emploient les memes techniques, mais leur intention rend leur activite contraire a l'ethique et probablement illegale. Le code d'ethique impose au testeur de ne pas divulguer ses activites et findings sans le consentement ecrit du commanditaire, en sus des NDA contractuels.

Le scope depend des objectifs. PCI DSS, par exemple, peut imposer de couvrir le cardholder data environment et exiger des tests reseau ET applicatifs. D'autres scenarios incluent une composante wireless, du social engineering ou de l'intrusion physique. Le test peut etre blind (le testeur ignore les details techniques) ou double-blind (l'equipe de defense - la blue team - n'est pas non plus prevenue), ce qui exerce la detection et la reponse, mais exige une deconfliction si les defenseurs decouvrent le test.

3.3 Box testing et methodologie en cinq phases

Le niveau de connaissance accorde au testeur definit le type de box testing. Le white-box (ou crystal-box) donne une connaissance complete du systeme (adresses IP, versions) : couverture maximale, mime un insider threat, le plus rapide et souvent le moins cher, mais les controles qui cachent l'information aux externes (comme le NAT) ne sont pas evalues. Le black-box n'accorde aucune connaissance : le testeur mene sa reconnaissance, ce qui confirme les controles destines a dissimuler l'information, au risque de manquer des actifs. Le gray-box melange les deux : information partielle, le testeur decouvre le reste. Rappel : un attaquant reel n'est pas contraint par le temps ni la facturation, contrairement au testeur dont le contrat dure quelques semaines.

La methodologie suit cinq phases. 1) Chartering : redaction des RoE, evaluation formelle du risque, integration au contrat si tiers. 2) Discovery : reconnaissance pour cartographier l'environnement (parfois inutile si les RoE definissent deja les systemes). 3) Scanning : identification et fingerprinting des faiblesses pour crafter les exploits. 4) Exploitation : livraison de l'exploit et documentation ; en se retirant, le testeur veille a ne pas augmenter le risque d'exploitation par un acteur malveillant. 5) Reporting : compilation des activites, executive summary, recommandations, restitution de tout le materiel (y compris les credentials obtenus). Il n'existe pas de standard unique : la sequence exacte doit etre documentee dans les RoE.

3.4 Red, blue, purple team et ethical hacking

Selon les objectifs (par ex. la response readiness), plusieurs equipes interviennent. La red team simule un attaquant malveillant pour evaluer la posture de securite : son but est d'identifier les vulnerabilites, exploiter les faiblesses et mesurer l'efficacite des mesures existantes. La blue team represente les defenseurs (equipe de securite interne) : elle monitore, detecte et repond aux attaques simulees, evaluant les strategies defensives, les capacites de reponse a incident et la resilience. La purple team combine les deux : elle favorise la collaboration et le partage de connaissances entre attaquants et defenseurs, pour combler les ecarts de defense et recommander des ameliorations.

L'ethical penetration testing ne doit pas etre confondu avec l'ethical hacking, qui regroupe les efforts de chercheurs amateurs ou professionnels pour sonder et detecter des vulnerabilites. Les bug bounty programs encouragent ces tentatives informelles : le hacking y est ethique tant que le chercheur respecte les termes du programme et ne divulgue pas ses resultats a des tiers. Google Project Zero en est un exemple emblematique. Le contexte legal pese : aux Etats-Unis, la section 1201 du DMCA fait du contournement des protections numeriques un delit, ce qui limite l'evaluation independante des protections cryptographiques.

3.5 Test continu : BAS, ATT&CK, chaos engineering

Un penetration testing est une activite point-in-time : il reflete un jeu de tests a un instant, alors que l'environnement et les menaces evoluent vite. Plusieurs approches de test continu completent les frameworks qui attendent un monitoring continu.

MITRE ATT&CK, base de connaissances des tactiques et techniques adverses, aide a tester la resilience par emulation du comportement attaquant. Les outils de breach and attack simulation (BAS) automatisent ces tests pour les executer en continu contre l'infrastructure ; couples a la threat intelligence et integres au change management, ils offrent un niveau d'assurance different du pentest traditionnel. Le BAS combine vulnerability scanning et penetration testing automatise, avec une base d'attaques constamment mise a jour. Il permet des tests plus frequents que les scans trimestriels ou les pentests annuels : si une attaque simulee est bloquee, les controles fonctionnent ; si elle reussit, cela signale un controle deficient ou un risque nouveau.

Le chaos engineering pousse les systemes de production a echouer pour evaluer les capacites de detection, reponse et recuperation. Ses tests no-notice stressent fortement les personnes et systemes : les equipes ne sont pas prevenues et traitent la panne comme une vraie attaque. A manier avec prudence : beaucoup de systemes ne sont pas conçus pour supporter un arret de production sans cout, et l'approche ne simule pas un vrai attaquant (les perturbations sont scriptees par des internes).

4.1 Code review : objectifs et SAST / DAST

La revue de code, plus precisement l'analyse et la revue du code source, vise a verifier six choses : toutes les fonctions requises existent ; aucun code etranger n'est present ; aucun code mort ou inatteignable ne subsiste ; aucun backdoor ni trapdoor ; les coding standards sont respectes ; tout le code est de provenance fiable. Ces objectifs ne valent pas qu'en developpement : ils supposent un configuration management rigoureux, sans quoi du code mort peut etre reactive et rendu exploitable par un petit changement ailleurs.

Le test peut etre manuel (code peer review : un developpeur relit le travail d'un pair) ou automatise. Deux familles dominent. Le SAST (static application security testing) analyse le code AU REPOS, sans l'executer : il modelise l'execution pour detecter buffer overflow, conditions de donnees incoherentes, mauvais usage de templates, librairies obsoletes, misconfigurations. C'est une approche boite blanche, ideale en shift-left. Le DAST (dynamic analysis) teste le programme EN COURS D'EXECUTION pour observer le comportement reel : approche boite noire. Une variante existe sur binaire compile (static binary analysis), moins precise que sur le source.

La philosophie shift-left (Agile, DevOps, DevSecOps) deplace les taches de securite vers la gauche de la timeline projet : revue d'architecture et threat modeling (prerequis au test, pas du test) en amont, puis SAST pendant le developpement. ISO 27002 14.2.1 prescrit des regles de developpement securise et la formation aux secure coding standards.

4.2 Misuse case et negative testing

Un use case decrit une façon intentionnelle d'utiliser un systeme pour accomplir un travail autorise. Le misuse case testing examine l'hypothese inverse : un ensemble d'actions pouvant provoquer des defaillances d'integrite, des dysfonctionnements ou des compromissions, qu'elles soient deliberees et malveillantes ou accidentelles. On l'integre aux plans de test, souvent en se concentrant sur le comportement du systeme face a des valeurs inattendues dans les champs (mauvais format, donnees tres eloignees de l'entree attendue). Exemple simple : un utilisateur saisit son numero de telephone dans un champ destine a son nom. Modeliser les agents hostiles et leurs misuse cases focalise l'attention du security professional.

Le negative testing, par contraste avec un positive test (qui verifie que le systeme marche comme prevu et echoue a la moindre erreur), apporte la preuve du comportement de l'application face a des donnees invalides ou inattendues. Toute provocation de defaillance doit surgir au test plutot qu'en production. La reponse optimale a un negative test est de rejeter gracieusement la donnee sans planter. Il est optimal de combiner positive et negative tests.

Ne pas confondre les deux : le negative testing detecte des plantages dans differentes situations ; le misuse case adopte le point de vue d'un acteur hostile. Les systemes safety-critical brouillent la frontiere (exigence de fail-safe). Les avancees de l'automated testing, comme le fuzz testing (mutation ou generation d'entrees), permettent de lancer des dizaines de milliers de cas aux limites de l'enveloppe acceptable du systeme - aussi bien pour les proprietaires que pour les attaquants.

4.3 Couverture de test et niveaux de test

Le niveau de test structurel se mesure par des metriques de couverture (coverage), qui indiquent le pourcentage de la structure logicielle evaluee. Par convention, parler de coverage suppose 100% : la statement coverage signifie que 100% des instructions ont ete executees au moins une fois. Les principaux types : statement coverage (chaque instruction au moins une fois, insuffisant a lui seul) ; decision/branch coverage (chaque branche prend chaque issue, minimum pour la plupart des logiciels, insuffisant pour le high-integrity) ; condition coverage (chaque condition prend toutes ses valeurs) ; multi-condition coverage (toutes les combinaisons de conditions) ; loop coverage (boucles executees zero, une, deux et plusieurs fois) ; path coverage (chaque chemin faisable, rarement atteignable vu le nombre de chemins) ; data flow coverage (chaque flux de donnees faisable). Le niveau vise doit etre proportionne au risque du logiciel.

Les tests se structurent aussi par niveau : unit (plus petit composant isole), integration (modules ensemble), system (systeme complet de bout en bout) et acceptance (UAT, validation vis-a-vis des besoins metier). S'y ajoutent des tests transverses : regression (verifier qu'un changement n'a rien casse), positive, negative, et les approches white-box / black-box. Atteindre 100% de couverture est rarement realiste : le cout et la pression de mise sur le marche le rendent difficile, surtout sur un code volumineux, meme si ce n'est pas strictement impossible.

4.4 Interface testing

Une interface est un point d'interaction avec un systeme. Exemples : l'UI (interaction humaine, GUI avec fenetres et menus, ou CLI en ligne de commande) et les API (communication systeme-a-systeme : REST pour le web, IPC, RPC). Evaluer la fonctionnalite et la securite des interfaces est un aspect crucial du system testing : les controles de securite doivent y etre implementes pour garantir la confidentialite (controles d'acces) et la non-repudiation (journalisation des actions). L'interface testing fait partie du test de developpement standard et joue un role dans les activites de securite (vulnerability assessments, pentests, breach simulations).

L'interface testing verifie que les composants (logiciels et materiels) se transmettent correctement donnees et controle, conformement a leur conception. Il differe de l'integration testing : il verifie que les composants distincts sont en phase et que les fonctions comme le transfert de donnees se deroulent comme prevu. Il permet notamment de verifier que les interactions application-serveur s'executent correctement, que les erreurs sont bien gerees, ce qui se passe si l'utilisateur interrompt une transaction, ou si une connexion au serveur web est reinitialisee. Cote serveur, on valide la communication entre serveurs web, applicatifs et bases, et la compatibilite logicielle/materielle/reseau. Cote interfaces externes, on verifie les navigateurs supportes et les conditions d'erreur quand l'application externe est indisponible.

4.5 Synthetic transactions et RUM

Pour evaluer performance, temps de reponse et disponibilite des applications, sites et services, deux approches complementaires existent.

Les synthetic transactions sont des activites automatisees executees contre une cible monitoree pour evaluer sa performance. Pour une application web, cela peut etre se connecter avec un compte de test pour verifier la reponse au login ou aux requetes. Le terme transactions ne designe pas que des transactions financieres : toute activite systeme (resolution DNS, attribution d'IP via DHCP) en releve. Le synthetic performance monitoring (ou proactive monitoring) fait executer par des agents externes des scripts suivant les etapes d'un utilisateur type (rechercher, voir un produit, se connecter, payer). C'est un test par scripts, et non par actions live, ce qui le distingue des autres formes de test. Il couvre le website monitoring, le database monitoring, le TCP port monitoring et la SLA validation, et fonctionne 24/7 meme sans trafic reel.

Le RUM (real-user monitoring), aussi appele real-user measurement ou end-user experience monitoring (EUM), est a l'inverse une forme de monitoring passif : il capture et analyse chaque transaction de chaque utilisateur reel d'un site ou d'une application. Le RUM top-down, cote client (petits scripts JavaScript ou agents locaux), voit directement l'experience vecue par l'utilisateur et le lien entre vitesse du site et satisfaction. Le RUM s'applique aussi a des operations humaines (centres d'appel). Synthetic et RUM se completent : le synthetic surveille la disponibilite en periode de faible trafic, le RUM mesure l'experience reelle.

5.1 Account management et revue IAM

Un account est l'ensemble des credentials servant a acceder a une ressource. Comme le controle d'acces est le socle de la securite des SI, la collecte des donnees de processus se concentre d'abord sur l'account management. Celui-ci soutient les fonctions metier en : assignant des account managers ; etablissant les conditions d'appartenance a un groupe ou role ; specifiant les utilisateurs autorises ; exigeant l'approbation des autorisations (creation, activation, modification, desactivation, suppression d'acces) ; monitorant l'usage des comptes ; notifiant le manager quand un acces n'est plus necessaire ; revoyant la conformite des comptes. Le controle d'acces est un exemple de controle mixte : des politiques appliquees par des procedures, implementees par la technologie, parfois avec des controles physiques (badges, smart cards).

La revue IAM s'appuie sur trois jeux d'information centraux. L'identity store est le referentiel centralise de toute l'information sur une identite ; il enregistre aussi les decisions d'octroi, de retrait ou de degradation des permissions. Le systeme IAM integre maintient ses bases d'authentification et d'autorisation (le 3e A du AAA : authentication, authorization, accounting). Les logs systeme et applicatifs, les agents de monitoring et les sondes enregistrent les indicateurs des actions des utilisateurs. Le user behavior modeling peut detecter des indicateurs declenchant des revues de comptes. Au gre des changements de poste et, in fine, des departs, les acces sont modifies, desactives, deprovisionnes puis supprimes. L'audit de ces sources fournit une riche matiere pour l'evaluation de securite.

5.2 Management review and approval

Le management est responsable de definir et executer la mission de l'organisation, securite et privacy comprises. Pour garantir que les controles reduisent le risque a un niveau acceptable, il conduit des revues et approuve les donnees de processus de securite. ISO 27001 demande que la direction revoie l'ISMS a intervalles planifies pour assurer sa pertinence, son adequation et son efficacite continues - exigence echoue par NIST, ITIL et COBIT 5.

La management review devrait inclure (sans s'y limiter) : les exemptions aux activites normales, l'information des revues precedentes, les metriques d'outcomes en cours, les resultats d'audits, l'atteinte des objectifs de securite, le retour des parties interessees, et le reporting d'evaluation du risque avec le plan de traitement. L'objectif est de soutenir le continual process improvement. Beaucoup d'organisations se fient encore a des jugements subjectifs pour prioriser, alors que les grands frameworks exigent des methodes statistiques, des metriques et des benchmarks - ce qui suppose que logging et monitoring fournissent l'information data-driven necessaire.

Les system owners ont des responsabilites analogues pour leurs propres stores : ils identifient leur tolerance au risque, leurs obligations de conformite, et decident d'autoriser l'usage d'un systeme. Ils sont essentiels pour determiner si les controles selectionnes atteignent leurs objectifs. Des changements d'environnement (nouvelles lignes metier, systemes, conformite, fusions/acquisitions) peuvent affecter l'efficacite des controles, d'ou un monitoring continu generant metriques et indicateurs.

5.3 KPI et KRI : mesurer le passe et anticiper l'avenir

On ne gere bien que ce que l'on mesure. Les metriques de securite servent de key performance indicators (KPI) et de key risk indicators (KRI). Attention a la distinction metrique vs indicateur : une metrique est une simple mesure (le nombre de patches appliques), tandis qu'un indicateur utilise des metriques et fournit un contexte (une indication). Exemple : le ratio d'endpoints patches sur le total est un indicateur de l'efficacite du patch management ; si l'on attend 100% de couverture a J+7 et que le chiffre est en-dessous, l'indicateur signale une action corrective.

KPI et KRI different par leur orientation temporelle. Les KPI regardent le passe : l'activite a deja eu lieu, les objectifs ont-ils ete atteints ? Ils aident a corriger les actions futures, peuvent reveler des segments sous-performants, justifier des recompenses et rassurer une clientele. Les KRI regardent l'avenir : ils captent comment le paysage de risque changeant pourrait affecter l'organisation, en utilisant modelisation, analyse ou estimation eclairee. Ils permettent d'evaluer la vraisemblance d'un risque et de declencher une action proactive - par exemple, une hausse du volume de trafic malveillant bloque par un firewall peut indiquer qu'il faut le mettre a niveau avant qu'il ne soit submerge. Les KRI soutiennent souvent des decisions de long terme (budget, ressources) et doivent etre revus par un change management formel quand le risque evolue.

5.4 Verification des backups et services de disponibilite

Les services de disponibilite sont une autre source de donnees de processus, car leur performance conditionne la capacite de l'organisation a tenir ses engagements et obligations de conformite. Les donnees de disponibilite sont routinement auditees.

Les backups de donnees et de systemes sont des controles essentiels d'integrite et de disponibilite. La premiere etape est d'identifier les donnees et systemes critiques, puis de concevoir une strategie de backup adaptee aux besoins de recuperation. Une fois les procedures en place, il est crucial de verifier l'integrite du processus de backup ET des donnees sauvegardees. Les deux s'evaluent par un test restore depuis le media de sauvegarde, pour s'assurer que toutes les donnees requises sont presentes et lisibles. Si des donnees manquent, cela peut indiquer une mauvaise configuration (repertoires ou systemes exclus) ou une corruption du media. Certains systemes de backup integrent une verification d'integrite automatique, generent des alertes en cas de perte et relancent le backup.

Cote conformite, ISO 27001 Annexe A:12.3 est le controle principal, mais le besoin de backup apparait dans de nombreux controles. FIPS 200 couvre les familles Contingency Planning (CP) et Media Protection (MP). HIPAA exige a la fois un data backup plan et un business contingency plan, et le critere Availability des TSC impose des attentes similaires pour un SOC 2. Le developpement d'un programme de disponibilite prolonge la pratique de gestion du risque : l'execution releve de l'IT, mais elle est dirigee par le risque de perte de donnees ou de defaillance.

6.1 SETA : education, training, awareness

L'environnement de securite change vite : etablir et maintenir un programme de security education, training and awareness (SETA) est vital, car les utilisateurs sont a la fois une ligne de defense critique et une cible de grande valeur. Les trois activites different. L'education presente un corps de connaissances applicable a un large eventail de problemes ; comme le corpus evolue vite, l'education d'un professionnel ne s'arrete jamais (les membres ISC2 doivent demontrer leur formation continue). Le training vise l'acquisition de connaissances specifiques pour accomplir une tache (configurer et utiliser correctement une technologie, un controle). L'awareness est plus general : NIST SP 800-50 distingue les deux en disant que le training enseigne des competences, tandis que l'awareness focalise l'attention sur un enjeu.

La structure et l'efficacite d'un SETA dependent de la politique et de la strategie de l'organisation. Un needs assessment, initial et continu, determine la strategie de formation et justifie l'allocation de ressources. Il doit impliquer des roles cles aux besoins de formation specifiques : executive management (comprendre directives et lois), security personnel (experts en politique et best practices), system owners (forte comprehension des controles), system administrators et IT support (connaissances techniques), operational managers et utilisateurs (awareness et regles de comportement). FIPS 200 identifie la famille Awareness and Training (AT) ; ISO 27001 A.7.2.2 a une attente similaire.

Evaluer l'efficacite est difficile : compter les participants ne montre aucun changement de comportement. Les campagnes anti-phishing, qui envoient de faux emails et tracent les reponses, sont une façon de quantifier l'effet. Les programmes SETA reussis ont des mesures d'evaluation significatives (taux de completion, retention long terme, couverture, adaptation a l'audience), reutilisees pour le retraining et la reevaluation.

6.2 BC et DR : deux processus distincts

Disaster recovery (DR) et business continuity (BC) sont souvent associes mais distincts. Le DR consiste a planifier et implementer des strategies pour restaurer les systemes IT, les donnees et les operations apres un desastre (catastrophe naturelle, cyberattaque, panne materielle) : il assure une reprise rapide et minimise le downtime, protegeant l'integrite des donnees et la fonctionnalite metier. Le BC se concentre sur le maintien des fonctions metier essentielles pendant et apres un desastre : il va au-dela de l'IT (securite des employes, protocoles de communication, sites de travail alternatifs), pour soutenir les operations coeur, le service client et limiter les pertes financieres. Ensemble, BC et DR forment la resilience de l'organisation.

Les donnees de processus liees a BC et DR interessent fortement les controls assessors. Les grands standards attendent une planification BC/DR pilotee par le risque : NIST SP 800-34 (Contingency Planning Guide) trace une feuille de route ; ISO 27031 traite la continuite des SI et s'aligne sur ISO 22301 (Business Continuity Management Systems). Beaucoup de secteurs (finance, nucleaire, aviation, infrastructures critiques) imposent des attentes de resilience elevees, parfois avec une demonstration a grande echelle reguliere et documentee.

Un dicton bien etabli rappelle que le desastre que l'on subit n'est jamais celui que l'on a planifie. Le plan, comme artifact, demontre l'engagement, mais le vrai test est de montrer que l'organisation peut l'executer. D'ou l'importance de former les equipes a la conduite de la reprise, avec une complexite et une ampleur progressives.

6.3 Tester les plans BC/DR : du desk check au full cutover

Les tests et formations BC/DR sont une donnee de processus de premier interet pour l'assesseur : ils demontrent l'efficacite des controles et alimentent l'amelioration continue. Le programme de formation doit progresser en complexite et en ampleur organisationnelle, chaque evenement reussi preparant le suivant. Un programme progressif type s'ordonne ainsi.

Le desk check : chaque membre revoit la documentation operationnelle, les rosters, sa disponibilite et sa version du plan DR ; resultat attendu : tout le monde dispose d'un plan a jour. Le walk-through : a l'aide des manuels, les equipes DR expliquent leurs roles et activites ; resultat : elles comprennent leur role les unes par rapport aux autres et deconflictent les chevauchements. Le tabletop exercise : les chefs d'equipe se voient presenter un scenario de desastre et discutent leur reponse ; resultat : deconfliction des roles et identification des faiblesses majeures du plan. La simulation : un desastre est simule HORS de l'environnement de production, les activites DR y sont menees ; resultat : demonstration des capacites de reprise dans le contexte du scenario. Le parallel : un desastre est simule pendant que la production continue ; resultat : demonstration de la pleine reprise sans interruption de la production. Le full cutover (full-interruption) : un desastre est declenche qui affecte reellement la production ; resultat : reprise de l'environnement de production dans les parametres etablis.

Piege classique : un exercice d'evacuation incendie est un walk-through (revue pas-a-pas des procedures sans execution temps reel), et non une simulation. Les resultats de ces activites sont documentes et mis a disposition des assesseurs et des autres parties pour l'amelioration des processus.

7.1 Remediation et amelioration continue

Le CISSP doit etablir un processus, appele remediation, pour traiter les findings issus des tests, assessments et audits. Cela mobilise des competences de gestion de projet : prioriser les taches, fixer des timelines et des jalons, suivre l'avancement jusqu'a completion. Les findings d'audit peuvent alimenter d'autres aspects du programme (analyse de risque) : un controle deficient revele un risque mal attenue, ce qui doit declencher une revue du processus de gestion du risque.

Les changements de l'environnement de controle s'inscrivent dans une demarche d'amelioration continue. Le modele le plus repandu est le PDCA (Plan-Do-Check-Act), aussi appele roue de Shewhart ou de Deming, en quatre etapes. Plan : decider ce qui doit etre fait, etablir les objectifs et les processus. Do : executer le plan (a petite echelle). Check : evaluer les resultats (mesures statistiques, observations, evaluations). Act (Adjust) : a partir des phases Do et Check, identifier les causes racines, reevaluer le risque, redefinir la baseline ; puis le cycle recommence.

Le Six Sigma applique un modele proche en cinq etapes (Define, Measure, Analyze, Improve, Control - DMAIC), repete jusqu'au niveau de qualite voulu. Tous les grands frameworks appliquent l'amelioration continue pour mieux aligner la performance des controles sur le risque. La maturite (CMM) procede de la meme logique. Aucun modele unique ne convient a toute organisation : l'adaptation considere culture, gestion du risque, priorisation, conformite et change management. L'amelioration continue est autant un etat d'esprit qu'un processus.

7.2 Exception handling

Quand un finding ou un indicateur etablit qu'un controle n'atteint pas le niveau de reduction de risque convenu, la reponse habituelle est d'ameliorer le controle. Dans certaines circonstances, la reponse appropriee est plutot d'ajuster la tolerance au risque pour l'aligner sur la performance du controle. Le processus de change management doit impliquer le system owner pour determiner la bonne marche a suivre.

Quand une evaluation revele un probleme qui ne peut etre remedie, il doit passer par un processus d'exception, calque sur celui des exceptions de politique (utilise quand un systeme ne peut satisfaire une exigence). Les exceptions peuvent etre accordees, mais seulement de maniere temporaire. Si l'on demande une exception permanente, ou si le meme probleme genere des demandes repetees, c'est le signe d'un desalignement avec les objectifs de l'organisation, justifiant une mise a jour des politiques ou des decisions de gouvernance.

Concretement : si la situation est temporaire et que le system owner accepte le risque, le change management documente les circonstances et signale l'exception pour revue a une date ou un evenement convenu. Si le owner refuse le risque additionnel, il doit soit ressourcer le controle supplementaire, soit prendre d'autres mesures couvrant le nouveau niveau de risque. Dans tous les cas, les exceptions doivent etre documentees, autorisees et revues.

7.3 Ethical disclosure des vulnerabilites

Les applications, sites et services web contiennent probablement des vulnerabilites. Une communaute de chercheurs s'attache a les identifier et les signaler de maniere responsable, avant qu'un acteur malveillant ne les exploite : c'est l'ethical ou responsible disclosure. Les organisations dotees de ressources web doivent etre pretes a recevoir ces signalements, souvent imprevus, de personnes externes. Trois postures coexistent.

La full disclosure : qui decouvre une faiblesse la publie le plus vite possible a toutes les parties affectees. Ses partisans estiment que ne pas tout divulguer immediatement laisse des organisations a risque, et que l'embarras public pousse les editeurs a corriger. La responsible disclosure : qui decouvre signale d'abord a l'organisation responsable et lui laisse le temps de corriger avant publication ; le delai fait debat, mais l'idee est soutenue par Linus Torvalds, Microsoft, Google. La nondisclosure : ne pas divulguer, parfois la seule voie legale et ethique, quand des accords (NDA), une enquete en cours, des droits de privacy ou des donnees financieres protegees l'imposent ; les safe harbor programs ont tente de creer des canaux de partage, mais se heurtent au RGPD.

Project Zero (Google, 2014) illustre la responsible disclosure : l'equipe transmet les details a l'editeur et, sans patch sous 90 jours, rend la faiblesse publique ; plus de 95% sont corrigees dans ce delai. Aux Etats-Unis, le Vulnerabilities Equities Process (VEP) arbitre, au cas par cas, la divulgation des vulnerabilites connues des agences. S'y ajoutent le mandatory reporting (obligation legale de signaler certaines circonstances, par ex. crimes impliquant des mineurs) et le whistleblowing (signalement ethique, protege de façon variable selon les juridictions, d'ou l'interet d'une assurance professionnelle). Le professionnel doit clarifier le statut legal du whistleblowing avant toute divulgation.

8.1 Audit interne et methodologie

Assessments et audits peuvent etre conduits en interne ou par des tiers independants. Un evaluateur independant donne plus de confiance dans les opinions, attestations et findings. L'audit interne vise a determiner si les controles repondent aux attentes de risque de l'organisation ; il aide aussi a ameliorer l'efficacite operationnelle et a preparer les audits externes. Il est souvent conduit par l'organisation elle-meme (self-assessment), ce qui exige rigueur et volonte de poser des questions difficiles - beaucoup d'organisations victimes de breaches decouvrent que leur culture n'encourageait pas cette introspection.

Avantage de l'audit interne : la familiarite des auditeurs avec processus, outils et personnel. Mais cette familiarite est aussi un risque : on peut negliger involontairement des problemes, et l'auditeur interne peut manquer d'independance pour une evaluation objective (tentation de minimiser un probleme majeur qui affecterait la performance ou les relations). Certaines organisations gardent les auditeurs dans une equipe separee ; pour les plus petites, ce n'est pas toujours faisable.

La methodologie suit des phases. Chartering : le management sponsorise et ressource l'evaluation. Scoping : le management determine profondeur, ampleur, calendrier, format de reporting et qui realise le travail (le stakeholder engagement et le risk assessment sont menes tout du long). Testing : conduite des controles physiques, techniques et administratifs (vulnerability assessment, penetration testing). Reporting : le rapport sert de benchmark, d'outil correctif ou d'artefact pour l'audit externe ; le niveau de detail s'adapte a l'audience, la divulgation reste de la responsabilite du management, et les artefacts sont proteges. Remediating : associer les resultats a l'action corrective ; aux Etats-Unis, le Plan of Action and Milestones (POA&M) tracte la faiblesse, la remediation proposee, les ressources et le calendrier (NIST SP 800-37).

8.2 Preparer et conduire un audit SOC

Pour un prestataire de services n'ayant jamais ete audite, la preparation d'un premier examen SOC suit typiquement deux phases. Le security professional joue ici un role cle de conseil et d'execution.

La phase de preparation (audit preparation phase) commence par familiariser la direction et les personnes cles avec le processus et le but des examens SOC. L'equipe procede ensuite comme pour tout projet majeur : etablir clairement calendrier, scope et criteres de succes ; determiner les controles dans le scope de l'examen, inventorier les controles actuels et identifier les manquants ; inventorier la documentation ; utiliser des techniques de gap analysis (readiness review) pour identifier et prioriser les problemes ; developper et executer des recommandations pour resoudre les ecarts ; verifier la resolution ; et etablir l'approche d'audit et de reporting la plus adaptee aux besoins externes.

La phase d'audit (audit phase) demarre une fois la preparation achevee : l'organisation est prete pour son premier audit formel. Avoir des auditeurs externes examinant l'organisation en detail peut etre perturbant ; une bonne planification reduit cette perturbation. Elle requiert une solide gestion de projet : batir un plan d'audit detaille ; collecter a l'avance tous les artefacts requis ; fournir acces, espaces de travail et salles ; planifier reunions d'introduction, revues d'avancement et outbriefings ; conduire les tests requis et fournir les artefacts ; laisser aux auditeurs le temps d'analyser hors site ; resoudre les obstacles de maniere collaborative ; fournir les versions brouillon et finale du rapport pour revue par le management ; et conduire une revue post-audit (lessons learned) pour le cycle suivant.

8.3 Audits externes : types et conduite

Un audit externe est une evaluation par un tiers demontrant que les controles de l'organisation respectent un standard de conformite - standard qui impose des consequences en cas de non-respect (penalites financieres, sanctions penales, limitations d'activite). Les audits externes sont reguliers (risque, gouvernance, finances) et emploient une organisation independante sans conflit d'interets ; parfois c'est l'organe de conformite qui audite. Dans tous les cas, l'organisation auditee est responsable de demontrer sa conformite. Les audits externes sont souvent obligatoires pour la conformite reglementaire ; leur avantage est d'etre approfondis et impartiaux, avec des auditeurs aux competences specialisees (ex. SOC 2 sous SSAE 18).

Le chartering releve de l'organe de gouvernance de l'auditee, qui fixe le calendrier, le scope, les ressources et les responsables de coordination. Le scope et les objectifs dependent du type d'audit et du standard. Les types les plus courants : compliance audits (tester des controles specifiques vs un standard), financial audits (exactitude du reporting financier), operational audits (controles internes d'un processus), information systems audits (controles du developpement et de l'exploitation des SI), integrated audits (operationnel + financier), forensic audits (decouvrir et rapporter fraude ou activite criminelle).

Deroulement : l'auditee connait a l'avance le standard applique, ce qui permet de preparer le support. Le pre-audit planning identifie competences et ressources, prepare une audit checklist (zones a investiguer, artefacts, personnes a interviewer, calendrier) partagee avec l'auditee pour combler les manques. L'audit execution collecte les artefacts, mene les tests et interviews (sur site et a distance). L'audit reporting analyse et compile un draft report partage avec l'auditee pour corriger erreurs et omissions, avant la presentation des resultats finaux. L'auditeur doit disposer de l'expertise suffisante, quitte a engager un tiers pour des tests specialises (autorise par l'audit charter).

8.4 Audits tiers, managed services et supply chain

Les relations tierces couvrent supply chains et prestataires : CSP, ISP, managed security services, consultants, mais aussi vendors de materiel/logiciel (consideres comme partie de la supply chain). L'audit tiers est un outil cle de gestion du risque : le security practitioner peut conduire l'audit ou demander un rapport d'audit au tiers. L'objectif partage est d'identifier les risques lies au tiers susceptibles d'impacter votre organisation et d'evaluer l'efficacite des attenuations. Exemples courants : SOC 2 et CSA STAR. Auditer les pratiques de tiers ayant acces a vos donnees sensibles est vital, car de nombreuses lois de privacy tiennent le data controller legalement responsable d'une breach, meme causee par un data processor (ex. un cloud).

Deux processus doivent conduire a identifier et caracteriser tous les tiers (risque, conformite, ou les deux). Les termes des contrats doivent etablir les responsabilites de securite et de conformite ; sinon, ce manque doit etre comble, contrats renegocies. Un tiers peut avoir lui-meme des relations (ses propres prestataires ou clients) : la first party doit identifier le mix de risque et de conformite et le resoudre avec le tiers.

Les managed services confient a un tiers la responsabilite de tout ou partie d'un ensemble de fonctions. Le security professional intervient sur deux fronts : ceux qui delivrent des services IT/securite (identity, incident response, BC/DR) et ceux qui, sur d'autres services, ont un acces partage aux actifs de l'organisation. Idealement, un contrat et un SLA etablissent une relation cooperative donnant visibilite sur les audits du fournisseur et permettant vos propres tests. Au minimum, les SLA doivent accorder une information de niveau resume sur les audits de securite. Enfin, les organisations existent aussi dans la supply chain d'autres : les principes de supply chain management s'appliquent en amont (suppliers) et en aval (customers) ; la serie ISO 28000 adresse le management de la securite de la supply chain. La collecte de preuves (field work) se fait en personne ou a distance, sur des actifs on-premises, cloud ou hybrides, le modele de responsabilite partagee precisant qui repond de quels controles (ex. securite physique des data centers du fournisseur d'infrastructure).