Post Mortem

Que faire lorsque l'on rencontre une vulnérabilité dans un produit ou un service numérique? 

On explore avec Rayna Stamboliyska (Twitter: @MaliciaRogue) le rôle de la divulgation coordonnée de vulnérabilités; en quoi celle-ci permet de fluidifier la remontée des vulnérabilités et offre un compromis intéressant pour préserver la sécurité des utilisateurs? 

Dans un environnement où nous sommes tous utilisateurs finaux de produits et de services numérique, où le risque 0 en cyber sécurité n'existe pas, une organisation qui affiche une politique de divulgation coordonnée envoie un signal fort sur son humilité face au risque ainsi que sur le cheminement qu'elle a déjà effectué afin de limiter ce risque.

Après un tour d'horizon du cadre légal sur la divulgation de vulnérabilités, on passe en revue quelques organisations à partir desquelles s'inspirer pour la vulnerability disclosure. Enfin Rayna nous partage ses bonnes pratiques pour la mise en place d'une politique de divulgation coordonnée de vulnérabilités. 

Références mentionnées au cours de l'épisode:

Norme ISO 29147 - Divulgation de vulnérabilité - iso.org

Norme ISO 30111- Processus de traitement de la vulnérabilité - iso.org

Arguments pour / contre les différents types de divulgation -  wikipedia.org

firebounty.com - recense les politiques de divulgation mises en ligne par des services providers (9577 policies au 28 octobre 2020) - firebounty.com

Article 323-1 du code pénal relatif au maintien frauduleux dans un système de traitement automatisé de données - legifrance.gouv.fr

Loi du 7 octobre 2016 pour une République numérique, article 47 - legifrance.gouv.fr

Hall of fame de Nokia sur sa divulgation responsable - nokia.com

F-Secure Vulnerability Reward Program - f-secure.com

The EU Cybersecurity Act at a glance, from the european commission - ec.europa.eu

Cyber Security Act de l'Article 6 Renforcement des capacités et l'Article 54 sur les Éléments des schémas européens de certification de cybersécurité - eur-lex.europa.eu

Les deux livres blanc de Yes We hack sur la divulgation coordonnées de vulnérabilités - blog.yeswehack.com

Ouriel Bettach, Data Scientist depuis plus de 6ans, nous propose un panorama de ses expériences au sein de grands groupes industriels sur des projets de machine learning (ML).

On en profite pour faire le bilan sur la façon dont les grands groupes approchent des projets ML et d’évoquer les points bloquants récurrents dans ces projets, avant d’ouvrir sur les challenges qui se dressent à l’horizon. 

Points clés ;

1. Avoir une équipe multi-compétences (Software Engineer et Data Scientist) dans une même squad permet de livrer des produits (pas simplement mener des projets) ML plus rapidement.

Références

Ouriel nous recommande le blog Towards Data Science pour se tenir au courant des dernières tendances du ML. Pour les livres, deux recommandations cette semaine, une lecture sur le data management et un classique du ML :

    - Data Management at Scale: Best Practices for Enterprise Architecture de Piethein Strengholt, ISBN 9781492054788

    - Deep Learning de Ian Goodfellow, Yoshua Bengio et Aaron Courville, ISBN 9780262035613 

En bonus, Ouriel nous recommande chaudement les interventions de Yann Lecun sur l’apprentissage profond. 

La transcription de notre discussion est disponible sur le blog du podcast Post Mortem. 

Wi-Fi Protected Access 3 (WPA3) est destiné à remplacer WPA 2 - en service depuis 2004 - en rendant presque impossible de craquer le mot de passe d'un réseau. 

Problème, des chercheurs ont révélé qu'un attaquant peut exploiter des failles dans les implémentations existantes de WPA 3 pour récupérer le mot de passe de la victime. 

Dans cet épisode, Mohamed Sabt, maître de conférence à l'université de Rennes 1 enseignant la cybersécurité et chercheur au sein de l'équipe "Sécurité et Cryptographie Embarquées" (EMSEC) nous révèle une toute nouvelle cyberattaque sur le wifi et en particulier sur la certification WPA3.

