Serveur d'impression

Comment nous pouvons opérationnaliser la confidentialité et la conformité – Bien choisir son serveur d impression

Le 5 décembre 2019 - 52 minutes de lecture

Transcription

Yang: Nous allons parler aujourd'hui de "Comment aider les développeurs à protéger leurs données". Je vais simplement dire que ce sur quoi nous travaillons actuellement, c’est toujours en mode furtif, alors je ne vais pas trop en parler. Je vais passer la prochaine heure à régler le problème, de sorte que vous avez également une bonne idée de la façon de le résoudre vous-même lorsque vous rentrerez chez vous aujourd’hui.

Nous sommes ici aujourd'hui parce que la protection des données est importante maintenant. Je pense que lorsque cette lourde amende de 5 milliards de dollars a frappé Facebook, les amendes récentes de Marriott et celle de British Airways, les gens ont commencé à prendre cela très au sérieux. Avant cela, j'avais des amis très intelligents qui disaient: "Jean [Yang]"Tout cela va juste exploser." J'étais, "Je ne pense pas." Il ne s'agit pas seulement des amendes, mais également des atteintes à la réputation. Quelqu'un qui dirigeait la vie privée dans une assez grande entreprise a déclaré L'année dernière, ils n'ont pas peur des régulateurs, ils ont peur de ce que les consommateurs vont penser. Je travaille dans ce domaine depuis plus de 10 ans et j'ai même été surpris de voir à quel point les gens se souciaient du dernier scandale sur Twitter. .

Il y a quelques années, personne n'aurait vraiment pensé que Twitter utilisait des numéros de téléphone à deux facteurs pour les publicités. Dans le même temps, peut-être surtout parce que le GDPR force tout le monde à signaler, il est devenu très clair que même les chefs de file de l'industrie souffrent de problèmes apparemment évitables. L'année dernière, nous avons vu beaucoup de grandes entreprises souffrir de fuites de mots de passe en clair. Je reviendrai plus tard au cours de cet entretien sur la raison pour laquelle cela se produit si souvent. Quand j’ai entendu parler de ce problème pour la première fois (j’étais venu du monde universitaire auparavant), j’étais: «Attendez, les gars, c’est résolu maintenant, n’est-ce pas?

Combien d'entre vous souffrent encore de ce problème dans vos organisations? C'est en fait assez bon parce que je pense qu'un grand nombre de personnes dans les plus grandes entreprises avec lesquelles je discute se disent: "C'est juste un gâchis total". Je suis ici aujourd'hui parce que personne n'est devenu ingénieur pour passer tout son temps à rechercher des mots de passe égarés, des emplacements, combien de fois j'ai écouté Miley Cyrus ce matin – ne le demandez pas. Nous voulons vraiment aider les ingénieurs à se concentrer sur l'essentiel.

Il y a cette chose que je vais appeler la lacune logicielle. D'un côté, vous avez des régulateurs, des responsables de la conformité, des consommateurs qui disent: "Le logiciel devrait faire cela avec mes données, je devrais être capable de supprimer toutes mes données d'une plateforme, c'est ce que les données devraient faire." D'autre part, vous avez la réalité du développement logiciel. Vous disposez de vos services, de vos conteneurs, de vos frameworks, de cette pile entassée – nous l'appellerons simplement un écosystème. Vous avez cet écosystème qui prend une vie propre qui est le logiciel lui-même, et il y a vraiment cet écart entre les deux.

Je définis le fossé logiciel comme l'abîme entre l'intention et la réalité, où le code n'est plus seulement 100 lignes de C distribuées entre deux ou trois fichiers avec un fichier makefile. C'est vraiment tout cet écosystème, et nous avons perdu la compréhension de ce que fait le code, ce qui signifie que nous n'avons pas compris ce que le code fait des données. Nous pouvons résoudre ce problème autant que possible avec différentes solutions de sécurité, mais au bout du compte, si nous ne retrouvons pas cette compréhension de ce que fait le code avec les données, nous aurons ces problèmes encore et encore.

Vous êtes probablement ici parce que vous le savez déjà, mais parlons simplement de la raison pour laquelle la lacune logicielle est importante. Cela mène à des amendes, à une atteinte à la réputation, à de l'argent perdu. Cela amène les équipes à faire preuve de prudence dans l'utilisation des données, ce qui oblige les développeurs à passer beaucoup de temps à les rechercher. Une entreprise à qui j'ai parlé récemment a dit s'être donnée plusieurs mois pour traiter leurs demandes de personnes concernées; il s'agit donc de demandes visant à obtenir toutes les données dont ils disposent sur un utilisateur. La raison pour laquelle ils se sont octroyés plusieurs mois, c’est qu’il faut parfois beaucoup de temps pour trouver toutes les données.

Enfin, cela ne fera que devenir un problème plus grave. Je parlais de cela à Weng plus tôt, il a dit: "Il y a aussi la réglementation du Brésil, il y a aussi la réglementation de New York, ce ne sera pas seulement l'Europe, ce ne sera pas seulement un petit problème que seules certaines entreprises devront traiter avec."

Dans cet exposé, nous allons d’abord parler de la raison pour laquelle le GDPR est difficile dans les environnements de développement logiciel modernes. En abrégé, toutes les réglementations relatives aux données sont simplement GDPR, car c'est celle sur laquelle nous disposons du plus grand nombre de données. Ensuite, je parlerai des raisons pour lesquelles les balles argentées ne résolvent pas le problème. Je pense que nous sommes tous assez doués pour le fait que les solutions miracles et le génie logiciel ne vont pas tout résoudre, mais les gens ne sont pas encore venus à considérer la sécurité et la confidentialité comme un problème logiciel de la même nature.

