Questions d'entretien Spécialiste en cybersécurité

Je commence par définir soigneusement le périmètre : quels actifs sont concernés, quel serait l'impact business d'une indisponibilité, et quelles fenêtres de maintenance sont disponibles. J'utilise des outils de scan automatisés comme Nessus ou Qualys pour identifier les CVE connus, puis je procède à une vérification manuelle pour éliminer les faux positifs. Sur les systèmes de production, je priorise d'abord les vérifications en lecture seule et non intrusives, et je planifie les tests actifs pendant les fenêtres de faible trafic en coordination avec l'équipe opérationnelle. Après le scan, je trie les résultats par score CVSS et par contexte métier : un score critique sur un système interne représente un risque différent du même score sur une API exposée sur Internet. Je documente tout dans un rapport de remédiation avec des responsabilités et des délais clairs.

J'ai travaillé avec Splunk et Microsoft Sentinel en environnement de production, et avec QRadar en laboratoire. La fatigue des alertes est l'un des plus grands défis pratiques dans tout SOC. Mon approche consiste à ajuster à la source : je révise les règles d'alerte chaque trimestre et je supprime ou ajuste toute règle n'ayant généré aucun vrai positif en 90 jours. Je crée aussi des règles de corrélation qui regroupent des alertes de faible fiabilité en un seul incident de confiance élevée, plutôt que de saturer la file avec des événements individuels. Pour les nouveaux environnements, je commence par mesurer le trafic normal pendant deux à quatre semaines avant d'activer les alertes à seuil. Je suis les taux de faux positifs par règle dans un tableau de bord simple.

Je suis plusieurs flux de renseignements sur les menaces : le catalogue des vulnérabilités exploitées connues de la CISA, les avis de sécurité de Microsoft et CrowdStrike, et des sources communautaires comme le SANS Internet Storm Center. Je m'abonne aux résumés hebdomadaires de Krebs on Security et The Hacker News pour avoir une vision plus large. Au sein de mon équipe, j'anime chaque mois une courte session où nous analysons ensemble une violation récente ou un CVE d'actualité, et nous discutons des contrôles qui auraient pu l'identifier ou la limiter. Je participe aussi à des compétitions CTF quelques fois par an pour maintenir mes compétences pratiques dans des domaines comme le reverse engineering. Je documente les menaces pertinentes dans notre base de connaissances interne pour que toute l'équipe en bénéficie.

Dans mon poste précédent, notre SIEM a déclenché une alerte un vendredi soir à 23h signalant un trafic sortant inhabituel depuis un contrôleur de domaine vers une IP externe inconnue. J'étais d'astreinte. J'ai immédiatement isolé la machine du réseau pour contenir la propagation potentielle, puis j'ai extrait les journaux Splunk des 48 heures précédentes. En 20 minutes, j'ai identifié qu'un compte de service avait été utilisé pour exécuter des commandes PowerShell qui avaient exfiltré un listing de répertoire vers un point de terminaison externe. J'ai escaladé au responsable sécurité et ouvert un ticket d'incident formel. Nous avons retracé l'accès initial à un e-mail de phishing qui avait livré un document avec macro trois jours plus tôt. J'ai coordonné la réinitialisation des identifiants, le correctif du vecteur et un scan complet des endpoints similaires. L'incident a été contenu en quatre heures. Le post-mortem nous a conduits à bloquer l'exécution des macros sur tous les endpoints.

Lors d'un test de pénétration interne de routine, j'ai découvert qu'une ancienne application web interne était vulnérable à l'injection SQL sur son endpoint de connexion. L'application traitait encore des données RH pour environ 400 employés. J'ai immédiatement arrêté les tests pour éviter toute extraction de données involontaire et documenté le payload exact et la réponse confirmant la vulnérabilité, avec des captures d'écran, pour que l'équipe de développement ait des étapes de reproduction claires. J'ai escaladé à la fois au propriétaire de l'application et au RSSI le même après-midi via notre processus de divulgation de vulnérabilités, en la signalant comme critique. J'ai recommandé de mettre l'application hors ligne temporairement pendant qu'un correctif était préparé. J'ai travaillé avec le développeur pour tester le correctif en staging puis l'ai validé en production le lendemain. L'ensemble du cycle a duré 36 heures. J'ai également signalé que d'autres applications héritées présentaient probablement des problèmes similaires et proposé un audit ciblé.

