ISO/IEC 27005 Lead Risk Manager

Dix questions d'exemple de l'examen

Une par domaine de compétence, telles qu'elles apparaissent dans le simulateur.

1. D1 Principes fondamentaux

   Selon ISO/IEC 27000:2018 et de manière harmonisée avec ISO 31000:2018, comment le risque est-il défini en termes normatifs ?

   1. Le risque est la combinaison de la probabilité d'occurrence d'un événement et de la conséquence pouvant en résulter pour les objectifs de l'organisme. Ce serait l'unique définition admise par la norme.
   2. Le risque est la différence mesurée entre la valeur observée d'une métrique de sécurité et sa valeur cible attendue par la direction.
   3. Le risque est l'effet de l'incertitude sur l'atteinte des objectifs, qu'il s'agisse d'objectifs de sécurité de l'information, de conformité ou de continuité d'activité.
   4. Le risque est un événement résultant de l'exploitation d'une vulnérabilité par une menace identifiée et caractérisée par un acteur opérationnel.

2. D3 Évaluation des risques

   Quelles activités la clause 7 d'ISO/IEC 27005:2022, intitulée information security risk assessment, regroupe-t-elle au sein de ses sous-clauses ?

   1. Les options de traitement, la détermination des contrôles nécessaires et l'élaboration du plan de traitement.
   2. L'identification, l'analyse et l'évaluation des risques liés à la sécurité de l'information.
   3. La communication, la surveillance des risques et l'amélioration continue du processus de gestion.
   4. Le contexte interne et externe, les critères d'appréciation et l'approche méthodologique retenue pour l'organisme.

3. D4 Traitement des risques

   MunicipalitéMétropole arbitre les options de traitement applicables à un risque cyber sur ses téléservices citoyens. Quelle nomenclature normative des quatre options de traitement le Lead Risk Manager doit-il citer selon la clause 8.2 d'ISO/IEC 27005:2022 ?

   1. Share (partager), transfer (transférer), retain (conserver) et reject (rejeter) selon la cartographie des contrôles disponibles.
   2. Modify (réduire le risque), share (partager le risque), avoid (éviter le risque) et retain (conserver le risque).
   3. Modify (modifier), accept (accepter), transfer (transférer) et reduce (réduire) sur la base des critères de risque retenus.
   4. Accept (accepter), transfer (transférer), mitigate (atténuer) et ignore (ignorer) le risque selon la décision du risk owner.

4. D6 Méthodologies d'appréciation

   Pour structurer l'appréciation des risques d'un projet de SMSI sectoriel, le Lead Risk Manager compare plusieurs méthodes nationales reconnues. Quelle proposition décrit correctement l'origine institutionnelle de MEHARI, CRAMM, NIST SP 800-30 et Harmonized TRA ?

   1. MEHARI a été retirée par le CLUSIF en 2020, CRAMM a cessé d'être maintenue depuis 2010, NIST SP 800-30 est devenue obsolète à la sortie d'ISO/IEC 27005:2018, et Harmonized TRA n'a jamais été publiée officiellement.
   2. MEHARI est publiée par le CLUSIF (France), CRAMM par le UK Government (CCTA), NIST SP 800-30 par le NIST (États-Unis), et Harmonized TRA par les autorités canadiennes (CSE et RCMP).
   3. MEHARI est publiée par l'ANSSI en France, CRAMM par le NIST aux États-Unis, NIST SP 800-30 par le UK Government britannique, et Harmonized TRA par l'ENISA pour l'Union européenne.
   4. MEHARI, CRAMM, NIST SP 800-30 et Harmonized TRA renvoient toutes à une méthode unique de référence retenue par IEC 31010:2019, leurs acronymes constituant des variantes locales d'un même cadre méthodologique.

5. D5 Communication, surveillance, amélioration

   Quel est le rôle des trigger criteria introduits par ISO/IEC 27005:2022 dans le pilotage du processus de gestion des risques ?

   1. Les trigger criteria ont été supprimés par la révision 2022 et n'apparaissent plus dans le corps normatif de la version courante d'ISO/IEC 27005.
   2. Les trigger criteria identifient les événements ou changements qui déclenchent une réévaluation du processus ou des risques, transversalement aux clauses du programme.
   3. Les trigger criteria fixent une périodicité strictement calendaire (annuelle ou trimestrielle) excluant les événements non planifiés et les changements organisationnels.
   4. Les trigger criteria sont des exigences obligatoires applicables uniquement à la clause 6 establishing the context, sans transversalité sur les autres clauses. Le reste du cycle n'en dépend pas.