Je vais expliquer pourquoi la confidentialité différentielle, pourquoi le cryptage homomorphique, pourquoi tout cela ne sera pas une solution miracle pour résoudre le problème. Enfin, je parlerai des bonnes pratiques logicielles que vous pouvez adopter aujourd'hui pour combler le fossé qui existe entre les logiciels. Avant de continuer, voici un peu de moi. Je venais du monde universitaire avant de commencer Akita. Je suis vraiment tombé amoureux de cette idée selon laquelle vous pouvez créer des outils logiciels pour aider les gens à comprendre ce qui se passe réellement dans vos systèmes. J'ai décidé il y a environ 10 ans que la sécurité et la confidentialité étaient le domaine où cela importait ou importait maintenant dans nos systèmes. Je suis allé aux études supérieures parce que je pensais que c'était le meilleur endroit pour vraiment comprendre cela. Après un stage chez Google, Facebook et Microsoft Research, j’ai décidé que si je voulais avoir un impact avec ce type d’outils, un jour, je devrais créer ma propre entreprise, mais c’était le moment où les gens soigné.

Puis, lorsque le GDPR est arrivé, j'étais: "C'est un endroit où la réglementation semble être en avance sur la technologie, il s'agit uniquement de comprendre les logiciels, de suivre les données, c'est le moment". Au cours des deux dernières années, j'ai parlé à des dizaines, voire des centaines d’équipes DevOps du secteur de la sécurité, et c’est pourquoi je ne parlerai pas de ma propre expérience, mais de ce que j’ai vu faire. à travers l'industrie.

GDPR et CCPA

GDPR et CCPA, ce ne sont pas que des bannières de cookies gênantes sur lesquelles vous cliquez simplement sans les lire. Vous avez été nombreux à dire que vous aviez déjà dû gérer cette conformité, vous êtes donc probablement sur la même longueur d'onde que tout ce qui est bon pour le consommateur est très difficile pour les développeurs. Dans le GDPR, les consommateurs ont le droit de savoir quelles données les entreprises ont sur eux, ce qui est excellent. C’est ce que nous voulons du point de vue du consommateur, mais cela signifie que les entreprises doivent maintenant suivre toutes les données associées à chaque utilisateur.

De même, avec la suppression de données, les consommateurs ont le droit de demander la suppression de données. J'adore le fait que les sites prennent désormais en charge. S'il y a une sorte de violation, je peux simplement être: "Regardez, enlevez toutes mes données, je ne veux plus que vous les conserviez." De l’autre côté, les entreprises doivent désormais suivre l’ensemble des données pour pouvoir les supprimer. De même, les entreprises doivent maintenant utiliser les données aux fins pour lesquelles elles ont été collectées. Si vous n'avez pas le consentement pour faire de la publicité ciblée, si vous n'avez pas le consentement pour la spécialisation politique, vous ne pouvez plus le faire sous GDPR.

Cela signifie maintenant que les entreprises doivent non seulement suivre les données, mais également les autorisations correspondantes. Pour moi, le GDPR était très intéressant, car j’étais: "Comment les gens vont-ils suivre les données? C’est un problème non résolu." Comme le disait Weng, "ce n'est pas résolu, pas seulement pour la vie privée, mais pour tout." Examinez vos pipelines d’apprentissage automatique, examinez tout ce qui nécessite des données, qui est tout ce qui se passe actuellement. Vous allez avoir besoin de savoir si vos données sont fraîches. D'où proviennent ces données? Qu'avez-vous fait avec les données avant d'arriver ici? Le GDPR est vraiment le premier exemple du type de problèmes où vous devez commencer à savoir ce qui se passe dans ce domaine.

Examinons maintenant ce qui se passe lorsque GDPR rencontre le développement de logiciels modernes. Si nous pensons à nos piles de développement de logiciels modernes, les bases de code sont plus grandes et plus fragmentées que jamais. La diapositive est un texte plus petit que je ne le pensais, mais un fait amusant qui ressort du graphique de la taille de cette base de code est que l’application pour iPhone moyenne est maintenant quatre fois plus grande que la première version d’Unix, ce qui me fait perdre la tête. Les bases de code sont plus grandes – je pense qu'elles ont ici comme l'ADN et tout ce genre de choses. Les bases de code sont vraiment grandes maintenant.

Il y a aussi une utilisation intensive des API tierces. Je suis récemment allé à un hackathon universitaire. Quand j'étais à l'université, les gens programmaient dans Assembly et C. Maintenant, les gens appellent Twilio, ils appellent Salesforce, ils appellent Box. Cela signifie qu'au cours de la fin de semaine, ces étudiants développent des choses étonnantes. Ils s'appuient également sur un grand nombre d'éléments qui transmettent des données sensibles. Ce qui m'a vraiment étonné, c’est que les entreprises se développent également de cette façon. Beaucoup d'entreprises ne roulent plus tout à la main. Vous communiquez vos données, et lorsque vous avez réellement besoin d'un consentement pour le faire, c'est à ce moment-là que cela commence à devenir problématique.

Combien d'entre vous travaillent dans des entreprises avec des architectures basées sur des services ou sur des microservices? Ok, la plupart d'entre vous. Vous avez probablement aussi compris que les systèmes prennent une vie propre. Avant qu'un architecte puisse simplement dire: «Voici le système complet, voici comment tout peut fonctionner», dès que vous commencez à décomposer les services en services et microservices, tous les services peuvent appeler n'importe quoi. Il est très difficile de faire respecter votre intention concernant ce numéro de carte de crédit ou ces données de localisation, à moins que vous ne disposiez d’une directive très stricte et que tout le monde soit au courant de la marche à suivre. Oui, je suis surpris que les entreprises se portent aussi bien qu’elles le font actuellement.

Si nous réfléchissons à ce que GDPR signifie dans les environnements modernes, cela signifie que prendre ces idées de données vraiment propres devrait être supprimable, que les données devraient être traçables, puis imposées à des graphiques qui ressemblent à ceci. Ce tweet est devenu viral il y a quelques semaines. C’était l’ingénieur en sécurité de cette banque, Monzo à Londres, qui disait: «Nous avons 1 500 microservices», ce qui est au bas de la liste si vous regardez les grandes entreprises. Chaque ligne de ce graphique est une ligne de trafic réseau imposé. Afin de verrouiller tous ces microservices, uniquement pour des raisons de sécurité, pas pour les problèmes de confidentialité ou de conformité avec lesquels nous discutons, ce type, ainsi que d'autres personnes, espèrent également retrouver tous ces services et mettre en place des règles de réseau.

