"L'avion est le mode de transport le plus sûr au monde"

Vous avez sûrement déjà entendu cette phrase. 
Comme le disait le professeur Arnold Barnett, qui s'est intéressé à la question :

"If you took one domestic flight a day, every day of the week, odds are you could go 36,000 years before you’d die in a plane crash"
Si vous preniez un vol intérieur par jour, chaque jour de la semaine, il vous faudrait en moyenne 36 000 ans pour mourir d'un crash

Rassurez-vous, nous n'allons pas remettre en question cette conclusion, vous pouvez toujours prendre l'avion sereinement quant à vos chances de survie. 

Mais il y a une question de terminologie derrière cette affirmation, qui amène à une confusion fréquente, notamment en cybersécurité (mais pas que). 
Dire que l'avion est un mode de transport "sûr" revient à dire qu'il n'est pas risqué. Mais il manque une précision : parle t'on des risques qu'implique un accident ou bien des risques d'avoir un accident ?

Cette subtilité peut paraître mineure au premier abord, pourtant elle est déterminante puisque les réponses aux deux nuances sont opposées.

Si on a le choix, on préfère avoir n'importe quel autre accident qu'un crash en avion

En effet, avoir un accident d'avion est très risqué, un choc à 800 km/h c'est presque 100% de chances de mourir (enfin je présume, j'ai pas regardé les chiffres). En tout cas on imagine bien que c'est plus grave qu'un choc à 130 km/h sur autoroute avec une voiture (pour le coup là les chiffres disent qu'il y a, en moyenne, "seulement" 6% des accidents de voiture qui sont mortels). De ce point de vue, un avion est plus risqué qu'une voiture, car avoir un accident d'avion est bien plus dangereux qu'avoir un accident de voiture. Si on vous donne le choix entre avoir un accident d'avion et un accident de voiture, il faut choisir l'accident de voiture.

Mais, si l'on parle maintenant des chances d'avoir un accident, c'est l'inverse. Quand vous prenez la voiture, vous avez bien plus de chances qu'un accident se produise que lorsque vous embarquez dans un avion.

Lorsque les accidents sont très graves, mais aussi très rares, ça peut être moins risqué qu'un autre truc où les accidents sont moins graves mais fréquents.
Voici un exemple chiffré pour s'en convaincre. Prenons deux technologies fictives : le laseromiltoneur et le friseur quantique. 
Un accident de laseromiltoneur est mortel dans 10% des cas. Et un accident se produit toutes les 1 000 utilisations.
Un accident de friseur quantique est motel dans 100% des cas. Et un accident se produit toutes les 10 000 000 utilisations.
On en déduit que le laseromiltoneur tuera une personne toutes les 10 000 utilisations là où le friseur quantique en tuera une toutes les 10 000 000 utilisations (donc 1000 fois moins souvent que le laseromiltoneur).

Donc on peut dire que, même si un accident de friseur quantique est plus risqué qu'un accident de laseromiltoneur (100% de chances de mourir contre 10%), l'utilisation du friseur quantique est moins risquée que celle du laseromiltoneur (1 mort sur 10 000 000 utilisations contre 1 sur 10 000).

Vous reprendrez bien un peu de pangolin ?

Cette nuance vous rappellera peut être deux notions que nous avons appris à distinguer lors de l'épidémie de COVID19 : on nous disait de ne pas confondre mortalité et létalité.

• La "létalité" c'est la probabilité de mourir quand vous avez attrapé le COVID : X % des patients atteints du COVID en sont morts ;
• La "mortalité" c'est la probabilité de mourir du COVID ... tout court (donc la probabilité de l'attraper + la probabilité d'en mourir quand on l'a attrapé) : Y % des français sont morts du COVID

Si vous avez lu attentivement les deux descriptions, vous aurez remarqué que la létalité est une sous-partie de la mortalité. Ces deux notions ne sont pas parallèles mais plutôt imbriquées : la mortalité c'est la conjonction de la létalité et de la probabilité de contracter la maladie (on parle d'"accidentalité" pour la sécurité routière par exemple).

