La sécurité informatique n’existe pas. Ou n’existe plus. Il fut un temps (lointain) où il était possible de rendre un système informatique à peu près sûr, mais ce temps-là a disparu, au gré de la complexification exponentielle de nos systèmes.

Quand on fait de la sûreté des systèmes (au sens large, pas seulement informatique, la sûreté est l’assurance qu’un système fait correctement ce qu’il doit faire, ce qui implique aussi de le faire en toute sécurité), on nous apprend très vite que la fiabilité globale d’un système est égale à celle du composant le plus faible : lorsque, dans une chaîne, un des maillons se brise, la chaîne ne remplit plus son rôle.

Tout au plus peut-on réutiliser les petits bouts encore intacts pour certains usages, mais certainement pas pour l’usage initial. Imaginez une chaîne servant à fermer une porte ou un grillage avec un cadenas de haute qualité. Si la chaîne se brise, et même si le cadenas est intact, la porte pourra être ouverte.

L’informatique contemporaine est un infâme « accumoncellement » de chaînes de plus en plus longues, composées de maillons de plus en plus fragiles, puisqu’étant eux-mêmes des chaînes complexes, etc. Au risque de passer pour un vieux con (je regrette le temps où on pouvait me traiter de jeune con), l’équivalent des premiers systèmes d’exploitation pouvaient tenir en quelques kilo-octets (si, si) et donc pouvaient quasiment être validés formellement (le Graal en sûreté informatique).

Comptez les lignes de codes pour Windows ou Linux : on navigue désormais sur des dizaines de millions de lignes. Pour un attaquant, il suffit d’une erreur, alors que le défenseur quant à lui n’a tout simplement pas droit à l’erreur : cette loi n’est encore une fois pas spécifique à l’informatique, mais la complexité croissante ne confine guère à l’optimisme.

De quoi en pousser certains à la technophobie pour lutter contre cette complexification à outrance... Oui, ça fait toujours bizarre d’entendre un spécialiste informatique dire qu’il est technophobe, n’est-ce pas Ferd ?

Plus sérieusement, faute de pouvoir prendre des mesures coercitives, douloureuses et autoritaires, il faut faire avec. Et c’est bien là tout le sujet : on ne sécurise pas un système informatique (au sens où on le rend sûr et inattaquable), car ça devient impossible. Non, on gère les risques liés à l’utilisation des systèmes informatiques.

Par ailleurs, le crime suit l’usage : plus l’informatique sert à des activités importantes ou ayant de la valeur, plus cela va intéresser les petits malins et les grands criminels. Nous voilà donc avec un cocktail explosif : des menaces à profusion (un monde plein de malfaisants) et des systèmes hypercomplexes (présentant des vulnérabilités).

Un soupçon d’ISO 27005 et de vocabulaire

L’ISO 27005 est une norme internationale qui fournit des lignes directrices et un cadre pour la gestion des risques liés à la sécurité de l’information. Il ne s’agit pas d’une méthode à proprement parler, mais ça fixe les bases et les principaux mécanismes que doivent avoir une bonne méthode de gestion des risques. La méthode EBIOS Risk Manager, promue par l’ANSSI, est compatible avec l’ISO 27005 (et heureusement).

Le vocabulaire aussi à son importance. Être clair permet de se faire comprendre plus facilement, et de ne pas mélanger les notions.

Une vulnérabilité est une faiblesse, un défaut, une anomalie dans un dispositif informatique (n’importe lequel : un ordinateur, un routeur, un programme applicatif, un OS, un driver, etc.) qui peut permettre à un méchant d’accomplir une action à son profit.

Un exploit (en français : une exploitation) est le mode opératoire pour utiliser cette vulnérabilité (par exemple injecter du code spécialement formé pour profiter de la vulnérabilité). Cette exploitation peut être plus ou moins complexe.

Une attaque a lieu quand un acteur (une source de menace) met en œuvre ce mode opératoire. Cette attaque, si elle réussit, impactera la cible (ça fera des dégâts).

Un impact peut être financier, opérationnel, juridique, de réputation (le fameux risque d’image).

Comment estimer le risque ?

Deux facteurs concourent à l’évaluation de l’importance d’un risque : d’une part les impacts si le sinistre (l’attaque) survient, et d’un autre côté sa probabilité d’occurrence. Expliquons : imaginons un entrepôt de stockage (de n’importe quoi, meubles, voitures, etc.). L’entrepôt et ce qu’il contient ont de la valeur. Si ça brûle (entièrement), l’impact sera cette valeur. Heureusement un entrepôt ne brûle pas tous les jours !

Les assurances ont des statistiques là-dessus, depuis très longtemps : on sait qu’un immeuble de ce type brûle une fois tous les vingt ans, par exemple. Donc si une entreprise utilise un tel entrepôt durant vingt ans, il faut qu’elle s’attende à avoir un incendie, et donc à perdre tout ce qu’il y a dedans.

En gestion de risque, on dit : risque = impact x probabilité. Sur un an, la probabilité de survenue est de 5 %, le risque annuel sera donc de 5 % de la valeur de l’entrepôt. Par contre, sur vingt ans, le risque est de 100 % !

Comment on gère le risque, alors ?

Facile (à dire) ! Selon l’ISO 27005, il n’y a que 4 façons de traiter le risque :

• • l’accepter ;

• • le réduire ;

• • le transférer ;

• • le refuser.

