La direction veut acheter un seul produit « nouvelle génération » pour « régler la sécurité ». Comment réagissez-vous en tant qu'architecte ?
Réponse courte
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.
L'expression « un seul produit pour régler la sécurité » est un signal d'alarme. La sécurité n'est pas un produit que l'on installe ; c'est une propriété que l'on conçoit à travers les personnes, les processus et de nombreux contrôles. Le rôle de l'architecte est de réorienter l'enthousiasme — et le budget — vers une réduction mesurable du risque.
Pourquoi la défense en profondeur l'emporte
Tout contrôle finit par échouer : un éditeur a une faille zero-day, une règle est mal configurée, un utilisateur est hameçonné, un correctif tarde. La défense en profondeur présuppose l'échec et superpose des contrôles indépendants et redondants, de sorte que lorsque l'un cède, un autre tient encore. Identité (MFA, accès conditionnel), réseau (segmentation, filtrage sortant), poste de travail (EDR), données (chiffrement, DLP) et détection/réponse (journalisation, SIEM, réponse à incident) interceptent chacun des modes de défaillance différents.
La bonne réponse n'est pas « non », mais « plaçons cette dépense là où elle comble une vraie lacune ». Confrontez la proposition à votre cartographie des contrôles et à votre modèle de menace : renforce-t-elle une couche faible ou duplique-t-elle une couverture existante ?
Pourquoi les mauvaises réponses sont fausses
« L'acheter — un seul produit solide est plus simple » est précisément l'instinct de direction qu'un architecte faible validerait. La simplicité séduit, mais un outil unique devient un point unique de défaillance : une fois contourné ou compromis, il n'y a rien derrière. « Remplacer tous les contrôles existants » est pire — cela arrache une couverture fonctionnelle pour courir après un seul éditeur, réduisant la surface défensive et créant une dépendance fournisseur. « Refuser de dépenser quoi que ce soit » surcorrige : il existe peut-être une vraie lacune que le budget devrait financer.
Ce que sonde l'examinateur
Il veut voir que vous savez repousser la pensée magique sans être un obstacle. Un bon architecte traduit un vague « régler la sécurité » en décision de portefeuille : identifier les lacunes les plus risquées, justifier la dépense par la réduction du risque, préserver les contrôles complémentaires et éviter à la fois les points uniques de défaillance et la prolifération incontrôlée d'outils. La leçon, c'est le jugement — la sécurité est en couches et continue, jamais un achat ponctuel.
Questions de suivi probables
- Comment décideriez-vous où ce budget réduit le plus le risque ?
- Donnez un exemple où deux contrôles redondants vous ont sauvé quand l'un a échoué.
- Comment éviter que la défense en profondeur ne tourne à la prolifération d'outils redondants et ingérables ?