Considerações sobre a Notificação de de Incidente de Segurança da Informação no contexto da Lei Geral de Proteção de DadosData Protection Officer Course

Data Protection Officer Course – Uma análise sobre como se dá a notificação de incidente prevista no art. 48 da Lei 13.709/18 (LGPD)

O legislador talvez tenha pecado em não especificar exatamente o que entende por incidente de segurança, tal como fez em relação a outras definições cobertas pela lei, em seu artigo 5º, limitando-se a estabelecer o objeto – no caso, que acarretem dano aos titulares dos direitos com o acesso impróprio a seus dados pessoais.

“Não existe privacidade sem segurança”. Data Protection Officer Course

Este princípio consagrado na proteção de dados se faz presente na Lei Geral de Proteção de Dados. Porém, não há ambiente informacional plenamente seguro nem tampouco impenetrável.

No âmbito da segurança da informação, é razoável afirmar que mesmo que sejam tomadas todas as medidas possíveis para garantir a mesma, realisticamente é impossível assegurar que sua efetividade seja absoluta, ou seja, que nunca haverá um incidente que não venha de modo efetivo em dado momento no tempo, com variados níveis de impacto, a comprometer o ecossistema informacional.

Isto posto, como parte de uma abordagem baseada em avaliação de riscos, faz- se necessário estabelecer um processo que deva ser utilizado quando da detecção de incidentes de segurança. Esses controles que compõe o processo devem levar em consideração a ameaça em si e o quão sensíveis são os dados objeto do incidente.

Tal normatização já se encontra consagrada em alguns frameworks regulatórios baseados em melhores práticas, com especial destaque para a família de normas ISO 27XXX (ou 27K). A propósito desta, os controles básicos são apresentados no item 16 do anexo

Data Protection Officer Course – A da ISO 27001:2013 e melhores detalhados no também item 16, agora da ISO 27002:2013 que preconiza ter por objetivo “assegurar um enfoque consistente e efetivo para gerenciar os incidentes de segurança da informação, incluindo a comunicação sobre fragilidades e eventos de segurança da informação”.

Complementarmente, convém destacar a importância no tocante aos aspectos específicos relacionados às vulnerabilidades, olhando-as agora por um prisma mais abrangente do que o proposto por um sistema de gestão de segurança da informação (SGSI) como o que se estabelece a partir da ISO 27001, a menção às normas ISO 29147 e ISO 30111 (vulnerability disclousure e vulnerability handling processes, respectivamente).

Muito embora essas últimas sejam guidelines que têm como foco endereçar problemas decorrentes de potenciais vulnerabilidades identificadas em produtos e serviços online, as mesmas podem e devem servir de guias auxiliares de referência.

Há que se deixar claro, desde já, que o supracitado princípio de uma inexistência da privacidade num ambiente informacional inseguro, de fato não pressupõe a existência de uma utópica “segurança perfeita”, e que os legisladores tanto no caso da LGPD como em sua equivalente europeia, o General Data Protection Regulation (GDPR), foram sensíveis a isto, de modo notadamente mais assertivo no diploma legal europeu.

De igual forma, quando olhamos para os dados pessoais (e sua proteção técnica e jurídica) como uma espécie do gênero informação (dados lato sensu, pessoais ou não), precisamos também contextualizar, considerando a interpretação que é dada tanto no âmbito doutrinário como no normativo aos incidentes (ou eventos) de segurança da informação e sua relação com as espécies de dados que foram afetados em decorrência daqueles, sem no entanto relegar os aspectos legais atrelados à tais situações.

Em outras palavras: assim como nem todo incidente de segurança necessariamente envolve vazamento de dados ou comprometimento de todos dos princípios da SI a um só tempo (confidencialidade, integridade, disponibilidade, não-repúdio, autenticidade, privacidade e legalidade), nem todo incidente de segurança, mesmo que envolva dados pessoais, necessariamente implica em responsabilização do agente de tratamento caso este comprove não ter sido negligente ou que a falha de segurança deu-se em virtude de algum fator alheio e aquém de seu controle. Quanto a isso, os artigos 82(1) e (3) do GDPR respaldam tal entendimento.

Essa análise se mostra oportuna quando observamos casos recentes no exterior e no Brasil, onde foram registradas ações de hackers alinhados aparentemente ao cyber-ativismo, que ao invadir sistemas, alegadamente não tiveram acesso a dados de consumidores/cidadãos.

Temos um exemplo de situação assim quando observamos o ataque recente à certisign e seu posicionamento tornado público, a respeito do ocorrido. Temos por um lado a comprovação da efetiva invasão, por parte do hacker: prints de telas do root, evidenciando acesso irrestrito – aparentemente – aos arquivos lá contidos.