Sans rentrer dans les détails d’une véritable analyse de risque, on va expliciter un peu ces options. Accepter, cela revient à dire : OK, j’accepte le fait que tous les vingt ans, je perde mon entrepôt. C’est la dure loi des statistiques. Refuser, c’est dire : j’arrête purement et simplement, je ne peux pas supporter de voir mes Porsche, Ferrari et autres brûler ne fût-ce qu’une seule fois. C’est une option radicale, mais possible et compréhensible dans certains cas, surtout quand il n’y a pas de solution pour réduire le risque.

Pour réduire un risque, rappelez-vous la formule de calcul, qui est une multiplication. Pour réduire le résultat, on peut tenter de jouer sur l’un des deux facteurs. Réduire l’impact est souvent difficile sans changer l’activité elle-même : on peut vendre des voitures bas de gamme pour réduire la valeur du stock, mais le chiffre d'affaires suivra.

Ajouter des cloisons anti-feu, des systèmes de détection et de prévention réduira la probabilité de survenue mais aussi l’impact (en empêchant que l’ensemble du bâtiment soit détruit, et en limitant l’impact à une partie). L’incendie reste un cas particulier, pas forcément transposable en informatique, où on pourra plus facilement jouer sur la probabilité que sur l’impact.

Le transfert consiste à refiler le bébé à quelqu’un d’autre : un assureur, la plupart du temps. Vous payez une cotisation, il vous rembourse quand le sinistre survient. Comment est calculée la prime d’assurance ? Excellente question.

En gros c’est... l’équivalent du risque que vous voulez assurer. Si vous voulez assurer votre entrepôt et son contenu, et qu’il a une probabilité de brûler une fois tous les vingt ans, vous paierez 5 % de cette valeur tous les ans (ou un peu plus, les assureurs ne sont pas des philanthropes, ils ont des frais internes). Et pour réduire la prime, il faut donc... réduire le risque. Plus vous avez de protections anti-incendie, moins votre prime sera élevée.

Je précise : nous restons dans une démonstration purement pédagogique, la réalité est toujours plus subtile.

Revenons à l’informatique

Dans ce domaine, il y a plusieurs difficultés. D’abord, côté statistiques et prévisions, on est loin d’avoir la même précision que les autres risques types habitation ou voiture ! On manque cruellement de recul, et en plus, le contexte évolue beaucoup plus rapidement.

Ensuite, le nombre d’actifs à protéger (et donc les risques associés) sont immenses ! Et vous avez deux grandes options : soit rester à un niveau très macro (très haut niveau), avec le risque de perdre en efficacité, soit gérer les risques réels, mais alors il faut plonger dans la nébuleuse de vos applications, de vos fournisseurs, de votre IT. Et on ne protège bien que ce qu’on connaît, en informatique le shadow IT réserve bien des surprises...

Pour conclure

En sécurité, tout évolue rapidement, plus vite que l’IT elle-même, et il faut en permanence suivre la cadence, pour comprendre l’IT, le métier, la production et même les criminels !

La sécurité informatique revient en réalité à gérer des risques liés à l’utilisation de l’IT. Gérer, c’est rendre le risque suffisamment faible pour être acceptable par le propriétaire. Et le propriétaire n’est ni le service informatique, ni la SSI (Sécurité du SI) : c’est le métier, le business, le taulier, c’est celui qui possède qui décide.

Le spécialiste de SSI ne fait qu’analyser et conseiller : il a le devoir d’éclairer son métier (le business) sur les risques existants et les moyens de les gérer, mais à la fin c’est le métier qui gagne et qui décide. Pour son entrepôt de voiture. C’est lui qui, in fine, décide s’il faut prendre une assurance, ajouter des extincteurs, accepter la situation ou changer de métier. Aujourd’hui, la question n’est même plus de savoir si on va être piraté, ni même quand, mais combien de fois.

Vous pensiez vous en tirer aussi facilement

Quant au marché de la sécurité, il est florissant. Malheur à celui qui ne rentre pas dans une case et qui n’a pas son sigle :

SASE (Secure Access Service Edge), SSPM (SaaS Security Posture Management), SIEM (Security Information and Event Management), SOC (Security Operations Center), MSSP (Managed Security Service Provider), EDR (Endpoint Detection and Response), XDR (Extended Detection and Response), NDR (Network Detection and Response), NAC (Network Access Control), IDS (Intrusion Detection System), IPS (Intrusion Prevention System), DLP (Data Loss Prevention), CASB (Cloud Access Security Broker), IAM (Identity and Access Management), PAM (Privileged Access Management), MFA (Multi-Factor Authentication), NSPM (Network Security Policy Management), UEBA (User and Entity Behavior Analytics), WAF (Web Application Firewall), NGFW (Next-Generation Firewall), APT (Advanced Persistent Threat), VPN (Virtual Private Network), SSL/TLS (Secure Sockets Layer / Transport Layer Security), PKI (Public Key Infrastructure), FIM (File Integrity Monitoring), RBA (Risk-Based Authentication), j’en passe et des meilleures.

C’est à croire que si un éditeur n’invente pas de sigle, il n’existe pas. Et je ne parle pas d’intelligence artificielle, dont l’absence semble éliminatoire dans l’esprit des équipes de marketing.

Pourtant, en sécurité, la complexité est un ennemi, mais l’obscurantisme est une aussi arme de vente et les approximations sont des techniques d’évitement classiques dans les discussions où on tente de creuser pour atteindre les vrais enjeux et les vrais problèmes.

En un mot, la sécurité informatique est vraiment un domaine où il faut savoir garder son sang-froid et savoir prendre suffisamment de recul et de hauteur, mais la pression monte au fil du temps et sous forme de menaces dont l’évolution est difficile à prédire.