Vincent Strubel nous parle de la politique open source de l’ANSSI

Dans le sillage de la libération du code de l'outil DFIR Orc, nous nous sommes entretenus avec l'un des sous-directeurs de l'agence française pour un point d'étape sur ses rapports avec l'open source.

L’Agence nationale de la sécurité des systèmes d'information a publié récemment, sous licence LGPL 2.1, un autre de ses outils. Après le système d’exploitation ClipOS, Wookey et OpenCTI, DFIR Orc a révélé ses « entrailles ». C’est le quatrième projet de taille à être publié par l’ANSSI en deux ans, même si l’agence est une habituée de l’open source depuis une décennie.

Orc est pour rappel une trousse à outils (presque une infrastructure) conçue pour relever dans de grands parcs informatiques des données forensiques au cours d’une expertise, quand il y a suspicion d’intrusion.

Nous avons donc voulu en savoir davantage sur cet outil, les attentes de l’ANSSI dans ce domaine, ses rapports avec le monde de l’open source et ses projets à long terme. Nous nous sommes entretenus sur ces sujets avec Vincent Strubel, sous-directeur Expertise.

Quels types d'informations est capable de trouver Orc plus précisément ?

C’est un outil configurable, donc on peut lui faire faire à peu près tout ce qu’on veut. La finalité est de trouver des artefacts, des traces subtiles qui auraient pu être laissées dans un parc de grand volume après une intrusion ou l’attaque d’un malware.

La situation de départ, c’est qu’on sait en général qu’il y a quelque chose de louche, mais on ne sait pas quoi. On lance donc un outil comme Orc, qui ne va pas identifier un programme du type « Virus.exe », mais relever des traces particulières dans les métadonnées, dans les journaux du système, des modifications dans certains fichiers, des éléments troubles dans la liste des processus, des processus avec des droits bizarres, des changements dans des droits d’accès, etc.

Ça peut aussi être des incohérences dans la manière dont un élément va répondre à deux requêtes strictement identiques, ou en réponse à une requête spécifiquement formulée. Ce n’est pas Orc qui va s’occuper directement de ce genre d’opérations, il est là pour lier les outils les uns avec les autres.

Ces informations sont collectées à grande échelle. On va chercher globalement tout ce qui ressemble à l’activité de quelqu’un qui aurait voulu effacer ses traces. C’est là qu’Orc fait toute la différence, parce que relever manuellement les informations sur 100 000 machines, c’est compliqué.

Les enquêteurs doivent donc avoir une idée de ce qu’ils cherchent et avoir d’autres outils pour analyser les données obtenues…

Tout à fait. Ce sont en général des ensembles assez volumineux, mais c’est tout l’avantage d’un outil comme Orc, parce qu’il est adaptable à presque tous les cas de figure.

On a parfois une forte suspicion de ce qu’on va trouver. Si vous avez déjà une idée du mode opératoire, vous resserrez la recherche sur des éléments plus précis. Dans d’autres cas, on ne sait pas, on fait de la « pêche au chalut » en quelque sorte, une recherche la plus large possible dans l’espoir de trouver quelque chose.

C’est ensuite à l’analyste, avec d’autres outils, de recouper tout ça avec des modes opératoires connus, des codes d’attaques connus, des scénarios identifiés a priori.

Quel risque pour une personne malintentionnée d’utiliser ce type d’outil ?

De manière générale, toutes nos publications open source sont mûrement réfléchies. On a depuis toujours un processus de revue de ce qu’on publie, d’autorisations un peu formelles. Ce n’est pas pour le plaisir de la bureaucratie, mais pour vérifier deux ou trois choses fondamentales.

La première est qu’on respecte toutes les questions de propriété intellectuelle. Pas question d’exposer des agents à des situations de contentieux. Ensuite, on vérifie que ce qu’on publie est conforme avec la mission fondamentale de l’ANSSI qui est de relever la sécurité numérique des administrations et des opérateurs d’importance vitale notamment.

On ne publie le code que quand on est convaincus que ça aura un effet positif. On se pose la même question pour nos publications scientifiques : « Est-ce qu’on rend service aux gentils ou aux méchants ? »

Dans le cas d’Orc, on peut publier sans risque, on ne voit pas bien quel avantage aurait un attaquant, pour deux raisons essentielles. Déjà, Orc est conçu pour fonctionner avec l’accord de la structure concernée et les administrateurs. Un attaquant qui aurait déjà ce niveau d’entrée dans un parc n’aurait pas besoin de notre outil. Ensuite, Orc est taillé pour la collecte de métadonnées, pas des données elles-mêmes.