Pour reprendre nos exemples :

• L'accident d'avion est très létal mais très peu mortel ;
• Le friseur quantique est lui aussi très létal mais peu mortel ;
• Le laseromiltoneur est peu létal mais très mortel.

"Mal nommer les choses c'est ajouter au malheur du monde" disait Camus (pas le chevalier du Verseau, l'autre)

Donc il n'est pas faux de dire que le friseur quantique est plus sûr que le laseromiltoneur tout comme ce n'est pas faux de dire que l'avion est le moyen de transport le plus sûr, si on parle de mortalité.
Vous allez me dire "Bon et bé il n'y a pas de problème alors, pourquoi on lit cet article ?". J'y viens.

Le problème c'est de savoir de quel droit décide-t-on que l'avion doit être jugé sur sa mortalité et non pas sur sa létalité ? Dans l'absolu, rien ne dit qu'il soit plus légitime de juger sur l'un ou sur l'autre des deux critères.

Par exemple, si vous dites que l'avion est le mode de transport le plus sûr du monde, vous devriez aussi dire que le nucléaire est l'énergie la plus sûre au monde. En effet, même si un accident nucléaire est quelque chose qu'on ne veut absolument pas vivre, la survenance de ces accidents est ultra rare. La mortalité du nucléaire est donc très faible (même comparée aux autres sources d'énergie).
Autre exemple, il faudrait aussi dire que l'oxygène est le gaz le plus dangereux au monde car il est notamment responsable de la Grande Oxydation qui a causé la disparition de 99% du vivant à l'époque.

En fait, la pertinence d'utiliser l'un ou l'autre des critères dépend de qui l'utilise et à quelles fins.
Par exemple, si vous venez d'attraper le COVID19, tout ce qui va vous intéresser c'est sa létalité : quelles sont les chances que vous y passiez. Si vous êtes un Etat, c'est plutôt la mortalité qui vous soucie. Vous vous en foutez un peu que la létalité soit faible si la contagiosité est telle que toute votre population l'attrape (genre si vous êtes la Chine, 1% de létalité ça vous fait quand même 14 millions de cadavres non prévus à gérer).

Donc n'importe qui peut vous dire que quelque chose est risqué ou que quelque chose est sûr, sans que vous ne sachiez s'il parle du danger de l'accident (la létalité), de la probabilité d'avoir cet accident (accidentalité) ou encore de la combinaison des deux (mortalité). Et surtout s'il a raison d'utiliser ce critère.

Les notions de "risque" ou de "sûreté" sont imprécises dans le langage courant. Mais dans le domaine professionel, ce sont des concepts très bien définis. Et c'est là qu'après cette longue introduction, on va reboucler avec la cybersécurité.
Il y a en fait, formellement, deux types de risque. Les deux sont utiles mais ne s'utilisent pas pour les mêmes fins.

"C'est pas grave si le firewall tombe, il est redondé"

Combien de fois ai-je entendu des phrases de ce type : "non, la perte des données de l'ERP n'est pas critique, elles sont sauvegardées".

En apparence tout à fait légitime, ces phrases cachent en fait une confusion fondamentale en sécurité.
Elle tient en ceci : croire que ce n'est pas grave puisque c'est protégé alors que c'est justement parce que c'est grave que c'est protégé.

Je n'ai pas trouvé de nom existant dans la littérature technique pour désigner ce biais, alors j'ai décidé de le baptiser moi-même d'après le célèbre meme du smart guy : le Roll Safe Syndrom.

A l'origine : l'analyse d'impact

Rappelons quelques notions de base de l'analyse de risque.
Formellement, on appelle "risque" la conjonction d'une vraisemblance (à quelle fréquence un incident se produit) et d'un impact (à quel point ça fait mal quand il se produit).
Pour rebondir sur l'introduction, l'impact est donc comparable à la létalité et le risque à la mortalité.
Donc un astéroïde de la taille du Texas, qui tombe sur Terre, c'est un risque moyen : fréquence très faible (grâce à Harry Stamper), impact immense. Marcher dans une déjection canine c'est aussi un risque moyen : vraisemblance moyenne, impact moyen.
Une matrice de risque ressemble donc grosso modo à ça :

