Une checklist sécurité?

#1

Bonjour tout le monde.

Cela fait plusieurs années que je souhaite devenir membre du collectif mais une chose me bloque : la sécurité.
Héberger des données, et notamment des données appartenant à des tiers, m’apparait être une lourde responsabilité.
Assurer l’intégrité de ces dernières ainsi qu’un contrôle le plus strict possible en ce qui concerne leur accès me semble être l’aspect le plus important.

Je me suis beaucoup documenté sur le sujet, et à vrai dire, j’en ressort avec encore plus d’interrogations qu’au début.
Jusqu’à présent, sur mes infrastructures de test, j’utilisais un firewall logiciel, fail2ban, portsentry, l’authentification SSH par clés, l’accès à certains services via VPN, l’utilisation de mot de passe complexe, l’authentification double facteur quand disponible …etc.

J’ai découvert il y a peut le document suivant édité par l’ANSSI. Celui-ci indique une myriade d’autres “domaines” à sécuriser et à vrai dire je ne sais plus vraiment par quel bout commencer …
Je m’aperçois également qu’un certain nombre de services s’installent avec une configuration non sécurisée par défaut.

Il y a peut d’information concernant ce domaine sur le wiki des CHATONS.
Pourrai-t-on créer une sorte de checklist concernant la sécurité, avec pour chaque point, une marche à suivre ou un/des liens vers des ressources externes ?
Auriez-vous des ressources à me conseiller ?

Bonne journée :slight_smile:

3 Likes
#2

Ce serait top d’avoir ce genre de checklist :+1: J’y vois une difficulté supplémentaire… qui est peut-être aussi paradoxalement un moyen de simplifier le problème. Tu ne vas pas sécuriser tous les services en ligne de la même façon. Ca dépend des risques auquels tu veux faire face. Dans le domaine qui m’intéresse, pour donner un exemple concret, c’est cohérent d’installer SecureDrop pour The Guardian pour recevoir les alertes sachant qu’E. Snowden s’est adressé à eux par le passé. Par contre Mediapart a estimé qu’un simple formulaire web était suffisant.

Il faudrait donc d’abord faire un modèle de menace, avec les outils et méthodes qu’on a sous la main. Et ensuite mettre en place le process de sécurité qui permet d’y faire face. La difficulté, évidement, c’est que chaque CHATONS a un modèle de menace différent (mais peut-être pas tant que ça). Et aussi que s’il est souhaitable pour un outil logiciel de publier un modèle de menace par soucis de transparence, il est peut-être sage de ne pas en publier 100% (99% peut suffire) pour éviter de macher le travail à un adversaire motivé.

C’est en partie pour simplifier ce casse tête que Enough est un CHATONS fait pour être cloné, c’est à dire qu’une organisation le déploie sur ses propres machines. Afin d’être indépendante, bien sur. Mais aussi, du coup, responsable de ses données les plus sensibles au lieu d’aller les déposer sur https://enough.community. Le modèle de menace de l’instance d’Enough est différent de celui des médias qui font tourner Enough chez eux et en tant que membre du collectif je suis bien content de ne pas avoir les contraintes associées: je me ferais un sang d’encre :scream:

4 Likes
#3

Bonsoir,

Je compte me lancer dans la rédaction de cette “checklist” :grimacing:
A votre avis, mieux vaut-il créer une page sur le wiki ou bien commencer par la rédaction d’un pad ?
Je serai d’avis de créer un pad vu que ce n’est qu’un brouillon mais je voulais avoir votre avis.

#4

Bonsoir,

Cette check-list “sécurité” est effectivement une très bonne idée et, la commencer dans un pad peut s’avérer très utile, le wiki n’étant pas vraiment fait pour recevoir des commentaires ou collaborer à plusieurs sur un même doc.

Puis, je pense qu’il faut effectivement énumérer tous les “domaines” liés à la sécurité sans pour autant entrer dans les détails mais plutôt citer des sources fiables qui permettent d’arriver à un certain niveau de sécurité.

