Sécurité des SI, menaces et patching permanent : non, ce n’était pas mieux avant

Lors de la première et passionnante conférence, Veracode, une plateforme dédiée au suivi du développement logiciel et à la fourniture d’outils pour améliorer le code, analyse plus de 200 000 développements Open Source selon les bugs rencontrés, le délai moyen de correction en fonction de la sévérité de ces derniers, de l’utilisation de telle ou telle bibliothèque externe, du langage employé, etc. Le fait d’héberger autant de projets permet à Veracode de produire des statistiques très fouillées – de nombreux slides très denses sont déroulés pendant la conférence et impossibles à résumer en quelques mots, mais le lecteur curieux pourra se procurer le rapport ici[1]. En résumé, les développements sont de meilleure qualité sur les langages fortement typés (Java meilleur que C) ou anciens (Java meilleur que PHP ou Python), les délais moyens de correction dépassent dans la plupart des cas l’année (y compris pour les bugs majeurs) et l’usage de bibliothèques externes, s’il facilite le développement (il est quasi impossible de faire sans), rend aussi plus dépendant d’un code qui ne sera pas forcément maintenu au rythme souhaité. Ce dernier point devient d’ailleurs un casse-tête presque insoluble lorsque l’on prend conscience que les bibliothèques font de plus en plus appel à d’autres bibliothèques, le graphe des dépendances devenant très complexe et impossible à maintenir sauf à affecter des ressources quasi infinies.

Dans une seconde conférence (une table ronde entre quatre intervenants), le Cesin[2] (Club des experts de la sécurité de l’information et du numérique) se demande si, pour sortir du cycle infernal bien connu des RSSI qu’est la course au patch, il ne faut justement pas traiter le mal à la racine et précisément s’attaquer à la qualité du code produit. Manifestement, certains des intervenants n’étaient pas inspirés par le sujet puisque, en gros, le débat a essentiellement tourné autour de deux idées : c’est la faute du code produit car les développeurs travaillent mal, et c’était mieux avant (sous-entendu, il y a 20 ans, on développait bien). Seul l’intervenant de Schneider avait un discours plus mesuré, parlant plutôt de tests et de rapidité de correction des bugs, on verra après pourquoi.

D’une part, dire que « c’était mieux avant » relève de l’amnésie à un niveau inquiétant : j’ai personnellement fait partie de la génération de développeurs qui a réalisé le passage de DOS à Windows d’une foultitude de logiciels, et j’affirme qu’à l’époque tous autant que nous étions développions comme des pieds, certes avec peu de contraintes et de formation sur la production de codes de qualité, mais surtout sous la pression du delivery qui nous poussait à produire plus vite pour coiffer les concurrents au poteau : rien ne sert d’avoir produit le logiciel le plus parfait du monde si vos concurrents vous ont piqué les clients dans ce qui n’est jamais qu’une course de vitesse et si la boîte a déposé le bilan. L’intervenant de Schneider était manifestement plus prudent que les autres, réalisant ce que les contraintes de qualité impliqueraient pour son entreprise : produits plus chers, délivrés plus tard, pour un bénéfice commercial négatif (montrez-moi comment vous vendez ce genre d’idée à votre PDG), sans même parler du fait que tous vos concurrents sont en train de travailler sur la V2 alors que vous n’avez pas terminé la V1, déjà obsolète avant même sa sortie.

Si l’on remonte à une génération plus tôt, lorsque IBM a sorti le PC au début des années 1980, il a fallu trouver en vitesse un OS disponible : CP/M était en retard, et IBM se tourna vers un jeune entrepreneur (Bill Gates) qui avait racheté QDOS (autrement dit « Quick and Dirty OS », tout un programme) et l’avait adapté à la va-vite pour le fourguer à IBM. Même si le système était obsolète au moment de sa sortie (DOS était monotâche et truffé de bugs, alors que les OS multitâches préemptifs existaient depuis plus de dix ans), Billou n’en a pas moins décroché la timbale et est devenu l’un des dix types les plus riches du monde. Microsoft mettra plus de 15 ans à nettoyer les cochonneries présentes dans le code DOS (il en restait encore en Windows 95), et il serait intéressant de tenter de faire le calcul de ce que le DOS tout pourri (avec les quelques mois de gagnés en ayant écarté CP/M) a coûté à l’humanité entière pestant devant les bugs de Microsoft, dont le fameux écran bleu de la mort : si la qualité payait dans le monde du logiciel, on le saurait.

Mais surtout, s’il est clair que le code d’aujourd’hui n’est pas pire que celui d’hier, la différence majeure, c’est qu’hier rien n’était interconnecté. Avec l’avènement d’Internet et l’interconnexion croissante de tous les systèmes, l’avalanche de bugs qui nous pourrissait l’existence hier et qui n’enquiquinait que l’utilisateur local touche maintenant le monde entier, attirant comme des mouches ceux dont l’appétit coïncide avec la seule chose que l’humanité a toujours su faire comme personne : détrousser son prochain. Ce n’était pas mieux avant, les conséquences étaient juste moindres et surtout moins de gens étaient impactés, sans compter que de gros vilains bielo-russo-chino-coréo-yankees ne pouvaient pas nous rançonner à tout va.

Il existe plusieurs pistes de travail pour résoudre ce problème systémique, si tant est qu’il soit soluble : étanchéifier certains réseaux sensibles (piste défendue par certains, notamment pour la question des systèmes Scada), découpler par rupture protocolaire, etc., revoir certains protocoles de niveau 4 à 7 sur le modèle OSI, monter un Internet souverain connecté à l’Internet par des points d’entrée-sortie maîtrisés (ce que les Russes et les Chinois sont en train de faire au demeurant), etc. Améliorer effectivement la qualité du code est une solution à laquelle je crois de moins en moins.

[1] https://info.veracode.com/analyst-report-forrester-sca-wave.html 

[2] https://www.cesin.fr/