Abus de la gestion des exceptions

Le programme de gouvernance de la sécurité d’une entreprise technologique comprenait un processus formel de gestion des exceptions : un flux structuré pour demander, examiner et approuver les exceptions aux exigences de la base de référence de sécurité. Le processus avait été conçu avec la rigueur voulue : les exceptions exigeaient une justification métier documentée, une évaluation des risques confirmant que le risque résiduel était acceptable, une durée limitée avec revue obligatoire et une autorité d’approbation au niveau du CISO. Lors d’une revue du programme de sécurité, un analyste a examiné le registre des exceptions et y a trouvé quarante et une exceptions actives, dont trente-sept concernaient la MFA sur des comptes d’accès administratifs. La justification métier de ces trente-sept exceptions était une variante de « la mise en œuvre de la MFA sur ce système exige des travaux d’ingénierie qui n’ont pas été planifiés ». Les durées des exceptions allaient de trois à douze mois, mais quatre d’entre elles avaient été approuvées, avaient expiré, avaient été réapprouvées et en étaient à leur deuxième ou troisième cycle annuel. Le processus d’exception fonctionnait correctement : chaque exception avait une justification métier, une évaluation des risques, une durée limitée et une approbation du CISO. Les exceptions n’étaient pas utilisées pour de réelles contraintes opérationnelles. Elles servaient à reporter des travaux d’ingénierie qu’il était gênant de planifier. Le processus d’exception était devenu la voie de moindre résistance pour contourner la base de référence de sécurité.

Qu’est-ce que réellement l’abus de la gestion des exceptions ?

La gestion des exceptions est le mécanisme de gouvernance qui permet de reconnaître que certaines circonstances opérationnelles créent des contraintes réelles empêchant la mise en œuvre d’une exigence de la base de référence de sécurité, et de gérer formellement ces situations au moyen de contrôles compensatoires, d’une acceptation documentée du risque résiduel et de délais définis pour lever la contrainte ou l’accepter formellement comme une limitation permanente. Elle existe pour traiter la complexité réelle de la mise en œuvre de la sécurité : systèmes hérités aux capacités d’authentification limitées, outils gérés par des fournisseurs qui ne peuvent pas être configurés pour satisfaire chaque exigence de base, et scénarios opérationnels où une application stricte de la base de référence créerait un risque opérationnel inacceptable.

L’abus survient lorsque le processus d’exception sert non pas à traiter des contraintes réelles, mais à reporter des mises en œuvre techniquement réalisables mais gênantes pour l’organisation, lorsque la véritable raison de l’exception tient à des priorités d’ingénierie concurrentes, à un manque de ressources ou à la réticence de la direction à prioriser les travaux de mise en œuvre, plutôt qu’à une réelle contrainte technique ou opérationnelle. Une exception à la MFA sur un système d’authentification hérité dont l’architecture ne permet pas les méthodes d’authentification modernes est une exception pour contrainte réelle. Une exception à la MFA sur un système moderne dont la mise en œuvre exige un sprint d’ingénierie non planifié est une exception de report : elle utilise le processus d’exception pour contourner une exigence de base difficile à satisfaire plutôt que réellement impossible à satisfaire.

Le problème de la banalisation est ce qui transforme des abus d’exception isolés en érosion systématique de la base de référence. Lorsque plusieurs équipes constatent que le processus d’exception produit des reports approuvés pour des mises en œuvre techniquement réalisables mais gênantes, l’exception devient la voie normale pour les exigences difficiles à respecter dans les délais. Les équipes d’ingénierie apprennent que demander une exception est plus rapide que mettre en œuvre le contrôle. Le registre des exceptions se remplit de reports. La base de référence existe en tant que norme documentée. Le taux de mise en œuvre reflète les seules exigences faciles à respecter sans exception. Le processus d’exception n’a pas échoué : il a été appris et exploité.

Exceptions de report : mises en œuvre techniquement réalisables reportées au moyen du processus d’exception
Registre des exceptions rempli de reports d’ingénierie : même justification dans plusieurs exceptions
Exceptions récurrentes : mêmes exceptions réapprouvées sur plusieurs cycles sans correction
Érosion de la base de référence : baisse du pourcentage de systèmes concernés qui respectent réellement les exigences de base
Processus d’exception banalisé comme alternative à la mise en œuvre des exigences contraignantes

Pourquoi c’est important