Enfin, il conviendra de se poser la question : quel niveau de sécurité “exige” t-on de la part d’un CHATON ? Qui pour auditer/vérifier que ce niveau est atteint ? Qui pour le faire dans la durée ? Doit-on le faire ? Etc…

Autant un “CHAT” peut être “certifié” et respecter à la lettre les grands standards en terme d’organisation et de sécurité (ISO27001:2013, IEC, FIPS, IETF…), autant ce niveau sera difficilement atteignable pour un CHATON, bien que je connaisse bon nombre d’entreprises de taille moyenne qui sont certainement plus vulnérables que certains CHATONS :wink:

Bon, je réfléchis un peu tout haut là (et je partage…), toujours est-il que c’est un vrai sujet!

Les guides de l’ANSSI paraissent effectivement être de bons référentiels mais quand on les connait on constate déjà que le niveau est élevé.

A+

1 Like
#5

Bonjour @fabrice61,
Merci pour ton retour :slight_smile:

Voici le lien vers le pad : https://pad.chapril.org/p/9juvsécurité

N’hésitez pas à contribuer :smiley:

1 Like
#6

Bonjour @Nexus75 très bonne initiative,
j’ai ajouté un certain nombre de points, même si ça me paraît compliqué d’avoir une checklist à la fois assez détaillée et à jour mais essayons :slight_smile:

1 Like
#7

Super merci pour ta contribution !

Je commençais à désespérer :upside_down_face:

#8

Bonjour tout le monde :slight_smile:

Apparemment il n’est pas vraiment “bon” de garder au fond de soit ce que l’on pense, et cela peut parfois aider à avancer, alors je vais m’exprimer librement ici.

Je suis étonné de voir qu’un sujet sur “faut-il indiquer ses coordonnées sur son site”, déchaine les passions, alors qu’un sujet sur la protection des données des utilisateurs soit, selon moi, complètement délaissé.

Il me semblait que le CHATONS, Collectif des Hébergeurs Alternatifs, Transparents, Ouverts, Neutres et Solidaires, se donnait pour mission, entre autre, de décentraliser Internet, et donc d’aider un maximum de citoyens à héberger leurs données en toute sécurité, en dehors des GAFAM & cie.

La forme est importante, mais tout autant que le fond. Selon moi …

Voilà, c’était mon petit “coup de gueule”.

#9

Je sympathise sur le fait qu’il est toujours frustrant qu’un sujet n’ai pas l’écho qu’il mérite. Ce n’est pas le seul, ni le premier, ni le dernier. J’aimerais avoir une sorte de baguette magique qui change la façon dont tout le monde décide de s’intéresser à ceci ou cela mais comme ça n’existe pas j’essaye de trouver d’autres moyens d’attirer l’attention. Pousser une gueulante ça me soulage parfois même si ce n’est pas trop mon style: je crains que malgré la légitimité de ma colère cela fasse fuir plus que cela n’attire. C’est mon ressentit personnel et je ne prétend pas qu’il soit meilleur ou moins bon, juste c’est le mien a moi personnellement :stuck_out_tongue:

La sécurité étant un sujet qui m’occupe pas mal, j’y travaillerais volontiers avec toi @Nexus75. Je ne sais pas ce que tu penses de l’idée de faire un modèle de menace, comme je l’ai proposé plus haut ?

#10

Merci pour ton retour @dachary.

Malheureusement, je n’ai pas la capacité technique de réaliser un “modèle de menace” et je pense qu’il en ai de même pour un certain nombre d’actuels et de futurs CHATONS …

#11

C’est clair que la première fois que j’ai lu la page wikipedia je suis partit en courant :scream_cat: Par chance j’ai travaillé avec une personne qui m’a montré le principe et j’ai trouvé ça très abordable. J’ai aussi compris que ça allait beaucoup me faciliter la vie parce que je n’aurais pas à me protéger d’adversaires hypothétiques. Par exemple je ne veux pas que la NSA archive mes données donc je chiffre mes échanges, c’est pas du fantasme, on a des preuves :male_detective: Mais je ne vais pas me protéger contre une attaque ciblée de la NSA qui cherche a rentrer sur mon système parce que bon, faut quand même voir les choses en face, les chances qu’ils s’intéressent à moi spécialement… ce serait flatteur je dis pas mais j’ai des doutes.

