Quelques mythes aux logiques de la sécurité informatique

Plus je lis d’articles dans la presse pourtant dite spécialisée, plus je me convaincs que – un peu comme en politique – il y a vraiment beaucoup de charlots qui ne comprennent rien à ce qu’ils racontent, ou s’appuient sur une compréhension erronée de la réalité, ce qui revient au même. Et ceci autant chez les experts que chez les journalistes.

Il y a ainsi un certain nombre de mythes, de sujets où on rencontre des articles et des opinions (*) les plus loufoques, faux ou imbéciles (cochez la mention inutile selon l’humeur du jour). J’en ai fait une liste à la Prévert sans prétention d’exhaustivité que je vous propose de parcourir et de remettre face au bon sens, en essayant de rester abordable par tous.

La sensibilisation des dirigeants

Beaucoup de « responsables de la sécurité informatique » se plaignent ou indiquent aux nombreuses enquêtes régulières du manque de sensibilisation de leurs dirigeants au risque que représente vraiment le manque supposé de sécurité au sein des entreprises. Et dès lors, le frein que cela représente à leur activité – celles des RSSI – et à leur fonction, par exemple par manque de moyens accordés. Pourtant, je considère que, sauf rares exceptions, il n’en est rien.

J’ai eu l’occasion de rencontrer assez souvent des grands patrons, ou du moins des membres de ce que les anglo-saxons appellent la C-suite. J’ai toujours et sans exception été frappé par la vision extrêmement claire et pertinente de ces personnes le plus souvent brillantes quant au rôle et aux enjeux joués par la sécurité au sein de leur entreprise.

Certes, il est tout aussi vrai que ces cadres-sups souvent peu techniques n’ont que rarement une compréhension fine de ce qui se passe vraiment dans un système d’information et notamment du concept même de faille de sécurité. Mais il n’y a là rien que de très logique puisque c’est précisément le rôle du RSSI ou CISO que de savoir faire le lien entre les deux niveaux. Une autre façon de dire que ceux qui se plaignent parlent moins de leurs chefs que d’eux-mêmes, en fait.

Car la méprise totale de ces RSSI frustrés, c’est de ne pas avoir su comprendre que la sécurité informatique fait partie du business, de tout business, et que la seule manière de la justifier à un CFO ou CEO, c’est de lui expliquer qu’elle est ou sera construite dans les systèmes comme le business l’exige – et non comme les hackers ou la conformité l’y forcent.

Les big chiefs commettent cependant souvent une erreur sans s’en rendre compte. Celle de penser que l’évidence naturelle qui est la leur d’intégrer la sécurité au business ne se fait en fait pas aussi automatiquement lors de la mise en place et en œuvre des systèmes d’information. Ce qui crée un écart réel mais incompris, par eux-mêmes comme par les RSSI. Mais cela n’est pas un problème de sensibilisation, mais de partage de la réalité.

Relier la sécurité au risque

Un autre phantasme de beaucoup de RSSI et même hélas de certaines normes, comme l’ISO 270xx et la 27005 en particulier, c’est de veiller, mettre l’accent sur le lien entre le risque métier et le risque « sécuritaire ». Comme ancien Risk Manager moi-même, je ne dirai pas, soyons clair, qu’il est mal de veiller à ce que ces deux métiers se parlent. Là n’est pas le problème, bien au contraire.

Le problème tient à la notion même de risque, qui est fondamentalement différente en informatique par rapport à l’acception générale de ce terme dans le reste du monde. Autrement dit, lorsqu’un RSSI parle de risque, neuf fois sur dix il parle en réalité d’autre chose. Et quand bien même il parlerait réellement de risque, il ne dispose que très rarement des données lui permettant d’exprimer sa réalité opérationnelle en de tels termes. Et ainsi souvent, lors de sa communication vers la C-suite, le résultat n’est qu’un élargissement du fossé de compréhension entre les deux et voir chacune des deux parties encore plus frustrée.

La raison tient à la réalité intrinsèque du risque sécuritaire. Un risque est constitué de deux grandeurs. Un « impact », qui exprime la conséquence négative maximale que l’événement considéré pourrait provoquer sur l’entreprise, en termes financiers. Et une probabilité dudit événement, entre 0 et 1 et qu’on cherche en général à réduire à zéro.