J'avais pour mission de déployer l'authentification multifacteur dans tous les environnements cloud. Une équipe d'ingénierie a fortement résisté, arguant que le MFA sur leurs comptes de service de pipeline CI/CD briserait leur flux de déploiement. Plutôt que d'escalader immédiatement, j'ai planifié un échange avec leur responsable technique pour comprendre la friction spécifique. Leur préoccupation s'est avérée légitime : leurs outils ne prenaient pas en charge les invites MFA interactives dans les pipelines automatisés. J'ai recherché des alternatives et proposé l'utilisation de jetons de compte de service à durée de vie courte avec une liste d'autorisation IP stricte et une rotation automatisée via HashiCorp Vault comme contrôle compensatoire, documenté dans notre registre d'écarts ISO 27001. L'équipe d'ingénierie a apprécié que j'aie pris leur contrainte au sérieux. Le résultat a été un déploiement complet sur les comptes interactifs en deux semaines.

L'authentification est le processus de vérification de l'identité d'un utilisateur ou d'un système. L'autorisation est le processus qui détermine ce que cette identité vérifiée est autorisée à faire. Ce sont des contrôles distincts et les défaillances dans chacun ont des conséquences différentes. Une vulnérabilité d'authentification cassée signifie qu'un attaquant peut usurper entièrement l'identité d'un utilisateur légitime. Une vulnérabilité d'autorisation cassée signifie qu'un attaquant déjà authentifié peut accéder à des ressources ou effectuer des actions non autorisées, comme accéder aux données d'un autre utilisateur en modifiant un identifiant dans une URL. En conception de sécurité, les deux sont nécessaires : une authentification forte avec MFA, gestion sécurisée des sessions et hachage des identifiants, combinée à un modèle d'autorisation bien défini utilisant un contrôle d'accès basé sur les rôles. Une erreur courante est de supposer que l'authentification est suffisante : de nombreuses violations réelles impliquent des identifiants valides utilisés pour atteindre des données qui auraient dû être contrôlées mais ne l'étaient pas.

Je divise un test de pénétration en cinq phases. D'abord, le périmètre et les règles d'engagement : je m'accorde avec le client sur ce qui est dans le périmètre, ce qui est exclu, les méthodes de test autorisées et les contacts en cas de problème. Ensuite, la reconnaissance : je collecte des renseignements en sources ouvertes avec des outils comme Shodan, Amass et theHarvester pour cartographier la surface d'attaque. Troisièmement, le scan et l'énumération : j'utilise Nmap pour la découverte des ports et services, puis des outils plus ciblés selon les résultats. Quatrièmement, l'exploitation : je tente d'exploiter les faiblesses identifiées, toujours dans les règles convenues, et je documente ce à quoi j'accède, pas seulement le fait d'être entré. Cinquièmement, le rapport : je rédige un rapport structuré autour du risque métier, pas seulement des résultats techniques. Je débrieffe toujours le client en personne avant le rapport écrit.

Le phishing est le vecteur d'accès initial le plus courant. La défense commence par des contrôles techniques : filtrage des e-mails, configuration DMARC et SPF, et blocage de l'exécution des macros dans les documents Office. Mais la défense la plus durable est la formation à la sensibilisation à la sécurité avec des exercices réguliers de phishing simulé. L'injection SQL se produit lorsque les entrées utilisateur sont insérées dans des requêtes de base de données sans assainissement. La défense principale consiste à utiliser des requêtes paramétrées ou des instructions préparées : cela rend l'injection structurellement impossible. Le WAF ajoute des couches supplémentaires, mais les requêtes paramétrées sont non négociables. Les attaques de type man-in-the-middle ciblent les données en transit, généralement sur des réseaux non sécurisés. La défense consiste à imposer TLS sur toutes les connexions, implémenter les en-têtes HSTS, utiliser l'épinglage de certificat pour les applications mobiles, et former les utilisateurs à ne pas se connecter au Wi-Fi public sans VPN.