Questions d'entretien CISM

Les auditeurs vérifient des preuves, pas des intentions : présentez la politique de revue d'accès, des relevés datés de chaque revue avec la validation d'un approbateur, et la confirmation que les accès signalés ont bien été révoqués et vérifiés. Une confirmation verbale ne prouve rien de reproductible, une promesse de commencer le trimestre prochain montre que le contrôle ne fonctionnait pas pendant la période auditée, et un organigramme décrit des liens hiérarchiques, pas des décisions d'accès. Seuls les artefacts datés et attribuables démontrent que le contrôle a fonctionné comme prévu sur toute la période.

Les sauvegardes sont nécessaires mais non suffisantes : la reprise d'activité et la continuité d'activité sont la capacité testée à restaurer l'activité dans les objectifs convenus de temps et de point de reprise (RTO/RPO), ce qui exige un plan documenté, des dépendances cartographiées, des runbooks et des restaurations validées — pas seulement l'existence de fichiers de sauvegarde. Affirmer qu'elles sont identiques confond une copie de données avec une capacité opérationnelle. Le PRA ne se résume pas à souscrire une assurance, qui transfère la perte financière mais ne restaure pas les systèmes. Et les sauvegardes ne rendent pas un PRA inutile — des sauvegardes non testées échouent régulièrement le moment venu. La clarification : le PRA doit être exercé, pas présumé.

Les référentiels fixent une barre minimale et peuvent être pleinement satisfaits alors qu'un risque réel subsiste ; une check-list réussie ne signifie donc pas sécurisé : signalez la faille, évaluez son risque et pilotez son traitement, quel que soit le statut de conformité. Conclure que c'est sécurisé parce que la conformité est validée est un amalgame dangereux entre deux choses différentes. Retirer la faille du rapport est une falsification, voire une fraude. Attendre le prochain cycle d'audit laisse sciemment une exposition réelle ouverte. La posture mature traite la conformité comme la preuve d'un plancher, pas d'un plafond, et agit sur le risque que l'on peut réellement voir.

Un traitement incohérent traduit généralement l'absence de définition partagée de la sensibilité ; le contrôle fondamental est donc un schéma de classification des données (par ex. public/interne/confidentiel/restreint) avec des exigences définies de traitement, de stockage et de partage par niveau, permettant aux équipes d'appliquer des contrôles proportionnés. Ne rien chiffrer « pour faire simple » ou traiter toutes les données comme publiques retire la protection aux données qui en ont besoin. Supprimer toutes les données de plus d'un jour détruit des enregistrements dont l'entreprise et la loi ont besoin. Seul un schéma de classification aligne la force des contrôles sur la sensibilité réelle des données.

Le risque au départ, c'est l'accès résiduel ; le contrôle à vérifier est donc le déprovisionnement rapide de chaque voie d'accès — comptes d'annuaire, SSO, VPN, identifiants privilégiés et de service, et SaaS tiers — rapproché du processus arrivée/mobilité/départ (JML). Supposer que les RH gèrent tout sans vérification laisse des failles que personne ne possède. Garder le compte actif « au cas où il reviendrait » est un risque permanent et non surveillé. Désactiver seulement l'e-mail ignore les nombreux autres systèmes que la personne pourrait encore atteindre. L'enjeu est de vérifier que l'accès est réellement et totalement retiré, pas de présumer qu'il l'a été.

Le périmètre PCI DSS couvre les systèmes qui stockent, traitent ou transmettent les données de titulaires de cartes, plus tout système qui leur est connecté ou peut les affecter ; une segmentation réseau efficace isole donc l'environnement des données de cartes (CDE) et exclut du périmètre les systèmes sans rapport, réduisant coût, effort et risque. Chiffrer tous les serveurs ne définit aucune frontière et les systèmes connectés restent dans le périmètre ; ajouter des pare-feu partout sans cible n'est pas de la segmentation si cela ne restreint ni ne valide les flux de données ; et cesser de lire les numéros de carte à voix haute relève de l'hygiène, pas d'un contrôle de périmètre. La réponse systémique est de maîtriser où vivent les données de cartes et ce qui peut les atteindre.

