Analyste en cybersécurité Questions d'entretien & Réponses

Exemple de réponse

J'ai détecté un trafic sortant anormal depuis un poste de travail à 2h du matin via les alertes de notre SIEM : 500 Mo avaient été envoyés vers une adresse IP inconnue par un canal chiffré. J'ai immédiatement isolé le poste du réseau et lancé l'investigation. L'analyse mémoire a révélé un beacon Cobalt Strike actif depuis 3 jours, vraisemblablement déposé par un e-mail de spear-phishing contenant une macro malveillante. J'ai retracé les mouvements latéraux jusqu'à 2 postes supplémentaires, aucun n'ayant accédé à des données sensibles. J'ai confiné tous les systèmes concernés, réinitialisé les identifiants des comptes compromis et coordonné avec l'équipe sécurité e-mail pour bloquer le domaine de phishing. Le temps total de confinement a été de 4,5 heures. En post-incident, j'ai mis en place des politiques de blocage des macros dans Office, ajouté des règles de détection comportementale pour les patterns de beaconing C2 et organisé une formation ciblée de sensibilisation au phishing. Aucun incident ultérieur n'a été constaté de la part de cet acteur malveillant.

Exemple de réponse

Lors d'une revue de routine de notre application web, j'ai remarqué que le flux de réinitialisation de mot de passe envoyait un token par e-mail, mais que ce token n'expirait pas après utilisation. J'ai testé et confirmé : le même token de réinitialisation pouvait être utilisé plusieurs fois pendant 24 heures. L'équipe de développement s'était concentrée sur l'expiration temporelle du token, mais avait omis l'exigence d'usage unique. J'ai rédigé un rapport sur la vulnérabilité avec une preuve de concept claire montrant comment un attaquant ayant accès à la boîte e-mail de quelqu'un pouvait utiliser un token périmé plusieurs jours après. Je l'ai classée en sévérité moyenne car elle nécessitait un accès à l'e-mail, mais urgente car le correctif était simple. L'équipe a déployé un correctif d'une ligne (invalider le token à l'usage) en 2 heures. J'ai ensuite passé en revue tous les autres flux basés sur des tokens et découvert un problème similaire dans le flux de vérification d'e-mail, que nous avons corrigé dans le même sprint.

Exemple de réponse

Je souhaitais déployer une solution de gestion des accès à privilèges (PAM) car nous avions plus de 40 comptes administrateurs partagés sans aucune piste d'audit. La direction le percevait comme une dépense de 60 000 € sans ROI visible. J'ai recadré la discussion : j'ai calculé le coût d'une violation par élévation de privilèges à partir de données sectorielles (4,5 millions d'euros en moyenne pour notre taille d'entreprise), multiplié par notre probabilité estimée compte tenu de nos contrôles actuels, et j'ai présenté la perte attendue. J'ai également montré 3 conclusions d'audit récentes citant les identifiants partagés comme un risque, ce qui pouvait affecter notre certification SOC 2, une exigence pour 70 % de nos clients grands comptes. Enfin, j'ai présenté le coût opérationnel : 15 heures par mois consacrées à la rotation manuelle des identifiants partagés. La solution PAM s'autofinancerait par les économies de gestion des identifiants en 14 mois. La direction a approuvé. La leçon : les investissements en sécurité doivent être présentés sous l'angle du risque métier et de l'efficacité opérationnelle, pas de la peur technique.

Exemple de réponse

Je maintiens une approche structurée de la veille sur les menaces. Au quotidien : je consulte des flux sélectionnés provenant de la CISA, Krebs on Security et The Record. Chaque semaine : je consacre 2 heures à des exercices pratiques, des salles TryHackMe, des défis HackTheBox ou la reproduction d'exploits de CVE récents dans mon lab personnel. Chaque mois : je participe à la réunion de mon chapitre OWASP local et à un groupe de partage de renseignements sur les menaces en ligne avec des professionnels de la sécurité de 15 entreprises. Chaque trimestre : je suis une formation ciblée. Le trimestre dernier, c'était la sécurité cloud sur AWS ; ce trimestre, l'analyse de malwares avec Ghidra. Quand une vulnérabilité majeure émerge (comme Log4Shell), j'évalue immédiatement notre exposition, je crée des règles de détection et je briefe l'équipe. Cette approche a porté ses fruits à plusieurs reprises : j'avais des règles de détection pour la vulnérabilité MOVEit prêtes en 6 heures après la divulgation, car je suivais les TTPs de l'acteur malveillant via mes flux de renseignements.

Exemple de réponse