On se concentre sur le moment du serrage de main, le handshake, au cours de l'initialisation de la connection entre un appareil et le point d'accès wifi. C'est à ce moment que plusieurs implémentations du handshake Dragonfly de WPA 3 présentent des failles.

En analysant les instructions chargées dans le cache de processeurs Intel ainsi que les temps d'exécutions, Mohamed et son équipe ont réussi à déterminer quelles instructions sont exécutées ce qui permet de réduire considérablement la taille des dictionnaires à utiliser pour enchaîner sur une attaque brute force.

Mohamed nous raconte ensuite comment ils ont travaillé avec la communauté open source qui maintient ces implémentations afin de patcher ces vulnérabilités et les leçons qu'il en a tiré d'un point de vue académique et organisationnel, par exemple; Comment remonter une faille de sécurité à un projet open source?

Points clés;

1. Le temps d'exécution d'une fonction de hachage ne doit pas dépendre de la valeur du secret. Pensez aux implémentations en temps constant.

Références

Site web Dragonblood - Analysing WPA3's Dragonfly Handshake

Papier original Dragonblood: Analyzing the Dragonfly Handshake of WPA3 and EAP-pwd, par Mathy Vanhoef et Eyal Ronen.

In Post Mortem, we have engineers coming back on real-life incidents of IT systems. In each episode, we zoom on a specific event, ranging from a system outage, a cyber-attack, or a machine learning algorithm going wild with production data. We try to understand what happened, how the people behind those systems solved the situation.

Along the way, you'll get hands-on advice shared by experienced practitioners that you can implement within your team to limit the risk of such incidents.

A typical episode will have a structure similar to a post mortem document. We clarify the incident's impact, understand its root causes, what worked, and what did not go as expected in the mitigation process to learn re-usable insights that other organizations can leverage.

You can expect interviews between 30 and 50 minutes with software engineers, cybersecurity experts, and machine learning practitioners.

We plan to release one episode every other week.

The show is to premiere on October 14; stay tuned!

Sends us your feedback at @PodcastMortem on Instagram or twitter.

This episode's complete transcript is available here on our blog, The Post Mortem Podcast

C’est quoi un « post mortem » ? 

Dans cet épisode je définis le thème du podcast, on y partage des retours d’expériences sur des incidents survenus dans des systèmes informatique.

Un post mortem, d’après Wikipédia, c’est un process que l’on réalise à la fin d’un projet pour analyser ce qui a fonctionné et ce qui a moins bien marché dans un projet. L’objectif est d’en tirer des bonnes pratiques et de les partager pour éviter de répéter des incidents similaires.

Dans ce podcast, on revient, via des témoignages d’ingénieurs logiciels, sur des incidents spécifiques vécus au sein d’une équipe et comment ils y ont fait face. Je vous propose des interviews d’une trentaine à une cinquantaine de minutes, deux fois par mois.

Pour soutenir le show et ne pas louper les prochains épisodes, abonnez-vous. Vous pouvez aussi partager votre épisode préféré avec un ou une amie. Si ce podcast vous plaît, n’hésitez pas à mettre 5 étoiles et un commentaire sur Apple Podcasts, ça aide énormément pour la visibilité du show.

Vos suggestions, tant pour améliorer le show que pour proposer un ou une invitée, sont les bienvenues. Envoyez-moi un message sur Instagram ou Twitter @PodcastMortem pour qu’on en discute ensemble.

La transcription de cette épisode est diponible ici sur le blog du podcast, The Post Mortem Podcast.

Nicolas walks us through a challenging service migration he experienced at Criteo, a personalized retargeting company.

A Windows to Linux server migration was on the way for several months already when they realized that the logging backend they used was not working as expected under Linux and failed to collect metrics. 

Problem: By that time, 95% of the machine park had already switched to Linux.

Product teams relying on those metrics to run their A/B tests were using small data sets subject to noise. As critical metrics, like the  Click-Through Rate, were less abundant, business decisions were more challenging for Nicolas' internal customers.

References

Criteo's blog post Moving .NET to Linux at Scale. 

Clean Code from Robert Martin.

Nicolas' newsletter, Memes Are Eating The World