Et de 100 ! Waouh … Et dire qu’à l’époque, on m’avait prédit pas plus de 3 numéros. Depuis le numéro 0 de MISC en juillet 2001 et sa tête de mort vert fluo, les choses ont bien changé. Enfin, une chose est restée constante : MISC est un magazine qui traite de la partie technique de la sécurité avant tout. Mais une fois ceci posé, force est de constater les évolutions depuis le lancement de MISC en 2001.
1. Expansion du domaine de la lutte (informatique)
À ce qui semble être /A long time ago in a galaxy far, far away/, il était possible de s’intéresser à la fois au réseau, au système, à la crypto, aux vulnérabilités, etc. Bref, d’être touche-à-tout. Aujourd’hui c’est… compliqué.
Avec le recul (a.k.a. expérience a.k.a. cheveux gris), je constate que la courbe d’apprentissage est aujourd’hui plus longue, même si certaines bases restent incontournables.
En gros, tout le monde commence à toucher à plusieurs sujets : c’est la naissance. On est curieux, on veut tester, c’est facile et marrant : un peu de ARP spoofing, quelques challenges ici et là dans plein de domaines, une injection, lire, lire, lire, pratiquer, pratiquer, pratiquer, pratiquer, pratiquer. On découvre avec émerveillement, on y passe des heures et nos conjoint(e)s découvrent le « temps informatique » : j’arrive dans 5 minutes. Et 2h plus tard, le dîner est froid, évidemment.
Cette phase de découverte est elle-même simplifiée aujourd’hui, car la connaissance est disponible partout : dans des magazines, sur Internet, dans des cours / écoles / cursus plus ou moins spécialisés. Là où seuls des fous furieux^w^w passionnés persévéraient, on trouve aujourd’hui des espèces variées intéressées par la sécurité : de l’opérateur de SOC au pentester en herbe qui fait ses premiers pas sur des bug bounties, tout en passant par les chantres des processus et de la gouvernance. Il y en a pour tous les goûts.
Tout comme le pratiquant, restreignons donc notre propos aux aspects techniques. Petit à petit le goût s’affine : Windows ou macOS (personne de sain n’utilise plus Linux en desktop), Android ou iOS, vim ou Emacs, Il est alors temps de se limiter à une discipline, deux grand maximum, afin d’acquérir une réelle expertise : reverse, OS, pentest, crypto, web, infrastructure…
Puis vient le temps de la sagesse, où les connaissances acquises s’adaptent à d’autres domaines. On se rend compte des similitudes et des différences plus aisément d’un domaine à un autre, et ce qu’on a appris sert à continuer à apprendre de nouveaux sujets.
Pour résumer, le chemin de la connaissance est une fuite en avant, avec toujours des choses à apprendre, à la fois, car l’espace de connaissances est énorme, mais aussi parce que, comme notre galaxie, il est en expansion.
La transmission est un enjeu critique. Comment attirer des gens dans ce domaine austère, les couver, les cocooner et les faire progresser dans notre discipline. MISC répondait - et répond toujours - à cet enjeu. Pas MISC seul bien sûr, mais il y contribue, encore aujourd’hui. Merci à tous ceux qui ont permis cela au cours des 100 précédents numéros, en partageant leur savoir-faire. Je ne désespère pas de m’atteler autrement à la transmission, ça m'a toujours guidé.
2. De l’âge de pierre à l’âge de bronze
Je vais maintenant me concentrer sur les sujets techniques qui m’intéressent le plus, tout ce qui est lié aux systèmes : les vulnérabilités, le reverse engineering, la crypto, les architectures, etc. Et là aussi, la fuite en avant n’est pas une vaine expression.
Globalement, tous ces sujets sont de plus en plus complexes à plusieurs titres :
- La complexité, ça compte : les systèmes d’aujourd’hui sont autrement complexes. Un navigateur ressemble de plus en plus à un noyau, avec son allocateur, ses interruptions, sa gestion du matériel en direct, etc.
- La taille, ça compte : il est loin le temps où les développeurs ne disposaient que de 1Ko de RAM, et pas de swap. Maintenant les applications sont énormes, embarquent ou interagissent avec des tonnes de composants externes et la seule économie recherchée est celle pour préserver les batteries de nos téléphones.
- La fréquence, ça compte : ces magnifiques logiciels évoluent en plus très rapidement aujourd’hui. Toutes les approches agiles et devops facilitent l’entretien et les mises à jour fréquentes, mais rendent encore une fois la tâche d’un analyste bien compliquée.
Moralité, telle la lutte antivirale, les analyses de systèmes sont un puits sans fond.
La question est donc de savoir quoi faire ? Faut-il compter sur les bug bounties pour tester puis fixer à moindre coût les problèmes ? Ou bien laisser Google Project 0 se charger de la sécurité d’Internet ? Évidemment, la réponse est « non » aux 2 questions.
Je distingue 3 axes pour tenter de résoudre cette situation. Tout d’abord, les éditeurs pourraient accroître le temps consacré aux analyses et autres recherches de vulnérabilités puisque les systèmes sont plus complexes. Malheureusement, ils ne sont pas pour autant prêts à augmenter leurs budgets. Une autre option est d’augmenter les cerveaux, c’est-à-dire recruter plus, mais on se retrouve confronté au problème évoqué en première partie : avec quelles personnes ? Reste une troisième voie : les outils.
Il existe des tonnes d’outils en sécurité informatique, beaucoup trop même. Nombre sont à peine maintenus ou ne fonctionnent que sur le poste du développeur. Pour autant, il faut aussi reconnaître des progrès dans ce secteur, mais sans trouver réponse à tous les besoins. Prenons l’exemple du fuzzing, qui permet de gagner du temps quand on doit tester des logiciels. En général, les fuzzers rendus publics ont déjà intensivement tourné, et ne sont pas facilement adaptables à des cibles différentes. En outre, tout le monde n’est pas Microsoft ou Google, à chercher à tester des failles dans des millions de fichiers de 1Mo. Faire la même chose sur une seule grosse cible de 20Mo ne pose pas du tout les mêmes défis.
À ce titre, il est intéressant de fouiller un peu les travaux réalisés actuellement en analyses statique, dynamique et symbolique. La conjonction de ces approches avec l’automatisation permise par l’intégration continue et les approches devops se révèle fascinante. Ainsi, ce n’est pas seulement une question de « meilleurs outils », mais aussi d’être capables d’en automatiser le fonctionnement sur des tâches plus ou moins simples, pour que l’humain puisse se concentrer sur les tâches où il apporte réellement.
L’exemple donné par le cyber grand challenge organisé par le DARPA s’avère riche en enseignements et en progrès. Il révèle aussi une tendance, l'automatisation, qui sera nécessaire dans le futur, l’informatique se trouvant partout : dans nos poches avec nos portables, nos ordinateurs, mais aussi nos voitures, nos maisons …
L’étape suivant l’automatisation est l’orchestration. Il s’agit d’être en mesure d’enchaîner les entrées/sorties des outils, pour que les sorties de l’un servent d’entrées à l’autre, et ainsi de suite. Là encore, les approches modernes de développement aident.
3. Et maintenant, que vais-je faire ?
La sécurité est souvent perçue comme un domaine où « il faut en chier », certains en tirent même une grande fierté. Qui n'a jamais passé plusieurs journées à essayer de faire tourner un obscur outil, invectivant son auteur, pour se rendre finalement compte qu’il ne répond pas exactement à notre besoin, et se lancer dans le développement d’un nouveau prototype, évidemment mieux ? Ou qui ne s'est jamais moqué des erreurs des autres, car les découvrir donne un sentiment d'être meilleur, plus fort, que le développeur ou l'architecte ? Ces comportements font malheureusement partie de la culture en sécurité.
Sortir de ses dogmes et de sa tour d’ivoire, où on a parfois l’impression qu’on doit sauver le monde alors que non, est une urgence. La sécurité ne doit pas être à part, mais faire partie de, tout en étant la plus invisible possible, sans quoi elle n’obtiendra pas l’adhésion du public. Elle doit se fondre dans l'existant, sous forme de compromis, donc s'ouvrir à d'autres voies. C’est aussi vrai pour apprendre d’autres domaines. Je l’ai évoqué à plusieurs reprises, mais les ingénieurs sécurité ont à apprendre des développeurs par exemple, car ils ne sont souvent pas du tout développeurs, la qualité et la pérennité de leur code y gagnerait beaucoup.
Le gars qui fait de la sécurité est encore trop souvent vu comme un artiste soliste, voire un magicien (ou il se considère comme tel). Pour que la sécurité fasse ses preuves, nous devrons faire évoluer nos mentalités maintenant que les non-pratiquants ont globalement compris qu’ils avaient besoin de sécurité. Et cela passe par un travail en équipe afin d’affronter une complexité croissante, tant technique qu’humaine.
Que ce soit avec MISC, SSTIC, ou les entreprises où je suis passé, j’ai toujours été convaincu que les solutions ne pourraient émerger qu’en équipe. Et plus encore aujourd’hui quand on voit les évolutions et les enjeux de société auxquels la sécurité est confrontée.
Remerciements
Au rédac’ chef en titre pour m'avoir tiré de ma retraite, à l'équipe de Quarkslab pour ses retours, et en particulier Cédric pour les heures passées à discuter de ces sujets et à essayer d'affronter certains de ces enjeux.