MITRE ATT&CK est une base de connaissances des tactiques, techniques et procédures (TTPs) des adversaires, organisée par étapes du cycle de vie d'une attaque : accès initial, exécution, persistance, élévation de privilèges, évasion des défenses, accès aux identifiants, découverte, mouvement latéral, collecte, exfiltration et commande et contrôle. Je l'utilise de trois manières. D'abord, pour l'ingénierie de détection : je cartographie nos règles de détection SIEM sur les techniques ATT&CK afin d'identifier les lacunes de couverture. Quand je constate qu'aucune détection ne couvre T1055 (injection de processus), je priorise la création de ces règles. Ensuite, pour la chasse aux menaces : j'utilise ATT&CK pour structurer des hunts basés sur des hypothèses. Si un renseignement indique qu'un groupe APT spécifique cible notre secteur, je traque ses TTPs documentés dans notre environnement. Enfin, pour l'investigation d'incidents : quand je détecte une technique, ATT&CK m'indique ce que l'adversaire a probablement fait avant et ce qu'il fera ensuite, ce qui me permet de cadrer l'investigation plus efficacement.

Exemple de réponse

Le chiffrement symétrique utilise la même clé pour le chiffrement et le déchiffrement. Il est rapide, mais nécessite un échange de clé sécurisé. AES-256 est le standard. Exemple concret : le chiffrement des données au repos dans une base de données. Le serveur applicatif détient la clé et chiffre ou déchiffre les données en lecture et en écriture. Le chiffrement asymétrique utilise une paire de clés : la clé publique chiffre, la clé privée déchiffre. Il est plus lent, mais résout le problème d'échange de clé. RSA et ECDSA sont des algorithmes courants. Exemple concret : la négociation TLS. Quand vous visitez un site web, votre navigateur utilise la clé publique du serveur pour établir une clé de session partagée, puis bascule vers le chiffrement symétrique pour le transfert effectif des données. Cette approche hybride combine la sécurité du chiffrement asymétrique pour l'échange de clé avec la rapidité du chiffrement symétrique pour les volumes importants. En pratique, je recommande toujours AES-256 pour les données au repos, TLS 1.3 pour les données en transit, et une gestion des clés appropriée via des services comme AWS KMS plutôt que de stocker les clés avec les données qu'elles protègent.

Exemple de réponse

Je suivrais un processus d'investigation structuré. D'abord, le périmètre : identifier la source de l'alerte et les premiers indicateurs, un volume de données inhabituel vers une IP externe, des patterns de tunneling DNS ou un accès non autorisé à un stockage cloud. Préserver les preuves immédiatement : snapshot des systèmes concernés, capture des journaux réseau et documentation de la chronologie. Ensuite, l'analyse : consulter les journaux SIEM pour la chronologie complète des activités de l'utilisateur ou du système source. Quelles données ont été accédées ? Quand le comportement anormal a-t-il commencé ? L'IP de destination est-elle connue comme malveillante ? Croiser avec les alertes DLP, les journaux des postes et les journaux d'authentification. Troisièmement, la détermination : s'agit-il d'une exfiltration réelle, d'un transfert de données autorisé ou d'un faux positif ? Je vérifierais avec le propriétaire des données et le responsable de l'utilisateur avant d'escalader. Quatrièmement, si la malveillance est confirmée : isoler les systèmes concernés, désactiver les comptes compromis, bloquer le canal d'exfiltration et activer le plan de réponse aux incidents, y compris la notification des équipes juridiques et de conformité. Cinquièmement, tout documenter dans le système de suivi des incidents avec la chronologie, les preuves et la chaîne de garde. Les 30 premières minutes sont critiques : la rapidité de confinement est directement corrélée au volume de données perdues.

Exemple de réponse

Le Zero Trust repose sur le principe « ne jamais faire confiance, toujours vérifier » : aucune confiance implicite fondée sur l'emplacement réseau, l'appareil ou l'identité de l'utilisateur. Chaque demande d'accès est authentifiée, autorisée et chiffrée, quelle que soit son origine. Mise en œuvre par phases. Première phase, l'identité : authentification forte pour tous les utilisateurs (MFA obligatoire, idéalement résistante au phishing comme FIDO2), avec un accès à moindre privilège et un provisionnement en juste-à-temps. Deuxième phase, les appareils : vérifier que les appareils respectent les standards de sécurité (OS à jour, protection des points de terminaison, chiffrement) avant d'autoriser l'accès, avec évaluation de la posture à chaque connexion. Troisième phase, le réseau : micro-segmentation pour limiter les mouvements latéraux. Remplacer le VPN par des proxys sensibles à l'identité (type BeyondCorp ou Zscaler) qui accordent un accès par application. Quatrième phase, les données : classifier les données, chiffrer au repos et en transit, et mettre en place des contrôles DLP. Cinquième phase, la surveillance : vérification continue tout au long de la session. Un comportement anormal déclenche une nouvelle authentification ou la révocation de l'accès. Je mettrais cela en place progressivement, en commençant par les systèmes les plus sensibles et en élargissant sur 12 à 18 mois.

Exemple de réponse

