Sécurité informatique: faisons un vrai pas en avant
Autour des années 2000-2001, j'ai découvert le langage OCaml par hasard sur le site "The great computer language shootout" hébergé sur alioth.debian.org. Motivé à investiguer cette étrange bestiole qui se classait en 3ème position, à l'époque, derrière C et C++ et avant Java en terme de performances d'exécution, je découvris la programmation fonctionnelle par l'entremise de ce langage.
Je suis un ingénieur HES en télécoms suisse diplômé début 1997 de la HEIG-VD à Yverdon. Dans les cursus d'écoles techniques et hautes écoles suisses, en tout cas à l'époque, on n'abordait pas le sujet de la programmation fonctionnelle.
Lorsque je pris connaissance de certains de ses avantages sur la programmation "traditionnelle", soit la programmation dite "impérative", je me souviens m'être dit qu'il m'avait manqué quelque chose d'important dans mon cursus scolaire.
A l'heure des cris bien compréhensibles du simple utilisateur final de l'informatique quant aux défauts de sécurité du domaine, qui plus est depuis l'avènement des "ransomware", je prends la plume et écrit ce billet pour vous proposer quelques pistes de réflexion voire de solution, pistes qu'ont pourrait nommer d'un quasi-oxymore, des solutions simples mais radicales.
Attention, je ne considère pas avoir la science infuse concernant la sécurisation de l'informatique connectée, je ne suis pas un spécialiste de la sécurité informatique, mais me débrouille tout à fait honorablement en sécurité préventive et défensive.
Les pistes que je propose ici sont celles que j'ai misent en pratique au fil du temps pour mon informatique personnelle ou professionnelle, avec comme simple motivation celle de me mettre un maximum à l'abri des risques majeurs d'insécurité informatique.
A mon sens un vrai spécialiste de la sécurité informatique est un "white hat hacker" maitrisant parfaitement les connaissances et outils du "black hat hacker", mais désireux de les mettre à profit exclusivement de manière éthique. C'est une personne qui connaît parfaitement l'article de Phrack Magazine "Smashing the stack for fun and profit", l'ayant lu et relu ET mis en pratique à titre expérimental. Idem concernant les "return into libc", "SQL injection", "IDS evasion/defeating" etc...
Personnellement je connais ces principes, ai essayé les exemples de code de l'article "Smashing the stack" mais ne suis jamais allé plus en profondeur dans le domaine. Par contre, j'ai troqué Windows contre Linux en 1994 déjà.
A noter la relative facilité d'être un bon spécialiste de la "SQL injection", de DoS ou DDoS ou de l'ingénierie sociale par rapport aux compétences nécessaires dans les 3 autres cas de figure cités en exemple ci-dessus. La spécialisation en sécurité informatique, la vraie, est difficile à acquérir. Gare aux charlatans qui ont déjà commencé à pulluler dans ce domaine.
Petit lexique
Hacker
Professionnel et passionné d'informatique en pratiquant encore dans son temps libre.
White hat, black hat
C.f. les liens vers wikipedia ci-dessus.
Sécurité défensive, proactive et réactive
A mon sens, la sécurité mettant une barrière autour d'un gros trou sur la route est réactive. Construire la route pour qu'elle ne comporte jamais de trou est proactif.
La sécurité défensive est l'ensemble des pratiques élémentaires de sécurité misent en oeuvre par les bons professionnels de l'informatique, par exemple l'application prompte des mise à jour, particulièrement celles de sécurité, antivirus, utilisation de parre-feu, sensibilisation de l'utilisateur final, utilisation au maximum possible de la cryptographie, backup, disaster recovery, bonnes règles de programmation etc...
Pourquoi la programmation fonctionnelle?
Pour qu'il n'y aie jamais de trou sur la route! L'état de l'art en terme de recherche en informatique théorique nous indique, et ce n'est même pas nouveau à vrai dire, qu'un logiciel codé dans un langage fonctionnel typé correspond dans un domaine des mathématiques à une preuve logique. Autrement dit, sous ces conditions, les algorithmes sont des méthodes mathématiques.
Ce fait permet de "raisonner" d'une manière automatisée sur du code source de manière on ne peut plus précise et aboutie que dans le paradigme de la programmation impérative. Le compilateur d'un langage fonctionnel fait office certes de compilateur, mais aussi se débrouille mieux pour prévenir les bugs que la meilleure combinaison compilateur/outil d'analyse statique d'un langage impératif.
Cette relation un à un entre les algorithmes codés dans le paradigme fonctionnel pure et les mathématiques logique se nomme la correspondance ou isomorphisme de Curry-Howard. C'est un élément central en informatique, qui mérite d'être beaucoup plus connu qu'à l'heure actuelle.
Pourquoi la progr. fonctionnelle est-elle si peu connue?
- Elle est probablement un petit peu plus difficile à acquérir qu'un langage impératif relativement simple comme le langage C. Mais probablement pas plus difficile que d'apprendre un langage impératif assez vaste et redondant tel que C++.
- La fierté nationale suisse en terme de langages, c'est Niklaus Wirth avec Pascal et Modula 2, deux langages impératifs.
- Sa rapidité d'execution est grosso-modo deux fois moindre qu'un programme équivalent écrit dans le langage C. Pendant longtemps cela a été un frein à son adoption. La puissance des CPU actuels, l'utilisation à outrance de langages interprétés pour la programmation web à largement contribué à relativiser, distancer ce problème.
Autres choix informatiques sécures
- Sur les serveurs, le choix de Debian GNU/Linux ou OpenBSD est quasiment un "must" de nos jours.
- Sur les stations de travail, le choix d'Ubuntu Linux est à investiguer urgemment, les distributions de Linux ayant énormément progressé en facilité d'utilisation ces dernières années.
Pour mémoire, Linux c'est l'Operating System (OS) faisant fonctionner internet et les smartphone Androïd. En tant que professionnel de l'informatique, il n'est pas rare de découvrir ici où là chez un client un serveur Linux ayant passé deux ans sans avoir besoin d'être redémarré et fonctionnant comme au premier jour.