Vous êtes dans : Accueil > Tribunes libres >

Former les utilisateurs à la sécurité des SI : et si on faisait fausse route ?

Cédric Cartau , LUNDI 26 AVRIL 2021 Soyez le premier à réagirSoyez le premier à réagir

Durant sa formation, un élève pilote d’aéronef apprend deux types de compétence : le pilotage à proprement parler, et la gestion des emmerdements qui, comme chacun sait, volent toujours en escadrille (sans mauvais jeu de mots). Il existe des statistiques précises sur le sujet, et aucun domaine n’a autant poussé l’analyse des accidents que l’aérien. Ainsi, un pilote commet en moyenne sept erreurs par heure, allant de la bêtise anodine (oublier de changer de fréquence radio) au truc beaucoup plus ennuyeux, par exemple oublier de sortir le train d’atterrissage… avant l’atterrissage (je suggère au lecteur curieux de visionner le lien ci-dessous [1], aucun blessé heureusement).

La question n’est pas tant de savoir s’il y aura des soucis pendant un vol ni si la cause en sera une erreur humaine ou la faute à pas de chance : il y aura des problèmes, et il faudra les régler. Les instructeurs et les examinateurs ont d’ailleurs un côté facétieux, aimant faire des blagues à leurs élèves pour leur apprendre à bien réagir : simulation de panne moteur au décollage, panne des volets en phase d’atterrissage (ennuyeux), panne du badin (compteur de vitesse) en plein vol (très ennuyeux), panne moteur en plein vol (un grand classique et test obligatoire à l’examen), voire des trucs plus tordus telle la manette de gaz bloquée à fond (posez-vous la question de savoir ce que vous feriez en approchant d’un péage sur l’autoroute avec votre pédale d’accélérateur bloquée à fond). Le secteur de l’aérien n’a donc pas amélioré sa propre résilience en pariant sur l’absence totale d’erreur par les pilotes (ce qui serait d’ailleurs illusoire puisque la panne moteur n’est généralement pas due à une erreur de pilotage), mais en développant la capacité des acteurs à gérer les ennuis en tout genre.

À la suite de l’attaque cyber de Dax, on a pu découvrir sur le site des DIM le témoignage[2] édifiant du Dr Anne Boudet (DIM de Dax), qui décrit par le menu ce qu’impacte pour le quotidien des agents la panne quasi totale de l’outil informatique. (Je suggère d’ailleurs au lecteur de lire, de relire et surtout de faire lire ce témoignage à sa direction générale, sa CME, sa DSI, etc. : en tant que RSSI, nous tentons régulièrement de tenir ce discours, mais manifestement il ne porte pas aussi bien que quand il provient de ceux qui ont vécu une attaque de l’intérieur.)

Ce qui frappe dans ce témoignage n’est pas tant la situation de panne terrible dans laquelle se débattent les équipes de Dax, mais surtout que les organisations ne semblent s’apercevoir de leur dépendance à un outil que lorsque ce dernier ne fonctionne plus. Ce n’est en rien une critique, c’est tout simplement le fonctionnement normal de l’être humain : nous sommes malheureusement tous logés à la même enseigne, y compris votre serviteur. Quand mon neveu (20 ans et une virgule) pétoche parce qu’il doit prendre la route en voiture et craint de se perdre alors qu’il a deux GPS embarqués (celui de la voiture et celui de son téléphone), les plus de 20 ans qui ont connu le temps que mon neveu ne peut pas connaître se tordent les zygomatiques. Mais quand à son tour votre serviteur peine à se diriger en avion avec seulement la carte et la montre (le GPS est interdit à l’examen), c’est l’examinateur qui rigole, lui qui a connu l’époque où le mot « GPS » n’existait même pas.

La stratégie qui consiste à penser que l’on peut protéger un réseau informatique et qu’il faut former les utilisateurs à cet égard est une impasse : l’entreprise doit protéger tous ses points d’entrée et toutes les zones sensibles, alors qu’il suffit à l’attaquant de n’en compromettre qu’un seul. Il faut, au contraire, développer la résilience des organisations.

On ne naît pas résilient, on le devient. Et pour le devenir on s’entraîne. Tout comme on entraîne les pilotes aux pannes moteurs, les organisations doivent s’entraîner à la panne du SI, qui est à l’attaque cyber ce que le vaccin est au virus : une accoutumance progressive de l’organisation à la menace externe. Un SI hospitalier comporte plusieurs dizaines d’applications critiques, chacune devant subir des coupures programmées au moins une fois par an, selon des durées variables (on ne coupe pas le serveur des résultats de labo pendant le même laps de temps que le système de prise de commande des repas), qui contraignent les métiers à passer en procédure dégradée afin de vérifier leurs connaissances et leur appropriation de ces dernières, le bon fonctionnement de la méthode et sa tenue dans le temps.

Bien entendu, ce n’est pas drôle, bien entendu, cette démarche enquiquine tout le monde, mais combien aurait-on de morts supplémentaires dans des incendies si jamais aucune entreprise ne faisait d’exercice d’alerte et d’évacuation ? Bien entendu, les organisations sont en flux tendu, mais en même temps si le moyen nominal est à saturation, que se passera-t-il le jour où seule la procédure dégradée, forcément moins productive, sera utilisable ? Que se serait-il passé si le dégagement du canal de Suez (moyen nominal) avait demandé six mois au lieu de dix jours, obligeant 10 % du trafic maritime mondial à emprunter une route beaucoup plus longue et coûteuse ?

Si une direction générale ne peut pas mettre des sous dans la sécurisation de son SI, elle doit a minima contraindre les organisations à pratiquer des tests réguliers de panne et de passage en mode dégradé. En commençant par elle-même : pas de PC, pas de GSM ni de messagerie pendant 72 heures. Chiche.


[1] https://www.youtube.com/watch?v=5McECUtM8fw&t=104s 

[2] http://www.departement-information-medicale.com/blog/2021/02/19/jetais-tranquille-jetais-penard/ 

sécurité, formation, dim