LGPD e a segurança da informação
Gisele Kauer, Advogada em proteção de dados/senior data protection analyst no Banco Safra
A LGPD – Lei Geral de Proteção de Dados, como o próprio nome sugere, tem uma abordagem exclusivamente voltada à proteção de dados pessoais, ou seja, a operações de tratamento (processamento) de informações relacionadas a pessoa natural (pessoa natural = pessoa física, ser humano, não pode ser empresa) identificada ou identificável (definição de “dado pessoal” dada pelo art. 5º, I, da LGPD).
Este foco específico da lei é excelente, pois traz uma proteção ao indivíduo que é assegurada na Constituição Federal: nosso direito fundamental à privacidade (art. 5º, X, Constituição Federal, que diz respeito à inviolabilidade da intimidade e da vida privada).
Mas, a proteção de dados só é verdadeiramente efetiva quando vem acompanhada de segurança da informação que, muitas vezes, é deixada de lado, não somente no texto da lei em si (a LGPD até fala sobre segurança da informação, porém de maneira consideravelmente superficial, e não suficientemente objetiva/específica), mas também pelas empresas e órgãos públicos que, por tantas vezes, vão em busca da adequação jurídica em proteção de dados, mas “se esquecem” da elaboração de um sistema adequado de segurança da informação (algo que diga respeito a um nível adequado de governança, com regras e controles que façam sentido dentro da realidade da empresa – tamanho, modelo de negócio, tipo de produto ou serviço oferecido, vulnerabilidades específicas etc. – e que sejam efetivos na prática, e não somente “no papel”).
A proteção de dados não pode ser um elemento isolado. Ela deve fazer sentido em todo o contexto. E, neste artigo, você vai conhecer algo que pode (e deve) conversar com o seu programa de adequação à LGPD.
Proteção de dados x segurança da informação: Qual é a diferença? (Conceitos)
Bom, conforme mencionei acima, a proteção de dados tem por objeto proteger os dados relativos a pessoa natural, com um foco na privacidade, no direito à individualidade.
A título de curiosidade, esse conceito não é exclusivo da LGPD. É o mesmo adotado no GDPR – Regulamento Geral sobre a Proteção de Dados, da União Europeia [Artigo 4º (“Definições”), (1), página 33 no link acima], bem como pelo NIST – National Institute of Standards and Technology, dos EUA, como se fosse o “Inmetro” norte-americano, que traz padrões de qualidade especialmente voltados à tecnologia e ciência – padrões adotados inclusive pelo FBI. Vocês podem verificar a definição de “personally identifiable information” neste link aqui, que é o glossário do NIST.
Já a segurança da informação não se limita à proteção de dados pessoais. Vamos à definição:
“Segurança da Informação compreende a proteção das informações, sistemas, recursos e demais ativos contra desastres, erros (intencionais ou não) e manipulação não autorizada, com o objetivo de reduzir a probabilidade e o impacto de incidentes de segurança”.
“Nem todo incidente de segurança da informação é uma violação de dados pessoais. Mas toda violação de dados pessoais é um incidente de segurança”. Guardem esta informação.
Os infográficos a seguir irão nos ajudar na identificação das formas mais efetivas de prevenção e resposta a ataques envolvendo a exploração de vulnerabilidades – e até a compreender porque a LGPD, sozinha, não necessariamente diz respeito à prevenção de incidentes de segurança (estes que podem resultar, como consequência, em violações à LGPD).
Segurança da informação: Vulnerabilidade, ameaça, risco, incidente, dano
Para falarmos na prevenção a qualquer tipo de incidente de segurança (seja ele proposital ou acidental) precisamos identificar estes 5 itens: vulnerabilidade; ameaça; risco; incidente; e dano. Ou seja, entender “o que é o que” na situação concreta que estamos analisando.
Recomendo olharem no infográfico após a leitura de cada item, para entenderem visualmente como eles se integram.
1 – Vulnerabilidade: É a “porta aberta” na empresa, no sistema, aquilo que deve ser protegido. A ISO 27000 (a norma internacional referência em gerenciamento de segurança da informação) usa a palavra “fraqueza” (“weakness”) para definir “vulnerabilidade”. Uma fraqueza (em determinado controle ou ativo) que pode ser explorada por uma ou mais ameaças – definição baseada na ISO 27000.
Vale dizer que a vulnerabilidade é sempre interna (do próprio sistema, empresa, site, aplicativo, etc.). É realmente como deixar uma porta destrancada – deixar a chave da porta com pessoas não confiáveis.
2 – Ameaça: Uma potencial causa de um incidente indesejado, que pode resultar em danos a um sistema ou organização – definição baseada na ISO 27000.
Geralmente, ameaça conta com um “agente de ameaça”, aquele que se aproveita de uma vulnerabilidade (conforme mostra o infográfico abaixo, que se aproveita da “porta aberta”).
3 – Risco: É a probabilidade de uma ameaça (ou agente de ameaça) “explorar” determinada vulnerabilidade – definição baseada na ISO 27000. Por exemplo, qual é a chance de um determinado tipo de malware afetar o sistema X? É um “cálculo” de probabilidades, basicamente.
Os riscos devem ser “metrificados”. Assim, é possível priorizar em quais ameaças focar e quais vulnerabilidades estão realmente suscetíveis a ataques, por exemplo.
4 – Incidente: É quando uma ameaça se manifesta. Por exemplo, quando um cracker explora formas de adentrar um sistema.
Incidentes são eventos indesejados ou inesperados, que têm uma chance (risco) significativa de comprometer o sistema, site, empresa, etc. – definição baseada na ISO 27000.
5 – Danos: Por fim, os danos são as possíveis consequências de um incidente, exatamente as consequências que desejamos evitar.
Os danos podem ser diretos (como a indisponibilidade de um e-commerce ou um acesso a informações confidenciais de uma empresa) e Indiretos (como a queda das ações da empresa na bolsa de valores ou perda de clientes).
É importante lembrar que, mesmo que a sua casa/apartamento tenha grade, portão, portaria 24h, câmeras de segurança, ainda é possível que uma pessoa mal-intencionada entre, certo?
O mesmo ocorre com sistemas. Por isso, estamos falando em prevenção, e não em impossibilitar ataques, blindar sistemas, impedir fraudes. Não existe 100% quando falamos de segurança. Lembre-se disso.
Quando analisarmos o caso concreto a seguir o primeiro passo será identificar quais são as vulnerabilidades encontradas em determinado servidor ou sistema operacional, ou seja, quais portas estão abertas. E assim por diante, identificando cada um dos cinco itens que foram listados acima, para então chegar numa resposta (ou quase isso) sobre as melhores formas de prevenção
Muitas vezes focamos na ação (que é bem importante, é claro), mas a análise do objeto a ser protegido + identificação das vulnerabilidades são necessárias para que a ação (prevenção) seja efetiva.
Pensar na ação sem antes analisar o cenário como um todo pode resultar numa escolha de ações de prevenção inadequadas, insuficientes ou não efetivas em relação às vulnerabilidades e ameaças que colocam em risco o objeto que queremos proteger.
O exemplo pode parecer um tanto exagerado (e “bizarro”), mas tenho certeza que vocês irão lembrar dele por muito tempo (e quem sabe utilizem em aulas e palestras futuramente, ou até mesmo para explicar para um cliente ou na empresa de vocês que segurança não é sobre “usar aquele antivírus que todo mundo está usando” ou “procurar no Google “Política de Segurança da Informação’ e usar um modelo genérico”).
Bom, a seguir, vocês verão dois infográficos com exemplos um tanto “familiares” da segurança da informação.
Penso que concordamos que, em ambos os casos, há uma ou mais formas de evitar a concretização do incidente, certo? Vocês talvez tenham pensado em outros mecanismos de defesa/prevenção, mas, para fins didáticos irei focar nas seguintes ideias:
Tanto no exemplo 1 quanto no 2, um backup atualizado e mantido em outro local físico poderia garantir uma recuperação em relação aos incidentes. Portanto, em ambos os exemplos seria um mecanismo efetivo que deve ser adotado.
Mas, a recuperação por meio de um backup, infelizmente, não é tão rápida como se imagina. Pode levar semanas até que um negócio volte a operar normalmente, ainda que com um backup realizado corretamente. Portanto, ainda que necessário e aplicável nos dois casos, existem formas de prevenção que podem ser aplicadas em momentos anteriores ao incidente.
Estas formas de prevenção devem ser focadas em: corrigir uma vulnerabilidade (ou seja, “diminuir” uma abertura que soe convidativa para determinadas ameaças); e afastar um tipo de ameaça específica de explorar as vulnerabilidades.
No exemplo 1, podemos falar em controles físicos, como portas corta fogo, por exemplo.
No exemplo 2, podemos falar em atualizações de software frequentes e, a depender do malware, de um firewall eficiente, por exemplo.
Agora, vamos ao meu exemplo “ridículo”! Mas que ajuda a visualizar a ideia e a usarmos essa lógica com mais facilidade em casos mais complexos:
No exemplo 1, uma firewall ou um update do software não faria muita diferença para prevenir um incêndio.
No exemplo 2, uma porta corta fogo não impediria um malware de acometer o sistema da empresa.
Essa foi a forma “caricata” que encontrei para expor um dos maiores problemas que temos hoje em questão de legislação específica e até mesmo dentro dos programas de segurança/governança (nos setores público e privado).
Governança é sobre “fazer regras” (“como algo deve ou não deve” ser feito, usado, executado, etc.), e essas regras se tornam um imenso problema quando quem as faz não compreende o objeto sobre o qual elas dizem respeito.
O resultado disso? Algo como procedimentos de segurança sugerindo uma instalação de antivírus para a proteção de um servidor (desconsiderando possíveis ameaças físicas, como um incêndio); ou uma política tratando um antivírus como solução para qualquer tipo de malware, desconsiderando as peculiaridades de cada subtipo de malware existentes – na realidade temos ataques como o WannaCry (ransomware), que se utilizou de uma brecha de segurança no Windows 10 e sua correção dependia da atualização do software para a correção da falha de segurança – nenhum antivírus poderia “segurar” o ataque.
Para concluir, um dos meus objetivos aqui foi demonstrar como é bem mais simples propor uma forma de prevenção com essa esquematização, com base na ISO 27001/27002, em matéria de segurança da informação e considerando o que falei logo no início: “Nem todo incidente de segurança da informação é uma violação de dados pessoais. Mas toda violação de dados pessoais é um incidente de segurança”. Este conhecimento é importante para a proteção dos dados pessoais na sua empresa, ou seja, para a adequação à LGPD ou outra legislação/regulamento de proteção de dados aplicável.
A minha mensagem com isso é: a atuação ideal é uma integração entre as áreas técnica e jurídica. Ambas são importantes, têm funções diferentes e, preferencialmente, devem coexistir para garantir um nível adequado de proteção de dados pessoais.
Espero que este artigo tenha sido útil para você. Até a próxima!
Advogada em proteção de dados/senior data protection analyst no Banco Safra. Graduada em Direito pela Faculdade de Direito de São Bernardo do Campo (FDSBC) e certificada em Financial Markets pela Yale University. Palestrante convidada na EACH-USP e na FDSBC. ISO/IEC 27001 (Information Security) certified. Coautora do capítulo “Regulation of Personal Data Processing” na International Encyclopaedia of Laws (IEL) for Cyber Law. Professora na Associação Brasileira de Propriedade Intelectual (ABPI) e na Privacy Academy.
