Le SSTIC 2010 s'est terminé sur une remarque intéressante concernant la tendance qu'à la communauté de la sécurité à privilégier la recherche de vulnérabilité au détriment de l'élaboration de systèmes réellement sécurisés. Je pense qu'il faut distinguer deux choses :

  • la vision court terme : l'analyse de sécurité d'un système spécifique (site web, applications, COTS, etc.) et la nécessité, pour faire bouger les choses, de démontrer que des vulnérabilités sont effectivement exploitables ;
  • la vision moyen/long terme : la nécessité de créer des cadres sécurisés dans lesquels des erreurs de développement ou d'utilisation ne mettent pas en péril la sécurité des systèmes.

Je crois moyennement à l'éducation des utilisateurs et des développeurs aux bonnes pratiques de sécurité (hormis à quelques règles de base, et encore...). Même après de nombreuses séances de sensibilisation, de formation, ou de démonstration, par l'exemple, de l'existence de vulnérabilités, il restera toujours quelques personnes qui coderont avec les pieds, introduisant alors une faille dans le système. Bref, l'éducation de 100% des gens aux bonnes pratiques me semble illusoire comme objectif et comme horizon pour que la situation s'améliore significativement.

Il faut plutôt considérer les utilisateurs et développeurs d'applications comme des sources potentielles de vulnérabilités. Je pense donc que le petit monde de la sécurité doit avant tout s'atteler à créer des cadres dans lesquels les utilisateurs et les développeurs peuvent se tromper, faire des erreurs, sans mettre en péril la sécurité des systèmes. Autrement dit, créer des systèmes tolérants aux failles et créer des environnements de développement empêchant de coder avec les pieds. Les différents guides de bonnes pratiques et de recommandations sont biensur intéressants et nécessaires. Cependant, un vrai environnement de développement sécurisé devrait être capable d'imposer de lui-même ces règles. La porte dérobée introduite involontairement dans le challenge SSTIC est un exemple typique d'erreur de développement. Un environnement de développement sécurisé devrait être capable de détecter, par exemple, de telles mauvaises utilisations d'API crypto.

Pour des systèmes tolérants aux failles, il s'agit notamment d'atténuer le risque d'exploitation. Voici quelques exemples de mécanismes ou de pistes qu'il est pourtant possible de mettre en place pour tenter de se protéger des programmes vulnérables :

  • activer les différents mécanismes qui rendent difficiles les exploitations en mémoire (bit NX, DEP, PaX, ASLR, canaris, UDEREF, etc.) ;
  • mettre en place ces mêmes mécanismes au niveau noyau ;
  • sandboxer les processus (chroot, SECCOMP) et les drivers (avec l'IOMMU) ;
  • limiter les droits des processus (capabilities sous Linux, etc.) ;
  • sortir des systèmes monolithiques (dont la moindre faille dans un driver ou une sous-partie obscure du noyau expose l'ensemble du noyau), pour utiliser des OS à base de micro-noyau (L4, Hurd, Coyotos, etc.) combinant les principes de moindre privilège et de minimalité ;
  • etc., etc. ;
  • d'autres mécanismes restent encore à imaginer !

Il existe des OS ou des prototypes d'OS durcis (Qubes, Gentoo Hardened, SeL4, etc.). Ces exemples doivent devenir la norme dans les futurs déploiements ou devenir la base de travail pour les futurs OS opérationnels.