Or la nature de l’informatique fait que ces deux concepts n’ont pas de réalité informatique. Connaître, mesurer l’impact suppose d’avoir une vision extrêmement claire de la manière dont chaque application, sous-système et autres contribue aux risques métiers. Sauf pour des entreprises de structure et processus simples, il est très rare que cela soit le cas et que le RSSI sache (au sens ait les moyens de) faire une telle estimation, autre que très grossière.

La probabilité quant à elle n’a tout simplement pas de sens. Il n’y a en sécurité que deux états, pas trois ni cent. Un système ou une application est vulnérable ou ne l’est pas. Le hacker a trouvé une faille ou pas. Le risque n’a donc de matérialité que s’il y a vulnérabilité. C’est donc binaire, 0 ou 1.

Certains tentent de s’en sortir en assimilant la probabilité à des choses comme l’idée d’une « densité de vulnérabilités », où la probabilité croîtrait avec le nombre de failles en présence. Mais la réalité, c’est qu’une seule vulnérabilité suffit pour qu’un hacker puisse pénétrer.

Sur la base de ces concepts, l’analyse des risques sert souvent à identifier des priorités d’action, celles en réponse aux risques les plus forts, le plus souvent. On voit généralement ainsi figuré le niveau de risque visé suite à ces mesures, niveaux forcément plus bas, avec une flèche entre avant et après. Neuf fois sur dix, les flèches obliquent du coin supérieur droit vers le coin inférieur gauche (du plus de risque au moins de risque).

Sauf que ce n’est presque jamais vrai. Car lorsqu’on colmate une faille, on ne change pas l’impact, on ne change que la probabilité. La flèche doit donc être verticale (ou horizontale, selon les axes). Mais pas oblique. C’est un détail ? Allez dire cela à celui qui vous finance. Combien ont des flèches obliques chez eux ?

L’analogie du maillon faible

Pour finir avec la notion de risque, on prendra l’analogie avec le maillon d’une chaîne, souvent utilisée comme illustration, par exemple sur l’enquête 2012 de Ernst & Young. Elle relève de la physique où la résistance des matériaux peut être approchée par analyse statistique. Sur une chaîne, un maillon peut rompre, mais en réalité c’est la chaîne qui rompt et il suffit de la renforcer pour régler le problème. Rien de tel en sécurité informatique. Si un maillon doit rompre, cela ne devra rien au hasard.  Et personne ne s’en apercevra.

Internet n’est pas sécurisé

On trouve assez fréquemment des articles qui croient malin de rappeler que Internet n’est pas sécurisé, c’est-à-dire que la sécurité ne fut pas prise en compte lorsque Ethernet, TCP/IP, DNS et les autres piliers mêmes du réseau furent conçus et établis. Ce n’est certes pas faux de prime abord, mais c’est en réalité montrer une incompréhension profonde de ce qui constitue la sécurité des informations.

Le sécurité ne concerne de manière profonde que les données. Internet n’a comme fonction que de transmettre des données de A à B. Et il fait cela très bien, il est assez fiable, et donc sûr d’une certaine manière, pour avoir été adopté pour cette fonction. Mais jamais Internet ne pourra sécuriser des données dont il ne sait pas si elles doivent l’être ou pas.

Il n’y a que le propriétaire des données qui peut savoir et décider du besoin de sécuriser ses données et contre quoi ou qui. Dire que le réseau n’est pas sécurisé, c’est donc ne pas comprendre la sécurité. Au mieux, c’est dire que les gens ou entreprises qui ont des données ne les sécurisent pas « suffisamment » avant de les confier au Net pour les transmettre. C’est très différent.

Je mets « suffisamment » en guillemets parce que là encore il n’y a pas de ligne absolue, et c’est souvent mal compris. On pourrait ainsi à l’inverse dire que Windows est sécurisé – Microsoft ne s’en prive pas – sous le prétexte, inverse de celui d’Internet, qu’il offre de nombreuses fonctions et paramètres pour protéger les données sous son contrôle. Quiconque a pu constater combien il est facile d’accéder à des données sous la plupart des machines Windows comprendra. Or les deux extrêmes sont tout aussi faux.

Pour que Windows soit « suffisamment » sécurisé, il est nécessaire de savoir ce qu’il y a à sécuriser et envers qui, puis configurer le système pour qu’il respecte ce qu’il est convenu d’appeler une politique ou un modèle de sécurité. Ce n’est pas garanti d’être suffisant, mais c’est déjà pas mal dans bien des cas. De la même façon, pour que le Net soit sécurisé, il faut par exemple chiffrer les données sensibles qui transitent.

