Qu'est-ce que le principe du biais des survivants ?
Le biais des survivants est un biais cognitif entraînant une analyse tronquée ne reposant que sur les sujets connus ou ayant réussi.
L’exemple le plus parlant est celui des études d’optimisation menées sur les bombardiers par les alliés pendant la seconde guerre mondiale. Initialement, les analyses des chercheurs ne portaient que sur les bombardiers revenus de zones de combat. Les chercheurs recommandaient alors de renforcer le blindage sur les zones de l’appareil présentant les impacts les plus importants.
Le biais de ce système d’analyse a rapidement été mis en lumière. Les résultats étaient faussés car ils reposaient uniquement sur les bombardiers en état de rejoindre la base (les survivants) et négligeaient les appareils tombés au combat.
La stratégie de renforcement des appareils militaires a ainsi pris un virage à 360° en préconisant de renforcer, au contraire, les zones vierges d’impact, reconnues comme points faibles car ayant entraîné la perte des appareils disparus lorsque touchées par les tirs ennemis.
Le biais des survivants appliqué au plan de reprise d'activités du SI
Dans le cadre d’une infrastructure informatique traditionnelle, un PRA (Plan de Reprise d’Activités) peut être lourd à mettre en place, maintenir et tester. La complexité et le manque d’agilité des architectures informatiques legacy poussent les équipes IT à faire des choix dans leur stratégie de mise en place et de test d’un plan de reprise d’activités.
L’attention se dirige alors naturellement vers les services considérés comme fragiles car victimes d’incidents physiques, ou cibles d’intrusions ou de tentatives d’intrusion. Ce parti pris a souvent pour conséquence d’occulter toute une partie du système d’information considérée comme suffisamment sécurisée car jamais impactée.
Pourtant, tout comme dans le cas des bombardiers pendant la seconde guerre mondiale, cette analyse repose sur une logique erronée en ne s’appuyant que sur les incidents détectés ou connus par l’équipe IT.
Si l’on prend l’exemple des attaques de ransomwares, les logiciels malveillants peuvent rester en sommeil pendant des semaines, voire des mois au sein du système informatique avant de détecter une opportunité et de s’activer. L’intrusion reste inaperçue jusqu’à la propagation de l’attaque. Ce n’est qu’à ce moment que le point faible est identifié.
La mise en place et la stratégie de tests d’un plan de reprise d’activités ne sont donc valides que dans une démarche holistique, pragmatique et sans préjugés.
Des systèmes d'informations en constante évolution
Les systèmes d’informations évoluent à un rythme quasi-quotidien au gré des mises à jour, et évolutions des systèmes d’exploitation Windows, ou Linux, et des solution anti-virales. Il n’est pas aisé d’avoir un suivi exhaustif de ces évolutions, et de leur éventuel impact sur le PRA en place. Il est donc incontournable de tester régulièrement son PRA afin de mettre en lumière d’éventuelles inconsistances et de les corriger.
Trop souvent, les tests de PRA se limitent à basculer les machines virtuelles d’un site à l’autre, sans interruption de service. Cette solution n’est pas optimale puisqu’il est important de tester la bonne orchestration du redémarrage des différentes VM, et services. Puis, de tester le bon fonctionnement des applications.
Afin d’atteindre cet objectif, il est nécessaire d’avoir un socle technologique permettant de tester son PRA sans implication majeure sur la production, et aussi souvent que souhaité. L’idéal étant d’avoir la capacité de tester son PRA en parallèle de la production.