Politique de sécurité

Bonjour à tous,

Jusqu'à présent, en interne, nous disposons d'une conversation privée pour discuter des failles découvertes au jour le jour tant au niveau de l'infrastructure que du logiciel. Cependant, des questions se posent de plus en plus pour savoir si c'est la bonne manière de faire pour communiquer autour de la sécurité. Pour tout un tas de raison, ce sujet fait son apparition pour discuter sur cette politique de sécurité et savoir comment réagir à la découverte d'une faille.

Pour situer tout le monde dans le contexte, une faille peut donc être à la fois logicielle que sur l'infrastructure. Il peut y avoir une dépendance du projet à mettre à jour (récemment, c'était Pillow et Django) suite à des failles sur ces dépendances. Il peut aussi y avoir des failles logicielles comme en témoigne cette issue sur le bug tracker public de Zeste de Savoir. Aujourd'hui, nous vivons dans un monde fait de bizounours. Elle est loin l'époque où une modération stricte était appliquée sur le feu Site du Zéro. Cependant, nous ne sommes pas à l'abri de voir demain une attaque grâce à l'une de ces failles.

Ce sujet veut donc statuer sur la manière de communiquer à propos de ces failles.

• Faut-il rester dans un contexte privée ? Ou faut-il reporter les failles sur le bug tracker public du projet ?
• Est-ce qu'un MP sur cette instance de la plateforme Zeste de Savoir n'est pas limite pour reporter les bugs ?
• Est-ce qu'une mailing list n'est pas plus appropriée avec un accès en lecture pour un groupe de personnes restreintes ?
• Une fois une faille détectée, comment réagir si c'est une faille sur l'infrastructure ou sur le logicielle ?
• Comment mettre au courant (en toute discretion), les développeurs pour qu'ils proposent un fix ?

Toutes ces questions doivent trouver des réponses parce que nous n'avons pas encore des attaques mais des failles nous en avons. Il n'y a qu'un pas à franchir pour avoir des attaques demain.

Je suis un peu étonné que la conversation aie dérapé sur l'issue que tu met en lien. Oui c'est une faille, mais au pire l'auteur détruit son propre historique de validation, tant pis pour lui, rien de "grave" là dedans. Soit, c'est pas la question ici. Il y a d'autre faille du genre qui ne méritent pas le "secret" à proprement parler. On ne peut rien faire non plus contre les failles sur des dépendances du projet, à part pousser la MàJ le plus vite possible : elles sont annoncées au public, donc rien de "secret" là dedans non plus, et un hacker mal intentionné dispose de toute façon du laps de temps qu'il nous faut pour réagir pour exploiter la faille.

Mais pour le reste (là ou on peut faire quelque chose et ou effectivement il y a matière à discussion, voir paragraphe du dessus), nous vivons effectivement dans un monde de bisounours. Pour moi, un MP, c'est pas la bonne solution : tout les devs concernés ne sont pas forcément au courant (il suffit d'en oublier un). Un forum "dev" privé pour ce genre de cas serait à la limite acceptable, mais il faut penser à le consulter. Éventuellement aussi un big MP "failles de sécurités", dont la liste des auteurs serait mise à jour en fonction de l'état du dev', parce qu'au moins ça génère une notif à chaque fois. L'option "mailing list" existe aussi.

Ou je veux en venir : je suis pour un peu de "privé" en ce qui concerne des bugs "sensibles", mais j'ai pas de bonne solution à proposer.

Hello,

Voici ce que j'en pense :

Faut-il rester dans un contexte privée ? Ou faut-il reporter les failles sur le bug tracker public du projet ?

Il faudrait rester dans un contexte privé au début, puis éventuellement communiquer les vulnérabilités une fois qu'elles sont corrigées. Au niveau communication, ça peut peut-être mettre en confiance les utilisateurs au vu de notre réactivité.

Un utilisateur intelligent est conscient que le risque zéro n'existe pas et que les bogues exploitables (failles, vulnérabilités) sont omniprésentes. Donc possiblement sur ZdS. L'important, c'est de les corriger rapidement.

Est-ce qu'un MP sur cette instance de la plateforme Zeste de Savoir n'est pas limite pour reporter les bugs ?

Bonne question. Est-ce qu'on dispose d'un bug tracker privé ? Et faut-il réellement signaler les bogues susceptibles d'impacter la sécurité de ZdS de manière privée ? J'aimerais votre avis là-dessus.

Est-ce qu'une mailing list n'est pas plus appropriée avec un accès en lecture pour un groupe de personnes restreintes ?

