Un énorme retard en matière de sécurité ? Le vrai problème est peut-être de savoir à qui appartiennent les correctifs, et non pas l’équipe de sécurité qui les suit.
Les équipes de cybersécurité devraient être responsables de la surveillance des risques, plutôt que de l’exécution de chaque mesure corrective. Attribuer aux équipes de sécurité les tâches de recherche, de priorisation, d’attribution, de mise en œuvre, de suivi et de validation de chaque mesure corrective ne favorise pas la responsabilisation. Au lieu de cela, il en résulte un référentiel organisationnel pour les problèmes non résolus.
Un modèle plus efficace distingue clairement les rôles : la sécurité joue le rôle de superviseur, tandis que la technologie et les opérations commerciales exécutent les mesures correctives. La sécurité doit tenir à jour l’inventaire des risques faisant autorité, déterminer les priorités, établir des normes de remédiation, faire remonter les engagements manqués et vérifier la clôture. Les propriétaires de l’infrastructure, de l’environnement cloud, de l’application, de la plateforme d’identité ou du processus métier concernés sont responsables de la mise en œuvre des correctifs. Les dirigeants sont chargés de résoudre les conflits de ressources et d’accepter explicitement les risques auxquels l’organisation choisit de ne pas remédier.
Cette distinction est importante, car elle détermine si un programme de gestion des vulnérabilités réduit efficacement les risques ou génère simplement des tickets de remédiation.
Un retard croissant indique un échec dans le modèle opérationnel
Les équipes de sécurité deviennent souvent les propriétaires par défaut de tout problème qualifié de problème de sécurité. Par exemple, lorsqu’un scanner identifie un package obsolète, la sécurité est censée corriger le serveur. Si une plateforme de sécurité cloud détecte un compartiment de stockage exposé, la sécurité est chargée de reconcevoir le déploiement. De même, lorsqu’un audit révèle des privilèges excessifs dans une application métier, la sécurité doit négocier les modifications d’accès avec le service responsable du flux de travail.
Cette dynamique se produit parce que la découverte est très visible, alors que la remédiation est souvent peu pratique. Lorsque l’équipe de sécurité produit un rapport, l’organisation peut supposer que l’équipe est également responsable de la mise en œuvre des solutions. Au fil du temps, les responsables des infrastructures, de l’ingénierie et des entreprises s’attendent à ce que la sécurité émette des tickets, fournisse des instructions, planifie des réunions, surveille les délais, demande des exceptions et communique les retards aux dirigeants. En conséquence, le véritable propriétaire du système devient un participant à un processus qui aurait dû relever de sa responsabilité principale.
Le retard qui en résulte est souvent attribué à l’équipe de sécurité, car c’est elle qui gère le tableau de bord. Cependant, le tableau de bord révèle simplement un échec organisationnel plus large : la propriété de l’actif n’a jamais été attribuée, le travail de remédiation n’a pas été intégré à la capacité opérationnelle et la direction n’a pas établi d’autorité décisionnelle claire quant au moment où la fiabilité, la livraison du produit, les engagements clients ou la dette technique devraient être relégués au second plan au profit de la réduction des risques.
Le Cybersecurity Framework 2.0 du NIST met l’accent sur la gouvernance, la priorisation et la communication des risques de cybersécurité dans toute l’organisation. Il n’est pas recommandé que la fonction de sécurité exécute personnellement chaque mesure corrective. De même, les directives de gestion des correctifs d’entreprise du NIST décrivent l’application de correctifs comme une maintenance préventive et un coût commercial standard, plutôt que comme une tâche spécialisée effectuée uniquement par l’équipe de sécurité.
Un retard n’est pas simplement une compilation de faiblesses techniques ; il représente un enregistrement de décisions organisationnelles non résolues. Chaque élément vieillissant reflète des questions sans réponse, telles que : à qui appartient le système ? Qui a le pouvoir de mettre en œuvre les changements ? Quels impacts business doivent être pris en compte ? Quelle capacité est disponible ? Qui est autorisé à accepter le risque restant ?
La sécurité est responsable de la tenue à jour de l’enregistrement des risques, tandis que les propriétaires du système sont responsables de l’exécution des mesures correctives.
Le moyen le plus efficace de préserver la responsabilité est de définir les responsabilités avant l’identification de nouvelles découvertes.
La sécurité doit détenir l’inventaire faisant autorité des risques connus. Cela comprend la validation des résultats, la suppression des doublons et des faux positifs, la connexion des faiblesses techniques aux actifs et services commerciaux concernés, l’attribution d’une priorité basée sur les risques, la définition de preuves de remédiation minimales, l’escalade des éléments en retard et la vérification indépendante de la clôture. La sécurité doit également identifier des modèles. Dix erreurs de configuration cloud presque identiques ne sont pas dix tickets sans rapport ; ils témoignent d’un non-respect des normes de déploiement, d’un manque d’automatisation ou d’un contrôle préventif faible.
La priorisation doit aller au-delà de la simple notation de la gravité. La Cybersecurity and Infrastructure Security Agency (CISA) recommande d’utiliser son catalogue de vulnérabilités exploitées connues comme entrée pour la priorisation de la gestion des vulnérabilités, car il met en évidence les vulnérabilités avec des preuves d’exploitation active. Par exemple, une vulnérabilité critique sur un actif de test isolé peut justifier une action moins urgente qu’une vulnérabilité moins bien notée, visible sur Internet, associée à un accès privilégié ou activement exploitée. Les équipes de sécurité sont les mieux placées pour faire ces distinctions grâce à leur compréhension globale des contextes de menace et de contrôle.
L’exécution des mesures correctives doit relever de la responsabilité des équipes qui possèdent la technologie ou le processus concerné. Les équipes d’infrastructure sont chargées d’appliquer les correctifs et de reconfigurer les serveurs et les points de terminaison. Les équipes de la plateforme cloud s’occupent des contrôles d’identité, de réseau, de stockage et de journalisation. Les équipes d’application mettent à jour les dépendances et repensent le code vulnérable, tandis que les propriétaires de systèmes d’entreprise approuvent les modifications de flux de travail et d’accès. Ces équipes possèdent la compréhension nécessaire des dépendances, des exigences de test, des risques de panne et des conséquences opérationnelles, ainsi que le contrôle des mécanismes d’ingénierie requis pour des solutions durables.
Les dirigeants sont propriétaires des décisions que ni les responsables de la sécurité ni les propriétaires des systèmes ne peuvent prendre. Lorsqu’un engagement de remédiation entre en conflit avec le lancement d’un produit, une obligation client, un problème de fiabilité ou une contrainte budgétaire, le problème devient une décision de gestion. Les dirigeants doivent choisir de fournir des capacités, de modifier le délai, d’approuver un contrôle compensatoire ou d’accepter le risque. Le silence n’est pas une acceptation du risque. Laisser une découverte vieillir parce que chaque équipe a un travail plus urgent est un risque non géré sans décision responsable. Ce modèle redéfinit également les mesures de performance. La sécurité doit être évaluée en fonction de la couverture, de la vitesse de validation, de la qualité de la priorisation, de la rapidité de l’escalade et de la vérification de la clôture. Les responsables des mesures correctives doivent être évalués en fonction de la réduction des risques, de l’ancienneté des découvertes hautement prioritaires, des taux de récurrence et de la proportion de travail éliminé grâce à l’automatisation ou à des modifications permanentes de la conception. Les dirigeants doivent surveiller la croissance du carnet de commandes par rapport à la capacité disponible, aux conflits de ressources non résolus, aux exceptions expirées et au volume de risques acceptés sans plan de traitement financé.
Aucune fonction organisationnelle ne devrait être tenue responsable de tâches indépendantes de sa volonté.
Les retards sont résolus grâce à une capacité accrue, et non par la mise en œuvre d’accords de niveau de service supplémentaires.
De nombreuses organisations résolvent un retard croissant en introduisant des accords de niveau de service plus stricts, exigeant par exemple que les problèmes critiques soient résolus dans un délai de 15 jours et les problèmes hautement prioritaires dans un délai de 30 jours. Même si les politiques peuvent changer et que les tableaux de bord reflètent une urgence accrue, la capacité de remédiation sous-jacente reste souvent inchangée.
Ce problème est particulièrement important lorsqu’une organisation hérite d’une dette technique importante. Des milliers de vulnérabilités héritées, de systèmes non pris en charge, de mauvaises configurations du cloud, de faiblesses d’identité et de résultats d’audit ne peuvent pas être simplement attribués aux équipes d’ingénierie déjà engagées dans les opérations en cours et les initiatives stratégiques. Une telle approche ne constitue pas un plan de remédiation viable. Il est peu probable que les équipes surchargées génèrent des capacités supplémentaires uniquement sur la base de l’importance du retard.
À une certaine échelle, les organisations devraient allouer des ressources à une équipe de remédiation temporaire dédiée à l’élimination des dettes à risque historique et à l’établissement d’une cadence opérationnelle durable. Cette équipe devrait être limitée dans le temps, financée séparément et composée de personnel possédant une expertise en matière d’infrastructure, de cloud, d’applications, d’automatisation et de gestion de programmes, leur permettant de mettre en œuvre les changements directement plutôt que de simplement coordonner les efforts. La sécurité doit conserver la responsabilité de la priorisation et de la validation indépendante, plutôt que de servir de principale main-d’œuvre de remédiation.
L’équipe de résolution temporaire doit s’attaquer à des catégories de problèmes plutôt qu’à des tickets individuels. Ses responsabilités incluent le développement de lignes de base automatisées de correctifs et de configuration, le remplacement des composants non pris en charge, la correction des modèles d’infrastructure réutilisables, la suppression des actifs abandonnés, la normalisation de la collecte de preuves et l’identification des systèmes qui nécessitent des décisions exécutives au lieu d’exceptions répétées. Les lignes directrices 2026 du NIST, qui relient les risques de cybersécurité, la gestion des risques d’entreprise et la planification des effectifs, renforcent le principe selon lequel les réponses aux risques et les décisions des effectifs doivent être coordonnées.
L’activation de cette équipe ne doit pas reposer sur un nombre arbitraire de constatations, mais plutôt sur un déséquilibre persistant entre les risques entrants et la capacité de remédiation. Les indicateurs incluent un retard en constante augmentation, des découvertes à haut risque qui dépassent les cycles de changement normaux, des faiblesses récurrentes ou des efforts de remédiation qui nécessiteraient plusieurs trimestres de capacité existante. Ces conditions fournissent aux dirigeants la preuve que les opérations standard sont insuffisantes pour restaurer le programme.
Les critères de sortie doivent être clairement définis : éliminer le retard historique à haut risque, réduire le travail restant à un niveau gérable pour les équipes standard, automatiser les correctifs récurrents, attribuer chaque actif à un propriétaire responsable et établir une cadence mesurable dans laquelle les nouveaux risques hautement prioritaires sont résolus plus rapidement qu’ils ne sont générés.
Un retard en matière de cybersécurité n’indique pas un échec de la part de l’équipe de sécurité. Cela démontre plutôt que l’organisation a séparé le pouvoir d’identifier les risques de la capacité et de la responsabilité nécessaires pour y faire face.
La sécurité doit être responsable de la surveillance, de la validation, de la priorisation, de l’escalade et de la vérification des risques. Les propriétaires de systèmes doivent mettre en œuvre des mesures correctives et les dirigeants doivent prendre des décisions stratégiques. À moins que ces responsabilités ne soient explicitement définies et dotées de ressources appropriées, l’arriéré persistera quel que soit le nombre de scanners, de tickets, de tableaux de bord ou d’accords de niveau de service introduits.
