Questions d'entretien CISO / Security Leadership

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.

Équilibrez utilisabilité et risque : imposez un accès conditionnel lié à la posture de l'appareil et isolez les données d'entreprise dans un conteneur géré (MAM/MDM) afin de les contrôler et de les effacer sélectivement sans prendre la main sur tout l'appareil personnel. Un accès illimité risque la fuite sur des terminaux non gérés, possiblement compromis. Une interdiction pure et simple pousse aux contournements non sûrs comme le transfert vers une messagerie personnelle. Et envoyer les données en pièces jointes les disperse de façon incontrôlable sur des appareils que vous ne récupérerez jamais.

Aucun produit unique n'arrête toutes les attaques ; une sécurité mature superpose des contrôles indépendants — la défense en profondeur — pour que la défaillance de l'un ne signifie pas la compromission. Cartographiez la dépense proposée par rapport aux véritables lacunes en identité, réseau, poste de travail, données et détection, et conservez les contrôles complémentaires qui fonctionnent déjà. Tout miser sur un seul outil crée un point unique de défaillance, et arracher les contrôles existants pour les remplacer réduit la couverture. Ne rien dépenser du tout ignore de vraies lacunes.

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.

Les dirigeants sont précisément les comptes que veulent les attaquants (BEC, fraude au virement), donc les exempter inverse le modèle de risque. Résolvez la friction, pas le contrôle : déployez des passkeys/FIDO2 résistants au phishing, plus rapides que les codes. Céder à la dérogation détruit la crédibilité du programme et laisse vos comptes de plus grande valeur sans protection. Abandonner le projet MFA, c'est renoncer à un contrôle de premier ordre. L'activer en douce dans leur dos détruit la confiance et la responsabilité.

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 classification étiquette les données par sensibilité afin que l'organisation applique des contrôles proportionnés à la valeur et au risque, évitant à la fois la sous-protection et la surprotection coûteuse. Le propriétaire des données (un rôle métier) fixe la classification et accepte le risque, tandis que le dépositaire des données (souvent l'IT) met en œuvre et maintient les contrôles de protection.

La défense en profondeur superpose des contrôles multiples, variés et indépendants à travers les personnes, les processus et la technologie, afin que la défaillance d'un seul contrôle n'entraîne pas de compromission. Elle suppose que chaque contrôle finira par échouer et utilise la redondance et la variété pour ralentir, détecter et contenir un attaquant.

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.

Une politique est l'énoncé obligatoire de haut niveau de l'intention de la direction ; une norme est une règle obligatoire et spécifique qui applique la politique (par exemple AES-256) ; une procédure est le mode opératoire obligatoire étape par étape ; une ligne directrice est une recommandation facultative. Les politiques, normes et procédures sont obligatoires, tandis que les lignes directrices sont discrétionnaires.

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.

Intégrez la sécurité à chaque phase du SDLC plutôt que de tester à la fin : les exigences incluent des exigences de sécurité et de confidentialité, la conception inclut la modélisation des menaces, le développement suit des normes de codage sécurisé avec SAST, les tests ajoutent DAST et des revues, et la mise en production nécessite une validation — le tout gouverné par la politique, la séparation des tâches et la gestion des changements. Corriger les failles tôt coûte nettement moins cher qu'après la mise en production.

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.

Un bon rapport sert deux publics : un résumé exécutif qui cadre le risque métier pour la direction, et des trouvailles détaillées et reproductibles avec preuves, évaluations de risque exactes et remédiation priorisée pour l'équipe technique. Le rapport — et non l'exploit — est le livrable.