Questions d'entretien Ingénieur sécurité

La modélisation des menaces est la plus précieuse quand elle est faite de façon collaborative avec l'équipe d'ingénierie pendant la phase de conception, avant que tout code soit écrit, car c'est à ce moment que les changements sont les moins coûteux. J'utilise le framework STRIDE comme point de départ structuré : Usurpation d'identité, Altération, Répudiation, Divulgation d'informations, Déni de service et Élévation de privilèges. Je passe en revue chaque composant du système avec l'équipe, identifiant les actifs, les limites de confiance et les flux de données, puis je demande systématiquement ce qui pourrait mal tourner pour chaque catégorie STRIDE. Je capture les menaces dans un document de modélisation des menaces qui associe chaque menace à une évaluation de probabilité et d'impact, et surtout à une atténuation spécifique. Les atténuations deviennent des exigences de sécurité qui alimentent le backlog de développement. Je revisite également le modèle de menaces lors de changements de conception importants.

Un test de pénétration utile commence par une portée claire et un modèle de menaces, pas un exercice de scan générique. Les meilleurs pentests sont ciblés : ils simulent les chemins d'attaque les plus probables pour le système spécifique. J'aborde les pentests en phases : reconnaissance pour comprendre la surface d'attaque, scan et énumération pour identifier les services et versions, identification des vulnérabilités, exploitation des découvertes, et post-exploitation pour comprendre le rayon d'explosion d'une compromission. Ce qui distingue les résultats utiles est la spécificité : un finding qui dit "injection SQL sur l'endpoint de connexion via le paramètre username, exploitable pour extraire la table users" est actionnable. J'insiste aussi sur les tests de régression après la remédiation pour vérifier que le correctif est efficace. Pour la sécurité continue, je préfère une combinaison de DAST automatisé en CI/CD et d'exercices ciblés de red team périodiques.

Le zero-trust signifie que chaque requête est authentifiée et autorisée indépendamment de son origine, y compris depuis l'intérieur du réseau d'entreprise. L'implémentation pratique comporte plusieurs composants. Premièrement, une identité forte pour chaque utilisateur et service : j'utilise SSO avec MFA pour les utilisateurs humains et l'identité de charge de travail (rôles IAM AWS, comptes de service Kubernetes) pour la communication machine à machine. Deuxièmement, la vérification de la confiance des appareils via une solution MDM. Troisièmement, la micro-segmentation : plutôt que de faire confiance à tout ce qui est à l'intérieur d'un VPN, j'utilise la technologie service mesh ou une API gateway pour imposer que chaque appel de service soit authentifié. Quatrièmement, la vérification continue : je n'accorde pas d'accès permanent ; j'utilise des tokens à courte durée de vie. La transition vers le zero-trust est progressive et nécessite l'adhésion des équipes d'ingénierie.

Intégrer la sécurité dans le SDLC signifie faire de la sécurité le chemin de moindre résistance plutôt qu'une barrière à la fin. En phase de conception, j'anime des ateliers de modélisation des menaces avec les équipes d'ingénierie et publie des patterns de sécurité réutilisables. En phase de développement, j'intègre des outils SAST dans l'IDE et le pipeline CI pour que les vulnérabilités courantes comme l'injection SQL et le XSS soient signalées au point d'introduction. Je maintiens également un guide de codage sécurisé référencé dans les templates de revue de code. En phase de déploiement, j'utilise le scan automatisé d'infrastructure avec Checkov et Trivy pour détecter les mauvaises configurations avant qu'elles n'atteignent la production. La clé est l'expérience développeur : si l'outillage de sécurité ajoute une friction significative sans valeur claire, les équipes trouveront des contournements.

Nous avons détecté une anomalie dans notre SIEM à 2h du matin : un compte de service interne effectuait des appels API vers un endpoint externe qui n'était pas dans notre liste d'autorisations, à une cadence cohérente avec une exfiltration de données. J'ai suivi le playbook de réponse aux incidents : contenir d'abord, puis enquêter. J'ai immédiatement révoqué les credentials du compte de service et isolé le service affecté du réseau, puis réuni l'équipe de réponse aux incidents. L'enquête a révélé qu'une dépendance dans notre pipeline de build avait été compromise dans une attaque de la chaîne d'approvisionnement et exfiltrait des variables d'environnement. Nous avons effectué un audit complet des secrets potentiellement exposés et les avons tous fait pivoter par précaution. La revue post-incident a conduit à plusieurs améliorations systémiques. Le délai de la détection à la confinement était de 22 minutes.