Le GDPR signifie que comprendre les flux de données signifie le suivi des données sur des milliers de services appartenant éventuellement à des centaines d'équipes différentes. Chaque développeur auquel j'ai parlé a déclaré: «C'est douloureux», mais les personnes chargées de rechercher tous les développeurs semblent souffrir beaucoup plus. Ensuite, il y a le fait que mettre en application des politiques de confidentialité ne signifie pas seulement garder trace des politiques à appliquer. Il ne suffit pas d'avoir une ligne disant «oui, certaines règles du réseau sont appliquées», mais il est également délicat de déterminer quelle règle de réseau est appliquée, car vous avez différents consentements. Les données proviennent de différentes sources et il y a toutes sortes de choses qui se passent ici.

Il y a aussi l'aspect personnel. Assurer la conformité partout n'est pas simplement: "D'accord, nous avons mis en place un pare-feu, nous verrouillons maintenant toutes les données sortant de notre pare-feu." Il faut vraiment que tous ces développeurs coopèrent. Le gros problème avec le GDPR est que ce ne sont pas seulement les mots de passe qui ne sont plus privés, ou les numéros de sécurité sociale, ou les numéros de téléphone. C'est des emplacements, c'est n'importe quoi identifiant. Ce sont toutes sortes de textes de forme libre sur lesquels il est difficile de faire correspondre les motifs, et ils sont partout. Cela remonte vraiment au fait que c'est un moment où nous devons maintenant comprendre le logiciel.

Rappelez nos mots de passe en clair

Revenons maintenant à notre problème de mot de passe en texte clair maintenant que nous avons cette compréhension. Certains de mes amis, même quand je leur parlais de cette discussion ou de ce sur quoi nous travaillons, ont dit: "Pourquoi est-ce si difficile?" Je pensais creuser un peu plus profondément et parler de la raison pour laquelle tout le monde divulgue des mots de passe en texte clair et pourquoi c'est un si gros problème. Le problème, c’est que les mots de passe sont supposés être les données les plus secrètes de tous, vous êtes censés les garder cryptés à tout moment. Si les mots de passe sont découverts en clair dans une base de données quelque part, l’entreprise doit maintenant demander à tout le monde de réinitialiser leurs mots de passe. Les violations sont également plus importantes, les entreprises ont maintenant plus de responsabilités.

Ce que les entreprises ne veulent vraiment pas faire, c'est stocker un mot de passe en texte brut quelque part, car elles doivent ensuite envoyer un courrier électronique à tous leurs clients, leur demander de modifier leur mot de passe. Cela s’explique par le fait que vous avez des objets utilisateur qui flottent, les utilisateurs ont des mots de passe. Chaque fois que vous enregistrez cet utilisateur ou chaque fois que vous effectuez un vidage d'erreur, ou que vous envoyez quelque chose à quelqu'un d'autre qui l'enregistre ou effectue un vidage d'erreur, ou que vous faites simplement une impression de débogage à laquelle il oublie de s'inscrire. sortir, c’est un endroit où un mot de passe peut accidentellement être connecté.

Pour donner un exemple très concret, mon équipe et moi avons trouvé un bogue dans WordPress que nous avons demandé à divulguer, WordPress prenant les paramètres de requête d'URL et acceptant les mots de passe. Que font les gens avec les paramètres de requête d'URL? Vous les connectez à Apache. Même dans cette très courte séquence de flux de données, tenez le journal des paramètres, vous avez déjà une fuite de mot de passe. Si vous imaginez un système beaucoup plus compliqué, vous pouvez imaginer, vous avez pris le paramètre ici, vous avez fait un tas de choses, puis vous vous êtes connecté, mais à la fin de la journée, vous vous connectez à ces mots de passe en texte clair.

Je ne sais pas exactement comment beaucoup de ces fuites se produisent, mais quelque chose d'intéressant pour moi était très récemment Robinhood. Combien d'entre vous utilisent l'application de services financiers Robinhood? Vous avez dû changer votre mot de passe récemment. Plus récemment, après la faille Robinhood, ce qui était vraiment intéressant pour moi était: je pense que leur équipe de sécurité se préparait vraiment pour Internet. Elle disait simplement: "Tout le monde devrait arrêter d'utiliser cette application", "Comment peuvent-ils être irresponsables?" Ensuite, si vous regardez les commentaires de Hacker News, la plupart du temps, les gens disent: "Comment cela peut-il arriver?" La moitié des commentaires étaient en réalité des personnes qui défendaient le développeur qui avait accidentellement enregistré le mot de passe en disant: "C'est en fait très facile de faire cette erreur."

Ecnahc515, cette personne, a déclaré: "Cela se produit essentiellement dans toutes les grandes entreprises d’applications Web. Activez la journalisation du débogage dans l’application qui enregistre les en-têtes de requêtes HTTP," exactement la forme de bogue que nous avons également détectée "et ne supprimera probablement pas les informations sensibles. Erreur facile. " Ensuite, il y a beaucoup d'autres personnes qui ont dit: "Regardez, je l'ai fait une fois, c'était une sorte de décharge." Les équipes de sécurité disent en réalité qu'elles recherchent des 500, car chaque fois qu'il y en a 500, il y a probablement un cliché, puis des mots de passe sont présents, ce qui permet aux équipes de sécurité de rechercher les erreurs.

Quelqu'un est sorti et a dit: "Regardez, si vous n'automatisez pas la détection de ce genre de choses, vous ferez à nouveau la même erreur." Oui, chaque développeur peut vérifier partout où il se connecte, écrit sur le réseau qu'il fait quoi que ce soit et s'assure que cela ne se produit pas, mais c'est une erreur qui attend, surtout que les systèmes deviennent de plus en plus complexes. Ce que les gens sur ce sujet ont également souligné, c'est que la plupart des grandes entreprises ont eu ce bogue au cours de la dernière année. Apple, qui est connu pour le moment, la confidentialité est leur truc – je pense que c’était leur journal d’erreurs d’API – avait ce problème précis. GitHub, également pro-développeur, très bon en ingénierie – même bogue.

