Privacidade Diferencial e Machine Learning

O que é a Privacidade Diferencial e como isso está relacionado com segurança em Machine Learning?

TL;DR: Algumas medidas para manutenção de privacidade e segurança podem ajudar a evitar ou minimizar o impacto de um vazamento/roubo de dados.

Esta semana na Finlândia aconteceu um roubo de dados de um centro de psicoterapia chamado Vastaamo.

O objeto do roubo foram as informações das sessões de terapia de um pouco mais de 40 mil pessoas, estas que foram extraídas pelos hackers que estão pedindo 450 mil euros para não divulgarem as informações.

Algumas destas pessoas já estão sendo diretamente chantageadas para realizarem pagamentos para os hackers, ao custo de terem as suas informações de acompanhamentos psicológicos vazadas (algumas, com inúmeros anos de terapia documentados nesta base de dados).

Este evento está marginalmente relacionado com duas tópicos que abordei este ano que foram a minha Talk no PyCon Africa que rolou em Agosto deste ano em que falei de segurança em Machine Learning e ataques adversariais e no post sobre condições latentes e falhas ativas em Machine Learning.

Apesar dos tópicos não terem falado diretamente de invasão de sistemas e vazamento de dados, eu queria usar esse caso como exemplo para trazer novamente a percepção para esses aspectos de segurança algorítmica e de dados, e também para falar a alto nível sobre privacidade diferencial.

Mas primeiramente o que aconteceu?

O vazamento de dados

A empresa Vastaamo é um centro de psicoterapia que funciona em diversos lugares da Finlândia, e funciona como uma espécie de franquia de psicoterapia e psiquiatria que atende aos mais diversos casos envolvendo saúde mental.

Os principais serviços da Vastaamo são: tratamento contra depressão, tratamento contra vício em jogos, ansiedade, traumas, problemas com alcoolismo, e problemas de relacionamentos em geral.

Grande parte dos acompanhamentos eram registrados de forma escrita e armazenados em um banco de dados, de forma descriptografada, sem anonimização dos pacientes, e que segundo alguns relatos com todos esses registros associados com as informações de endereço, e-mail e dados pessoais de cada um dos pacientes.

Dado este cenário, é tecnicamente possível que estas 40 mil pessoas tenham o seus nomes, telefones, e e-mails e as suas sessões de terapia reveladas publicamente; o que além de ser um crime hediondo contra pessoas em posição de extrema vulnerabilidade, que pode potencialmente levar a inúmeras consequências não mensuráveis. Inclusive até mesmo políticos do alto escalão estão sendo chantageados para pagar a extorsão.

Um fato agravante nisso tudo é que mesmo no *press release *sobre a crise, a Vastaamo divulgou [1] que além de reter as informações das sessões de terapia em sua base de dados pelo período de 12 anos, ela tem o suporte da legislação da Finlândia [2] que excluí a possibilidade de remoção desses registros, mesmo mediante pedido dos pacientes, contrariando claramente a lei de proteção de Dados da União Europeia, também conhecida como General Data Protection Regulation (GDPR).

E como desgraça pouca não é o bastante, ao que parece a empresa não tem nenhum tipo de apólice de seguro em relação ao vazamento dos dados, ou qualquer tipo salvaguarda em relação a uma potencial e óbvia ação judicial indenizatória por parte das vítimas.

O objetivo deste ensaio é mostrar que os profissionais de dados (engenheiros, cientistas e praticantes de Machine Learning) podem aprender com estes eventos catastróficos.

Eventos estes que fundamentam argumentos convincentes sobre a importância da implementação de contramedidas para redução ou mitigação da probabilidade destes eventos ocorretem em seus empregadores.

Contramedidas contra ataques adversariais em Machine Learning

Na minha palestra no PyCon Africa em agosto desse ano, eu falei sobre “Security in Machine Learning Engineering: Adversarial attacks and countermeasures” (Segurança em Engenharia de Machine Learning: Ataques Adversariais e contramedidas) em que em um dos exemplos eu abro um arquivo com a extensão .RData e mostro algumas instâncias do treinamento.

Os registros além de não estarem criptografados ou anonimizados devidamente, permitem inferir membros da base de dados, como no exemplo abaixo utilizado pelo usando o exemplo do Professor Karandeep Singh (@kdpsinghlab):