La gouvernance, c'est capturer et gérer le risque, pas le traiter de façon informelle : inscrivez-le au registre des risques avec une probabilité et un impact évalués, désignez un propriétaire responsable, décidez et documentez le traitement (atténuer, transférer, accepter ou éviter), et fixez une date de revue. Le corriger vous-même sur-le-champ contourne la responsabilité, la priorisation et le suivi, et ce n'est peut-être même pas à vous de le faire. L'ignorer jusqu'à ce qu'il devienne un incident est une négligence, et l'envoyer par e-mail à tout le monde crée du bruit mais aucune responsabilité ni suivi. Le registre transforme une observation ponctuelle en une décision suivie, attribuée et réexaminée.

Un rapport SOC 2 ne vous rassure que si vous le lisez vraiment : confirmez le bon type (le Type II teste l'efficacité opérationnelle dans la durée, le Type I seulement la conception à un instant donné), vérifiez le périmètre et les critères des services de confiance couverts, que la période est récente et sans trou, l'opinion rendue par l'auditeur (sans réserve ou avec réserve), et examinez les exceptions relevées ainsi que les contrôles complémentaires de l'entité utilisatrice (CUEC) qui vous incombent. Se contenter de constater que le rapport existe — ou le juger à son logo de couverture ou à son nombre de pages — ne dit rien de l'efficacité réelle des contrôles du fournisseur ni de vos obligations résiduelles.

Transmettre des données personnelles à un tiers étend votre périmètre de confiance ; menez donc d'abord une évaluation de sécurité du fournisseur — traitement des données, chiffrement, contrôles d'accès, certifications comme SOC 2 / ISO 27001, sous-traitants, modalités de notification de violation — et signez un accord de traitement des données (DPA) avant tout transfert. Un contrat de prix ou la parole verbale d'un commercial n'est pas une diligence raisonnable. Et un « site web soigné » ne dit rien sur la façon dont le fournisseur protège réellement les données ; vous en restez responsable.

« Sécurisé » n'est pas binaire ; un RSSI communique dans le langage du risque métier : les risques les plus importants, la manière dont les contrôles actuels les réduisent par rapport à l'appétit pour le risque du conseil, les investissements prévus et le risque résiduel accepté. Un « oui » absolu est une fausse assurance qui s'effondre dès le premier incident. « Non, nous ne serons jamais sécurisés » est techniquement vrai mais inutile et trahit un manque de maîtrise. Une liste d'achats de pare-feu et d'outils traduit une dépense, pas un risque ni un résultat que le conseil puisse gouverner.

La gestion d'une violation est encadrée par la loi et le contrat : travailler avec le juridique pour respecter les délais de notification obligatoires (comme les 72 heures du RGPD vers l'autorité de contrôle) et informer les personnes concernées avec exactitude. La dissimulation expose à des amendes bien plus lourdes, à des sanctions et à une atteinte à la réputation lorsqu'elle est découverte. Diffuser prématurément des détails techniques bruts et non vérifiés peut induire les clients en erreur et aider les attaquants. Désigner publiquement un employé comme bouc émissaire n'est ni exact, ni légal, ni une gestion de crise efficace.

Les métriques de niveau conseil doivent se rattacher au risque et aux résultats : temps de détection et de réponse (MTTD/MTTR), respect des SLA de correctifs sur les systèmes critiques, couverture des contrôles et évolution du risque résiduel par rapport à l'appétit. Le nombre d'attaques bloquées par le pare-feu, le compte des signatures antivirus et le total des courriels reçus sont des chiffres vaniteux — ils impressionnent mais ne disent rien sur la baisse du risque. Le conseil gouverne le risque, les métriques doivent donc lui montrer la tendance et lui permettre de décider.