Il n’ya pas que les petites entreprises qui n’ont pas trouvé le moyen de ne pas encore enregistrer les mots de passe, c’est vraiment un problème très répandu. La forme du problème ne se limite pas aux mots de passe, les mots de passe ne sont que le symbole des choses les plus secrètes. Si vous enregistrez même des mots de passe en clair, vous feriez mieux de faire autre chose. Un incident de forme similaire est cet incident à deux facteurs de Twitter. Ce qui s’est passé est que Twitter a pris des numéros de téléphone pour l’authentification à deux facteurs. Il disait: «Les gens, donnez-nous votre numéro de téléphone pour que nous puissions vous envoyer un code de secours par SMS afin de vous protéger davantage. Ensuite, quelqu'un a accidentellement utilisé, je suppose, ces numéros de téléphone pour des publicités ciblées. Internet a été totalement scandalisé. "Nous essayons de rester plus confidentiels et plus sûrs, et vous allez le faire?"

Matt Green, cryptographe chez Johns Hopkins, a déclaré: "Si vous voulez simplement sécuriser les numéros de téléphone, vous devez les mettre dans une base de données appelée" Les numéros 2FA ne vendent pas aux spécialistes du marketing "." Je soutiens que c'est vraiment difficile si nous ne pouvons même pas conserver les mots de passe – mots de passe, chiffrer, ne pas déchiffrer. Les gens vont prendre cette information, vous avez un environnement basé sur les services de microservices, quelqu'un va appeler quelque chose quelque part, et les gens vont être, "Cool, numéros de téléphone, je peux gagner plus d'argent." En même temps, les gens continueront à plaider votre cause pour avoir commis ces erreurs.

Matt Green a déclaré: "Ce genre de choses est comme une banque qui laisse l'argent aux clients et la dépense en snacks." Évidemment, cela pourrait arriver, nous essayons simplement de l'empêcher parce que, vous savez, l'éthique. Je pense qu’un côté, oui, c’est vraiment facile de laisser échapper des mots de passe partout. Devrions-nous le faire? Probablement pas. C’est vraiment facile de parler de ça, mais nous devrions vraiment nous arrêter et voici comment nous pouvons nous arrêter.

Si vous ne vous souvenez plus de rien de cette conversation – je ne peux m'en souvenir que d'une seule chose à la fois – voici la chose dont vous devez vous souvenir: il s'agit uniquement de flux de données. La plupart des problèmes nouveaux concernent en réalité la façon dont nous déterminons où se trouvent les données sensibles, puis nous en assurons le suivi au fur et à mesure de leur circulation dans le logiciel. Comme vous l'avez vu avec ce WordPress ou l'hypothétique fuite de mot de passe de Hacker News, les données ne doivent pas aller très loin. Le flux de données pourrait simplement être, entre, va directement dans le journal, mais vous voulez vraiment suivre ce chemin.

Comment combler le fossé logiciel?

Mon équipe et moi avons beaucoup réfléchi à la manière de réduire cet écart et de suivre les flux de données. Nous avons élaboré un ensemble de critères. Je vais maintenant dire que ce sont des critères de grands traits, nous pouvons diviser les cheveux autant que possible pour le reste de la discussion sur comment faire les catégories, mais ceci est juste pour vous donner une idée de la façon dont nous sommes. penser au problème. Nous pensons qu'il devrait y avoir des solutions adaptables. J'étais chercheur en langages de programmation auparavant, et vous savez, nos articles sont: "Voici la sémantique", et nous: "Nous avons trouvé une solution à ce gros problème, utilisez simplement ce langage." Tout le monde dit: "Nous n'allons pas utiliser cette langue."

Quelqu'un a dit: "Jean [Yang], tout le monde dans votre domaine, comment vous parlez – si vous allez chez le médecin, et ce dernier vous dit: "Si vous mangiez une pomme tous les jours et que vous faisiez de l'exercice dès le jour de votre naissance, vous ne seriez plus ici." "Ce n'est pas pratique, nous devons rencontrer les gens là où ils se trouvent. Je pense que la priorité numéro un pour beaucoup des solutions que nous devrions examiner est qu'elles doivent être adaptables, elles doivent être compatibles avec les langages de pile de technologies modernes, l'hétérogénéité des technologies modernes." environnements, où ils se trouvent aujourd’hui, ils devraient être automatisés.

Si nous pensons à l’échelle des logiciels modernes, des logiciels d’échelle de la taille du génome de l’ADN humain, nous devons vraiment automatiser la vérification de l’ensemble de cette base de code. La solution doit être adaptable, de sorte que ce ne soit pas comme s'il n'y avait qu'un seul coup, un seul règlement et que rien ne changera, tout ira bien à partir de là. Nous avons besoin d'éléments modulaires en ce qui concerne les politiques pour que cela soit à l'épreuve du temps.

Nous avons besoin de solutions qui soient exploitables. C’est un nouveau sujet sur lequel nous tenons beaucoup après avoir parlé à de nombreuses équipes de sécurité et de protection de la vie privée. Il ne suffit pas de détecter l'existence de problèmes et de remédier aux symptômes de ce problème. Vous souhaitez réellement améliorer les systèmes logiciels et mieux comprendre la façon dont les données circulent afin que les développeurs ne puissent pas simplement voir une alerte: "Shoot, je fuis à nouveau des données." Ils peuvent dire: "Ok, celui-ci est important, voici comment je vais le réparer, et voici comment je vais empêcher que cela se produise la prochaine fois. Enfin, bon nombre de solutions sont bonnes, mais ne résolvez pas réellement le problème de flux de données, ce qui, selon moi, est une raison essentielle pour laquelle ces systèmes ne se rencontrent pas là où les régulateurs le souhaitent.

Pour le reste de la discussion, je vais expliquer pourquoi la liste ne contient pas de solution miracle, et je vais parler de ce que vous pouvez faire aujourd'hui et de la manière dont cela se compare à cette liste. Ensuite, il y a encore un vide, c'est pourquoi nous avons des choses à faire, alors je vais en parler aussi.

