View in

English

Sécurité informatique : dîner raffiné ou tarte brûlée ?

Computer security blog
(Image: CERN)

Oh ! que j’ai hâte de cuisiner à nouveau pour mes amis et ma famille, de les inviter à un dîner raffiné, d’organiser un repas spécialement pour eux. Au menu : une salade César pour les végétariens, une sélection de charcuterie pour les carnivores, une fondue au fromage pour les Suisses et ceux qui ne craignent pas le lactose et, bien sûr, meringue et double crème de la Gruyère en guise de bouquet final ! Tous ces plats seront préparés avec soin, amour et savoir-faire, en utilisant uniquement les meilleurs ingrédients, soigneusement choisis au marché local un dimanche matin ensoleillé. Préparer un menu étoilé pour les personnes qui me sont chères – un festin digne d’un chef, d’un gourmet ou d’un connaisseur.

Je n’en suis hélas pas capable, car je ne sais pas cuisiner. Je ne maîtrise que les préparations Thermomix et la programmation de mon Thermomix. Je suis programmeur et développeur de logiciels. Et si je devais cuisiner comme un programme, mes amis ne reviendraient pas, pas même pour une simple tarte aux pommes. En effet, en tant que programmeur, lorsque je cuisine je me contente de prendre des ingrédients dans des endroits choisis au hasard. Je ne vérifie pas s’ils ont la même qualité, la même texture, le même goût et les mêmes arômes (délicats et subtils) que ceux achetés par le passé, qu’ils correspondent à mes attentes et peuvent apporter saveur et volupté à mon dîner. En fait, j’ai plutôt tendance à mémoriser l’emplacement des échoppes sur le marché, celle du boucher, du fromager, du vendeur de fruits et légumes, et je reviens, encore et toujours, pour acheter leurs produits. Je fais aveuglément confiance à ces échoppes ; je ne tiens pas compte du fait que les produits vendus sur les stands, au comptoir, par un boucher ou un vendeur peuvent ne plus avoir la même qualité, ou la même saveur, ne plus être soumis aux mêmes contrôles, ou bien que les échoppes puissent tout simplement ne plus être au même endroit ou avoir changé de propriétaire.

Aucun cuisinier ne se fierait aveuglément à un emplacement sur un marché quand il s’agit de préparer un bon dîner. Mais moi, comme je suis programmeur, je le fais. J’importe automatiquement des progiciels et des bibliothèques à partir de n’importe quelle source que j’estime pertinente. Ils m’apparaissent utiles au moment où je les importe car je trouve les bons morceaux de code sur la page web en question. Je privilégie les réimportations et les mises à jour automatiques grâce à des outils comme NPM ou PyPi. C’est aussi simple que de faire une tarte aux pommes, au risque de la faire brûler…

Gare aux attaques contre la chaîne d’approvisionnement ; en effet, se fier à des progiciels externes comporte des risques. De telles attaques se sont déjà produites par le passé. Des paquets se trouvant sur NPM, PyPi, GitHub, ou sur d’autres plateformes de distribution de logiciels à distance, ont été piratés soit parce qu’un code source venant d’une porte dérobée se trouvant dans la version la plus récente de ces paquets a été accepté, soit parce que des progiciels et des bibliothèques n’ont pas été vérifiés, soit parce que le compte du propriétaire du code source était compromis, soit parce que la maintenance de ce code source a été confiée à un nouveau gestionnaire (malveillant). Récemment, un spécialiste de la sécurité a mené avec succès une attaque à la chaîne d’approvisionnement contre Microsoft, Apple, PayPal, Shopify, Netflix, Tesla, Yelp et Uber ; il s’est contenté de diffuser des paquets publics portant le même nom que les paquets internes de ces entreprises. Il a profité du fait que PyPi et NPM recherchent la dernière version disponible des paquets et leur donnent la priorité, et ce même sur un téléchargement provenant de sources internes. Les logiciels utilisant NPM ou PyPi avec des dépendances internes à des bibliothèques tierces vont donc, en priorité, chercher les nouvelles dépendances sur internet. Tout ce que le spécialiste a eu à faire a été de trouver les noms de ces bibliothèques, de publier une version plus « récente » et d’attendre que PyPi et NPM fassent leur travail.

Le CERN n’a certes pas été attaqué, mais nos méthodes de développement (PyPi, NPM, téléchargements internet automatiques) sont les mêmes et le risque est donc identique. Il existe des mesures pour réduire les risques, comme l’utilisation de logiciels centraux pour gérer les dépendances tels que Snyk ou Nexus, mais ceux-ci doivent être déployés, gérés de manière centralisée et organisés, et tout autre moyen de téléchargement direct doit être évité. Je souhaite donc encourager la communauté des développeurs du CERN, par souci d’intégrité et de sécurité des logiciels que vous développez – mais également pour garantir un meilleur contrôle des versions et des révisions, une meilleure gestion des dépendances et le respect des licences – y compris pour les paquets et les bibliothèques que vous importez, à réfléchir à ces questions et à faire appel à votre hiérarchie afin de rendre possible la mise en place d’un tel service géré de manière centralisée ! En définitive, c’est à vous de choisir : êtes-vous plutôt dîner raffiné ou tarte brûlée ? Bon appétit !

_______

Pour en savoir plus sur les incidents et les problèmes en matière de sécurité informatique au CERN, consultez notre rapport mensuel (en anglais). Si vous souhaitez avoir plus d’informations, poser des questions ou obtenir de l’aide, visitez notre site ou contactez-nous à l’adresse Computer.Security@cern.ch.