Lors d'une démarche d'appréciation des risques, il y a un temps dédié à l'identification des impacts. Durant cette phase, vous faites des interviews avec les métiers et vous leur soumettez votre petite science-fiction : "si ça ça tombe, est-ce que vous allez crier et est-ce que ça va crier fort ?".
Et la subtilité, qu'on vous enseigne en analyse de risque, c'est que cette phase doit se faire sans tenir compte des mesures de sécurité en place (ça c'est plus tard). Là, vous cherchez à connaître l'impact "nu", l'impact théorique maximum (comme si l'entreprise n'avait pris aucune disposition pour s'en prémunir ou bien qu'elles avaient toutes failli).
En fait les mesures de sécurité en place seront prises en compte au moment d'estimer la vraisemblance : avoir des sauvegardes diminue la vraisemblance de subir une perte de données. Mais ça n'affecte pas vraiment l'impact d'une perte de données.
Or, ceux qui répondent ont justement le biais (que j'ai nommé Roll Safe Syndrom) de ne pas arriver à s'affranchir des mesures de sécurité (et c'est sûr que si l'analyste ne les prévient pas qu'il faut le faire, ils ne vont pas y penser naturellement) :

- Quelles sont les conséquences si vous perdez les données de l'ERP ?
- Ho ça va elles sont sauvegardées.
- OK, donc il existe une copie de ces données. Du coup : vous ne les avez pas perdues.
- Oui c'est ça.
- Mais alors, ça ne répond pas à la question "quelles sont les conséquences si vous les perdez ?"
- Ah ... donc vous demandez dans le cas où on perd même les sauvegardes ?
- Sinon on ne peut pas dire que les données sont perdues.
- Oui mais enfin il faudrait perdre en même temps l'ERP et le serveur de sauvegarde ... c'est quand même assez improbable.
- J'espère, mais on parlera de ça dans la partie "vraisemblance". Là on parle d'impact seulement.

Pour clarifier cet aspect, on peut utiliser une dénomination que certains d'entre vous ont peut être déjà entendue : risque brut contre risque net.
Cette formulation a l'avantage d'être assez transparente et de quasiment pouvoir se passer d'explication :

• Le risque brut c'est ce que vous auriez à craindre en l'absence de toute mesure de sécurité
• Le risque net c'est que vous avez à craindre compte tenu de vos mesures de sécurité en place

Ces termes ne sont malheureusement pas standards. On ne les rencontre pas directement dans l'ISO 27005 par exemple. Bien que cette norme aborde l'étape d'appréciation initiale sans tenir compte des mesures de sécurité, elle n'y consacre pas de terminologie. On y trouvera la notion de "risque résiduel" qui décrit une sorte de risque net dans le futur (lorsque le plan de traitement aura été appliqué), mais ce n'est pas équivalent.
On peut aussi tomber sur la dénomination "risque intrinsèque", dans la littérature cybersécurité, pour désigner le risque brut. Mais ce n'est pas non plus un terme consacré.
C'est dommage, car distinguer ces deux notions est très pratique.

Pourquoi on en parle

Si on reprend la phrase "C'est pas grave si le firewall tombe, il est redondé", après tout, vous pourriez être tenté de dire "Oui bon ben il parle de risque net au lieu de risque brut et alors ? Tant que c'est clair dans sa tête ça va non ?".

Et bien ... dans certains cas, ça pourrait ne pas aller.
En effet, si l'interviewé répond en parlant de risque net au lieu de risque brut, sans expliciter son raisonnement à haute voix, ça peut passer inaperçu. L'analyste n'a pas le temps de demander à l'interviewé de justifier le détail de son appréciation pour toutes les réponses. De plus, sur une structure assez grosse, il peut y avoir des dizaines d'interlocuteurs, potentiellement interrogés par des analystes différents.
C'est donc malheureusement "facile" de passer à côté de ce biais. On pourrait alors se retrouver avec une ressource critique considérée, à tort, comme d'importance minime, car les impacts ont été vus comme dérisoires.

Reprenons l'exemple de l'ERP :
Lors de l'analyse d'impact, le responsable métier se dit : "s'il y a une perte de données ? hummm non aucun problème, on a les sauvegardes". Et il répond alors "Je dirais que l'impact est minime : 1/4".
Sauf que du coup, si l'impact est minime, alors ce n'est pas un actif critique.
Si ce n'est pas un actif critique, alors il n'y a pas de raison de lui allouer du budget.
S'il n'y a plus de budget, on aura pas assez d'argent pour payer le renouvellement de la licence de la solution de sauvegarde.
S'il n'y a plus de sauvegarde, l'ERP ne sera plus protégé contre les pertes de données.
Si une perte de données se produit, ce sera la catastrophe.

Pour éviter ce genre d'écueil, pensez toujours à rappeler, lors d'une analyse d'impact, que l'on réfléchit sans tenir compte des mesures en place.

Au centre de tout ça : les mesures de sécurité

En cybersécurité, une "mesure de sécurité" désigne précisément un moyen (technique, humain, organisationnel, ...) par lequel on diminue un risque. Une mesure de sécurité peut être préventive ou palliative.
‍Préventive en diminuant la survenance d'un incident :

• Je mets en place un antispam pour diminuer la fréquence à laquelle mes utilisateurs vont recevoir une pièce jointe infectieuse
• Je mets en place des sondes de température dans le noyau de mon réacteur nucléaire pour détecter assez tôt toute augmentation anormale et pouvoir couper la réaction avant que ça ne cause un accident
• Je mets en place une tour de contrôle du trafic aérien pour diminuer la fréquence des collisions entre avions

Palliative en diminuant les conséquences d'un incident :

• Je mets en place une segmentation réseau pour restreindre la propagation d'un virus depuis un poste compromis par une pièce jointe infectieuse
• Je garde un stock de pastilles d'iode pour protéger la population en cas d'exposition aux radiations, postérieurement à un accident
• Je mets des gilets de sauvetage dans l'avion au cas où celui-ci ait dû amerrir en urgence

Protéger en amont ou en aval

Comme on dit souvent : "mieux vaut prévenir que guérir". C'est le parti pris de nombreux domaines industriels.

Par exemple, dans le domaine de la sécurité de l'aviation on se repose énormément sur des mesures préventives qui visent à réduire la survenance d'un incident : une tour de contrôle pour gérer le trafic, des pilotes très qualifiés (plutôt que vous-même qui conduisez, comme pour la voiture) et toujours en binôme au cas où l'un ait un problème, des avions capables de voler avec un seul moteur fonctionnel sur 4, etc. 
Mais il n'y a quasiment aucune mesure palliative. On ne met pas d'airbags pour essayer d'atténuer les conséquences d'un crash, on considère que s'il y a crash c'est plus ou moins trop tard pour faire quoi que ce soit.
Donc le fait que l'avion soit un mode de transport avec un risque net très faible est dû à une différence très importante entre la vraisemblance brute et nette d'un crash. Mais les différences entre impact brut et net sont assez minces. La réduction du risque se fait essentiellement par la diminution de la fréquence des accidents (comme le nucléaire).

En cybersécurité en France, il y a un petit biais qui fait que le plupart des mesures, préventives ou palliatives, affectent la vraisemblance et non l'impact. En effet, la méthode que l'on utilise (EBIOS) a la particularité de distinguer la partie "incident" de la partie "événement redouté".
Pour faire très simplifié, considérons le risque intitulé "Un pirate s'introduit dans mon système et coupe le service de messagerie". "Un pirate" c'est la menace. "s'introduit dans mon système" c'est l'incident. "coupe le service de messagerie" c'est l'événement redouté.

Dans cette approche, en fait, l'incident tout seul, je m'en fiche. Je ne crains l'incident que s'il produit des événements redoutés. Si un pirate s'introduit dans mon système et qu'il ne me fait rien de mal (il ne m'espionne pas, il ne détourne pas mes ressources, il ne coupe pas mes services, etc.) et bien je n'ai subi aucun impact. Les incidents ont une vraisemblance mais n'ont pas directement d'impact. On ne regarde les impacts qu'au niveau des événements redoutés que les incidents produisent.
Avec cette approche, la plupart des mesures de sécurité qu'on peut imaginer touchent, de fait, à la partie vraisemblance. Si je redonde mon serveur de messagerie (c'est à dire que je mets un clone qui peut prendre le relai immédiatement), je vais en fait diminuer la capacité de l'incident "un pirate s'introduit dans mon système" à causer l'événement redouté "coupe le service de messagerie". En effet, si le pirate flingue un serveur de messagerie, il en reste un autre. Donc le service de messagerie est toujours assuré.
Et par contre si le pirate réussit à flinguer les deux serveurs de messagerie, il cause l'événément redouté (la coupure du service) et là on se retrouve avec les mêmes impacts qu'avant. Ce qui a diminué c'est la vraisemblance de couper ce service, car il faut maintenant que le pirate saccage deux serveurs au lieu d'un seul, mais l'impact n'a pas bougé.

On peut mettre des mesures préventives ou palliatives (vis-à-vis d'un incident) mais ça diminue quasiment toujours la partie vraisemblance du risque. Donc, même s'il y a bien un écart, à la fin, entre risque brut et net, l'impact brut est quasiment égal à l'impact net.

Tous les risques faibles ne se valent pas

La distinction risque brut/net permet, par exemple, de soulever un problème trop souvent ignoré : la défaillance des mesures de sécurité.

En effet, vous pouvez avoir deux technologies qui ont un risque net faible (par exemple les panneaux solaires et le nucléaire), mais l'une d'elles a un risque brut très conséquent (je vous laisse deviner laquelle).
Elles ne sont alors pas exactement équivalentes. Une technologie avec un risque brut faible a un avantage : elle n'est pas dépendante de l'infaillibilité des mesures de sécurité : elle est peu risquée dans tous les cas.
Une technologie avec un risque net faible mais un risque brut initialement très fort, nécessite des mesures de sécurité très fiables. 

Où commencent les mesures de sécurité ?

Une difficulté vient ternir l'aspect très élégant de tout ce concept : définir ce qui relève de la mesure de sécurité, et de la fonction "normale", est parfois difficile.

Par exemple dans une voiture, les freins permettent d'arrêter le véhicule en cas de surprise (piéton qui traverse, virage serré, arrêt en côte, ...).
Mais c'est aussi une fonction de la voiture : ça permet de s'arrêter quand on a fini notre trajet. Est-ce donc avant tout un mécanisme de sécurité ou une fonction du véhicule ?

Ajouter de la sauvegarde est, au sens strict, une mesure de sécurité qui permet de se protéger des pertes de données. 
Mais dans la plupart des entreprises, c'est souvent perçu comme une "fonction" du SI : permettre de retrouver une version ancienne d'un fichier en cas de besoin. Presque plus personne ne s'imagine avoir un serveur de fichiers sans mécanisme de sauvegarde.
C'est pour cette raison, notamment, que l'on peut être tenté de répondre : "ce n'est pas grave si on perd les données de l'ERP, elles sont sauvegardées", car beaucoup voient la sauvegarde comme une fonction normale du SI.

Et la distinction entre fonction et mesure de sécurité tend à devenir encore plus floue avec l'avènement du "security by design". En effet, dans l'ancien monde où on incluait la sécurité seulement deux ans après la livraison du projet, quand il a déjà été piraté 4 fois, il était facile de distinguer les mesures de sécurité des fonctions : les mesures de sécurité c'était ce qu'on rajoutait après.
Heureusement, de plus en plus, on prévoit la partie sécurité dès l'étape de conception. Mais du coup, de nombreuses mesures de sécurité peuvent être multi-usages et aussi servir fonctionnellement le projet.
Par exemple, quitte à développer un module de vérification d'intégrité pour les mises à jour d'une solution logicielle, on réutilise ce même module pour permettre à l'utilisateur de localiser les doublons dans ses fichiers.

Comment donc doit-on juger ce qui rentre dans le risque brut ou le risque net ? 
Et bien il n'y a malheureusement pas de réponse déterministe. Il faut faire preuve de discernement au regard de l'état de l'art de l'exploitation des SI. Distinguer les "must have" des "nice-to-have".
Par exemple, mettre un mot de passe est, initialement, une mesure de sécurité. Mais aujourd'hui tous les systèmes marchent avec un mot de passe, on peut donc considérer que c'est une fonction basique, un must have. Dans l'analyse du risque brut, on prendra donc en compte la présence d'un mot de passe.
Ajouter une authentification multi-facteur, par contre, n'est pas une pratique universellement adoptée, c'est un nice-to-have. Ce sera donc considéré comme une mesure de sécurité et exclu du risque brut.

En fait, un must have est une mesure tellement universellement adoptée, que ne pas l'avoir est considéré comme une vulnérabilité. En bon français, on parlera de mesure obligatoire.
Un nice-to-have est une mesure bonne à adopter, mais optionnelle. En bon français, on parlerait de mesure surérogatoire.

Toutes les mesures de réduction du risque n'ont pas le même ROI

D'un domaine à l'autre, il y a de grandes disparités dans le positionnement le plus rentable des mesures de sécurité. Ça vous semble peut être rien de dire ça, mais ça signifie que l'expertise en gestion du risque n'est pas facilement transposable entre des domaines industriels différents. Il n'y a pas de "formule" qui marche tout le temps.

Quand quelqu'un vous dit qu'il va s'occuper d'un risque en mettant en place une mesure, il ne faut pas automatiquement considérer que c'est une bonne décision. On pourrait se dire "oui ben c'est toujours ça de pris, ça va diminuer le risque". 
Sauf qu'on ne peut pas prendre toutes les mesures, tout de suite. Elles ont un coût, un temps de mise en place, etc. Il faut arbitrer. Les mesures doivent être prises par ordre décroissant de rentabilité : d'abord les mesures simples et pas chères qui diminuent fortement le risque. Ensuite les mesures efficaces mais plus chères et plus complexes. Puis les mesures simples mais moins efficaces, etc.

Donc quelqu'un qui met en place une mesure qui attenue le risque de 10%, à la place d'une autre mesure qui l'aurait atténué de 30% (à coût comparable), dessert finalement la sécurité. En effet, en ayant dépensé du budget pour cette mesure, il retarde le moment où l'on pourra mettre en place la mesure qui réduit de 30%. Donc il fait perdurer un risque non nécessaire.
Pour prendre un exemple, aérer les pièces et nettoyer les patients est une mesure simple, économe, et avec un bien meilleur retour sur investissement que de miser, à posteriori, sur le traitement des patients surinfectés. Bon et bien si vous connaissez l'histoire de Florence Nightingale, vous savez que ce n'est pas dans cet ordre qu'on a priorisé les mesures au XIXe siècle.

Conclusion

Ce petit voyage au pays de l'analyse de risque était une occasion de vous faire conceptualiser précisément des choses qui étaient peut être seulement des intuitions dans votre esprit :

• Il y a deux risques : le risque brut (à quel point quelque chose est dangereux intrinsèquement) et le risque net (à quel point cette chose demeure dangereuse compte tenu des mesures de sécurité pour s'en protéger). On ne doit pas comparer le risque net de quelque chose avec le risque brut d'une autre chose.
• Identifier les éléments critiques et prioritaires d'un système demande de réfléchir avec le risque brut. Comparer la sureté de plusieurs technologies demande de réfléchir avec le risque net.
• Un risque c'est la conjonction de la vraisemblance d'un incident et de son impact. Lutter contre un risque c'est donc poser des mesures préventives (diminuer la survenance) et/ou palliatives (diminuer les impacts). Suivant le domaine, les mesures préventives et palliatives ne sont pas forcément aussi rentables.