Anonymisation des données

Passons maintenant à la dissipation du mythe de la solution miracle. Il n'y a pas de solution miracle, vous le savez déjà. J'ai l'impression que les gens me posent encore souvent des questions sur la sécurité, parce qu'ils disent: "La sécurité n'est pas un logiciel, c'est juste là-bas." Je suis, "Non, toujours pas de solution miracle."

Le premier sujet dont on parle beaucoup est l'anonymisation des données. C'est ce que j'ai à dire à ce sujet. Il y a tous ces titres qui disent: "Désolé, vos données peuvent toujours être identifiées même si elles sont anonymisées." S'il y a une sous-traitance, ce n'est même pas le point central de mon travail, cela me tient vraiment à cœur. Chaque fois que je tweet à ce sujet, il y a la mafia d'anonymisation des données et ils sont, "Mais Jean [Yang], nous avons prouvé dans ces cas "et je suis," Oui, vous avez prouvé dans ces cas, pas tous les cas. "Vous devez être très prudent avec l'anonymisation des données.

C’était mon costume d’Halloween de l’année dernière, j’avais anonymisé les données. Comme vous pouvez le constater, mon déguisement est très pauvre, vous pouvez toujours dire exactement qui je suis et ce qui est sur mon t-shirt. Je pense avoir écrit un tweet qui disait: "Parce que je n'avais pas de costume sur mesure, vous pouvez toujours tout dire." Voilà comment je pense que tout le monde devrait penser à l'anonymisation des données.

Nous pouvons parler de deux parties de l’anonymisation des données. Il y a la désidentification des données, et il y a aussi la confidentialité différentielle, dont les gens aiment vraiment parler. Les deux peuvent vous faire sortir de certaines exigences GDPR, on dirait. Le RGPD stipule que si vous créez vos données de manière à ce qu’elles ne puissent pas être réidentifiées, votre consentement et votre suivi disparaissent. Cela n'a pas encore été défini et les données ne sont pas ré-identifiées – personne n'y a vraiment créé de précédent. Ce que je dirais, c’est que la plupart des données peuvent être réidentifiées, donc si vous ne voulez pas d’amende potentielle, ni d’atteinte à la réputation, je ferais extrêmement attention. Voici pourquoi. La désidentification consiste à supprimer certains champs de vos données. Si vous avez tout votre contenu comme Grubhub, ou autre chose, il aura l'historique de vos commandes, mais pas votre nom, votre numéro de téléphone, votre adresse. Je veux dire, qui d'autre commande Asian Box tous les repas tous les jours? C'est moi.

Beaucoup de chercheurs ont travaillé dans tous ces domaines, même si vous enlevez tous ces champs d'identification avec une très grande probabilité. Ils pourraient peut-être limiter cela à moi et à Weng, qui aime aussi beaucoup Asian Box. Il est très facile de préciser qui c'est. À l'heure actuelle, je pense que les gens ne savent toujours pas quoi en penser, mais la plupart des choses qu'ils ont faites sont: "C'est le moyen de désidentifier vos données." Quelqu'un est venu et a dit: "Je l'ai ré-identifié."

Une grande raison à cela est la liaison; combien d'entre vous ont pensé aux ensembles de données de liaison? Si quelqu'un a mon histoire Grubhub, et qu'il a ma boîte asiatique tous les jours, commande tous les repas, puis qu'il a mes données de carte de crédit qu'il a achetées quelque part, alors il peut vraiment dire que c'est probablement moi. C'est la même personne qui achète également tous ces t-shirts du groupe Miley Cyrus. Si vous prenez toutes les données isolément, la ré-identification peut sembler difficile. Si vous pensez que si quelqu'un peut acheter toutes vos données non identifiées ensemble, puis essayer de les reconstituer, vous ne voulez probablement pas cela. Je dirais, soyez extrêmement prudent si vous allez sur ce territoire.

Même chose avec la confidentialité différentielle. Je peux faire environ 5 minutes de discours sur la confidentialité différentielle que je ne ferai pas dans cette discussion, car je ne pense pas que nous devrions prendre ce genre de temps, mais je suis heureux de le faire pour vous. à tout moment. Après ce rêve, vous pouvez créer des enregistrements individuels, les garder confidentiels, puis diffuser des informations globales. L'exemple canonique est que, si vous avez des enregistrements d'employé, vous pouvez garder les salaires des employés confidentiels, mais ensuite le salaire moyen est libéré. Comme vous pouvez le constater, il existe certains problèmes potentiels ici. Par exemple, si vous n’avez qu’un seul employé? Que signifie la moyenne, etc.?

Confidentialité différentielle, je tiens à dire pour l'instant que le traitement de vos données est très sensible à votre ensemble de données et à l'efficacité de vos calculs, ainsi que l'efficacité des garanties statistiques. Les chances qu'ils puissent dire quel est mon salaire sont très faibles. C'est très dépendant de ces deux choses. Les cas où des gens me tweetent toujours "Jean [Yang], mais cela fonctionne. "Ils sont", nous avons prouvé que cela fonctionne sur cet algorithme pour cet ensemble de données. "Je suis," Oui, la plupart des gens ne vont pas le faire. "Sauf si vous allez pour prouver que cela fonctionne pour, vous le savez, un algorithme spécifique et un ensemble de données spécifique, je dirais de faire très attention aux attaques de ré-identification.

Ce que je retiens en ce qui concerne l’anonymisation des données, c’est que vous devez vraiment vous assurer que votre méthode d’anonymisation est adaptée à la fois aux algorithmes d’analyse des données et aux données. Autrement, vous n’avez pas les garanties mathématiques autrement, alors si vous n’êtes pas sûr, ne le faites pas.

Ensuite, en rentrant dans notre case à cocher conviviale, vous pouvez diviser les catégories en différentes catégories. Certaines d’entre elles pourraient appartenir à cette catégorie. Je dirais que l’un des attraits de cette solution est que c’est vraiment adaptable, il vous suffit d’anonymiser vos données, puis de faire comme si de rien n'était. Cela ne règle vraiment pas beaucoup d'autres problèmes, et les dangers sont nombreux. Je dirais que ce n'est pas une solution miracle.

