Evidence-based security
En écho à la "broscience" (usuellement de la désinformation scientifique par des personnes non-compétentes), je souhaite m'adresser dans cette série d'articles à des mythes persistants de la sécurité informatique, qui n'ont jamais été corrects, ou bien obsolètes.
Pourquoi cet article ?
La désinformation est souvent involontaire, et doit être évitée, mais elle est amplifiée par la façon dont les réseaux sociaux sont utilisés. Beaucoup de personnes ne sont tout simplement pas qualifiées pour débattre sur certains sujets, et pourtant ce sont les personnes que l'on entend le plus.
La désinformation moderne a un caractère viral : une fois l'information fausse transmise à d'autres personnes, elle se répandra forcément, si bien que certains seront convaincus et défendront corps et âme sa prétendue véracité ; sans doute au nom d'une question d'égo, car l'humain est un être d'égo avant tout qui n'aime pas concéder avoir été dans le faux.
Halte à la "brosécurité" ! Prenons le temps de voir les choses.
Avertissement : je ne suis pas un professionnel dans le domaine de la sécurité. Vous devriez en toute rigueur me considérer comme un potentiel vecteur de désinformation : faites de la vérification en toutes circonstances.
La sécurité informatique basée sur l'évidence
Le relativisme est une bonne chose, mais peut être parfois l'ennemi de la véracité. Il y a des faits objectifs, on ne peut pas être "sûr de rien" sans quoi la science ne pourrait jamais avancer : les mathématiques commencent par des postulats, des points de départ évidents et admis (aussi appelés axiomes).
Enfin, et je le répète peut-être à chaque fois, gardez un esprit critique sur tout ce que vous lisez pour éviter d'être à votre tour le vaisseau de la désinformation. Je suis l'auteur de ces lignes, et je ne suis pas omniscient, je vous propose "ma" vérité que je souhaite basée sur l'évidence plutôt que la spéculation et l'idéologie.
Je fais donc également référence à l'evidence-based medicine, autrement dit la médecine moderne, factuelle, celle qui prône les études cliniques randomisées en double aveugle et qui est à l'origine de la pharmacologie moderne également. On peut comparer la sécurité informatique à la sécurité d'un corps humain, au fond : dans des sujets aussi sensibles, le factuel doit donc primer.
Le modèle de menace, souvent négligé
Le modèle de menace est un principe fondamental en sécurité informatique, bien trop souvent oublié lors de débats animés en ligne.
Contre qui souhaitez-vous vous protéger ? De quoi ?
Contrairement à ce que certains pensent, sécurité et vie privée sont intrinsèquement liés : il n'y a pas pire atteinte à la vie privée qu'une intrusion malveillante dans votre système informatique. Le respect de la vie privée ne peut être obtenu sans une sécurité décente.
Jusqu'à quels sacrifices compte tenu de la menace ?
Autrement dit, tout est question de compromis. Le risque zéro d'une intrusion est difficilement atteignable, mais il peut l'être si vous vivez en autarcie sans connexion quelconque au monde extérieur. À mon humble sens, tout est question de minimiser ce risque et cela passe par de bonnes pratiques communes : réduire sa surface d'attaque et maintenir à jour son système.
Ce n'est pas une question de SI mais de QUAND un système sera compromis.
Dès lors, les vulnérabilités les plus dangereuses sont souvent celles qui sont théoriquement possibles mais pas encore observées. Son exploitation est peut-être déjà possible et inconnue des personnes responsables : on parlera d'une 0-day. Partez du principe que des attaquants sophistiqués ont une longueur d'avance sur vous et auront à disposition des fameuses 0-day.
Le mythe de l'open-source garant
L'open-source signifie qu'un code source est ouvert, à la portée de tous. Selon sa licence, il peut être réutilisé de différentes façons (commerciales et/ou personnelles), avec ou sans parentalité associée ; mais dans tous les cas, c'est un code qui peut être consulté par tout le monde.
Given enough eyeballs, all bugs are shallow. - Loi de Linus
L'open-source a longtemps été vanté comme un gage de sécurité :
- Un code ouvert peut être audité par n'importe qui, il y a donc de plus fortes chances de détecter des vulnérabilités.
- Un code ouvert est transparent, donc il est difficile d'y intégrer du code malveillant, comme des portes dérobées par exemple.
Par exemple, les contributeurs du noyau Linux doivent également lever leur anonymat au moment de leur contribution, ce qui ajoute la confiance à la transparence.
Le problème, c'est que cet avantage de sécurité par rapport à un code "fermé" est très souvent théorique. Bien sûr, il faut promouvoir des solutions robustes et ouvertes, mais il ne faut surtout pas associer automatiquement l'ouverture à la sûreté. En réalité, beaucoup de projets open-source sont même très négligents de la sécurité.
Quelques exemples récents de ce que ça implique :
Animesh Jain
De plus, il est à souligner qu'un code fermé (tout comme une architecture informatique, composée d'un parc de serveurs par exemple) peut être audité de façon transparente et indépendante. Ces mêmes audits "professionnels" existent bien également pour du code ouvert ou disponible sur demande.
Ce premier exemple servira à illustrer l'evidence-based security : des faits plutôt que des croyances. Le libre (et l'open-source en général) est une excellente chose, mais il peut aussi être le Cheval de Troie idéal dans certaines circonstances. Il ne faut jamais baisser la garde.
Le CVE counting : quantifier ne marche pas
CVE est l'acronyme de Common Vulnerabilities and Exposures. C'est un système d'information qui permet de référencer publiquement les vulnérabilités. Une CVE possède un identifiant construit ainsi :
Préfixe CVE + année + numéro d'identifiantC'est un système très pratique mais qui doit être considéré seulement pour ce qu'il est. En d'autres termes, le système de CVE ne peut pas être un moyen de "quantifier" la sécurité d'une architecture : ce n'est pas parce qu'un code A a plus de CVEs qu'un code B que le code A est moins sûr.
En médecine, une toux est un symptôme assez commun : d'une allergie passagère à un cancer très grave, ce seul symptôme ne suffit naturellement pas à établir un diagnostic.
Parfois, c'est une indication qu'effectivement il y a un problème d'architecture avec le code A, mais ça peut également dire que le code B n'est tout simplement pas assez audité. Voyez le problème : les humains sont assez vicieux pour réussir à faire mentir les chiffres. Le CVE reste avant tout un système à but de référencement et d'information, mais ne peut être un argument à lui-seul.
L'hypocrisie, ennemie de l'information
Dans les communautés liées à la vie privée et la sécurité, de nombreux débats en ligne sont trop souvent animés par des sophismes et des arguments qui n'ont aucun fond concret, simplement car une grande partie de personnes n'arrivent pas à mettre leur égo de côté quitte à s'enfoncer délibérément dans les propos fallacieux et inutilement conflictuels.
Je souhaiterais qu'on puisse en débattre plus sereinement, avec des informations, du bon sens, et dans la bonne humeur quand c'est possible ! Mais pour ce faire, il faut prendre le temps d'analyser quelques procédés contraires à ces principes et trop souvent utilisés.
J'ai lu cet article, mais l'auteur est biaisé, ne le croyez pas.
Le désaccord ne signifie pas que la personne en face est biaisée. Elle peut l'être, mais vous aussi. Un réel biais résulte dans une recommandation irrationnelle basée sur une préférence personnelle. Il faut séparer l'information de la préférence : ce n'est pas parce que j'utilise Windows que je n'aime pas Linux, par exemple.
C'est ton avis... pas le mien !
C'est assez récurrent : face à une information qu'on est incapable de réfuter ou de montrer ses faiblesses, on se résigne à la faire passer pour un avis personnel pour lui retirer son caractère universel. C'est à éviter : tout ne peut pas être relatif ou sujet à opinion, sans quoi il est impossible d'avancer.
Tu utilises ce logiciel, mais pourtant tu dis qu'il n'est pas sécurisé ?
Ce n'est pas de l'hypocrisie que d'utiliser un logiciel dont on liste pourtant ses défauts techniques. C'est au contraire parce qu'on utilise beaucoup un logiciel qu'on est prompt à reconnaître ses faiblesses pour pouvoir l'améliorer. Le contraire serait assez triste, non ?
Cet auteur a fait une erreur sur un autre article, donc cet article est faux.
L'erreur est humaine : il arrive à tous de faire des erreurs, des fautes de jugement, même si on peut essayer de les éviter, notamment par la rigueur scientifique. Il est possible qu'un article soit complètement à côté de la plaque, mais ça ne signifie pas pour autant que les autres ne sont pas justes. Inversement, ce n'est pas parce qu'un article est juste que les autres le sont : il faut isoler les conclusions et ne pas faire plus attention à l'auteur qu'au contenu de ses propos.
Cet auteur n'est même pas compétent, il serait incapable de me hacker.
Déjà hacker est un mot qui signifie tout et n'importe quoi (littéralement bidouiller), dans ce contexte on comprend que ce serait plutôt une intrusion. Bref, cet argument ne constitue en aucun cas une forme de réfutation et le monde ne tourne pas autour de vous.
La sécurité théâtrale : à fuir !
Par sécurité théâtrale, j'entends les pratiques ou propos avancés sans fondement ou sans réel intérêt censés soutenir l'argument de sécurité.
Quelques exemples :
- Military-grade encryption pour désigner l'utilisation d'algorithmes standardisés : ça sonne bien à l'oreille, mais ça ne veut rien dire sur la sécurité de l'architecture. Pire encore, c'est mauvais signe...
- Comme il a été vu plus haut, l'argument de l'open-source et des CVEs à lui-seul ne veut rien dire, et peut même s'avérer très trompeur.
- Vérifier le hash d'un fichier téléchargé au même endroit où le hash a été récupéré. C'est peu utile, mais ça pourrait laisser penser le contraire.
- Penser que la sécurité peut fonctionner en énumérant le mal (antivirus classiques par exemple) : non, ça ne fonctionne pas comme ça !
Il faut une sécurité pragmatique, basée sur l'évidence. Il ne faut pas juste penser bien faire, il faut que ce soit réel.
Quid de la sécurité par l'obscurité ?
La sécurité par l'obscurité, ce n'est pas tout à fait la même chose, même si parfois cela peut se recouper avec la sécurité théâtrale. La sécurité par l'obscurité repose sur le secret de conception ou de l'implémentation.
Quand il est seul, c'est évident un mauvais mécanisme. Mais s'il est considéré pour ce qu'il est et accompagné d'autres mécanismes de sécurité plus robustes et objectifs, il peut néanmoins être utile : pour détourner des attaquants peu sophistiqués entre autres.
Un exemple est de configurer un serveur SSH sur un port autre que 22. Cela détournera pour sûr des bots et des attaquants qui ne vous ciblent pas forcément, mais un attaquant saura trouver le bon port : il convient donc de sécuriser SSH autrement, et de considérer cette mesure à la fin.
La sécurité spéculative (FUD)
Fear, uncertainty and doubt : peur, incertitude et doute. C'est une façon de penser qui relève de la rhétorique et de la spéculation plutôt que du domaine factuel, il convient donc de s'en méfier. Un exemple de FUD :
Tel logiciel contient une backdoor (porte dérobée), je n'y toucherais pas !
Dès lors, sachez que tout et n'importe peut contenir une backdoor :
- Votre hardware jusqu'au CPU-même. Et même si son architecture était open-source (RISC-V), rien ne garantit l'absence de backdoors au niveau du silicone.
- Votre software, qu'il soit closed ou open-source. De la même façon que le silicone du CPU, quand vous utilisez un code compilé par un tiers, le fait que son code source soit disponible n'est pas une garantie.
- Parenthèse : des backdoors très élaborées peuvent même être introduites à la vue de tous dans des codes sources publics.
Bref, à moins de contrôler toute la supply chain, ce qui est improbable, difficile d'avoir des garanties absolues.
Ces craintes ne sont pas forcément à balayer dans l'établissement d'un modèle de menace, mais nous verrons ci-dessous un modèle de sécurité idéal qui y répond. Il n'est pas pertinent et raisonnable (bien que tentant) de partir dans des délires conspirationnistes : je propose que l'on reste dans le pragmatique, le reste n'a pas vraiment sa place sur mon blog.
Si vous êtes amateur de titres sensationnels à coups de "NSA" et de "backdoors", vous ne trouverez rien d'intéressant ici et n'obtiendrez rien d'intéressant en tentant de m'en parler. Vous êtes cependant libre de lire d'autres sources et d'avoir votre propre avis.
Gare à la fausse sensation de sécurité : toutes ces mauvaises approches et visions de la sécurité informatique contribuent d'autant plus à la conception et l'utilisation d'architectures fragiles ainsi qu'à la propagation de "fausses" bonnes pratiques. Or une personne qui se sent faussement en sécurité est une personne d'autant plus vulnérable...
Le modèle idéal : Zero Trust Security
Le modèle Zero Trust relève du bon sens : on n'accorde pas sa confiance n'importe comment. Ce modèle s'applique aussi bien dans nos pratiques quotidiennes, que dans les pratiques de développement dans des architectures informatiques quelles qu'elles soient.
Le modèle du château fort est dépassé, il faut une sécurité en profondeur avec plusieurs couches de défense et une architecture robuste.
Différents principes non-exhaustifs découlent de ce modèle :
- Le moindre privilège, les moindres permissions
- La vérification systématisée dès que possible
- La transparence : des audits indépendants jusqu'à l'open-source
- La compromission présumée à chaque couche : pas de confiance disproportionnée
- La configuration sécurisée out-of-the-box : pour limiter les failles humaines, une architecture doit être "sûre par défaut"
Ce modèle est un idéal auquel on doit tendre, et qui doit être gardé à l'esprit par tout utilisateur et développeur.
À venir…
Je comptais tout écrire dans un seul article mais au fur et à mesure de l'écriture, je me suis rendu compte que la longueur allait être sub-optimale quant à l'accroche du lecteur et son intégration des informations.
Je vais donc proposer au cours de ces prochains mois plusieurs articles de taille modérée qui traiteront un sujet unique. Nous allons aborder :
- La sécurité, ou plutôt l'insécurité, du versant desktop de Linux
- L'état actuel du modèle de sécurité mobile
- Des mesures pour renforcer la sécurité de Linux
- gVisor et la problématique de la surface d'attaque exposée
- Les vulnérabilités liées à la mémoire (buffer overflow & cie)
- L'utilisation de root sur les distributions Linux classiques
- Le modèle de sécurité de Windows 10 et ses mitigations
- GrapheneOS : l'OS sécurisé basé sur AOSP
On peut considérer le précédent article sur les VPN comme une partie de cette série. Donc si cela vous intéresse, je vous y réfère :
Ma relation à la sécurité informatique
Je m'intéresse à la sécurité informatique depuis mon plus jeune âge. Je dévorais des bouquins à ce sujet et m'amusais comme tout bon script kiddie avec certains outils pour faire quelques bêtises (jamais rien de méchant !) à l'époque où Kali Linux s'appelait encore BackTrack.
Je ne m'intéressais pas seulement à l'attaque, mais aussi (et surtout maintenant) à la défense, que ce soit sur mon PC Windows, mon MacBook, mon iPad, mon smartphone Android ou encore mes serveurs Linux (j'ai d'ailleurs longtemps utilisé Linux sur desktop, mais ce n'est plus le cas depuis quelques années). J'essaie donc d'être impartial et je m'intéresse aux bonnes pratiques universelles, peu importe la plateforme sous peu qu'elle soit moderne.
Ce long travail de veille technologique sur la sécurité est continuel, mais je souhaite en partager un instantané partiel.
Enfin, j'aimerais que l'on termine sur une petite touche humoristique :