Do outro, temos a nota divulgada pela certisign afirmando que não foram atingidos dados de clientes, parceiros e fornecedores, bem como – e aí o mais importante para todo o país – que as infraestruturas de chaves públicas brasileiras (ICP-Brasil), certificados digitais e chaves privadas, não foram de modo algum afetadas. Típico impasse que os norte-americanos chamam popularmente de “he said, she said”.

A verdade é que a gravidade de facto e extensão do ataque serão, sem demora, conhecidos e esperamos todos que realmente tenham sido limitados a uma invasão como demonstração “de habilidade” e com o intuito único de expor uma grave falha de segurança. Muito provavelmente, o MPDFT deverá, como fez diversas vezes em casos semelhantes no passado, solicitar maiores esclarecimentos à certisign.

O que temos efetivamente até o momento é a ocorrência de um grave incidente de segurança já admitido pela empresa, cujo negócio é segurança; que gerou além de grande espanto e até mesmo a crença de que se trataria de fake news a partir do momento em que a notícia passou a circular nos grupos de discussão de InfoSec, até enorme transformar-se numa enorme onda de preocupação em todo ecossistema, e tudo isso apenas considerados como efeitos do ataque os limitados ao que a própria empresa divulgou, através de uma declaração formal pública, feita por uma liberalidade, sem maiores detalhamentos e comprovação dos aspectos técnicos envolvidos.

Para além de adentrar nas questões atinentes ao campo legal penal na situação recente relatada bem como em análogas, o que não é objeto do presente artigo, é nosso entendimento que há de se considerar a aplicação, futuramente, do previsto no artigo 48 da LGPD que versa sobre a obrigatoriedade de comunicação à autoridade nacional de proteção de dados também em caso de incidentes de segurança como o ocorrido, em consonância com os princípios previstos artigos 5º e 6º, VII.

Em nosso entendimento, muito embora a lei geral de proteção de dados tenha por objeto a tutela jurisdicional dos dados pessoais, sua especificidade não deveria obstar a possibilidade de, lançando mão de uma interpretação integrativa por analogia, expandir essa tutela e obrigação decorrentes do previsto no artigo 48 da LGPD, a saber a notificação de incidentes de segurança à ANPD, para eventos onde, notadamente, há a possibilidade de que danos aos indivíduos possam, de alguma forma, ter ocorrido, mesmo que não envolvam dadospessoais em princípio.

Até por carência de outros diplomas legais específicos, observamos com esperança que a LGPD chega também para auxiliar fortemente a que seja criada uma cultura orientada à segurança, compliance e transparência com relação a todo ciclo de vida de dados pessoais no ambiente das empresas e órgãos públicos. Isso, como efeito colateral, vai ensejar a criação um ambiente mais seguro lato sensu, não restrito aos dados pessoais, por questões óbvias.

Tal interpretação futura da lei tanto na esfera administrativa quanto junto aos tribunais, parece-nos não apenas factível como oportuna e benfazeja. Observando, claro, algumas exceções.

Um ataque a partir de um zero-day exploit (“vulnerabilidade de dia zero”), pode por exemplo, não chegar a gerar punição ao agente de tratamento. Numa extrapolação, chegamos à possibilidade de até desconsiderar que ocorreu uma violação, aos olhos da lei.

Isto considerado, em tempos atuais, onde segundo recente pesquisa em 13 grandes vazamentos registrados ao redor do globo, envolvendo apenas 11 empresas, foram afetadas mais de um bilhão de pessoas em 2018, quase corriqueiros e populares tornaram-se os termos “vazamento de dados” ou “ataques de hackers” na mídia tradicional não- especializada, antes de ser encarada como uma obrigação legal, uma apropriada e formal sinalização por parte de uma empresa após um incidente de segurança de grande impacto e repercussão, por si só já justificariam a formalização ante ao Estado como, no mínimo, uma forma de mitigar os impactos reputacionais suscitados perante o mercado e os consumidores/cidadãos. No máximo, atendendo a interpretação legal proposta.

Opiniões pessoais à parte, passamos a discorrer mais especificamente sobre o tema – a notificação de incidente de segurança em si – prevista pelo disposto no artigo 48 da LGPD, com o intuito de fornecer uma contribuição sobre o assunto, agora com uma visão quase que totalmente técnica, uma vez que na falta momentânea de parâmetros a serem estabelecidos pela ANPD, o texto da lei coloca o que deve constar, grosso modo, em tal documento sem no entanto, dizer como o mesmo deve ser produzido ou as minúcias envolvidas em sua elaboração.