L’abus de la gestion des exceptions compte pour la TPRM parce que les bases de référence de sécurité des fournisseurs confirmées par questionnaire peuvent s’accompagner de registres d’exceptions volumineux qui soustraient systématiquement des parties importantes de l’environnement aux exigences de base. Un fournisseur dont la base de référence exige la MFA pour tous les accès administratifs et qui compte trente-sept exceptions actives pour des reports de MFA dispose d’une base de référence qui s’applique à une partie seulement des comptes administratifs. La confirmation dans le questionnaire que la MFA est exigée par la politique est exacte. La réalité opérationnelle, c’est-à-dire le nombre de comptes administratifs effectivement protégés par MFA, peut être nettement plus restreinte.

Le schéma des exceptions récurrentes est le signal spécifique que produit l’abus des exceptions. Une exception accordée pour six mois, renouvelée, accordée à nouveau et désormais dans son troisième cycle d’approbation est de fait devenue permanente par simple répétition procédurale plutôt que par acceptation formelle. Chaque renouvellement a été approuvé dans l’attente que la mise en œuvre ait lieu au cycle suivant. Deux ou trois cycles plus tard, la mise en œuvre n’a pas eu lieu et l’exception est devenue une exclusion permanente de fait de la base de référence. Repérer les exceptions récurrentes dans le registre d’un fournisseur fait apparaître les mises en œuvre systématiquement reportées au moyen du mécanisme d’exception.

Là où la plupart des équipes se trompent

L’échec le plus constant consiste à accepter le nombre d’entrées du registre des exceptions et la qualité formelle du processus comme preuves d’une bonne gouvernance des exceptions, sans examiner les justifications ni les schémas de récurrence. Un processus d’exception bien encadré mais détourné produit la même documentation de gouvernance qu’un processus bien encadré utilisé à bon escient : la différence se trouve dans les tendances des justifications et des récurrences.

Accepter la documentation du registre des exceptions comme preuve d’une bonne gouvernance sans examiner les tendances des justifications
Exceptions récurrentes non identifiées : mêmes exceptions approuvées sur plusieurs cycles sans signalement
Justifications de report non distinguées des justifications pour contrainte réelle
Taux de couverture de la base de référence non calculé : pourcentage de systèmes concernés conformes sans exception
Suivi de la résolution des exceptions absent : les exceptions mènent-elles à une mise en œuvre ou à un renouvellement perpétuel

À quoi ressemblent les bonnes pratiques

Les programmes matures de gestion des exceptions distinguent dès leur conception les exceptions pour contrainte réelle des exceptions de report, en exigeant des niveaux de justification et un traitement différents pour chacune. Les contraintes réelles font l’objet d’une gestion appropriée à long terme. Les exceptions de report font l’objet d’un examen de plus en plus approfondi et d’une remontée obligatoire à chaque cycle de renouvellement.

Distinction par type de justification : exceptions pour contrainte réelle et exceptions de report traitées différemment
Exigences d’approbation renforcées pour les exceptions récurrentes : le deuxième renouvellement exige l’approbation de la haute direction
Taux de couverture de la base de référence suivi : pourcentage de systèmes concernés conformes sans exception
Rapport sur l’ancienneté des exceptions : comité des exceptions examinant les exceptions classées par ancienneté
Aucun renouvellement sans preuve d’avancement de la mise en œuvre : la réapprobation exige la preuve que la mise en œuvre progresse activement

Outils

GRC avec flux de gestion des exceptions : ServiceNow GRC, Archer

Les plateformes GRC dotées de flux de gestion des exceptions permettent de renforcer les exigences d’approbation des exceptions récurrentes et de produire des rapports d’ancienneté pour l’examen par le comité de gouvernance. Pour les praticiens TPRM, demander si la plateforme de gestion des exceptions du fournisseur suit la récurrence des exceptions et renforce l’approbation des renouvellements constitue une question précise de prévention des abus.

Conformité à la base de référence de sécurité : Qualys, Tenable

Les outils de conformité à la base de référence de sécurité indiquent le pourcentage de systèmes concernés qui satisfont chaque exigence de base, faisant apparaître le taux de couverture réel que les registres d’exceptions réduisent. Pour les praticiens TPRM, demander le taux de conformité à la base de référence pour les exigences de sécurité critiques (MFA, chiffrement, correctifs) plutôt que le registre des exceptions fournit l’indicateur de couverture de la mise en œuvre que le décompte des exceptions masque.

Enjeux de gouvernance

