[AMA] Sécurité chez Finary, posez-moi vos questions!

Bonjour à tous,

J’ai rejoint il y’a plusieurs mois l’équipe Finary pour prendre en charge la cybersécurité (intro). Mon rôle consiste à veiller à ce que nos systèmes et vos informations sensibles soient protégés de manière optimale, et à réduire les risques potentiels.

Si vous vous demandez comment nous gérons ce sujet ou si vous avez des préoccupations concernant votre sécurité personnelle et cherchez des idées pour l’améliorer, n’hésitez pas à utiliser ce thread pour poser vos questions.

Je ferai de mon mieux pour répondre de manière claire et efficace. Certaines informations sur Finary doivent rester confidentielles pour des raisons évidentes de sécurité, mais je m’engage à partager autant de details utiles que possible :handshake:

11 « J'aime »

Bonjour et merci.
Je ne sais pas si ca relève directement de la cybersecurité, mais outre l’engagement répété de @mounir, qu’est ce qui garantie que les données clients ne seront jamais utilisées dans un but commercial par Finary ? Ou revendues ? Ou détournées en interne comme en externe ?

En effet rien à voir

Bonjour Mence et merci,

Je voudrais savoir où sont stockées nos informations et nos données ? Quel prestataire ? En France ? En Europe ? Ailleurs ? Les réplications sont où ?

Pour le besoin de vos traitements comment sont anonymisés nos portefeuilles ? Le sont-ils ?

Avez-vous réalisé un audit de votre infrastructure IT ?

Le code de l’application est-il audité ?

Suivez-vous vos vulnérabilités ?

J’aurai un tas d’autres questions mais c’est de la déformation pro !

Merci à toi !

3 « J'aime »

Bonjour @Botrytis,

Je voudrais savoir où sont stockées nos informations et nos données ? Quel prestataire ? En France ? En Europe ? Ailleurs ? Les réplications sont où ?

Notre plateforme principale est hébergée chez Google Cloud Platform (GCP), en région Europe, y compris les réplicas et les sauvegardes (sur des zones différentes des primaires). On a fait en sorte de ne pas pouvoir créer d’asset ailleurs qu’en Europe, même par erreur.

Pour le besoin de vos traitements comment sont anonymisés nos portefeuilles ? Le sont-ils

Je ne sais pas si c’est exactement la réponse que tu attends, mais vos données financières sont « physiquement » décorrélées de vos données d’identification, le seul lien est un id (parce qu’il faut quand même qu’on puisse rattacher un portefeuille à un utilisateur à un moment). Tout ce qui traite les données ne connait que les chiffres.

Avez-vous réalisé un audit de votre infrastructure IT ?
Le code de l’application est-il audité ?

Oui, nous faisons réaliser minimum un audit de sécurité par an, plateforme et code (le dernier date d’Avril et n’a rien soulevé de critique). Nous avons également un programme de bug bounty privé pour avoir des remontées potentielles au fil de l’eau.

Suivez-vous vos vulnérabilités ?

Oui nous avons des outils en place au niveau de nos repositories pour détecter et/ou monitorer des vulnérabilités du code, des dépendances et des images de base des containers.

J’aurai un tas d’autres questions mais c’est de la déformation pro !

Je peux tout à fait comprendre :smiling_face:

2 « J'aime »

Notre plateforme principale est hébergée chez Google Cloud Platform (GCP)

ok, c’est déjà mort: https://noyb.eu/files/CJEU/EU-US_form_v3.docx

Google est soumise au FISA 702 ce qui leur impose de mettre à disposition sous demande des agences USA toutes les données à leur disposition (y inclus sa subsidiaire irlandaise). Le fait que les données soient stockées en Europe par une de se subsidiaires ne constitue donc pas une garantie suffisante au sens du RGPD.

Pour en savoir plus (facebook rentre aussi dans le FISA 702):

ou (specifique à google analytics mais ça rend bien l’idée du problème):

Oui, nous faisons réaliser minimum un audit de sécurité par an, plateforme et code (le dernier date d’Avril et n’a rien soulevé de critique)

Sympa de le savoir mais pas mesurable : pour cela faudrait avoir accès aux résultat et savoir ce qui a été audité, comment et les résultats.

Certaines informations sur Finary doivent rester confidentielles pour des raisons évidentes de sécurité

The United States National Institute of Standards and Technology (NIST) specifically recommends […] and they state, “system security should not depend on the secrecy of the implementation or its components