Pour être plus concret, à l’échelle d’un CHATONS il peut être suffisant de faire une liste des menaces avec une grille du genre (je m’inspire de SecureDrop en traduisant). A la fin ça donne un tableur et on peut prendre les menaces les plus prioritaires et y travailler. Soit en installant des logiciels, soit en changeant les méthodes, souvent un mix des deux.

Modèle de menace

Il s’agit de faire méthodiquement la liste des risques. Pour commencer on peut mettre tout ce qui nous passe par la tête, sans trier. Et ensuite on prend chaque risque l’un après l’autre et on se demande s’il nous concerne vraiment et ce qu’on pourrait faire pour s’en prémunir.

Comme ça prend très longtemps d’être exhaustif et qu’il faut mettre ce modèle à jour régulièrement, ça vaut le coup de trier les risques les plus importants et de s’en occuper en premier. Même si on arrive pas au bout du modèle de menace, on est au moins rassuré sur le fait qu’on s’est occupé du plus pressé au lieu de se disperser dans toutes les directions.

Définir a quoi s’applique le modèle de menace

Il n’est pas possible de faire un modèle de menace abstrait, c’est un exercice pratique qui s’applique à un cas concret.

Par exemple, on peut imaginer faire un modèle de menace pour un CHATONS qui fournit un service Wekan ouvert au public. La menace pourrait porter sur l’extraction des données des utilisateurs qui sont sur ce service. Mais on pourrait, aussi à titre d’exemple, ne pas s’intéresser à ce qui pourrait rendre le service indisponible.

Evaluer la menace

Chaque menace a deux notes. Une note de base qui est calculé sans prendre en compte les parades mises en place. La not ajustée prend en compte les parades, qu’elles soient dans l’infrastructure ou dans le logiciel. On s’interesse en priorité aux menaces qui ont la note ajustée la plus forte.

Description de l’attaque

On décrit l’attaque sous la forme d’une action réalisée par un adversaire. Par exemple: Un code malicieux exposant les données des utilisateurs est injecté sur le service Wekan en exploitant une vulnérabilité de Wekan..

Impact

Quel est l’impact pour la confidentialité des données lorsque l’attaque est réussie ? La valeur peut être: faible, moyen, fort. Par exemple: Fort car un code malicieux peut extraire toutes les données.

Probabilité de réalisation

Quel est l’effort et la sophistication nécessaire pour que l’adversaire exploite avec succès cette attaque ? La valeur peut être: faible, moyenne, forte. Par exemple: Faible car Wekan est peu connu et un adversaire devrait non seulement chercher la vulnérabilité mais aussi trouver le moyen de l’exploiter. Il n’y a pas de CVE pour Wekan ni de mises à jour de sécurité sur une version stable, ce qui augmente la probabilité de réalisation mais peut etre pas tant que ça.

Note de base

Une note entre 1 et 5 que l’on attribue en comparant les menaces et en reflechissant à leur impact et leur probabilité de réalisation. Plus l’impact et important et plus la probabilité de réalisation est forte, plus la note est élevée. On peut élargir l’intervalle si besoin mais quand on a une liste de moins de cent menaces, c’est probablement suffisant. Par exemple: 4 parce que l’impact est vraiment important, même si la probabilité de réalisation est faible.

Les acteurs

C’est une liste des adversaires qui sont susceptibles de réaliser l’attaque et des personnes ou organisations qui pourraient contribuer à la réalisation d’une attaque. On distingue l’adversaire qui a la volonté de nuire d’une personne ou organisation qui réaliserait le risque par accident. Par exemple: Cracker par jeu, forces de l’ordre dans le cadre d’une enquête parce que le CHATONS n’a pas répondu à la demande de communiquer les données. Pour illustrer le cas ou une personne réalise une menace de fuite des données qui sont sous Wekan on peut aussi citer le fait de rendre public par accident un tableau wekan qui n’aurait pas du l’être.

Parades