Le défi de gouvernance de la gestion des exceptions est l’incitation à approuver. L’approbation au niveau du CISO fait de chaque exception une décision à fort enjeu. Lorsqu’il faut choisir entre approuver une exception de report et bloquer un processus métier en attente de mise en œuvre, la voie de l’approbation produit des reports approuvés. Une gouvernance qui pousse vers la mise en œuvre plutôt que vers le report, en exigeant comme condition d’approbation une feuille de route de mise en œuvre avec un suivi trimestriel des jalons, transforme le processus d’exception d’un mécanisme de report en un mécanisme d’engagement de mise en œuvre.

Demander le taux de conformité à la base de référence, et non le registre des exceptions : pourcentage de systèmes conformes sans exception
Poser des questions sur l’ancienneté et la récurrence des exceptions : combien d’exceptions actives en sont à leur deuxième ou troisième cycle d’approbation
Exiger une feuille de route de mise en œuvre comme condition d’approbation des exceptions de report
Examiner les tendances des justifications d’exception : le même type de justification revient-il dans plusieurs exceptions
Demander quel pourcentage d’exceptions aboutit finalement à une mise en œuvre plutôt qu’à un renouvellement perpétuel

Si vous êtes une petite équipe

Posez deux questions à votre fournisseur le plus à risque au sujet de son registre des exceptions. Premièrement : parmi vos exceptions actives, combien ont été renouvelées au moins une fois, c’est-à-dire en sont à leur deuxième cycle d’approbation ou plus ? Deuxièmement : pour les exceptions portant spécifiquement sur la MFA, le chiffrement ou le contrôle d’accès, quelle est leur ancienneté moyenne, et quel pourcentage a une date cible de mise en œuvre définie avec des travaux d’ingénierie effectivement en cours ? Ces deux questions permettent de distinguer un registre des exceptions bien géré d’un registre devenu un mécanisme systématique de contournement de la base de référence.

Demander combien d’exceptions actives en sont à leur deuxième cycle d’approbation ou plus
Demander l’ancienneté des exceptions et les dates cibles de mise en œuvre pour les exceptions portant sur les contrôles de sécurité critiques
Demander le taux de conformité à la base de référence pour les exigences les plus critiques, et non le nombre d’entrées du registre des exceptions
Demander si des feuilles de route de mise en œuvre sont exigées pour les exceptions de report

Ce qu’il faut exiger

Demandez directement :

« Pour vos exceptions actives à votre base de référence de sécurité, en particulier aux exigences de MFA, de chiffrement ou de contrôle d’accès, quelle est leur ancienneté moyenne et combien en sont à leur deuxième cycle de renouvellement ou plus ? Et quel pourcentage des systèmes concernés par ces exigences les satisfont sans exception ? »

Preuves attendues

Répartition par ancienneté et nombre de récurrences des exceptions
Taux de conformité à la base de référence pour les exigences critiques
Feuilles de route de mise en œuvre pour les exceptions de report
Répartition des exceptions par type de justification : contrainte réelle ou report

Il faut demander à un fournisseur dont le processus d’exception est formellement encadré le taux de conformité à la base de référence que les exceptions font baisser et le nombre d’exceptions renouvelées sur plusieurs cycles d’approbation. Le processus est encadré. Les tendances révèlent s’il est utilisé à bon escient.

Comment le prouver

Registres d’examen des tendances des justifications d’exception
Suivi du taux de conformité à la base de référence
Identification des exceptions récurrentes
Exigence d’une feuille de route de mise en œuvre pour les exceptions de report

À retenir

Le processus d’exception est encadré. Chaque exception dispose d’une documentation, d’une évaluation des risques, d’une approbation du CISO et d’une durée limitée. Trente-sept des quarante et une exceptions actives concernent des mises en œuvre de la MFA qui exigent des travaux d’ingénierie non priorisés. Quatre en sont à leur deuxième ou troisième cycle d’approbation. Le processus fonctionne comme prévu. La base de référence de sécurité est systématiquement contournée par son intermédiaire. La gestion des exceptions existe pour traiter des contraintes réelles. Lorsqu’elle sert à reporter des mises en œuvre difficiles, le registre des exceptions grossit et le taux de couverture de la base de référence diminue. Suivez le taux de conformité à la base de référence, et non la qualité du registre des exceptions. Identifiez les exceptions récurrentes. Exigez une feuille de route de mise en œuvre comme condition d’approbation d’un report. L’exception est le mécanisme de gouvernance des contraintes. La mise en œuvre est l’obligation. Le processus doit pousser vers l’obligation, et non offrir une voie pour s’y soustraire.