Un taux de clic de 30 % est un point de référence à améliorer, pas une liste de personnes à punir : associer une formation ciblée par rôle et un bouton de signalement sans friction à des défenses techniques (MFA, filtrage de courrier, moindre privilège) pour qu'un seul clic ne mène pas à une compromission, et suivre la tendance dans le temps. Humilier publiquement les employés étouffe le signalement dont vous dépendez. Déclarer le personnel irrécupérable supprime un contrôle à renforcer. Un nouveau courriel anxiogène à tous n'est pas une intervention mesurable et ne change pas le comportement.

Les dépenses de sécurité doivent suivre le risque, pas l'effet de mode : utiliser une analyse de risque pour orienter l'argent là où l'impact métier et la probabilité sont les plus élevés et où la couverture des contrôles actuels est la plus faible, puis mesurer la réduction obtenue. Acheter ce que vend le fournisseur à la mode ignore votre profil de menace réel et finance souvent des outils inutilisés. Répartir le budget également sous-finance les rares domaines qui comptent le plus. Copier les concurrents suppose que leur profil de risque égale le vôtre, ce qui est rarement le cas.

Les simulations répètent le côté humain et décisionnel de la RI — qui a l'autorité de déclarer un incident, comment circule la communication juridique/RP/direction, et où le manuel se brise — afin que la première fois où vous prenez ces décisions ne soit pas en pleine crise réelle. Il est bien moins coûteux de trouver les failles lors d'un exercice qu'en pleine violation. Ce n'est pas une case de conformité vide, ce n'est pas pour attribuer des blâmes sur des incidents passés, et c'est transverse, pas réservé au SOC — la direction doit s'entraîner aux décisions qu'elle seule peut prendre.

Quand on ne peut pas remédier, on gère le risque : réduire l'exposition par des contrôles compensatoires (segmentation réseau, restriction des accès, surveillance renforcée), quantifier le risque résiduel et faire accepter formellement ce risque par le propriétaire métier responsable, avec une date de revue définie. Un arrêt unilatéral outrepasse l'autorité du RSSI et nuit à l'entreprise. L'ignorer parce qu'il est non corrigeable est une négligence. L'omettre du registre des risques masque la responsabilité, rompt la piste d'audit et signifie que personne n'assume officiellement la décision.

Une violation chez un fournisseur est aussi votre incident : déclencher la réponse à incident pour cadrer quelles données et intégrations ont été exposées, faire tourner tous les secrets partagés, clés API et relations de confiance SSO, évaluer vos propres obligations de notification réglementaire et tenir le fournisseur à sa divulgation. Attendre passivement le fournisseur vous fait perdre le contrôle de votre propre calendrier et de vos obligations. Une résiliation publique du contrat est un effet de manche prématuré avant même de connaître votre exposition. Supposer que vous n'êtes pas touché saute précisément l'évaluation qu'attendent les régulateurs et vos clients.

Le NIST AI Risk Management Framework (AI RMF 1.0) est un cadre volontaire et fondé sur le risque pour gouverner une IA digne de confiance tout au long de son cycle de vie. Son cœur est constitué de quatre fonctions : Govern (culture, politique, responsabilité — et elle traverse les autres), Map (contexte et identification des risques), Measure (évaluer et suivre les risques) et Manage (prioriser et répondre). Il définit aussi des caractéristiques de fiabilité — valide et fiable, sûr, sécurisé et résilient, responsable et transparent, explicable, respectueux de la vie privée et équitable. Il complète des listes techniques comme l'OWASP LLM Top 10 au niveau du programme.

La continuité d'activité (BCP) est la stratégie globale visant à maintenir les fonctions métier critiques pendant et après une perturbation ; la reprise après sinistre (DRP) en est le sous-ensemble informatique qui restaure les systèmes et les données. Le RTO est le temps maximal tolérable pour rétablir une fonction ; le RPO est la perte de données maximale tolérable mesurée en temps.

La due diligence est l'investigation et la compréhension continues des risques (savoir ce qu'il faut faire), tandis que la due care consiste à prendre les mesures raisonnables qu'une personne prudente prendrait pour y répondre (le faire réellement). La diligence est la recherche et la supervision ; la care est la mise en œuvre et le maintien.