6. D2 Mise en œuvre du programme

   MunicipalitéMétropole structure son programme triennal en articulant ISO/IEC 27001:2022 et ISO/IEC 27005:2022. Quelle proposition décrit correctement le rôle distinct de chacune des deux normes dans le programme ?

   1. ISO/IEC 27005:2022 est obligatoire pour la certification ISO/IEC 27001 et son non-respect entraîne automatiquement le rejet du dossier de certification.
   2. ISO/IEC 27005:2022 fixe les exigences certifiables du système de management et ISO/IEC 27001:2022 n'en constitue qu'un guide d'application facultatif pour le programme.
   3. ISO/IEC 27001:2022 fixe les exigences du SMSI, tandis qu'ISO/IEC 27005:2022 fournit la méthode de gestion des risques.
   4. ISO/IEC 27001:2022 et ISO/IEC 27005:2022 imposent toutes deux des exigences certifiables auditables, dont les écarts entre les deux référentiels peuvent générer des constats de non-conformité distincts lors de l'audit de certification.

7. D1 Principes fondamentaux

   Dans la terminologie d'ISO/IEC 27000:2018 et d'ISO/IEC 27005:2022, comment se distingue likelihood par rapport à probability lorsqu'on caractérise la possibilité de survenue d'un événement de risque ?

   1. La distinction entre likelihood et probability a été introduite par ISO 31000:2018 puis abandonnée par ISO/IEC 27000:2018, qui ne retient plus que le terme probability.
   2. Probability s'emploie pour les risques financiers, tandis que likelihood s'applique exclusivement aux risques opérationnels et de cybersécurité.
   3. Probability désigne uniquement les estimations issues de données historiques, alors que likelihood se limite aux estimations expertes formulées en atelier.
   4. Likelihood est un terme générique englobant la probabilité quantifiée et la fréquence qualifiée, applicable aussi bien à des estimations chiffrées qu'à des appréciations expertes.

8. D3 Évaluation des risques

   BankSecure Europe construit son approche d'identification des risques cyber pour son périmètre de paiement carte. Le Lead Risk Manager doit choisir entre les approches event-based et asset-based d'ISO/IEC 27005:2022. Quelle proposition décrit correctement leur articulation normative ?

   1. L'approche asset-based a été antérieure dans la pratique et l'approche event-based en constitue la généralisation, les deux clauses 7.3.1 décrivant deux moments successifs d'une même démarche d'identification.
   2. L'approche event-based suit une logique top-down (scénarios à fort impact stratégique) tandis que l'approche asset-based suit une logique bottom-up (inventaire actifs, menaces, vulnérabilités).
   3. Les deux approches event-based et asset-based forment une inversion symétrique l'une de l'autre, leurs résultats devant être identiques à un changement de point d'entrée près.
   4. L'approche event-based est une option facultative réservée aux grandes entreprises disposant d'une cellule de threat intelligence interne et d'un programme TLPT mature.

9. D4 Traitement des risques

   Comment s'articulent la clause 6.1.3.d d'ISO/IEC 27001:2022 (Statement of Applicability) et la clause 8.5 d'ISO/IEC 27005:2022 dans la production de la SoA ?

   1. La SoA est une copie mécanique de l'Annexe A d'ISO/IEC 27001:2022, reprenant les 93 contrôles sans sélection ni justification contextuelle.
   2. ISO/IEC 27001:2022 exige la production d'une SoA listant les contrôles applicables avec justification, alimentée méthodologiquement par ISO/IEC 27005:2022.
   3. La SoA est une production facultative pour le SMSI candidat à la certification, dispensée par la révision 2022 d'ISO/IEC 27001 pour les organismes en phase initiale.
   4. La SoA est une simple conséquence directe de l'appréciation des risques 27005, produite mécaniquement à la fin du processus sans intervention formelle de l'organisme.

10. D6 Méthodologies d'appréciation

    Au sein du portefeuille de méthodes d'appréciation des risques, le Lead Risk Manager rencontre les déclinaisons OCTAVE et OCTAVE Allegro publiées par le Software Engineering Institute (SEI). Quelle proposition décrit correctement leur origine institutionnelle et leur articulation interne ?

    1. OCTAVE est éditée par le NIST dans le cadre du programme SP 800, alors qu'OCTAVE Allegro reste une variante propriétaire publiée séparément par Carnegie Mellon, sans articulation entre les deux versions.
    2. OCTAVE et OCTAVE Allegro renvoient à la même méthode dans deux variantes linguistiques (anglaise et latine pour Allegro), leurs deux acronymes étant strictement interchangeables dans la littérature professionnelle.
    3. OCTAVE Allegro a été remplacée en 2018 par une fusion avec FAIR donnant naissance à une méthode unique combinant l'approche actif-vulnérabilité du SEI et la quantification monétaire du FAIR Institute.
    4. OCTAVE et OCTAVE Allegro sont publiées par le Software Engineering Institute (SEI) de Carnegie Mellon, Allegro étant une déclinaison simplifiée centrée sur les actifs informationnels critiques.

Répondez à ces mêmes dix questions dans le simulateur et voyez l'explication de chaque option, y compris des mauvaises. Il s'ouvre sans inscription →

À propos de l'examen officiel : le format, la durée et le nombre de questions sont fixés par l'organisme qui certifie et peuvent évoluer ; confirmez-les dans sa documentation avant de vous présenter. Ce matériel entraîne la norme, pas l'examen d'un organisme particulier : il sert donc aussi si vous vous certifiez ailleurs.