Alors oui, on va pas demander d’avoir le mot de pass d’admin mais dans mon expérience le « security through obscurity » est utilisé dans la majorité des cas pour masquer une politique qui ne privilégie pas la transparence, surtout quand utilisé en avance et pas en cas-pas-cas.

Ceci-dit, ça reste un problème très compliqué car de nature de diplomatie internationale et avec des enjeux économique monstruex: d’un coté les US qui réclame touts droits sur les données auxquelles ils peuvent accéder peu importe leurs provenance, de l’autre coté l’UE qui impose que les données de ses citoyens soient protégées selon certains critères; ceci mène à un macro-problème économique: ces données représentent la matière 1ère nr 1 des chiffres d’affaires plus importantes aux US: pour un facebook ça reste rentable de payer des amendes à 10 chiffres mais si ça continue à monter ça va créer des fortes tensions US-EU (et peut-etre créer des opportunités pour des nouvelles offres alternative auxquelles les entreprises EU pourront faire référence car pas vraiment d’alternative viable aujourd’hui sauf créer sa propre infra).

Bon courage, c’est un rôle chargé en responsabilité et complexité, et merci pour avoir ouvert la conversation!

5 « J'aime »

Merci pour ce retour et courage pour la suite

1 « J'aime »

Certes et ils ne se privent pas de regarder/indexer les data.
Mais est-ce que ça les intéressent de savoir que tu as un fond euros ou un ETF ?
Et si ce sont tes data perso qui t’inquiètent ils savent déjà (gmail, linkedin, facebook,…)

Voici les quelques questions que je me pose :
Combien de personnes chez Finary (et prestataires éventuels) ont accès aux données des utilisateurs et peuvent à partir d’un nom accéder au patrimoine d’un client ?
Etes-vous en capacité de détecter immédiatement si une personne interne à l’entreprise accède à ces informations sans autorisation. Surveillez-vous aussi les personnes autorisées pour le cas où leurs accès auraient été compromis ? A ce sujet, Quelle est la politique d’authentification de ces personnes (double/triple auth) ?
En cas de piratage, quelle sera la politique de communication de Finary ?

3 « J'aime »

Bonjour Adrien !

En soit la sécurité des données (personnelles ou non) relève bien entendu de la cybersécurité, et de son amie proche : la conformité, je vais tâcher de t’apporter une réponse décortiquée :

« qu’est ce qui garantie que les données clients ne seront jamais utilisées dans un but commercial par Finary ? » => Tout dépend de ce que l’on appel but commercial, Finary peut tout à fait envoyer des mails à ces utilisateurs pour mettre en avant son offre Finary Plus (et donc une offre commercial), ainsi que pour mettre en avant les futurs Finary talk par exemple.

« Ou revendues ? » => Ici c’est une politique interne de Finary, nous ne souhaitons pas vendre les Données à Caractères Personnelles (DCP) ou autres données à des tiers, de plus, le RGPD (et la CNIL) nous rappel cependant que nous devons obtenir le consentement des utilisateurs de Finary afin de pouvoir revendre notre fichier de clients actifs. De plus l’acquéreur du fichier devra ensuite informer les personnes dont les données ont obtenu de cette façon.

« Ou détournées en interne comme en externe ? » => Ici le RGPD nous rappelle que le détournement de finalité du traitement d’une DCP est une infraction. Exemple : Finary collecte l’adresse email de ses utilisateurs pour leur adresser un newsletter. Nous ne pouvons pas revendre cette DCP à un tiers, ce n’est pas la même finalité initiale.

A dispo pour continuer la conversation,
Florimon

5 « J'aime »

pour info: une bonne partie des questions que tu poses sont réglementées par la loi (principalement RGPD).

Par exemple ce qui doit se passer en cas de de fuite est réglé par les art 33 (notification à l’autorité: CNIL en France) et part l’ar 34 (notification aux utilisateurs).

La difficulté majeure (pour les responsables de données) est d’être certains que les données soient bien labellisés pour après définir qui peut avoir accès à quoi: selon la loi il ne doit pas y avoir possibilité d’accès sans autorisation.

Dans la réalité après ça se passe autrement (surtout en France, car la CNIL s’occupe sérieusement que d’une dizaine de gros cas qui apportent bcp d’€€€ et ne donne pas de réponse sur des milliers d’autres): plein de petits/moyens jugements sont passés et malgré une reconnaissance de l’illégalité du (mode de) traitement, il n’y a pas eu d’amende, juste un petit rappel. Cela commence à changer grâce aux associations qui font recours au niveau Européen (avec rappels/amendes aux autorités des Pays) et qui maintenant peuvent et représenter un individu et faire des sortes de « class action ».