Des personnes restreintes, cela va de soi. Mais quand tu dis accès en lecture, tu omets l'accès en écriture pour certains d'entre eux ? Dans cette liste je verrais au moins SpaceFox et firm1.

Une fois une faille détectée, comment réagir si c'est une faille sur l'infrastructure ou sur le logicielle ?

Appliquer le correctif au plus vite : mise à jour des dépendances si ça concerne l'infrastructure, sinon corriger le bogue au plus vite (il faut évaluer la priorité en fonction de l'impact du bogue aussi…).

Comment mettre au courant (en toute discretion), les développeurs pour qu'ils proposent un fix ?

Tu as évoqué la mailing-list. J'ai évoqué l'utilisation d'un bogue tracker privé. Le tout est d'avoir un outil simple et accessible, sans prise de tête supplémentaire par rapport à ce qu'un bugfix pourra nous causer.

Très bonne initiative en tout cas !

Pour moi, une faille doit rester privé. N'étant pas trop fan de la multiplication des entrées possibles de déclaration de bug (github, forum dev zone, forum bug et suggestion, mailing list, etc.) j'ai toujours envie de dire en première approche "si on utilisait un vrai bugtracker, ce genre de problème ne se poserait pas".

Vu qu'on a toujours pas trouvé le bugtracker qu'il nous faut, je dirais qu'on peut demander à ceux qui trouvent des failles de l'envoyer à l'adresse centrale (celle gérée par la comm). On créerait donc un forum privé pour les devs (en fait c'était à l'origine le but du forum Dev Zone) et c'est sur le forum qu'on discuterait de la résolution des failles.

Je dis ça, car c'est beaucoup plus pratique et lisible les discussions sur le forum que via une mailing list.

En tout cas merci pour ce topic. J'ai refait les comptes, je crois qu'on a au moins 5 failles un peu critique sur le site.

En tout cas merci pour ce topic. J'ai refait les comptes, je crois qu'on a au moins 5 failles un peu critique sur le site.

ne les connaissant pas, je ne peux pas aider.

Merci artragis d'exposer merveilleusement bien le problème actuel.

Dans les réponses de Ge0 et firm1, l'idée d'un bug tracker privé se dégage. Sommes-nous d'accord pour dire qu'il devient urgent de statuer aussi sur le bugtracker qui nous convient le mieux ? Parce que les autres solutions me semblent bien lourdes comme :

Vu qu'on a toujours pas trouvé le bugtracker qu'il nous faut, je dirais qu'on peut demander à ceux qui trouvent des failles de l'envoyer à l'adresse centrale (celle gérée par la comm). On créerait donc un forum privé pour les devs (en fait c'était à l'origine le but du forum Dev Zone) et c'est sur le forum qu'on discuterait de la résolution des failles.

Ca veut dire qu'il faut communiquer sur le fait de communiquer les failles à l'adresse e-mail de communication. Que cette équipe doit répertorier toutes les failles rapportées dans un forum privé et de maintenir un listing de développeurs de "confiance" (TODO: donner une définition pour ce dernier terme) pour corriger les bogues.

Pour moi, cette solution n'est pas envisageable. Le process est bien trop lourd et il faut garder une rigueur constante.

Mon avis sur la question :

Faut-il rester dans un contexte privée ? Ou faut-il reporter les failles sur le bug tracker public du projet ?

Une faille = privé. Point. A la limite si elle est jugée "pas grave" (cf celle de l'exemple que tu donnes, qui permet au pire de dégager l'historique de validation de ses propres tutos uniquement), elle peut être re-postée en public.

Est-ce qu'un MP sur cette instance de la plateforme Zeste de Savoir n'est pas limite pour reporter les bugs ?

Si. D'ailleurs "un MP à qui ?". C'est tout sauf une bonne solution, on doit en trouver une autre.

Est-ce qu'une mailing list n'est pas plus appropriée avec un accès en lecture pour un groupe de personnes restreintes ?

Dans la mesure où c'est la solution généralement utilisée (par Django ou Wordpress, par exemple), ça me paraît être une solution efficace et robuste.

Le premier et principal intérêt de la ML est qu'il permet à n'importe qui de déclarer simplement une faille. Après, on peut tout à fait avoir un outil tiers (bugtracker, forum privé, …) pour en discuter entre gens de confiance.

A noter que cette adresse n'est pas celle de la comm'. C'est une adresse dédiée qui prévient directement les personnes concernées.