Cryptage

Passons à la crypto. Cela ne sert que si vous l'utilisez réellement, et alors cela ne sert vraiment que si vous l'utilisez correctement. Le fait que nous ayons tous ces mots de passe en texte clair flottants montre que si vous ne chiffrez pas réellement, c'est plutôt problématique. Parlons des problèmes de crypto. Les gens disent: "Si nous avions juste un meilleur cryptage, cela résoudrait tous nos problèmes." Et je dis toujours: «Cela ne résout pas les problèmes du GDPR, de l'ACCP, parce que le problème n'est pas que ces trucs ont été piratés, c'est qu'ils n'ont pas été cryptés du tout, ils étaient simplement assis là. Les gens disent: "Qu'en est-il du cryptage homomorphique et fonctionnel?" Je vais en parler un peu, mais cela ne va pas nous sauver non plus.

Le cryptage ne donne accès aux données qu'à ceux qui possèdent une clé, mais vous êtes toujours responsable de la protection de vos clés. De plus, vous êtes toujours responsable de la mise en sécurité de vos données. Par conséquent, si vous laissez vos données en texte clair, cela ne vous aidera pas. La partie la plus pertinente est que le cryptage ne vous dit pas quand il est correct de donner une clé à quelqu'un, ou quand déverrouiller une valeur pour quelqu'un. Je suis sûr que ces entreprises cryptent la plupart du temps leurs mots de passe et d'autres éléments, mais il faut parfois les décrypter pour pouvoir les regarder et les montrer aux gens, et c'est alors que les mauvaises choses arrivent.

J'appelle cela le problème de décryptage. Je pense que le cryptage de base, les gens l'ont piraté. Ces autres problèmes ne se produisent pas car le cryptage était faible. C’était que le matériel avait été mal déchiffré, ou n’avait pas été conservé au bon moment, ou tout le reste. Les gens disent: "Qu'en est-il du cryptage homomorphique?" Un récapitulatif très rapide – c'est peut-être beaucoup trop rapide, probablement – mais le cryptage homomorphique et fonctionnel permet de prendre une valeur cryptée, puis de faire des calculs par dessus. À la limite, les utilisateurs ont créé une base de données cryptée homomorphique dans laquelle votre base de données reste cryptée, et vous pouvez toujours effectuer quelques requêtes par dessus. Une chose qui n’est pas du tout ce que je veux dire c’est que c’est une belle théorie, mais c’est vraiment coûteux et les choses que vous pouvez réellement faire sont assez limitées. Le point principal est que cela ne vous dit pas ce qui se passe lorsque vous le décryptez. Je peux prendre mes valeurs cryptées, je peux faire des calculs dessus, puis si je les déchiffre et les stocke en texte clair, cela irait à l’encontre du but de l’avoir crypté.

Encore une fois, je dirais que cela revient au problème du flux de données. Je pense que le cryptage est excellent, nous en avons besoin, mais c'est comme si vous deviez porter des chaussures, mais vous ne pouvez pas seulement porter des chaussures, vous devez également porter vos autres vêtements. Pour moi, c'est le cryptage.

Nous voyons à quel point nous sommes à la hauteur, il est très facile de s’adapter, il vous suffit de chiffrer toutes vos valeurs, de faire des choses avec. C'est automatisé, donc une fois que vous cryptez, c'est crypté partout, mais vous êtes toujours responsable de la gestion lorsque vous décryptez. Cela signifie que vous êtes toujours responsable de la gestion de toutes vos stratégies, du suivi de tous vos flux de données et c'est toujours ainsi que nous nous retrouvons avec tous les problèmes que nous avons.

Langages de programmation

Sur cette note heureuse, voyons comment les nouvelles langues ne peuvent pas tout résoudre non plus. En fait, je suis très surpris que les gens en parlent. J'ai rencontré un responsable de l'ingénierie lors de certaines réunions. «Si nous avions juste un nouveau langage et que tous nos développeurs écrivent dans ce nouveau langage, cela résoudrait tous nos problèmes». J'étais, "quand j'étais un étudiant de première année aux cycles supérieurs, j'ai également dit cela et tout le monde m'a fait rire de la pièce pendant des années." Depuis, j'ai vraiment appris que le langage ne résoudra pas tous vos problèmes pour de nombreuses raisons.

Voici une photo du document de Fred Brooks et son contenu est le suivant: "Il n’existe pas de langage, d’outil, d’abstraction ou autre qui puisse résoudre tous vos problèmes de logiciel." Il en va de même pour la sécurité et la confidentialité.

Oui, il n’existe pas de langage de programmation ou de bibliothèque unique capable de résoudre l’ensemble du problème. Les langages de programmation et les bibliothèques offrent de très bonnes garanties, mais ils vous obligent à tout porter dans ce langage ou cette bibliothèque. Si vous pensez aux flux de données, ce n'est pas une partie de votre programme, comme "Voici mon serveur de paiement". Je me souviens de la première fois où j’ai appris que vos fenêtres utilisaient réellement prologue pour faire correspondre votre pilote au démarrage, j’étais «Wow, prologue». C'est une tâche à accomplir. Ce n'est pas comme si tout dans tout votre logiciel. Si vous voulez réellement suivre les données en utilisant une langue, il faut que ce soit partout.

Qu'en est-il de vos bibliothèques tierces? Qu'en est-il de ce code que vous avez apporté ailleurs? Qu'en est-il de quelque chose d'autre, comme un projet parallèle d'une personne d'il y a 10 ans que vous devez maintenant porter? Tout cela est très problématique. Really, for data flows, anything that's not part of your really nice world now can subvert any of your guarantees. Most of the time I kept everything safe and one place I didn't. That's how we get breaches, that's literally how each one of these leaks happened.

