Socle
Deux façons de voir l'erreur s'opposent. L'approche centrée sur la personne cherche un coupable ; l'approche systémique considère l'erreur comme normale et demande à l'organisation de prévoir des défenses successives, comme des tranches de fromage suisse dont les trous ne doivent pas s'aligner (Reason, 2000).
Toutes les erreurs ne se ressemblent pas. Les ratés et les oublis surviennent dans des gestes routiniers ; les fautes viennent d'un mauvais raisonnement ; les violations sont des écarts volontaires, souvent pour gagner du temps (Reason, 1990). Chacune appelle une parade différente : rappels et vérifications, formation, ou règles plus simples.
En sécurité informatique, les règles qui gênent le travail sont contournées (Adams et Sasse, 1999) : chacun dispose d'un budget de conformité limité, que des exigences trop nombreuses épuisent (Beautement et coll., 2008). Une procédure qui résiste à l'erreur demande peu d'effort, s'insère dans le travail et fait de chacun un capteur qui signale plutôt qu'un maillon faible.
Blue team : défense
Signaux : recherche d'un coupable après chaque incident ; règles contournées de façon répétée ; procédures longues sur des gestes fréquents ; incidents évités de justesse jamais rapportés.
Contre-mesures : analyser les incidents sans chercher de coupable ; recenser les contournements et en comprendre la raison ; ajouter des défenses indépendantes plutôt qu'une seule règle stricte ; simplifier les gestes fréquents ; encourager le signalement des incidents évités de justesse.
Red team : simulation encadrée
Hypothèse testée : une procédure de vérification simplifiée est-elle davantage appliquée, dans un exercice fictif, qu'une procédure complète mais longue ?
Indicateur : taux d'application de la procédure simplifiée et de la procédure complète, et nombre de contournements déclarés pour chacune.
Cadre : Exercice fictif, participants informés et consentants, indicateurs agrégés, débriefing, aucun individu désigné, aucun résultat publié pour un groupe de moins de 10 personnes.
Pistes originales
- Cartographier les tranches de défense d'un circuit de paiement.
- Mesurer le temps que chaque règle de sécurité coûte aux équipes.
Techniques DIMA associées
Fiche de conception : aucune technique DIMA. Rapprochement proposé, à valider. Voir le tableau complet.
Qui est plus sensible, ce qui protège
Plus sensibles
- Organisations qui cherchent un coupable plausible
Les erreurs y sont cachées, donc jamais corrigées. - Équipes chargées de règles nombreuses documenté
Le budget de conformité s'épuise et les contournements se multiplient (Beautement et coll., 2008).
Ce qui protège
- Organisations qui analysent les incidents sans blâme plausible
Les incidents évités de justesse remontent et les défenses s'améliorent.
À lire pour se prémunir : repérer les situations où l'on est plus exposé, et y renforcer ses défenses. Tendances de groupe, jamais un jugement sur une personne : un diagnostic ne dit pas qu'une personne est manipulable. Usage légitime : adapter les formations et les procédures, protéger.
Références
- Reason, J. (2000). Human error: Models and management. BMJ, 320(7237), 768–770. lien vérifiée
- Reason, J. (1990). Human error. Cambridge University Press. vérifiée
- Adams, A., & Sasse, M. A. (1999). Users are not the enemy. Communications of the ACM, 42(12), 40–46. lien vérifiée
- Beautement, A., Sasse, M. A., & Wonham, M. (2008). The compliance budget: Managing security behaviour in organisations. Proceedings of the 2008 New Security Paradigms Workshop, 47–58. lien vérifiée
« Vérifiée » : titre, auteurs, année et support confirmés en ligne. « À contrôler » : la référence existe mais un détail (pages, éditeur, lien) n'a pas été relu à la source. Toutes les références.
Niveau de preuve : modèles bien établis en sécurité industrielle et médicale ; leur transposition à la sécurité informatique est documentée. Fiche liée à Réactance et à Contrôle exécutif.
Contribuer à cette fiche
Une source, un cas public, une correction ? Chaque proposition est relue avant publication. Précisez le titre de la fiche : « Facteurs humains : concevoir pour l'erreur plutôt que contre l'utilisateur ».