PS : Par contre, je n'ai vu personne utiliser un bout de bugtracker privé pour gérer ses failles. En tous cas, ce bugtracker s'il existe n'est pas exposé au public.

Une fois une faille détectée, comment réagir si c'est une faille sur l'infrastructure ou sur le logicielle ?

• Faille sur l'infrastucture : mise à jour de l'élément problématique (je l'ai déjà fait plein de fois, je suis abonné à la liste de sécurité Debian). Si c'est un élément dans l'un des fichiers requirements.txt, mise à jour de ce fichier via une procédure de hotfix (cf le git flow standard).
• Faille sur le logiciel (i.e. ZdS la plate-forme, donc notre code) : il faut qu'on trouve un moyen de la corriger rapidement en fonction de sa criticité. Donc procédure de hotfix.

Je rappelle en 3 mots la procédure de hotfix :

1. Tirer une branche depuis prod
2. Corriger
3. Tester - en préprod si y'a un risque de régression majeur
4. Merge dans prod et dans dev

Il n'y a pas de PR dans cette liste, sauf éventuellement en cas de conflit lors du merge dans dev.

Comment mettre au courant (en toute discretion), les développeurs pour qu'ils proposent un fix ?

Les développeurs de confiance devraient être dans la liste de gens au courant dès qu'il y a une faille (ex : la mailing list). Si vraiment personne ne sait corriger une faille… on fera appel à un autre dev de confiance. Mais à voir si le cas se présente un jour.

En tout cas merci pour ce topic. J'ai refait les comptes, je crois qu'on a au moins 5 failles un peu critique sur le site.

Outre que j'ai du mal avec la notion de "un peu critique" (ça veut dire quoi ?), je m'étonne de ne pas encore les voir dans le MP "problèmes de sécurité" dont toi et moi (entre autres) faisons partie.

Il faudrait rester dans un contexte privé au début, puis éventuellement communiquer les vulnérabilités une fois qu'elles sont corrigées. Au niveau communication, ça peut peut-être mettre en confiance les utilisateurs au vu de notre réactivité.

J'aime bien cette idée de communiquer les vulnérabilités corrigées – par contre je ne sais pas trop comment.

J'aime bien cette idée de communiquer les vulnérabilités corrigées – par contre je ne sais pas trop comment.

Selon la nature de la faille ça peut aller d'un simple poste dans le forum de où tu as l'habitude d'avertir des mises en prod jusqu'à un article qui détaille la faille, le pourquoi, la criticité, une estimation des personnes vulnérables… on est sur un site de partage de la connaissance, ça peut faire partie de ladite connaissance, non?

Je n'ai pour l'instant pas pris part au développement, donc mon avis n'a pas forcément d'importance ou de poids, mais d'un point de vue utilisateur, je suis totalement d'accord avec SpaceFox. Un utilisateur n'a pas besoin d'être au courant d'une faille de sécurité sur le site, au moment où elle est découverte. Au contraire, ça serait pour moi une raison de perte d'affluence (côté peu "pro"). En revanche une communication sur :

• le moment et la façon de la découverte
• les données impactées par cette faille (mon adresse email a-t-elle pu être leakée ? mon mot de passe ?)
• la procédure qui a été mise en place pour corriger la faille
• des p'tites stats histoire de s'astiquer un peu (on a corrigé la faille en X jours), c'est un peu flatteur.

Avis perso, je préfère voir un fix retardé de quelques heures/jours parce qu'on a dû appliquer un process, plutôt qu'un fix posé dans la précipitation, qui pourrait avoir d'autres dégats collatéraux.

Juste pour rebondir sur un point : surtout pas un MP, surtout pas un forum dev.

Il faut un canal de communication externe au site pour les devs certes utile en cas de faille mais surtout en cas d'attaque.

Si jamais le site est down (via exploitation d'une faille) et que l'info concernant ladite faille a été signalée voire discutée 30 minutes plus tôt dans le MP en question, c'est super dommage d'être coupé de la discussion, de reprendre à zéro avec les différents souvenirs des gens qui ont eu vent de la faille (et qui avec un peu de bol sont partis boire une bière entre temps).

Je pense que la mailing list est importante. Beaucoup de gens ont accès à leurs mails depuis leurs téléphones, sont capables ne serait-ce que de glisser un "je m'en occupe en rentrant" etc. dans le cas d'une vulnérabilité critique. (si on essaie de parer les cas les plus catastrophiques).

A mon avis c'est crucial que l'historique des discussions concernant la sécurité du site, ses failles connues, résolues, ses vulnérabilités soient archivé ailleurs que sur le site lui-même.