Antes de aprofundarmos no tema, cabe retroceder ainda um pouco na discussão no intuito de estabelecer uma definição mais acurada sobre o que viria a ser “incidente de segurança”. De modo bastante sucinto, conceitua-se incidente de segurança como todo evento adverso relacionado à segurança. De acordo com o CERT.br, um incidente de segurança pode ser definido como “qualquer evento adverso, confirmado ou sob suspeita, relacionado a segurança de sistemas de computação ou de redes de computadores”.

Um incidente de segurança pode acarretar um ou mais resultados, dentre eles por exemplo fraudes, destruição de recursos de uma rede ou vazamento de informações. Ao relacionarmos à proteção de dados pessoais, este último é significativamente mais recorrente, muito embora não seja o único tipo de incidente, como visto.

Sendo assim, o legislador talvez tenha pecado em não especificar exatamente o que entende por incidente de segurança, tal como fez em relação a outras definições cobertas pela lei, em seu artigo 5º, limitando-se a estabelecer o objeto – no caso, que acarretem dano aos titulares dos direitos com o acesso impróprio a seus dados pessoais.

Voltando-nos ao texto da lei, a previsão legal para a resposta a incidentes de segurança vem no capítulo VII da LGPD, justamente o que trata da segurança da informação e das boas práticas a serem adotadas para tanto. Em seu artigo 48, consta: Data Protection Officer Course

Art. 48. O controlador deverá comunicar à autoridade nacional e ao titular a ocorrência de incidente de segurança que possa acarretar risco ou dano relevante aos titulares.

§ 1º A comunicação será feita em prazo razoável, conforme definido pela autoridade nacional, e deverá mencionar, no mínimo:
I – a descrição da natureza dos dados pessoais afetados; II – as informações sobre os titulares envolvidos;
III – a indicação das medidas técnicas e de segurança utilizadas para a proteção dos dados, observados os segredos comercial e industrial;
IV – os riscos relacionados ao incidente;
V – os motivos da demora, no caso de a comunicação não ter sido imediata; e
VI – as medidas que foram ou que serão adotadas para reverter ou mitigar os efeitos do prejuízo.

Muito embora a LGPD seja fortemente inspirada na sua equivalente europeia, o GDPR, alguns pontos constantes nesta não foram replicados no ordenamento pátrio, como por exemplo uma definição clara sobre qual deve ser o prazo entre a descoberta do incidente e a efetiva notificação por parte do controlador dos dados.

No regulamento europeu este prazo é de 72 horas, muito embora não de maneira peremptória, porém não desacompanhada de uma justificativa pelo atraso. Não que tal (in)determinação de prazo seja algo exclusivo do diploma brasileiro.

Ao contrário. Observa- se, por exemplo, que nos Estados Unidos ainda que neste ainda careça de uma lei Federal tratando especificamente de vazamentos de dados, todos os estados têm leis que tratam sobre a matéria e, em diversas delas, não há igualmente exatidão quanto ao prazo requerido, prevendo apenas que a notificação ocorra “sem atrasos indevidos”.

Da mesma forma, o Digital Privacy Act canadense estabelece que a notificação por parte da organização deva ocorrer “assim que possível” a partir do momento em que determinar que o vazamento ocorreu.

Tratando especificamente sobre a notificação do artigo 48 da Lei Geral de Proteção de Dados, tomando por base boas práticas e o que já é aplicado por outras autoridades nacionais de proteção de dados, propomos que seja dividido o processo de identificação para posterior notificação de incidentes de segurança envolvendo dados pessoais da seguinte forma:

1. Identificação do incidente (descoberta/confirmação do possível vazamento)
2. Avaliação do incidente (registro do incidente e avaliação dos riscos envolvidos)
3. Elaboração da notificação

A identificação do incidente pode se dar de diversas formas: através de denúncia por parte de titular do direito; pelo emprego de ferramentas automatizadas que detectam vazamentos de dados; através do reporte por parte de um operador (data processor); ou ainda por parte de um terceiro.

É mandatório que tão logo seja identificado, o incidente deva ser informado ao encarregado de proteção de dados. Quando houver na empresa, também ao CISO/CIO.

Num segundo momento na fase de identificação do incidente, é necessário que se realize uma investigação sobre o possível incidente. Muito embora não haja um prazo estabelecido na lei, tal investigação não pode ser deveras demorada ou aprofundada, sob o risco de implicar numa demora excessiva em notificar o incidente. Data Protection Officer Course