L'analyse quantitative attribue des valeurs monétaires concrètes pour calculer la perte attendue ; l'analyse qualitative classe le risque sur des échelles relatives (élevé/moyen/faible) par jugement d'expert. La quantitative utilise SLE = valeur de l'actif x facteur d'exposition, ARO = occurrences attendues par an, et ALE = SLE x ARO pour exprimer la perte annuelle attendue en euros.

Vous pouvez atténuer (réduire la probabilité/l'impact avec des contrôles), transférer (déplacer l'impact financier via une assurance ou des contrats), éviter (cesser entièrement l'activité risquée) ou accepter (tolérer sciemment le risque résiduel). Le choix dépend de l'appétit pour le risque et d'une comparaison coûts-bénéfices au regard de la perte attendue du risque.

Les contrôles se classent de deux façons. Par type : administratif (politiques, formation, procédures), technique/logique (pare-feu, MFA, chiffrement) et physique (serrures, badges, caméras). Par fonction : préventif (empêcher un événement — MFA, contrôle d'accès), détectif (repérer un événement — SIEM, IDS, journaux d'audit), correctif (réparer après — restauration de sauvegarde, correctif), dissuasif (décourager — bannières d'avertissement) et compensatoire (une alternative quand le contrôle principal n'est pas faisable). La défense en profondeur superpose ces contrôles pour qu'aucune défaillance isolée ne mène à une compromission.

L'article 5 du GDPR pose sept principes : licéité/loyauté/transparence, limitation des finalités, minimisation des données, exactitude, limitation de la conservation, intégrité et confidentialité, et responsabilité. En cas de violation de données personnelles, le responsable du traitement doit notifier l'autorité de contrôle compétente sans retard injustifié et, si possible, dans les 72 heures après en avoir pris connaissance (article 33). Si la violation est susceptible d'engendrer un risque élevé pour les personnes, le responsable doit aussi notifier les personnes concernées sans retard injustifié (article 34).

La gouvernance est la façon dont la direction fixe le cap, définit la responsabilité et aligne la sécurité sur les objectifs métier — les politiques, les rôles et la supervision qui disent à quoi ressemble « le bon niveau ». La gestion des risques est le processus d'identification, d'évaluation, de traitement et de surveillance des menaces pesant sur ces objectifs. La conformité consiste à démontrer le respect des obligations — lois, règlements, contrats et politiques internes. La gouvernance pilote les décisions de risque ; le risque détermine les contrôles nécessaires ; la conformité prouve que ces contrôles répondent aux normes exigées. La conformité est un résultat d'une bonne GRC, pas un substitut à la sécurité.

HIPAA (la loi américaine Health Insurance Portability and Accountability Act) protège les Protected Health Information (PHI). La Privacy Rule encadre l'utilisation et la divulgation des PHI ; la Security Rule s'applique aux PHI électroniques (ePHI) et exige trois catégories de garanties — administratives, physiques et techniques. Elle s'applique aux covered entities (prestataires, régimes de santé, chambres de compensation) et aux business associates qui traitent des PHI pour leur compte, liés par des Business Associate Agreements. La Breach Notification Rule fixe les obligations de notifier les personnes, le HHS et parfois les médias.

ISO/IEC 27001 spécifie les exigences d'un Information Security Management System (ISMS) : un cadre descendant et fondé sur le risque, fait de politiques, de processus, de rôles et d'amélioration continue (Plan-Do-Check-Act) qui régit la manière dont une organisation gère la sécurité de l'information. L'Annexe A est un catalogue de contrôles de référence. On ne les applique pas tous aveuglément — on mène une analyse des risques, on décide quels contrôles sont nécessaires, et on documente les décisions d'inclusion/exclusion avec justification dans une Statement of Applicability (SoA).

Le NIST Cybersecurity Framework organise les résultats de cybersécurité en fonctions principales. Dans le CSF 2.0, il y en a six : Govern (la nouvelle fonction faîtière pour la stratégie, les rôles, les décisions de risque et la supervision), Identify (comprendre les actifs et les risques), Protect (garanties pour limiter l'impact), Detect (repérer les événements), Respond (agir sur les incidents) et Recover (restaurer les capacités). Elles ne sont pas strictement séquentielles — elles fonctionnent en continu et décrivent ensemble un cycle de vie complet de gestion du cyber-risque.

PCI DSS (Payment Card Industry Data Security Standard) est une norme de sécurité maintenue par le PCI Security Standards Council qui s'applique à toute organisation qui stocke, traite ou transmet des données de titulaires de cartes. Elle s'organise autour d'objectifs de contrôle couvrant un réseau sécurisé, la protection des données stockées, la gestion des vulnérabilités, un contrôle d'accès fort, la surveillance/les tests et une politique de sécurité de l'information. Le périmètre est tout ce qui se trouve dans le cardholder data environment (CDE) — donc la segmentation, la tokenisation et le fait de ne pas stocker de données inutiles sont les principaux moyens de le réduire.

Traitez la sensibilisation comme un changement de comportement, pas comme une case à cocher annuelle. Rendez-la basée sur les rôles (un développeur a besoin d'un contenu différent de celui de la finance), continue plutôt qu'un diaporama une fois par an, et ancrée dans des risques réels comme le phishing, l'ingénierie sociale et la manipulation des données. Renforcez-la avec des simulations de phishing, des rappels au bon moment et des canaux de signalement clairs. Mesurez les résultats — taux de signalement de phishing, taux de clic, temps de signalement — pas seulement les pourcentages d'achèvement. Bâtissez une culture où les gens signalent leurs erreurs sans crainte, car la crainte étouffe le signalement.

Un KPI (Key Performance Indicator) mesure la performance d'une activité de sécurité par rapport à son objectif — par exemple le délai moyen de détection, le respect du SLA de correctifs, ou le pourcentage de systèmes avec MFA. Un KRI (Key Risk Indicator) est un signal prospectif indiquant que l'exposition au risque augmente vers un niveau inacceptable, avec un seuil censé déclencher une action — par exemple le nombre de correctifs critiques en retard, le compte d'appareils non gérés, ou les revues d'accès échouées en hausse. Les KPI vous disent comment vous vous en sortez ; les KRI vous avertissent de la direction que vous prenez.

Un rapport SOC 2 Type I évalue si les contrôles d'une organisation de services sont conçus de façon adéquate à un instant unique. Un rapport Type II va plus loin : il teste si ces contrôles ont fonctionné efficacement sur une période d'examen, généralement de 3 à 12 mois. Les deux reposent sur les Trust Services Criteria de l'AICPA — la Sécurité (les critères communs obligatoires), plus en option la Disponibilité, l'Intégrité du traitement, la Confidentialité et la Vie privée.

Traitez le risque fournisseur comme un cycle de vie, pas comme un questionnaire ponctuel. Inventoriez vos tiers et classez-les par criticité et sensibilité des données. Menez une due diligence proportionnelle au niveau — examinez les rapports SOC 2 / ISO 27001, les questionnaires de sécurité, les synthèses de pentest, ainsi que les données et accès concernés. Inscrivez les contrôles dans le contrat (exigences de sécurité, droit d'audit, notification de violation, traitement des données, sous-traitants). Surveillez ensuite en continu, pas seulement à l'onboarding, et prévoyez un processus d'offboarding propre pour révoquer les accès et récupérer ou détruire les données. Le risque de quatrième partie (sous-traitant) compte aussi.

Une analyse de risque identifie les actifs et leur valeur, les menaces et vulnérabilités qui pourraient les affecter, puis estime le risque comme une fonction de la vraisemblance et de l'impact. On peut la mener qualitativement (élevé/moyen/faible, rapide et subjectif) ou quantitativement (SLE × ARO = ALE, fondé sur des données mais plus difficile). Des référentiels comme NIST RMF et ISO 27005 lui donnent une structure, et la sortie alimente le traitement du risque : atténuer, transférer, éviter ou accepter.