Quelles parades sont mises en oeuvre pour réduire l’impact ou la probabilité de réalisation de l’attaque ? Par exemple: Wekan est mis à jour a chaque nouvelle version publiée par l’auteur. Il y a un risque de regression a faire cela mais cela rend le travail d’analyse d’un adversaire un peu plus compliqué. L’auteur de Wekan est incité a développer une politique de sécurité.

Il peut aussi être décidé de ne pas s’occuper de ce risque et de ne rien mettre en oeuvre. Pour reprendre l’exemple de l’utilisateur qui révèle involontairement un tableau au public, il y a bien réalisation d’un risque de fuite de données mais il n’est pas possible pour le CHATONS de déterminer s’il s’agit d’un accident ou non, on peut donc choisir de ne pas mettre en oeuvre une parade.

Parades possibles

Ce sont les parades auquelles on refléchit mais qui n’ont pas encore été mises en oeuvre.

Note ajustée

Une note entre 1 et 5 que l’on attribue en estimant l’efficacité des parades pour réduire la note de base. Par exemple: Les mises à jour régulières aident un peu mais pas tant que ça alors on passe de 4 à 3.

2 Likes
#12

Bonsoir @Nexus75,

L’initiative à l’origine de ton sujet est très intéressante, mais c’est peut-être un peu trop général et vague pour que les gens accrochent ? (Ou les gens pensent que ça va demander trop de travail par rapport à leurs dispos actuelles, ou ils se sentent pas mieux armés que toi sur ce sujet, ou plein d’autres bonnes raisons…)

Je veux bien vous aider aussi et un modèle de menace peut être une bonne piste pour définir les priorités.

Une autre possibilité pourrait être que tu exprimes plus en détail ton besoin, parce que le fait de rédiger une check-list est une solution potentielle mais il y en a peut-être d’autres pour le satisfaire et passer ta frustration ?

Par exemple peut-être que tu as besoin de te rassurer sur ce que tu as mis en place, ou pmd’être aidé sur un point en particulier, ou de mieux comprendre une point technique, ou de partager tes expériences sur le sujet, etc.

Ainsi on pourrait y voir plus clair sur par quel bout prendre ce sujet, en partant de ton besoin, ce qui permettra de faire une première étape vers cette potentielle check-list, tout en réduisant ta frustration ? (J’avoue que de mon côté j’ai pas forcément l’envie ni la possibilité de passer des heures sur ce sujet si ça doit pas t’aider juste dans l’optique que ça pourra sûrement aider d’autres un jour)

2 Likes
#13

C’est comme dans les revues de code, il y a toujours plus de monde pour commenter les petites Pull Request (demande d’intégration de code) que les grosses. Simplement parce que revoir une grosse PR, prend énormément de temps, alors que la petite est facile à traiter.

Tu le dis toi même au début du topic “à vrai dire je ne sais plus vraiment par quel bout commencer …”

Par ailleurs, tout le monde est ok pour dire qu’il faut sécuriser, alors que l’autre topic que tu pointes semble soulever des divergences de points de vue sur la question de l’anonymat d’un candidat CHATONS. C’est une question plus politique, et moins technique, donc c’est plus simple de participer. N’oublie pas qu’un CHATONS ce n’est pas que des adminsys, il y a ici des personnes qui font de la com, de l’administratif, de l’animation, du design, du dev…

Ceci dit, je pense que sur ce topic si on parle risque par risque on aura pas non plus les mêmes conclusions.

Enfin je t’encourage à prendre connaissance de la grille d’analyse des candidatures, a priori la plupart des points évoqués sont en lien avec des questions de sécurité et de fiabilité:

2 Likes
#14

Merci pour tous vos retours :slight_smile:

Je vais me pencher sur un modèle de menace, tout du moins une version simplifiée m’inspirant du post de @dachary.
Même si ça peut être long, il me semble que c’est une bonne manière de mettre en place des contre-mesures adaptées à l’architecture ainsi qu’aux types de services qui tournent sur la/les machines de façon systématique.
Je vais également me fier à la liste de conformité des CHATONS.

Je vous ferai part de mes avancées :slight_smile:

1 Like