C’est surtout des questions qu’il faut pas poser aux entreprises mêmes de manière « je demande une info » mais selon les modalités du RGPD qui prévoit tout ce que la réponse doit inclure et dans quel délai/modalité car si on fait pas appel aux bons articles, ils ne considèrent (légitimement) pas ça comme un exercice de ses droit mais comme une simple demande d’info.

Pour qui souhaite en savoir plus:

Bonjour @AlexIT,
Je laisse @Florimon te répondre sur la partie FISA/RGPD

Oui, nous faisons réaliser minimum un audit de sécurité par an, plateforme et code (le dernier date d’Avril et n’a rien soulevé de critique)
Sympa de le savoir mais pas mesurable : pour cela faudrait avoir accès aux résultat et savoir ce qui a été audité, comment et les résultats.

Certaines informations sur Finary doivent rester confidentielles pour des raisons évidentes de sécurité
The United States National Institute of Standards and Technology (NIST) specifically recommends […] and they state, “system security should not depend on the secrecy of the implementation or its components
Alors oui, on va pas demander d’avoir le mot de pass d’admin mais dans mon expérience le « security through obscurity » est utilisé dans la majorité des cas pour masquer une politique qui ne privilégie pas la transparence, surtout quand utilisé en avance et pas en cas-pas-cas.

Pour répondre à ces deux points :

Pour moi, “security through obscurity” c’est obfusquer la bannière de ton server web en espèrant leurrer des outils automatisés, ou avoir nommé de façon random tous tes sous-domaines en priant pour que personne ne les trouve - ne pas révéler des details d’architecture ou un rapport d’audit contenant des informations potentiellement sensibles sur un forum public, c’est juste du bon sens :slight_smile:
Je comprends ton point, mais pour moi il y’a un degré de détails différent à donner entre un auditeur, un partenaire et en « public ».

5 « J'aime »

Bonjour @Sebastien,

Combien de personnes chez Finary (et prestataires éventuels) ont accès aux données des utilisateurs et peuvent à partir d’un nom accéder au patrimoine d’un client ?

On parlait de niveau de détail précedemment suite à la réponse d’@AlexIT et cette question est un très bon exemple : te donner un nombre exact, voire les fonctions des personnes en question, augmente le risque de faire d’eux des cibles. Ce que je peux te dire c’est que seules certaines personnes clés de l’entreprise ont accès aux informations correlées, et n’y accèdent que suite à une demande utilisateur.

Etes-vous en capacité de détecter immédiatement si une personne interne à l’entreprise accède à ces informations sans autorisation. Surveillez-vous aussi les personnes autorisées pour le cas où leurs accès auraient été compromis ?

Tous les accès aux données sont restreints, loggués et monitorés

A ce sujet, Quelle est la politique d’authentification de ces personnes (double/triple auth) ?

La MFA est obligatoire pour toute la team sur l’ensemble des outils que nous utilisons, avec une clé de sécurité physique partout ou c’est supporté (et c’est supporté sur tous les outils critiques).

En cas de piratage, quelle sera la politique de communication de Finary ?

L’ honnêteté.

4 « J'aime »

Merci pour tes réponses mais je sens une faille. Utilisez vous des systèmes MFA suffisamment robustes pour que la compromission d’un individu ne suffise pas à accéder aux données ? En clair, utilisez-vous des systèmes à multiples signatures pour qu’un individu seul ne puisse jamais accéder aux données ?

le MFA s’occupe (exclusivement) d’authentifier l’utilisateur, pas de ce qui se passe après; si un utilisateur est compromis (quelqu’un de tiers a réussi à se faire passer pour lui), ce n’est plus dans le champ de la MFA (mais dans d’autres).

MFA: Multi Factor Authentication; C.A.D qui requiert au même temps la disponibilité de plusieurs méthodes d’auth :

exemples:

  • mot de passe + code sur dispositif qui créé une clé temporaire (style RSA SecurID)
  • pin + texto envoyé par sms

c’est la définition de M(ulti)FA: avec le seul mot de passe/pin ou code temporaire (RSA ou SMS dans les exemples), la personne ne peut pas s’authentifier.