This was actually the topic of my Ph.D., how do we track data flows at the application level. These people are, "I know, I'll just write a library." I'm, "Look, I spent like 10 years studying this, there's a lot of subtle problems that come with tracking data flow." What happens when you have to put two data values together and say where they came from? What happens if you have a conditional and something that depends on a sensitive value, but the thing that's actually being leaked isn't? If this is something you tempted to do and the first two points aren't deterring you, I hope the third point deters you a little bit.

Programming languages are great, they can potentially address all of the points. I'd say their big weakness is that the adaptability is very low. In fact, the more it tracks the data flows, the less adaptable it's going to be.

To summarize, data anonymization is not relevant to tracking and protecting data as it flows across this graph. It also has the other issues that I've discussed, so it is not a silver bullet. Encryption protects individual values but doesn't say anything about rules for accessing any of this, so that's still up to you. I would say that's where a lot of the problems come from. Then finally, if you use a specialized language or library, you're applying it to something that looks like this, potentially more complicated, so good luck with that.

What You Can and Can’t Do Today

Now we can move on to what you can and can't do today. I was told that I have to leave you with hopefulness, so I had to add this section at the end of the talk. I think it's also really important to be aware of the limitations, so I will leave you with some anti-hopefulness as well.

The most practical thing to do is, from this point forward, you can start architecting your systems to take compliance into account. A lot of my friends who run engineering teams will say things like, "We did our whole software thing and then at the end security was like, 'no'. Then we said no to them, and then we shipped it." That was maybe ok in the past, but as these fines get bigger, as people start caring more about this, this is going to be less ok in the future. One thing to do is to just stay up to date on best practices for designing and employing encryption, which, like I said, is necessary, but not everything, but in the very least, you're making sure there's that extra layer of protection everywhere. The important thing is you're still responsible for keeping track of when you decrypt.

The other thing to do is to build tools and libraries for centralizing your policy management. A lot of companies have done things like make API's for developers to use when they're reading from the database, writing to the database, and when they're writing values to the outside so that they're not responsible for writing those checks themselves, but it's become centralized. I think Uber has some paper about it somewhere about how they do it. Then there's a lot of academic papers about the proper ways to do this as well. I was thinking about putting a blog post together – if you follow me, one day maybe you'll see.

It seems like moving forward if you set everything up so that developers aren't responsible for at least doing the checks themselves, they're still responsible for making sure they're instantiating the checks with the right arguments, but that can go a long way. If you have this, this is pretty good, but it doesn't address your data flow issue, and especially if you have large legacy codebases, you're going to need to untangle your data flow hairball. There also has been a lot of effort towards this in the push to GDPR, so you probably know about some of these already. The first one is, it seems like the most effective thing is still just a document because it's so complicated that the tools just, frankly, haven't caught up.

I asked one privacy engineer at a pretty progressive high-tech company, what they do. They said, "If I have to track down data, I write a Jira ticket with all the people I'm going to talk to, and I talk to those people as quickly as I can." I think a lot of this information is still in people's heads, so getting people to put more of this into documentation is a good idea.

Metadata also has been really useful, so this is everything from adding columns to each of your tables – to talk about where the data is coming from, what the permissions are, and making it so that when you join on the tables, the metadata gets propagated, that kind of thing – to, some companies have even started making object-store this metadata, every object store is a metadata inside. Again, if you get into data flow, like information flow kind of things, this starts getting a little bit tricky.

Then finally, there's just starting to be tooling that gives visibility to data flows. I would say we're still at the very beginning of this, so how many of you use APM tools like New Relic, LightStep? Those will give you something like, this is what service talks about service, and this is the superset of all of your possible data interactions. What it won't give you is, if your credit card leaves your service, this is exactly the path it can take. I would say this is something we hope to address and there's also a small set of people working on addressing that problem as well.

The screenshot on the left bottom corner is actually from Lift's cartography tool. They map out between your services, like what credentials are shared and what resources you're sharing between your different AWS-hosted services – I'm not sure actually, go read the documentation. This is a very important part, especially if you have these complex legacy systems of sorting out your data situation.

This is all great, but what you do with it is still an open question. Then even this leaves gaps, so I would say it's really important not just to build guardrails, but also install safety nets. I asked around, and it seems that one of the most tried and true ways of not leaking passwords is just to use sentinel values. In your tests put in passwords that you know how to recognize. For any sensitive data, put in stuff that you know how to recognize. Put that into your system, see where it ends up. I think someone who was the head of privacy at a very large company said that to this day, this was one of the techniques that they still use because it beats pretty much most other techniques for certain kinds of leaks.

There's also pen testers and bug bounties. People have traditionally used them for security purposes. Pen testers are people you bring in from the outside to beat up against your system. Bug bounties are a crowdsource way of doing it. I haven't seen a lot of people doing bug bounties, for instance, for information disclosure, but that's something that I think is doable. That's something that especially as regulation gets stricter, I think, would be a really good idea to do.

Then finally, there are these data loss prevention solutions that can provide an extra layer of protection. These are solutions that sit at your API, at your network edge, at the boundaries of your system, and they'll match on sensitive data that might be flowing out. As I'll get into, this is also limited in some ways.

All these approaches are pretty good, they can catch a lot of stuff at the edges of your system, but I would say the thing they're missing is this actionability. We caught the errors, but why do they happen? How do we fix it? How do we prevent this from happening next time? How do we build our software to make it easier not to have this happen?

My caveats with this are first, a lot of the approaches I talked about just now that you can do today rely on the developer, and relying on the developer has its limitations. Developers need to stay up-to-date with latest process, teams may need to update legacy code and get up-to-date with new best practices. Then finally, any outside code that your organization brings in might not fit with this, and there's actually quite a bit of outside code if you think about just what outside code your org might be using today.

To dig into what I mean by lack of actionability, let's talk about data loss prevention. If you just have a safety net, it's not going to fix your problem. It'll help fix your symptoms, but you still have data flows that you don't have any idea about. Data loss prevention techniques operate at your points of egress, your APIs, your networks, your logs, to detect potentially sensitive data leaving the system.