Ce n’est ni à Windows ni au Net de sécuriser quoi que ce soit. Ce malentendu est d’ailleurs à mon sens la source de 90% des incompréhensions entre le management et les opérationnels, le premier ne comprenant pas que les seconds n’aient pas spontanément sécurisé les systèmes techniques selon leur vue des enjeux, vue qu’ils n’ont pas eux-mêmes spontanément exprimée sous forme de politique exploitable. Là est un des vrais enjeux.

Le rôle de l’état sur le Net

Depuis l’affaire Snowden, mais aussi un peu avant avec le virus Stuxnet, les journalistes ont repris goût à la question du rôle de l’état sur le Net  et dans les questions de sécurité en général. Il n’est pourtant pas très difficile de comprendre qu’aucun état n’a quelque légitimité que ce soit sur le Net.

Il y aurait là de quoi écrire une thèse en droit et une thèse en informatique, mais essayons de voir les arguments principaux. Tout d’abord, Internet est un monde virtuel, sans aucune réalité matérielle et où les notions  de base de droit ne sont absolument pas applicables. Il n’y a pas de juridiction car il n’y a pas de territoire et il n’y a pas de frontières pour limiter le champ de l’état. Il n’y a pas de droit car il n’y a pas de propriété – et il n’y a pas de propriété parce qu’il n’y a pas – sauf de rares cas très précis – de conflit d’accès à la ressource informatique. Il n’y a pas de cyber-guerre parce qu’il n’y a pas de victimes ni d’ailleurs de cyber-citoyens. Oui je sais, cela va à l’inverse de tout ce que dit le droit positif moderne sur la question. Mais le droit positif montre souvent plus de côtés négatifs que le simple bon sens.

Un autre angle de vue consiste à revenir à Max Weber qui nous définit l’état comme une organisation ayant le monopole de la violence sur un territoire – ladite violence étant réputée servir à assurer l’ordre. On constate simplement que sur Internet, il n’y a aucun territoire, encore moins monopolisable, il n’y a pas d’ordre à faire régner et il n’y a pas non plus de violence physique. Donc l’état n’a aucune légitimité sur le Net qui n’en a simplement pas besoin.

Je m’arrête ici sur ce sujet, car il mériterait un ouvrage. Je suis sûr d’en choquer plus d’un avec ces propos. Si vous n’êtes pas convaincus, demandez-vous si vous ne confondez pas le matériel qui constitue ce qu’il faut pour donner vie à Internet et Internet soi-même.

C’est crypté

Parmi les sujets qui touchent à l’état justement, il y a le chiffrement, la cryptographie en français plus courant. Et c’est un sacré trompe-l’œil, car la cryptographie constitue le seul véritable moyen de protéger les données en informatique lorsqu’il n’est pas possible d’assurer un contrôle d’accès logique efficace.

De ce fait, on trouve de plus en plus de crypto un peu partout, dans les échanges, les VPN, les bases de données, les systèmes d’authentification ou de signature et j’en oublie. De la même façon, on trouve de plus en plus d’outils ou produits qui offrent du chiffrement. Mais quel chiffrement ?

A de rares exceptions près, tous les algorithmes de chiffrement font l’objet d’une autorisation étatique. Pas de la part de tous les états, mais disons que tous les états acteurs sur le Net ou ayant des velléités de voir le Net mis sous contrôle ont une réglementation en matière de chiffrement. Ainsi en France, l’usage de produits est autorisé, mais inventer et utiliser sa solution à soi ne l’est pas a priori. Et l’usage de quelques algorithmes reste interdit au public.

La raison en est invariablement simple : l’état veut pouvoir déchiffrer vos messages et vos données, il veut pouvoir surveiller ce qui se passe, ce qui se dit et ce qui s’échange. Le recours au chiffrement pour protéger ses données personnelles est ainsi une vaste bouffonnerie, puisque ces messieurs peuvent lire ce qu’ils veulent.

Il n’y a donc qu’une seule solution à ce problème : protégez vos données vraiment sensible en utilisant un algorithme non autorisé par l’état, ce sont les meilleurs et les seuls qui protègent vraiment. Une amende ? C’est un prix à payer.

Le syndrome de l’antivirus

Outre les produits de chiffrement, la sécurité est aujourd’hui assurée pour la plus grosse part par des « solutions », des produits logiciels commerciaux dont l’anti-virus est celui connu par le plus grand nombre, y compris la ménagère de 50 ans. Et ces produits se veulent assurer la sécurité qui sinon serait absente de nos systèmes. Cela est faux pour une bonne part.