Je gérerais cela avec précaution, car il pourrait s'agir d'une simple mauvaise configuration des contrôles d'accès ou d'une menace interne intentionnelle. D'abord, je vérifierais la découverte discrètement : confirmer que les journaux d'accès sont exacts, vérifier si le rôle de l'employé a récemment changé (un changement de rôle sans mise à jour des accès est fréquent) et déterminer quelles données ont été consultées. Je n'alerterais pas l'employé. Ensuite, j'escaladerais à mon responsable sécurité et aux RH avec les preuves documentées : ce qui a été consulté, quand, à quelle fréquence, et si des données ont été téléchargées ou transférées vers l'extérieur. Troisièmement, selon leurs instructions, je travaillerais avec l'équipe IT pour restreindre discrètement l'accès (s'il s'agit d'un problème de contrôle d'accès) ou je mettrais en place une surveillance renforcée si une menace interne est suspectée. Je préserverais toutes les preuves au cas où cela deviendrait une affaire juridique. L'essentiel est la proportionnalité de la réponse : conclure trop vite à une menace interne alors qu'il s'agit d'une politique RBAC défaillante crée un drame inutile et nuit à la confiance.

Exemple de réponse

Actions immédiates (première heure) : évaluer notre exposition. Le composant vulnérable est-il accessible depuis Internet ? À quelles données a-t-il accès ? Existe-t-il un exploit connu dans la nature ? Si nous sommes activement exploitables, je mettrais en place des mesures d'atténuation d'urgence : règles WAF pour bloquer les patterns d'exploitation connus, restrictions réseau pour limiter l'accès au service vulnérable, et désactivation de la fonctionnalité concernée si l'impact métier est acceptable. À court terme (premier jour) : mettre en place une surveillance des indicateurs d'exploitation spécifiques, augmenter la verbosité des journaux pour le système concerné, et traquer les signes d'exploitation passée. Communication : informer la direction sécurité et les propriétaires du système avec une évaluation claire des risques et l'état des mesures d'atténuation. À moyen terme : appliquer le correctif du fournisseur dès sa disponibilité, en le pré-stageant et le testant en environnement de staging pour pouvoir déployer dans les heures suivant sa publication. Si aucun correctif n'arrive sous une semaine, évaluer la migration vers une alternative ou des modifications architecturales pour isoler le risque. Tout au long du processus : suivre la vulnérabilité dans notre registre des risques avec les contrôles compensatoires documentés.

Exemple de réponse

Je réaliserais une évaluation structurée du risque fournisseur. D'abord, la classification des données : quelles données clients l'outil va-t-il traiter ? Des données personnelles, financières, de santé ? Cela détermine les exigences réglementaires (RGPD, CCPA, HIPAA, PCI-DSS). Ensuite, la posture de sécurité du fournisseur : demander leur rapport SOC 2 Type II, leur certification ISO 27001 et leurs résultats de tests d'intrusion. Examiner leurs pratiques de chiffrement des données (au repos et en transit), leurs contrôles d'accès et leurs capacités de réponse aux incidents. Troisièmement, la revue technique : comment fonctionne l'intégration ? OAuth ou authentification par mot de passe ? Quelles autorisations API nécessite-t-elle ? Où les données sont-elles stockées géographiquement (important pour le RGPD) ? Peut-on imposer le SSO et le MFA ? Quatrièmement, la revue contractuelle : accord de traitement des données, délai de notification en cas de violation, clauses de propriété et de suppression des données, droit d'audit. Je noterais le fournisseur sur une matrice de risque et présenterais une recommandation : approuver, approuver sous conditions (exigences de sécurité spécifiques) ou rejeter avec des alternatives. En cas d'approbation sous conditions, je fixerais une date de révision pour vérifier que les conditions sont remplies.

Exemple de réponse

J'escaladerais le risque clairement, sans être conflictuel. Je présenterais la découverte avec une évaluation concrète : la sévérité de la vulnérabilité (score CVSS), son exploitabilité (existe-t-il un exploit public ? est-elle exploitable à distance ?), les données en jeu et l'impact métier estimé en cas de violation. Je proposerais des contrôles compensatoires pour la période intérimaire : segmentation réseau pour limiter l'exposition, règles WAF pour bloquer les patterns d'attaque connus, surveillance et alertes renforcées pour les tentatives d'exploitation, et réduction des permissions d'accès. Je travaillerais avec le propriétaire du système pour comprendre pourquoi le correctif prend 3 mois. Parfois la durée est réelle (fenêtres de changement réglementaires, dépendances complexes) ; parfois c'est simplement de l'inertie dans la planification. Si les contrôles compensatoires permettent de ramener le risque à un niveau acceptable, je documenterais le risque résiduel accepté avec la validation du propriétaire du système et de sa direction. Si le risque est véritablement critique et qu'aucun contrôle compensatoire ne suffit, j'escaladerais au RSSI avec une recommandation claire. C'est alors une décision métier, pas seulement technique.