Combien coûterait le piratage de votre téléphone ? La meilleure estimation pour un iPhone se situe entre 0 et 65 000 $ – et ce prix dépend principalement de vous. Si vous avez ignoré une mise à jour de sécurité très importante, le coût est plus proche de 0 $.

Dis que tu étais à jour. Ce chiffre de 65 000 $ représente un coût supérieur pour l’exploitation d’un individu médian : passez à un Android, un Mac ou un PC et il pourrait être bien inférieur. Apple a investi d’énormes ressources en durcissant l’iPhone. Le prix demandé pour un exploit individuel, plutôt que pour un service, peut aller jusqu’à 8 millions de dollars. Comparez cela au coût d’un exploit d’un lecteur PDF comme Adobe Acrobat – notoirement truffé de failles de sécurité – qui, selon ce Rapport de recherche TrendMicro (PDF) coûte 250 $ et plus.

Passez du ciblage d’une personne spécifique au ciblage de l’une des milliers de personnes d’une grande entreprise et il existe une myriade de façons d’y parvenir. Un attaquant n’a qu’à trouver la moins chère.

Le fait qu’un exploit iPhone moderne se vende à des millions contre des centaines pour un exploit Adobe Acrobat est une réussite extraordinaire pour Apple, qui mérite d’être célébrée et d’essayer de reproduire ailleurs. Cela reflète le fait que les grandes entreprises technologiques ont discrètement dépensé d’énormes ressources pour augmenter le coût d’exploitation des logiciels au cours des 20 dernières années.

Comment augmenter le coût d’exploitation ?

En dehors des plus grandes entreprises technologiques, l’idée de rendre les logiciels plus difficiles à exploiter a souvent été considérée comme une cause perdue. Imaginez qu’un ver se déplace sur votre réseau. Il est difficile de convaincre 1 000 employés de bureau de redémarrer leurs ordinateurs. Il faut donc installer un pare-feu sur le périmètre du réseau pour bloquer les paquets réseau du ver. Cela empêchera le ver d’entrer, mais les machines resteront vulnérables s’il pénètre dans le réseau.

L’approche moderne (confiance zéro, lancé par Forrester) consiste à supposer que le « périmètre » est déjà violé : chaque appareil et chaque application, quel que soit l’emplacement du réseau, doit désormais être renforcé. Comment? En augmentant le coût d’exploitation du logiciel lui-même.

Bien que cette approche soit considérée comme d’un coût prohibitif, elle gagne en popularité. Voici quelques techniques qui ont considérablement augmenté le coût d’exploitation des logiciels, ainsi que ce qui les rend coûteuses ou difficiles à déployer :

• Architecture sécurisée dès la conception : Concevoir la possibilité de modèles de vulnérabilité courants conduisant à des exploits. C’est incroyablement efficace et un une partie de l’architecture de l’iPhone qui est sous-estimé par le grand public. La sécurité par conception peut se produire au niveau de la couche matérielle ou au niveau de la couche linguistique, comme avec un langage tel que Rouillerconçu par Mozilla pour réduire la probabilité d’erreurs de programmation qui provoquent des failles de sécurité dans Firefox. Firefox est sorti en 1998 et Rust en 2018 ; après cinq ans de dur labeur, Rust représente désormais 10 % du code de Firefox. Imaginez l’effort qu’il faudrait pour porter un système d’exploitation complet comme Linux. À moins que vous ne partiez de zéro, la conception sécurisée est difficile et lente à mettre en œuvre.
• Atténuation des exploits du matériel et du système d’exploitation : Il s’agit sans doute davantage d’un périmètre, mais s’il est intégré, cela peut être efficace, car il n’y a pas de comparaison directe avec l’exécution de l’application en dehors du périmètre, car elle nécessite un système d’exploitation pour l’exécuter. Cette approche a joué un rôle important dans le durcissement au début des années 2000, en particulier pour l’écriture ou l’exécution de Linux et la prévention de l’exécution des données de Microsoft. Les approches plus récentes, telles que l’intégrité des flux de contrôle, sont théoriquement solides, mais entraînent souvent des coûts de performances que les développeurs ne sont généralement pas prêts à payer.
• Payer pour les vulnérabilités (également connu sous le nom de bug bounty) : Ironiquement, l’une des techniques les moins coûteuses consiste simplement à payer les pirates pour qu’ils partagent ce qu’ils trouvent. En théorie, les pirates pourraient monétiser les exploits pour bien plus que ce que le fournisseur paiera. Mais en pratique, maximiser la valeur extraite demande beaucoup de travail et peut confronter un pirate informatique à des dilemmes éthiques. Les primes aux bogues sont particulièrement idéales pour les entreprises disposant de nombreux services accessibles sur Internet, car leur configuration nécessite peu de travail.
• Outils de tests automatisés : Dès le début des années 2000, plusieurs startups sont apparues autour des tests automatisés pour des questions de sécurité. L’idée selon laquelle le code recherche des bogues dans le code semble intuitive, mais est sujette au bruit, car les réviseurs humains ont un contexte difficile à encoder dans une analyse en phase de compilation. Il reste populaire car sa mise en œuvre est relativement peu compliquée : configurez une tâche qui analyse le code tout au long du cycle de vie de développement. Il existe un vaste marché d’outils qui analysent le code au moment de la construction (SAST) et au moment de l’exécution (DAST) ; la plainte la plus courante concernant les outils est qu’ils contiennent un volume élevé de faux positifs.
• Revues de code manuelles ou automatisées : Transférer l’expertise de développeurs plus expérimentés à des développeurs plus juniors, ou utiliser des outils qui peluchent ou trouvent automatiquement des anti-modèles simples. Cela peut être d’une efficacité disproportionnée. L’automatisation de la révision du code peut efficacement mettre en œuvre une version moins ambitieuse de la sécurité dès la conception, appelée « garde-corps sécurisés », dans laquelle, au lieu d’une réarchitecture de fond en comble, les commentaires automatisés guident les développeurs vers une nouvelle méthode qui évite toute une classe de vulnérabilités.

Quelles sont les solutions potentielles ?

Je crois que l’avenir nécessite trois choses. Premièrement, davantage d’ingénieurs et d’ingénierie en sécurité : embaucher des ingénieurs en sécurité ayant une expérience en développement et obtenir que les dirigeants de l’ingénierie adhèrent au concept d’augmentation du coût d’exploitation des logiciels. Deuxièmement, nous devons délaisser les outils qui simplifient la détection et la réponse pour nous concentrer sur la création d’outils qui augmentent le coût d’exploitation. Troisièmement, il ne faut pas créer de nouveaux outils dans un monde isolé et centré sur la sécurité, mais en collaboration avec les développeurs et en tenant compte des besoins de l’entreprise en matière de livraison rapide.

Les logiciels dévorent le monde et leur exploitation est peu coûteuse. Nous n’allons certainement pas ralentir le premier, alors modifions le second.