Savoir poser les bonnes questions

le 08/10/2009 à 22:32
Savoir poser les bonnes questions
Une mauvaise réponse est souvent causé par une mauvaise question. Cette question peut être poser par des développeurs pour des très bons développeurs où encore des utilisateurs vers des développeurs.

Mike Bernat a écrit sur son blog un article concernant ce sujet, car souvent on trouve dans les différents forums, de nombreuses questions qui ont été déjà posés, où bien encore votre question n'est pas assez détaillée.

Il ne faut pas avoir peur de mettre un maximum de détails, même si ceux sont des choses erronés, c'est pour cela qu'il faut lire son article très complet car il sera très utile pour tous les programmeurs et programmeuses, même en PHP.

- How Do GOOD Developers Ask Questions

A lire également

C'est un peu dans une atmosphère de cantina de Star Wars que La cantine à Paris organisait ce jeudi le faux procès d'un hacker. Le but était alors d'expérimenter un cas pratique tiré de réelles expériences sur le sujet de la communication de failles de sécurité. Un hacker était donc sommé de s'expliquer pour avoir dévoilé une vulnérabilité sur des appareils respiratoires d'un hôpital.Pour rappel, le full disclosure est un principe qui prévoit une divulgation publique d'un problème de sécurité connu. Dans le cas de cette parodie de justice clairement assumée, chaque représentant défendait son point de vue. Occasion était donc donnée de cibler les manques en matière de régulation mais également de compréhension du sujet.

Concrètement, une faille a donc été découverte dans un logiciel contenu dans un respirateur officiel d'un hôpital. Le hacker transmet ses informations mais, estimant qu'aucune réponse n'est apportée, il communique alors les détails sur Twitter puis la Presse reprend l'information.

Dès lors, l'hôpital estime subir des dommages du fait de la publication de cette faille. Premier témoin appelé à la barre, Eric Filliol, expert en sécurité à l'ESIEA. Une main dans la poche, il donne un aperçu du monde de la sécurité et des failles : « La sécurité se fait a posteriori, c'est ainsi que fonctionnent les connaissances. On ne peut boucher des failles que lorsqu'on les connaît. C'est un peu comme un sonar qui envoie un écho radar pour détecter un sous-marin ».

Rapidement le tribunal se pose la question de savoir s'il y a eu ou non intrusion dans un système informatique. La qualification est des plus difficiles car il n'y a pas eu de modification de l'état du système. De même, le tribunal de Grande Instance a déjà estimé qu'une découverte de faille via un simple navigateur (comme c'est le cas ici) ne constitue pas une intrusion.

Enfin le juge et le jury populaire ont dû trancher sur les deux faits reprochés à l'accusé : mise en danger de la vie d'autrui puis le fait de s'être maintenu dans un système d'information. Pour cela, la salle doit répondre à trois questions. Y-a t-il eu intrusion dans un système informatique, la salle estime à une large majorité que non au motif que la faille était connue. Avait-il un motif légitime pour dévoiler la vulnérabilité, l'assemblée pense que non. Pour autant, le jury lui accorde la « nécessité d'agir » car la faille concernait des appareils censés conserver en bonne santé des malades. Le jury a donc fait le choix de relaxer le prévenu.

Ce faux procès digne du tribunal des flagrants délires agrémenté de la rectitude toute juridique et de quelques morceaux de mauvaise foi des spécialistes en sécurité dans la salle à eu le mérite de poser les bases du débat sur la notification des failles de sécurité.

La France brille en effet par un certain vide en la matière. Pire, ce cas pratique a montré le manque de communication et surtout de compréhension entre celui qui rapporte la faille et celui qui en est victime.

Commentaires

Ecrire

Ecrire un message

Votre message vient d'être créé avec succès.
LoadingChargement en cours