5 étapes pour sécuriser un processus de signature de code

Nous vivons dans un monde digitalisé qui repose sur une multitude de lignes de code. Les logiciels ont envahi presque tous les pans de notre existence, de notre quotidien jusqu’aux infrastructures critiques de la société. Dans le même temps, les pirates sont passés maîtres dans l’art de diffuser leurs programmes malveillants ou malware.

Une situation tristement démontrée par l’attaque SolarWinds, qui a vu plus de 18 000 clients lourdement affectés pour avoir trop fait confiance à ses logiciels, et pour cause les logiciels étaient signés numériquement et authentifiés à l’aide d’une identité machine à signature de code.

Ce mode d’attaque n’est pas nouveau : les pirates implantent leur programme nocif dans le logiciel pendant sa phase de développement, afin qu’il soit ensuite repris par toutes les mises à jour légitimes dudit logiciel. Mais la sophistication et le champ d’action de ce type d’attaque a fait ses preuves, et reste très attractif pour d’autres aspirants pirates. Les entreprises doivent s’en prémunir et, si aucune approche n’est infaillible, elles doivent absolument revoir leurs processus de signature de code pour resserrer la vis.

La signature du code était un problème alors qu’elle aurait dû être la solution

Mais comment éviter que des malwares soient glissés furtivement dans les logiciels en cours de développement ? Dans le cas de l’attaque de la compagnie SolarWinds, ses clients avaient confiance car ils pensaient qu’elle développait elle-même ses logiciels de signature, qui étaient donc forcément exempts de code nocif, d’autant que rien ne laissait penser qu’ils avaient été corrompus.

Aucun moyen actuel n’aurait permis d’éviter cette attaque, mais l’application de procédures renforcées autour du code auraient été un moindre mal. Les certificats de signature de code sont des identités machines qui permettent aux développeurs de prouver qu’un programme logiciel est authentique.

En signant digitalement des applications, des logiciels ou des microprogrammes (firmware) embarqués à l’aide d’une clé privée, les utilisateurs finaux reçoivent la preuve que ce code provient d’une source digne de confiance et légitime. Néanmoins, si des identités de signature de code sont insuffisamment protégées et tombent entre les mains de pirates, les conséquences pourraient être désastreuses. L’identité d’une machine peut être utilisée comme une arme, en permettant à un pirate de passer outre des processus de signature de code tout en paraissant digne de confiance.

Il y a dix ou vingt ans, les entreprises protégeaient leurs environnements de développement logiciel au moyen d’un bac à sable (ou sandbox), isolé du reste du réseau. Tout code source importé était vérifié par un régiment de moteurs antivirus pour s’assurer qu’il ne contenait entre ses lignes aucune vulnérabilité connue. Si l’on y perdait en rapidité et en commodité, cela permettait de développer les meilleurs produits qui soient.

Aujourd’hui, ce n’est plus possible étant donné la vitesse des développeurs et les délais imposés par la transformation digitale des entreprises. Dès lors, s’il n’est pas envisageable de disposer d’un environnement de développement logiciel totalement déconnecté du réseau, comment mieux protéger les pipelines de développement et de livraison fonctionnant en continu ?

Deux approches permettent de renforcer la sécurité de ces processus : primo, le pipeline de développement peut être mieux protégé en le verrouillant et en donnant accès uniquement aux packages de logiciels qui ont été approuvés spécifiquement à des fins d’installation dans le pipeline de livraison. Et rien ne s’oppose à ce qu’une liste vraiment statique de binaires approuvés avec des signatures valides soit vérifiée avant d’en autoriser l’exécution.

La seconde approche consiste à renforcer les procédures de signature du code afin d’autoriser les seuls packages logiciels strictement nécessaires dans la station de travail, et de bien s’assurer que seul le code sûr sera exécuté. Seuls les logiciels validés (par signature) par leurs fournisseurs seraient dans ces conditions intégrés à l’environnement de développement, et chaque malware qui serait éventuellement installé (comme dans le cas de l’attaque SolarWinds) ne pourrait alors pas s’exécuter.

Il n’existe pas de solution universelle capable de bloquer de futures attaques

Comme pour toute intrusion, aucune formule magique n’aurait permis d’éviter l’attaque SolarWinds et les modifications apportées à cette occasion au code source du programme éponyme. L’approche reposant sur plusieurs couches de sécurité restera toujours privilégiée pour renforcer la sécurité du système dans son ensemble : de la couche réseau aux personnes ayant accès au code source ; de la vérification du code source à la livraison d’un produit dont la provenance est assurée par les entreprises, qui peuvent prouver qu’il vient de leur environnement de développement sécurisé. Tout doit être passé au crible, surveillé et maintenu en gardant à l’esprit les éventuels risques.

La cadence est telle du côté des pipelines DevOps que le problème a désormais dépassé le périmètre de l’intervention et des contrôles humains, bien trop lents. Les entreprises ne peuvent plus compter uniquement sur des processus et checklists manuels pour s’assurer qu’elles exécutent le bon logiciel et qu’aucune modification n’y a été apportée sans autorisation.
Dès lors, les professionnels de la sécurité peuvent effectuer plusieurs actions pour vérifier que leurs procédures de signature de code sont bien verrouillées et n’impacteront pas la sécurité globale du système. En voici la liste :

1 > Centraliser la protection des clés
En centralisant le stockage de leurs clés privées, les entreprises n’auront pas à se soucier de la circulation éventuelle de copies non autorisées ou de l’endroit où ces clés de signature sont stockées.

2 > Un circuit de validation pour les signatures
Les organisations ont besoin d’un circuit de validation afin de paramétrer quelles personnes ont le droit de signer du code, et les systèmes sur lesquels ces dernières ont le droit de solliciter ces signatures, via les clés dont le stockage a été centralisé.

3 > Validation des signatures (validation de ce qui peut être signé)
A partir du moment où l’on approuve qu’un utilisateur et un système définis effectuent des opérations de signature, que vont-ils réellement signer ? Les entreprises doivent également définir un circuit de validation qui permet à un administrateur d’inspecter la demande de signature avant son approbation.

4 > Capacité à contrôler les signatures, même avec un pipeline CI/CD à haut degré d’automatisation
La totalité des opérations de validation et de signature devrait être attribuée aux comptes système, puis inspectées et planifiées. L’automatisation est nécessaire pour permettre aux développeurs de livrer dans les délais, tout en leur assurant d’avoir mis des règles ad hoc en place pour prouver qu’ils pilotent le processus de signature.

5 > Audits et reporting
Il est essentiel d’être en mesure d’auditer et de prouver que vous vous conformez à la politique définie et aux bonnes pratiques lorsque vous avez recours à la signature de code au sein du pipeline de livraison des logiciels. Les entreprises doivent consigner les opérations de signature de code et de validation, pour limiter les risques d’attaques perpétrées par des cybercriminels opportunistes.

Chaque organisation spécialisée dans les logiciels, mais aussi l’ensemble de ses collaborateurs dédiés à la sécurité, doit chercher à sécuriser ses identités machines. Cette démarche va bien au-delà d’efforts de protection accrus en vue de réduire le nombre de vulnérabilités dans le code. L’intégralité du processus de développement doit être protégé à l’aide des identités machines.

Chacune de ces identités doit être gérée, ce qui inclut le fait d’avoir une visibilité sur tous les certificats de signature utilisés, de savoir de quelle manière ils sont exploités et de recourir à l’automatisation pour gérer l’intégralité de leur cycle de vie. A défaut, des personnes malveillantes continueront de cibler les processus de signature de code, en parvenant à leurs fins.