Constatons tout d’abord que tous les systèmes ne sont pas égaux face aux virus. Windows a toujours été une passoire noyée par les virus alors que la chose est beaucoup plus rare pour ce qui concerne Linux, Unix et MacOS. Un bon système ne devrait tout simplement pas rendre les virus possible. Et donc le concept même d’antivirus est une insulte à la sécurité informatique.

Mais on s’aperçoit vite qu’il y a bien d’autre produits de sécurité dont le besoin même est aberrant, dans la mesure où leur n’existence ne se justifie que par déficience des systèmes d’exploitation. Les systèmes d’IAM sont un autre exemple de fonction certes très générale de contrôle d’accès logique, mais qui ne s’explique que parce que les OS n’ont pas la capacité d’utiliser des comptes selon des modèles externes.

Un des problèmes de la sécurité informatique vient donc du recours à des systèmes d’exploitation qui reposent sur un modèle de la sécurité sur le Net qui remonte au temps d’avant le Net et ne permet pas de modéliser les véritables organisations des entreprises complexes mais réelles.

L’open source n’est pas sûr

Quand on voit combien les systèmes ‘commerciaux’ sont peu ou mal sécurisés et de vraies passoires dans la réalité, il est surprenant, voire amusant d’entendre régulièrement cette légende qui voudrait que les systèmes et applications dits open-sources ne sont pas assez sécurisés ou sécurisables.

En fait, les entreprises qui achètent des machines et choisissent les OS pour les faire fonctionner tiennent un raisonnement faux. Elles constatent avec justesse que les systèmes sont des passoires et cela le plus souvent parce que les éditeurs livrent des versions qui ne sont pas absolument débuggées et qui présentent donc des failles. Elles se disent ensuite, toujours avec justesse, que face à de telles circonstances, en particulier en cas de piratage, elles n’ont pas les compétences pour sécuriser « à chaud » ces systèmes.

Elles cherchent donc à pouvoir se retourner vers des spécialistes qui pourront leur assurer les meilleures compétences face à ces questions. Et elles tombent alors dans le piège tendu par les éditeurs. Ceux-ci se placent comme les meilleurs spécialistes de leur propres produits et donc les sauveurs des passoires qu’ils ont réussi à vendre auparavant.

Pourtant, un Linux est en réalité bien plus fiable et sécurisé comme sécurisable qu’un Windows bancal et poreux. Le gros avantage d’un Linux, c’est que toute la communauté travaille sans relâche pour blinder ce système. Un Linux est donc en standard bien plus robuste et bien moins perforable qu’un Windows. Alors pourquoi toujours garder Microsoft ?

Parce que, paraît-il, comme il s’agit d’un open source, on ne peut se retourner vers personne en cas de bug. Si l’entreprise est prise dans une crise à cause d’un bug Linux, aucun recours n’existe, la seule option est de faire appel à des spécialistes, mais qui ne seront pas responsables du bug.

C’est là une logique de courte vue. Parce que les Linux étant bien plus robustes que Windows, il y est proportionnellement rare de connaître des failles de sécurité. Et c’est ce qui devrait primer. Le recours à des experts reste toujours possible, il y existe un vaste marché des experts sécurité open source. Et comme l’open source ne coûte presque rien, ni le TCO ni la sécurité objective ne plaident en faveur des éditeurs. Mais leur marketing a réussi à faire peur et nous sommes dans une société où la peur prime...

Le paradigme du bastion

Avec l’arrivée d’Internet et surtout celle des firewalls, les entreprises et autres organisations ont peu à peu ouvert leurs systèmes pour profiter de l’immense potentiel offert par le concept d’entreprise étendue.  Bien sûr,  les systèmes étant rarement conçus dès l’origine pour être totalement ouverts, les firewalls ont servi d’espèce de ponts levis entre le monde extérieur sauvage et un réseau interne tout aussi chaotique mais du moins supposé à l’abris. Tout le monde sait cela.

Ce paradigme de la forteresse a connu de beaux jours, la robustesse des ponts levis aidant et les architectures à base de DMZ se sophistiquant. Les attaques elles aussi allant croissant, en nombre et peu à peu en complexité, le paradigme de la forteresse est devenu celui du bastion, ou de la défense en profondeur, où au lieu d’avoir une seule enceinte, les barrière s’enchaînent en cercles intérieurs, une peu comme Minas Tirith, forteresse superbe du Gondor.