J'ai trouvé une vulnérabilité de type SSRF (Server-Side Request Forgery) dans un outil d'administration interne. L'équipe d'ingénierie l'a évaluée comme de faible priorité car l'outil était uniquement interne et nécessitait une connexion. Mon analyse a montré que le SSRF était exploitable pour atteindre l'endpoint de métadonnées d'instance AWS, ce qui permettrait à un attaquant disposant d'un accès interne d'obtenir des credentials IAM et d'escalader vers un accès complet au compte AWS. J'ai préparé une note d'une page avec une démonstration de preuve de concept dans un environnement de staging et une chaîne d'attaque claire : d'un email de phishing vers un employé jusqu'à l'accès aux données S3. Rendre le chemin d'attaque complet concret a déplacé la conversation de "est-ce théoriquement possible ?" vers "à quelle vitesse pouvons-nous corriger cela ?"

J'ai mené l'implémentation d'un programme de scan de secrets dans notre organisation d'ingénierie. Avant le programme, il n'y avait pas de détection systématique des secrets commis dans le contrôle de version. J'ai commencé par un scan rétrospectif de tout notre historique Git avec truffleHog, qui a révélé 47 secrets uniques commis dans 12 dépôts sur une période de trois ans. J'ai validé chaque découverte, confirmé que 31 étaient valides et potentiellement encore actifs, et coordonné leur rotation avec les équipes concernées sur deux semaines. J'ai ensuite configuré des hooks de pre-commit et une barrière CI avec GitLeaks. Six mois plus tard, la barrière CI avait bloqué 23 commits accidentels de secrets. Le programme m'a coûté environ trois semaines de travail à implémenter et fait maintenant partie permanente de notre flux de développement.

Un SIEM n'est aussi utile que la qualité de ses règles et la rapidité de son processus de réponse. Je commence par identifier les scénarios à plus haut risque que le SIEM doit détecter, basés sur le modèle de menaces : vol d'identifiants, mouvement latéral, exfiltration de données et escalade de privilèges sont les catégories principales. J'identifie ensuite les sources de logs qui permettraient d'attester chaque scénario et les ingère dans le SIEM avec une couche de normalisation des données. Pour l'ajustement des alertes, je commence par des règles de haute fidélité et faible volume plutôt que d'essayer de tout capturer immédiatement, car la fatigue d'alerte tue la qualité de réponse. J'ajuste chaque règle sur deux semaines en examinant chaque alerte pour comprendre le taux de faux positifs, puis j'ajuste les seuils jusqu'à ce que le taux de faux positifs soit inférieur à 10 %.

La gestion des vulnérabilités est un problème de priorisation, pas de scan. Chaque organisation a plus de vulnérabilités qu'elle ne peut en corriger, donc la discipline consiste à décider quoi corriger en premier et quoi accepter comme risque. Mon approche commence par un scan continu avec un scanner basé sur des agents authentifiés, combiné à une analyse de la composition logicielle pour les dépendances d'applications. Je ne traite pas les scores CVSS seuls comme signal de priorité : une vulnérabilité CVSS critique sur un système isolé sans accès externe est de priorité inférieure à une vulnérabilité CVSS élevée sur un service de production exposé aux clients. Je calcule la priorité en combinant la sévérité, l'exploitabilité, l'exposition et la criticité de l'actif. Je communique des SLAs aux équipes d'ingénierie par niveau de risque : critique avec exploit public sur des actifs exposés à Internet obtient 48 heures ; élevé obtient 7 jours.

Les frameworks de conformité sont souvent mis en oeuvre comme un exercice de documentation séparé de la vraie pratique de sécurité, ce qui crée le pire des deux mondes : la charge sans protection. Mon approche est de construire des contrôles automatisés et attestés par des sorties système plutôt que par des attestations manuelles. Pour SOC 2 Type II, je mappe chaque exigence de contrôle à un check automatisé ou un log système qui prouve que le contrôle fonctionne, de sorte que le dossier de preuves est généré à partir d'une instrumentation existante plutôt qu'assemblé manuellement. Par exemple, les preuves de contrôle d'accès viennent des exports de politiques IAM ; les preuves de gestion des changements viennent de la piste d'audit CI/CD. J'utilise un outil GRC pour maintenir le mapping des contrôles. J'implique également les équipes d'ingénierie dans la conception des contrôles.