pour qu’un individu seul ne puisse jamais accéder

Pas compris. Justement, l’MFA a pour but de permettre seulement à un seul individu (la personne qui détient les moyens d’authentification) d’accéder.

1 « J'aime »

Utilisez vous des systèmes MFA suffisamment robustes pour que la compromission d’un individu ne suffise pas à accéder aux données ? En clair, utilisez-vous des systèmes à multiples signatures pour qu’un individu seul ne puisse jamais accéder aux données ?

Je ne suis pas sûre de comprendre ta question : si tu penses à des systèmes comme Vault où plusieurs clés sont nécéssaires pour dévérouiller et déchiffrer les données - nous ne procédons en effet pas de cette manière, mais ca n’est pas toujours possible de transposer ce modèle aux technologies que nous utilisons.
Le management des postes de l’équipe (updates, tooling et paramètres de sécurité) et la MFA avec clé physique réduisent de façon significative le risque de compromission d’un membre de la dite équipe.
Nous appliquons ensuite des principes de zero-trust et de defense-in-depth (pardon aux amoureux de la langue française mais je trouve que ca se traduit mal) : ce n’est pas parce qu’un utilisateur a passé une étape d’authentification que c’est openbar sur toute la plateforme ou les outils. Il y’a plusieurs niveaux de contrôle dépendemment de l’action à effectuer, et personne n’a plus de droits que nécessaires pour effectuer ses tâches quotidiennes.

Je ne dis pas qu’on est totalement sécurisés, parce que cela n’est pas possible. Nous avons des choses (non critiques) à améliorer dont nous sommes conscients, et très probablement des inconnues. Par contre nous mettons en place les contrôles nécessaires pour garantir le minimum de risque pour vos (et nos) données, et travaillons en permanence à renforcer notre posture de sécurité et à réduire notre surface d’attaque.

6 « J'aime »

Dans mon entreprise, on utilise aussi des clés physiques mais il y a des règles à « multiples signatures »,
Par exemple, pour s’authentifier et ouvrir une session, il faut au moins 2 personnes présentes dans l’équipe. Pour l’accès à certaines données, on a besoin qu’un administrateur soit authentifié. Des choses comme ça.

Je ne dis pas qu’on est totalement sécurisés, parce que cela n’est pas possible. […] Par contre nous mettons en place les contrôles nécessaires pour garantir le minimum de risque pour vos (et nos) données, […] et à réduire notre surface d’attaque.

Là je suis fan et je félicite qui a embauché @Mence : perso je trouve ça très rassurant :+1:

La seule manière de garantir le zero risque d’attaque informatique est de mettre le système en question dans un coffre-fort fermé (bien entendu sans qu’il soit connecté à quoi que ça soit, même pas l’électricité): se méfier de qui dit le contraire car soit il/elle n’a pas la compréhension du sujet, soit il/elle l’a et ment volontairement :slight_smile:

La meilleure manière de faire face à la (in)sécurité, comme Mence le dit, est d’être conscient(e) des risques et faire le max pour les réduire, pas de les ignorer; et ça, c’est un sacré boulot non seulement à faire mais aussi à faire comprendre :clap:

5 « J'aime »

Totalement en accord avec tes réponses, mis à part sur ce point :

(pardon aux amoureux de la langue française mais je trouve que ca se traduit mal)

Défense en profondeur, c’est très bien et le modèle « Zero Trust » fait partie de la défense en profondeur

1 « J'aime »

@Mence, je rencontre un problème qui est peut-être dans ton champ d’expertise.
J’investis en startup et certaines de ces startups ne communiquent pas sur leur levée pour des raisons stratégiques.

Voici mes points avec Finary:

  • Quand je rajoute une startup, on me propose souvent une liste et parfois dans cette liste, je retrouve des startups qui ont demandé explicitement à ne pas communiquer. J’imagine que d’autres utilisateurs ont créé la startup et quelle rentre alors dans la liste. Votre outil étant de plus en plus utilisé, cela permet à leurs concurrents de facilement savoir s’ils ont fait des levées de fonds et même à quelle date s’ils sont organisés. voire même avant que le deal ne soit fait. Avez-vous des solutions pour protéger ces informations ?

  • Le personnel qui prend en charge le support est-il contractuellement engagé à ne pas communiquer d’informations. J’entends des contrats de type NDA avec sanctions en numéraire très dissuasives ou bien s’agit-il uniquement d’une clause de secret professionnel classique à l’engagement ?