Malheureusement, ce type de paradigme est une erreur de conception depuis le début. On le voit dans le film, Minas Tirith est plus difficile à percer et à prendre que le Gouffre de Helm qui a moins de remparts. Mais elle aurait cédé tout autant sans l’arrivée des secours. Avec la puissance des APT actuels, peu importe la défense en profondeur. Ce qui compte, c’est soit une sécurité sans faille, soit la prise de conscience que les hackers finiront par passer.

De plus, à l’intérieur de chaque enceinte, les systèmes se supposent à l’abris et plus aucune – ou rare – mesure ne vient se mettre sur le chemin des hacker ayant réussi à arriver jusque-là. Et les vols et autres dégâts sont désormais en rapport.

Bien sûr, sécuriser un système qui n’a pas été conçu pour l’être peut coûter cher, surtout a posteriori. Mais il n’y a pourtant que deux cas dans notre monde. Soit une application ou ses données sont vraiment sensibles et doivent être sécurisées. Et dans ce cas ce n’est pas Minas Tirith qu’il faut car elle ne suffira pas, mais ce sont les données elles-mêmes qu’il faut sécuriser. Soit l’enjeux est moindre voire absent, et dans ce cas pourquoi ne pas ouvrir totalement les systèmes, histoire qu’au moins on gagne sur la fluidité ?

Encore une fois, on ne peut pas raisonner en informatique avec les notions de risques du monde réel. C’est un monde binaire et les arbitrages ne peuvent eux aussi qu’être binaires.

La non-sécurité est une fatalité

Ainsi, en cumulant toutes les erreurs précédentes et bien d’autres, on en arrive avec la conviction implicite des uns et des autres qu’il n’est pas, sinon plus, possible d’assurer une véritable sécurité informatique, le sujet et les systèmes étant devenus trop complexes. Il n’en est bien sûr rien.

Il est parfaitement possible de constituer un système, sous-système ou application absolument sûr. Ou même simplement « très » sûr. Les militaires le font, en isolant leurs systèmes, par exemple. Ou en chiffrant strictement tout. Et sans dépendre en aucune façon de logiciels commerciaux farcis de failles. Il n’y a aucune difficulté. Il juste un budget.

Et il faut juste savoir ce qu’on veut. Et c’est précisément sur ce point que beaucoup d’entreprises pèchent. Comme l’histoire a fait que le paradigme du bastion s’est imposé à une époque où les hackers étaient moins forts, elles ont pris l’habitude de poser comme principe que ce qui prime, c’est la simplicité des échanges et la fluidité des communications internes comme externes.

Avec comme conséquence que très souvent, les systèmes ou données réellement sensibles, quand ils sont connus ce qui n’est pas si fréquent, sont noyés indistinctement au sein d’un réseau peu sécurisé et eux-mêmes sans sur-sécurisation particulière. Ou comme autre conséquence que les équipes des RSSI sont vues et se voient elles-mêmes, ce qui est pire, comme des empêcheurs de développer en rond. Alors que la sécurité devrait être un enjeux primaire des DSI.

Il n’y a qu’une seule issue, me semble-t-il. Il faut que les RSSI cessent de vouloir boucher les trous de leurs gruyères et avec le budget ainsi économisé, se concentrent sur la mise en place de bastions dignes de ce nom et dans lesquels la sécurité des quelques données qui le nécessitent soit réelle. Mais attention, un vrai bastion. Pas derrière un simple firewall. Derrière les deux seules mesures qui sont quasiment inviolables sans coûter une fortune : le chiffrement basé sur des algorithmes non autorisés et une authentification par empreinte digitale, disponible en standard sur de nombreux PC.

On peut aussi hacker de tels systèmes ? Certainement. Mais cela sera cher. Les données dérobées seront donc très chères. La dissuasion fonctionnera donc pour le plus gros de la foule. Pour les données hyper-sensibles, ou s’il s’agit de se protéger des chinois, la solution reste encore plus simple : ne les mettez pas sur le réseau. Non, il n’y a pas de sécurité sans risque – on reboucle…

(*) J’ai écrit un article sur Contrepoints dont la thèse est de contester la notion d’opinion politique, dans la mesure où la théorie ne laisse aucune place au doute, seul le libéralisme est humaniste et viable. C’est un peu la même chose en sécurité, on peut exprimer plein d’avis, mais il n’y a qu’une seule réalité technique, une seule interprétation correcte.