Um “razoável grau de certeza” deve ser o motivador para prosseguimento no processo de notificação.

Uma vez superada a fase de identificação, passa-se à fase de avaliação do incidente. Deve haver no sistema de gestão de segurança da informação do agente de tratamento um registro de todos os incidentes de segurança, inclusive os que não envolvam dados pessoais bem como os que, mesmo envolvendo, posteriormente sejam considerados de menor potencial ofensivo aos direitos e garantias dos titulares.

Tal registro é considerado uma boa prática de governança. Além do mais, o mesmo é passível de auditoria. O registro de incidente normalmente contempla os seguintes dados:

• Quando ocorreu o incidente

• Quais dados foram afetados

• Quais e quantos titulares foram afetados

• Quais as causas do incidente

• Quais seus efeitos e consequências

• Qual o plano para mitigação desses efeitos e suas respectivas consequências

• Uma linha do tempo do incidente, incluindo quando houve o primeiro alerta quanto ao incidente e quando de fato foi determinado que o mesmo ocorreu

• As decisões relativas à notificação

A avaliação dos riscos envolvidos no incidente sucede ao registro. Em termos gerais, a mesma considera habitualmente os seguintes pontos:

• O tipo do incidente/vazamento

• O tipo de dados pessoais afetados

• A sensibilidade dos dados afetados

• O volume de dados afetados

• O número de titulares atingidos

• A natureza do processamento

• A facilidade ou não de identificação dos titulares (se por exemplo, os dados estavam criptografados ou anonimizados, o risco reduz)

• A gravidade das consequências para os titulares

• A extensão das consequências para os titulares

• Se houve menores entre os titulares

• Caso haja uma falha de confidencialidade, quais as possíveis intenções de quem perpetrou o ataque que gerou o incidente

Como resultado desta avaliação, os possíveis resultados com relação aos direitos dos titulares são:

• Não gera risco relevante
• Gera risco relevante
• Gera risco elevado

Muito embora, diferentemente do GDPR que preconiza que a depender da avaliação, a distinção entre risco relevante e risco elevado pode determinar que a notificação ocorra apenas para a autoridade nacional de dados ou para esta e também aos titulares dos direitos, respectivamente, tal previsão não resta de modo explícito na LGPD.

Não pode-se hoje definir exatamente qual tratamento deverá ser dado com relação à publicização ou não junto aos titulares quando de um incidente de segurança, uma vez que a discricionariedade quanto à comunicação aos titulares recai, tal como previsto no artigo 48, § 2º, na esfera de competência da ANPD e esta ainda não teve tempo suficiente para editar as orientações que irão nortear o mercado e os consumidores/cidadãos. Resta então classificar os riscos e, a depender do que venha a ser estabelecido pelo órgão regulador, aguardar qual o entendimento será adotado.

Por fim, o processo se completa com a formatação do relatório com a notificação em si, contemplando as informações destacadas no parágrafo 1º do referido artigo da lei.

Data Protection Officer Course
Muito embora todo o processo descrito não esteja formalmente no texto da LGPD, o mesmo baseia-se na prática utilizada tanto no âmbito do GDPR quanto nas melhores práticas de governança de segurança da informação, incluídas aí as já mencionadas normas ISO citadas anteriormente e as orientações fornecidas em documento produzido pelo WP29 – Article 29 Working Party (substituído após a entrada em vigência em 25 de maio do ano passado pelo European Data Protection Board – EDPB) sobre data breach notifications.

Certamente, com a estruturação da autoridade nacional para, a exemplo da ICO e CNIL (autoridades nacionais do Reino Unido e França, respectivamente), estabelecer e divulgar parâmetros e guidelines para o reporte de incidentes de segurança de dados pessoais, bem como outras tantas orientações de caráter mais técnico, teremos em breve os subsídios que deverão não diferir por demais, acreditamos, dos que são colocados no presente texto.

Até lá, para todos nós que já estamos atuando e envolvidos nos aspectos tecnológicos e legais na longa e difícil (não impossível, decerto) estrada rumo ao compliance na lei geral de proteção de dados em nossos clientes resta, no momento, utilizarmos a experiência e padrões já consagrados internacionalmente como orientação.

Marcilio Braz é advogado, gerente de projetos em TI, professor e fundador da Privacy Academy.

Disponível também em:

Migalhas:
https://www.migalhas.com.br/dePeso/16,MI295440,81042-Consideracoes+sobre+a+notificacao+de+incidente+de+seguranca+da (publicado em 01/02/2019)

Data Protection Officer Course