First, they don't have visibility into how the data got there, so developers have to figure that out. What one security engineer told me once is, if all I'm doing is giving alerts to my developers, they're probably going to ignore them. They don't have time to go through hundreds of alerts and figure out which ones of them are legit. Also, these alerts don't give hints about how to change the code, because there's no visibility, it's completely on the outside. The developers, even if they agree that something is a leak, they have to figure out how to change it.

Also, because of the lack of visibility, it introduces the weakness into the tool. If you think about if you're just sitting on the outside of a system, and you're trying to figure out is something a password, or an address, or a location, there's some stuff you can use regular expressions or simple AI to match on, but it's actually really hard to get that right. People also have complained about false positives, and just, in general, having to do a lot of manual work sorting through the results of this. There is some stuff you can do today, but it's also good to recognize that there's still some ways to go.

The software gap remains. Today, the developers can bridge the software gap, but it takes a lot of time and energy on the part of developers. What we think is that software teams can be much more effective at finding and fixing data issues if they get an understanding of the underlying data flows, and then everybody can architect systems better to deal with compliance and privacy issues in the first place.

Again, if there's one thing that you take away from the talk, I'd like you to remember that it's all about the data flows. What GDPR and CCPA introduce in terms of complexity for developers is that everything that was pretty much designed to make development easy, scalable, modern, etc., made things very hard to reason about data flows. There's a lot of techniques that you can use to patch together today to help, but when it comes to the underlying data flows, we still have some work to do in building the tooling and process to untangle that.

Akita: Giving Visibility into Your Data Flows

I said I wasn't going to talk very much about what we're doing, but I'll just give a very quick sneak peek. What we're going after is giving visibility into those underlying data flow so that people can build better software. The immediate goal is to just help developers find data leaks faster. The canonical passwords and logs problem, existing tools don't do a very good job with that. We want to help developers find those kinds of leaks and others faster, and in a way where they can take action once they have the results. We think it's really important to be very easily integratable, so we've been building in conjunction with modern container infrastructure, with modern API infrastructure, and trying to fit in and meet people where they are.

Finally, we really believe that, as Weng said, this is not just about privacy, this is not just about compliance. It's really about understanding data flows to build better software for all purposes with data. We've been thinking about this as developer-centric tooling for data flows, rather than security tooling, or just privacy tooling or, something like that.

To end, I'll say that we are still pretty early, we're in a private alpha. This is a problem I'm very passionate about solving, so I would love to talk more and understand what your problems are, even if you don't think that this is useful for you now. We're also hiring, so if you email invites, and say you want a job, I'm sure we would consider you. We'd also just love to keep in touch. We're trying to make a lot of fast progress on this problem, so hopefully, we'll have updates soon. Let's close this software gap and make life easier for developers.

Questions and Answers

Participant 1: You pounded on the no silver bullets point repeatedly, and I think that many of the people in this room understand that there is no silver bullet, you can't just fix something. To what extent do you think that regulators or legislators understand that you can't just decrease something and have it happen?

Yang: I think when GDPR first came out, I was pretty shocked because I was, "This is so far ahead of what people can do. The auditing isn't even turned on to do any of this. How are they going to do it?" What I hope will happen is that standard bodies arise and then technical people can get together and say, "This is what we agree, it’s the state of the art, and we can do some things." The one point where I was really interested in what they [GDPR] would do was around re-identification of data, and I think they have been pretty good there, not just saying, "If you use differential privacy or something like that, it's ok." They left it in terms of, if it's re-identifiable under whoever's ruling at the time. Yes, I think it's very tricky there.

Participant 2: I was curious if you're also thinking about the thing that keeps me up at night. It’s the analytical side of this thing as well, is where you have not just the software and log files and things like that, but you have some user who runs a report and all of a sudden drops it somewhere or leave it on their laptop running locally, or something like that. They aren't necessarily involved in all the best practices and automation and stuff like that.

Yang: Yes, that's a really good point. I would say, we've been really thinking a lot about the software part of this problem, but one of our advisors actually is working on the permissioning part of which users can access which data. Yes, that's a really big problem as well.

Participant 3: When I think about being able to track data flows, in my mind, it feels like there needs to be some kind of instrumentation done. Essentially, to get a really good picture you need to carefully instrument the system, so they'll be costs associated with instrumentation. You mentioned that using widely adopted programming languages might make that better. There's also the cost associated with generating this whole new sea of data. Is there a good way to quantify this and measure the effort? Because it might be easier to tell people, "This is a good idea, do it and this is the cost associated with it."

Yang: Yes, that's a really good idea, that even if you're not adopting a new programming language, the instrumentation you might have to do to track this is very high. Something we've been trying to solve is how can we do this with as low instrumentation as possible, but it's an extremely hard problem. Yes, I think that it's a really good idea to actually say, "At some point, you might as well just use a whole new language because you're going to have to do all this work." Yes, that's super interesting. I agree, if you do this at runtime, there are runtime instrumentation overheads. Even if you do it in test, there are things you have to do there. Your question is precisely what we've been trying to go after, how can we take all the overheads and knock them as low as possible.

Participant 4: One of the things you talked about was legacy code, and I'm wondering when you're in a company that is trying to overcome tech debt and actually get not even to the future of privacy, compliance, but just trying to maintain status quo? How do you communicate the value of starting to wear down that tech debt with new applications, new business solutions? How do you think about that?

Yang: Something that I've noticed is, there seems to be a communication barrier between engineering teams and compliance, security, privacy. Something we've been thinking a lot about is how do we build essentially communication tools to bridge that? Communication tool is a very specific thing, but at a higher level, how can you help communication be better there? Because there's some kind of people talking past each other where people are, "It needs to be like this," and developers are just, "Look, we can only move so fast, we can't spend all of our time making this compliant. We also need software."

I there's more two-way communication, developers will also appreciate it more. A lot of what I've been seeing is people just say, "Developers, you got to do this." And they're just, "No, it's not possible," and then they'll just ignore it. If you tell developers "Do this one thing this month, and then, we see what you're doing, we understand what the status is," or, "Here's actionable things you can take," I think that is a way forward. I think right now like if you just tell developers, "You got to do this thing," that sounds impossible, they're just not going to.

See more presentations with transcripts

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.