Pourquoi le choix de la LGPL 2.1 pour la licence d’Orc ?

(Rires)

Il faudrait que je me renseigne plus en détails sur cette question. Je me souviens qu’à une époque on a beaucoup débattu sur les choix de GPL en 2.1 ou 3.0. On est restés sur la 2.1 qui nous paraissait plus souple.

Il fallait que ça réponde pour nous à deux objectifs : que ce soit réutilisable, et aussi – c’est un peu plus égoïste – que l’on puisse profiter des retours engendrés par ces utilisations. On préfère donc une licence qui oblige à partager les modifications faites qu’une licence comme BSD qui permettrait à chacun de reprendre le code à sa sauce, sans obligation derrière.

Quelles sont les attentes de l’ANSSI suite à la libération de ce code ?

On publie du code open source depuis une dizaine d’années maintenant, mais c’est vrai qu’on a pris ce grand virage il y a deux ans de pousser les « joyaux de la couronne » en quelque sorte, des outils qu’on utilisait et développait en interne depuis longtemps.

On a donc publié de gros projets dans une logique communautaire. On essaie vraiment d’avoir cette démarche maintenant sur des projets « flagship » comme on dirait aujourd’hui : ClipOS, Wookey, OpenCTI et maintenant Orc.

L’idée, c’est à la fois de participer à un effort collectif absolument indispensable vu l’ampleur du défi, et une forme de maturité ou d’humilité, de se dire que nous n’avons pas science infuse, et que les usages auxquels on a pensé peuvent répondre à des tas d’autres cas.

On fait des choses imparfaites comme tout le monde, donc publier et maintenir en open source des projets largement utilisés, c’est une manière de les améliorer, de créer une émulation.

Le choix de l’anglais pour la présentation du projet sur GitHub n’est pas anodin…

Oui, si on veut une utilisation la plus large possible. La stratégie de l’ANSSI s’inscrit dans un cadre national et international, depuis longtemps. On publie depuis toujours de nombreux articles scientifiques, entre 40 et 50 par an, et la plupart se retrouvent dans des conférences internationales. Pas de raison de se limiter au français donc.

Maintenant que des gros projets ont été publiés comme ClipOS et Wookey, y a-t-il eu des retours de la communauté ?

Réponse générale : oui. Plus particulièrement, il faut savoir que certains projets comme ClipOS ont été confinés pendant très longtemps. Une grande partie des informations étaient classifiées, donc on a franchi une étape significative.

En termes de retours, on a surtout eu des rapports de bugs, de gens qui avaient cherché à le recompiler ou l’adapter à d’autres usages. Pour Wookey, on a même des entreprises qui sont venues nous voir pour reprendre ça dans leurs produits. Sur OpenCTI, on avait déjà des retours avant même la publication parce qu’on était dans une logique collaborative.

Pour Orc, je pense que c’est un peu trop nouveau pour avoir autre chose que des réactions et questions initiales comme le choix du langage. Mais la publication faisait suite notamment à des demandes en ce sens. Donc oui on imagine qu’il y aura des retours.

C’est l’avantage de publier un projet comme Orc : il est utilisé par des spécialistes qui ont déjà l’habitude de modifier leurs outils. Il ne faut pas oublier que c’est un outil susceptible d’être employé par des prestataires qu’on connait bien. Et l’ANSSI a mis en place depuis longtemps des qualifications. Et derrière ces qualifications, il n’y a pas qu’un examen, il y a aussi une émulation collective autour des outils avec partages d’informations.

On est un peu sur des prestataires qui font le même métier que l’ANSSI. La charge de travail est telle que nous avons tout intérêt à se partager les informations.

Quels sont les plans à long terme de l’ANSSI avec l’open source ?

On a pris ce virage maintenant et on va continuer à publier. Je ne sais pas s’il nous reste encore en soute des gros projets comme ceux publiés ces deux dernières années.

Par contre, pour tous les nouveaux projets, je ne vois aucune raison de ne pas les lancer directement en open source.

Tout ça s’inscrit dans une réflexion plus générale sur la façon dont l’ANSSI peut être un contributeur utile et responsable à l’écosystème open source au sens large, notamment à des briques fondamentales et critiques. Il n’y a pas besoin de chercher longtemps pour en trouver, je parle de tout ce qui est bibliothèques de cryptographie, d’authentification, etc.

Ce sont quelque part des biens communs sur lesquels reposent d’autres projets open source ou la sécurité d’énormément de choses, notamment l’infrastructure d’Internet.