Tradução: Uma pessoa asiática de 91 anos com um histórico médico de psicose e tratada por hipertensão é hospitalizada pela universidade da Califórnia, no Hospital de São Francisco de 2016 e 2017. Fonte: [https://twitter.com/kdpsinghlab/status/1181474070006829057](https://twitter.com/kdpsinghlab/status/1181474070006829057)

O código completo da palestra pode ser encontrado no repositório no Github.

O ponto principal da palestra é que aplicações de Machine Learning devem levar em consideração aspectos de segurança em todas as fases do seu ciclo de vida, desde a extração de dados até o monitoramento do modelo em produção.

Se analisarmos os tipos de ataques adversariais, todos eles passam essencialmente por (i) manipulação dos dados e/ou (ii) ausência de manutenção de privacidade dos dados na geração dos modelos. Alguns dos tipos de ataques são:

Além desses aspectos, existe ainda a anonimização pode ajudar no processo de retirar qualquer vínculo dos usuários com os registros na base de dados.

A definição de anonimização de acordo com a Lei Geral de Proteção de Dados (LGPD) é do dado que, originariamente, era relativo a uma pessoa, mas que passou por etapas que garantiram a desvinculação dele a essa pessoa. Se um dado for anonimizado, então a LGPD não se aplicará a ele.

Ainda sobre a anonimização, a LGPD ainda ressalta* que um dado só é considerado efetivamente anonimizado se não permitir que, via meios técnicos e outros, se reconstrua o caminho para “descobrir” quem era a pessoa titular do dado — se de alguma forma a identificação ocorrer, então ele não é, de fato, um dado anonimizado e sim, apenas, um dado pseudonimizado e estará, então, sujeito à LGPD.*

Uma contramedida que é pouco comentada e que pode ser utilizada pelos engenheiros de machine learning é **privacidade diferencial, **que pode ser aplicada durante a coleta, transformação dos dados e até mesmo no momento da inferência dos modelos.

Mas primeiro, vamos ver a definição de privacidade diferencial, e um exemplo a grosso modo do que exatamente seria este mecanismo.

O que e Privacidade Diferencial?

Utilizando a definição da Wikipedia, a privacidade diferencial é um sistema para compartilhar publicamente informações sobre um conjunto de dados, descrevendo os padrões dos grupos dentro do conjunto de dados, enquanto retém informações sobre os indivíduos no conjunto de dados. A ideia por trás da privacidade diferencial é que, se o efeito de fazer uma única substituição arbitrária no banco de dados for pequeno o suficiente, o resultado da consulta não pode ser usado para inferir muito sobre um único indivíduo e, portanto, fornece privacidade.

Em outras palavras, alguns registros sofrerão um pouco de ruído para não seja possível a ligação/associação dos registros com os usuários, ao mesmo tempo em que as dinâmicas dos dados agregados não serão afetadas durante a análise dos dados e nem no treinamento dos modelos de Machine Learning.

Um exemplo simples de privacidade diferencial

Para entender a grosso modo o que é a privacidade diferencial, vamos imaginar o seguinte cenário que temos um instituto de pesquisa que vai abrir uma enquete para entrevistar algumas pessoas de forma aleatória.

Mas o objeto desta pesquisa não será algo como perguntar sobre intenção de voto para candidato a prefeito ou presidente. O estudo será para saber algo um pouco mais pessoal através da seguinte pergunta:

Você já traiu o seu esposo(a)/companheiro(a)?

A pergunta por si só pode parecer indiscreta e incomoda, mas como o objeto da pesquisa requer essa pergunta, ela terá que ser feita.

Entretanto, algumas pessoas podem se sentir desconfortáveis para dar uma resposta sincera; então um método é proposto pelo entrevistador do nosso instituto:

“Eu vou jogar uma moeda o alto, se der Cara você é *obrigado a me** **contar a verdade** se der *Corôa **você me conta o que quiser, mesmo sendo verdade ou não”.

E agora que entra o aspecto da privacidade diferencial na nossa pesquisa: Uma coisa que ninguém além dos pesquisadores sabe, e que ao invés de colocarem uma moeda honesta (com 50% de chance para cada um dos lados) os pesquisadores colocaram uma moeda viciada, com um fator de vício de 70% para a face Cara.

A grosso modo, na prática isso significa que a cada 10 entrevistados, existe a probabilidade de que 7 deles vão ter que falar a verdade.

E com exceção dos pesquisadores, todos que forem analisar estes dados agregados, não saberão qual a probabilidade das respostas estarem certas ou não. Contudo, todos saberão que há ruído indeterminado junto com as respostas corretas de uma forma que não tenha como ter uma associação dos registros com os entrevistados.

Esse mecanismo resolve dois problemas: (i) mantém a privacidade de quem está respondendo a pesquisa dado que um aspecto de incerteza indeterminado, e (ii) torna a ligação/associação das respostas aos indivíduos muito mais difícil; seja para quem está analisando os dados, seja em um potencial cenário de vazamento de dados.

Pacotes e soluções para privacidade diferencial

Diretamente do excelente EthicalML eu extraí algumas alternativas para o uso da privacidade diferencial que são:

  • Google’s Differential Privacy — Esta é uma biblioteca C ++ de algoritmos ε-diferencialmente privados, que podem ser usados para produzir estatísticas agregadas sobre conjuntos de dados numéricos contendo informações privadas ou confidenciais.

  • Microsoft SEAL — Microsoft SEAL é uma biblioteca de criptografía homomórfica de código aberto fácil de usar (licenciada pelo MIT) desenvolvida pelo grupo de Pesquisa de Criptografia da Microsoft.

  • PySyft — O PySyft separa os dados privados do treinamento do modelo, usando Multi-Party Computation (MPC) no PyTorch.

  • Tensorflow Privacy — Uma biblioteca Python que inclui implementações de otimizadores TensorFlow para treinar modelos de aprendizado de máquina com privacidade diferencial.

  • Uber SQL Differencial Privacy — Biblioteca da Uber para o uso de privacidade diferencial para consultas SQL.

Se houver demanda, eu faço alguns tutoriais aqui no blog ou no Medium sobre cada uma dessas ferramentas.

Considerações Finais

Ninguém sabe ainda das consequências: nem em relação às pessoas que roubaram os dados, e especialmente em relação às vítimas que tiveram a sua intimidade e acompanhamentos psicologicos expostos.

Como eu falei no meu artigo “[Machine Learning e o modelo de queijo suíço: falhas ativas e condições latentes](https://flavioclesio.com/machine-learning-e-o-modelo-de-queijo-suico-falhas-ativas-e-condicoes-latentes)” esse problema não será devido a um único fator, mas sim múltiplas falhas ativas e condições latentes que se alinharam e determinou o acontecimeno desse roubo de dados como:

Para os engenheiros de machine learning, fica uma grande lição de que segurança e privacidade são coisas sérias, e essas falhas mostram como a tecnologia e os seus processos devem ser levados de forma mais prudente e responsável possível.

E para os colegas de tecnologia da Finlândia ao que parece a marcha da regulamentação e a clava forte do governo vão agir.

Se você está em uma situação de crise, procure ajuda especializada. A vida sempre vale a pena. Abaixo alguns recursos para situações de crise:

Referências

Notas

[1] Texto original sobre a legislação no tocante ao uso dos dados:

Q: Voidaanko asiakkaan tiedot pyynnöstä poistaa tietosuojalainsäädännön mukaisesti? Useat saamamme pyynnöt ovat koskeneet asiakastiedon poistoa. Vastaamon käsittelemät hoidolliset potilastiedot kuuluvat kuitenkin lakisääteisiin potilasasiakirjoihin. Potilasasiakirjoilla tarkoitetaan potilaan hoidon järjestämisessä ja toteuttamisessa käytettäviä, laadittuja tai saapuneita asiakirjoja taikka teknisiä tallenteita, jotka sisältävät henkilön terveydentilaa koskevia tai muita henkilökohtaisia tietoja (laki potilaan asemasta ja oikeuksista 785/1992). Potilastietoihin sovelletaan paljon erityistä lainsäädäntöä (tästä tarkemmin selosteessa), joka sulkee pois tai rajoittaa useita yleisen tietosuoja-asetuksen mukaisia oikeuksia, mukaan lukien oikeus tietojen poistamiseen. Terveydenhuollon kontekstissa rekisteröidyn tietoja ei voida poistaa pyynnöstä. Emme täten voi poistaa tietoja, sillä terveydenhuollon ammattihenkilöillä on velvollisuus laatia potilasasiakirjamerkinnät kaikista potilaan palvelutapahtumista, kuten käynneistä. Nämä merkinnät on säilytettävä STM:n potilasasiakirja-asetuksessa (298/2009) ja sen liitteessä määritellyn ajan. Myöskään yksittäistä, jotakin palvelutapahtumaa koskevaa merkintää ei voida poistaa, ellei kyseessä ole selkeästi virheellinen kirjaus. Arviointi tehdään merkinnän laatimishetkellä vallinneen käsityksen näkökulmasta. Jos jokin tieto osoittautuu virheelliseksi ja se korjataan, sekä alkuperäisen että korjatun tiedon tulee olla myöhemmin luettavissa. Myös tilanteessa, jossa poistettaisiin potilaan hoidon kannalta tarpeeton tieto, potilasasiakirjoihin tulee tehdä merkintä tiedon poistamisesta. Q: Kauanko potilastietoja säilytetään? Kaikki potilasasiakirjat pitää säilyttää vähintään 12 vuotta siitä, kun tieto on merkitty; suurinta osaa tiedoista on kuitenkin säilytettävä koko potilaan elinaika ja vielä 12 vuotta kuoleman jälkeenkin (Sosiaali- ja terveysministeriön asetus potilasasiakirjoista https://finlex.fi/fi/laki/alkup/2009/20090298, ks. liite sivun alalaidassa). Vastaamo poistaa sellaiset henkilötiedot, joita sillä ei enää ole lakisääteistä velvollisuutta säilyttää, heti kun se on mahdollista

[2] Folheto adicional sobre as informações da legislação de dados: https://vastaamo.fi/files/potilasrekisteri_tietosuojaseloste.pdf